TL;DR

• 개인 개발 주식 정보 서비스인 dow-japan.jp의 데이터 기반 위에서, 매일 약 4,400개 종목을 처리하여 개별 해설을 자동 생성하는 파이프라인을 가동 중이다 (16개 병렬 처리 · 로컬 LLM (Large Language Model)으로 비용 최적화).
• 그 위에서 단기/중기 스윙 판단을 내리는 12체의 멀티 에이전트 (Multi-agent) 리서치 팀을 운영한다. 전 종목 스크리닝 → 수 종목으로 압축 → 심층 분석 → 레드팀 (Red Team)이 반드시 반증한 후, PM (Project Manager)이 최종 판정하는 구조다.
• 단순한 데모가 아니라, 기존의 실제 운영 시스템 (Laravel 12 / Nuxt 3 / MySQL / J-Quants API)에 통합하여 매일 무인으로 작동시키고 있다는 점이 핵심이다. 환각 (Hallucination) 대책, 비용 설계, 운용까지 포함하여 "만들고 끝내지 않는" 제작 방식을 기술한다.

과제: 수천 개 종목 중 '지금 봐야 할 몇 개 종목'을 근거와 반증을 담아 추출하기

도쿄증권거래소에는 3,000개 이상의 기업이 상장되어 있다. 매일의 가격 변동, 거래량, 지표를 전부 사람이 추적하는 것은 물리적으로 불가능하다. 게다가 원하는 것은 단순한 요약이 아니라, "지금 주목해야 할 종목은 무엇이며, 어떤 근거가 있고, 어디에 리스크가 있는가"까지 파고드는 판단이었다.

여기서 단순히 LLM에 모든 종목을 맡겨버리면, 비용과 품질 (환각) 측면에서 파산하게 된다. 수천 개 종목 × 매일 × 고성능 모델 조합은 지갑이 버티지 못할 뿐만 아니라, 근거 없는 "그럴싸한 거짓말"만 양산하게 된다. 또한, 단발적인 LLM 출력은 "강세로도, 약세로도 그럴싸하게 써낼 수 있다". 판단에 사용하려면, 출력을 그대로 믿지 않는 메커니즘이 필요하다.

이 기사는 그 세 가지——스케일 (전 종목을 매일) / 신뢰성 (반증을 거친 판단) / 비용——를 어떻게 양립시켰는지에 대한 이야기다.

수법: 데이터 기반 → 12체 팀의 "확장 · 압축 · 반증 · 결정"

전체 구조는 2단계로 나뉜다. 먼저 dow-japan의 데이터 기반이 매일 거의 모든 종목의 데이터와 해설을 생성한다. 그 위에서 12체의 리서치 팀이 "넓게 포착 → 압축 → 심층 분석 → 반증 → 결정" 과정을 반복한다.

[ 데이터 기반 / dow-japan ]
J-Quants API → MySQL 정규화 → flow_score · 상관 메타데이터
매일 약 4,400개 종목의 개별 데이터/해설을 자동 생성 (16개 병렬 처리 · 로컬 LLM)
...

단 한 명의 만능 에이전트에게 모든 것을 시키지 않고, 역할을 나눈 전문 에이전트를 배치한 것이 핵심이다. 공정을 나눌수록 각 에이전트의 프롬프트 (Prompt)는 단순해지며, 검증도 용이해진다.

12체의 역할

발굴 · 분석반 (무엇을 · 왜 후보로 삼는가)

• 02 퀀트 스크리너 (Quant Screener) … 모멘텀/수급/유동성/변동성 (Volatility)의 복합 조건으로 기계적으로 후보 풀을 추출
• 03 카탈리스트/재료 헌터 (Catalyst/Material Hunter) … 적시 공시, 결산 스케줄, 레이팅 변경을 추적하여 가까운 미래에 움직일 종목을 추출
• 06 매크로 · 섹터 전략가 (Macro · Sector Strategist) … 시장 분위기, 섹터 로테이션을 판정하여 후보의 매크로 정합성을 평가
• 09 사후 검토 (Post-Mortem) … 과거의 프로세스와 결과를 분리하여 검증하고, 승리/패배 패턴을 추출
• 11 필터 (Filter) … 경량 필터로 3040개 종목을 57개 종목으로 압축

심층 분석 · 검증반 (정말 좋은 종목인가 · 어디서 진입하고 어디서 손절할 것인가)

