이것이 위임을 돕는가 관리할 것을 하나 더 주는가 - Grok Bot이 인터페이스를 덜어낸 기준

이것이 위임을 돕는가 관리할 것을 하나 더 주는가

TL;DR

• 출발점은 현재 관행에 대한 진단인데 대부분의 AI 인터페이스가 사용자가 조작하는 채팅 세션을 중심으로 조직되어 있어서 각 세션이 설정으로 시작하고 사용자가 지켜보는 동안 펼쳐지고 대화가 멈추면 끝난다는 것이다. 목표는 달랐다. 어떤 한 세션을 넘어 지속하며 스스로 책임을 질 수 있는 에이전트를 위해 설계하려 했고, 그래서 사이드바에 무엇이 속하는지부터 다시 생각해야 했다
• 어휘를 줄이는 데서 시작했는데 채팅과 세션, 모델, 컨텍스트 윈도, 메모리, 스킬, 커넥터, 샌드박스, 권한 같은 개념 하나하나를 별도 제품 개념으로 노출하는 것은 사용자에게 필요한 것보다 더 많이 이해하라고 요구하는 일이다. 그래서 다섯으로 압축했다. 봇과 채팅, 프롬프트, 도구, 아티팩트만 남기고 그 밖의 모든 것은 사용자가 신경 쓸 이유가 생길 때까지 인터페이스 아래에 둔다
• 주 객체를 채팅에서 봇으로 옮긴 근거도 명확한데 채팅은 소모품이어서 문제를 풀려고 시작하면 사이드바 아래로 밀려나고 가장 최근 다섯 개를 넘어서는 거의 돌아가지 않는다. 상호작용의 단위가 질문일 때는 합리적이지만 상대가 지속적 존재라면 이상해진다. 그래서 봇이 주 객체가 되고, 내일 돌아올 때 같은 봇에게 돌아온다
• 감독을 유도하지 않는 설계가 핵심 발견인데 컴퓨터 노출 방식을 네 가지로 실험한 뒤 컴퓨터를 더 두드러지게 만들수록 제품이 사용자에게 그것을 감독하도록 더 유도했다는 것을 확인했다. 그래서 3단으로 갈랐다. 상태는 제목 표시줄 아이콘 색으로, 미리보기는 대화를 떠나지 않는 고정 측면 패널로, 인수는 봇이 도움을 요청할 때 전체 화면으로 제어권을 가져오는 방식이다
• 능력과 맥락은 서로 다른 경계를 따르는데 도구와 스킬은 계정 수준에 두어 많은 봇이 웹 브라우징이나 문서 작업, 이메일 발송에 쓰게 하고, 메모리와 루틴은 봇에 두어 그 역할이 시간에 걸쳐 무엇을 알고 무엇을 하는지 반영하게 한다. 원칙은 한 문장이다. 능력은 넓게 공유될 수 있지만 맥락은 그것을 필요로 하는 역할에 남는다

Source

Designing Grok Bot — xAI, 2026년 9월 3일

