Grok Bot은 채팅이 아닌 Bot을 메인 객체로 만들었습니다 — 계정당 하나의 메모리가 아닌 역할당 하나의 메모리 (2026)

5가지 기본 요소, 그리고 Bot의 승리

에세이는 용어의 피로감에서 시작하는데, 이는 타당한 진단입니다: "채팅, 세션, 모델, 컨텍스트 창, 메모리, 시스템 프롬프트, 프로젝트, 스킬, 커넥터, 에이전트, 도구, 샌드박스, 권한, 자동화 등은 모두 이러한 시스템의 실제 부분을 설명합니다." 그들의 결론은 다음과 같습니다: "이들 각각을 별도의 제품 개념으로 노출하는 것은 사용자에게 필요 이상으로 많은 것을 이해하도록 요구합니다."

그들은 5가지만 남겼습니다. 원문 그대로 인용합니다:

• "Bots는 고유한 아이덴티티, 메모리, 런타임, 도구를 가진 지속적인 에이전트입니다."
• "Chats는 Bot과 작업하기 위한 대화형 인터페이스입니다."
• "Prompts는 Bot에게 컨텍스트나 지침을 제공합니다. 일회성으로 사용하거나, Skills로 저장하거나, Routines로 자동 실행되도록 트리거할 수 있습니다."
• "Tools는 Bots가 소프트웨어, API, 커넥터, 셸 또는 컴퓨터 사용을 통해 정보에 액세스하고 조치를 취할 수 있도록 합니다."
• "Artifacts는 Bots가 생성하거나 수정하는 문서, 디자인, 코드, 데이터 및 기타 지속 가능한 결과물입니다."

이 목록에서 메모리가 어디에 위치하는지 주목하십시오. 메모리는 사용자의 속성이 아니라, 아이덴티티 및 런타임과 함께 Bot의 속성입니다.

채팅 기록이 Bot 목록이 되다

인터페이스의 결과는 명확하게 설명되어 있습니다: "따라서 Grok Bot의 주요 객체는 대화가 아니라 Bots입니다. Bot은 이름을 가집니다. 아바타와 타이틀을 가집니다. 사용자와의 대화를 기억합니다. 자체 컴퓨터와 도구를 가집니다. 내일 다시 돌아올 때, 여러분은 동일한 Bot으로 돌아오는 것입니다."

사이드바에는 스레드가 아닌 Bots가 나열되며, 아바타는 아이덴티티를 전달하는 동시에 상태 표시기 역할도 겸합니다 — "Bot은 대기 중, 생각 중, 작업 중, 대기 중, 차단됨 또는 완료 상태일 수 있습니다."

각 Bot은 자체 머신도 할당받습니다: "각 Bot은 자체 컴퓨터를 가지고 있어 웹 브라우징, 파일 작업, 소프트웨어 실행 등에 사용할 수 있습니다." 액세스는 세 가지 수준으로 제공되며, 마지막은 "Takeover(인수): Bot의 도움이 필요할 때 사용자가 컴퓨터를 전체 화면으로 열고 제어권을 가져온 다음 다시 넘겨줄 수 있습니다."로 끝납니다.

중요한 분리: 기능은 공유되고, 컨텍스트는 공유되지 않는다

다음은 두 번 읽을 가치가 있는 문단이자, 이 글이 존재하는 이유입니다:

"따라서 Grok Bot에서 기능(Capabilities)과 컨텍스트(Context)는 서로 다른 경계를 따릅니다. 많은 Bots가 웹 브라우징, 문서 작업, 이메일 발송을 필요로 할 수 있기 때문에 Tools와 Skills는 계정 수준에 존재합니다. Memory와 Routines는 특정 역할이 시간이 지남에 따라 알고 수행하는 바를 반영하므로 Bot에 속합니다. 달리 말해, 기능은 광범위하게 공유될 수 있는 반면 컨텍스트는 그것을 필요로 하는 역할에 머무릅니다."

의도적으로 두 개의 서로 다른 범위를 둔 것입니다. 그리고 그들은 그 이유를 다음과 같이 설명합니다:

