investment-decision-factory 개선 개발계획¶
작성일: 2026-05-08
기준 문서: docs/methodology/investment-decision-factory-improvement-axes-2026-05-08.md
목표: 45개 발전 축을 실제 스킬, 데이터팩, 스키마, 검증기, 보고서, 사후학습 루프로 반영하기 위한 개발계획을 세운다.
/goal 사용 결과¶
/goal 도구를 호출했지만, 이 스레드에는 이미 완료된 목표가 남아 있어 새 목표 생성이 차단되었다. 따라서 새 goal 객체는 만들지 못했다. 이번 문서는 다음 작업 목표를 기준으로 작성했다.
방금 작성한 45개 발전 축 보고서를 바탕으로
investment-decision-factory스킬 개선 개발계획을 단계별로 설계하고, 구현 순서, 파일 영향, 검증 기준, 리스크를 문서화한다.
개발 판단¶
이 개선은 한 번에 45개 항목을 SKILL.md에 더 붙이는 방식으로 하면 실패할 가능성이 높다. 그렇게 하면 문서는 커지지만 실제 실행은 바뀌지 않는다. 핵심은 발전 축을 아래 다섯 가지 계약으로 동시에 잠그는 것이다.
- 스킬 본문과 참조 문서
- 데이터팩과 원천 증거 저장
- JSON schema와 scaffold
- validator, guard, 감사 스크립트
- 최종 보고서와 판단 로그
따라서 개발계획은 "문서 보강"이 아니라 "계약 기반 제품 개선"으로 잡아야 한다.
목표 아키텍처¶
flowchart TD
A["Universe and portfolio input"] --> B["Entity master and source registry"]
B --> C["Evidence packet v2"]
C --> D["Fundamental engine"]
C --> E["Quant alpha engine"]
C --> F["Entry and execution engine"]
C --> G["Portfolio risk and tax EV engine"]
D --> H["Result schema v2"]
E --> H
F --> H
G --> H
H --> I["Strict validators and final guard"]
I --> J["Decision report with claim evidence bridge"]
J --> K["Decision journal and post-trade learning"]
K --> E핵심 구조는 단순하다. build_data_pack.py가 원천 근거를 모으고, 분석 엔진들이 같은 evidence_packet v2를 읽고, 결과는 result.schema.json에 잠기며, 최종 보고서는 claim 단위로 근거와 숫자 영향을 보여줘야 한다.
개발 에픽¶
45개 축은 12개 개발 에픽으로 묶어 진행한다.
| 에픽 | 포함 축 | 개발 목표 | 주요 파일 |
|---|---|---|---|
| E0 | 전체 | 현 상태를 깨지 않도록 baseline run, fixture, 계약 버전을 먼저 만든다 | schemas/*, validate_run.py, audit_validate_factory_run.py |
| E1 | 1, 2, 6, 45 | SKILL.md를 얇게 유지하고 세부 계약은 참조 문서로 분리한다 |
SKILL.md, references/process-contract.md |
| E2 | 1, 2, 3, 6 | entity master, source registry, freshness, 원문성 등급을 만든다 | build_data_pack.py, 신규 references/data-contract-v2.md |
| E3 | 3, 4, 5, 7 | 공시, XBRL, 실적 원문, transcript, 추정치 변화, 대체데이터 adapter를 붙인다 | build_data_pack.py, 신규 data adapters |
| E4 | 8-15 | 사업모델, 해자, ROIC, owner FCF, 경영진, variant view를 구조화한다 | references/fundamental-engine.md, evidence_packet.schema.json |
| E5 | 16-22 | 팩터, residual alpha, 백테스트, walk-forward, 확률 보정을 만든다 | 신규 build_alpha_dataset.py, backtest_factory.py |
| E6 | 23-29 | 추세 구조, 거래량, ATR stop, 유동성, 체결비용, 이벤트 갭 리스크를 계산한다 | chart-trend-gate.md, tax_ev_calculator.py, validate_run.py |
| E7 | 30-37 | downside, 상관, 팩터 쏠림, CVaR, 세후 EV, sizing, optimizer를 목표비중에 연결한다 | tax_ev_calculator.py, 신규 portfolio_risk_sizer.py |
| E8 | 38-41 | 매수 논리, 매도 논리, 반론, 확신도, 언어 가드를 claim 단위로 연결한다 | generate_final_decision_report.py, final_answer_guard.py |
| E9 | 42, 43 | 판단 로그, superseded, post-trade attribution을 만든다 | 신규 decision_journal.py, run_quality_iteration_loop.py |
| E10 | 40, 44 | 전문가 페르소나의 독립성과 반론 품질을 검증한다 | expert_persona_run_reviewer.py |
| E11 | 전체 | S&P500, KOSPI 후보군 같은 대형 universe에서 반복 검증한다 | run_six_agent_factory.py, audit_run_batch.py, audit_compare_runs.py |
단계별 실행계획¶
0단계. 기준선 고정¶
먼저 지금 시스템의 통과 기준을 고정한다. 개선 중에 기존 기능이 조용히 깨지는 일을 막는 단계다.
| 작업 | 산출물 | 통과 기준 |
|---|---|---|
| 현재 strict run 샘플 2-3개 확보 | process_test/baseline_* |
기존 통과 run과 실패 run을 모두 보관 |
| 주요 schema 필드 목록화 | contract_version=idf-v1 |
결과, evidence, blocker, red-team 필드가 문서화됨 |
| fixture universe 생성 | 한국 5종목, 미국 5종목, 오류 유발 3종목 | 빠른 회귀테스트가 가능함 |
| 감사 스크립트 기준선 저장 | baseline audit report | 개선 전후 차이를 비교할 수 있음 |
이 단계에서는 투자판단 품질을 높이려 하지 않는다. 먼저 "무엇이 깨졌는지 알 수 있는 상태"를 만든다.
1단계. 계약 v2 골격¶
45개 축을 바로 구현하지 말고, 먼저 v2 계약을 세운다.
| 작업 | 추가할 내용 | 수정할 내용 | 줄일 내용 | 검증 |
|---|---|---|---|---|
contract_version 도입 |
idf-v2 |
모든 결과 JSON에 버전 포함 | 버전 없는 결과 허용 | validator가 버전 누락 시 실패 |
| evidence packet v2 설계 | entity, source, claim, freshness, proxy 상태 | evidence_packet.schema.json |
keyword pass | 필수 원천 없는 claim은 proxy_only |
| result schema v2 설계 | alpha, fundamental, entry, portfolio, claim bridge | result.schema.json |
additionalProperties 과다 허용 |
핵심 필드 누락 시 strict 실패 |
| blocker 분류 확장 | source, data, calculation, risk, report blocker | blocker-state-machine.md |
애매한 incomplete | blocker별 repair action 필수 |
완료 기준은 간단하다. 새 분석 기능이 없어도 v2 필드가 비어 있으면 어디서 실패하는지 정확히 보여야 한다.
2단계. 데이터 원천 v2¶
수익 확률을 높이는 첫 실질 개선은 데이터다. 좋은 판단보다 먼저 좋은 입력이 필요하다.
| 작업 | 구현 방향 | 통과 기준 |
|---|---|---|
| entity master | ticker, CIK, FIGI, LEI, ISIN, 거래소, 도메인, 앱 ID를 연결 | ticker만 있는 해외주식은 source blocker |
| source registry | source tier, retrieved_at, content_hash, license_status 저장 | 원천별 freshness 계산 |
| SEC/XBRL adapter | submissions, companyfacts, accession raw 저장 | SEC 값과 vendor 값 차이 flag |
| 실적 원문 adapter | earnings release, IR deck, transcript, Q&A topic | 실적 claim은 원문 evidence id 필요 |
| 추정치 변화 adapter | 7/30/90일 revision, breadth, dispersion | 목표가만 있고 revision 없으면 낮은 근거 등급 |
| 대체데이터 adapter | 웹, 앱, 가격 페이지, 채용, 리뷰 | 업종별 적용 가능 여부와 편향 경고 |
주의할 점은 무료 데이터로 시작하되 adapter 인터페이스는 유료 데이터도 꽂을 수 있게 만드는 것이다. 처음부터 유료 데이터 의존으로 설계하면 재현성이 약해진다.
3단계. 펀더멘털 엔진¶
이 단계는 "왜 이 회사가 더 좋은 기업인가"를 구조화한다.
| 모듈 | 핵심 필드 | 검증 |
|---|---|---|
| 사업모델 | revenue_formula, segment_profit_pool, price_volume_mix |
segment 매출과 회사 보고값 대조 |
| 단위경제 | 업종별 unit KPI | 업종 template 없는 종목은 not_applicable_reason 필요 |
| 해자 | moat_type, moat_evidence, moat_decay_risk |
peer 대비 마진, 점유율, 유지율 중 최소 1개 근거 |
| ROIC | roic_wacc_spread, incremental_roic |
5년 median과 최근값 모두 계산 |
| owner FCF | owner_earnings, maintenance_capex, sbc_burden |
reported FCF와 차이를 표시 |
| variant view | consensus_belief, variant_view, variant_trigger |
consensus와 다른 점이 없으면 높은 확신 금지 |
최종 보고서에는 회사 소개가 아니라 "매출이 어디서 나고, 왜 유지되며, 무엇이 바뀌면 틀리는지"가 보여야 한다.
4단계. 가격, 체결, 위험 엔진¶
좋은 회사도 나쁜 가격과 나쁜 크기로 사면 좋은 투자가 아니다.
| 영역 | 구현할 내용 | 통과 기준 |
|---|---|---|
| 추세 구조 | HH/HL, LH/LL, failed breakout, reclaim, retest | buy_now는 구조 라벨 필수 |
| 변동성 | ATR, realized vol percentile, vol regime | stop이 ATR과 무관하면 경고 |
| 손익비 | bull/base/bear target과 stop의 R multiple | 신규 매수는 원칙적으로 R 2 이상 |
| 유동성 | ADV, 주문/ADV, spread, market impact | 비용 차감 후 alpha가 음수면 보류 |
| 이벤트 | 실적, FOMC, FDA, 규제, gap risk | 10거래일 내 핵심 이벤트면 size cap |
| 옵션과 수급 | IV percentile, put/call, short interest | squeeze성 반등은 별도 라벨 |
이 단계부터 BUY와 WEIGHT_UP은 단순 EV가 아니라 체결 가능한 기대값이어야 한다.
5단계. 세후 EV와 포트폴리오 sizing v2¶
기존 대원칙인 세후 기대값 우위를 더 정교하게 만든다.
| 작업 | 구현 방향 | 통과 기준 |
|---|---|---|
| 시나리오별 세금 | bull/base/bear 각각 세금, 손실상계, 공제, 환전비용 계산 | 최종 EV와 시나리오 합계 검산 |
| downside 확률 | -10/-20/-30% 도달확률과 예상손실 | 평균 EV와 별도 표시 |
| 상관관계 | 상위 보유, 시장, 섹터, 테마와 상관 | 고상관 추가매수는 haircut |
| CVaR | expected shortfall과 stress cases | tail risk 대비 보상 부족 시 size 축소 |
| sizing | Kelly, volatility, drawdown, liquidity, confidence cap | 최종 비중은 보수적 최소값 |
| optimizer | 세후 EV 최대화와 리스크 제약 동시 적용 | marginal risk contribution 표시 |
여기까지 와야 "수익률 극대화"와 "리스크 관리"가 충돌하지 않는다. 리스크는 독립 매도 사유가 아니라 세후 EV와 목표비중 산식 안에 들어가야 한다.
6단계. 계량 알파 검증¶
이 단계는 가장 중요하지만 처음부터 하면 늦어진다. 데이터와 계약이 먼저 있어야 의미가 있다.
| 작업 | 구현 방향 | 통과 기준 |
|---|---|---|
| alpha dataset | point-in-time feature와 forward return label 저장 | look-ahead bias 검사 |
| 팩터 노출 | value, quality, momentum, low vol, size, beta | 섹터 중립 z-score 산출 |
| residual alpha | market, sector, style premia 제거 | raw rank와 residual rank 분리 |
| backtest | 거래비용, 세금, 슬리피지 포함 | top-minus-bottom spread와 MDD |
| walk-forward | train, validation, test를 굴림 | 파라미터 안정성 기준 |
| 확률 보정 | Brier score, calibration curve | 확률이 실제 빈도와 크게 어긋나면 confidence haircut |
이 단계의 목표는 예쁜 모델이 아니다. "우리가 쓰는 신호가 실제로 forward return을 개선했는지"를 계속 묻는 장치다.
7단계. 보고서와 감사 v2¶
마지막에는 사용자에게 보여주는 결론을 바꾼다.
| 작업 | 구현 방향 | 통과 기준 |
|---|---|---|
| claim evidence bridge | 모든 핵심 주장에 claim id와 evidence id 연결 | 투자 액션에 영향 주는 출처 없는 문장 금지 |
| decision bridge | pre-EV, gate contribution, post-EV 표시 | "반영했다"만 있고 숫자 없으면 실패 |
| 반대 논리 | strongest countercase, EV impact, veto 여부 | 빈 리스크 문장 금지 |
| 확신도 | confidence, uncertainty drivers, calibration band | 높은 확신은 더 강한 근거 필요 |
| 언어 가드 | 과장 표현 차단 | "반드시", "확정", "압도적" 등 금지 |
| 실행 표 | 주문 방식, limit, 분할, 실패 시 대안 | 금액만 있는 매수 액션 금지 |
최종 보고서는 설득력이 있어야 하지만, 과장되면 안 된다. "사장님에게 바로 설명할 수 있을 만큼 선명하되, 투자위원회 감사도 통과할 만큼 차갑게"가 기준이다.
8단계. 판단 로그와 학습 루프¶
좋은 시스템은 판단 이후가 더 중요하다.
| 작업 | 구현 방향 | 통과 기준 |
|---|---|---|
| decision journal | decision id, supersedes, changed fields, change reason | 새 EV와 과거 판단 충돌 시 자동 superseded |
| monitoring triggers | 가격, 실적, 뉴스, 환율, thesis KPI | 재검토 조건 없는 BUY 금지 |
| post-trade attribution | ¼/12주 수익률, MAE, signal PnL | 추천 후 성과가 모델 학습으로 돌아감 |
| replay audit | 과거 실패 사례 재실행 | 같은 오류 반복 시 gate 강화 |
이 단계가 들어가야 스킬이 매번 새로 똑똑한 척하는 도구가 아니라, 실제로 경험을 축적하는 투자판단 시스템이 된다.
첫 스프린트 제안¶
첫 스프린트는 욕심내지 말고 "v2 계약과 데이터 품질 차단"에 집중한다.
| 순서 | 작업 | 이유 |
|---|---|---|
| 1 | contract_version=idf-v2와 fixture run 만들기 |
이후 모든 변경을 비교 가능하게 만든다 |
| 2 | evidence_packet.schema.json에 entity, source, freshness, proxy 상태 추가 |
제목 뉴스나 keyword pass를 막는다 |
| 3 | result.schema.json에 claim bridge, risk sizing, entry quality 필드 추가 |
보고서와 검증기를 같은 필드로 묶는다 |
| 4 | validate_run.py에 필수 필드 누락, stale, proxy_only 차단 추가 |
문서에만 있는 기준을 실제 실패로 만든다 |
| 5 | final_answer_guard.py에 출처 없는 투자 주장 차단 추가 |
최종 답변 품질을 가장 빨리 끌어올린다 |
| 6 | 최종 보고서에 decision bridge 표 추가 | 사용자 불만이 컸던 "왜 사야 하는가"를 숫자로 보여준다 |
첫 스프린트의 성공 기준은 신규 데이터 adapter가 많은 것이 아니다. BUY 결론을 내려면 어떤 데이터와 근거가 필요한지 시스템이 강제로 요구하는 상태가 되는 것이다.
구현 순서의 이유¶
| 먼저 하지 않을 것 | 이유 |
|---|---|
| S&P500 전체 백테스트부터 시작 | 데이터 계약이 약한 상태에서는 쓰레기 입력으로 과최적화할 위험이 크다 |
| 대체데이터를 한꺼번에 붙이기 | 소스 매핑, 라이선스, 편향 검증이 없으면 거짓 정밀도가 생긴다 |
| SKILL.md에 45개 축을 그대로 붙이기 | context가 비대해지고 실제 실행은 바뀌지 않는다 |
| 전문가 페르소나만 늘리기 | 같은 입력과 같은 검증기를 쓰면 이름만 다른 검토가 된다 |
| 목표비중 cap만 강화 | 리스크 축소가 세후 EV 원칙을 이겨버리는 잘못된 구조가 될 수 있다 |
개발 완료 기준¶
최종적으로 아래 조건을 모두 만족해야 한다.
| 기준 | 완료 조건 |
|---|---|
| 데이터 | 핵심 claim은 원천 evidence id, 기준일, freshness, source tier를 가진다 |
| 펀더멘털 | 사업모델, 해자, ROIC, owner FCF, variant view가 구조형으로 나온다 |
| 계량 검증 | 최소한 후보군 단위 rank IC, backtest, walk-forward 결과를 저장한다 |
| 진입과 체결 | buy_now는 추세 구조, 손익비, 유동성, 이벤트 위험을 통과해야 한다 |
| 포트폴리오 | 목표비중은 세후 EV, 변동성, 상관, CVaR, 유동성 cap을 반영한다 |
| 보고서 | 매수 논리, 매도 논리, 반론, EV 영향, 무효화 조건이 한 표로 이어진다 |
| 감사 | final_answer_guard가 출처 없는 투자 주장과 숫자 없는 반영 표현을 차단한다 |
| 학습 | 결정 로그와 사후 성과가 다음 모델 가중치와 gate 개선으로 돌아간다 |
예상 리스크와 대응¶
| 리스크 | 문제 | 대응 |
|---|---|---|
| context 비대화 | 스킬이 너무 길어져 실제 사용성이 떨어진다 | SKILL.md는 네비게이션만, 세부는 references와 scripts로 분리 |
| 데이터 라이선스 | 일부 transcript, revision, 실시간 호가는 유료일 수 있다 | 무료 adapter 우선, 유료 adapter는 선택형 인터페이스 |
| 과최적화 | 백테스트가 좋아 보이지만 미래 성과가 나쁠 수 있다 | walk-forward, holdout, 단순 모델 우선 |
| 거짓 정밀도 | 대체데이터가 있어 보이지만 실제 예측력이 없을 수 있다 | IC와 hit ratio가 없으면 낮은 근거 등급 |
| 실행시간 | S&P500 전체 6-agent가 너무 오래 걸릴 수 있다 | shared data pack, 캐시, 샘플 smoke test, batch audit 분리 |
| 최종결론 지연 | strict gate가 너무 많아 항상 blocked가 될 수 있다 | blocker materiality와 fallback verdict를 명확히 분리 |
| 한국 시장 이식 | SEC/XBRL 중심 구조가 한국에 그대로 맞지 않는다 | DART adapter를 같은 interface로 별도 구현 |
다음 작업 지시로 바로 바꾸면¶
실제 구현으로 들어갈 때는 다음 순서가 가장 안전하다.
idf-v2계약과 fixture를 만든다.evidence_packet.schema.json,result.schema.json,validate_run.py,final_answer_guard.py를 먼저 고친다.build_data_pack.py에 entity/source/freshness/proxy 상태를 넣는다.- 최종 보고서에 decision bridge와 claim evidence bridge를 추가한다.
- 한국 5종목, 미국 5종목 smoke test를 통과시킨다.
- 그다음 SEC/XBRL, transcript, estimate revision, fundamental engine, portfolio risk engine 순서로 확장한다.
이 계획대로 가면 이번 개선의 첫 번째 목표는 "더 많은 내용을 말하는 스킬"이 아니라 "근거가 없으면 좋은 말을 못 하게 막는 스킬"이다. 그 위에 알파 검증, 포트폴리오 sizing, 사후학습을 얹어야 수익 확률을 높이는 방향으로 실제 개선이 된다.