요즘 HERMES 쥬를 보면 종목을 고르는 기능보다, 왜 그 종목을 보고 있는지와 왜 아직 멈춰 있는지를 남기는 기능이 더 빠르게 자라고 있다.
이번에는 현재 구현 상황을 먼저 정리하고, 2026년 8월 27일 KIS 국내장 알파 화면에 실제로 들어온 후보 20개를 다시 읽어 보려고 한다. “어떤 종목이 오를까?”를 맞히는 글이 아니라, 쥬가 어떤 자료를 보고 후보를 올렸으며 그 후보가 어떤 문턱 앞에 서 있는지 적는 개발·관찰 기록이다.
기준 시각은 2026-08-27 15:36 KST다. 당시 KIS 원본 상태는 ok였지만, 글을 쓰는 밤에는 최신성 플래그가 stale로 바뀌어 있다. 그러므로 아래 숫자는 현재 실시간 호가가 아니라 그날 장 마감 뒤 저장된 스냅샷으로 읽어야 한다.
“가비아가 82점이면 사도 되는 건가?”라는 질문부터 답하면, 아니다.
이번 글은 HERMES 쥬의 KIS 국내장 알파 화면에 실제로 남아 있던 후보 20개를 꺼내 보고, 그 점수가 무엇을 뜻하는지 정리한 작업 노트다. 점수가 높다고 미래 수익률이 높다는 뜻은 아니고, 쥬가 정한 몇 가지 관찰 기준을 같은 시장 안에서 비교한 결과에 가깝다.
기준 시각은 2026-08-10 15:53 KST다. 이때 데이터 원본 상태는 정상이었지만, 밤에 이 글을 쓰는 시점에는 그 스냅샷의 최신성 플래그가 지났다. 따라서 아래 표는 그 시각의 기록이지, 지금 바로 쓸 실시간 시세판이 아니다. 20개 모두 no_experiment, 즉 실험으로 검증되어 자본을 붙일 단계가 아닌 관측 후보였다.
지난 글에서는 백테스트의 마지막 하루를 맞추는 일을 썼다. 오늘은 그보다 조금 넓게, 그래서 쥬가 지금 실제로 무엇을 할 수 있는 상태인지를 정리해 본다.
한 줄로 말하면 이렇다.
쥬는 종목을 찍어 주는 자동매매 봇이 아니라, 자료를 읽고 검증되지 않은 판단에는 자본을 붙이지 않도록 만든 개인 운용 시스템이다.
이 글은 2026-08-09 18:55 KST의 HERMES v3 코드 스냅샷과 그때까지의 구현 기록을 기준으로 썼다. 계좌 잔고, 보유 종목, 실제 주문 정보는 넣지 않았다.
오늘 HERMES v3에서 가장 눈에 띈 결과는 “어떤 종목이 제일 잘 나왔나”가 아니었다.
마지막 하루가 맞지 않으면, 좋아 보이는 백테스트도 아직 믿지 않는다.
이 글은 2026-08-07 22:13 KST의 코드 스냅샷과 22:11 KST까지의 운영 기록을 기준으로 썼다. 계좌, 보유 종목, 실제 주문 정보는 넣지 않았다.
오늘의 HERMES v3는 조금 더 조용한 방향으로 진척됐다.
쥬는 리포트를 읽고, 시장을 다시 훑고, 필요할 때 생각을 기록한다. 그래도 주문 문은 아직 잠겨 있다.
이 글은 2026-08-06 20:32 KST의 코드 스냅샷과 21:48 KST까지 확인한 관찰 기록을 기준으로 썼다. 계좌, 보유 종목, 실제 주문 정보는 넣지 않았다.
HERMES v3가 지금 어디까지 왔는지, 아주 쉽게 적어 보면 이렇다.
쥬는 이제 한국 주식, 미국 주식, 코인 시장을 계속 보고 기록할 수 있다. 하지만 아직 무엇도 사거나 팔 수는 없다.
겉으로 보면 “계속 보고 있다”와 “자동매매한다”가 비슷해 보이지만, 지금은 전혀 다른 단계다. 쥬는 관찰자이자 기록자다. 손에는 아직 주문 버튼이 없다.
이 글은 2026-08-05 21:44 KST의 HERMES v3 코드 스냅샷을 기준으로 썼다. 계좌, 보유 종목, 실제 주문 정보는 넣지 않았다.
어제는 쥬가 시장의 날씨를 읽기 시작했다는 이야기를 썼다. 오늘은 그 다음 이야기다.
신호가 다섯 개 생기고, 시장 상태를 나누고, 전수 스캔까지 빨라졌다고 해서 바로 매매를 재개하면 안 된다. 과거 그래프에서 그럴듯해 보인다는 것과 실제 돈을 걸어도 견딜 수 있다는 것은 완전히 다른 문제다.
그래서 지금 HERMES v3는 잘 되는 전략을 찾는 시간보다, 잘못된 결과가 좋아 보이는 경로를 먼저 막는 시간을 보내고 있다.
이 글은 2026-08-03 21:10 KST의 코드 스냅샷을 기준으로 썼다. 계좌, 실제 보유 종목, 주문 정보는 넣지 않았다.
HERMES v3를 다시 세운 뒤, 두 번째 큰 구현 차수에 들어왔다.
지난 글에서 “데이터부터 다시 쌓는다”고 적었는데, 이제는 그 위에 시장을 읽는 규칙을 올리기 시작했다. 그래도 쥬는 아직 매매하지 않는다. 지금 하고 있는 일은 매수 버튼을 누르게 만드는 일이 아니라, 그 버튼을 누르면 안 되는 날을 더 잘 구분하는 일에 가깝다.
이번 글은 2026-08-02 20:50 KST에 고정한 HERMES v3 코드 스냅샷을 기준으로 쓴다. 실시간 계좌·보유 종목·주문 정보는 넣지 않았다.
HERMES v3를 다시 짓기 시작한 지 얼마 안 됐는데, 생각보다 바닥 공사가 꽤 멀리 왔다.
아직 매매를 다시 시작한 건 아니다. 오히려 그 반대다. 이번에는 주문이나 쥬의 말투보다 먼저, 나중에 결과가 마음에 안 들어도 원인을 다시 찾아갈 수 있는 데이터와 규칙부터 깔고 있다.
이 글은 2026-08-01 밤, 현재 작업 트리와 테스트 결과를 보고 적는 중간 보고서다. 계좌·인증값·실제 보유 종목·주문 정보는 적지 않는다.
오늘 ChatGPT 구독을 해지했다. 그동안 GPT와 코덱스로 HERMES를 꽤 멀리까지 끌고 왔다. 화면도 만들고, 쥬의 말투도 붙이고, KIS와 바이낸스를 연결하고, 실패할 때마다 규칙을 덧댔다.
그런데 어느 순간부터는 고치는 속도보다 구조를 이해하는 속도가 더 느려졌다. 기능 하나를 만질 때마다 다른 곳의 예외와 오래된 실험이 같이 따라오고, “이게 왜 여기 있지”라는 질문이 먼저 나오는 상태. 열심히 만든 것이 틀렸다는 뜻은 아니지만, 계속 덧붙이는 방식으로는 내가 원하는 종류의 시스템이 되기 어렵다는 뜻은 분명했다.
그래서 이번에는 Claude를 새로 구독하고, 새 작업 환경에서 HERMES v3를 다시 시작한다. 이 글은 “어느 모델이 더 똑똑한가”에 대한 결론이 아니다. 오히려 모델이 바뀌어도 흔들리지 않아야 할 경계와 규칙을 먼저 세우는 기록이다.
기준 시점: 2026년 8월 1일. v3 저장소의 Phase 0 구현과 테스트 결과를 바탕으로 썼다. 아직 v3는 실거래를 시작한 시스템이 아니라, 재작성의 기반을 검증하는 단계다.
v2는 많은 것을 할 수 있었다. 대신 너무 많은 것이 한곳에 쌓였다. Python 코드만 36만 줄이 넘고, 실행 진입점은 21개, 독립적으로 도는 러너는 14개였다. 한 달 동안 LLM을 17,715번 호출해 약 1억 6,900만 토큰을 썼다.
문제는 비용만이 아니었다. 종목 분석의 상당 부분이 LLM 호출에 기대고 있으면, 같은 조건을 다시 돌려도 같은 판단을 보장하기 어렵다. 재현하기 어렵다면 백테스트로 검증하기도 어렵고, 검증하지 못하면 “좋아 보이는 판단”과 “돈을 걸어도 되는 판단”을 나눌 수 없다.
실제 기록도 이 불편한 결론을 피하지 못했다. 표본이 쌓인 전략군에서 뚜렷한 양의 기대값을 증명하지 못했고, 만들어 둔 검증 장치도 실제 진입 경로에서 우회된 적이 있었다. 프롬프트를 더 길게 쓰거나 모델을 한 번 더 바꾸는 일로 해결할 문제가 아니다.
v3의 첫 원칙은 단순하다. 재현 가능해야 개선할 수 있다.
종목을 넓게 훑는 일은 가능한 한 로컬의 결정론적인 분석 엔진이 맡는다. 같은 데이터와 같은 시점이면 같은 결과가 나와야 한다. LLM은 모든 종목을 매번 읽는 엔진이 아니라, 이벤트가 생겼을 때 포트폴리오 전체를 해석하는 판단 계층으로 줄인다.
여기서 Claude는 기본 판단 프로바이더가 된다. 다만 코드의 경계는 특정 모델에 묶지 않는다. 입력과 출력의 계약은 모델 바깥에 두고, Claude가 구조화된 결과를 내는지와 예산 안에서 동작하는지를 먼저 확인하는 식이다. 다음에 모델을 바꾸더라도 투자 규칙과 데이터 계층까지 다시 갈아엎지 않기 위해서다.
| v2에서 불편했던 것 | v3에서 바꾸는 방식 |
|---|---|
| 종목 분석이 LLM 호출에 크게 의존 | 로컬 알파 엔진이 분석을 만들고, LLM은 필요한 판단만 담당 |
| 검증 장치가 있어도 진입 경로에서 우회 가능 | enter는 워크포워드 검증을 통과한 신호만 만들 수 있게 설계 |
| 여러 러너가 각자 타이머를 가짐 | KIS와 Binance를 세 개의 명시적 스테이지 DAG로 정리 |
| DB 연결 규칙이 모듈마다 다름 | 단일 SQLite 연결 팩토리로 WAL과 잠금 대기 규칙을 강제 |
첫날에 만든 것은 멋진 화면도, 새 매매 로직도 아니다. 계획과 계약, 그리고 그 계약을 어기기 어렵게 만드는 작은 기반이다.
우선 v2를 실제 데이터로 다시 감사했다. 무엇을 버리고 무엇을 가져갈지 정하려면 “아마 복잡할 것이다”가 아니라, 어떤 경로가 비용을 쓰고 어떤 기록이 성과 측정에 남아 있는지부터 알아야 한다. 그 뒤 Phase 0 계획, 데이터·알파·판단·실행의 경계, 그리고 쥬 페르소나의 역할을 문서로 분리했다.
구현으로는 SQLite 연결을 한 군데로 모았다. 새 데이터베이스는 WAL 모드와 잠금 대기 시간, 외래키 설정을 같은 규칙으로 열고, 다른 모듈이 직접 연결을 만들면 검사 단계에서 막힌다. 눈에 띄는 기능은 아니지만, 런타임이 길어질수록 이런 작은 규칙이 시스템의 성격을 결정한다.
이 첫 기반은 단위 테스트 11개와 코드 검사, 포맷 검사, 모듈 의존성 검사까지 통과했다. 아직 “잘 굴러간다”는 말은 할 수 없지만, 적어도 어디까지가 공용 기반이고 무엇을 침범하면 안 되는지는 실행 도구가 확인한다.
Claude를 구독했다고 수익률이 갑자기 좋아질 거라고 기대하지는 않는다. HERMES v3가 제대로 가는지 판단할 기준도 거기에 두지 않을 생각이다.
이 네 가지가 먼저다. 통과한 전략이 하나도 없다는 결과도, 실자본을 계속 태우는 것보다 낫다. 이번 리팩토링은 뭔가를 더 많이 시키는 작업이 아니라, 모르는 것을 모른다고 적고, 확인한 것만 다음 단계로 넘기는 연습에 가깝다.
ChatGPT를 해지하고 Claude로 옮긴 일은 겉으로 보면 구독 서비스 하나를 바꾼 것뿐이다. 하지만 내게는 HERMES를 다시 이해할 수 있는 크기로 되돌리는 시작점이다. 모델은 새로울 수 있어도, 이번에는 구조가 먼저다.
이 글은 개인 프로젝트의 개발 기록이며 투자 권유가 아니다. HERMES v3의 검증 결과와 실제 동작은 이후 구현과 측정에 따라 달라질 수 있다.