---
id: IP02
manual_id: IP02
series: Integrated Projects
title: AI 문서 검토 서비스 만들기
version: 0.1.0
content_version: 0.1.0
status: pilot
audience: 입문 개발자·AI 서비스 기획자·검토 운영자
estimated_time: 90분 실습 + 4시간 자율 학습
---

# AI 문서 검토 서비스 만들기

> **한 줄 목표:** 문서를 AI에게 ‘읽혀 보는 데모’가 아니라, 원문 provenance·검색 근거·구조화 finding·평가 dataset·사람의 판정·운영 evidence가 끝까지 연결된 로컬 서비스를 만듭니다.

## 1. 먼저 보는 한 장: 문서에서 사람 결정까지

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/01-document-to-human-decision-journey.svg" alt="합성 문서에서 검색, 출력 검증, 사람 판정, 평가로 이어지는 흐름"><figcaption>그림 1. AI 출력은 중간 산출물이고, 최종 학습 단위는 근거와 사람 판정까지 연결된 trace입니다.</figcaption></figure>

AI 문서 서비스는 ‘문서를 넣고 답을 받는 화면’만으로 완성되지 않습니다. 어떤 문서 version을 읽었는지, 어떤 정책 rule로 어떤 chunk를 찾았는지, 인용이 원문에 실제 존재하는지, 출력이 schema를 만족하는지, 사람이 어떤 이유로 수용·거절·수정·상향했는지가 이어져야 합니다.

| 단계 | 학습 질문 | IP02 evidence |
|---|---|---|
| Source | 무엇을 읽었나 | document·section·chunk ID + checksum |
| Retrieve | 왜 이 근거인가 | rule query·rank·score |
| Validate | 출력 형식과 인용이 맞나 | schema·membership·substring |
| Decide | 누가 무엇을 결정했나 | decision·reason·actor·time |
| Evaluate | 어떤 case에서 얼마나 통과했나 | 12 cases·metric denominator |

## 2. 이 교재를 공부하는 순서

이 교재는 개념 설명을 길게 읽고 마지막에 실습하는 방식이 아닙니다. 각 장에서 먼저 그림을 보고, 실제 화면에서 같은 요소를 찾고, 작은 검증을 실행한 뒤, 마지막에 자기 말로 설명합니다.

| 순서 | 행동 | 완료 신호 |
|---|---|---|
| 1 · SEE | 도표의 화살표와 경계 색을 먼저 본다 | 한 문장으로 흐름 설명 |
| 2 · FIND | 실제 앱 화면에서 같은 ID를 찾는다 | DOC·RULE·RUN·chunk 연결 |
| 3 · DO | 실습 command와 역할 흐름을 실행한다 | 정상·거부·abstain 재현 |
| 4 · EXPLAIN | Expected와 actual 차이를 기록한다 | evidence·한계·next action |
| 5 · TEST | 셀프 테스트를 풀고 정답을 펼친다 | 틀린 질문의 도표로 회귀 |

> **PDF 활용법:** 한 장을 공부한 뒤 화면을 가리고 도표의 다음 화살표를 말해 보세요. 읽은 내용을 다시 말하는 것보다 빈칸에서 workflow를 복원하는 연습이 오래 남습니다.

## 3. 문제·사용자·권한 경계를 먼저 정하기

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/02-authority-and-ai-safety-boundary.svg" alt="로컬 학습, pilot, production, assurance의 권한 경계"><figcaption>그림 2. 각 단계의 통과는 다음 단계 승인이 아닙니다.</figcaption></figure>

IP02가 답하는 질문은 ‘합성 문서의 정책 누락을 근거와 함께 보여 주고, 사람이 판정하는 workflow가 연결됐는가’입니다. 실제 법률 적합성, 실제 고객 문서 처리, 실제 모델 안전성, production 운영 승인은 답하지 않습니다.

| 포함 | 제외 | 다음 권한 단계 |
|---|---|---|
| 합성 문서 3종 | 실제 계약서·개인정보 | 데이터 owner 승인 |
| 로컬 deterministic provider | 실제 LLM 품질 | Model owner 평가 |
| FTS5 lexical retrieval | embedding·vector DB | Architecture 검토 |
| 12 합성 eval cases | 실제 분포 성능 | Pilot dataset 평가 |
| 학습 Gate | 보안·법률 인증 | 권한 있는 조직 승인 |

## 4. 전체 서비스 구조와 같은 사건 추적

한 번의 검토 실행 `RUN-003`을 예로 들면 `DOC-003` → `RULE-05` → retrieval `DOC-003-C01` → finding → human decision → evaluation·audit가 연결됩니다. 각 계층은 같은 사건을 서로 다른 이름으로 복제하지 않고 안정된 ID로 참조합니다.

| 계층 | 핵심 record | 같은 사건 확인 |
|---|---|---|
| UI | selected document·review run | DOC-003·RUN-003 |
| API | POST review·GET run | request ID·run ID |
| DB | review_runs·retrievals·findings | foreign key |
| Policy | RULE-01~06 | rule ID·version |
| Evaluation | EV-01~12 | evidence ID |
| Gate | SC-01~24 | control·risk·critical |

