검사 기준 사전

문서 종류 6가지 · 기본 검사 기준 38개 · 2026년 10월 17일 정리

문서 분석기의 문서 감사·QA 산출물 모드는 사용자가 정한 "검사 기준"에 따라 문서를 읽습니다. 이 페이지는 도구에 기본으로 들어 있는 기준 38개를 그대로 공개하고, 각 기준에 걸렸을 때 어떻게 고치면 되는지를 덧붙인 사전입니다. 도구를 쓰지 않고 사람이 직접 검토할 때의 체크리스트로도 쓸 수 있습니다.

이 사전을 읽는 법

• 기준 ID — 보고서·CSV에 표시되는 번호입니다(예: CON-02). 결과에서 ID를 보면 이 사전에서 바로 찾을 수 있습니다.
• 심각도 — 치명·높음·보통·낮음 네 단계이며 의미는 판정 방식 아티클에 있습니다. 기준에 정해 둔 값은 "기본 심각도"이고, 실제 결과에서는 문서 내용에 따라 AI가 조정할 수 있습니다.
• 문제로 보는 경우 — 도구가 AI에게 전달하는 기준 문장 그대로입니다.
• 고치는 방법 — 이 사이트가 덧붙인 조치 예시입니다. AI가 출력하는 "수정 제안"과는 별개입니다.

문서 종류별 목차

• 계약서 — 기준 9개
• 정부지원사업 서류 — 기준 7개
• 게임 기획서 — 기준 7개
• QA 보고서 — 기준 6개
• 운영 정책 — 기준 5개
• 기타 — 기준 4개

계약서 (9개)

계약서 기준은 "무엇이 적혀 있는지·빠졌는지"를 점검하는 용도입니다. 조항이 법적으로 유효한지나 협상에서 유리한지는 판단하지 않으며, 법률 자문을 대신하지 않습니다.

CON-01 · 당사자·목적물 특정 미비 (기본 심각도: 치명)

문제로 보는 경우. 계약 당사자(상호, 대표자, 주소)나 계약 목적물(무엇을 제공하는지)이 특정되지 않았거나 "일체", "관련 업무" 같은 포괄적 표현으로만 적혀 있으면 문제로 본다.

고치는 방법. 당사자는 상호·대표자·주소를, 목적물은 "무엇을 어떤 범위로 제공하는지"를 별첨 표나 제1조에 구체적으로 적는다. "일체", "관련 업무"는 범위를 한정하는 문장으로 바꾼다.

CON-02 · 대금·지급 조건 불명확 (기본 심각도: 치명)

문제로 보는 경우. 금액, 지급 시기, 지급 방법, 부가세 포함 여부, 지연이자 중 하나라도 정해지지 않았으면 문제로 본다. "협의하여 정한다"만 있는 경우도 포함한다.

고치는 방법. 금액, 부가세 포함 여부, 지급 시기(예: 검수 후 30일 이내), 지급 방법, 지연 시 이자율을 한 조항에 모은다. "협의하여 정한다"는 협의 기한과 협의 불발 시 기준을 함께 쓴다.

CON-03 · 계약 기간·갱신·해지 조건 누락 (기본 심각도: 높음)

문제로 보는 경우. 계약 시작·종료 시점, 자동 갱신 여부와 갱신 거절 통지 기한, 중도 해지 사유와 절차 중 빠진 것이 있으면 문제로 본다.

고치는 방법. 시작일·종료일, 자동 갱신 여부와 거절 통지 기한, 중도 해지 사유와 통지 방법을 각각 적는다. 빠진 것이 무엇인지 표로 점검하면 누락을 찾기 쉽다.

CON-04 · 책임 한도·손해배상 조항 문제 (기본 심각도: 높음)

문제로 보는 경우. 손해배상 범위나 한도가 아예 없거나, 한쪽에만 무제한 책임을 지우는 형태이면 문제로 본다.

고치는 방법. 손해배상 범위(직접손해 한정 여부)와 한도(예: 계약금액 상한)를 정하고, 양쪽에 같은 기준이 적용되는지 확인한다.

CON-05 · 지식재산권 귀속 미정 (기본 심각도: 높음)

