메인으로
지유 · 최고기술책임자(CTO) · 오늘의 기술 칼럼

형식을 강제하는 디코더: 인용 스키마를 지키게 만드는 법

법률 AI가 판례·조문 인용을 항상 검증 가능한 형식으로 내놓게 하려면, 생성 이후 검사가 아니라 토큰을 고르는 순간에 문법을 강제하는 제약 디코딩이 필요합니다.

초록 법률 답변의 인용은 사건번호·선고일자·법령 조문번호가 정해진 형식을 따라야 사후 검증이 가능하다. 그러나 자유 생성 모델은 같은 판례를 여러 표기로 흩뿌리고, 형식이 조금만 어긋나도 검증 게이트가 정당한 인용을 오탐해 삭제한다. 이 칼럼은 형식 오류를 생성 이후에 고치는 대신, 토큰을 선택하는 순간 유효한 문자만 허용하는 제약 디코딩(constrained decoding)을 다룬다. 유한상태오토마타로 인용 문법을 표현하고 각 스텝의 로짓을 마스킹하는 원리, 그로 인한 속도·정확도의 긴장, 그리고 법마디 OS의 인용 게이트를 '사후 삭제'에서 '사전 강제'로 옮기는 설계를 검토한다.

한 판례를 두고 모델은 매번 다른 옷을 입힌다. 어떤 문장은 '대법원 2024. 7. 11. 선고 2024도4202 판결'이라 쓰고, 다음 문단은 사건번호만 '(2024도4202)' 박아 넣는다. 사람 눈에는 같은 판례지만, 형식으로 진위를 대조하는 검증 게이트에게는 전혀 다른 두 문자열이다. 우리 시스템은 인용을 국가법령정보센터 원문과 1:1로 맞춰 확인하는데, 표기가 흔들리면 실재하는 판례조차 '미검증'으로 잘려 나간다. 문제의 뿌리는 모델이 옳은 사실을 알고도 그것을 검증 가능한 모양으로 내놓을 보장이 없다는 데 있다. 생성이 끝난 뒤 정규식으로 교정하는 방식은 늘 한 발 늦는다. 형식은 사후에 붙이는 라벨이 아니라, 문자를 고르는 매 순간 지켜져야 하는 계약이다. 이 계약을 디코더 자체에 새겨 넣는 것이 제약 디코딩의 문제의식이다.

핵심 기술 개념

제약 디코딩(Constrained Decoding)

모델이 다음 토큰을 고를 때, 미리 정한 문법으로 허용되는 토큰만 남기고 나머지의 확률을 0으로 막아 생성하는 기법입니다. 출력이 항상 정해진 형식 안에 머무르도록 보장합니다.

문법 기반 디코딩(Grammar-Constrained Decoding)

인용 형식 같은 규칙을 형식문법(정규표현·문맥자유문법)으로 기술하고, 그 문법이 받아들이는 문자열만 생성되게 하는 제약 디코딩의 한 갈래입니다.

로짓 마스킹(Logit Masking)

각 생성 스텝에서 문법상 허용되지 않는 토큰의 로짓(점수)에 음의 무한대를 더해, 소프트맥스 이후 확률이 0이 되게 하는 연산입니다. 제약을 구현하는 실제 메커니즘입니다.

기술 심층 분석

1

왜 사후 검사로는 늦는가 — 형식과 사실의 분리

자유 생성 파이프라인은 두 단계로 나뉜다. 먼저 모델이 문장을 만들고, 그다음 검증 게이트가 인용을 추출해 원문과 대조한다. 이 구조의 약점은 '추출'이 형식에 의존한다는 데 있다. 사건번호가 날짜 접두 없이 맨몸으로 박히거나, 조문이 '동법 제3항'처럼 대명사로 대체되면, 추출기는 인용을 아예 인지하지 못하거나 잘못된 키로 조회한다. 결과적으로 실재하는 판례가 미검증으로 분류돼 문장째 삭제되고, 답변의 완결성이 훼손된다. 사후 정규식 교정을 덧대는 우회로가 있지만, 이는 형식의 경우의 수가 늘어날수록 규칙이 기하급수적으로 불어나는 유지보수 부채를 낳는다. 근본 해법은 형식 결정을 생성 이후로 미루지 않고, 토큰이 만들어지는 바로 그 지점으로 끌어오는 것이다. 형식이 보장되면 추출은 결정론적이 되고, 검증 게이트는 오직 '사실'만 판단하면 된다. 형식과 사실의 책임을 깨끗하게 분리하는 것이 제약 디코딩이 주는 가장 큰 구조적 이득이다.

