AI가 화면을 하나의 채팅창으로 접으면, Jakob’s Law는 어디에 적용될까

Jakob’s Law는 오래된 말입니다. 사용자는 대부분의 시간을 다른 사이트에서 보내기 때문에, 당신의 사이트도 사용자가 이미 아는 방식으로 작동해야 한다는 법칙입니다. 로고는 대체로 왼쪽 위에 있고, 장바구니는 오른쪽 위에 있으며, 드롭다운은 드롭다운처럼 작동해야 합니다. 독창성보다 익숙함이 사용성을 만든다는 이야기입니다.

UX Collective의 Patrick Neeman은 이 법칙을 AI 어시스턴트 시대에 다시 적용합니다. 핵심 질문은 이렇습니다. 사용자의 시간이 더 이상 여러 웹사이트와 앱에 흩어져 있지 않고, Claude, ChatGPT, Copilot, Gemini 같은 하나의 대화형 입구로 모인다면, 사용자가 기대하는 “익숙한 방식”은 어디에서 생길까.

사용자가 머무는 곳이 웹사이트에서 어시스턴트로 이동한다

과거의 소프트웨어는 표면을 계속 늘렸습니다. 일정은 일정 앱, 문서는 문서 앱, 계약서는 계약 관리 서비스, 이슈는 이슈 트래커, 메일은 메일 앱에서 처리했습니다. 사용자는 여러 목적지를 오가며 각 인터페이스의 규칙을 배웠습니다. Jakob’s Law는 이 많은 목적지가 서로 너무 다르게 작동하지 않도록 하는 기준이었습니다.

이제 많은 작업은 어시스턴트에서 시작합니다. 사용자는 앱을 열기보다 “계약서에서 자동 갱신 조항을 찾아줘”, “이 문서들을 읽고 회의 요약을 만들어줘”, “지난주 이슈를 기준으로 발표 자료 초안을 만들어줘”라고 말합니다. 어시스턴트가 여러 소스와 도구를 오가며 결과를 가져옵니다.

원문은 이 변화를 “표면의 수가 줄어든다”고 표현합니다. 실제로 소프트웨어가 줄어드는 것은 아닙니다. 오히려 더 많아집니다. 줄어드는 것은 사용자가 직접 만지는 표면의 수입니다. 사용자의 앞에는 하나의 채팅창이 있고, 뒤에서는 여러 시스템이 연결됩니다.

이제 Jakob’s Law는 어시스턴트를 가리킨다

사용자가 시간을 보내는 곳이 기대를 만듭니다. 웹사이트를 많이 쓰던 시대에는 웹의 공통 패턴이 기대를 만들었습니다. 이제 사용자가 어시스턴트에서 많은 작업을 한다면, 기대의 기준은 어시스턴트가 됩니다.

사용자는 자연어로 요청하고, 답을 받고, 다시 수정하고, 이전 맥락을 기억해주기를 기대합니다. 새로운 AI 기능을 만났을 때도 비슷하게 작동하길 바랍니다. 입력창은 더 이상 수많은 패턴 중 하나가 아닙니다. 원문 표현처럼 ‘asking box’, 즉 요청을 던지는 기본 입구가 되고 있습니다.

이 변화는 디자이너에게 꽤 불편합니다. 우리가 세심하게 설계한 내비게이션, 대시보드, 브랜드 경험을 사용자가 보지 않을 수 있기 때문입니다. 제품은 일을 하지만, 표면은 어시스턴트가 소유합니다. 사용자는 우리 제품을 열지 않고도 결과를 받을 수 있습니다.

보이지 않는 제품은 어떻게 발견될까

사용자가 직접 제품을 둘러보지 않는다면, 기능 발견은 클릭에서 설명으로 이동합니다. 어시스턴트가 “이 제품은 이런 작업을 할 수 있다”고 이해하고, 적절한 순간에 불러낼 수 있어야 합니다. 원문은 이 지점에서 정보 구조의 의미가 바뀐다고 말합니다. 정보 구조는 더 이상 사이트맵만의 문제가 아닙니다. 모델이 우리 제품의 기능, 데이터, 행동을 이해하고 정확히 호출할 수 있는가의 문제가 됩니다.