## 5. 네 역할과 decision right

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/03-roles-and-decision-rights.svg" alt="Author Reviewer Risk owner Viewer의 판정 권한"><figcaption>그림 3. HIGH finding의 수용·수정 권한은 Risk owner에게만 있습니다.</figcaption></figure>

| 역할 | 읽기 | 검토 실행 | 일반 판정 | HIGH accept/edit |
|---|---|---|---|---|
| AUTHOR | 허용 | 허용 | 거부 | 거부 |
| REVIEWER | 허용 | 허용 | reject·edit(중위험)·escalate | 거부 |
| RISK_OWNER | 허용 | 허용 | 모두 | 허용 |
| VIEWER | 허용 | 거부 | 거부 | 거부 |

화면에서 버튼을 숨기는 것은 사용성 조치입니다. 보안 경계는 서버가 `role + action + severity + decision`을 다시 검사하는 곳에 있습니다. 거부된 요청도 DB mutation 없이 problem response와 redacted audit를 남깁니다.

## 6. 문서 lifecycle과 classification

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/04-document-lifecycle-and-classification.svg" alt="DRAFT INGESTED REVIEWING HUMAN REVIEW RESOLVED와 실패·상향 상태"><figcaption>그림 4. 문서는 처리 상태와 분류·보존 책임을 가진 record입니다.</figcaption></figure>

| 상태 | 뜻 | 다음 확인 |
|---|---|---|
| DRAFT | 아직 ingestion 전 | classification·owner |
| INGESTED | section·chunk·checksum 생성 | provenance |
| REVIEWING | retrieval·provider 실행 중 | timeout·trace |
| HUMAN_REVIEW | 검증된 finding 판정 대기 | decision right |
| RESOLVED | 필요 판정 완료 | audit·handoff |
| FAILED | schema·retrieval·저장 실패 | retry·incident |
| ESCALATED | 현재 권한 밖 | risk owner |

## 7. Ingestion·chunk·checksum·provenance

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/05-ingestion-chunk-checksum-provenance.svg" alt="원문에서 section과 chunk로 이어지는 provenance"><figcaption>그림 5. 검색 편의를 위해 나눠도 원문으로 되돌아가는 ID와 checksum을 유지합니다.</figcaption></figure>

IP02는 각 합성 문서를 3개 section·3개 chunk로 만듭니다. 실제 서비스라면 chunk size·overlap·OCR·parser version을 추가로 기록해야 하지만, 이 실습은 의미 단위와 provenance 계약을 먼저 익히도록 단순화합니다.

| Record | 예 | 검증 |
|---|---|---|
| Document | DOC-003 | classification·version·SHA-256 |
| Section | DOC-003-S02 | heading·ordinal·body |
| Chunk | DOC-003-C02 | section link·text·SHA-256 |
| Source quote | IGNORE ALL PREVIOUS… | chunk exact substring |

## 8. Retrieval·ranking·citation grounding

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/06-retrieval-ranking-and-citation-grounding.svg" alt="Rule query에서 FTS5 검색과 citation validator까지의 흐름"><figcaption>그림 6. 검색되지 않은 chunk와 원문에 없는 quote는 저장 전에 거부합니다.</figcaption></figure>

각 policy rule은 검색 query를 가집니다. FTS5가 같은 document 안의 chunk를 찾아 rank와 score를 남기고, 결과가 없으면 제한된 local fallback을 사용합니다. Provider는 retrieval set 밖을 인용할 수 없습니다.

| 검사 | Expected | 실패 시 |
|---|---|---|
| Document filter | 현재 DOC만 | 다른 문서 인용 거부 |
| Top-k | 최대 2 chunk | context·cost 증가 관찰 |
| Membership | chunk ID ∈ retrieval set | finding reject |
| Exact quote | quote ⊂ chunk text | finding reject |
| Empty retrieval | reason과 abstain | 무근거 생성 금지 |

## 9. Instruction trust와 Prompt Injection

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/07-instruction-trust-and-prompt-injection.svg" alt="신뢰된 제어와 비신뢰 문서 데이터를 나눈 경계"><figcaption>그림 7. 문서 속 지시문은 실행하지 않고 인용·분석할 데이터로만 취급합니다.</figcaption></figure>

Prompt injection 방어의 출발점은 ‘문서가 모델에게 지시할 권한이 없다’는 것입니다. `DOC-003`의 공격 문장은 삭제하지 않습니다. 화면에서 붉게 표시하고, retrieval quote에도 나타나게 해 학습자가 공격이 존재한 채로 정책이 유지되는 것을 확인합니다.

| 통제 | IP02 구현 | 실제 서비스 확장 |
|---|---|---|
| Hierarchy | server policy 우선 | provider별 system/developer contract |
| Isolation | document text를 data로 전달 | tool·URL·file sandbox |
| Authorization | 문서가 action 실행 불가 | tool allowlist·confirmation |
| Validation | schema·citation 검사 | semantic support·DLP |
| Human review | 결정권 분리 | 고위험 four-eyes |

