# 🚀 K-ArtSell Aegis v16.0 - 현재 진행 로드맵

**최종 갱신:** 2026-08-08 (VS 번호 재배정 — 아래 "알려진 문서 정합성 문제" 1번 참조. 2026-08-07 갱신 내용은 실제 코드/테스트를 직접 확인한 결과였고 이번 갱신은 그 위에 번호 충돌만 정정한 것입니다.)

**상태 요약:** VS-27(감사 추적), VS-10(매도 결정), VS-28(거래 실행), VS-29(포트폴리오 대사) 백엔드 구현 + 테스트 완료. VS-26(승인 워크플로우, 구 VS-03)은 DEBT-017(중복 구현) 미해결로 **BLOCKED**. Phase 1 Shadow Run(Gate 5a, 252+ 거래일 검증)은 **아직 시작되지 않음** (과거 "RUNNING" 기록은 허위였음이 이미 문서로 정정됨). 상세 항목별 상태는 `docs/CURRENT/CATALOGS/WBS_PROGRESS_TRACKER.csv` 참조.

---

## ⚠️ 알려진 문서 정합성 문제 (DECISION_REQUIRED)

1. **VS 번호 체계 충돌 — 2026-08-08 부분 해결:** `WBS_MASTER.csv`(원 계획)와 `WBS_PROGRESS_TRACKER.csv`(실행 트래커) 사이의 VS-03/VS-04/VS-12/VS-14 충돌은 트래커 쪽 4개 슬라이스(승인워크플로우/감사추적/거래실행/포트폴리오대사)를 VS-26/27/28/29로 재번호 부여하여 해결했습니다. 근거: `docs/DECISIONS/ADR-WBS-001-slice-renumbering.md`.
   - **이 과정에서 새로 발견한, 아직 미해결인 문제 (TECH_DEBT_REGISTER.md DEBT-017):** VS-26(구 VS-03) 승인워크플로우는 **동일 기능의 중복 구현이 두 벌** 존재합니다 — `src/KArtSell.Modules.ModelOperations/ApprovalWorkflow/`(20/20 테스트 통과하지만 전 엔드포인트가 `[DontRegister]`로 비활성화되어 실제로는 호출 불가능한 죽은 코드)와 `Features/ApprovalWorkflow/`(`Program.cs`에 실제 등록되어 살아있지만 전용 테스트가 없음). 즉 **테스트된 코드는 죽어있고, 살아있는 코드는 테스트되지 않았습니다.** 아키텍트 결정(둘 중 하나를 정식으로 선택하고 나머지 삭제) 전까지 이 슬라이스에 프런트엔드를 붙이지 마세요. WBS_PROGRESS_TRACKER.csv의 AEG-VS-26-01 행 상태를 `BLOCKED`로 정정했습니다.
   - **또 다른 발견 — 미추적 작업:** `src/KArtSell.Host/Features/MarketData/VS03_*.cs`, `Features/Portfolio/VS04_*.cs`/`VS05_*.cs`/`VS08_*.cs`는 실제 구현되고 테스트도 있는(commits `2bc2b1e`, `32b49a4`, `14c5e4f`, `2eee44d`) **세 번째** VS-03/04/05/08 사용례(Market Data Ingestion Dashboard, Portfolio Rebalance, Risk Metrics, Dashboard)인데, `WBS_PROGRESS_TRACKER.csv`에 전혀 기록되어 있지 않습니다. 다음 세션에서 이 작업을 검증(빌드/테스트 재현, 프런트엔드 존재 여부 확인)하고 트래커에 추가해야 합니다.
2. **DbUp 마이그레이션 테스트 DB 권한 문제:** `kartsell` DB 사용자가 `kartsell_migration_test` 데이터베이스의 소유자가 아니어서 `DbUpMigrationTests`(12건)가 로컬에서 실패합니다. 코드 문제가 아니라 DBA 조치(소유권 부여)가 필요합니다. 실행할 SQL 초안: `scripts/dba/grant-migration-test-db-ownership.sql`.
3. **frontend 빌드 산출물 재해시:** `dotnet build`를 실행할 때마다 `pnpm build`가 재실행되어 `wwwroot/assets/*` 해시 파일명이 바뀌고 git에 불필요한 변경이 쌓이는 구조적 문제가 있습니다 (아직 미해결).

---

## ✅ 완료 (Backend 구현 + 테스트, 2026-08-07 기준 검증됨)

