분류나 판단처럼 '정해진 보기 중 하나를 고르는' 작업을 언어 모델에 맡길 때, 많은 개발자는 자연스럽게 구조화 출력(Structured Output)을 떠올린다. 모델이 반드시 유효한 JSON만 뱉도록 문법을 제약해 두면 파싱 실패 걱정 없이 결과를 타입 있는 값으로 받을 수 있기 때문이다. 겉으로 보기에는 깔끔한 해법이지만, 이 방식이 내부적으로 어떤 비용을 치르는지는 잘 드러나지 않는다. 원문은 바로 이 지점을 파고들며, '결정 모델(decision model)'이라는 다른 사고방식을 제안한다.
토큰마다 한 번씩 도는 추론
언어 모델의 추론은 크게 두 단계로 나뉜다. 입력 프롬프트를 한 번에 읽어 들이는 프리필(prefill) 단계와, 그 뒤로 출력 토큰을 한 개씩 만들어 내는 생성 단계다. 핵심은 출력이 '한 번에' 나오지 않는다는 데 있다. 입력은 한 번의 패스로 처리되더라도, 유효한 응답을 완성하려면 토큰 하나를 생성할 때마다 다시 순전파(pass)를 돌려야 한다. 원문이 든 예시에서는 최종 출력을 만드는 데 11번의 패스가 필요했다. 구조화 출력으로 JSON 형식을 강제하더라도 이 생성 과정 자체가 사라지지는 않는다. 결국 응답이 길어질수록, 즉 토큰 수가 늘어날수록 지연 시간과 연산 비용이 비례해 커진다. 단지 '결정' 하나를 얻으려는데 중괄호와 따옴표, 키 이름까지 전부 토큰 단위로 생성하고 있다면, 그 비용의 상당 부분은 판단이 아니라 포장에 쓰이는 셈이다.
모든 보기에 확률을 매기는 결정 모델
원문이 말하는 'System one' 결정 모델은 결이 다르다. 허용된 모든 답(allowed answer)에 대해 보정된 확률(calibrated probability)을 추론해 돌려주는 모델이다. 여러 토큰을 순차적으로 뽑아 문장을 완성하는 대신, 가능한 선택지들의 집합 위에서 각 보기가 정답일 확률을 읽어 내는 데 가깝다. 사람에 비유하면, 긴 추론을 거쳐 글로 답을 써 내려가는 방식이 아니라 즉각적이고 직관적인 반응으로 판단을 내놓는 쪽에 해당한다. 출력이 하나의 샘플링된 문자열이 아니라 선택지 전체에 걸친 확률 분포이기 때문에, 단순히 '어떤 답'인지뿐 아니라 '얼마나 확신하는지'까지 함께 얻을 수 있다는 점이 구조화 출력과 결정적으로 다르다.
실무에서 무엇이 달라지나
이 구분은 추상적인 이론이 아니라 아키텍처 선택의 문제다. 스팸 여부 판정, 티켓 라우팅, 감정 분류, 콘텐츠 필터링처럼 답의 후보가 고정되어 있고 그 수가 유한한 작업이라면, 매번 JSON을 토큰 단위로 생성하게 하는 것은 과한 선택일 수 있다. 확률을 직접 돌려받으면 임계값을 조정해 재현율과 정밀도를 튜닝하거나, 확신이 낮은 사례만 사람이나 더 무거운 모델로 넘기는 식의 의사결정 파이프라인을 설계하기도 쉬워진다. 단일 답만 받는 구조에서는 '모델이 얼마나 확신하지 못했는지'라는 중요한 신호가 사라지는데, 결정 모델 관점은 그 신호를 1급 시민으로 다룬다.
물론 한계도 분명하다. 이 접근은 답의 공간이 사전에 열거 가능한 경우에만 성립한다. 자유 형식의 생성이 필요하거나 보기 집합 자체가 유동적인 작업에는 맞지 않는다. '보정된 확률'이라는 표현도 주의가 필요하다. 모델이 내놓는 확률값이 실제 정답률과 일치한다는 보장은 저절로 따라오지 않으며, 별도의 보정 작업과 검증 없이 수치를 그대로 신뢰해서는 안 된다. 또한 원문도 스스로 밝히듯 11번의 패스라는 수치는 투기적 디코딩(speculative decoding)을 비롯한 추론 최적화 기법을 고려하지 않은 값이다. 실제 서비스에서는 이런 기법들이 생성 비용의 격차를 어느 정도 줄여 준다.
그럼에도 이 글의 가치는 비용 수치 자체보다 관점의 전환에 있다. 언어 모델을 무조건 '문장을 생성하는 기계'로만 쓰는 대신, 필요한 작업이 본질적으로 분류나 판단이라면 그에 맞는 출력 형태를 처음부터 설계하라는 제안이다. 당장 쓰는 추론 스택을 바꾸기 어렵더라도, 내가 모델에 요구하는 것이 '문자열'인지 '결정'인지를 구분해 보는 것만으로도 지연 시간과 비용, 그리고 신뢰도 관리 방식을 다시 점검할 단서가 된다.