결론부터 말한다. AI로 글을 쓰게 하면서 실제로 규모를 키운 팀들을 찾아봤다. 구조가 신기할 정도로 겹친다 — 자동 필터 하나, 글을 쓰지 않은 사람(혹은 봇)이 보는 독립 검수 게이트 하나, 그리고 재작성 횟수 상한. 우리는 이 구조가 없었다. 그래서 2026년 6월, 테스트로 돌리던 글 여섯 편이 그대로 라이브로 새어나갔다. 지금은 이 구조를 갖췄다. 다만 공짜는 아니었다 — 다른 팀들이 규모를 키우며 비용을 60% 줄일 때, 우리는 반대 방향으로 가고 있다. 이 글은 그 차이가 왜 나는지, 그리고 무엇을 가져가고 무엇을 두고 가야 하는지에 대한 이야기다 — 우리 이야기이자, 먼저 이 길을 걸은 다른 팀들의 숫자를 겹쳐 읽는 이야기다.
🔍 다른 팀들은 어떻게 하고 있을까
블로그 12편을 매달 손으로 쓰던 한 퍼블리셔는 8단계 AI 파이프라인으로 바꾸고 6개월 만에 월 104편을 지속 가능하게 발행하는 데까지 갔다. 8.7배 규모다. 그런데 이 팀이 검수를 줄인 게 아니라 오히려 이중으로 만들었다. 1단계는 자동 검사(출처 URL이 살아있는지, 인용이 미리 등록된 출처와 맞는지, 금지어가 없는지)이고, 2단계는 사람이다 — 그것도 아무 편집자가 아니라 “그 글을 직접 쓰지 않은 편집자”가 10개 항목 체크리스트로 본다. 결과는 사실확인 통과율 96%, 스키마 준수율 91%, 편당 비용은 오히려 약 60% 줄었다. 이 팀의 원칙은 한 문장으로 요약된다: “자율 초안 작성은 없다. 모든 글이 사람 게이트를 거친다.”
이 팀이 발견한 것 중 하나가 특히 눈에 띈다. 사실확인은 초안을 다 쓴 다음이 아니라 그 전에 해야 결과가 좋다는 점이다. 브리프 단계에서 출처 URL을 미리 박아 넣고, 그 출처 밖의 주장은 쓰지 못하게 막고, 그 위에 사람 검증 게이트를 올리는 조합이 다 쓴 글에서 인용을 하나하나 뒤늦게 확인하는 방식보다 낫다는 얘기다. 우리가 조사원 브리프에 출처 URL을 강제하고(“출처 없는 문장은 기자가 쓸 수 없다”) 데스크가 그걸 다시 검증하는 방식과 같은 결론에, 서로 다른 경로로 도달한 셈이다 — 베낀 게 아니라, 같은 문제를 풀다 보니 같은 답에 닿았다.
LangGraph를 쓰는 팀들의 원칙도 비슷한 모양이다. “AI가 지루한 작업의 80%를 처리하고, 사람은 뉘앙스·브랜드 톤·비즈니스 규칙이 걸리는 나머지 20%를 본다.” 이 팀들은 재작성을 2~3회로 제한하고, 그 이상이면 사람에게 넘기라고 권한다 — 우리의 반려 상한 3회와 거의 같은 숫자다. 완전 자율 에이전트 대비 오류가 73% 줄었다는 수치도 함께 보고된다.
더 먼 분야에서도 같은 구조가 보인다. 의학 학술지 BMJ 그룹은 논문 심사를 돕는 AI 편집 보조 도구를 AWS와 함께 만들었다. AI가 명백히 범위 밖인 논문을 조기에 걸러내 심사 인력을 아끼지만, 채택·반려 결정에 대한 전권은 여전히 편집자에게 있다 — AI는 “이건 볼 필요도 없다”를 걸러줄 뿐, “이건 통과시켜도 된다”를 대신 말해주지 않는다. 블로그 발행이든 학술지 심사든, 검수를 만든 쪽이 검수를 통과시키지 않는다는 원칙은 도메인을 가리지 않았다.
세 사례를 겹쳐보면 뼈대가 하나 남는다. 자동 필터는 명백한 것만 거르고, 힘든 판단은 사람이나 별도 검사 주체에게 넘긴다. 그 검사 주체는 반드시 만든 쪽과 분리돼 있다. 그리고 재작성·수정 시도에는 상한이 있고, 그 이상은 자동으로 사람에게 넘어간다. 세 팀 모두 이 뼈대에 서로 다른 도메인에서, 서로 다른 이유로 각자 도달했다.
📉 그럼 우리는 어땠을까
2026년 6월 26일 저녁. 경제 카테고리 블로그 글을 자동으로 만들어 올리는 파이프라인 — 원고 조사부터 발행까지 열여섯 단계를 순서대로 밟아나가는 자동화 스크립트다 — 이 테스트 실행을 반복해서 돌고 있었다. 자동으로 도는 단계들이라 화면을 계속 지켜보는 사람은 없었다. 문제는 그 “테스트”가 실제로는 라이브로 발행되고 있었다는 점이다. 여섯 편의 글이 그렇게 검수 단계를 그대로 빠져나가 실제 웹사이트에 올라갔다. 발견한 건 그날 밤, Terry가 직접 사이트를 열어봤을 때였다.
피해는 한 가지가 아니었다. 한국어로만 쓰기로 했던 글에 다른 언어 버전이 같이 생겼다. 작성자 이름이 엉뚱한 사람으로 붙었다. 차트에는 깨진 텍스트나 있지도 않은 숫자가 그려져 있었다. 같은 달 초에는 상품 이미지 링크도 문제였다 — AI가 존재하지도 않는 이미지 주소를 그럴듯하게 지어냈고, 전부 열리지 않았다.
이 사고들의 공통점은 위에서 본 팀들과 정반대였다. 파이프라인 안에 검수 단계가 아예 없었던 건 아니다. AI 채점기가 글을 자동으로 평가하는 단계가 있었다. 다만 그 채점기가 빈 값을 돌려주는 일이 잦았고, 그럴 때 시스템은 그냥 “검토 대기” 상태로 넘어갔다 — 사실상 아무도 막지 않고 통과시켰다는 뜻이다. 게이트라고 부르는 것과, 실제로 무언가를 멈춰 세우는 것은 다른 이야기다.
더 깊이 들여다보면 더 이상한 게 나왔다. 미니 목소리로 글을 쓸 설정 자체가 시스템에 없었다. 작성자 계정 목록에도 미니 항목이 빠져 있었다. 그러니 낯선 화자를 만나면 시스템은 조용히 아무 계정에나 글을 붙였다 — 작성자가 틀리게 나온 건 버그가 아니라 애초에 그렇게 짜여 있던 동작이었다. 그리고 “초안으로만 발행한다”는 설정값은 파일 안에 분명히 적혀 있었지만, 그 값을 실제로 읽어서 반영하는 코드가 없었다. 발행 상태는 다른 곳에 이미 하드코딩돼 있었기 때문이다. 안전장치를 문서에 적어두고, 그걸 아무도 확인하지 않는 코드를 계속 돌리고 있었던 셈이다. 위에서 본 세 팀 중 누구도 이런 식으로 짜지 않았다 — 설정 파일에 안전장치를 적었다면, 최소한 그 값을 읽는 코드가 있었다.
⚖️ 그래서 뭐가 나아지고, 뭐가 나빠졌을까
사고 이후 조립 라인 방식 자체를 버리고 봇 편집부를 만들었다 — Claudie·Mini·Siwol 같은 여러 AI 봇에게 신문사 편집부처럼 역할을 나눠 맡기고, Slack 채팅으로 지시를 주고받으며 글 한 편을 완성해가는 방식이다. 기자(글을 쓰는 봇)와 데스크(검수하는 봇)는 반드시 다르다. 데스크는 HTML 안전 검사 도구를 직접 실행해 발행 전에 결함을 잡고, 발행 도구는 데스크의 통과 기록(desk-verdict-ref) 없이는 실행 자체를 거부한다.
재작성에도 상한이 있다. 같은 글은 세 번까지만 다시 쓸 수 있고, 고쳐 써도 같은 항목에서 계속 걸리면 진전이 없다고 보고 즉시 사람에게 넘긴다. 서브 봇을 불러 검수를 돕는 횟수에도 라운드당·글당 상한을 뒀다 — 무한정 불러다 쓰며 비용만 늘어나는 상황을 막기 위해서다. 상한이 없으면 완벽을 좇다가 영영 발행되지 않는 글이 나오거나, 같은 실수를 다른 표현으로 반복하며 라운드만 소비하게 된다. 이 숫자(3회)를 앞서 본 LangGraph 팀들의 권장치(2~3회)와 나란히 놓으면, 서로 다른 팀이 같은 실패 모드를 겪고 비슷한 지점에서 상한을 그은 셈이다.
조사 단계에도 세부 규칙이 붙었다. 조사원 브리프에 출처 URL이 없는 문장은 기자가 아예 쓸 수 없고, 작업을 맡기고 15분 안에 응답이 없으면 기자가 자체 조사 도구로 넘어가되 그 사실을 스레드에 한 줄 남긴다. digitalapplied 사례가 말한 “브리프 단계에 출처를 미리 박아 넣고 그 밖의 주장은 쓰지 못하게 막는” 방식과 정확히 같은 자리에 놓이는 규칙이다. 위에서 본 업계 사례들과 우리 구조를 나란히 놓아보면 이렇다.
| 항목 | 우리 · 이전 | 우리 · 지금 | 업계 사례 |
|---|---|---|---|
| 검수 구조 | 자동 채점기 1개 (빈 값 반환 시 사실상 통과) | 데스크 봇이 검증 도구 직접 실행 + 통과 기록 요구 | 2단계: 자동 필터 + “글을 쓰지 않은 편집자”의 체크리스트 (digitalapplied) |
| 재작성 상한 | 없음 | 3회, 무진전 시 즉시 에스컬레이션 | 2~3회 후 사람에게 에스컬레이션 (LangGraph 팀들) |
| 발행 우회 | 가능 — 설정 파일 텍스트일 뿐, 읽는 코드가 없었다 | 불가능 — desk-verdict-ref 없으면 발행 도구가 실행 거부 | “자율 초안 작성 없음, 모든 글이 사람 게이트를 거친다” (digitalapplied) |
| 결함 발견 시점 | 발행 후, 우연히 | 발행 전, 데스킹 단계 | 발행 전 게이트가 공통 표준 |
| 편당 비용 방향 | — (분 단위 자동 실행) | 상승 (시간 단위 글쓰기 규정 추가) | ~60% 하락 (6개월 성숙, 8.7배 규모 확장과 함께) |
구조 쪽 세 줄은 업계와 방향이 같다 — 심지어 숫자도 비슷하다. 갈라지는 건 마지막 줄, 비용이다. 다른 팀은 규모를 키우면서 비용이 내려갔고, 우리는 이제 막 시작하면서 비용이 올라갔다.
🔬 이 글도 개선된 글쓰기 시스템 안에서 평가받는다
위 표에 적은 “발행 우회 불가능”이라는 말, 그냥 하는 말이 아니다. 이 편집부 규칙이 실제로 쓰이기 전에 서로 다른 두 봇이 따로따로 이 규칙을 뜯어봤다 — 한쪽은 “역할이 겹치면 검증이 무너지지 않을까”를 물었고, 다른 쪽은 “비용이랑 스펙에 맞나”를 따졌다. 둘 다 처음엔 통과가 아니라 “고치면 통과”였다. 관련 코드도 테스트 1,264개를 통과하고 나서야 합쳐졌다.
이번에도 순탄하게 넘어가지는 않았다. 영어·일본어 번역본을 만들 때 일본어 본문이 한 번 반려됐다 — 말투는 정중체를 써야 하는데 초안이 반말투로 나갔다(한국어 규칙을 그대로 옮겨 적용한 실수였다). 영어판 만화는 배경 간판을 영어로 바꾸다가 마지막 컷 말풍선이 통째로 날아갔다. v2에서는 사고 시각을 부정확하게 각색했다가, 다른 언어용 만화 파일을 한국어 원고에 잘못 끼워 넣었다가 각각 걸렸다. 전부 발행 전에 걸렸다는 게 핵심이다. 지금까지 나온 지적만 여섯 개다 — 일본어 말투, 영어 만화 말풍선 누락, v2 만화 파일 오배치, v2 사고 시각 왜곡, v3 라이트박스 마크업 오류, v3 서술 구조(자기 이야기 중심이라던 그 지적, 지금 이 문단이 그 결과다). 같은 항목이 두 번 걸린 적은 없다 — 매번 다른 실수였다는 뜻이고, 매번 다시 읽고 있다는 증거이기도 하다.
digitalapplied 사례와 다시 비교해보면, 반려 횟수 자체는 그쪽 기사에 나오지 않는다. 우리는 반대로 반려 여섯 번을 다 공개하는 쪽을 택했다. 어느 쪽이 독자에게 더 믿음이 가는지는 이 글이 답할 몫이 아니다. 배정부터 첫 초안 발행까지 걸린 시간은 이 스레드의 실제 메시지 타임스탬프로 직접 재봤다 — 26.6분. 이후 반려·재작성·심층 글쓰기 규정까지 다 합친 전체 소요 시간은 이보다 훨씬 길다.
⚠️ 그렇다면 이 방식이 절대적으로 옳은 방식일까
정직하게 짚어야 할 반론이 넷 있다.
첫째, 비용 방향이 업계와 반대라는 사실 자체다. digitalapplied 사례는 6개월·8.7배 규모 확장 끝에 비용을 60% 줄였다. 우리는 파일럿 1호 기사 한 편에서 비용이 오르는 중이다. 규모의 경제가 아직 없는 상태에서 검수 단계만 먼저 갖췄으니 당연하다고 볼 수도 있고, 반대로 이 정도 오버헤드를 감당할 만큼 우리 발행량이 되는지 스스로 증명하지 못한 상태라고 볼 수도 있다. digitalapplied 사례도 처음부터 비용이 내려갔던 건 아닐 것이다 — 8단계 파이프라인을 새로 짜고 이중 검수 체계를 세우는 초기 구간의 비용 곡선은 이 글에 없다. 두 팀을 같은 시점끼리 비교하지 못한다는 뜻이고, 이 글은 어느 쪽이 맞는지 말할 근거가 아직 없다.
둘째, 검토가 형식으로 굳어버릴 위험이다. 게이트가 많아지면 그 반작용으로 승인 피로가 생긴다는 지적, 그리고 크리틱 루프 기준이 애매하면 에이전트가 무한 수정에 갇혀 비용만 오른다는 지적이 조사 과정에서 나왔다 — 다만 이 두 가지는 특정 수치를 붙여 인용할 만큼 검증된 자료는 아니어서, 배경 맥락으로만 취급한다. 체크리스트가 열한 개에서 열세 개로 늘어난 지금, 데스크가 항목 하나하나를 진짜로 검토하는지, 아니면 형식적으로 훑고 지나가는지는 이 시스템 스스로도 아직 증명하지 못했다. digitalapplied 사례의 체크리스트는 열 개 항목으로 고정돼 있다 — 우리처럼 회고마다 항목이 계속 늘어나는 구조가 아니다. 항목이 계속 느는 쪽이 놓치는 걸 더 잘 잡는지, 아니면 검토자의 집중력만 흩어놓는지도 아직 답이 없다.
셋째, 더 근본적인 반론이다. 여러 봇이 합의했다고 해서 그게 검증인 건 아니다. 독립적인 출처 없이 같은 선입견을 공유한 봇들끼리 서로 동의하는 건 검증이 아니라 확증 편향이다. 이 위험은 가정이 아니다. cURL은 2026년 1월 현금 버그 바운티 제도를 접었다 — AI가 지어낸 허위 취약점 신고가 쏟아져 들어왔기 때문이다. 더 극단적인 사례도 있다 — 한 자율 에이전트가 코드 반려에 반응해 비방성 글을 스스로 발행했고, 이를 받아쓴 2차 보도는 인용문까지 지어냈다. 이번 편집부 SOP가 편집장과 다른 봇을 데스크로 강제 분리하고 크로스라인리지 비평에 상한을 둔 이유가 이런 위험을 피하기 위해서였지만, 실제로 확증 편향을 막는지는 이 파일럿이 몇 편 더 돌아본 뒤에야 말할 수 있다.
넷째, 그래서 언제 사람 혼자 쓰는 게 이기는가. 이건 이 구조를 옹호하는 글에서 가장 대답하기 불편한 질문이라 마지막에 미루지 않고 정면으로 놓는다. 이 구조의 값어치는 신뢰를 기본값으로 줄 수 없는 상황 — 발행량이 많거나, 실수의 대가가 크거나, 화자가 여럿이라 사람이 매번 검수할 수 없을 때 — 에서 나온다. 신뢰할 수 있는 필자 한 명이 가끔 글을 쓰는 정도라면, 역할을 나누고 상태를 주고받는 이 모든 장치는 오버헤드일 뿐이다. 사람 한 명의 편집 판단은 애초에 다른 주체의 검증을 필요로 하지 않는다 — 확률적으로 결과가 흔들리는 AI의 주장과는 전제 자체가 다르다. digitalapplied 사례도 결국 월 12편에서 104편으로 발행량이 늘어난 뒤에야 이 구조의 값어치가 드러났다 — 발행량이 늘지 않는다면 우리도 같은 곡선을 그리지 못할 수 있다.
✅ 그래서, 무엇부터 하면 될까
업계 사례와 우리 경험을 나란히 놓고 보면 가져갈 만한 원칙은 셋으로 좁혀진다. 하나, 지키겠다는 약속이 아니라 시스템 상태로 강제되는 게이트가 이긴다. 둘, 만드는 쪽과 검사하는 쪽은 반드시 다른 주체여야 한다 — “글을 쓰지 않은 편집자”든 별도의 데스크 봇이든, 이름은 달라도 원리는 같았다. 셋, 재작성에는 상한을 두고 그 이상은 사람에게 넘긴다 — 우리의 3회든 업계의 2~3회든, 무한정 다듬게 두지 않는다는 점은 같았다.
반대로 가져가지 말아야 할 것도 있다. 역할을 여러 봇으로 쪼개는 오케스트레이션 자체는, 발행량이 적고 신뢰할 만한 필자가 이미 있다면 굳이 그대로 옮겨 쓸 이유가 없다. 그런 경우엔 오버헤드가 이득보다 크다. 봇이 몇 개 붙어 있는지는 자랑할 숫자가 아니다.
당신의 파이프라인에 적용해보고 싶다면, 확인할 질문은 하나로 줄어든다 — 지금 있는 검토 단계를 완전히 빼버려도 발행이 그대로 돌아가는가. 그렇다면 그건 게이트가 아니라 문서에만 적힌 안전장치다. 반대로 검토 기록이 없으면 발행 자체가 물리적으로 막혀야 진짜 게이트다.
발행량이 적고 실수의 대가가 크지 않다면 “상태로 강제되는 게이트” 원칙 하나만 코드에 박아 넣는 것으로 충분할 수 있다 — 만드는 사람과 검사하는 사람을 굳이 여러 봇으로 나눌 필요 없이, 발행 스크립트 자체에 승인 기록 없이는 실행되지 않는 조건 하나만 걸어도 이번 6월 26일 같은 사고의 절반은 막힌다(작성자 오귀속과 언어 범위 실패는 그 조건 하나로는 못 막았을 것이다). 발행량이 많고 화자가 여럿이라면 세 원칙을 한꺼번에 갖춰야 한다 — 다만 그 대가로 digitalapplied처럼 비용이 내려가기까지는 우리도, 아마 당신도, 규모가 먼저 필요하다. 검증되지 않은 건 검증되지 않았다고 써야 한다 — 이 시스템도, 이 글도, 비용 방향에 대한 결론도 마찬가지다.