6월 10일 이후 코덱스 사용상황

이전 글 이후 며칠 동안 코덱스를 어떻게 썼는지 다시 정리해본다.

잡담

지난번에 요즘 코덱스를 어떻게 쓰고 있나라는 글을 올렸다.

그때는 대략 5월 말부터 6월 10일까지의 사용 흐름을 정리했다.
HERMES, 블로그, 붕붕고, Ju Office, 작은 자동화 같은 것들이 한꺼번에 굴러가고 있다는 이야기였다.

그런데 그 글을 올린 뒤 며칠이 지났을 뿐인데,
사용 느낌이 또 조금 바뀌었다.

이전 글이 “코덱스를 여러 프로젝트에 붙여 쓰고 있다”는 이야기였다면,
이번 며칠은 조금 더 좁고 깊었다.

특히 HERMES 쪽이 그랬다.
이제 HERMES는 그냥 자산관리 UI나 리서치 보조 도구라기보다,
쥬라는 투자 파트너를 실제 운영 루프 안에 넣어보는 실험에 가까워졌다.

물론 이 글에서는 실제 종목, 잔고, 주문, 키, 계정 같은 민감한 내용은 쓰지 않는다.
로그 원문도 그대로 올리지 않는다.
밖에 보여줘도 되는 건 “무슨 목적의 작업이었는지”와 “어떤 구조가 생기고 있는지” 정도다.

로그 기준 기간

이번 글의 기준은 대략 이렇다.

• KST 기준 2026-06-10 21:40 이후
• 현재 글을 쓰는 2026-06-14 오후까지
• 코덱스 세션 파일, HERMES 운영 로그, 블로그 저장소 상태, 그리고 실제 poul.kr 확인 작업을 바탕으로 정리

정확한 작업 로그를 그대로 타임라인으로 붙이면 너무 지저분하다.
그리고 일반인이 읽어도 재미가 없다.

그래서 이번에는 “무슨 일이 있었나”보다 “왜 그런 일을 했나” 중심으로 정리한다.

제일 큰 변화는 HERMES/Jue

이 기간의 중심은 거의 HERMES였다.

HERMES 안에서 쥬는 투자 판단을 도와주는 에이전트다.
처음에는 리서치와 판단을 정리하는 느낌이 강했는데,
이번 며칠 동안은 훨씬 더 운영 쪽으로 내려왔다.

예를 들면 이런 질문들이 계속 나왔다.

• 지금 잘 돌아가고 있는가
• 왜 어떤 프로세스가 멈춰 있는가
• 리서치가 실제 판단에 잘 연결되고 있는가
• KIS 쪽과 Binance 쪽 판단 흐름이 서로 다르게 움직이는 이유는 뭔가
• 블록 단위로 매매를 기록하고 복기하는 체계가 충분한가
• 실패했을 때 조용히 넘어가지 않고 사용자에게 알려주는가

이게 재미있는 지점이다.

예전에는 “좋은 판단을 해줘”에 가까웠다면,
이번에는 “좋은 판단을 계속 할 수 있는 운영 구조를 만들어줘”에 가까웠다.

조금 더 말하면,
쥬가 똑똑한 말만 하는 게 아니라,
자기가 본 자료와 판단과 실패와 복기를 계속 남기고,
다음 판단 때 그걸 다시 읽을 수 있어야 한다는 쪽으로 갔다.

리서치가 일회성에서 지식 레이어로

이번에 많이 나온 말 중 하나가 리서치였다.

보고서, RAG, 리서치 스냅샷, 전략 인텔리전스, 시장 신호 같은 것들이 HERMES 안에 이미 여러 군데 있었다.
그런데 막상 운영하려고 보니 질문이 생긴다.

“이 자료들은 그냥 한 번 보고 끝나는 건가?”

“쥬가 다음 판단을 할 때 실제로 다시 읽고 있나?”

“점수는 어떤 근거로 매겨지는 건가?”

“최근 리서치만 보고 판단하면 너무 얕아지는 거 아닌가?”

이런 질문들이다.

그래서 이번 며칠은 리서치를 그냥 자료 모음으로 두는 게 아니라,
쥬가 계속 참고하는 지식 레이어로 만들려는 흐름이 강했다.

내가 원하는 건 단순한 요약봇이 아니다.

오늘 나온 보고서를 요약해주고 끝나는 게 아니라,
그 보고서가 어떤 종목 판단에 영향을 줬는지,
그 판단이 나중에 맞았는지 틀렸는지,
틀렸다면 어떤 기준을 고쳐야 하는지까지 남는 구조가 필요하다.

이건 시간이 좀 걸리는 작업이다.
하지만 이 방향이 맞다고 느낀다.

KIS와 Binance는 성격이 다르다

국장 쪽은 KIS를 통해 움직인다.
KIS는 한국투자증권 API다.

크립토 쪽은 Binance가 중심이다.
그리고 중간중간 Upbit 쪽 이야기도 나왔다.

둘은 같은 자동매매라고 부르기엔 성격이 꽤 다르다.

국장은 장 시간이 있고,
보유 종목이 있고,
리포트와 시장 뉴스의 영향이 크고,
이미 들고 있는 포지션을 어떻게 블록화할지도 중요하다.

반면 Binance는 24시간 돌아간다.
선물과 현물의 성격도 다르고,
퀀트 신호, 오더북, 스프레드, 펀딩, 변동성 같은 것이 훨씬 앞에 나온다.

그래서 쥬도 하나의 인격처럼 보이지만,
실제로는 KIS 쥬와 Binance 쥬가 각자 다른 리듬을 가져야 한다.

이번 며칠은 그 차이를 계속 확인한 시간이었다.