"법률 Bot은 진행 중인 분쟁의 기록이 필요할 수 있는 반면, 재무 Bot은 수년간의 재무 기록이 필요할 수 있습니다. 이러한 기록들을 하나의 큰 메모리로 통합하면 각 Bot에게 해당 작업과 관련된 정보를 제공하기가 더 어려워집니다."

이것은 지속성을 중심으로 제품을 막 재구축한 벤더가 내놓은, 메모리 풀링(pooling)에 대한 명시적인 반대 논거입니다. 가볍게 넘기기보다는 진지하게 받아들일 가치가 있습니다.

프롬프트 없이 시작되는 작업

시작 없는 지속성은 절반의 아이디어에 불과하므로 한 가지 더 짚고 넘어가겠습니다: "대부분의 에이전트 세션은 사용자가 프롬프트를 보낼 때 시작됩니다. 이는 지속적인 Bot조차 누군가 활성화해주기를 기다리게 만듭니다." Routines가 그 해답입니다 — "일정에 따라 또는 이벤트에 반응하여 실행되는 상시 책임" — 그리고 이 기능은 디자인 중간에 격상되었습니다: "우리는 처음에 Routines를 보조적인 설정으로 취급했습니다. 자율적인 작업에서 이 기능이 더 중요해짐에 따라, 우리는 이를 Bot의 메인 인터페이스로 이동시켰습니다."

Routines는 메모리와 마찬가지로 Bot으로 범위가 제한됩니다. Skills와 Tools는 그렇지 않습니다.

같은 날 공개된 엔터프라이즈 페이지

에세이와 함께 SpaceXAI는 기업용 Grok Bot을 출시했으며, Bot을 작업자 관점에서 다음과 같이 설명했습니다: "Bot은 특정 작업을 위해 Grok Bot 내에 생성하는 작업자입니다. 각 Bot은 클라우드의 자체 컴퓨터에서 실행되며, 여러분과 동일한 방식으로 모든 앱과 웹사이트를 사용할 수 있습니다." 격리에 대해서는 다음과 같이 언급했습니다: "Grok Bot에서 각 사용자의 작업은 다른 모든 사용자와 분리된 자체 보안 및 격리된 환경에서 실행됩니다. Bot은 기본적으로 액세스 권한이 없으며 사용자가 로그인한 계정에만 도달합니다."

출시 노트에 따르면 Grok 및 Cursor Enterprise 고객은 "향후 2주 동안" 무료로 사용할 수 있으며, "기존 시트가 없는 사람들을 포함하여" 조직 전체를 초대할 수 있습니다.

지속성의 단위를 세션에서 분리해 냅니다. 이는 실질적인 변화이며 올바른 방향입니다. 자체 상태, 도구, 상시 책임을 가진 이름 있는 객체는 이전 대화를 되감아 찾아봐야 하는 대화창보다 축적된 지식을 담기에 더 나은 컨테이너입니다.

메모리를 이식 가능하게 만들지는 않습니다. Bot의 메모리는 해당 제품 내의 해당 Bot의 속성입니다. 에세이의 그 어떤 내용도 메모리가 이동할 수 있음을 시사하지 않습니다. 그리고 역할별 범위 지정은 지식이 벤더뿐만 아니라 역할별로도 분할되기 때문에 이동을 더 어렵게 만듭니다.

병합되지 않으며, 이는 의도된 것입니다. 법률 Bot과 재무 Bot을 실행하는 경우, 어느 쪽도 상대방이 무엇을 학습했는지 알지 못합니다. SpaceXAI는 이를 기능으로 간주하며, 단일 제품 내에서의 검색(retrieval) 품질 측면에서는 일리가 있는 주장입니다.

그들도 공유 컨텍스트 문제를 인정합니다. 에세이는 역할이 절대 겹치지 않는 척하지 않습니다: "그룹 채팅은 프로젝트나 팀에 공유 컨텍스트를 제공하는 동시에 각 Bot이 전문화된 메모리를 유지할 수 있도록 합니다." 따라서 그들의 모델에도 공유 레이어가 존재합니다. 다만 이는 저장소가 아니라 프로젝트로 범위가 지정된 대화입니다.

