AI 에이전트는 오후 한나절이면 만들 수 있습니다. 하지만 프로덕션 (Production) 환경에서 AI 에이전트를 배포하고 관리하는 법 — 즉, 10개의 에이전트를 살아있게 하고, 정직하게 유지하며, 예산 범위 내에서 운영하는 법 — 을 배우는 것이 진짜 업무이며, 이는 튜토리얼이 준비시켜 주는 업무와는 전혀 다른 업무입니다.

제가 처음 출시한 에이전트는 제 노트북에서 아주 훌륭하게 작동했습니다. 고객 지원 편지함을 읽고, 답장을 초안하고, 화가 난 메일에 태그를 달고, 확신이 서지 않을 때는 저에게 알림을 보냈습니다. 목요일에 팀원들에게 데모를 보여주었을 때 모두가 박수를 쳤습니다. 하지만 그다음 주 수요일이 되자 에이전트는 조용히 응답을 멈췄고, 저는 왜 그런지 알아내기 위해 서버에 SSH로 접속하여 두 시간을 허비했습니다. 원인을 찾아냈을 때 그것은 당혹스러웠습니다. 프로세스가 3일 전에 종료되었는데 아무도 저에게 알려주지 않았던 것입니다.

"에이전트를 만들었다"와 "에이전트를 운영한다" 사이의 그 간극 — 바로 그곳에 대부분의 고통이 실제로 존재합니다. 만약 여러분이 'AI 에이전트 만드는 법' 튜토리얼을 따라오면서도 왜 프로덕션 환경은 여전히 칼부림 싸움처럼 느껴지는지 궁금했다면, 이 글이 도움이 될 것입니다.

튜토리얼이 보여주는 것 vs 실제로 30일째 운영 중인 것.

에이전트 하나를 만드는 것은 쉬운 20%에 불과합니다

프레임워크가 여러분을 어디까지 도와줄 수 있는지에 대해 솔직해져 봅시다. LangChain, OpenAI Agents SDK, CrewAI 및 기타 오픈 소스 AI 에이전트 프레임워크들은 구축 (Construction) 부분을 진정으로 쉽게 만들어 주었습니다. 모델을 연결하고, 몇 가지 도구 (Tools)를 주고, 루프 (Loop)를 추가하면 계획하고 행동할 수 있는 무언가가 만들어집니다. 주말 프로젝트만으로도 놀라울 정도로 유능해 보일 수 있습니다.

튜토리얼은 데모에서 끝납니다. 자율적인 AI 에이전트가 항공권을 예약하거나 PDF를 요약하는 모습을 보여준 뒤, 기사는 거기서 멈춥니다. 아무도 속편을 쓰지 않습니다 — 즉, 실제 사용자들과 실제 돈을 대상으로 12개의 에이전트를 운영하고 있으며, 여러분이 호출기 (Pager)를 들고 대기해야 하는 그 부분에 대해서는 말이죠.

그 속편에 실제로 담겨 있는 내용은 다음과 같습니다.

데모에서는 나타나지 않는 네 가지 문제.

1일 차가 아닌 30일 차에 나타나는 네 가지 문제

1. 그들이 무엇을 하고 있는지 볼 수 없습니다. 전통적인 웹 서비스는 500 에러, 스택 트레이스 (stack trace), 대시보드의 빨간 선처럼 요란하게 실패합니다. 하지만 에이전트는 조용하고 그럴듯하게 실패합니다. 잘못된 도구 (tool)를 자신 있게 호출합니다. 한 번만 반복해야 할 것을 네 번 반복합니다. 잘못된 일을 하면서도 "성공"합니다. 모든 단계—프롬프트 (prompt), 도구 호출 (tool call), 결과, 다음 결정—에 대한 기록이 없다면, 여러분은 느낌 (vibes)에 의존해 디버깅을 하게 됩니다. 단순한 텍스트 로그만으로는 부족합니다. 흥미로운 실패는 단일 행이 아니라 결정의 _순서 (sequence)_에서 발생하기 때문입니다.

2. 청구서는 살아있는 수류탄입니다. 모든 추론 (reasoning) 단계는 토큰 (tokens)을 소모하며, 토큰은 곧 달러입니다. 밤새 재시도 루프 (retry loop)에 빠진 에이전트 하나는 정말로 값비싼 실수가 됩니다. 저는 통제 불능 상태의 에이전트가 8시간 동안 태워버린 비용이, 그 에이전트가 지원하는 기능이 한 달 동안 벌어들인 수익보다 더 많은 것을 목격했습니다. 전통적인 인프라 비용은 예측 가능한 방식으로 트래픽에 따라 확장됩니다. 에이전트 비용은 _모델이 얼마나 혼란스러워했는지_에 따라 확장되며, 이는 예측할 수 없습니다. 지출을 거의 실시간으로 모니터링해야 하며, 그렇지 않으면 청구서를 보고서야 알게 될 것입니다.

