6부 30장. 데모가 아닌 제품으로서의 에이전트
에이전트 데모는 사람을 감탄하게 만든다. 한 번의 멋진 시연만으로도 회의실 분위기가 바뀐다. 검색도 하고, 요약도 하고, 메일까지 보내는 모습을 보면 금방이라도 팀의 모든 일이 자동화될 것처럼 보인다. 하지만 제품은 감탄으로 운영되지 않는다. 제품은 월요일 아침에도 돌아가야 하고, 사용자가 엉뚱한 요청을 던져도 버텨야 하며, 장애가 나면 누가 멈추고 누가 복구할지 분명해야 한다.
그래서 이 장의 핵심 문장은 간단하다. 에이전트가 제품이 되었다는 말은, 똑똑해졌다는 뜻이 아니라 반복해서 믿고 쓸 수 있게 되었다는 뜻이다.
데모는 "될 때의 모습"을 보여 준다. 제품은 "안 될 때도 어떻게 버티는지"를 증명한다. 그리고 그 차이는 모델 성능보다 시스템 운영 원칙, 조직의 준비 상태, 제품 기준의 명확함에서 더 크게 갈린다.12
데모와 제품은 무엇이 다른가
데모는 보통 행복한 경로만 지나간다. 입력은 미리 준비되어 있고, 도구는 잘 연결되어 있으며, 데이터도 정돈되어 있다. 발표자는 어떤 질문이 들어올지 대략 알고 있고, 시스템은 가장 보기 좋은 순간을 중심으로 설계된다. 그래서 데모는 종종 정확하다기보다 연출이 잘된 상태 에 가깝다.1
반면 제품은 전혀 다른 세상에서 산다. 사용자는 장황하게 말하고, 로그인은 만료되고, 외부 API는 느려지고, 데이터 형식은 어제와 다르게 들어온다. 심지어 문제는 모델이 아니라 네트워크, 권한, 큐 적체, 오래된 문서, 잘못된 승인 흐름에서 터지기도 한다. 실전에서는 "모델이 좋아 보인다"보다 "전체 시스템이 실제 환경을 견디는가"가 훨씬 중요하다.2
이 차이를 이해하지 못하면 팀은 늘 비슷한 실수를 한다. 프롬프트를 다듬고, 모델을 바꾸고, 데모를 더 멋지게 만드는 데는 열심이지만, 정작 출시 후 필요한 예산 상한, 장애 기준, 롤백 절차, 사람 승인 조건은 나중으로 미룬다. 그러면 첫 번째 사고가 곧 첫 번째 기획 문서가 된다. 운영 원칙을 사고 뒤에 배우는 셈이다.34
제품이 되려면 통과해야 하는 다섯 가지 질문
에이전트를 제품으로 볼 수 있는지 판단하려면, 기능 목록보다 먼저 다섯 가지 질문을 던져야 한다.
같은 요청을 반복해서 받아도 품질이 크게 흔들리지 않는가
실패했을 때 조용히 망가지지 않고 멈추거나 축소 동작으로 전환하는가
누가 소유하고, 누가 승인하고, 누가 끌 수 있는지가 분명한가
비용과 지연 시간이 대략이라도 예측 가능한가
사용자가 한 번 써 보고 끝나는 것이 아니라 다시 돌아올 이유가 있는가
첫째는 반복 가능성 이다. 데모는 한 번의 성공으로 충분하지만, 제품은 백 번의 평균으로 평가된다. 어떤 날은 잘 되고 어떤 날은 엉뚱하면, 그 시스템은 아직 제품이 아니다.
둘째는 실패 방식의 품질 이다. 좋은 제품은 늘 성공하는 제품이 아니라, 실패할 때도 위험하게 무너지지 않는 제품이다. 예를 들어 답을 못 찾으면 안전한 기본 응답으로 돌아가고, 도구 호출이 실패하면 재시도하거나 사람에게 넘기고, 예산을 넘기면 계속 달리지 않고 멈춘다. 이런 식의 품위 있는 실패가 있어야 한다.34
셋째는 책임 구조 다. 운영 중인 에이전트에는 반드시 주인이 있어야 한다. 누가 품질을 본다, 누가 권한 범위를 관리한다, 누가 장애 때 롤백한다, 누가 사용자 불만을 제품 개선으로 연결한다가 분명해야 한다. 이것이 흐리면 장애는 기술 문제가 아니라 조직 문제가 된다.5
넷째는 예측 가능성 이다. 제품은 "가끔 아주 잘 되는 시스템"이 아니라 "대략 어떤 결과가 나올지 짐작되는 시스템"이어야 한다. 비용, 속도, 성공률, 승인 대기 시간에 대한 대강의 범위를 설명할 수 있어야 한다. CFO에게는 숫자로, 운영팀에게는 한계치로, 사용자에게는 기대 가능한 경험으로 설명할 수 있어야 한다.46
다섯째는 반복 사용 가치 다. 멋진 시연은 박수를 받지만, 제품은 습관이 된다. 사용자가 이 에이전트를 다시 쓰는 이유가 분명해야 한다. 빨라서, 덜 귀찮아서, 실수를 줄여서, 사람에게 넘길 타이밍이 좋아서 같은 이유다. 단지 신기해서는 오래 못 간다.
운영 기준은 기능보다 먼저 정해야 한다
많은 팀이 "일단 붙여 보고 운영은 나중에 생각하자"고 말한다. 하지만 제품 단계에서는 순서가 반대다. 먼저 통제 경계를 정하고, 그 안에서 기능을 키워야 한다. 출시 전에 적어도 다음 항목은 문장으로 정리되어 있어야 한다.
어떤 행동이 자동 승인이고 어떤 행동이 사람 승인이어야 하는가
어떤 조건에서 실행을 중단하고 이전 버전으로 되돌리는가
요청당, 세션당, 기간당 예산 상한은 얼마인가
성공률, 지연 시간, 오류율의 최소 기준은 무엇인가
누가 온콜이고 누가 최종 롤백 권한자인가
이런 기준이 없으면 운영은 늘 감으로 흘러간다. "조금 이상한데 좀 더 보자"가 반복되고, 승격은 분위기로 결정되며, 롤백은 너무 늦어진다. 반대로 기준이 있으면 에이전트 운영은 훨씬 덜 감정적이 된다. 숫자가 흔들리면 멈추고, 기준을 넘으면 되돌리고, 승인 대기열이 쌓이면 범위를 줄인다. 제품은 용기가 아니라 절차로 지킨다.67
특히 에이전트는 일반 웹 서비스보다 원자적 버전 관리 가 중요하다. 모델만 바꾸는 것이 아니라 프롬프트, 도구 연결, 정책, 메모리 설정, 가드레일까지 한 묶음으로 관리해야 한다. 그래야 사고가 났을 때 "어느 한 조각만" 되돌리다가 더 이상한 상태로 빠지지 않는다.7
에이전트 제품팀은 무엇을 준비해야 하는가
프로덕션 전환은 기술팀만의 일이 아니다. 실제로는 데이터, 기술, 사람, 프로세스가 동시에 준비되어야 한다. 데이터가 막혀 있거나, 내부 시스템에 안정적인 API가 없거나, 운영 책임자가 없거나, 사람 승인 흐름이 비어 있으면 에이전트는 똑똑한 척만 하는 챗봇으로 돌아간다.5
이 네 가지를 조금 더 현실적으로 바꿔 보면 이렇다.
데이터 준비는 "에이전트가 필요한 정보를 제때, 구조적으로 읽을 수 있는가"의 문제다. PDF 속에 갇힌 정보, 수기로 옮겨야 하는 CSV, 하루 한 번만 갱신되는 재고 데이터는 제품 단계에서 큰 병목이 된다.
기술 준비는 "연결된 시스템이 버틸 수 있는가"의 문제다. 내부 CRM, 파일 저장소, 승인 시스템, 외부 SaaS가 안정적인 인터페이스를 제공하지 않으면 에이전트는 행동하는 대신 자꾸 멈춘다.
팀 준비는 "누가 이 시스템을 이해하고 돌보는가"의 문제다. 최소한 한 사람은 구현 수준에서 에이전트의 동작을 이해해야 하고, 한 사람은 서비스 관점에서 품질을 책임져야 하며, 한 사람은 운영과 보안의 경계를 관리해야 한다. 이 역할을 모두 한 사람이 떠안으면 초반에는 빠를 수 있어도 오래 못 간다.
프로세스 준비는 "사람과 에이전트가 어떻게 공존하는가"의 문제다. 어떤 단계에서 사람에게 넘길지, 예외는 누가 처리할지, 고객에게는 어떻게 설명할지, 장애 공지는 누가 할지까지 포함된다.
흥미로운 점은 많은 조직에서 가장 큰 장벽이 모델이 아니라 사람과 프로세스라는 사실이다. 조직이 준비되지 않으면 훌륭한 기술도 시범 사업을 벗어나지 못한다.5
출시 전략은 한 번에 여는 것이 아니라 좁게 열고 빨리 배우는 것이다
에이전트를 제품으로 출시할 때 가장 위험한 문장은 "생각보다 잘 되니까 전체 사용자에게 열자"다. 에이전트는 사용량이 늘 때 단순히 서버만 늘리면 끝나는 시스템이 아니다. 비용 구조가 달라지고, 승인 대기열이 생기고, 엣지 케이스가 폭증하며, 느린 외부 도구 하나가 전체 흐름을 흔들 수 있다.4
그래서 좋은 팀은 출시를 이벤트가 아니라 단계적 개방 과정 으로 본다. 먼저 저위험 작업, 저위험 사용자군, 작은 트래픽으로 시작한다. 그다음 품질 지표와 운영 지표를 보고 범위를 조금씩 넓힌다. 이때 중요한 것은 "단계가 많다"가 아니라 "각 단계의 통과 조건이 명확하다"는 점이다. 성공률, 지연 시간, 승인 대기 시간, 정책 위반률 같은 지표가 기준을 넘지 못하면 다음 단계로 가지 않는다.6
출시 후 첫 24시간에서 72시간은 특히 중요하다. 이 기간은 출시가 끝난 뒤가 아니라, 사실상 출시의 일부다. 집중 모니터링 담당자를 정하고, 비용 변화와 품질 저하를 계속 비교해야 한다. 많은 회귀 문제는 이 초반 관찰 구간에서 조용히 드러난다.7
그리고 반드시 자주 연습해야 한다. 롤백은 문서에 써 두는 것과 실제로 10분 안에 해내는 것이 다르다. 사고 재현, 승인 경로 점검, 장애 커뮤니케이션 리허설을 해 본 팀은 실제 사고에서도 덜 당황한다.46
관측 가능해야 운영할 수 있다
제품으로서의 에이전트는 "답변이 그럴듯하다"는 인상으로 평가되지 않는다. 추적 가능하고, 설명 가능하고, 숫자로 볼 수 있어야 한다. 모든 세션은 적어도 어떤 입력이 들어왔고, 어떤 도구를 불렀고, 어디서 실패했고, 얼마나 비용이 들었는지 재구성할 수 있어야 한다.38
여기서 중요한 것은 대시보드의 양이 아니라 관점의 분리다. 엔지니어는 실행 추적과 오류 원인을 보고 싶어 한다. 운영 책임자는 이상 징후와 온콜 알림을 보고 싶어 한다. 리더십은 요청당 비용, 처리량, 품질 추세를 궁금해한다. 사용자는 그런 것을 모르더라도, 결국 응답이 일정하고 믿을 만한지만 체감한다. 좋은 제품팀은 이 네 시선을 모두 만족시키는 관측 체계를 만든다.34
또 하나 잊지 말아야 할 것은 이상 징후는 장애보다 먼저 온다 는 점이다. 에러가 폭발하지 않아도 완료율이 95%에서 70%로 떨어지면 이미 큰 문제다. 응답이 오긴 오지만 쓸모가 없어지는 식의 열화는 에이전트에서 특히 흔하다. 그래서 에이전트 운영은 다운 여부만 보는 전통적 모니터링으로는 부족하다.3
제품은 제어 시스템이어야 한다
이 책의 앞 장들에서 우리는 프롬프트, 도구, 메모리, 실행 루프, 평가, 추적, 권한 관리를 각각 살펴보았다. 제품 단계에서는 이 조각들이 따로 잘 작동하는지보다, 서로를 제어하는 구조 로 묶여 있는지가 더 중요하다.
모델 제어가 없으면 제공자 버전 변경 한 번에 동작이 미묘하게 달라질 수 있다. 가드레일이 없으면 성능이 좋을수록 더 위험한 행동을 빨리 할 수 있다. 예산 통제가 없으면 잘못된 루프 하나가 밤새 비용을 태운다. 추적이 없으면 원인 분석이 감에 기대게 되고, 평가가 없으면 품질 저하를 사용자가 먼저 발견한다.8
이 말을 다르게 하면 이렇다. 제품은 기능의 집합이 아니라 제한의 집합 이다. 무엇을 할 수 있는지보다, 무엇을 못 하게 막았는지가 제품의 성숙도를 보여 준다. 훌륭한 에이전트 제품은 자유롭게 날아다니는 시스템이 아니라, 좁고 안전한 활주로 위에서 반복 이륙하는 시스템이다.
데모 냄새가 나는 안티패턴
에이전트가 아직 데모 단계에 머물러 있다는 신호도 꽤 분명하다.
모든 문제를 더 긴 시스템 프롬프트로 해결하려 한다
하나의 강력한 서비스 계정에 모든 권한을 몰아 준다
몇 개의 인상적인 사례만 보고 품질이 좋다고 판단한다
비용 상한과 재시도 한도 없이 자동 실행부터 건다
장애 때 누가 멈추는지, 어떤 기준으로 되돌리는지 정해져 있지 않다
운영 문서가 개발자의 머릿속에만 있고 온콜 교대가 불가능하다
이런 상태에서는 시스템이 멀쩡해 보여도 사실상 운에 기대고 있는 셈이다. 특히 "우리가 계속 보고 있으니 괜찮다"는 말은 통제 전략이 아니라 희망 사항에 가깝다. 제품은 Slack 채널의 긴장감으로 운영하면 안 된다.6
출시 전 마지막 기준
출시 직전이라면 화려한 기능 목록보다 아래 질문에 먼저 답하는 편이 낫다.
이 에이전트의 핵심 사용 사례는 한 문장으로 설명되는가
성공과 실패를 가르는 지표가 배포 전에 합의되었는가
승인 조건, 중단 조건, 롤백 조건이 숫자로 적혀 있는가
요청 경로 전체가 추적 가능하고, 사고를 재현할 수 있는가
예산 상한과 권한 범위가 작업 단위로 제한되어 있는가
첫 90일 동안 누가 매주 품질과 운영을 리뷰하는가
사용자가 실패를 만났을 때 대안 경로가 준비되어 있는가
이 질문에 선뜻 답하기 어렵다면, 기능이 부족한 것이 아니라 제품 기준이 아직 부족한 것 이다.
결국 제품은 신뢰의 반복이다
에이전트의 미래를 이야기할 때 사람들은 자꾸 더 자율적인 시스템을 상상한다. 물론 맞는 방향이다. 하지만 제품 관점에서 더 중요한 질문은 자율성의 크기가 아니다. 얼마나 신뢰 가능하게 반복되느냐 다.
사용자는 매번 에이전트의 내부 구조를 이해하고 싶어 하지 않는다. 그저 이 도구를 써도 되는지, 일을 맡겨도 되는지, 이상하면 금방 바로잡을 수 있는지만 알고 싶어 한다. 기업도 마찬가지다. 멋진 데모보다 중요한 것은 손실 없이 운영할 수 있는가, 팀이 감당할 수 있는가, 감사와 복구가 가능한가다.24
그래서 데모가 아닌 제품으로서의 에이전트는 이렇게 정의할 수 있다. 현실의 지저분함을 받아들이고, 그 안에서도 품질·비용·권한·책임을 통제할 수 있는 시스템.
그 기준을 넘어서면 에이전트는 더 이상 박수받는 기능이 아니다. 반복해서 쓰이는 서비스가 된다. 그리고 바로 그 지점에서, 에이전트는 실험이 아니라 소프트웨어 산업의 다음 운영 단위가 된다.
참고
1Building Compelling AI Agent Product Demos
2From demo to production: What agent-based AI must actually deliver
3Making AI Agents Production-Ready: A Complete Checklist
48 Production Readiness Checklists to Turn Prototypes Into Reliable AI Agents
5AI Agent Readiness Checklist: Is Your Team Prepared?
6AI Agent Production Deployment Checklist
7Deploying AI Agents to Production: A Complete Checklist
87 Things You Must Get Right Before Deploying an AI Agent to Production
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.