채팅은 인터페이스가 아니라 입력 방식이다

채팅창에서 제 주소를 물어본다면, 당신은 방금 제 삶을 더 힘들게 만든 것입니다. 저는 폼 (Form)에 3초 만에 주소를 입력할 수 있습니다. 우편번호를 검증하고, 도시를 통해 제 주를 파악하며, 숫자를 잘못 입력했을 때 즉시 알려주는 폼 말입니다. 채팅창에서는 모델 (Model)이 제 답변을 어떻게 파싱 (Parse)할지에 따라 제 운명이 결정되며, 제가 프롬프트 (Prompt)가 예상하지 못한 방식으로 문장을 구성할 경우 아주 가끔 미묘하게 틀린 답변이 돌아오기도 합니다. 폼은 바로 저기에 있었는데 말이죠.

이것이 제가 채팅 우선 (Chat-first) 제품들의 물결을 보며 계속해서 되돌아오게 되는 지점입니다. 대화는 하나의 실제적인 입력 양식 (Input modality)입니다. 하지만 그것이 적절한 기본값인 경우는 드뭅니다. 작업에 적합한 인터페이스 (Interface)를 선택하는 것이 디자인 작업이며, 모델 (Model) 비용이 저렴하다는 이유로 모든 폼 (Form), 그리드 (Grid), 캔버스 (Canvas)를 프롬프트 (Prompt) 박스로 대체하는 것은 그 작업을 수행하는 것과는 정반대의 행동입니다.

채팅은 하나의 입력 방식일 뿐, 인터페이스가 아니다

대부분의 채팅 우선 제품들이 범하는 범주 오류 (Category error)은 채팅을 하나의 입력 방식이 아닌 '유일한' 인터페이스로 취급하는 것입니다. 그 밑단의 모델 (Model)은 처리 계층 (Processing layer)입니다. 사용자가 접하는 표면 (Surface)은 별개의 결정 사항이며

대화로부터 진정으로 이득을 얻는 입력 (Input) 범주가 있습니다. 답변의 구조를 사전에 알 수 없거나, 후속 질문이 이전 답변에 의존하거나, 사용자의 어휘가 애플리케이션의 어휘와 일치하지 않아 그 사이에서 무언가 번역되어야 하는 경우입니다. 만약 해당 작업이 설문지보다 인터뷰 (Interview)를 통해 더 잘 처리될 수 있는 종류라면, 채팅 (Chat)을 탐색해 볼 가치가 있습니다. 핵심 키워드는 _인터뷰 (Interview)_입니다. 여기에는 한계가 있으며, 그 한계는 매우 빠르게 찾아옵니다.

제가 참여하고 있는 프로젝트 중 건설 견적 (Construction takeoff estimating)이 좋은 예시입니다. 도면은 측정 가능한 구조화된 데이터 (Square footage, 방 개수, 설비 위치 등)를 제공하지만, 마감 수준 (Finish level)에 대해서는 아무것도 말해주지 않습니다. 일반적인 빌더 등급 (Builder-grade) 주방 패키지는 약 1만 달러일 수 있습니다. Viking 레인지와 Sub-Zero 냉장고가 포함된 프리미엄 패키지는 15만 달러에 달할 수 있습니다. 설계도에는 소유자가 어느 쪽을 원하는지 나와 있지 않으며, 단일 양식 필드 (Form field)로는 그 차이를 깔끔하게 포착할 수 없습니다.

채팅이 적합한 지점이 바로 여기입니다. 시스템은 계약자에게 소유자와 어떤 대화를 나누었는지 묻고, "좋은 걸 원하지만 너무 과하지는 않게"라거나 "그녀가 계속 이탈리아 타일을 보여줘요"와 같은 내용을 포착하여, 견적사가 적용할 수 있는 구조화된 데이터로 번역합니다. 계약자의 멘탈 모델 (Mental model)은 대화형입니다. 그들에게 마감 수준 드롭다운 (Dropdown) 메뉴를 강요하는 것은 정보를 버리는 행위입니다. 또한 채팅은 모호함 (Ambiguity)이 유지되어야 할 때 이를 허용합니다. "아직 결정 중이지만, 3만 5천 달러에서 4만 5천 달러 사이가 될 것 같아요"라는 말은 완벽하게 유효한 답변이며, 양식 필드는 이러한 변동성을 처리하지 못해 막히거나, 그 자체로 매우 복잡한 인터페이스가 되어버립니다.

