복잡한 개개인의 투자행동지표(BI) 엔진 로직을 1,403줄 사양서로 확정하고, 자산유형별 파라미터 구조의 설계를 확정했습니다.
## 🎯 이런 개발자에게 도움돼요
복잡한 도메인 로직(금융, 헬스케어)을 코드로 바로 작성하기 전에 사양서부터 확정하고 싶은 분,
여러 문서를 동시에 업데이트해야 하는데 동기화가 힘든 분,
비즈니스 로직이 자주 바뀌는 프로젝트에서 버전 관리가 필요한 개발자에게 제 사례가 도움이 될 듯해요.
## 😫 문제 상황
1. "손절회피(LCA)등 문제가 되는 지표들을 기존에 고민해서 만든 로직과 엔진들이 있는데, 어떻게 정교하게 공식화 하지? 또 잘못된 투자행동을 교정하는데 도움이 될 수있는 인사이트가 있어야 되는데. 흠..
2. 파라미터 P01~P10이 개별주식과 ETF에 동일하게 적용되면 문제 발생
3. 관련 기획 문서 5개가 흩어져 있어서, BI 사양서만 고치면 나머지는 outdated되는 문제가 발생
## 🔧 작업 과정
지표 확정과 공식 결정
*요청:**
```
"투자행동심리학의 10개 대표 투자행동지표 (LCA, TSI, RRR, GLA, FOMO, LEV, DIV, HOLD, PROF, AVG, PANIC)의 기존 로직들 계산 공식을 Python + Excel 수식으로 작성해줘"
```콜르드코드와 Gemini Pro를 활용했어요.
**예시: LCA(손절회피)**
```python
# 트리거 조건
TRIG_LCA = (side == "SELL") AND (pnl_pct <= P01)
# 준수 조건
OK_LCA = TRIG_LCA AND (holding_days <= P02)
# 준수율
LCA_Score = count(OK_LCA) / count(TRIG_LCA) × 100
```
**효과:**
- 구현 시 이 사양서만 보고 코드 작성 가능
- Excel로 미리 검증 가능 (CSV 데이터로 테스트)자산유형별 파라미터 분기
문제 발견:
"개별주식 손절 -10%를 ETF에도 적용하면,
ETF는 변동성이 낮아서 너무 자주 손절됨"
** 해결:**
```python
# Before: 단일 기본값
P01_stop_loss = -0.10
# After: 자산유형별 분리
if asset_type == "stock":
P01_stop_loss = -0.10 ~ -0.15
elif asset_type == "etf":
P01_stop_loss = -0.05 ~ -0.08
```
**Claude 작업:**
- 10개 파라미터 × 2개 자산유형 = 20개 기본값 설정
- 각 파라미터마다 행동경제학 근거 작성
| 파라미터 | 개별주식 | ETF | 근거 |
|:---------|:--------:|:---:|:-----|
| P01 손절기준 | -10~-15% | -5~-8% | 지수 -8% = 개별주 -20% 충격 |
| P02 보유기간 | 10~15일 | 40일 | ETF는 장기 추종 |
| P04 목표수익 | 20%+ | 12~15% | 심리적 가치 동등 |
**효과:**
- 온보딩 시 자산유형 감지 → 적절한 기본값 제안
- BI 계산 로직에서 `instrument.asset_type` 기반 분기문서동기화. BI 사양서를 수정하면 관련 문서 4-5개도 함께 수정 필요
- 수동 작업 시 누락 위험
**해결:**
```
"BI 사양서 확정했으니, 관련 문서도 같이 업데이트해줘:
- DATABASE-SCHEMA-v3.md의 seed 데이터
- MIGRATION-ROADMAP-v3.md의 검증 코드"
```결과와 배운 점
1. BI 사양서 v4.1.2 (1,403줄)
- 10개 행동지표 계산 공식
- Python + Excel + 시나리오 예시
- 자산유형별 파라미터 20개 기본값
- 버전 변경 이력 테이블
2. 관련 문서 동기화
- 5개 파일 업데이트 (+3,722줄), 문서 간 불일치 방지로, 나중에 구현 시 BI v 4.1.2 사양서만 참조하면 됨
1개 Git 커밋으로 원자적 변경
```bash
git commit -m "docs(bi): BI specification v4.1.2 - 자산유형별 파라미터 업데이트"
```
## 💬 개발자를 위한 AI 활용 팁
### ✅ 효과적이었던 것
1. 문서부터 시작하세요
❌ 나쁜 순서: 코드 작성 → 문서 작성 (나중에)
✅ 좋은 순서: 문서 작성 → 코드 생성 → 문서 업데이트
이유:
- 복잡한 도메인 로직은 코드보다 문서로 검증하기 쉬움
- Claude는 문서 읽기/쓰기에 강함
다음 할 일
-모바일 앱 UI 화면구성과 백엔드 관계형 데이타베이스 테이블 실시간 모니터링