그래서 명명과 구조가 중요해집니다. 기능 이름은 데이터베이스 내부 용어가 아니라, 사용자가 실제로 말할 법한 언어와 가까워야 합니다. 액션은 어시스턴트가 언제 어떤 목적으로 호출해야 하는지 설명되어야 합니다. 프로토콜과 커넥터를 통해 접근 가능해야 합니다. 연결되어 있지 않고 설명되어 있지 않은 기능은, 어시스턴트 시대에는 사실상 발견되지 않는 기능이 될 수 있습니다.

이 논의는 최근 AI 검색/에이전트 최적화 논의와도 닿아 있습니다. 사람이 읽는 랜딩 페이지를 잘 만드는 것만으로는 부족합니다. 제품과 조직의 지식이 기계가 읽고 사용할 수 있는 구조로 정리되어야 합니다. AI에게 보이지 않는 기능은 사용자에게도 점점 덜 보일 수 있습니다.

표준 컴포넌트는 사람뿐 아니라 에이전트를 위한 것이다

원문에서 좋은 대목은 표준 UI 패턴의 의미를 다시 해석하는 부분입니다. 과거에 표준 컴포넌트는 사용자를 위한 배려였습니다. 익숙한 입력창, 버튼, 날짜 선택기, 폼 구조는 사용자가 덜 헤매게 만들었습니다.

하지만 에이전트가 화면을 조작하는 시대에는 표준 패턴이 모델을 위한 조건도 됩니다. 에이전트가 API나 커넥터로 작업하지 못하면, 결국 사람이 보는 화면을 보고 클릭하고 입력해야 합니다. 이때 지나치게 독특한 인터페이스는 사람에게도 어렵지만, 모델에게도 예측하기 어렵습니다. 익숙한 라벨과 표준 컴포넌트는 에이전트가 덜 추측하게 만드는 장치가 됩니다.

원문은 A2UI와 MCP Apps 같은 흐름도 언급합니다. 대화 안에서 폼, 차트, 예약 플로우 같은 실제 인터페이스를 렌더링하는 방식입니다. 텍스트만 오가는 채팅창은 복잡한 작업에 충분하지 않습니다. 날짜를 고르고, 옵션을 비교하고, 결과를 미리 보고, 오류를 막는 그래픽 인터페이스의 장점이 다시 필요해집니다. 다만 그 인터페이스는 독립 앱이 아니라 어시스턴트 안에서 나타날 수 있습니다.

crit의 관점: 화면을 줄이는 것이 아니라, 화면의 소유권이 바뀐다

이 글의 좋은 점은 AI 인터페이스를 “채팅 UI가 대세다” 정도로 단순화하지 않는다는 데 있습니다. 핵심은 화면이 사라지는 것이 아니라, 화면의 소유권과 진입점이 바뀐다는 것입니다. 사용자는 여전히 폼, 표, 카드, 미리보기, 선택기를 필요로 합니다. 다만 그 화면이 우리 앱 안에만 있지 않을 수 있습니다.

디자이너에게 남는 질문은 꽤 구체적입니다. 우리 제품의 핵심 작업 중 어떤 것은 어시스턴트에서 시작될까. 사용자가 더 이상 우리 홈 화면에 오지 않는다면, 기능은 어떻게 발견될까. 우리가 만든 디자인 시스템은 사람의 화면뿐 아니라 에이전트가 호출하고 렌더링할 수 있는 구조를 가지고 있을까. 기능명, 액션, 권한, 결과, 실패 상태는 모델이 이해할 만큼 명확하게 설명되어 있을까.

아쉬운 점도 있습니다. 원문은 A2UI와 MCP Apps를 비교적 큰 흐름으로 설명하지만, 실제 제품팀이 지금 당장 어디까지 적용할 수 있는지는 아직 불확실합니다. 표준은 빠르게 움직이고 있고, 플랫폼마다 구현도 다릅니다. 그래서 오늘 할 일은 “AI용 새 UI를 전면 설계하자”보다 작아야 합니다.

먼저 사용자의 여정을 표면 단위로 다시 그려보는 것이 좋습니다. 어떤 단계는 여전히 우리 제품 안에서 일어나고, 어떤 단계는 어시스턴트에서 시작되며, 어떤 단계는 백그라운드 에이전트가 처리할 수 있는지 표시해야 합니다. 그 경계에서 기대가 깨집니다. 앞으로의 UX는 화면 안의 흐름만이 아니라, 화면과 어시스턴트 사이의 핸드오프를 설계하는 일이 될 가능성이 큽니다.