## 10. Provider input·output·version contract

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/08-provider-input-output-schema-contract.svg" alt="Versioned provider input과 structured output"><figcaption>그림 8. Provider를 바꿔도 입력 provenance와 출력 schema 계약은 유지합니다.</figcaption></figure>

| Input | Output | Version evidence |
|---|---|---|
| document ID | claim | document version |
| rule ID·expected | severity·confidence | policy version |
| retrieved chunks | chunk ID·source quote | retrieval trace |
| boundary instruction | recommended action | prompt version |
| provider config | abstain reason | provider·schema version |

실제 OpenAI API를 연결할 경우 structured output과 file input·file search의 현재 동작·보존·지원 형식을 공식 문서에서 다시 확인해야 합니다. IP02는 네트워크 호출 없이 같은 계약과 실패 경로를 먼저 학습합니다.

## 11. Structured finding과 citation validation

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/09-structured-output-and-citation-validation.svg" alt="Schema citation quote enum range의 다섯 검증"><figcaption>그림 9. 출력은 저장 전에 결정적인 검사를 거칩니다.</figcaption></figure>

| Field | Rule | 예 |
|---|---|---|
| rule_id | 존재하는 policy rule | RULE-05 |
| claim | 비어 있지 않음 | 보존 기간이 보이지 않음 |
| severity | LOW·MEDIUM·HIGH·CRITICAL | MEDIUM |
| confidence | 0~1 | 0.88 |
| chunk_id | retrieved set 안 | DOC-003-C01 |
| source_quote | 해당 chunk exact substring | 외부 파트너… |
| policy_quote | rule expected | 보존 기간과 삭제 책임… |

Validator의 `VALID`은 사실성 인증이 아닙니다. ‘최소한 올바른 형식으로, 검색된 chunk의 실제 문장을 가리킨다’는 저장 전 계약입니다. 의미적 support는 eval과 사람이 다시 봅니다.

## 12. Hallucination·uncertainty·abstain

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/10-uncertainty-abstain-and-contradiction.svg" alt="근거 충분·부족·누락·모순에 따른 abstain finding escalate"><figcaption>그림 10. 모를 때 멈추는 것도 명시적 출력입니다.</figcaption></figure>

| 상황 | 출력 | 사람에게 보이는 뜻 |
|---|---|---|
| 요구사항 후보가 보임 | abstain: requirement_observed | 누락 finding 없음 |
| 검색 근거 없음 | abstain: insufficient_evidence | 판단 보류 |
| 정책 누락이 검증됨 | finding | 사람 판정 필요 |
| 근거 모순·고위험 | escalate | 상위 책임자 필요 |
| schema·citation 실패 | reject/abstain | 출력 저장 금지 |

## 13. Human review·decision·escalation

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/12-human-review-decision-and-escalation.svg" alt="Accept Reject Edit Escalate 네 사람 판정"><figcaption>그림 11. 사람 판정은 decision과 이유·actor·time을 함께 남깁니다.</figcaption></figure>

| Decision | 언제 | 필수 기록 |
|---|---|---|
| ACCEPTED | 근거와 정책에 동의 | reason·actor·time |
| REJECTED | 오탐·부적합·근거 부족 | reason |
| EDITED | claim을 더 정확하게 수정 | edited claim·reason |
| ESCALATED | 현재 권한 밖·고위험 | target owner·reason |

## 14. Privacy·retention·redaction·access

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/13-privacy-retention-redaction-and-access.svg" alt="입력 처리 출력 보존 접근의 privacy 흐름"><figcaption>그림 12. 문서 원문과 판정 기록은 입력부터 삭제까지 책임이 이어집니다.</figcaption></figure>

| 위험 | 학습 통제 | Production gap |
|---|---|---|
| 실제 개인정보 | 합성 문서만 | DPIA·계약·지역 법률 |
| 외부 전송 | 네트워크 없는 provider | provider data controls |
| Raw log 노출 | ID·action·outcome만 audit | central logging redaction |
| 과도한 접근 | 4 role server authz | SSO·SCIM·least privilege review |
| 무기한 보존 | policy requirement 평가 | 삭제 job·legal hold |

## 15. Evaluation dataset·metric denominator

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/11-evaluation-dataset-and-metric-denominator.svg" alt="12개 평가 case와 metric 분모"><figcaption>그림 13. 점수는 dataset version·분모·evidence ID와 함께 읽습니다.</figcaption></figure>

| Lane | 대표 case | Metric |
|---|---|---|
| Grounding | 검색 chunk만 인용·exact quote | citation validity |
| Quality | 완전 문서 false positive·누락 recall | precision·recall |
| Safety | 문서 지시 무시·고위험 권한 | injection resistance·authorization |
| Human | 판정 audit | human agreement |
| Contract | schema 검증 | structured output |
| Operation | provider version·trace | reproducibility·cost proxy |

