스틸맨: AI 에이전트가 복잡성을 감수할 만해지는 순간

본문

이 글은 대부분의 ‘AI 에이전트(AI agent)’가 실제로는 LLM 호출 하나를 포함한 결정적 워크플로, 즉 트렌치코트를 입은 파이프라인에 불과하다는 기존 비판에서 출발합니다. 이전 논의에서 한 사용자는 자신의 에이전트를 감사한 결과 94%의 실행에서 같은 네 번의 API 호출을 같은 순서로 수행했고, 나머지 6%도 재시도(retry)였다고 말했습니다. 그러나 글쓴이는 여기서 멈추지 않고, 반대편의 가장 강한 논거를 세우는 ‘스틸맨(steelman)’을 시도합니다. 정말 자율적인 에이전트가 필요한 경우가 있다면 언제인지, 그리고 그 복잡성과 비용을 어떤 기준으로 정당화할 수 있는지를 엄격하게 따집니다.

에이전트의 비용을 먼저 계산해야 합니다

핵심 질문은 ‘에이전트로 할 수 있는가’가 아닙니다. 에이전트라면 거의 무엇이든 할 수 있기 때문에 이 질문은 유용하지 않습니다. 대신 모델이 제어 흐름(control flow)을 직접 소유해야 하는지 물어야 합니다. 모델에 제어권을 넘기면 같은 입력에도 다른 경로를 택할 수 있는 비결정성(nondeterminism)이 생기고, 재현 가능한 스택 트레이스를 읽는 대신 의사결정 과정을 조사해야 하는 디버깅 비용이 발생합니다. 이미 알고 있는 경로를 추론 루프가 다시 검토하면서 토큰 비용도 늘어나며, 고정된 실행 경로가 없는 시스템에서는 회귀 테스트(regression test)를 설계하기도 어렵습니다.

따라서 정당화의 기준은 런타임에 모델이 제어 흐름을 결정해야 하는 상황이 실제로 존재하는지, 그 결정이 설계 시점에는 만들어질 수 없었는지, 그리고 그 대가를 감수할 가치가 있는지입니다. 글은 대부분의 작업이 이 기준을 충족하지 않는다고 봅니다.

외부 환경이 다음 단계를 결정하는 경우

첫 번째 정당화 조건은 시스템 바깥의 응답이 다음 단계를 결정하는 경우입니다. 협상, 코칭, 지원, 대화처럼 실시간 참여자의 답변에 따라 경로가 달라지는 작업에서는 대화의 흐름을 미리 완성된 플로차트로 그릴 수 없습니다. 환경이 단순한 고정 입력이 아니라 시스템의 두 번째 작성자처럼 작동하기 때문입니다.

외부 API의 응답에 따라 다음 행동이 달라지거나, 하룻밤 사이 변경된 DOM(Document Object Model)을 만나는 스크래퍼(scraper), 실패 양상을 완전히 열거할 수 없는 도구를 다루는 경우도 같은 논리로 설명합니다. 중요한 테스트는 ‘시스템 바깥에서 온 응답이 다음 행동을 결정하는 단계가 있는가’입니다. 반대로 세 개의 도구를 정해진 순서로 호출하는 작업이라면 환경이 대화하는 것이 아니라 시스템이 스스로 정한 절차를 실행하는 것입니다.

실행을 통해 경로를 발견하는 다중 홉 작업

두 번째 조건은 진정한 다중 홉(multi-hop)입니다. 대표적인 사례로 글은 개방형 디버깅(open-ended debugging)을 듭니다. 첫 번째 단계에서 나온 트레이스백(traceback)을 확인하기 전에는 두 번째 단계를 알 수 없고, 빈 입력에서만 나타나는 버그는 코드를 읽는 것만으로 드러나지 않으며 실제 실행 결과를 확인해야 존재를 알 수 있습니다. 연구와 탐색도 동일합니다. 각각의 발견이 다음 질문을 결정하므로, 답변을 보기 전에는 질문 목록을 미리 만들 수 없습니다.

이를 판별하는 더 날카로운 질문은 ‘아무도 작성하지 않은 경로가 나타날 수 있는가’입니다. 미리 열거하지 못한 원시 동작(primitives)을 조합해 실행 순서를 만들어낸다면 경로를 발견하는 진짜 자율성에 가깝습니다. 반면 모델이 선택하는 모든 경로가 개발자가 작성한 코드의 어느 한 줄로 거슬러 올라간다면, 분기 수가 많더라도 그것은 에이전트가 아니라 변장한 분기 로직입니다. 핵심 차이는 경로가 달라지는지 여부가 아니라, 모델이 경로를 조합하는지 아니면 이미 작성된 경로 중 하나를 고르는지에 있습니다.

