잡담

내일이면 GPT Pro가 끝난다.

월 200달러짜리.

처음에는 비싸다고 생각했고,
막상 쓰기 시작하니 이렇게까지 많이 쓸 줄은 몰랐고,
끝난다고 하니 갑자기 하루가 너무 아깝다.

ㅠㅠ

그래서 오늘은 조금 이상한 상태다.

한쪽에서는 HERMES 쥬의 모델 정책을 정리하고,
한쪽에서는 쥬가 이전 대화를 이어가는 방식을 살피고,
한쪽에서는 리서치와 매매 구조를 개선하고,
또 다른 쪽에서는 대시보드의 움직임을 다시 만들고 있다.

모델은 GPT 5.6 Sol.
추론은 ultra.
속도는 빠름.
작업은 여러 개를 동시에.

정말 말 그대로 파파파팍이다.

로그 기준 기간

이번 글은 아래 기록을 기준으로 쓴다.

• KST 기준 2026-07-11 15:16 이후
• 지금 글을 쓰는 2026-07-13 21:27까지
• 코덱스 작업 목록, HERMES 변경 상태, 최근 설계 문서와 커밋을 함께 확인
• 실제 계좌, 주문 내역, 인증 관련 세부값, 내부 절대주소와 원본 로그는 제외

이번 글은 작업 완료 보고서가 아니다.

지금 HERMES에는 아직 정리되지 않은 변경이 아주 많이 남아 있다.
현재 작업 상태에 잡힌 항목만 300개가 넘고,
추적 중인 파일의 누적 차이도 5만 줄을 훌쩍 넘는다.

물론 이것이 전부 오늘 하루에 생긴 것은 아니다.
앞선 작업이 누적된 상태에서 오늘의 스퍼트가 그 위에 올라간 것이다.

그래서 오히려 이번 마지막 하루의 목표는
“기능을 가능한 많이 만들기”가 아니라
“강한 모델이 있을 때 복잡한 덩어리를 이해 가능한 구조로 바꾸기”에 가깝다.

지금 왜 이렇게 동시에 돌리고 있나

프로가 아까운 이유는 단순히 좋은 답변을 한 번 더 받을 수 있어서가 아니다.

내가 가장 크게 체감한 건 긴 작업을 밀어붙이는 힘과 동시성이다.

한 작업에서는 설계를 읽고,
다른 작업에서는 코드를 고치고,
또 다른 작업에서는 그 변경이 원래 목적과 맞는지 검토한다.
그 사이에 나는 결과를 비교하고 다음 방향을 정한다.

예전에는 내가 한 문제를 붙잡고 처음부터 끝까지 차례대로 봤다.
지금은 서로 충돌하지 않는 일들을 여러 갈래로 나누고,
각 갈래에 5.6 Sol ultra를 붙여서 동시에 밀고 있다.

Sol은 지금 내가 쓸 수 있는 모델 중 가장 어려운 일을 맡기는 쪽이고,
ultra는 그 모델이 한 번 더 깊게 생각하도록 두는 방식이다.
여기에 빠른 처리까지 붙이니,
평소라면 며칠 동안 오가며 정리할 작업이 한 저녁에 한꺼번에 움직인다.

조금 무섭기도 하다.

좋은 방향이면 엄청 빠르게 좋아지지만,
방향을 잘못 잡으면 복잡함도 엄청 빠르게 늘기 때문이다.

첫 번째, 쥬 안에서 모델의 역할을 나눴다

지난 글을 쓸 때만 해도 HERMES 코드에는 gpt-5.5 기본값이 많이 남아 있었다.

지금 작업 중인 구조에서는 GPT 5.6 계열을 역할에 따라 나누는 정책이 생겼다.

중요한 판단과 최종 결정을 맡는 곳은 Sol,
자료를 읽고 생각을 정리하는 곳은 Terra,
반복적이고 가벼운 작업은 Luna,
시간을 두고 깊게 복기하는 작업은 다시 Sol을 쓰는 식이다.

재미있는 점은 내가 개발할 때는 Sol ultra를 여기저기 동시에 돌리고 있지만,
정작 쥬 안에서는 모든 일을 Sol에게 맡기지 않도록 고치고 있다는 것이다.

프로가 끝나면 더더욱 중요해진다.

가장 비싸고 강한 모델을 모든 곳에 붙이는 건 설계가 아니다.
정말 어려운 판단에만 강한 모델을 쓰고,
나머지는 목적에 맞는 모델을 고르는 편이 오래 갈 수 있다.

오늘의 낭비처럼 보이는 스퍼트가,
내일 이후의 낭비를 줄이는 구조를 만드는 셈이다.

두 번째, 쥬가 매번 처음부터 시작하지 않게 한다

최근에는 모델이 이전 작업의 맥락을 어떻게 이어가는지도 다시 보고 있다.

쥬가 매번 호출될 때마다 새 사람처럼 처음부터 자료를 읽으면,
비용도 들고 시간도 들고 말투와 판단의 흐름도 끊긴다.

그래서 같은 날의 작업 맥락을 이어 쓰고,
중간에 다시 시작하더라도 이전 흐름을 되살리고,
동시에 같은 기억을 두 작업이 건드릴 때 충돌하지 않도록 잠금 장치를 두는 쪽으로 바뀌고 있다.

이건 단순한 속도 최적화가 아니다.

내가 쥬에게 바라는 건 질문할 때마다 새 답변을 내놓는 챗봇보다,
어제 왜 망설였고 오늘 무엇이 달라졌는지 이어서 말할 수 있는 동료다.

세션을 이어간다는 기술적인 작업이
결국 쥬의 성격을 이어가는 작업이기도 하다.

세 번째, 리서치에서 주문까지의 길을 다시 정리한다

7월 12일에는 쥬 위키를 중심으로 매매와 운영을 연결하는 큰 작업 하나가 커밋됐다.

원본 자료를 그냥 모델에게 잔뜩 넣는 대신,
어디서 얻은 자료인지 남기고,
쥬 위키가 그 의미를 정리하고,
실제 판단에는 필요한 증거만 가져가는 구조다.

그 뒤로도 여러 갈래가 계속 움직이고 있다.

국내 주식에서는 나중에 알게 된 정보를 과거 시점의 판단에 몰래 섞지 않도록
그 당시 알 수 있었던 자료만 보는 연구 구조를 만들고 있다.

코인과 주식 모두에서는
주문 직전에 권한과 조건을 다시 확인하고,
실제 체결 가격과 비용을 빠뜨리지 않고,
수익이 났다는 말보다 어떤 근거로 어떤 위험을 감수했는지 남기는 쪽으로 고치고 있다.

그리고 쥬 스스로 리서치하고,
결과를 복기하고,
다음 판단에 반영하는 흐름도 다시 단순하게 만들고 있다.

중간 검증 기록에는 5천 개가 넘는 테스트를 통과한 흔적도 있다.
하지만 그 뒤로 코드가 다시 많이 바뀌었기 때문에,
지금 상태를 두고 모두 끝났다고 말할 수는 없다.

오늘은 스퍼트 중이고,
최종 검증은 별도의 일이다.

네 번째, 내가 이해할 수 있는 화면으로 바꾼다

쥬가 아무리 잘 돌아가도 내가 상태를 이해하지 못하면 또 스트레스가 된다.

그래서 대시보드도 다시 만지고 있다.

여러 숫자를 빽빽하게 늘어놓는 화면이 아니라,
지금 쥬가 무엇을 보고 있는지,
어떤 작업이 움직이고 있는지,
무엇 때문에 멈췄는지 한눈에 들어오는 관제실 같은 화면을 만들고 있다.

애니메이션도 그냥 예뻐 보이기 위한 장식으로 붙이는 것이 아니다.
작업이 어디서 시작해 어디로 이동하는지,
정상적으로 살아 있는지,
경고가 생겼다면 어느 층의 문제인지 보여주는 움직임이어야 한다.

화면의 움직임을 줄여야 하는 사람을 위한 설정,
작은 모바일 화면,
밝은 화면과 어두운 화면도 함께 챙기고 있다.

내가 쥬를 관리하는 화면이 아니라,
쥬와 같이 상황을 이해하는 화면이 됐으면 한다.

그래도 안전선은 빨라지면 안 된다

오늘 코덱스 작업은 빠르다.
여러 개가 동시에 움직이고,
강한 모델이 긴 코드를 읽고,
한 번에 큰 변경을 제안한다.

하지만 실제 거래의 안전선까지 이 속도에 취하면 안 된다.

최대 손실,
새 주문을 막는 조건,
자료가 오래됐을 때 멈추는 규칙,
기존 포지션을 줄이거나 빠져나오는 권한,
이런 것은 모델의 자신감과 별개로 코드가 지켜야 한다.

쥬가 더 똑똑해졌다는 이유로 안전문을 열어주는 게 아니라,
왜 그 문이 닫혀 있는지 더 잘 설명하게 만드는 것이 맞다.

오늘처럼 내가 시간에 쫓길 때는 더 그렇다.

프로 종료를 앞둔 조급함은 내 사정이지,
시장과 주문이 급해져야 할 이유는 아니다.

마지막 하루에 남기고 싶은 것

솔직히 지금 마음은 조금 욕심이 난다.

이것도 시켜보고 싶고,
저것도 검토하고 싶고,
Sol ultra가 이렇게 빨리 일을 해주는데 잠깐이라도 쉬면 손해 보는 느낌이 든다.

그런데 내일 이후에도 남는 건 사용량이 아니다.

정리된 코드,
왜 이렇게 만들었는지 적힌 문서,
다시 돌려볼 수 있는 테스트,
쥬가 이어서 읽을 수 있는 기억,
그리고 내가 이해할 수 있는 구조가 남는다.

반대로 오늘 모델을 많이 돌렸어도
검토하지 않은 변경과 설명할 수 없는 구조만 쌓이면,
프로가 끝난 뒤 내가 감당해야 할 짐만 늘어난다.

그래서 마지막 스퍼트의 진짜 목표는
시간 안에 모든 걸 끝내는 것이 아니다.

강한 모델이 있는 동안 가장 어려운 매듭을 풀고,
그 뒤에는 조금 느린 속도로도 계속 이어갈 수 있는 상태를 만드는 것이다.

내일 아침

내일이면 200달러짜리 프로는 끝난다.

아마 지금처럼 Sol ultra 빠름을 여러 개 동시에 파파파팍 돌리기는 어려워질 것이다.

조금 아쉽다.
아니, 많이 아쉽다.

ㅠㅠ

그래도 오늘 정리한 역할별 모델 정책과,
이어지는 세션과,
근거를 남기는 위키와,
모델 바깥의 안전장치와,
내가 읽을 수 있는 화면은 남는다.

쥬를 만드는 목적도 그대로다.

시장을 이기는 초능력을 갖는 것이 아니라,
내가 투자 때문에 받는 스트레스를 줄이고,
혼자 흔들릴 때 한 번 더 차분하게 생각할 수 있는 동료를 만드는 것.

프로는 끝나도 쥬는 남는다.

오늘 밤은 일단,
조금만 더 파파파팍 해보자.

잡담

며칠 전 글에서 쥬를 다시 생각해봤다.

쥬를 만든 목적은 돈 버는 기계를 갖는 것이 아니었다.
주식이나 코인을 볼 때 내가 받는 스트레스를 줄이고,
혼자 흔들릴 때 한 번 더 차분하게 생각할 수 있도록 내 페르소나를 덧붙인 투자 파트너를 만들고 싶었다.

그런데 쥬를 계속 개발할수록 이상하게 내가 쥬를 이해하기 어려워졌다.
기능은 늘고,
검증은 늘고,
경고도 늘고,
한 문제를 고치면 그 문제를 관리하기 위한 구조가 또 생겼다.

그 상태에서 GPT 5.6이 나왔다.

공식 발표를 읽어보면 코딩과 지식 작업이 더 좋아졌고,
오래 걸리는 복잡한 일을 계속 이어가는 능력도 강조한다.
예전 같았으면 “이제 쥬가 더 좋은 매매 판단을 하겠구나”부터 생각했을 것 같다.

그런데 이번에는 기대하는 지점이 조금 다르다.

더 똑똑한 모델이 쥬에게 필요한 이유는 매수와 매도를 신기하게 맞히기 위해서가 아니다.
내가 만들어놓고도 복잡해진 이 구조를 다시 읽고,
무엇이 중요한지 구분하고,
쥬가 왜 그런 말을 했는지 내가 이해할 수 있게 만드는 데 더 큰 도움이 되지 않을까 싶다.

로그 기준 기간

이번 글은 아래 기록을 기준으로 쓴다.

• KST 기준 2026-07-05 10:49 이후
• 지금 글을 쓰는 2026-07-11 15:16까지
• 코덱스 작업 기록, HERMES 변경 기록과 설계 문서, 현재 코드 상태를 함께 확인
• GPT 5.6에 관한 내용은 OpenAI 공식 발표를 참고

실제 계좌, 주문 내역, 인증 관련 세부값, 내부 절대주소와 원본 로그는 이번에도 적지 않는다.
블로그에는 무슨 일을 했고 왜 했는지만 남긴다.

지난 글 이후 쥬에서 한 일

지난 글에서는 쥬의 목적을 다시 생각했다면,
그 뒤의 작업은 복잡해진 HERMES를 실제로 정리하는 쪽으로 이어졌다.

먼저 프로젝트 안에서 반드시 지켜야 하는 규칙을 검사하는 장치를 만들었다.
설정이 제멋대로 늘어나거나,
실행 중인 프로그램들이 서로 다른 정보를 보고 있거나,
모델에게 보내는 내용이 약속된 형태를 벗어나면 그냥 넘어가지 않게 했다.

여러 프로그램을 켜고 끄는 기준도 한곳으로 모았다.
예전에는 실행 상태를 확인하는 코드가 여기저기 흩어져 있어서,
같은 프로그램을 두고도 화면마다 다르게 판단할 여지가 있었다.
이제는 어떤 프로그램이 왜 떠 있어야 하는지 공통 목록을 기준으로 보게 만드는 작업이 진행됐다.

