100만 토큰 컨텍스트 윈도, 어디까지 맡길 수 있을까

100만 토큰 컨텍스트 윈도의 가치는 단순히 입력 칸이 커졌다는 데 있지 않습니다. 원래는 여러 번 나눠 넣어야 했던 자료를 같은 분석 범위 안에 올릴 수 있다는 점이 핵심입니다. 긴 계약서 한 편, 여러 건의 연구 보고서, 정리된 코드 저장소가 대표적인 예입니다. 공개 보도에 따르면 GPT-4.1 계열의 3개 모델은 최대 100만 컨텍스트 토큰을 처리할 수 있으며, TestingCatalog도 대형 문서와 대형 codebase를 이 능력의 활용 방향으로 설명했습니다.

하지만 이는 용량의 돌파구이지 신뢰도의 보증서는 아닙니다. 한 기술 분석 글은 GPT-4.1이 긴 컨텍스트 처리와 정보 찾기에 맞춰 훈련됐다고 설명하지만, 다른 분석은 1M 컨텍스트가 실제 업무 흐름 전체를 해결하기에는 여전히 부족할 수 있다고 지적합니다. 그래서 실무에서 던져야 할 질문은 “들어가느냐”보다 “자료가 깨끗한가, 질문이 충분히 좁은가, 결과를 원문으로 되짚을 수 있는가”에 가깝습니다.

빠른 판단: 세 가지 자료를 한 번에 읽힐 수 있나

자료 유형	1M 컨텍스트에 한 번에 넣을 가능성	잘 맞는 작업	그대로 넣기 애매한 경우
단일 계약서 전체	대체로 좋은 후보	조항 요약, 위험 조항 표시, 지급·해지 의무 정리, 버전 차이 비교	부속 문서가 지나치게 많거나 OCR 품질이 낮을 때, 공식 법률 의견이 필요할 때
연구자료 묶음	자주 가능	여러 문서 비교, 공통 결론 추출, 모순점 찾기, 근거 표 만들기	출처 품질이 들쭉날쭉하거나, 문장 단위 추적이 필수이거나, 자료가 계속 갱신될 때
코드 저장소, 즉 repo	크기와 정리 상태에 따라 다름	아키텍처 파악, 버그 위치 추정, API 동작 추적, 리팩터링 후보 찾기	대형 monorepo, 의존성 디렉터리, generated files, 바이너리 자산, 테스트 데이터가 많을 때

핵심은 1M 컨텍스트가 전체를 한눈에 보게 할 가능성을 키운다는 점입니다. 그러나 원본을 아무 정리 없이 통째로 올리는 것이 항상 최선은 아닙니다. 특히 코드 저장소는 공개 자료에서 대형 codebase가 활용 대상으로 언급되지만, 그것이 정리되지 않은 모든 프로젝트를 한 번에 밀어 넣어도 된다는 뜻은 아닙니다.

계약서: 읽힐 수는 있어도, 질문은 검토표처럼 좁혀야 한다

단일 계약서는 100만 토큰 컨텍스트 윈도에 비교적 잘 맞는 자료입니다. 계약서는 보통 장, 조항, 정의, 부속 문서처럼 구조가 있고, 공개 자료에서도 대형 문서가 1M 컨텍스트의 활용 대상으로 언급됩니다.

다만 위험은 모델이 못 읽는 데서만 생기지 않습니다. 더 흔한 문제는 그럴듯하지만 원문으로 확인하기 어려운 요약이 나오는 것입니다. 따라서 “이 계약서에 문제 있어?”처럼 묻기보다, 위치·근거·위험 구분을 강제로 요구하는 편이 낫습니다.

조항 번호를 기준으로 지급 의무, 해지권, 책임 제한, 비밀유지 의무, 계약 위반 시 효과를 정리해 주세요. 각 항목에는 원문 일부를 함께 붙이고, 법률 전문가 확인이 필요한 부분을 별도로 표시해 주세요.

이런 식의 요청은 모델이 먼저 조항으로 돌아가게 만듭니다. 법무, 구매, 영업, 사업 개발 업무에서 긴 컨텍스트는 초안 검토와 쟁점 정리에 유용할 수 있지만, 최종 법률 판단을 대신하는 도구로 쓰기는 어렵습니다.

