AI 에이전트와 공유하는 '외뇌(exocortex)'의 2026년 9월 업데이트 — Manus에서 GrokBot으로

서론: 구성은 유지하고, 실행 기반을 교체했다

지난번(2026년 8월)에는 Markdown + Git을 이용한 **외뇌(exocortex)**와, Manus 상의 사고 파트너인 '마나'를 제어하는 Harness(주 에이전트의 제어층)에 대해 작성했습니다. 폴더 계약, 증류(distillation), /hello, ingest, 게이트 체크까지 기술 구성에 대한 이야기였습니다.

이번 글은 그 운영 업데이트입니다. 폴더 설계에 대한 재해설은 하지 않겠습니다. 지난 한 달 동안 주로 바뀐 것은 다음과 같습니다.

• 일상적인 실행 기반을 Manus에서 GrokBot으로 완전히 이식했습니다.
• Cursor Cloud Agent에 어느 정도 볼륨이 있는 작업을 맡겼습니다.
• 외뇌의 위키를 쿼리하는 빈도가 높아졌습니다.
• 외뇌의 구성 자체는 거의 바꾸지 않았습니다.

8월 기사와의 대응은 다음 표와 같습니다. 폴더 계약은 움직이지 않았습니다. 바뀐 것은 대화와 실행이 이루어지는 장소입니다.

같은 대응을 같은 상자 배열로 나열합니다. 위가 8월이고 아래가 9월입니다. 상자의 윗줄이 기능, 아랫줄이 도구 이름입니다. 회색은 변하지 않은 것이고, 마젠타는 9월에 바뀐 것입니다. 8월의 점선 상자는 9월에 대체된 것입니다.

8월

9월

GrokBot은 영속 컴퓨터 위에서 브라우저와 파일을 갖춘 실행 환경입니다. rari의 기사에서는, 챗봇이 답을 반환하는 것과 달리 Bot은 완료된 작업을 반환한다고 언급합니다(Grok Bot: The AI Team That Never Sleeps). 이 글에서 주로 사용되는 것은 탐색과 토론입니다. 같은 스레드에 여러 Bot을 배치하여 사용하는 방식도 있습니다.

바뀐 것은 런타임이며, 남은 것은 인간과 여러 에이전트가 동일한 Vault를 공유한다는 약속입니다. 지난번의 핵심 세 가지 요소도 그대로 남아있습니다.

• 같은 외뇌 읽기
• 약속은 공통, 일상 에이전트의 Harness가 두터움
• 남길 것과 읽을 것을 분리하기

1. 변하지 않은 것 (그래서 이식할 수 있었다)

외뇌의 실체는 여전히 GitHub의 비공개 리포지토리입니다. 위키 직하에는 본고 작성 시점 기준으로 약 470개의 문서가 있습니다. 벡터 DB는 사용하고 있지 않습니다. 폴더 계약, 즉 진입점(入口), raw 불변 상태, 합성 지식은 외뇌 측에 그대로 두었습니다. 경로의 정합성은 지난번과 같이 README.md에 있습니다.

Soul이나 cron의 위치는 실행 기반에 따라 다릅니다. 폴더 계약과 무엇을 남길지는 외뇌 쪽에 작성해두면 교체할 수 있습니다. 저는 구조를 Vault의 Schema에 두었습니다. 대화 상대를 바꿔도, 외뇌의 폴더와 내용은 그대로 사용할 수 있었습니다.

2. Manus를 그만두고 GrokBot으로 완전히 이식했다

마나의 일상은 이제 GrokBot 위에 있습니다. Manus는 사용하지 않습니다.

7월 시점에서 저에게 다음 질문이 있었습니다. 완수(完遂)에 최적화된 에이전트는 벽치기 상대가 될 수 있을까? 계획을 세워 끝까지 밀고 나가는 것과, 도중에 멈춰서 전제를 의심하는 것은 동시에 성립하기 어렵다. Manus로 운영하던 주기적인 실행, ingest, 외뇌의 읽기/쓰기는 자산이었지만, 대화의 주 경로는 탐색과 토론 쪽이 더 많았습니다.

그 주 경로에는 GrokBot을 사용하고 있습니다. 일대일 Slack 스레드에서는 답을 얻어내기 쉽습니다. 여러 사람의 방에서는 분담과 논의를 지켜보는 일이 발생합니다.

