Claude Opus 5.5에서 눈에 잘 띄는 숫자 중 하나는 100만 토큰 컨텍스트 윈도우입니다. Anthropic 공식 문서 기준으로 Opus 5.5는 1M 토큰의 컨텍스트와 최대 128K 토큰 출력을 지원하며, adaptive thinking이 항상 활성화됩니다.

숫자만 보면 이런 생각이 들 수 있습니다.

“이제 저장소 전체를 통째로 넣으면 되는 것 아닌가?”

하지만 실전에서는 긴 컨텍스트를 기억 용량처럼 이해하면 오히려 문제가 생깁니다.

컨텍스트 윈도우는 데이터 창고가 아닙니다

컨텍스트는 현재 요청을 처리할 때 모델이 참고할 수 있는 작업 공간에 가깝습니다. 많은 정보를 넣을 수 있다고 해서 모든 정보가 같은 중요도로 처리되거나, 서로 충돌하는 요구사항이 자동으로 정리되는 것은 아닙니다.

예를 들어 대형 프로젝트에는 이런 정보가 동시에 존재합니다.

  • 현재 코드
  • 오래된 README
  • 최신 ADR(Architecture Decision Record)
  • 과거 이슈의 논의
  • 테스트 코드
  • 사용하지 않는 예전 구현

모두 관련 있어 보이지만 서로 다른 시점의 진실을 담고 있을 수 있습니다.

긴 컨텍스트가 커질수록 중요한 능력은 ‘더 많이 넣기’보다 무엇을 신뢰해야 하는지 알려주는 것입니다.

CodeBridge 미니 실험: 3개의 충돌하는 요구사항을 일부러 넣어보기

작은 샘플 프로젝트나 본인의 저장소에서 다음 실험을 해볼 수 있습니다.

먼저 같은 기능에 대해 서로 다른 지시가 담긴 파일 3개를 준비합니다.

README.md        : 사용자는 이메일로 로그인한다.
docs/auth-v2.md  : 이메일 + 패스키를 지원한다.
TODO-old.md      : 소셜 로그인만 남기고 이메일 로그인을 제거한다.

그 다음 바로 구현을 시키지 말고 이렇게 요청합니다.

이 저장소에서 로그인 요구사항을 구현하려고 한다.
코드를 수정하기 전에 서로 충돌하거나 오래되었을 가능성이 있는 요구사항을 찾아라.

각 주장마다:
- 근거 파일
- 마지막 수정 시점(알 수 있다면)
- 서로 충돌하는 주장
- 구현 전에 사람에게 확인할 질문
을 먼저 정리해라.

이 실험에서 볼 것은 정답 하나가 아닙니다.

  • 충돌을 발견하는가?
  • 파일을 단순히 모두 합쳐버리지 않는가?
  • 최신 문서를 무조건 진실로 가정하지 않는가?
  • 구현 전에 불확실성을 표면으로 끌어올리는가?

긴 컨텍스트의 가치는 정보량이 아니라, 많은 정보 속에서 불확실성을 관리할 때 드러납니다.

Adaptive thinking도 같은 관점으로 봐야 합니다

Opus 5.5는 adaptive thinking을 항상 사용합니다. 사용자가 매번 “깊게 생각해”라고 주문하지 않아도 모델이 작업에 맞게 추론을 조절하도록 만든 접근입니다.

하지만 이 역시 완료 조건을 대신해주지는 않습니다.

예를 들어 “이 코드를 리팩터링해줘”보다 아래처럼 검증 가능한 조건을 주는 편이 좋습니다.

목표: PaymentService의 중복 로직 제거

완료 조건:
- public API 시그니처 유지
- 기존 테스트 전부 통과
- 새 의존성 추가 금지
- 수정 파일 목록과 이유 요약
- 테스트하지 못한 항목은 별도로 표시

좋은 모델을 쓰더라도 완료 정의가 없으면 ‘그럴듯한 수정’과 ‘끝난 작업’을 구별하기 어렵습니다.

100만 토큰을 언제 쓰면 좋을까?

큰 컨텍스트가 특히 유용한 상황은 다음과 같습니다.

  • 여러 모듈에 걸친 코드 마이그레이션
  • 긴 기술 문서와 코드의 교차 검토
  • 대규모 로그와 설정의 원인 분석
  • 여러 버전의 요구사항 비교
  • 장시간 이어지는 에이전트 작업

반대로 파일 몇 개만 보면 되는 버그를 잡는데 저장소 전체를 넣는 것은 비용과 집중도 측면에서 이득이 적을 수 있습니다.

긴 컨텍스트에서 자주 생기는 실패 패턴

1. 관련 없는 자료까지 모두 넣기

“혹시 필요할까 봐”라는 이유로 모든 것을 넣으면 중요한 정보와 잡음의 차이가 흐려집니다.

2. 우선순위를 알려주지 않기

코드와 문서가 충돌할 때 무엇이 더 신뢰할 만한지 설명하지 않으면 모델이 임의로 해석할 수 있습니다.

3. 한 번의 거대한 요청으로 끝내려 하기

분석 → 계획 → 구현 → 검증을 한 요청에 몰아넣으면 중간에 잘못된 가정이 생겼을 때 수정 비용이 커집니다.

이 부분은 루프 엔지니어링과 하네스 엔지니어링의 관점과도 연결됩니다.

결론: 컨텍스트가 커질수록 ‘정리하는 능력’이 더 중요해집니다

Claude Opus 5.5의 1M 컨텍스트는 분명 강력한 도구입니다. 다만 “이제 모든 것을 한 번에 넣어도 된다”는 의미로 받아들이면 장점을 제대로 쓰기 어렵습니다.

오히려 컨텍스트가 커질수록 다음 질문이 중요합니다.

무엇이 최신인가? 무엇이 신뢰할 수 있는가? 무엇이 서로 충돌하는가? 무엇을 먼저 확인해야 하는가?

좋은 긴 컨텍스트 사용법은 자료를 최대한 많이 넣는 기술보다, 큰 작업을 검증 가능한 흐름으로 바꾸는 기술에 가깝습니다.

함께 읽으면 좋은 글

참고 자료