AI 에이전트? 속지 마세요, 대부분 '코트 입은 파이프라인'입니다

작년에 저는 직접 에이전트를 하나 만들었고, 그때는 정말 자랑스러웠습니다.

명확한 플래너가 있었고, 필요한 도구들도 갖췄죠. 다음 단계는 무엇을 할지, 자신의 출력물을 어떻게 반성할지, 그리고 여러 단계를 유기적으로 연결하여 실제 작업을 수행하는 추론 루프까지 완벽하게 구현했습니다. 데모 시연에서는 정말 인상적이었어요. "오!" 하는 탄성을 자아낼 만한 시스템이었죠.

하지만 이 에이전트가 실제 프로덕션 환경에 배포되자마자 문제는 터져 나왔습니다. 너무 느렸고, 비쌌으며, 도저히 재현할 수 없는 방식으로 오류가 발생했어요. 화요일에 동일한 입력값을 넣었는데 수요일에는 전혀 다른 행동을 하더라고요. 시스템이 뻗었을 때, 그 원인은 제가 제어할 수도, 심지어 볼 수도 없었던 세 가지 "자율적 결정"에 있었습니다.

그래서 저는 멋지지 않지만 실용적인 해결책을 택했습니다. 그 에이전트를 지루하고 선형적인 파이프라인으로 다시 작성했죠. 고정된 단계, 추론 루프는 제거했습니다. 결과는 놀라웠어요. 속도, 비용, 테스트 용이성, 디버깅 용이성 등 모든 면에서 훨씬 더 나아졌습니다.

그리고 문득 예전 "에이전트"의 로그를 확인했을 때, 솔직히 속이 좀 울렁거렸습니다. 그 에이전트는 매번 똑같은 세 가지 단계만 반복하고 있었어요. 추출(Extract), 변환(Transform), 응답(Respond). 모든 실행에서요. 한 번도 귀한 '자율성'을 사용해 다른 일을 시도한 적이 없었던 겁니다. 저는 그저 for 루프를 만들어 놓고, 시스템 프롬프트를 줬을 뿐인데, 그걸 에이전트라고 부르고 있었던 거죠. 제가 실무에서 이 부분을 테스트해 봤을 때, 특히 비재현성 버그는 정말 골치 아팠습니다. 같은 인풋인데도 어떨 땐 되고 어떨 땐 안 되니, 밤새 로그만 뒤적이던 기억이 생생하네요.

이런 경험을 한 사람이 저뿐이라고 생각하지 않습니다. 2026년에 '에이전트'라고 불리는 대부분은 사실 트렌치코트를 입은 파이프라인일 뿐이라고 확신해요. 그리고 저는 이게 결코 모욕적인 말이 아니라는 점을 강조하고 싶습니다. 오히려 안도감에 가깝습니다.

'에이전트'의 진짜 정의 (아무도 제대로 설명 안 해주는 것)

'에이전트'는 너무 많은 것을 의미하게 되면서 결국 아무것도 의미하지 않게 된 단어 중 하나입니다. 그래서 이 논의의 핵심이 되는, 정말 중요한 한 가지 차이점을 명확히 짚어보겠습니다.

에이전트는 런타임에 스스로 제어 흐름을 결정합니다. 어떤 도구를 호출할지, 다음 단계는 무엇일지, 다시 반복할지, 언제 멈출지 등—모델이 자신이 보는 것에 따라 동적으로 경로를 선택합니다.

파이프라인은 설계 시점에 당신이 제어 흐름을 고정합니다. 1단계, 그다음 2단계, 그리고 3단계. 매번 같은 경로를 따르죠. LLM은 각 단계 내부에서 작업을 수행하지만, 단계를 선택할 권한은 없습니다.

이것이 전부입니다. 그리고 사람들이 자주 간과하는 부분이 있습니다. 고정된 단계 안에서 LLM이 똑똑한 일을 한다고 해서 그것이 '에이전시(Agency)'는 아닙니다. 필드를 추출하거나, 티켓을 분류하거나, 요약을 생성하는 것은 그저 LLM을 활용하는 것일 뿐입니다. 똑똑한 함수 호출과 다를 바 없죠. 에이전시란 모델이 직접 운전대를 잡고 경로를 선택할 때 비로소 발휘되는 것입니다.

대부분의 '에이전트'는 실제로 운전대를 넘겨주지 않습니다. 그저 고정된 경로를 유창한 자연어로 설명하고, 그 설명을 '추론(reasoning)'이라고 부를 뿐이죠.