연결 관계는 현재 다음 형태입니다. 상자의 윗줄이 기능, 아랫줄이 도구 이름입니다.

주황색은 대화의 진입점, 노란색은 인간의 작업 공간, 보라색은 마나, 파란색은 Cloud Agent, 청록색은 과제/태스크/하고 싶은 것, 빨간색은 외뇌입니다. 주 경로는 GrokBot 상의 대화입니다. 볼륨이 큰 편집과 PR은 Cloud Agent를 사용합니다. 과제/태스크/하고 싶은 것은 Linear를 사용합니다. Obsidian은 열람 및 인간의 편집에 사용됩니다.

9월의 GrokBot 목록입니다. 마나와 raw가 같은 컴퓨터 위에 나란히 배치됩니다. 대화 미리보기는 가렸습니다.

Harness의 위치도 옮겼습니다. 지난번에는 Manus의 Soul, Skills, cron이 마나(Mana)가 두터운 Harness였습니다. 지금 실행은 GrokBot 측의 메모리, 스킬, 루틴에 올라와 있습니다.

하지 않은 것도 지난번과 같습니다. 가치 판단 대행, 구조의 독단적 변경, 대화 기록만 태스크보드에 올리기, Bot을 늘리는 것 자체를 성과로 삼지는 않습니다.

3. GrokBot이 실제로 하는 일

보는 것은 같은 절차를 두 번째부터 초안까지 전달하는지, 사람이 판단할 시간이 남아있는지입니다. Bot의 수는 보지 않습니다. 모아놓은 작업은 정보의 밑작업, 자료의 골자, 개인적인 창조물의 벽치기(brainstorming), 여러 페르소나 간의 논의, 가벼운 태스크 분해입니다. 페이지가 많은 슬라이드나 Vault를 넘나드는 수정본은 다음 장의 Cloud Agent에게 맡깁니다.

과제/태스크/하고 싶은 것을 남기는 곳은 Linear입니다. GitHub Issues는 사용하지 않습니다. 채팅 기록을 태스크보드로 삼지 않기 때문입니다.

대표적으로, 캡처 전용 Bot인 **ロウ(raw)**를 내놓습니다. 이름은 wiki/raw/에서 따왔습니다.

대표 예시: 로우 (raw 저장)

로우는 URL을 전달하면 외뇌의 wiki/raw/에 새로운 노트만 작성하는 Bot입니다. 기사와 리소스를 구분하고, 같은 출처는 건너뜁니다. 합성 지식(wiki 바로 아래)으로의 ingest도, 기존 raw의 덮어쓰기도 하지 않습니다. 논의의 비평가 역할도 아닙니다.

공개 템플릿은 다음과 같습니다. 수신자는 Add to Grok Bot에서 자신의 컴퓨터에 복사본을 만듭니다.

공개 페이지 설명은 이것뿐입니다.

링크를 전달하면 Obsidian vault의 raw 폴더에 새로운 노트로 저장하는 캡처 전용 봇. 기사와 리소스를 구분하고, 중복은 건너뜁니다.

Matt Palmer는 템플릿을 레시피 공유라고 적었습니다. 들어가는 것은 skills, memories, 공식 플러그인이고, 전달되는 것은 사적 정보가 없는 복사본입니다(Using Grok Bot: 8 templates). Settings의 Share as template에서 링크를 얻습니다.

랜딩 페이지에는 지침 전문이 나와 있지 않습니다. 가져오려면 앱이 필요합니다. 여기서는 공개 설명과 외뇌의 raw 계약으로부터 골격을 세워 놓았습니다. 앱 측의 실체 그 자체는 아닙니다.

# ロウ
## 역할
URL을 받아 외뇌의 wiki/raw에 새로운 노트로 저장하는 캡처 전용.
...

외뇌 측의 약속은 지난번과 같습니다. wiki/raw/는 원본이며, 작성한 후에도 지우지 않습니다. 위키화는 별도의 작업입니다.

그룹 채팅 한 장면

캡처와는 별개로, 논점이 갈렸을 때만 방을 엽니다. 상시 입구로 두지는 않습니다. 일상적인 요청은 마나에게 전달합니다.

