AI 팩트체크, 블로그 글 올리기 전에 원본과 한 줄씩 대조하는 우리 팀 순서
글을 AI와 같이 쓰는 1인 창업자나 초기 스타트업 팀이라면, 올리기 직전에 “이 숫자 정말 원본에 있었나” 싶은 순간이 있을 거예요. 이 글은 우리 팀이 블로그 글마다 거치는 AI 팩트체크(Fact-check) 순서를 그대로 열어 본 기록입니다. 원고를 쓴 AI와 원본을 대조하는 AI를 나누고, 대조할 원문을 파일로 남기고, 사람은 공개할 수치와 물어볼 것만 보는 구조예요.
앞 글 혼자 하는 콘텐츠 제작 자동화에서는 사실 대조가 열두 단계 중 한 칸이었죠. 여기서는 그 칸을 여섯 단계로 펼치고, 실제 보고서에서 걸러 낸 문장 세 개를 원고와 발행 글로 나란히 놓았습니다. 우리 팀 문서에서는 이 일을 “사실 검증”이라고 불러서, 본문에서도 그 말을 같이 써요. 자기 일에 AI 업무 설계를 해 보려는 분께는 검증 자리를 어디에 두는지 보는 견본이 될 거예요.
AI 팩트체크, 올리기 전에 이 6단계를 거쳐요
이 블로그는 역할별 AI 작업 창(터미널)으로 일을 나눠요. 기획·블로그·영상·게시 담당 창이 따로 떠 있고, AI 팩트체크는 블로그 담당 창 안에서 끝납니다. 블로그 담당은 원고를 원고 담당에게, 대조를 사실 검증 담당에게 맡기는데, 둘 다 그때그때 띄우는 보조 AI인 서브에이전트(Subagent)예요.
| 단계 | 하는 일 | 맡는 쪽 |
|---|---|---|
| 원문 저장 | 근거로 쓸 1차 출처를 받아 파일로 둔다 | 원고 담당 |
| 원고와 목록 | 글을 쓰고 확신이 약한 문장 5~15개를 뽑는다 | 원고 담당 |
| 기계 검사 | ./wc check 오류 0까지, 공개 금지 항목은 우회 없음 |
엔진(원고 담당이 돌림) |
| 원본 대조 | 문장마다 원본을 찾아 판정 3가지로 보고 | 사실 검증 담당 |
| 고치기·재검사 | 틀림·근거 없음은 고치거나 지우고 다시 검사 | 블로그 담당 |
| 사람에게 알림 | 공개한 수치, 뺀 내용, 물어볼 것 | 블로그 담당 → 사람 |
사실 검증 담당이 받는 건 글의 영문 이름(슬러그)과 원고 담당이 뽑은 확신이 약한 문장 목록이에요. AI 팩트체크에 필요한 나머지는 글 머리에 적힌 근거 파일과 원문을 직접 열어 확인합니다.
쓰는 AI는 근거 원문부터 파일로 남겨요
AI 팩트체크의 출발점은 원고 담당 지침 앞쪽에 나오는 출처 규칙이에요. 공식 문서, 공식 블로그, 공식 저장소 같은 1차 출처만 근거로 쓰고, 기사나 검색 요약은 길잡이로만 봅니다. 근거가 된 페이지는 받아서 글감 폴더(.work/src/<슬러그>/)에 파일로 두고요. 지침에는 “검증 담당이 이 파일들로 대조한다”라고 적혀 있어요.
요약 도구로 읽은 내용만 보고 쓴 수치는 글에 넣지 않는다는 줄도 같은 지침에 있습니다. 받지 못한 페이지(403 같은 접근 거부)의 내용은 아예 쓰지 않아요. 이 사례 글처럼 근거가 저장소 안의 기록이면, 글 머리 정보(frontmatter)의 sources에 그 파일 경로를 적습니다. 사실 검증 담당은 이 목록에서 AI 팩트체크를 시작하죠.
원고를 다 쓰면 원고 담당은 보고 파일에 확신이 약한 문장을 5~15개 뽑아 적어요. 원문과 표현이 달라진 곳, 조건을 줄인 곳, 원문에 없던 분류로 직접 묶은 곳 같은 문장입니다. 블로그 담당은 이 목록을 사실 검증 담당에게 넘기는데, 스킬 파일에는 “넘길 때 내가 확신하지 못하는 주장을 구체적으로 적어 준다”라고 되어 있어요.
확신이 약한 문장을 먼저 뽑게 한 까닭
우리 팀 글쓰기 기준 파일(style.md)에 이 방법을 쓴 기록이 남아 있어요. 작성 담당이 확신이 약한 문장을 스스로 뽑아 오게 하면 검증이 빨라지고, 그렇게 쓴 다섯 편은 검증에서 1~2건씩만 걸렸다고 적혀 있습니다.
대조하는 AI는 따로 띄우고 고치지 못하게 했어요
AI 팩트체크를 맡는 사실 검증 담당은 정의 파일 하나(wolcheon-fact-checker.md)로 움직여요. 역할은 본문 첫 줄에 있습니다. “글을 고치지 않는다. 틀린 곳을 찾아 보고만 한다.” 쓸 수 있는 도구도 읽기·찾기·명령 실행(Read, Grep, Glob, Bash)으로 정해 두었고, 파일을 고치는 편집 도구는 목록에 없어요.
나누는 이유도 같은 파일에 적혀 있어요. “글쓴이는 방금 글을 썼기 때문에 자기 글의 오류를 잘 못 본다. 그래서 네가 처음 보는 눈으로 확인한다.” 스킬 파일의 사실 검증 절도 같은 취지로 시작하고, 이 단계는 건너뛰지 않는다고 못 박아 두었습니다.
확인 목록은 수치, 코드, 서술, 스크린샷 설명, 공개 금지 항목, 과장 순으로 이어져요. 수치는 본문·표·FAQ·메타 설명의 숫자를 모두 원본에서 찾고, 글에서 계산한 합계나 비율은 직접 다시 계산합니다. 글에 공식 문서 주소가 붙어 있으면 원문을 새로 받아 숫자·조건·순서를 글자로 맞춰 보고요.
| 판정 | 뜻 | 다음 할 일 |
|---|---|---|
| 틀림 | 원본과 다르다, 파일 경로와 줄 번호를 붙인다 | 반드시 고친다 |
| 근거 없음 | 원본에서 찾지 못했다, 찾아본 곳을 적는다 | 고치거나 지운다 |
| 애매함 | 글쓴이가 판단할 것 | 글쓴이가 판단한다 |
이 표를 받치는 건 “찾지 못한 것을 맞다고 치지 않는다”는 한 줄이에요. AI 팩트체크 보고는 40줄 이내로 쓰고, 맞음으로 확인한 항목은 늘어놓지 않고 “확인한 수치 N개 중 일치 M개”처럼 개수로만 적습니다. 줄 번호 같은 긴 근거는 보고서 파일로 따로 남겨요.
올리기 전에 이런 문장이 걸러졌어요
보고서 폴더(.work/reports/)에서 파일 이름이 -fact·-factcheck로 끝나는 보고서를 세어 보니 21건이었어요(2026-10-18 기준). 모두 10월 12일부터 17일 사이에 쓴 파일입니다. 그중 세 건을 골라 AI 팩트체크에서 원고 문장이 받은 판정과 발행 글에 들어간 문장을 옮겼어요. 세 글 모두 발행된 글이고, 고친 문장이 원고 파일에 들어가 있는 것까지 확인했습니다.
첫째는 개수예요. 지원사업 한글 파일을 챗GPT·클로드·제미나이 3가지 AI에 올려 본 한글 양식 AI 비교 글에서, 원고는 시험에 쓴 가상 자료를 15줄이라고 적었어요. 사실 검증 담당은 시험 파일의 자료 부분을 직접 세어 13줄이라며 틀림으로 판정했고, 코드박스 제목뿐 아니라 이미지 대체 텍스트와 카드 아래 문구까지 같은 숫자가 있던 곳을 짚었습니다. 발행 글에는 13줄로 들어갔어요.
둘째는 범위예요. 회사 PPT 양식에 새 내용만 채운 글의 원고는 초록 바탕과 산호색 원, 로고, 바닥글과 쪽 번호가 “장마다” 있다고 썼어요. 사실 검증 담당은 양식을 만든 코드를 열어, 초록 바탕과 원은 1·6장에만, 로고·바닥글·쪽 번호는 2~5장에만 들어간다는 걸 보고 틀림으로 판정했습니다. 발행 글에는 표지·끝 장과 2~5장으로 나눈 문장이 들어갔고요.
같은 글에서 원고 담당이 넘긴 확신이 약한 문장은 12개였어요. 이번 AI 팩트체크에서 사실 검증 담당은 12개를 하나씩 판정했고, 그중 2개가 고칠 문장으로 남았습니다. 하나는 결과 파일을 직접 풀어 보니 “원래 글상자 안의 글자만 바뀐” 게 아니라 같은 자리·크기·글꼴로 글상자가 새로 쓰인 경우였고, 다른 하나는 근거 없는 평가 문장이었어요.
셋째는 근거의 폭이에요. 회의 메모를 할 일 표로 바꾼 글의 원고는 요청문 “맨 앞에” 한 줄을 붙였다고 썼는데, 시험 기록에는 “앞에 붙임”까지만 있었어요. 근거 없음 판정을 받고 “요청문 앞에”로 고쳤습니다. 한 번 시험한 결과를 일반 규칙처럼 쓴 “칸을 정하지 않으면 AI가 알아서 정해요”도 “칸을 정하지 않았더니 Gemini가 알아서 칸을 정했어요”로 바뀌었어요.
AI 업무 설계, 일 맡기기 전에 이렇게 쪼개 보세요: 단계·요청문·확인할 자리사람은 공개할 수치와 물어볼 것만 봐요
AI 팩트체크 판정을 받은 뒤 ‘틀림’과 ‘근거 없음’은 전부 고치거나 지워요. 스킬 파일에 그 줄과 “고친 뒤 ./wc check를 다시 돌린다”는 줄이 이어져 있습니다. 기계 검사의 공개 금지 오류는 우회 방법이 없어서, 걸리면 그 값을 글에서 지워요.
애매함은 보고 형식에 “글쓴이가 판단할 것”이라고 적혀 있어서, 남길지 고칠지 글쓴이가 판단합니다.
원고 담당·사실 검증 담당·블로그 담당
- 문장마다 원본 찾기와 판정
- 틀림·근거 없음 고치기, 지우기
- 애매함은 글쓴이가 판단
- 고친 뒤 기계 검사 다시 돌리기
사람
- 글에 공개한 수치 목록, 공개해도 되는지
- 원본에서 확인하지 못해 뺀 내용
- 판단이 서지 않아 묻는 것
사람에게 가는 건 임시글로 올린 뒤의 알림이에요. 블로그 담당은 글 주소와 미리보기 파일 경로에 위 세 가지를 붙여 보냅니다. 공개한 수치 목록을 따로 받는 건 사용자가 공개 여부를 정할 수 있게 하려는 거라고 스킬 파일에 적혀 있고, 돈 수치는 처음부터 글에 넣지 않아요.
쓰는 쪽, 대조하는 쪽, 정하는 쪽으로 칸을 나눈 이 구조도 AI 업무 설계의 한 예예요. 일을 칸으로 쪼개는 방법은 AI 업무 설계, 일 맡기기 전에 이렇게 쪼개 보세요에 따로 정리해 두었습니다.
내 글에도 AI 팩트체크를 붙여 보세요
작업 창을 여러 개 띄우지 않아도 AI 팩트체크 순서는 그대로 가져갈 수 있어요. 한 대화에서 글을 쓰고, 새 대화를 열어 글과 원문 파일만 준 다음 판정 3가지로 대조해 달라고 하면 됩니다. 아래는 우리 팀 기준을 줄마다 옮긴 점검표예요.
AI 팩트체크를 처음 붙인다면 원문을 모아 둘 폴더 하나와 판정 3가지 형식부터 정해 보길 권해요. 대조하는 쪽에 “고치지 말고 보고만”이라는 한 줄을 넣어 두면 쓰는 쪽과 보는 쪽의 역할이 갈려요. 확신이 약한 문장 목록은 그다음에 붙이면 돼요.
이 글의 근거
여기 적은 AI 팩트체크 순서와 문구는 이 블로그 저장소의 사실 검증 담당 정의 파일, 글쓰기 스킬 파일과 원고 담당 지침, 보고서 폴더의 실제 사실 검증 보고서에서 옮겼어요. 보고서 개수는 2026년 10월 18일에 센 값입니다.
업종과 업무에 맞춘 AX 설계 상담은 무료 AX 상담 신청에서 받습니다.
AI 팩트체크 자주 묻는 질문
사실 검증 담당 AI가 틀린 곳을 바로 고치면 더 빠르지 않나요?
이 팀은 고치지 말라고 정해 두었어요. 정의 파일에 “글을 고치지 않는다. 틀린 곳을 찾아 보고만 한다”라고 적었고, 쓸 수 있는 도구 목록에도 편집 도구가 없습니다. 판정을 받은 뒤 ‘틀림’과 ‘근거 없음’은 전부 고치거나 지우고, 기계 검사를 다시 돌려요.
공식 문서를 인용한 글은 어떻게 대조하나요?
원고 담당이 근거로 쓴 페이지를 받아 글감 폴더에 파일로 저장해 둡니다. 사실 검증 담당은 글에 적힌 주소를 직접 다시 받아서 숫자·조건·순서를 원문 글자로 맞춰 봐요. 요약 도구로만 읽은 수치와, 받지 못한 페이지의 내용은 글에 넣지 않습니다.
사람은 무엇을 확인하나요?
블로그 담당이 임시글 주소와 함께 공개한 수치 목록, 원본에서 확인하지 못해 뺀 내용, 물어볼 것을 정리해 올려요. 공개한 수치 목록은 공개해도 되는지 정하라고 따로 받습니다.
글에 나온 역할별 AI 작업 창은 Claude Code로 띄운 것이고, 공식 안내는 Claude Code 공식 문서에 있습니다.
이 글은 직접 만들고 운영하며 남긴 기록입니다. 적힌 수치는 작성 시점의 운영 계정 기준이며, 같은 결과나 수익을 보장하지 않습니다.
