서브에이전트의 한계에서 개인 지식 뇌 패턴을 발견하기까지

개인 프로젝트를 AI와 진행할수록 한 가지가 계속 걸렸다. 세션이 끝나면 그 안의 결정도, 삽질도, 오간 맥락도 전부 증발한다는 것. 다음 세션은 어제의 나를 모른 채 백지에서 다시 시작한다. 이 글은 그 증발 문제를 붙들고 “AI에게 사용자 역할을 대신 시키면 되지 않을까”를 바닥부터 검증했다가, 서브에이전트가 그 일에 맞지 않음을 확인하고, 방향을 틀어 개인 지식 뇌를 착상하고, 마지막에 직접 설계 대신 이미 검증된 패턴을 채택하기까지의 기록이다.

시작은 제품 공장이라는 욕심이었다

내가 그리던 그림은 소박하지 않았다. 여러 역할의 에이전트가 알아서 굴러가고 사람은 최종 검토만 하는 “제품 공장”이다.

여러 개의 역할이 각각 부여된 에이전트들이 트렌드랑 아이디어를 아침에 알림으로 알려주는 거야. 내가 OK 하면 자동으로 기획·검증·개발·테스트하고, 난 최종 검토만 하는 거지. 그다음엔 운영·마케팅 에이전트가 이어받아서 여러 제품을 빠르게 시장에 내는 거야. 허무맹랑할지 모르겠지만 난 가능하다고 믿어.

이 비전을 실현하려면 두 가지가 필요했다.

자율 실행 수단: 사람 대신 판단하고 다음 단계로 넘기는, 사용자 역할을 대신할 무언가.
축적되는 장소: 대화와 결정이 증발하지 않고 쌓여, 다음 작업을 더 똑똑하게 만드는 곳.

이 세션은 첫 번째를 서브에이전트로 풀 수 있는지 파고들다가, 두 번째의 필요를 선명하게 자각한 자리였다. 그 두 번째가 훗날 지식 뇌의 발원지가 된다.

서브에이전트에게 사용자를 대신 시킬 수 있을까

Claude Code의 서브에이전트부터 이해될 때까지 캐물었다. 결론부터 말하면, 판단이 필요한 연속 작업에는 부적합하다는 것이었다. 이유는 하나가 아니라 구조에서 나왔다.

한 번 쓰고 사라진다: 서브에이전트는 결과 텍스트 하나를 돌려주고 소멸하는 one-shot 구조다. 여러 작업을 연속으로 맡겨도 매번 처음부터다.
백지에서 시작한다: 메인 세션의 맥락을 모르고, 프롬프트로 넘긴 것만 본다.
판단을 자기 재량으로 해버린다: 사용자에게 물어야 할 중단점에서 서브에이전트가 대신 결정하면, “사용자 판단을 받는다”는 설계가 통째로 무력해지고 confirmation bias를 피하려던 장치가 무너진다.
재진입이 어색하다: 상위로 넘긴 뒤(escalate) 다시 이어받는 흐름이 매끄럽지 않다.

⇒ 사용자 역할 대행은 서브에이전트가 아니라 Headless Claude Code + 외부 오케스트레이터나 Claude Agent SDK 층의 일이다. SDK가 공식 지원이라 우선순위가 높다.

방향을 튼 지점 — 설계하는 곳과 만드는 곳

검증이 부적합으로 끝나자 두 번째 필요가 앞으로 나왔다. 대화·사고·비전이 증발하지 않고 사는 장소. 나는 그곳을 대장간이라 불렀다.

이때 하나를 분명히 갈랐다.

대장간: 시스템이 설계·결정되는 곳. 대화와 비전이 사는 개인 작전실. 여기서 정한다.
시스템 리포: 실제로 만드는 곳. 대장간에서 정한 것을 여기서 구현한다.

즉, 결정이 사는 곳과 구현이 사는 곳을 섞지 않는다. 이 경계가 흐려지면 각 리포의 정체성도 흐려진다.

직접 짜지 말고, 검증된 것 위에 얹어라

여기서 나 자신에게 건 규칙이 방향을 결정했다.

너가 알아서 짜지 말고, 유명한/각광받는/검증된 방식을 조사해서 그 위에 얹어.

그래서 개인 지식 관리(PKM) 방법론부터 훑었다.

Zettelkasten · Evergreen Notes: 원자 단위 노트를 링크로 엮어 지식을 키운다.
PARA (Building a Second Brain): 실행 가능성을 기준으로 정보를 네 범주로 정리한다.
ADR · MOC · Digital Garden: 결정 기록·지도 노트·공개 정원 등 목적별 변형.

대화 누적과 비전 진화형에는 Evergreen에 ADR·MOC를 얹은 조합이 근접했다. 그런데 이들 대부분은 사람이 손수 정리하는 것을 전제한다. 정리 부담이 그대로 남는다.

결국 채택한 것 — LLM Wiki 패턴

그 부담을 없애는 패턴이 2026년 들어 부상하고 있었다. Karpathy가 제안한 LLM Wiki 방식이다.

벡터 임베딩도, 검색 DB도 없다. 순수 마크다운만 쓴다.
LLM이 모든 입력을 정독해 요약 페이지를 쓰고, 사람·개념별 페이지를 만들고, 서로 크로스링크한다.
사용자는 대화와 메모만 던진다. 정리 부담이 0에 수렴한다.

비유하자면, 도서관에 책을 아무렇게나 반납해도 사서가 알아서 분류·색인·상호참조까지 해두는 구조다. 나는 던지기만 하고, 정리는 LLM이 맡는다. Obsidian과 Claude Code를 얹으면 그대로 굴러간다. 이것이 지금 지식 뇌의 씨앗이 됐다.

회고 — 발견의 순서가 남긴 것

돌아보면 이 세션의 가치는 특정 답이 아니라 순서에 있었다.

“AI에게 사용자 역할을 대신 시킨다”는 매력적인 아이디어였지만, one-shot·백지·소멸이라는 구조가 판단 연속 작업과 맞지 않았다. 자율 실행이 필요하면 오케스트레이터·SDK 층으로 올라가야 한다.
개인 지식 시스템을 처음부터 직접 설계하려 들지 않았다. 검증된 패턴 위에 얹는 편이 빠르고 안전하다.
LLM Wiki의 핵심 이득은 “정리 부담 0”이다. 벡터 DB 없이 plain markdown으로 된다.

이 씨앗이 실제 지식 뇌로 어떻게 자랐는지는 두뇌를 짓는 이야기에서 이어진다.