그럴듯한 허구를 거르는 자리 — LLM을 판단자로

정제와 태깅을 거친 후보가 줄을 섰다. 표기는 일관되게 다듬어졌고, 도메인 축으로 분류도 끝났다. 그런데 마지막 질문이 남는다 — 이걸 코퍼스에 들여도 되나?

LLM이 만든 결과가 문법적으로 매끄럽고, 읽어 보면 그럴듯하다. 그런데 한 끼 구성을 뜯어 보면 제철이 아닌 재료가 끼어 있거나, 이 도메인에서 누구도 그렇게 묶지 않는 조합이 자신 있게 들어앉아 있다. 틀렸는데 매끄럽다. 유창함이 정확함을 가린 그럴듯한 허구다. 한두 건이면 사람이 잡지만, 후보가 쌓이면 못 잡는다.

데이터가 8할이라는 글에서 다섯 단계 지도를 그릴 때, 우리는 “검증” 칸을 한 줄로만 스쳤다 — 들일지 말지를 판정한다. 이 글은 그 한 줄을 연다.

생성을 의심한다 — LLM을 판단자 자리로

해법은 LLM에게 더 잘 생성시키는 게 아니었다. 더 똑똑한 생성 프롬프트로 허구를 줄이려는 시도는 끝이 없다. 유창함을 높이면 허구도 같이 그럴듯해질 뿐이다. 우리가 택한 전환은 방향이 다르다 — 생성과 판정을 분리한다. 생성물을 만든 LLM과, 그 생성물을 들일지 판정하는 LLM을 다른 자리에 세운다. 후자가 코퍼스 진입 직전의 judge다.

지난 글에서 LLM의 자리를 생성자에서 판단자로 옮긴 전환을 짚었다면, 이 글은 그 판단자가 검증 단계에서 정확히 무엇을 하는지를 본다. judge가 보는 것은 “유창한가”가 아니다. “이 도메인에서 말이 되는가”다. 같은 출력이라도 묻는 축이 다르다.

정제·태깅을 거친 후보
  → 판정 게이트(judge: "이 도메인에서 말이 되는가")
      ├─ 통과 → 코퍼스로 승격
      └─ 탈락 → 보류 / 재정제 큐로

구조만 보면 단순하다. 핵심은 화살표의 방향이 아니라, 판정 없이는 어떤 후보도 코퍼스로 넘어가지 못한다는 데 있다.

왜 게이트인가 — 통과/탈락이 아니라 승격 결정

판정을 게이트로 세운 건, 더 쉬운 대안들이 모두 무너졌기 때문이다.

첫째, 생성물을 일단 다 넣고 나중에 거른다. 가장 빠르지만 가장 비싸다. 나쁜 데이터를 들이는 비용보다, 들어온 뒤 그 위에 쌓인 것까지 되짚어 오염을 풀어내는 비용이 훨씬 크다. 코퍼스는 다음 단계의 토대라서, 한 번 섞인 허구는 그 위에 세운 모든 판단을 흔든다. 둘째, 사람이 전수 검수한다. 품질은 높지만 규모와 일관성에서 무너진다 — 같은 경계를 매번 같게 판정하는 일은 사람에게 가장 어렵다. 셋째, 규칙만으로 판정한다. 빠르고 재현 가능하지만, 도메인의 모호함 — 이게 한식인가 퓨전인가 같은 경계 — 앞에서 멈춘다.

그래서 셋을 가르지 않고 조합했다. 규칙으로 잘라낼 수 있는 건 규칙으로 먼저 거르고, 규칙이 못 잡는 회색지대만 judge에게 넘기고, 최종 승격은 게이트가 결정한다. 게이트는 통과/탈락의 단순 이분이 아니라 “지금 들인다 / 보류하고 다시 본다”는 승격 결정이다. 보류는 실패가 아니라 다음 라운드의 입력이 된다.

여기서 정직할 부분이 있다. judge도 LLM이라 틀린다. 그것도 그럴듯하게 틀린다. 그래서 게이트는 한 번의 통과로 끝나는 관문이 아니라, 판정 결과를 다시 들여다보는 더 큰 루프의 한 마디다.

판정도 검증되어야 한다

한 번 데었다. LLM 판정을 신뢰의 종착점으로 삼았던 때다. judge가 통과시켰으니 괜찮겠지 하고 넘긴 후보들 중에, 매끄럽게 정당화된 허구가 섞여 있었다. judge의 유창함이 우리의 의심을 잠재운 것이다. judge를 세운다고 그럴듯한 허구가 사라지는 게 아니라, 허구를 판정하는 자리로 한 칸 옮겨갈 뿐이었다.

그래서 배운 건 두 가지다. 하나, judge의 출력 자체를 검증 가능한 도메인 사실에 묶어야(ground) 한다 — 사실에 근거를 댈 수 없는 판정은, 아무리 그럴듯해도 받아들이지 않는다. 둘, 판정 품질을 측정해 회귀를 잡는 체계 안에 게이트를 둬야 한다. 판정은 한 번 통과로 끝나는 게 아니라, 수집하고 회고하며 되감기는 루프의 일부다. 이 두 갈래 — 판정을 사실에 묶는 일, 판정 품질을 측정하는 일 — 는 각각 따로 펼칠 이야기다.

한 가지는 분명히 해둔다. 이 글의 판정도 게이트도 전부 코퍼스/데이터 파이프라인 안의 일이다. 사용자에게 나가는 주 단위 식단을 짜는 코어 엔진은 LLM 없이 도는 결정론 알고리즘으로, 이와 별개다. 데이터를 승격할지 판단하는 자리에는 회색지대를 읽는 judge가 일하고, 식단을 짜는 자리에는 재현 가능한 결정론이 일한다. 둘을 섞지 않는 것이 우리 설계의 전제다.

더 잘 생성하기가 아니라, 믿을 수 있게 만들기

생성형 AI를 자기 도메인에 붙일 때 진짜 문제는 “더 잘 생성하기”가 아니라 “생성을 믿을 수 있게 만들기”다. 생성과 판정을 분리하고, 판정을 데이터 승격 게이트로 세우면, 그럴듯한 허구가 자산을 오염시키기 전에 멈춰 세울 수 있다. judge 하나로 끝나지 않는다는 것까지 포함해서 — 판정도 사실에 묶고, 판정의 품질도 측정해야 게이트가 신뢰를 얻는다.

우리는 한국어 식문화라는, 경계가 충분히 모호한 실제 도메인에서 이 게이트를 매일 굴리며 검증했다.