1M 컨텍스트가 바꾼 것, 바꾸지 않은 것

결제·정산 팀이 특히 들떴던 이유

컨텍스트 창이 1M 토큰에 도달했다는 소식을 들었을 때, 우리 팀이 유독 반응했던 데는 이유가 있다. 결제와 정산 업무는 구조적으로 '긴 문서를 통째로 다뤄야 하는 일'이다. 하루치 거래 로그, PG사 정산 명세서, 자동화 배치 스크립트의 예외 처리 이력, 가맹점별 수수료 약정서 — 이것들은 수십 페이지에서 수천 줄 규모로 매일 쌓인다. 이전 세대 모델(64K~~128K 컨텍스트)으로 이 파일들을 다룰 때는 반드시 '청킹'이 필요했다. 파일을 3~~5개 조각으로 나눠 순차적으로 넣고, 각 조각의 요약을 다시 합치는 방식이다.

문제는 이 과정에서 맥락이 끊긴다는 점이다. 앞 청크에서 발생한 이상 거래가 뒤 청크 분석에서 누락되는 일이 실제로 있었다. 1M 컨텍스트라면 이 병목이 사라진다. 한국어 기준 약 50~~60만 어절에 해당하는 분량이다. 중소 규모 결제 플랫폼의 일일 정산 파일(거래 건수 10만~~20만 건, 건당 평균 120바이트)은 약 12~~24MB, 토큰으로 환산하면 300만~~600만 토큰이라 전체를 한 번에 넣기는 여전히 어렵다. 그러나 이상 거래가 집중된 시간대 로그나 특정 가맹점의 한 달치 정산 내역은 충분히 커버된다. 이것만으로도 청킹으로 인한 맥락 손실 문제는 사실상 제거할 수 있다.

실제로 달라진 것: 세 가지 구체적 변화

정산 불일치 분석의 맥락 연속성이 살아났다. 이전에는 PG사 정산 파일과 내부 거래 DB를 대조할 때, 청크 경계에서 매칭되어야 할 거래 쌍이 서로 다른 조각에 들어가면 불일치가 누락됐다. 한 달치 정산 파일(약 2만 건, 8MB)을 통째로 넣고 불일치 항목을 추출하는 방식으로 바꾼 뒤, 팀 내 검수에서 검출 건수가 청킹 방식 대비 12~18% 증가했다. 청크 경계 자체가 오류의 원인이었다는 방증이다.

레거시 자동화 코드 분석이 실용적으로 바뀌었다. 우리가 지금도 운영 중인 정산 자동화 배치 코드는 약 15,000줄 규모다. 이전에는 128K 컨텍스트 안에 맞추려고 "어떤 파일을 넣을지"를 판단하는 데만 상당한 시간을 썼다. 이 선별 작업 자체가 비생산적이다. 이제는 코드베이스 전체를 넣고 "이 오류가 발생하는 코드 경로를 추적해줘"라고 바로 시작할 수 있다. 분석 착수까지 준비 시간이 절반 이하로 줄었다.

약관 기반 자동화 규칙 생성 속도가 빨라졌다. 가맹점 약정서나 PG사 정산 약관은 보통 3080페이지다. 이전에는 담당자가 직접 읽고 수수료 예외 조항을 코드에 반영했다. 이제는 전체 문서를 한 번에 넣고 "이 약관에서 수수료 예외 조항을 추출해 자동화 규칙으로 변환 가능한 형태로 정리해줘"라고 할 수 있다. 건당 23시간 걸리던 약관 분석이 30분 이내로 줄었다.

변하지 않은 것: 직접 부딪혀 확인한 현실

컨텍스트가 길어진다고 해서 LLM이 더 정확해지지는 않는다. 이것이 가장 중요한 불변의 사실이다. 실제 사례가 있다. 3개월치 정산 내역(약 6만 건)을 통째로 넣고 "월별 불일치 금액을 집계해줘"라고 요청했을 때, 모델이 특정 월의 취소 거래를 중복 계산해 실제보다 약 340만 원 높은 불일치 금액을 출력했다. 검증 단계가 없었다면 그대로 보고서에 올라갈 뻔했다.

더 위험한 것은 긴 컨텍스트가 만들어내는 '신뢰 착시'다. 방대한 데이터를 처리한 결과니까 맞겠지 싶은 심리가 생긴다. 짧은 컨텍스트 시절에는 청킹과 요약 과정에서 사람이 자연스럽게 개입했다. 전체를 한 번에 넣는 구조에서는 그 개입 기회가 사라진다. "더 많이 위임해도 된다"는 착각이 바로 이 지점에서 생긴다. 컨텍스트 창의 크기는 LLM에게 맡길 수 있는 '판단의 종류'를 바꾸지 않는다. 정보 추출과 패턴 탐색은 맡길 수 있지만, 최종 정산 금액 확정은 여전히 사람의 몫이다.

