Claude Code 1M 컨텍스트의 함정: 길게 넣는다고 똑똑해지지 않는다

"이젠 코드베이스 통째로 넣으면 되겠네"

Claude Opus 4.7이 1M 컨텍스트를 열었을 때 처음 든 생각이다. 이전에는 200K 한도 때문에 잘라서 넣어야 했는데, 이젠 중소 규모 프로젝트는 통째로 들어간다.

그래서 통째로 넣어봤다. 결과는 예상과 달랐다. 컨텍스트가 길어질수록 답이 더 흐려졌다. 나만 그런 줄 알았는데, 이건 잘 알려진 현상이고 이름도 있다.

이 글은 1M 컨텍스트를 두 달쯤 굴리면서 확인한 6가지 함정을 정리한다.

함정 1: Lost in the Middle

긴 컨텍스트에 정보를 넣으면, 모델이 앞과 뒤는 잘 보고 가운데는 흘려본다. 스탠퍼드와 Anthropic이 모두 확인한 현상이다.

내가 직접 겪은 사례는 이렇다. 50만 토큰짜리 코드베이스를 통으로 넣고 "결제 모듈에서 환불 처리하는 함수가 어디 있어?"라고 물었다. 답은 그럴듯했지만, 실제로는 다른 함수를 가리키고 있었다. 진짜 환불 함수는 컨텍스트 한가운데 묻혀 있었다.

해결책은 단순하다. 중요한 정보는 앞이나 뒤에 둔다. 코드베이스를 넣어야 한다면 가장 관련성 높은 파일을 직접 골라 앞쪽에 배치한다. AI에게 "탐색해서 찾아줘"가 아니라 "이 5개 파일을 본 다음 답해줘"가 정확도가 높다.

함정 2: 비용이 선형으로 증가하지 않는다

200K 컨텍스트 가격을 1M에 적용하면 5배가 될 것 같지만, 실제는 더 비싸다. Anthropic의 1M 컨텍스트는 입력 토큰당 단가가 다르다.

대략적인 감각:

• 200K 미만: 표준 단가
• 200K 초과: 단가가 올라간다 (2배 정도, 모델·시점에 따라 다름)

여기에 출력 토큰까지 더해지면, 한 번 호출에 몇 달러가 나가는 게 흔해진다. 코드베이스 통째로 넣고 "버그 찾아줘"를 한 시간 동안 반복하면, 점심값이 사라진다.

대안:

• 의심되는 파일만 추려서 50K 이내로 줄인다
• AI가 직접 grep/find를 돌리게 한다 (검색 결과만 컨텍스트로)
• Plan Mode로 먼저 어디를 봐야 하는지 좁힌다

이전 글에서 다뤘던 Plan Mode가 여기서도 효자다.

함정 3: 캐시 무효화 폭격

Claude의 프롬프트 캐싱은 앞부분이 동일할 때만 적용된다. 캐시 히트는 비용을 90%까지 낮춰준다.

문제는 1M 컨텍스트로 작업할 때다. 코드 한 줄만 수정해도, 그 파일이 컨텍스트에 들어가 있으면 그 위치 이후로 캐시가 전부 무효화된다. 50만 토큰을 캐시 미스로 처리하면 비용이 곱절로 뛴다.

내가 쓰는 우회법:

1. 변하지 않는 부분을 앞에 둔다 — 시스템 프롬프트, 코드 컨벤션, 도메인 설명 같은 것들
2. 자주 변하는 파일은 뒤에 둔다 — 작업 중인 파일, 최근 diff
3. CLAUDE.md를 적극 활용한다 — 캐싱이 잘 되는 프로젝트 메모리

함정 4: "거기 있는 척" 답하는 모델

긴 컨텍스트에서 모델은 자기가 본 적 없는 정보도 본 척하는 경향이 강해진다. Hallucination이 더 자연스럽게 섞여 들어온다는 뜻이다.

예: 코드베이스를 넣고 "이 함수의 단위 테스트는 어디 있어?"라고 물었을 때, 테스트가 없는데도 "tests/payment.test.ts에 있습니다"라고 답한다. 그 파일이 실제로 컨텍스트에 들어가 있지 않아도, 그럴듯한 경로를 만들어낸다.

