AI를 활용하여 수익을 창출하는 실험 중 하나로, 저는 유료 책(전체 9개 장)을 기술 기사 및 도서 게시 서비스인 Zenn에 올렸습니다. 이 원고에 작성된 숫자나 주장이 원래 기록과 일치하는지 여부를, 매주 1회 자동으로 작동하는 시스템에 확인하도록 했습니다. 그 결과, 첫 번째 실행의 결과는 '제9장만 보고 종료'였습니다.

이에 저는 AI에게 업무를 지시하는 방식을 수정하고, 상위 모델로 교체하여 두 번째 실행을 진행했습니다. 그랬더니 전 9개 장 전체를 비교하며 6곳을 수정하고 3곳은 출처가 없어 약화(weakened) 처리했습니다. 본 글에서는 무엇이 달라졌는지, 확인 결과를 표 형태로 남긴 이유, 그리고 원인을 알 수 없는 부분에 대해 작성하겠습니다. 이 글은 AI에게 긴 분량의 원고 검토를 맡기려는 사람들을 위한 이야기입니다.

전제: 무엇이, 언제, 누구의 판단으로 작동하는가

이 실험은 revenue-lab이라는 저의 리포지토리(파일과 변경 이력을 모아두는 장소)에서 진행하고 있습니다. 이곳에서는 AI를 사용하여 수익을 창출하려는 시도를 규칙과 기록을 남기며 지속하고 있습니다.

매주 토요일 4시에 Windows의 작업 스케줄러(Task Scheduler, 정해진 시간에 프로그램을 작동시키는 기능)가 RevenueLab Weekly Cycle이라는 작업을 시작합니다. 내부 내용은 Start-RevenueCycle.ps1이라는 스크립트이며, 이 스크립트를 통해 AI를 호출하여 작업을 진행시킵니다.

AI가 수행하는 작업은 docs/QUEUE.md라는 작업 목록의 가장 위에 있는 미완료 항목 단 하나뿐입니다. 목록에는 추가할 때 지켜야 할 규칙이 있습니다. '무엇을, 왜, 완료 조건'을 한 줄로 작성해야 합니다. 공개나 결제, 계정이 필요한 작업에는 '요: 이용자(User)'라고 기재하고, 자동 실행으로 진행되는 작업은 건너뜁니다.

도서 원고 검토는 이 목록에 추가된 여러 업무 중 하나였습니다.

1차 시도 결과: 제9장만 보고 끝났다

자동 실행을 실제로 두 번 돌려본 결과, 첫 번째는 경량 모델(성능이나 비용이 적은 AI 모델)이 제9장만 확인하고 종료했습니다. 총 9개 장 중 마지막 한 장뿐이었습니다.

도서 검토였는데, 마지막 한 장만 본 것입니다. 저는 업무 범위나 완료 조건이 모호했기 때문에, AI가 어디까지를 '끝'이라고 해석했는지 범위를 좁게 해석한 것이 아닐까 생각합니다. 다만, 첫 번째 요청 기록은 남아있지 않아 무엇이 부족했는지는 추측일 뿐입니다.

이에 저는 업무 지시 방식을 수정하고 상위 모델로 교체하여 두 번째 시도를 진행했습니다. 이 두 가지를 동시에 변경했기 때문에 어느 쪽이 효과가 있었는지 분리해서 판단할 수는 없습니다.

수정한 방식: 범위, 비교 대상, 완료 조건을 명시하다

현재 작업 목록에 남아있는 작성 방식은 다음과 같습니다(요약).

• 범위: 도서 전 9개 장(01부터 09까지의 9개 파일 전체)을 통독할 것.
• 비교 대상: 사실과 숫자가 다른 리포지토리(agent-toolkit, AI를 위한 공통 규칙 및 보조 스크립트 모음)의 기록, 즉 core/EVIDENCE.md와 README.md에 일치하는지 확인할 것.
• 수정 방식: 일치하지 않으면 수정한 것으로 처리할 것.
• 완료 조건: docs/REVIEW_book.md를 다시 작성하여, 9개 파일 각각에 대해 확인한 숫자와 주장의 내용, 그리고 그 결과(일치/수정함/출처 없음으로 약화)를 표로 만들 것.