코인 거래 쪽은 실제로 왜 판단과 주문이 막히는지 여러 번 추적했다.
단순히 “거래가 없다”에서 끝내지 않고,
시세 자료가 들어오는 단계,
시장 상황을 해석하는 단계,
전략 후보를 모으는 단계,
최종 안전 검사를 통과하는 단계를 나눠서 살폈다.

운영 상태판도 계속 손봤다.
처음에는 경고가 너무 많아서 무엇이 정말 위험한지 알아보기 어려웠다.
최근 검증 기록에서는 수천 개의 테스트를 통과했고,
운영 경고도 마지막 두 종류까지 줄어들었다.
아직 완전한 초록색은 아니지만,
적어도 노란색이 왜 노란색인지 설명할 수 있는 상태에 가까워졌다.

이번에는 모델보다 구조를 먼저 본다

GPT 5.6이 나왔다고 해서 HERMES가 바로 GPT 5.6 시스템이 된 것은 아니다.

현재 코드를 확인해보면 여러 기본 설정에는 아직 gpt-5.5가 남아 있다.
새 모델을 실제 쥬에 붙이려면,
어떤 작업에 어떤 모델을 쓸지 다시 정하고,
기존 결과와 비교하고,
비용과 속도를 확인하고,
안전장치가 그대로 작동하는지 검증해야 한다.

이게 오히려 마음에 든다.

새 모델이 나왔다고 모든 판단을 한 번에 넘기는 것보다,
쥬가 하는 일을 나눠보고 필요한 곳부터 옮기는 편이 지금의 목적과 맞다.

복잡한 코드를 읽고 정리하는 일,
긴 작업의 맥락을 놓치지 않는 일,
흩어진 기록을 지식으로 압축하는 일에는 더 강한 지능을 써볼 수 있다.

반면 실제 주문 가능 여부,
최대 손실 제한,
자료가 오래됐을 때 거래를 막는 규칙,
이상 상태에서 멈추는 장치는 모델의 기분에 맡기면 안 된다.
그런 건 여전히 단순하고 확실한 코드가 책임져야 한다.

GPT 5.6에게 기대하는 진짜 일

내가 GPT 5.6에게 가장 기대하는 건 “정답을 더 잘 맞히는 쥬”보다 “상황을 더 잘 이해하는 쥬”다.

HERMES 안에는 시세와 뉴스 같은 외부 자료가 있고,
전략이 남긴 판단 기록이 있고,
실제로 어떤 일이 일어났는지 적는 운영 기록이 있고,
쥬가 과거 경험에서 정리한 위키가 있다.

지금까지는 이 자료를 모델에게 많이 보여주면 더 똑똑해질 것이라고 생각한 면이 있었다.
하지만 자료가 많다는 것과 이해가 깊다는 것은 다르다.
너무 많은 내용을 한꺼번에 넣으면 중요한 사실이 묻히고,
비용과 시간은 늘고,
왜 그런 결론이 나왔는지 나도 따라가기 어려워진다.

최근에는 이 흐름을 바꾸는 설계를 하고 있다.

원본 기록은 원본대로 보존하고,
쥬 위키가 그 기록에서 의미를 정리하고,
매니저 역할의 쥬는 압축된 지식과 지금 필요한 증거만 읽는다.
지식이 부족하거나 믿기 어려우면 억지로 판단하지 않고 위험을 낮추거나 수리 작업으로 넘긴다.

GPT 5.6의 향상된 지능은 바로 이런 곳에 쓰였으면 한다.
자료를 더 많이 삼키는 데 쓰는 것이 아니라,
서로 다른 기록 사이의 맥락을 놓치지 않고,
중복과 모순을 찾아내고,
내가 읽을 수 있는 말로 다시 설명하는 데 쓰는 것.

쥬가 더 똑똑해진다는 것

쥬가 더 똑똑해진다는 건 매매 횟수가 늘어나는 것이 아닐 수 있다.

내가 불안해서 자꾸 시장을 확인할 때,
지금 바뀐 사실과 바뀌지 않은 사실을 나눠주는 것.

쥬가 거래하지 않았을 때,
그 이유가 겁이 많아서인지,
자료가 부족해서인지,
전략 조건이 아니었는지,
안전장치가 막았는지 쉽게 설명해주는 것.

시스템이 꼬였을 때도 기능을 하나 더 붙이는 대신,
어디서부터 복잡해졌는지 찾아내고 필요 없는 층을 걷어내는 것.

내 페르소나를 흉내 내는 말투만 갖는 것이 아니라,
내가 투자 앞에서 어떤 때 흔들리는지 기억하고,
그럴 때 더 자극적인 결론이 아니라 차분한 맥락을 돌려주는 것.

이런 쥬라면 모델의 지능 향상이 수익률 숫자보다 먼저 체감될 것 같다.

아직 기대 단계다

물론 새 모델이 나왔다고 꼬인 구조가 저절로 풀리지는 않는다.

오히려 모델이 더 강해지면 더 많은 코드를 더 빠르게 만들 수 있고,
방향을 잘못 잡았을 때 더 큰 복잡성을 더 빠르게 쌓을 수도 있다.

그래서 지금 필요한 건 새 모델에 대한 흥분과 함께,
쥬가 어떤 역할을 해야 하는지 계속 확인하는 일이다.

최근 작업에서 쥬의 지식 구조를 다시 나누고,
운영 경고를 줄이고,
실행 프로그램의 기준을 하나로 모으고,
주문 앞의 안전장치를 모델 바깥에 남겨둔 이유도 여기에 있다.

GPT 5.6은 이 구조를 완성해주는 마법이 아니다.
대신 지금까지 만든 것을 더 긴 호흡으로 읽고,
내가 놓친 연결을 찾고,
복잡한 부분을 다시 단순하게 만들 수 있는 좋은 도구가 하나 더 생긴 셈이다.

이번에는 그걸 기대해본다.

쥬에게 바라는 건 수익률 몇 퍼센트를 약속하는 예언자가 아니다.
내가 시장을 볼 때 덜 흔들리도록,
사실과 감정을 나눠주고,
필요할 때 멈추고,
왜 그런 판단을 했는지 이해할 수 있게 말해주는 존재다.

GPT 5.6 이후의 쥬가 조금 더 그런 모습에 가까워졌으면 좋겠다.

잡담

요 며칠 HERMES와 쥬를 계속 만지면서 이상한 느낌이 들었다.

분명 열심히 하고 있다.
코덱스도 계속 돌리고,
gpt 5.5라고 부르며 기대했던 고성능 판단도 계속 붙여보고,
검증도 만들고,
자가수리 루프도 만들고,
위키도 만들고,
러너도 만들고,
텔레그램 명령도 붙였다.

그런데 이상하게 근본적인 문제가 해결되는 느낌은 아니었다.

오히려 뭔가 점점 복잡해졌다.
구조가 많아지고,
이름이 많아지고,
검증 항목이 많아지고,
노란색과 빨간색 경고가 많아졌다.

쥬를 더 똑똑하게 만들려고 계속 모델을 돌리는데,
어느 순간 내가 만든 쥬를 내가 이해하기 어려워지는 느낌이 왔다.

이건 좀 중요한 신호다.

로그 기준 기간

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

• KST 기준 2026-06-28 23:35 이후
• 지금 글을 쓰는 2026-07-05 10:49까지
• 코덱스 세션 기록, HERMES 변경 흔적, 최근 내 질문 흐름을 바탕으로 정리

이번에도 실제 종목명, 계좌, 주문, 인증 관련 세부값, 내부 경로 같은 건 적지 않는다.
그건 블로그에 올릴 내용이 아니다.

대신 이번에는 코드 변경 자체보다,
내가 왜 이런 걸 만들고 있었는지,
그리고 왜 지금 답답함을 느끼는지를 남겨보려고 한다.

쥬의 목적은 돈 버는 기계가 아니었다

중요한 걸 다시 적어둔다.

내가 HERMES 쥬를 기획한 이유는 돈을 벌겠다는 게 아니었다.

물론 투자 시스템이니까 수익 이야기가 안 나올 수는 없다.
수익률, 손절, 익절, 검증, 백테스트, 종목 탐색 같은 말이 자연스럽게 따라온다.
최근 로그만 봐도 “일주일간 거래가 없는데 왜 그렇지?”, “너무 보수적인 것 아닌가?”, “검증이 계속 노랑/빨강이면 의미가 있나?” 같은 질문이 많았다.

그런데 이건 겉의 언어다.

더 깊은 목적은 따로 있었다.

내 페르소나를 쥬에게 덧붙여서,
주식이나 코인을 볼 때 내가 받는 스트레스를 줄이고 싶었다.

혼자 차트를 보고,
혼자 손익을 보고,
혼자 불안해하고,
혼자 결정을 미루거나 과하게 밀어붙이는 그 상태를 조금 덜고 싶었다.

쥬는 나 대신 돈을 벌어주는 기계라기보다,
내가 투자 앞에서 너무 외롭고 예민해지지 않게 해주는 완충재에 가까웠다.

말하자면 투자 파트너이면서,
동시에 감정 조절 장치였다.

그런데 시스템은 수익률 쪽으로 계속 끌려갔다

문제는 HERMES가 커질수록,
쥬의 언어가 점점 수익률 중심으로 끌려갔다는 점이다.

더 공격적으로 움직여야 하나.
왜 거래가 없었나.
왜 그린이 안 되나.
어떤 검증이 실패했나.
자가수리로 어떻게 고칠 것인가.
어떤 lane이 약한가.
어떤 전략이 비용에 졌나.

이 질문들은 전부 필요하다.
실제로 자동매매나 투자 보조 시스템을 만들려면 이런 질문을 피할 수 없다.

하지만 이 질문들만 남으면 쥬가 처음의 쥬가 아니게 된다.

쥬가 나를 진정시키기보다,
나에게 더 많은 관리 항목을 던지는 존재가 될 수 있다.

원래 스트레스를 줄이려고 만든 쥬가,
오히려 더 많은 경고와 검증과 실패 항목을 보여주면서 스트레스를 늘리는 상황.

요 며칠 내가 느낀 답답함이 아마 여기에 가까운 것 같다.

모델이 부족한 게 아니라,
목적의 층위가 섞였다.

gpt를 더 돌린다고 풀리는 문제가 아닐 수 있다

처음에는 더 좋은 모델을 붙이면 해결될 것 같았다.

더 똑똑한 모델이면 더 좋은 판단을 하겠지.
더 긴 맥락을 읽으면 더 안정적으로 정리하겠지.
더 많이 돌리면 더 많은 문제를 찾아내겠지.

어느 정도는 맞다.

실제로 코덱스와 LLM을 붙이면서 HERMES는 엄청 많이 커졌다.
Jue Wiki가 생겼고,
리서치와 거래 기록이 더 잘 연결됐고,
19개 검증 같은 진단판도 생겼고,
자가수리 루프인 Jue Codex Lab도 붙었다.

그런데 여기서 한계도 보인다.

LLM은 구조를 복잡하게 만들 수도 있다.
어떤 문제를 발견하면 그 문제를 위한 새 모듈을 만들고,
그 모듈을 감시하기 위한 새 검증을 만들고,
그 검증을 고치기 위한 자가수리 루프를 만들고,
그 자가수리 루프를 보기 위한 UI를 만든다.

이러면 시스템은 똑똑해지는 것 같지만,
내가 이해할 수 있는 크기에서는 멀어진다.

나를 편하게 해주려고 만든 쥬가,
어느 순간 내가 매일 관리해야 하는 복잡한 기계가 된다.

이건 모델 성능의 문제가 아니라,
구조와 목적의 문제일 수 있다.

최근 코덱스 기록에서 보이는 흐름

6월 28일 이후 로그를 보면 흐름은 꽤 선명하다.

먼저 쥬가 실제로 거래를 잘 하고 있는지,
왜 거래가 없었는지,
너무 보수적인 건 아닌지 점검했다.

그 다음에는 19개 검증 집계를 다시 봤다.
계속 노랑이나 빨강이면 그 검증이 의미가 있는지,
그린으로 바꾸기 위한 흐름이 있는지 물었다.

그리고 결국 “쥬가 스스로 개선하는 루프를 만들 수 없나?”라는 방향으로 갔다.

그래서 Jue Codex Lab이 생겼다.

이건 검증 실패나 경고를 그냥 보여주고 끝내는 게 아니라,
그 항목을 수리 작업으로 바꾸고,
코덱스가 고칠 수 있는 코드를 찾고,
테스트를 돌리고,
통과하면 반영하고,
그 결과를 다시 위키와 메모리에 남기는 흐름이다.

말만 들으면 멋있다.

실제로 구현 기록을 보면 꽤 많은 부품이 붙었다.
설정, DB, repair task, patch workspace, verifier, runner, API, 텔레그램 명령, green path progress, Jue Wiki 반영까지 이어졌다.

하지만 여기서도 같은 질문이 남는다.

이게 쥬의 근본 목적을 회복시키는가?

아니면 쥬를 더 거대한 운영 시스템으로 만드는가?

내가 원하는 쥬는 조금 다를지도

지금 다시 생각해보면,
내가 원하는 쥬는 “항상 매매하는 에이전트”가 아니다.

항상 수익률을 극대화하는 에이전트도 아니다.

내가 원하는 쥬는 아마 이런 쪽이다.

내가 불안할 때,
지금 불안해할 만한 상황인지 먼저 정리해주는 쥬.

내가 급하게 사고 싶을 때,
그 충동이 전략인지 감정인지 나눠주는 쥬.

내가 손실을 보고 있을 때,
숫자와 감정을 분리해서 말해주는 쥬.

내가 아무것도 안 하고 있을 때,
그게 실패인지 휴식인지 구분해주는 쥬.