조정 문제를 없애는 것이 아니라 위치를 옮길 뿐입니다. 그들의 해답은 실제 사용 사례에서 나왔습니다: "일부 사용자는 여러 전문가를 조정하는 역할을 담당하는 비서실장(Chief of Staff) Bot을 만들었습니다." Bots 간에 작업을 라우팅하는 Bot은 합리적인 패턴이며, 이 또한 라우팅에 대한 자체적인 별도 메모리를 가진 Bot입니다.

"Bot별 메모리는 메모리 문제가 해결되었음을 의미한다." 단일 제품 내부에서, 단일 역할에 대해서만 해결된 것입니다. 도구를 전환할 때 사용자의 규칙이나 관례를 파악하는 것과 같이 이전부터 어려웠던 문제는 여전히 해결되지 않았습니다. 이는 what persistent memory actually is에서 다룬 것과 동일한 차이점입니다.

"그렇다면 하나의 큰 메모리는 실수다." 이는 주의 깊게 바로잡아야 할 오해입니다. SpaceXAI의 주장은 생각보다 좁은 범위에 적용되기 때문입니다. 그들은 역할 기록을 하나의 덩어리로 병합하는 것에 반대하는 것입니다. 즉, 수년간의 재무 기록과 활발히 진행 중인 법률 분쟁을 단일 저장소에 쏟아붓고 검색 알고리즘이 이를 알아서 분류해 주기를 바라는 방식에 반대하는 것입니다. 이는 실제 검색 품질의 문제이며, 그들의 지적은 옳습니다.

그들이 반대하지 않는 것은 지속적인 사실들의 공유 소스입니다. 예를 들어 아키텍처 결정 사항, 도메인 어휘, 규칙 등이 이에 해당합니다. 이러한 것들은 특정 역할의 기록이 아닙니다. 모든 역할에 동일하게 적용되는 것이며, 모든 Bot이 이를 개별적으로 다시 학습하는 것은 효율적인 관리가 아니라 낭비입니다. 기록의 범위를 제한하는 것과 사실을 공유하는 것은 서로 다른 조치이며, 에세이가 옹호하는 것은 전자뿐입니다.

"그러니 모든 Bot에게 동일한 지침을 주어야겠다." 동일한 컨텍스트를 5개의 Bot에 복사하는 것은 한 달 정도는 해결책처럼 보이는 임시방편에 불과합니다. 그러다 한 복사본만 수정되고 나머지는 수정되지 않으면, 5명의 전문가가 사용자의 규칙에 대해 서로 확신을 가지고 불일치하는 의견을 내놓는 상황이 발생합니다. 이는 multi-agent memory에서 설명한 실패 모드입니다.

"Routines가 자율적으로 작동하게 해주니 컨텍스트에 대해 더 이상 신경 쓰지 않아도 된다." Routines는 Bot이 언제 작동할지를 결정합니다. Bot이 무엇을 알고 있는지를 결정하지는 않습니다. 매일 아침 오래된 컨텍스트를 바탕으로 실행되는 Routine은 매일 아침 잘못된 결과를 낳을 뿐입니다.

"Takeover 기능이 있으니 모든 것을 감독할 수 있다." 세 가지 액세스 수준은 바로 그러한 상황을 피하기 위해 특별히 설계되었습니다: "컴퓨터를 더 눈에 띄게 만들수록 제품은 사용자가 이를 감독하도록 부추겼습니다." Takeover는 예외적인 경로이지 일반적인 워크플로우가 아닙니다.

1단계: 컨텍스트를 기록과 사실로 분류하기

실제로 사용하는 Bot 하나를 선택해 그동안 축적된 내용을 읽어보십시오. 모든 항목을 두 개의 더미로 분류하십시오.

기록(History). 이 역할이 수행하고, 결정하고, 지시받은 일련의 내용입니다. 분쟁 타임라인, 수집된 영수증, 소싱된 후보자 등이 이에 해당합니다. 이는 Bot에 속하며, 이를 여러 역할에 걸쳐 병합하면 검색 품질이 저하된다는 SpaceXAI의 지적은 옳습니다.