채팅이 그 자리에 위치할 수 있는 이유는 입력값이 소스 단계에서 진정으로 비구조화 (Unstructured)되어 있기 때문입니다. 제가 보는 대부분의 채팅 인터페이스는 그 문제를 해결하고 있지 않습니다. 그들은 "모델을 출시했으니 이제 모든 것이 모델처럼 보여야 한다"라는 훨씬 더 작은 문제를 해결하고 있을 뿐입니다.

직접 조작 (Direct Manipulation)이 승리하는 곳

그리고 채팅 우선 (chat-first) 프레임워크가 조용히 무시하고 있는 더 넓은 영역이 있습니다. 바로 그래픽 인터페이스 (graphical interfaces)가 그 어떤 문장보다 더 잘 수행하는 작업들입니다. 왜냐하면 인터페이스 자체가 곧 정밀도 (precision)이기 때문입니다.

이미지의 간격을 설명하는 방식으로 조정하려고 시도해 보십시오. "왼쪽으로 조금 — 아니, 더 적게 — 좋아, 이제 아래로." Figma나 Illustrator에서 10초면 끝날 직접 조작 (direct manipulation)이 짜증 나는 '전화기 게임 (game of telephone)'으로 변질됩니다. 산문 (prose)만으로 프로덕션 디자인 (production design)을 수행하는 경로(화면을 설명하고, 결과로 무엇이 나오든 수용하는 방식)는 시작하기도 전에 실패합니다. 인간의 언어는 픽셀 간격 (pixel spacing)을 지정할 수 없으며, 실제로 작동하는 도구들은 애초에 언어에 그런 것을 요구하지 않기 때문입니다. 이는 CAD, 스프레드시트 (spreadsheets), 페이지 레이아웃 (page layout), 비즈니스 분석 (business analytics) 분야에도 동일하게 적용됩니다. 즉, 가치가 사용자의 손과 결과물 사이의 정밀하고 공간적이며 직접적인 관계에 존재하는 영역들입니다. 산문은 그 정도의 대역폭 (bandwidth)을 감당할 수 없습니다.

양식 (forms)의 사례는 이와 동일한 스펙트럼에서 그저 좁고 다루기 쉬운 끝부분일 뿐입니다. 주소 입력, 날짜 선택, 숫자 범위, 엄격한 검증 (validation)이 필요한 모든 것, 사용자가 수백 번 입력해 온 모든 것, 답변이 짧은 드롭다운 (dropdown)에 깔끔하게 나열되는 모든 것들이 여기에 해당합니다. 이것들은 시스템이 수집해야 하는, 때로는 항목 간의 순서나 의존성 (dependency)을 가진 이산적인 형태 (discrete shape)의 기지 데이터 (known data)입니다. 양식은 하나의 계약입니다. 양식은 무엇이 필요한지 정확히 명시하고, 로컬에서 검증하며, 즉각적으로 오류를 드러내고, 몇 초 안에 완료됩니다. 동일한 작업을 채팅으로 수행하면, 모호함이 사용자에게 전가되는 느린 추측 게임이 됩니다. 사용자는 배송 확인 메일이 하루 뒤에 도착할 때까지 모델이 주소를 잘못 읽었다는 사실을 알아차리지 못할 수도 있습니다.

대량 작업 (Bulk) 단계로 가면 차이는 더욱 극명해집니다. 채팅으로 전화번호 하나를 입력하는 것? 그럴 수도 있습니다. 모든 연락처 정보가 포함된 고객 리스트를 입력하는 것? 거의 불가능합니다. 백 개의 행을 말로 설명하는 것보다 CSV 파일을 업로드하거나 그리드 (grid)에 입력하는 것이 더 빠릅니다. 구조가 풍부해질수록, 산문의 성능은 더 나빠집니다.

