저는 한동안 GPT-4o만 쓰면서 "이걸로 안 되는 건 없다"고 생각했습니다. 그 착각이 깨진 건 계약서 자동 검토 기능을 만들다가였습니다. 페이지가 좀 되는 계약서를 넣으면 모델이 처리를 거부하거나, 문서를 쪼개서 넣으면 조항 간 맥락이 끊겨 누락 오류가 생겼습니다. 그때부터 컨텍스트 윈도우라는 개념을 제대로 들여다보게 됐습니다.
컨텍스트 윈도우, 숫자만 보면 절반만 아는 겁니다
컨텍스트 윈도우란 AI 모델이 한 번의 요청에서 읽고 처리할 수 있는 텍스트의 최대 범위를 의미합니다. 쉽게 말해 모델이 한꺼번에 기억할 수 있는 문서의 양입니다. 이 수치가 클수록 긴 문서를 쪼개지 않고 통째로 처리할 수 있습니다.
현재 시점 기준으로 각 모델의 컨텍스트 윈도우는 GPT-4o가 128,000토큰, Claude 3.7 Sonnet이 200,000토큰, Gemini 1.5 Pro가 최대 1,000,000토큰입니다. 여기서 토큰이란 모델이 텍스트를 처리하는 최소 단위로, 한국어 기준으로는 대략 한 글자에서 두 글자 정도가 하나의 토큰에 해당합니다.
제가 직접 써봤는데, GPT-4o의 128,000토큰은 실무에서 생각보다 빠르게 바닥납니다. 20~30페이지짜리 계약서를 넣고 시스템 프롬프트까지 추가하면 이미 컨텍스트의 절반 가까이 차버리는 경우가 있었습니다. 결국 문서를 청크 단위로 잘라서 넣게 되는데, 문제는 이렇게 자르면 조항과 조항 사이 맥락이 사라지고, 그 빈틈에서 오류가 생긴다는 점입니다. 실제로 저는 이 구조 때문에 고객사 계약서에서 면책 조항 하나가 검토에서 빠지는 상황을 경험했습니다. 숫자만 봐서는 보이지 않는 실무 한계가 있습니다.
Claude로 전환한 건 그 이후였습니다. 200,000토큰이라는 컨텍스트 덕분에 웬만한 계약서는 통째로 넣을 수 있었고, 지시사항을 군더더기 없이 따르는 특성 덕분에 파싱 안정성도 높아졌습니다. 파싱이란 모델의 출력에서 필요한 정보를 구조적으로 추출하는 과정인데, 이게 불안정하면 아무리 긴 문서를 넣어도 결과를 신뢰하기 어렵습니다.
단순 수치 정리를 하자면 GPT-4o(128,000토큰)는 일반적인 문서 처리와 빠른 프로토타입에 적합하고, Claude 3.7 Sonnet(200,000토큰)은 긴 계약서나 법률 문서 등 정밀 분석에 강점이 있으며, Gemini 1.5 Pro(최대 1,000,000토큰)는 대용량 배치 분석에 수치상 우위를 보입니다. 하지만 이 분류가 전부는 아닙니다.
대용량이라고 다 같은 게 아닙니다, Gemini의 현실
Gemini 1.5 Pro의 1,000,000토큰이라는 수치는 처음 봤을 때 솔직히 예상 밖이었습니다. 이 정도면 장편소설 수십 권을 한 번에 넣을 수 있는 수준이니까요. 저는 대용량 회의록 분석 프로젝트에서 처음으로 이 모델을 써봤습니다. 수십 회차에 걸친 회의 전사본을 통째로 밀어 넣고 핵심 의사결정 흐름을 뽑아내는 작업이었습니다.
결론부터 말하면, 숫자가 전부는 아니었습니다. 컨텍스트를 꽉 채워 넣었을 때 응답 레이턴시가 눈에 띄게 길어졌습니다. 레이턴시란 요청을 보내고 응답이 돌아오기까지 걸리는 시간을 말하는데, 실시간 서비스라면 이게 사용자 경험에 직결됩니다. 그리고 더 아쉬웠던 건 소위 Lost in the Middle 현상이었습니다. 컨텍스트의 앞부분과 뒷부분은 잘 반영되는데, 가운데 부분의 내용이 응답에서 충분히 활용되지 않는 경향이 있었습니다.
이 부분에서 저는 중요한 점을 짚고 싶습니다. "컨텍스트 윈도우가 크다 = 더 잘 처리한다"는 등식은 성립하지 않습니다. 물리적으로 입력받을 수 있는 양과, 그 전체를 고르게 잘 활용하는 능력은 다른 문제입니다. 큰 컨텍스트를 '입력받을 수 있는 능력'으로는 Gemini가 앞서지만, '입력된 전체를 고르게 활용하는 능력'에서는 아직 한계가 있었습니다. 스펙시트의 숫자와 실제 서비스 품질 사이의 간극을 여기서 체감했습니다.
한국어 품질과 비용에 대한 현실적인 이야기
한국어 품질에 대해서도 한마디 덧붙이고 싶습니다. "Claude >= GPT-4o > Gemini" 식으로 한 줄로 정리하는 시각도 있는데, 저는 이게 너무 단순화된 측면이 있다고 봅니다. 제 경험상 정보 추출이나 구조화 작업에서는 Claude가 지시를 정확하게 따르는 강점이 두드러지고, 창의적 글쓰기나 자유로운 문체가 필요한 작업에서는 GPT-4o가 더 자연스러운 경우도 있었습니다. 작업 유형에 따라 모델별 특성이 다르게 나타나기 때문에, 한국어 서비스를 만드는 개발자라면 자신의 실제 태스크로 직접 A/B 테스트를 해보는 과정이 반드시 필요합니다. 누군가의 정성적인 평가를 그대로 믿고 모델을 고르는 건 위험합니다.
비용 얘기도 짚고 넘어가야 합니다. 특정 시점의 수치를 제시하는 것은 스냅샷에 가깝습니다. 세 회사 모두 경쟁이 심화되면서 가격을 자주 조정하고 있어서, 특정 숫자보다는 각 제공사의 공식 가격 페이지를 직접 확인하는 습관이 훨씬 실용적입니다. 특히 한국어 서비스를 계획하고 있다면 토큰 비용을 한국어 샘플로 직접 측정해두는 것도 잊으면 안 됩니다. 앞서 이야기했듯 한국어 텍스트는 영어보다 1.5배에서 2배 이상 토큰이 나오는 경우가 많아서, 영어 기준으로 뽑은 비용 추정이 한국어 서비스에는 그대로 적용되지 않습니다.
모델을 나눠 쓰는 게 정답이었습니다
결국 저는 지금 세 모델을 나눠서 쓰고 있습니다. 빠른 프로토타입과 생태계 의존 작업은 GPT-4o, 긴 문서 처리와 파싱 정밀도가 중요한 작업은 Claude, 배치성 대용량 분석은 Gemini로 역할을 분리했습니다. 처음부터 한 모델에 묶이지 않는 구조로 설계해둔 게 나중에 모델을 교체하거나 추가할 때 유연성을 줬습니다. 반대로 특정 모델에 종속된 방식으로 설계하면 모델을 바꿀 때마다 구조 전체를 뜯어야 합니다.
어떤 모델이 '최고'냐는 질문보다, 내 작업에 어떤 모델이 '맞는가'를 따지는 게 훨씬 생산적인 접근입니다. 모델 선택은 한 번 정하고 끝낼 문제가 아닙니다. 모델들의 성능과 가격은 계속 바뀌고 있고, 새로운 모델이 계속 나오고 있습니다. 프로젝트와 함께 계속 재검토해야 할 의사결정입니다.
참고:
OpenAI 모델 문서: https://platform.openai.com/docs/models
Anthropic 모델 문서: https://docs.anthropic.com/ko/docs/about-claude/models
Google Gemini 모델 문서: https://ai.google.dev/gemini-api/docs/models/gemini