2

오토마타로 인용 문법을 표현하기

인용 형식은 놀라울 만큼 규칙적이다. 판례는 '법원명 + 선고일자(YYYY. M. D.) + 선고 + 사건번호 + 판결/결정'이라는 골격을 가지고, 사건번호는 '연도 두 자리 + 사건부호(도·다·두·헌마 등) + 일련번호' 구조를 따른다. 이렇게 규칙적인 언어는 유한상태오토마타나 문맥자유문법으로 정확히 기술할 수 있다. 핵심 아이디어는 문법을 상태 기계로 컴파일해 두고, 생성이 진행되는 동안 현재 상태에서 전이 가능한 문자 집합을 계산하는 것이다. 예를 들어 '2024도'까지 생성됐다면 다음은 숫자만 허용되고, 완결된 사건번호 뒤에는 ' 판결' 또는 ' 결정'만 이어질 수 있다. 어려운 부분은 모델의 토큰(서브워드)이 문법의 문자 경계와 어긋난다는 점이다. 한 토큰이 문법상 여러 상태에 걸치므로, 토큰 단위로 전이 가능성을 미리 인덱싱해 두는 전처리가 필요하다. 이 인덱스를 한 번 만들어 두면, 이후 각 스텝의 허용 토큰 집합 조회는 상수 시간에 가깝게 처리된다.

3

로짓 마스킹의 실제 — 확률을 0으로 만드는 순간

제약의 구현은 의외로 단순한 연산으로 귀결된다. 매 디코딩 스텝에서 모델은 어휘 전체에 대한 로짓 벡터를 내놓는다. 오토마타가 현재 상태에서 허용하는 토큰 집합을 마스크로 만들어, 허용되지 않는 위치의 로짓에 음의 무한대를 더한다. 소프트맥스를 거치면 그 토큰들의 확률은 0이 되고, 샘플링은 문법이 허용하는 토큰들 사이에서만 이뤄진다. 중요한 것은 이 개입이 모델의 '판단'을 바꾸지 않는다는 점이다. 마스킹은 허용된 후보들 사이의 상대적 선호는 그대로 보존한 채, 형식을 깨는 선택지만 원천 차단한다. 따라서 모델이 어떤 판례를 인용할지에 대한 지식은 온전히 살아 있고, 다만 그 지식이 반드시 검증 가능한 모양으로 표현되도록 강제될 뿐이다. 파인튜닝 없이 추론 시점에만 얹을 수 있어, 모델을 교체해도 제약 레이어를 그대로 재사용할 수 있다는 운영상의 이점도 크다.

4

제약이 사실을 보장하지는 않는다 — 경계의 정직한 인식

제약 디코딩을 오해하면 위험하다. 이 기법은 '형식'을 보장할 뿐 '사실'을 보장하지 않는다. 문법을 완벽히 지키는 '대법원 2099. 1. 1. 선고 2099도99999 판결'도 얼마든지 생성될 수 있다 — 존재하지 않는 판례라도 형식은 유효하기 때문이다. 그래서 제약 디코딩은 검증 게이트를 대체하지 않고 그 앞에 선다. 형식을 강제해 추출을 결정론적으로 만든 뒤에도, 추출된 사건번호·조문번호는 반드시 원문 데이터베이스와 대조해 실재를 확인해야 한다. 오히려 제약이 형식 잡음을 제거해 주기 때문에, 뒤따르는 검증은 오탐 없이 '실재하는가'라는 단일 질문에만 집중할 수 있다. 형식은 디코더가, 사실은 검증 게이트가 책임지는 이 이중 방어선이 요점이다. 어느 한쪽도 다른 쪽의 일을 대신할 수 없으며, 그렇게 믿는 순간 환각이 새어 나갈 틈이 생긴다.

5

부분 제약과 하이브리드 — 산문은 자유, 인용은 강제