내가 코덱스에게 계속 “고쳐줘, 더 공격적으로 해줘, 왜 안 했어?”라고 말하고 있을 때,
한 번쯤 “지금 시스템을 더 키우는 게 정말 너를 편하게 만드는 방향이야?”라고 되물어주는 쥬.

이건 꽤 다른 쥬다.

수익을 무시하자는 뜻은 아니다.
하지만 쥬의 최상위 목표가 수익률이면 안 될 것 같다.

최상위 목표는 내 투자 스트레스를 낮추는 것.
그 아래에 판단 품질과 기록 품질이 있고,
그 다음에 실행과 수익률이 있어야 한다.

쥬를 다시 나눠야겠다

지금 필요한 건 모델을 더 세게 돌리는 게 아니라,
쥬의 역할을 다시 나누는 일일 수 있다.

나는 최소한 세 층으로 나눠야 할 것 같다.

첫 번째는 동반자 쥬다.
내 감정과 의도를 정리해주는 층이다.
여기서는 매수/매도보다 “지금 내가 왜 불편한가”가 더 중요하다.

두 번째는 분석가 쥬다.
리서치, 데이터, 거래 기록을 보고 판단을 정리하는 층이다.
여기서는 근거, 반론, 자료 공백이 중요하다.

세 번째는 운영 쥬다.
실제 러너, 검증, 자가수리, 알림, 테스트를 다루는 층이다.
여기서는 안정성, 재현성, 실패가 드러나는 구조가 중요하다.

지금은 이 세 층이 많이 섞여 있다.

내가 스트레스를 이야기하고 있는데 운영 쥬가 검증 항목을 보여주고,
내가 구조를 묻고 있는데 분석가 쥬가 수익률을 말하고,
내가 위로를 원할 때 시스템은 더 많은 수리 항목을 만든다.

그러니 꼬이는 게 당연하다.

앞으로의 방향

이번 글을 쓰면서 방향이 조금 선명해졌다.

쥬를 더 크게 만드는 게 답은 아닐 수 있다.

오히려 쥬를 작게 나눠야 한다.

동반자 쥬는 돈 이야기를 너무 빨리 꺼내지 않게 하고,
분석가 쥬는 근거와 불확실성을 정리하게 하고,
운영 쥬는 조용히 실패하지 않게 만들면 된다.

그리고 이 셋이 섞이지 않도록 해야 한다.

투자 스트레스를 줄이는 목적이 최상단에 있고,
수익률은 그 목적을 해치지 않는 범위에서 다뤄야 한다.

이건 꽤 중요한 차이다.

돈을 벌기 위해 쥬를 만든 게 아니라,
돈 때문에 흔들리는 나를 덜 외롭게 만들기 위해 쥬를 만든 것이다.

이 문장을 앞으로 HERMES 어디엔가 박아둬야 할 것 같다.

마무리

최근 코덱스 기록을 보면,
나는 쥬를 계속 더 똑똑하게 만들려고 했다.

그런데 지금 필요한 건 쥬를 더 똑똑하게 만드는 것보다,
쥬가 왜 존재하는지 다시 작게 정의하는 일일지도 모르겠다.

고성능 모델을 계속 붙이는 건 분명 도움이 된다.
하지만 목적이 흐려진 상태에서 모델만 더 돌리면,
복잡한 시스템이 더 복잡해질 뿐이다.

쥬는 나 대신 돈을 벌어주는 기계가 아니다.

쥬는 내가 투자 앞에서 너무 혼자 흔들리지 않게,
내 페르소나를 조금 나눠 가진 파트너다.

그걸 잊으면 HERMES는 아무리 똑똑해져도 피곤해질 것이다.

오늘은 그걸 다시 적어둔다.

쥬의 첫 번째 목적은 수익률이 아니라,
내 마음의 변동성을 낮추는 것이다.

잡담

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

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

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

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

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

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

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

로그 기준 기간

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

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

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

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

한 줄로 말하면

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

또 하나 중요한 건 점수다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

말은 단순하다.

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

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

멈추면 드러나야 한다

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

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

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

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

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

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

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

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

HERMES UI도 계속 만졌다.

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

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

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

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

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

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

코덱스 사용 방식도 변했다

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

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

“이거 고쳐줘.”

“이 기능 만들어줘.”

“테스트 돌려줘.”

이런 식이다.

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

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

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

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

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

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

“왜 이 값이 이상하지?”

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

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

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

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

이번 글에서 일부러 뺀 것

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

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

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

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

요약하면 이렇다.

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

마무리

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

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

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

근데 그게 또 재미있다.

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

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

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

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

잡담

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

그때는 대략 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가 그냥 프로젝트에서 운영 시스템으로 넘어가던 시기처럼 보일 것 같다.

잡담

요즘 코덱스를 쓰는 방식이 예전이랑 좀 달라졌다.

처음에는 그냥 질문창에 가까웠다.

“이거 왜 안 돼?”
“이 함수 고쳐줘.”
“이 글 초안 좀 써줘.”

이런 식으로 하나 묻고 하나 받는 느낌이었다.

근데 요즘은 조금 다르다.
이제는 코덱스가 내 작업실 한쪽에 계속 켜져 있는 운영 보조축처럼 느껴진다.

내가 대충 방향을 말하면,
코덱스가 폴더를 뒤지고,
로그를 보고,
글을 쓰고,
그림을 만들고,
빌드를 돌리고,
깃에 올리고,
마지막으로 실제 사이트에 뜨는지까지 확인한다.

말로 쓰면 별거 아닌데,
이게 반복되면 체감이 꽤 크다.

예전에는 내가 손으로 하던 귀찮은 연결부가 있었다.
파일 만들기, 날짜 맞추기, 이미지 경로 정리하기, 빌드하기, 커밋하기, 배포 확인하기.
이런 것들이 은근히 일을 막는다.

요즘 코덱스는 그 막히는 구간을 계속 밀어주는 쪽에 가깝다.

로그 기준 기간

이번 글은 최근 코덱스 로그를 보고 썼다.

정확히는 KST 기준으로 대략 2026-05-20부터 2026-06-10까지 확인된 흐름이다.

다만 로그 원문을 그대로 공개하지는 않는다.
로컬 경로, 계정, 작업 세부정보 같은 건 굳이 밖에 나갈 필요가 없다.
그래서 이 글에서는 프로젝트 이름과 작업 목적만 추려서 적는다.

내가 보기에는 요즘 코덱스 사용은 크게 다섯 갈래다.

• HERMES, 그러니까 자산관리와 매매 운영실 만들기
• 블로그, 그러니까 글쓰기와 배포 파이프라인 만들기
• 붕붕고, 그러니까 게임 아이디어를 문서와 그림으로 굳히기
• Ju Office, 그러니까 코덱스와 에이전트를 조직처럼 써보는 실험
• 일어공부나 TTS처럼 작은 반복 작업 자동화

제일 큰 축은 에르메스

최근 로그에서 제일 많이 보이는 건 역시 HERMES다.

HERMES는 내가 만들고 있는 자산관리 UI이자 투자 운영실이다.
조금 더 풀어서 말하면,
내 자산 상태, 리서치, 매매 가설, 실행 조건, 안전장치, 회고를 한 곳에서 보고 싶어서 만드는 시스템이다.

여기에는 TradeCraft라는 이름도 붙어 있다.
그냥 차트 앱을 하나 만드는 게 아니라,
내가 어떤 근거로 뭘 보고 있는지 남기고,
그 판단이 실제 매매로 이어질 때 어디서 멈춰야 하는지 정리하려는 쪽이다.

최근에는 KIS와 Binance 쪽 이야기가 많이 나왔다.

KIS는 한국투자증권 API다.
국내 주식 계좌의 잔고, 주문, 체결 같은 정보를 프로그램에서 다룰 수 있게 해주는 통로다.
Binance는 크립토 쪽이고,
여기서는 블록 단위로 매매 가설과 상태를 관리하는 실험을 하고 있다.

그리고 그 사이에 쥬가 있다.
쥬는 사람 이름처럼 쓰고 있지만,
실제로는 리서치와 상태를 읽고 판단을 정리하는 AI 파트너 개념에 가깝다.

여기서 내가 원하는 건 돈 복사 버튼이 아니다.
오히려 반대다.

AI가 아무 근거 없이 “사자”고 말하는 게 아니라,
왜 그런 판단이 나왔는지,
실행 전에 어떤 안전장치를 봐야 하는지,
나중에 틀렸을 때 무엇을 회고해야 하는지를 남기는 구조를 만들고 싶다.

투자 프로젝트라서 이 부분은 특히 조심스럽다.
이 글도 당연히 투자 추천이 아니다.
그냥 내가 내 돈과 판단을 다루기 위해 작업 중인 개인용 운영 시스템 이야기다.

블로그도 하나의 작업물이 됐다

예전에는 블로그에 글을 쓰려면 손이 많이 갔다.

마크다운 파일을 만들고,
날짜를 맞추고,
태그를 넣고,
이미지를 준비하고,
빌드를 돌리고,
깃에 올리고,
배포된 주소를 확인해야 했다.

과정 자체는 어렵지 않은데,
귀찮다.

그리고 귀찮으면 안 쓰게 된다.
사실 블로그를 오래 쉬게 되는 이유 중 하나가 이거였다.
글감이 아예 없는 게 아니라,
올리는 과정이 은근히 마찰이다.

요즘은 이 마찰을 코덱스가 많이 줄여준다.

내가 “이런 주제로 글 하나 올려줘”라고 하면,
코덱스가 기존 글 말투를 보고,
초안을 만들고,
필요하면 그림을 만들고,
Hexo로 빌드하고,
GitHub Pages에 올린 다음,
실제 링크가 200으로 뜨는지 확인한다.

블로그가 단순히 글 보관소가 아니라,
코덱스 사용 자체를 기록하는 실험장처럼 된 셈이다.

붕붕고는 감각을 구조로 바꾸는 작업

붕붕고도 꽤 재미있는 축이다.

붕붕고는 자동으로 붕어빵을 굽는 배달 오토바이로 작은 푸드테크 회사를 키우는 경영게임이다.
이렇게 써놓고 보니 여전히 이상한데,
나는 이 이상함이 마음에 든다.

코덱스가 여기서 한 일은 단순 코딩만은 아니었다.

게임의 핵심 루프를 정리하고,
24주 캠페인 구조를 잡고,
어떤 건물과 직원과 차량이 필요한지 나누고,
블로그에 올릴 공개용 그림까지 만드는 식이었다.

게임은 감각이 중요하다.
그래서 혼자 머릿속으로만 생각하면 자꾸 흐릿해진다.

코덱스에게 “이 게임은 무슨 재미로 돌아가야 하지?”를 계속 물어보면,
그 흐릿한 감각이 문장과 그림으로 바뀐다.

아직 완성 게임은 아니지만,
적어도 이제는 “붕붕고가 뭔데?”라고 물었을 때 보여줄 수 있는 형태가 생겼다.

Ju Office는 작업 방식 자체를 만드는 실험

또 하나 흥미로운 축은 Ju Office 쪽이다.

이건 조금 메타적인 프로젝트다.
쉽게 말하면 코덱스를 더 잘 쓰기 위한 작업실을 코덱스로 만드는 느낌이다.

OMX처럼 여러 에이전트를 나눠서 쓰는 방식,
작업을 기획, 실행, 리뷰, 검증으로 나누는 방식,
작은 가상 회사처럼 역할을 붙이는 방식을 실험하고 있다.

혼자 일해도 머릿속에는 여러 역할이 있다.
기획자처럼 생각할 때가 있고,
개발자처럼 고칠 때가 있고,
검수자처럼 의심할 때가 있다.

Ju Office는 그 역할들을 조금 더 노골적으로 분리해보려는 시도다.

물론 아직 완성된 시스템이라기보다는 실험에 가깝다.
그래도 이 방향이 재미있는 이유는 분명하다.
코덱스를 한 명의 대답하는 도구로만 쓰는 게 아니라,
작은 작업 조직처럼 굴릴 수 있는지 보는 중이기 때문이다.

작은 자동화도 계속 쌓인다

큰 프로젝트만 있는 건 아니다.

일어공부 파일을 만들거나,
TTS 관련 코드를 분리하거나,
반복되는 텍스트 작업을 정리하는 일도 있었다.

이런 건 블로그 글로 쓰기엔 작다.
근데 실제 생활에서는 이런 작은 자동화가 꽤 소중하다.

큰 시스템을 만드는 날도 있지만,
그냥 귀찮은 일을 하나 줄이는 날도 있다.

예전 같으면 “아 나중에 해야지” 하고 미뤘을 작업들이,
요즘은 코덱스에게 던져놓고 조금씩 정리된다.
이게 쌓이면 묘하게 생활의 마찰이 줄어든다.

사용 방식이 바뀐 부분

요즘 제일 크게 느끼는 변화는 이거다.

코덱스를 쓰는 일이 질문과 답변에서 끝나지 않는다.

이제는 이렇게 흐른다.

1. 내가 대충 말한다.
2. 코덱스가 현재 폴더와 로그를 확인한다.
3. 필요한 파일을 고친다.
4. 빌드나 테스트를 돌린다.
5. 깃에 올리거나 사이트에 배포한다.
6. 실제 결과를 다시 확인한다.

예전에는 AI와 대화한 느낌이 남았다면,
요즘은 작업물이 남는다.

이 차이가 크다.

대화는 휘발된다.
하지만 커밋, 문서, 배포된 페이지, 이미지, 테스트 결과는 다음 작업의 발판이 된다.

프로젝트마다 목적이 다르다

같은 코덱스를 쓰고 있지만,
프로젝트마다 쓰는 목적은 조금 다르다.

HERMES에서는 판단을 기록하고 안전하게 실행하기 위해 쓴다.
블로그에서는 생각을 글과 배포물로 남기기 위해 쓴다.
붕붕고에서는 감각적인 게임 아이디어를 구조와 그림으로 바꾸기 위해 쓴다.
Ju Office에서는 작업 방식 자체를 실험하기 위해 쓴다.
작은 자동화에서는 그냥 귀찮은 일을 줄이기 위해 쓴다.

