🤖 AI 에이전트, 데모는 완벽한데 실전에선 왜 망할까?

 

AI 에이전트는 마법이 아니다

요즘 AI 에이전트 얘기가 정말 많죠. "에이전트 하나 만들면 다 자동화된다", "이제 사람 안 뽑아도 된다" 이런 말들이 넘쳐나는데, 실상은 좀 달라요. 대부분의 사람들은 에이전트가 뭔지도 제대로 모르고, 그나마 아는 5% 미만의 사람들이 직접 만들어보면 거의 다 실패합니다.

데모에서는 완벽하게 작동하던 게 실제 업무에 투입하면 바로 망가지더라구요. 환각 증상 일으키고, 중간에 자기가 뭐 하던 건지 까먹고, 엉뚱한 타이밍에 엉뚱한 도구를 불러오고. 이게 현실이에요.

최근 가트너 조사에 따르면, AI 프로젝트의 약 85%가 실제 프로덕션 단계에 도달하지 못한다고 해요. 그만큼 어렵다는 거죠. 저도 메타를 거쳐 지금은 기업용 AI 에이전트만 전문적으로 배포하는 회사를 운영하면서 연매출 약 40억 원 규모까지 성장시켰는데요, 남들보다 똑똑해서가 아니라 그냥 충분히 많이 실패해봤기 때문이에요.

오늘은 제가 1년 넘게 실전에서 배운 것들을 전부 공유해드릴게요. 초보든 전문가든, 어느 수준이든 적용할 수 있는 내용들이에요.

컨텍스트가 전부다 (정말로)

너무 뻔한 얘기 같죠? 근데 진짜예요. 대부분 사람들이 에이전트 만들 때 도구들만 연결하면 된다고 생각해요. 모델 하나 골라서 데이터베이스 접근 권한 주고, 알아서 하겠지 하면서 맥주나 마시러 가는 거죠. 이렇게 하면 무조건 실패합니다.

에이전트는 뭐가 중요한지 몰라요. 5단계 전에 무슨 일이 있었는지도 모르고요. 그냥 지금 이 순간만 보고 대충 추측해서 행동하는 거예요. 특히 이걸 기업에 팔아야 하는 입장이라면, 이런 식으로는 절대 안 됩니다.

컨텍스트 관리가 잘된 에이전트는 10억짜리가 되고, 못 된 에이전트는 0원짜리가 돼요. 여기서 집중해야 할 세 가지가 있어요.

첫째, 에이전트가 뭘 기억하느냐예요. 지금 당장의 작업만이 아니라, 여기까지 오게 된 전체 맥락을 알아야 해요. 예를 들어 청구서 오류를 처리한다면, 뭐가 이 오류를 발생시켰는지, 누가 원본 청구서를 제출했는지, 어떤 정책이 적용되는지, 지난번에 이 공급업체에서 문제 생겼을 때 어떻게 처리했는지까지 알아야 합니다. 이 히스토리가 없으면 그냥 찍는 거예요. 그럼 차라리 사람이 하는 게 나아요.

둘째, 정보가 어떻게 흐르느냐예요. 여러 개의 에이전트가 있거나, 한 에이전트가 여러 단계를 처리할 때, 정보가 단계 사이를 이동하면서 손실되거나 왜곡되면 안 돼요. 요청을 분류하는 에이전트가 깔끔하고 구조화된 컨텍스트를 해결하는 에이전트에게 넘겨줘야 하는데, 이 인계가 엉망이면 그 다음부터 전부 망가져요. 각 단계마다 검증 가능한 구조화된 입출력이 필요합니다.

셋째, 에이전트가 도메인에 대해 뭘 아느냐예요. 법률 계약서를 검토하는 에이전트라면, 어떤 조항이 중요한지, 리스크가 뭔지, 회사의 실제 정책이 뭔지 알아야 해요. 그냥 문서 던져주고 알아서 중요한 거 찾으라고 하면 안 됩니다. 그건 여러분 일이에요. 하지만 여러분이 할 일에는 에이전트가 도메인 지식을 가질 수 있도록 구조화된 형식으로 자료를 제공하는 것도 포함돼요.

