문서 검토·감사 실무 가이드

최종 수정: 2026년 8월 18일

문서 검토는 대개 "읽어 보고 이상하면 말하기"로 이루어집니다. 그래서 검토자가 바뀌면 결과가 바뀌고, 같은 종류의 결함이 프로젝트마다 반복됩니다. 이 문서는 그 검토를 기준으로 바꾸는 방법을 정리한 것입니다. 문서 분석기를 쓰지 않더라도, 사람이 직접 검토할 때의 체크리스트로 그대로 쓸 수 있습니다.

1. 왜 "요약"이 아니라 "감사"인가

AI에게 기획서를 주고 "검토해 줘"라고 하면 대체로 요약과 인상평이 돌아옵니다. 읽기에는 그럴듯하지만 실무에서는 쓸 수 없습니다. 무엇을 근거로 그렇게 판단했는지 알 수 없고, 다음 버전에서 같은 검토를 다시 했을 때 결과가 달라지기 때문입니다.

감사는 세 가지가 갖춰졌을 때 성립합니다.

• 기준 — 무엇을 문제로 볼지 미리 정해 둔다.
• 근거 — 문서의 어느 문장 때문에 그렇게 판단했는지 원문을 인용한다.
• 처리 — 각 항목을 누가 언제 어떻게 처리했는지 남긴다.

셋 중 하나라도 빠지면 "검토했다"는 기록만 남고 다음에 재활용할 수 없습니다. 이 도구가 결과마다 근거 문장과 상태를 붙여 두는 이유가 그것입니다.

2. 쓸모 있는 검사 기준을 쓰는 법

검사 기준은 "무엇이 있으면 문제인가"를 판정 가능한 문장으로 적은 것입니다. 아래 두 문장의 차이가 결과 품질의 대부분을 결정합니다.

나쁜 기준: "밸런스가 잘 잡혔는지 확인한다."
좋은 기준: "데미지·체력·쿨타임 등 수치를 언급하면서 구체적인 값이나 계산식이 없으면 문제로 본다."

기준을 쓸 때 지킬 것 네 가지입니다.

1. 한 기준에 한 가지만. "수치와 예외 처리를 확인한다"처럼 묶으면, 둘 중 하나만 걸려도 뭉뚱그린 결과가 나옵니다.
2. 판정 가능한 표현으로. "적절한지", "충분한지"는 사람마다 답이 다릅니다. "값이 없으면", "표가 비어 있으면"처럼 확인 가능한 조건으로 바꿉니다.
3. 우리 팀 규칙을 넣는다. 일반적인 기준은 어디에나 있습니다. 차이를 만드는 것은 "우리는 신규 재화를 도입할 때 반드시 소각 경로를 함께 정의한다" 같은 팀 고유 규칙입니다.
4. 실패했던 사례를 기준으로 승격한다. 한 번 사고가 났던 항목은 다음 프로젝트에서 반드시 검사 기준이 되어야 합니다. 이것이 감사가 축적되는 방식입니다.

3. 심각도는 "놓치면 무슨 일이 생기는가"로 정한다

심각도를 느낌으로 매기면 결국 전부 "높음"이 됩니다. 결과가 아니라 영향을 기준으로 나누면 논쟁이 줄어듭니다.

"높음"이 절반을 넘는다면 기준이 너무 느슨한 것입니다. 심각도의 목적은 분류가 아니라 처리 순서를 정하는 것이라는 점을 기억하세요.

4. 문서 종류별 체크리스트

4-1. 계약서

아래는 문서에 무엇이 적혀 있는지·빠졌는지를 확인하는 실무 체크리스트이며, 법률 자문이 아닙니다. 실제 체결 전에는 변호사의 검토를 받으세요.

