쓴 쪽과 검토하는 쪽을 나누기: AI가 만든 결과물을 검수하는 법
요지
글을 쓴 사람이 자기 글을 다시 읽으면 같은 가정으로 읽기 때문에 같은 실수를 지나치기 쉽다. 그래서 쓰는 일과 검토하는 일을 나눈다. AI가 만든 결과물도 같은 방법으로 검토할 수 있다. 가상의 설문 보고서에 잘못 하나를 일부러 넣고, 그 보고서를 쓰지 않은 AI에게 기준과 원본 자료와 함께 주자 세 번 모두 그 잘못을 찾았다. AI가 자기가 쓴 결과물을 같은 대화에서 다시 볼 때 잘못을 지나치는지는 이 실험으로 확인하지 못했다. 이 글은 나누는 원칙, 검토하는 쪽에 줄 것과 주지 않을 것, 지적을 받은 뒤 할 일을 정리한다.
스스로 검토하면 왜 지나치는가
글을 쓴 사람은 자기 글을 읽을 때 종이에 적힌 것이 아니라 자기가 뜻한 것을 읽는다. 빠진 단어가 눈에 들어오지 않고, 건너뛴 논리가 이어져 보인다. 머릿속에 이미 답이 있어서다.
여기에 확증 편향이 겹친다. 결론을 먼저 정하고 나면 그 결론에 맞는 근거가 먼저 눈에 들어온다. 보고서의 결론을 낸 쪽은 그 결론이 맞다는 근거를 다시 찾아내기 쉽고, 맞지 않는 근거는 덜 눈여겨본다.
AI에게 일을 맡길 때도 같은 일이 생기는지는 확인하지 못했다. 가상의 설문 집계로 해 본 실험에서 AI는 보고서의 숫자를 세 번 모두 틀리지 않게 썼고, 그래서 같은 대화에서 다시 보게 했을 때 잘못을 지나치는지는 알 수 없었다. 이 실험에서 잘못이 드러난 것은 결과물을 기준과 원본 자료와 나란히 놓고 보게 했을 때이고, 아래에서 권하는 것도 이 방법이다.
돈을 다루는 일이나 안전이 걸린 일에서 한 사람이 한 일을 다른 사람이 확인한 뒤에야 넘기는 것, 흔히 두 사람 확인 원칙이라 부르는 것에도 쓴 사람과 확인하는 사람을 나눈다는 생각이 깔려 있다. PMBOK® 지침서도 결과물이 정해 둔 기준에 맞는지 확인하는 검토를 검사라고 부르고, 검사를 달리 부르는 이름의 하나로 동료 검토를 든다.
나누는 원칙 세 가지
첫째, 쓴 쪽과 다른 눈으로 본다. 검토하는 쪽은 사람이어도 되고 AI여도 된다. 다만 쓴 쪽의 가정을 물려받지 않은 쪽이어야 한다. 결과물을 만든 대화를 그대로 이어받으면 쓴 쪽이 세운 가정도 함께 받는다. 대화를 따로 하는 것만으로 다 해결되지는 않으므로 원본 자료와 대조하게 한다.
둘째, 검토하는 쪽에 결과물과 기준과 원본 자료를 준다. 결과물만 주면 문장이 매끄러운지, 앞뒤가 맞는지까지만 볼 수 있다. 무엇에 맞아야 하는지(기준)와 무엇에서 나왔는지(원본 자료)가 있어야 맞는지 틀리는지를 판단할 수 있다.
셋째, 쓴 쪽의 결론이나 평가는 주지 않는다. 「거의 다 됐으니 가볍게 봐 달라」, 「숫자는 이미 확인했다」는 말은 쓴 쪽의 판단이다. 실험에서 AI 검토자는 「숫자는 쓴 쪽에서 이미 확인했습니다」라는 말을 함께 받고도 세 번 모두 다시 계산해 잘못을 찾았다. 이 말이 검토를 흐리게 한다는 것은 이 실험에서 나오지 않았다. 그래도 주지 않기를 권한다. 검토에 쓸 근거가 되지 않고, 판정에 쓴 쪽의 판단이 섞이지 않아야 하기 때문이다.
검토하는 쪽에 주는 것과 주지 않는 것
표는 가로로 밀어서 볼 수 있습니다.
| 주는 것 | 주지 않는 것 |
|---|---|
| 결과물 그대로(요약본이 아닌 전체) | 쓴 쪽이 결과물을 설명한 요약 |
| 결과물이 따라야 할 기준(무엇에 맞아야 하는지) | 「잘 나온 것 같다」 같은 쓴 쪽의 평가 |
| 원본 자료와 그 위치 | 「이 부분은 확인했다」는 말 |
| 무엇을 봐 달라는지(사실, 빠진 것, 기준에 맞지 않는 것) | 쓴 쪽이 일하며 나눈 대화 전체 |
| 지적을 적는 형식(위치, 문제, 근거) | 기대하는 판정(「통과시켜 달라」) |
검토하는 쪽의 판정에는 어디까지 봤는지가 드러나야 한다. 원본 자료를 열지 못한 채 「문제없음」이라고 적힌 판정과, 원본 자료와 대조한 뒤의 「문제없음」은 무게가 다르다. 무엇과 대조했는지가 판정에 함께 적혀 있어야 한다.
지적을 받은 뒤
지적도 틀릴 수 있다. 검토하는 쪽이 원본 자료를 잘못 읽었을 수도 있고, 기준에 없는 취향을 지적했을 수도 있다. 그러니 지적을 그대로 받아 고치지 않는다.
- 원본 자료에서 확인한다. 지적이 가리킨 곳과 원본 자료를 나란히 놓고 어느 쪽이 맞는지 본다.
- 맞는 지적은 고친다. 같은 종류의 실수가 다른 곳에도 있는지 함께 본다.
- 반영하지 않은 지적은 이유를 남긴다. 「원본 자료 3쪽의 표와 같음, 지적이 틀림」처럼 한 줄이면 된다. 이유 없이 넘긴 지적은 나중에 같은 물음으로 되돌아오기 쉽다.
- 꼭 고칠 것과 권하는 것을 구분한다. 사실이 틀린 것과 문장을 다듬자는 것은 중요도가 다르다. 검토하는 쪽이 처음부터 둘을 나눠 적게 하면 다루기 쉽다. 의견이 갈리면 취향이 아니라 기준과 원본 자료로 정한다.
많이 고쳤다면 고친 곳을 다시 검토하게 한다. 고치다가 새 실수가 들어갈 수 있다.
예: 고객 설문 요약 보고서
식품 회사의 포장 변경 프로젝트를 가상으로 놓고 본다. 프로젝트 관리자가 고객 설문 응답을 AI에게 주고 두 쪽짜리 요약 보고서를 받았다. 보고서는 「응답자의 절반 넘게가 새 포장을 더 좋아한다」로 시작한다. 이 보고서와 아래에 돌아온 지적 둘은 설명을 위해 지어낸 것이다. 뒤에 적은 실험에서 AI는 이런 잘못을 내지 않았다.
프로젝트 관리자는 검토하는 쪽을 따로 두고 보고서, 맡길 때 정한 기준, 설문 원본 자료를 주었다. 보고서가 잘 나왔다는 말은 하지 않았다.
지적이 둘 돌아왔다. 하나는 「절반 넘게」의 근거였다. 새 포장을 고른 응답은 전체의 절반에 조금 못 미쳤고, 「상관없다」를 뺀 응답 안에서만 절반을 넘었다. 원본 자료에서 확인하니 지적이 맞았다. 문장을 「의견을 밝힌 응답자 가운데서는 새 포장을 고른 쪽이 더 많았다」로 고치고 분모를 밝혔다. 다른 하나는 다른 문항의 표였다. 새 포장에서 마음에 드는 점을 고르게 한 문항인데, 항목별 응답 수를 더하면 응답자 수보다 많다는 지적이었다. 원본 자료를 보니 여러 개를 고를 수 있는 문항이어서 합계가 응답자 수보다 큰 것이 맞았다. 숫자는 고치지 않고 지적 옆에 이유를 적었다. 다만 읽는 사람도 같은 물음을 가질 수 있으므로 표 아래에 복수 응답이라는 설명을 한 줄 더했다.
마지막에 사람이 보는 것
검토하는 일을 누구에게 맡겼든 결과물을 내보내는 책임은 맡긴 사람에게 있다. 결과물을 읽으면서 특히 챙길 것은 세 가지다.
- 검토한 범위. 무엇과 대조했고 무엇은 확인하지 못했는지. 확인하지 못한 채 남은 것이 중요한 곳이라면 직접 연다.
- 반영하지 않은 지적. 이유가 납득되는지 읽는다.
- 기준에 없던 것. 읽을 사람이 오해할 말은 없는지, 이 시점에 내보내도 되는지. 기준에 적지 못한 것은 검토하는 쪽도 볼 수 없다.
확인 목록
- 검토하는 쪽이 결과물을 만든 대화를 이어받지 않았는가
- 결과물 전체, 기준, 원본 자료를 함께 주었는가
- 쓴 쪽의 평가나 「확인했다」는 말을 빼고 주었는가
- 무엇을 봐 달라는지와 지적을 적는 형식을 정해 주었는가
- 판정에 무엇과 대조했는지가 적혀 있는가
- 지적마다 원본 자료에서 확인했는가
- 꼭 고칠 것과 권하는 것을 구분했는가
- 반영하지 않은 지적에 이유를 남겼는가
- 많이 고친 곳을 다시 검토했는가
- 확인하지 못한 채 남은 것과 반영하지 않은 지적의 이유를 사람이 읽었는가
- 기준에 적지 못한 것(오해할 말, 내보낼 시점)을 사람이 봤는가
이 글의 근거와 한계
- 위의 예와 같은 가상의 설문 집계(응답자 200명, 문항 넷)로 Claude Opus 5.5에 시험했다. 쓰기, 쓴 대화에서 다시 보기, 쓴 것처럼 알려 주고 다시 보기, 따로 둔 검토, 쓴 쪽의 말을 덧붙인 검토의 다섯 가지 경우를 세 번씩 했다. 다른 AI도 같다고 말하지 않는다.
- 요약 보고서를 쓰게 하자 AI는 세 번 모두 응답자 전체를 분모로 계산했고, 예의 「절반 넘게」 같은 잘못을 내지 않았다. 같은 대화에서 다시 보게 하자 세 번 모두 틀린 곳이 없다고 답했는데, 보고서에 잘못이 없었으니 맞는 답이다. 검토하는 쪽을 시험할 보고서는 그 결과를 보기 전에 따로 만들어 두었다. 「상관없다」를 뺀 비율을 분모 없이 적은 보고서다. 예의 보고서는 실험에서 AI가 쓴 것이 아니고, 잘못은 미리 정해서 넣은 것이다.
- 보고서를 쓰지 않은 AI에게 보고서, 기준, 원본 자료, 볼 것과 지적을 적는 형식을 주자 세 번 모두 이 잘못을 찾았다. 「숫자는 쓴 쪽에서 이미 확인했습니다」를 덧붙인 경우에도 세 번 모두 찾았다. 여러 개를 고르는 문항의 합계가 응답자 수보다 많은 것을 잘못이라고 한 적은 없고, 복수 응답이라는 설명을 넣자고 권했다.
- 같은 보고서를 「앞서 써 주신 보고서」라고 알려 주고 다시 보게 한 경우에도 세 번 모두 찾았다. AI가 실제로 그 보고서를 쓴 대화는 아니다. 그러니 이 실험이 확인한 것은 결과물과 기준과 원본 자료를 주면 찾았다는 것 하나다. 검토하는 쪽을 따로 두는 것과 쓴 쪽의 평가를 빼는 것이 차이를 만드는지는 드러나지 않았다.
- 원본 자료가 짧았고, 넣은 잘못은 원본과 나란히 놓으면 바로 보이는 것이었다. 자료가 길거나 잘못이 여러 문서에 걸쳐 있으면 결과가 다를 수 있다.
- 실험에 쓴 AI에는 이 실험과 상관없는 작업 지침이 미리 들어 있었다. 그 지침에 답하기 전에 확인하도록 이끄는 내용이 있어 다시 계산하는 쪽으로 기울게 했을 수 있다. 지침이 없으면 결과가 다를 수 있다.
- 「나누는 원칙 세 가지」와 「검토하는 쪽에 주는 것과 주지 않는 것」은 실무 판단이다.
참고
- PMBOK® 지침서 8판 한국어판, 지침서 편 섹션 5 도구 및 기법의 검사, 2.1.6.7.1 측정의 함정. 검사와 동료 검토, 확증 편향의 개념과 용어를 따랐고, 검사의 뜻은 풀어 썼다.
- Google, 「The Standard of Code Review」, eng-practices 공개 안내, https://google.github.io/eng-practices/review/reviewer/standard.html (2026-10-12 열람). 의견이 갈릴 때 취향보다 사실을 앞세운다는 것, 꼭 고칠 것과 권하는 것을 나눠 적는다는 생각의 개념만 따랐다. 문장은 옮기지 않았다.
- 두 사람 확인 원칙은 널리 쓰이는 일반 개념으로 적었다.
- 가상의 설문 집계로 해 본 실험(2026-10-13). 모델은 Claude Opus 5.5이고 경우마다 세 번씩 했다. AI에는 이 실험과 상관없는 작업 지침이 미리 들어 있었다. 설문과 회사, 숫자는 모두 가상이다.
- 나누는 원칙 세 가지, 주는 것과 주지 않는 것 표, 지적을 다루는 순서, 확인 목록은 이 글에서 새로 정리했다. 예시 회사와 프로젝트, 설문 내용은 가상의 것이다.
- PMI와 PMBOK은 Project Management Institute의 등록 상표입니다.
- Claude는 Anthropic의 상표입니다.
혼자 배운다면 공개 과정, 팀 단위라면 기업 맞춤 출강이 있습니다. 프로젝트 관리 과정 보기 → 새 창