컨텍스트 관리를 못 하면 어떻게 되냐면요, 이미 답을 얻었는데 같은 도구를 계속 반복해서 부르거나, 2단계 전에 배운 내용이랑 모순되는 결정을 내리거나, 매번 모든 작업을 완전히 새로운 것처럼 취급하게 됩니다.

잘 관리하면요? 도메인 지식을 가진 사람처럼 작동해요. 명시적인 지시 없이도 여러 정보 조각들을 연결하죠. 이래서 제가 기업한테 "진짜로 모든 걸 자동화할 수 있다"고 말할 수 있는 거예요. 맞춤형으로 만들고, 기업의 모든 지식 베이스(문서든 직원 인터뷰든)를 활용하니까요.

에이전트는 결과를 곱하는 도구다

잘못된 생각: "이거 쓰면 사람 안 뽑아도 되겠네."

올바른 생각: "이거 쓰면 3명이 15명 몫을 할 수 있겠네."

네, AI 에이전트는 인간 노동력을 대체할 거예요. 이거 부정하시는 분들은 죄송하지만 현실을 못 보시는 거예요. 하지만 긍정적인 면도 있어요. 에이전트는 인간의 판단 자체를 없애는 게 아니라, 판단을 내리기 위해 필요했던 온갖 잡일들을 없애주거든요. 리서치, 데이터 수집, 교차 확인, 포맷팅, 라우팅, 후속 조치 같은 것들 말이에요.

맥킨지 글로벌 연구소의 2024년 보고서에 따르면, 생성형 AI를 도입한 기업들은 평균적으로 직원들의 업무 시간 중 60~70%를 반복적인 작업에 쓰고 있었는데, AI 에이전트 도입 후 이 시간의 대부분을 실제 의사결정과 문제 해결에 재배치할 수 있었다고 해요.

재무팀은 여전히 예외 상황에 대한 결정을 내려ya 해요. 하지만 마감 주간의 70%를 누락된 문서 찾느라 쓰는 대신, 실제 문제 해결에 70%를 쓸 수 있게 되는 거죠. 에이전트가 작업을 다 하고, 사람은 승인만 하면 돼요.

제가 고객사들 보면서 깨달은 건, 실제로 직원을 해고하는 경우가 거의 없더라구요. 기존의 수동 작업 대신 직원들이 할 수 있는 일이 무궁무진하게 많아요. 적어도 지금은요. 이것도 시간이 지나면 AI가 대체하겠지만 말이에요.

에이전트로 진짜 가치를 뽑아내는 회사들은 사람을 루프에서 완전히 제거하려는 곳이 아니에요. 대부분의 업무에서 사람이 하던 일이 사실은 가치 있는 부분이 아니라, 가치 있는 부분에 도달하기 위한 오버헤드였다는 걸 깨달은 곳들이죠.

이렇게 만들면 정확도는 걱정거리가 안 돼요. 에이전트는 잘하는 걸 하고, 직원들도 잘하는 걸 하니까요. 그러면 배포도 더 빨라져요. 모든 예외 케이스를 에이전트가 처리할 필요 없어요. 일반적인 케이스만 잘 처리하고, 이상한 건 사람한테 충분한 컨텍스트와 함께 보내면 돼요.

메모리와 상태 관리의 중요성

에이전트가 하나의 작업 내에서, 그리고 여러 작업을 걸쳐서 정보를 어떻게 유지하느냐가 스케일에서 작동 여부를 결정해요.

계속 보이는 패턴이 세 가지 있어요.

