해외여행을 마치고 인천공항에 도착했습니다. 출국 전에 이용했던 주차대행 서비스 덕분에 공항 주차장에 제 테슬라가 대기하고 있었죠. 주차대행 시스템은 간단합니다. 대행사가 차를 주차장에 세워두고, 카드키를 뒷바퀴 근처에 두면 제가 찾아가는 방식이에요.

문제는 여기서 시작됐습니다.

추운 겨울 주차장에서 차를 발견한 순간, 오랜만에 보는 제 차가 너무 반가웠어요. 그런데 너무 익숙한 습관 때문에 실수를 하고 말았습니다. 뒷바퀴에 둔 카드키를 챙기는 걸 완전히 잊어버리고, 스마트폰 앱으로 차문을 열고 그대로 집으로 출발해버린 거예요.

출발한지 한 참이 지나서야 카드키를 안챙겼다는 걸 깨달았습니다. 인천공항 주차장 바닥에 쓸쓸하게 버려진 카드키를 생각하니 가슴아프네요.

결국 카드키를 다시 마련하게되었습니다.

테슬라 카드키 재발급 방법

1. 공식 홈페이지에서 주문하기

테슬라 카드키는 공식 홈페이지나 테슬라 앱의 Shop 메뉴에서 구매할 수 있습니다.
https://shop.tesla.com/ko_kr/product/key-card

• 테슬라 공식 스토어 접속
• 액세서리 카테고리에서 ‘Key Card’ 검색
• 가격은 약 2-3만원 대 (모델에 따라 상이)
• 주문 후 배송까지 약 1-2주 소요

2. 카드키 등록하기

새 카드키가 도착하면 차량에 등록해야 합니다.

등록 방법:

1. 차량 터치스크린에서 ‘제어 > 잠금장치’ 메뉴 진입
2. ‘키 추가’ 또는 ‘키 관리’ 선택
3. 새 카드키를 센터 콘솔의 카드 리더기에 터치
4. 화면 지시에 따라 인증 절차 진행
5. 기존에 등록된 카드키나 폰키로 승인
6. 등록 완료!

3. 분실한 카드키 삭제하기 (중요!)

보안을 위해 분실한 카드키는 반드시 차량에서 삭제해야 합니다.

• **’제어 > 잠금장치 > 키 관리’**에서 분실한 키 선택
• ‘삭제’ 버튼으로 등록 해제
• 이제 분실한 카드키로는 차문을 열 수 없습니다

교훈: 주차대행 이용 시 체크리스트

이번 일로 배운 교훈을 공유합니다.

주차대행 픽업 전 확인사항

• 카드키 위치 미리 확인 (보통 뒷바퀴, 타이어 휠 근처)
• 차 인수 후 즉시 카드키 회수
• 스마트폰으로 문 열기 전에 카드키부터 챙기기
• 카드키 확인 후 차량 출발

카드키 보관 팁

• 운전석 수납공간에 예비 카드키 보관
• 집에 여분의 카드키 하나 더 보관
• 지갑이나 카드지갑에 함께 넣어두기

마무리하며

테슬라는 스마트폰 키가 너무 편리해서 오히려 카드키의 존재를 잊기 쉽습니다. 하지만 배터리 방전, 스마트폰 고장 등 만약의 상황을 대비해 카드키는 꼭 필요한 백업 수단이에요.

여러분도 주차대행이나 발레파킹 이용 시, 카드키 회수를 잊지 마세요! 저처럼 허탈한 경험을 하지 않으셨으면 좋겠습니다.

사람을 한 단어로 설명하기는 어렵다.
그래서 우리는 종종 비유를 쓴다.

별자리, 날씨, 계절.
그리고 오늘은 색이다.

이건 성격을 규정하기 위한 이야기가 아니다.
그저 사람을 조금 더 이해해보려는,
가벼운 이야기다.

빨간색을 좋아하는 사람

빨간색을 좋아하는 사람은
대체로 에너지가 앞서 있다.

하고 싶은 일이 생기면
“좀 더 생각해볼까?”보다는
“일단 해보자”가 먼저 나온다.

감정 표현이 빠르고, 솔직하다.
기쁜 건 기쁘다고 말하고
싫은 건 싫다고 말한다.

곁에 있으면 일이 빨리 진행된다.
대신, 가끔은 속도가 부담스러울 수도 있다.

