최근 코덱스 사용상황 - 쥬가 운영체제가 되어가는 중

최근 코덱스 사용상황 - 쥬가 운영체제가 되어가는 중

이전 글 이후로 코덱스를 어떻게 쓰고 있는지 다시 정리해본다.

잡담

마지막으로 올린 글이 6월 10일 이후 코덱스 사용상황이었다.

그 글을 쓰고 나서 또 2주 정도가 지났다.
겉으로 보면 블로그 글은 잠깐 멈춘 것처럼 보이는데,
실제로는 HERMES 안쪽에서 꽤 큰 변화가 있었다.

이번 기간은 새 프로젝트를 마구 늘렸다기보다,
이미 만들고 있던 HERMES를 “진짜 매일 돌아가는 운영 시스템”처럼 만드는 쪽에 가까웠다.

HERMES는 내가 만들고 있는 투자 운영실이고,
는 그 안에서 투자 판단을 도와주는 에이전트다.
처음에는 쥬가 리서치 요약을 잘하고,
종목에 대한 생각을 정리해주는 정도였다.

그런데 최근에는 느낌이 조금 달라졌다.

이제 쥬는 그냥 말을 잘하는 AI가 아니라,
자기 기억을 가지고,
자기 판단 근거를 읽고,
거래 기록을 복기하고,
멈추면 다시 일어나야 하는 하나의 운영체제처럼 변해가고 있다.

뭔가 말이 거창한데, 실제로 내가 요즘 코덱스로 하고 있는 일이 딱 그쪽이다.

Recent Codex and HERMES cover

로그 기준 기간

이번 글은 아래 기간을 기준으로 적는다.

  • KST 기준 2026-06-14 13:56 이후
  • 지금 글을 쓰는 2026-06-28 23:35까지
  • 블로그 소스, 코덱스 세션 기록, HERMES 프로젝트 변경 흔적을 기준으로 정리

이번에도 원문 로그를 그대로 붙이지는 않는다.
로그에는 실제 종목, 계좌, 주문, 설정, 인증 관련 흐름이 섞일 수 있기 때문이다.

그래서 공개 글에서는 숫자보다 구조를 남긴다.
무엇을 만들었고,
왜 만들었고,
내가 시스템을 어떤 방향으로 밀고 있는지만 적는다.

Work period map

한 줄로 말하면

최근 2주의 핵심은 이거다.

HERMES가 “투자 관련 기능이 많은 앱”에서 “쥬가 실제로 판단하고 복기하고 다시 배워가는 운영실”로 넘어가는 중이다.

전에는 화면, 리포트, 자동화, API 연결 같은 부품을 붙이는 느낌이 강했다.
요즘은 그 부품들이 쥬의 판단 루프 안으로 들어오고 있다.

보고서가 있으면 그냥 요약하고 끝나는 게 아니라,
그 보고서가 어떤 판단에 쓰였는지 남아야 한다.

거래가 일어나면 그냥 수익/손실만 보는 게 아니라,
진입이 좋았는지,
청산이 늦었는지,
수수료와 스프레드 때문에 손익이 깎였는지,
어떤 lane에서만 성과가 나는지 봐야 한다.

여기서 lane은 쉽게 말하면 “거래가 굴러가는 차선” 같은 거다.
국장 단기, 국장 중기, ETF, Binance 현물, Binance 선물처럼 성격이 다른 거래 묶음을 따로 보는 개념이다.

이걸 하나로 섞어버리면,
어디가 잘하고 어디가 못하는지 모른다.

쥬가 기억을 가지기 시작했다

가장 큰 변화는 메모리 쪽이다.

예전에는 쥬가 그때그때 자료를 보고 답하는 느낌이 강했다.
물론 그것도 충분히 유용했다.
그런데 투자 쪽에서는 이게 조금 부족하다.

왜냐하면 투자 판단은 한 번의 질문으로 끝나는 일이 아니기 때문이다.

