결론

현재 virtual-insanity 웹앱의 문제는 “섹터가 많다”보다 분류 기준이 서로 다른 층위에서 동시에 노출되는 것이다.

화면 메뉴: 시장 / 참고 / 운영
텔레그램 라우팅: market / ideas / industry / report / ops
섹터 나침반: 17개 Compass sector
뉴스 섹터: 22개 S-code, 현재 파일 15개
애널리스트 로그: macro/fundamental/technical/pm 투자판단 로그인데 현재 운영에 배치

이 상태에서는 해리가 “시장 판단을 보러 온 것인지 / 운영상태를 보러 온 것인지 / 자료창고를 보러 온 것인지” 한 번에 구분하기 어렵다.

확인한 현재 상태

웹앱 라이브

/ 200
/analyst/log 200
/market/sector-compass 200
/news/all 200
/ops/ 200, 최초 3초 timeout 후 15초 재시도에서 0.2초 응답
/api/sector-compass 200, 약 835KB, sector 17개

현재 좌측 메뉴

파일: ~/.hermes/workspace/scripts/pipeline/webapp/templates/base.html

시장

브리핑
데이터
섹터나침반
뉴스
가설
투자 판단

참고

기업 리서치
리서치
채권
볼트
히트맵
칸반
널리지그래프

운영

에이전트 로그
시스템
파이프라인

문제 진단

1. 에이전트 로그 위치가 잘못됨

파일: webapp/blueprints/analyst.py, templates/analyst/log.html

/analyst/log는 시스템 실행 로그가 아니라 다음 네 투자 판단 산출물을 보여준다.

macro
fundamental
technical
pm

따라서 이것은 운영 로그가 아니라 시장 판단 레이어다. 해리 지적처럼 운영이 아니라 시장에 있어야 맞다.

운영에 있어야 하는 로그는 다음이다.

크론 성공/실패
LaunchAgent 상태
에러 레저
Gateway/Worker 상태
파이프라인 실행 이력

2. “참고”는 기준 없는 잡동사니가 됨

현재 참고에는 성격이 다른 것들이 섞여 있다.

기업 리서치 / 리서치 / 채권: 시장 판단 자료
볼트 / 히트맵 / 칸반 / 널리지그래프: 지식관리 도구

즉 참고라는 이름이 “보조자료”인지 “지식 시스템”인지 “리서치 데이터”인지 불명확하다.

3. 섹터 분류가 3계층으로 혼재됨

Compass sector: 17개

sector_data.py 기준.

반도체, 디스플레이, 조선, 해운/물류, 에너지/정유, 석유화학, 배터리/EV, 방산/우주, 원전/전력인프라, 바이오/헬스케어, 로봇/자율주행, 경기소비재, 필수소비재, 금융, 플랫폼/미디어, 인프라/유틸리티, 소재/철강

뉴스 S-code: 22개

sector_news.py 기준.

S10 반도체기술, S11 조선, S20 바이오, S30 산업재방산, S31 방산, S32 소재철강, S33 해운, S40 콘텐츠, S50 에너지, S51 석유화학, S52 배터리2차전지, S53 소비재유통, S54 원전, S55 필수소비재, S56 유틸리티, S57 부동산리츠, S58 정보기술IT, S59 통신커뮤니케이션, S60 금융, S70 중국, S80 매크로, S94 전략의사결정

텔레그램 topic: 5개

~/.hermes/sector-group.json

market
ideas
industry
report
ops

문제는 이 셋이 모두 “섹터”처럼 쓰인다는 점이다. 실제로는 역할이 다르다.

Telegram topic = 전달 채널
Webapp nav = 사용 목적
Compass sector = 투자 분석 산업분류
News S-code = 수집/분류용 taxonomy

권장 원칙

원칙 1. 웹앱 상단/좌측 메뉴는 “사용 목적” 기준으로 4개만 둔다

원칙 2. 섹터는 내부 표준 하나만 canonical로 둔다

Canonical sector는 17개 Compass sector로 두는 것이 낫다.

이유:

투자 판단에 필요한 수준까지 세분화되어 있음
이미 valuechain, subsector, linkage, watch indicators가 붙어 있음
뉴스 S-code와 매핑 테이블이 이미 존재함

뉴스 S-code는 노출용이 아니라 수집/분류용 하위 호환 코드로 내려야 한다.

원칙 3. 매크로/전략/중국은 “섹터”가 아니다