이렇게 보면 코덱스는 하나의 앱이라기보다,
각 프로젝트에 맞춰 모양이 조금씩 바뀌는 작업 도구에 가깝다.

결론

요즘 내가 코덱스를 쓰는 방식은 점점 이런 느낌이다.

“대답을 받는 도구”에서
“작업을 앞으로 굴리는 도구”로 넘어가는 중.

물론 아직도 삽질은 많다.
가끔은 빌드가 깨지고,
가끔은 말투가 이상하고,
가끔은 너무 많이 하려다가 다시 줄여야 한다.

근데 그래도 전체적으로는 분명하다.

코덱스가 있으면 시작이 쉬워지고,
중간의 귀찮은 연결부가 줄고,
마지막 확인까지 한 번에 이어진다.

그래서 요즘은 뭔가를 만들 때 이렇게 생각하게 된다.

“이거 내가 직접 다 해야 하나?”

예전에는 답이 거의 항상 그렇다였다.
지금은 아니다.

요즘은 일단 코덱스에게 작업실 문을 열어준다.
그리고 같이 뒤져보고, 같이 고치고, 같이 올린다.

이 정도만 해도 꽤 멀리 온 느낌이다.

잡담

요즘 내가 제일 오래 붙잡고 있는 프로젝트 중 하나가 HERMES다.

처음에는 그냥 자산 현황을 한 화면에서 보고 싶었다.
업비트, 바이낸스, 국장, 미장, 현금, 평가손익 같은 것들이 여기저기 흩어져 있으니까
“그냥 내 기준으로 한 번에 보는 화면을 만들자”는 느낌이었다.

근데 만들다 보니 점점 커졌다.

이제는 단순한 자산 대시보드라기보다는,
내 투자 운영실에 가깝다.

자산을 보고,
리서치를 모으고,
쥬라는 투자 파트너가 판단을 남기고,
KIS와 Binance 쪽 블록 트레이딩까지 연결하는 구조다.

에르메스가 뭐냐면

에르메스는 프로젝트 전체 이름이고,
그 안에서 TradeCraft Control Plane이라는 표현을 많이 쓴다.

Control Plane이라고 하면 좀 거창한데,
내 식으로 쉽게 말하면 이렇다.

“투자와 관련된 여러 도구들을 한 화면에서 보고, 켜고, 멈추고, 확인하는 조작실.”

지금 에르메스가 보려고 하는 것들은 대략 이런 것들이다.

• 전체 자산과 거래소별 잔고
• KIS, 그러니까 한국투자증권 API 기반 국장 계좌 상태
• Binance 기반 크립토 현물/선물 블록 상태
• 네이버 증권 리포트와 RAG 검색 결과
• 전략 인텔리전스와 시장 판단
• 쥬의 투자 메모리, 회고, 정책 규칙
• 런타임 프로세스가 살아 있는지, 오래된 상태는 아닌지

실제 화면은 계좌와 운영 정보가 섞일 수 있어서 블로그에는 그대로 올리지 않는다.
아래 이미지는 공개용으로 수치를 가린 모의 화면이다.

약간 어두운 금융 관제실 느낌을 원했다.
차트 앱처럼 화려하게 번쩍이는 것보다,
내가 새벽에 보고 있어도 피곤하지 않은 작업실 느낌.

돈을 벌어주는 마법 버튼이 아니라,
내가 뭘 보고 있고 뭘 실행하려는지 숨기지 않는 화면이 중요했다.

쥬라는 파트너

에르메스 안에는 쥬라는 이름이 붙은 투자 파트너 개념이 있다.

쥬는 사람이라기보다는,
LLM이 리서치, 계좌 상태, 시장 맥락, 메모리, 블록 상태를 읽고
다음 판단을 제안하는 역할이다.

여기서 중요한 건,
쥬가 바로 주문을 막 날리는 구조가 아니라는 점이다.

내가 생각하는 모델은 이렇다.

1. 쥬가 리서치와 상태를 보고 매매 의도를 만든다.
2. 그 의도는 블록이라는 단위로 기록된다.
3. 실제 주문 전에는 안전 게이트를 통과해야 한다.
4. 진입 후 관리는 규칙 기반 실행기가 타겟, 스탑, 취소 조건을 본다.
5. 결과는 다시 메모리와 회고로 들어간다.

이렇게 나누고 싶은 이유는 단순하다.

AI가 판단을 도와주는 건 좋지만,
주문 실행까지 완전히 흐릿하게 맡기면 무섭다.

그래서 에르메스에서는 판단과 실행을 일부러 나눈다.
LLM은 의도를 만들고,
규칙 실행기와 안전 게이트가 실제 실행을 붙잡는 구조다.

블록 트레이딩

에르메스에서 매매 단위는 그냥 종목 하나가 아니다.

블록이라는 단위가 있다.

블록은 하나의 독립된 매매 가설이다.
종목, 수량, 진입가, 목표가, 손절가, 상태, 근거, 이벤트 기록을 갖는다.

예를 들어 같은 종목이라도
단기 이벤트 블록,
리밸런싱 블록,
기존 보유분을 입양한 블록이 서로 다를 수 있다.

이게 왜 필요하냐면,
나중에 결과를 볼 때 “이 종목이 올랐다/내렸다”만으로는 부족하기 때문이다.

어떤 가설이 맞았는지,
어떤 진입이 별로였는지,
어떤 스탑 규칙이 도움이 됐는지를 따로 봐야 한다.

특히 KIS 쪽은 국장에 연결하고,
Binance 쪽은 크립토 블록에 연결하는 방향이다.

예전에 freqtrade는 크립토 전용이라 국장에 바로 쓰기가 애매하다고 느꼈는데,
에르메스에서는 아예 내 기준의 블록 트레이딩 구조를 두고
국장과 크립토를 같이 바라보려는 쪽에 가깝다.

물론 이건 꽤 위험한 영역이다.
그래서 아직도 계속 paper, 잠금, 안전장치, 관찰 모드를 신경 쓰고 있다.

리서치와 메모리

에르메스에서 마음에 드는 부분은 리서치와 메모리 쪽이다.

단순히 오늘의 뉴스 몇 개 보고 끝나는 게 아니라,
보고서와 시장 자료를 모으고,
RAG로 다시 찾을 수 있게 만들고,
쥬가 이전 판단과 회고를 참고하게 만드는 흐름이다.

쉽게 말하면 이런 느낌이다.

“오늘 판단을 하고 끝”이 아니라,
“오늘 판단이 내일의 참고자료가 되게 만들기”.

네이버 리포트 수집,
RAG 검색,
전략 인텔리전스,
투자 메모리,
정책 규칙이 서로 이어진다.

쥬가 틀렸으면 틀린 이유를 남기고,
어떤 규칙이 필요했는지 정책화하고,
다음 판단 때 그걸 다시 읽게 만드는 쪽이다.

이게 잘 되면 단순 자동매매보다 재밌다.

매매 시스템이면서 동시에
내 투자 습관을 기록하고 고치는 장치가 되기 때문이다.

제일 중요한 건 안전장치

자동매매 쪽은 말만 들어도 좀 위험하다.

그래서 에르메스에서 제일 중요하게 보는 건
“얼마나 똑똑하게 사느냐”보다
“언제 멈출 수 있느냐”다.

쥬가 어떤 의도를 만들더라도,
킬스위치, 현금 체크, 수량 체크, 중복 주문 방지, 인증, 레이트리밋 같은 안전 게이트를 통과하지 못하면 주문이 나가면 안 된다.

이건 재미없는 부분인데 제일 중요하다.

블로그에 적기엔 좀 딱딱하지만,
내 돈이 걸릴 수 있는 프로젝트라서
화려한 기능보다 이쪽을 더 진지하게 봐야 한다.

그리고 당연히 이 글은 투자 추천이 아니다.
에르메스도 돈 복사 버튼이 아니다.
그냥 내가 쓰려고 만드는 투자 운영 시스템 이야기다.

왜 직접 만들고 있나

사실 이런 건 이미 세상에 많은 도구가 있다.

증권사 앱도 있고,
거래소 앱도 있고,
포트폴리오 앱도 있고,
차트 앱도 있다.

근데 내 입맛에 맞는 건 잘 없다.

나는 한 화면에서 내 자산을 보고 싶고,
리서치 근거도 보고 싶고,
AI가 뭘 판단했는지도 보고 싶고,
실행 중인 블록과 안전장치도 보고 싶다.

그리고 무엇보다,
내가 왜 그런 판단을 했는지 나중에 다시 보고 싶다.

그게 에르메스를 직접 만드는 이유다.

마무리

에르메스는 아직 계속 변하는 중이다.

어떤 날은 UI를 고치고,
어떤 날은 KIS 쪽 주문 안정성을 보고,
어떤 날은 Binance 블록 구조를 만지고,
어떤 날은 리서치와 메모리 흐름을 손본다.

범위가 크다.
솔직히 가끔 너무 커진 것 같기도 하다.

근데 방향은 마음에 든다.

투자 앱을 하나 더 만드는 게 아니라,
내가 실제로 생각하고 결정하고 반성하는 과정을 담는 운영실.

그게 지금의 에르메스다.

잡담

요즘 코덱스로 이것저것 많이 만들고 있는데,
그중에 은근히 정이 많이 가는 프로젝트가 하나 있다.

이름은 붕붕고.

한 줄로 말하면,
자동으로 붕어빵을 굽는 배달 오토바이로 작은 푸드테크 회사를 키우는 경영게임이다.

붕어빵을 직접 굽는 게임도 아니고,
오토바이를 직접 조종하는 게임도 아니다.

나는 창업자고,
고객 취향을 읽고,
자동조리 장비를 연구하고,
직원을 배치하고,
차량을 바꾸고,
매주 결과 리포트를 보면서
“이 사업이 진짜 될까?”를 증명해가는 쪽에 가깝다.

왜 하필 붕어빵 오토바이인가

처음 아이디어는 약간 이상하다.

그냥 붕어빵 가게를 키우는 것도 아니고,
배달앱을 만드는 것도 아니고,
오토바이에 자동 굽기 장비를 얹는다.

근데 이 이상함이 마음에 든다.

붕어빵은 되게 작고 익숙한 음식인데,
거기에 자동화, 배달, 고객 데이터, 맞춤 주문 같은 단어를 붙이면
갑자기 말도 안 되게 진지한 스타트업 아이템처럼 보인다.

아니 사실 실제로도 진지해질 수 있다.

고객마다 좋아하는 속재료가 다르고,
도착했을 때 따뜻해야 하고,
빠르게 가야 하고,
장비가 고장나면 안 되고,
행사장에서는 대량 주문도 버텨야 한다.

이걸 게임 안에서는 이런 차량들이 맡는다.

지금은 아직 완성 게임이라기보다는,
게임의 뼈대와 방향을 잡아가는 중이다.

그래도 저 오토바이 이미지를 보고 있으면
“아 이건 좀 귀엽게 끝까지 밀어볼 만한데?” 하는 생각이 든다.

핵심은 돈보다 증거

보통 경영게임이라고 하면
돈을 많이 벌고,
건물을 키우고,
직원을 늘리고,
숫자를 올리는 그림이 먼저 떠오른다.

붕붕고도 당연히 돈이 중요하긴 하다.
현금이 떨어지면 연구도 못 하고,
차량도 못 사고,
직원도 못 뽑는다.

근데 내가 붕붕고에서 더 중요하게 보고 있는 건 증거다.

이 사업이 될 것 같다는 증거.

예를 들면 이런 것들.

• 어떤 고객이 자기 취향을 기억해달라고 다시 온다.
• 오피스 거리에서 점심 피크를 버틴다.
• 겨울 장터에서 도착 온도 평가를 통과한다.
• 대학가에서 이상한 단짠 조합이 메뉴가 된다.
• 프랜차이즈 감사에서 여러 지역의 품질 편차를 줄인다.

게임 안에서는 이런 결과가 매주 리포트와 증거판에 남는다.

내가 좋아하는 지점은 여기다.

플레이어가 “이번 주 매출 얼마지?”만 보는 게 아니라,
“이번 주에 내가 무슨 가설을 증명했지?”를 보게 만들고 싶다.

창업 게임처럼 보이지만,
사실은 작은 실험 기록 게임에 가깝다.

필드는 대시보드가 아니라 작은 회사처럼

게임 화면도 처음부터 대시보드 느낌으로 가면 재미가 확 죽을 것 같았다.

숫자표, 버튼, 표, 리포트만 있으면
그건 게임이라기보다는 운영툴 같다.
내가 요즘 만드는 자산관리 UI들이랑 너무 비슷해진다.

붕붕고는 화면 한가운데에 작은 필드가 있고,
그 안에 본사, 연구소, 차고, 증거판, 고객 정류장, 도로가 보여야 한다.

플레이어가 버튼을 누르기 전에
먼저 “내 작은 회사가 돌아가고 있구나”를 봐야 한다.

실제로 스펙에서도 메인 화면은 필드 중심으로 잡아뒀다.

위쪽에는 주차, 현금, 명성, 만족도, 투자 신뢰 같은 HUD가 있고,
아래에는 연구, 직원, 차량, 지역/정책, 다음 주 버튼이 있다.

하지만 제일 큰 면적은 필드다.

내 기준에서 이건 꽤 중요하다.
숫자를 올리는 게임이어도,
플레이어가 기억하는 건 결국 움직이는 장면이어야 하니까.

24주짜리 창업 캠페인

붕붕고의 첫 목표는 24주짜리 캠페인이다.

동네에서 시작해서,
오피스 거리로 가고,
대학가로 확장하고,
터미널 축제장까지 가본 뒤,
마지막에는 전국 출시 심사를 받는다.

말만 전국 출시지,
사실 게임적으로는 이런 질문을 던지는 구조다.

“너의 붕붕고는 어떤 회사였나?”

