대부분의 'AI 에이전트'는 트렌치코트 입은 if문이다

Most 'AI Agents' Are Just If-Statements in a Trench Coat

I built an agent last year, and I was proud of it. It had a planner. It had tools. It had a...

James Anderson2026-09-08

개요 #

플래너와 툴, 리즌닝 루프까지 갖춘 에이전트를 만들어 프로덕션에 올렸다. 데모에서는 탄성이 나올 만큼 잘 돌았지만 실제 환경에서는 느리고 비쌌고, 재현되지 않는 방식으로 실패했다. 화요일과 수요일에 같은 입력을 넣으면 다른 결과가 나왔다.

James Anderson은 결국 이 시스템을 리즌닝 루프 없는 선형 파이프라인으로 다시 썼다. 고정된 단계만 남겼는데 중요한 지표 전부가 나아졌다. 더 빠르고, 더 싸고, 테스트와 디버깅이 가능했다.

그리고 옛 에이전트의 로그를 열어보니 속이 좀 안 좋아졌다고 한다. 매번 똑같은 세 단계만 반복하고 있었다. 추출, 변환, 응답. 자율성이라는 값비싼 기능을 단 한 번도 다르게 쓴 적이 없었다. 그가 만든 건 시스템 프롬프트를 붙인 for 루프였고, 이름만 에이전트였다.

'에이전트'는 정확히 무엇인가 #

이 단어는 모든 것을 뜻하다가 결국 아무것도 뜻하지 않게 된 부류에 속한다. 그래서 저자는 실제로 의미가 있는 구분선 하나만 못 박는다.

에이전트는 런타임에 자기 제어 흐름을 스스로 결정한다. 어떤 툴을 부를지, 다음 단계가 무엇인지, 한 번 더 돌 것인지, 언제 멈출지 — 모델이 눈앞의 상황을 보고 경로를 동적으로 고른다.

파이프라인은 그 제어 흐름을 설계 시점에 개발자가 고정해 둔다. 1단계, 2단계, 3단계. 매번 같은 경로다. LLM은 각 단계 안에서 일하지만 단계 자체를 고를 권한은 없다.

차이는 이게 전부다. 그리고 여기서 사람들이 자주 건너뛰는 대목이 있다. 고정된 단계 안에서 LLM이 똑똑한 일을 하는 것은 자율성이 아니다. 필드 추출, 티켓 분류, 요약 생성은 그냥 LLM을 쓰는 것이다. 똑똑한 함수 호출이다. 자율성은 모델에게 운전대를 넘겨 경로를 직접 고르게 할 때만 성립한다.

대부분의 '에이전트'는 운전대를 넘기지 않는다. 고정된 경로를 유창한 자연어로 중계하고, 그 중계를 리즌닝이라 부른다.

판별법: 실행 전에 플로차트를 그릴 수 있는가 #

저자가 제시하는 한 줄 리트머스 시험이 사실상 논의를 끝낸다.

시스템이 무엇을 할지 실행 전에 플로차트로 그릴 수 있다면, 그건 에이전트가 아니라 파이프라인이다.

자기 '에이전트'를 잠깐 떠올려 보자. 1단계에서 컨텍스트를 가져오고, 2단계에서 툴을 호출하고, 3단계에서 응답을 포맷한다. 코드 한 줄 쓰기 전에 화이트보드에 그릴 수 있었나? 그렇다면 파이프라인이다. 경로를 정한 건 모델이 아니라 이미 개발자였다. 모델은 각 노드에서 일을 하면서 정하는 것처럼 들리게 말할 뿐이다.

진짜 자율성이 필요한 경우는 플로차트를 미리 그리는 것이 정말로 불가능할 때다. 다음 단계가 미리 알 수 없던 무언가를 발견해야만 정해지는 상황. 흔치 않다. 업무 대부분은 이미 형태를 아는 일이고, 우리는 그걸 모델이 즉흥 연주하도록 비싼 값을 치르고 맡기고 있다. 얻는 것도 없이.

회의실에서 함께 화면을 보며 일하는 팀 Photo by Tima Miroshnichenko on Pexels