어떤 종목을 왜 봤는지,
어떤 조건에서 들어가려고 했는지,
들어간 뒤에 무엇이 틀렸는지,
익절과 손절은 계획대로 됐는지,
다음에는 어떤 기준을 더 조심해야 하는지,
이런 것들이 계속 쌓여야 한다.

최근 작업에서는 이런 기억을 더 촘촘하게 만들었다.

RAG라는 것도 자주 나온다.
RAG는 쉽게 말하면 AI가 답하기 전에 자료창고에서 관련 기록을 찾아오는 방식이다.
그냥 머릿속으로 대충 말하는 게 아니라,
보고서, 메모리, 거래 기록, 전략 노트 같은 것을 다시 꺼내 읽고 판단하게 하는 장치다.

여기에 한 단계 더해서 Jue Wiki라는 흐름도 생겼다.
이건 쥬가 계속 참고하는 내부 위키에 가깝다.

사람으로 치면 투자 노트, 반성문, 작전 매뉴얼, 실수 기록, 체크리스트가 한곳에 정리되는 느낌이다.
그리고 쥬가 다음 판단을 할 때 이 위키를 다시 읽는다.

Jue memory loop

리서치는 자료가 아니라 척추가 됐다

이번 기간에 리서치 쪽도 꽤 중요했다.

HERMES에는 여러 리서치 흐름이 있다.
증권사 리포트도 있고,
시장 흐름을 보는 쪽도 있고,
국장 종목을 보는 쪽도 있고,
크립토 시장 내러티브를 보는 쪽도 있다.

처음에는 이 자료들이 “읽을거리”에 가까웠다.
그런데 지금은 이걸 쥬 판단의 척추처럼 만들고 싶어졌다.

왜 이 종목이 후보가 됐는지,
왜 어떤 후보는 피해야 하는지,
왜 어떤 거래는 너무 비싸거나 위험한지,
이런 판단이 리서치와 연결되어 있어야 한다.

또 하나 중요한 건 점수다.

AI가 어떤 종목이나 전략에 점수를 주면 그럴듯해 보인다.
그런데 “왜 89점이지?”라는 질문을 해보면 갑자기 허술한 점이 드러난다.

그래서 최근에는 점수 자체보다,
점수가 어떤 근거에서 나왔는지,
단기/중기/장기 관점이 섞인 건 아닌지,
실제 성과와 나중에 맞춰볼 수 있는지,
이런 쪽을 더 보게 됐다.

요즘 내가 원하는 쥬는 그럴듯한 말을 하는 쥬가 아니다.
근거가 약하면 약하다고 말하고,
자료가 부족하면 부족하다고 말하고,
자기 판단이 틀렸으면 다음번 정책을 고치는 쥬다.

Knowledge layer

KIS, Binance, Upbit가 같은 자동매매는 아니었다

이번 기간에도 KIS와 Binance 이야기가 계속 나왔다.

KIS는 한국투자증권 API다.
국장 쪽 거래를 연결하는 통로라고 보면 된다.

Binance와 Upbit는 크립토 쪽이다.
Binance는 해외 거래소고,
Upbit는 국내 크립토 거래소다.

겉으로는 전부 자동매매처럼 보이지만,
실제로는 성격이 많이 다르다.

국장은 장 시간이 있다.
장전, 장중, 마감이라는 리듬이 있고,
리포트와 공시, 수급, 보유 종목 상태를 같이 봐야 한다.
또 이미 들고 있는 종목을 쥬가 어떤 블록으로 관리할지도 중요하다.

크립토는 24시간 돌아간다.
현물과 선물이 다르고,
오더북, 스프레드, 펀딩비, 변동성이 훨씬 앞에 나온다.
잠깐 좋아 보이는 신호도 비용을 빼면 별 의미가 없을 수 있다.

그래서 쥬도 하나의 이름을 가지고 있지만,
실제로는 국장 쥬와 Binance 쥬가 서로 다른 리듬을 가져야 한다.

