Claude Opus 4.7의 1M 토큰 컨텍스트 윈도는 공식 사양입니다. 하지만 이것이 곧 어떤 레포든 그대로 프롬프트에 붙여 넣으면 된다는 뜻은 아닙니다. 더 정확히는, 레포 전체와 작업 지시, 기존 대화, 도구 출력, 오류 로그, 그리고 결과를 써낼 출력 여유까지 모두 한도 안에 들어올 때 한 번에 분석할 수 있습니다.[2]
대형 모노레포, 생성 파일, vendor 의존성, 빌드 산출물, 긴 문서나 로그가 많은 저장소라면 여전히 선별, 분할, 도구 기반 탐색이 필요합니다. 1M 컨텍스트는 레포 분석의 상한을 크게 넓혀 주지만, 레포 전체 자동 통과권은 아닙니다.
먼저 결론: 가능하지만 조건부입니다
Claude Opus 4.7은 1M 토큰 컨텍스트 윈도와 최대 128k 출력 토큰을 지원합니다.[2] 이 점만 보면 긴 문서, 긴 코드, 넓은 범위의 코드베이스 분석에 훨씬 유리합니다.
다만 레포 전체를 한 번에 읽히려면 최소한 세 가지를 확인해야 합니다.
- 입력 전체가 1M 컨텍스트 안에 들어와야 합니다. 소스 파일만 계산하면 부족합니다. 시스템 프롬프트, 사용자 지시, 대화 기록, 검색 결과, 테스트 로그, 도구 출력도 모두 컨텍스트를 차지합니다.[
2]
- 출력 공간을 남겨야 합니다. Opus 4.7은 최대 128k 출력 토큰을 지원하지만, 감사 보고서, 대형 패치, 리팩터링 계획, 파일별 분석을 요구한다면 입력을 한계까지 채우는 방식은 위험합니다.[
2]
- Opus 4.7 기준으로 토큰을 다시 세야 합니다. Anthropic은 Opus 4.7의 새 토크나이저가 같은 텍스트를 처리할 때 약 1배에서 1.35배 토큰을 사용할 수 있으며,
/v1/messages/count_tokens결과도 Opus 4.6과 달라진다고 설명합니다.[2]
공식 자료가 실제로 말해주는 것
| 확인할 질문 | 공식 자료의 내용 | 실무적 해석 |
|---|---|---|
| 컨텍스트 윈도는 얼마나 큰가 | Opus 4.7은 1M 토큰 컨텍스트 윈도를 지원합니다.[ | 매우 큰 작업 묶음을 한 번에 다룰 수 있지만, 여전히 하드 리밋은 있습니다. |
| 출력은 얼마나 가능한가 | Opus 4.7은 최대 128k 출력 토큰을 지원합니다.[ | 긴 보고서, 긴 패치, 대량 분석에는 출력 예산을 따로 남겨야 합니다. |
| 토큰 계산 방식이 달라졌나 | 새 토크나이저는 같은 텍스트에 대해 약 1배에서 1.35배 토큰을 사용할 수 있고, 토큰 카운팅 결과도 Opus 4.6과 다를 수 있습니다.[ | 예전 모델 기준 토큰 수나 단순 글자 수 추정만 믿으면 안 됩니다. |
| 레포 작업에 적합한가 | Anthropic은 Opus 4.7을 | 대형 코드 작업에 더 적합하다는 근거는 있지만, 모든 레포에 대한 무조건적 보장은 아닙니다. |
| 장시간 작업은 안정적인가 | Anthropic은 Opus 4.7이 복잡하고 오래 걸리는 작업을 엄밀하고 일관되게 처리한다고 소개합니다.[ | 공식 메시지는 긍정적입니다. 다만 실제 프로덕션 적용 전에는 자신의 레포와 테스트로 검증해야 합니다. |
왜 1M 컨텍스트가 레포 전체 보장을 뜻하지 않을까
레포는 보통 깔끔한 긴 문서 한 편이 아닙니다. 유의미한 코드베이스 분석에는 README, 설정 파일, 테스트, 의존성 목록, CI 오류, stack trace, 검색 결과, 도구 출력까지 함께 들어가는 경우가 많습니다. 모델이 실제로 보는 컨텍스트는 이 모든 것의 합입니다.
따라서 1M 토큰은 매우 큰 작업 세트를 담을 수 있다는 뜻에 가깝습니다. 어떤 저장소든 아무 정리 없이 전부 넣어도 된다는 뜻은 아닙니다. 생성 파일, vendor 디렉터리, 빌드 결과물, 거대한 로그, 중복 문서가 많다면 그 내용을 모두 넣는 것은 컨텍스트를 낭비하고, 정작 중요한 코드와 출력 공간을 밀어낼 수 있습니다.
특히 Opus 4.7에서는 토크나이저 변화도 고려해야 합니다. Anthropic은 새 토크나이저가 같은 텍스트를 처리할 때 이전 모델 대비 최대 약 1.35배 토큰을 쓸 수 있다고 안내합니다.[2]
안정적이라는 말은 어디까지 믿어야 하나
낙관할 근거는 있습니다. Anthropic의 제품 페이지는 Opus 4.7을 복잡한 에이전트형 워크플로, 장시간 작업, 더 큰 코드베이스에 맞는 모델로 설명합니다.[6] 공식 발표도 Opus 4.7이 복잡하고 오래 걸리는 작업을 엄밀하고 일관되게 처리한다고 소개합니다.[
8]
하지만 이 자료들이 증명하는 것은 보다 좁게 해석하는 편이 안전합니다. 즉, Anthropic은 Opus 4.7을 긴 컨텍스트, 긴 워크플로, 큰 코드베이스 작업에 더 적합한 모델로 포지셔닝하고 있습니다. 이것이 곧 모든 초장문 입력, 모든 레포, 모든 에이전트 루프가 한 번에 안정적으로 끝난다는 뜻은 아닙니다.
보안 감사, CI/CD 자동 수정, 대형 리팩터링, 장시간 에이전트 실행처럼 실패 비용이 큰 작업이라면 공식 스펙만 보고 바로 맡기기보다 자신의 레포, 테스트 스위트, 실제 실패 사례를 기준으로 검증하는 것이 안전합니다.[6][
8]
레포 전체를 보고 싶을 때의 실무 절차
1. 파일 목록부터 만들고, 바로 전부 붙여 넣지 마세요
먼저 주요 디렉터리, 사용 언어, 엔트리 포인트, 테스트, 설정 파일, 최근 변경 파일을 파악합니다. 그다음 실제로 컨텍스트에 넣을 파일을 고르는 편이 좋습니다. 보통은 빌드 산출물, generated files, vendor 의존성, 큰 로그, 캐시, 중복 파일을 먼저 제외합니다.
2. Opus 4.7 기준으로 토큰을 다시 계산하세요
Opus 4.6이나 다른 모델에서 계산한 토큰 수를 그대로 믿으면 안 됩니다. Anthropic은 Opus 4.7의 새 토크나이저가 같은 텍스트를 약 1배에서 1.35배 토큰으로 처리할 수 있고, /v1/messages/count_tokens 결과도 달라진다고 설명합니다.[2]
3. 1M 컨텍스트를 끝까지 채우지 마세요
입력이 간신히 들어간다고 해서 좋은 결과가 보장되는 것은 아닙니다. 레포 분석은 보통 모델이 구조 요약, 위험 목록, 수정 제안, 테스트 전략, 패치까지 출력해야 합니다. Opus 4.7의 최대 출력은 128k 토큰이므로, 작업을 설계할 때 출력 예산을 반드시 남겨야 합니다.[2]
4. 큰 레포는 단계별 탐색이 더 현실적입니다
Anthropic은 Opus 4.7을 복잡한 에이전트형 워크플로와 더 큰 코드베이스에 적합한 모델로 설명합니다.[6] 대형 레포라면 처음부터 모든 파일을 넣기보다, 먼저 아키텍처를 파악하고 핵심 파일을 읽은 뒤, 참조 검색, 테스트 확인, 오류 로그 분석을 단계적으로 진행하는 쪽이 더 안정적입니다.
5. 모델이 무엇을 봤고 무엇을 못 봤는지 쓰게 하세요
레포 분석을 맡길 때는 결과물에 다음 항목을 포함시키는 것이 좋습니다. 읽은 파일, 읽지 않은 파일, 주요 가정, 위험 요소, 사람이 확인해야 할 부분, 다음 테스트 단계입니다. 이것이 정답을 보장하지는 않지만, 모델이 일부 컨텍스트를 본 것을 전체 코드베이스를 완전히 이해한 것으로 착각하는 위험을 줄여줍니다.
최종 판단
Claude Opus 4.7은 실제로 1M 토큰 컨텍스트 윈도와 최대 128k 출력 토큰을 지원합니다.[2] Anthropic도 이 모델을 장시간 작업, 에이전트형 워크플로, 더 큰 코드베이스에 적합한 모델로 소개합니다.[
6][
8]
그렇지만 레포 전체를 한 번에 읽을 수 있는지는 1M이라는 숫자만으로 결정되지 않습니다. 레포 전체와 작업 맥락, 도구 출력, 출력 여유가 모두 한도 안에 들어온다면 한 번에 처리할 수 있습니다. 반대로 레포가 너무 크거나 노이즈가 많거나 결과물 자체가 길어야 한다면, 더 신뢰할 만한 방법은 먼저 선별하고, 필요하면 분할하고, 실제 테스트로 결과를 검증하는 것입니다.