파란색을 좋아하는 사람

파란색을 좋아하는 사람은
조용히 중심을 잡는다.

말수는 많지 않지만
생각은 늘 한 발 앞서 있다.
계획과 순서를 중요하게 여긴다.

약속을 가볍게 여기지 않고
한번 맡은 일은 끝까지 해내려 한다.

눈에 잘 띄지는 않지만
없으면 가장 먼저 티가 나는 사람이다.

노란색을 좋아하는 사람

노란색을 좋아하는 사람은
세상을 조금 가볍게 바라본다.

새로운 걸 보면 먼저 웃고,
아이디어가 떠오르면 말부터 나온다.
이야기가 여기저기 튀어 다닌다.

함께 있으면 분위기가 밝아진다.
대신, 대화가 길어질 가능성도 크다.

회의 시간에 노란색이 있다면
시간은 늘어나고, 웃음도 늘어난다.

초록색을 좋아하는 사람

초록색을 좋아하는 사람은
사이의 온도를 잘 안다.

누군가 불편해하면 먼저 눈치채고,
갈등이 생기면 부드럽게 넘기려 한다.

자기 주장을 세게 내세우진 않지만
늘 그 자리에 있다.

조용하지만 오래 남는 사람.
돌아보면 항상 곁에 있었던 사람이다.

검은색을 좋아하는 사람

검은색을 좋아하는 사람은
쉽게 자신을 드러내지 않는다.

말이 적고, 선택이 분명하다.
불필요한 걸 싫어하고
자기 기준이 뚜렷하다.

가까워지기까지 시간이 걸리지만
한번 신뢰하면 오래 간다.

가볍지 않다.
그래서 더 믿음이 간다.

흰색을 좋아하는 사람

흰색을 좋아하는 사람은
단순함을 원한다.

복잡한 감정, 복잡한 관계보다
정돈된 상태를 좋아한다.
마음이 어지러울수록
흰색을 찾게 된다.

새로운 시작에 대한 거부감이 적고
비워두는 것의 가치를 안다.

흰색은 아무것도 없는 색이 아니라
아직 채워지지 않은 색이다.

그래서, 이 이야기는

사람은 한 가지 색으로 설명되지 않는다.
우리는 상황에 따라 색이 바뀐다.

다만,
요즘 내가 어떤 색에 끌리는지는
지금의 마음 상태를 말해줄지도 모른다.

오늘 당신이 가장 자주 고르는 색은 무엇일까.
그리고 그 색은
당신의 어떤 이야기를 담고 있을까.

태그

#색으로보는성격 #컬러심리 #사람이야기
#일상기록 #감성에세이

이 글은 코드를 GitHub에 올리기만 하면
Docker 이미지가 자동으로 GHCR에 등록되는 흐름를 직접 만들어보는 따라하기 글이다.

0. 전체 흐름 미리 보기

우리가 만들 구조는 이렇다.

이제 하나씩 따라가 보자.

1⃣ GitHub에서 앱용 Repository 만들기

먼저 GitHub 에서 컨테이너로 배포할 앱 전용 레포지토리를 만든다.

Repository 생성

1. GitHub 접속

2. New repository 클릭

3. 아래처럼 설정

• Repository name: my-first-ghcr-app

• Public (처음엔 공개가 편함)

• Add a README 체크

생성 버튼 클릭

2⃣ 최소한의 앱과 Dockerfile 준비

예시: 아주 간단한 웹앱 구조

index.html

<h1>Hello GHCR 👋</h1> <p>This app is running from a container.</p>

Dockerfile

FROM nginx:alpine COPY index.html /usr/share/nginx/html/index.html

지금은 **“컨테이너가 된다”**는 게 핵심이라
앱은 최대한 단순하게 시작한다.

3⃣ GitHub Actions로 자동 빌드 설정하기

이제 핵심 단계다.
push 하면 자동으로 GHCR에 이미지가 등록되도록 설정한다.

.github/workflows/docker.yml 생성

docker.yml

name: Build and Push to GHCR

on:
  push:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and Push
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.actor }}/my-first-ghcr-app:latest

커밋 & 푸시

4⃣ GHCR에 이미지가 자동 등록되는 순간

푸시가 끝나면:

1. GitHub → Actions 탭

