Claude Opus 4.7의 100만 토큰, 정말 다 쓸 수 있을까 — 모노레포를 통째로 맡겨서 실측해 본 결과

「100만 토큰」이라고 하면 실감이 나시나요? 저는 처음에 감이 잘 오지 않았습니다.

Anthropic이 2026년 4월 16일에 Claude Opus 4.7을 출시하며, 1M token 컨텍스트가 표준으로 제공되었습니다. 요금도 Opus 4.6에서 그대로 유지되었습니다($5/$25 per M tokens).

「이걸로 모노레포(Monorepo)를 통째로 먹일 수 있을까」가 기술자의 관심사입니다. 본 기사에서는 제가 자사의 중규모 모노레포(약 640k 토큰)를 Opus 4.7에 통째로 맡겨서 실측한 4가지 태스크의 체감과 실제 비용, 그리고 1M이 정말로 도움이 되는 상황을 공유합니다.

시간이 없는 분들을 위한 결론입니다.

1M token은 「통째로 맡겨도」 일단 작동한다 — 640k 토큰 입력 시 첫 응답 약 2.1분 -
NIAH(Needle In A Haystack) 정확도는 1M에서도 76%, 256k라면 93% — 256k 이내라면 기존처럼 사용 가능 -
1회 풀 투입 비용은 몇 달러 — 테스트하기에는 문제없지만, 반복하면 아픔 -
진정한 용도는 「횡단 리팩토링(Cross-cutting Refactor)」 — 단순한 코드 생성보다 문맥을 가로지르는 태스크에서 빛을 발함

저는 처음에 지식 QA나 Spec(사양)으로부터 구현까지의 일괄 생성을 기대했습니다. 실제로 해보니 용도가 다른 곳에 꽂히는 도구라는 것을 체감했습니다.

제 손에 있는 검증 대상입니다.

항목	값
모델	claude-opus-4-7 (1M context)
...

640k 토큰의 내역은 src/ 하위가 약 450k, docs/가 약 80k, CHANGELOG.md와 README.md 계열이 약 110k 정도입니다. Spec-Driven Development(사양 주도 개발)로 설계서를 두껍게 가지고 있는 리포지토리라 문서의 비율이 높을지도 모릅니다.

Opus 4.7은 새로운 토크나이저(Tokenizer)를 채택하고 있어, 같은 글자 수라도 기존 모델보다 최대 35% 더 많은 토큰을 소비한다는 보고가 있습니다. 원래 글자 수로 견적을 낸 비용은 과소평가될 가능성이 있으므로, 요금 계산 시에는 새로운 토크나이저로 다시 계산해 주세요.

처음에 시도한 것은 「이 모노레포의 의존 라이브러리와 역할을 목록화해줘」라는 심플한 태스크입니다.

결과는 압도적으로 좋습니다. package.json과 requirements.txt뿐만 아니라, 각 모듈이 어떻게 연계되어 있는지를 의존 그래프(Dependency Graph) 스타일로 정리해 주었습니다. 평소라면 3~4개 파일씩 나누어 물어봤을 작업을 단 1번의 리퀘스트(Request)로 끝냅니다.