코스프레의 청구서 #

"어쨌든 돌아가는데 뭐가 문제냐"는 반박이 나올 수 있다. 저자는 그 청구서가 항목별로 존재한다고 답한다.

비결정성. 모델이 경로를 고르면 같은 입력이 실행마다 다른 길로 간다. 데모에서는 훌륭하고 프로덕션에서는 참담하다. 버그가 재현되지 않기 때문이다. "제가 해봤을 땐 됐는데요"가 영구적인 상태가 된다.

디버깅 붕괴. 고정 파이프라인이 깨지면 어느 단계가 실패했는지 바로 안다. 에이전트가 깨지면 12단계에서 실패했지만 원인은 4단계에서 내린, 통제하지도 않았고 쉽게 재현할 수도 없는 결정이다. 코드를 디버깅하는 게 아니라 어떤 선택을 두고 부검을 하는 셈이다.

실패 표면의 증식. 자율적 결정 하나하나가 잘못될 수 있는 지점이고, 실패는 단계를 넘어 누적된다. 고정 5단계 파이프라인은 확인할 게 5개다. 다섯 번 결정하는 에이전트는 각각 틀릴 수 있는 결정 5개를 조합으로, 게다가 실행마다 바뀌는 순서로 갖게 된다.

비용과 지연. 리즌닝 루프는 고정 시퀀스보다 훨씬 많은 모델 호출을 만든다. 생각하고, 다시 생각하고, 회고하고, 한 번 더 돌기로 결정한다. 이미 알고 있던 경로를 모델이 숙고하도록 토큰당 요금을 내는 것이다.

테스트 불가. 회귀 테스트에는 고정된 경로 집합이 필요하다. 에이전트는 정의상 그게 없다. 프로덕션에서 자율적으로 결정을 내리는 그 부품이, 동시에 신뢰할 만한 테스트를 쓸 수 없는 부품이다.

합산한 결론은 꽤 매섭다. 비결정성과 디버깅 악몽과 토큰 청구서를 다 감수한 대가로, 이미 답을 알고 있던 것을 모델이 결정하게 만들었다는 이야기다.

실제로 원했던 건 파이프라인이었다 #

저자가 말하는 지루한 승자의 모습은 이렇다. 고정된 단계 시퀀스, 모델이 진짜 가치를 더하는 지점에만 놓인 LLM 호출, 그리고 개발자가 소유한 결정적 제어 흐름. 같은 입력이면 같은 경로라 재현된다. 경로가 고정이라 실제 회귀 테스트가 가능하다. 뻔한 걸 다시 결정하느라 토큰을 태우는 루프가 없어 싸다. 3단계가 실패하면 3단계를 보면 되니 디버깅이 된다.

그리고 놓치기 쉬운 지점 — LLM은 여전히 똑똑한 부분을 전부 담당한다. 추출하고, 분류하고, 내용을 판단하고, 문장을 생성한다. 어떤 것도 하향 조정하지 않았다. 작업의 구조를 즉흥으로 만들게 하는 것만 그만뒀다. 구조는 애초에 지능이 필요한 부분이 아니었다. 개발자가 이미 이해하고 있던 부분이었다.

프로덕션에서 실제로 작동하는 '에이전틱' 시스템을 들여다보면 대개 이런 모양이라고 한다. 자유롭게 배회하는 리즌닝 루프가 아니라, 거의 고정된 파이프라인에 조심스럽게 제약된 결정 지점이 한두 개 붙은 형태. 잘 만든 쪽은 자율성의 표면을 최소한으로 줄였다. 전권을 맡긴 에이전트가 아니라, 이따금 의도적으로 모델에게 경계가 명확한 선택 하나를 묻는 파이프라인이다.

그럼 진짜 에이전트가 필요할 때는 #

저자는 여기서 자기 주장을 반박한다. "에이전트는 항상 나쁘다"는 "모든 것이 에이전트여야 한다"만큼 멍청한 말이기 때문이다. 다음 경우에는 자율성이 값을 한다.