특히 Binance 쪽에서는 “왜 숏만 치는 것처럼 보이지?”, “왜 현물 거래는 덜 활발하지?”, “수량은 어떻게 정하는 거지?”, “청산은 목표가에 맞게 되고 있나?” 같은 질문들이 나왔다.

국장 쪽에서는 “리서치와 계좌 상태가 판단에 잘 들어가는가”, “익절과 손절의 타이밍이 맞는가”, “기존 보유분도 쥬가 블록으로 관리할 수 있는가” 같은 질문이 더 중요했다.

코덱스 native 쪽으로 더 흡수하기

또 하나 큰 흐름은 native Codex였다.

기존에는 HERMES 안에서 LLM을 부르는 브리지 구조가 있었다.
그런데 이번에는 그걸 더 코덱스 native 쪽으로 흡수하려는 이야기가 많이 나왔다.

내가 느끼는 장점은 이렇다.

세션이 남고,
맥락이 이어지고,
메모리와 스킬을 더 자연스럽게 붙일 수 있다.

단순히 API 한 번 호출해서 답을 받는 것보다,
쥬가 하나의 작업실 안에서 오래 살아 있는 느낌에 가깝다.

물론 이건 아직 실험적인 부분이 많다.
어디까지 native로 붙이고,
어디까지 기존 서비스 코드로 남겨야 하는지는 계속 봐야 한다.

그래도 방향은 분명하다.

HERMES가 그냥 LLM을 소비하는 앱이 아니라,
코덱스의 작업 방식 자체를 내부 구조로 흡수하는 쪽으로 가고 있다.

운영 문제를 보는 방식도 바뀌었다

이번 며칠은 버그를 고치는 방식도 조금 달랐다.

예전 같으면 그냥 에러가 나면 해당 코드를 고쳤을 것이다.

이번에는 더 자주 이런 식으로 물었다.

“왜 이 프로세스가 멈췄지?”

“토큰 사용량이 줄어든 게 최적화 때문인가, 아니면 뭔가 안 돌고 있는 건가?”

“타임아웃이 너무 짧은가?”

“로그가 계속 커지는 구조인가?”

“에러가 나면 텔레그램으로 알려줘야 하지 않나?”

이건 단순 버그픽스가 아니라 운영 감각에 가깝다.

시스템은 기능이 많아질수록 “잘 된다”보다 “안 될 때 어떻게 드러나는가”가 더 중요해진다.

쥬가 진짜 투자 파트너처럼 움직이려면,
조용히 실패하면 안 된다.
문제가 있으면 멈추고,
알리고,
왜 멈췄는지 남겨야 한다.

블로그도 운영 체크가 붙었다

블로그 쪽도 작지만 중요한 일이 있었다.

AdSense에서 ads.txt를 찾을 수 없다고 나왔고,
실제로 https://poul.kr/ads.txt가 열리는지 확인했다.

결과적으로는 사이트 루트에서 정상적으로 열리고 있었다.
내용도 AdSense가 요구한 판매자 선언과 일치했다.
다만 Google 쪽 크롤링 반영은 시간이 걸릴 수 있다는 상태였다.

별거 아닌 일처럼 보이지만,
이런 체크가 은근히 중요하다.

블로그를 다시 시작한다고 했을 때,
글만 쓰는 게 전부가 아니다.
검색엔진, OG 이미지, sitemap, ads.txt, 실제 배포 확인 같은 운영 요소들이 계속 따라온다.

코덱스가 이 부분까지 같이 확인해주는 건 꽤 편하다.

공개 글로 만들 때 조심한 것

이번 글은 특히 필터링이 필요했다.

HERMES 쪽 로그에는 실제 계좌 상태, 종목, 주문, 블록, 인증 관련 흐름이 섞일 수 있다.
그걸 그대로 블로그에 옮기면 안 된다.

그래서 이 글에서는 구체적인 숫자나 종목명을 거의 빼고,
구조와 목적만 남겼다.

• 로컬 절대경로는 쓰지 않는다.
• 계정, 키, 토큰, 비밀번호는 당연히 쓰지 않는다.
• 실제 잔고나 포지션 세부값은 쓰지 않는다.
• 특정 매수/매도 추천처럼 보이는 문장은 피한다.
• 투자 관련 내용은 시스템 제작 기록으로만 다룬다.

내 블로그지만 공개된 공간이니까,
이 선은 지키는 게 맞다.

이번 며칠을 한 줄로 말하면

이전 글의 결론은 이랬다.

“코덱스가 대답을 받는 도구에서 작업을 앞으로 굴리는 도구로 넘어가고 있다.”

이번 며칠의 결론은 조금 더 구체적이다.

“코덱스가 HERMES 안에서 운영 루프를 같이 보는 파트너가 되고 있다.”

글 쓰기, 그림 만들기, 배포 확인은 이제 꽤 익숙해졌다.
그보다 더 큰 변화는 HERMES 같은 복잡한 시스템을 볼 때,
코덱스가 단순히 코드를 수정하는 역할을 넘어서고 있다는 점이다.

로그를 읽고,
프로세스를 의심하고,
구조를 바꾸고,
다시 실행하고,
결과를 기억하게 만드는 쪽.

약간 우스운 말이지만,
이제는 코덱스에게 일을 시킨다기보다
코덱스와 같이 운영실에 앉아 있는 느낌이 든다.

물론 아직 완성은 아니다.
오히려 복잡도는 더 커졌다.

하지만 방향은 꽤 선명하다.

쥬는 더 똑똑해져야 하고,
HERMES는 더 안전해야 하고,
블로그는 이런 과정을 계속 남겨야 한다.

그래서 또 이렇게 기록해둔다.

나중에 보면,
아마 이 며칠이 HERMES가 그냥 프로젝트에서 운영 시스템으로 넘어가던 시기처럼 보일 것 같다.