대응:

• 답을 받으면 인용 위치를 명시적으로 요구한다 ("파일명과 라인 번호를 적어줘")
• 인용된 위치를 grep으로 검증한다
• 중요한 결정은 컨텍스트에 안 들어 있을 가능성을 의심한다

함정 5: 응답 시간 폭증

1M 토큰을 처리하면 첫 토큰까지 10초 이상 걸리는 게 흔하다. 작업 흐름이 끊긴다. 코딩하면서 "이거 어떻게 짤까?"를 빠르게 물어보던 리듬이 깨진다.

게다가 Claude Code 같은 에이전트는 한 작업 안에서 여러 번 호출한다. 호출당 10초가 더 붙으면 전체 작업 시간이 분 단위로 늘어난다.

해결:

• 빠른 작업은 작은 컨텍스트로 (Haiku 4.5 + 50K)
• 깊은 분석만 큰 컨텍스트로 (Opus 4.7 + 1M)
• 모델 라우팅을 자동화하는 OMC 같은 도구를 쓴다

함정 6: 컨텍스트가 길수록 지시가 흐려진다

이게 가장 미묘하다. 긴 컨텍스트에서는 시스템 프롬프트의 영향력이 상대적으로 약해진다. 50만 토큰의 코드 안에 "한국어로 답해줘" 한 줄이 묻혀 있으면, 모델이 한국어 지시를 잊고 영어로 답하기도 한다.

내 대처법은 단순하다. 중요한 지시를 사용자 메시지 마지막에 한 번 더 박는다. 컨텍스트가 아무리 길어도 마지막 지시는 잘 따른다.

[큰 컨텍스트 파일 1]
[큰 컨텍스트 파일 2]
...
 
위 코드를 분석해서 한국어로 답해줘. 출력은 마크다운으로.

지시는 마지막에. 이 한 줄이 답 품질을 크게 바꾼다.

그럼 1M 컨텍스트는 안 쓰는 게 좋은가

아니다. 진짜 필요할 때는 가치가 크다.

내가 1M을 써서 가치가 있었던 사례:

• 새 코드베이스 온보딩 — 처음 프로젝트를 받았을 때 전체 구조를 한 번에 파악
• 대규모 리팩토링 사전 분석 — 변경이 어디까지 파급되는지 전체 보기
• legacy 코드 마이그레이션 계획 — 의존성과 호출 그래프 파악

공통점은 **"전체를 한 번 본다"**가 본질인 작업이다. 일상 코딩에서는 1M까지 안 가는 게 정답이다.

실전 가이드

내가 굳어진 운영 규칙은 이렇다.

• 기본은 50K 이내 — Sonnet/Opus 모두에서 안전한 영역
• 200K까지는 자유롭게 — 표준 가격, 캐싱 잘 된다
• 200K 넘으면 한 번 더 생각 — 정말 다 필요한가? Plan Mode로 좁힐 수 있나?
• 1M은 일회성 분석에만 — 계속 굴리면 비용이 위험하다

또 한 가지 — 컨텍스트가 클수록 사람이 답을 검증하는 비용이 같이 커진다는 걸 잊지 말자. 검증할 수 없는 답은 가치가 없다.

정리

1M 컨텍스트는 마법이 아니다. 길게 넣을수록 답이 좋아진다는 직관은 틀린 직관이라는 게 두 달 굴려본 결론이다.

가운데 정보가 묻히고, 비용이 폭발하고, 캐시가 깨지고, 응답이 느려지고, 환각이 자연스러워지고, 지시가 흐려진다. 여섯 가지 함정이 동시에 터진다.

그래도 1M이 무용한 건 아니다. **"전체를 한 번 보는 작업"**에는 다른 대안이 없다. 일회성 온보딩, 사전 분석, 마이그레이션 계획. 이런 작업에는 1M이 답이고, 그 외에는 50~200K가 답이다.

긴 컨텍스트의 진짜 사용법은 "더 많이 넣기"가 아니라 "넣을지 말지 한 번 더 묻기"다. 컨텍스트는 비싸고, 짧을수록 정확하다.