뉴스 S-code의 S80_매크로, S94_전략의사결정, S70_중국은 산업 섹터가 아니다.

권장 처리:

매크로 → 시장 > 매크로
전략 → 시장 > 투자 판단 또는 가설
중국 → 지역/테마 필터

이 셋을 산업 섹터와 같은 줄에 놓으면 섹터 체계가 무너진다.

적용 우선순위

1차 — 메뉴 정리만 적용

에이전트 로그를 운영 → 시장으로 이동
참고를 리서치와 지식으로 분리
코드 변경 파일: templates/base.html
영향: 낮음. 라우트 변경 없음, 메뉴 표시만 변경

2차 — taxonomy 문서화

webapp/taxonomy.py 또는 webapp/nav_schema.py를 만들어 canonical menu와 sector group을 한 곳에 둔다.
base.html에 하드코딩된 nav_groups 제거
sector_news의 S-code는 canonical 17 sector에 매핑된 내부 코드임을 명시

3차 — 섹터 UI 축약

섹터 나침반 첫 화면에 17개를 그대로 뿌리지 말고 8~9개 그룹 → 17개 drilldown 구조로 변경
매크로/전략/중국은 산업 섹터 탭에서 분리

바로 적용 가능한 최소 변경

base.html 메뉴만 바꾸면 된다.

변경 전:

시장: 브리핑/데이터/섹터나침반/뉴스/가설/투자 판단
참고: 기업 리서치/리서치/채권/볼트/히트맵/칸반/널리지그래프
운영: 에이전트 로그/시스템/파이프라인

변경 후:

시장: 브리핑/데이터/에이전트 판단/뉴스/가설/투자 판단
리서치: 섹터 나침반/기업 리서치/증권사 리서치/채권
지식: 볼트/히트맵/칸반/널리지그래프
운영: 시스템/파이프라인

판단

해리 지적이 맞다.

에이전트 로그는 운영이 아니라 시장이다.
참고는 기준이 없다. 없애야 한다.
섹터분류는 줄이는 게 아니라 “노출 계층”을 정리해야 한다.
canonical은 17개 Compass sector로 두고, 뉴스 S-code는 수집용 내부코드로 내려야 한다.

가장 안전한 다음 조치는 base.html 메뉴 재배치다. 기능 경로는 그대로 두고, 해리가 보는 정보 구조만 바로 좋아진다.

2026-04-16 적용 기록

적용 완료.

변경 파일:

~/.hermes/workspace/scripts/pipeline/webapp/templates/base.html

백업:

templates/base.html.bak-nav-taxonomy-20260416085809

변경 내용:

에이전트 로그 → 에이전트 판단으로 라벨 변경 후 운영에서 시장으로 이동
참고 그룹 제거
리서치 그룹 신설: 섹터 나침반 / 기업 리서치 / 증권사 리서치 / 채권
지식 그룹 신설: 볼트 / 히트맵 / 칸반 / 널리지그래프
운영은 시스템 / 파이프라인만 유지
모바일 더보기 메뉴도 동일한 기준으로 동기화

검증:

웹앱 PID 78582 → 21011 재기동
/ 200, 새 메뉴 반영 확인
/analyst/log 200
/market/sector-compass 302 정상 리다이렉트
/analyst/research 200
/ops/ 200
/ops/pipelines 200

남은 과제:

섹터 첫 화면을 8~9개 1차 그룹 → 17개 Compass sector drilldown 구조로 축약
S80_매크로, S94_전략의사결정, S70_중국을 산업 섹터와 분리
nav/taxonomy 하드코딩을 webapp/nav_schema.py 같은 단일 스키마로 이동

2026-04-16 섹터 나침반 1차 그룹 적용

적용 완료.

변경 파일:

~/.hermes/workspace/scripts/pipeline/webapp/blueprints/sector_compass.py
~/.hermes/workspace/scripts/pipeline/webapp/templates/market/sector_compass.html

백업:

blueprints/sector_compass.py.bak-sector-groups-20260416090126
templates/market/sector_compass.html.bak-sector-groups-20260416090126

변경 내용:

/market/sector-compass 진입 시 더 이상 첫 섹터로 자동 리다이렉트하지 않고 1차 그룹 개요를 보여줌
기존 17개 Compass sector는 유지
17개를 다음 8개 1차 그룹으로 묶음
반도체/디스플레이
에너지/화학/소재
조선/해운
방산/원전/전력
배터리/EV/로봇
바이오/헬스케어
소비/플랫폼
금융
오른쪽 패널도 평면 17개 목록에서 1차 그룹 → 세부 섹터 목록으로 변경
매크로/금리/환율, 중국, 전략 의사결정은 산업 섹터가 아니라는 안내 문구 추가

