저는 기술 글쓰기를 위해 AI 보조 편집 파이프라인을 구축해 왔습니다. Notion 카드가 저장소(repo)의 마크다운 초안이 되고, 리뷰를 거친 뒤, dev.to로 동기화되는 방식입니다.

동기는 간단했습니다. 저는 이미 코드에 대해 신뢰하는 리뷰 루프를 가지고 있었습니다. PR을 열고, 리뷰 가이드에 따라 Cursor의 Bugbot을 실행하고, 중요한 부분을 수정하고, 머지(merge)합니다. 저는 글쓰기에서도 동일한 리듬, 즉 초안 작성, 비평, 수정, 발행의 과정을 원했습니다. 그래서 저는 editor-critique라고 불리는 저만의 AI 리뷰 기술을 구축했습니다.

또한 코드 주석과 유사하게 초안 내부에 HTML 주석을 추가하기 시작했습니다. 이는 발행된 포스트의 일부가 되지 않으면서도, 특정 섹션이 왜 그 위치에서 시작되었는지, 왜 증거가 그 위치에 배치되었는지 등 섹션 뒤에 숨겨진 편집 의도를 담아냈습니다.

덕분에 리뷰 단계는 간단해 보였습니다. AI에게 루브릭(rubric, 평가 기준)을 제공하고, 초안을 채점하며, 우선순위가 지정된 피드백을 돌려받는 것이죠.

루브릭이 좋다면, 비평도 좋을 것이라고 가정했습니다.

그 가정은 매우 특정한 방식으로 실패했습니다.