연구자료: 한 편씩 요약하기보다 문서 사이를 비교할 때 강하다

연구자료는 단일 요약보다 교차 비교에서 가치가 큽니다. 여러 보고서가 같은 결론을 지지하는지, 가정이 다른지, 수치가 충돌하는지, 각 연구의 한계가 무엇인지 한 번에 보는 작업이 대표적입니다. 1M 컨텍스트의 장점은 각 문서를 따로 요약한 뒤 사람이 이어 붙이는 수고를 줄이고, 여러 문서를 같은 질문 아래 놓을 수 있다는 데 있습니다.

잘 맞는 요청은 다음과 같습니다.

1. 여러 보고서를 같은 기준의 비교표로 정리하기
2. 모든 문서가 공통으로 지지하는 결론만 추리기
3. 서로 충돌하는 정의, 가정, 결과를 표시하기
4. 각 연구의 방법, 표본, 한계, 남은 질문을 뽑기
5. 다음 조사나 인터뷰에서 물어볼 질문 만들기

연구자료를 넣을 때는 먼저 근거 행렬을 요구하는 것이 좋습니다. 결론마다 출처 문서, 위치, 원문 발췌를 붙이게 하는 방식입니다. 긴 컨텍스트는 여러 자료를 동시에 참고할 기회를 키우지만, 외부 분석이 지적하듯 1M 컨텍스트가 검색, 분할 처리, 사람의 확인을 완전히 대체하지는 않습니다.

코드 저장소: ZIP째 올리기 전에 가지치기부터

코드 저장소는 1M 컨텍스트가 가장 매력적으로 보이는 영역 중 하나입니다. TestingCatalog는 대형 codebase와 대형 문서를 1M 컨텍스트의 활용 대상으로 함께 언급했고, 기술 분석 글도 GPT-4.1이 긴 컨텍스트 안에서 이해하고 정보를 찾도록 훈련됐다고 설명했습니다.

문제는 코드 저장소의 잡음 밀도가 높다는 점입니다. 모델이 실제로 필요한 것은 모든 파일이 아니라, 작업과 관련된 아키텍처, 진입점, 설정, 핵심 모듈, 오류 단서인 경우가 많습니다. 저장소를 통째로 올리면 컨텍스트 공간을 무관한 파일에 쓰게 될 수 있습니다.

보통은 먼저 제외하거나 뒤로 미루는 편이 좋은 항목들입니다.

• node_modules/, vendor/ 같은 외부 의존성 디렉터리
• 문제 자체가 생성 결과가 아닌 한, 대형 generated files
• build artifacts와 임시 출력물
• 바이너리 파일, 이미지, 모델 가중치
• 대량의 fixture, snapshot, 테스트 데이터
• 작업과 무관한 과거 출력, 백업 파일, 임시 파일

더 안정적인 순서는 이렇습니다. 먼저 디렉터리 트리, README, 아키텍처 문서, 주요 설정 파일을 넣습니다. 그다음 작업과 관련된 핵심 코드를 추가합니다. 마지막으로 오류 메시지, 재현 절차, 실패한 테스트 로그, 기대 동작을 붙입니다. 이렇게 해야 모델이 저장소의 구조를 먼저 잡고, 필요한 코드 조각을 그 구조 안에서 해석하기 쉽습니다.

흔한 오해 세 가지

1. 1M 컨텍스트는 모든 자료를 다 넣으라는 뜻이 아니다

100만 토큰 한도는 대형 문서와 codebase 작업을 더 현실적으로 만들지만, 자동으로 잡음을 걸러주지는 않습니다. 중복 문단, 생성 파일, 의존성, 스캔 오류, 작업과 무관한 첨부가 많으면 모델의 주의가 낮은 가치의 자료로 흩어질 수 있습니다.

2. 모델 한도와 내가 쓰는 플랫폼 한도는 다를 수 있다