검증:

웹앱 PID 21011 → 27281 재기동
/market/sector-compass 200, 섹터 나침반 1차 그룹, 8개 그룹, 반도체/디스플레이, 그룹 개요 반영 확인
/market/sector-compass?sector=semiconductor 200, 기존 세부 섹터 상세 정상
/api/sector-compass 200, 기존 API 유지
/ 200, 메뉴 구조 유지 확인

남은 과제:

뉴스 S-code 화면도 같은 8개 그룹 기준으로 한 번 더 정리 필요
S80_매크로, S94_전략의사결정, S70_중국은 뉴스/브리핑/투자판단 필터로 분리하는 후속 작업 필요
현재 group schema는 sector_compass.py에 있음. 다음 리팩터에서 webapp/taxonomy.py로 분리하는 것이 좋음

2026-04-16 뉴스 S-code 분류 / OpenClaw→Hermes 잔존 확인

적용 완료.

변경 파일:

~/.hermes/workspace/scripts/pipeline/webapp/blueprints/sector_news.py
~/.hermes/workspace/scripts/pipeline/webapp/templates/sector_news/all.html
~/.hermes/idea_sources.json 신규 복구/이관

백업:

blueprints/sector_news.py.bak-news-taxonomy-20260416091045
templates/sector_news/all.html.bak-news-taxonomy-20260416091045

확인한 사실:

뉴스 S-code 분류 원천은 idea_sources.json의 focus_areas다.
Hermes 코드 기준 idea_collector.py:29는 이미 ~/.hermes/idea_sources.json을 읽도록 되어 있었지만, 실제 파일이 없어 OpenClaw 쪽 설정에 의존/결손 상태였다.
~/.openclaw/idea_sources.json → ~/.hermes/idea_sources.json 복사 완료. 양쪽 모두 focus_areas=26, size 43686, updated_at=2026-03-26 확인.
실제 분류 흐름은 idea_collector.py가 키워드/소스 기반으로 focus_area를 붙이고, sector_news_scorer.py가 그 focus_area별로 memory/sector-news/YYYYMMDD_Sxx.json을 만든다.

분류 기준 반영:

뉴스 화면 /news/all의 필터를 평면 “섹터”에서 “분류”로 변경.
산업 섹터와 비산업 코드를 분리:
산업 섹터: S10/S11/S20/S30/S31/S32/S33/S40/S50/S51/S52/S53/S54/S55/S56/S57/S58/S59/S60
지역/중국: S70_중국
매크로/금리/환율: S80_매크로
전략/의사결정: S94_전략의사결정
카드에도 상위 분류 배지를 추가했다. 예: 지역/중국 + 중국, 매크로/금리/환율 + 매크로.
현재 S94 뉴스 파일은 없어서 화면에 전략/의사결정 그룹은 실제 파일이 생길 때 노출된다.

전략의사결정 주체 확인:

S94_전략의사결정은 산업 섹터가 아니라 “PM·가설·리스크 관리 프레임워크 입력” 카테고리다.
최종 의사결정 권한은 사람(해리)이고, 시스템상 판단 생성/표시는 analyst-pm이 담당한다.
근거:
analyst_daily_brief.py:53-60 — analyst-pm을 PM으로 정의하고 positioning/confidence/one_liner/narrative를 표시
notion_analyst_sync.py:582 — pm 영역을 S94_전략의사결정, S95_포트폴리오에 매핑
webapp/blueprints/market.py:1511-1526 — 웹앱 시장 판단은 memory/analyst-pm/latest.json에서 PM 포지셔닝을 읽음
현재 ~/.hermes/workspace/memory/analyst-pm/latest.json 존재, 2026-04-16 08:15 갱신, positioning=적극, one_liner 존재 확인

OpenClaw→Hermes 잔존 확인:

~/.openclaw/cron/jobs.json: 295개, enabled 0
~/.hermes/cron/jobs.json: 8개, enabled 8
Hermes workspace scripts 내부의 .openclaw 직접 참조는 일반 파이프라인에서는 발견되지 않았고, podman/docker 테스트·레거시 wrapper류에만 남아 있음.
다만 “모든 것 이전” 관점에서는 아직 완결로 보기 어렵다. 이유는 OpenClaw cron 295개가 모두 꺼져 있고 Hermes에는 실운영 8개만 남아 있어, 예전 cron 전체가 Hermes job으로 1:1 보존된 상태는 아니다.
이번에 즉시 고친 것은 실제 결손이 확인된 idea_sources.json 이관과 웹앱 분류 체계다. cron 전체 재구성은 별도 reconcile 작업이 필요하다.

검증:

python3 -m py_compile blueprints/sector_news.py 통과
Flask test client:
/news/all 200, 분류, 지역/중국, 매크로/금리/환율 반영
/news/all?sector=S70_중국 200
/news/all?sector=S80_매크로 200
웹앱 PID 27281 → 41764 재기동
live curl:
/news/all 200, 분류=True, 지역/중국=True, 매크로/금리/환율=True
/news/all?sector=S70_중국 200
/news/all?sector=S80_매크로 200
/market/sector-compass 200, 섹터 나침반 1차 그룹=True

남은 과제:

OpenClaw cron 295개를 Hermes 8개와 대조해서 폐기/보관/재활성/병합으로 분류하는 reconcile 필요.
sector_news_scorer, idea_collector, intelligence_cluster, keyword_tuner 계열이 현재 Hermes 정기 job에 없는지 추가 확인 후 필요한 것만 복구.
S-code/Compass/news/watchlist에 중복된 매핑을 webapp/taxonomy.py 같은 단일 스키마로 통합.
S70 중국은 “지역/중국”으로 유지하되, 중국 안에서 배터리·소비·플랫폼·매크로를 하위태그로 다시 나누는 2차 분류 필요.

추가 확인 — Hermes cron migration target 보존 상태

정밀 대조 결과, OpenClaw cron의 migration.hermes_id가 Hermes jobs.json에 실제 남아 있는지는 매우 낮다.

OpenClaw cron: 295개 / enabled 0
migration 메타데이터 보유: 86개
그중 Hermes jobs.json에 target id가 실제 존재: 3개
bond-daily-report → ocAK-AK000-bond-daily-dry-run
bond-morning-poll → ocAO-AO003-bond-morning-command
gmail-newsletter-collector → ocAQ-AQ004-gmail-newsletter-command
migration target이 메타데이터에는 있지만 Hermes 현재 jobs에 없음: 83개
migration 메타데이터 자체가 없는 OpenClaw cron: 209개

판정:

“OpenClaw는 꺼졌다”는 점은 맞지만, “OpenClaw의 모든 cron이 Hermes에 보존되어 있다”는 상태는 아니다.
특히 sector_news_scorer, notion-analyst-sync, analyst-pm-agent, hypothesis_lifecycle 등은 OpenClaw 쪽에는 verified_cutover 기록이 있으나 현재 Hermes jobs에는 대응 id가 보이지 않는다.
따라서 다음 단계는 무작정 재활성화가 아니라, 해리가 실제 보는 것 기준으로 필요한 cron만 우선 복원하고 나머지는 archive 처리해야 한다.

웹앱 메뉴·섹터 분류 점검 메모

결론

확인한 현재 상태

웹앱 라이브

현재 좌측 메뉴

시장

참고

운영

문제 진단

1. 에이전트 로그 위치가 잘못됨

2. “참고”는 기준 없는 잡동사니가 됨

3. 섹터 분류가 3계층으로 혼재됨

Compass sector: 17개

뉴스 S-code: 22개

텔레그램 topic: 5개

권장 원칙

원칙 1. 웹앱 상단/좌측 메뉴는 “사용 목적” 기준으로 4개만 둔다

원칙 2. 섹터는 내부 표준 하나만 canonical로 둔다

원칙 3. 매크로/전략/중국은 “섹터”가 아니다

추천 메뉴 구조

시장

리서치

지식

운영

추천 섹터 노출 방식

화면에서 처음 보이는 섹터는 8~10개 묶음으로 축약

17개 Compass sector는 2차 드릴다운으로 유지

적용 우선순위

1차 — 메뉴 정리만 적용

2차 — taxonomy 문서화

3차 — 섹터 UI 축약

바로 적용 가능한 최소 변경

판단

2026-04-16 적용 기록

2026-04-16 섹터 나침반 1차 그룹 적용

2026-04-16 뉴스 S-code 분류 / OpenClaw→Hermes 잔존 확인

추가 확인 — Hermes cron migration target 보존 상태