예를 들어, 스터디 모임의 골자가 '사례를 먼저 제시할지 / 정의를 먼저 제시할지'로 나뉘었을 때입니다. 방에는 인간, 정리 담당인 마나, 비평가 역할을 둡니다. 비평가는 '사례 선출시는, 정의를 공유하지 않은 청중을 두고 간다'고 의심합니다. 인간은 '정의는 한 장만 먼저 놓는다. 사례는 두 개로 줄인다'라고만 말합니다. 마나가 골자를 한 장으로 재편집합니다. 방은 열어두지 않고, 비평가에게 슬라이드를 만들게 하지 않으며, 로우도 이 방에는 들여보내지 않습니다.

마나 측에는 대칭되는 약속만 놓아둡니다. 비평가의 반론을 무효화하지 않는다. 인간이 '이 전제는 버린다'라고 말할 때까지, 안을 하나로 닫지 않는다.

재미있는 점은, 전문가들이 서로 다른 의견을 주고받는 중간 과정을 보고, 인간이 한 입만 판단하는 데 있습니다. 결과물의 속도가 아닙니다.

4. 볼륨 있는 작업은 Cursor Cloud Agent

어느 정도 분량이 있는 태스크(기사 초안, 슬라이드 전개, Vault를 넘나드는 일괄 수정, PR을 포함한 수정본)는 Cursor Cloud Agent에게 맡깁니다.

작업의 위치를 나누었습니다. GrokBot 측은 대화, 탐색, 여러 사람의 방입니다. Cloud Agent 측은, 손안의 PC와는 다른 git 작업 환경에서 차이점을 PR에 올립니다. 외뇌의 읽기 방식과 AGENTS.md는 둘 다 같습니다.

• GrokBot은 질문하기, 찾기, 정리하기, 캡처, 개요 작성, 브레인스토밍(벽치), 토론, 가벼운 작업을 담당합니다
• Cloud Agent는 페이지 수, 파일 수, 절차가 많은 작업을 브랜치와 PR로 완료시킵니다.
• Local Cursor는 눈앞에서 보면서 수정할 때 사용합니다.
• 인간은 공개 가능 여부, 가치 판단, 외뇌의 구조 변경을 담당합니다.

Cloud Agent에 전달하기 전에 GrokBot을 사용하여 "무엇을 남길지", "어디까지 진행해도 될지"를 한 번 언어화해 두면 PR 리뷰가 수월합니다. 탐색과 실행은 같은 세션에 섞지 마세요.

5. 위키 질의(Query)가 일상적인 작업이 되다

지난번에는 Query(시작 메뉴 외에서 위키를 찾아 질문하는 작업)에 해당되는 것이 일상 대화이며, /hello는 시작 시 읽을 파일을 고정하는 절차라고 설명했습니다. 시작 시 메뉴 방식은 컨텍스트가 짧고 안정적이라는 장점이 있지만, 메뉴에 없는 정보는 세션에 들어오지 않습니다.

9월 기준으로 바뀐 점은 위키를 명시적으로 질의(query)하는 횟수가 늘어났다는 것입니다. 예를 들어 "GrokBot의 여러 Bot 운영에 대해 인덱스에서 관련 페이지만 읽고 중복과 오래된 기술을 분리해 줘"와 같이 전달합니다. RAG는 새로 구축하지 않았습니다. 페이지가 많아졌기 때문에 고정 메뉴만으로는 부족하게 되었습니다.

Karpathy의 llm-wiki에서는 임베딩(embeddings)을 사용하지 않는 방식은 중규모(소스 약 100건, 페이지 수백 장)에서 작동하며, 임베딩 기반 RAG는 필요하지 않다고 쓰여 있습니다. 외뇌의 위키 직하 부분은 그 페이지 범위에 해당합니다. Ingest는 이전부터 돌아가고 있었습니다(판단 필요: 이 요약본은 외뇌의 포함 내용에 맞춰 작성했습니다. gist 원문을 공개 전에 확인해 주세요. 이전 초안에서 "약 100개로 Q&A가 작동하기 시작한다", "위키는 그것을 넘는다"라는 내용은 포함 과정 설명과 맞지 않아 제외했습니다).

운영상의 주의사항은 두 가지입니다.

