현실 IT 개발자의 고백: 'AI 에이전트'는 코트 입은 If문일 뿐입니다

작년, 저는 직접 에이전트(Agent)를 만들면서 상당한 자부심을 느꼈습니다.

그 에이전트에는 명확한 플래너가 있었죠. 필요한 도구들도 갖추고 있었고요. 다음에 무엇을 할지 결정하고, 자신의 출력에 대해 스스로 반성하며, 여러 단계를 엮어 실제 작업을 수행하는 추론 루프까지 탑재했습니다. 데모 시연에서는 정말 감탄사가 절로 나올 정도였죠. 다들 "오~" 하며 놀라움을 금치 못했습니다.

하지만 프로덕션에 배포되는 순간, 모든 것이 바뀌었습니다. 느리고, 비용이 많이 들고, 도저히 재현할 수 없는 방식으로 오류를 뿜어냈습니다. 화요일에 같은 입력을 넣었는데, 수요일에는 전혀 다른 동작을 하는 식이었죠. 시스템이 고장 났을 때, 원인은 제가 제어할 수도, 들여다볼 수도 없는 세 가지의 "자율적인 결정"에 있었습니다.

그래서 저는 겉보기엔 전혀 멋지지 않은 방법을 택했습니다. 지루하고 선형적인 파이프라인으로 시스템을 다시 작성한 거죠. 고정된 단계, 추론 루프는 제거했습니다. 결과는 어땠을까요? 속도, 비용, 테스트 용이성, 디버깅 용이성 등 모든 면에서 훨씬 더 나아졌습니다.

그러고 나서 예전 "에이전트"의 로그를 들여다보니 약간 씁쓸했습니다. 그 에이전트는 매번 똑같은 세 단계를 반복하고 있었더군요. 추출하고, 변환하고, 응답하는 과정이 모든 실행에서 동일했습니다. 한 번도 귀하디귀한 자율성을 사용해서 다른 일을 한 적이 없었습니다. 결국 저는 평범한 for 루프를 만들고, 거기에 시스템 프롬프트를 부여한 다음, 거창하게 "에이전트"라고 부르고 있었던 겁니다.

저만 이런 경험을 한 건 아닐 겁니다. 2026년 현재 '에이전트'라고 불리는 것들 대부분은 사실 코트 입은 파이프라인이라고 생각합니다. 그리고 저는 이것이 결코 모욕적인 발언이 아니라는 점을 강조하고 싶습니다. 오히려 안도해야 할 사실이죠.

"에이전트"의 진짜 정의 (아무도 제대로 설명하지 않는 그것)

'에이전트'는 어느새 모든 것을 의미하면서 결국 아무것도 의미하지 않는 단어가 되어버렸습니다. 그래서 이 논의의 핵심을 짚는, 단 하나의 중요한 차이점을 명확히 짚고 넘어가겠습니다.

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

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

이게 전부입니다. 그리고 많은 사람이 놓치는 부분이 있습니다. 고정된 단계 안에서 LLM이 똑똑한 일을 하는 것이 '에이전시(Agency)'는 아닙니다. 필드를 추출하고, 티켓을 분류하고, 요약을 생성하는 것 – 그저 LLM을 활용하는 것일 뿐입니다. 그건 똑똑한 함수 호출이죠. 에이전시는 모델에게 운전대를 넘겨주고, 스스로 경로를 선택하게 할 때를 의미합니다.

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

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

이 모든 것을 판가름할 수 있는 한 줄짜리 리트머스 시험이 있습니다.

만약 시스템이 실행되기 전에 그 플로우차트를 그릴 수 있다면, 당신은 에이전트가 아닌 파이프라인을 가지고 있는 겁니다.

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

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

이 "코스튬"이 비싼 이유

"좋아, 기술적으로는 파이프라인이라고 쳐. 하지만 잘 작동하는데 누가 신경 써?" 라고 말할 수도 있겠죠. 누가 신경 쓸까요? 그것을 운영하고, 비용을 지불하고, 새벽 2시에 디버깅해야 하는 모든 사람이 신경 씁니다. 파이프라인을 에이전트인 척하는 것은 실제 비용 청구서를 동반하며, 그 내역은 다음과 같습니다.

비결정성 (Nondeterminism). 모델이 경로를 선택할 때, 같은 입력이 실행마다 다른 경로를 따를 수 있습니다. 데모에서는 멋지지만, 프로덕션에서는 비참합니다. 버그가 재현되지 않기 때문이죠. "제가 테스트할 땐 잘 됐는데요"라는 말이 상시 상태가 됩니다. 제가 실무에서 이런 비결정적 문제를 맞닥뜨렸을 때의 고통은 이루 말할 수 없었습니다. 같은 인풋을 넣어도 매번 다른 결과가 나오니, 재현조차 안 되는 버그 앞에서 얼마나 많은 개발자가 좌절했을지 상상만 해도 아찔하죠.

