4.4 KiB
역할별 처절한 비판과 교정안
운영사
비판: 화면과 알고리즘 이름은 많지만, 누가 새벽 배치 실패를 인지하고 어떤 기준으로 고객 공개를 멈추며 몇 시간 안에 복구할지 계약이 약하다. 자동화가 늘수록 운영인력은 줄지 않고 예외처리 책임이 증가한다.
교정: P1/P2 장애등급, Owner/Secondary, BusinessHold/Quarantine/Poison 분기, 대사·정정·재처리 Runbook, 월별 rollback drill을 Release Gate에 묶는다.
아키텍트
비판: Modular Monolith와 Vertical Slice 선택은 정공법이다. 하지만 문서상의 13개 논리 모듈과 실제 구현 2개 모듈 사이의 간극이 크다. Architecture Test가 문자열 검사에 머물면 직접 DB 접근과 잘못된 참조를 놓친다.
교정: assembly/namespace/schema/API ownership fitness function, 모듈별 public contract, 금지 의존 allowlist, DB schema role 분리를 CI에서 검증한다. 조기 microservice와 Generic Repository는 금지한다.
PM
비판: 288개 WBS는 상세하지만 반복되는 7개 표준 작업이 많아 진행률이 부풀려질 수 있다. PLANNED 60%를 완료 60%로 오인할 위험이 있다.
교정: P0 Critical Path, Gate burn-down, Decision Required aging, Evidence completeness를 관리한다. 작업 완료는 파일 생성보다 검증 artifact 링크로 판정한다.
PL
비판: 공통 템플릿은 생산성을 높이지만 Slice별 실패상태·경계값·권한·데이터시점이 구체화되지 않으면 복사된 구조만 남는다.
교정: VS-03, 08, 09, 10, 11, 14, 15/16, 18, 19, 23, 25를 먼저 실제 계약으로 완성하고 나머지는 동일 패턴을 적용한다.
UX/AX 디자이너
비판: 운영 AG Grid와 기술적 Evidence 화면은 있으나 고객이 “왜 매도인가, 얼마나 팔아야 하는가, 무엇이 틀릴 수 있는가, 언제 다시 보나”를 이해하는 여정이 약하다.
교정: 행동요약→핵심근거→반대증거→비용/세금→불확실성→다음검토→재진입 계약 순서로 정보위계를 고정한다. 고객에게 내부 점수와 모델 jargon을 노출하지 않는다.
QA 테스터
비판: Python 정적검증과 Golden 4건은 smoke evidence일 뿐이다. .NET compile, PostgreSQL migration, concurrency, crash, replay, timezone, delisting, corporate action, partial fill을 검증하지 않았다.
교정: Architecture/Data/Golden/Integration/E2E/Backtest/Failure/Replay/DR의 8중 테스트 포트폴리오와 Release Evidence를 구축한다.
투자 고객
비판: 적중률과 예상수익만 보이면 오해를 유발한다. 추천과 실제 체결·고객행동·시장성과가 섞이면 성과책임이 왜곡된다.
교정: 추천 성과, 고객 의사결정, 실행 성과를 분리하고 비용·세금·FX·유효기간·데이터 경고를 명시한다. 수익보장 표현은 금지한다.
개발자
비판: skeleton은 깔끔하지만 lockfile이 없고 실제 build가 미검증이며, 생성되지 않은 OpenAPI client 때문에 DTO drift가 발생할 수 있다.
교정: 승인 환경에서 lockfile 생성·review, OpenAPI artifact diff, generated client/Zod schema, Testcontainers/PostgreSQL integration, deterministic seed를 Gate로 둔다.
데이터 아키텍트
비판: PIT 필드 정의는 강하지만 source priority, 충돌해결, calendar, 단위/통화, total-return, delisting return의 실제 공급계약이 없다.
교정: L0 Source Contract를 먼저 승인하고 Raw→Canonical PIT→DQ→Dataset Manifest를 분리한다. 수정은 revision과 supersession으로 보존한다.
DBA
비판: DDL은 불변성 방향이 옳지만 볼륨, partition, 인덱스, vacuum, retention, query plan 근거가 없다. 모든 append-only 테이블이 무한 증가하면 운영이 무너진다.
교정: 데이터 규모 결정 후 월/시장 partition, BRIN/B-tree 선택, 보존·archive, index usage, migration 4시나리오, backup/restore를 실증한다.
컨설턴트
비판: 문서 버전이 올라갈수록 “완성”이라는 인상을 주지만, 실제 증거가 없는 상태에서 버전 숫자는 위험한 착시다.
교정: 상태를 IMPLEMENTATION_TEMPLATE로 고정하고, Build/DB/Shadow/Pilot은 독립 Evidence Gate로만 승격한다. 더 많은 문서보다 Decision을 닫고 첫 End-to-End Slice를 완성한다.