📋 Claude 5 모델을 위한 새로운 컨텍스트 엔지니어링 규칙
10분만 이 글을 읽어보세요!
Opus 5, Sonnet 5 모델에 맞춰서 시스템 프롬프트, CLAUDE.md, Skills를 더 가볍고 유연하게 설계하는 컨텍스트 엔지니어링 원칙을 익힐 수 있어요.
↓
Claude에게 메시지를 보낼 때, 프롬프트는 Claude가 받는 컨텍스트의 아주 작은 부분에 불과합니다.
컨텍스트의 대부분은 시스템 프롬프트, Skills, CLAUDE.md 파일, 메모리, 그리고 그 외 여러 소스로부터 조합되지요.
우리는 이걸 컨텍스트 엔지니어링이라고 부릅니다.
Claude Code를 사용하거나 여러분만의 에이전트를 구축할 때 결과물에 큰 영향을 미칩니다.
프롬프트와 달리 컨텍스트는 여러 요청에 걸쳐 일반적으로 사용되기 때문에 그만큼 구체적일 수 없습니다.
그렇다면 사용자의 프롬프트가 무엇일지 모르는 상황에서, 이런 범용적인 프롬프트와 가이드를 Claude에게 어떻게 만들어줘야 할까요?
↓
🔓 Claude의 족쇄를 풀자
전반적으로 시스템 프롬프트뿐 아니라 CLAUDE.md 파일과 skills를 통해서도 Claude를 과도하게 제약하고 있었다는걸 발견했습니다.
이제는 그중 많은 부분을 삭제하고 모델이 주변 컨텍스트와 판단력을 활용하도록 놔둘 수 있다는 걸 알게 됐습니다.
그리고 Claude Code는 이제 훨씬 더 많은 도구를 갖추고 있습니다.
Claude는 예전에는 CLAUDE.md를 메모리, 정보, 가이드의 원천으로 의존했습니다.
이제는 메모리, 아티팩트, skills가 있어서, Claude가 세션 전반에 걸쳐 컨텍스트를 불러오고 공유하는 새로운 방식을 만들어낼 수 있습니다.
↓
🤔 그때와 지금은 다르다
과거에는 유효했지만 이제는 신화가 되어버린 컨텍스트 엔지니어링 모범 사례들이 몇 가지 있습니다.
그때: Claude에게 규칙을 줘라
→ 지금: Claude가 판단하게 하자
Claude Code를 처음 출시했을 때, 우리는 Claude가 파일을 삭제하는 것 같은 최악의 시나리오를 피하도록 확실히 해야 했습니다.
그러다 보니 항상 옳지는 않을 수 있는 특히 강한 가이드를 주게 됐습니다.
하지만 일부 프롬프트에서는 이 가이드가 틀린 것으로 판명됐습니다.
새로운 모델들은 판단력이 더 뛰어나서, 명시적인 규칙 없이도 이런 결정을 잘 처리할 수 있습니다.
새로운 시스템 프롬프트에서는 이렇게 말합니다.
"주변 코드처럼 읽히는 코드를 작성하라. 그 코드의 주석 밀도, 네이밍, 관용구를 맞춰라."
그때: Claude에게 예시를 줘라
→ 지금: 인터페이스를 설계하자
도구 사용에 관한 첫번째 규칙은 Claude에게 사용법 예시를 주는 것이었습니다.
하지만 최신 모델에서는, 예시를 주는 것이 오히려 특정한 탐색 공간으로 Claude를 제약한다는 걸 발견했습니다.
예시를 사용하는 대신, 우리의 도구, 스크립트, 파일의 설계에 대해 더 깊이 고민하세요.
Claude가 어떤 파라미터를 가지고 있고, 이를 어떻게 더 표현력 있게 만들 수 있을지.
그때: 모든 것을 처음부터 다 제시하라
→ 지금: 점진적 공개를 사용하라
Claude Code는 코딩에 초점을 맞추고 있었기 때문에, 우리 시스템 프롬프트에는 코드 리뷰와 검증을 어떻게 하는지에 대한 상세한 정보가 포함되어 있었습니다.
이 정보가 항상 필요한 건 아니었지만, 필요할 때는 결정적으로 중요한 정보였습니다.
그 이후로 Claude Code는 점진적 공개를 활용하는 데 매우 능숙해졌습니다.
하지만 점진적 공개는 skills에만 해당하는 게 아니라 도구에도 적용됩니다.
우리 도구 중 일부는 지연 로딩 방식으로 되어 있어, 에이전트가 도구를 사용하기 전에 ToolSearch를 이용해 전체 정의를 검색해야 합니다.
이 덕분에 우리는 (Task 도구처럼) 필요할 때까지 컨텍스트를 차지하지 않는 더 많은 도구를 가질 수 있습니다.
그때: 반복해서 말하라
→ 지금: 간단한 도구 설명
이전 Claude 모델들은 때때로 반복된 지시가 필요했고, 컨텍스트 윈도우의 시작 부분보다 끝 부분에 있는 지시를 더 잘 따르는 경향이 있었습니다.
그래서 시스템 프롬프트에는 메인 시스템 프롬프트에서의 도구 언급과, 도구 설명의 지시가 함께 존재하는 경우가 종종 있었습니다.
우리는 이런 중복된 예시들을 삭제하고, 도구 사용법에 대한 지시를 시스템 프롬프트가 아니라 도구 설명에 담을 수 있다는걸 발견했습니다.
그때: CLAUDE.md 파일 안의 메모리
→ 지금: 자동 메모리
예전에는 사용자들에게 # 단축키를 사용해 CLAUDE.md에 자동으로 기록하는 방식으로 Claude의 메모리에 무언가를 저장하도록 권장했습니다.
이제 Claude는 작업 및 우리와 관련된 메모리를 자동으로 저장합니다.
그때: 단순한 스펙
→ 지금: 풍부한 참조 자료
Plan 모드에서 Claude Code는 계획을 담은 마크다운 파일에 크게 의존해왔습니다.
이런 파일에 계획을 저장해두는 것은 필요할 때 Claude가 이를 참조하는 데 도움이 됐습니다.
하지만 우리는 Claude가 점점 더 복잡한 참조 자료를 다룰 수 있다는 걸 발견했습니다.
단순한 마크다운 파일 대신, Claude는 새로운 아티팩트 기능으로 만들어진 HTML 아티팩트를 참조할 수 있습니다.
코드 형태로 Claude에게 참조 자료를 줄 수도 있습니다. 스펙은 상세한 테스트 스위트이거나, Claude가 이식해야 할 다른 코드베이스의 함수일 수도 있습니다.
↓
🛠️ 우리의 컨텍스트에 적용하기
이 모든 것을 종합하면, 우리가 컨텍스트를 조합할 때는 어떤 모습이어야 할까요?
시스템 프롬프트
시스템 프롬프트는 제품 컨텍스트와 밀접하게 연결되어 있습니다.
이건 Claude에게 지금 어떤 제품 안에서 작동하고 있고 무엇을 하고 있는지 알려줍니다.
Claude Code의 경우 여러분이 이를 수정할 일은 아마 없겠지만, 여러분만의 에이전트 하네스를 구축하고 있다면 여기에 많은 시간을 투자해야 합니다.
CLAUDE.md
CLAUDE.md는 가볍게 유지하고, 레포가 무엇을 위한 것인지 간략히 설명하되, 대부분의 토큰은 코드베이스 안의 함정들을 설명하는데 쓰세요.
Claude가 파일 시스템이나 레포를 보면 알 수 있는 '당연한' 내용들을 굳이 적지 마세요.
더 자세한 내용은 점진적 공개를 활용하세요.
예를 들어 작업물을 검증하는 방법에 대한 독특한 지시사항이 여러 개 있다면, 검증 skill을 만들고 CLAUDE.md에서 이를 참조하세요.
Skills
Skills는 필요할 때 Claude가 정보를 찾을 수 있게 해주는 가벼운 가이드라고 생각하세요.
정말 중요한 영역이 아니라면 과도하게 제약하지 마세요.
긴 skill의 경우 가능한 한 점진적 공개를 활용해보세요. 여러 파일로 나누고 분리하세요.
Skills는 우리, 우리의 팀, 혹은 제품에 특화된 특정 견해, 지식, 모범 사례를 담을 때 가장 효과적입니다!
참조 자료
파일을 @ 멘션해서 참조 자료로 포함시킬 수 있습니다.
참조 자료를 통해 Claude는 현재 계획에 대한 심층적인 정보를 참고할 수 있습니다.
이는 스펙 파일, 목업, 혹은 전체 코드베이스일 수도 있습니다.
일반적으로는 코드 형태의 파일을 선호하는 게 좋은데, Claude가 매우 잘 아는 언어로 명확하고 정밀도 높은 지시를 제공하기 때문입니다.
예를 들어 디자인의 HTML 목업은 대체로 그 디자인에 대한 설명이나 스크린샷보다 더 나은 결과를 만들어냅니다.
↓
✨ 단순화를 시도해보세요
시스템 프롬프트, skills, CLAUDE.md 파일 전반에 걸쳐, 우리가 그랬던 것처럼 여러분도 단순화가 필요할 수 있습니다.
이걸 자동으로 도와주는 claude doctor 라는 새 명령어가 출시 되었습니다.
We removed ~80% of the Claude Code system prompt for our newest models, this is what we've learned about writing system prompts, skills and Claude.MDs for them. https://t.co/6DZwSrZjE9