Agent Loop 아저씨, 보이지 않는 책임(Responsibility)에 패배하다

안녕하세요, Agent Loop 아저씨입니다.

Agent Skills에 MCP, 그리고 Loop 발동. 크으~ 참을 수 없네. 이것이 바로 Agent Loop라는 것이다. LLM이 알아서 모든 것을 해결해 준다.

게다가 AG-UI를 통해 화면 측에 지금 무엇을 하고 있는지도 보여준다. 모더니제이션(Modernization)이다.

……라고 생각하던 시기가 있었습니다.

우와ㅋ, 출력이 이상할 때 어디를 고쳐야 할지 모르겠다.

PoC(Proof of Concept)는 생각보다 쉽게 돌아갑니다. Agent Framework에 맡기면 LLM 호출도, tool 연결도, structured output도, trace도 그럴싸하게 갖춰집니다.

하지만 조금 복잡한 태스크에 다가가자 다른 문제가 나타났습니다. 출력이 이상할 때 어디를 고쳐야 할지 모르겠습니다.

prompt인가. context인가. workflow인가. schema인가. reflection인가. tool calling인가.

모든 것을 하나의 Agent Loop에 던져 넣었을 때, 작동할 때는 기분이 좋습니다. 하지만 어긋났을 때 어떤 책임(Responsibility)에서 어긋난 것인지 보이지 않습니다.

자유도가 높다는 것은 책임의 경계가 녹아 있다는 뜻이기도 했습니다.

처음에는 MAF, Microsoft Agent Framework를 사용하고 있었습니다. 추상화(Abstraction)를 사용하면 호출도 structured output도 정리할 수 있을 것이라고 생각했죠.

그런데 Codex에게 MAF를 사용한 구현을 부탁하니, workflow와 Agent loop의 중간 같은 코드가 나왔습니다. 완전한 workflow도 아니고, 완전한 autonomous loop도 아닙니다.

우와ㅋ, coding Agent조차 헤매고 있잖아.

Codex가 잘못된 것이 아닙니다. 반대입니다. 추상의 자유도가 넓기 때문에 어디에 무엇을 두어도 성립해 버립니다. 인간도 AI도 놓을 장소가 정해져 있지 않으면 헤맵니다.

내가 원했던 것은 그 자유도가 아니라, workflow는 workflow, model call은 model call, context provider는 context provider로서 분리되어 있는 것이었습니다.

보이게 된 것은 orchestration(workflow를 진행하는 것)과 execution(node 안에서 model call을 실행하는 것)을 같은 framework의 같은 책임으로 만들 필요는 없다는 사실이었습니다.

두 가지를 같은 framework로 모으면 언뜻 정리되어 보입니다. 하지만 실제로는 책임이 섞입니다. 섞이면 부품을 교체하기 어려워집니다.

우와ㅋ, 밀결합(Tight Coupling)이잖아.

분리해 두면 workflow는 LangGraph 그대로 두고, node 내부의 model runtime만 MAF에서 Pydantic AI로 교체할 수 있습니다. 전부 하나에 넣으면 처음에는 기분이 좋습니다. 하지만 나중에 어디를 빼야 할지 알 수 없게 됩니다.

Agent Framework를 고르는 이야기라고 생각했는데, 실제로 막혔던 것은 "어떤 책임을 어디에 둘 것인가"였습니다.

책임을 나누고 나니 남은 것은 꽤 수수한 모습이었습니다.

workflow는 LangGraph. output schema는 Pydantic. prompt surface는 Jinja. context는 MCP를 application이 deterministic하게 호출. Skill은 판단 축. Reflection은 별도의 node. trace는 Langfuse. UI는 system state를 출력.

우와ㅋ, 그냥 소프트웨어 설계잖아.

상태를 외부에 둔다. 입출력 계약(Contract)을 가진다. prompt surface를 분리한다. context provider를 제어한다. trace를 남긴다. 새로운 것을 하는 것 같지만 상당히 고전적입니다. 고전으로 돌아왔다기보다, 문제 구조가 고전을 불러온 것입니다.

가장 컸던 것은 책임을 나누면 실패가 "수정 가능한 signal"이 된다는 점이었습니다.

실패했을 때 prompt가 잘못된 것인가. context가 부족한 것인가. MCP의 candidate가 약한 것인가. output schema가 거친 것인가. reflection이 약한 것인가. routing이 틀린 것인가.

우와ㅋ, CI(Continuous Integration)잖아.

Agent Loop에 모든 것이 녹아 있으면 실패는 그저 실패가 됩니다. "뭔가 미묘함"으로 끝나버리죠. 하지만 책임이 나누어져 있다면 실패는 다음 PR을 끊을 수 있는 signal이 됩니다.

보이는 책임만이 고칠 수 있는 책임입니다.

Agent Framework에 전부 맡겨버리기. 하나의 loop로 돌아가는 쾌감. "일단 돌아간다"는 안도감.

대결해 주셔서 감사합니다.

Agent Loop 아저씨, 보이지 않는 책임(Responsibility)에 패배했습니다.

패배한 상대는 외부 서비스도, 더 똑똑한 모델도, 더 강력한 framework도 아니었습니다. 스스로 보이지 않게 만든 책임(Responsibility)의 위치였습니다.

통째로 맡기기(Agent Loop에 전부 맡기기)로 이기려 했던 것이, 뺄셈(책임을 나누어 보이게 만들기)으로 이겼습니다. 자유도를 높일수록 이기는 것이 아니라, 책임을 보이는 위치에 둘수록 고칠 수 있게 되었다는 이야기입니다.

Agent Loop를 믿기 전에, 책임이 보이는 위치에 있었는가에 대한 이야기입니다.