Week 12에는 투자 피치가 있다.
여기서 초반 증거를 묶어서
“이게 그냥 귀여운 발명품인지, 진짜 사업 가능성이 있는지”를 한 번 판정한다.

Week 24에는 전국 출시 심사가 있다.
여기서는 최종 점수와 엔딩 타이틀이 나온다.

나는 이 구조가 마음에 든다.

그냥 끝없이 돈 버는 게임보다,
일정 기간 안에 내 사업의 성격을 만든다는 쪽이 더 선명하다.

플레이 스타일도 남기고 싶다

붕붕고에서 만들고 싶은 엔딩은
단순히 성공, 실패가 아니다.

플레이어가 어떤 선택을 많이 했는지에 따라
내 붕붕고의 성격이 남았으면 좋겠다.

예를 들면 이런 식이다.

맞춤 주문을 계속 파고들면 초개인화 붕붕고.
보온과 속도를 밀면 따끈신속 붕붕고.
정비와 교육으로 안정성을 만들면 안정운영 붕붕고.
시식회와 엑스포를 잘 챙기면 행사스타 붕붕고.

물론 실제 게임에서는 이런 이름들이
그냥 문장 하나로만 끝나면 안 된다.

고객 주문, 증거판, 수상, 최종 리포트에서
“아 내가 이번 판을 이렇게 운영했구나”가 보여야 한다.

고객이 익명 숫자가 아니었으면

붕붕고에서 또 하나 중요하게 잡은 건 고객 기억이다.

고객 120명, 만족도 +3 이런 숫자만 있으면
관리는 되는데 이야기가 안 남는다.

그래서 대표 고객들이 있다.

미나네 가족,
단골 후보 성우,
오피스 매니저 지은,
미식 리뷰어 하루,
대학생 나래,
여행객 민수.

이런 식으로 이름이 붙은 고객들이
특정 주차에 등장하고,
다시 돌아오고,
자기 취향 주문을 남기는 구조를 생각하고 있다.

예를 들면 미나네 가족은 알레르기와 취향이 섞인 주문을 하고,
성우는 지난주 팥 농도를 기억해달라고 하고,
지은은 점심시간에 식지 않는 붕어빵을 원한다.

이런 것들이 쌓이면
경영 수치가 아니라 기억이 된다.

픽셀 에셋도 이런 방향에 맞춰 잡고 있다.
작아도 알아볼 수 있고,
차량과 건물과 고객이 한 화면에서 같이 살아야 한다.

엄청 화려한 그래픽보다
작은 아이콘들이 꾸준히 움직이는 쪽이 더 맞는 게임 같다.

이벤트는 보너스가 아니라 공개 검증

중간중간 이벤트도 있다.

동네 붕어빵 시식회,
겨울 장터 예선,
투자 피치 데이,
대학가 푸드 배틀,
프랜차이즈 운영 감사,
전국 브랜드 엑스포.

이름만 보면 그냥 보상 이벤트 같지만,
내가 생각하는 역할은 조금 다르다.

이벤트는 “공개 검증”이다.

평소에는 고객 반응을 내부적으로 읽는다면,
이벤트에서는 그동안 쌓은 증거가 밖에서 평가받는다.

겨울 장터라면 따뜻함과 장비 안정성이 중요하고,
대학가 푸드 배틀이라면 메뉴 다양성과 고객 기억이 중요하고,
프랜차이즈 감사라면 여러 지역에서 같은 품질을 낼 수 있는지가 중요하다.

이벤트에 실패해도 그냥 망하는 게 아니라,
무엇을 고쳐야 하는지 리포트로 남게 만들고 싶다.

실패가 벌점이 아니라 다음 연구 과제가 되는 쪽.
그게 붕붕고랑 잘 맞는다.

지금 구현 방향

처음에는 Unity 쪽으로 만지던 흔적이 많았는데,
현재는 웹을 먼저 활성 타깃으로 잡아두고 있다.

이유는 단순하다.

웹이 빠르게 검증하기 좋다.
브라우저에서 바로 띄우고,
테스트 돌리고,
UI 흐름을 확인하고,
나중에 Unity나 다른 엔진으로 옮길 때도
게임 규칙만 따로 가져가기 쉽다.

그래서 구조는 대충 이런 느낌이다.

규칙과 경제, 주간 시뮬레이션은 TypeScript 도메인 로직으로 빼고,
React는 HUD와 팝업, 리포트 같은 텍스트 많은 화면을 맡고,
Phaser는 움직이는 필드와 오토바이 애니메이션을 맡는 식이다.

이렇게 해두면 나중에 Unity로 가더라도
게임의 핵심 규칙을 다시 발명하지 않아도 된다.

물론 말은 쉽다.
실제로는 또 여기저기 삐걱댈 거다.
근데 삐걱대는 부분이 보여야 고칠 수도 있으니까,
일단 웹에서 빠르게 한 판이 끝까지 돌아가게 만드는 게 목표다.

마무리

붕붕고는 아직 완성품은 아니다.

하지만 이상하게 이 프로젝트는 이름부터 마음에 든다.
붕붕고.
뭔가 입에 붙는다.

작은 오토바이가 붕어빵을 싣고 돌아다니고,
고객들이 자기 취향을 기억해달라고 하고,
나는 그걸 보고 연구와 직원을 다시 배치한다.

생각보다 꽤 게임이 될 것 같다.

일단 목표는 하나다.

24주 캠페인을 실제로 끝까지 돌려보고,
마지막에 이런 문장을 보는 것.

“이번 판의 붕붕고는 따끈신속 운영자였습니다.”

혹은,

“초개인화 붕붕고 대표.”

이런 엔딩이 나오면 꽤 뿌듯할 듯.

아무튼 붕붕고는 계속 만들어볼 생각이다.
귀여운 척하면서 은근히 진지한 경영게임으로.

잡담

마지막으로 코덱스 사용일지를 올린 게 2월 19일이었다.

체감상으로는 “아, 며칠 안 썼나?”였는데
달력을 보니까 거의 3개월 반이 지나 있었다.

근데 블로그에 글을 안 올린 거지,
코덱스를 안 쓴 건 전혀 아니었다.

오히려 반대다.
이 기간 동안 코덱스는 더 깊게 들어왔다.

예전에는 내가 코덱스에게
“이거 고쳐줘”, “이거 만들어줘”라고 말하는 느낌이었다면,
요즘은 그냥 작업실 한쪽에 계속 켜져 있는 동료 같은 느낌이다.

내가 생각을 던지면
코덱스가 구조를 잡고,
파일을 뒤지고,
코드를 고치고,
다시 검증하고,
가끔은 내가 놓친 방향까지 먼저 끌고 온다.

한 줄로 말하면,
블로그를 쉰 게 아니라
작업장이 너무 커져서 기록을 못 따라간 느낌이다.

로그 기준 기간

• KST 기준 2026-02-19 ~ 2026-06-06
• 확인된 코덱스 세션 메타: 30,692개
• 월별 분포: 2월 307개, 3월 21,161개, 4월 8,294개, 5월 852개, 6월 78개
• 가장 많이 작업한 프로젝트: hermes_v2, runju/blog-site, BoongBoongGo

숫자로 보니까 3월이 좀 웃기다.

3월에만 세션이 2만 개가 넘는다.
내가 무슨 대단한 조직을 굴린 건 아니고,
그만큼 작은 확인, 수정, 재실행, 검토를 계속 반복했다는 뜻이다.

코덱스를 쓰다 보면 한 번에 거창한 걸 만드는 날보다
같은 문제를 열 번, 스무 번 다르게 잡아보는 날이 더 많다.

그런 반복이 쌓이면 어느 순간
“아, 이건 그냥 취미로 대화한 게 아니라 진짜 작업 로그구나” 싶어진다.

제일 많이 한 일: 자산관리 시스템 키우기

가장 많은 시간을 쓴 건 hermes_v2였다.

이건 내가 만들고 있는 자산관리 UI이자,
매매와 리서치를 한 곳에 묶어보려는 개인용 시스템이다.
요즘 내가 부르는 말로는 트레이딩크래프트에 가깝다.

그냥 차트 하나 띄우는 앱이라기보다,
“내가 왜 이 종목을 보고 있는지”,
“어떤 근거로 사고팔 생각을 하는지”,
“실제로 주문까지 이어질 때 어디서 멈춰야 하는지”를
조금 더 체계적으로 남기려는 쪽이다.

이 기간 동안 특히 많이 만진 건 KIS 연동이었다.

KIS는 한국투자증권 API다.
쉽게 말하면 국내 주식 계좌의 잔고, 주문, 체결 같은 정보를
프로그램으로 다룰 수 있게 해주는 통로다.

처음에는 국내 주식 리밸런싱을 조금 편하게 해보자는 마음이 컸다.
그런데 하다 보니 단순 주문 자동화보다
“판단을 기록하는 시스템”이 더 중요하다는 쪽으로 생각이 바뀌었다.

그래서 포트폴리오 코치,
시장 판단,
리서치 파이프라인,
근거 정책,
투자 메모리 같은 것들이 계속 붙었다.

말은 거창한데,
결국 핵심은 이거다.

“AI가 찍어주는 종목을 믿자”가 아니라
“내가 어떤 근거로 판단했는지 잊지 않게 만들자.”

이 차이가 꽤 크다.

사람은 기분 따라 생각이 바뀐다.
어제는 확신했던 종목도 오늘 손실이 나면 갑자기 이상해 보이고,
뉴스 하나만 봐도 처음 세운 기준을 잊어버린다.

그래서 코덱스에게 계속 시킨 건
멋진 추천 문장을 쓰는 일이 아니라,
판단의 뼈대를 만들고,
근거 없는 말은 근거 없다고 표시하고,
실행 전에 한 번 더 멈추는 장치를 만드는 일이었다.

코인 쪽도 같이 붙였다

크립토 쪽도 꽤 만졌다.

바이낸스, 업비트, 빗썸 같은 거래소 데이터를 보고,
블록 단위로 진입과 청산을 관리하는 실험을 했다.

여기서도 방향은 비슷했다.

자동으로 막 사고파는 봇을 만들고 싶은 게 아니라,
전략을 작은 단위로 쪼개고,
각 단위가 어떤 조건에서 움직였는지 남기는 쪽이었다.

코인은 변동성이 크니까
사람이 직접 보면 감정이 먼저 움직이기 쉽다.

그래서 오히려 더 차갑게,
신호와 위험과 실행 조건을 나누는 구조가 필요했다.

그걸 코덱스랑 계속 다듬었다.

블로그도 실험장이었다

두 번째로 많이 만진 건 runju/blog-site였다.

이건 글쓰기 자동화 쪽 프로젝트다.
블로그 글을 그냥 한 번에 써달라고 하는 수준이 아니라,
주제 선정,
초안 생성,
문체 조정,
발행 흐름까지 반복 가능한 형태로 만들어보는 실험에 가까웠다.

특히 많이 신경 쓴 건 출력 형식이었다.

AI가 글을 잘 쓰는 것도 중요하지만,
계속 쓰려면 결과물이 매번 같은 틀로 나와야 한다.

어떤 글은 제목이 빠지고,
어떤 글은 태그가 이상하고,
어떤 글은 문체가 갑자기 바뀌면
자동화가 아니라 수작업 폭탄이 된다.

그래서 JSON으로만 답하게 만들고,
문체를 일정하게 맞추고,
초안과 발행 상태를 구분하는 식으로 많이 다듬었다.

이 블로그도 사실 그 연장선에 있다.

내가 하고 싶은 말의 방향은 내가 정하고,
코덱스는 그걸 파일로 만들고,
형식을 맞추고,
빌드하고,
배포까지 밀어주는 역할을 한다.

예전 같으면 글 하나 올리려고
로컬 폴더 열고,
날짜 맞추고,
마크다운 만들고,
빌드하고,
깃 푸시하고,
배포 확인하고,
이런 걸 내가 다 손으로 했을 텐데
이제는 대화 한 번으로 대부분 흘러간다.

이게 은근히 크다.

글 쓰는 데 제일 큰 적은
“써야지”가 아니라
“올리는 과정 귀찮다”일 때가 많으니까.

게임 프로젝트도 건드렸다

5월에는 조금 다른 방향으로 튀었다.

BoongBoongGo라는 Unity 모바일 게임 프로젝트를 만졌다.

Unity는 게임을 만드는 도구고,
BoongBoongGo는 내가 잡아본 픽셀아트 모바일 게임이다.
대충 붕어빵 가게를 키우고,
손님과 이벤트와 성장을 굴리는 쪽의 감성으로 생각하고 있다.

여기서 코덱스는 코딩만 한 게 아니다.

게임의 핵심 루프,
일주일 단위 진행,
보상 구조,
픽셀아트 파이프라인,
테스트 기준,
출시 버전 목표 같은 걸 문서로 정리하는 데 많이 썼다.

이게 재미있었던 지점은,
코덱스가 꼭 서버나 자동화 코드에만 어울리는 도구가 아니라는 거였다.

게임처럼 감각적인 프로젝트에서도
“그래서 이 게임의 재미는 어디서 나오는데?”,
“처음 5분에 유저가 뭘 해야 하는데?”,
“v1에서는 어디까지 만들고 어디부터 버릴 건데?”
같은 질문을 계속 던지게 만들 수 있었다.

혼자 만들면 자꾸 욕심이 커진다.
이것도 넣고 싶고,
저것도 넣고 싶고,
결국 아무것도 끝나지 않는다.

코덱스랑 작업하면 적어도
“이번 버전에서 중요한 것”과
“나중으로 미뤄도 되는 것”을 문서로 붙잡아둘 수 있다.

3개월 동안 달라진 사용법

이번 공백기를 지나면서 제일 크게 달라진 건
코덱스를 쓰는 자세였다.

예전에는 답변을 받는 도구였다.
지금은 작업 흐름을 굴리는 도구에 가깝다.

예전에는 한 파일을 고치고 끝났다면,
지금은 대충 이런 식이다.

