며칠 전, Vaibhav Sisinty가 X(구 트위터)에 올린 게시물이 제 스크롤을 멈추게 했습니다. 누군가가 Claude 모델 사이를 전환하기 위해 실제 물리적인 스틱 시프트(stick shift)를 연결했다는 내용이었습니다. 설정 메뉴도 아니고, 드롭다운 메뉴도 아닙니다. 자동차에 있는 것과 같은 기어 변속기가 책상 위에 놓여 있는 것입니다.

한 기어에는 Haiku(Haiku)가, 다른 기어에는 일상적인 주행을 위한 Sonnet이 설정되어 있습니다. 문제가 정말 깊이 있는 분석을 필요로 할 때는 Opus를 사용합니다. 스틱을 위치에 맞춰 쾅 밀어 넣으면, 워크플로우 하단의 모델이 변경됩니다.

이것을 단순한 신기한 물건 이상으로 만드는 디테일은, 그가 Claude를 사용하여 이 변속기를 직접 만들었다는 점입니다. 구체적으로는 자신의 Claude 사용 속도를 높이기 위해서였죠. 이는 모델을 사용하여 모델 사용 시의 마찰(friction)을 제거하는 아주 멋진 루프(loop)입니다.

이것이 들리는 것보다 더 똑똑한 아이디어인 이유

겉보기에는 눈길을 끌기 위한 장치(gimmick)처럼 보일 수 있습니다. 하지만 그 이면에는 모든 헤비 AI 사용자가 직면하는 실제 문제, 즉 모델 선택은 결정 비용(decision tax)이다라는 문제를 해결하고 있습니다.

채팅을 열 때마다 "이게 Sonnet 작업인가, 아니면 Opus 작업인가?"라고 생각해야 할 때마다, 당신은 실제 문제 대신 메타 작업(meta-work)에 주의력을 소모하고 있는 것입니다. 이는 아주 작은 비용이지만, 하루에도 수십 번씩 지불하게 되는 비용이며, 그 어떤 생산성 대시보드에도 나타나지 않습니다. 물리적 제어 장치는 그 결정을 단 한 번의 운동 동작으로 압축합니다. 자동차 운전자가 기어비에 대해 의식적으로 추론하지 않고, 그저 도로를 느끼며 변속하는 것과 같은 방식입니다.

여기서 얻을 수 있는 실제 통찰은 이것입니다: 지속적으로 내리는 결정에 대한 최고의 인터페이스는 의식적인 사고를 가장 적게 요구하는 인터페이스이다. 메뉴는 당신이 보고, 읽고, 결정하고, 클릭하게 만듭니다. 물리적 레버는 당신이 느끼고 움직이게 합니다. 한 세션 동안 50번씩 수행하는 작업이라면, 그 차이는 빠르게 누적됩니다.

이런 장치가 어떻게 만들어지는지에 대한 타당한 고찰

여기 정확한 배선도를 공개한 사람은 없지만, 취미용 하드웨어와 API 기반 모델 전환을 다뤄본 적이 있다면 그 구조는 거의 저절로 그려집니다. 이런 제작 과정에는 대략 다음과 같은 것들이 포함됩니다:

1. 물리적 입력 계층 (The physical input layer)
재용도(repurposed)된 자동차용 또는 심 레이싱(sim-racing)용 기어 변속기는 일련의 위치를 가지고 있으며, 각 위치는 서로 다른 스위치를 닫거나 서로 다른 가변 저항기(potentiometer) 값을 생성합니다. 마이크로컨트롤러(microcontroller) — Arduino 또는 Raspberry Pi Pico가 명확한 선택지입니다 — 가 스틱이 어떤 기어에 있는지 읽어 들입니다. 모델 티어(tier)당 하나씩, 3~4개의 기어면 충분합니다.

2. 소프트웨어로의 신호 전달 (Signal to software)
마이크로컨트롤러는 USB 시리얼(USB serial)을 통해(무선 방식을 원한다면 Bluetooth를 통해) 호스트 머신에서 실행되는 작은 스크립트로 기어 위치를 보고합니다. 이 스크립트의 유일한 작업은 기어 변경 이벤트를 감시하고 이를 모델 선택으로 변환하는 것입니다. 예를 들어, 기어 1 → Sonnet, 기어 2 → Opus, 기어 3 → Fable와 같은 식의 매핑(mapping)입니다.

3. 스위치가 실제로 적용되는 지점 (Where the switch actually takes effect)
이 부분은 통합(integration)이 얼마나 "실제"처럼 느껴지는지를 결정합니다. 몇 가지 합리적인 접근 방식이 있습니다:

• API 측면 (API-side): 스크립트가 다음 요청(예: Claude API를 통해) 시 전달될 모델 문자열(model string)을 업데이트합니다. 따라서 사용 중인 도구나 래퍼(wrapper)가 다음 호출 시 새로운 모델을 채택하게 됩니다.
• 클라이언트 측 자동화 (Client-side automation): 스크립트가 채팅 인터페이스의 모델 선택기에서 사람이 수행할 클릭을 시뮬레이션하여, 하드웨어 속도로 메뉴 탐색을 대신 수행합니다.

어떤 방식이든 멘탈 모델(mental model)은 동일합니다. 기어 변속기가 Claude와 직접 통신하는 것이 아니라, 작은 글루 코드(glue code)와 통신하며, 그 글루 코드가 실제로 모델 전환을 일으키는 것입니다.

4. 눈을 감고 조종하는 느낌을 방지하기 위한 피드백 (Feedback so it doesn't feel like flying blind)
잘 만들어진 빌드에는 확인 계층(confirmation layer)이 추가됩니다. 기어마다 색상이 변하는 LED나 짧은 상태 표시 등을 통해, 화면을 확인하지 않고도 현재 어떤 모델이 활성화되어 있는지 항상 알 수 있게 합니다. 이는 생각보다 훨씬 중요합니다. 피드백이 없다면 물리적 제어 장치는 단지 무엇을 클릭했는지 불확실하게 만드는 더 화려한 방법일 뿐입니다.

깊이 생각해 볼 부분 (The part worth sitting with)

이 프로젝트에서 제가 좋아하는 점은 납땜 기술이 아닙니다. 그것이 장려하는 근본적인 행동 양식, 즉 탭에 이미 열려 있는 것이 무엇이든 기본값으로 사용하는 대신, 어떤 모델을 사용할지 의도적으로 (deliberate) 결정하게 만든다는 점입니다. 우리 중 많은 이들은 눈앞의 작업이 실제로 깊은 추론 (deep reasoning)을 필요로 하는지, 아니면 단순히 빠르게 처리해야 하는지에 관계없이 마지막으로 로드된 모델을 그냥 사용하곤 합니다.

기어 변속기 (gear shifter)는 매 전환 시마다 아주 짧은 의도의 순간을 강제합니다. 이는 하드웨어가 없더라도 훔쳐올 만한 가치가 있는 UX 패턴입니다. 키보드 단축키 (keyboard shortcut), CLI 별칭 (alias), 빠른 전환 패널 (quick-switch panel) 등, "이미 열려 있는 것을 그냥 사용하기"보다 "이 작업에 맞는 올바른 도구를 선택하기"가 더 적은 노력을 들게 만드는 것이라면 무엇이든 가능합니다.

그리고 이는 잊기 쉬운 무언가를 상기시켜 주는 좋은 사례입니다. 때때로 가장 흥미로운 AI 프로젝트는 모델 그 자체에 관한 것이 아닙니다. 그것은 모델로 향하는 더 나은 진입로 (on-ramp)를 설계하는 것에 관한 것입니다.