저는 버튼을 어디에 배치해야 할지를 고민하며 인생의 일주일을 허비했습니다. 다시는 그러고 싶지 않으며, 벤치마크 도구를 포팅(porting)하는 과정에서 그 이유를 깨달았습니다.

먼저 누구나 이야기하고 싶어 할 명백한 사실부터 인정하고 넘어가겠습니다. GUI는 여전히 입력 장치(input devices)입니다. 직접 조작(Direct manipulation), 메뉴, 팔레트, 키보드 단축키, 드래그 대상, 접근성 어포던스(accessibility affordances) — 이 모든 것은 입력이며, 대체 불가능합니다. 저는 UI 대신 채팅을 사용하자는 주장을 하는 것이 아닙니다. 커맨드 팔레트(Command palettes), 스크립팅(scripting) 및 매크로 시스템은 수십 년 동안 GUI 내부에서 개방형 명령어를 흡수해 왔으며, 잘 작동하고 있습니다.

제가 하고자 하는 논점은 더 좁으며, 특정한 실패에 관한 것입니다. 바로 유효한 작업 세트가 고정되어 있지 않은 시스템을 위해, 컨트롤(controls)을 먼저 설계하는 문제입니다.

인지하게 된 계기

저는 벤치마크 도구를 하나 만들었습니다. 이 도구는 **LLM/SLM 모델 × 기술(skills)**의 조합을 평가하며, 각 조합을 정확도(accuracy), 실행 시간(runtime), 턴 수(turn count), 총 비용(total cost)이라는 네 가지 항목으로 점수를 매깁니다.

또한 이 도구는 가변적인 요소들을 추적합니다. 새로운 모델이 끊임없이 등장합니다. 가격도 끊임없이 변합니다. 이 두 가지 모두 도구의 상태(state)의 일부입니다.

이 도구는 Claude Code 내부에서 실행되었습니다. 저는 이를 제대로 된 웹 도구로 포팅하기로 결정했고, 인터페이스를 설계하기 위해 앉았지만, 드롭다운(dropdowns) 두 개를 만드는 단계에서 막혀버렸습니다.

두 개의 드롭다운은 괜찮았습니다. 모델을 선택하고, 기술 세트를 선택하는 것 말입니다. 둘 다 유한하며, 사용자에게 보여져야(shown) 합니다. 모델이 존재하는지 모른다면 요청할 수 없기 때문입니다. 또한 둘 다 렌더링 비용이 저렴합니다.

문제는 그 외의 모든 것이었습니다.

실제 작업의 본질

이 도구의 본질은 단순히 "벤치마크를 실행하는 것"이 아닙니다. 그것은 _유지보수(maintenance)_입니다. 모델이나 기술이 추가되거나 업데이트될 때마다 작업이 발생합니다:

• 모델이 추가되었습니다. 어떤 기술들을 대상으로 다시 실행해야 할까요? 전부 다일까요, 아니면 이전 최고 기록과 차이가 적은 기술들일까요? 어떤 베이스라인(baseline)과 비교해야 할까요?
• 가격이 변했습니다. 과거의 비용을 다시 계산해야 할까요, 아니면 지금부터만 계산해야 할까요? 지난달의 비용 비교가 여전히 의미가 있을까요?
• 기술이 업데이트되었습니다. 저장된 결과 중 어떤 것이 이제 무효가 되었나요? 전체 매트릭스(matrix)를 다시 실행해야 할까요, 아니면 영향을 받은 열(column)만 실행해야 할까요?

저는 이것들을 위한 컨트롤(controls)을 설계하려고 계속 시도했지만, 매번 똑같은 사실을 발견했습니다. 각각이 조금씩 다른 작업(task)이라는 점입니다. 작업의 변형(variant)이 아니라, 무엇이 변했는지와 제가 이미 알고 있는 것이 무엇인지에 의해 형성된 '다른 작업'입니다.

이를 UI에 담으려면 그것들을 열거(enumerate)해야 합니다. 다음 모델 출시가 저에게 무엇을 원하게 만들지 알기도 전에, 모든 것을 사전에 나열해야 하죠. 그리고 새로운 축(axis)이 추가될 때마다 다른 모든 축과의 교차 조합(cross-combinations)이 더 많이 생성됩니다.