• 당사자와 목적물 — 누가 누구에게 무엇을 제공하는지 특정되어 있는가. "관련 업무 일체" 같은 포괄 표현으로 끝나지 않는가.
• 대금 — 금액, 지급 시기, 지급 방법, 부가세 포함 여부, 지연이자가 모두 있는가. "협의하여 정한다"만 남아 있지 않은가.
• 기간과 종료 — 시작·종료일, 자동 갱신 여부와 갱신 거절 통지 기한, 중도 해지 사유와 절차가 있는가.
• 검수 — 검수 기준, 기한, 기한 내에 아무 말이 없으면 어떻게 되는지(간주 규정)가 있는가.
• 책임 — 손해배상 범위와 한도가 있는가. 한쪽만 무제한 책임을 지지 않는가.
• 지식재산권 — 결과물의 권리가 누구에게 귀속되는가. 상대방의 이용 범위와 기간이 정해져 있는가.
• 비밀유지 — 비밀정보의 정의, 예외, 계약 종료 후 유지 기간이 있는가.
• 준거법·관할 — 분쟁 시 어느 법, 어느 법원(또는 중재)인지 정해져 있는가.
• 대칭성 — 해지권·위약금·감액권이 한쪽에만 있지 않은가.
• 상호 참조 — "제N조에 따라"의 그 조항이 실제로 있고 내용이 맞는가. 별첨이 실제로 첨부되어 있는가.

4-2. 게임 기획서

• 수치 정의 — 언급된 모든 수치에 값·범위·계산식 중 하나가 있는가. "밸런싱 후 결정"이라면 결정 기한과 담당이 적혀 있는가.
• 예외 경로 — 성공 흐름만 있고 실패·취소·중복 실행·네트워크 끊김 처리가 빠져 있지 않은가.
• 경계값 — 0개일 때, 최대치일 때, 만료 직전일 때의 동작이 정의돼 있는가.
• 데이터 영속성 — 언제 저장하는가, 서버가 검증하는가, 재접속·중복 로그인 시 어떻게 되는가.
• 권한 — 미로그인·미성년·정지 계정 상태에서의 동작이 정의돼 있는가.
• 용어 — 같은 개념을 두 이름으로 부르고 있지 않은가. 새 용어에 정의가 있는가.
• 재화·확률 — 획득 상한, 소각 경로, 확률 공시, 환불 기준이 있는가.
• 모순 — 앞 장과 뒷 장이 같은 대상에 대해 다른 값을 말하고 있지 않은가.

4-3. QA 보고서

• 재현 가능성 — 재현 단계, 기기·OS, 빌드 버전이 모두 적혀 있는가. 다른 사람이 그대로 따라 할 수 있는가.
• 기대와 실제의 분리 — "무엇이 일어나야 하는데 무엇이 일어났는지"가 구분되어 있는가.
• 심각도 일치 — 진행 불가·데이터 손실·결제 오류가 낮은 심각도로 적혀 있지 않은가. 반대로 사소한 오탈자가 최고 심각도로 올라와 있지 않은가.
• 케이스 커버리지 — 정상 경로만 있고 실패 경로, 경계값, 권한 없는 상태가 빠져 있지 않은가.
• 판정 근거 — Pass 판정에 확인 방법이나 증적이 붙어 있는가.
• 중복·상충 — 같은 현상이 여러 건으로 흩어져 있거나, 서로 반대되는 결과가 함께 있지 않은가.

4-4. 운영 정책

• 제재 기준 — 사유와 단계(횟수·기간)가 구체적인가. 운영자 재량 범위가 명시돼 있는가.
• 고지 절차 — 정책 변경과 제재 적용을 언제 어떤 방법으로 알리는가.
• 이의제기 — 창구와 기한, 처리 기간이 정해져 있는가.
• 법정 고지 — 청약 철회, 미성년자 결제, 확률 공시, 개인정보 처리 항목이 빠져 있지 않은가.
• 조항 간 충돌 — 같은 상황에 대해 두 조항이 다른 결론을 내지 않는가.

4-5. 정부지원사업 서류