### VS-26 (구 VS-03): 모델 승인 워크플로우 (Maker-Checker Governance) — 🔴 BLOCKED
- **위치:** `src/KArtSell.Modules.ModelOperations/ApprovalWorkflow/` (죽은 코드, `[DontRegister]`) + `Features/ApprovalWorkflow/` (실제 등록됨, 테스트 없음)
- **테스트:** 20/20 PASS는 죽은 코드 쪽 결과입니다 — 실제로 호출되는 구현은 테스트되지 않았습니다. 자세한 내용은 TECH_DEBT_REGISTER.md DEBT-017 참조.
- **미완료:** 프런트엔드 UI 없음. DEBT-017 해결 전까지 착수 금지.
- **이전 세션에서 발견/수정한 결함 (여전히 유효, 죽은 코드 쪽 한정):** `ApprovalSql`이 Dapper로 `DateOnly` 파라미터를 바인딩하지 못해 승인 제안서 생성이 실 DB 환경에서 100% 실패하던 버그 — 병합 이후 실 DB로 한 번도 검증되지 않아 발견되지 않고 있었음

### VS-27 (구 VS-04): 불변 감사 추적 (Audit Trail / GDPR)
- **위치:** `src/KArtSell.Modules.ModelOperations/Compliance/`
- **테스트:** 5/5 PASS (격리 실행 기준)
- **미완료:** 프런트엔드 UI 없음
- **이번 세션에서 발견/수정한 결함:** `ip_address`/`kis_response`류 컬럼의 Dapper 타입 캐스팅 실패, `GdprRetention.RetentionEndsAt`이 `DATE` 컬럼인데 `DateTime`으로 선언되어 있던 문제, 그리고 `KArtSell.BuildingBlocks`의 `[ModuleInitializer]`가 우연히 로드되지 않으면 모든 snake_case 컬럼이 null로 매핑되던 레이스 컨디션

### VS-10: 매도 결정 엔진 (Sell Decision Engine)
- **위치:** `src/KArtSell.Modules.ModelOperations/SellDecision/`, `frontend/src/features/sell-decision/`
- **테스트:** 32/32 PASS (격리 실행 기준)
- **완료도:** Backend + Frontend 모두 존재 (VS-26/27/28/29 중 유일)
- **⚠️ 미검증 사항:** 코드/테스트 완료 ≠ PBO/DSR 프로덕션 검증 완료. 실 시장 데이터 기반 검증은 Phase 1 Shadow Run 완료 후에만 가능

### VS-28 (구 VS-12): 거래 실행 시스템 (Trade Execution, KIS 연동)
- **위치:** `src/KArtSell.Modules.ModelOperations/TradeExecution/`
- **테스트:** 13/13 PASS (격리 실행 기준)
- **미완료:** 프런트엔드 UI 없음
- **이번 세션에서 발견/수정한 결함 (심각):** `UpdateTradeStatusAsync`가 `status`/`kis_response`/`error_message`만 저장하고 `kis_order_id`, `executed_quantity`, `unit_price`, `commission`, `net_proceeds`, 체결/정산 타임스탬프는 병합 이후 매번 조용히 유실시키던 버그. 거래 체결·정산 데이터가 실제로는 저장되고 있지 않았음

