통합 설계안: 볼트 300 + 섹터나침반 v3 + 방법론

3개 시스템의 현재 상태 정밀 진단 + 통합 아키텍처 + 구현 로드맵

Part 0: 사전 정리 — 나침반 통합 전 필수 해결 과제

진단 결과, 나침반 통합(Phase 1~3) 진입 전에 반드시 해결해야 할 5대 운영 문제가 확인됨. 이 정리가 선행되지 않으면 vault_bridge 태깅 정확도, 키 정렬, inlinks 품질 모두 저하됨.

0.1 331 중첩폴더 + MOC 중복 정리 (진행 중)

331/331 중첩: 19개 파일이 331 정보기술/331 정보기술/ 이중 폴더에 위치 → 정리
타 섹터 폴더 중첩: 다른 GICS 섹터 폴더가 331 안에 잘못 중첩된 것 → 올바른 위치로 이동
MOC 33건 중복: 동일/유사 MOC가 391과 다른 폴더에 분산 → 중복 해소 후 391로 통합
타이밍: 즉시 (Phase 0)
의존성: vault_bridge 태깅 정확도의 전제 조건 — 폴더 구조가 어긋나면 경로 기반 섹터 추론이 실패

0.2 maturity 56% 백필 (진행 중)

전체 350개 중 198개 노트에 maturity 필드 없음 (56% 미설정)
백필 규칙:
MOC/structure 타입 → evergreen
literature 타입 → growing
나머지 → 본문 길이/inlinks 수로 seed/growing 자동 판정
타이밍: 즉시 (Phase 0)
의존성: vault_flow_health 품질점수 정확도, vault_architect Phase 3 maturity 업그레이드 로직

0.3 태그 표준화 (진행 중)

대소문자 통일: HBM vs hbm, DRAM vs dram → 소문자 기준으로 통일
동의어 한국어 통합: semiconductor vs 반도체, shipbuilding vs 조선 → 한국어 기준 1개로
슬래시 태그 정리: 분석/반도체 같은 슬래시 태그 → 계층 태그 또는 평탄화
1회 사용 태그 정리: 단 1개 노트에만 사용된 태그 → 상위 태그로 병합 또는 삭제
타이밍: 즉시 (Phase 0)
의존성: vault_bridge 키워드 매칭, knowledge_connector 유사도 계산

0.4 insight/judgment 생산 구조 개선 (Phase 1에서)

현재 zk_type 분포가 literature/permanent에 편중 → insight 타입 부족
vault_architect Phase 3에서 zk_type 재라벨링 로직 추가 필요:
본문에 "따라서", "결론", "판단" 등 판단 표현 + 1차 소스 인용 → insight
단순 요약/정리 → literature 유지
literature/permanent → insight 전환 기준 명확화:
독자적 해석이 포함된 노트 = insight
외부 자료 정리만 된 노트 = literature
타이밍: Phase 1 (방법론 추가와 병행)
의존성: 볼트 400 판단 계층으로의 승격 품질

0.5 inlinks 개선 (Phase 2에서)

knowledge_connector가 현재 키워드 자카드 유사도만 사용 → 나침반 하위섹터 개념 없음
개선 방향:
vault_bridge의 compass_subsector 태그를 활용하여 같은 하위섹터 노트 간 연결 제안
크로스섹터 연결 강화: 예) 반도체↔배터리 (소재 공유), 조선↔해운 (수급 연동)
knowledge_connector의 매칭 가중치에 subsector 일치 보너스 (+0.3) 적용
타이밍: Phase 2 (vault_bridge 완성 후)
의존성: vault_bridge.py의 compass-index 생성이 선행되어야 함

Phase 0 완료 기준

[ ] 331 중첩폴더 해소 — find 기준 이중 경로 노트 0개
[ ] MOC 중복 33건 → 단일 정본으로 통합
[ ] maturity 백필 — 미설정 노트 198개 → 0개
[ ] 태그 표준화 — 대소문자/동의어/슬래시/1회 태그 정리 완료
[ ] vault_flow_health 품질점수 재측정 → 개선 확인

Part 1: 현재 상태 정밀 진단

1.1 볼트 300 지식망 — 현황

노트 분포 (총 350개, 19개 폴더):

폴더	노트 수	비고
331 정보기술	113	반도체+디스플레이+SW 혼재
394 방법론	40	14섹터 방법론 + MOC + 기타
391 MOC	40	Map of Content
316 산업재	40	조선+방산+건설 혼재
310 에너지	24	정유+원전+신재생 혼재
370 기술	15	크로스섹터 기술
328 금융	15
373 산업분석	12	크로스섹터
319 경기소비재	10
334 커뮤니케이션	9
나머지 9개	1~4개씩	소재/헬스케어/유틸리티/부동산 등

노트 frontmatter 구조 (실측):

tags: ["nepcon", "sapiens", "기업분석"]
category: "기업"
entities: ["NVDA", "AMD"]
technologies: ["HBM", "DRAM"]
dimensions: ["수급", "밸류에이션"]
zk_type: "insight"
maturity: "evergreen"
source_platform: "nepcon"

문제점: 1. GICS 11섹터 분류의 한계: 반도체 113개 노트가 "331 정보기술"에 전부 묻혀 있음. 조선/방산/원전이 "316 산업재"에 혼재 2. 나침반 하위섹터 태그 부재: frontmatter에 compass_sector, compass_subsector 같은 필드가 없음 3. 방법론과의 연결 없음: 노트가 어떤 방법론의 어떤 축(사이클/지정학/구조적힘)과 관련되는지 표시 없음 4. dimensions 필드 불일치: 볼트의 dimensions(수급/밸류에이션/시장)과 나침반의 3축(price/industry/linkage)이 다른 체계

1.2 섹터나침반 v3 — 현황

17개 섹터 / 108개 하위섹터:

섹터	한글명	하위섹터 예
semiconductor	반도체	memory_dram, memory_hbm, memory_nand, foundry, equipment, materials, fabless_ai, backend_analog, electronic_components, eda_ip, fabless_consumer
display	디스플레이	panel_oled, driver_ic, display_equipment
shipbuilding	조선	LNG선, 컨테이너선, 방산선박, 해양플랜트
shipping_logistics	해운/물류	컨테이너 해운, 벌크, 항만, 물류
energy_refinery	에너지/정유	정유, E&P, LNG, 가스유통
petrochemical	석유화학	기초유분, 합성수지, 합성고무, 특수화학
battery_ev	배터리/EV	upstream_mineral, cathode_anode, electrolyte_separator, cell_manufacturing, ev_oem, charging_infra, recycling_circular
defense_space	방산/우주	무기체계, 우주발사체, 위성, 방산전자
nuclear_power	원전/전력인프라	원자로, 핵연료, 전력기기, 송배전
bio_healthcare	바이오/헬스케어	CDMO, 바이오시밀러, 신약, 의료기기
robot_auto	로봇/자율주행	산업로봇, 서비스로봇, 자율주행, 센서/LiDAR
consumer_discretionary	경기소비재	자동차OEM, 부품, 의류, 면세/여행
consumer_staples	필수소비재	식품, 음료, 생활용품, 농업
financials	금융	은행, 증권, 보험, 부동산/REITs
comm_platform	플랫폼/미디어	인터넷플랫폼, 게임, 광고
infra_utilities	인프라/유틸리티	전력, 가스, 수처리, 건설
materials	소재/철강	철강, 비철금속, 시멘트, 특수소재

데이터 파이프라인:

market_indicator (07:05) → 32개 지표 수집
    ↓
signal_synthesizer (07:35) → 3축 시그널 합성 (price/industry/linkage)
    ↓
analyst_fundamental (07:38) → LLM 사이클/시그널 분석 (14개 AF 키)
    ↓
sector_research (17:30) → 6단계 통합 집계 (10개 SR 키)
    ↓
linkage_validator (주 1회) → 6-Stage 정량 검증
    ↓
sector_compass.py → 웹앱 렌더링

키 불일치 현황:

시스템	키 이름	섹터 수	비고
나침반 (_SUBSECTORS)	battery_ev, bio_healthcare, comm_platform 등	17	기준
AF (analyst_fundamental)	battery_ev, consumer_retail, comm_platform 등	14	display/shipping_logistics/consumer_discretionary 누락
SR (sector_research)	battery, healthcare, comm_services 등	10+	레거시 키 사용
signal_synthesizer	consumer_retail, consumer_staples 등	17	거의 일치
linkage_validator	battery, consumer_disc, comm_services 등	16	레거시 키 혼재

매핑 레이어 현황 (sector_data.py): - _LEGACY_TO_COMPASS: battery→battery_ev, healthcare→bio_healthcare 등 6개 - _COMPASS_TO_SR: battery_ev→battery 등 역매핑 5개 - _COMPASS_TO_AF: consumer_discretionary→consumer_retail 1개

1.3 방법론 14섹터 — 현황

현재 14개 방법론 파일:

파일명	나침반 섹터 대응	상태
방법론-semiconductor.md	semiconductor	O
방법론-shipbuilding.md	shipbuilding	O
방법론-energy.md	energy_refinery	O
방법론-battery_ev.md	battery_ev	O
방법론-materials.md	materials	O
방법론-financials.md	financials	O
방법론-consumer_disc.md	consumer_discretionary	O
방법론-consumer_staples.md	consumer_staples	O
방법론-healthcare.md	bio_healthcare	O
방법론-comm_services.md	comm_platform	O
방법론-industrials.md	infra_utilities (부분)	불완전
방법론-info_tech.md	comm_platform (부분)	중복
방법론-utilities.md	infra_utilities (부분)	불완전
방법론-real_estate.md	financials (통합됨)	레거시

누락된 나침반 섹터 (3개): 1. display (디스플레이) — 방법론 없음 2. shipping_logistics (해운/물류) — 방법론 없음 3. defense_space (방산/우주) — 방법론 없음 4. nuclear_power (원전/전력인프라) — 방법론 없음 5. robot_auto (로봇/자율주행) — 방법론 없음

실제 누락은 5개. 그러나 일부는 기존 방법론에서 부분 커버: - defense_space: 조선 방법론에 일부 언급 - nuclear_power: 에너지/유틸리티 방법론에 일부 언급 - robot_auto: 반도체/IT 방법론에 일부 언급

sector_schemas.py도 14개만 정의. 나침반 17개와 3~5개 차이.

방법론 6축 구조 (각 파일 공통): 1. 사이클 모델: 5단계(TROUGH/EARLY_RECOVERY/EXPANSION/PEAK/OVERHEATING) + 전환 규칙 2. 지정학 벡터: 섹터별 2~4개, 방향 규칙 + 데이터 프록시 3. 구조적 힘: 2~3개 장기 요인, bull/bear 시나리오 4. 정책 프레임워크: 공식 소스 URL + 체크 빈도 5. Moat 레이어: 섹터 내 지배적 해자 원천 + 기업별 Wide/Narrow/None 분류 기준 6. 분석 출처: 뉴스 소스 8~10개 + 애널리스트 1차 소스 5~8개

Part 2: 갭 분석 — 3개 시스템 교차 진단

2.1 볼트 → 나침반 방향 (지식이 시그널로 흐르지 않음)

현재: 볼트 350개 노트의 인사이트가 나침반에 전혀 반영되지 않음. - 예: "엔비디아 GTC Preview" 노트(HBM/AI 반도체 인사이트)가 있어도, 나침반의 semiconductor 섹터 화면에서 이 노트의 존재를 알 수 없음 - knowledge_connector.py는 키워드 자카드 유사도만 사용하며, 나침반 하위섹터 개념이 없음