editor-critique의 첫 번째 버전은 제가 요청한 대로 작동했습니다. 초안을 읽고, 5가지 채점 차원을 적용하여 다듬어진 보고서를 생성했습니다. 제 기사인 ["The agent plan had every step except where to stop">(https://dev.to/michaeltruong/the-agent-plan-had-every-step-except-where-to-stop-357h)]를 리뷰하면서, 이 도구는 해당 글에 23/25점을 부여했고 대부분 다듬기(polish) 위주의 제안을 했습니다.

또한 제가 실제로 필요로 했던 피드백을 놓쳤습니다.

유효한 루브릭, 얕은 읽기

초안에는 쉼표나 섹션 레이블에 대한 추가 검토가 필요하지 않았습니다. 더 냉철한 편집적 읽기가 필요했습니다.

유용한 리뷰어라면 다음과 같은 질문을 던졌어야 했습니다:

• 제목이 사건이 교훈을 얻기 전에 미리 교훈을 드러내고 있는가?
• 기사가 dev.to 독자가 알 수 없는 프라이빗 저장소(private repo)의 맥락을 가정하고 있는가?
• PR, 계획, 표준에 대한 링크가 뒷받침하는 증거인가, 아니면 반드시 읽어야 하는 필수 자료인가?
• 거버넌스(governance) 프레임이 실제 사건이 증명한 것보다 앞서 나가고 있는가?

이것들은 포맷팅 확인이 아니라, 독자의 여정(reader-journey)에 관한 질문들입니다.

점수부터 매기는 리뷰어(score-first reviewer)는 루브릭(rubric, 평가 기준)을 첫 번째 관점으로 취급했습니다. 만약 논지(thesis)가 존재하고, 증거가 명시되어 있으며, 흐름(arc)이 완결된 것처럼 보인다면, 초안은 준비된 것으로 간주되었습니다. 루브릭은 비평을 출판 전 점검(publication preflight)으로 변질시켰습니다: 섹션이 채워져 있는가, 목소리가 적절한가, 명백한 빈틈은 없는가와 같은 점들 말입니다.

유용하지만, 그것만으로는 충분하지 않았습니다.

순서에서 무엇이 바뀌었는가

저는 분석이 점수 산정보다 앞서도록 리뷰어 기술(reviewer skill)을 수정했습니다.

이전:

초안 로드 (Load draft)
→ 루브릭 차원 점수 산정 (Score rubric dimensions)
→ 비평 생성 (Generate critique)

이후:

초안 로드 (Load draft)
→ 편집적 통독 (Editorial read-through)
→ 루브릭 차원 점수 산정 (Score rubric dimensions)
...

루브릭은 그대로 유지되었습니다. 다만, 그것이 첫 번째 단계가 되지 않도록 했을 뿐입니다.

이제 리뷰어는 점수를 매기기 전에, 마치 dev.to의 냉정한 독자처럼 가시적인 산문(prose)을 읽습니다. 머릿속으로 저자의 노트(author notes)를 걷어내고, 만약 리포지토리(repo) 링크와 숨겨진 근거들이 사라진다면 이 교훈이 여전히 유효할지를 자문합니다. 그다음 논지의 타이밍, 독자에 대한 가정, 참조 프레이밍(reference framing), 그리고 추측의 이탈(speculation drift)을 점검합니다.

여기서 주석 루프(annotation loop)가 중요했습니다. 주석이 설명하고자 하는 섹션 바로 옆에 위치했기 때문에, 비평은 의도와 효과를 비교할 수 있었습니다. 즉, 주석은 해당 섹션이 무엇을 하려 하는지를 설명하는 반면, 독자에게 보이는 문단은 그것이 실제로 수행되었는지를 보여주었습니다. 때로는 기사에 수정이 필요하기도 했고, 때로는 주석을 통해 편집자 비평(editor-critique) 자체가 해당 섹션을 너무 기계적으로 읽고 있다는 사실이 드러나기도 했습니다. 어떤 경우든, 이러한 불일치는 리뷰어 기술을 위한 유용한 학습 자료가 되었습니다.

그러한 통독을 거친 후에야 비로소 점수를 할당합니다.

출력 결과는 더욱 편집적(editorial)으로 변했습니다. 단순히 "이 초안이 루브릭을 충족하는가?"라고 묻는 대신, "독자에게 무엇이 문제가 될 것인가?"라고 묻기 시작했습니다.

동일한 기사에 대해, 수정된 리뷰어는 교훈을 망치는 제목, 사적인 PR(Pull Request) 가정, 리포지토리 산출물(repo artifacts)에 대한 약한 프레이밍, 그리고 증거보다 앞서 나가는 잠재적인 거버넌스 언어 등을 찾아냈습니다. 23/25점의 통과 점수는 이러한 요소들을 사소하거나 보이지 않는 것으로 취급했었습니다.

왜 순서가 루브릭 튜닝보다 효과적이었는가

루브릭 (Rubric)은 판단을 논지 (thesis), 구조 (structure), 근거 (evidence), 문체 (voice), 준비도 (readiness)와 같은 범주로 압축합니다. 이러한 압축은 일관성을 유지하는 데 도움을 줍니다.

하지만 너무 이른 시점의 압축은 문제를 숨길 수 있습니다.

리뷰어가 수치적 평가를 먼저 확정하고 나면, 나머지 보고서는 그 평가를 정당화하는 경향을 보입니다. 23/25점짜리 초안에는 23/25점에 걸맞은 피드백이 필요했기에, 모델은 독자가 무엇을 어려워할지 독립적으로 발견하는 대신 해당 글이 왜 대부분 준비되었는지에 맞춰 추론을 구성했습니다.

이는 디자인 문서 (design doc)를 읽기 전에 린터 (linter)를 실행하는 것과 비슷합니다. 린터는 임포트 (import)와 포맷팅 (formatting)이 깔끔한지 확인할 수는 있습니다. 하지만 설계가 타당한지는 알려줄 수 없습니다. 린터부터 시작하면 문서는 실제보다 더 완성도 있게 느껴질 수 있습니다.

이곳에서 일어난 일이 바로 그것이었습니다. 루브릭이 나빴던 것이 아닙니다. 시기상조였을 뿐입니다.

분석이 먼저 이루어지자, 동일한 범주들이 더욱 정직해졌습니다. "근거와 구체성 (Evidence and specificity)"에는 링크에만 의존하는 문제가 포함될 수 있었습니다. "논지와 도입부 (Thesis and opening)"에는 제목이 교훈을 미리 망쳐버리는 문제가 포함될 수 있었습니다. "발행 준비도 (Publish readiness)"에는 비공개 저장소 (private repo) 접근 권한 없이도 산문 (prose)이 성립하는지 여부가 포함될 수 있었습니다.

점수는 읽기 과정의 대체물이 아니라, 읽기 과정의 요약이 되었습니다.

QA 리뷰 vs 편집 리뷰 (QA review vs editorial review)

수정을 거치며 저는 두 가지 종류의 AI 리뷰를 구분하게 되었습니다.

QA 리뷰는 묻습니다: 결과물이 명시된 기준을 충족했는가?

편집 리뷰는 묻습니다: 독자가 무엇을 오해하거나, 놓치거나, 믿지 못할 것인가?

이것이 저에게 완전히 새로운 개념은 아니었습니다. 코드 리뷰 (code review)에서 저는 최적화하고자 하는 대상(보안, 게임 상태 변경, UX 회귀, 또는 계획 의도)에 따라 서로 다른 Bugbot 가이드를 이미 사용해 왔습니다. 동일한 디프 (diff)라도 서로 다른 관점을 통해 리뷰될 수 있습니다.

글쓰기 또한 코드 리뷰와 동일한 특성을 가지고 있음이 드러났습니다. QA 리뷰어는 완성도와 발행 기준을 점검합니다. 편집 리뷰어는 독자의 혼란과 신뢰도를 염두에 두고 읽습니다. 결과물은 그대로였지만, 리뷰의 관점이 변한 것입니다.

둘 다 중요합니다. 잘못된 프론트매터 (frontmatter), 누락된 섹션, 또는 핵심 요약 (takeaways)의 부재는 여전히 품질 보증 (QA)이 필요합니다. 하지만 리뷰어가 거기서 시작해서 거기서 끝난다면, 독자가 기사를 따라가는 경로를 전혀 고려하지 않은 채 자신감 넘치는 보고서만을 만들어낼 수 있습니다.

첫 번째 리뷰어가 쓸모없었던 것은 아닙니다. 그것은 비평이라는 이름 아래 품질 보증 (QA)을 수행하고 있었습니다.

수정된 리뷰어는 여전히 점수를 매기지만, 먼저 읽음으로써 그 점수를 얻을 자격을 갖춰야 합니다.

이러한 순서의 변화는 결과물을 "이 기사는 대체로 준비되었습니다"에서 "이 기사는 너무 많은 맥락을 가정하고 있으며, 교훈을 너무 일찍 드러내고, 에이전트가 어디에서 멈춰야 하는지에 대한 거버넌스 (governance) 논거가 안착하기 전에 서사 내의 더 강력한 증거가 필요합니다"라는 방향으로 이동시켰습니다.

이것이 바로 제가 필요로 했던 피드백이었습니다.

다음 리뷰어에서 내가 할 일

내가 구축할 다음 AI 리뷰어를 위해, 나는 루브릭 (rubric) 차원을 조정하기 전에 순서를 설계할 것입니다.

1. 제한 없는 읽기로 시작하기. 점수 임계값이 나타나기 전에 독자, 의도, 리스크, 그리고 증거를 검토합니다.
2. 루브릭이 분석을 요약하게 만들기. 점수는 사후에 만들어내는 것이 아니라, 읽기 과정을 통해 관찰된 내용을 인용해야 합니다.
3. 체크리스트 통과와 판단 통과를 분리하기. "완성되었는가?"와 "좋은가?"는 서로 다른 질문입니다.
4. 독자 영향 중심의 언어를 강제하기. 비평 항목은 단순히 어떤 규칙을 위반했는지만 말하는 것이 아니라, 독자에게 무엇이 문제가 되는지를 말해야 합니다.
5. 점수는 마지막에 나오게 하기. 일단 숫자가 나타나면, 모든 것이 그 숫자를 중심으로 조직됩니다.

이는 단지 글쓰기에 관한 것만이 아닙니다. 저는 동일한 패턴이 PR 리뷰 (PR review), 아키텍처 리뷰 (architecture review), 장애 분석 (incident analysis), 그리고 평가 보고서에도 적용될 수 있다고 의심합니다. 만약 리뷰어가 이해하기 전에 점수를 매긴다면, 루브릭에 과적합 (overfit)되어 상황을 충분히 읽어내지 못하게 됩니다.

이 구조는 이식 가능해 보입니다. 평가 기준만으로는 충분하지 않습니다. 리뷰어가 생각하는 순서가 그것이 주목하는 것을 바꿉니다.

핵심 요약 (Takeaway): 만약 당신의 AI 리뷰어가 기술적으로는 정확하지만 피상적인 피드백만을 계속 생성한다면, 루브릭을 다시 작성하는 데 그치지 마세요. 점수 매기기 이전에 분석을 배치하세요.

이러한 워크플로우 실험의 이면에 있는 프로젝트를 확인하고 싶다면, Codenames AI를 살펴보세요.