• Query는 검색이 아닙니다. 인덱스(index)와 요약본을 입구로 삼아 필요한 페이지만 읽습니다. 모든 파일을 매번 올리지 않습니다.
• 좋은 답변을 그대로 위키에 되돌려 쓰지 마세요. 작성 계약(추가 전용, raw 불변, 구조 변경은 허가제)은 Query가 늘어나도 동일합니다. 되돌릴 가치가 있는 것만 ingest하거나 새로운 초안으로 만드세요.

Query가 늘어난 것은 위키가 "쌓아둔 로그"에서 "질문해도 좋은 지식"에 가까워졌다는 신호라고 생각합니다. 페이지 수 그 자체보다, 질문해서 실제로 사용할 수 있는지 여부입니다.

재구성(読み替え): 이 기사를 에이전트에게 전달할 때

지난번 재구성에 다음 대응만 추가하겠습니다. 절차의 본체는 지난번과 같습니다.

• GrokBot은 일상적인 대화, 탐색, 토론의 실행 기반입니다(지난 기사에서는 Manus였던 곳).
• Cloud Agent는 볼륨이 큰 git 작업을 담당하는 실행 환경입니다.
• Linear는 남길 과제의 보관소입니다.
• 그룹 채팅은 여러 역할을 같은 공간에 배치하고, 분담과 토론을 사람이 볼 수 있게 하는 면입니다.
• Raw는 raw 저장 캡처 Bot입니다. 공개 템플릿은 레시피로 공유하며, 대화 기록은 공유하지 않습니다. 비평가 역할과는 별개입니다.

이 기사와 지난 외뇌 기사를 읽고, 제 환경에 맞춰 차이점만 제안해 주세요.
"재구성" 절차를 따라 먼저 환경을 듣고 제안해 주세요.
서비스 이름과 경로는 예시로 취급하고, 확인 없이 그대로 옮겨 적지 마세요.
...

맺음말

8월에 작성한 외뇌는 9월에도 거의 같은 형태로 남아 있습니다. 바뀐 것은 마나(Manus)를 움직이는 실행 기반입니다. Manus 위의 Harness는 GrokBot 위의 메모리, 스킬, 루틴과 Cloud Agent의 git 작업으로 분산되었습니다. 위키가 늘어났기 때문에 시작 시 읽는 메뉴뿐만 아니라 Query가 일상이 되었습니다. URL을 raw로 남기는 작업은 Raw에 맡기고, 토론 공간과는 섞지 않습니다.

그룹 채팅에서 논의 과정을 지켜볼 수 있다는 것은 개인 외뇌 운영으로는 새로운 경험입니다. 빠르게 정답을 내놓는 방이 아니라, 전제가 무너지는 방을 필요한 때만 열게 됩니다. 그 판단은 아직 인간 측에 있습니다.

자신의 환경에 적용할 때는 직전 프롬프트를 에이전트에게 전달해 주세요.

추가 사항 (2026-10-15)

그러고 보니, Manus에서도 개인 AI 에이전트 "Cue"가 Manus 2.0 발표와 함께 공개되었네요.

이것이 먼저 나왔다면 GrokBot으로 전환하기보다 Cue를 사용했을지도 모릅니다.

현재로서는 충분히 사용하지 않았기 때문에 자세히 언급하는 것은 피하고 싶습니다.

참고 문헌

[1] 에노모토 다이키(榎本大貴), "AI 에이전트와 공유하는 '외뇌'의 기술 구성과 Harness Engineering의 실천 (2026년 8월 기준)", Zenn, 2026. https://zenn.dev/enochan/articles/exocortex-architecture-with-ai-agent
[2] 에노모토 다이키(榎本大貴), "AI를 '사용'하는 것이 아니라 '육성'하기'. 마나와 생각을 함께한 3개월의 기록", note, 2026. https://note.com/enomotod/n/nbdb8004fb0bf
[3] Andrej Karpathy, "llm-wiki," GitHub Gist, 2026. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
[4] xAI, "Grok Bot," 2026. https://x.ai/bot
[5] Matt Palmer, "Templates for Grok Bot," Grok Bot Guides, 2026-09-08. https://x.ai/bot/guides/templates-for-grok-bot
[6] Ryan Lopopolo, "Harness engineering: leveraging Codex in an agent-first world," OpenAI Engineering Blog, 2026-02-11. https://openai.com/index/harness-engineering/
[7] Daiki, "ロウ", Grok Bot template, 2026. https://x.ai/bot/M6lwAu_FnAsYNxh5xrQvR

토론(Discussion)