갭 크기: 완전 단절. 브릿지 모듈이 전무.

2.2 나침반 → 볼트 방향 (시그널이 지식 검색을 안내하지 않음)

현재: 나침반이 "반도체 회복기, HBM 수요 강세" 시그널을 생성해도, 이걸 보고 볼트에서 HBM 관련 노트를 찾아 읽을 방법이 없음. - vault_context_builder가 있지만 나침반 시그널을 입력으로 사용하지 않음

갭 크기: 완전 단절.

2.3 방법론 ↔ 나침반 (프레임워크와 실시간 데이터의 단절)

현재: - 방법론의 사이클 모델과 나침반의 사이클 위치(cycle_position)는 같은 개념을 다른 방식으로 표현 - 방법론: "DRAM 현물가 -70% 정점 → TROUGH" (정적 규칙) - 나침반: "회복기 (메모리 강세 지속, 비메모리 약세 유지)" (LLM 판단) - 이 두 결과를 크로스체크하는 메커니즘 없음 - 방법론의 지정학 벡터와 나침반의 linkage 시그널은 같은 힘을 다른 축으로 측정 - 방법론: "미-중 반도체 전쟁 — 규제 강화 시 장비·소재 업체 매출 영향" (정성 규칙) - 나침반: linkage_validator의 IMPACT_TEMPLATES (정량 전파) - 연동 없음 - methodology_assessor.py가 Layer 2 동적 평가를 하지만, 나침반의 signal_synthesizer 결과를 입력으로 쓰지 않음 (웹검색만 의존)

갭 크기: 논리적으로 동일한 개념인데 물리적으로 분리됨. 가장 큰 비효율.

2.4 방법론 ↔ 볼트 (지식이 프레임워크 검증을 받지 않음)

현재: - 볼트 노트가 "에너지 전환 압력"에 대해 다루더라도, 방법론의 구조적 힘 "에너지 전환 압력 [5-15Y]"과 자동 연결되지 않음 - 볼트 노트의 인사이트가 방법론의 bull/bear 시나리오 어디에 해당하는지 표시 없음

갭 크기: 수동으로만 가능. 자동화 전무.

2.5 키 불일치 테이블 (해결 필요한 매핑)

나침반 키	AF 키	SR 키	linkage 키	방법론 sector	상태
semiconductor	semiconductor	semiconductor	semiconductor	semiconductor	OK
display	(없음)	(없음)	display	(없음)	누락
shipbuilding	shipbuilding	shipbuilding	shipbuilding	shipbuilding	OK
shipping_logistics	(없음)	(없음)	shipping_logistics	(없음)	누락
energy_refinery	energy_refinery	energy_refinery	energy_refinery	energy	OK(키차이)
petrochemical	petrochemical	petrochemical	petrochemical	(없음)	방법론 누락
battery_ev	battery_ev	battery	battery	battery_ev	SR 레거시
defense_space	defense_space	(없음)	(없음)	(없음)	대부분 누락
nuclear_power	nuclear_power	(없음)	(없음)	(없음)	대부분 누락
bio_healthcare	bio_healthcare	healthcare	healthcare	healthcare	SR/linkage 레거시
robot_auto	robot_auto	(없음)	(없음)	(없음)	대부분 누락
consumer_discretionary	consumer_retail	consumer_disc	consumer_disc	consumer_disc	3중 불일치
consumer_staples	(없음*)	consumer_staples	consumer_staples	consumer_staples	AF 누락
financials	financials	financials	financials	financials	OK
comm_platform	comm_platform	comm_services	comm_services	comm_services	SR/linkage 레거시
infra_utilities	infra_utilities	(없음)	utilities	utilities+industrials	분산
materials	materials	(없음)	materials	materials	SR 누락

Part 3: 통합 아키텍처 설계

3.1 설계 원칙

매핑 테이블 금지 (아키텍처 문서 명시): 볼트↔나침반 사이에 양방향 매핑 레이어를 만들지 않음
단방향 참조만: 나침반 하위섹터에서 볼트로의 검색 쿼리, 또는 볼트 노트의 compass_sector 태그를 통한 단방향 연결
방법론은 섹터 레벨 유지: 하위섹터 레벨까지 방법론을 세분화하지 않음. 하위섹터는 나침반의 _SUBSECTORS가 담당
LLM 호출 최소화: 태깅은 규칙 기반 우선, LLM은 애매한 경우만
기존 파이프라인 흐름 보존: 새 모듈은 기존 체인에 삽입하되, 기존 모듈 수정 최소화

3.2 통합 데이터 모델

방법론 17 (정적 프레임워크)
  = sector_schemas.py + 방법론-{sector}.md
  = 사이클 모델 / 지정학 벡터 / 구조적 힘 / 정책 / Moat 레이어 / 출처
       │
       │ methodology_assessor.py (Layer 2 동적 평가, 주 1회)
       ▼
나침반 17/108 (실시간 시그널 + LLM 판단)
  = signal_synthesizer → 3축 시그널
  = analyst_fundamental → 사이클 위치 + 시그널 텍스트
  = sector_research → 6단계 통합 판단
  = linkage_validator → 전후방 정량 검증
  = _MOAT_ANALYSIS (sector_data.py) → 17섹터 정성 해자 분석
       │                              moat_scorer.py → 기업별 정량 스코어 (주 1회)
       │
       │ [NEW] vault_bridge.py (규칙 기반 태깅 + 검색)
       ▼
볼트 300 지식망 (축적된 지식)
  = 350+ 노트, GICS 11섹터 폴더 구조
  = frontmatter: tags, category, entities, technologies
       │
       │ [기존] knowledge_connector.py (강화)
       ▼
볼트 400 판단 (최종 투자 판단)
  = 400 판단/430 Moat/ → Moat 등급 + Fair Value (예정)