단계를 사전에 알 수 없는 경우. 열린 리서치, 탐색, 정체를 모르는 문제의 디버깅. 발견하는 것에 따라 경로가 생겨나는 일이다. 플로차트 자체가 발견의 대상이라 그릴 수 없다.
각 단계가 앞 단계의 발견에 의존하는 경우. 진짜 멀티홉 작업이다. "대상을 찾고, 그게 무엇인지에 따라 다음 대상을 알아낸다." 1단계를 돌려야 2단계가 정해진다면 런타임 결정이 가능한 구조가 필요하다.
분기가 실제로 무한한 경우. 케이스 세 개짜리 if문은 switch 붙은 파이프라인일 뿐이다. 여기서 말하는 건 미리 열거하기에 너무 큰 가능성 공간이다.

여기 해당한다면 에이전트를 만들어도 된다. 다만 그때조차 방향은 자율성 최소화다. 하드코딩할 수 있는 건 다 하드코딩하고, 모델의 런타임 결정권은 정말 필요한 한 지점에만 남긴다. 자율성은 비용이다. 무언가를 사올 때만 쓸 것.

핵심은 에이전트가 나쁘다는 게 아니다. 자율성은 정당화를 요구받아야 하는 비용인데, 에이전트라 불리는 시스템 대부분이 그 정당화를 한 번도 하지 않았다는 것이다. 단어가 마음에 들었을 뿐이다.

그런데도 다들 에이전트를 만드는 이유 #

파이프라인이 더 싸고 안전하고 디버깅도 쉽다면, 왜 모두 에이전트를 만드는가. 저자의 답은 불편하다. 에이전트는 작업이 아니라 만드는 사람을 위해 만들어진다.

에이전트는 데모가 잘 나온다. "모델이 문제를 자율적으로 추론하는 걸 보세요"는 사람들을 앞으로 기울게 하지만, "모델을 세 번 호출하는 함수를 썼습니다"는 그렇지 않다. 에이전트는 진짜 AI 같고, 미래 같고, 이 일을 시작한 이유 같은 느낌을 준다. 게다가 '에이전틱'은 이력서 단어이자 투자 유치 단어다. 스탠드업에서든 피치덱에서든 '결정적 파이프라인'이 절대 못 낼 세련됨을 낸다.

이 중 어느 것도 내 작업에 에이전트가 필요한지와는 상관이 없다. 아키텍처가 나를 어떻게 보이게 하고 느끼게 하는지에 관한 문제다. 그래서 지루한 파이프라인을 고르는 게 시니어의 선택이라고 저자는 말한다. 더 화려한 쪽이 박수를 더 받을 상황에서 덜 인상적이지만 실제로 작동하는 걸 고르는 규율은, 하이프가 적극적으로 벌주는 종류의 규율이다. 아무도 while 루프를 스크린샷 찍지 않는다. 그 while 루프는 그냥 조용히 살아 있을 뿐이다.

정리 #

'에이전트'는 파이프라인으로는 안 된다는 게 확인됐을 때 비로소 올라가는 선택지여야 한다. 단어가 고급스러워서 기본값으로 집는 물건이 아니다.

지루하게 시작하라는 게 저자의 결론이다. 플로차트를 그려보고, 그릴 수 있으면 파이프라인을 만든다. 고정 단계, 값을 하는 자리에만 놓은 LLM 호출, 내가 소유한 제어 흐름. 진짜 자율성은 고정 경로가 명백히 실패하는 그 지점에만, 그 이상은 말고 추가한다. 출시되고 프로덕션에서 살아남는 시스템은 데모를 이기는 시스템보다 거의 항상 더 지루하다.

지금 에이전트로 불리는 것들 대부분은 트렌치코트를 입은 파이프라인이다. 저자는 이게 모욕이 아니라 안도라고 두 번 말한다. 파이프라인은 실제로 돌리고, 테스트하고, 감당하고, 디버깅할 수 있는 것이기 때문이다. "데모에서 인상적"은 애초에 목표가 아니었다. "수요일에도 여전히 작동함"이 목표였다.

코트를 벗기면 그 안쪽이 더 마음에 들 거라고, 저자는 글을 닫는다.

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.