Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 웹 기반 정보 조사(OSINT)를 AI 파이프라인으로 구현하려다 겪었던 실패와 재설계 과정을 기록합니다. 초기에는 복잡한 다단계 게이트를 사용했으나, 이 방식이 오히려 오류의 근거를 제시하지 못하는 블랙박스가 되어 무너졌습니다. 결국 인간 조사 절차를 모방한 '메모 선행 파이프라인'과 '판단은 AI, 결정은 코드'라는 현실적인 구조에 도달했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기다단계 게이트의 붕괴부터 인간 조사 절차를 재현하는 '메모 선행 파이프라인'으로 회귀하기까지
어떤 주제에 대해 사람이 웹에서 조사하고 사실을 확인하는 작업을 LLM에게 대행시킨다. 본고는 그를 위한 비동기 조사 파이프라인을 실제 환경에서 고장 내고 다시 구축한 기록이다.
예상 독자
다루지 않을 내용
TruthHive는 게시된 정보를 사용자가 심의하는 웹 서비스다. 게시물에는 '정보' 또는 '의견' 장르가 있으며, 사용자는 '맞음 / 틀림 / 사실이 아님'으로 심의한다.
심층 분석(Deep Dive)은 그 위에 덧씌우는 조사 기능이다. 어떤 주제나 담론을 기점으로 사람이 웹 검색으로 하는 OSINT(공개 정보를 활용한 조사)를 AI로 재현한다. 그리고 다음 사항들을 정리하여 TruthHive의 게시물 그룹으로 공개한다.
목표는 논쟁의 전제가 되는 정보를 미리 모아두는 것이다. 각자가 똑같은 기초 조사를 반복할 필요도, 전제가 다른 채로 싸우는 '공중전'도 없애고 싶다.
입력: 주제/담론 (예:
- 起点となる言説から論点（Claim）をスマートに抽出し、クラスタリングする
- 収集したWeb資料との対応関係を行列（Matrix）で管理・マッピングする
- 各段階に多重のAIバリデーション（通常承認 / 厳格承認）を置き、品質判定（合格 / 監査用保持 / 却下）を厳密に行う
- 最後に親ハブが全体をきれいに要約してロールアップする
화이트보드 그림은 완벽했다. 이렇게 AI끼리 상호 검증하게만 하면, 환각(Hallucination) 같은 건 일어날 리가 없다. 진심으로 그렇게 생각했다.
돌이켜보면, 이 설계는 '오류를 발견할 수 있는 형태로 제시한다'는 방침과는 정반대였다. AI를 겹치게 쌓아 올리면서, 오류 그 자체를 제로로 만들려고 했던 것이다.
결과적으로는 전멸했다.
본고는 그 기록이다. 왜 '정도가 높아 보이는 다단계 설계(Multi-stage design)'가 모두 무너졌는지. 그리고 평가 사이클을 여러 번 돌린 끝에, 왜 인간의 OSINT 절차를 그대로 모방하는 '메모 선행 파이프라인'과, '판단은 AI, 결정은 코드'라는 현실적인 타협점에 도달했는지. 의사결정 과정을 숨김없이 써 내려간다.
## 2. 좌절의 기록: '정도가 높아 보이는 다단계 설계'는 왜 죽었나
### 2-1. 다단계 게이트는 '왜 멈췄는지'를 설명할 수 없게 되었다
가장 먼저 망가진 것은, 각 태스크 완료 시 AI가 합격/불합격을 결정하는 다단계 게이트였다.
**감사용 상태와 공개 판정이 괴리되어 블랙박스가 되었다**
중간 태스크 로그를 분류하기 위한 '상태'와, 최종 사용자에게 공개해도 되는지 여부를 판단하는 '공개 판정'. 이 두 가지가 이중화되면서 결국 차이가 나기 시작했다. 그 결과,
생각해 보면, 제대로 된 조사원은 처음부터 긴 글을 쓰지 않는다. 자료를 읽고, 해당하는 부분을 발췌(抜き書き)하여, 그 발췌 내용만 보고 정리한다. 나는 그 당연한 과정을 억지로 AI의 다단계 승인으로 대체하려고 했던 것이다.
【구 경로 (파탄)】
기사 본문 가져오기 → 복잡한 다단계 논점 추출 → 명제 클러스터 → AI가 장문 초안 작성 → 다단계 지지 판정 (과탐지로 인한 오발)
【메모 선행 파이프라인 (도착점)】
...
### 메모 선행의 단계 구성
새로운 파이프라인에서는 각 단계의 역할을 물리적으로 분리하고 있다.
| 단계 | 스테이지명 | 담당 | 역할 |
|---|---|---|---|
| 1 | 질문 생성 | AI + 코드 | 출발점의 논제를 전제로 하지 않고, 조사 가능한 질문으로 분해 |
| ... |
단계 수만 보면 구 경로보다 늘어났다. 2-3에서 '공정 자체가 누락의 주원인'이라고 썼는데, 그렇게 생각할 수도 있다. 차이점은 공정의 성격에 있다. 구 경로의 많은 공정들은 내용을 요약하거나 추출하여 재구성하는 것이어서, 통과할 때마다 정보가 부족해졌다. 새롭게 늘어난 단계의 대부분은 대조(照合)나 판정과 같은 검사이며, 내용을 수정하지 않는다. 내용을 수정하는 단계는 메모화, 직역, 정리 작성에 한정되어 있다.
시제품 단계에서 측정했을 때, AI가 작성한 메모의 인용문은 대조를 거치기 전 시점에서 거의 모두 원문에 실제로 존재했다. 작은 시제품에서의 측정이지만, 구 경로와는 느낌이 완전히 달랐다.
수십 번이나 만지작거린 프롬프트보다, 인간의 작업 순서를 그대로 코드로 만든 것이 훨씬 강력했다. 조금 분하다.
### 2장의 과제는 어떻게 되었나
2장에서 언급했던 과제가 현재 설계에서 어떻게 다루어지고 있는지 대응시켜 본다.
| 2장 과제 | 현재 설계에서의 처리 |
|---|---|
| 공개를 중단하는 이유가 추적되지 않음 | 공개 중단 판단을 코드의 공개 게이트에 모았다 (4-3) |
| ... |
후보 배치(候補の置き場) 일원화는 메모 선행 파이프라인의 공로가 아니다. 한 단계 전에서 정리되어 있던 토대 위에, 메모 선행을 얹은 형태이다.
## 4. 핵심 원칙: '판단은 AI, 결정은 코드' 구현
이 시스템을 관통하는 원칙은 하나다. **'판단은 AI, 결정은 코드', '의미는 AI, 기계 확인은 코드'**이다.
AI에게 결정권(정성 평가나, 공개 가능 여부의 bool 값)을 쥐여주면, 시스템은 통제 불능이 된다. 2장의 참상은 그 증거다.
### 4-1. 원문 대조 (Window Verification)
AI가 출력한 인용문(quote)을 코드 측에서 냉철하게 검증한다. 처리의 골자는 이것뿐이다 (설명을 위해 간략화했다).
verifyQuote(본문, 인용):
본문과 인용문의 공백/줄바꿈을 정규화한다
인용이 비어 있거나 너무 짧다 → 불합격
...
여기서 게으름을 피우고 AI를 신뢰하면, 그럴듯한 거짓 인용문이 그냥 지나간다. 대조에 떨어진 메모는 에러 로그를 뱉으며 그 자리에서 폐기되고, 작성 프롬프트의 컨텍스트에는 한 글자도 전달되지 않는다. 'AI가 원 기사에 없는 문장을 인용처럼 조작하는' 버그는 이 지저분한 문자열 대조로 물리적으로 막힌다.
하지만 대조가 보장하는 것은 인용이 본문에 실제로 존재한다는 것까지이다. 요약문의 문장이 메모 내용에 충실한지는 별개의 문제로 남는다. 그래서 7.5단계의 뒷받침(裏取り)에서, 요약문을 한 문장씩 근거 메모와 대조한다.
2장에서 화려하게 오발했던 '지지 판정'을 또 넣었나 싶을 수도 있다. 넣었다. 다만, 판정부터 삭제까지의 흐름을 바꿨다.
- 근거 메모가 연결되지 않은 문장은 코드가 기계적으로 제거한다
- AI는 문장별로 '메모에 의해 지지되는지'를 판단하고, 부분적으로만 지지되는 문장에는 수정안을 덧붙인다
- 수정안은 다시 대조를 거쳐 완전히 지지되었을 때만 채택한다. 수정안이 없거나 통과하지 못하면 제거한다
- 근거가 전혀 없는 문장은 여전히 제거한다. 이것은 오발이 아니라, 제거해야 할 문장이다
- 판정이 돌아오지 않는 등 예외적인 경우에는, 제거하지 않는 쪽으로 기울인다
구 경로는 '완전히 지지되는' 것 외의 모든 것을 삭제했다. 지금은 부분적으로 지지될 수 있는 문장에 복구할 길이 있다. 그리고 삭제를 결정하는 것은 항상 코드가다.
또 하나, 상류(上流) 변화도 크다. 구 경로에서는 AI가 자유롭게 쓴 장문을 나중에 판정했다. 지금은 대조가 완료된 메모만을 재료로 쓰기 때문에, 애초에 근거에서 멀리 떨어진 문장이 생겨나기 어렵다. 문장은 메모로부터 쓰고, 메모는 원문으로부터 쓴다. 구 경로의 오발을 막는 핵심은 판정 규칙 개선보다, 이 구조라고 생각한다.
솔직히 말하자면, 이것은 설계상의 의도일 뿐 효과를 측정해낸 것은 아니다. 신구(新旧)를 같은 조건으로 비교한 기록은 없으며, 복원 규칙과 상류 변화 중 어느 것이 얼마나 효과가 있었는지 분리하여 측정할 수 없다. 이곳이 앞으로의 숙제다. 그럼에도 불구하고 빠져나가는 요약의 오차는 마지막 심의에서 다룰 것을 전제로 설계하고 있다.
### 4-2. '확실성'은 AI에게 점수 매기게 하지 않는다
출력된 게시물에는 객관적인 '확실성 배지(確からしさバッジ)'가 붙는다. 여기에서도 AI가 자체 신고하는 '신뢰도 점수' 같은 것은 일절 믿지 않는다. 판정의 관점은 다음 4가지다.
- 1차 자료에 근거했는지
- 서로 독립적인 여러 정보원이 일치하는지
- 당사자의 주장으로만 그치는 것은 아닌지
- 자료들 사이에 모순이 없는지
배지를 결정하는 것은, 모인 메타데이터와 출처의 정보를 바탕으로 한 코드의 순수 함수다. 같은 입력이라면, 몇 번을 반복해도 똑같은 배지가 붙는다. 그런 것이 AI에게 맡겼을 때는 보장할 수 없었다.
의미 판단이 필요한 관점에서는 AI의 역할도 있다. 모순이 좋은 예시다.
- 날짜나 숫자가 서로 다른 메모 묶음을 코드가 기계적으로 찾아낸다
- 그것이 진짜 모순인지, 보기상의 차이에 불과한지 AI가 판단한다
- 그 판단을 채택할지, 배지를 붙일지는 코드가 결정한다
**'판단은 AI, 결정은 코드'를 하나의 관점 안에서 분업하면 이렇게 된다.**
### 4-3. 공개 게이트의 '멈추는 기준'을 좁히다
과거에는 '조금이라도 논리가 의심스러우면 멈춘다'는 방침으로 운영 불능에 빠졌다. v1에서는 코드가 공개를 보류하는 조건을 극소수로 좁혔다.
예를 들어, 근거 메모가 하나도 연결되지 않은 문장이 있는 경우다. 나머지 조건들도 생각은 같아서, '기계가 명확하게 판단할 수 있고, 놓치면 실해가 큰 것'만을 선택하고 있다.
그 외의 사소한 뉘앙스의 흔들림이나 미확인 사항은 게시물을 멈추는 이유로 삼지 않는다. '요 확인' 표시를 한 후, 커뮤니티 공개 심의 장소에 넘긴다.
심층 분석(深層分析) 게시물은 판정 '사실 아님', 상태 '심의 중'으로 공개한다. 일반 게시물과는 다른, 심층 분석만만의 방침이다. AI는 답을 단정하지 않는다. 출처와 함께 정리되어 있어도, 그것이 사실인지를 결정하는 것은 심의이고, 이 초기값은 심의에서 뒤집힐 때까지의 출발점에 불과하다.
**기계가 멈추는 것은, 기계가 확실하게 판정할 수 있는 것만.** 그 외는 인간의 심의에 맡긴다.
## 5. 세부 사항으로 내린 의사결정
파이프라인의 골격이 잡힌 후에도, 세세한 함정은 아직 이어졌다.
### 5-1. 경량 모델로 오프로드하면서 표시 품질이 붕괴했다
판정 계정 과정은, 경량 모델의 정밀도로 충분할지 알 수 없었기 때문에 일단 Pro 클래스로 시작했다. 구성이 잡히면, 단계적으로 등급을 낮춰도 괜찮은지 시험해 볼 생각이었다.
그 전초전으로, 기계적 처리로 보이는 '모순 의미 판단'과 '직역'만 경량한 소형 모델(Gemini Flash 등)에 오프로드해 보았다. 뒷받침 자료 확인과 답 판정은 Pro 클래스로 유지했다.
태스크는 완수한다. 수치상의 포괄도도 유지된다. 대시보드만 보면 성공이다. 그런데 화면을 열어보니, 표시 품질이 눈에 띄게 무너져 있었다.
- 해외 조직명이 일본어로 번역되지 않고, 대부분 영어 그대로 잔류
- 주체와 주장의 요약 표시가 무너진다
- 번역 과정에서 원문에 없는 뉘앙스를 추가하여 모호한 표현을 오해한다
모두 직역의 열화가 주요 원인이었다. 같은 시기에는 표시 측 코드의 버그도 겹쳤기 때문에, 모든 것을 모델 탓으로 할 수는 없다. 그래도, 번역의 질이 떨어지면, 그 다음 표시가 연쇄적으로 무너지는 것은 확실했다.
2장에서는 '놓치는 주원인은 모델이 아니라 과정이다'라고 썼다. 모순되는 것 같지만, 그렇지 않다. 과정을 줄였기 때문에, 남은 하나하나의 과정의 질이 그대로 출력의 질에 직결되게 된 것이다.
### 5-2. 전체 요약(테마 지도)은 AI에게 글을 쓰게 하는 것을 그만두었다
조사의 전반적인 모습을 조망하는 '테마 지도'. 초기에는 AI에게 시계열이나 대립 구조를 에세이 형식으로 정리하게 했다. 망가지는 방식은 다채로웠다.
- 스키마 없는 JSON의 파싱에 실패하여, 요약란 전체가 사라진다
- 'OO 통신은 ~', '△△ 신문은 ~'처럼, 매체명만 나열된다
- 역사의 탄생 배경만 골라 담고, 핵심 사건이 빠진다
프롬프트를 고치면, 다른 곳이 망가졌다. 완전히 모래성 쌓기였다.
### 5-3. 출처 URL: canonical 통합을 폐지했다
당초에는, 전재 기사나 중복 URL을 영리하게 모으기 위해, `canonical URL`와 `og:url`로 체계를 정규화한 후 출처 번호를 매겼다.
실제 검증 테스트에서는 거의 모든 것이 일치했지만, 아주 미세한 불일치가 발생했다. 진단 결과, 동일한 형식을 사용하지만 연도가 다른 별도의 문서를 URL 정규화 로직이 같은 문서로 오판하여 병합(삭제)하고 있었다. 공개 시스템에서 다른 연도의 자료를 출처로 표시하는 것은 단 한 번이라도 치명적이다.
그래서 출처 번호는 정규화를 거치지 않고, 메모 획득 시의 원본 `sourceUrl`로부터 직접 부여하도록 변경했다. 똑똑한 정규화 과정에서 다른 버전을 오판할 위험을 감수하는 것보다, 있는 그대로의 생(生) URL로 보내는 것이 공개 시스템으로서 신뢰성을 유지하는 방법이다.
### 5-4. 상태 기계: 세션 좀비 처리하기
마지막 이야기는 AI와 관련이 없다. 반복 가능 키(冪等キー) 제약으로 다음 작업이 생성되지 않아, 할 일은 아무것도 없는데도 '실행 중' 상태로 끝나지 않는 세션이 발생했다. LLM 이야기를 하고 있었지만, 마지막에 가로막은 것은 고전적인 상태 관리였다.
대책은 작업 사슬의 끝에서 후속 작업의 유무를 코드로 확인하고, 없다면 `no_scheduled_work` (예정 작업 없음)으로 명시적으로 정상 종료시키는 것이다. 여기서도 '끝났는지 여부'를 결정하는 것은 코드다.
## 6. 요약: 아키텍처의 경계선
쌓아온 시행착오를 한마디로 총괄하자면, AI에 대한 과도한 기대를 버리고 코드가 결정론을 향해 돌아가게 만든 역사였다.
× AI에게 답을 내리게 하고, 삭제나 공개 여부까지 결정하게 하며, 아름다운 에세이를 쓰게 하는 것
○ AI에게 질문을 분해시키고, 생 텍스트에서 메모를 획득하게 하며, 판정의 재료를 나오게 하는 것
○ 인용의 실재 확인, 확실성 집계, 문구 구성, 남길지/버릴지/공개할지 결정은 모두 코드가 실행하는 것
LLM 오케스트레이션에서 효과적이었던 것은 똑똑한 프롬프트보다 경계를 긋는 방식이었다. **어디까지를 자연어의 변동성(AI)에 맡기고, 어디부터를 엄격한 결정론(코드)으로 묶을 것인가.** 그 선을 가려내고, 시스템의 이음매를 계속 의심하는 것. 화이트보드의 아름다운 그림들을 한 장씩 벗겨가며 내가 절실히 느낀 것이 바로 그것이었다.
## 끝으로
LLM을 실제 파이프라인에 통합하면서 'AI에게 어디까지 맡길지' 고민하는 사람들에게 도움이 되기를 바란다. 저희는 이렇게 선을 긋고 있다는 이야기가 있다면, 꼭 댓글로 알려주었으면 좋겠다.
심층 분석을 담은 TruthHive는 여기입니다.
### Discussion