3.3 핵심 신규 컴포넌트: vault_bridge.py

역할: 볼트 노트 ↔ 나침반 하위섹터 간 양방향 검색 브릿지 (매핑 테이블 없이)

방식 A — 노트 → 나침반 방향 (태깅):

# vault_bridge.py의 핵심 로직 (pseudo-code)

COMPASS_KEYWORDS = {
    "semiconductor": {
        "memory_dram": ["DRAM", "DDR5", "DDR4", "메모리", "삼성전자 메모리"],
        "memory_hbm": ["HBM", "HBM3", "HBM4", "광대역메모리"],
        "memory_nand": ["NAND", "SSD", "3D NAND", "낸드"],
        "foundry": ["파운드리", "TSMC", "삼성 파운드리", "첨단공정"],
        "equipment": ["ASML", "AMAT", "반도체 장비", "EUV"],
        "fabless_ai": ["엔비디아", "NVIDIA", "AI칩", "GPU", "AI 반도체"],
        ...
    },
    "shipbuilding": {
        "lng_carrier": ["LNG선", "LNG운반선", "가스선"],
        "container": ["컨테이너선", "SCFI"],
        "tanker": ["탱커", "VLCC", "수에즈막스"],
        "naval": ["구축함", "잠수함", "함정", "해군"],
        ...
    },
    ...
}

def tag_note(note_path: Path) -> dict:
    """노트의 frontmatter + 본문에서 나침반 섹터/하위섹터 추론."""
    content = note_path.read_text()
    # 1. entities 필드 확인 (NVDA → fabless_ai)
    # 2. technologies 필드 확인 (HBM → memory_hbm)
    # 3. 본문 키워드 매칭
    # 4. 결과: {"compass_sectors": ["semiconductor"], "compass_subsectors": ["memory_hbm", "fabless_ai"]}

태깅 결과는 frontmatter에 추가하지 않음 (볼트 쓰기 규칙: 지식 내용 = 사람만). 대신 별도 인덱스 파일에 저장:

memory/vault-compass-index/index.json
{
    "notes": {
        "300 지식망/331 정보기술/260313_sapiens_엔비디아-GTC-Preview.md": {
            "compass_sectors": ["semiconductor"],
            "compass_subsectors": ["fabless_ai", "memory_hbm"],
            "confidence": 0.92,
            "matched_by": ["entities:NVDA", "technologies:HBM", "body:엔비디아"]
        },
        ...
    },
    "generated_at": "2026-03-21",
    "total_notes": 350,
    "tagged_notes": 280,
    "coverage_pct": 80.0
}

방식 B — 나침반 → 노트 방향 (검색):

def search_vault_for_sector(sector: str, subsector: str = None) -> list[dict]:
    """나침반 섹터/하위섹터에 관련된 볼트 노트 검색."""
    # 1. vault-compass-index에서 해당 섹터로 태깅된 노트 필터
    # 2. 관련성 점수 순 정렬
    # 3. 최근 수정일 가중치
    # 결과: [{"path": ..., "title": ..., "relevance": 0.92, "subsectors": [...]}]

3.4 방법론 17섹터 확장

확장 대상 5개 + 매핑 조정 2개:

신규/조정	파일명	sector_schemas.py 키	비고
신규	방법론-display.md	display	OLED/LCD/DDI 사이클
신규	방법론-shipping_logistics.md	shipping_logistics	해운 운임 사이클 (조선과 구분)
신규	방법론-defense_space.md	defense_space	방산 수주/지정학
신규	방법론-nuclear_power.md	nuclear_power	원전 건설 사이클/탈탄소
신규	방법론-robot_auto.md	robot_auto	로봇/자율주행 기술 채택
조정	방법론-industrials.md → 흡수	infra_utilities로 통합	나침반 키에 맞춤
조정	방법론-real_estate.md → 흡수	financials에 병합	나침반 키에 맞춤

하위섹터 레벨 방법론은 만들지 않는 이유: - 나침반의 108개 하위섹터 각각에 방법론을 쓰면 108개 파일 관리 = 유지보수 지옥 - 대신 방법론의 사이클 모델에 하위섹터별 차이를 "참고 노트"로 기술 - 예: 반도체 방법론에 "DRAM/HBM/NAND 각각의 사이클 특성은 나침반 _SUBSECTORS의 cycle_independence 필드 참조" 한 줄 추가

3.5 methodology_assessor.py 강화 — 나침반 데이터 주입

현재: methodology_assessor.py는 웹검색으로만 현재 데이터를 수집 개선: 나침반의 기생성 데이터를 LLM 프롬프트에 주입

# methodology_assessor.py 개선 (pseudo-code)

def _build_assessment_prompt(sector: str, schema: SectorAnalysisSchema) -> str:
    # 기존: 웹검색 결과만
    # 개선: 나침반 데이터 3종 추가 주입

    # 1. signal_synthesizer 결과
    signals = load_json_safe(MEMORY / "sector-signals" / "latest.json")
    sector_signals = signals.get("sectors", {}).get(sector, {})

    # 2. analyst_fundamental 결과
    af = load_json_safe(MEMORY / "analyst-fundamental" / "latest.json")
    af_key = COMPASS_TO_AF.get(sector, sector)
    af_data = af.get("industries", {}).get(af_key, {})

    # 3. linkage_validator 결과 (해당 섹터 관련)
    lv = load_json_safe(MEMORY / "linkage-validation" / "latest.json")
    relevant_verdicts = [v for v in lv.get("linkage_verdicts", [])
                         if v["source"] == sector or v["target"] == sector]

    # 4. 볼트 관련 노트 (vault_bridge 활용)
    vault_notes = search_vault_for_sector(sector)[:5]

    prompt = f"""
    ## 기존 나침반 시그널 (signal_synthesizer)
    {json.dumps(sector_signals, ensure_ascii=False, indent=2)}

    ## 현재 사이클 위치 (analyst_fundamental)
    사이클: {af_data.get('cycle_position', 'N/A')}
    시그널: {af_data.get('signals', [])}

    ## 연결고리 검증 결과 (linkage_validator)
    {json.dumps(relevant_verdicts[:5], ensure_ascii=False, indent=2)}

    ## 볼트 관련 노트 (최근 5건)
    {chr(10).join(f"- {n['title']} ({n['date']})" for n in vault_notes)}

    ## 웹검색 결과
    {web_search_results}
    """
    return prompt

