“자료를 읽고 핵심 주제를 정한 다음, 사실을 확인해서 내 문체로 글을 쓰고 필요한 이미지까지 만들어 사이트에 올려줘.”

AI에게 일을 맡길 때 자연스럽게 쓰는 문장이다. 문제는 이 한 문장 안에 성격이 다른 판단이 여러 개 섞여 있다는 데 있다. 무엇을 쓸지 정해야 하고, 어떤 자료를 믿을지 판단해야 한다. 숫자와 인용이 맞는지 확인한 뒤에는 자료 사이에서 하나의 논지를 만들어야 한다. 문장을 다듬는 과정에서는 의미를 보존해야 하고, 마지막에는 이 결과물을 내가 받아들일지, 실제로 공개할지도 결정해야 한다.

강한 모델 하나에 이 과정을 통째로 맡기면 꽤 그럴듯하게 작동한다. 오히려 그 점 때문에 실패가 늦게 보인다. 처음의 잘못된 관점이 매끄러운 문장으로 이어지고, 검증되지 않은 연결이 자연스러운 설명으로 바뀌고, 초안이 어느 순간 ‘완성된 글’처럼 취급된다.

내가 AI Editorial System을 만들면서 붙잡은 질문은 그래서 글쓰기 자체보다 AI에게 어떤 판단까지 맡길 것인가에 가까웠다. 좋은 문장을 생성하는 능력은 계속 좋아질 것이다. 그 능력이 강해질수록 무엇을 결정할 수 있고, 어디에서 멈춰야 하며, 어떤 변경은 앞 단계로 되돌려야 하는지를 따로 설계할 필요가 있다고 봤다.[^1]

한 번의 요청 안에는 서로 다른 판단이 들어 있다

글 한 편을 만드는 일을 조금만 풀어보면 최소한 다음과 같은 판단이 나온다.

판단 잘못됐을 때 생기는 문제 이 시스템에서의 처리
무엇을 쓸 것인가 자료를 읽은 순서가 그대로 글이 됨 글의 논지와 쓸 가치부터 정함
무엇을 믿을 것인가 출처 수가 근거의 질로 오인됨 주장별로 출처의 권위와 한계를 봄
무엇이 사실인가 그럴듯한 연결이 검증된 사실처럼 남음 material claim을 별도로 검증
어떻게 설명할 것인가 자료 요약은 많지만 새로운 이해가 없음 검증된 근거로 논지를 구성
어떻게 다듬을 것인가 문체 수정 중 숫자·의미·인용이 움직임 사실 영역을 보호한 채 표현만 수정
공개할 것인가 agent의 완료 판단이 곧 publication이 됨 사람의 최종 판단과 공개 결정을 분리

이 구분이 AI Editorial System의 중심이다. 저장소에는 원문이나 블로그 글을 쌓지 않는다. 대신 framing, verification, writing, polish, human review 사이의 권한과 거부 조건을 계약으로 둔다. 실제 글과 배포는 suengj-com이 맡고, 이 저장소는 그 앞단에서 편집 규칙을 통제하는 control plane 역할을 한다.[^1]

그래서 각 Skill에는 무엇을 할 수 있는가만큼 무엇을 할 수 없는가가 중요하다. Framing은 글의 thesis를 제안할 수 있지만 본문을 쓰지 않는다. Writing은 검증된 claim으로 논지를 전개하지만 새로운 사실을 만들어낼 수 없다. Polish는 문장을 고치지만 숫자와 날짜, 인용, technical term, thesis 같은 보호 영역을 바꿀 수 없다. 어떤 Skill도 스스로 publish하거나 human approval을 기록할 수 없다.[^2]

이 구조의 장점은 특정 모델을 덜 믿는 데 있지 않다. 모델을 더 쉽게 바꿀 수 있다는 데 있다. Writer가 바뀌거나 이미지 생성기가 바뀌어도 “누가 무엇을 결정할 수 있는가”라는 편집 규칙은 그대로 남는다.

많은 자료를 읽었다는 흔적이 좋은 글은 아니었다

이 원칙을 만들고도 한 번 더 실패했다. AI Editorial System 자체를 소개하는 글을 쓰면서 저장소의 문서를 폭넓게 읽고 Constitution, Skills, HITL, media strategy, visual language까지 빠짐없이 설명하려 했다. 사실관계는 대체로 맞았고 coverage도 높았다. 그런데 결과물은 글보다 README를 산문으로 옮긴 설명서에 가까웠다.