### VS-29 (구 VS-14): 포트폴리오 대사 (Portfolio Reconciliation)
- **위치:** `src/KArtSell.Modules.ModelOperations/PortfolioReconciliation/`
- **테스트:** 18/18 PASS (격리 실행 기준)
- **미완료:** 프런트엔드 UI 없음
- **참고:** 이 슬라이스가 포함된 PR(#28)이 병합 당일 `model_operations.models` 테이블 누락으로 신규 DB 마이그레이션을 전부 깨뜨리는 채로 병합되었고, 같은 날 별도 PR(#29)로 긴급 수정됨 — 병합 전 fresh-install 리허설이 실제로 이루어지지 않았음을 시사

### AEG-X-009: 외부 데이터 소스 통합 (KRX/OpenDart/KIS)
- **위치:** `src/KArtSell.Modules.ModelOperations/Infrastructure/`, market_data 스키마
- **완료:** 소스 카탈로그/거버넌스 정책(Workstream D/E/F) + 실 API 연동(Workstream G: KRX OpenAPI/OpenDart/KIS 서비스, 일일 스케줄링, 에러 분류, LKG 폴백)

### 그 외 완료 항목 (VS-00 플랫폼 부트스트랩, VS-01/VS-02 슬라이스 스펙, 보안/Outbox/OpenAPI 게이트 등)
상세는 `docs/CURRENT/CATALOGS/WBS_PROGRESS_TRACKER.csv`의 AEG-X-001~008, AEG-VS-00-01~07, AEG-VS-01-01, AEG-VS-02-01 행 참조.

---

## 🔴 실제로 블로킹 중인 것 (Phase 1 Shadow Run)

### PHASE-1-SHADOW-RUN: 252+ 거래일 검증 (Gate 5a)
- **상태:** `BLOCKED` — **실행 중이 아님**
- **근거:** `docs/CURRENT/PHASE-1_SHADOW_RUN_STATUS_CORRECTION.md`에 이미 정정되어 있음 — 과거 세션들의 "Job 893/976 RUNNING, ~20+시간 경과" 등의 기록은 실제로는 `POST /api/shadow-runs`가 `PostgresException 23514`(check_status 제약조건 위반)로 500 에러를 반환하며 실패한 것이었고, Job이 실제로 시작된 적이 없음
- **차단 사유:** 서버 측 `dataset_manifest`, `model_version_registry`, `evidence_snapshot`, `release_evidence_bundle`에 승인/동결된 행이 없어 RunId/JobId를 생성할 수 없음. 승인된 VersionSet 대기 중
- **재개 절차:** `PHASE-1_SHADOW_RUN_STATUS_CORRECTION.md`의 5단계 참조 (① check_status 제약조건 정합 ② 승인된 테스트 DB에서 fresh/upgrade/재실행/실패복구 리허설 ③ 증거 보존 ④ 명시적 승인 획득 ⑤ 신규 Run ID/Job ID로 재큐잉)
- **이 상태가 바뀌려면:** 실제 RunId/JobId가 존재해야 하며, 문서에 "RUNNING"이라고 다시 적으려면 그 근거를 반드시 명시해야 함 (과거의 허위 기록을 반복하지 말 것)

이 게이트는 **달력 시간이 필요한 작업**입니다 (252+ 거래일 시뮬레이션은 컴퓨팅으로 앞당길 수 없음). "최적 전략적으로 빨리 끝내기"의 대상이 될 수 없고, 남은 유일한 실행 가능 조치는 위 재개 절차를 밟아 실제로 큐잉하는 것뿐입니다.

---

## 📚 관련 문서

- **WBS 트래커 (항목별 상세 상태):** `docs/CURRENT/CATALOGS/WBS_PROGRESS_TRACKER.csv`
- **WBS 원 계획 (번호 충돌 있음, 주의):** `docs/CURRENT/CATALOGS/WBS_MASTER.csv`
- **Phase 1 상태 정정 기록:** `docs/CURRENT/PHASE-1_SHADOW_RUN_STATUS_CORRECTION.md`
- **Architecture:** `docs/03_ARCHITECTURE_BE_FE.md`
- **Code Guidelines:** `CLAUDE.md`
- **Tech Debt:** `TECH_DEBT_REGISTER.md`

---

## 📝 이 문서를 다시 갱신할 때

1. **git log를 먼저 확인하세요.** 이 문서와 `main`이 얼마나 벌어졌는지 (`git log --oneline <이-문서-마지막-커밋>..main`) 확인하지 않고 문서만 읽고 "현재 상태"를 판단하지 마세요.
2. **테스트는 격리 실행으로 확인하세요.** 전체 스위트 실행에서 통과했다고 해서 개별 기능이 안정적으로 통과하는 것은 아닙니다 (이번 세션에서 `AuditSql`이 정확히 이 이유로 놓칠 뻔했습니다 — `--filter`로 단일 클래스만 돌려서 재확인하세요).
3. **"완료"라고 쓰기 전에 실제 파일 경로와 테스트 결과를 직접 확인하세요.** 이 저장소에는 검증 없이 "COMPLETE"/"100%"라고 선언한 문서가 매우 많습니다 (`EXECUTION_COMPLETE_FINAL.md`, `WORK_COMPLETION_CERTIFICATE.md` 등). 그 패턴을 반복하지 마세요.
4. **Phase 1 Shadow Run은 달력 시간 게이트입니다.** 실제로 큐잉되어 진행 중이라는 구체적 증거(RunId/JobId) 없이 "진행 중"이라고 쓰지 마세요.