Ep.1에서 나는 Hermes-Agent를 fork했다. “내 에이전트를 만들겠다”는 생각 하나로. 그게 Drewgent의 시작이었다.

거의 2년 동안 Hermes는 Drewgent의 backbone이었다. Knowledge Bus, NeuronFS, 칸반, office-autopilot — 전부 Hermes 위에서 돌아가는 코드였다. 나는 Hermes에 customize layer를 덧대고, Python 3.14 버그를 우회하는 패치를 쌓고, launchd plist를 손보면서 버텨왔다. 잘 돌아가고 있다고 믿었다.

어느 순간 숫자를 세어봤다. 에이전트를 만드는 시간보다, 에이전트가 죽지 않게 하는 시간이 더 길어져 있었다.

Python 3.14의 json scope 버그 때문에 __import__(‘json’).loads() 같은 해괴한 코드가 곳곳에 박혔다. Hermes 세션 관리는 macOS 업데이트마다 깨졌다. customize layer는 점점 두꺼워져서 원본 Hermes와의 괴리가 파일 200개를 넘었다. 이미 fork가 아니었다. Hermes의 시체를 이고 가는 꼴이었다.

유지보수가 불가능해진 시스템은 버려야 한다.

Ep.5에서 배운 교훈이다. 죽은 서비스를 감지하는 시스템이 서비스보다 중요하다는 말 — 이번엔 Hermes 자체가 그 “죽은 서비스”였다. 내가 만든 self-healing 시스템이 내 프레임워크를 가리키고 있었다. 아이러니지만, 덕분에 결정은 빨랐다.

opencode를 발견한 건 그 무렵이다. opencode serve로 데몬을 띄우고, MCP server를 붙이는 구조였다. WordPress, Discord, gbrain, Gajae-Code — Hermes에서는 각각 플러그인을 만들고 유지보수해야 했던 것들이, opencode에서는 MCP server 주소 하나 등록하는 걸로 끝났다. 가장 결정적이었던 건 내가 유지보수하지 않아도 된다는 점이었다. 프레임워크 패치는 opencode 팀이 한다. 내가 할 일은 에이전트를 만드는 거다.

n8n도 같은 이유로 날렸다. 워크플로 자동화 툴로서는 쓸만했지만, 유지보수가 점점 부담이었다. 노드 버전 올리면 워크플로가 깨지고, 컨테이너 재시작하면 상태가 날아가고, 로그가 쌓이면 디스크를 잡아먹었다. launchd cron 하나로 갈아탔다. ai.drewgent.cron.plist 하나가 60초마다 drewgent_cron.py를 실행한다. n8n의 수십 개 워크플로가 단일 Python 스크립트 하나로 정리됐다. 이사하면서 짐을 버리는 기분이었다.

망설이면 절대 못 버린다. 그래서 그냥 밀었다.

마이그레이션 자체는 사흘 걸렸다. 하지만 그 사흘 전에, 버리기로 마음먹기까지는 몇 달이 걸렸다. 거의 2년 동안 쌓은 코드를 버리는 건 기술적 결정이 아니라 감정적 결정이다. “여기까지 오는데 얼마나 많은 밤을 썼는데”라는 생각이 발목을 잡는다. 근데 그게 함정이다. 쏟은 시간이 많을수록 버리기가 더 어려워진다. 시간을 많이 썼다는 이유만으로 망가진 걸 계속 들고 있는 꼴이 된다.

가장 어려운 결정은 무엇을 추가할까가 아니라, 무엇을 버릴까다.

실제로 정리한 목록을 보면 이렇다:

에이전트 프로필 14개 → 6개로 압축 n8n 제거 → launchd cron으로 스케줄링 전체 대체 스크립트 43개 → 25개로 감축 Hermes customize layer 200+ 파일 → 전부 폐기 게이트웨이 코드 9,876줄 → opencode MCP 구성 파일 하나로 대체

덜어내는 것도 설계다. 나는 이걸 v0.8 simplification이라고 불렀다. 기능을 추가하는 건 정말 누구나 한다. 하지만 기능을 지우면서도 시스템이 더 나아지게 만드는 건 설계자만 할 수 있는 일이다. 줄이는 행위 자체에 의도와 구조가 들어가야 한다.

재미있는 건, launchd watchdog이 Hermes의 죽음을 처음으로 알려줬다는 점이다. Ep.5에서 만든 self-healing 시스템이 “Hermes gateway가 5분째 응답 없음”이라고 Discord에 알림을 쏘고 있었다. 내가 만든 감시자가 내 프레임워크를 가리키는 순간 — 그 알림을 보면서 “아, 이거 진짜 버려야겠다” 싶었다. 시스템이 스스로 진단을 내린 셈이다.

가장 웃긴 결과는 이거다. Hermes를 제거하고 나서 Drewgent가 오히려 더 안정적으로 돌아갔다. 죽지 않는다. launchd watchdog이 할 일이 줄었다. cron job 실패율이 10분의 1로 떨어졌다. 왜냐하면 실패할 지점 자체를 없앴기 때문이다. 복구 로직을 짜는 대신, 복구가 필요 없는 구조로 바꾼 거다.

이 에피소드가 Drewgent Origin Story의 분기점이다. Ep.1에서 fork해서 시작한 관계를, Ep.6에서 끝냈다. Hermes 없는 Drewgent가 이제 진짜 시작이다. 내 코드도 아니고, 내가 고쳐야 할 버그도 아니고, 그냥 없앴다. 그게 가장 큰 설계 결정이었다.

사람들은 보통 “무슨 기술을 썼나요?”부터 묻는다. 근데 내가 배운 건 기술이 아니라 태도다. 프레임워크는 갈아탈 수 있다. 코드는 지울 수 있다. 하지만 “내가 만든 걸 내가 버릴 수 있는가”는 완전히 다른 문제다. 거기엔 자존심이 걸려 있고, 밤샘 작업의 무게가 실려 있고, “이걸 버리면 내가 뭘 한 거지?”라는 불안이 붙어 있다. 그걸 넘어야 진짜 설계가 시작된다.

Drewgent Origin Story 시리즈. Ep.1~5에서 환경·기억·뇌·자기 관리·첫 사고를 거쳐, Ep.6은 가장 큰 결정을 다뤘다 — 만든 것을 버리는 결정.