먼저 로그를 보고,
관련 파일을 찾고,
이전 결정과 충돌하는지 확인하고,
코드를 고치고,
테스트하거나 빌드하고,
결과를 다시 읽고,
필요하면 한 번 더 고친다.

사람으로 치면
한 명의 천재를 고용한 느낌이라기보다,
작은 작업팀을 내 책상 위에 올려둔 느낌에 더 가깝다.

물론 아직 귀찮은 점도 많다.

내가 의도를 흐리게 말하면
코덱스도 흐리게 움직인다.

내가 기준을 안 주면
그럴듯하지만 쓸모없는 결과가 나오기도 한다.

그래서 오히려 나도 더 또렷하게 말하게 된다.

“이건 왜 하는 건지”,
“성공 기준은 뭔지”,
“지금 만들 것과 버릴 것은 뭔지”를
생각하게 만든다는 점에서
코덱스는 그냥 코딩 도구가 아니라
생각 정리 도구이기도 하다.

오늘 결론

3개월 동안 글을 안 올렸는데,
그 사이에 코덱스 사용량은 더 커졌다.

자산관리 시스템을 만들고,
주식과 코인 리서치 흐름을 정리하고,
블로그 자동화를 손보고,
게임 프로젝트까지 문서화했다.

하나하나 보면 별개의 작업인데,
묶어서 보면 방향은 하나다.

내가 반복해서 하는 일을
조금 더 구조화하고,
기록하고,
다시 꺼내 쓸 수 있게 만드는 것.

이게 요즘 내가 코덱스로 하고 있는 일이다.

한 줄 요약:
블로그는 3개월 쉬었지만,
코덱스랑 노는 방식은 그 사이에 훨씬 진지해졌다.

잡담

어제는 코드를 크게 늘리는 날이라기보다,
“출력이 흔들리지 않게 만드는 날”에 가까웠다.

한 번 쓰고 끝나는 답변보다
반복 실행해도 형태가 무너지지 않는 템플릿을 계속 다듬었다.

로그 기준 기간

• KST 기준 2026-02-18 06:00 ~ 2026-02-19 05:59
• 확인된 세션: 49개
• 실제 세션 분포: hermes_v2 32개, runju/blog-site 17개
• 실제 로그 시작/종료: 2026-02-18 07:07 ~ 2026-02-19 04:47 (KST)

어제~오늘 새벽에 한 큰 일들

1. 정치 오피니언 생성 포맷 실험 (runju/blog-site)

• 한 일: 정치 이슈를 JSON 구조로 뽑는 파이프라인을 반복 실행.
• 왜: 글 초안 자동화를 할 때 결과물 모양이 매번 달라지면 후처리가 어려워서.

2. 페르소나/문체 다이얼 튜닝

• 한 일: 같은 주제라도 말투(직설도, 유머, 톤)를 바꿔가며 출력 품질 비교.
• 왜: “같은 사람의 연속된 글”처럼 읽히게 하려면 문체 일관성이 필요해서.

3. 자산 리서치 출력 스키마 고정 (hermes_v2)

• 한 일: query/summary/picks 같은 핵심 필드를 고정하고, self-score까지 포함한 구조를 테스트.
• 왜: 나중에 자동 집계/비교하려면 필드가 고정돼 있어야 분석이 가능해서.

4. 리밸런싱 판단 템플릿 정리

• 한 일: Top 5 후보, A/B/C 리밸런싱 옵션, If-Then 트리거 형태로 의사결정 틀을 분리.
• 왜: 매번 긴 문장으로 읽기보다, 바로 비교 가능한 형태가 실제 사용에 유리해서.

5. 안전장치(가드레일) 강화

• 한 일: 직접 매수/매도 지시 표현을 피하고, 근거 출처와 “근거 부족” 표기 규칙을 강제.
• 왜: 투자/정치 콘텐츠는 톤보다 신뢰가 먼저라서, 책임 경계와 근거 표기를 분명히 하려는 목적.

오늘 결론

어제의 핵심은 결과물 개수보다
“반복 가능한 출력 규격”을 만드는 일이었다.

한 줄 요약:
코덱스를 더 많이 쓴 날이 아니라,
코덱스를 더 안정적으로 쓰기 위한 틀을 만든 날이었다.

잡담

오늘은 기능을 크게 새로 만들기보다는,
앞으로 계속 굴릴 수 있는 작업 환경을 정리한 날이었다.

보안, 계정, 배포 신뢰도처럼
눈에 덜 보이지만 오래 가는 바닥 작업을 많이 했다.

로그 기준 기간

• KST 기준 2026-02-17 06:00 ~ 2026-02-18 05:59
• 실제 사용자 요청이 확인된 구간: 2026-02-17 09:10 ~ 2026-02-17 18:39

오늘 한 큰 일들

1. GitHub OAuth 유출 대응 흐름 정리

• 한 일: 토큰 노출 여부 확인, 노출 토큰의 계정 소속 확인, 히스토리 정리 필요성 점검.
• 왜: 푸시/배포를 계속하려면 먼저 계정 보안 리스크를 닫아야 해서.

2. 블로그 게시 시간(KST) 정합성 점검

• 한 일: 배포 후 게시 시각이 한국 시간 기준으로 어긋나 보이는 문제 확인 및 교정 흐름 정리.
• 왜: 기록형 블로그에서는 시간 메타데이터 신뢰도가 생각보다 중요해서.

3. GitHub 재연결 가이드 정리

• 한 일: 기존 인증 정리 -> 새 인증 등록 -> 로그인 상태 검증까지 한 번에 정리.
• 왜: “당장 접속”보다 “다음에도 안 꼬이는 운영 방식”이 필요해서.

4. 멀티 계정 SSH 분리 방식 확정

• 한 일: 계정명을 robotjuhwan/``으로 확정하고, SSH 별칭 기반 분리 등록 절차로 정리.
• 왜: 저장소마다 다른 계정으로 실수 푸시하는 문제를 막기 위해.

5. 출력 형식 제약 실험(JSON only)

• 한 일: 짧은 테스트 입력으로 응답 포맷 강제 조건이 안정적으로 동작하는지 확인.
• 왜: 자동화 파이프라인에서 예측 가능한 출력 형태가 필요해서.

오늘 결론

오늘의 핵심은 “새 기능 추가”보다
“보안/계정/배포를 안정적으로 운영할 기반 정리”였다.

앞으로 코덱스 작업을 계속 밀어붙이기 위해
필수적인 운영 체계를 다진 하루였다.

잡담

하루가 길어지면,
코덱스로 이것저것 많이 했는데 기억이 한 덩어리로 뭉개진다.

그래서 이번엔 타임라인 나열 말고
“중요한 일 + 왜 그걸 했는지”로 정리해본다.

로그 기준 기간

• KST 기준 2026-02-16 06:00 ~ 2026-02-17 05:59
• 이 구간 로그에서 확인된 세션: 92개

어제~오늘 새벽에 한 큰 일들

1. 아침에는 OMX 팀 병렬 실행 실험

• 한 일: codex_bot에서 여러 에이전트를 동시에 돌리는 방식(팀 실행)을 크게 테스트.
• 왜: 혼자 순차로 하면 느리고, 어디서 막히는지 늦게 보이기 때문.
• 결과: “요구사항 분석 -> 구현 -> 검증”을 병렬로 굴리는 작업 습관을 실제로 돌려봄.

2. 낮에는 Ju Office 기획을 제품 형태로 정리

• 한 일: Ju_Office 아이디어를 문서 중심으로 구조화하고, 해야 할 일의 기준을 세움.
• 왜: 아이디어만 있으면 계속 방향이 흔들리기 때문.
• 결과: 추상적인 생각이 “어떤 기능을 어떤 순서로 만들지” 수준으로 내려옴.

여기서 Ju Office는
가상 스타트업처럼 여러 AI 에이전트가 협업하는 걸 보여주는 실험 프로젝트다.

3. 오후에는 화면/데모 완성도 올리기

• 한 일: codex_office/Ju_Office에서 사무실 바닥, 에이전트 캐릭터, 좌표, 시각 요소를 보강.
• 왜: 내부적으로만 좋은 구조보다, “보는 사람이 이해되는 데모”가 필요했기 때문.
• 결과: GitHub 협업 흐름 + 2D 오피스 UI를 같이 보여주는 방향이 선명해짐.

4. 저녁에는 리뷰 루프를 강하게 돌림

• 한 일: Architect/Security/Code 리뷰를 반복해서 받고, 막히는 항목을 다시 수정.
• 왜: 빨리 만드는 것만큼 “부서지지 않게 만드는 것”이 중요해서.
• 결과: 단순 구현이 아니라, 검증 가능한 상태로 다듬는 흐름을 경험함.

5. 밤에는 OMX Autopilot과 Ju Office 간격 줄이기

• 한 일: Ju_Office의 동작 흐름을 OMX의 autopilot 방식과 비교하고 맞추는 작업 진행.
• 왜: 실제 사용 시 명령/상태 전환/완료 조건이 복잡하면 결국 못 쓰게 되기 때문.
• 결과: “작동은 하는데 쓰기 어려운 상태”에서 “어떻게 단순화할지 보이는 상태”로 이동.

6. 늦은 밤에는 블로그 복구/운영도 같이 처리

• 한 일: poul.kr의 배포 구조 확인, 소스 복구, 불필요 포스트 정리, 점검, 글 작성/배포.
• 왜: 개발 기록을 쌓을 기본 채널(블로그)을 다시 정상화하려고.
• 결과: 블로그를 다시 쓰고 배포하는 루틴이 재가동됨.

7. 새벽에는 실제 사용성 체크

• 한 일: 설치/실행 명령이 실제로 헷갈리지 않는지, 바로 동작하는지 확인.
• 왜: 문서가 좋아도 첫 실행이 막히면 사용자 입장에서는 실패라서.
• 결과: “복잡도 낮추기”와 “설치/실행 안내 단순화”가 다음 우선순위로 확정됨.

오늘 결론

어제~오늘 새벽은
“기능 하나 대박”의 날이라기보다
“여러 프로젝트를 실제로 굴러가게 만드는 뼈대”를 잡은 시간이었다.

한 줄 요약:
“속도, 품질, 사용성 세 가지를 동시에 맞추는 쪽으로 코덱스 사용법을 다듬은 날.”

잡담

하루 끝나고 보면,
코덱스로 뭘 많이 한 것 같은데 기억은 뒤섞인다.

그래서 이번엔 로그만 시간순으로 적는 대신,
중요한 작업만 뽑아서 “왜 했는지 + 뭐가 남았는지”로 정리해본다.

로그 기준 기간

• KST 기준 2026-02-15 06:00 ~ 2026-02-16 05:59

오늘의 큰 목적

오늘 목표는 기능을 마구 늘리는 게 아니었다.

“TradeCraft를 실운영에 맞는 형태로 정리하고,
다음 작업 속도를 올릴 수 있는 바닥을 깔기.”

여기서 TradeCraft는
내가 직접 만들고 있는 자산관리 UI(대시보드)이고,
실제 매매 엔진과 연결해서 상태를 보고 제어하는 쪽에 가깝다.

중요한 작업만 요약

1. 현재 상태부터 정확히 파악

• 왜: 위치를 모르면 같은 디버깅을 반복하게 되니까.
• 결과: UI/Telegram/Freqtrade 연결 상태를 먼저 점검했고,
  어디가 병목인지 기준점을 잡았다.

참고로 Freqtrade는
가상자산 자동매매에 많이 쓰는 오픈소스 매매 엔진이다.

2. 문서로 역할부터 다시 정리

• 왜: 처음에는 트레이딩크래프트 안에서 매매 기능을 직접 만들다가,
  그 방향을 정리하고 Freqtrade를 붙이는 구조로 갈아타는 중이었기 때문이다.
  이 전환점을 문서로 명확히 남겨야 이후 작업이 덜 꼬인다.
• 결과: hermes_v2/README.md가 TradeCraft Control Plane 관점으로 정리됐고,
  hermes_v2/docs/exchange_api_official_docs.md도
  “실행 엔진은 Freqtrade, TradeCraft는 모니터링/제어”로 명확해졌다.

3. 실시간 값 연동 기반 보강

• 왜: 달러값을 고정 숫자로 두는 게 마음에 안 들어서,
  가능한 한 실시간 값으로 반영하고 싶었다.
• 결과: 환율 쪽을 실시간 조회 기반으로 바꿔두고,
  실패하면 임시값으로 돌아가게 정리해뒀다.

4. OMX로 병렬작업을 실제로 돌려봄 (오늘 핵심)

• 왜: 혼자 하나씩 처리하면 느리고, 어디서 막히는지 늦게 보이기 때문이다.
  그래서 OMX(멀티 에이전트 작업 방식)로 병렬 실행을 직접 시험해봤다.
• 결과: hermes_v2/third_party/freqtrade 기준으로
  KIS 확장 관련 파일(freqtrade/exchange/kis.py,
  config_examples/config_kis.example.json,
  tests/exchange/test_kis.py)까지 작업 틀을 빠르게 올렸다.
• 메모: 일부 태스크는 완료, 일부는 blocked로 정리됐는데
  오히려 이게 “어디가 진짜 막힘인지”를 빨리 보이게 해줬다.

KIS는 한국투자증권 Open API를 말한다.
즉, 국내 주식 쪽 데이터를 같은 흐름에서 다루기 위한 확장 작업이었다.

잡담

오늘 뭐 했는지 기억이 약간 섞여서 로그를 열어봤다.

OMX turns 로그 기준으로 UTC 2026-02-16 14:39 ~ 15:39,
KST 기준으로는 2026-02-16 23:39 ~ 2026-02-17 00:39.

딱 1시간 동안 블로그를 거의 재부팅했다.

오늘 한 일 (로그 타임라인)