현재 방식의 특징을 표로 정리했습니다.

2차 시도 결과: 6곳 수정, 3곳 약화 처리

두 번째 시도는 전 9개 장을 비교하여 다음과 같은 결과를 얻었습니다.

• 수정함 (출처에 맞게): 6건. 세부 내역은 제1장에 1건, 제2장에 2건, 제4장에 1건, 제8장에 2건입니다.
• 약화 처리 (출처가 없어 작성 방식을 변경): 3건. 제1장, 제4장, 제7장에 각각 1건씩입니다.
• 남은 불일치: 0건

무엇을 수정했는지 몇 가지 예를 들겠습니다.

반면에, 일치하거나 확인된 부분도 많습니다. 예를 들어, Codex 사용 상한선이 3개월 동안 80회였다는 점, 지시(instruction) 339건 및 명령어(command) 4,284건이라는 수치, 규약을 절반으로 줄인 것(-51%, 약 16KB → 약 7.8KB) 등의 수치는 출처와 일치했습니다.

3가지 라벨로 고정한 이유

결과 라벨을 '일치', '수정함', '출처 없이 약화됨'의 세 가지로 고정한 데에는 이유가 있습니다. '보고 문제없음'과 '아직 보지 않음'을 표 위에서 구분할 수 있기 때문입니다. 표의 행이 공란으로 남아 있다면, 그 항목은 확인하지 않았다는 것을 알 수 있습니다.

이는 저의 설계상의 이유이며, 이 형태가 정답이라는 뒷받침은 없습니다. 다만, '출처 없이 약화됨'이라는 라벨을 준비함으로써 AI는 '출처를 찾지 못했을 때'도 나아갈 곳이 생겼습니다. 선택할 수 있는 결과가 '일치' 아니면 '수정함'만이라면, 출처가 없는 주장에도 억지로 둘 중 하나를 붙여버릴 위험이 있습니다.

누가 무엇을 하는가

한계점 및 아직 확인하지 못한 점

• 첫 번째 원본 요청 기록이 없으므로, 무엇이 부족했는지에 대한 것은 추측입니다.
• '작성 방식을 수정한 것'과 '상위 모델로 교체한 것'을 동시에 했기 때문에, 효과를 낸 요인을 분리하여 파악하지 못했습니다.
• 이 확인은 책 원고가 출처 기록과 일치하는지 본 것입니다. 출처 기록 자체가 정확한지는 확인하지 못했습니다.
• '9개 파일 각각의 표가 있는지'를 자동으로 세는 메커니즘은 기록에 없습니다. 표가 모두 갖춰져 있는지는 현재 사람이 보고 있습니다.
• 상위 모델이라면, 매번 전 9장을 읽을지 여부는 알 수 없습니다. 기록된 실행은 단 2회뿐입니다.

가져갈 점 (Takeaways)

AI에게 긴 원고의 확인 작업을 맡길 때 제가 가져간 네 가지는 다음과 같습니다.

• 범위를 숫자와 이름으로 지정하기('전체'가 아닌 '01~09의 9개 파일 모두')
• 대조할 파일을 명시적으로 지목하기
• 완료 조건을 범위 내 모든 항목에 대한 표로 만들기. 하나라도 빠지면 끝이 나지 않도록 만듭니다.
• 출처가 없을 때를 위한 선택지(약화시키기, 제외하기)를 결과 라벨에 포함시키기

첫 단계는 다음에 확인을 요청할 때, 요청의 '완료 조건'에 '대상 파일 각각에 대해, 확인한 내용과 결과를 1줄씩 작성할 것'을 추가하는 것입니다. 이것만으로도 '전부 했다고 하지만 실제로는 일부만 한 상태'라는 것이 결과표에서 찾기 쉬워집니다.

Discussion