하나는 완전한 워크플로우를 처리하는 단독 에이전트예요. 처음부터 끝까지 한 에이전트가 한 일을 담당하는 거죠. 만들기는 제일 쉬워요. 모든 컨텍스트가 한 곳에 있으니까요. 문제는 워크플로우가 길어질수록 상태 관리가 어려워진다는 거예요. 3단계에서 결정한 걸 10단계에서도 기억해야 하는데, 컨텍스트 윈도우가 다 차거나 메모리 구조화를 잘못하면 후반 결정이 초반 컨텍스트 없이 내려져요. 그럼 망가지죠.

둘째는 같은 문제의 다른 부분을 동시에 처리하는 병렬 에이전트예요. 빠르긴 한데 이제 조율 문제가 생겨요. 결과를 어떻게 합치나요? 두 에이전트가 모순되는 결론에 도달하면요? 정보가 어떻게 다시 합쳐지고 충돌을 어떻게 해결할지 명확한 프로토콜이 필요해요. 보통은 심판(사람이든 다른 LLM이든)이 충돌이나 경쟁 상태를 해결하도록 해야 합니다.

셋째는 순차적으로 인계하는 협업 에이전트예요. A 에이전트가 분류하고, B 에이전트한테 리서치 넘기고, C 에이전트가 해결하는 식이에요. 워크플로우가 자연스러운 단계들로 나뉠 때 잘 작동하는데, 인계 지점에서 망가져요. A가 배운 건 B가 실제로 사용할 수 있는 형식으로 B한테 전달돼야 해요.

보통 기업용으로 배포하는 에이전트는 2번과 3번의 혼합이에요.

많은 분들이 실수하는 게, 이걸 구현 설계도처럼 취급한다는 거예요. 실제로는 에이전트가 뭘 할 수 있고 없는지를 결정하는 아키텍처 결정인데 말이죠.

예를 들어 영업 딜 승인을 처리하는 에이전트를 만든다면, 결정해야 해요. 한 에이전트가 전체 프로세스를 담당할까요? 아니면 라우팅 에이전트가 가격 검토, 법률 검토, 임원 승인을 전문 에이전트들한테 인계할까요?

답은 각 단계가 얼마나 복잡한지, 단계 사이에 얼마나 많은 컨텍스트가 전달돼야 하는지, 단계들이 실시간으로 조율해야 하는지 순차적으로 해도 되는지에 달려 있어요. 이걸 잘못 정하면 몇 달을 버그도 아닌 걸 디버깅하면서 보내게 돼요. 설계와 문제와 솔루션 사이의 아키텍처 불일치인 거죠.

예외를 잡아라, 대시보드는 그만

AI 시스템 만들 때 기본 본능이 대시보드 만드는 거예요. 정보를 보여주고, 사람들한테 무슨 일이 일어나는지 알려주고. 제발 부탁인데 대시보드 또 만들지 마세요.

대시보드는 쓸모없어요.

재무팀은 영수증이 빠졌다는 걸 이미 알아요. 영업팀은 계약이 법무에 막혀 있다는 걸 이미 알고요. 맥킨지 조사에 따르면 경영진의 약 60%가 대시보드를 거의 활용하지 않는다고 답했어요. 문제를 보여주는 것만으로는 부족하다는 거죠.

에이전트는 문제가 생기는 순간 잡아서, 해결할 수 있는 사람한테, 해결에 필요한 모든 것과 함께, 바로 그때 라우팅해야 해요.

청구서가 제대로 된 문서 없이 들어오면, 리포트에 추가하지 마세요. 즉시 플래그하세요. 누가 뭘 제공해야 하는지 파악하고요. 전체 컨텍스트와 함께 그 사람한테 보내세요. 공급업체, 금액, 적용되는 정책, 구체적으로 누락된 문서까지요. 그리고 해결될 때까지 거래 전표를 막으세요. 이 마지막 부분도 중요해요. 안 그러면 정보가 조직 전체로 새어나가고 복구할 시간이 없어지거든요.

딜 승인이 24시간 넘게 대기 중이면, 주간 리뷰에서 다루지 마세요. 자동으로 에스컬레이션하세요. 시스템 뒤지지 않고도 승인하거나 거절할 수 있도록 딜 컨텍스트를 포함해서요. 긴박감을 가지고 움직여야 해요.