• 04 테크니컬 애널리스트 (Technical Analyst) … 멀티 타임 프레임 (Multi-timeframe)으로 추세/눌림목 위치/거래량 정합성을 판정
• 05 펀더멘털 애널리스트 (Fundamental Analyst) … 실적 모멘텀, 컨센서스 괴리, 선반영 정도를 판정
• 07 리스크 매니저 (Risk Manager) … ATR/상관관계/허용 최대 낙폭 (Drawdown)으로부터 포지션 규모와 손절 (Loss-cut) 수준을 정량화
• 08 레드팀 (Red Team, 반증) ★가장 중요 … 모든 제안에 반드시 반론을 제기. 베어 케이스 (Bear case)/간과한 점/로직의 허점/편향 (Bias)을 지적. 동의는 금지

의사 결정 · 관리 · 코치

• 01 PM/통합 전략 책임자 … 모든 이의 분석을 통합하여 최종 의사 결정. 제안을 기록
• 10 포지션 리뷰어 (Position Reviewer) … 보유 중인 종목을 일간 리뷰하여 지속/청산/부분 익절/스탑 업데이트를 판정
• 12 트레이드 코치 (Trade Coach) … 규율과 실행력을 단련 (체크리스트 대조 · 일지 리뷰 · 약점 교정)

여기서부터가 본론: 커모디티(Commodity)와의 차이를 만드는 "깊이"

"에이전트를 만들 수 있습니다"라는 말은 이제 누구나 할 수 있다. 차이가 나는 지점은 실제 운영 환경에서 매일 작동시키기 위해 필요한, 지루하고 번거로운 부분이다. 4가지로 나누어 기술한다.

1. 통합: 기존의 실제 운영 시스템에 "組み込んだ (통합했다)"

새로 만든 격리된 데모가 아니라, 이미 작동 중인 dow-japan의 운영 구성(Production Configuration)에 그대로 얹었다.

데이터: J-Quants API로부터 취득 → MySQL에 정규화 → 33 업종별 독자 스코어인 flow_score와 상관 메타데이터를 생성 -
오케스트레이션 (Orchestration): Laravel 12의 배치(Batch)/큐(Queue)와 daily_run.sh가 에이전트 군의 실행·재시도·스케줄링을 담당 -
표시: Nuxt 3 대시보드에 반영, Slack 및 X(구 Twitter)에 자동 게시

즉, 에이전트는 "기존의 데이터 계층·애플리케이션 계층 위에 증설한 모듈"이며, 수탁 업무로 비유하자면 "고객의 기존 시스템에 통합하는 것"과 같은 구조로 만들고 있다.

2. 신뢰성: 반증한 뒤에 결정한다 (레드팀과 평가 루프)

매일 자동으로 판단을 내리는 이상, 근거 없는 출력을 쏟아내지 않는 메커니즘이 필수적이었다. 이 부분이 이 기반 시스템의 가장 핵심적인 부분이다.

입력을 사실에 구속: 생성 전에 MySQL 상의 확정값(가격·거래량·flow_score 등)을 전달하여, **"전달된 숫자 이외의 것을 단정하지 말 것"**이라는 제약을 건다 -
08 레드팀(Red Team)이 반드시 반증: 모든 제안에 대해 베어 케이스(Bear Case, 하락 시나리오)·간과한 점·로직의 허점·편향(Bias)을 지적한다. 동의는 금지된다 -
01 PM은 그 반증을 바탕으로 판정: 레드팀의 베어 케이스를 채택한 상태에서 GO / 타진 / 보류를 결정한다 -
**09 회고(Retrospective)**를 통해 프로세스와 결과를 분리하여 검증하고, 다음 단계에 반영한다

이 확장 → 압축 → 반증 → 판정의 루프가 단발적인 LLM 호출과 결정적으로 다른 점이다. 어떤 날은 "1개 종목만 타진(눌림목 한정), 나머지는 보류"라는 판정이 나온다. 즉, 화려하게 종목을 늘어놓는 것이 아니라, 반증을 통과한 소수의 종목만이 남는다.

3. 비용 설계: 전부 비싼 모델에 던지지 않는다 (Dual LLM)

수천 개의 종목을 매일 돌리기 때문에, 처리 성격에 따라 모델을 구분해서 사용하고 있다.

대량 배치(Batch)는 로컬 LLM: 모든 종목의 개별 데이터/해설의 1차 생성은 로컬 PC에 구축한 자체 LLM 추론 서버에서 처리한다. 외부 API를 호출하는 횟수 자체를 줄인다 -
소량·고품질이 필요한 곳에만 상위 API: 번역이나 최종 마무리 등, 하루 수십 건 수준의 용도에만 상위 API 모델을 사용한다