2. 워크플로우 실행 확인

3. 성공하면

GHCR 확인 경로

• GitHub 프로필

• Packages 탭

• my-first-ghcr-app 패키지 생성됨

이미지 주소는 이렇게 된다:

ghcr.io/깃허브아이디/my-first-ghcr-app:latest

5⃣ 이 이미지, 어디서든 실행 가능

이제 이 이미지는:

• 시놀로지 Container Manager

• 개인 서버

• VPS

• 로컬 Docker

어디서든 실행 가능하다.

docker pull ghcr.io/아이디/my-first-ghcr-app:latest docker run -d -p 8080:80 ghcr.io/아이디/my-first-ghcr-app:latest

6⃣ 왜 이 방식이 좋은가

이 구조의 핵심 장점은 딱 3가지다.

1. GitHub = 코드 + 이미지의 기준점

2. 빌드 자동화 (사람 손 안 탐)

3. 시놀로지 배포와 자연스럽게 연결

“이미지를 어디에 저장할까?”라는 고민이 사라진다.

#GitHub #GHCR #Docker #GitHub Actions, #CI/CD
#Synology #시놀로지 도커 #배포 자동화
#개인 서버 #홈서버

결론부터 한 줄로 정리하면

Synology의 Container Manager는 Docker CLI 위에 얹힌 “관리 UI”이고,
실제 Docker 엔진은 리눅스 백그라운드에서 그대로 돌아가고 있다.

전체 구조 한 번에 보기

1⃣ Docker CLI와 Container Manager의 관계

Docker CLI

• docker ps, docker run, docker compose up

• 진짜 Docker를 직접 조작하는 도구

• SSH 접속해서 실행

• 표준 Docker 환경과 동일

Container Manager

• DSM 웹에서 클릭으로 관리

• 내부적으로는 Docker API를 호출

• CLI 명령을 대신 실행해주는 관리자

즉,

Container Manager = docker 명령을 대신 쳐주는 GUI

2⃣ “Docker는 어디에 존재할까?”

Synology에서 Docker는 이렇게 관리됩니다.

실제 Docker 위치

• DSM 내부 리눅스 OS

• dockerd 데몬이 백그라운드에서 상시 실행

• Synology가 빌드·패키징한 Docker 엔진

사용자가 직접 보는 건

• Docker 엔진 자체

• Container Manager UI

• SSH로 접근한 Docker CLI

3⃣ Container Manager가 하는 일 (정확히)

Container Manager는 새로운 컨테이너 시스템이 아닙니다.

모두 Docker CLI로도 100% 동일하게 제어 가능

4⃣ CLI로 만든 컨테이너, UI에서 보일까?

보입니다. 완벽하게.

docker run -d -p 3000:3000 my-app

• Container Manager → 컨테이너 목록에 바로 표시

• 중지 / 재시작 / 로그 확인 가능

반대로도 마찬가지입니다.

UI에서 만든 컨테이너 = CLI에서도 동일하게 존재

5⃣ Docker Compose는 어떻게 관리될까?

Synology의 Project 기능은 사실상:

Docker Compose 관리 전용 UI

내부 동작

• docker-compose.yml 저장

• docker compose up/down 실행

• 컨테이너들을 하나의 프로젝트 단위로 묶어 관리

차이점

6⃣ Synology가 “Docker를 통제”하고 있을까?

아니요. Docker는 표준 Docker입니다.

다만,

• DSM에 맞게 패키징

• 권한 / 볼륨 경로를 Synology 방식으로 관리

• GUI 중심 운영을 권장

그래서 느낌은 이렇습니다.

Docker는 완전히 열려 있는데
Synology가 안전한 울타리(UI) 를 씌워둔 상태

7⃣ 언제 CLI를 쓰고, 언제 UI를 쓸까?

Container Manager가 좋은 경우

• 서비스 운영

• 상태 확인

• 재시작, 로그 확인

• NAS 관리 목적

Docker CLI가 필요한 경우

• 자동 배포 (CI/CD)

• GitHub Actions 연동

• 스크립트 기반 관리

• 복잡한 compose 구성

• 개발자 워크플로우

실전에서는 둘 다 씁니다.

핵심 정리

• Docker는 DSM 내부 리눅스에서 정상적으로 실행

