이전 글에서 이어집니다.
지난 글에서 AI의 책상은 좁고, 대화가 끝나면 치워진다는 이야기를 했습니다. 그래서 모든 걸 한꺼번에 올려두는 대신, 필요한 것만 적시에 꺼내 쓰는 구조로 바꾸기로 했다고요.
이번에는 제가 사용하고 있는 구조에 대해서 구체적으로 이야기해보겠습니다.
처음에는 이전 글처럼 비유와 상징 위주로 가볍게 작성했었는데, 영양가가 없는 것 같더라구요.
Claude Code를 본격적으로 사용하시는 분들도 많이 계시는 것 같아서, 조금이나마 도움이 될까 하는 생각에 어느정도 실제 적용하는 기술적 내용도 덧붙였습니다.
Claude Code와 그 확장 시스템을 조합해서 사용하면 아래와 유사한 구조를 가지게 되는데요.
이 중에서 Context 관리에 필요한 구성요소들에 대해 이야기하고자 합니다.
주인이 깨워서 눈을 떠보니 주위엔 아무것도 없고, 눈앞엔 지도 한장 놓여있었다.
Claude Code에는 CLAUDE.md라는 파일이 있습니다.
이 친구가 새 대화를 시작할 때 무조건 가장 먼저 읽는 파일입니다.
텅 빈 책상 위에 가장 먼저 놓여지는 문서인 것이죠.
저는 여기에는 자세한 내용을 적지 않습니다. 대신 지도를 그려놨습니다.
이 프로젝트가 뭔지 (프로젝트 구조, 기술 스택, 빌드 방법)
절대 하면 안 되는 것들 (핵심 규칙)
어떤 규칙들이 있고, 그 규칙이 어디에 적혀 있는지 (규칙 파일 경로 목록)
어떤 도구와 명령어를 쓸 수 있는지 (스킬, 에이전트 목록)
OpenAI 엔지니어들의 말처럼 1000페이지 매뉴얼을 그대로 올리면 책상이 바로 꽉 차겠죠. 지도 한 장이면, 필요할 때 해당 챕터를 찾아가서 읽으면 됩니다.
여기서 중요한건 '핵심 규칙’인데요.
지도에 적힌 내용은 매 세션마다 항상 Context Window에 올라가기 때문에, 절대 잊어버리면 안 되는 가장 중요한 것들만 지도 자체에 직접 적어둡니다.
예를 들어 “동료나 외부에 노출되는 시스템(업무관리/협업 도구, 위키 등)에 뭔가를 쓰는 건 반드시 내 허락을 받고 해” 이 규칙은 별도 파일이 아닌 지도에 직접 박아뒀습니다. 이러면 대화가 아무리 길어져도, 압축이 일어나도, 이 규칙은 살아남습니다.
이전 글의 OpenClaw 사건에서 "확인 후 실행하라"는 지시가 대화 속에만 있었기 때문에 압축 과정에서 사라진 거잖아요. 가장 중요한 규칙은 대화가 아닌, 매 세션마다 자동으로 로딩되는 파일에 적어둬야 합니다.
지도에는 이렇게 적혀있었다. “필요한 규칙은 전부 서랍에 있어"
지도에는 상세 규칙에 대한 경로가 작성되어 있고, 실제 규칙들은 rules/ 폴더 아래에 주제별로 분류되어 있습니다. 서랍장처럼요.
현재 저는 세 종류의 서랍에서 각 Task에 맞게 실행되는 수십개의 규칙 문서를 관리하고 있습니다.
첫 번째 서랍 — rules/workflow/
업무를 어떤 순서로 처리하는지에 대한 규칙입니다. 회사에 신입이 왔을 때 "우리 팀은 이렇게 일해"라고 알려주는 온보딩 문서와 비슷합니다.
구체적으로는 이런 내용들이 들어 있습니다.
작업 파이프라인 : 요구사항 분석 → 계획 수립 → 코드 작성 → 검증 → 발행. 각 단계에서 어떤 산출물을 만들어야 하는지, 다음 단계로 넘어가려면 뭘 확인해야 하는지.
작업 공간 전략 : 코드를 수정할 때 어떤 이름으로 별도 작업 공간(브랜치)를 만들고, 완료 후 어떻게 병합하는지.
코드 변경 이력 관리 : 코드 변경 이력을 남길 때 메시지를 어떤 형식으로 작성하는지.
문서 관리 정책 : 작업 관련 문서를 어디에, 어떤 구조로 저장하는지.
규칙을 파일로 명문화 할수록 AI가 제멋대로 일할 가능성이 줄어듭니다.
갑자기 메시지 작성 언어가 바뀐다던지, 문서 템플릿이 매일매일 달라진다던지 하는 일이 사라지죠.
두 번째 서랍 — rules/code-quality/
코드를 작성할 때 지켜야 하는 기준입니다.
코딩 스타일: 변수 이름 규칙, 불변 객체 우선 사용, 값이 없는 경우의 안전성 처리 방법 등.
보안 체크리스트: 사용자 입력 검증, 서버 호출에 사용되는 인증키, 암호화 처리 등.
테스트 가이드: 어떤 종류의 테스트를 작성해야 하는지, 테스트가 서비스 전체 기능의 어느정도를 커버해야 하는지.
코드 검증 방법: 빌드 해보고 디버깅 도구를 통해 결과물을 확인하는 프로세스.
이 서랍이 필요한 이유는 코드를 ‘잘’ 작성하는 것과 우리 '팀에 맞는’ 코드를 작성하는 것은 다르기 때문입니다.
AI는 일반적으로 좋은 코드를 작성하지만, 팀의 코드 작성 규칙이나 스타일 패턴까지 알지는 못하거든요.
세 번째 서랍 — rules/tools/
업무에 사용하는 외부 시스템들의 사용 규칙입니다.
제가 ...