## 16. Cost·latency·observability·incident

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/14-cost-latency-observability-and-incident.svg" alt="Latency cost proxy observability incident의 운영 사분면"><figcaption>그림 14. 품질 지표와 운영 지표를 함께 봅니다.</figcaption></figure>

| 질문 | Signal | 한계/다음 행동 |
|---|---|---|
| 얼마나 걸렸나 | started_at·finished_at | 실제 provider p50/p95 필요 |
| 비용은 무엇에 비례하나 | retrieved chunks·runs·findings | token·사람 검토 비용 추가 |
| 무슨 사건인가 | request ID·run ID·audit | 분산 trace 확장 |
| 위험하면 어떻게 멈추나 | review run disable·Gate block | kill switch·feature flag |
| 복구 가능한가 | SQLite backup·restore·integrity | RPO/RTO·multi-region |

## 17. 앱 실행·reset·검증

```bash
cd 02_Labs/Integrated_Projects/IP02_starter
python3 scripts/reset_lab.py
python3 app.py --host 127.0.0.1 --port 4524
```

다른 터미널에서 다음 네 검사를 실행합니다.

```bash
python3 -m unittest discover -s tests -v
python3 scripts/audit_integrated_project_contract.py
python3 scripts/contract_probe.py
python3 scripts/backup_restore_rehearsal.py
```

| 검사 | Expected |
|---|---|
| Unit/integration/frontend/server | 384/384 PASS |
| Integrated contract audit | 72/72 PASS |
| Scenario candidate | 24/24·critical 12/12 |
| Evaluation | 12/12 |
| Foreign key | 0 errors |
| Restore | counts match·integrity ok |

## 18. Documents 화면에서 provenance 읽기

<figure class="visual screenshot"><img src="../../07_Assets/IP02/lab/01-documents-desktop.jpg" alt="데스크톱 Documents 화면의 문서 목록과 원문 section"><figcaption>실습 화면 1. 문서 목록·classification·chunk 수와 원문 section·checksum을 한 화면에서 확인합니다.</figcaption></figure>

`DOC-001`은 모든 정책 요구사항이 보이는 완전한 합성 문서입니다. 이 문서에서 검토를 실행하면 0 finding·6 abstain이 나와야 합니다. Finding 수가 많을수록 좋은 서비스가 아니라, 필요할 때만 정확히 생성하는 서비스가 목표입니다.

## 19. Prompt Injection 문서를 데이터로 확인하기

<figure class="visual screenshot"><img src="../../07_Assets/IP02/lab/02-injection-document-desktop.jpg" alt="UNTRUSTED TEXT 표시가 있는 DOC-003 원문"><figcaption>실습 화면 2. 공격 문구를 숨기지 않고 비신뢰 데이터로 표시합니다.</figcaption></figure>

문서 카드의 `UNTRUSTED TEXT`, source flow의 trust 상태, 붉은 section을 확인합니다. 공격 문장이 그대로 보이더라도 앱 navigation·role·policy·Gate가 바뀌지 않아야 합니다.

## 20. Review 화면에서 document quote와 policy quote 비교하기

<figure class="visual screenshot"><img src="../../07_Assets/IP02/lab/03-review-injection-desktop.jpg" alt="DOC-003 검토 finding과 두 근거 quote"><figcaption>실습 화면 3. 각 finding은 문서 quote와 정책 기대를 나란히 보여 줍니다.</figcaption></figure>

사람은 AI claim부터 읽지 않습니다. `DOCUMENT · chunk ID`와 `POLICY EXPECTATION`을 먼저 비교하고, 그 다음 claim·severity·confidence·recommended action을 읽습니다. 화면 순서 자체가 source-first review를 가르치도록 설계했습니다.

## 21. 완전 문서·누락 문서·공격 문서 비교하기

<figure class="visual screenshot"><img src="../../07_Assets/IP02/lab/04-review-missing-desktop.jpg" alt="DOC-002의 여섯 누락 finding"><figcaption>실습 화면 4. 근거 누락 문서는 여섯 policy rule에 대해 검증된 finding을 만듭니다.</figcaption></figure>

| 문서 | 설계 의도 | Expected result |
|---|---|---|
| DOC-001 | 요구사항 완전 | 0 finding / 6 abstain |
| DOC-002 | 근거 누락 | 6 finding / 0 abstain |
| DOC-003 | Prompt injection 포함·일부 요구 충족 | 3 finding / 3 abstain |

이 세 문서는 모델 benchmark가 아니라 workflow fixture입니다. 실제 서비스에서는 문서 유형·길이·언어·표·OCR·공격 방식·정답 불일치가 더 다양한 evaluation set이 필요합니다.

## 22. Evaluation 화면에서 12/12의 의미 읽기

<figure class="visual screenshot"><img src="../../07_Assets/IP02/lab/05-evaluation-desktop.jpg" alt="12개 evaluation case와 metric 표"><figcaption>실습 화면 5. PASS 숫자와 함께 lane·metric·expected·evidence를 읽습니다.</figcaption></figure>