이렇게 하면 methodology_assessor의 LLM이 나침반의 정량 데이터와 볼트의 인사이트를 함께 보고 평가할 수 있음.

3.6 knowledge_connector.py 강화 — 나침반 하위섹터 활용

현재: 자카드 유사도 기반 키워드 매칭만 개선: vault_bridge의 나침반 태그를 활용한 정밀 매칭

# knowledge_connector.py 강화 (pseudo-code)

def enhanced_matching(discovery: dict, vault_notes: list) -> list[dict]:
    """나침반 하위섹터를 활용한 정밀 매칭."""

    # 1. 발견(discovery)의 나침반 태그 추론
    discovery_sectors = tag_text(discovery["title"] + " " + discovery["summary"])

    # 2. vault-compass-index에서 같은 하위섹터 노트 필터
    same_subsector_notes = [n for n in vault_notes
                            if set(n["compass_subsectors"]) & set(discovery_sectors["subsectors"])]

    # 3. 기존 키워드 매칭 + 하위섹터 매칭 가중 합산
    # subsector 일치 = 유사도 +0.3 부스트

    return ranked_matches

3.7 웹앱 통합 표시 — 섹터나침반 페이지 확장

현재 섹터 상세 페이지: - 사이클 위치 + 시그널 - 전후방 연결 (linkage) - 하위섹터 목록 + 종목

추가할 3개 섹션:

<!-- sector_compass.html 확장 -->

<!-- 섹션 1: 방법론 프레임워크 -->
<div class="methodology-panel">
    <h3>분석 프레임워크</h3>
    <div class="cycle-model">
        <!-- sector_schemas.py에서 현재 사이클 단계의 특성/밸류에이션 접근 표시 -->
        <p>현재 단계: EARLY_RECOVERY</p>
        <p>밸류에이션: EV/EBITDA 8~12x, 회복 사이클 선취</p>
        <p>전환 신호: 컨트랙트 가격 인상 → EXPANSION 진입</p>
    </div>
    <div class="geopolitics">
        <!-- 지정학 벡터 요약 -->
        <p>미-중 반도체 전쟁: 규제 강화 모니터링 중</p>
    </div>
</div>

<!-- 섹션 2: 방법론 ↔ 나침반 교차 검증 -->
<div class="cross-validation">
    <h3>사이클 교차 검증</h3>
    <table>
        <tr><th>소스</th><th>판단</th><th>일치</th></tr>
        <tr><td>방법론 규칙</td><td>EARLY_RECOVERY (DRAM반등+HBM수주)</td><td>-</td></tr>
        <tr><td>AF LLM 판단</td><td>회복기</td><td>O</td></tr>
        <tr><td>SR 6단계</td><td>매수</td><td>O</td></tr>
    </table>
</div>

<!-- 섹션 3: 볼트 관련 노트 -->
<div class="vault-notes">
    <h3>관련 지식 노트 (최근 5건)</h3>
    <ul>
        <li><a href="obsidian://open?vault=knowledge&file=...">엔비디아 GTC Preview</a> (2026-03-13) — HBM, AI반도체</li>
        <li><a href="...">SK하이닉스 HBM 매출 전망</a> (2026-03-10) — HBM</li>
    </ul>
</div>

3.8 데이터 흐름 통합 아키텍처 (최종)

                    ┌─────────────────────────────┐
                    │   볼트 300 지식망 (350+ 노트)   │
                    │   GICS 11 폴더 (변경 없음)      │
                    └──────────┬──────────────────┘
                               │
                    vault_bridge.py (태깅+검색)
                    규칙 기반 키워드 → compass_sector/subsector
                    인덱스: memory/vault-compass-index/
                               │
          ┌────────────────────┼─────────────────────┐
          │                    │                      │
          ▼                    ▼                      ▼
┌─────────────────┐ ┌─────────────────────┐ ┌─────────────────┐
│  방법론 17       │ │  나침반 17/108       │ │  knowledge      │
│  sector_schemas │ │  signal_synthesizer  │ │  connector      │
│  .py + .md      │ │  analyst_fundamental │ │  (강화)         │
│                 │ │  sector_research     │ │                 │
│  Layer 1: 정적  │ │  linkage_validator   │ │  subsector      │
│  Layer 2: 동적  │ │                      │ │  매칭 부스트    │
└────────┬────────┘ └──────────┬──────────┘ └────────┬────────┘
         │                     │                      │
         │  methodology_assessor.py                   │
         │  (나침반 데이터 주입)                        │
         ├─────────────────────┤                      │
         │                     │                      │
         ▼                     ▼                      ▼
┌──────────────────────────────────────────────────────────────┐
│                 sector_compass.py 웹앱                       │
│  기존: 나침반 시그널 + 하위섹터 + 종목                         │
│  추가: 방법론 프레임워크 + 교차검증 + 볼트 노트 목록            │
└──────────────────────────────────────────────────────────────┘
         │
         ▼
┌──────────────────────┐
│   400 판단 (최종)     │
│   analyst에게 3중     │
│   컨텍스트 제공       │
└──────────────────────┘

Part 4: 방법론 ↔ 나침반 실시간 연결 상세

4.1 사이클 모델 ↔ 사이클 위치 자동 연동

