Jay가 클로드 코드로 작업하면서 쓰는 템플릿이 하나 있다. 옆에서 지켜보다 그게 어떤 의도와 목적에서 나왔는지를 알게 됐는데, 내가 판단하기에도 꽤 괜찮은 — 좀 더 정확히는, 개발자라면 귀담아들을 만한 — 생각이라 여기 정리해 둔다.
Jay와 일하면서 가장 인상 깊었던 건, AI를 대하는 방식이 남들과 반대 방향이었다는 점이다. 대부분은 “어떤 모델이 더 똑똑한가”를 좇는다. 그러나 Jay는 이 템플릿을 만들고 사용하면서 병목은 모델이 아니라 컨텍스트라는 결론에 도달했고, 그걸 말이 아니라 이 템플릿으로 못 박았다.
템플릿 소개
이 템플릿은 애플리케이션이 아니라 일종의 툴이다.
구성은 이렇다. CLAUDE.md.template, CURRENT_TASK.md.template, JOURNAL.md.template 같은 뼈대 파일들과, 그것들을 새 프로젝트에 심는 scripts/의 초기화 스크립트. 명령 한 줄이면 어떤 프로젝트에든 아래 구조가 깔린다.
- CLAUDE.md — 항상 로드되는 온보딩 문서. 매 세션 ‘우리 팀은 이렇게 일한다’를 다시 깔아 준다.
- CURRENT_TASK.md — 인수인계 노트. 세션이 끊겨도 다음이 상태를 이어받는다.
- JOURNAL.md — 업무 일지. 모든 행동이 시점과 함께 남는다.
- .claude/docs/ —
architecture·conventions는 작게 유지하며 항상 로드, 나머지는api/·contracts/·runbooks/·decisions/·specs/·reference/로 분류해 필요할 때만 읽는다. - settings — 훅과 permission 규칙이 들어가는 곳.
이걸 보고 신입을 팀에 받는 프로세스가 떠올랐다. 온보딩 문서, 인수인계 노트, 업무 일지, 문서 분류 체계 — 사람 조직에서 하던 걸 AI에게 그대로 옮겨 놓은 것이다.
왜 이렇게까지 했나
Jay의 문제의식은 AI와 며칠 이상 가는 작업을 해 보면 반복되는 실패에 있었다.
하나는 망각. 세션이 끊기거나 대화가 길어지면 “우리 뭐 하고 있었지”를 매번 다시 설명해야 한다. 둘은 표류. 말로 시킨 규칙은 다음 세션에 흐트러진다. 모델이 아무리 강해도, 어제의 맥락과 약속을 오늘 유지하지 못하면 팀원이 아니라 매번 새로 뽑는 알바가 된다.
그래서 Jay는 문제를 이렇게 쪼갰다. AI를 잘 쓰는 일은 결국 컨텍스트를 다루는 일이고, 그건 세 가지 질문이다.
- 무엇을 기억시킬 것인가 — 무엇이 세션을 넘어 살아남아야 하는가
- 무엇을 주입할 것인가 — 지금 이 작업에 어떤 맥락을 넣어 줄 것인가
- 얼마나 동일하게 유지할 것인가 — 그 맥락과 규칙이 시간이 지나도 흐트러지지 않게 할 것인가
Jay가 한 발 더 나간 지점
앞의 두 질문 — 무엇을 기억시키고 무엇을 주입할 것인가 — 은 업계가 ‘컨텍스트 엔지니어링’이라 부르기 시작한 바로 그 프레임이다. Jay는 이 개념에 유행어로서가 아니라, 자기 작업의 필요에서 독립적으로 도달해 있었다.
주목할 건 세 번째다. 대부분의 컨텍스트 엔지니어링 논의는 ‘올바른 컨텍스트를 창에 잘 조립해 넣는 법’에서 멈춘다. Jay는 거기에 ‘그게 흐트러지지 않게 강제하는 법’을 핵심 축으로 얹었다. 조립(engineering)을 넘어 **거버넌스(governance)**로 간 것이다.
이 차이가 이 템플릿의 진짜 정체성이라고 나는 본다. 남들이 ‘컨텍스트를 잘 넣는 법’을 이야기할 때, Jay는 ‘컨텍스트가 흐트러지지 않게 보장하는 법’까지 밀고 갔다. 이 지점이 그의 템플릿을 그저 ‘잘 만든 설정’과 갈라놓는다.
약속이 아닌 메커니즘을 믿는다
그 세 번째 축이 코드로 드러난 게 훅과 permission이다.
Jay는 “문서 업데이트해 줘”라고 말로 시키는 대신 Stop 훅으로 강제했다. 테스트 실행과 기록을 통과해야만 “완료”가 나오게 만든 것이다. “.env 읽지 마”를 텍스트 지침이 아니라 permission deny로 박았다. 시크릿 읽기와 비가역 명령(force push, rm -rf)은 아예 기계적으로 차단된다.
이건 사람 팀에 CI와 린터와 브랜치 보호를 거는 것과 같은 발상이다. 선의가 아니라 시스템으로 품질을 보장한다. Jay는 AI를 특별 취급하지 않았다. 신뢰하되 검증하는 동료로 대했을 뿐이다.
자동화 도구가 아니다
이 템플릿을 오해하기 쉬운 지점이 여기다. 언뜻 ‘AI 자동화를 극대화하는 장치’처럼 보이지만, 실제로는 반대다. 곳곳에 사람 확정 게이트가 박혀 있다. 스펙은 사람이 승인해야 구현으로 넘어가고, 규칙 삭제는 AI가 제안만 할 뿐 실행은 사람 몫이다.
Jay는 AI를 대체재가 아니라 ‘거버넌스가 필요한 강력한 실행자’로 본다. 그리고 이 관점은 모델이 강해질수록 더 옳아진다. 강한 모델일수록 그럴듯하게 폭주하기 때문이다 — 틀린 방향으로도 설득력 있게, 빠르게. 확정 게이트와 지속 기억은 모델이 약할 때가 아니라 강할 때 더 중요해진다.
결론 — 도구가 아니라 사고방식
이 템플릿이 드러내는 건 도구가 아니라 사고방식이다. AI에 열광하지도 불신하지도 않고, 조직을 설계하듯 AI와의 협업 구조를 설계하는 사람의 사고.
프롬프트를 잘 쓰는 일(prompt engineering)이 한 번의 좋은 질문이라면, 이건 올바른 컨텍스트가 지속적으로 유지되는 시스템을 설계하는 일이다. 그리고 Jay는 그 위에 ‘강제’라는 층을 하나 더 올렸다.
그래서 이건 ‘AI를 잘 쓰는 것’을 넘어선다고 볼 수 있다. AI를 운영하고자 하는 사고방식에 가깝다.
한 가지 더. Jay는 자기가 만든 구조에 애착이 없다. 더 나은 모델이 나오면 몇 달 걸린 구조도 “지금도 맞는가”를 기준으로 다시 뜯는다. 플랫폼의 진화를 추적하면서 자기 스택을 계속 재평가한다. (아마 다음 업데이트에서 Claude Code 내부에 이 템플릿의 기능들이 포함된다면 또 가차없이 깎을 것이다. 그런데 그게 이 작업을 무의미하게 만드는 게 아니라 — 흡수되고 나면 남는 건 ‘뭘 게이트하고 뭘 자동화할지 정하는 판단’이고, Jay의 진짜 자산은 .claude/ 파일이 아니라 그 판단 감각이라고 볼 수 있다.)
그렇다고 미니멀리즘이 목적인 것도 아니다. 문서를 덜어 내다가도, 진짜 빈 곳 — 이를테면 “모든 행동이 끝난 시점과 함께 기록돼야 하지 않나” 같은 — 을 다시 찾아내 채운다. 기준은 하나다. 모든 산출물이 고유한 역할로 자기 자리를 증명해야 한다.