3. 모든 것이 여러분이 소유하고 싶지 않았던 인프라입니다. 에이전트 자체는 200줄에 불과합니다. 하지만 그 주변에는 이제 다음과 같은 것들이 생깁니다: 서버, 에이전트가 죽었을 때 재시작하기 위한 프로세스 매니저 (process manager), 수십 개의 API 키를 위한 비밀 정보 관리 (secrets handling), 요청이 쌓이지 않게 하기 위한 큐 (queue), 로그 집계 (log aggregation), 알림 (alerting), 그리고 프롬프트 수정 사항을 배포할 때 밤 11시에 서버에 SSH로 접속하지 않아도 되게 해주는 배포 파이프라인 (deploy pipeline). 만약 실행 상태 (execution state)가 Python 프로세스 내부에 존재한다면, 재시작은 단순히 에이전트를 종료하는 것에 그치지 않고 현재 작업에서 진행 중이던 모든 진척도를 지워버립니다. 이 중 흥미로운 부분은 하나도 없습니다. 하지만 이 모든 것이 필요합니다.

4. 계획보다 훨씬 빠르게 하나가 열 개로 불어납니다. 첫 번째 에이전트가 잘 작동하면 누군가 두 번째를 요구합니다. 그다음에는 영업팀에서 하나, 고객 지원팀에서 하나를 원하게 되고, 이제 당신은 작은 함대를 보유하게 됩니다. 각 에이전트는 자신만의 키(keys), 실패 모드(failure modes), 비용(spend)을 가지고 있지만, 이를 한곳에서 볼 수 있는 단일 지점은 없습니다. 바로 이때 사람들이 흩어진 열 개의 스크립트 대신 하나의 제어 평면(control plane)을 제공하는 AI 에이전트 오케스트레이션 플랫폼 (AI agent orchestration platform) 또는 _AI 에이전트 관리 플랫폼 (AI agent management platform)_을 찾기 시작합니다.

에이전트에게 "프로덕션 준비 완료(production-ready)"란 실제로 무엇을 의미하는가

유행어를 걷어내 봅시다. AI 에이전트를 위한 프로덕션 설정에는 여섯 가지가 필요합니다:

