실제 서비스업에 AI 에이전트를 도입할 때 진짜로 문제가 되는 것들 (1년 운영 후기)
What actually breaks when you ship AI agents for real service businesses (a year in)
핵심 요약
서비스업 AI 자동화 1년 운영 경험을 바탕으로, 데모와 실제 제품 간의 간극과 실무에서 겪는 핵심 문제들을 공유합니다.
- 인프라의 중요성 — AI 모델 자체보다 인증, 데이터 격리, 에러 처리 등 보이지 않는 배관 작업이 훨씬 중요함
- 실질적 가치 — AI라는 기술 자체보다 고객의 시간을 아껴주는 구체적이고 사소한 워크플로우 해결이 핵심임
- 개발 범위 산정 — 서비스업 대상 솔루션은 1~2주 내로 빠르게 구축해야 하며, 장기 프로젝트는 비효율적임
- 운영 안정성 — AI의 지능보다 인간에게 넘기는 에스컬레이션 경로와 시스템 관측 가능성이 서비스 성공을 좌우함
지난 1년간 서비스업(HVAC, 계약업체, 공증인, 법률 사무소 등)을 위한 AI 자동화 시스템을 구축하고 운영해 왔습니다. 데모 영상은 실제보다 훨씬 깔끔해 보이기 때문에, 아무도 경고해주지 않는 실무의 문제점들을 공유하고자 합니다.
제가 겪은 몇 가지 문제들입니다:
-
AI 레이어는 쉬운 20%입니다. 어려운 80%는 그 주변의 지루한 배관 작업입니다. 인증, 클라이언트별 데이터 격리, 결제 예외 처리, 재시도 로직, 웹훅이 두 번 발생할 때의 처리 등이 포함됩니다. 약속을 잡는 에이전트는 데모일 뿐입니다. 약속을 잡고, 이중 결제를 방지하며, 캘린더 API 타임아웃 시 복구까지 해내는 것이 진짜 제품입니다.
-
사업주들은 "AI"를 원하는 게 아닙니다. 그들은 화요일의 여유를 되찾고 싶어 합니다. "퇴근 후 부재중 전화 놓치지 않기", "똑같은 서류 달라고 계속 쫓아다니지 않기"처럼 창피할 정도로 구체적인 성과가 먹힙니다. 유행어(buzzword)가 아니라 고통스러운 워크플로우에 집중하세요.
-
이 시장을 위한 대부분의 맞춤형 빌드는 1~2주 범위 내에서 끝나야지, 분기 단위가 아닙니다. 몇 달씩 걸린다고 견적을 낸다면, 과잉 설계이거나 워크플로우를 아직 이해하지 못한 것입니다.
-
처음부터 멀티 테넌트(Multi-tenant) 구조로 가야 합니다. 나중에 클라이언트별 격리 기능을 추가하는 건 정말 끔찍한 일입니다.
-
음성 AI는 이제 고객 앞에 내놓을 만큼 좋아졌지만, 전달/에스컬레이션 경로를 제대로 설계했을 때만 가능합니다. AI가 얼마나 똑똑하게 들리느냐보다 인간에게 언제 넘겨야 할지 아는 것이 훨씬 중요합니다.
댓글로 이 내용들에 대해 구체적으로 논의할 의향이 있습니다. 기술 스택, 비기술직 사업주들과 범위를 정하는 법, 프로덕션 환경에서 에이전트가 조용히 실패하는 지점 등 무엇이든 도움이 될 만한 이야기를 나눌 수 있습니다.
(참고로 저는 이 모든 것을 직접 구축하고 운영하기 때문에, 위 내용은 이론이 아니라 흉터로 남은 경험담입니다.)
