2026년 1분기 LLM 시장 정리: 공급, 가격, 컨텍스트

왜 LLM 시장 변화가 결제·정산 현장에 직결되는가

많은 개발팀이 LLM 시장 동향을 "흥미로운 IT 트렌드" 수준으로 모니터링한다. HEDVION에서는 다르게 읽는다. LLM은 이미 프로덕션 파이프라인 안에 들어와 있다. 정산 오류 탐지 로직의 일부를 모델이 처리하고, 가맹점 문의 자동 분류에 소형 모델이 붙어 있으며, 대사(reconciliation) 예외 케이스에 대한 1차 판단을 모델에 위임한다. 이 맥락에서 "토큰 비용이 절반으로 내려갔다"거나 "새 모델이 나왔다"는 뉴스는 단순한 기술 정보가 아니다. 월간 API 비용 구조, 특정 업무 자동화 가능성, 시스템 의존도 리스크와 직결된다.

1분기 시장 변화를 팀 내에서 검토하며 가장 먼저 던진 질문은 "멋지다"가 아니라 "지금 구조에서 이걸 어떻게 써먹을 수 있고, 어디서 위험해질 수 있는가"였다. 결제·정산 시스템에서 LLM은 UX 기능이 아니라 운영 로직의 일부다. 시장이 바뀌면 운영 비용과 리스크 구조가 함께 바뀐다.

공급 다양화: 선택지 증가는 의사결정 비용 증가다

2025년 초만 해도 프로덕션에 실제로 쓸 만한 모델 API는 OpenAI, Anthropic, Google 정도가 현실적 선택지였다. 이제는 Azure OpenAI, AWS Bedrock, Google Vertex를 통한 기업 배포 옵션이 안정화됐고, Mistral·Cohere 계열의 특화 소형 모델도 특정 태스크에서 충분히 경쟁력 있는 수준에 올라왔다. 오픈소스 Llama 계열을 자체 호스팅하는 선택지도 현실적인 논의 대상이 됐다.

그런데 선택지가 많아진 게 단순히 좋은 소식만은 아니다. 우리 팀이 직접 겪은 문제는 모델 평가 비용이다. "이 태스크에 어떤 모델이 맞는가"를 검증하려면 평가 데이터셋을 만들고, 프롬프트를 튜닝하고, 비용-품질 트레이드오프를 정량화해야 한다. 모델 후보 수가 두 배가 되면 이 작업도 두 배가 된다. 소수정예 팀일수록 평가에 쓸 수 있는 시간이 제한적이다. 우리가 내린 결론은 "모든 모델을 평가하지 않는다"는 것이다. 범용 추론에는 상위 2개 모델로 고정하고, 분류나 구조화 태스크에서만 소형 모델 후보를 제한적으로 검토한다. 공급 다양화의 또 다른 함의는 벤더 리스크다. 결제·정산 시스템은 안정성이 최우선이다. API가 갑자기 서비스 중단되거나, 요금 정책이 3배 오르거나, 출력 형식이 조용히 바뀌는 일은 실제로 일어난다. 하나의 모델 API에 비즈니스 로직이 단단히 묶여 있으면, 그 순간 대응 비용은 단순한 모델 교체가 아니라 전체 파이프라인 재검토로 번진다.

가격 하락: "쓸 수 있게 됐다"는 것의 구체적 의미

수치를 구체적으로 보자. GPT-4 터보 계열 기준으로 2024년 초 입력 토큰 1M당 약 $10였던 가격이 2025년 말 기준 $2~~3 수준으로 내려왔다. Claude Haiku, Gemini Flash 계열 소형 모델은 $0.1~~0.3/1M 토큰 수준까지 떨어졌다. 이 격차는 단순한 숫자가 아니다. 우리 팀이 작년에 검토하다 보류했던 기능 중 하나가 정산 이상 거래 1차 분류 자동화였다. 당시 추정 비용이 월 $400~~600 수준이었는데, 이 정도면 해당 업무에 투입되는 사람의 시간 대비 ROI가 애매했다. 지금 가격 구조로 동일 파이프라인을 재설계하면 월 $80~~120 수준으로 내려온다. 이 차이가 "보류"와 "도입" 사이의 경계를 바꾼다.

단, 중요한 트레이드오프가 있다. 저렴한 모델이 모든 작업에서 충분하지 않다. 우리가 테스트한 결과, 단순 분류(정상/의심/오류) 태스크에서는 소형 모델이 대형 모델과 5% 이내 차이였지만, "이 거래가 약관 위반인지 판단하라"는 식의 맥락 추론이 필요한 태스크에서는 오류율이 3배 이상 벌어졌다. 비용이 싸다고 무조건 소형 모델로 교체하면 후처리 비용이 오히려 늘어난다. 태스크 유형별로 모델 티어를 달리 가져가는 라우팅 설계가 필요하다.

컨텍스트 확장: 숫자가 아니라 설계 능력이 관건