채팅에서는 그것이 하나의 문장으로 나타납니다. "gpt-5-mini가 들어왔으니, 모든 스킬(skill)에 대해 실행하고 haiku 옆에 배치해줘." 그러면 에이전트(agent)가 실제로 어떤 실행(run)이 필요한지 계산해냅니다. 그 요청을 위해 특별히 설계된 것은 아무것도 없었으며, 그럴 필요도 없었습니다.

이것이 전부입니다. "채팅이 더 낫다"는 뜻이 아닙니다. 단지 유효한 작업(operations)의 집합이 계속 변할 때, 컨트롤 서피스(control surface)는 계속 커져야만 하며, 그것은 언제나 모델 출시보다 한 단계 뒤처져 있을 수밖에 없다는 뜻입니다.

경계가 나뉜 지점

"유한함 대 무한함"의 문제가 아닙니다. 처음에는 제가 잘못 이해했습니다. 경계는 다음과 같습니다:

모델 목록은 UI여야 합니다. 목록이 짧아서가 아닙니다. 존재하는지조차 모르는 것은 요청할 수 없기 때문입니다. 열거(Enumeration) 그 자체가 핵심 가치입니다.

4가지 점수도 마찬가지입니다. 정확도(Accuracy), 실행 시간(runtime), 턴(turns), 비용(cost) — 당신은 그것들을 읽습니다. 가격이 변하면 업데이트됩니다. 클릭할 것은 아무것도 없으며, 클릭한다고 해서 도움이 되지도 않습니다.

예상치 못했던 부분

사용자가 GUI에서 막히게 되면, 종종 쓸모 있는 정보를 얻지 못합니다. 그들은 컨트롤을 찾지 못하고, 해당 작업이 불가능하다고 결론 내린 뒤 떠나버립니다. 사용자가 이탈했다는 사실은 알 수 있겠지만, 그들이 무엇을 하려고 했는지는 거의 알 수 없습니다.

사용자가 채팅에서 막히게 되면, 그들은 자신이 하려던 것을 타이핑합니다. 이제 당신은 사용자의 언어로, 당신의 제품이 지원하지 않는 작업을 설명하는 문장을 갖게 됩니다.

여기서 주의하고 싶습니다. 분명한 반론이 존재하며, 그 반론은 옳기 때문입니다: 채팅 사용자 또한 조용히 떠납니다. 실제로 아주 많습니다. 그리고 GUI에는 텔레메트리 (telemetry), 퍼널 (funnels), 세션 녹화 (session recordings)가 있습니다. 이것은 범주적인 차이가 아니며, 만약 제가 그렇다고 말한다면 과장하는 것이 될 것입니다.

제가 생각하기에 차이점은 _복구 (recovery)_에 있습니다. 실패한 GUI 상호작용은 대개 의도가 아닌 이벤트를 남깁니다. 실패한 채팅 상호작용은 문장을 남기며, 이는 사용자(당신, 지원 담당자, 또는 에이전트 자체)가 사용자가 아직 머물고 있는 동안 답변해야 할 무언가를 갖게 된다는 것을 의미합니다. 항상 그런 것은 아닙니다. 하지만 이는 당신이 해석해야 하는 신호와 스스로를 드러내는 신호 사이의 차이입니다.

매주 작업 목록이 바뀌는 도구에게 있어, 이 점은 제가 예상했던 것보다 더 중요했습니다. 지원되지 않는 요청들이 바로 로드맵 (roadmap)입니다.

두 번째 데이터 포인트, 솔직하게 라벨링된 것

저는 또한 여러 코딩 에이전트 (coding agents)를 동시에 감독하기 위해 브라우저 터미널 그리드 (terminal grid)를 유지 관리하고 있습니다. 다른 제품이고, 다른 문제이며, 다른 이유로 만들어졌습니다.

한 셀의 헤더를 세어보면: 대략 **11개의 버튼과 9개의 상태 칩 (status chips)**이 있습니다. 칩들은 디렉토리 (directory), git 브랜치 (git branch) 및 변경 횟수, 모델 (model) 및 컨텍스트 (context) 백분율, 토큰 수 (token counts), 해당 셀이 어떤 PR 또는 이슈에 있는지, diff 배지 (diff badge), 사용량, 그리고 에이전트가 현재 수행 중인 작업에 대한 한 줄 요약입니다. 해당 구성에서 이 중 어느 것도 클릭할 수 없습니다. 그것들은 읽기 전용입니다.