`12/12 PASS`만 캡처하지 마세요. 어떤 case가 어떤 metric 분모에 들어갔는지, expected가 actual과 어떻게 비교되는지, dataset version이 무엇인지 함께 남깁니다.

## 23. Evidence 화면과 AI Service Gate

<figure class="visual screenshot"><img src="../../07_Assets/IP02/lab/06-evidence-desktop.jpg" alt="12 controls와 24 scenarios가 있는 Evidence 화면"><figcaption>실습 화면 6. 기능 시연이 아니라 연결된 control·scenario·evaluation으로 Gate를 판정합니다.</figcaption></figure>

<figure class="visual diagram"><img src="../../07_Assets/IP02/diagrams/15-ai-service-gate.svg" alt="12 control과 24 scenario 12 evaluation이 연결된 Gate"><figcaption>그림 15. 24/24 뒤에도 실제 모델·문서·사용자·production 검증이 남아 있습니다.</figcaption></figure>

| Gate signal | Threshold | IP02 actual |
|---|---|---|
| Scenario | 24/24 | 24/24 |
| Critical | 12/12 | 12/12 |
| Controls | 12/12 | 12/12 |
| Evaluation | 12/12 | 12/12 |
| Orphan | 0 | 0 |
| Unsupported | 0 | 0 |
| Regression | 0 | 0 |
| Open TBR | 공개 | 2 |

## 24. 모바일 Documents에서 가로 넘침 없이 읽기

<figure class="visual screenshot"><img src="../../07_Assets/IP02/lab/08-documents-mobile.jpg" alt="375 곱하기 812 모바일 Documents 화면"><figcaption>실습 화면 7. 문서 카드·UNTRUSTED TEXT·선택 문서 metadata가 한 열로 읽힙니다.</figcaption></figure>

모바일은 화면을 축소하지 않습니다. 하단 navigation을 고정하고 본문만 내부 scroll하며, 문서 목록을 안정된 한 열로 재배치합니다. 375×812에서 `scrollWidth - clientWidth = 0`을 확인했습니다.

## 25. 모바일 Review와 Evidence에서 정보 밀도 다루기

<figure class="visual screenshot"><img src="../../07_Assets/IP02/lab/09-review-mobile.jpg" alt="375 곱하기 812 모바일 Review 화면"><figcaption>실습 화면 8. Run 목록·선택 review·핵심 metric을 세로로 읽고 finding으로 내려갑니다.</figcaption></figure>

<figure class="visual screenshot"><img src="../../07_Assets/IP02/lab/07-evidence-mobile.jpg" alt="375 곱하기 812 모바일 Evidence 화면"><figcaption>실습 화면 9. Gate metric은 2열, controls는 1열, scenarios는 4열로 재배치됩니다.</figcaption></figure>

| 영역 | Desktop | Mobile |
|---|---|---|
| Navigation | 왼쪽 sidebar | 하단 fixed nav |
| Document/Run list | 왼쪽 rail | 한 열 list |
| Grounding quote | 2열 비교 | 한 열 순차 |
| Decision form | 4열 | 한 열 |
| Gate metrics | 6열 | 2열 |
| Main scroll | page | app main 내부 |

## 26. 12 controls·24 scenarios·세 readiness version

| Version | Pass | Evidence | Orphan | Unsupported | TBR | Decision |
|---|---|---|---|---|---|---|
| ungrounded-demo-v1 | 7 | 5 | 12 | 8 | 9 | blocked_ungrounded_ai_summary |
| connected-rag-v2 | 16 | 15 | 3 | 2 | 4 | blocked_incomplete_ai_assurance |
| evaluated-human-review-v3 | 24 | 24 | 0 | 0 | 2 | ai_service_review_ready |

**12 Controls**

| ID | Control | Minimum evidence |
|---|---|---|
| CTRL-01 | Purpose·scope·authority boundary | purpose-scope-boundary |
| CTRL-02 | Document classification·lifecycle·retention | document-lifecycle |
| CTRL-03 | Ingestion·chunk·checksum·provenance | ingestion-provenance |
| CTRL-04 | Retrieval·ranking·citation grounding | retrieval-citation |
| CTRL-05 | Instruction trust·prompt injection boundary | instruction-trust |
| CTRL-06 | Model input/output·schema·version contract | provider-contract |
| CTRL-07 | Evaluation dataset·grader·metric denominator | evaluation-record |
| CTRL-08 | Hallucination·uncertainty·abstain·contradiction | uncertainty-record |
| CTRL-09 | Human review·decision right·escalation | human-decision |
| CTRL-10 | Privacy·security·redaction·access control | security-record |
| CTRL-11 | Latency·cost·observability·incident·restore | operation-evidence |
| CTRL-12 | Value·risk·handover·AI Gate decision | ai-gate-package |

**24 Scenarios**