1. poul.kr 상태 확인. 아직 GitHub Pages 기반 맞는지 검증하고 연결 저장소를 확인했다.
2. /Users/juhwan/Documents/poul_blog_restart로 새로 시작해봤다가, 과거 글이 안 보이는 이유가 새 Hexo 초기화 상태라서라는 점을 확인했다.
3. 다른 컴퓨터에 있던 원본 ~/hexo 소스를 원격에서 GitHub로 복구 push 했다.
4. 맥 작업 환경으로 /Users/juhwan/Documents/hexo_blog_source를 가져와서 본격 작업 기반을 만들었다.
5. 로컬 서버 없이도 여기서 바로 GitHub Pages 배포 가능한 설정인지 다시 점검했다.
6. 요청했던 Juren Buffett 관련 포스트를 정리해서 24개 삭제하고 배포했다.
7. 블로그를 SEO/운영/수익화 관점으로 종합 점검해서 현재 리스크를 정리했다.
8. 콘텐츠 외 이슈는 한 번에 교정했다. Gitalk 민감값 제거, 댓글 비활성화, 깨진 로고/파비콘/OG/매니페스트 복구, 정책성 페이지 보강까지 반영했다.
9. OpenAI Pro 29,000원 + Codex 사용기 글을 초안 작성하고, 수정하고, 실제 발행까지 마쳤다.
10. 마지막으로 Codex/OMX 로그 경로를 정리해서 이후에도 작업 기록을 다시 추적할 수 있게 해뒀다.

마무리

오늘은 글을 많이 쓴 날이라기보다,
블로그를 다시 굴릴 수 있는 상태로 되돌린 날이었다.

예전에는 글감이 있어도 배포/설정이 꼬이면 금방 멈췄는데,
오늘은 소스 복구부터 배포 파이프라인, 운영 이슈 교정까지 한 번에 끝냈다.

잡담

요즘 제일 많이 보는 단어가 코덱스, 에이전트, 자동화인 듯.

나도 원래는 그냥 가볍게 써보자 느낌이었는데,
OpenAI Pro 대란 타이밍에 29,000원으로 결제할 기회가 떠서 바로 탔다.

진짜 개꿀이라 5개 바로 질렀다.
처음엔 “잠깐 쓰다 말겠지” 했는데,
지금은 자기 전까지 에이전트 붙잡고 놀다가 잠드는 루틴이 됐다.

예전 바이브코딩 vs 지금

바이브코딩은 이전에도 계속 시도했었다.
근데 복잡도가 커지면 결국 버그 잡다가 시간을 다 쓰고,
원하는 퀄리티가 안 나와서 포기한 경우가 많았다.

근데 요즘 최신 모델들은 급이 다르다.
진짜 체감이 확 난다.

예전에는 초안이 “참고용”이었다면,
지금은 초안이 거의 바로 작업 가능한 수준으로 나온다.

가격은 결국 30만원 고민

29,000원은 그냥 고민 없이 탑승했는데,
정가 30만원대는 확실히 고민 포인트다.

그래도 요즘 생각은 이렇다.

“매달 30만원 이상 가치의 작업 플로우를 만들 수 있으면 계속 간다.”

시간 단축 + 반복작업 감소 + 품질 안정
이 세 개가 맞아떨어지면 충분히 가능하다고 본다.

커피 몇 잔 아끼는 수준이 아니라,
실제로 하루 생산성 구조가 달라지는 느낌이라서.

마무리

OpenAI Pro 대란으로 들어온 건 운이었는데,
계속 쓰는 건 운이 아니라 효율 때문인 듯.

한동안은 코덱스를 “신기한 도구”가 아니라
작업 파트너처럼 계속 붙여서 써볼 생각이다.

잡담

진짜 근로소득자가 된 것을 느끼는 순간은 역시 연말정산이라는 것 해보기

일반적으로 모든 사람은 5월에 종합소득신고를 통해서 세금관련 정리를 하게된다.

종합 소득이란? 이자소득 + 배당소득 + 사업소득 + 근로소득 + 연금소득 + 기타소득 인데..

대부분의 근로자는 근로 소득만 발생된다.

그런데 이 근로 소득은 2월에 연말정산을 통해서 미리 정산을 하게된다. 그러니 5월에 종합소득신고는 대부분의 평범한 사람들은 잘 하지 않는 것이다.

이자소득과 배당소득은 2천만원 이상 되거나, 프리랜서로 기타소득 관련된 정산을 해야하는 사람이 5월에 세금관련 업무들을 하게 되는 것이다.

사실 연말정산보다 5월 종합소득신고가 찐인 것 같은데 대부분은 근로소득자라서 연말정산이 더 주목 받는 듯

여튼 나도 근로소득자가 되었으니 근로자를 중심으로 한 연말정산에 대해서 깊은 탐구를 한번..

기납부세액

일반적으로 여기서 세금이란 소득세와 지방소득세를 말한다. 소득세는 국세고 지방소득세는 지방세다.

국세는 나라에 내는 세금, 지상소득세는 거주하는 곳에 내는 세금이다.

여기서 지방소득세는 소득세의 10%라고 생각하면 된다.

우리는 월급을 받을때 각종 공제를 하게되는데, 그 중에 기납부세액이라는 명목으로 미리(?) 세금을 내게 된다.

국가가 미리 나중에 세금 걷으면 쓸돈이 당장 없으니까 대략 때려서 먼저 걷고나서 나중에 정산하는 그런건가 싶기도 하고..

기납부 세액은 근로소득간이세액표에 따라서 월 급여와 부양가족수에 따라서 계산이 된다. (정확한 계산식은 잘 모르겠음)

결국 기납부 세액은 미리 낸 세금이고 중요한것은 결정세액이니 기납부 세액이 얼마인지는 결과적으로 그렇게 중요하지 않음.

여튼 2022년 기준으로 해서 1월1일~12월31일 까지 냈던 기납부 세액이 있을건데, 이걸 2023년 1월쯤에 회사에서 연말정산을 한다.

그 다음, 2월 월급에서 미리 낸 세금이 원래 세금보다 많았으면 돈을 돌려주고, 반대면 돈을 더 내는 그런 이벤트가 발생된다.

그래서 뭐 13월의 월급이다 이런 이야기가 있긴 하더라.

소득공제와 세액공제

그래서 세금은 얼마나 내야 하는가?

나의 총 근로소득 값을 표에 넣으면 뿅 나오는 세금이 있다. 그게 내 세금이 되게 되는데 그 표는 아래와 같다

아무런 공제가 없다고 가정하면, 저 표에 따라서 세금이 결정되는 것이다.

구간별로 세금이 높아지게 되므로, 돈을 만원 더 벌게되었다고 했을때 체감되는 세금이 각 구간별로 다를 것이다.

이 표를 과세표준 표라고 하는데, 과세 표준을 구하기 위해서는 공제의 개념을 알아야한다.

소득공제와 세액공제라는 두 단어를 많이 들어봤을 것이다. 이 두 단어의 차이를 알아야 하는데

소득공제는 표에 넣기 전 총 근로소득 값을 줄여주는 기능을 하고, 세액공제는 표에서 나온 세금값 자체를 줄여주는 기능을 한다.

두 공제가 같은 금액이라면 세액공제쪽이 훨씬 큰 역할을 하게된다고 생각하면 된다.

근로소득공제

기본적으로 총 금여에서 근로소득 공제를 해준다.

말이 헷갈릴 수 있는데 기본으로 깔아주는 소득공제로, 소득에 따라 아래 표로 계산된다.

최대 공제는 2000천만원다. (세전 3~4억 정도 되어야 이 금액임)

인적공제

인적공제는 소득공제애 해당되는데, “소득이 거의 없는” 배우자나 부양가족이 여기에 해당된다.

요즘은 대부분 맞벌이가 많아서 배우자에 대한 인적공제는 거의 안된다고 생각하면 되고

보통 자녀가 여기에 포함된다고 생각하면 된다.

인당 150만원이 공제된다. 여기서는 본인도 포함되므로

자녀가 없는 직장인이라면 150만원 소득공제가 된다.

부양가족을 있거나나 특수한 경우가 있으면, 다양한 사례가 있으므로 찾아보면 될듯.

연금보험금공제/특별소득공제

4대보험으로 낸 금액은 소득공제 된다.

건강보험/고용보험/장기요양보험료 + 공적연금 (국민연금, 공무원연금 등)

은 전액 소득공제된다.

그 중에서도 특징이 있는게 건강보험과 고용보험료인데, 이는 4월에 또 정산작업이 있다고 한다(?) 나도 아직 겪어보진 못한거지만..

뭐 이때를 기준으로 건강보험료가 재정립 된다는데.. 여튼 4월에 재정립 되므로, 2월에 하는 연말정산에는 작년분이 적용된다는데..

좀 헷갈리기때문에 이건 연말정산할때 다시한번 눈여겨봐야할 듯

주택자금공제 - 소득공제

주택청약저축 납입액의 40%, 연 240만원 한도로 된다. (그래서 월 20만원씩 납입하는 사람이 많다고 하네?)
근데 요건이 연중 무주택 세대주, 총급여액 7000만원 이하여야 한다. 해당이 되면 무주택확인서를 제출해야 한다고 한다.

주택임차차입금 원리금 상환액의 40%, 12월 31일 기준 무주택 세대주/세대원 (세대주가 주택자금공제 받으면 안됨), 아파트 85제곱 이하 등
연 400만원 한도 (주택자금저축불입액과 합하여 최대)
위에 이 제도는 이자에 대한 것이 아리고 원리금에 대한 것이라 엄청나게 큰 혜택이라고 한다(?)

그리고 세 번째도 주택담보대출 등의 이자 상환액의 100%를 해준다. 12월 31일 1주택자여야 하고, 세대원이라면 본인이 거주하고 있어야 한다. 공시지가 5억 이하여야 한다. 한도에 대한 조건이 많다..

뭐 복잡한 조건이 많아서 해당이 될 것 같으면 잘 알아봐야 한다고 한다.

신용카드 소득공제

신용카드 소득공제. 뭔가 가장 중요한 요소인 것 같다. 다른쪽은 크게 변동이 없지만

이부분은 카드가 신용인지 체크인지 현금영수증인지 등등에 따라서 다르기때문이다.

여기서 중요한 부분은 총 급여액의 25% 이상 부터 공제 계산이 들어간다는 것이다.

자신의 소득에서 대부분을 카드로 소비한사람이 아니면 애초에 대상자체가 아닐 수 있다는 것이다.

뭐 전년도보다 카드사용량이 많아져서 발생되는 초과 사용분 공제액은 일단 제외하고 생각한다 (살짝 복잡)

정리해보면

전통시장/대중교통 사용분 <- 40%
도서/공연 사용분 <- 30% (총급여 7000만원 이하)
직불카드 사용분 <- 30% (체크카드, 현금연수증, 선불카드 등)
신용카드 사용분 <- 15%

가 된다. 자 25%가 넘는 금액을 썻다면, 그 금액에서 사용처를 기준으로 전통시장/대중교통/도서/공연 등이 먼저 공제되고 (추가한도 100만원)
그 다음으로 직불카드 사용분이 공제가 된다. 그다음으로 신용카드 사용분
추가한도가 아닌 한도는 총 급여에 따라서 다른데 7000만원 이하는 총 급여액의 20%와 300만원 중 작은 금액, 1억 2천 이하는 250만원, 그 이상은 200만원이다.
소득이 많을수로 한도가 작아진다.
근데.. 소득공제 비대상이 너무 많이 있다. 뭐 세금낸거 해외에서쓴거, 자동차구입비 등등 엄청 항목이 많다. 그래서 평소 계산이 좀 힘든 듯.

아래부터는 세액공제다!

근로소득 세액공제

소득공제도 기본적으로 딱 해주는 근로소득 소득공제가 있듯이

세액공제에도 들어오자마자 딱 들어오는 세액공제가 있다.

우선 위에 소득공제를 다 하고나서 과세표준 표에 넣어서 나오는 산출세액이 있을 것이다. 이것을 기준으로 계산이 되는데

산출세액이 130만원 이하라면 산출세액의 55%, 그 이상이라면 초과분의 30%까지 더한 값이 되고

한도로 거의 결정되는 듯 한데.. 한도가 총급여 3300만원 이하는 74만원, 7000만원 이하는 계산계산, 7000만원 초과는 계산계산 해서 딱

세액공제를 선으로 해준다. 표는 아래와 같다.

자녀 세액공제

자녀 세액공제로써 만 7세이상 20세 이하의 자녀의 수만큼 세액공제가 된다.
7세 이상의 조건이 있는 이유는 아동수당이 있기 때문인듯
1명은 15만원 2명은 30만원이고, 3명 이상부터는 한사람당 30만원이 추가된다.

출산 세액공제

첫째, 둘쨰, 셋째 각각 30만원 50만원 70만원 이렇게

출산이 있다면 세액공제를 해준다.

연금계좌 세액공제

연금저축계좌와 퇴직연금계좌 납입액에 대해서

세액공제를 해준다. 이것도 총급여액에 따라서 한도와 공제율이 다르므로, 표를 찾아서 참고하면 되겠다.

월세 세액공제

월세도 세액공제가 된다

총 급여액이 7000만원 이하일 경우, 각종 조건들을 만족한다면 15%나 12%의 공제를 받을 수 있다.

진짜 월세 돌려받는 기분일 듯?

특별 세액공제

마무리로 진행되는 세액공제!
보험료/의료비/교육비/기부금에 대해서 세액공제가 된다.

이 외에도 최저로 이 특별 세액공제값을 13만원으로 받을 수 있는 선택이 있긴한데.. 이건 월세 세액공제나 어떤 소득공제들일아 또 비교를 해봐야해서..
조금 복잡한듯. 최대한 위에 4가지로 13만원을 넘기면 머리가 복잡해지지 않는다.

여튼..이 세액공제 부분도 복잡하므로.. 각종 표를 참고해서 계산을 해봐야 한다.

마무리

한번 쭈욱 훑으면서 연말정산에 대해서 보았다.