100만 토큰 컨텍스트 윈도우가 상위 모델의 사실상 표준에 가까워진 2026년 1분기, 결제 현장에서 이 변화가 가장 직접적으로 와닿는 건 대량 트랜잭션 로그 처리다. 하루 수만 건의 거래 로그를 한꺼번에 모델에 넣고 "이상한 패턴이 있는가"를 물을 수 있다는 건 이론적으로 매력적이다.

그런데 실제로 해보면 문제가 생긴다. 우리가 실험한 케이스에서 5만 건, 약 800K 토큰 분량의 로그를 단일 컨텍스트에 넣었을 때, 모델이 앞쪽 데이터를 참조하지 않는 '중간 소실(lost-in-the-middle)' 현상이 뚜렷이 나타났다. 중요한 이상 거래가 로그의 앞 10% 구간에 있으면 탐지율이 크게 떨어졌다. 이는 모델 버그가 아니라 긴 컨텍스트에서 일반적으로 관찰되는 특성이다. 해결책은 "더 긴 컨텍스트 모델을 쓰는 것"이 아니라 컨텍스트 구성 방식을 바꾸는 것이었다. 중요도가 높은 거래를 앞부분에 배치하거나, 로그를 청크로 나눠 병렬 처리 후 결과를 집계하거나, 요약-심층분석 2단계 구조를 쓰는 식이다. 컨텍스트 윈도우 크기는 이제 제약 조건이 아니라 설계 변수다. 얼마나 넣을 수 있는지보다 어떻게 배치하는지가 품질을 결정한다.

HEDVION 팀이라면: 가맹점 이의 신청 자동화 시나리오

1분기에 우리가 실제로 논의한 시나리오를 구체적으로 공유한다. 가맹점 정산 이의 신청 자동 처리 파이프라인이다.

기존 구조는 이렇다. 가맹점이 이메일·채널로 이의 신청 → 담당자가 내용 파악 → 정산 데이터 조회 → 처리 또는 에스컬레이션. 건당 평균 처리 시간 약 15분, 하루 30~50건 수준이다.

LLM 파이프라인 설계안은 4단계로 구성된다. (1) 소형 모델로 이의 신청 유형 분류(단순 오기재 / 금액 불일치 / 정책 이의 등 7개 유형), (2) 유형별로 정산 DB에서 관련 데이터를 자동 조회, (3) 중형 모델로 처리 가능 여부 판단 및 초안 응답 생성, (4) 담당자 최종 승인 후 발송. 이 설계에서 핵심은 분류(1단계)와 판단(3단계)를 분리한 것이다. 1단계는 소형·저렴 모델로 충분하고, 3단계는 컨텍스트 이해가 필요하므로 중형 이상을 쓴다. 현재 가격 구조에서 3단계도 월 $100 이하로 운영 가능하다. 그리고 이 구조는 어느 단계에서도 모델을 교체할 수 있도록 추상화 레이어를 둔다—나중에 더 좋은 소형 모델이 나오면 1단계만 바꾸면 된다.

지금 당장 써먹을 수 있는 실행 시사점

시장 변화를 정리한 뒤 팀이 정한 실행 항목은 다음과 같다. 이 중 일부는 이미 실행 중이다.

1. 모델 추상화 레이어를 먼저 만들어라. LLM 호출 코드에 특정 모델명을 하드코딩하지 않는다. 환경 변수 또는 설정 파일에서 모델을 주입하고 인터페이스를 통일한다. 교체 비용이 거의 0에 가까워야 시장 변화에 유연하게 대응할 수 있다.

2. 태스크별 허용 오류율과 비용 상한을 문서화하라. "이 태스크에서 허용 가능한 오류율은 X%, 처리 비용 상한은 월 $Y"를 미리 정해두면 모델 선택 논의가 의견이 아니라 데이터로 결정된다. 없으면 새 모델이 나올 때마다 같은 토론을 반복하게 된다.

3. 긴 컨텍스트는 '설계 실험'으로 접근하라. 무작정 로그 전체를 넣어보는 게 아니라, 정보 배치 위치를 바꿔가며 탐지율이 어떻게 달라지는지 측정한다. 컨텍스트 구성 자체를 하나의 엔지니어링 문제로 취급해야 한다.

4. 가격 하락을 비용 절감이 아니라 기능 확장으로 써라. 기존 기능의 API 비용을 줄이는 것도 의미 있지만, 작년에 "비용 때문에 안 된다"고 접었던 기획을 다시 꺼내보는 게 더 가치 있다. 우리 팀은 이 목록을 분기마다 재검토한다.

5. 벤더 리스크 시뮬레이션을 분기 1회 돌려라. "지금 쓰는 API가 갑자기 2배가 되면 어떻게 할 것인가"를 미리 설계해두지 않으면, 실제로 그런 상황이 왔을 때 패닉 대응이 된다. 대안 모델로의 전환 비용을 미리 측정해두는 것이 보험이다.

시장이 빠르게 바뀌는 건 준비된 팀에게는 기회지만, 준비가 안 된 팀에게는 노이즈가 된다. 결국 중요한 건 어떤 모델을 고르느냐가 아니라, 어떤 모델로도 교체할 수 있는 구조를 유지하느냐다.

— by mings