문제로 보는 경우. 용역·개발·제작 결과물을 다루면서 저작권·특허 등 권리의 귀속 주체와 이용 범위가 정해져 있지 않으면 문제로 본다.

고치는 방법. 결과물의 저작권·특허를 누가 갖는지, 상대방은 어떤 범위로 이용할 수 있는지, 기존 보유 자산은 제외되는지를 분리해서 적는다.

CON-06 · 비밀유지 범위·기간 불명확 (기본 심각도: 보통)

문제로 보는 경우. 비밀정보의 정의, 예외 사유, 유지 기간(계약 종료 후 포함) 중 빠진 것이 있으면 문제로 본다.

고치는 방법. 비밀정보의 정의, 비밀이 아닌 것의 예외(공지된 정보 등), 계약 종료 후 유지 기간을 적는다.

CON-07 · 준거법·분쟁 해결 조항 누락 (기본 심각도: 보통)

문제로 보는 경우. 준거법이나 관할 법원(또는 중재 기관)이 정해져 있지 않으면 문제로 본다.

고치는 방법. 어느 나라 법을 적용하는지와 분쟁 시 관할 법원(또는 중재 기관)을 명시한다.

CON-08 · 일방에게만 유리한 조항 (기본 심각도: 높음)

문제로 보는 경우. 해지권, 위약금, 검수 거부권, 대금 감액권 등이 한쪽에만 주어지고 상대방에게 대응 수단이 없으면 문제로 본다. 어느 쪽에 유리한지 함께 적는다.

고치는 방법. 해지권·위약금·검수 거부권 등이 한쪽에만 있다면 상대방에게도 대응 수단(이의 제기, 시정 기간, 대금 청구 등)을 줄지 검토한다. 어느 쪽에 유리한지 먼저 표시해 두면 협상 항목이 정리된다.

CON-09 · 조문 상호 참조 오류 (기본 심각도: 높음)

문제로 보는 경우. "제N조에 따라"처럼 다른 조항을 참조하는데 그 조항이 없거나 내용이 맞지 않으면 문제로 본다. 별첨·부속 문서 참조도 포함한다.

고치는 방법. "제N조에 따라"를 모두 찾아 해당 조가 실제로 있고 내용이 맞는지 대조한다. 조문 번호를 바꾼 버전에서 자주 어긋난다. 별첨도 같은 방식으로 확인한다.

정부지원사업 서류 (7개)

사업계획서·신청서에서 자주 반려되는 유형인 필수 항목 누락, 산출 근거 부재, 정량 목표 미기재, 일정 불일치를 잡도록 구성했습니다. 실제 평가 기준은 공고문마다 다르므로 공고문 원문이 우선합니다.

GOV-01 · 공고 요구 항목 누락 (기본 심각도: 치명)

문제로 보는 경우. 사업계획서의 필수 항목(사업 개요, 추진 체계, 사업비, 기대 효과 등) 중 제목만 있고 내용이 비어 있거나 아예 빠진 항목이 있으면 문제로 본다.

고치는 방법. 공고문의 필수 항목 목록과 사업계획서 목차를 나란히 놓고 한 줄씩 대조한다. 제목만 있고 비어 있는 항목은 "해당 없음"이라도 이유를 적는다.

GOV-02 · 사업비 산정 근거 부재·합계 불일치 (기본 심각도: 치명)

문제로 보는 경우. 사업비 항목에 단가·수량·산출식이 없거나, 세부 항목의 합과 총액이 맞지 않으면 문제로 본다. 자부담 비율이 조건과 다른 경우도 포함한다.

고치는 방법. 사업비는 단가 × 수량 = 금액 산출식을 적고, 세부 합계와 총액, 자부담 비율을 계산기로 다시 검산한다.

GOV-03 · 정량 목표 미기재 (기본 심각도: 높음)

문제로 보는 경우. 성과 목표를 제시하면서 측정 지표, 목표치, 달성 시점 중 하나라도 없으면 문제로 본다. "향상", "확대" 같은 서술만 있는 경우를 포함한다.

고치는 방법. "향상", "확대" 대신 지표 이름, 현재값, 목표값, 달성 시점을 한 줄로 적는다. 예: "월 방문자 1,000명 → 3,000명, 사업 종료 시".

