document-consistency-report.md

문서 정합성 점검 보고서

항목	내용
점검일	2026-09-29
점검 범위	docs/ 중 conventions/를 제외한 문서 9개 (md 8개 + wireframe.pdf)
점검 방식	모든 문서를 처음부터 끝까지 읽고 항목별로 교차 대조. 와이어프레임 PDF는 16페이지 전체를 이미지로 확인. 기능 명세서 집계·REQ 매핑·문서 간 참조는 스크립트로 한 번 더 검증
반영 이력	2026-09-29 COMMON-4: 🔴 높음 · 🟠 중간 · 🟡 낮음 30건 결정 반영 (아래 "반영 결과"). 와이어프레임(PDF) 수정은 미반영 목록으로 남김

반영 결과 (COMMON-4, 2026-09-29)

🔴 높음 · 🟠 중간 · 🟡 낮음 30건에 대한 팀 결정을 문서에 반영했다. 와이어프레임(PDF)은 이번 작업에서 뺐으므로, 문서와 와이어프레임이 달라진 부분은 아래 "와이어프레임 미반영 목록"에 모았다.

반영 후 문서 버전

문서	이전 → 반영 후
requirements-specification.md	v5.4 → v5.5
기능_명세서.md	v3.1 → v3.2 (107 → 111개: MVP 48 · 확장 26 · 이후 24 · 데이터 13. 신규 REQ-108 ~ 111)
final-planning.md	v4.1 → v4.2
information-architecture.md	v1.5 → v1.6
erd.md	v1.2 → v1.3
api-specification.md	v0.2 → v0.3
sequence-diagram.md	v0.3 → v0.4
tech-stack.md	(이력 없음) → v1.1 (작성 이력 표 추가)

항목별 결정과 반영 내용