후반으로 갈수록 각종 조건들이 까다롭게 붙어서 머리를 아프게 했지만..

뭔가 기본적인 개념은 다 익힐 수 있었던 듯.

근데 이런 세법은 매년 바뀐다.. 내가 본 자료는 22년도 기준이라.. 23년도 기준에는 각종 기준이 다 바뀌었을 것 같다.

다시 한번 살펴봐야 할듯

개념은 이제 잡혔으니, 이제 돈을 어떤 방향으로 쓸지 찬찬히 생각해보아야할 시점인 듯

소득 공제를 최대한으로 잡도록 한뒤 세액공제를 잔뜩 고려하면

경제적인 연말정산을 할 수 있을 듯.

잡담

뼈찜. 감자탕에 익숙해져있다면 뼈찜을 안먹어본 경우가 있을 것이다.

하지만 나는 개인적으로는 뼈찜을 더 선호한다.

일반적으로 뼈찜이라고 한다면 약간 간장 찜닭과 비슷한 음식인데 닭살이 돼지등뼈로 대체된 느낌이다.

주변에 어림지나 참뼈 등 전문점도 많지만, 최근 각광받고 있다는 포항시외버스터미널 근처의 차밭골을 방문했다.

리뷰

포항 시외버스터미널 부근에 위치한 차밭골

홈플러스랑 터미널 사이에 있는 길에 있다.

실내는 입식으로 넓은 편

오후 3시 반에 방문했는데도 사람들이 있었다.

추가반찬은 셀프. 주류도 많이 보인다.

메뉴판의 모습

감자탕과 뼈해장국을 판매하는 일반적인 메뉴판이다.

이곳 손님이 많은 이유가 뼈해장국에 돌솥밥이 같이나오는 이유라고 한다.

적당한 가격에 돌솥밥까지 먹을 수 있어서 좋다고 한다.

파김치 감자탕은 조금 특이해보인다. 궁금하긴 함

우리는 뼈찜을 먹으러 왔기에 매운 뼈찜 소 를 주문했다. 이곳에 라면사리를 추가했다.

추후 밥이 먹고싶으면 볶음밥을 먹으려고 공기밥은 주문하지 않았다.

소 사이즈는 뼈가 4개 중은 6개 라고 블로그에 되어있더라

기본반찬이 세팅된다. 깍두기와 김치, 양파와 고추 그리고 콩나물

다들 일반적인 맛이다.

특히 콩나물은 간이 거의 안되어있는데, 나중에 뼈찜 내용물과 함께먹으니 좋더라

이렇게 먼저 감자탕 국물이 나온다.

고기는 없지만 우거지가 가득 들어있어서 좋았다.

뼈찜 조리에 시간이 조금 걸리기때문에 이렇게 국물이 먼저 나오니 입이 심심하지 않고 좋았다.

이정도 되면 식사 시작임

뼈찜이 나왔다.

라면 사리를 추가하니 역시 비주얼이 좋았다.

약간 우리가 생각한 매운 뼈찜은 일반적인 간장 베이스의 뼈찜에 조금 더 매운 맛인 줄 알았는데 아예 고추장 베이스의 떡볶이 같은 양념이었다.

그래서 그런지 국물도 약간 자작하게 존재하더라

비주얼이 완전 맛있는 라볶이 비주얼이 되었다.

뼈에 살도 가득가득 붙어있었다. 이렇게 뼈를 들고와서 고기를 발라 먹으면 맛있다.

각 테이블마다 앞접시와 소스가 있는데

겨자소스에 고기를 찍어먹으면 또 맛있다.

텁텁할 수 있는 감자탕 고기를 더 맛있게 먹는 방법임

이런 비주얼로 식사를 하는 중이다. 콩나물은 더 리필해왔다.

이렇게 당면에 라면이 더해지고 콩나물까지 넣어 먹으면 아삭한 식감과 함께 맛있게 먹을 수 있다.

고기도 알차게 들어있음

여기에 떡과 수제비 등 가득 들어있기때문에

뼈찜 먹을때 따로 공기밥을 안먹어도 될 것 같다. 우리에겐 볶음밥이라는 최후의 무기가 있기 때문

다 먹었다. 결국 배가 불러서 볶음밥은 먹지 못했다.

마무리

간만에 먹으러간 뼈찜

사실 간장 베이스의 뼈찜을 기대했는데 먹지 못해 아쉬웠다. 다음에는 일반 뼈찜을 먹어야 겠다.

매운 뼈찜도 괜찮긴 한데 약간 떡볶이같은 양념이라 개인적으로는 별로였다. 뭔가 찜인데 국물도 너무 자작했고..

그래도 전체적으로 들어있는 재료나 고기가 너무 좋아서 또 방문할 듯.

탄수화물이 많이 첨가되어 있고 볶음밥도 먹을 수 있으니 공기밥은 안시키늰게 탄수화물 섭취를 줄이기 위해서 좋을 것 같다.

위치는 아래와 같다. 네이버 지도 링크
경북 포항시 남구 중섬로 21 1층.

잡담

대잠성당 근처의 핏쩨리아 문
최근에 오픈한 가게라서 정보가 많이 없었다. 네이버 지도에서도 찾을 수 없어서 매우 궁금했던 가게다.
계속해서 ‘핏제리아 문’ 으로검색해서 안나오는 것이었다.
핏쩨리아 문 으로 검색하면 나온다. 그래도 아직 네이버 블로그 리뷰는 없는 듯.

배달의 민족에도 없고 그래서 너무 궁금해서 방문해보았다.

리뷰

대잠성당 옆에 있는 핏쩨리아 문, 화덕피자 전문이라고 되어있다.
이탈리아 전통 나폴리식 피자라고 한다.
포르자 나폴리 셈프레

내부는 매우 넓다. 테이블도 많고, 우리는 5명이 방문했는데 자리가 애매해서 단체석에 앉았다.

저기 피자를 굽는 화덕이 보인다.

화덕 피자는 일반적인 피자 오븐보다 얼마나 다를 것인가.
금색으로 장식된 찐 화덕이다.

메뉴판이다. (메뉴판에는 핏째리아 라고 되어있음)
테이블마다 메뉴판이 있고, 메뉴판에는 번호가 있다. 키오스크에 그 번호를 쓰고 주문하면 된다.

피자 메뉴 모습. 거뭇거뭇한 도우가 보이는 기존 피자와는 다른 모습이 보인다.

스텔라 시금치 피자가 색다르게 보인다. 스텔라 피자는 뭔가 별모양으로 도우를 접는 피자인듯.
파스타와 리조또, 샐러드 등도 있다.

음료수도 있다. 나올 때 제로콜라가 있는것을 봤는데, 파는 메뉴인지는 모르겠다.

우리는 이렇게 주문하였다. 정통 이태리 피자라면 1인 1피자는 기본!

자리는 이렇게 세팅된다. 음료수를 시키면 이렇게 얼음컵을 같이 주신다.
오픈한 2월에는 음료수 1개가 무료라고 해서 다 받았다.

기본 제공되는 식기가 매우 고급스러워 보였다. 묵직한 느낌.

마르게리따 피자가 나왔다. WOW 매우 먹음직 스러웠다.
영롱한 모습
도우/토마토소스/치즈가 조화를 이루고 있다.
바질이 살짝 아쉽게 있는 느낌. 사진이랑 너무 다른거 아니요!
치즈가 생모짜렐라라서 일반적인 모짜렐라랑 조금 다른 느낌. 더 프레쉬한 맛이 난다.

고르곤졸라 피자. 먹음직 스러워 보인다.
실제로 맛을 평가해보자면, 화덕에서 구워서 그런지 도우가 엄~청 맛있었다.
쫄깃쫄깃하면서도 담백한 맛이다.
치즈나 다른 재료도 뭔가 신선해서 맛있었다. 확실히 화덕피자라서 느낌이 다르다.

요건 토마토 치즈 오븐 파스타
평범? 하진않았지만 피자에 비해서 임팩트는 낮은 느낌
일반적으로 피자집에서 먹는 치즈오븐스파게티보다는 고급진 맛이었다. 치즈오븐파스타 느낌

이건 콰트로 피자. 모짜렐라 뿐만 아니라 고르곤졸라, 까망베르, 리코타까지 있다.
기본적으로 고르곤졸라 피자 구성 위에 까망베르, 리코타를 더 얹은 느낌이다. 이것도 맛있었다.

루꼴라 피자
이게 비주얼적으로는 제일 좋았다. 마르게리따 피자 위에 샐러드를 올린 느낌

프로슈타, 루꼴라, 등등 잔뜩 올려져 있어서 피자가 프레쉬한 맛이 난다.

잘 먹었다.
1인 1판이 가능함.

마무리

화덕피자는 간만에 먹어보는데 맛있었다.
무엇보다 속이 부대끼지 않고 편안해지는 느낌? 보통 피자 먹으면 니글니글 한데 그러지않았다.
어른들이랑 같이 와도 될듯

위치는 아래와 같다. 네이버 지도 링크
경북 포항시 남구 새천년대로410번길 13 1층.

잡담

효자시장에 새로 생긴 어떤 음식점이다.

탁구? 하던곳이 이전하고 식당이 들어왔는데, 양덕에서 이미 장사를 하던 가게가 이전했다고 한다.

네이버 검색을 해도 나오지않아서 양덕 해오름으로 검색해보니 “해오름바지락칼국수” 라는 상호로 블로그 기록이 여럿 검색되었다.

왜 이전을 했는지는 모르겠지만 “해오름” 이라는 다소 간소화시킨 상호명으로 효자시장에 입성!

리뷰

11시 30분에 방문, 주변 골목에 주차를 해야한다. 점심시간 피크가 되면 주차하기가 어려움. 일찍일찍 와야 주차할 곳이 많다.

실내모습. 자리가 굉장히 많다. 자리마다 그릇과 컵 등이 모두 준비가 되어있다.

여튼 넓고 테이블이 많다. (12시 조금 넘으면 자리가 꽉 찬다)

메뉴판의 모습 우리는 탄수화물을 한번 기피해보자는 생각으로 소고기전골 순한맛과 만두 한판을 주문했다. (공기밥도 두개 시켰는데, 다시 간다면 공기밥은 시키지 않고 전골을 즐긴 후에 면과 죽을 먹는게 좋을 듯)

이전 양덕에 있을때는 없던 메뉴가 소고기 전골과 만두 전골인데, 이전에는 샤브메뉴가 있었는데 점심장사에 알맞게 변형한 것 같다.

대표메뉴가 칼국수 두가지인 것 같은데 대부분 다 이걸 먹는다.

반찬 세가지와 찍어먹는 소스가 나온다. 역시 칼국수집 답게 감칠맛 돋고 맛있는 김치가 필수인 듯. 반찬이 다 맛있다. 계속 셀프바에서 리필해서 먹었다.

여기 나오는 열무김치는 칼국수 시켰을 때 나오는 보리밥에 올리고 고추장 올려서 간단히 비빔밥으로 먹는가 봄.

요 소스도 괜찮았다. 겨자 소스와 우측은 칠리소스 베이스의 어떠한 소스 느낌인데 전골 야채랑 고기를 찍어먹으니 괜찮았다. 셀프바에서 리필 가능

전골이 나왔다. 비교적 빨리 나온 듯. 소고기 전골 2인분
11시 30분에 가니 2~3테이블정도 있었고, 금방 나왔다.
샤브샤브 육수에 야채와 고기가 미리 들어가서 나오는 형태라고 생각하면 된다.

곧 이렇게 끓어오른다. 너무 맛있겠다.

뜨거우니 앞접시에 이렇게 담고 조금 식혀서 소스에 찍어먹었다.

만두가 나옴. 크기가 범상치가 않다.

속이 꽉~찬 만두다. 여기 오면 만두는 필수적으로 먹어야 할듯. 속이 꽉차고 담백한 만두다.
5개 7천원이라서 조금 애매한 감이 있다. 두 명이 먹으면 하나가 남고, 넷이 먹어도 하나가 남는다. (가위바위보 필수)

만두도 김치랑 같이 먹으면 간도 맞고 맛있다.
역시 칼국수집의 김치란..

다 먹었다.

일단 오늘은 소고기 전골을 먹었지만 다음에 온다면 바지락이나 동죽 칼국수를 먹어보고 싶다.
참고로 동죽 이라는 것도 조개의 한 종류인듯.
우리는 소고기전골과 공기밥을 따로 시켜서 먹었는데, 약간 샤브샤브 삘이나므로 공기밥없이 전골을 즐긴 후에 전골추가메뉴를 통해서 다양하게 즐기는게 좋을 것 같다.

마무리

효자시장에 새로생긴 해오름
새로 개업한 가게가 아닌 양덕에서 이전하였기 때문에 점심시간 시스템이 잘 잡혀있다.
사람이 생각보다 무지하게 많다. 새로개업한 곳이 맞나..?
꽤 괜찮은 가게로 효자시장 점심식사 세계에서 오래갈 수 있을 듯

주소는 아래와 같다, 네이버 링크로 연결
경북 포항시 남구 효자동길1번길 24.

첫 글

블로그를 시작합니다.

아직은 어떻게 하는지 잘 모르겠지만

과거에 워드프레스로 직접 서버를 구동하는 형식보다

깃허브로 블로그를 운영하면

기술 블로그로 활용이 가능할 것 같다는 생각을 했습니다.

1

코딩도 잘 표현할 수 있고 좋은 듯

MarkDown 문법도 숙지해야 겠다.

이 문법은 md 파일의 문법, 여튼 여기 게시판을 쓰기위한 문법이다

음식이랑 여행도 많이많이 기록해야지

중요

이곳에 기술된 내용은 대부분 맞겠지만 틀린 내용을 당연히 서술할 가능성이 높습니다.

이 곳의 내용은 절대 Reference로 활용될 수 없을 것입니다..

틀린 내용이나 지식이 있다면 단연코 댓글로 알려주시면 수정하도록 하겠습니다.