최근 작업에서는 이 차이를 더 노골적으로 분리하려고 했다.
메모리도 섞이면 안 되고,
성과표도 섞이면 안 되고,
판단 기준도 똑같이 쓰면 안 된다.

이건 꽤 중요한 전환이었다.

AI에게 “잘해봐”라고 말하는 것보다,
“네가 어떤 경기장에서 뛰고 있는지부터 구분해”라고 말하는 쪽에 가까웠다.

수익률보다 먼저 본 것은 기록의 품질

요즘 제일 많이 느낀 건,
자동매매에서 수익률만 보면 오히려 헷갈린다는 점이다.

수익이 났는지 손실이 났는지는 당연히 중요하다.
하지만 그 전에 기록이 정확해야 한다.

진입 가격,
청산 가격,
수수료,
세금,
스프레드,
슬리피지,
펀딩비,
실제 순손익.

이런 게 정확히 기록되지 않으면,
쥬가 나중에 자기가 잘한 건지 못한 건지 배울 수 없다.

또 거래 lane별로 따로 봐야 한다.

어떤 lane은 소액으로는 괜찮은데 키우면 안 될 수 있고,
어떤 lane은 승률은 낮아도 한 번 맞을 때 크게 벌 수 있고,
어떤 lane은 그냥 비용 때문에 구조적으로 약할 수 있다.

그래서 최근에는 “좋은 lane만 권한을 키우자”는 방향이 강했다.

말은 단순하다.

잘하는 방식은 조금 더 기회를 주고,
약한 방식은 줄이고,
검증 안 된 방식은 너무 빨리 키우지 않는다.

투자에서는 너무 당연한 말인데,
이걸 코드와 데이터 구조로 만들려면 생각보다 손이 많이 간다.

멈추면 드러나야 한다

운영 쪽에서 또 많이 본 것은 멈춤이다.

프로그램이 많아지면 언젠가는 뭐가 멈춘다.
리서치 러너가 멈출 수 있고,
메모리 업데이트가 실패할 수 있고,
거래 판단 루프가 시간 초과될 수 있고,
프롬프트가 너무 커져서 LLM이 처리하지 못할 수도 있다.

중요한 건 “안 멈추는 척”이 아니다.
멈췄을 때 티가 나야 한다.

그래서 watchdog 같은 개념이 나온다.
watchdog은 말 그대로 감시견이다.
주기적으로 프로세스 상태를 보고,
멈춘 것이 있으면 알려주거나 다시 띄우는 역할이다.

또 텔레그램 알림도 중요해졌다.
내가 화면을 보고 있지 않아도,
중요한 에러가 있으면 알려줘야 한다.

이런 건 멋있는 기능은 아니다.
하지만 실제 운영에서는 이런 기능이 제일 중요할 때가 많다.

자동매매에서 제일 무서운 건 화려한 UI가 없는 게 아니라,
조용히 실패하는 것이다.

Safety and operations

UI도 그냥 예쁜 화면이 아니었다

HERMES UI도 계속 만졌다.

예쁘게 만드는 것도 중요하지만,
요즘 더 중요하게 느낀 건 “운영자가 지금 무엇을 봐야 하는가”였다.

왼쪽 탭이 왜 이렇게 많은지,
국장 정보가 왜 안 보이는지,
LLM 사용량에 어떤 컴포넌트만 잡히는지,
Jue Wiki가 실제 판단에 어떻게 연결되는지,
러너 상태의 노란색 경고가 무엇을 의미하는지,
이런 질문들이 계속 나왔다.

이건 일반 웹페이지 디자인과 조금 다르다.

HERMES는 예쁜 소개 페이지가 아니라,
작은 투자 관제실에 가깝다.
그래서 화면은 보기 좋아야 하지만,
무엇보다 “지금 문제가 있는가”, “쥬가 무엇을 근거로 판단했는가”, “어떤 루프가 돌고 있는가”가 잘 보여야 한다.

요즘 UI 작업은 그 방향이었다.

