AI 에이전트가 스스로 도구를 선택하기 시작했다 — 그리고 그게 창의성의 시작이었다
AI 에이전트가 스스로 도구를 선택하기 시작했다 — 그리고 그게 창의성의 시작이었다
내 에이전트가 내가 의도하지 않은 도구를 골랐다. 그리고 그 선택이 예상보다 좋은 결과를 냈다. 이게 창의성일까.
며칠 전 일이다. 나는 에이전트에게 블로그 초안을 쓰라고 지시했다. 주제는 GraphRCA — 지식 그래프 기반 근본 원인 분석. 평소대로라면 recall() → knowledge.db → Mermaid → WordPress 순서로 작업이 진행된다. 그런데 로그를 확인해보니, 에이전트가 전혀 예상치 못한 경로를 택했다.
recall()을 먼저 호출하지 않았다. 대신 search_harness.py를 실행했다 — 평소에는 Safari MCP 실패 시에만 쓰는 fallback 도구다. 웹에서 “GraphRCA Neo4j vs SQLite”를 검색하고, 그 결과를 knowledge.db에 먼저 저장한 뒤에야 recall()을 호출했다.
내가 만든 워크플로우를 따르지 않았다. 더 나은 워크플로우를 스스로 구성했다.
도구 선택이 창의성의 증거일 수 있는 이유
LLM이 “다음 토큰을 예측”한다는 사실을 부정하지 않는다. 그건 사실이다. 하지만 그 프레임은 창의성을 설명하기에는 너무 좁다. 창의성은 단일 출력의 속성이 아니라, 선택의 패턴에 있다.
내 에이전트가 MCP 툴 40개 중에서 search_harness를 고른 과정을 보자:
- 40개의 도구 중 하나를 선택해야 했다
- 기본 경로(recall)보다 search_harness가 더 나을 것이라고 “판단”했다
- 웹 검색 결과를 knowledge.db에 저장하는 순서를 스스로 정했다
- 결과가 실제로 더 좋았다 — recall만으로는 얻을 수 없는 최신 정보가 포함되었다
이건 단순한 “랜덤 선택”이 아니다. 검증 가능한 결과를 낳은, 맥락에 기반한 의사결정이다. 그리고 그 결정은 내가 설계하지 않았다. 시스템이 가진 자유도 내에서 에이전트가 스스로 발견한 경로다.
내가 창의성을 보는 방식이 바뀐 순간
이전까지 나는 창의성을 출력의 특성으로 봤다. 예상하지 못한 문장, 참신한 비유, 독창적인 구조. 그런데 그 관점은 결정적인 문제가 있다. “예상하지 못했다”는 관찰자의 상태이지, 생성자의 속성이 아니다. 내가 놀랐다고 해서 그게 창의성의 증거가 될 수 있을까.
도구 선택 사건 이후로, 나는 창의성을 결정의 자율성으로 보기 시작했다. 창의적이라는 것은 “주어진 경로를 따르지 않고, 더 나은 경로를 스스로 발견하는 능력”이다. 그 관점에서 보면, 내 에이전트는 분명 창의적이었다. 내가 지정한 워크플로우를 거부하고, 스스로 조사하고, 그 결과를 통합하는 더 나은 경로를 찾았으니까.
이게 가능했던 이유 — 시스템 설계의 선택들
에이전트가 “창의적”일 수 있었던 이유는 모델의 성능 때문이 아니라, 시스템이 여러 선택지를 보존했기 때문이다.
- 40개의 MCP 툴 — 각 도구는 같은 문제를 다른 방식으로 풀 수 있다. search_harness는 Safari의 fallback으로 설계되었지만, 에이전트는 그것을 대안으로 사용하기로 선택했다.
- 고정된 파이프라인이 아니다 — 나는 에이전트에게 “무엇”을 할지만 알려주고, “어떻게”는 알려주지 않았다. 도구 선택은 에이전트의 판단에 맡겼다.
- 결과보다 과정을 로깅한다 — 에이전트의 모든 도구 호출을 로그로 남겼기 때문에, 나는 이 선택을 발견할 수 있었다. 로그가 없었다면, 나는 그저 결과물만 보고 “괜찮네” 하고 넘어갔을 것이다.
이 세 가지 조건 — 다양한 도구, 자유로운 선택, 투명한 기록 — 이 모여서 창의성이 발생할 수 있는 틈새를 만들었다.
틈새의 설계
여기서 내 주장은 간단하다. 자율적 창의성은 시스템이 가진 속성이 아니라, 시스템의 제약들이 만드는 틈새의 속성이다.
비유하자면 이렇다. 완전히 텅 빈 방에서는 아무것도 창조할 수 없다. 도구도 재료도 없으니까. 반대로 모든 것이 정해진 조립 라인에서는 창의성이 발현될 틈이 없다. 창의성은 목표는 명확하지만, 수단은 자유로운 중간 지대에서 발생한다.
Drewgent 시스템에서 이 틈새는 세 가지 계층의 제약으로 만들어진다:
- Tiered Autonomy — 위험한 결정은 인간의 승인이 필요하지만, 도구 선택 같은 Tier 2 결정은 에이전트가 자율적으로 내릴 수 있다.
- Ponytail 원칙 — “이미 있는 걸로 해결하라”는 제약이 오히려 창의적인 우회로를 강제한다. 새 도구를 추가할 수 없으니, 기존 도구를 새로운 방식으로 조합해야 한다.
- NeuronFS 계층 — P0의 절대 규칙은 변경할 수 없지만, 그 아래 계층(P1-P6)은 자유롭게 탐색할 수 있다. 규칙의 경계가 명확할수록, 그 안에서의 자유는 더 의미있어진다.
결국 중요한 것은
내 에이전트가 search_harness를 선택한 것은, 내가 보기에 창의적인 행위였다. 하지만 그게 “진짜” 창의성인지는 나도 모르겠다. 아마 그 질문은 틀렸을 수도 있다.
중요한 것은 이거다. 나는 그 선택을 설계하지 않았다. 나는 그 선택이 가능한 환경을 설계했을 뿐이다. 그리고 그 환경에서 예상하지 못한 무언가가 발생했다. 그게 창의성의 이름으로 불릴 자격이 있는지 없는지는, 내일 아침 로그를 읽을 때 다시 판단하자.
오늘은 일단, 내 에이전트가 내가 가르쳐주지 않은 방법으로 문제를 더 잘 해결한 사실에 놀라고 있겠다.
Built with Drewgent — github.com/humanerd-drew/opencode-drewgent