제약 디코딩(Constraint Decoding)의 정의와 강제성

제약 디코딩을 적용하면 거대언어모델(LLM)이 정의된 제약 조건을 벗어난 결과물을 내놓는 것이 수학적으로 불가능해진다. 이는 프롬프트에 특정 형식을 요청하는 수준을 넘어, 모델이 다음 토큰(Token)을 선택하는 단계에서 물리적인 제어를 가해 규칙을 강제하는 방식이다. 제약 디코딩은 구조화된 생성(Structured Generation) 또는 가이드 디코딩(Guided Decoding)이라고도 하며, 출력의 형식을 강제하여 파싱 에러를 제거하고 시스템 안정성을 확보한다.

제약 조건은 데이터 스키마, 문법, 정규표현식(Regex)으로 정의된다. 데이터 스키마는 데이터의 구조와 타입, 필수 항목을 정의한 설계도이며, 정규표현식은 특정한 규칙을 가진 문자열의 집합을 표현하는 형식 언어다. 모델은 텍스트를 생성하는 매 순간 이 규칙들을 대조하며, 허용되지 않은 문자가 선택될 확률을 수학적으로 제거한다. 이를 통해 JSON 응답 앞뒤에 불필요한 설명을 덧붙이는 현상을 원천적으로 차단한다.

기존의 프롬프트 방식은 "마크다운 없이 JSON으로만 출력하라"는 지시어에 의존했다. 하지만 이는 모델의 확률적 특성 때문에 지시를 무시하고 서술형 문장을 포함하는 등 데이터 파싱 에러를 유발할 가능성이 있다. 제약 디코딩은 출력 가능한 토큰 목록에서 규칙에 어긋나는 항목을 완전히 삭제하여 오답의 경로를 없애는 제어 방식이다. 확률 기반의 생성 모델에 결정론적인 필터를 씌워 출력의 일관성을 보장한다.

이러한 강제성은 LLM의 출력이 다음 파이프라인의 입력값으로 사용되어 엄격한 타입 체크가 필요한 환경에서 필수적이다. 데이터 타입 불일치로 발생하는 런타임 오류는 서비스 중단으로 이어질 수 있으며, 이를 방지하기 위한 후처리 검증 로직은 시스템 복잡도를 높인다. 제약 디코딩은 모든 토큰이 사전에 정의된 문법 체계 내에 존재함을 보장함으로써 후처리 비용을 줄이고, 생성 AI를 예측 가능한 소프트웨어 컴포넌트로 변환한다.

유한 상태 기계(FSM)와 로짓 마스킹의 작동 원리

추론 시작 전 단계에서 타겟 제약 조건을 컴파일하여 유한 상태 기계(FSM, 정해진 상태 사이를 이동하며 동작을 제어하는 장치)를 구축한다. 파이썬의 Pydantic 모델 같은 데이터 검증 도구로 제약 조건을 정의하면, 이를 기반으로 토큰 생성의 허용 범위를 결정하는 상태 제어 장치가 만들어진다. FSM은 현재까지 생성된 텍스트의 상태를 추적하며, 다음에 올 수 있는 유효한 토큰 목록을 실시간으로 계산하여 제공한다. 사전 컴파일을 통해 제약 조건을 상태 기계 형태로 변환했기에 추론 시 매번 규칙을 다시 계산할 필요가 없다.

LLM은 다음 토큰을 예측하는 단계에서 어휘집에 포함된 모든 후보 토큰에 대해 가공되지 않은 점수인 로짓(Logits) 벡터를 생성한다. FSM이 제공한 허용 토큰 목록(화이트리스트)을 기준으로, 목록에 포함되지 않은 모든 토큰의 로짓 값은 마이너스 무한대(`-inf`)로 설정한다. 로짓 값이 마이너스 무한대가 되면 이후 확률 계산 과정에서 해당 토큰이 선택될 확률은 수학적으로 0이 된다. 모델이 내부적으로 높은 점수를 부여한 토큰이라도 화이트리스트에 없다면 선택지에서 배제되는 마스킹 과정이 작동하는 것이다.

마스킹 과정을 통해 살아남은 토큰들에 대해서만 소프트맥스(Softmax) 정규화와 샘플링 과정이 진행된다. 이 단계에서는 온도(Temperature)나 Top-p, Top-k 같은 기존 샘플링 파라미터가 적용되어 최종 토큰을 선택한다. 제약 조건에 어긋나는 토큰들은 이미 로짓 단계에서 제거되었으므로, 모델은 허용된 범위 내에서만 확률적인 선택을 내리게 된다. 결과적으로 모델의 언어 생성 능력은 유지하면서 출력 형태는 정의된 스키마를 완벽하게 따르게 된다.

'믿음의 생성'과 '프로그램 방식 생성'의 대비

