클로드 코드(Claude Code)를 만드는 앤트로픽 팀이 최신 세대 모델을 대상으로 시스템 프롬프트의 80% 이상을 걷어냈는데도 코딩 평가 지표에서 측정 가능한 성능 저하가 없었다고 밝혔다. 앤트로픽의 기술 스태프 타리크 시히파르가 정리한 이 글은 개별 프롬프트가 아니라, 시스템 프롬프트·스킬·CLAUDE.md·메모리 등 여러 출처에서 조립되는 '컨텍스트'를 어떻게 설계할지를 다룬다. 사용자가 매번 던지는 질문은 컨텍스트의 일부일 뿐이며, 나머지 대부분은 사전에 구성해 둔 일반적 지침에서 온다. 문제는 이 지침이 특정 요청에 맞춰 좁게 쓸 수 없다는 점이다. 사용자가 무엇을 물을지 모르는 상태에서 범용 안내문을 만들어야 하기 때문이다.
핵심 진단은 그동안 클로드 코드가 '과도하게 제약되어 있었다'는 것이다. 팀이 자체 사용 기록을 들여다보니 한 요청 안에서도 지침이 서로 충돌하고 있었다. 시스템 프롬프트는 '주석을 달지 말라'고 하는데 스킬이나 사용자 요청은 '적절히 문서화하라'고 말하는 식이다. 과거 모델은 이런 충돌 속에서 판단이 흔들렸기 때문에, 최악의 상황(예: 파일 삭제)을 막기 위해 다소 사실과 어긋나더라도 강한 규칙을 걸어 둘 수밖에 없었다. 그러나 판단력이 향상된 신세대 모델은 주변 맥락과 스스로의 판단으로 이런 결정을 잘 처리한다는 것이 팀의 결론이다.
규칙에서 판단으로
대표적인 사례가 주석에 대한 지침이다. 예전 시스템 프롬프트는 '기본적으로 주석을 쓰지 말고, 여러 문단짜리 독스트링이나 여러 줄 주석 블록을 절대 만들지 말라'고 못 박았다. 하지만 복잡한 코드의 특정 부분은 여러 줄 주석이 필요할 수 있고, 사용자마다 선호도 다르다. 새 시스템 프롬프트는 이를 '주변 코드처럼 읽히는 코드를 작성하라 — 주석 밀도, 명명, 관용을 맞추라'는 한 문장으로 바꿨다. 절대 규칙 대신 맥락에 맞춘 판단을 요구하는 방향이다.
도구 사용에 대한 통념도 뒤집혔다. 과거의 제1원칙은 '도구 사용법을 예시로 보여주라'였지만, 최신 모델에서는 오히려 예시가 탐색 공간을 좁혀 버린다는 것이 팀의 관찰이다. 예시를 채워 넣는 대신 도구·스크립트·파일의 설계 자체를 고민하라는 조언이다. 예컨대 할 일 관리 도구에서 상태 값을 pending·in_progress·completed라는 열거형으로 두는 것만으로도 모델은 사용 방식을 유추한다. 여기에 '동시에 하나만 in_progress로 두라'는 한 줄을 더하면 원하는 동작이 정의된다. 즉 장황한 예시보다 파라미터의 표현력이 더 중요하다.
점진적 공개라는 축
반복되는 또 하나의 열쇳말은 '점진적 공개(progressive disclosure)'다. 클로드 코드는 코드 리뷰와 검증 방법을 시스템 프롬프트에 상세히 담고 있었지만, 이는 항상 필요한 정보가 아니었다. 팀은 이를 별도 스킬로 분리해 필요할 때만 선택적으로 불러오도록 바꿨다. 도구에도 같은 원리를 적용해, 일부 도구는 ToolSearch로 정의를 검색해야 쓸 수 있는 '지연 로딩' 방식으로 두었다. 이렇게 하면 도구 수가 많아져도 실제로 쓰기 전까지는 컨텍스트를 차지하지 않는다. CLAUDE.md와 스킬 파일도 마찬가지다. 모든 관행을 한 파일에 몰아넣어야 한다는 생각은 오히려 통념에 가깝고, 적절한 시점에 로드되는 파일들의 트리 구조가 더 낫다는 것이다.
지침을 여러 곳에 중복해 두던 관행도 정리 대상이 됐다. 이전 모델은 컨텍스트 창의 앞쪽보다 뒤쪽 지시를 더 잘 따르는 경향이 있어, 같은 도구 설명을 시스템 프롬프트와 도구 설명 양쪽에 넣곤 했다. 이제는 이런 중복을 지우고 사용법을 도구 설명 안에 두는 것으로 충분하다. 메모리도 자동화됐다. 예전에는 # 단축키로 CLAUDE.md에 수동 저장하도록 권했지만, 지금은 작업과 사용자에게 관련된 내용을 클로드가 알아서 저장한다.
참조를 코드로 다루기
계획이나 명세를 단순 마크다운 파일로 저장하던 방식도 확장되고 있다. 모델이 더 복잡한 참조를 다룰 수 있게 되면서, 명세는 상세한 테스트 스위트가 될 수도 있고 다른 코드베이스에서 이식할 함수가 될 수도 있다. 좋은 API 설계란 무엇인가 같은 취향을 평가 기준(루브릭) 형태로 넘겨 검증 에이전트를 띄우는 방식도 제시된다. 글은 특히 '가능하면 코드 형태의 참조를 우선하라'고 강조하는데, 디자인을 말로 설명하거나 스크린샷을 주는 것보다 HTML 목업을 주는 편이 더 나은 결과를 낸다는 것이다. 코드는 모델이 매우 잘 아는 고충실도 언어이기 때문이다.
실무자 입장에서 정리하면 방향은 분명하다. 시스템 프롬프트는 제품 맥락에 강하게 묶이므로 자체 에이전트를 만들 때 공들일 부분이고, CLAUDE.md는 가볍게 유지하되 파일 시스템만 봐도 알 수 있는 뻔한 사실 대신 코드베이스의 함정(gotcha)에 토큰을 쓰라는 것이다. 반복되는 검증 절차는 스킬로 빼서 참조하고, 스킬은 팀이나 제품에 고유한 의견·지식을 담되 지나치게 제약하지 말라고 권한다. 다만 이 조언들은 판단력이 향상된 최신 세대 모델을 전제로 한다는 점, 그리고 자동 정리를 돕는다는 claude doctor(/doctor) 명령의 실제 효과는 각자의 환경에서 확인해 봐야 한다는 점은 감안할 필요가 있다. 규칙을 줄이는 것이 곧 방임은 아니며, 어디까지 모델의 판단에 맡길지를 팀이 다시 설계하는 작업에 가깝다.