• 의식이 필요 없는 배포 (Deployment that isn't a ritual). 변경 사항을 푸시하면 서버를 씨름할 필요 없이 즉시 반영되어야 합니다. 프롬프트 수정 하나를 배포하는 것이 두려운 일이라면, 당신은 에이전트 개선을 멈출 것이고, 정체된 에이전트는 도태될 것입니다.
• 완전한 관측 가능성 (Full observability). 모든 행동, 모든 도구 호출(tool call), 모든 결정이 사후에 재현 가능해야 합니다. 에이전트가 새벽 3시에 멍청한 짓을 했을 때, 당신에게 필요한 것은 추측이 아니라 영수증(receipt)입니다.
• 내구성이 있는 실행 (Durable execution). 프로세스 종료나 배포 후에도 살아남는 상태(state)가 필요합니다. 충돌(crash)이 발생했을 때

이 점에 주목하세요. 이 내용들은 에이전트를 더 ‘똑똑하게(smarter)’ 만드는 것에 관한 것이 아닙니다. 에이전트를 ‘운영 가능하게(operable)’ 만드는 것에 관한 것입니다. 똑똑한 것은 프레임워크의 역할입니다. 운영 가능한 것은 여러분의 몫이며, 이것이야말로 해당 시스템이 실제 사용자들과 접촉했을 때 살아남을지 여부를 결정하는 일입니다.

플랫폼 구축 또는 임대하기

운영 계층(operational layer)이 실제로 해야 할 작업이라는 것을 받아들였다면, 두 가지 길이 있습니다.

직접 구축하기(Roll your own). 완전히 가능합니다. Kubernetes나 VM 군집, 프로세스 슈퍼바이저, Prometheus 같은 로깅 스택, 시크릿 관리자, 그리고 아마 직접 작성해야 하는 비용 측정 계층(per-agent token accounting은 공짜로 얻을 수 있는 것이 아닙니다)이 필요하며, 그 위에 배포 파이프라인까지 구축해야 합니다. 만약 여러분에게 플랫폼 팀이 있고 이 역량이 비즈니스의 핵심이라면, 직접 소유하는 것이 좋습니다.

제어 평면 임대하기(Rent the control plane). 목표가 에이전트 인프라를 ‘운영’하는 것보다 에이전트를 ‘출시’하는 것이라면, 운영 계층을 이 작업을 위해 구축된 AI 에이전트 배포 플랫폼에 맡기고 실제 제품 개발에 집중하세요.

두 가지 길: 스택을 소유할 것인가, 아니면 제어 평면을 임대할 것인가.

제가 결국 선택한 길은 두 번째 길이었습니다. 첫 번째 에이전트가 조용히 작동을 멈춘 이후, 저는 이 부분을 직접 구현(hand-rolling)하는 것을 그만두었습니다. 저는 현재 OneTeam APP을 통해 에이전트를 운영합니다. 이는 관리형 제어 평면 (managed control plane)으로, 서버에 SSH 접속을 할 필요 없이 몇 분 만에 에이전트를 배포하고, 에이전트가 취하는 모든 행동을 실시간으로 관찰하며, 각 에이전트가 정확히 얼마를 소비하고 있는지 확인할 수 있습니다. 실시간 액션 피드 (live action feed) 덕분에 "에이전트가 왜 저런 행동을 했지?"라는 의문은 2시간짜리 조사 작업에서 30초간의 스크롤로 바뀌었습니다. 이제 목요일의 데모와 수요일의 침묵 사이에서 무슨 일이 일어났는지 조각조각 맞추는 일은 더 이상 없습니다. 실행이 중단되었을 때, 에이전트가 이미 무엇을 완료했는지 추측하는 대신 정확히 어디서 멈췄는지 확인하고 그 지점부터 다시 시작할 수 있습니다. 지출 한도(spending caps)가 설정된 에이전트별 비용 추적 (per-agent cost tracking) 덕분에, 제어 불능 루프 (runaway-loop) 시나리오 때문에 밤잠을 설치는 일도 사라졌습니다. 지루한 운영 업무 80%가 해결되었기에, 저는 진정으로 제 소유인 20%의 업무에 시간을 쏟을 수 있게 되었습니다.

제어 평면 (control plane)이 제공하는 것: 실시간 액션, 에이전트별 비용, SSH 불필요.

이것만이 유일한 정답이라고 주장하려는 것은 아닙니다. 핵심은 바로 "카테고리"입니다. 직접 구축하든 임대하든, 프로덕션 환경에서 AI 에이전트를 배포하고 관리할 계층 (layer)이 반드시 필요합니다. 그렇지 않으면 침묵을 통해 에이전트가 사흘 전에 이미 죽었다는 사실을 뒤늦게 깨닫게 될 뿐입니다.

이를 수행하는 합리적인 순서

만약 여러분이 첫 번째 에이전트를 바라보며 저의 '목요일부터 수요일까지의 대서사시'를 반복하지 않으려면 어떻게 해야 할지 고민하고 있다면, 제가 지금 따를 순서는 다음과 같습니다:

1. 확장하기 전에 계측(Instrument)하세요. 에이전트가 아직 단순할 때, 첫 번째 에이전트에 완전한 단계별 로깅(step-level logging)을 추가하세요. 이미 구축된 대규모 플릿(fleet)에 관측성(observability)을 사후에 적용하는 것은 매우 고통스러운 일입니다.
2. 시작부터 모든 에이전트에 지출 한도(spending cap)를 설정하세요. 청구서를 보고 나서야 알게 되는 소프트 리밋(soft limit)보다는, 의도적으로 설정한 하드 리밋(hard limit)이 훨씬 낫습니다.
3. 배포를 단 한 번의 명령(또는 클릭)으로 만드세요. 배포 과정이 고통스럽다면 배포 빈도가 낮아질 것이고, 배포가 드물다는 것은 에이전트가 최신 상태를 유지하지 못하고 뒤처진다는 것을 의미합니다.
4. 에이전트 3번째를 만들기 전에 직접 구축할지(build) 빌려 쓸지(rent) 결정하세요. 10번째를 만든 후가 아닙니다. 마이그레이션 비용은 계속 증가할 뿐이며, 여기저기 흩어진 10개의 스크립트는 당신이 피하려고 했던 바로 그 난장판이 될 것입니다.
5. 플릿을 하나의 뷰(view)로 관리하세요. 에이전트가 두 개 이상이 되는 순간, "어디를 확인해야 하는가"에 대한 답은 단 하나여야 합니다.

지금 제가 따를 순서 — 먼저 계측하고, 나중에 확장하기.

솔직한 결론

오픈 소스 AI 에이전트 프레임워크와 상용 AI 에이전트 플랫폼들은 추론(reasoning), 계획(planning), 도구 사용(tool use)과 같이 어려워 보이는 문제들을 충분히 잘 해결해 두었습니다. 덕분에 이제 에이전트를 만드는 것은 오후 한나절이면 끝나는 해결된 문제가 되었습니다. 하지만 그들이 당신의 몫으로 남겨둔 것은 화려하지는 않지만 핵심적인 부분입니다. 바로 프로덕션 환경에서 에이전트 플릿을 생존시키고, 관측 가능하게 하며, 격리시키고, 예산 범위 내에서 관리하는 일입니다.

이것은 모델링(modeling)의 문제가 아닙니다. 운영(operations)의 문제이며, 당신의 영리한 에이전트가 신뢰할 수 있는 팀원이 될지 아니면 수요일 오후의 미스터리가 될지를 조용히 결정짓는 문제입니다. 운영 계층을 빌드 과정의 일급 시민(first-class part)으로 취급하세요. 의도적으로 직접 소유하거나 의도적으로 빌려 쓰십시오. 그렇게 해야 이 모든 과정이 마치 칼싸움을 하는 듯한 위태로운 느낌을 멈출 수 있습니다.