열거할 수 없는 분기와 단순한 의사결정 트리의 구분

동적으로 보인다는 이유만으로 에이전트가 되는 것은 아닙니다. 오류가 나면 도구 A를 호출하고, 다시 실패하면 도구 B를 호출하고, 그래도 안 되면 C로 에스컬레이션하는 구조는 단일 선형 흐름으로 그리기 어렵더라도 고정된 의사결정 트리입니다. 재시도와 백오프(retry with backoff), 다섯 개의 알려진 경로를 가진 라우터(router)도 마찬가지입니다.

판별 기준은 충분한 시간을 들이면 모든 경로를 명시적인 if 문으로 작성할 수 있는지입니다. 가능하다면 코드로 작성하는 편이 디버깅하기 쉽습니다. 진짜 자율성의 후보는 분기 공간 자체가 실행 시점 전에는 열거 불가능한 경우, 즉 단순히 작성하기 귀찮은 것이 아니라 가능성의 공간이 본질적으로 열려 있는 경우입니다.

자율 영역은 가장 작게 만들어야 합니다

위 조건을 만족하더라도 해결책은 에이전트 전체를 풀어놓는 것이 아닙니다. 자율적인 표면(autonomous surface)을 최소화해야 합니다. 글은 열다섯 단계 중 한 번의 의사결정만 모델에 맡기고 나머지는 결정적으로 처리하는 설계를 강조합니다. 모델은 런타임 판단이 실제로 필요한 한 지점만 소유하고, 나머지는 테스트 가능하고 단순한 코드가 맡아야 합니다.

따라서 설계 질문은 ‘에이전트인가 파이프라인인가’가 아니라 의사결정 경계(decision boundary)를 어디에 둘 것인가입니다. 모델이 제어 흐름을 더 많이 소유한다고 시스템이 더 유능해지는 것은 아니며, 오히려 디버깅 가능성이 낮아집니다. 진짜 에이전트조차 대부분의 주변부는 파이프라인이어야 하며, 자율성은 하나의 분기 지점과 제한된 선택, 강제된 대체 경로(fallback) 정도로 좁혀야 합니다.

검증 가능성과 기록이 마지막 관문입니다

동적인 작업이고 자율 영역도 최소화했더라도, 각 자율 결정의 결과를 빠르게 확인할 수 없고 그 확인 과정이 기록되지 않는다면 자율성을 정당화할 수 없습니다. 변경된 DOM에 맞춰 동작하는 스크래퍼가 정당화되는 이유는 데이터를 가져왔는지 즉시 확인할 수 있기 때문입니다. 429 응답 뒤 재시도하는 결정도 요청이 성공했는지라는 명확하고 저렴한 신호가 남습니다.

반대로 검증할 수 없는 자율성은 비결정성을 더 비싼 형태로 바꾼 것에 불과합니다. 결정의 정확성을 신속하게 확인할 수 없거나, 확인 결과를 지속적으로 기록할 수 없다면 실패 원인을 추적하기 어렵습니다. 기록에는 단순히 검사가 실행됐다는 사실뿐 아니라 누가 확인했는지도 남아야 합니다. 작성자 없는 성공 표시(authorless green light)는 누구도 책임지고 지지 않는 결과가 되기 때문입니다.

네 가지 조건과 결론

글이 제시하는 기준은 네 가지입니다. 첫째, 아무도 작성하지 않은 경로가 나타나야 하며 환경의 응답이나 런타임 탐색이 실제 경로를 만들어야 합니다. 둘째, 분기 공간이 충분히 열려 있어 사전에 의사결정 트리로 열거할 수 없어야 합니다. 셋째, 모델이 런타임 판단에 필요한 최소 지점만 맡고 나머지는 결정적 코드가 처리해야 합니다. 넷째, 각 결정의 결과를 저렴하게 검증할 수 있고, 누가 확인했는지를 포함한 기록이 남아야 합니다.

이 네 가지 중 하나라도 빠지면 에이전트 가격을 지불하면서 파이프라인을 운영하는 셈입니다. 모두 충족한다면 복잡성은 비로소 정당한 이유를 갖습니다. 글쓴이는 이 결론이 이전의 에이전트 비판과 모순되지 않는다고 말합니다. 오히려 진짜 에이전트의 가장 강한 변호를 끝까지 밀어붙일수록, 실제 운영 환경에서 네 조건을 모두 만족하는 작업이 얼마나 적은지 더 분명해집니다. 글은 마지막으로 네 조건을 모두 충족하는 시스템을 데모가 아니라 프로덕션에 배포한 사례가 있는지 묻습니다.

원문: dev.to / 번역·요약: Trawling