Anthropic 엔지니어링 블로그 #10: Effective Context Engineering — 프롬프트가 아니라 '컨텍스트 전체'를 설계하는 일

이 글은 Anthropic 엔지니어링 블로그에 2025년 9월 29일 게재된 “Effective context engineering for AI agents” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

한 줄로 말하면

#

프롬프트 잘 짜기에서 한 단계 위 — 컨텍스트 창에 ‘무엇을, 언제, 얼마만큼’ 채울지 설계하는 일이 진짜 일이다.

어떤 문제를 해결하려 했나

#

LLM을 처음 쓸 땐 “프롬프트만 잘 짜면 된다"고 생각합니다. 하지만 에이전트로 가면 상황이 달라져요.

“Claude가 처음에는 잘 따랐는데, 한 시간쯤 작업하니까 앞 지시를 잊더라고요.”

이건 모델이 나쁜 게 아닙니다. 컨텍스트 창이 가득 차면 성능이 떨어집니다(context rot). 트랜스포머는 모든 토큰이 다른 모든 토큰과 관계를 맺어야 해서 n² 부담이 생기고, 학습 데이터도 긴 시퀀스보단 짧은 시퀀스가 많아 긴 컨텍스트엔 약합니다.

원문이 못 박은 핵심: “컨텍스트는 결정적이지만 유한한 자원이다.” 새 토큰 하나하나가 ‘주의 예산(attention budget)‘을 깎아냅니다.

그래서 잘 쓰려면 프롬프트가 아니라 컨텍스트 전체를 설계해야 합니다 — 시스템 지시, 도구, MCP, 외부 데이터, 메시지 기록 모두 포함해서요.

해결책: 컨텍스트 엔지니어링의 세 기법

#

1. 압축(Compaction)과 노트(Note-taking)

#

컨텍스트가 한계에 가까워지면 두 가지 방법으로 비웁니다.

압축: 그동안의 대화를 모델 자신이 요약하게 하고, 요약본 + 최근 파일 5개로 다시 시작합니다. 결정사항·미해결 버그·중요한 구현 디테일은 보존, 중복된 도구 출력은 버립니다.

노트(외부 기억): 에이전트가 컨텍스트 창 밖 파일에 메모를 적습니다. Pokémon을 플레이하는 Claude의 사례가 인상적이에요.

“지난 1,234 스텝 동안 Route 1에서 피카츄를 훈련시켜 목표 레벨 10 중 8레벨을 올렸다.”

수천 스텝을 가도 진행 상황이 안 흐트러집니다. 컨텍스트는 가볍게 유지하면서 장기 기억은 외부 파일로 두는 방식. Anthropic이 공개한 Memory tool이 이걸 표준화한 형태입니다.

2. Just-in-Time 로딩 — 미리 다 넣지 말고, 필요할 때만 가져오기

#

미리 모든 자료를 컨텍스트에 채워두는(pre-emptive) 방식 대신, 파일 경로·쿼리·링크 같은 식별자만 들고 있다가 필요할 때 도구로 불러오는 방식입니다.

[Pre-emptive 방식]
프로젝트 시작 시 관련 문서 100개를 통째로 로드
   → 토큰 폭발, 정작 필요한 정보 못 찾음

[Just-in-Time 방식]
파일 트리·인덱스만 보고 있다가
   → grep, head, tail 같은 도구로 필요 부분만 읽기
   → 사람이 책장 보고 책 꺼내 읽는 것과 같음

Claude Code가 이 패턴을 그대로 씁니다. CLAUDE.md는 미리 로드(빠른 접근), glob/grep은 필요할 때 탐색(유연). 하이브리드가 최적입니다.

3. 시스템 프롬프트는 ‘딱 맞는 고도’에서 쓴다

#

시스템 프롬프트는 두 실패 모드 사이의 골디락스 지점을 잡아야 합니다.

원문 권장: <background_information>, <instructions>, ## Tool guidance 같은 명시적 섹션 구조로 나눠 쓰기. 그리고 “행동을 완전히 그릴 만큼의 최소 정보”(minimal ≠ short)를 목표로.

핵심 결론

#

LLM 응답이 별로일 때 사람들은 본능적으로 “프롬프트가 부족했나?“를 봅니다. 이 글의 답은 다릅니다.

“프롬프트가 문제인 줄 알았는데, 사실은 컨텍스트 창을 무엇으로 채웠는지가 문제였다.”

좋은 컨텍스트 엔지니어링이란 “원하는 결과를 끌어낼 확률을 최대화하는, 가장 적은 양의 고신호 토큰” 을 찾는 일입니다. 더 많이 넣는 게 아니라 더 잘 골라 넣는 거예요.

내 작업에 적용한다면

#

시나리오 1 — 일반적인 데이터 분석 과정

#

분석에서 LLM 활용도 같은 함정에 빠집니다. “데이터 전부를 LLM에 던지고 분석해달라” 가 가장 흔하지만 가장 나쁜 패턴이에요.

[Before — 모두 다 넣기]
CSV 100MB 전체를 컨텍스트에 붙여 "이상치 찾아줘"
   → 컨텍스트 폭발, 답변 흐트러짐

[context engineering 적용]
[식별자만 들고 있기]
   - 컬럼 스키마, 행 수, 기본 통계만 컨텍스트에 로드
[Just-in-Time 도구]
   - SQL 쿼리 / pandas 조각 / head/tail 호출로 필요 부분만 가져오기
[중간 결과는 외부 노트]
   - "지금까지 발견한 가설/이상치" 별도 파일에 누적
   - 컨텍스트는 항상 가볍게 유지
[압축 시점 정하기]
   - 한 분석 단계 끝날 때마다 "결정사항 + 다음 단계"만 요약하고 재시작

핵심: 데이터 분석 보조에 LLM을 쓸 때, “한 컨텍스트 안에 다 우겨넣지 않는 설계” 가 분석 품질을 좌우합니다.

시나리오 2 — 웹 사이트를 자동으로 운영할 때

#

자동 운영도 똑같은 원리가 적용됩니다. 운영 자동화가 길어질수록 컨텍스트 누적 문제가 커져요.

[Before — 한 세션에 모든 운영 정보]
사이트 전체 구조 + 로그 + 모니터링 데이터 다 컨텍스트에 채움
   → 토큰 한계 도달, 핵심 지시 잊음

[context engineering 적용]
[시스템 프롬프트는 골디락스 고도]
   - "톤 가이드, 금지 표현, 에스컬레이션 절차"만 명시
   - 모든 운영 케이스를 if-else로 적지 않음
[Just-in-Time 운영 데이터]
   - 로그/메트릭은 필요할 때 grep·API 호출로 가져옴
   - 미리 로드 X
[외부 메모리 = 운영 상태]
   - 진행 중인 인시던트, 진단 가설은 외부 파일/티켓
   - 새 세션 시작 시에도 거기서 다시 읽음
[작업 단위 압축]
   - 한 작업(글 발행/배포) 끝나면 핵심만 요약하고 재시작

핵심: 자동 운영의 안정성은 “컨텍스트를 항상 가볍게 유지하는 설계” 에서 옵니다. 미리 채우지 말고, 필요할 때 가져오고, 끝나면 비우세요.

Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.