Analysis (Check) — todo-app

PDCA Phase: Check · Feature: todo-app · 작성일: 2026-06-15 상위: Plan · Design

Context Anchor

항목	내용
WHY	사내 샘플을 실제 쓰는 최소 To-Do 앱으로 — DB+S3 패턴 시연
WHO	로그인 없는 단일 공용 목록
RISK	첨부 처리, schema 마이그레이션, S3-DB 정합성
SUCCESS	브라우저 CRUD + 첨부 업/다운로드, db/minio check 통과
SCOPE	IN: todo CRUD + 첨부 1개 + 웹UI + API / OUT: 인증·태그·검색

Match Rate

축	점수	가중치	기여
Structural	100%	0.15	15.0
Functional	96%	0.25	24.0
Contract	100%	0.25	25.0
Runtime (L1)	100%	0.35	35.0
Overall	99%

런타임 실행 공식 적용(서버 기동). 16/16 L1 테스트 통과, 서버 로그 에러 없음.

1. Structural Match — 100%

Design §2 모듈 구조 전부 존재, §4 라우트 6개(GET /, GET/POST /api/todos, PATCH/DELETE /api/todos/:id, GET /api/todos/:id/attachment) 모두 구현·마운트 확인.

2. Functional Depth — 96%

항목	결과
업로드 보상 삭제(§5,§6)	✅ 업로드 실패 시 `repo.remove`
삭제 시 S3 선삭제 후 DB(§6)	✅ best-effort 로깅 후 진행
pgcrypto fallback(§3)	✅ 런타임에서 실제 발동 확인(`permission denied`→`randomUUID`)
입력 검증(title/uuid/done)	✅
placeholder/미구현	없음

−4% 사유 (Minor): Design §5는 "단일 INSERT(첨부 키 포함)"로 기술됐으나, 구현은 "INSERT → setAttachment UPDATE" 2단계. 동작·정합성은 동일(오히려 id 기반 키 생성에 더 적합). 문서-구현 표현 불일치만 존재.

3. API Contract — 100% (3자 검증)

Design §4 ↔ src/routes.todos.js ↔ public/index.html fetch 호출 일치:

응답 envelope {data} / {error} ✅
hasAttachment 노출 + attachment_key 비노출 ✅ (런타임 L1-8 검증)
상태코드(201/400/404/413/204/200) 일치 ✅
다운로드 Content-Disposition 헤더 ✅ (L1-10)

4. Runtime Verification (L1) — 16/16 PASS

#	검증	기대	결과
1	GET /	200	✅
2-3	GET /api/todos + {data}	200	✅
4	POST title	201	✅
5-6	POST no title + {error}	400	✅
7	첨부 hasAttachment	true	✅
8	attachment_key 비노출	—	✅
9-10	다운로드 + Content-Disposition	200	✅
11	PATCH done	200	✅
12-14	PATCH bad uuid/no done/404	400/400/404	✅
15	DELETE	204	✅
16	삭제 후 다운로드(cascade)	404	✅

5. Success Criteria 평가

SC	상태	근거
SC-01 CRUD UI	✅ Met	L1 + public/index.html
SC-02 업로드→S3+DB key	✅ Met	L1-7, S3 객체 생성
SC-03 다운로드	✅ Met	L1-9/10 내용 일치
SC-04 삭제 시 S3도 삭제	✅ Met	L1-16 cascade
SC-05 db/minio check	✅ Met	둘 다 통과
SC-06 podman	⚠️ Partial	Dockerfile 무변경으로 빌드 가능하나 이 세션 미실행

6. Decision Record 준수 검증

결정	준수
Option C(repo/attachments/routes 분리)	✅
서버 프록시 스트리밍(presigned 미사용)	✅ `GetObjectCommand` pipe
pgcrypto + randomUUID fallback	✅ 런타임 발동
변경점: multer 1.x→2.1.1	✅ 의도된 보안 대응, API 동일

7. Gap 목록

ID	Severity	내용	조치
G1	Minor	§5 단일 INSERT 서술 vs 2단계 구현	문서 동기화(선택)
G2	Minor	SC-06 podman 빌드 미검증	컨테이너 빌드 1회 권장
G3	Minor	파일 content-type 화이트리스트 미적용(NFR-03 일부)	OUT-of-scope 수준, 향후

Critical/Important 갭: 0건.

8. 결론

Overall 99% (≥90% 목표 달성). Critical/Important 이슈 없음. Minor 3건은 모두 문서/범위 외/검증 절차 항목으로 코드 수정 불요. → iterate 없이 QA 또는 report 단계로 진행 가능.

4.2 KiB Raw Blame History Unescape Escape