디버깅 불가능성 (Debuggability collapse). 고정된 파이프라인이 고장 나면, 정확히 어떤 단계에서 실패했는지 알 수 있습니다. 에이전트가 고장 나면, 4단계에서 내린 결정 때문에 12단계에서 실패한 건데, 그 결정은 당신이 제어할 수 없고 쉽게 재현할 수도 없습니다. 더 이상 코드를 디버깅하는 것이 아니라, 에이전트의 "선택"에 대한 법의학적 조사를 하는 것과 같습니다. 어떤 분들은 '그래도 잘 돌아가면 그만이지'라고 할지 모르지만, 제가 새벽 2시에 긴급 장애를 처리하며 겪었던 트라우마는 그런 낙관론을 허락하지 않습니다. 에이전트가 무슨 생각으로, 어떤 흐름으로 문제가 발생했는지 파악하기 위해 로그를 파헤치던 경험은 정말이지 '코드 디버깅'이 아니라 '범죄 현장 분석'에 가까웠습니다.

증폭되는 실패 지점 (Multiplied failure surface). 모든 자율적인 결정은 잘못될 수 있는 또 다른 지점이며, 실패는 여러 단계에 걸쳐 복합적으로 발생합니다. 다섯 개의 고정된 단계로 이루어진 파이프라인은 다섯 가지를 확인할 수 있습니다. 반면 다섯 가지 결정을 내리는 에이전트는 각 결정이 잘못될 수 있는 경우의 수가 다섯 가지이며, 이들이 조합되어 매번 다른 순서로 실패할 수 있습니다.

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

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

이 모든 것을 종합하면 핵심은 잔인합니다. 당신은 비결정성, 디버깅 악몽, 토큰 비용 등 모든 것을 지불하고서, 모델이 당신이 이미 답을 알고 있는 것을 결정하게 한 것입니다.

사실 당신이 원했던 것은 파이프라인이었습니다

여기 지루하지만 결국 승리하는 것이 있습니다.

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

그리고 많은 사람이 놓치는 부분이 있습니다. LLM은 여전히 모든 똑똑한 부분을 수행합니다. 여전히 추출하고, 분류하고, 콘텐츠에 대해 추론하고, 언어를 생성합니다. 당신은 아무것도 어리석게 만들지 않았습니다. 단지 작업의 구조를 즉흥적으로 만들도록 내버려 두는 것을 멈췄을 뿐입니다. 왜냐하면 구조는 지능이 필요한 부분이 아니었기 때문입니다. 구조는 당신이 이미 이해하고 있던 부분이었죠.

프로덕션에서 실제로 작동하는 "에이전트적인" 시스템들을 면밀히 살펴보면, 보통 이런 특징을 발견할 수 있습니다. 대부분 고정된 파이프라인에 하나 또는 두 개의 신중하게 제약된 결정 지점이 있을 뿐, 자유롭게 돌아다니는 추론 루프는 아닙니다. 좋은 시스템들은 자율성을 가능한 한 가장 작은 표면으로 최소화했습니다. 이들은 가끔, 의도적으로, 모델에게 하나의 경계 있는 선택을 요청하는 파이프라인이지, 전체 쇼를 운영하도록 신뢰받은 에이전트가 아닙니다.

진짜 에이전트가 필요할 때

이제 제 주장에 반박해보겠습니다. 왜냐하면 "에이전트는 항상 나쁘다"는 주장은 "모든 것이 에이전트여야 한다"는 주장만큼이나 어리석을 테니까요. 진정한 에이전시는 특정 경우에만 그 비용을 진정으로 정당화할 수 있습니다.

단계들을 사전에 진정으로 알 수 없을 때. 개방형 연구, 탐색, 알 수 없는 문제 디버깅과 같이, 경로가 당신이 발견하는 것에서 진정으로 나타나는 작업들. 그 플로우차트를 그릴 수 없는 이유는 플로우차트 자체가 발견되고 있는 대상이기 때문입니다.
각 단계가 이전 단계의 발견에 의존할 때. 진정한 멀티-홉(multi-hop) 작업: "그것을 찾고, 그것이 무엇인지에 따라 다음 것을 알아낸다." 만약 1단계가 실행될 때까지 2단계가 진정으로 예측 불가능하다면, 런타임에 결정할 수 있는 무언가가 필요합니다.
분기가 무한하고 실제적일 때. 단순히 세 가지 케이스를 가진 if문(이것은 스위치문이 있는 파이프라인일 뿐)이 아니라, 사전에 열거하기에는 너무 큰 가능성의 공간을 가질 때입니다.

이 중 하나라도 당신의 작업에 해당한다면, 에이전트를 만드세요. 그럴 만한 가치가 있습니다. 그리고 그 경우에도, 자율성을 최소화하는 것이 중요합니다. 할 수 있는 모든 것을 하드코딩하고, 모델의 런타임 결정은 정말로 필요한 한 곳에만 남겨두세요. 자율성은 비용입니다. 가치가 있는 곳에만 사용해야 합니다.

요점은 결코 "에이전트가 나쁘다"가 아닙니다. 에이전시는 당신이 정당화해야 하는 비용이며, 스스로를 에이전트라고 칭하는 대부분의 시스템은 그 비용을 정당화하지 못했습니다. 그저 그 단어가 마음에 들었을 뿐이죠.

왜 모두가 에이전트를 만들까요?

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

에이전트는 데모에서 더 멋지게 보입니다. "문제를 자율적으로 추론하는 것을 보세요!"라고 하면 방 안의 사람들은 귀를 기울이지만, "모델을 세 번 호출하는 함수를 작성했습니다"는 그렇지 않습니다. 에이전트는 진정한 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-09 01:48:33