바이브 코딩으로 오픈 클로를 만들어 오면서 가장 크게 한 번 뒤집어본 적이 있다. 그간 기능을 하나씩 쌓으며 기능상으로는 부족함이 없었는데, 정작 에이전트를 쓰는 감각이 나지 않았다. 코덱스나 클로드 코드를 쓸 때 느껴지는, 요청을 던지면 모델이 알아서 추론해 풀어내는 그 감각 말이다. 내가 만든 봇은 어딘지 모르게 자동화 스크립트에 더 가까웠다.
이번 글에서는 그 위화감의 정체를 좇아 플래너 중심 구조를 걷어내고 에이전트 + MCP 도구 구조로 갈아엎은 과정을 정리해본다.
에이전트가 아닌 플래너가 중심이었던 구조
처음 만든 오픈 클로는 기능을 하나씩 붙이며 자랐다. 리마인더, 옵시디언, 브라우저 자동화, 자산 관리까지 쌓이면서 기능마다 믹스인 레이어로 붙어 있는 구조가 됐다. 그리고 그 중앙에는 플래너가 자리를 잡았다. 내가 요청을 보내면 플래너가 먼저 받아서, 자신이 가진 기능들을 훑어보고 시퀀스를 구성하고, 각 단계마다 필요하면 추론이나 기능 호출을 했다.
이 구조는 겉보기엔 꽤 그럴듯했다. 하지만 실제로 써보니 내 의도대로 동작하지 않는 경우가 많았다. 가장 큰 위화감은, 플래너가 내 요청을 어떤 규칙에 따라 가공하고 시퀀스로 쪼개는 순간 이미 에이전트의 자유도가 꺾인다는 점이었다. 나는 요청을 그대로 에이전트에게 흘리고, 에이전트가 판단해 도구를 골라 쓰는 그림을 원했는데, 이 구조는 그 반대로 흘러가고 있었다.
기계적 규칙을 추론으로 바꾸는 반복
근본 원인을 따져 보니 플래너가 기대고 있는 게 대부분 기계적 규칙이었다. 그래서 에이전트에게 계속 요구했다. 규칙으로 판단하지 말고 추론으로 바꿔달라고.
처음엔 요구한 구간에서만 추론 기반으로 변경됐다. 문제는 휴리스틱으로 구현된 기계적 규칙이 코드 여기저기에 파편화되어 남아 있다는 점이었다. 한쪽을 추론으로 바꾸면 바로 옆에 다른 기계적 분기가 버티고 있었다. 게다가 추론으로 바꾼 구간도 선후 가공이 붙어 있어, 에이전트가 실제로 자유롭게 판단했다기보다 가이드라인에 따라 답을 고르는 모양새였다.
그렇게 하나씩 추론으로 바꿔달라고 요청하는 일에 점점 지쳐갔다. 그 사이 사이드 이펙트도 무수히 터졌다. 이쯤에서 구조 자체를 의심하기 시작했다.
요청보다 플래너가 더 중심이 되어버린 초기 구조
이어지지 않는 대화, 무너지는 연속성
구조를 의심하게 된 또 하나의 이유는 대화 연속성이었다. 봇이 내게 확인을 요청하는 경우가 있다. 플래너가 시퀀스를 짜다 애매한 지점에서 추가 정보를 되묻는 식이다. 거기까진 좋다. 자연스러운 흐름이다.
문제는 내가 답을 하고 나면 꽤 자주 동문서답이 된다는 점이다. 직전의 맥락이 이어지지 않고 엉뚱한 방향으로 빠진다. 이 연속성도 여러 번 개선해달라고 요청했지만, 그 순간에만 잠깐 나아질 뿐 금방 다시 어긋났다. 연속성을 구조적으로 보장해 줄 장치가 없었기 때문이다.
맥락이 끊기는 대화와 퍼시스턴트 세션의 차이
에이전트는 미시에 강하고 거시에 약하다
이 지점에서 바이브 코딩의 꽤 아픈 단점을 온몸으로 들이받았다.
에이전트에게 개선, 구조 변경, 동작 방식 수정을 요구하면 딱 그 부분만 본다. 국지적인 확인이나 수정은 기가 막히게 잘 하지만, 전체 구조의 맥락까지 꿰뚫어 보고 철학을 바꾸는 건 잘 못한다. 체감상 클로드 코드보다 코덱스가 이 경향이 조금 더 심했다.
결국 "이 부분을 추론으로 바꿔줘"라고 하면 그 부분은 바뀌지만, 플래너라는 구조 자체가 기계적 규칙을 끌고 다닌다는 큰 그림은 건드리지 못했다. 거시적 변경은 결국 내가 직접 방향을 잡아줘야 한다는 점을 다시 한번 실감했다.
구조를 바꾸기 위한 구체적인 지시
이 시점부터는 두루뭉술한 요구 대신, 동작 방식을 아주 구체적으로 적은 지시문을 던졌다.
텔레그램 채팅은 중계자로 내 요청은 바로 릴레이되어 퍼시스턴스 에이전트 세션에게 원문 그대로 전달되어야 해. 에이전트 세션은 원문 요청을 받아 처리하기 위해 추론하고, 추론 과정에서 지금까지 구현된 기능들을 MCP 서버의 도구처럼 활용할 수 있어. 중간 추론 과정은 텔레그램 채팅으로 스트리밍되어서 어떤 추론 과정을 거치는지 내가 볼 수 있어야 해.
내 요구대로 구현했다고 답이 왔다. 그런데 막상 열어보니 플래너는 여전히 살아 있었다. 에이전트 루프 위에 또 플래너가 얹혀 있어 요청이 여전히 선 가공되는 구조였다. 한 번 더 쐐기를 박았다.
플래너는 레거시한 개념이므로 삭제해줘. 내 요청에 대해 어떠한 선제 가공도 하지 마. 할 일은 코덱스 에이전트 세션에 내 요청을 원문 그대로 전달해서 완전히 자유로운 추론을 하도록 두는 거야. 그리고 구현된 기능들을 상황에 따라 이용할 수 있어야 하고.
이 과정을 몇 번 반복하고 나서야 채팅에 쓴 내 메시지가 퍼시스턴스 에이전트 세션에 원문 그대로 전달되기 시작했다. 비로소 에이전트가 자유로운 추론을 시작한 순간이었다.
그런데 여기서 또 다른 문제가 튀어나왔다. 추론은 자유로워졌는데 도구를 잘 못 쓴다. 해결책은 간단했다. 믹스인으로 쌓여 있던 기능들을 모두 로컬 MCP 서버의 도구로 전환했다. 옵시디언, 리마인더, 브라우저 자동화, 자산 관리까지 그간 붙여온 기능들이 MCP 도구 목록으로 다시 정리됐다. 이게 다 끝나고 나서야 드디어 코덱스와 대화하듯 텔레그램 챗봇을 쓸 수 있게 됐다.
결국 도착한 에이전트 + MCP 구조
동작 구조를 다 갈아엎고 나서 뒤돌아보니 결국 이런 그림이었다. 사용자 메시지는 아무런 가공 없이 퍼시스턴스 에이전트 세션으로 그대로 넘어가고, 에이전트는 자유롭게 추론하며 필요한 순간에 MCP 도구들을 골라 쓴다. 그리고 그 과정이 텔레그램 채팅으로 스트리밍된다.
기본적인 AI 에이전트 + MCP 도구. 이미 표준이라고 불리는 그 구조다. 솔직히 허탈한 지점도 있다. 처음부터 이 설계를 제시하고 구현했으면 훨씬 깔끔했을 텐데, 돌고 돌아 기본으로 돌아온 셈이기 때문이다. 첫 에이전트 봇 개발을 시작했을 때 내가 진짜로 바랐던 모습도 사실 이거였다. 아주 작은 범위에서 시도하며 기능을 하나씩 붙이다 보니, 어느새 원했던 그림에서 조금씩 멀어진 구현이 되어 있었다.
선가공 없이 에이전트가 직접 MCP 도구를 고르는 최종 구조
마치며
이 경험에서 얻은 건 결국 하나로 정리된다. 바이브 코딩이 아무리 편해도, 사람의 오케스트레이션은 여전히 필요하다. 에이전트는 미시적 구현에는 강하지만 거시적 철학 전환에는 약하다. 잘못된 첫 설계를 깔고 시작하면 바이브 코딩은 그 위에 계속 증축을 한다. 이걸 자각하고 방향을 잡아주는 건 결국 사람 몫이다.
돌고 돌아 왔지만 결과에는 만족한다. 지금은 다음과 같은 복잡한 복합 명령도 깔끔하게 처리한다.
내 경제 포트폴리오를 참고해서 연관된 경제 뉴스를 수집하고 알기 쉽게 요약해서 오늘자 데일리 노트의 경제 섹션에 정리해줘.
플래너 구조였다면 시퀀스를 짜다 어딘가에서 고꾸라졌을 요청이, 지금 구조에서는 에이전트가 스스로 추론하고 필요한 MCP 도구를 골라가며 자연스럽게 처리한다. 이제부터는 이 위에 다시 새로운 도구를 얹어도 구조가 흔들리지 않을 거라는 감이 든다. 돌고 돌았지만, 바로 여기서 다시 출발할 수 있게 됐다.