• 공고 요구 항목 — 공고문이 요구한 항목이 전부 있는가. 제목만 있고 내용이 빈 항목은 없는가.
• 사업비 — 항목마다 단가·수량·산출식이 있는가. 세부 항목의 합이 총액과 맞는가. 자부담 비율이 공고 조건과 맞는가.
• 정량 목표 — 측정 지표, 목표치, 달성 시점이 함께 있는가. "향상", "확대"로만 끝나지 않는가.
• 일정 — 단계별 일정이 사업 기간 안에 들어오는가. 기간의 합이 전체와 맞는가.
• 참여 인력 — 역할, 자격·경력, 참여율이 있는가. 한 사람의 참여율 합계가 100%를 넘지 않는가.
• 차별성 — 기 수행 과제나 유사 사업과 무엇이 다른지, 중복 지원이 아닌 근거가 있는가.
• 근거 — 시장 규모·매출 전망·기술 우위 주장에 출처나 산출 근거가 붙어 있는가.

5. 자주 반복되는 결함 다섯 가지

1. "추후 결정"이 결정되지 않은 채 개발에 들어간다. TBD 항목은 그 자체가 문제가 아니라, 기한과 담당이 없는 것이 문제입니다.
2. 성공 경로만 그린 플로우. 화면 흐름도에 뒤로가기와 오류 화면이 없으면 구현 단계에서 각자 다르게 만듭니다.
3. 수치는 있는데 단위가 없다. "쿨타임 30"이 초인지 프레임인지 적혀 있지 않아 그대로 구현되는 경우가 실제로 자주 발생합니다.
4. 표와 본문이 어긋난다. 본문을 고치고 표를 안 고치거나 그 반대. 문서 안 모순 중 가장 흔한 형태입니다.
5. 예외 문구가 정책을 무력화한다. "단, 운영진 판단에 따라 달라질 수 있음" 한 줄이 앞의 모든 기준을 무의미하게 만드는 경우입니다.

6. AI 감사 결과를 검증하는 절차

AI 검토 결과는 검토를 시작하기 위한 초안이지 결론이 아닙니다. 다음 순서로 확인하면 잘못된 지적에 시간을 낭비하지 않습니다.

1. 근거 문장을 원문에서 찾는다. 인용된 문장이 문서에 실제로 없거나 다르게 적혀 있으면 그 항목은 버립니다. 이 확인이 가장 중요하고 가장 빠릅니다.
2. 문맥을 확인한다. 근거는 맞지만 다른 장에서 이미 정의된 내용일 수 있습니다. 문서를 조각으로 나눠 검사하면 이런 지적이 나올 수 있습니다.
3. 심각도를 우리 기준으로 다시 매긴다. AI가 매긴 심각도는 제안일 뿐입니다.
4. 남은 항목만 담당자를 지정한다. 이 단계에서 남은 항목이 실제 작업 목록입니다.
5. 반복된 지적은 기준으로 승격한다. 여러 문서에서 같은 지적이 나왔다면, 그것은 문서 문제가 아니라 팀의 작성 습관 문제입니다.

7. 도구가 할 수 없는 일

다음은 AI 감사로 대체되지 않습니다. 미리 알고 쓰는 편이 낫습니다.

• 법률 자문. 계약서 검사는 "무엇이 빠졌는지"를 짚어 주는 것이지 법적 유효성 판단이 아닙니다. 실제 체결 전에는 변호사의 검토를 받으세요.
• 공고문·법령과의 대조. 정부지원사업 서류를 검사할 때, 해당 공고문을 함께 올리지 않으면 "공고가 요구한 항목"은 일반적인 기준으로만 판단됩니다.
• 재미 판단. 게임이 재미있을지는 문서 검사로 알 수 없습니다.
• 문서 밖 정보와의 대조. 실제 코드, 이전 버전, 다른 팀 문서와의 불일치는 그 자료를 함께 올리지 않는 한 찾을 수 없습니다.
• 수치의 타당성. "공격력 120"이 적혀 있으면 정의된 것으로 봅니다. 그 값이 밸런스상 적절한지는 시뮬레이션과 플레이의 영역입니다.
• 이미지·도표 안의 내용. 텍스트로 추출되지 않는 다이어그램은 검사 대상에 포함되지 않습니다. 중요한 내용은 본문에도 적어 두세요.