ID	결정	반영 결과	반영한 곳
C-01	제안대로 (API 명세 기준)	✅ 성공 응답은 감싸지 않고, 에러만 {code, message, currentStatus, details}	기술 스택 4 · 5장
C-02	제안대로	✅ VERDICT_OUT_OF_RANGE → OUT_OF_ALLOWED_RANGE, 에러 코드는 API 명세 1-5만 기준	기술 스택 4 · 5장
C-03	제안대로	✅ 경로를 /cases/{caseId}/experience/...로 통일, "체험 ID" 표현을 "사건 ID + 쿠키"로 정정	기술 스택 4장, 시퀀스 3 ~ 6장
C-04	경합범 서비스 제외 + 예시를 단일 범행으로 교체	✅ 동종 경합범을 포함한 경합범 전체를 서비스 대상에서 제외. 예시 사건을 "지인 투자금 편취 사건"(피해자 1명, 1회 4,500만 원)으로 교체	요구사항 FR-1-3 · 6장 보류 · 15장 · FR-6-6 예시, 기능 명세 REQ-081, 기획서 6-3-2 · 6-6-6 · 12장, IA 2장 #6, ERD 3-1 · 6장, API 1 · 4 · 5 · 6 · 8 · 9 · 10 · 12 · 14 · 15 예시
C-05	제안대로	⚠️ 부분 반영 — 문서의 권고 범위 예시를 "제1유형 기본영역, 6개월 ~ 1년 6개월(예시 값, 등록 시 재계산)"으로 정리. 와이어프레임 표기는 미반영	API 6, ERD 6장
C-06	제안대로 + RAG 우선, RAG를 적용할 수 없으면 퓨샷	✅ MVP = 오프라인 생성 결과 적재, 확장 파이프라인 = RAG(pgvector) 기본 · 불가 시 퓨샷	요구사항 3장 · FR-4-2 · 4-3 · 7장 결정 상태 · 15장, 기능 명세 REQ-043 · 044, 기획서 6-4-3 · 6-4-4, 기술 스택 6장, 시퀀스 1 · 2장
C-07	제안대로	✅ PostgreSQL 확정, 타입을 jsonb · timestamptz로, MySQL 문구 삭제	ERD 전체(3장 타입, 3-3 제약, 결정 #6, 7장)
C-08	제안대로	✅ judgment.references → reference_tags (API 응답 필드명 references는 유지)	ERD 3-3, API 10
C-09	API 6장 #1 제안대로	✅ 화면 진입 시 상태를 따로 조회하지 않고 각 API의 INVALID_STATE + currentStatus로 이동	API 1-6 · 5장 · 6장 #1, 기술 스택 5장 라우터 흐름, 시퀀스 3장 비고, IA 9장
C-10	제안대로, 없는 문서는 "노션 보관"	✅ 본문 참조를 실제 파일명으로, 조사 결과 · 논의 기록은 "노션 보관"으로 표기. 기술 스택 9장의 문서 관리 위치를 "설계 문서 = 저장소 docs/, 회의록 · 조사 자료 = 노션"으로 정리	요구사항 근거 문서 · 2 · 4 · 9 · 11 · 16장, 기획서 3-1 · 8장, IA 6 · 9장, 기술 스택 9장
C-11	제안대로	✅ REQ-024 변경 칸을 "v3.1 확장 → MVP, S-04 ④ 용어 설명"으로 정정	기능 명세 REQ-024
C-12	MVP에서 무죄 제외, ERD 예시의 무죄 행 삭제	✅ NOT_GUILTY 선택지 · 예시 행 · CHECK 조건 삭제, 도입 여부는 추후 검토. 와이어프레임은 미반영	요구사항 FR-3-1 · 6장 보류 · 15장, 기능 명세 REQ-029, 기획서 6-3-2, IA S-06, ERD 3-1 · 3-3 · 6장, API 8 · 9 · 14 · 6장 #5, 시퀀스 6장
C-13	와이어프레임 S-02 정렬 · 더 보기에 점선 표시	⏸ 미반영 — 와이어프레임 작업을 이번 범위에서 뺌	(와이어프레임 미반영 목록)
C-14	방안 1 (ERD · API에 데이터 추가)	✅ 아래 표 참고	요구사항 FR-1-5 · FR-6-4 · DR-10, 기능 명세 REQ-006 · 062 · 109(신규), 기획서 6-6-5, IA S-02 · S-03 · S-09, ERD 3-1 · 3-3, API 1 · 4 · 판결 공통 형식 · 12 · 14 · 15, 시퀀스 7 · 8장, 기술 스택 6장
C-15	확장 기능, 화면 · 문구는 미정	✅ 기능 명세 REQ-108(확장) 신설, 표시 화면 · 문구는 요구사항 15장 미정으로 유지	요구사항 10장 보류 · 15장, 기능 명세 REQ-108, IA 7 · 8장, API 1-2, 기술 스택 3장

C-14 세부 — 와이어프레임 요소별 데이터 근거

와이어프레임 요소	반영
S-01 · S-02 사건 이미지	ERD legal_case.thumbnail_url 추가, API 1 thumbnailUrl. 없으면 범죄 유형별 기본 이미지
S-03 · S-05 범죄 분류명 ("사기 / 재산범죄")	컬럼 대신 crime_type별 코드 상수, API 1 · 4 crimeCategoryLabel
S-09 판결 카드 한 줄 요약	기능 명세 REQ-109(MVP) 신설. AI · 재판부는 ERD judgment.summary(팀 입력). 내 판결은 MVP에서 판단 요소마다 붙인 요약어(factor.summary_tag, BE-26 확정)를 방향별로 모은 규칙 문장(예: "흉기 사용을 무겁게 보고 범행 인정 · 반성을 감안한 판단"), 확장 단계에서 AI가 사용자 입력으로 실시간 요약(API 15 perspectives.USER, REQ-062)을 만들어 교체
(확장) S-08 비식별화 정보 태그	ERD legal_case.deidentified_items, API 12 deidentifiedItems (항목 종류만, 원래 값은 넣지 않음)
(확장) S-08 출처 기관 예시	API 12 예시를 와이어프레임과 같은 "법원 판결서 인터넷열람 서비스"로 통일

와이어프레임 미반영 목록

와이어프레임 v2.1을 고칠 때 아래 항목을 반영해야 문서와 맞는다.

페이지	화면	고칠 내용	관련
p.3 ~ 16	전체	(COMMON-11 갱신) 예시 사건을 가상 살인 사건 "빌린 돈 문제로 찾아온 지인을 살해한 사건"으로 교체. 값은 ERD 6장(v1.5) · API 예시(v0.5) 기준(판단 요소 11개, 내 판결 15년 / AI 12년 / 재판부 10년 · 몰수, 권고 범위 7 ~ 12년). 이전 지시(사기 예시 교체)는 대체됨. 종전 내용: 값은 ERD 6장 · API 예시 기준(피해 4,500만 원 · 회복 1,500만 원, 판단 요소 7개, 내 판결 1년 6개월 · 집유 3년 / AI 1년 · 집유 2년 / 재판부 10개월 · 집유 2년 · 사회봉사 80시간)	C-04
p.7 · 8 · 9 ~ 12	S-04c · S-05 · S-06	산출 근거 "일반사기 제2유형, 가중영역" → "제1유형(1억 원 미만), 기본영역", 권고 범위 "징역 1년 ~ 3년 6개월" → 새 예시 값 "6개월 ~ 1년 6개월" COMMON-11에서 대체됨 — 위 p.3 ~ 16 항목대로 살인 기준(제2유형 감경영역, 권고 범위 7년 ~ 12년)으로 바꾼다	C-05
p.9 ~ 12 · 16	S-06a ~ d, 모바일 S-06a	형벌 종류의 무죄 버튼 삭제. (징역 · 벌금만) COMMON-11에서 대체됨 — 살인 예시라 형벌은 사형 · 무기징역 · 징역 3종이고 벌금은 없다(아래 BE-13 항목 참고)	C-12
p.9 ~ 12 · 16	S-06a ~ d, 모바일 S-06a	사형 · 무기가 법정형에 있는 사건에서 형벌 종류 4종과 감경 선택(reducedTo: 사형 → 무기 · 징역, 무기 → 징역) 시안 추가, 살인 사전 판단(S-03) 구간에서 벌금형 삭제 (FR-3-2, FR-2-8)	BE-13
p.3	S-02	정렬 : 최신순 드롭다운과 사건 더 보기 버튼에 점선(확장/이후) 표시	C-13
p.15	S-09	판결 카드 한 줄 요약은 유지. 내 판결 요약 문구를 요약 태그 규칙 문장 형식으로 바꾸면 더 정확함 (선택)	C-14
—	(미정)	쿠키 삭제 시 안내(REQ-108, 확장)는 표시 화면 · 문구가 정해지면 추가	C-15
p.15	S-09	"처음 판단 → 직접 판결" 아래 (확장) 카드에 "이미 알던 요소의 무게가 바뀜" 카드 추가 (현재 "새로 알게 된 요소" · "처음부터 알던 요소" 2개)	C-16
p.7 · 8 · 15	S-04c · S-05 · S-09	권고 범위 막대 오른쪽 끝 라벨 "법정형 상한 10년" → "선고할 수 있는 상한 10년"	C-27

🟡 낮음 항목 결정과 반영 내용

ID	결정	반영 결과	반영한 곳
C-16	제안대로 + 와이어프레임에도 추가	✅ "변화 2유형 + 변화 없음 1유형(총 3가지)"로 표현 통일, IA S-09에 "무게가 바뀜" 추가. 와이어프레임은 미반영 목록에 추가	요구사항 FR-6-6, 기획서 6-3-3 · 6-6-6, IA S-09
C-17	제안대로	✅ "요구사항 8장" → "요구사항 11장 톤 원칙 · FR-6-3"	API 14, 시퀀스 8장
C-18	API의 대응 표 삭제	✅ "시퀀스 9장 후보와의 대응" 표 삭제	API 2장
C-19	제안대로	✅ Jira 공통 COMMON 추가, 디렉터리명 frontend/ (컨벤션 경로는 COMMON-3에서 수정)	기술 스택 5 · 9장
C-20	제안대로 + Could Have 두 항목에 REQ	✅ MoSCoW(가치) · 구현 단계(일정) 관계 명시, Must Have에 MVP 단서 추가, 회원가입/로그인 · 통계 · 공유는 이후 단계로 확정. REQ-110 같은 사건 재체험 · REQ-111 범위 자동 계산 (이후) 신설	요구사항 12 · 15장, 기능 명세, 기획서 10장
C-21	제안대로	✅ "내 Law 남불" → "내Law남불"	기획서 전체
C-22	제안대로	✅ 미결정 사항을 요구사항 15장으로 일원화. 기획서 12장에만 있던 항목(데이터 구조, 권고 범위 계산 로직, RAG 데이터 구축, 비교 분석 시간 초과, 화면 UI)을 요구사항 15장으로 이관. 기획서 9-1에 판례 조사 결과 추가	요구사항 15장, 기획서 9-1 · 12장
C-23	변경 내용 이동 + MVP 묶음 표 언급 삭제	✅ REQ-017 · 023 · 037 · 063 · 077의 변경 내용을 변경 칸으로 이동, 작성 이력의 "MVP 묶음 표" 삭제	기능 명세
C-24	제안대로	✅ REQ-019 변경 칸 "서버에서 순서 강제, 잠긴 섹션 본문 미응답"	기능 명세
C-25	제안대로	✅ 복원 범위 "확인한 섹션과 다음에 확인할 섹션까지"	요구사항 FR-2-11
C-26	제안대로	✅ "형량 구간 7개 MVP 확정, 범죄 유형별 세부 조정은 추후"	기획서 6-2-4
C-27	라벨 "선고할 수 있는 상한"	✅ 요구사항에 라벨 확정. 와이어프레임은 미반영 목록에 추가	요구사항 FR-3-2
C-28	같은 도메인, API 6장 #2와 맞춤	✅ EC2 Nginx가 프론트 빌드 파일 서빙 + /api 백엔드 프록시. SameSite=Lax 유지, CORS 불필요	기술 스택 8장, API 1-2 · 6장 #2
C-29	제안대로 (시퀀스 8장 기준)	✅ 입력 = 세 판결의 형벌 · 형량 · 요소 ID · 문구 · 방향, 사전 판단 구간, 요소 공개 단계 (원문 · 판결문 전문 제외)	요구사항 FR-6-3, 기획서 6-6-4
C-30	최신 버전으로, 기술 스택에 작성 이력	✅ IA S-14 "MVP", "익명 세션" → "익명 ID"(IA · 기능 명세 · 요구사항 DR-5), 요구사항 근거 문서에 각 문서 최신 버전 표기, 기술 스택 작성 이력(v1 · v1.1) 서술	IA, 기능 명세, 요구사항, 기술 스택

• 아래 본문(1 ~ 6장)은 점검 당시 기준으로 남겨 두었다. 줄 번호와 예시 값은 반영 전 문서 기준이다.

0. 점검 대상 문서와 현재 버전

파일	문서	현재 버전	비고
final-planning.md	기획서 최종본	v4.1
requirements-specification.md	요구사항 명세서	v5.4
기능_명세서.md	기능 명세서	v3.1	107개 항목
information-architecture.md	정보 구조도 (IA)	v1.5
erd.md	ERD	v1.2
sequence-diagram.md	시퀀스 다이어그램	v0.3
api-specification.md	API 명세서	v0.2
tech-stack.md	기술 스택 정리	(작성 이력 없음)	다른 문서와 달리 버전 표가 없음
wireframe.pdf	와이어프레임	v2.1	이미지 PDF(텍스트 없음) 16p

심각도 기준

표시	의미
🔴 높음	그대로 구현하면 프론트·백엔드 계약이 어긋나거나 핵심 규칙·예시 데이터가 틀어지는 문제
🟠 중간	문서마다 결정이 다르게 적혀 있어 구현 전에 팀 판단이 필요한 문제
🟡 낮음	표기·참조·문구 차이. 오해 소지는 있으나 구현에 직접 영향은 작음

---

1. 요약

총 30건 (🔴 4 · 🟠 11 · 🟡 15)

ID	심각도	주제	어긋나는 문서
C-01	🔴	API 응답 형식 (감싸는 객체 유무)	기술 스택 ↔ API 명세
C-02	🔴	선고 가능 범위 밖 에러 코드 이름	기술 스택 ↔ API 명세
C-03	🔴	API 경로 체계 (체험 ID vs 사건 ID + 쿠키)	기술 스택 · 시퀀스 ↔ API 명세
C-04	🔴	예시 사건(37회 반복 사기)의 경합범 가중과 선고 가능 상한	요구사항 ↔ ERD · API · IA · 와이어프레임
C-05	🟠	사기 양형기준 유형 표기(제1유형/제2유형)와 권고 범위 근거	API 명세 ↔ 와이어프레임 · ERD
C-06	🟠	AI 판결 생성 방식 (RAG / 퓨샷 / 오프라인 적재)	기획서 ↔ 요구사항 · 기술 스택
C-07	🟠	ERD가 DB 확정(PostgreSQL)을 반영하지 않음	ERD ↔ 기술 스택
C-08	🟠	judgment.references 컬럼명이 SQL 예약어	ERD · API 명세 ↔ 기술 스택(PostgreSQL)
C-09	🟠	화면 진입 시 상태 확인 방식이 미정인데 기술 스택은 한쪽으로 확정	기술 스택 ↔ API 명세 · IA
C-10	🟠	문서 간 파일 참조가 실제 파일명과 다름 / 없는 문서 참조	요구사항 · 기획서 · IA · 기술 스택
C-11	🟠	REQ-024 변경 칸이 v3.1 결정(MVP)과 반대로 읽힘	기능 명세서 ↔ 요구사항 · IA
C-12	🟠	"무죄" 처리 규칙이 미정인데 MVP 화면·API에 선택지로 들어가 있음	요구사항 ↔ 와이어프레임 · API · ERD
C-13	🟠	S-02 정렬 드롭다운 · "사건 더 보기"가 MVP 화면에 그려져 있음	와이어프레임 ↔ IA · 요구사항 · API
C-14	🟠	와이어프레임 요소 중 데이터(ERD·API)가 없는 항목	와이어프레임 ↔ ERD · API · IA
C-15	🟠	익명 ID 쿠키 삭제 시 안내 여부 (미정 vs 확정)	기술 스택 ↔ 요구사항 · IA
C-16	🟡	판단 이유 변화 "두 유형"이라 쓰고 표는 3유형 / 와이어프레임은 2개만	기획서 · 요구사항 ↔ 기능 명세 · API · IA · 와이어프레임
C-17	🟡	"요구사항 8장 톤 규칙" 참조가 잘못된 장	API 명세 · 시퀀스 ↔ 요구사항
C-18	🟡	API 명세의 "시퀀스 9장 후보"가 시퀀스 문서에 없음	API 명세 ↔ 시퀀스
C-19	🟡	기술 스택의 Jira 키 · 컨벤션 경로 · 디렉터리명이 현재와 다름	기술 스택 ↔ 저장소 · CLAUDE.md
C-20	🟡	MoSCoW 우선순위와 기능 명세 구현 단계가 1:1로 맞지 않음	요구사항 · 기획서 ↔ 기능 명세서
C-21	🟡	서비스명 띄어쓰기 표기	기획서 ↔ 나머지 전부
C-22	🟡	미결정 사항 목록이 문서마다 다름	기획서 12장 ↔ 요구사항 15장
C-23	🟡	기능 명세서 표 형식 (변경 내용이 설명 칸에 섞임, 없는 표 언급)	기능 명세서 내부
C-24	🟡	REQ-019 변경 칸 "순서대로 이동만"이 서버 강제 결정과 어긋남	기능 명세서 ↔ 요구사항 · IA · API
C-25	🟡	새로고침 시 S-04 복원 범위 표현 차이	요구사항 ↔ IA · API
C-26	🟡	사전 판단 형량 구간 7개: "확정" vs "예시"	요구사항 · 기능 명세 ↔ 기획서
C-27	🟡	권고 범위 막대의 상한 기준(선고 가능 상한 vs 법정형 상한)	요구사항 ↔ 와이어프레임
C-28	🟡	프론트엔드 배포 구조 누락 (쿠키 SameSite 결정과 연결)	기술 스택 ↔ API 명세
C-29	🟡	AI 비교 분석 입력 항목 표현 차이	요구사항 · 기획서 · 시퀀스
C-30	🟡	기타 표기 (IA S-14 단계 "M", "익명 세션"/"익명 ID" 용어 혼용, 요구사항의 기획서 버전 참조)	IA · 기능 명세 · 요구사항

---

2. 🔴 높음

C-01. API 응답 형식 — 성공 응답을 data로 감싸는가

문서	위치	내용
기술 스택	tech-stack.md:144, :166, :219, :228	"API 응답은 공통 형식(code, message, data)을 사용한다", 프론트 공통 함수는 "성공 → data 반환"
API 명세	api-specification.md:49	"성공 응답은 결과 객체를 그대로 돌려준다(감싸는 객체 없음)". 에러는 { code, message, currentStatus, details }

• 문제: 프론트는 response.data를 꺼내도록, 백엔드는 결과 객체를 그대로 내려주도록 구현하게 된다. 에러 형식도 기술 스택에는 currentStatus·details가 없어서, 화면 이동(currentStatus로 보낼 화면 결정, API 1-6)이 빠진다.
• 제안: API 명세(v0.2)가 더 최신이고 상세하므로 API 명세 기준으로 기술 스택 4장·5장을 고친다. 반대로 감싸는 형식을 쓰기로 하면 API 명세 1-4와 모든 응답 예시를 고쳐야 한다. 어느 쪽이든 한 문서에만 정의하고 다른 문서는 참조만 하게 한다.

C-02. 선고 가능 범위 밖 에러 코드 이름

문서	위치	코드
기술 스택	tech-stack.md:170, :229	VERDICT_OUT_OF_RANGE
API 명세	api-specification.md:77, :380	OUT_OF_ALLOWED_RANGE (HTTP 422)

• 문제: 프론트는 기술 스택 예시대로 VERDICT_OUT_OF_RANGE에 경고 박스를 연결하게 되는데, 서버는 OUT_OF_ALLOWED_RANGE를 보낸다. S-06c 방어 로직이 동작하지 않는다.
• 제안: 기술 스택의 예시 코드를 OUT_OF_ALLOWED_RANGE로 바꾸고, 에러 코드 목록은 API 명세 1-5만 기준으로 삼는다고 명시한다.

C-03. API 경로 체계 — 체험 ID를 경로에 넣는가

문서	위치	내용
API 명세	api-specification.md:36-45, :99-115	/api/v1/cases/{caseId}/experience/.... 체험 ID를 화면이 들고 다니지 않고 사건 ID + 익명 ID 쿠키로 체험을 찾는다. API 2 응답에도 체험 ID가 없다
기술 스택	tech-stack.md:149-159	/api/v1/experiences/{id}/... (체험 ID 기반). 경로 이름도 reviews(↔ review-steps), complete(↔ comparison-reveal)로 다름
시퀀스	sequence-diagram.md:80, :112, :139, :143, :180, :195	"체험 ID + 현재 상태"를 응답으로 받고, 이후 요청마다 "체험 ID"를 보냄

• 문제: 기술 스택에는 "예시이며, 최종 경로는 API 명세서에서 확정한다"는 단서가 있지만, 시퀀스 v0.3은 "API 명세서 v0.2와 맞춤"이라고 해 놓고도 체험 ID를 주고받는 흐름을 그대로 두었다. 문서를 보는 사람에 따라 체험 ID 기반으로 구현할 수 있다.
• 제안: 시퀀스 3 ~ 6장의 "체험 ID"를 "사건 ID(+ 쿠키)"로 바꾸고, 기술 스택의 경로 예시는 지우거나 API 명세 경로로 맞춘다.

C-04. 예시 사건의 경합범 가중과 선고 가능 상한 (120개월)

문서	위치	내용
요구사항	requirements-specification.md:511 (15장 미정)	"같은 죄명을 여러 번 저지른 사건(동종 경합범, 예: 피해자 여러 명 반복 사기)… 경합범 가중(형법 제38조)을 적용하면 예시 사건의 상한이 10년 → 15년이 될 수 있음"
기획서	final-planning.md:857	같은 내용을 추후 결정 사항으로 둠
ERD	erd.md:457-463	예시 penalty_rule에서 PRISON allowed_max = 120으로 확정 서술, "S-06c(12년 = 144개월)는 120을 넘으므로 확정 불가"
API 명세	api-specification.md:270, :329	allowedMax: 120, "징역 1개월 ~ 10년"
IA / 와이어프레임	IA :239, 와이어프레임 p.11 (S-06c)	12년 입력 → "선고할 수 있는 범위를 벗어났습니다" 확정 불가 예시
기능 명세 / 요구사항	기능_명세서.md:173 (REQ-081), requirements-specification.md:281	경합범은 "여러 죄명이 결합된" 사건만 MVP 제외

• 문제: 대표 예시 사건(10개월간 37회, 피해자 37명)이 바로 요구사항이 미정으로 둔 "동종 경합범"에 해당한다. 경합범 가중을 적용하면 상한이 15년(180개월)이 되어, ERD 예시 데이터·API 예시·와이어프레임 S-06c의 "12년은 확정 불가" 시나리오가 법적으로 틀린 예시가 된다. 또 REQ-081의 제외 대상은 "여러 죄명" 결합뿐이라, 이 사건이 MVP 대상인지도 문서만으로 판단할 수 없다.
• 제안: 대표 판례를 고르기 전에 ① 동종 경합범을 MVP에 넣을지 ② 넣는다면 allowed_max 산정에 경합범 가중을 포함할지 먼저 정한다. 정해진 뒤 ERD 6장 예시, API 6·8 예시, 와이어프레임 S-06c 예시 값을 함께 고친다. REQ-081 문구도 "이종 경합범"인지 "경합범 전체"인지 분명히 한다.

---

3. 🟠 중간

C-05. 사기 양형기준 유형 표기와 권고 범위 근거

문서	위치	표기
API 명세	api-specification.md:6 (v0.2 이력), :270	"사기 양형기준 유형 표기 정정(제1유형)" → 일반사기 제1유형(1억 원 미만), 가중영역
와이어프레임	p.7 (S-04c), p.8 (S-05), p.9 ~ 12 (S-06 사이드바)	일반사기 **제2유형**(1억 원 미만), 가중영역
API 명세	api-specification.md:273	"사기 제1유형 가중영역은 1년 ~ 2년 6개월이라 42개월의 근거는 확인되지 않았다"
ERD · 와이어프레임 · IA	ERD 6장, 와이어프레임 p.7 ~ 12	권고 범위 "징역 1년 ~ 3년 6개월"(12 ~ 42개월)을 전제로 예시 구성

• 문제: API 명세만 정정됐고 와이어프레임은 이전 표기 그대로다. 권고 범위 12 ~ 42개월 자체도 근거가 확인되지 않았다고 API 명세가 적어 두었는데, 다른 문서에는 이 주의 문구가 없다.
• 제안: 와이어프레임의 "제2유형" 표기를 "제1유형"으로 고친다. 권고 범위 예시 값에는 "예시 값, 대표 판례 등록 시 재계산"이라는 주의를 ERD 6장에도 같이 적는다. C-04와 함께 정리하는 것이 좋다.

C-06. AI 판결 생성 방식 (RAG / 퓨샷 / 오프라인 적재)

문서	위치	서술
요구사항	requirements-specification.md:306	MVP는 오프라인에서 생성·검수한 결과를 적재. 서비스 안 파이프라인은 확장 단계이며 퓨샷 우선, 필요할 때 RAG로 전환
기술 스택	tech-stack.md:256-259, :300	"MVP에서는 퓨샷 방식으로 먼저 전체 흐름을 검증하고, RAG는 이후 단계"
기획서	final-planning.md:437, :445, :458	"유사 판례 및 양형기준 등 필요한 자료는 RAG를 활용하여 검색", 제목 "에이전틱 RAG 구조", Agent 2 활용 자료는 "판례 Vector Store"만 있음
기능 명세	REQ-040 ~ 045	파이프라인은 확장 단계

• 문제: 기획서는 RAG를 기본 방식처럼 서술하고 퓨샷 우선 결정이 빠져 있다. 기술 스택은 "MVP = 퓨샷"처럼 읽혀 "MVP = 오프라인 적재"와 맞지 않고, 단계 표현도 기능 명세서의 정의("이후" = 6주 이후)와 다르게 "(이후)"를 쓴다.
• 제안: 요구사항 FR-4-2를 기준으로 삼는다. 기획서 6-4-3과 Agent 2 활용 자료에 "퓨샷 우선, 필요 시 RAG"를 반영하고, 기술 스택 6장은 "MVP: 오프라인 생성 결과 적재 / 확장: 퓨샷 파이프라인 / 필요 시: RAG(pgvector)"처럼 기능 명세서의 단계 용어로 고쳐 쓴다.

C-07. ERD가 DB 확정(PostgreSQL)을 반영하지 않음

문서	위치	내용
기술 스택	tech-stack.md:62, :67, :69-76	PostgreSQL 확정, JSON은 jsonb, 부분 유니크 인덱스 SQL까지 제시
ERD	erd.md:347	"PostgreSQL은 부분 유니크 인덱스, MySQL은 생성 컬럼 또는 서비스 로직으로 구현"
ERD	erd.md:414	결정 #6 "DB 제품은 기술 스택 확정 때 최종 확인"
ERD	erd.md:508	"(PostgreSQL, MySQL 8.0.16 이상에서 동작)"
ERD	컬럼 타입 전반	json, datetime (PostgreSQL에서는 jsonb, timestamp/timestamptz)

• 문제: 기술 스택에서 PostgreSQL로 정했는데 ERD는 아직 두 DB를 모두 고려한 상태다. Flyway로 DDL을 직접 쓸 때 ERD 타입을 그대로 옮기면 PostgreSQL에서 datetime이 오류가 나고, json/jsonb 선택도 갈린다.
• 제안: ERD 결정 #6을 "PostgreSQL 확정"으로 바꾸고, MySQL 관련 문구를 지우고, 타입 표기를 jsonb, timestamptz 등으로 맞춘다.

C-08. judgment.references 컬럼명이 SQL 예약어

문서	위치	내용
ERD	erd.md:334, :414	judgment.references (json) 컬럼 추가 (v1.2)
API 명세	api-specification.md:419	"judgment.references(ERD v1.2)에서 읽는다"
ERD	erd.md:137	"case는 SQL 예약어라 legal_case로 둔다" — 같은 원칙이 이미 있음

• 문제: REFERENCES는 PostgreSQL(기술 스택 확정 DB)과 SQL 표준의 예약어라, 따옴표 없이 DDL·JPQL/네이티브 쿼리를 쓰면 오류가 난다. ERD가 case에 적용한 원칙과도 맞지 않는다.
• 제안: reference_tags 같은 이름으로 바꾸고 API 명세의 참조도 함께 고친다. API 응답 필드명 references는 그대로 둬도 된다.

C-09. 화면 진입 시 상태 확인 방식 — 미정인데 기술 스택은 한쪽으로 확정

문서	위치	내용
API 명세	api-specification.md:561, :569 (6장 #1)	결정 필요. 제안은 "각 API의 INVALID_STATE로 처리"(요청 수 절약)
IA	information-architecture.md:348	"진입 시 상태를 먼저 조회할지, 각 API의 INVALID_STATE로 처리할지는 API 명세 6장 #1에서 정한다"
시퀀스	sequence-diagram.md:96	"화면은 진입할 때 체험 상태를 조회하고…"
기술 스택	tech-stack.md:201-217	라우터가 매번 "체험 상태 조회"를 먼저 하는 흐름으로 확정 서술

• 문제: API 명세의 제안과 반대 방식을 기술 스택과 시퀀스가 전제하고 있다. 프론트 라우터 구조를 정하는 결정이라 먼저 정해야 한다.
• 제안: API 6장 #1을 확정하고, 그 결과에 맞게 기술 스택 5장 라우터 흐름과 시퀀스 3장 비고를 고친다.

C-10. 문서 간 파일 참조가 실제 파일명과 다름 / 없는 문서를 참조

참조하는 곳	참조	실제
requirements-specification.md:544	08_ERD.md(v1.2)	erd.md
information-architecture.md:275	09_시퀀스다이어그램.md 8장	sequence-diagram.md
final-planning.md:716	07_와이어프레임.md	wireframe.pdf (md 파일 없음)
requirements-specification.md:114, :368, :436	정보구조도, 시퀀스다이어그램, 와이어프레임 (문서명)	information-architecture.md 등 영문 파일명
requirements-specification.md:57, :161	판례_후보_조사결과.md	저장소에 없음
requirements-specification.md:57, final-planning.md:80	논의기록/2026-09-28_경쟁서비스_분석.md, 논의기록/2026-09-28_차별화_결정사항.md	저장소에 없음
tech-stack.md:383	"Notion에서 기획서·요구사항·ERD 등 문서 관리"	현재 문서는 저장소 docs/에 있음

• 문제: 노션에서 옮겨 오면서 파일명이 바뀌었는데 본문 참조는 그대로다. 특히 요구사항은 판례 조사 결과(데이터 확보 경로 미정의 근거)를 근거로 드는데, 그 문서를 저장소에서 확인할 수 없다.
• 제안: 본문 참조를 실제 파일명(상대 경로 링크)으로 바꾼다. 없는 문서는 docs/에 추가하거나 "노션 보관"이라고 위치를 적는다. 문서 관리 위치(노션 vs 저장소)도 기술 스택 9장에서 정리한다.

C-11. REQ-024 변경 칸이 v3.1 결정(MVP)과 반대로 읽힘

문서	위치	내용
기능 명세서	기능_명세서.md:73	REQ-024 구현 단계 MVP, 변경 칸 "MVP는 REQ-035 산출 근거로 대체"
기능 명세서 이력	기능_명세서.md:10	v3.1 "REQ-024 · 026을 확장 → MVP로 이동"
요구사항	requirements-specification.md:189, :527	"MVP는 권고 범위 산출 근거와 사건별 주요 용어 설명을 S-04 ④에 표시(REQ-024 · 035)" / "S-04 ④ 용어 설명(REQ-024) 🟢 MVP"
IA · 와이어프레임	IA :121, :216, 와이어프레임 p.7	S-04 ④에 용어 설명(가중영역, 처벌불원) 표시

• 문제: 변경 칸은 확장 단계이던 시절의 메모로 보인다. "산출 근거로 대체"라고 적혀 있어 용어 설명을 구현하지 않아도 된다고 읽힐 수 있다.
• 제안: 변경 칸을 "v3.1 확장 → MVP. S-04 ④ 용어 설명(case_section LAW_TERM)"으로 고친다.

C-12. "무죄" 처리 규칙이 미정인데 MVP 화면·API에 선택지로 들어가 있음

문서	위치	내용
요구사항	requirements-specification.md:285, :503	"무죄" 선택 시 형량·집행유예 입력 처리 규칙 미정
와이어프레임	p.9 ~ 12 (S-06a ~ d), p.16 모바일	형벌 종류에 징역 / 벌금 / 무죄가 점선 없는 MVP 요소로 그려짐
API 명세	api-specification.md:329, :363, :487	NOT_GUILTY 선택지 포함, "정해질 때까지 무죄 penalty_rule이 있는 사건에서만 허용" 임시 규칙, S-09 방향 비교에서 무죄를 가장 가벼운 값으로 취급
ERD	erd.md:199, :461	penalty_type에 NOT_GUILTY, 예시 사건에도 무죄 행 있음
요구사항 FR-2-8 / API 4	사전 판단 형량 구간	7개 구간에 "무죄"는 없음

• 문제: 규칙은 미정인데 MVP 화면·API·예시 데이터에는 이미 들어가 있다. 무죄를 고르면 S-06 판단 요소 방향 입력을 받는지, S-09 "처음 판단 → 직접 판결" 문구를 어떻게 쓸지 정해진 문서가 없다.
• 제안: MVP에서 무죄를 뺄지 넣을지 먼저 정한다. 넣는다면 판단 요소 입력 여부와 S-09 표시 규칙까지 요구사항에 적고, 빼면 와이어프레임과 ERD 예시에서 무죄 행을 없앤다.

C-13. S-02 정렬 드롭다운 · "사건 더 보기"가 MVP 화면에 그려져 있음

문서	위치	내용
와이어프레임	p.3 (S-02 데스크톱)	정렬 : 최신순 ▾ 드롭다운과 하단 사건 더 보기 버튼이 점선(확장) 표시 없이 그려짐. 모바일(p.16)에는 둘 다 없음
IA	information-architecture.md:193	"범죄 유형 칩, (정렬은 이후 단계)"
요구사항 · 기능 명세	requirements-specification.md:157, REQ-009(기능_명세서.md:53)	정렬은 이후 단계
API 명세	api-specification.md:156	"정렬: published_at 최신순 고정". 페이지네이션 파라미터 없음

• 문제: 와이어프레임에서 점선 없는 요소는 MVP로 본다는 원칙(요구사항 :436) 때문에, 정렬과 "더 보기"를 MVP로 구현할 수 있다. "더 보기"(페이지네이션)는 어느 문서에도 정의가 없다.
• 제안: 와이어프레임 S-02의 정렬·더 보기에 점선(확장/이후) 표시를 하거나 지운다. 페이지네이션이 필요하면 API 1에 파라미터를 추가하고 REQ를 만든다.

C-14. 와이어프레임 요소 중 데이터(ERD·API)가 없는 항목

와이어프레임	요소	대응 데이터
p.2 S-01, p.3 S-02	랜딩 이미지 영역, 카드별 "사건 유형 이미지"	ERD legal_case에 이미지 컬럼 없음, API 1 응답에 없음
p.4 S-03, p.8 S-05	"사기 / 재산범죄" (죄명 / 범죄 분류)	ERD crime_type은 MURDER/FRAUD/INJURY(살인/사기/상해)뿐이라 "재산범죄" 같은 상위 분류명의 출처가 없음
p.15 S-09	3열 판결 카드마다 한 줄 요약 ("반복성과 전력을 무겁게 본 판단" 등)	API 14 judgments에 해당 필드 없음. IA :126은 "062(판단 포인트 요약)는 와이어프레임에 없음"이라고 적었지만 실제로는 카드에 비슷한 문구가 있음
p.14 S-08 (확장)	"비식별화 정보" 태그 (인명 · 지명 · 사건번호 · 거래 플랫폼명)	ERD·API에 해당 필드 없음 (FR-5-2 확장 항목)
p.14 S-08 (확장)	출처 기관 "법원 판결서 인터넷열람 서비스"	API 12 예시는 "대법원 종합법률정보" (api-specification.md:447)

• 제안: MVP 요소(이미지, 분류명, S-09 카드 요약)는 ① ERD 컬럼·API 필드를 추가하거나 ② 와이어프레임에서 빼거나 점선으로 바꾼다. S-09 카드 문구는 REQ-062(확장)에 해당하는지 판단해 IA 비고를 고친다. 출처 기관 예시는 한쪽으로 맞춘다.

C-15. 익명 ID 쿠키 삭제 시 안내 여부 — 미정 vs 확정

문서	위치	내용
요구사항	requirements-specification.md:413, :506	익명 ID 유지 방식·기간과 사용자 고지(쿠키 삭제 시 한계 안내 여부) 미정
IA	information-architecture.md:300	남은 결정 #7: "…진행 상태가 사라지는 한계를 안내할지"
API 명세	api-specification.md:32, :570	쿠키 NLNB_AID, 1년 제안, "요구사항 15장 결정 시 확정"
기술 스택	tech-stack.md:131	"쿠키를 지우면 진행 기록을 이어갈 수 없다는 점은 서비스에서 안내한다" (확정 서술)

• 제안: 결정을 확정하고, 그 결과를 요구사항 15장 → IA 8장 → API 1-2 → 기술 스택 3장 순으로 반영한다. 안내한다면 어느 화면에 어떤 문구로 둘지도 와이어프레임·IA에 추가해야 한다(현재 와이어프레임에는 없음).

---

4. 🟡 낮음

C-16. 판단 이유 변화 "두 유형"이라 쓰고 표는 3유형 / 와이어프레임은 2개만

• 기획서 final-planning.md:345, :649("판단 이유 변화의 두 유형"), 요구사항 requirements-specification.md:374("변화를 두 유형으로 구분하고") — 그런데 바로 아래 표는 3행(새로 알게 된 요소 / 처음부터 알던 요소 / 무게가 바뀜)이다.
• 기능 명세 REQ-096(:139)과 API changeType(NEWLY_LEARNED / KEPT / WEIGHT_CHANGED, api-specification.md:498)은 3유형이다.
• IA S-09(information-architecture.md:270)와 와이어프레임 p.15에는 "새로 알게 된 요소 / 처음부터 알던 요소" 2개 카드만 있다. 기획서가 "서비스명이 던지는 질문에 가장 가까운 지점"이라고 강조한 "무게가 바뀜" 카드가 화면에 없다.
• 제안: 문구를 "변화 2유형 + 변화 없음 1유형(총 3가지)"으로 통일하고, 와이어프레임·IA S-09에 "무게가 바뀜" 카드를 추가할지 정한다.

C-17. "요구사항 8장 톤 규칙" 참조가 잘못된 장

• API 명세 api-specification.md:496 "(요구사항 8장)", 시퀀스 sequence-diagram.md:316 "(요구사항 8장 톤 규칙)".
• 요구사항 8장은 "실제 판결 공개"다. 톤 규칙은 11장 UI/UX 공통 원칙(requirements-specification.md:433)이고, 금지 표현 목록은 FR-6-3(9장, :369)에 있다.
• 제안: "요구사항 11장 · FR-6-3"으로 고친다. (8장은 기획서의 UI/UX 장 번호라 섞인 것으로 보인다.)

C-18. API 명세의 "시퀀스 9장 후보"가 시퀀스 문서에 없음

• api-specification.md:119-132에 "시퀀스 9장 후보와의 대응" 표가 있지만, 현재 sequence-diagram.md는 8장까지만 있고 "API 후보 목록" 장이 없다(v0.1 · v0.2 이력에만 언급됨).
• 제안: 시퀀스에서 후보 목록을 지웠다면 API의 대응 표도 지우고, 남겨야 한다면 시퀀스에 9장을 되살린다.

C-19. 기술 스택의 Jira 키 · 컨벤션 경로 · 디렉터리명이 현재와 다름

위치	기술 스택 서술	현재
tech-stack.md:381	Jira "(Backend BE, Frontend FE)"	CLAUDE.md에 공통 COMMON Space 추가됨
tech-stack.md:411	docs/GIT_CONVENTIONS.md, docs/CODE_CONVENTIONS.md	현재 브랜치에서 docs/conventions/로 이동 중 (staged)
tech-stack.md:192	Frontend/src	저장소 디렉터리는 frontend/ (백엔드도 backend/로 변경됨)

• 제안: 세 곳을 현재 기준으로 고친다. 컨벤션 경로는 이번 이동이 머지되면 바로 깨지므로 같은 PR에서 함께 고치는 것이 좋다.

C-20. MoSCoW 우선순위와 기능 명세 구현 단계가 1:1로 맞지 않음

• 요구사항 12장(:448) · 기획서 10장(:779-787)의 Should Have에 있는 "회원가입/로그인, 판결 기록 저장·조회, 과정 기록, AI Q&A, 판단 요소 단위 참여자 통계"가 기능 명세서에서는 모두 이후(6주 이후, "프로젝트 기간 안에 하지 않아도 되는 것") 단계다(REQ-066 ~ 070, 028, 100).
• Could Have의 "같은 사건 재체험", "선고 가능 범위 · 권고 범위 자동 계산"은 대응하는 REQ가 없다.
• 요구사항 15장(:493)은 "회원가입/로그인 도입 시점"을 미정으로 두었지만, 기능 명세서·IA는 이미 "이후"로 정해 두었다.
• 요구사항 12장 Must Have의 "AI 판결 생성 및 제공"에는 기획서(final-planning.md:767)처럼 "(MVP는 오프라인 생성 · 검수 결과 적재)" 단서가 없다.
• 제안: MoSCoW는 가치 우선순위, 구현 단계는 일정이라는 점을 요구사항 12장에 한 줄 적고, Could Have 두 항목에 REQ를 붙이거나 "REQ 없음(구조만 준비)"이라고 적는다.

C-21. 서비스명 띄어쓰기

• 기획서 final-planning.md 전체: "내 Law 남불"
• 요구사항, IA, 와이어프레임 등 나머지 전부: "내Law남불"
• 제안: 와이어프레임 로고 표기에 맞춰 "내Law남불"로 통일한다.

C-22. 미결정 사항 목록이 문서마다 다름

• 요구사항 15장(:483-511)에만 있는 미정 항목: 판례 데이터 확보 경로, 초기 MVP 콘텐츠 구성, 권고 범위 이탈 시 사유 입력 강제, 무죄 처리, 부가 처분 비대칭 안내, 익명 ID 유지, 약관 조항, "내 판결과의 차이" 문구 로직 등.
• 기획서 12장(:837-866)에는 이 항목들이 없고, 반대로 "범죄 유형별 데이터 구조 확정", "권고 범위 계산 로직 상세 설계"처럼 요구사항 15장에 없는 항목이 있다.
• 기획서 9-1(:722-735)에는 요구사항 FR-1-9의 "조건을 만족하는 판례를 아직 찾지 못했다"는 조사 결과가 없다.
• 제안: 미결정 사항은 요구사항 15장 한 곳에서 관리하고, 기획서 12장은 "요구사항 15장 참고"로 바꾼다.

C-23. 기능 명세서 표 형식

• REQ-017(:66), 023(:72), 037(:93), 063(:136), 077(:169): 설명 칸 안에 "/ 변경: …"이 섞여 있고, 023 · 037 · 077은 변경 칸이 "—"다.
• 작성 이력 v3.1(:10)의 "MVP 묶음 표 제목 · API 참조 정정"에 나오는 "MVP 묶음 표"가 현재 문서에 없다.
• (검증 결과) 총 107개, MVP 47 · 확장 25 · 이후 22 · 데이터 13으로 요약 표·요구사항 15장·기획서 12장과 숫자는 맞다. ID 누락·중복도 없다.
• 제안: 변경 내용을 변경 칸으로 옮기고, 이력의 "MVP 묶음 표" 문구를 지우거나 표를 복원한다.

C-24. REQ-019 변경 칸 "MVP는 순서대로 이동만"

• 기능_명세서.md:68 변경 칸 "MVP는 순서대로 이동만".
• 요구사항 FR-2-4(:192), IA 9장(:347), API 7(STEP_OUT_OF_ORDER)은 서버가 순서를 강제하고, 잠긴 섹션 본문은 응답하지 않는다로 확정했다.
• 제안: "서버에서 순서 강제, 잠긴 섹션 본문 미응답(v3)"으로 고친다.

C-25. 새로고침 시 S-04 복원 범위 표현

• 요구사항 FR-2-11(:213): "마지막으로 확인한 섹션까지 펼쳐진 상태로 복원"
• IA(:222), API 6(openStep = lastReviewedStep + 1): 확인한 섹션 + 그다음 섹션까지 펼침
• 제안: 요구사항 문구를 "확인한 섹션과 다음에 확인할 섹션까지"로 맞춘다.

C-26. 사전 판단 형량 구간 7개: "확정" vs "예시"

• 요구사항 FR-2-8(:203), REQ-016: "MVP 선택지(7개)" 확정 (v5.4)
• 기획서 6-2-4(:243-253): "형량 구간 예시" + "실제 선택 범위는 … 별도로 정의", 12장(:842)에서는 미정. 반면 7장(:678)은 "7개 중 1개"라고 적었다.
• 제안: 기획서 6-2-4를 "MVP 7개 확정, 범죄 유형별 세부 조정은 추후"로 고친다.

C-27. 권고 범위 막대의 상한 기준

• 요구사항 FR-3-2(:241): 막대는 "0 ~ 선고 가능 상한"
• 와이어프레임 p.7 · 8 · 15: 막대 끝 라벨 "법정형 상한 10년"
• 예시 사건은 둘 다 10년이라 차이가 안 보이지만, 누범 가중이 있는 사건에서는 달라진다. (요구사항 본문도 이 차이를 괄호로 적어 두었다.)
• 제안: 라벨을 "선고할 수 있는 상한"으로 고치거나, 요구사항에 "라벨은 법정형 상한을 표시"로 결정 내용을 적는다.

C-28. 프론트엔드 배포 구조 누락

• 기술 스택 8장(tech-stack.md:353-373)은 백엔드 EC2 배포만 있고 프론트 배포(정적 호스팅/같은 도메인 프록시)가 없다. 로컬 Vite 프록시만 언급(:175).
• API 명세 1-2(:33), 6장 #2(:570)는 도메인 구조에 따라 SameSite·CORS 설정이 달라진다며 "같은 도메인(/api 프록시)"을 제안한다.
• 제안: 기술 스택 8장에 프론트 배포 방식을 정하고 API 6장 #2와 맞춘다.

C-29. AI 비교 분석 입력 항목 표현 차이

• 요구사항 FR-6-3 ①(:369): 형벌·형량·요소 ID·방향, 사전 판단 구간
• 기획서 6-6-4(final-planning.md:626): 형벌·형량·판단 요소·방향 (사전 판단 구간 없음)
• 시퀀스 8장 #1(sequence-diagram.md:314): 위에 더해 요소 문구 · 공개 단계, 자유 입력 처리 규칙
• 제안: 시퀀스 8장 안전장치 표를 기준으로 요구사항·기획서 문구를 맞춘다.

C-30. 기타 표기

• IA 화면 목록 S-14 단계가 "M"(information-architecture.md:132) — 사이트맵은 [MVP].
• "익명 세션"(기능 명세 REQ-098 · 105, IA) vs "익명 ID"(API, ERD, 기술 스택) 용어가 섞여 있다. 쿠키 기반 UUID이므로 "익명 ID"로 통일하는 것이 정확하다.
• 요구사항 근거 문서(requirements-specification.md:57)가 "기획서 최종본 v1 · v2"를 들고 있으나 기획서는 현재 v4.1이다. 본문의 "(기획서 v2 반영)" 표기는 이력으로서 괜찮지만, 근거 문서 목록에는 최신 버전을 적는 것이 좋다.
• 기술 스택 문서에만 작성 이력(버전 표)이 없다.

---

5. 서로 잘 맞는 부분 (검증 완료)

아래 항목은 관련 문서 사이에서 모두 일치했다.

항목	확인한 문서
체험 상태 7단계(STARTED ~ COMPLETED)와 상태별 허용 화면 · 보낼 화면	요구사항 DR-6, 기능 명세 REQ-105, IA 9장, ERD experience, API 1-6 · 4장, 시퀀스 3장
섹션 번호(① = 1 ~ ④ = 4), 사전 판단 제출 시 last_reviewed_step = 1, 순서 서버 강제	IA, ERD, API 5 · 6 · 7, 시퀀스 5장
선고 가능 범위의 정의(법률상 감경 + 작량감경을 모두 적용한 가장 넓은 범위), 범위 밖 확정 불가 + 서버 거절	요구사항 FR-3-3, 기능 명세 REQ-037 · 104, IA 2장 #6, ERD 4장, API 9, 기획서 6-3-5, 와이어프레임 S-06c
집행유예 조건(징역 3년 이하 · 벌금 500만 원 이하, 기간 1 ~ 5년)	ERD penalty_rule, API 8 · 9, 시퀀스 6장
예시 데이터: 판단 요소 7개, 내 판결 30/48개월 · AI 24/36 · 재판부 18/36(+사회봉사 120시간), 요소별 방향, 매트릭스 분류 태그(ALL_SAME / ONLY_ME_MISSED / DIVERGED)	ERD 6장, API 8 · 10 · 12 · 14 · 15, 와이어프레임 p.9 ~ 15
사전 판단 형량 구간 7개와 문구	요구사항, 기능 명세, API 4, 와이어프레임 S-03
진행 표시 6단계, S-06 진행 표시 없음	요구사항 FR-2-7, IA 2장, 와이어프레임 p.4 ~ 12
AI 비교 분석: S-08 진입(AI_REVEALED) 시 비동기 생성, 체험당 1회, S-09는 규칙 문장 먼저	요구사항 FR-6-3, IA S-08 · S-09, ERD comparison_analysis, API 11 · 15, 시퀀스 8장, 기획서 6-6-4, 기술 스택 6장
사전 판단은 S-09에서 처음 다시 보여 줌(API 14에서 처음 응답)	요구사항, IA 2장 #2, ERD 5장, API 5 · 14, 시퀀스 7장, 기획서 6-2-4
공개 AI · 재판부 판결 1개 제약(부분 유니크 인덱스)	ERD 3-3, 기술 스택 2장
기능 명세 단계 집계 107 = 47 / 25 / 22 / 13	기능 명세서, 요구사항 15장, 기획서 12장
IA 화면 목록의 REQ 번호와 기능 명세 구현 단계	IA 4장 ↔ 기능 명세서 (MVP 화면에 확장 REQ가 괄호 없이 들어간 경우 없음)

---

6. 권장 정리 순서

1. 구현 계약 먼저 (C-01 · C-02 · C-03 · C-09): API 명세를 기준 문서로 정하고, 기술 스택 4 · 5장과 시퀀스의 체험 ID 표현을 API 명세에 맞춘다. BE/FE 개발 착수 전에 끝내야 한다.
2. 대표 판례와 예시 값 (C-04 · C-05 · C-12): 동종 경합범 처리와 무죄 처리 방침을 정한 뒤 ERD 예시, API 예시, 와이어프레임 S-04c ~ S-06 값을 함께 고친다.
3. DB 스키마 (C-07 · C-08): Flyway 마이그레이션을 작성하기 전에 ERD 타입과 컬럼명을 PostgreSQL 기준으로 확정한다.
4. 와이어프레임 보정 (C-13 · C-14 · C-16 · C-27): 점선 표시와 데이터가 없는 요소를 정리한다.
5. 표기 · 참조 정리 (C-10 · C-11 · C-17 ~ C-26 · C-28 ~ C-30): 한 번에 묶어 문서 정리 PR로 처리한다.

---

부록. 점검 범위 밖 참고 사항 (문서 ↔ 코드)

문서 점검 중 확인한 것이라 참고로 남긴다. 이번 점검 대상은 아니다.

기술 스택 서술	현재 코드
Flyway로 스키마 관리, 운영은 ddl-auto: validate (tech-stack.md:63, :78)	backend/build.gradle에 Flyway 의존성 없음, application.yml 기본값 ddl-auto: update
Docker Compose로 PostgreSQL + Redis 구성 (tech-stack.md:323-328)	backend/docker-compose.yml에 Redis 서비스 없음 (PostgreSQL은 pgvector/pgvector:pg17 이미지로 일치)
Spring Boot 4, PostgreSQL, open-in-view 끔	4.1.1, org.postgresql:postgresql, open-in-view: false로 일치