비용과 지연: 트레이드오프를 숫자로

1M 토큰 입력은 공짜가 아니다. 2025년 기준 주요 모델 입력 단가를 보면, Gemini 1.5 Pro는 $1.25/1M tokens(128K 초과 시 $2.50), Claude 3 Opus는 $15/1M tokens, GPT-4o는 $2.50~$5/1M tokens 수준이다. 비교적 저렴한 모델로도 1M 토큰 호출 1회에 $1.25~$2.50의 입력 비용이 든다. 하루 정산 검증에 이런 호출을 10회 반복하면 월 비용이 $375~$750에 달한다. 연간으로 치면 450~900만 원이다.

지연도 현실적인 제약이다. 1M 토큰 프롬프트의 첫 토큰 응답(TTFT)은 네트워크·모델에 따라 3090초 수준이다. 실시간 결제 이상 탐지처럼 응답 속도가 핵심인 파이프라인에는 사용 자체가 불가능하다. 우리 팀의 현재 운용 기준은 이렇다: **입력 토큰 50K 미만은 일반 호출, 50K300K는 작업 성격에 따라 판단, 300K 초과는 비용·지연을 명시적으로 정당화할 수 있을 때만 사용.** 이 기준을 세운 뒤 LLM 호출 비용이 기존 대비 약 30% 절감됐다.

HEDVION이라면 어떻게 쓸 것인가: 세 가지 실제 시나리오

시나리오 1 — 월말 정산 불일치 자동 리포트. 매월 마지막 영업일, PG사별 정산 파일(평균 약 150K 토큰)과 내부 거래 기록을 하나의 프롬프트로 묶어 불일치 항목을 추출한다. 모델 출력은 반드시 내부 DB 쿼리와 교차검증한 후 담당자가 최종 승인한다. LLM은 찾아주는 역할, 판단은 사람이 한다. 이 원칙을 자동화 파이프라인 설계 단계부터 명문화한다.

시나리오 2 — 약관 변경 감지 및 자동화 규칙 갱신 알림. PG사가 약관을 업데이트할 때마다 이전 버전과 신규 버전 전체(합산 약 60K~100K 토큰)를 넣고 수수료 조항, 정산 주기, 예외 처리 규정 변경 사항을 추출한다. 결과를 바탕으로 자동화 스크립트 수정 항목을 리스트업하고 담당자가 코드 반영 여부를 판단한다. 약관 모니터링 자동화의 '탐지' 레이어로 쓰는 것이 현실적이다.

시나리오 3 — 레거시 배치 코드 오류 추적. 전체 배치 코드베이스(약 15,000줄)를 한 번에 넣고 특정 정산 오류가 발생하는 코드 경로를 추적하게 한다. "어떤 파일을 선별해서 넣을까" 고민하는 시간을 없애고 원인 탐색부터 시작한다. 단, 모델이 제시한 수정 방향은 반드시 로컬 테스트를 거친 뒤 반영한다.

지금 바로 써먹을 실행 지침

일반론이 아니라, 내일 당장 팀 내에 적용 가능한 기준이다.

토큰 예산 기준을 팀 내 명문화하라. 50K / 300K 두 구간을 경계선으로 삼아 호출 승인 기준을 문서로 만들어라. 비용이 보이지 않으면 낭비가 조용히 쌓인다.
LLM 출력에는 반드시 검증 단계를 붙여라. 정산 금액·거래 건수·날짜 범위, 이 세 가지만큼은 LLM 출력을 그대로 쓰지 말고 DB 쿼리로 교차확인하는 단계를 자동화 파이프라인에 명시적으로 넣어라.
"한 번에 넣을 수 있다"와 "넣어야 한다"를 구분하라. 1M 컨텍스트는 옵션이지 기본값이 아니다. 작업별로 실제로 필요한 최소 토큰을 먼저 파악하고 그 기준에서 시작해라.
300K 초과 호출은 실시간 파이프라인에서 분리하라. 배치 전용으로 격리하고, 타임아웃을 90초 이상으로 설정해라. 실시간 응답이 필요한 흐름에 섞이면 전체 파이프라인이 병목된다.
모델이 자신 있게 말할수록 더 의심하라. 방대한 데이터를 처리한 결과일수록 출력이 그럴듯해 보인다. "이 정도면 맞겠지"라는 신뢰가 생기는 순간이 가장 위험하다.

도구가 강력해질수록 원칙은 더 단단하게 유지해야 한다. 1M 컨텍스트는 작업의 준비 비용을 낮춰줬다. 판단 비용은 여전히 우리 몫이다.

— by slecs