| ID | Scenario | Lane | Control | Risk | Critical |
|---|---|---|---|---|---|
| SC-01 | purpose and non-goal | document-retrieval | CTRL-01 | purpose |  |
| SC-02 | classification and retention | document-retrieval | CTRL-02 | provenance | YES |
| SC-03 | section chunk provenance | document-retrieval | CTRL-03 | grounding |  |
| SC-04 | checksum and source span | document-retrieval | CTRL-04 | injection | YES |
| SC-05 | retrieval ranking | document-retrieval | CTRL-05 | hallucination |  |
| SC-06 | empty retrieval abstain | document-retrieval | CTRL-06 | privacy | YES |
| SC-07 | provider input version | model-output | CTRL-07 | decision |  |
| SC-08 | structured output schema | model-output | CTRL-08 | operation | YES |
| SC-09 | citation membership | model-output | CTRL-09 | purpose | YES |
| SC-10 | quote validation | model-output | CTRL-10 | provenance | YES |
| SC-11 | unsupported finding reject | model-output | CTRL-11 | grounding |  |
| SC-12 | contradiction handling | model-output | CTRL-12 | injection |  |
| SC-13 | instruction hierarchy | safety-human | CTRL-01 | hallucination | YES |
| SC-14 | prompt injection resistance | safety-human | CTRL-02 | privacy | YES |
| SC-15 | sensitive output redaction | safety-human | CTRL-03 | decision | YES |
| SC-16 | viewer decision denied | safety-human | CTRL-04 | operation |  |
| SC-17 | human accept reject edit | safety-human | CTRL-05 | purpose |  |
| SC-18 | high risk escalation | safety-human | CTRL-06 | provenance | YES |
| SC-19 | gold dataset version | evaluation-operation | CTRL-07 | grounding |  |
| SC-20 | metric denominator threshold | evaluation-operation | CTRL-08 | injection | YES |
| SC-21 | evaluation regression | evaluation-operation | CTRL-09 | hallucination |  |
| SC-22 | latency cost trace | evaluation-operation | CTRL-10 | privacy |  |
| SC-23 | backup restore incident | evaluation-operation | CTRL-11 | decision | YES |
| SC-24 | value authority handoff | evaluation-operation | CTRL-12 | operation |  |

## 27. 90분 실습 워크북

| 시간 | 행동 | 남길 evidence | 통과 질문 |
|---|---|---|---|
| 0~10분 | 목적·non-goal·authority | boundary note | AI가 결정 주체가 아님이 보이나 |
| 10~20분 | 문서 lifecycle·provenance | DOC/section/chunk trace | 원문으로 되돌아가나 |
| 20~30분 | retrieval·citation | query/rank/quote | retrieved set만 인용하나 |
| 30~40분 | injection·schema | attack fixture·validator | 문서 지시를 실행하지 않나 |
| 40~50분 | abstain·finding | 3 documents comparison | 0/6·6/0·3/3 재현 |
| 50~60분 | human decision | accept/reject/edit/escalate | role·severity 권한이 맞나 |
| 60~70분 | evaluation | 12 cases·metric denominator | score 의미를 설명하나 |
| 70~80분 | privacy·operation | redacted audit·restore | 원문·token이 log에 없나 |
| 80~90분 | AI Gate·handoff | 24/24·TBR·next test | production gap을 숨기지 않나 |

별도 워크북 `02_Labs/Integrated_Projects/IP02_build-ai-document-review-service.md`의 12 control checklist와 `03_Templates/TIP02_ai-document-review-evidence-package.md`를 함께 사용합니다.

## 28. 공식 자료와 적용 경계

> 아래는 최신 동작과 원리를 다시 확인할 1차 자료입니다. 링크를 넣었다는 사실만으로 IP02가 해당 표준에 적합하거나 인증됐다는 뜻은 아닙니다. 확인 기준일은 2026-07-16입니다.