현재 독립적으로 작동하는 두 시스템:

항목	방법론 (Layer 1)	나침반 (AF)
사이클 판단	정적 규칙 (전환 규칙)	LLM 동적 판단
데이터	없음 (규칙만)	실시간 지표 + 시그널
출력	CyclePhaseSpec	cycle_position 문자열
밸류에이션	단계별 접근법 텍스트	없음

연동 설계:

# cycle_crosscheck.py — 사이클 교차 검증 모듈

def crosscheck_cycle(sector: str) -> dict:
    """방법론 전환 규칙과 나침반 AF 판단을 교차 검증."""

    # 1. 방법론의 전환 규칙 적용 (규칙 기반)
    schema = SECTOR_ANALYSIS_SCHEMAS[sector]
    indicators = load_current_indicators(sector)
    rule_based_phase = apply_transition_rules(schema.cycle_model, indicators)

    # 2. 나침반 AF의 LLM 판단
    af_data = load_af_data(sector)
    af_phase = parse_phase(af_data.get("cycle_position", ""))

    # 3. 교차 검증
    match = rule_based_phase == af_phase

    # 4. 불일치 시 근거 생성
    if not match:
        discrepancy = {
            "rule_says": rule_based_phase,
            "af_says": af_phase,
            "rule_evidence": explain_rule_decision(schema, indicators),
            "af_evidence": af_data.get("signals", []),
            "recommendation": "AF 판단 우선, 규칙 재검토 필요"
        }

    return {
        "sector": sector,
        "rule_phase": rule_based_phase,
        "af_phase": af_phase,
        "aligned": match,
        "valuation_guidance": schema.cycle_model.phases[rule_based_phase].valuation_approach,
        "discrepancy": discrepancy if not match else None
    }

apply_transition_rules 구현은 방법론 md 파일의 전환 규칙을 정량화해야 함: - "HBM 솔드아웃 + DRAM 현물가 반등 → TROUGH→EARLY_RECOVERY" - → signal_synthesizer의 price_signals에서 DDR5 z-score > 0 + AF의 HBM 솔드아웃 언급 체크

4.2 지정학 벡터 ↔ 전후방 영향 통합

현재: - 방법론: GeopoliticalVector에 direction_rule + data_proxies 정의 - 나침반: IMPACT_TEMPLATES에 (source, target) → {up/down 문구} 정의 - 겹치는 부분이 있으나 구조가 다름

연동 설계: 방법론의 지정학 벡터를 signal_synthesizer의 입력으로 사용하지 않음. 대신:

methodology_assessor가 지정학 벡터를 평가할 때, 나침반의 linkage 시그널을 참고 컨텍스트로 주입
웹앱에서 방법론의 지정학 벡터와 나침반의 linkage 시그널을 나란히 표시

이유: 지정학 벡터는 정성적 판단이 필요하고, signal_synthesizer는 정량적(z-score 기반). 강제 통합하면 오히려 정확도 하락.

4.3 방법론의 전환 규칙 → signal_synthesizer 임계값

가장 직접적인 연동 가능 지점:

방법론의 전환 규칙에 명시된 수치를 signal_synthesizer의 z-score 임계값 보정에 활용:

# 예: 반도체 방법론의 전환 규칙
# "DRAM 현물가 -70% 정점 → TROUGH"
# "컨트랙트 가격 연속 인상 3회 → EXPANSION 확인"

# signal_synthesizer에서 활용:
METHODOLOGY_THRESHOLDS = {
    "semiconductor": {
        "trough_signal": {"indicator": "DDR5", "condition": "zscore < -2.0"},
        "expansion_signal": {"indicator": "DDR5", "condition": "zscore > 1.5 for 3 consecutive readings"},
    },
    "energy_refinery": {
        "trough_signal": {"indicator": "WTI", "condition": "close < 60"},
        "expansion_signal": {"indicator": "WTI", "condition": "close > 70 and backwardation"},
    },
}

이건 Phase 3(장기)에서 구현. 현재 signal_synthesizer의 z-score 1.0 임계값은 모든 섹터에 동일하게 적용되는데, 방법론의 섹터별 전환 규칙으로 세분화 가능.

Part 4.4: Moat 레이어 — 구조적 vs 사이클적 구분

Moat의 역할: 6번째 분석 축

방법론의 기존 5축(사이클/지정학/구조적힘/정책/출처)은 "시장 환경이 어떻게 변하는가"를 다룬다. Moat 축은 "이 기업이 그 환경 속에서 초과수익을 지속 가능한가"를 추가로 답한다.

구조적(Moat) vs 사이클적 구분이 필요한 이유: - 사이클적 반등: 업황 회복으로 일시적 이익 증가 → 추세 전환 시 소멸 - 구조적 성장: Moat에 기반한 지속적 초과수익 → 사이클 무관하게 방어

두 요인이 겹칠 때 확신도가 최고조에 달한다.

의사결정 트리: Moat + 사이클 결합

                    사이클 판단
                    ┌─────────────────────────────────────┐
                    │ 저점/회복기          │ 고점/과열기   │
         ┌──────────┼──────────────────────┼──────────────┤
  Wide   │ ★★★★★   강력 매수             │ ★★★         사이클 고려 비중 유지 │
  Moat   │ 이유: Moat 방어 + 사이클 반등  │ 이유: 고평가지만 Moat가 보호      │
  ───────┼──────────────────────────────────┼──────────────┤
  Narrow │ ★★★★    매수 (사이클 중심)    │ ★★          비중 축소           │
  Moat   │ 이유: 반등 폭 있으나 지속성 주의│ 이유: 고평가 + 해자 약해 이중 위험│
  ───────┼──────────────────────────────────┼──────────────┤
  None   │ ★★★     트레이딩 매수          │ ★           회피               │
  Moat   │ 이유: 사이클 반등만, 단기 관점  │ 이유: 고평가 + 해자 없음         │
         └──────────────────────────────────┴──────────────┘

