첫 편에서는 OpenCode 멀티 에이전트 구성을 접고 Codex로 옮긴 이야기를 다뤘습니다. 복잡한 하네스는 잠시 접어두고, 이제는 개발만 하면 되겠다고 생각했습니다. GPT는 제게 잘 맞았고 사용량도 넉넉했습니다.
그런데 시장은 저를 가만히 두지 않았습니다. 새 도구와 모델이 계속 나왔고, 하나씩 놓치다 보면 나만 뒤처질 것 같은 기분이 들었습니다. 지금 생각하면 FOMO에 가까웠습니다. ‘그래프 엔지니어링’ 같은 말도 그때는 하네스를 넘어선 새로운 방식처럼 들렸습니다. 막상 들여다보면 Codex에서 하던 일을 조금 더 예쁘게 감싼 경우가 많았지만요.
그래도 Codex 앱은 계속 신경이 쓰였습니다. 업데이트될 때마다 화면이 편해졌고, 여러 프로젝트를 동시에 열어두고 작업하는 흐름도 제게 잘 맞았습니다. 다른 도구를 찾아 헤매는 동안에도 Codex는 조용히 좋아지고 있었습니다.
개인 비서가 필요했습니다
개발 말고도 맡기고 싶은 일이 생겼습니다. 그때 Hermes Agent가 눈에 들어왔습니다. 생각은 단순했습니다. Codex는 개발을 하고, Hermes는 개인 비서처럼 움직이게 하자는 것이었습니다.
Hermes가 대화와 요청을 정리하고, 명령마다 다른 모델에 일을 나눠 맡깁니다. 개발이 필요하면 codex exec로 Codex에 넘기고, 결과를 다시 Hermes가 받아 처리합니다. 잘만 되면 작은 개발팀 하나가 움직이는 것처럼 보일 것 같았습니다. Hermes가 내세운 자가 학습도 선택한 이유 중 하나였고, Slack과 Discord를 연결할 수 있다는 점도 마음에 들었습니다.
문제는 둘을 연결하는 순간부터 생겼습니다. Hermes에서는 Codex 안에서 실제로 무슨 일이 진행되는지 잘 보이지 않았습니다. 중간 상태가 블랙박스에 가까웠습니다. 그래서 제가 중간중간 상황을 설명하고, 같은 맥락을 다시 요약해서 넘겨야 했습니다. 일을 시키는 시간보다 두 도구가 서로 알아듣게 만드는 시간이 늘어났습니다.
토큰도 양쪽에서 같은 내용을 반복해서 읽고 요약하는 데 쓰였습니다. 비용은 Codex 구독료에 OpenRouter 사용료가 더해졌습니다. 이후 ChatGPT 모바일 앱에서 Codex 작업을 확인하고 이어갈 수 있게 되자, 제게는 Slack·Discord 연동의 장점도 예전만큼 크지 않았습니다. 결국 다시 Codex 하나를 쓰게 됐습니다.
도구를 나누니 맥락과 결과를 옮기는 일도 생겼습니다.
이번에는 직접 그래프를 만들었습니다
에이전트 팀을 만들고 싶은 마음까지 사라진 것은 아니었습니다. Hermes에서 마음에 들었던 부분을 가져와 이번에는 직접 Drig를 만들었습니다. 계획, 인터뷰, 개발, QA, 리뷰, 배포를 하나의 그래프로 묶어 자동화해 보자는 생각이었습니다.
오픈소스로 공개할 생각까지 있어서 한 달 넘게 매달렸습니다. 그러다 어느 순간부터 본래 개발보다 Drig를 고치는 데 더 많은 시간을 쓰고 있었습니다.
특히 리뷰와 QA에서 발목이 잡혔습니다. 변경된 부분만 처리하려고 증분 흐름을 만들었는데, 리뷰 목록과 수정 목록에 같은 작업이 다시 들어갔습니다. 하나를 고치면 다음 단계에서 같은 항목이 또 나타났습니다. 문제를 해결하면서 이전 경로를 정리했어야 했는데, 실제로는 오래된 단계는 남고 새 분기만 계속 붙었습니다.
그래프는 점점 커졌고, 검증 과정은 더 복잡해졌습니다. 개발에는 10분이 걸렸는데 검증에는 한 시간이 걸리는 날도 있었습니다. 당시에는 이 현상을 AI의 문제라고 생각했습니다. 한 가지 문제를 해결하면서 기존 문제를 없애지 않고 그 위에 새 해결책을 쌓는 모습이 반복됐기 때문입니다.
그런데 지금 돌아보면 절차를 만든 저도 똑같이 행동했습니다. AI가 낡은 경로를 남긴다고 불평하면서, 저는 그 경로를 지우지 않은 채 통제 단계만 하나씩 추가했습니다. Codex Sol이 나온 뒤에는 Drig가 더 무겁고 우유부단하게 느껴졌습니다. 결국 프로젝트에서 Drig를 지웠습니다.
이 글은 당시 작업 흐름을 돌아본 회고입니다. 시간과 비용을 통제한 비교 실험은 아니므로, 특정 도구의 성능을 판정하려는 글도 아닙니다.
다음에는 무엇부터 확인할까
이번 일을 겪고 나서 도구를 고르는 기준이 조금 달라졌습니다. 역할을 몇 개로 나눌 수 있는지보다, 나눈 뒤에 제가 관리해야 할 일이 얼마나 늘어나는지를 먼저 봅니다.
- 인계가 정말 필요한가: 다음 도구가 앞선 도구의 결과를 다시 요약해야 한다면, 그 인계부터 줄일 방법을 찾습니다.
- 현재 상태가 보이는가: 무엇을 했는지뿐 아니라 지금 막힌 이유와 다음 행동까지 한 화면에서 확인할 수 있어야 합니다.
- 새 단계가 기존 단계를 없애는가: 문제를 해결할 때 새 분기만 추가하지 않고, 더 이상 필요 없는 경로를 지울 수 있어야 합니다.
- 검증 비용을 따로 세는가: 자동화가 개발 시간을 줄였는지만 보지 않고, 리뷰·QA·수정 목록을 관리하는 데 새로 든 시간도 함께 봅니다.
개발팀에서 오래 일한 만큼, 이상적인 팀처럼 움직이는 에이전트팀을 만들고 싶은 마음은 아직 남아 있습니다. 다만 당분간은 Codex를 중심에 두려고 합니다. 다음에 다시 그래프를 만들게 된다면, 멋진 구조를 먼저 그리기보다 실제로 줄어드는 일과 새로 생기는 검증부터 세어볼 생각입니다.