시뮬레이션을 해보면 차이가 명확하다. 하루 약 5,000건(입력 5M / 출력 1.5M 토큰)을 상위 API 모델로 매일 돌리면, 대략적인 추산으로 월 수만~십수만 엔이 든다(예: Gemini Flash급은 월 $30~50, Claude Haiku급은 월 $375, Sonnet급은 월 $1,000 초과). 이 대량 배치를 로컬 LLM으로 돌림으로써 해당 부분은 전기료만 발생하는 실질적 제로(Zero) 비용으로 억제하고, 상위 API는 "소량이지만 품질이 필요한" 용도로만 사용하는 이중 구조(Dual LLM)를 취하고 있다. 만들 수 있느냐의 문제가 아니라, 비용까지 설계하여 구성을 선택한다. 이 점이 실제 운영에서 큰 힘을 발휘한다.

4. 운용: 실운영 환경에서 매일 돌아가고 있다

가장 확실한 증거는, 이것이 특별한 날의 데모가 아니라 매 영업일 무인으로 작동하고 있다는 점이다.

• 데이터 취득 → 분석 데이터 구축 → 개별 텍스트 생성 → 캐시 업데이트까지 일일 배치로 자동화
• 12체 팀의 daily_run.sh도 매일 실행되며 판단을 기록
• 실패 시의 재시도/로그, 출력의 자동 게시까지 포함하여 운용 체계에 올라와 있음

성과: 무엇이 얼마나 변했는가

• 매 영업일, 데이터 취득 → 분석 데이터 구축 → 개별 텍스트 생성 → 캐시 업데이트까지를 전 과정 자동 완주 (일련의 과정에 약 4.8시간 / 약 17,000초 소요, 사람은 전혀 관여하지 않음) -
• 일봉·주봉 합쳐서 약 7,400개 종목 분량(일봉 3,732건 + 주봉 3,712건)의 개별 해설 텍스트를 매일 생성 -
• 텍스트 생성은 16개 워커(Worker) 병렬 처리로 약 3,700건을 약 30분 만에 완료 -
• 원본 데이터는 J-Quants로부터 일일 약 4,400개 종목(imported 4,442 / skipped 7)을 가져옴 -
• 그 위에서 12체 팀이 전 종목 중 수 개의 종목으로 압축하여, 반증을 통과한 후보만을 제안으로 남김 -
• 출력은 대시보드·Slack·X로 자동 전달되어, 사람은 "결과를 읽기만 하면" 되는 상태가 됨

사람이 매일 수천 개의 종목을 읽는 것은 불가능하다. 그것을 "무인으로 약 4.8시간 동안 매 영업일 계속 돌아가며, 반증을 거친 소수의 종목만이 남는" 상태로 만든 것이 가장 큰 성과이다.

이것은 주식에만 국한된 이야기가 아니다

여기서 사용한 요소들 ——

• 대량 데이터를
  **공정 분할된 에이전트 군 (Agent Group)**으로 처리한다 -
  레드팀 (Red Team)에 의한 반증 → 통합 판단으로 출력의 신뢰성을 담보한다 -
  모델의 카스케이드 (Cascade) + 로컬 LLM으로 비용을 설계한다 -
  그것들을
  기존의 운영 시스템 (Production System)에 통합하여 무인 운용한다

—— 는, 주식 분석에 고유한 것이 아니다. 대량의 데이터와 다단계 판단 업무를 안고 있는 모든 기존 시스템에 동일한 패턴으로 도입할 수 있다. "PoC(개념 증명)는 작동했지만 실운영에 올리지 못한다", "비용을 예측할 수 없다", "환각 (Hallucination)이 무서워 내보낼 수 없다" —— 그 지점을 넘어선 것이 내가 해온 일이라고 생각한다.

요약

• 데모가 아니라,
  실운영 환경에서 매일 작동하는 멀티 에이전트 (Multi-Agent)를 실데이터 위에 구축하여 운용하고 있다 -
  차이를 만드는 것은 화려한 부분이 아니라,
  통합 · 신뢰성 (반증 후 결정) · 비용 설계 · 운용이라는 지루한 4가지 지점 -
  이 패턴은 금융에 국한되지 않고,
  기존 시스템으로의 AI 에이전트 통합으로서 전용할 수 있다

Discussion