그리고 살아남은 모든 버튼은 동일한 종류의 일을 수행합니다: 확장, 닫기, 파일 표시, 캔버스 (canvas) 열기, 타임라인 (timeline) 열기. 그것들은 당신이 바라보는 위치를 바꿉니다. 그중 어느 것도 에이전트에게 무언가를 시키지는 않습니다 — 그것은 타이핑으로 이루어집니다.

동일한 경계가 다른 제품에서도 나타났는데, 이는 제가 벤치마크 도구를 만들 때 생각하고 있던 제품이 아니었습니다.

하지만 이것을 수렴 (convergence)이라고 부를 수는 없습니다. 동일한 저자, 동일한 시기, 동일한 도구, 동일한 가정. 이것은 두 번 나타난 개인적인 디자인 패턴이지, 독립적인 검증이 아닙니다. 이 경계가 특정 벤치마크 워크플로 (workflow)에만 국한된 것이 아니라는 증거로만 받아들이십시오. 그 이상은 아닙니다.

이것이 사실이 아니게 되는 지점

정확히 말하자면, 결코 실패하지 않는다는 주장은 별다른 의미가 없기 때문입니다:

• 정밀도와 공간적 피드백 (Precision and spatial feedback). 당신은 크롭(crop), 곡선(curve), 또는 필렛(fillet)을 말로 설명하지 않습니다. 사진 편집기나 CAD 도구들이 이를 프롬프트(prompt)로 옮기지는 않을 것이며, 옮겨서도 안 됩니다.
• 반복과 근육 기억 (Repetition and muscle memory). 하루에 50번 수행하는 동작은 단 한 번의 키 입력이어야 합니다. 그것을 타이핑하는 것은 매번 성능의 저하(downgrade)를 의미합니다.
• 발견 (Discovery). 새로운 사용자는 무엇을 요청해야 할지 모릅니다. 이것이 컨트롤 서피스(control surface)를 유지해야 하는 가장 강력한 논거이며, 모델 목록이 여전히 목록 형태로 남아 있는 이유입니다.
• 안전성 (Safety). "실패한 실행 건들을 삭제해줘"라는 명령은 무언가를 가리키는 방식이어야지, 관대하게 해석될 여지가 있는 문장이어서는 안 됩니다.

스프레드시트, IDE, 그리고 디자인 도구들은 하이브리드(hybrid) 상태로 남습니다. 그래야만 합니다. 채팅은 안정적인 기본 요소(primitives) 위에 구축된 오케스트레이션 레이어(orchestration layer)이지, 그것들의 대체재가 아닙니다.

최대한 좁게 정의한 논지

시각적 인터페이스는 **안정적인 객체(objects), 상태(state), 제약 조건(constraints), 그리고 고빈도 동작(high-frequency actions)**을 드러내는 데 탁월합니다. 하지만 유효한 작업이 수없이 많고, 구성적(compositional)이며, 상태에 의존적이고, 지속적으로 변할 때는 비용이 많이 들고 취약(brittle)해집니다.

그러한 시스템에서는: UI가 선택하고 검사해야 할 것들을 열거하게 하고, 대화형 레이어(conversational layer)가 매주 새로운 컨트롤을 만들어야 했을 법한 요청들을 흡수하게 하십시오.

이득은 채팅이 인터페이스를 대체하는 것이 아닙니다. 새로운 조합이 나올 때마다 버튼을 배포하지 않고도, 의도의 변경이 **관찰 가능하고(observable), 복구 가능하며(recoverable), 확장 가능(extensible)**해진다는 점에 있습니다.

따라서: 동사(verbs)가 고정되지 않을 제품의 부분들에 대해서는 버튼 배치에 대해 고뇌하는 것을 멈추십시오. 그 외의 모든 곳에서 버튼은 여전히 정답입니다. 지금까지 그래왔던 것처럼 말입니다.

만약 당신이 밑바닥에서 계속 변하는 워크플로(workflow)를 위해 컨트롤 서피스를 배포했다면, 그 결과가 어땠는지 듣고 싶습니다. 솔직한 제 입장은, 저 자신의 두 제품에서 그 경계를 발견했으며 이것이 얼마나 일반화될 수 있는지는 아직 모른다는 것입니다.