# 역할별 처절한 결함 감사

## 운영사
가장 위험한 착각은 “추천이 생성되면 운영 가능”이라는 판단이다. 데이터 지연·격리·승인 대기·만료·정정·대사·민원·DR 화면과 Runbook이 없으면 운영사는 매일 DB와 로그를 뒤진다. v14는 T08/T09/T10과 J39로 운영 상태를 제품 표면에 올린다.

## 아키텍트
v13의 Adapter 방향은 맞지만 공급자가 하나뿐이면 교체 가능성은 선언에 불과하다. v14는 reference provider를 추가하고 contractVersion/capability/fail-fast를 도입했다. 단, Native provider를 생산 대안으로 오해하지 않도록 `productionEligible=false`로 고정한다.

## PM/PL
400개 WBS가 있어도 “누가 어떤 증거로 완료를 승인하는가”가 약하면 숫자 장식이다. v14 Delta 80건은 각 작업에 Artifact, Acceptance Evidence, Owner, Dependency, Gate, Risk를 유지한다. P0는 Gate 전에 종료하거나 승인된 완화통제를 가져야 한다.

## UX/AX
표준 화면은 예쁜 shell이 아니라 실패 상태의 일관성이다. LOADING/EMPTY/WARN/ERROR/권한/부분/충돌/만료/읽기전용/처리중이 누락되면 고객과 운영자는 시스템을 신뢰하지 못한다. T01~T10은 상태와 증거를 계약으로 만든다.

## QA
정적 파일 존재 검사는 품질이 아니다. v14는 정적 검증 범위를 명시하되 typecheck/build/DB/E2E를 PASS로 주장하지 않는다. 공급자 교체는 contract test만으로 부족하며 접근성·시각회귀·대량목록 성능이 필요하다.

## 투자 고객
고객에게 필요한 것은 내부 점수표가 아니라 “왜, 어느 시점 데이터로, 어떤 비용과 반대증거를 보고, 언제 다시 검토하는가”다. EvidenceVersionSet, as-of, warning, 만료, 승인본 hash가 화면의 필수 정보다.

## 개발자
Generic Repository, God Service, 모든 클래스 interface, 모든 화면 AG Grid는 생산성을 가장한 복잡성이다. Endpoint/Application/Policy/SQL/Event/Test의 Slice를 유지하고, 외부 경계와 교체 seam에만 interface를 둔다.

## 데이터 아키텍트/DBA
현재값 overwrite와 current flag 중심 설계는 PIT 백테스트와 감사의 적이다. Raw/PIT/DQ/Evidence/Ledger/Read Model을 분리하고, 원장·Evidence·transition은 append-only, 화면 성능은 projection으로 해결한다.

## 컨설턴트 결론
프로젝트의 가장 큰 위험은 기술 부족이 아니라 “검증하지 않은 것을 완료로 말하는 문화”다. Source/Assumption/Unknown/Decision Required와 실제 artifact를 PR·Release Gate의 언어로 고정해야 한다.