리트머스 테스트: 미리 플로우차트를 그릴 수 있는가?

이 모든 논의를 한 문장으로 압축하는 결정적인 리트머스 테스트가 있습니다.

시스템이 실행되기 전에 어떤 작업을 할지 플로우차트로 그릴 수 있다면, 당신은 에이전트가 아닌 파이프라인을 가지고 있는 것입니다.

당신의 '에이전트'를 잠시 들여다보세요. 1단계: 컨텍스트를 검색합니다. 2단계: 도구를 호출합니다. 3단계: 응답을 포맷합니다. 이 모든 과정을 코드를 한 줄도 작성하기 전에 화이트보드에 그릴 수 있었나요? 그렇다면 그건 파이프라인입니다. 모델이 경로를 결정하는 것이 아니라, 당신이 이미 결정한 것입니다. 모델은 그저 각 노드에서 작업을 수행하며, 마치 스스로 결정하는 것처럼 들릴 뿐이죠.

진정한 에이전시는 플로우차트를 미리 그릴 수 없을 때만 필요합니다. 즉, 미리 알 수 없었던 무언가를 발견해야 다음 단계를 결정할 수 있을 때 말이죠. 이런 경우는 드뭅니다. 대부분의 비즈니스 작업은 이미 그 형태를 이해하고 있습니다. 어떤 단계가 필요한지 당신은 이미 알고 있죠. 그런데 모델에게 엄청난 비용을 들여, 아무런 이득도 없이 즉흥적인 판단을 맡기고 있는 셈입니다.

그 '화려한 코트'가 비싼 이유

"좋아, 기술적으로는 파이프라인이라고 치자. 하지만 잘 작동하는데 뭐가 문제야?" 라고 반문할 수도 있겠죠. 문제는 시스템을 운영하고, 비용을 지불하고, 새벽 2시에 디버깅해야 하는 모든 사람에게 있습니다. 파이프라인을 에이전트인 척하는 데는 실제 비용이 따르며, 그 비용은 항목별로 청구됩니다.

비결정론성 (Nondeterminism). 모델이 경로를 선택하면, 같은 입력도 실행할 때마다 다른 경로를 택할 수 있습니다. 데모용으로는 훌륭하지만, 프로덕션에서는 비참하죠. 버그가 재현되지 않으니까요. "제가 테스트할 때는 됐었는데요"라는 말이 일상이 됩니다.

디버깅 불가능 (Debuggability collapse). 고정된 파이프라인이 고장 나면, 정확히 어떤 단계에서 실패했는지 알 수 있습니다. 에이전트가 고장 나면, 4단계에서 내린 결정 때문에 12단계에서 실패한 것인데, 그 4단계의 결정을 당신은 제어할 수도, 쉽게 재현할 수도 없습니다. 코드를 디버깅하는 것이 아니라, 어떤 '선택'에 대한 디지털 포렌식을 하는 것에 가깝습니다. 솔직히 말씀드리면, 이런 경우엔 디버깅이 아니라 '디지털 포렌식'에 가깝습니다. 특정 오류 시점을 재현하기 위해 여러 가정을 세우고, 각 스텝의 중간 아웃풋을 일일이 확인하며 경로를 추적하는 일은 정말 고된 작업이죠.

실패 표면 확대 (Multiplied failure surface). 모든 자율적인 결정은 잘못될 수 있는 또 다른 지점이며, 이러한 실패는 여러 단계에 걸쳐 복합적으로 작용합니다. 다섯 개의 고정된 단계로 이루어진 파이프라인은 다섯 가지를 확인하면 됩니다. 하지만 다섯 가지 결정을 내리는 에이전트는 다섯 가지 결정 각각이 잘못될 수 있고, 그 조합과 순서가 실행할 때마다 바뀝니다.

비용 및 지연 시간 (Cost and latency). 추론 루프는 고정된 순서보다 훨씬 더 많은 모델 호출을 발생시킵니다. 모델은 생각하고, 다시 생각하고, 반성하고, 다시 루프를 돌기로 결정합니다. 당신이 이미 알고 있는 경로에 대해 모델이 숙고하도록 토큰당 비용을 지불하고 있는 셈입니다.