이 중 어느 것도 모델에 대한 반론이 아닙니다. 모델은 양식 (form), 그리드 (grid), 캔버스 (canvas) 뒤에 자리 잡으며, 자동 완성 (autocompleting), 외부 소스에 대한 검증 (validating), 수정 제안 (suggesting corrections) 등을 수행할 수 있습니다. 처리 계층 (processing layer)이 LLM이라고 해서 반드시 인터페이스 표면 (interaction surface)이 채팅창일 필요는 없습니다. Andrej Karpathy가 그의 Software 3.0 프레임워크에서 언급했듯이, 미래의 스택은 클래식 코드 (classical code), 머신러닝 (machine learning), 그리고 LLM이 함께 작동하는 형태입니다. 진정한 비즈니스 로직 (business logic)을 위해서는 그 목록에 규칙 엔진 (rules engine)을 추가하고 싶습니다. 인터페이스는 밑단에서 무엇이 작업을 수행하느냐와는 독립적인 디자인 선택 (design choice)입니다.

적절한 방식의 수

이것은 부분적으로 새로운 옷을 입은 오래된 논쟁입니다. 즉, 애플리케이션이 한 가지 일을 수행하기 위해 얼마나 많은 방식을 제공해야 하는가에 대한 문제입니다. 양극단 모두 틀렸습니다.

Perl와 COBOL은 동일한 한 줄을 작성하는 15가지 방법을 제공하는 것으로 유명하며, 그 결과는 종종 아무도 읽을 수 없는 코드가 됩니다. 독자는 작성자가 무엇을 했는지뿐만 아니라 그가 어떤 방언 (dialect)을 사용하고 있었는지까지 역공학 (reverse-engineer)해야 합니다. 운영 체제에 대한 가장 유연한 인터페이스는 아마도 Unix 셸 (shell)일 것입니다. 거의 모든 것을 할 수 있지만

애플리케이션을 위한 균형은 동일한 작업을 위해 의도적으로 선택된 두세 가지의 양식 (modalities)입니다. 구조화된 케이스를 위한 양식 (form), 비구조화된 케이스를 위한 채팅 폴백 (chat fallback), 그리고 반복적인 작업을 위한 파워 유저용 단축키(shortcut) 정도가 적당합니다. 세 가지 방식은 사용자가 작업하는 방식의 유의미한 변주를 포괄하면서도, Perl-land(지나치게 복잡하고 난해한 환경)로 빠지지 않게 해줍니다. 반면, 디자이너가 특정 양식에 매료되어 단 하나만을 선택한다면, 사용자 기반의 절반을 조용히 더 나쁜 경험으로 밀어넣게 됩니다.

LLM이 간극을 메운다

그렇다면 채팅이 인터페이스가 아니라면, 모델의 실제 용도는 무엇일까요? 모델의 진정한 힘은 모호함을 메우는 데 있습니다. 워크플로우 상에서 입력이 지저분하거나, 형식이 일관되지 않거나, 혹은 답변이 아직 반쯤 형성된 상태인 지점들을 덮어줌으로써, 사용자가 입력값이 수용되지 않는 필드에서 멈춰 서는 대신 목표를 향해 계속 나아갈 수 있도록 돕는 것입니다.

건설 현장의 사례로 돌아가 보겠습니다. 하도급 업체들로부터 돌아오는 입찰서들은 매우 일관성 없는 형식으로 작성됩니다. 각 입찰서에서 총액을 추출하는 것은 정규 표현식 (regex)이나 파서 (parser)로 처리할 수 있는 사소한 일입니다. 하지만 그 가격에 무엇이 포함되고 제외되었는지를 파악하려면 실제적인 해석이 필요하며, 이것이 바로 LLM의 역할입니다. 지저분한 문서를 읽고, 일반적인 머신러닝 (machine learning)이 추출할 수 있는 것, 규칙 엔진 (rules engine)이 결정할 수 있는 것, 그리고 진정으로 모델의 해석이 필요한 것을 분류(triage)하는 것입니다. 출력물은 채팅 기록이 아닙니다. 그것은 입찰서의 구조화된 모델이며, 원본이 아무리 거칠더라도 매번 동일한 필드를 가진 일관된 형태로 일반적인 인터페이스를 통해 다시 전달됩니다.