• Container Manager는 Docker 위에 얹힌 관리 UI

• CLI UI는 같은 Docker 엔진을 공유

• 컨테이너는 하나의 실체, 접근 방법만 다름

Synology Container Manager는 시놀로지 NAS에서
Docker 컨테이너를 GUI로 쉽게 관리할 수 있게 해주는 공식 앱입니다.
예전의 _Docker 패키지_가 발전·개편된 형태라고 보면 이해가 쉬워요.

한 줄 요약

NAS 위에서 웹서비스·자동화 도구·개인 앱을 컨테이너로 띄우고 관리하는 통합 관리자

왜 쓰는 걸까?

Container Manager를 쓰면 다음 같은 일이 가능합니다.

• 개인 웹앱을 NAS에서 바로 실행
• Home Assistant, AdGuard, Gitea 같은 서비스 서버 없이 운영
• 개발 중인 앱을 테스트/배포 환경으로 활용
• Docker 명령어 몰라도 클릭 몇 번으로 운영

주요 기능 정리

1⃣ 컨테이너 관리 (핵심)

• 컨테이너 생성 / 시작 / 중지 / 재시작
• CPU·메모리 사용량 실시간 확인
• 로그(Log) 확인
• 환경변수, 포트, 볼륨 설정을 UI로 관리

2⃣ 이미지(Image) 관리

• Docker Hub 등에서 이미지 검색·다운로드
• 로컬 이미지 버전 관리
• 이미지 기반으로 컨테이너 생성

3⃣ 프로젝트(Project) = Docker Compose

• docker-compose.yml 기반으로 여러 컨테이너를 한 번에 관리
• 웹앱 + DB + 캐시 구조에 매우 유용
• “프로젝트 시작/중지” 개념으로 묶어서 운영 가능

4⃣ 볼륨 & 네트워크

• NAS 폴더 컨테이너 연결 (데이터 영구 보관)
• 컨테이너 간 전용 네트워크 구성

언제 특히 유용할까?

이런 경우라면 꼭 써볼 만해요

• 내가 만든 웹앱을 NAS에 올리고 싶을 때
• React / Next / API 서버를 집 서버에서 운영
• Obsidian Publish 대체용 개인 위키
• 블로그 자동화, 크롤러, 배치 작업
• 홈 서버 입문자 (CLI 부담 없이)

Docker CLI와의 관계

구분	Container Manager	Docker CLI
사용 방식	웹 UI	터미널
난이도	쉬움	중~상
Compose 지원
자동화/스크립트	제한적	매우 강력

입문 & 운영은 Container Manager,
완전 자동화는 CLI 병행이 가장 이상적입니다.

시놀로지에서의 위치

• DSM 패키지 센터에서 설치
• DSM 7.x 기준 기본/권장 컨테이너 도구
• NAS 성능에 따라 동시 실행 컨테이너 수 결정

#시놀로지 #Synology #Docker #ContainerManager

“뭘 설치해야 하지?”
“어디서부터 시작해야 하지?”

이 글은 그런 고민을 줄이기 위해 작성했다.
맥에서 Node.js 기반으로 Codex를 실행할 수 있는 최소한의 환경을
한 단계씩, 실패하지 않는 경로로 세팅해본다.

이 글에서 만드는 최종 상태

이 글을 끝까지 따라 하면 다음 상태가 된다.

• 터미널에서 Node.js 사용 가능
• Node 기반 프로젝트 생성 완료
• Codex를 실행할 수 있는 준비 상태
• 이후 AI 자동화 스크립트를 바로 추가할 수 있는 구조

최종 폴더 구조는 단순하다.

ai-workspace/
  ├─ package.json
  ├─ scripts/
   │   └─ test.js
  └─ README.md

