Claude Code로 29개 글 초안 만들고 검수한 과정
Claude Code가 밤새 29개의 아티클 초안을 작성하게 한 뒤, 별도의 검토자가 소스와 대조했더니 24개의 불일치를 찾아냈습니다
2026–09–21 밤에 Claude Code로 아티클 초안들을 작성하게 했습니다. 허용된 재료는 제 기록에 남아 있는 측정값과 실패 사례뿐이었습니다(Obsidian 노트, git 기록, 스크립트 주석). 약 2시간 만에 29개의 초안, 104장의 이미지, 그리고 본문 약 96,000자의 일본어 텍스트가 만들어졌습니다.
작성이 끝난 뒤에는 작성자와 분리된 두 명의 검토자를 두고, 각 게시물을 하나씩 소스 기록과 대조하게 했습니다. 그 결과 24개의 오류와 과장 표현이 발견되었습니다. 가장 큰 문제는, 한 게시물이 기록의 결론과 정반대로 읽힐 수 있었다는 점입니다. 이 글은 어떻게 작성했는지, 그리고 무엇이 드러났는지를 다룹니다. 이 글은 AI의 도움을 받아 작성했습니다.
이 글은 AI에게 아티클이나 보고서를 쓰게 한 뒤, 그대로 공개하려는 사람들을 위한 것입니다.
작성 방법: 기록에 실제로 존재하는 숫자만 사용
지시 사항은 “실제로 했던 일을 기록에서 재료를 끌어와 써 달라”는 것이었습니다. 작성 규칙은 제 Vault(Obsidian)에 있습니다. 처음 다섯 줄 안에 누구를 위한 글인지와 무엇에 관한 글인지 밝히고, 결론은 제목에 넣고, 이미지는 반드시 포함하는 식입니다.
각 게시물은 다음 단계를 거쳤습니다:
- Vault 노트와 git 기록에서 숫자와 배경 정보를 가져오기
- HTML로 도표를 작성한 뒤 Playwright로 PNG로 렌더링하기. 영상 주제의 경우 실제 영상에서 프레임을 잘라 쓰기
- 본문 작성하기
- 자동 텍스트 검사 실행하기(AI스러운 표현을 잡는 textlint 규칙과 금칙어 목록 포함)
- 각 폴더의
素材.md파일에 어떤 숫자가 어떤 소스에서 왔는지 기록하기
자동 검사는 세 가지만 잡아냈습니다(과하게 강한 표현 1개, “furthermore” 같은 군더더기 연결어 2개). 어휘 습관은 대부분 작성 단계에서 잘 통제되었습니다.
작성자는 과정 중간에도 스스로 문장을 지웠습니다
작성자는 초안을 다시 읽으며 스스로 수정하기도 했습니다. 지운 것 대부분은 기록에 없는 배경 설명과 이유였습니다.
“멈춘 기억은 없다.” “용량을 줄이려고 해봤다.” “처음에는 알림을 더 추가할 생각이었다.” 이런 문장들은 아티클에서 자연스럽게 이어지고, 기록에는 적혀 있지 않았습니다. 숫자를 기록 그대로 정확히 써도, 연결 문장에는 “그럴듯한 배경”이 스며듭니다.
그렇더라도 작성자 본인의 재검토만으로는 충분하지 않았습니다.
두 명의 별도 검토자가 소스와 대조했습니다
29개 중 28개의 게시물을 반씩 나눠 두 명의 검토자에게 맡겼습니다. 지시 사항은 다음과 같았습니다:
- 어떤 파일도 다시 쓰지 말 것. 읽기만 할 것
- 본문에서 숫자, 날짜, 고유명사, 사실 주장만 뽑아내고,
素材.md에 적힌 소스를 열어 서로 대조할 것 - 소스와 다른 숫자, 소스에 없는 사실, 게시물 간의 모순, 다른 사람의 이야기를 내 경험처럼 쓴 부분을 보고할 것
- 확인할 수 없는 내용은 별도의 “확인 불가” 그룹으로 분류할 것
전체적으로 24개의 오류와 과장 표현이 있었습니다.
가장 큰 것은 GPU 머신 관련 글이었습니다. 제목은 “Sending work to the GPU machine was slow. Five fixes to make it fast,”였고, 수정 사항들이 속도를 빠르게 만들어 준 것처럼 읽히도록 쓰여 있었습니다. 하지만 기록의 결론은 정반대였습니다. 처음 측정한 7.7배는 실제 운영에는 없는 단계에 대한 것이었고, 운영 단계로 다시 측정했더니 GPU 머신은 Mac보다 약 3배 느려서 속도 면에서는 사용하지 않기로 했다는 내용이었습니다. 이 글은 기록의 앞부분 절반만 보고 작성된 것이었습니다. 저는 제목부터 다시 써서 그 게시물을 수정했습니다.
수치 계산 오류도 있었습니다. “6시간짜리 영상은 54분 분량만 인코딩하면 된다”고 썼지만, 장면별 영상(18분)도 따로 인코딩했으므로 총합은 약 72분이었습니다. 스크립트 안쪽을 읽어봤다면 알 수 있었을 것입니다.
그들은 원문에는 없던 원인도 찾아냈다: “서로 다른 스크립트로 렌더링한 청크를 -c copy로 합쳤기 때문에”, “가장 큰 것은 네 번째였다”, “가장 잘 통했던 것은”. 기록은 그저 항목들을 나란히 적어 둘 뿐이고, 원인이나 순위를 매기지 않는다.
시리즈의 각 회차 사이에는 모순도 있었다. 동물 영상에 대한 시리즈에서 3부는 “30초가 그날 안에 완성됐다”고 했고, 4부는 “이틀 동안 만들었는데 단 하나도 통과하지 못했다”고 했다. 3부의 30초는 블록을 조합해 만든 CG 영상이었고, 4부는 AI가 생성한 실사풍 영상에 대한 것이었다. 나는 이 둘을 구분하지 못했다.
그 밖에도 검토자들은 기록 쪽의 오류도 찾아냈다. 내 아이디어 노트에 복사해 둔 정규식이 실제 것보다 한 글자 달랐고, 사이드 프로젝트 노트의 “어떻게 알아차렸는지”는 막 한 주 된 채널의 증거로는 쓸 수 없었다. 나는 게시물뿐 아니라 원본 기록도 고쳤다.
검토자들의 사용량은 대화에 보인 것의 약 40배였다
작업을 끝냈을 때, 대화에 표시된 두 검토자의 사용량은 각각 약 20만 토큰이었다. 로그를 다시 집계해 보니 약 794만과 823만이었다.
차이의 거의 전부는 캐시 읽기인데, 이것은 대화에 표시되는 숫자에는 포함되지 않는다. 28개의 게시물을 각각 원문과 대조하려면 파일을 열고 닫고 다시 읽는 일을 50번 넘게 해야 하고, 그때마다 컨텍스트를 다시 읽기 때문에 금세 누적된다.
즉, 24개의 불일치를 찾아내는 데 약 1600만 토큰이 들었다는 뜻이다. 이것이 비싼지 아닌지는 출판 후 오류를 찾아내는 작업과 비교해 봐야 한다. 만약 GPU 포스트를 그대로 게시했다면, 결론이 거꾸로 된 글을 내보냈을 것이다.
찾아내지 못한 것
검토자들이 “확인할 수 없음”이라고 표시한 것들 중에는, 대화 중 API에서만 가져오고 따로 기록하지 않았던 수치들도 있었다(YouTube 유입 경로의 내역, 구독자 수 등). 원본이 대화뿐이라면 나중에 아무도 그것을 검증할 수 없다. 나는 이제 素材.md에 각 수치를 어떻게 얻었는지는 적어 두지만, 값 자체도 Vault에 저장해 두었어야 했다.
다른 사람의 글을 내 경험처럼 써 버린 혼동은, 작성 전에 두 번이나 알아챘다. 내 아이디어 노트에서는 그것들이 “내 실험 기록”으로 분류되어 있었지만, 원본 노트를 열어 보니 다른 사람들 글을 가져온 것이었다. 분류를 그대로 믿었다면, 남의 경험을 내 것처럼 게시했을 것이다.
남아 있는 것
이 글을 쓴 뒤, 나는 29번째 초안인 이 글, 다시 쓴 GPU 포스트, 그리고 몇몇 다른 글을 세 번째 검토자에게 맡겼고, 세 군데를 더 고쳤다. 세 곳 모두 원문에 없는 숫자 혼동이나 배경 서술이었다. 다시 쓴 GPU 포스트에서는 불일치가 발견되지 않았다.
AI에게 글을 쓰게 한다면, 작성자와 다른 에이전트에게 “원문에 없는 배경과 이유”를 특히 찾아보게 해 보라. 이번에는 연결 문장에 끼어들어간 “그럴듯한 배경과 이유”가 숫자 오류만큼이나 자주 드러났다.
출처
- 원문: https://medium.com/@claire_ai/i-had-claude-code-write-29-article-drafts-overnight-then-had-a-separate-reviewer-check-them-8ebab210d2dd?source=rss------claude_code-5 (2026-10-21 · Claire)