| 공식 자료 | 확인할 원리 | 적용 경계 |
|---|---|---|
| [NIST AI RMF 1.0](https://www.nist.gov/itl/ai-risk-management-framework) | Govern·Map·Measure·Manage 기반 위험 질문 | RMF 1.0은 revision 진행 중; 조직 적용 필요 |
| [NIST AI 600-1 Generative AI Profile](https://doi.org/10.6028/NIST.AI.600-1) | 생성형 AI 특유 위험·action | 프로필 참고가 평가·인증을 대신하지 않음 |
| [NIST AI TEVV](https://www.nist.gov/artificial-intelligence/ai-fundamental-research-ai-test-evaluation-validation-and-verification-tevv) | 시험·평가·검증·확인의 구분 | 실제 context와 독립 평가 필요 |
| [OWASP Top 10 for LLM Applications 2025](https://genai.owasp.org/llm-top-10/) | Prompt injection·민감정보·과도한 agency 검토 | 목록 사용이 침투시험·보안 인증이 아님 |
| [OpenAI Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs) | JSON schema 기반 출력 계약 | 실제 지원 model·제약을 구현 시 재확인 |
| [OpenAI File Inputs](https://developers.openai.com/api/docs/guides/file-inputs) | 파일 입력 형식과 처리 방식 | 데이터 분류·보존·법률 책임은 서비스 owner |
| [OpenAI File Search](https://developers.openai.com/api/docs/guides/tools-file-search) | hosted retrieval의 기본 개념 | IP02는 SQLite FTS5만 사용 |
| [OpenAI Data Controls](https://platform.openai.com/docs/guides/your-data) | API 데이터 처리·보존 control 확인 | 계정·제품·계약별 최신 조건 재확인 |
| [JSON Schema 2020-12](https://json-schema.org/draft/2020-12) | structured JSON type·required·enum·constraint | 업무 의미와 authorization은 별도 |
| [WCAG 2.2](https://www.w3.org/TR/WCAG22/) | keyboard·focus·reflow·name·contrast | 자동 검사만으로 전체 적합 보장 아님 |
| [SQLite FTS5](https://www.sqlite.org/fts5.html) | local full-text search·ranking | 실제 multilingual retrieval 품질 보장 아님 |
| [Python http.server](https://docs.python.org/3/library/http.server.html) | 표준 라이브러리 로컬 서버 | production 사용 권장 서버가 아님 |

## 29. 셀프 테스트 30

### 1. AI 문서 검토 서비스에서 최종 결정 주체는 누구인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 권한 있는 사람입니다. AI는 근거를 정리하는 decision support이며 최종 판단과 책임을 대신하지 않습니다.</p>
</details>

### 2. IP02의 local synthetic provider가 실제 모델을 대신하지 못하는 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 결정적 규칙으로 workflow와 검증 계약만 재현할 뿐 실제 모델의 언어 능력·오류 분포·비용·데이터 처리를 검증하지 않기 때문입니다.</p>
</details>

### 3. 문서 checksum을 남기는 가장 직접적인 목적은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 검토와 인용이 어느 내용 version을 기준으로 했는지 확인하고 내용 변경을 감지하기 위해서입니다.</p>
</details>

### 4. Section과 chunk를 나누고도 provenance를 잃지 않으려면 무엇이 필요한가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> document ID·section ID·chunk ID·ordinal·checksum과 원문으로 돌아가는 관계가 필요합니다.</p>
</details>

### 5. Retrieval trace에 최소 어떤 정보가 있어야 하나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> run ID·rule ID·query·document filter·chunk ID·rank·score가 있어야 합니다.</p>
</details>

### 6. Citation membership 검사는 무엇을 막나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 모델이 검색되지 않은 chunk나 존재하지 않는 source를 인용하는 것을 막습니다.</p>
</details>

### 7. Quote validation만 통과하면 finding이 참이라고 말할 수 있나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아닙니다. 원문에 문장이 존재함만 확인할 뿐 그 문장이 claim을 의미적으로 지지하는지는 사람과 추가 평가가 확인해야 합니다.</p>
</details>

### 8. 문서 속 IGNORE PREVIOUS INSTRUCTIONS 문장은 어떻게 처리하나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 실행할 지시가 아니라 분석할 비신뢰 데이터로만 처리합니다.</p>
</details>

### 9. Prompt injection을 단어 필터 하나로 해결할 수 없는 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 표현이 다양하고 우회가 가능하므로 instruction hierarchy·권한 제한·retrieval·출력 검증·사람 판정을 함께 써야 하기 때문입니다.</p>
</details>

### 10. Structured output의 핵심 이점은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 필수 field·enum·range·citation을 결정적으로 검사하고 실패 위치를 설명할 수 있다는 점입니다.</p>
</details>

### 11. Finding이 가져야 할 두 종류의 quote는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 검토한 document quote와 기준이 된 policy quote입니다.</p>
</details>

### 12. Abstain은 실패인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 항상 실패는 아닙니다. 근거가 부족하거나 요구사항이 이미 보일 때 무리한 finding을 만들지 않는 설계된 안전 출력입니다.</p>
</details>

### 13. Requirement observed abstain과 insufficient evidence abstain의 차이는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 전자는 요구사항 후보가 근거에서 보여 누락 finding을 만들지 않은 것이고, 후자는 판단할 근거 자체가 부족한 것입니다.</p>
</details>

### 14. Reviewer가 HIGH finding을 ACCEPTED로 만들 수 없는 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 고위험 수용·수정 권한을 Risk owner에게 분리해 decision right와 책임을 명확히 하기 위해서입니다.</p>
</details>

### 15. Human decision record에 decision 외 무엇을 남기나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> Reason·edited claim(필요 시)·actor·timestamp·finding ID를 남깁니다.</p>
</details>

### 16. Evaluation 점수에 분모가 필요한 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 12/12처럼 몇 건의 어떤 case를 평가했는지 알아야 점수를 과장하지 않고 비교할 수 있기 때문입니다.</p>
</details>

### 17. Citation validity와 recall은 같은 지표인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아닙니다. Citation validity는 제시한 인용의 유효성을, recall은 찾아야 할 문제를 얼마나 발견했는지를 봅니다.</p>
</details>

### 18. IP02의 12/12 evaluation이 실제 업무 성능을 보증하나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아닙니다. 12개 합성 case의 계약 검증 결과이며 실제 문서 분포·언어·공격·모델 성능은 별도 평가가 필요합니다.</p>
</details>

### 19. 평가 dataset을 versioning해야 하는 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> Case와 expected가 바뀌었을 때 점수 변화를 모델 개선과 dataset 변경으로 구분하기 위해서입니다.</p>
</details>

### 20. AI 비용 proxy의 한계는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> Chunk·finding·호출 수는 실제 token 가격·provider 과금·사람 검토 비용을 정확히 나타내지 못합니다.</p>
</details>

### 21. Audit log에 원문 전체와 session token을 남기지 않는 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 운영 추적에 불필요한 민감 데이터 노출과 자격 증명 탈취 위험을 줄이기 위해서입니다.</p>
</details>

### 22. 문서 분류와 보존 기간은 어느 시점에 정해야 하나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> Ingestion 전에 목적·민감도·처리 위치·삭제 책임과 함께 정해야 합니다.</p>
</details>

### 23. Viewer 화면에서 mutation command를 숨기는 것으로 권한 검사가 끝나나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아닙니다. 직접 API 요청을 보내도 서버가 authorization과 CSRF를 검사해 거부해야 합니다.</p>
</details>

### 24. Restore rehearsal에서 row count만 같으면 충분한가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 아닙니다. Integrity·foreign key·health·핵심 review 흐름까지 다시 확인해야 합니다.</p>
</details>

### 25. ai_service_review_ready가 production approval이 아닌 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 합성 문서·합성 provider·로컬 환경의 학습 Gate이며 실제 모델·실제 데이터·실사용자·보안·법무·운영 검토를 포함하지 않기 때문입니다.</p>
</details>

### 26. Orphan evidence가 0이어야 하는 이유는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 모든 evidence가 어떤 claim·control·scenario를 뒷받침하는지 설명할 수 있어야 하기 때문입니다.</p>
</details>

### 27. Unsupported finding count가 0이라는 말의 정확한 뜻은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 저장된 finding이 최소 schema·retrieval membership·exact quote 계약을 통과했다는 뜻이며 사실성 전체 보증은 아닙니다.</p>
</details>

### 28. 세 readiness version의 목적은 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 화면 데모 7/24, 연결된 RAG 16/24, 평가·사람 판정 24/24의 차이를 비교해 빠진 통제가 Gate를 왜 차단하는지 배우기 위해서입니다.</p>
</details>

### 29. 실제 모델을 다음 단계에서 붙일 때 가장 먼저 versioning할 네 가지는 무엇인가요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> Provider/model version·prompt version·schema version·evaluation dataset version입니다.</p>
</details>

### 30. 좋은 IP02 handoff package는 어떤 질문에 답해야 하나요?

<details class="answer">
<summary>정답 보기</summary>
<p><strong>정답:</strong> 무엇을 검토하고, 어떤 근거로 판정하며, 누가 결정하고, 어떻게 시험·관찰·복구하고, 무엇이 아직 production에서 미정인지 답해야 합니다.</p>
</details>

## 30. 용어집 300과 다음 프로젝트 IP03

`04_Glossary/GLOSSARY_ai_document_review_service.md`에는 15묶음·300개 unique term이 있습니다. 목적·문서·provenance·검색·grounding·injection·model contract·finding·abstain·evaluation·human review·privacy·API·operation·Gate 순서로 공부합니다.

| 묶음 | 핵심 질문 |
|---|---|
| 01~03 | 왜 만들고 어떤 원문을 읽었는가 |
| 04~06 | 어떤 근거를 찾고 문서 지시를 어떻게 격리하는가 |
| 07~09 | 출력 계약과 finding·abstain을 어떻게 나누는가 |
| 10~12 | 평가·사람 판정·데이터 보호를 어떻게 연결하는가 |
| 13~15 | 오류·운영·Gate·인계를 어떻게 재현하는가 |

다음 프로젝트 **IP03 · 데이터 분석 대시보드 서비스**에서는 IP01의 운영형 웹 서비스와 IP02의 provenance·evaluation·Gate를 재사용해, dataset 품질·metric definition·filter·visualization·insight·decision·refresh·access control을 연결합니다.

```text
IP01 · 사용자 업무·API·DB·운영
      +
IP02 · provenance·retrieval·evaluation·human decision
      ↓
IP03 · dataset → metric → visualization → insight → decision
```

> **마지막 확인:** 좋은 AI 문서 검토 서비스는 그럴듯한 문장을 많이 만드는 서비스가 아닙니다. 언제 어떤 원문과 정책을 보았는지 보여 주고, 근거가 부족하면 멈추며, 사람의 권한과 이유를 남기고, 다른 사람이 같은 evidence로 같은 한계를 확인할 수 있는 서비스입니다.

---

## 배포본 안내

- 매뉴얼 ID: `IP02`
- 콘텐츠 버전: `v0.1.0`
- [인쇄용 PDF](../IP02/IP02_build-ai-document-review-service_v0.1.0.pdf)
- 그림·실습·템플릿·용어집 링크는 이 프로젝트 폴더 구조를 기준으로 합니다.