사실(Facts). 누가 묻든 상관없이 조직에 대해 항상 참인 정보입니다. API 버전 관리 방식과 그 이유, 내부 용어의 의미, 각 팀의 담당 업무, 작성 규칙, 준수해야 할 규제 제약 조건 등이 이에 해당합니다.

두 번째 더미는 소리 없이 중복되는 부분입니다. 여러분이 만드는 모든 Bot은 이 정보의 일부를 필요로 하며, 역할별 메모리 구조에서는 모든 Bot이 이를 처음부터 다시 학습해야 합니다. 그렇지 않으면 정보를 알지 못해 오류를 범하게 됩니다.

2단계: 5번째 Bot을 만들기 전에, 각 Bot의 공유 컨텍스트가 어디서 오는지 결정하기

2개의 Bot은 수동으로 관리할 수 있습니다. 하지만 5개가 되는 순간 복사본 간의 불일치가 발생하기 시작합니다.

SpaceXAI가 이미 계정 수준으로 범위를 지정한 요소들을 살펴보십시오. 바로 Tools와 Skills입니다. "많은 Bots가 웹 브라우징, 문서 작업, 이메일 발송을 필요로 할 수 있기 때문"입니다. 이는 사실(facts)에도 정확히 적용되는 논리입니다. 기능의 경계가 "많은 Bot이 이것을 필요로 한다"로 설정된 것처럼, 지식에 동일한 테스트를 적용하면 동일한 답을 얻을 수 있습니다.

실질적으로, 각 Bot에 대해 어떤 공유 사실이 필요한지, 그리고 현재 그 사실들을 어디서 가져오는지 적어보십시오. 만약 그 답이 "첫 번째 대화에서 내가 입력한 내용"이라면, 그것이 바로 불일치가 발생할 복사본입니다.

여기서는 그룹 채팅을 의도적으로 활용할 가치가 있습니다. 그룹 채팅은 "프로젝트나 팀에 공유 컨텍스트를 제공하는 동시에 각 Bot이 전문화된 메모리를 유지할 수 있도록" 하므로, 프로젝트별로 겹치는 부분에는 적합하지만 상시 규칙에는 적합하지 않습니다. 그룹 채팅은 대화일 뿐이며, 규칙은 대화보다 더 오래 지속되어야 하기 때문입니다.

3단계: 어떤 Bot도 소유하지 않는 레이어에 사실을 배치하기

구조적인 해결책은 계정 수준의 Tools 경계가 이미 암시하고 있는 것과 같습니다. 즉, 많은 Bot이 필요로 하는 것은 그 어떤 단일 Bot 내부에도 존재해서는 안 된다는 것입니다.

제품 외부의 메모리 레이어가 지식에 대해 이 역할을 수행합니다. 각 Bot은 SpaceXAI가 설계한 대로 정확히 범위가 지정되고 전문화된 자체 기록을 유지하며, 공유 사실은 어떤 Bot의 소유도 아닌 저장소에서 읽어옵니다. 이렇게 하면 6번째 전문가 Bot을 만들 때 규칙을 6번째로 다시 설명할 필요가 없어지며, 수정 사항은 5번이 아닌 단 한 번만 반영하면 됩니다.

또한 이는 Bot별 메모리가 해결할 수 없는 문제, 즉 다음에 사용할 도구로의 전환 시에도 유지됩니다. MemoryLake는 3단계로 설정할 수 있습니다.

1단계: API 키 생성하기

로그인 후 대시보드에서 API 키를 생성합니다. 이 키는 Bot, 계정, 제품이 아닌 사용자 본인에게 속하며, 이는 여러분의 역할이 둘 이상의 벤더에 분산되어 있을 때 매우 중요한 속성입니다.

2단계: 첫 번째 메모리 업로드하기

1단계의 두 번째 더미에 해당하는 내용을 입력하십시오: 아키텍처 결정 사항과 그 이유, 도메인 어휘, 서비스 소유권, 상시 선호도, 모든 역할이 준수해야 하는 제약 조건 등입니다.

