기획 AI, 개발 AI가 따로 노는 게 답답해서, 컨텍스트를 연결하기 시작했다
세컨드 브레인 시리즈 — EP3: 통합편
Claude Chat에서 기획하고, Claude Design으로 디자인하고, Claude Code로 개발하고, Hermes로 자동화한다. 각자 잘하는 게 달라서 이리저리 옮겨 다니는데, 옮길 때마다 설명을 다시 해야 한다. “이 프로젝트가 뭔지”, “지금까지 뭘 결정했는지”, “어디서 막혔는지” — 매번 처음부터 깔아야 한다.
어느 순간 이게 내 에너지를 제일 많이 먹고 있다는 걸 알았다. 이름이 있으면 관리가 된다 싶어서 “재설명 세금”이라고 불렀다. LLM은 새 세션마다 처음 만나는 사람이라, 이게 정신없음의 정체였다.
도구를 통합하면 안 되는 이유
처음 든 생각은 단순했다. “챗도 되고 코딩도 되고 자동화도 되는 올인원을 쓰면 되지 않나.” 그런데 해보니 그게 함정이었다. 챗은 챗이 잘하고, 코드 에디터는 코드 에디터가 잘한다. 억지로 합치면 둘 다 한 단계씩 떨어지는 짝퉁 두 개가 되는 통합할 건 도구가 아니라 그 사이를 흐르는 컨텍스트였다. 도구를 통합하면 안 되는 이유, 컨텍스트 척추가 필요한 이유를 정리해뒀다.
지식만 통합했는데 뻥 뚫렸다
세컨드 브레인에 CLI 세션들을 수집하기 시작했다. 직접적인 기대는 “나중에 찾아보자”였는데, 생각지 않은 효과가 있었다. 다음 세션이 “처음부터 설명”이 아니라 “어디까지 했지”로 시작됐다.
실제로 이런 표현을 쓴 적이 있다.
“기획은 챗에서 하고 디자인은 디자인에서 하고 코드는 코드에서 하고 그 컨텍스트가 다 따로 놀고 근데 또 거기가 젤 잘하니 안갈수도 없고 그러다 llm wiki를 알게 되고 지식만 통합되도 뭔가 뻥 뚫리더라고”
그게 정확한 표현이었다. 도구는 그대로인데, 그 사이를 꿰는 것 하나가 생기니까 맥락이 날아가지 않았다. 재설명 세금이 사라졌다.
척추 개념: 도구를 대체하지 말고 사이를 꿰라
이걸 개발 흐름 전체로 확장하면 어떨까. 기획(뭘·왜) → 구현(어떻게) → 배포(내보내기), 이 세 단계를 각자 잘하는 도구가 맡되, 그 사이에 컨텍스트만 나르는 척추가 있으면 된다.
second 브레인이 지식 통합으로 이미 작게 증명했다. 같은 방식을 빌드 체인 전체에 적용한 큰 버전을 구상 중이다. Atlas라는 이름을 붙여뒀다 — 무게를 떠받치는 거인이기도 하고, 지도책(색인/위키)이기도 한 이름이다. 재귀적이기도 하다. Atlas를 만드는 방법이 정확히 Atlas가 하려는 것이니까.
다음 세션이 달라진다
지금도 세션을 열 때 달라진 게 있다. Hermes와 Claude Code를 함께 쓰면서 “저번에 어디까지 했지?”라고 물으면, second 위키를 읽고 맥락을 가져온다. 내가 설명하지 않아도 된다.
다음에 AI랑 대화한 뒤, 그 내용을 어딘가에 ingest해보면 된다. 그 다음 세션의 첫 줄이 달라진다.
<- 이전 편: EP1·EP2 구축편 · 다음 편 ->: EP4 디스코드편 심화: 컨텍스트 척추 아이디어 · 방법: 세컨드브레인 자동화 · 함께 보기: 두 AI 역할 분담 · EP5 활용편 · EP6 앱편