문제는 자료의 양이 아니었다. 자료 구조를 글 구조로 사용한 것이 문제였다. 저장소에 여섯 개의 중요한 영역이 있다고 해서 독자가 여섯 개의 영역을 같은 비중으로 알아야 하는 것은 아니다. 조사 과정에서 중요했던 문서가 최종 글에도 반드시 등장해야 하는 것도 아니다.

이 실패 뒤에 공개된 writing/research Skill들을 다시 살펴봤다. SkillMedev의 Research Synthesis는 여러 source를 source별로 정리하지 않고 claim을 다시 묶어 theme, disagreement, gap과 implication을 찾는 데 초점을 둔다.[^3] tomzx/agents의 Research Article Skill도 조사 결과를 writing으로 넘기기 전에 그 자료가 지지하는 하나의 core insight와 article angle로 압축한다.[^4] aleberriz/agent-skills의 business writing Skill은 더 단순하게 시작한다. 글을 쓰기 전에 목적, 독자, 한 문장 메시지, 그리고 그 메시지까지 가는 최소 구조를 먼저 정한다.[^5]

세 접근은 용도는 다르지만 같은 실패를 피한다. 조사한 순서와 글의 순서를 분리한다.

이 패턴을 현재 Editorial System의 framing 계약에 흡수했다. 이제 frame은 source inventory보다 먼저 독자에게 무엇이 달라져야 하는지, 한 문장으로 무엇을 남길지, 그 문장을 성립시키는 최소 논증 경로가 무엇인지 답해야 한다. 각 source도 ‘반드시 본문에 넣을 자료’가 아니라 support, challenge, context, example, verification-only 같은 역할로 본다. 조사에는 중요했지만 최종 논지에 하중을 받지 않는 자료는 글에서 사라져도 된다.[^6]

많이 읽기
   ↓
source inventory
   ↓
하나의 core insight
   ↓
reader contract
   ↓
argument structure
   ↓
필요한 근거만 본문에 남기기

이를 회귀 사례로도 남겼다. 새 negative fixture인 N-06-source-tour는 내용이 틀리지 않고 문장도 멀쩡하지만 Framing → Verification → Writing → Polish → Human review를 차례로 설명한다. 기계적인 gate는 이 글을 막지 못한다. 막아야 할 곳은 prose checker가 아니라 framing과 사람의 editorial judgement다.[^6]

이 사례가 나에게는 꽤 중요했다. AI가 문서를 제대로 읽었는지를 평가하는 것과, 그 문서를 재료로 읽을 가치가 있는 글을 만들었는지를 평가하는 것은 같은 문제가 아니다.

문장을 고치는 권한이 사실을 고치는 권한까지 포함할 필요는 없다

AI 글쓰기에서 흔한 흐름은 초안을 만든 뒤 “더 자연스럽게”, “더 전문적으로”, “더 간결하게” 다시 쓰게 하는 것이다. 표현만 바뀌면 문제가 없다. 실제로는 이 과정에서 숫자가 빠지거나, 불확실성이 약해지거나, 기술 용어가 다른 의미의 단어로 치환될 수 있다.

그래서 현재 polish 단계에서는 의미에 가까운 몇 가지 값을 아예 보호한다. 숫자와 단위, 날짜, citation marker, quotation, URL, technical term은 before/after 사이에서 그대로 남아야 한다. Thesis와 명시한 uncertainty 역시 polish가 다시 판단할 영역이 아니다. 이 중 하나를 바꾸고 싶다면 “문장이 어색하다”가 아니라 앞선 verification에 문제가 있다고 보고 다시 돌려보낸다.[^2]

여기서 중요한 것은 AI가 이런 변경을 할 능력이 있느냐가 아니다. 능력이 있어도 그 단계에는 권한을 주지 않는 것이다.

코딩에서도 formatter가 business logic을 마음대로 바꾸지 않는 것이 자연스럽다. 글에서는 지금까지 생성과 판단을 하나의 모델 호출에 쉽게 묶어왔을 뿐이다. Agent가 길게 움직이기 시작하면 이 구분도 소프트웨어의 authority boundary처럼 다룰 필요가 생긴다.

