도구를 통합하면 안 되는 이유 — 컨텍스트 척추라는 아이디어

기획→개발→배포 핸드오프마다 맥락이 증발하는 문제, 해결책은 도구 통합이 아니었다

문제: 이음매마다 세금이 붙는다

제가 마이위키를 만들면서 좀 이상한 걸 느꼈습니다. B12 세션, Organize 파이프라인을 작업하던 날이었는데요 — 이전 세션에서 Claude랑 같이 정한 빌드 플랜 내용을, 새 세션에서 처음부터 다시 설명하고 있는 제 자신을 발견했어요.

“우리 지난번에 이렇게 하기로 했잖아”가 통하지 않는 겁니다. 모델은 기억이 없고, 저는 또 그 결정의 맥락을 전부 재조립해서 넘겨줘야 하는 상황. 이게 한두 번이 아니었어요. 기획 채팅에서 정한 것이 IDE에선 사라져 있고, 배포 단계에서는 왜 이 구조로 짰는지를 다시 설명해야 합니다.

저는 이걸 핸드오프 세금이라고 부르게 됐어요. 도구 사이를 넘어갈 때마다 재설명 비용이 붙는 것.

진단: 도구가 아니라 이음매가 문제다

처음 드는 생각은 “그러면 도구를 통합하자”입니다. 기획도 코딩도 배포도 한 곳에서. 그런데 이게 틀린 접근이에요.

Figma는 Figma대로, IDE는 IDE대로, 각자 best-in-class 이유가 있어서 거기 있는 겁니다. 이걸 하나로 합치려면 각각이 가진 깊이를 포기해야 해요. 그리고 솔직히 말해서, 그 도구들을 다 대체할 만한 걸 혼자 만드는 건 가능하지도 않고요.

문제는 도구가 아니라 도구 사이의 이음매였습니다. 기획 채팅과 코딩 세션 사이, 코딩 세션과 배포 사이. 거기서 컨텍스트가 빠져나가고 있었던 거예요.

그러면 도구를 대체하는 게 아니라, 이음매에서 증발하는 컨텍스트만 꿰면 되지 않을까요?

접근법: Atlas — 척추만 짓는다

이게 Atlas라는 구상의 시작점입니다. 구조는 단순해요:

• app-creator: 기획, 요구사항, 디자인 — “뭘, 왜 만드는가”
• app-builder: 구현, build-plan 실행 — “어떻게 만드는가”
• app-publisher: 배포 — “어떻게 내보내는가”
• Atlas: 위 셋을 꿰는 컨텍스트 척추

Atlas가 실제 작업을 하는 게 아닙니다. 각 단계에서 어떤 결정이 내려졌는지, 왜 그 결정을 했는지, 다음 단계에서 알아야 할 게 무엇인지를 나르는 역할이에요. 뼈대가 팔다리를 움직이는 게 아니라 잡아주는 것처럼.

이름도 거기서 왔습니다. Atlas — 하늘을 떠받치는 거인이면서, 동시에 지도책(색인)이기도 한. 하중을 지는 척추이자 지식의 색인.

왜 작동하나: 에스컬레이션의 논리

이 구조에서 중요한 건 무엇을 사람한테 올리고 무엇을 AI가 알아서 처리하느냐입니다. 특히 비개발자가 쓴다고 생각하면 이게 더 중요해져요.

제가 실제로 Claude Code 작업하면서 깨달은 게 있는데, **에스컬레이션의 기준은 “중요도”가 아니라 “사용자가 주인인 결정”**이어야 한다는 겁니다.

기술적으로 복잡한 것이라도 AI가 잘 알면 AI가 결정하면 됩니다. 하지만 비용이 두 배 늘어난다거나, 이 방향으로 가면 나중에 바꾸기 어렵다거나 — 이런 건 기술 판단이 아니라 사용자의 의도와 우선순위에 달린 문제예요. 그건 올려야 합니다.

그런데 올릴 때도 “MikroORM v6 vs v7 API 계약 드리프트” 이렇게 올리면 안 되고, “느려도 싸게 갈 건지, 빠른데 비싸게 갈 건지” 이렇게 번역해서 올려야 해요. 결과의 언어로.

실증 사례도 있었어요. auto 모드로 돌리고 있었는데 MikroORM 버전 업그레이드 과정에서 계약 드리프트가 에스컬레이션됐습니다. auto가 “안 물어본다”가 아니라 “계획을 보여주지 않는다”는 거였어요. 사용자가 주인인 결정은 모드를 뚫고 올라오는 거라는 걸 그때 직접 확인했습니다.

재귀: 척추를 척추로 짓는다

제가 이 구상에서 제일 흥미롭게 본 건 재귀 구조입니다.

Atlas는 “사람은 방향을, AI는 실행을” 분담해서 혼자도 큰 걸 만들 수 있게 하는 척추입니다. 그런데 Atlas를 만드는 방법이 정확히 그겁니다. 저 혼자 build-plan으로 빌드하고, 에스컬레이션 결정만 직접 내리면서 진행하는 것.

척추를 척추로 짓는다. 만드는 과정이 곧 제품의 데모가 되는 거예요.

현재 제가 이미 두 조각을 가지고 있어요. 마이위키가 지식 척추로 작동 중이고, build-plan이 builder로 작동 중입니다. 다음은 가장 아픈 이음매 하나를 고르는 것.

지금 해볼 수 있는 것

다음 프로젝트에서 기획과 코딩 사이에 “재설명 세금”이 얼마나 붙는지 한번 측정해보세요. “이 결정 왜 했더라”를 설명하는 데 걸리는 시간, 이전 세션 컨텍스트를 복구하는 데 드는 메시지 수. 그게 Atlas가 겨냥하는 문제입니다.

도구를 바꿀 필요 없어요. 이음매만 꿰면 됩니다.

배경: 기획 AI 개발 AI가 따로 노는 게 답답해서 컨텍스트를 연결했다 · 나만의 세컨드브레인 설계 결정 방법: build-plan 스킬로 개발 시간 단축하기 심화: 에이전트가 내 말을 안 듣는다면 — 4레버 방법론 함께 보기: 마이위키가 탄생한 이유

변경 요약: 본문에 비개발자-자연어-개발-가이드·claude-code-4레버-방법론 인라인 링크 2개 추가, 하단 관련 글을 배경/방법/심화/함께 보기 레이블로 정비