GOV-04 · 일정과 사업 기간 불일치 (기본 심각도: 높음)

문제로 보는 경우. 추진 일정표의 시작·종료 시점이 사업 기간을 벗어나거나, 단계별 기간의 합이 전체 기간과 맞지 않으면 문제로 본다.

고치는 방법. 일정표의 가장 이른 시작과 가장 늦은 종료가 사업 기간 안에 들어오는지, 단계별 기간의 합이 전체 기간과 맞는지 확인한다.

GOV-05 · 참여 인력 정보 미비 (기본 심각도: 보통)

문제로 보는 경우. 참여 인력을 적으면서 역할, 자격·경력, 참여율(투입 비율) 중 빠진 것이 있으면 문제로 본다. 참여율 합계가 100%를 넘는 인력도 포함한다.

고치는 방법. 참여 인력마다 역할, 자격·경력, 참여율을 적고, 한 사람의 참여율 합계가 한도를 넘지 않는지 확인한다. 한도는 공고문 기준을 따른다.

GOV-06 · 중복 지원·차별성 미기재 (기본 심각도: 높음)

문제로 보는 경우. 유사한 기 수행 과제나 타 사업과의 차별성, 중복 지원이 아니라는 근거가 제시되지 않았으면 문제로 본다.

고치는 방법. 유사한 기존 과제나 타 사업을 적고, 무엇이 다른지와 중복 지원이 아닌 근거를 한 문단으로 쓴다.

GOV-07 · 근거 없는 성과 주장 (기본 심각도: 보통)

문제로 보는 경우. 시장 규모, 매출 전망, 기술 우위 등을 단정하면서 출처나 산출 근거가 없으면 문제로 본다.

고치는 방법. 시장 규모·매출 전망·기술 우위를 쓸 때는 출처(기관, 연도)나 산출식을 붙이고, 출처가 없으면 추정이라고 표시한다.

게임 기획서 (7개)

구현자가 기획서를 읽고 막히는 지점을 기준으로 삼았습니다. 수치 미정의, 예외 경로 누락, 문서 내 모순, 모호한 표현 같은 것들입니다.

SPEC-01 · 수치가 정의되지 않음 (기본 심각도: 높음)

문제로 보는 경우. 데미지·체력·쿨타임·보상량·확률 등 수치를 언급하면서 구체적인 값, 계산식, 또는 범위가 적혀 있지 않으면 문제로 본다.

고치는 방법. 수치를 언급한 곳마다 값, 단위, 계산식 또는 범위를 적는다. 여러 곳에서 쓰이는 값은 한 표에 모으고 다른 곳은 그 표를 참조하게 한다.

SPEC-02 · 예외·실패 경로 누락 (기본 심각도: 높음)

문제로 보는 경우. 조건 분기나 사용자 행동을 설명하면서 실패했을 때, 취소했을 때, 경계값(0, 최대치, 만료)일 때의 처리가 적혀 있지 않으면 문제로 본다.

고치는 방법. 각 기능마다 "실패했을 때", "취소했을 때", "0 또는 최대치일 때", "만료됐을 때"의 동작을 한 줄씩 추가한다.

SPEC-03 · 문서 내 모순 (기본 심각도: 치명)

문제로 보는 경우. 같은 대상에 대해 서로 다른 수치나 규칙이 문서 안에 함께 적혀 있으면 문제로 본다. 두 서술을 모두 근거로 인용한다.

고치는 방법. 모순된 두 서술 중 어느 쪽이 맞는지 기획자에게 확인하고, 틀린 쪽을 고친 뒤 같은 값이 쓰인 다른 곳도 찾아 함께 고친다.

SPEC-04 · 모호한 표현 (기본 심각도: 보통)

문제로 보는 경우. "적절히", "충분히", "자연스럽게", "빠르게"처럼 구현자가 임의로 판단해야 하는 표현이 사양 서술에 쓰였으면 문제로 본다.

고치는 방법. "적절히", "빠르게" 같은 표현을 측정 가능한 값(예: 0.3초 이내)이나 판정 규칙으로 바꾼다.

