본문 바로가기

IT & AI

Claude 5 시대, 긴 지침보다 필요한 맥락을 제때 꺼내야 해요

728x90

Claude 5 시대, 긴 지침보다 필요한 맥락을 제때 꺼내야 해요

Claude 5 컨텍스트 엔지니어링 썸네일
Claude 5 컨텍스트 엔지니어링 썸네일

Anthropic이 Claude Opus 5와 Claude Fable 5에 맞춰 Claude Code의 시스템 지침을 80% 넘게 줄였어요. 그런데 내부 코딩 평가에서는 측정 가능한 성능 저하가 없었다고 해요. 최신 모델을 잘 쓰려면 규칙을 계속 덧붙이기보다, 필요한 정보가 필요한 순간에 들어오도록 전체 맥락을 설계하는 쪽이 낫다는 설명이에요. 1

핵심 요약

구분달라진 방향실무에서 할 일
시스템 지침반복 규칙과 예시를 줄여요제품 역할과 안전 경계만 선명하게 남겨요
CLAUDE.md저장소 설명서를 짧게 유지해요코드만 봐서는 알기 힘든 함정을 적어요
Skills모든 지식을 한 파일에 넣지 않아요작업할 때 필요한 안내서만 불러오게 나눠요
도구긴 사용 예시보다 구조를 또렷하게 만들어요매개변수와 상태값만 봐도 쓰임새를 알 수 있게 해요
참조 자료짧은 글만 고집하지 않아요테스트, 코드, HTML 모형, 평가 기준표를 함께 써요

1. Claude 5는 규칙의 양보다 맥락의 질에 더 민감해졌어요

Anthropic의 설명에서 가장 눈에 띄는 숫자는 80%예요. Claude Code가 최신 모델에 전달하던 시스템 지침의 대부분을 덜어냈지만 코딩 평가 결과는 나빠지지 않았어요. 지침이 길수록 결과가 좋아진다는 익숙한 가정에 제동을 건 사례예요. 다만 이 수치는 Anthropic의 내부 평가 결과라서, 모든 저장소와 작업에서 같은 폭으로 줄여도 된다는 뜻은 아니에요. 2

예전에는 잘못된 파일 삭제나 불필요한 주석 같은 최악의 상황을 막으려고 세부 규칙을 많이 넣었어요. 시간이 지나면서 시스템 지침, CLAUDE.md, Skills, 사용자의 요청이 서로 다른 방향을 가리키는 문제가 생겼어요. 예를 들어 문서를 적절히 남기라는 요청과 주석을 만들지 말라는 규칙이 한 작업 안에서 부딪힐 수 있어요. 모델은 코드를 고치기 전에 어느 지침을 우선해야 할지 판단하느라 주의를 써야 해요.

728x90

새 접근은 저장소의 기존 스타일을 먼저 읽게 해요. 주석의 양, 이름 짓는 방식, 코드 관용 표현을 주변 코드에 맞추라는 식이에요. 세부 행동을 일일이 지정하기보다 판단 기준을 주는 셈이에요. 최신 모델의 판단력이 좋아졌다는 전제가 깔려 있으므로, 삭제나 권한 변경처럼 되돌리기 어려운 작업의 안전장치까지 없애면 안 돼요.

CLAUDE.md에는 코드에서 보이지 않는 함정만 남겨요

저장소의 폴더 구조나 사용 언어는 모델이 파일을 읽으면 알 수 있어요. 이런 내용을 CLAUDE.md에 길게 반복하면 중요한 예외가 묻혀요. 타입은 반드시 한 파일에서만 관리한다거나, 특정 검증 명령을 정해진 순서로 실행해야 한다는 규칙처럼 탐색만으로 알아내기 어려운 내용을 우선하는 편이 좋아요.

긴 검증 절차는 별도 Skill로 옮길 수 있어요. 평소에는 짧은 안내만 보고, 검증 단계가 오면 세부 절차를 불러오는 방식이에요. Anthropic은 이를 점진적 공개라고 불러요. Claude Code의 일부 도구도 전체 정의를 처음부터 넣지 않고, 실제 사용 직전에 찾아보게 구성했어요.

도구 예시를 늘리기 전에 인터페이스를 고쳐요

과거 모델에는 도구 호출 예시를 여러 개 보여주는 방식이 잘 먹혔어요. 최신 모델에서는 예시가 오히려 탐색 범위를 좁힐 수 있다고 해요. 대신 도구의 매개변수와 상태값이 행동을 자연스럽게 설명해야 해요.

할 일 도구의 상태를 `pending`, `in_progress`, `completed`로 제한하면 모델은 가능한 전이를 바로 이해할 수 있어요. 동시에 진행 중인 항목은 하나만 허용한다는 규칙도 인터페이스에서 드러낼 수 있어요. 문장으로 같은 규칙을 여러 번 반복하는 것보다 오류가 적고 유지보수도 쉬워져요.

명세는 테스트와 코드로도 건넬 수 있어요

참조 자료의 형식도 넓어졌어요. 요구사항을 Markdown 문서로만 설명할 필요는 없어요. 상세한 테스트 스위트는 통과 조건을 정확히 보여줘요. 다른 코드베이스의 함수는 원하는 구조를 코드로 전달해요. 화면 작업에서는 긴 디자인 설명보다 실행 가능한 HTML 모형이 더 선명한 기준이 될 수 있어요.

평가 기준표도 유용해요. 좋은 API가 갖춰야 할 조건이나 코드 리뷰에서 볼 항목을 기준표로 만들면, 결과를 만든 뒤 같은 기준으로 다시 확인할 수 있어요. 말로만 "품질을 높여 달라"고 하는 것보다 확인할 조건을 구체적으로 줄 수 있어요.

왜 중요한가요

Claude Code를 오래 쓴 팀은 실패할 때마다 새 규칙을 추가하기 쉬워요. 그러면 같은 뜻의 문장이 여러 파일에 퍼지고, 오래된 규칙과 새 규칙이 충돌해요. 모델이 바뀐 뒤에도 예전 보호 장치를 그대로 쌓아 두면 컨텍스트 비용만 늘고 실제 판단은 더 어려워질 수 있어요. 2

바로 적용할 때는 무작정 80%를 지우지 않는 편이 안전해요. 먼저 중복 지침을 찾고, 저장소를 읽으면 알 수 있는 설명을 덜어내요. 그다음 작업별 절차를 별도 파일로 나누고 필요할 때만 불러오게 해요. 마지막으로 삭제, 배포, 권한, 개인정보처럼 사고 비용이 큰 규칙은 그대로 남겨요. 변경 전후에 같은 평가 세트를 돌려야 성능이 유지됐는지 확인할 수 있어요.

핵심은 짧은 문서 자체가 아니에요. 모델의 주의가 현재 작업에 필요한 정보로 향하게 만드는 구조예요. 시스템 지침은 제품의 역할과 경계를 잡고, CLAUDE.md는 저장소의 함정을 알려줘요. Skills는 작업별 절차를 열어 주고, 테스트와 코드는 결과를 판단할 기준이 돼요. 각 요소의 역할이 겹치지 않으면 새 모델로 바뀌어도 관리하기 쉬워져요.

참고 자료

  1. Claude 5 모델을 위한 새로운 컨텍스트 엔지니어링 규칙 — GeekNews
  2. The new rules of context engineering for Claude 5 generation models — Claude by Anthropic
  3. Thariq의 Claude Code 시스템 지침 축소 소개 — X
728x90