믿되, 검증하고, 또 검증하라

생성 시스템은 평범한 소프트웨어와는 다르게 실패한다. 죽지 않는다. 그럴듯하고 유창하며 이따금 틀린 것을, 대량으로, 태연한 얼굴로 만들어 낸다. 그 결과물을 중간 장치 없이 바깥세상으로 내보내는 건 직무유기다. 우리 결과물은 세 개의 벽을 지난다.

첫 번째 벽: 증거 게이트

자동으로 나온 주장은 하나같이 증빙을 달고 있어야 하고, 그 증빙은 분위기가 아니라 구조화된 데이터다.

{
  "claim": "business site has no online booking flow",
  "evidence": {
    "url": "https://example-biz.com/reserve",
    "fetched_at": "2026-03-11T02:14:09Z",
    "check": "booking CTA selectors absent in rendered DOM",
    "screenshot": "sha256:9f2c11ab..."
  },
  "verdict": "pass"
}

증거 객체가 없으면 통과 없음. 규칙이 정확 일치를 요구하는데 어림 매칭이면 통과 없음. '그걸 어디서 읽었는지 대라'는 단순한 요구 하나에 죽어 나가는 환각이 얼마나 많은지 놀라울 정도다.

두 번째 벽: 신원 게이트, 그리고 우리에게 겸손을 가르친 버그

실제 업체를 두고 글을 쓰는 파이프라인이라면, 먼저 제대로 된 업체를 보고 있다는 걸 증명해야 한다. 우리의 첫 신원 게이트는 상호를 도메인 이름과 대조해서 맞지 않으면 전부 건너뛰었다. 합리적이었지만, 상호는 한글인데 도메인은 로마자인 시장에서는 재앙에 가깝게 틀린 방식이었다. 이 게이트는 정당한 대상의 98%를 조용히 버리고 있었다. 해법은 도메인 문자열을 믿기를 그만두고, 대신 페이지 본문에서 신원을 확인하는 것이었다. 상호·주소·전화번호를 기록과 교차 검증했다. 통과율은 2%에서 71%로 뛰었고, 그 뒤로 엉뚱한 대상을 잡은 사고는 한 건도 없다. 여기서 얻은 교훈은 이렇게 일반화된다. 닫힘으로 실패하는 게이트도 열림으로 실패하는 게이트만큼이나 틀릴 수 있고, 어느 쪽 실패에 걸렸는지는 오직 측정만이 알려 준다.

세 번째 벽: 적대적 2차 검토

우리가 아는 가장 값싼 품질 향상은, 두 번째 모델 인스턴스에게 첫 번째 결과물을 공격하라고 시키는 것이다. 개선이 아니다. 반박이다. 검토자 프롬프트에는 네 임무가 결함을 찾는 것이며, 확신이 안 설 때는 검토 대상을 '반박됨'으로 판정하라고 못 박아 둔다. 놓친 결함이 버려진 결함보다 우리에게 더 비싸기 때문이다. 결함 찾기만이 임무인 검토자는, 협조적인 검토자라면 점잖게 넘어갔을 것들을 찾아낸다. 살아남은 지적이 곧 손댈 가치가 있는 지적이다.

세 벽 뒤에는 회귀 스위트가 앉아 있다. 약 3,900건, 예상 실패는 0, 사고가 날 때마다 한 건씩 늘어난다. 이 중 어느 것도 파이프라인을 눈에 띄게 늦추지 않는다. 이 전부가 모여야, 생성 기계를 현실 세계의 결과에 겨눠 놓고도 두 다리 뻗고 잘 수 있다.