기존의 LLM 생성 과정은 프롬프트를 전달한 뒤 원하는 결과가 출력되기를 기대하는 '믿음의 행위(Act of faith)' 방식으로 작동한다. 사용자가 출력 형식을 상세히 지정하더라도 모델이 이를 준수할지 알 수 없는 확률적 불확실성이 상존하며, 이는 복잡한 구문이나 엄격한 형식이 필요한 작업에서 예기치 못한 오류를 발생시킨다.

제약 디코딩은 텍스트 생성을 프롬프트와 인터리브(Interleaved, 교차 배치)된 하나의 프로그램으로 정의한다. 구문 유지에 필수적인 특정 문자를 미리 고정(Lock down)하여 모델이 변경할 수 없게 만들고, 모델은 그 사이의 빈칸만을 채우도록 제한하는 구조다. 생성 과정에서 규칙이 적용되는 지점과 모델이 자유롭게 생성하는 지점을 교차 배치함으로써, 텍스트 생성을 단순한 확률 예측이 아니라 정해진 규칙을 따라가는 프로그램의 실행 과정으로 전환한다.

모든 가능한 토큰의 확률을 매 단계 필터링하면 추론 지연 시간(Latency)이 증가할 위험이 있다. 이를 방지하기 위해 outlines 라이브러리는 LLM의 어휘집이 정적 구조라는 점을 이용해 어휘집을 사전 컴파일(Pre-compile)한다. 사전 컴파일된 상태 기계는 추론 시점에 전체 어휘 목록을 일일이 조회하지 않고, 현재 상태에서 허용되는 토큰만을 즉각적으로 식별한다. 이를 통해 제약 조건을 엄격하게 적용하면서도 추론 시 발생하는 지연 시간 오버헤드를 낮춘다.

outlines 라이브러리를 이용한 Pydantic 기반 구현

outlines 라이브러리는 Pydantic 모델, JSON 스키마, 정규표현식을 통해 LLM의 출력 자유도를 직접적으로 제한한다. 구현을 위해 먼저 라이브러리를 설치한다.

pip install outlines

설치 후에는 사전 학습된 모델과 토크나이저를 outlines로 래핑(Wrapping)한다. 래핑은 기존 모델의 생성 로직 위에 outlines의 제어 계층을 씌우는 작업이다. 이 과정을 통해 모델은 다음 토큰을 선택할 때 outlines가 설정한 제약 조건을 실시간으로 참조하게 된다.

구체적인 구현은 Pydantic의 `BaseModel`을 상속받은 클래스를 정의하는 것에서 시작한다. 예를 들어 사용자 정보를 담는 `UserProfile` 클래스를 만들어 이름, 나이, 이메일 같은 필드와 타입을 지정한다. 이렇게 정의된 클래스를 래핑된 모델에 전달하면 LLM은 해당 클래스의 구조와 일치하는 JSON 객체만을 생성한다. 모델은 임의의 설명을 덧붙이지 않고 정의된 스키마에 맞는 값만 채워 넣는다.

이 방식은 개발자가 모델의 지시사항 준수 여부를 염려해 여러 번 재시도하거나 복잡한 후처리 코드를 짤 필요를 없앤다. 출력값이 항상 정해진 타입을 준수하므로 LLM의 결과물을 다음 파이프라인의 입력값으로 즉시 사용할 수 있다.

한국 AI 실무자를 위한 도입 판단 기준

챗봇처럼 사람이 읽는 결과물이 아니라 API 서버나 데이터베이스에 직접 값을 전달하는 구성 요소로 LLM을 사용할 때 제약 디코딩 도입이 필요하다. 프롬프트에 JSON 형식을 요청해도 모델이 마크다운 태그를 섞거나 쉼표를 빠뜨리는 불확실성을 제거하여 데이터 흐름의 연속성을 보장하는 것이 엔지니어링의 핵심이다.

이 방식의 트레이드오프는 모델의 자유로운 생성 능력을 일부 제한하는 대신 시스템의 안정성을 확보하는 것이다. 모델이 창의적으로 답변할 수 있는 선택지는 줄어들지만, 파싱 에러로 인해 서비스가 중단되는 상황을 원천적으로 차단한다. 모델이 생성하는 모든 토큰이 이미 정의된 스키마 내에 있도록 수학적으로 강제하기 때문에 예외 처리를 위한 복잡한 조건문을 겹겹이 쌓을 필요가 없다.

도입 전에는 사용 중인 모델의 토크나이저와 outlines 라이브러리의 호환성을 점검해야 한다. 특히 Pydantic 모델을 통해 제약 조건을 생성하는 사전 컴파일 단계에서 발생하는 메모리 점유율 확인이 필요하다. 모델의 어휘집 크기가 클수록 컴파일 과정에서 일시적으로 메모리 사용량이 급증하여 서버 자원에 영향을 줄 수 있다.

프롬프트에 의존해 결과가 나오기를 기대하는 방식에서 벗어나, 코드 수준의 스키마로 출력을 제어하는 프로그램 방식의 생성으로 전환하는 것이 안정적인 AI 시스템 구축의 기준이다.

JSON만 출력. 코드블록 감싸기 금지.