테스트 불가능 (You can't test it). 회귀 테스트는 고정된 경로 세트에 대해 테스트해야 합니다. 에이전트는 정의상 그런 것이 없습니다. 따라서 프로덕션에서 자율적인 결정을 내리는 시스템은 동시에 신뢰할 수 있는 테스트를 작성할 수 없는 시스템이 됩니다. 정말 대단하죠.

이 모든 것을 합산하면 결론은 잔인합니다. 비결정론성, 디버깅 악몽, 토큰 비용 등 이 모든 것을 지불한 대가는 바로 모델에게 당신이 이미 답을 알고 있던 것을 결정하게 한 것입니다.

당신이 정말 원했던 것은 파이프라인입니다

여기서 말하는 '지루하지만 승리하는 것'은 바로 파이프라인입니다.

파이프라인은 고정된 단계의 순서이며, 모델이 진정으로 가치를 더하는 특정 지점에서만 LLM을 호출하고, 당신이 소유하는 결정론적인 제어 흐름을 가집니다. 재현 가능하죠. 같은 입력, 같은 경로. 테스트 가능합니다. 고정된 경로는 실제 회귀 테스트를 의미합니다. 저렴합니다. 자명한 것을 다시 결정하기 위해 토큰을 태우는 추론 루프가 없습니다. 디버깅 가능합니다. 3단계가 실패하면 3단계를 살펴보면 됩니다.

그리고 사람들이 놓치는 점이 있습니다. LLM은 여전히 모든 똑똑한 부분을 담당합니다. 여전히 추출하고, 분류하고, 콘텐츠에 대해 추론하며, 언어를 생성합니다. 아무것도 바보같이 만든 것이 아닙니다. 단지 작업의 구조를 즉흥적으로 만들도록 허용하는 것을 멈췄을 뿐입니다. 왜냐하면 구조는 지능이 필요했던 부분이 아니었으니까요. 구조는 당신이 이미 이해하고 있던 부분이었습니다.

실제로 프로덕션에서 작동하는 '에이전트 같은(agentic)' 시스템들을 자세히 살펴보면, 대개 이런 모습을 발견할 수 있습니다. 대부분 고정된 파이프라인에 한두 개의 신중하게 제약된 결정 지점이 있을 뿐, 자유롭게 돌아다니는 추론 루프는 찾아보기 어렵죠. 좋은 시스템들은 자율성을 가능한 한 최소한의 표면으로 제한했습니다. 그들은 가끔, 의도적으로, 모델에게 하나의 제한된 선택을 요청하는 파이프라인일 뿐, 전체 쇼를 운영하도록 믿고 맡겨진 에이전트가 아닙니다.

진짜 에이전트가 필요할 때

이제 저 스스로의 주장에 반박해보겠습니다. 왜냐하면 "에이전트는 항상 나쁘다"는 말은 "모든 것이 에이전트여야 한다"는 말만큼이나 어리석을 것이기 때문입니다. 진짜 에이전시는 특정 상황에서 그 비용을 진정으로 정당화합니다.

단계를 미리 전혀 알 수 없을 때. 개방형 연구, 탐색, 알려지지 않은 문제 디버깅과 같이 경로가 발견되는 과정에서 진정으로 나타나는 작업들입니다. 그 플로우차트 자체를 발견해야 하므로 미리 그릴 수 없습니다.
각 단계가 이전 단계의 발견에 의존할 때. 진정한 멀티홉 작업입니다. "무엇인가를 찾고, 그 찾은 것이 무엇인지에 따라 다음 할 일을 결정하는" 식이죠. 1단계가 실행되기 전까지 2단계를 진정으로 알 수 없다면, 런타임에 결정할 수 있는 무언가가 필요합니다.
분기가 무한하고 실제적일 때. "세 가지 케이스를 가진 if 문"과 같은 스위치 구문이 있는 파이프라인이 아니라, 미리 열거할 수 없을 정도로 가능성의 공간이 너무 큰 경우입니다.

만약 당신의 작업이 위에 설명된 것 중 하나에 해당한다면, 에이전트를 만드세요. 그만한 가치가 있습니다. 그리고 그럴 때조차도, 핵심은 자율성을 최소화하는 것입니다. 할 수 있는 모든 것을 하드코딩하고, 모델의 런타임 결정은 진정으로 필요한 한 곳에만 남겨두세요. 자율성은 비용입니다. 그 비용이 가치를 가져다주는 곳에만 사용해야 합니다.

요점은 결코 "에이전트가 나쁘다"가 아니었습니다. 에이전시(Autonomy)는 정당화해야 하는 비용이라는 것입니다. 그리고 '에이전트'라고 자칭하는 대부분의 시스템들은 그 비용을 정당화하지 않았을 뿐입니다. 그저 그 단어가 좋았을 따름이죠.

왜 모두가 어쨌든 에이전트를 만들까?

파이프라인이 더 저렴하고, 안전하며, 디버깅하기 쉽다면, 왜 모두가 에이전트를 만들까요? 여기 불편한 진실이 있습니다. 에이전트는 작업을 위한 것이 아니라, 만드는 사람을 위해 만들어집니다.

에이전트는 데모에서 훨씬 더 멋지게 보입니다. "문제를 자율적으로 추론하는 모습을 보세요"라고 하면 사람들의 시선이 집중되지만, "모델을 세 번 호출하는 함수를 작성했습니다"는 그렇지 않죠. 에이전트는 실제 AI 같고, 미래 같고, 이 분야에 뛰어든 이유가 바로 이것인 것 같은 느낌을 줍니다. 그리고 '에이전트(agentic)'는 이력서에 쓸 한 단어이자 투자 유치용 단어입니다. 스탠드업 미팅이나 투자 피치덱에서 '결정론적 파이프라인'으로는 결코 얻을 수 없는 정교함을 암시하죠.

이런 이유들 중 그 어떤 것도 당신의 작업에 에이전트가 필요한지 여부와는 아무런 관련이 없습니다. 이는 그 아키텍처가 당신에게 어떻게 느껴지고, 어떻게 보이느냐에 대한 것입니다. 그리고 이것이 바로 '지루한 파이프라인'이 시니어 개발자의 선택이 되는 이유입니다. 더 화려한 것이 더 많은 박수를 받을지라도, 실제로 작동하는 덜 인상적인 것을 선택하는 것이야말로 맹목적인 과대광고가 적극적으로 외면하는 규율입니다. 아무도 당신의 while 루프를 스크린샷 찍지 않습니다. 당신의 while 루프는 그저 조용히 시스템을 유지시켜 줄 뿐이죠.

핵심 정리

'에이전트'는 파이프라인으로는 도저히 할 수 없다는 것이 입증되었을 때 도달해야 할 단계여야 합니다. 단지 그 단어가 '고급스러워 보인다고' 해서 기본값으로 선택해서는 안 됩니다.

지루하게 시작하세요. 플로우차트를 그리세요. 만약 그릴 수 있다면, 파이프라인을 만드세요. 고정된 단계, LLM 호출은 그 가치를 증명하는 곳에만, 그리고 당신이 소유하는 제어 흐름으로 말입니다. 진정한 에이전시는 고정된 경로가 명백히 실패하는 특정 지점에만, 그리고 더 이상 필요 없는 곳에는 추가하지 마세요. 프로덕션에 배포되어 안정적으로 유지되는 시스템은 거의 항상 데모에서 이기는 시스템보다 지루합니다.

지금 '에이전트'라고 불리는 대부분은 트렌치코트를 입은 파이프라인일 뿐입니다. 그리고 서두에서 말했듯이 다시 한번 말씀드립니다. 이건 모욕이 아닙니다. 안도감입니다. 왜냐하면 파이프라인이야말로 실제로 운영하고, 테스트하고, 비용을 감당하고, 디버깅할 수 있는 것이니까요. "데모에서 인상적"인 것이 목표가 아니었습니다. "수요일에도 여전히 작동하는 것"이 목표였죠.

그 코트를 벗으세요. 그 밑에 있는 것이 훨씬 마음에 들 겁니다.

두 가지 질문입니다. 댓글에 모두 남겨주세요. 첫 번째, 재미있는 질문입니다. 당신이 '에이전트'라고 만들었다가 알고 보니 위장한 파이프라인이었던 것은 무엇인가요? 그리고 진짜 논쟁거리인 두 번째 질문입니다. 당신에게 있어서 그 경계선은 어디인가요? 진정한 에이전트가 그 복잡성을 정당화하는 가장 작은 작업은 무엇이라고 생각하시나요? 아마 우리 모두 그 선을 다른 곳에 그릴 것이고, 그것이 바로 이 논쟁이 가치 있는 이유일 겁니다.

원문: https://dev.to/james_anderson_h/most-ai-agents-are-just-if-statements-in-a-trench-coat-3960 수집일: 2026-09-10 01:44:01