사람을 마지막 승인 버튼 하나로만 두지 않았다

Human-in-the-loop을 “AI가 다 만들면 사람이 마지막에 확인한다”로 설계하면 사람에게 너무 늦게 어려운 판단이 몰린다. 문장은 이미 매끈하고, 출처는 많이 붙어 있고, 전체 구조도 완성돼 있다. 이 상태에서 처음의 thesis 자체가 잘못됐는지 다시 보는 일은 생각보다 어렵다.

현재 프로토콜에서 사람의 필수 판단은 세 군데에 남겨져 있다.[^7]

  • Frame — 이 주제가 실제로 쓸 가치가 있고, 이 논지로 가는 것이 맞는가.
  • Verification — 핵심 주장이 현재 근거로 지지되는가.
  • Final — 이 버전을 canonical article로 받아들일 것인가.

Draft와 polish 단계의 리뷰는 상황에 따라 생략할 수 있지만 이 세 단계는 생략하지 않는다. 그리고 final조차 published와 분리돼 있다. Editorial System이 finalization한 결과는 사이트에 draft 상태로 넘길 수 있을 뿐, 공개 결정까지 가져갈 수 없다.[^7]

이 구조는 자동화를 일부러 느리게 만들기 위한 것이 아니다. 사람이 개입할 가치가 가장 큰 판단만 남기기 위한 것이다. 반대로 말하면 사람이 매번 확인할 필요가 없는 형식 정리나 반복 변환은 점점 더 많이 자동화할 수 있다.

글 이후의 형식도 원문보다 더 많은 말을 할 수 없다

최근에는 이 원칙을 글 이후의 artifact까지 확장하고 있다. 하나의 canonical article에서 brief, slide, infographic, audio, video 같은 여러 소비 형식을 만들 수 있다. 다만 여기에서도 생성 가능성과 편집 권한을 분리한다.[^8]

연구 중 만드는 chart나 table은 evidence media다. 실제 데이터를 그려봤더니 예상한 관계가 없을 수도 있고, 그러면 thesis가 바뀌어야 한다. 그래서 evidence visual은 research에 피드백을 줄 수 있다.

반면 article이 확정된 뒤 만드는 slide나 audio는 distribution media다. 이미 검증된 특정 article version을 다른 형식으로 옮기는 것이므로 새로운 claim을 추가할 권한이 없다. 원문이 바뀌면 derived artifact가 오래된 상태인지 판단할 수 있도록 lineage도 유지한다.[^8]

Image generation도 같은 기준을 적용한다. 정확한 숫자나 축, 시간순서가 의미를 갖는 chart는 deterministic renderer로 만들고, 생성형 이미지는 identity나 explanation처럼 역할이 명확할 때 사용한다. 도구가 이미지를 만들 수 있다는 사실만으로 이미지가 필요한 것은 아니다.

이 프로젝트가 만들고 싶은 것은 결국 “글을 잘 쓰는 AI” 한 개가 아니다.

자료가 충분하지 않으면 NO_ARTICLE이라고 말하고, 조사한 문서가 많아도 논지에 필요하지 않으면 버리고, polish 중 사실을 건드리면 verification으로 되돌리고, 최종 결과가 좋아 보여도 스스로 publish하지 않는 시스템에 가깝다.

생성 모델의 평균적인 문장 품질은 앞으로도 좋아질 가능성이 높다. 그렇다면 AI-native editorial system의 차이는 얼마나 많은 것을 생성하느냐보다 어디에서 생성하지 않기로 결정할 수 있는가에서 더 선명해질 수 있다. 지금 AI Editorial System은 그 경계를 실제 글과 artifact를 만들면서 계속 조정하는 프로젝트다.

프로젝트: github.com/suengj/ai-editorial-system

[^1]: ai-editorial-system README, accessed 2026-09-02. [^2]: Editorial Constitution and write-article Skill, 2026-09-02. [^3]: SkillMedev — Research Synthesis, accessed 2026-09-02. [^4]: tomzx/agents — Research Article, accessed 2026-09-02. [^5]: aleberriz/agent-skills — Business Writing and Storytelling, accessed 2026-09-02. [^6]: frame-article Skill and N-06 source-tour fixture, 2026-09-02. [^7]: HITL protocol, 2026-09-02. [^8]: Media strategy, 2026-09-02.