나는 업계 뉴스를 찾아내고, LLM (Large Language Model) 판독기가 점수를 매기며, 기준을 통과한 것만 게시하는 콘텐츠 파이프라인을 운영하고 있습니다. Cloudflare Workers와 D1을 사용하는 완전 자동화 시스템이며, 운영자는 저 한 명뿐입니다. 이 시스템은 매일 실행되며, 핵심은 제가 일일이 관리할 필요가 없다는 점입니다.

지난 7월, 이 시스템은 2024년의 뉴스를 마치 방금 일어난 일인 것처럼 게시했습니다.

아무도 피해를 입지는 않았습니다. 한 가지 항목이 니치 사이트(niche site)에 올라갔으나, 며칠 내에 정기 품질 점검 과정에서 발견되어 게시가 취소되었습니다. 하지만 "로봇이 2년 전 뉴스를 게시했고 아무도 이를 막지 못했다"는 식의 실패는 사이트의 신뢰성을 조용히 갉아먹는 종류의 실패이며, 이는 단순히 어깨를 으쓱하고 넘길 일이 아니라 제대로 된 사후 분석(postmortem)이 필요한 문제였습니다. 무엇이 잘못되었는지 파헤쳐 보니 예상보다 훨씬 흥미로웠고, 해결책은 제가 작성하려 했던 한 가지가 아니라 결국 세 가지 계층의 수정으로 이어졌습니다.

실제로 무엇이 잘못되었나

파이프라인에는 이미 이 문제를 잡아냈어야 할 두 가지 메커니즘이 있었습니다.

최신성 확인(recency check) 절차가 있었습니다. 하지만 제가 이를 구축했을 때, 제가 목격했던 오래된 콘텐츠 문제는 애그리게이터(aggregator) 사이트에서 오래된 제품 출시 소식이 다시 떠오르는 것이었습니다. 그래서 연도 무결성 확인(year-sanity check)은 제품 항목을 대상으로 실행되었습니다. 뉴스 항목은 게이트를 통과하는 다른 경로를 사용했기에 이 확인 절차를 만나지 못했습니다. 확인 절차 자체에는 버그가 없었습니다. 단지 잘못된 문 앞에 서 있었을 뿐입니다.

LLM 판독기(LLM judge)가 있었습니다. 이 판독기는 게시 전 모든 항목에 점수를 매깁니다: 관련이 있는가? 흥미로운가? 독자의 시간을 들일 가치가 있는가? 판독기는 2024년의 이야기를 읽고 높은 점수를 주었습니다. 왜냐하면 그 이야기가 실제로 관련성이 있고 흥미로웠기 때문입니다. 저는 판독기에게 그 이야기가 최신인지 물어본 적이 없었습니다. 그 질문은 평가 기준(rubric)에 없었기에 질문되지 않았습니다. 인간 편집자는 "잠깐만, 이거 언제 뉴스지?"라는 반사적인 반응을 보입니다. 하지만 LLM 판독기는 당신이 적어준 반응만을 보이며, 적어주지 않은 반응은 전혀 보이지 않습니다.

상류(Upstream)에서 한 애그리게이터가 새로운 피드 타임스탬프(feed timestamp)와 함께 오래된 이야기를 다시 끌어올렸습니다. 하류(Downstream)의 모든 과정은 피드의 말을 그대로 믿었습니다. 두 명의 경비원이 모두 설계된 대로 작동하고 있었지만, 이 한 가지 상황에 대해서는 모두 눈이 멀어 있었습니다.

해결책

제가 처음 구상한 수정안은 단 한 줄이었습니다. 뉴스 항목에도 연도 확인 로직을 확장하는 것이었죠. 끝, 배포하면 된다고 생각했습니다. 저는 수많은 '한 줄 수정(one-line fix)'을 배포해 본 경험을 통해, 방금 겪은 사고가 다음에 겪게 될 사고와 정확히 일치하는 경우는 드물다는 사실을 알고 있습니다. 그래서 대신 세 개의 더 얇은 계층(layers)으로 나누어 구성했습니다. 각 계층은 나머지 두 계층이 실패할 수 있는 서로 다른 방식을 보완합니다.