SPEC-05 · 용어 불일치 (기본 심각도: 보통)

문제로 보는 경우. 같은 개념을 서로 다른 용어로 부르거나, 정의 없이 새로운 용어를 사용하면 문제로 본다.

고치는 방법. 용어집을 만들어 같은 개념에 하나의 이름만 쓰고, 처음 나오는 곳에 정의를 붙인다.

SPEC-06 · 데이터 저장·동기화 미정 (기본 심각도: 높음)

문제로 보는 경우. 진행도·재화·설정 등을 다루면서 저장 시점, 서버 검증 여부, 재접속·중복 로그인 시 처리 방식이 없으면 문제로 본다.

고치는 방법. 무엇을 언제 저장하는지, 서버가 값을 검증하는지, 재접속·중복 로그인 때 어느 쪽이 우선하는지를 적는다.

SPEC-07 · 재화·확률 규정 위험 (기본 심각도: 치명)

문제로 보는 경우. 유료 재화나 확률형 요소를 다루면서 확률 표기, 획득 상한, 환불·보상 기준이 빠져 있으면 문제로 본다.

고치는 방법. 확률형 요소는 항목별 확률 표기 방식과 획득 상한, 유료 재화의 환불·보상 기준을 문서에 넣는다. 구체적 의무 범위는 현행 법령과 플랫폼 정책의 원문을 확인한다.

QA 보고서 (6개)

QA 보고서를 받은 개발자가 "재현이 안 된다", "그래서 뭐가 문제냐"라고 되묻게 만드는 요인을 기준으로 삼았습니다.

QA-01 · 재현 절차 불충분 (기본 심각도: 높음)

문제로 보는 경우. 버그 항목에 재현 단계, 기기/환경, 빌드 버전 중 하나라도 없어 다른 사람이 재현할 수 없으면 문제로 본다.

고치는 방법. 버그마다 재현 단계(번호), 기기·OS, 빌드 버전, 발생 빈도를 채운다. 다른 사람이 문서만 보고 재현할 수 있는지가 기준이다.

QA-02 · 기대 결과·실제 결과 미기재 (기본 심각도: 보통)

문제로 보는 경우. 무엇이 일어나야 하는데 무엇이 일어났는지가 구분되어 적혀 있지 않으면 문제로 본다.

고치는 방법. "기대 결과"와 "실제 결과"를 별도 칸으로 나눠 적는다.

QA-03 · 심각도와 내용 불일치 (기본 심각도: 치명)

문제로 보는 경우. 진행 불가·데이터 손실·결제 오류인데 낮은 심각도로 적혔거나, 사소한 표기 오류가 최고 심각도로 적혔으면 문제로 본다.

고치는 방법. 진행 불가·데이터 손실·결제 오류는 높은 심각도로, 표기 오류는 낮은 심각도로 맞춘다. 팀의 심각도 정의표를 문서 앞에 둔다.

QA-04 · 테스트 케이스 누락 (기본 심각도: 높음)

문제로 보는 경우. 기능을 테스트했다고 하면서 실패 경로, 경계값, 권한 없는 상태 등 당연히 필요한 케이스가 목록에 없으면 문제로 본다.

고치는 방법. 기능마다 정상 경로 외에 실패 경로, 경계값, 권한 없는 상태 케이스가 있는지 목록을 점검한다.

QA-05 · 판정 근거 없음 (기본 심각도: 보통)

문제로 보는 경우. Pass/Fail 판정이 적혀 있는데 확인 방법이나 증적(로그·스크린샷 언급)이 전혀 없으면 문제로 본다.

고치는 방법. Pass/Fail 옆에 확인 방법과 증적(로그 파일명, 스크린샷 번호 등)을 한 줄 붙인다.

QA-06 · 중복·상충 리포트 (기본 심각도: 보통)

문제로 보는 경우. 같은 현상이 여러 항목으로 중복 기재되었거나, 서로 반대되는 결과가 함께 적혀 있으면 문제로 본다.

고치는 방법. 같은 현상은 하나의 항목으로 합치고 재현 환경만 나열한다. 반대되는 결과가 있으면 환경 차이인지 확인해 조건을 적는다.