`

1. 사전 준비: 맥 기본 환경 확인

macOS 확인

터미널을 열고 아래 명령어를 실행한다.

sw_vers

macOS 버전 정보가 나오면 정상이다.

이미 터미널을 사용하고 있다면, 이 단계는 확인만 하고 넘어가도 된다.

2. Homebrew 설치

맥에서 개발 환경을 세팅할 때
Homebrew는 사실상 기본 도구다.

아래 명령어를 그대로 복사해 실행한다.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

설치 중간에:

• 비밀번호 입력
• 엔터 입력 요청

이 나올 수 있다.
화면 안내 그대로 진행하면 된다.

설치 확인:

brew --version

버전이 출력되면 성공이다.

3. Node.js 설치 (권장 방식: nvm)

Node.js는 **버전 관리 도구(nvm)**를 사용하는 것이 가장 안전하다.

nvm 설치

brew install nvm

nvm 디렉토리 생성

mkdir ~/.nvm

환경 변수 설정

사용 중인 쉘이 zsh라면 ~/.zshrc에 아래 내용을 추가한다.

export NVM_DIR="$HOME/.nvm"
[ -s "$(brew --prefix nvm)/nvm.sh" ] && . "$(brew --prefix nvm)/nvm.sh"
[ -s "$(brew --prefix nvm)/etc/bash_completion.d/nvm" ] && . "$(brew --prefix nvm)/etc/bash_completion.d/nvm"

적용:

source ~/.zshrc

Node.js 설치

nvm install --lts 
nvm use --lts

설치 확인:

node -v
npm -v

버전 번호가 출력되면 정상이다.

4. 필수 CLI 도구 설치

AI 작업과 자동화를 하다 보면
반드시 쓰게 되는 기본 도구들이다.

brew install git jq ripgrep

• git: 코드 및 작업 이력 관리
• jq: JSON 데이터 가공
• ripgrep: 대용량 파일 검색

지금 당장 쓰지 않더라도,
Codex와 함께 작업하다 보면 자연스럽게 필요해진다.

5. Codex용 Node 프로젝트 생성

이제 실제 작업 공간을 만든다.

mkdir ai-workspace cd ai-workspace npm init -y

현재 구조를 확인한다.

ls

package.json

아직은 비어 있지만,
이 폴더가 앞으로 AI 업무가 쌓이는 공간이 된다.

6. Node 스크립트로 정상 동작 확인

scripts

폴더를 만들고 테스트 파일을 추가한다.

mkdir scripts nano scripts/test.js

아래 내용을 입력한다.

console.log("Node 기반 AI 업무환경 준비 완료");

저장 후 실행:

node scripts/test.js

출력 결과:

Node 기반 AI 업무환경 준비 완료

이 문장이 보이면,
Node 기반 AI 작업 환경은 제대로 준비된 상태다.

정리하며

이 글에서는
Codex를 사용하기 위한 Node 기반 최소 환경을 준비했다.

아직 AI는 등장하지 않았다.
하지만 중요한 토대는 이미 만들어졌다.

다음 글에서는 이 환경 위에서:

• Codex를 실제로 실행해보고
• Node 스크립트와 결합해
• 반복되는 업무를 자동화하는 예제를 만들어볼 예정이다.

조급할 필요는 없다.
환경이 준비되면, 그다음은 생각보다 빠르다.

새로산 아이폰16 프로는 버튼이 많아져서 그런지 카메라로 사진 영상을 찍는데, 뭔가 자꾸 불편했다. 의도치 않은 버튼들이 눌리면서 원치 않는 동작이 되고, 범퍼 케이스를 쓰면서 들고 다닐때의 그립감은 좋지만, 촬영할 때의 그립감은 불편함이 있었다.

요즘은 맥세이프 호환 악세사리가 많이 나오는데, 아무래도 자석이라서 큰 움직임에는 불안하지 않을까 해서 구매를 망설이고 있었다.
하지만 여행이나 일상 생활 중 걸어다니면서 촬영하는 상황에는 이만큼 편한 삼각대는 없겠다는 생각이 들어서 맥세이프 호환용 삼각대를 알아보게 되었다.

그래서, 구매하게 된 울란지 맥세이프 삼각대와 맥세이프 조명 사용 경험을 공유해 본다.

울란지 맥세이프 삼각대(MA38)

좋았던 점

심플한 디자인

기본 형태가 한손에 착 감기는 그립감이고 납작하게 수납이 용이했다.

놀라운 디테일

삼각대 형태일 때 다리를 받치는 고무패드가 바닥 면에 안정적으로 둘 수 있도록 설계되었다. 접고, 펼쳤을 때의 디테일이 살아 있었다.

군더더기 없는 완성도

모든 모서리는 부드럽게 처리되어 있었고 조작감이 좋았다. 유격도 없이 느슨함도 없이 단단하고 야무진 느낌을 주었다.

다양한 사용성

맥세이프 부분은 360도 회전이 가능해서 다양한 촬영 방식이 가능했다.

자석 기능으로 다양한 활용성이 있었다. 같이 산 조명의 활용도도 더 높아졌다.

거미 다리 처럼 특이한 구도도 가능했다.

가방에 걸 수 있는 고리 형태를 보고 누가 이렇게 머리가 좋은 것인지 놀라웠다.

아쉬웠던 점

높이 조절

높이는 두 가지 형태만 가능했다. 아무래도 길게 뽑아서 쓸 수 있는 형태는 아니기 때문에 세밀한 높이 조절은 불가능한 제품이다. 높이의 한계는 감안하고 구매해야 한다.

범퍼 케이스에서의 단점

맥세이프와 손잡이가 평평하게 설계된 구조이기 때문에 범퍼케이스처럼 튀어나온 부분에는 설치가 어렵다. 나는 가로 형태로만 사용이 가능했고, 자력이 강해서 억지로 붙여서 쓸 수 있기는 하지만 안전하게 쓰려면 세로 형태로 거치하는 것은 포기해야 한다. 범퍼 케이스일 때만의 단점이라서 일반적인 케이스일 때는 단점이 되지 못한다.

울란지 맥세이프 조명(LM-19)

작고 가볍다

같이 산 맥세이프 삼각대와 함께 사용이 가능하다

두가지 색상으로 변경이 가능하다

조명의 밝기를 조절할 수 있다

길이 조절이 된다

충전 상태를 확인할 수 있다

촬영 뿐 아니라 다양한 조명으로도 사용할 수 있었다

총평

삼각대와 조명 두 제품 모두 10점 만점에 9.5를 주고 싶다. 최근에 산 카메라, 스마트폰 등 수많은 악세사리 중 가장 만족도가 높았다. 범퍼 케이스를 포기해야 할지 고민 중이다.

낚시 구멍을 직접 만들어서 낚시를 해야 하는데, 시시각각 변하는 날씨 때문에 탁트인 공간에서 낚시를 하는 것은 안전하지 않다.
그래서 고민하다가 눈대피소에서 낚시를 할 수 있는 곳을 찾아보게 되었다.
주둔지 근처에서 낚시를 할만한 곳을 찾아봤는데,
그 중 한 곳만 선택한다면 이곳이 가장 최적의 포인트다 싶은 곳이 있어서 소개를 하고자 한다.

라이켄호에서 가까운 곳이다.

등대에서 가까운 곳도 있고, 공장에서 가까운 곳도 있다.
하지만 거리상 가까운 곳이지 거점으로 잡은 생선을 옮기는 동선 거리는 큰 차이가 없다.
황량한 해안 지역은 그렇게 큰 지역이 아니기 때문에 중심지역인 라이켄호 근처를 가장 많이 이용하고 있다.
게다가 라이켄호에는 망치가 필요한 곳이기 때문에 아예 낚시 포인트 근처에 망치를 두고 얼음 낚시 구멍을 만들 때 사용하고 있다.

참고로 나는 등대 근처 낚시 포인트는 아래와 같은 곳에 만들어 두긴 했다.

각자 취향에 맞는 곳을 찾아보는 것도 흥미로운 일이 될 것이다.

이런 식으로 낚시 구멍과 눈 대피소를 만들 수 있는 지역을 찾아보면 된다.

그럼, 안전하고 따뜻한 낚시활동으로 즐거운 더롱다크 생활이 되길 바라며 황량한 해안의 최적의 낚시 포인트 설명을 마친다.

내가 사용하는 키보드에서 그런 유용한 기능을 제공하고 있었다. 아마도 Fn 키를 가지고 있는 요즘 키보드들은 대부분 이 기능을 차용하고 있을 것으로 예상된다.

왼쪽에 있는 Win 키가 종종 눌려서 윈도우 메뉴가 뜨면서 게임의 흐름을 망치는 경험이 있었을 것이다.

우측에 있는 Fn + Win 키를 몇초간 누르고 있다가 떼면, 윈도우키가 안먹히는 것을 확인할 수 있다.
다시 한번 같은 방식으로 누르면 다시 윈도우키가 먹힌다.

이제 게임하다가 윈도키때문에 신경쓰지 않아도 되니 너무 좋다!