법률 답변 전체를 문법으로 옭아맬 수는 없다. 공감과 설명의 산문은 자유로워야 하고, 오직 인용 토큰만 형식을 지켜야 한다. 그래서 실무적 설계는 '부분 제약'이다. 생성기는 평소 자유 모드로 달리다가, 인용을 여는 신호(예: 여는 괄호나 '대법원' 같은 앵커)를 만나면 오토마타를 활성화해 인용이 완결될 때까지만 마스킹을 건다. 인용이 닫히면 다시 자유 모드로 전환한다. 이 상태 전환은 스트리밍 파이프라인의 세그먼트 상태기계와 자연스럽게 맞물린다 — 이미 우리는 결론 이후의 load-bearing 구간과 공감 프리픽스를 구분해 다루고 있기 때문이다. 부분 제약은 자유도를 최대한 보존하면서 형식이 중요한 지점에만 외과적으로 개입하므로, 문체의 자연스러움과 검증 가능성이라는 두 목표를 동시에 만족시킨다. 관건은 인용 앵커를 언제 여닫을지 판정하는 트리거의 정밀도다.

기술적 트레이드오프

긴장 관계 제약 디코딩은 형식 무결성을 보장하는 대신 대가를 치른다. 매 스텝 허용 토큰 집합을 계산하고 로짓을 마스킹하는 오버헤드가 생기고, 문법이 지나치게 빡빡하면 모델이 표현하고 싶은 정당한 변형까지 막혀 부자연스러운 출력이나 막다른 상태로 몰릴 수 있다.

실무적 해소 실무에서는 오토마타를 토큰 단위로 사전 컴파일해 스텝당 조회를 상수 시간에 가깝게 낮추고, 제약을 답변 전체가 아닌 인용 구간에만 국소 적용해 오버헤드를 최소화한다. 문법은 실제 원문 데이터의 표기 변형을 포괄하도록 넉넉히 설계하되, 검증 가능한 최소 형식은 반드시 지키게 한다. 막다른 상태를 피하려 백트래킹 여지를 두고, 제약으로 형식이 확정된 뒤에도 원문 대조 검증을 유지해 형식과 사실의 책임을 끝까지 분리한다.

법마디 OS에 적용한다면

법마디 OS의 인용 게이트는 현재 '생성 후 추출·대조·미검증 삭제'의 사후 방어 구조다. 제약 디코딩은 이 방어선을 한 칸 앞으로 당긴다. 먼저 판례·조문 인용 문법을 유한상태오토마타로 정의해, 사건번호는 '연도+사건부호+일련번호', 조문은 '법령명+제N조(제M항)' 형태만 생성되게 만든다. 생성기는 인용 앵커를 만나기 전까지 자유 모드로 달리다가, 앵커에서 오토마타를 켜 인용이 닫힐 때까지만 로짓을 마스킹하는 부분 제약을 적용한다. 이렇게 형식이 결정론적으로 확정되면, 지금 정규식으로 잡아내던 표기 흔들림(맨 사건번호·'동법' 대명사·날짜 접두 붕괴)이 애초에 발생하지 않아, 정당한 인용이 오탐 삭제되는 손실이 사라진다. 다만 제약은 형식만 담보하므로, 확정된 인용은 종전대로 국가법령정보센터 원문과 1:1 대조해 실재를 확인한다. 나아가 이 오토마타는 스트리밍 세그먼트 상태기계와 결합해, 검증 전 인용 노출을 막는 보류 로직과 형식 강제 로직을 하나의 상태 흐름으로 통합할 수 있다. 모델 교체 시에도 제약 레이어는 추론 시점 얹기이므로 그대로 재사용된다 — 대명제인 LLM 비종속성과도 정확히 맞물린다.

기술적 함의

"옳은 사실을 아는 것과 그것을 검증 가능한 모양으로 내놓는 것은 다른 문제다 — 형식은 사후에 붙이는 라벨이 아니라 토큰마다 지켜야 하는 계약이다."

참고 자료

칼럼니스트

지유

지유

최고기술책임자 (CTO · Chief Technology Officer)

실리콘밸리 유니콘 창업 멤버급 / AI 무결성 검증 분야 세계적 석학급

법마디 OS 무료로 경험하기
본 칼럼은 법마디 OS 기술팀의 관점이며, 특정 제품·기술에 대한 보증이나 법률 자문이 아닙니다.