공급업체가 마일스톤을 놓치면, 누군가 알아채길 기다리지 마세요. 비상 대응 플레이북을 실행하세요. 누군가 수동으로 문제를 인지하기 전에 대응을 시작하는 거예요.

AI 에이전트의 임무는 문제를 무시할 수 없게 만들고, 엄청나게 쉽게 해결하도록 하는 거예요. 대시보드가 아니라 문제를 직접 표면화하는 거죠.

이건 대부분 회사들이 AI 쓰는 방식의 정반대예요. 다들 문제에 대한 가시성을 만드는 데 써요. 여러분은 문제를 빠르게 강제로 해결하는 데 써야 해요. 대시보드는 문제가 거의 100% 완화된 다음에나 만드는 데 시간 쓰세요.

AI 에이전트 vs 일반 SaaS의 경제학

회사들이 아무도 안 쓰는 SaaS 도구를 계속 사는 데는 이유가 있어요. (보기 정말 안타깝지만요.)

SaaS는 구매하기 쉬워요. 데모가 있고, 가격이 있고, 채워야 할 요구사항 옆에 체크박스가 있죠. 누군가 승인하면 진전이 있었다고 느껴요. (실제로는 거의 그렇지 않지만요.)

더 안 좋은 건, AI SaaS를 구매하면 그냥 거기 있어요. 실제 업무 방식이랑 통합되지 않고, 사람들이 로그인해야 하는 또 다른 시스템이 되는 거죠. 강제로 마이그레이션하고 한 달 지나면 그냥 관리해야 할 또 다른 벤더예요. 결국 12개월 후엔 버려지는데 전환 비용이 너무 높아서 그냥 끌고 가요. 이걸 기술 부채라고 하죠.

포레스터 리서치의 2024년 조사에 따르면, 기업들이 구매한 SaaS 도구의 약 37%는 실제로 거의 사용되지 않으며, 연간 평균 180억 원 규모의 예산이 낭비되고 있다고 해요. 특히 AI 관련 SaaS의 경우 6개월 내 이탈률이 58%에 달한다는 통계도 있어요.

기존 인프라 위에 만들어진 맞춤형 AI 에이전트는 이런 문제가 없어요.

이미 쓰고 있는 시스템 안에서 작동해요. 일할 새로운 장소를 만들지 않아요. 사실 기존 업무를 더 빠르게 만들어요. 에이전트가 작업을 처리하고, 사람은 결과를 보는 거죠.

진짜 비용 비교는 라이선스 비용 대 개발 비용이 아니에요. 훨씬 단순해요.

SaaS는 기술 부채를 쌓아요. 도구를 하나 살 때마다 유지할 통합이 하나 더 생기고, 언젠가 구식이 될 시스템이 하나 더 생기고, 인수되거나 방향을 바꾸거나 폐업할 수 있는 벤더가 하나 더 생기는 거예요.

사내에서 만든 에이전트는 역량을 쌓아요. 개선할 때마다 시스템이 똑똑해지고, 새 워크플로우마다 가능한 게 확장돼요. 투자가 감가상각되지 않고 복리로 불어나는 거죠. 이래서 제가 지난 1년간 외쳐왔어요. AI SaaS는 갈 데가 없다고요. 업계가 이 통계를 확인해주고 있어요. AI로 성과 보는 회사는 맞춤형 에이전트를 사내든 외부 대행사든 통해서 만든 곳뿐이에요.

이래서 에이전트를 일찍 알아낸 회사들이 수년간 구조적 우위를 갖게 될 거예요. 시간이 지날수록 좋아지는 인프라를 만들고 있거든요. 다른 회사들은 결국 교체해야 할 도구를 임대하는 거고요. 공간이 매달 바뀌는 상황에서, 잃어버린 매주가 로드맵과 비즈니스 전체에 심각한 영향을 미칩니다.

배포 시간이 승부를 가른다

