왜 지금까지 만들어진 모든 에이전트는 Claude Code보다 못한 걸까?
Why is every agent ever made just a worse Claude Code?
핵심 요약
Claude Code가 범용적으로 뛰어난 성능을 보이면서, 굳이 복잡한 에이전트 워크플로우를 따로 구축할 필요가 있는지에 대한 회의감을 토로하는 글입니다.
- Claude Code의 범용성 — 복잡한 에이전트 설계 없이도 대부분의 작업을 수행함
- 에이전트 설계의 의문 — 도구 정의와 워크플로우 구축이 단순히 효율성을 위한 것인지 고민함
- 문제 분해의 난이도 — 모든 문제를 Claude Code가 해결 가능한 작업 단위로 쪼갤 수 있는지 의문을 제기함
- 에이전트의 한계 — Claude Code보다 기능이 떨어지는 에이전트를 만드는 상황에 대한 자괴감
지난 몇 주 동안 오픈형 에이전트 솔루션을 구축하는 작업을 맡으면서 조금 미칠 것 같아서 현실 점검이 좀 필요합니다.
Claude를 유능한 하네스로 정의해 봅시다. Claude Code가 현재로서는 아마 최고일 텐데, 본인이 생각하기에 최고라고 느끼는 것으로 대체해도 좋습니다.
기본적으로, 지금까지 만들어진 모든 에이전트가 사실 데이터에 가드레일이 쳐진, Claude보다 못한 무언가일 뿐이라는 생각을 지울 수가 없습니다.
사소한 예로, 오케스트레이터 에이전트, 데이터베이스 에이전트, 그리고 내부 지식(PDF, 벡터 DB 등)에 접근할 수 있는 지식 에이전트가 있다고 칩시다. 이걸 구현하려면 각 에이전트의 능력을 정의해야 합니다. 오케스트레이터 에이전트는 구조화된 계획을 세워야 하고, 데이터베이스 에이전트는 SQL 쿼리를 작성하고 호출해야 하며, 지식 에이전트는 벡터 DB와 상호작용하고 마크다운 파일을 탐색해야 하죠.
이건 그 자체로는 꽤 잘 작동하지만, Claude Code는 /goal 명령어로 이 모든 걸 할 수 있습니다. DB 스키마를 탐색하거나 마크다운을 찾는 데 몇 번의 사이클이 더 걸릴 수는 있어도 결국 해냅니다. tools=[]를 사용해서 에이전트의 능력을 정의하는 게 도대체 무슨 의미가 있을까요? 그냥 도구로 지름길을 만들 수 있는 솔루션을 반복하는 사이클을 제한하는 문제일 뿐인가요? 그게 다인가요?
이 문제 때문에 머리가 터질 것 같습니다. 제 생각에는 아무리 추상적이고 복잡한 문제라도, 각 노드가 Claude Code가 해결할 수 있는 작업(컴퓨터에서 실행 중이고 HITL 제한이 없다고 가정할 때)인 DAG로 구성할 수 있을 것 같습니다. 정말 문제는 문제 분해(problem decomposition)뿐인가요? 이 분해라는 게 정말 그렇게 어려운 건가요?
Claude Code 자체보다 기능이 떨어지는 에이전트 워크플로우를 또 만들라는 과제를 받으면서, 날이 갈수록 아이러니에 중독되는 기분입니다 lol.

