•Grok Bot은 정체성·기억·실행 환경을 유지하는 에이전트 에 장기적인 책임을 맡길 수 있도록, 개별 대화 기록 대신 Bot 목록을 제품의 중심에 둠
•인터페이스를 Bots·Chats·Prompts·Tools·Artifacts 라는 다섯 개념으로 정리하고, 아바타 움직임과 필요할 때만 확인하는 실행 상태로 관리 부담을 줄임
•각 Bot의 독립된 컴퓨터 에는 상태 확인·미리보기·제어권 인수의 세 단계로 접근하며, 응답에는 산문뿐 아니라 카드·위젯·시스템 이벤트를 함께 표시함
•여러 Bot이 협업할 때 Tools와 Skills는 계정 단위 , 기억과 Routines는 Bot 단위로 관리하며, 조정 역할의 Bot과 그룹 채팅이 업무 분배와 맥락 공유를 지원함
•일정이나 이벤트로 실행하는 Routines 를 주요 인터페이스에 배치하고 불필요한 제어 요소를 제거해, 에이전트의 책임이 커질수록 사용자가 관리할 것은 줄어들도록 설계함
세션을 조작하는 대신 지속적인 책임을 위임하기
•일반적인 AI 인터페이스는 사용자가 설정하고 지켜보며, 대화 종료와 함께 끝나는 채팅 세션 을 중심으로 구성됨
•Grok Bot은 한 세션을 넘어 지속되고 스스로 책임을 수행하는 에이전트를 목표로 삼음
•이를 위해 사이드바에 무엇을 배치할지, 진행 상황을 어떻게 알릴지, 작업을 언제 사용자에게 보여줄지부터 재검토함
사용자가 알아야 할 다섯 가지 기본 개념
•채팅, 세션, 모델, 컨텍스트 윈도, 기억, 시스템 프롬프트, 프로젝트, 스킬, 커넥터, 에이전트, 도구, 샌드박스, 권한, 자동화를 모두 별도로 노출하면 사용자가 필요 이상으로 많은 개념을 이해해야 함
•인터페이스의 기본 개념을 다섯 가지 로 정리함
• Bots : 고유한 정체성, 기억, 실행 환경, 도구를 갖춘 지속형 에이전트임
• Chats : Bot과 함께 일하기 위한 대화 인터페이스임
• Prompts : Bot에 맥락이나 지시를 전달하며, 한 번 사용하거나 Skills로 저장하거나 Routines로 자동 실행할 수 있음
• Tools : 소프트웨어, API, 커넥터, 셸, 컴퓨터 사용을 통해 정보를 얻고 행동하게 함
• Artifacts : Bot이 생성하거나 수정하는 문서, 디자인, 코드, 데이터 등 지속적으로 남는 결과물임
•나머지 개념은 사용자가 알아야 할 이유가 생길 때까지 인터페이스에 드러내지 않음
대화 기록에서 Bot 목록으로
•질문 해결이 상호작용의 단위라면 대화를 만들고 사이드바 아래로 밀어두는 방식이 자연스러움
•하지만 상대가 사용자를 기억하고 장기적으로 책임을 맡아야 한다면 이 방식은 맞지 않음
•Grok Bot의 중심은 대화가 아니라 Bot 임
•각 Bot은 이름, 아바타, 직함을 갖고 사용자와 나눈 대화를 기억함
•자신만의 컴퓨터와 도구를 보유하며, 다음 날 돌아와도 같은 Bot과 일하게 됨
아바타로 정체성과 작업 상태 전달하기
•Bot 목록은 누구인지, 무엇을 하는지, 얼마나 알아야 하는지 라는 세 질문에 답해야 함
•목록이 커져도 매번 이름을 읽지 않고 알아볼 수 있도록, 아바타의 식별성과 시각적 일관성 을 함께 추구함
•이니셜, 이모지, 픽셀 아트, 수채화, 클레이모피즘, Noritake 스타일 선화, 실루엣, 아이덴티콘 등을 검토함
•수채화와 점토 스타일은 개성이 강하지만 사이드바 크기에서는 지나치게 복잡했고, 단순한 체계는 인터페이스에 잘 어울리지만 Bot끼리 구분하기 어려웠음
•최종적으로 단순한 형태와 표현력 있는 눈을 공통 기반으로 삼고, 제한된 변형과 액세서리로 개성을 부여함
•별도 상태 표시기를 늘리는 대신 아바타의 움직임 에 작업 생애주기를 담음
•유휴, 사고, 작업, 대기, 진행 불가, 완료 상태를 고려함
•쉬는 동안에는 차분하고 약간 호기심 있는 모습이며, 작업을 받으면 반응하고 실행을 시작하면서 움직임이 달라짐
•대기하거나 도움이 필요할 때 다시 움직임이 바뀌고, 완료되면 안정된 상태로 돌아감
•실행 정보를 얼마나 보여줄지는 안심할 수 있는 신호 를 기준으로 조정함
•움직이는 점 세 개만으로는 작업 중인지 멈췄는지 판단하기 어려웠음
•현재 행동을 짧은 문장으로 보여주자 사용자는 나머지 단계도 보고 싶어 했고, 사용자 조사에서 그 이유는 주로 정상적으로 진행 중인지 확인하려는 것이었음
•최종 설계에서는 아바타 움직임으로 활동 여부를 알리고, 마우스를 올리면 현재 행동을 확인할 수 있음
사용자의 컴퓨터가 아닌 Bot의 작업 공간
•각 Bot은 웹 탐색, 파일 작업, 소프트웨어 실행에 사용할 자신만의 컴퓨터 를 갖춤
•컴퓨터 화면을 노출하는 네 가지 배치를 검토했지만 각각 제약이 있었음
• 플로팅 창 은 접근하기 쉽지만 대화를 가림
• 나란히 배치 하면 작업이 계속 보이지만 사용자가 지켜보도록 유도함
• 모달 창 은 확인하기 쉽지만 Bot의 작업 공간을 일시적인 방해 요소처럼 취급함
• 전체 화면 은 넓은 공간을 제공하지만 대화를 완전히 밀어냄
•컴퓨터를 강조할수록 사용자의 감독을 유도했기 때문에, 최종 설계는 필요에 따라 접근하는 세 단계 로 구성함
• 상태 : 컴퓨터가 작동 중이면 제목 표시줄 아이콘이 보라색으로 바뀜
• 미리보기 : 고정된 측면 패널에서 대화를 떠나지 않고 작업을 확인함
• 제어권 인수 : Bot이 도움을 필요로 하면 전체 화면으로 열어 직접 조작한 뒤 제어권을 돌려줌
•배경화면은 아침에 밝아지고 밤에 어두워져, Bot의 컴퓨터에 독립적인 시간감 을 부여하고 사용자 데스크톱과 구분되게 함
•원격 기계를 계속 조작하기보다 동료가 일하는지 확인하고, 필요할 때 화면을 살펴보며, 도움이 필요한 순간에만 개입하는 방식에 가까움
답변의 형식도 답변의 일부로 다루기
•초기 버전은 5일 일기예보나 작업 목록까지 대부분 산문으로 답해, 사용자가 정보를 다시 구조화해야 했음
• 인라인 카드와 위젯 을 도입해 산문이 적합하면 글로, 그렇지 않으면 구조화된 UI로 응답하게 함
•일기예보는 예보 형태로, 작업은 보드 형태로 보여줌
•이메일 위젯에서는 발신자·수신자·제목·본문을 확인하고 전송하거나 폐기할 수 있음
•Routine 생성, 설정 변경, 다른 Bot에 메시지 전송 같은 행동도 대화 기록에 직접 표시 하며, 세부 확인이 필요하면 열어볼 수 있음
•여러 Bot에 진행 상황을 확인한 뒤 이를 매일 수행하는 Routine으로 만드는 흐름을 지원함
•대화, 시스템 이벤트, 상호작용 가능한 객체, 시각화가 하나의 타임라인 을 공유함
여러 Bot의 역량과 맥락을 나누는 기준
•Bot이 늘어나면 역할별 맥락을 유지하고 겹치는 업무의 정보를 공유하면서도, 사용자에게 업무 배분 부담을 넘기지 않는 조정 방식이 필요함
•일부 사용자는 Chief of Staff Bot 에 여러 전문 Bot의 조정을 맡김
•각각을 확인하고 모든 업무를 직접 전달하는 대신, 하나의 Bot에 지시할 수 있음
•역할마다 필요한 기억이 다르므로 역량과 맥락의 경계 를 다르게 설정함
•법무 Bot에는 진행 중인 분쟁 이력이, 재무 Bot에는 수년간의 재무 기록이 필요할 수 있음
•이를 하나의 거대한 기억으로 합치면 각 Bot에 업무 관련 정보를 제공하기 어려워짐
• Tools와 Skills 는 여러 Bot이 웹 탐색·문서 작업·이메일 발송에 활용할 수 있도록 계정 단위로 둠
• 기억과 Routines 는 해당 역할이 장기적으로 알고 수행하는 내용이므로 Bot에 귀속함
• 그룹 채팅 은 전문 기억을 유지하면서 프로젝트나 팀의 맥락을 공유하는 공간임
•디자이너, 엔지니어, PM, 데이터 과학자 역할의 Bot이 같은 대화에서 협업하고 작업을 넘기며 필요한 정보를 공유할 수 있음
•대시보드, 업무 배정 보드, 명시적인 인계 제어 기능은 사용자에게 조정 업무를 더했기 때문에 채택하지 않음
•대신 조정 Bot 이 일상적인 업무 분배를 처리하고, 판단이 필요한 결정에서 사용자를 참여시킴
프롬프트 없이도 계속되는 업무
•지속형 Bot이라도 사용자의 프롬프트만 기다리면 누군가가 매번 활성화해야 함
• Routines 는 일정이나 이벤트에 따라 실행되는 상시 책임을 부여함
•산업 동향 관찰이나 매일 아침 브리핑 준비처럼 업무를 한 번 정의하면 필요한 시점에 Bot이 활성화됨
•처음에는 부차적인 설정으로 취급했지만, 자율 업무에서 중요성이 커지면서 Bot의 주요 인터페이스 로 옮김
•대화 기록에서 무엇이 실행됐는지 확인하고 결과를 검토하거나 예외를 처리할 수 있음
•트리거는 정기 일정과 업무 이벤트 를 포괄함
•매일·평일·매주·매월·30분 간격 등으로 실행할 수 있음
•이슈 생성·상태 변경·주기 종료, 사고 발생, PR 열기·병합·닫기, 코드 푸시, 검사·워크플로 실패, 라벨 추가, 특정 문자열을 포함한 댓글, 리뷰 승인, 스레드 해결 같은 이벤트를 지원함
•웹훅 POST 수신, 채널이나 팀의 새 메시지, 반응 추가, 조건에 맞는 채널 생성도 트리거로 사용할 수 있음
•대화는 프롬프트뿐 아니라 일정·이벤트·다른 Bot 에 의해서도 시작될 수 있으며, 시간이 지나면서 사용자가 없는 동안 시작되는 업무가 더 많아질 수 있음
책임이 커질수록 인터페이스는 줄어들어야 함
•설계 후반에는 제어 요소를 제거하는 작업 이 큰 비중을 차지함
•창과 패널 제어, 컴퓨터 보기 옵션, 에이전트 메타데이터를 제거함
•실용적인 제한으로 계정당 약 50개 Bot , 그룹 채팅당 6개 Bot 을 설정함
•각 결정은 사용자의 위임을 돕는지, 아니면 관리할 것을 하나 더 만드는지를 기준으로 삼음
•모델이 개선되면서 AI를 직접 조작하는 것과 동료에게 위임하는 것 사이의 경계도 움직임
•에이전트가 더 많은 책임을 맡을수록 인터페이스가 사람에게 요구하는 것은 줄어들어야 함