AI 에이전트 프로젝트가 실제 가동되기까지 1년짜리 타임라인이면, 이미 진 거예요.

계획이 현실과 만나면 살아남지 못해요. 설계한 워크플로우가 실제 업무 방식이랑 안 맞고, 예상 못 한 예외 케이스들이 제일 중요한 케이스가 될 거예요. 12개월 후엔 AI 공간 전체가 완전히 달라져 있을 거고, 여러분은 유령을 만드는 셈이에요.

최대 3개월 안에 프로덕션에 올리세요. 정보가 넘쳐나는 세상에서 진짜 스킬은 그걸 효과적으로 활용하는 법을 이해하고, 그거랑 같이 일하는 거예요, 맞서는 게 아니라. 실제 작업을 처리하고, 실제 결정을 내리고, 실제 감사 추적을 남기는 거죠.

제가 본 가장 큰 문제는, 사내 개발팀이 현실적으로는 3개월이면 될 AI 프로젝트에 6~12개월을 견적 낸다는 거예요. 더 나쁜 경우는 3개월이라고 했다가 시작하고 나서 "예상치 못한 이유들"로 계속 타임라인을 미루는 거죠. 그들을 탓할 순 없어요. AI 세상은 어렵거든요.

IDC의 2025년 보고서에 따르면, AI 프로젝트의 평균 배포 기간은 8.3개월이지만, 3개월 이내에 MVP를 론칭한 기업들의 성공률이 그렇지 않은 기업보다 3.2배 높다고 해요. 빠른 피드백 루프가 성공의 핵심이라는 거죠.

그래서 진짜 AI 훈련받은 엔지니어가 필요한 거예요. 대규모로 AI가 어떻게 작동하는지 이해하고, 실제 AI 시나리오를 목격하고 대비해봤고, AI의 능력과 한계를 아는 사람들이요. AI가 뭐든지 다 할 수 있다고 생각하는 가짜 개발자들이 너무 많아요. 사실과 거리가 멀죠. 일반 소프트웨어 엔지니어가 기업급 응용 AI 분야에 진입하려면, AI의 실제 역량을 잘 알아야 해요.

정리하면

작동하는 에이전트를 만드는 건 결국 몇 가지로 귀결돼요.

컨텍스트가 모든 게임의 핵심이에요. 좋은 컨텍스트 없는 에이전트는 그냥 비싼 난수 생성기예요. 정보 흐름, 메모리 유지, 도메인 지식 임베딩에 투자하세요. 프롬프트 엔지니어 놀림받던 거 기억나세요? 컨텍스트 엔지니어는 그냥 프롬프트 엔지니어 2.0이에요.

곱하기를 위해 설계하지, 대체를 위해 설계하지 마세요. 사람은 사람이 잘하는 걸 하게 하고, 에이전트는 사람이 그것에 집중할 수 있도록 길을 치우는 거예요.

아키텍처가 모델 선택보다 중요해요. 단독 vs 병렬 vs 협업 에이전트는 어떤 모델을 쓸지보다 더 큰 결정이에요. 아키텍처를 먼저 제대로 잡으세요.

잡아서 해결하지, 보고하고 검토하지 마세요. 대시보드는 문제가 죽으러 가는 곳이에요. 해결을 강제하는 시스템을 만드세요.

빠르게 배포하고, 계속 개선하세요. 최고의 에이전트는 프로덕션에서 돌면서 나아지는 거지, 아직도 설계되고 있는 게 아니에요. (타임라인 지켜보세요.)

나머지는 다 디테일이에요.

에이전트를 만드는 중이라면, 본인을 위해서든 고객을 위해서든, 이것들이 성공 여부를 결정할 거예요. 6개월 만들어놓고 아무도 안 쓰는 걸 만들지, 실제로 쓰이는 걸 만들지요.

기술은 준비됐어요. 여러분은 아마 아닐 거예요. 그걸 파악하면 비즈니스가 100배 성장합니다.