기록은 원래 있던 자리에 그대로 두십시오. Bot의 자체 작업 기록은 정확히 해당 Bot의 범위 내에 머물러야 하는 정보입니다.

3단계: AI 및 에이전트 연결하기

에이전트가 이 저장소를 가리키도록 설정하십시오. 새로운 전문가 Bot은 아무것도 없는 상태가 아니라 조직의 사실 정보에서부터 시작하며, 사실 정보는 한 곳에서 올바르게 유지됩니다. 이것이 바로 제품별이 아닌 syncing memory across your tools를 수행하는 핵심 이유입니다.

첫 번째 변화는 전문가 Bot을 만드는 비용이 저렴해진다는 것입니다. 현재는 새 Bot을 만들 때 일반적인 모든 내용을 다시 가르쳐야 하는 비용이 수반되며, 이는 이 디자인이 지향하는 세분화된 역할을 만드는 것을 은연중에 저해합니다.

두 번째는 수정 작업이 N가지 방식으로 분산되지 않는다는 것입니다. 규칙을 한 번만 수정하면 모든 역할이 우연히 전달받은 버전이 아닌 수정된 버전을 읽게 됩니다.

세 번째는 역할 범위 지정이 우회해야 하는 제약 조건이 아니라 진정한 디자인 선택지가 된다는 점입니다. 공유 사실이 공유 레이어에서 제공될 때, 각 Bot의 기록을 좁게 유지하는 데는 아무런 비용도 들지 않습니다. 이는 SpaceXAI가 애초에 원했던 바이며, keeping less in agent memory의 배경이 되는 주장과도 일치합니다.

• 규모를 확장하기 전에 기록과 사실을 분리하십시오. 기록은 역할에 속하고, 사실은 모두에게 속합니다.
• 지식에 Tools 테스트를 적용하십시오. 많은 Bots가 필요로 한다면, 그중 어느 한 Bot 내부에 존재해서는 안 됩니다.
• 공유 컨텍스트를 각 Bot에 복사하지 마십시오. 이는 불일치를 유발하는 메커니즘이며, 소리 없이 오류를 발생시킵니다.
• 프로젝트가 겹치는 부분에는 그룹 채팅을 사용하고, 상시 규칙에는 사용하지 마십시오. 대화는 그 대화보다 더 오래 지속되어야 하는 규칙을 담기에는 적합하지 않은 장소입니다.
• 조정 Bot을 메모리가 아닌 라우터로 취급하십시오. 해당 Bot의 자체 메모리는 도메인이 아닌 라우팅에 관한 것입니다.
• Routine을 예약하기 전에 Bot이 무엇을 알고 있는지 확인하십시오. 자율성은 잘못된 컨텍스트를 포함하여 Bot이 가진 모든 컨텍스트를 증폭시킵니다.
• Takeover는 예외적인 상황으로 유지하십시오. 이 디자인은 의도적으로 감독을 지양합니다. 이를 지속적으로 사용한다는 것은 Bot에게 정보가 부족하다는 것을 의미합니다.
• 변화에 따라 재확인하십시오. Grok Bot은 새로운 제품이고, 엔터프라이즈 혜택은 기간 한정이며, 이처럼 새로운 디자인 결정은 변경되기 쉽습니다.

올해 AI 벤더에서 나온 제품 관련 글 중 가장 사려 깊은 글 중 하나이며, 그 핵심 주장인 '유지하고자 하는 그 어떤 것에도 세션은 결코 올바른 단위가 아니었다'는 점에 동의합니다.

다만 이 글이 저희보다 더 나아간 부분은 컨텍스트가 역할과 함께 존재해야 한다고 결론짓는 점입니다. 기록에 대해서는 그것이 맞고 타당한 주장입니다. 하지만 모든 역할이 필요로 하는 사실 정보에 대해서는, 하나의 공유된 문제를 Bot당 하나의 문제로 변질시킵니다. 기록의 범위는 SpaceXAI가 설계한 대로 제한하십시오. 그리고 사실 정보는 어떤 Bot도 소유하지 않는 곳에 두십시오.