이러한 일관성이야말로 LLM 기반 UX의 실제 보상이며, 이는 표면적인 인터페이스로서의 채팅과는 거의 관련이 없습니다. CAD 환경을 상상해 보십시오. 나는 3D 마우스를 사용하고, 단축키를 활용하며, 부품의 기하학적 구조(geometry) 속에 깊이 몰입해 있습니다. 채팅은 내가 모델링을 하는 곳이 아닙니다. 그렇게 한다면 말도 안 되는 일일 것입니다. 하지만 "이제 대략적인 형태가 잡혔으니, 이것에 대해 토크 분석 (torque analysis)을 실행하고 내가 계속 작업하는 동안 백그라운드에서 돌려줘"라는 명령은 대화형 명령이 정확히 제 자리를 찾는 순간입니다. 대화형 명령은 정밀한 인터페이스를 대체하는 것이 아니라, 그 옆에서 함께 작동합니다. 모델은 간극을 메우는 것이지, 운전대를 뺏는 것이 아닙니다.

기본 설정(Default)은 디자인의 적이다

만약 당신이 지금 제품을 설계하고 있고 기본 화면이 채팅창이라면, 다음과 같은 테스트를 해보십시오. 사용자가 수행하는 가장 흔한 작업 5가지를 뽑아보세요. 각 작업에 대해, 문장을 입력하는 것보다 양식(Form), 그리드(Grid), 드롭다운(Dropdown), 버튼(Button) 또는 캔버스(Canvas)를 사용하는 것이 더 빠르고, 모호함이 적으며, 더 나은 검증(Validation)을 제공할 수 있는지 자문해 보십시오.

만약 모든 항목에서 그 대답이 '예'라면, 당신은 챗봇의 탈을 쓴 '양식과 그리드 기반 애플리케이션'을 만든 것이며, 그 탈이 사용자에게 해를 끼치고 있는 것입니다. 진짜 인터페이스를 출시하십시오. 채팅은 입력 내용이 구조화된 표면(Structured surface)에 진정으로 맞지 않는 일부 사례를 위해서만 남겨두고, 채팅을 정문(Front door)으로 만들기보다는 "또는 그냥 설명하기"라고 적힌 버튼 뒤에 배치하십시오.

만약 일부 항목에서 대답이 '아니오'라면(예: 입력의 형태를 예측할 수 없거나, 후속 작업이 답변에 따라 달라지거나, 사용자의 어휘가 필드(Fields)로 변환되는 과정에서 유실될 수 있는 경우), 그렇다면 채팅은 해당 작업들에 대해 올바른 기본 입력 방식입니다. 이를 잘 구축하되, 이를 원하는 사용자를 위해 옆에 구조화된 단축키를 배치하십시오. 그리고 채팅을 애플리케이션의 정체성이 아니라, 애플리케이션이 제공하는 하나의 모드(Mode)로 취급하십시오.

모델은 도구입니다. 채팅은 모델이 구동할 수 있는 인터페이스 중 하나이며, 모호함이 존재하는 곳에서는 매우 가치 있지만 그 외의 모든 곳에서는 잊혀질 것입니다. 양식(Forms), 그리드(Grids), 슬라이더(Sliders) 및 직접 조작(Direct manipulation)은 사람들이 실제로 소프트웨어로 하는 대부분의 작업에 대해 여전히 정답으로 남아 있습니다. 이 모든 것을 한꺼번에 머릿속에 담아두고 의도적으로 선택할 수 있는 디자이너가, 단순히 유행하는 방식(Modality)을 쫓는 디자이너보다 더 뛰어난 제품을 만들어낼 것입니다.

기본 설정(Default)은 디자인의 적입니다.