운영 정책 (5개)

이용자에게 제재·변경을 적용하는 운영 정책에서 분쟁이 되기 쉬운 지점(기준 모호, 고지 누락, 이의 제기 부재)을 점검합니다. 법정 고지 항목은 현행 법령 원문을 확인해야 합니다.

OPS-01 · 제재 기준 모호 (기본 심각도: 높음)

문제로 보는 경우. 제재·경고 사유를 정하면서 판단 기준이나 단계(횟수, 기간)가 구체적이지 않으면 문제로 본다.

고치는 방법. 제재 사유마다 판단 기준과 단계(경고 몇 회, 정지 기간)를 표로 만든다.

OPS-02 · 이용자 고지 절차 누락 (기본 심각도: 높음)

문제로 보는 경우. 정책을 변경하거나 제재를 적용할 때 언제 어떤 방법으로 알리는지가 없으면 문제로 본다.

고치는 방법. 정책 변경과 제재 적용 때 언제(시행 며칠 전), 어디로(공지·메일), 무엇을 알리는지 적는다.

OPS-03 · 이의제기·예외 절차 없음 (기본 심각도: 보통)

문제로 보는 경우. 이용자가 결과에 이의를 제기할 수 있는 창구나 기한이 정해져 있지 않으면 문제로 본다.

고치는 방법. 이의 제기 창구, 접수 기한, 처리 기한, 결과 통지 방법을 정한다.

OPS-04 · 법정 고지 항목 누락 (기본 심각도: 치명)

문제로 보는 경우. 청약 철회, 미성년자 결제, 확률 공시, 개인정보 취급 등 법령상 요구되는 고지 항목이 빠져 있으면 문제로 본다.

고치는 방법. 청약 철회, 미성년자 결제, 확률 공시, 개인정보 취급 등 서비스에 해당하는 고지 항목을 현행 법령 원문에서 확인해 목록으로 만들고, 문서에 있는지 대조한다.

OPS-05 · 정책 간 충돌 (기본 심각도: 높음)

문제로 보는 경우. 문서 안의 두 조항이 같은 상황에 대해 다른 결론을 내리면 문제로 본다.

고치는 방법. 충돌하는 두 조항의 적용 우선순위를 정하거나 하나로 통합한다.

기타 (4개)

종류를 특정하기 어려운 문서에 공통으로 적용되는 기본 기준입니다.

GEN-01 · 결정되지 않은 항목 (기본 심각도: 높음)

문제로 보는 경우. TBD, 미정, 협의 필요처럼 결정되지 않은 채 남아 있는 항목이 있으면 문제로 본다.

고치는 방법. TBD·미정 항목을 목록으로 뽑아 각각 결정 담당자와 결정 기한을 붙인다.

GEN-02 · 근거 없는 단정 (기본 심각도: 보통)

문제로 보는 경우. 수치나 사실을 단정하면서 출처나 산출 근거가 없으면 문제로 본다.

고치는 방법. 단정한 수치마다 출처나 산출식을 붙이거나 "추정"이라고 표시한다.

GEN-03 · 내용 모순 (기본 심각도: 치명)

문제로 보는 경우. 문서 안의 두 서술이 서로 어긋나면 문제로 본다.

고치는 방법. 어긋난 두 서술 중 맞는 쪽을 확인해 고치고, 같은 내용이 다른 곳에도 있는지 검색한다.

GEN-04 · 담당·기한 미지정 (기본 심각도: 보통)

문제로 보는 경우. 해야 할 일이 적혀 있는데 담당자나 기한이 없으면 문제로 본다.

고치는 방법. 할 일마다 담당자 이름과 기한을 채운다.

기본 기준의 심각도 분포

기본 기준 전체를 문서 종류별로 센 값입니다(도구의 기준 데이터에서 계산).

직접 기준을 만들 때

기본 기준이 맞지 않는 문서라면 "+ 검사 기준 추가"로 직접 쓰세요. 잘 쓴 기준은 위 사전처럼 "~이면 문제로 본다"로 끝나며, 무엇이 있거나 없을 때 문제인지가 구체적입니다. 작성 요령은 실무 가이드에 있습니다.