정보를 더 많이 보여주는 게 아니라,
운영자가 지금 필요한 상태를 빨리 알아보게 만드는 쪽.

Operations console

코덱스 사용 방식도 변했다

내가 코덱스를 쓰는 방식도 조금 바뀌었다.

처음에는 한 번에 하나씩 시키는 느낌이었다.

“이거 고쳐줘.”

“이 기능 만들어줘.”

“테스트 돌려줘.”

이런 식이다.

그런데 HERMES가 커지면서 이제는 단일 요청보다,
큰 목표를 잡고 여러 에이전트나 단계로 쪼개는 일이 많아졌다.

예를 들면 Jue Wiki 작업도 그냥 “위키 만들어줘”가 아니었다.

스펙을 만들고,
러너를 만들고,
RAG 근거를 붙이고,
프롬프트 예산을 제한하고,
오류를 고치는 API를 만들고,
UI에 붙이고,
매니저 판단 루프가 실제로 읽게 만들고,
마지막으로 문서와 테스트를 확인하는 식이었다.

조금 웃긴 건,
이제 내가 코덱스를 쓰는 게 아니라,
코덱스 안에서 작은 개발팀을 굴리는 느낌이 난다는 점이다.

물론 아직 내가 계속 찔러봐야 한다.

“왜 현물 거래가 덜 일어나지?”

“왜 이 값이 이상하지?”

“왜 메모리가 섞여 있지?”

“왜 국장 정보가 안 보이지?”

이런 식으로 계속 물어봐야 한다.

하지만 예전보다 훨씬 큰 단위의 작업을 맡길 수 있게 된 건 확실하다.

이번 글에서 일부러 뺀 것

이번 글에서는 실제 투자 관련 세부값은 거의 뺐다.

실제 종목명,
잔고,
주문 결과,
세부 수익률,
API 키나 인증 흐름,
내부 파일 절대경로,
원문 로그.

이런 건 블로그에 그대로 올릴 내용이 아니다.

대신 공개해도 되는 수준에서,
최근 코덱스로 어떤 방향의 작업을 했는지만 남긴다.

요약하면 이렇다.

  • HERMES는 더 실제 운영 시스템처럼 변하고 있다.
  • 쥬는 단발성 답변봇보다 기억과 복기를 가진 투자 파트너 쪽으로 가고 있다.
  • 국장, Binance, Upbit는 서로 다른 리듬으로 분리되고 있다.
  • 수익률보다 먼저 정확한 기록과 검증 가능한 학습 구조가 중요해졌다.
  • 멈춤, 경고, 알림, 재시작 같은 운영 장치가 점점 중요해졌다.
  • 코덱스는 이제 단순 코드 작성 도구보다, 내 프로젝트를 같이 운영하는 개발팀 같은 느낌이 강하다.

마무리

최근 2주는 블로그에는 조용했지만,
속으로는 꽤 많은 구조가 바뀐 기간이었다.

예전에는 “코덱스로 이런저런 것을 만들었다”였다면,
요즘은 “코덱스로 시스템이 스스로 기억하고 복기하고 운영되게 만들고 있다”에 가깝다.

아직 완성은 아니다.
오히려 이제야 진짜 운영의 피곤한 부분들이 보이기 시작했다.

근데 그게 또 재미있다.

화면 하나 만들고 끝나는 게 아니라,
매일 돌아가는 작은 생물을 키우는 느낌이랄까.

쥬가 아직 완벽한 투자 파트너는 아니다.
하지만 적어도 이제는 그냥 말만 하는 쥬는 아니다.

기억하고,
틀리고,
고치고,
다시 움직이는 쥬가 되어가는 중이다.

그리고 나는 그걸 코덱스랑 같이 계속 다듬고 있다.

최근 코덱스 사용상황 - 쥬가 운영체제가 되어가는 중

https://poul.kr/2026/06/28/20260628-codex-hermes-recent/

Author

PouL

Posted on

2026-06-28

Updated on

2026-06-28

Licensed under