출력 예시(발췌):
- src/core/orchestrator.ts → src/agents/* 를 호출하는 코어 루프
- src/agents/{plan,write,review}.ts → 3가지 모드로 동작, 공통의 BaseAgent를 상속
...

「CHANGELOG.md에 기재된 v0.4로부터의 설계 변경 사항」까지 찾아낸 것이 감동 포인트였습니다. 코드와 문서를 횡단하는 태스크에서 1M context는 본령을 발휘합니다. 의존 그래프를 구두로 설명할 수 있는 수준까지 정리해 주었기에, 신입 엔지니어의 온보딩(Onboarding)용 자료로도 그대로 유용할 법한 출력이었습니다.

다음으로 「UserId 타입을 string에서 분기 유니온(AuthUserId | GuestUserId)으로 바꾸고, 영향이 있는 곳을 전부 수정해줘」라고 지시했습니다.

이것도 거의 누락 없이 작동했습니다. 평소의 Claude Code에서는 20~30개 파일에 걸친 수정은 의존 관계를 놓치는 경우가 종종 있습니다. 1M context로 전부를 한꺼번에 보여주니, 놓치는 부분이 눈에 띄게 줄었습니다.

다만, 첫 응답까지 2.1분이 걸립니다. 이는 GPT-OSS와 같은 작은 모델과는 차원이 다르게 느립니다. 짧은 리퀘스트라면 몇 초 만에 답하는 Opus도, 640k를 먹이면 GPU가 진지하게 생각할 시간이 필요해집니다.

여담이지만, 첫 2.1분 동안 저는 Slack을 열어보며 「아, 이거 멈췄나?」 하고 브라우저를 한 번 닫을 뻔했습니다. Opus 4.7은 제대로 생각하고 있으니, 서둘러 재전송하지 않도록 합시다. 저처럼 중복 게시를 해서 비용을 두 배로 내면 은근히 눈물이 납니다.

prompt caching(프롬프트 캐싱)을 병용하면 2회차부터는 극적으로 빨라집니다. 첫 번째 리퀘스트에서 전체 모노레포를 캐시에 올리고, 두 번째 리퀘스트부터는 차분(Diff)만 보내는 것. 이것이 Opus 4.7의 올바른 사용법이라고 생각합니다.

「2024년 Q3에 중단한 인증 방식의 이유를 커밋 로그와 CHANGELOG에서 알려줘」라는 태스크입니다.

결과는 그저 그랬습니다. 오래된 CHANGELOG의 기술은 요약에 치우쳐, 당시 논의의 세세한 뉘앙스가 누락되었습니다. 이는 1M context(100만 토큰 컨텍스트)의 '등가성(Equivalence)'이 완벽하지 않다는 증거라고 생각합니다.

구체적으로는, CHANGELOG의 항목이 오래될수록 "○○을 개선"과 같이 요약되어 버리는 경향이 있었습니다. 가공되지 않은 커밋 메시지(Raw commit message)가 고유명사나 숫자를 더 잘 남기기 때문에, 과거의 판단을 추적하려면 커밋을 직접 입력하는 것이 더 정확할지도 모릅니다.

Anthropic의 공개 자료에 따르면, Opus 4.7의 전신인 Opus 4.6은 8-needle 1M MRCR v2에서 76%, 256k에서는 93%를 기록했습니다. 1M로 읽게 하더라도 모든 정보를 256k 수준의 정밀도로 추출할 수 있는 것은 아니다라는 점은 운용상의 전제로 알고 있어야 합니다.

제 체감상으로는 입력의 전반부 20-30%에 있는 정보는 요약되기 쉬웠고, 후반부에 배치한 정보가 더 추출하기 쉬웠습니다 (어디까지나 체감입니다). 중요한 지시사항이나 코드는 입력의 마지막에 두는 것이 안전합니다.

이것은 저도 처음에 실수했던 부분입니다. README.md를 서두에 떡하니 올려두고 "이것이 가이드니까 읽어줘"라고 덧붙였더니, 정작 중요한 가이드를 무시한 답변이 돌아왔습니다. 그 이후로는 "지시는 마지막에, 코드는 중간에"라고 정해두고 있습니다.

"이 모노레포(Monorepo)와 정합성을 유지하는 형태로, 새로운 /api/users/:id/preferences 엔드포인트를 구현해줘"라는 태스크.

이것도 작동했습니다. 작동은 했지만, 첫 응답이 느립니다. 640k 컨텍스트를 매번 읽어서 구현하는 것은 가성비(Cost-performance)가 좋지 않습니다.

순수하게 코드 생성만 목적이라면, 관련 파일만 200k context로 압축한 Opus 4.6/Sonnet 4.6이 더 빠르고 저렴하다는 것이 저의 결론입니다. 1M context를 사용하는 것은 "전체를 보고 나서야 알 수 있는 태스크"로 한정해야 합니다.

"실제로 비용이 얼마나 드는가"에 대한 리얼한 숫자입니다.

시나리오	입력 토큰	출력 토큰	개략적 비용
모노레포 통째로 맡기기 (1회 요청)	640k	약 8k	약 $3.4
...
입력은 $5/M tokens, 출력은 $25/M tokens로 계산했습니다. Prompt caching (캐시 히트)를 사용하면 최대 90% 할인되므로, 첫 번째의 몇 달러만 지불하면 두 번째부터는 수십 센트로 동일한 모노레포를 참조할 수 있습니다.

저의 사용 방식은 "아침에 모노레포 전체를 캐시에 올린다" $\rightarrow$ "하루 종일 그 캐시에 대해 질문한다" 스타일입니다. Anthropic의 prompt caching은 TTL(Time To Live)을 5분 또는 1시간으로 설정할 수 있으며, 긴 TTL을 선택하면 하루 비용을 절감할 수 있습니다.

저의 현재 용도별 구분입니다.

용도	권장 모델 / context
설계서로부터 코드 생성	Opus 4.6 / 200k
...
1M이 효과적인 경우는 "횡단(Cross-cutting)", "전체 조망", "과거 이력을 포함한 판단"이 필요한 태스크입니다. 그 외에는 200k 이내로도 충분합니다.

저의 규칙: 관련 파일이 3~5개로 끝난다면 200k, 10개 이상 + 문서를 넘나든다면 1M으로 올린다고 정해두었습니다. 임계값은 사람마다 다르겠지만, 매번 1M을 사용할 필요가 없다는 것은 확실합니다.

Claude Code에서 1M context를 사용할 경우, --max-input-tokens에 해당하는 설정으로 의도치 않게 제한이 걸려 있지 않은지 확인해 두어야 합니다. 저의 초기 설정에는 200k 제한이 남아 있어서, 모처럼의 Opus 4.7을 제대로 활용하지 못하고 있었습니다. 이를 깨달은 것은 API 로그를 다시 살펴본 지 30분 후였고, 그동안 계속 200k로 작동시키면서 "어라, 생각보다 정밀도가 낮네"라며 고개를 갸우뚱하고 있었던 셈입니다. 이제는 새로운 환경을 만들면 먼저 claude config list를 보는 습관이 생겼습니다. 서버 측 설정만 업데이트되고 클라이언트가 옛날 상태로 남아 있는 것은 AI 관련 도구에서 자주 발생하는 패턴이므로, 처음에 확인하는 것이 결국 더 빠릅니다.

# Claude Code의 현재 설정 확인
claude config list
# 모델 전환 (2026-05 시점)
...

또한, Claude Code를 통해 prompt caching을 사용하는 경우, /cache 명령어로 세션 중의 캐시 상태를 확인할 수 있습니다. 긴 리포지토리를 다룰 때는 적극적으로 사용해야 할 기능입니다.

Claude Opus 4.7의 100만 토큰을 정말로 다 쓸 수 있는지에 대한 답변입니다.

• 다 쓸 수 있다, 다만 모든 것이 동등하지는 않다 — 1M(100만 토큰)에서는 76% 정확도, 256k에서는 93% 정확도
• 「통째로 맡기기」는 테스트용으로는 좋지만, 반복하면 비용이 아프다 — 1회 요청당 약 $3
• Prompt Caching (프롬프트 캐싱)이 핵심 — 2회차 요청부터 90% 할인, 운영 비용이 현실적으로 변함
• 횡단 리팩터링 (Cross-cutting Refactoring)과 온보딩 (Onboarding)이 진가 — 단순한 코드 생성에는 200k로도 충분
• 끝부분에 중요한 정보를 배치할 것 — 전반부는 요약되어 버리기 쉬움 (체감상)

1M Context (컨텍스트)를 단순히 "데이터를 더 많이 집어넣는" 스케일 확장이라고 생각하며 사용하면 돈이 녹아내립니다. 진짜 가치는 "의존성과 이력을 포함한 전체 파악"이라는 새로운 사용법에 있습니다. 저는 매주 모노레포를 이 방식으로 점검(Inventory)하게 되었습니다. 주간 점검은 리뷰도 설계도 아닌, "현재 리포지토리의 형태를 조망하는" 시간이며, 이것이 있는 것만으로도 의사결정의 질이 달라진다고 느낍니다.

여러분은 Opus 4.7의 1M Context를 어디에 사용하고 계신가요? "이 정도까지 넣었을 때 의미가 있었다", "여기서부터는 정확도가 무너졌다"와 같은 경험담을 댓글로 모집합니다. 저의 검증은 중규모 리포지토리 수준에 그쳤으므로, 더 큰 리포지토리에서의 실측 결과가 귀중한 지견이 될 것입니다.