구조적 판단 우선 원칙

Moat 분석이 선행되어야 사이클 분석의 가중치가 결정된다:

Wide Moat 기업: 사이클 고점이어도 보유 관점. DCF 안전마진이 충분하면 유지.
Narrow Moat 기업: 사이클 위치가 포지션을 결정. 저점에서 매수, 고점에서 비중 축소.
None Moat 기업: 사이클 트레이딩만. 장기 포지션 부적합.

Moat 분석이 사이클 해석을 바꾸는 사례

상황	Moat 없을 때 해석	Moat 있을 때 해석
DRAM 가격 반등	"사이클 회복, 단기 매수"	"구조적 HBM 수요 + 사이클 반등 = 중기 포지션"
방산 수주 급증	"지정학 수혜, 수주잔고 증가"	"Wide Moat(진입장벽/IP) + 수주잔고 = 장기 성장"
석유화학 스프레드 개선	"업황 회복"	"None Moat — 사이클 트레이딩, 다음 고점에서 매도 준비"

Part 5: 구현 로드맵

Phase 0: 사전 정리 (즉시)

Part 0 참조. 나침반 통합의 전제 조건.

작업	내용	예상 시간
331 중첩폴더 정리	19개 파일 이동 + 타 섹터 중첩 해소	1시간
MOC 중복 해소	33건 → 단일 정본 통합	2시간
maturity 백필	198개 노트에 maturity 추가	1시간 (스크립트)
태그 표준화	대소문자/동의어/슬래시/1회 태그	2시간

Phase 1: 방법론 확장 + insight 구조 (1~2주)

1.1 방법론 5개 추가 작성

파일	내용 기반	예상 시간
방법론-display.md	OLED 사이클, DDI 수급, IT 겹침 해소	2시간
방법론-shipping_logistics.md	BDI/SCFI 운임 사이클, 조선과 분리	2시간
방법론-defense_space.md	방산 수주 사이클, 지정학 강 의존	2시간
방법론-nuclear_power.md	원전 건설 장기 사이클, 탈탄소	2시간
방법론-robot_auto.md	로봇/자율주행 기술 채택 S-curve	2시간

1.2 sector_schemas.py 5개 추가 + Moat 필드 추가

기존 14개 스키마에 5개 dataclass 인스턴스 추가. 기존 구조 그대로 따름. 각 스키마에 moat_layer 필드 추가:

@dataclass
class MoatLayer:
    dominant_source: str       # switching_costs / intangible_assets / network_effects / cost_advantage / efficient_scale
    secondary_source: str
    sector_comment: str
    wide_moat_signals: list[str]   # Wide 판단 기준 지표
    narrow_moat_signals: list[str]
    moat_risk: str             # 해자를 약화시킬 수 있는 요인

1.3 방법론 키 정렬

현재	변경	파일명 변경
방법론-industrials.md	infra_utilities 통합	방법론-infra_utilities.md
방법론-real_estate.md	financials 병합	삭제 (financials에 REITs 섹션 추가)
방법론-info_tech.md	comm_platform으로 재정렬	방법론-comm_platform.md

결과: 14개 → 17개 방법론 (GICS 레거시 3개 정리 + 신규 5개 + 통합 1개)

1.4 insight/judgment 생산 구조 개선

vault_architect Phase 3에 zk_type 재라벨링 로직 추가
literature/permanent → insight 전환 기준 정의 및 적용
상세: Part 0.4 참조

1.5 MOC 업데이트

MOC-투자방법론-14섹터.md → MOC-투자방법론-17섹터.md 리네이밍 + 클러스터 재구성

Phase 2: 중기 (2~4주)

2.1 vault_bridge.py 개발

COMPASS_KEYWORDS 딕셔너리 작성 (17섹터 x 하위섹터별 10~20개 키워드)
vault-compass-index 생성 크론 등록 (1일 1회, 비LLM)
커버리지 목표: 볼트 300 노트의 80%+ 자동 태깅

2.2 knowledge_connector.py 강화

vault_bridge의 인덱스 활용한 subsector 매칭 부스트
discovery → vault 매칭 시 같은 compass_subsector 노트 우선

2.3 methodology_assessor.py 나침반 데이터 주입

signal_synthesizer + AF + linkage_validator 결과를 프롬프트에 추가
웹검색 의존도 감소 → 비용 절감 + 정확도 향상

2.4 sector_compass.py API 확장

@sector_compass_bp.route("/api/sector-compass/<sector>/vault-notes")
def api_vault_notes(sector):
    """해당 섹터의 관련 볼트 노트 반환."""
    index = load_vault_compass_index()
    notes = [n for n in index["notes"].values()
             if sector in n.get("compass_sectors", [])]
    return jsonify(sorted(notes, key=lambda x: -x["confidence"])[:20])

@sector_compass_bp.route("/api/sector-compass/<sector>/methodology")
def api_methodology(sector):
    """해당 섹터의 방법론 프레임워크 요약 반환."""
    schema = SECTOR_ANALYSIS_SCHEMAS.get(sector)
    if not schema:
        return jsonify({"error": "no schema"}), 404
    return jsonify({
        "cycle_model": asdict(schema.cycle_model),
        "geopolitical_vectors": [asdict(g) for g in schema.geopolitical_vectors],
        "structural_factors": [asdict(s) for s in schema.structural_factors],
    })

2.5 웹앱 UI 추가

sector_compass.html에 방법론/볼트 노트 패널 추가
AJAX로 2.4의 API 호출

2.6 inlinks 개선

knowledge_connector가 나침반 하위섹터 기반으로 연결 제안
크로스섹터 연결 강화 (반도체↔배터리, 조선↔해운 등)
subsector 일치 시 매칭 가중치 +0.3 부스트
상세: Part 0.5 참조