모델이 1M 컨텍스트를 지원한다는 말과 내가 쓰는 API, 클라우드 배포, 제품 화면에서 같은 조건으로 1M을 쓸 수 있다는 말은 다릅니다. Microsoft Q&A에는 Azure OpenAI에서 gpt-4.1을 사용할 때 1M보다 적은 토큰에서도 context window exceeded 오류를 겪었다는 사용자 보고가 있습니다. 이 사례는 모든 환경에 대한 일반 결론이라기보다, 배포 방식과 제품 레이어에 따라 실제 한도가 달라질 수 있다는 경고로 보는 편이 적절합니다.

3. 긴 컨텍스트는 완벽한 검색기가 아니다

자료를 컨텍스트에 넣었다는 것은 모델이 그 자료를 참고할 기회가 있다는 뜻이지, 반드시 모든 핵심 조각을 안정적으로 찾아낸다는 뜻은 아닙니다. GPT-4.1의 1M 컨텍스트를 다룬 비판적 글도 이 능력을 인상적이지만 실제 업무 사례를 모두 감당하기에는 부족하다고 평가했습니다.

권장 흐름: 정리 → 증거 → 결론

계약서, 연구자료, 코드 저장소를 긴 컨텍스트에 넣는다면 다음 순서가 안전합니다.

1. 먼저 토큰을 어림잡지 말고 세어본다. 페이지 수, 파일 수, MB 용량만으로는 부족합니다. 언어, 서식, 코드, OCR 상태에 따라 토큰 수가 크게 달라집니다.
2. 자료를 먼저 청소한다. 중복 내용, 무관한 첨부, 생성 파일, 의존성 디렉터리, 스캔 잡음, 과거 출력물을 빼거나 뒤로 미룹니다.
3. 구조를 살린다. 문서는 제목, 페이지, 문단, 조항 번호를 유지하고, 저장소는 경로, 파일명, 디렉터리 트리를 유지합니다.
4. 결론보다 증거를 먼저 요구한다. 모델이 조항, 문단, 파일 경로, 코드 조각을 먼저 나열하게 한 뒤 해석을 요청합니다.
5. 질문을 좁힌다. “전체를 보고 문제를 찾아줘”보다 “지급 조항 충돌을 찾아줘”, “8개 연구의 결론 차이를 비교해줘”, “이 오류와 관련된 모듈을 좁혀줘”가 낫습니다.
6. 위험도가 높은 결과는 나눠 검증한다. 계약, 재무, 의료, 보안, production code 변경은 한 번의 긴 컨텍스트 출력만으로 결정하지 않는 편이 좋습니다.

언제 분할 처리나 검색을 써야 하나

자료가 자주 갱신되거나, 문장 단위 인용 추적이 필요하거나, 버전별 차이를 반복 비교해야 하거나, 저장소가 너무 커서 무관한 모듈이 많다면 긴 컨텍스트만으로 밀어붙이는 방식이 최선이 아닐 수 있습니다. 이때는 1M 컨텍스트를 전체 이해를 위한 층으로 쓰고, 검색, 분할 요약, 테스트 로그, 사람의 리뷰를 함께 붙이는 편이 현실적입니다. 이는 1M 컨텍스트가 강력하지만 실제 업무 흐름의 완전한 해법은 아니라는 기존 분석의 경고와도 맞닿아 있습니다.

실무 결론

• 단일 계약서 전체: 대체로 가능하다. 다만 조항 번호, 원문 발췌, 위험 분류를 함께 요구해야 한다.
• 연구자료 묶음: 자주 가능하다. 여러 문서의 공통 결론, 차이, 모순점을 비교하는 데 특히 적합하다.
• 코드 저장소 전체: 정리된 소·중형 프로젝트나 명확한 작업일 때만 권할 만하다. 대형 monorepo, 의존성 디렉터리, 생성 파일이 많다면 먼저 선별하거나 검색 기반 흐름을 쓰는 편이 낫다.
• 들어간다고 곧 믿을 수 있는 것은 아니다. 1M 컨텍스트가 해결하는 것은 더 많은 자료를 같은 장에 올리는 문제다. 안정적으로 찾고, 인용하고, 판단하는 문제는 여전히 프롬프트 설계, 증거 추출, 분할 검증, 사람의 확인에 달려 있다.