계층 1: 결정론적 검사(deterministic check)의 범위 확장. 이제 연도 무결성 검사(year-sanity check)는 과거에 문제를 일으켰던 특정 유형뿐만 아니라, 게이트를 통과하는 모든 콘텐츠 유형에 대해 실행됩니다. 결정론적 가드(deterministic guard)가 놓친다면, 로직을 점검하기 전에 그 범위(scope)를 먼저 확인하십시오. 제 경험상 문제는 가드를 뚫고 지나가는 것이 아니라, 가드를 '우회'하여 발생하는 경우가 거의 대부분이었습니다.

계층 2: 판단 기준(rubric)에 최신성(recency) 포함. 이제 판단 모델(judge)은 시의성(currency)을 명시적으로 평가합니다. 이 이벤트가 언제 발생했는지, 그 연령이 가치를 훼손하는지 확인하며, 이벤트 날짜가 피드 날짜보다 훨씬 뒤처져 있는 항목에는 불이익을 줍니다. 이는 규칙으로 표현할 수 없는 부분을 잡아내는 계층입니다. 다만, 이 방식은 당신이 이름을 붙여준 차원(dimensions)에 대해서만 작동합니다. 루브릭(rubric)은 그런 면에서 테스트와 같습니다. 이미 상상해 본 실패 사례들은 인코딩하지만, 그 외의 것은 담지 못합니다.

계층 3: 콘텐츠 자체에서 이벤트 날짜 추출. 이 단계는 근본 원인인 '상류 메타데이터(upstream metadata)에 대한 신뢰'를 다룹니다. 다시 떠오른 이야기는 새로운 타임스탬프를 달고 도착합니다. 콘텐츠 자체는 거짓말을 하지 않더라도, 포장(packaging)은 거짓말을 할 수 있습니다. 이제 파이프라인은 항목의 텍스트에서 실제 이벤트 날짜를 추출하려고 시도하고, 이를 피드가 주장하는 최신성과 비교합니다. 불일치가 발견되면 게시되는 대신 저에게 플래그(flag)가 지정됩니다. 이 방식은 세 계층 중 가장 불안정합니다. 산문(prose)에서 날짜를 추출하는 작업은 아주 황당한 방식으로 실패하곤 하니까요. 바로 그 점 때문에 더 투박한 두 계층이 앞단에서 방어해 주는 것입니다.

이 중 어느 하나만 있었어도 7월의 사고를 잡아냈을 것입니다. 하지만 저는 각 계층의 '유형'이 실패하는 것을 이전에도 목격해 왔습니다. 결정론적 검사는 범위(scope)를 놓치고, 판단 모델은 루브릭의 공백(rubric gaps)을 놓치며, 추출(extraction)은 이상한 입력값(weird input) 때문에 실패합니다. 그래서 세 가지 모두가 필요합니다.

자동 발행을 운영하는 누구에게나 해주고 싶은 말

당신의 실패 모드는 공개적입니다. 잘못된 배치 작업 (batch job)은 로그 파일 속에서 당신을 당황하게 만듭니다. 잘못된 게시 (publish)는 독자들 앞에서 당신을 당황하게 만듭니다. 품질 게이트 (quality-gate)에 투입할 노력은 코드의 크기가 아니라, 대상 독자의 규모에 따라 예산을 책정하십시오.

LLM 심사위원 (LLM judges)에게는 직관이 없습니다. 인간 편집자가 무료로 수행하는 모든 암묵적인 점검 사항은 루브릭 (rubric)에 명시적으로 작성되어야 합니다. 심사위원은 당신이 지정한 모든 축(axis)에 대해 완벽한 점수를 부여하겠지만, 당신이 지정하지 않은 항목에서 해당 항목은 실패할 것입니다.

직접 계산하지 않은 타임스탬프 (timestamp)를 신뢰하지 마십시오. 피드 메타데이터 (feed metadata)는 피드의 동작을 설명하는 것이지, 콘텐츠의 실제 연령을 설명하는 것이 아닙니다. 신선도 (freshness)가 중요하다면, 콘텐츠로부터 이를 도출하십시오.

문제가 된 항목은 내려갔고, 세 가지 계층의 수정 사항은 같은 주에 배포되었으며, 파이프라인은 다시 무인 상태로 작동하기 시작했습니다. 이것이 바로 핵심입니다. 한 사람이 자동 발행을 운영할 수 있습니다. 다만 그 대가는 모든 장애 발생 시 단순한 임시방편 (patch)이 아닌 구조적 수정 (structural fix)을 수행해야 한다는 것입니다. 인스턴스에 임시방편을 적용한다면, 당신은 단지 다음 장애를 예약하고 있는 것뿐입니다.