Phase 3: 장기 (1~2개월)

3.1 cycle_crosscheck.py 개발

방법론 전환 규칙의 정량화 (17섹터)
AF 판단과의 자동 교차 검증
불일치 시 텔레그램 알림

3.2 signal_synthesizer 섹터별 임계값

방법론의 전환 규칙에서 추출한 METHODOLOGY_THRESHOLDS
z-score 1.0 일괄 → 섹터별 차등 임계값

3.3 vault_context_builder 나침반 통합

기존 vault_context_builder에 나침반 시그널 컨텍스트 추가
"현재 관심 섹터"를 나침반의 attractiveness 점수로 자동 결정

3.4 analyst_fundamental 17섹터 완전 커버

현재 14개 AF 키 → 17개로 확장 (display, shipping_logistics, consumer_discretionary 추가)
sector_research도 17개 키로 정규화

3.5 linkage_validator 키 정규화

LINKAGE_PROXY_MAP의 레거시 키 (battery, consumer_disc, comm_services 등)를 나침반 키로 통일
_LEGACY_TO_COMPASS 매핑 제거 가능

Part 6: 하위섹터 레벨 방법론에 대한 판단

질문: 각 하위섹터(108개)에 방법론을 만들어야 하나?

결론: 아니오.

이유: 1. 하위섹터는 분류 체계이지 분석 프레임워크가 아님 2. 108개 방법론 파일의 유지보수 비용 >> 가치 3. _SUBSECTORS의 cycle_independence 필드가 이미 하위섹터별 사이클 특성을 1문단으로 기술 4. 방법론의 사이클 모델은 섹터 레벨에서 충분 (DRAM 사이클 = 반도체 사이클의 핵심)

대신: - 나침반 _SUBSECTORS의 cycle_independence 필드를 방법론의 사이클 모델과 연결 - 예: 반도체 사이클 모델의 TROUGH 단계에서 "HBM은 독자 사이클 — _SUBSECTORS.semiconductor.memory_hbm.cycle_independence 참조" - 이 연결은 웹앱 UI에서 표시하되, 별도 파일은 만들지 않음

Part 7: 위험과 제약

7.1 아키텍처 문서 제약 준수

섹터나침반-아키텍처.md의 "절대 하지 말 것" 4가지: 1. "매핑 레이어/매핑 테이블 추가 금지" → 준수: vault_bridge는 매핑 테이블이 아니라 검색 인덱스. 단방향 키워드 매칭. 2. "나침반을 GICS 11개로 축소 금지" → 준수: 17개 유지. 3. "_SUBSECTORS를 JSON 외부화 금지" → 준수: Python dict 유지. 4. "etf_tracker.py 수정 금지" → 준수: 건드리지 않음.

7.2 볼트 쓰기 규칙 준수

"지식 내용(인사이트/판단/해석) = 사람만. 구조(분류/이동/연결/태그/frontmatter/MOC) + 운영문서(800번대) = Cowork OK" → vault_bridge가 노트 frontmatter를 수정하지 않음. 별도 인덱스 파일에 저장.

7.3 비용 제약

vault_bridge: LLM 없이 규칙 기반 → 비용 0
methodology_assessor 나침반 주입: 기존 LLM 호출에 컨텍스트 추가 → 토큰 +20% 정도
cycle_crosscheck: LLM 없이 규칙 기반 → 비용 0

7.4 리스크

리스크	대응
vault_bridge 키워드 매칭 오태깅	confidence 0.7 이상만 표시. 수동 검토 리포트 생성
방법론 5개 신규 작성 품질	기존 14개와 동일 구조 + methodology_assessor 자동 평가
sector_schemas.py 비대화	현재 14개 → 17개 = 관리 가능 범위
AF 14개 → 17개 확장 시 프롬프트 비용	display/shipping_logistics/consumer_discretionary 3개만 추가

Part 8: 완료 기준

Phase 0 완료 조건

[ ] 331 중첩폴더 해소 — 이중 경로 노트 0개
[ ] MOC 중복 33건 → 단일 정본 통합
[ ] maturity 백필 — 미설정 198개 → 0개
[ ] 태그 표준화 — 대소문자/동의어/슬래시/1회 태그 정리
[ ] vault_flow_health 재측정 → 개선 확인

Phase 1 완료 조건

[ ] 방법론 17개 파일 존재 (신규 5개 + 정렬 완료) — 각 파일 6축 구조 포함
[ ] sector_schemas.py 17개 스키마 정의 + MoatLayer 필드 추가
[ ] sector_data.py _MOAT_ANALYSIS 딕셔너리 17섹터 정성 분석 작성
[ ] moat_scorer.py 기업별 정량 스코어 파이프라인 구현
[ ] insight 생산 구조 — zk_type 재라벨링 로직 vault_architect에 추가
[ ] MOC-투자방법론-17섹터.md 업데이트

Phase 2 완료 조건

[ ] vault_bridge.py 작동, 커버리지 80%+
[ ] methodology_assessor.py에 나침반 데이터 주입 작동
[ ] sector_compass.py API에 /vault-notes, /methodology 엔드포인트
[ ] 웹앱에 방법론/볼트 노트 패널 표시
[ ] inlinks 개선 — knowledge_connector에 subsector 매칭 부스트 적용

Phase 3 완료 조건

[ ] cycle_crosscheck.py 17섹터 교차 검증 작동
[ ] signal_synthesizer 섹터별 임계값 적용
[ ] AF/SR/linkage 17개 키 정규화 완료

연결

[[섹터나침반-아키텍처]] — 나침반 v3 기본 아키텍처
[[MOC-투자방법론-14섹터]] → 17섹터 확장 예정
[[002 구조도]] — 볼트 전체 구조

통합 설계안: 볼트 300 지식망 + 섹터나침반 v3 + 방법론 17섹터