[x.ai/news/designing-grok-bot](https://x.ai/news/designing-grok-bot)

Knowledge

세션을 넘어 지속하는 에이전트를 위한 설계

Grok Bot을 설계하기 시작했을 때 중심 질문은 하나였다. 인터페이스가 사용자와 에이전트의 관계를 어떻게 형성해야 하는가.

대부분의 AI 인터페이스는 사용자가 조작하는 채팅 세션을 중심으로 조직되어 있다. 각 세션은 설정으로 시작하고 사용자가 지켜보는 동안 펼쳐지고 대화가 멈추면 끝난다. 우리가 원한 것은 달랐다. 어떤 한 세션을 넘어 지속하며 스스로 책임을 질 수 있는 에이전트를 위해 설계하고 싶었다. 그러려면 인터페이스의 기본 객체와 신호 일부를 다시 생각해야 했다. 사이드바에 무엇이 속하는지, 에이전트가 어떻게 진행을 보이는지, 그 작업이 언제 보이게 되어야 하는지가 모두 다시 결정할 문제였다.

원시 개념을 다시 짜기

AI 제품들은 짧은 시간에 큰 어휘를 축적했다. 채팅과 세션, 모델, 컨텍스트 윈도, 메모리, 시스템 프롬프트, 프로젝트, 스킬, 커넥터, 에이전트, 도구, 샌드박스, 권한, 자동화가 모두 이 시스템들의 실제 부분을 서술한다. 그런데 그 하나하나를 별도의 제품 개념으로 노출하는 것은 사용자에게 필요한 것보다 더 많이 이해하라고 요구하는 일이다. 그래서 다른 질문에서 시작했다. 사람이 에이전트와 일하기 위해 실제로 필요한 개념은 무엇인가.

다섯 개로 계속 돌아왔다. 봇은 자기 정체성과 메모리, 런타임, 도구를 가진 지속적 에이전트다. 채팅은 봇과 일하기 위한 대화 인터페이스다. 프롬프트는 봇에게 맥락이나 지시를 주는데, 한 번 쓸 수도 있고 스킬로 저장할 수도 있고 루틴으로 자동 발동시킬 수도 있다. 도구는 봇이 소프트웨어와 API, 커넥터, 셸, 또는 컴퓨터 사용을 통해 정보에 접근하고 행동하게 한다. 아티팩트는 봇이 만들거나 수정하는 문서와 디자인, 코드, 데이터, 그리고 다른 지속적 산출물이다. 그 밖의 모든 것은 사용자가 신경 쓸 이유가 생길 때까지 인터페이스 아래에 남아 있을 수 있다. 다음 질문은 이 다섯 객체 중 어느 것이 제품을 조직해야 하는지였다.

대화 이력에서 봇 명부로

채팅은 소모품이다. 문제를 풀려고 대화를 시작하면 그것이 사이드바 아래로 밀려나고 일주일 뒤 또 다른 것을 시작한다. 가장 최근 다섯 개를 넘어서는 거의 돌아가지 않는다.

상호작용의 단위가 질문일 때 그 행태는 완벽하게 합리적이다. 그런데 상호작용의 반대쪽에 있는 것이 나를 알고 이전 작업을 기억하고 시간에 걸쳐 책임을 지기로 되어 있는 존재라면 이상해진다. 그래서 Grok Bot의 주 객체는 대화가 아니라 봇이다. 봇은 이름을 갖고 아바타와 직함을 가지며 당신과의 대화를 기억하고 자기 컴퓨터와 도구를 갖는다. 내일 돌아올 때 같은 봇에게 돌아오는 것이다.

현존을 인터페이스로

봇이 시작하는 세션이 아니라 시간에 걸쳐 유지하는 무언가가 되자, 제품에서 봇이 나타나는 방식이 세 질문에 동시에 답해야 했다. 이것은 누구인가. 그들이 무엇을 하고 있는가. 내가 얼마나 알아야 하는가.

첫 질문은 명부의 문제였다. 명부는 빠르게 훑을 수 있어야만 작동한다. 명부가 커지면서 제품을 열 때마다 모든 이름을 읽어야 하는 상황은 원하지 않았다. 거의 주변시로도 아바타에서 봇을 인식할 수 있어야 했다. 동시에 아바타들이 하나의 시스템으로 읽힐 만큼 일관되게 유지하고 싶었다.

일러스트레이션과 애니메이션, 게임, 인터페이스 디자인에 걸친 캐릭터 시스템을 연구했다. 이니셜과 이모지에서 픽셀 아트, 수채화, 클레이모피즘, 노리타케 스타일 라인 아트, 실루엣, 아이덴티콘까지 탐색했다. 대부분의 접근이 문제의 한쪽을 다른 쪽보다 잘 풀었다. 수채화와 클레이는 개별 봇에 충분한 성격을 줬지만 사이드바 크기에서 너무 많은 디테일을 지녔다. 더 단순한 시스템은 인터페이스에 더 자연스럽게 앉았지만 봇들이 서로 교체 가능해 보이게 만드는 일이 잦았다.

최종 시스템은 기본 구성을 일관되게 유지한다. 단순한 형태와 표현력 있는 눈을 쓰고 그다음 통제된 변형과 액세서리로 구별을 도입한다. 각 봇이 한눈에 인식 가능하게 남으면서도 다른 시각 세계에서 온 것처럼 보이지 않는다.

아바타 하나에 생애주기를 싣기

아바타가 봇의 정체성이 되자 그것이 상태를 보여줄 자연스러운 자리이기도 했다. 봇은 유휴나 사고 작업, 대기, 차단, 완료 상태일 수 있다. 각 상태를 별도 표시기로 나타낼 수도 있었는데, 그것은 사용자가 해석할 UI 층을 하나 더 더하는 일이었다. 대신 아바타 자체가 생애주기의 얼마나 많은 부분을 짊어질 수 있는지 탐색했다.

움직임으로 상태를 갈랐다. 쉴 때 봇은 차분하고 약간 호기심 있다. 작업이 오면 그 과업을 인정한다. 작업이 시작되면 기어를 넣는다. 기다리거나 도움이 필요할 때 움직임이 다시 바뀐다. 작업이 끝나면 가라앉는다. 그래서 아바타가 어느 봇인지만이 아니라 봇이 무엇을 하고 있는지도 보여준다.

얼마나 보여줄 것인가

봇의 실행을 얼마나 보여줄지도 관련된 설계 질문이었다. 표준적인 세 개의 움직이는 점이었을 수도 있는데, 그것은 정보가 너무 적어서 봇이 작동하는지 막혔는지 알기 어렵게 만들었을 것이다. 봇의 현재 행동에 대한 짧은 서면 서술을 보여주는 것도 시도했다. 그런데 사람들이 한 단계를 볼 수 있게 되자 나머지도 보고 싶어 했다.

사용자 리서치가 진짜 동기를 밝혔다. 그들이 주로 그 세부를 요청한 것은 봇이 여전히 작동하고 있고 올바른 궤도에 있다는 안심을 위해서였다. 그래서 최종 설계는 아바타의 움직임이 봇이 활성 상태임을 보여줌으로써 첫 번째 안심을 제공하고 누군가 무엇을 하고 있는지 확인하고 싶으면 호버해서 현재 행동을 볼 수 있게 했다.

당신 것이 아니라 그들의 컴퓨터

각 봇은 자기 컴퓨터를 갖는다. 그것으로 웹을 브라우징하고 파일로 작업하고 소프트웨어를 실행할 수 있다. 문제는 그 컴퓨터가 얼마나 보여야 하는지, 사용자가 언제 그것을 제어할 수 있어야 하는지였다.

네 배치를 탐색했다. 떠 있는 창은 컴퓨터에 접근하기 쉽게 유지했지만 대화를 덮었다. 나란히 배치는 작업을 계속 보이게 만들었고 사용자가 그것을 지켜보도록 유도했다. 모달은 확인을 쉽게 만들었지만 봇의 작업 공간을 일시적 방해로 취급했다. 전체 화면은 컴퓨터에 충분한 공간을 줬지만 대화를 완전히 밀어냈다.

여기서 핵심 관찰이 나왔다. 컴퓨터를 더 두드러지게 만들수록 제품이 사용자에게 그것을 감독하도록 더 유도했다. 그래서 컴퓨터는 봇의 작업 공간으로 남고 인터페이스는 사용자가 필요할 때 서로 다른 수준의 접근을 제공하기로 했다. 세 수준이 사용자를 봇의 작업 공간에 들이면서도 그것을 조작하는 데 끌려 들어가지 않게 한다. 상태는 컴퓨터가 활성인 동안 제목 표시줄 아이콘이 자색으로 바뀌는 것이다. 미리보기는 그것을 열면 고정된 측면 패널이 나타나 사용자가 대화를 떠나지 않고 작업을 따라갈 수 있는 것이다. 인수는 봇이 도움이 필요할 때 사용자가 컴퓨터를 전체 화면으로 열어 제어권을 가져오고 그다음 돌려주는 것이다.

디테일 하나를 더 넣었다. 하루 동안 변하는 배경화면인데 아침에는 밝아지고 밤에는 어두워진다. 그 디테일이 봇의 컴퓨터에 자기만의 시간 감각을 주고 사용자의 데스크톱과 분리되어 느껴지게 만든다. 원격 기계를 조작하는 것보다 동료와 일하는 것에 더 가까워진다. 그들이 작업하고 있다는 것을 알 수 있고 맥락이 필요할 때 그들의 화면을 흘깃 볼 수 있고 무언가 도움이 필요할 때 앉을 수 있다.

정보의 형태

Grok Bot의 초기 버전은 거의 모든 요청에 산문으로 응답했다. 5일 예보를 보여주는 대신 서술했고 일련의 과업을 보드로 배치하는 대신 이야기했다. 그러면 사용자가 답을 재구조화해야 했다. 그래서 응답의 형태를 답의 일부로 취급하게 됐다.

이를 지원하려고 Grok Bot에 인라인 카드와 위젯을 넣었다. 봇은 산문이 정보에 맞을 때는 산문으로 답하고 그렇지 않을 때는 구조화된 UI를 쓸 수 있다. 행동에도 같은 원칙이 적용된다. 봇이 루틴을 만들거나 설정을 바꾸거나 다른 봇에게 메시지를 보낼 때 그 사건이 대화록에 직접 나타나고 검사할 것이 더 있으면 사용자가 그것을 열 수 있다. 결과는 대화와 시스템 사건, 상호작용 가능한 객체, 시각화가 하나의 타임라인을 공유하는 이질적인 대화록이다.

지능을 조직하기

사람들이 봇 여러 개를 만들면 제품은 그 봇들이 함께 일하는 방식도 조직해야 한다. 어떤 맥락이 각 역할에 속해야 하는지, 작업이 겹칠 때 봇들이 맥락을 어떻게 공유해야 하는지, 사용자를 배차원으로 만들지 않으면서 어떻게 조율할지를 정해야 했다.

답이 사용자에게서 나왔다. 사람들이 봇을 더 많이 만들면서 일부가 여러 전문가를 조율하는 책임을 맡은 참모장 봇을 만들었다. 각각을 확인하고 모든 과업을 직접 라우팅하는 대신 한 봇에게 지시를 줄 수 있었다.

봇들에게 구별되는 역할을 주는 것은 각 역할이 무엇을 알아야 하는지 결정하게 강요했다. 법무 봇은 진행 중인 분쟁의 이력이 필요할 수 있고 재무 봇은 여러 해의 재무 기록이 필요할 수 있다. 그 이력들을 하나의 큰 메모리로 합치면 각 봇에게 그 작업에 관련된 정보를 주기가 더 어려워진다. 그래서 Grok Bot에서 능력과 맥락은 서로 다른 경계를 따른다. 도구와 스킬은 계정 수준에 있는데, 많은 봇이 웹을 브라우징하거나 문서로 작업하거나 이메일을 보낼 필요가 있을 수 있기 때문이다. 반면 메모리와 루틴은 봇에 속하는데, 그 특정 역할이 시간에 걸쳐 무엇을 알고 무엇을 하는지를 반영하기 때문이다. 다시 말해 능력은 넓게 공유될 수 있지만 맥락은 그것을 필요로 하는 역할에 남는다.

역할 경계를 넘는 작업은 그룹 채팅이 처리한다. 프로젝트나 팀을 위한 공유 맥락을 제공하면서 각 봇이 자기 전문 메모리를 유지하게 한다. 디자이너와 엔지니어, PM, 데이터 과학자가 같은 대화에서 일하고 서로에게 작업을 넘기고 프로젝트가 요구하는 것을 공유할 수 있다. 이 그룹들을 관리하려고 대시보드와 배정 보드, 명시적 인계 제어를 추가하는 것도 고려했다. 각각이 사용자에게 더 많은 조율 작업을 줬다. 대신 조율하는 봇들이 일상적 라우팅을 처리하고 판단이 필요한 결정일 때 사용자를 들인다.

계속 움직이는 작업

대부분의 에이전트 세션은 사용자가 프롬프트를 보낼 때 시작한다. 그러면 지속적인 봇조차 누군가 활성화해 주기를 기다리게 된다.

루틴이 그것을 푼다. 사용자가 봇에게 일정에 따라 또는 사건에 응답해 실행되는 상시 책임을 줄 수 있게 한다. 어떤 산업을 지켜보거나 매일 아침 브리핑을 준비하는 일이 여기 해당한다. 사용자가 작업을 한 번 정의하고 루틴이 그것이 일어나야 할 때 봇을 활성화한다.

처음에는 루틴을 이차적 설정으로 취급했다. 그것이 자율적 작업에 더 중요해지면서 봇의 주 인터페이스로 옮겼다. 대화록은 무엇이 실행되었는지 보여주고 사용자가 결과를 검토하거나 예외를 처리할 자리를 준다. 프롬프트가 세션을 시작할 수 있지만 일정과 사건, 또는 다른 봇도 그럴 수 있다. 시간이 지나면서 더 많은 작업이 사용자가 아예 없는 상태에서 시작될 수 있다.

사라지는 인터페이스

프로젝트가 끝날 무렵 설계 작업의 많은 부분이 무언가를 덜어내는 일이었다. 창과 패널 제어, 컴퓨터 보기 옵션, 에이전트 메타데이터를 제거했다. 실용 한계도 정했는데 계정당 대략 봇 50개, 그룹 채팅당 6개다.

각 결정은 같은 질문으로 돌아왔다. 이것이 누군가 위임하는 것을 도왔는가, 아니면 그들에게 관리할 것을 하나 더 준 것인가.

AI를 조작하는 것과 동료에게 위임하는 것 사이의 선은 모델이 개선되면서 계속 움직인다. Grok Bot은 그것이 오늘 어디에 있다고 우리가 생각하는지를 반영한다. 가장 초기 탐색부터 출시까지 Grok Bot을 설계하는 일은 그 선을 찾고 인터페이스가 그것과 함께 변하도록 돕는 것이었다. 에이전트가 더 많은 책임을 맡으면서 인터페이스는 사람에게 더 적게 요구해야 한다.

더 생각해보기

• 원시 개념을 다섯 개로 줄인 판단은 고급 사용자의 통제 요구와 어디서 충돌하는가.
• 채팅이 소모품이라는 전제는 어떤 사용 패턴에서 깨지는가.
• 아바타에 상태 여섯 단계를 싣는 방식은 색각 이상이나 저사양 환경에서 어떻게 작동하는가.
• 세부를 원하는 요청이 실은 안심 요구였다는 발견은 다른 제품에도 일반화되는가.
• 컴퓨터를 두드러지게 하면 감독을 유도한다는 관찰은 신뢰가 낮은 초기 사용자에게도 옳은가.
• 능력은 계정에 맥락은 봇에 두는 경계는 봇 사이 지식 이전이 필요할 때 어떻게 처리되는가.
• 참모장 봇 패턴이 사용자에게서 나왔다면 그것을 공식 기능으로 만들 조건은 무엇인가.
• 대시보드와 배정 보드를 기각한 판단은 봇이 수십 개로 늘면 유지되는가.
• 루틴을 주 인터페이스로 옮긴 결정은 실패한 자동 실행의 책임을 누구에게 두는가.
• 계정당 봇 50개라는 한계는 무엇을 근거로 정해졌는가.