SaaS를 위한 AI 에이전트: 무엇을 먼저 자동화할까

[운영자의 시선] 나는 클라이언트를 위해 AI 에이전트 작업의 가격을 책정하고 직접 구축해왔고, 컨설팅 브랜드와 오스틴, 텍사스 광역권에서 운영하는 피클볼 시설 Pickleland 사이에서 30개 이상의 에이전트를 프로덕션에서 운영하고 있으며, Claude를 엔지니어링 파트너로 삼아 실제 멀티테넌트 클럽 관리 SaaS인 Courtlines를 만들었다. SaaS 비즈니스가 자동화에서 실제로 무엇이 필요한지 추측하고 있는 게 아니다 — 내가 직접 운영하고 있다. 아래는 모든 에이전트 의사결정에 사용하는 것과 같은 단계 프레임워크와 ROI 계산을, 구독형 비즈니스를 구성하는 워크플로에 구체적으로 적용한 것이다.

목차

목차 열기

• 기본 본능은 거꾸로 되어 있다
• 후보를 하나가 아니라 세 가지 축으로 평가하라
• 어디서 시작할까: 지원 응답이 아니라 지원 분류
• ROI 계산에서 SaaS만의 특징
• 온보딩 리마인더: 또 하나의 쉬운 승리
• 표시만 하고 직접 행동하지는 않을 것: 사용량 이상과 이탈 위험
• 적어도 처음에는 완전히 피할 것들
• 최신 벤더 선택지는 어디서 확인할까
• 당신에게 넘기지 않을 부분: Courtlines의 플레이북
• FAQ
  • SaaS 창업자가 가장 먼저 구축해야 할 AI 에이전트는 무엇인가요?
  • SaaS가 환불이나 청구 분쟁을 자동화해야 할까요?
  • SaaS 자동화는 지역 비즈니스 자동화와 어떻게 다른가요?
  • SaaS를 자동화하는 데 커스텀 멀티에이전트 시스템이 필요한가요?
  • AI 에이전트가 이탈을 직접 줄일 수 있나요?

기본 본능은 거꾸로 되어 있다

SaaS 창업자에게 “AI로 뭘 가장 먼저 자동화해야 할까요?”라고 물으면 거의 모두가 같은 답을 한다: 지원 챗봇. 가장 눈에 띄는 워크플로이고, 경쟁사들이 이미 광고하고 있는 것이며, 카테고리 의미에서 가장 “AI”처럼 느껴지는 것이기 때문이다.

하지만 그게 옳은 출발점인 경우는 드물다. 지원 봇은 고객을 직접 상대하고, 범위가 열려 있는 다양한 질문을 처리해야 하며, 돈을 지불하는 바로 그 사람 앞에서 실패한다. 시작하기에 가장 난이도가 높고 위험 부담이 큰 지점이지 가장 쉬운 지점이 아니다. 5가지 항목 루브릭을 정말 빠르게 통과하는 워크플로는 더 조용하고, 대부분 고객 눈에는 보이지 않는다.

후보를 하나가 아니라 세 가지 축으로 평가하라

워크플로를 고르기 전에 양, 실패 비용, 그리고 이미 얼마나 잘 정의되어 있는지로 점수를 매겨라.

1. 양. 한 달에 얼마나 자주 발생하는가? 낮은 빈도의 작업은 아무리 성가셔도 개발 비용을 정당화하지 못하는 경우가 많다.
2. 실패 비용. 에이전트가 틀리면 어떤 대가를 치르는가 — 몇 분간의 뒷수습, 환불, 이탈한 고객, 아니면 컴플라이언스 문제인가? 이 축이야말로 고객을 직접 상대하고 되돌릴 수 없는 일부터 시작하지 못하게 막아줘야 한다.
3. 정의된 정도. 그 작업은 명확하고 반복 가능한 패턴인가, 아니면 건마다 진짜 판단이 필요한가? 변형이 천 가지여도 잘 정의된 작업은 여전히 좋은 자동화 후보다. 반면 모든 경우가 진짜로 다른 작업은 양이 아무리 많아도 후보가 아니다.

가장 먼저 자동화할 가치가 있는 워크플로는 양과 정의된 정도에서 높은 점수를, 실패 비용에서 낮은 점수를 받는다. 이 조합이 바로 내가 거의 항상 지원 티켓 분류와 온보딩부터 시작하는 이유다 — 챗봇도, 청구도 아니다.

어디서 시작할까: 지원 응답이 아니라 지원 분류

이 기준을 가장 빨리 통과하는 워크플로는 “AI가 고객에게 답하게 하는 것”이 아니라 “AI가 읽고, 분류하고, 초안을 작성하게 하고, 사람이 전송 버튼을 누르는 것”이다. 구체적으로는 다음과 같다.

• 분류하기 — 들어오는 모든 티켓을 도착하는 즉시 카테고리와 긴급도에 따라 분류한다.
• 초안 작성하기 — 비밀번호 재설정, 문서에 명확한 답이 있는 청구 관련 질문, 기능 제공 여부 질문처럼 잘 정의된 카테고리에 대한 답변 초안을 만든다.
• 전달하기 — 모호하거나 감정적으로 격앙된 것은 분류 결과와 함께 바로 사람에게 넘겨서, 이를 맡는 사람이 처음부터 시작하지 않도록 한다.

이는 모든 자동화 결정에 사용하는 프레임워크에서 티어 2 DIY 구축에 해당한다 — 모델 호출 한 번, 문서나 FAQ에 대한 검색 한 번, 그리고 큐. 헬프데스크를 통째로 교체할 필요도 없고, 감독받지 않는 모델을 고객 앞에 세우지도 않는다 — 여기서 사람의 개입에 대한 질문에는 쉬운 답이 있다. 티켓 양이 검토 단계를 병목으로 만들 만큼 많은 경우는 드물고, 잘못된 분류가 초래하는 비용은 고객이 아니라 몇 분이기 때문이다.

이미 AI 어시스턴트가 인용할 수 있는 문서나 헬프센터를 구축해두었다면, 분류 에이전트와 그 GEO 작업은 서로를 강화한다 — 당신의 문서가 ChatGPT와 Claude에 인용되도록 만드는 바로 그 콘텐츠가, 분류 에이전트가 답변 초안을 작성하는 근거가 된다. 문서를 먼저 만들어라. 그 위에서라면 자동화가 더 쉽고 더 정확해진다.

ROI 계산에서 SaaS만의 특징

다른 모든 곳에서 사용하는 ROI 프레임워크 — 수동 비용 대 개발 비용 대 운영 비용 대 유지보수세 — 는 여기서도 변함없이 적용된다. SaaS에서 구체적으로 다른 점은 이 방정식에서 수동 비용 쪽이 움직이는 방식이다.

Pickleland에서는 대부분 작업의 양이 물리적 시설에 의해 제한된다 — 코트 9개짜리 클럽이 일주일에 만들어내는 예약 건수에는 한계가 있고, 자동화가 한번 구축되면 그 회수율은 대체로 평평하다. SaaS에는 그런 천장이 없다. 지원 티켓의 양은 인력이 아니라 고객 수에 비례해 늘어나므로, 지원 분류 에이전트의 회수 기간은 코드를 다시 건드리지 않아도 성장할수록 매달 더 좋아진다. 이것이 바로 통증을 느낀 후가 아니라 느끼기 전에 자동화를 구축해야 하는 가장 강력한 이유다. 고객 200명일 때는 수동 비용이 개발을 정당화하지 못할 수 있지만, 2,000명일 때는 분명히 정당화된다. 그리고 200명일 때 만든 에이전트가 바로 2,000명일 때 10배 더 빨리 회수되는 그 에이전트다.

특정 비즈니스에 대한 주장이 아니라 예시로 든 계산이다. 지원 티켓이 한 달에 200건이고 건당 처리 시간이 10분이라면, 수동 비용은 한 달에 약 33시간이다. 지원 인력을 늘리지 않고 고객 기반을 두 배로 늘리면 수동 비용은 두 배가 되지만, 에이전트의 운영 비용은 거의 움직이지 않는다 — 여전히 티켓당 분류 호출 한 번과 문서 검색 한 번이기 때문이다. 이렇게 점점 벌어지는 격차가, 이걸 일찍 구축해야 하는 이유의 전부다.

온보딩 리마인더: 또 하나의 쉬운 승리

고객을 직접 상대하는 그 무엇보다 먼저 구축할 두 번째 워크플로는 행동 기반으로 트리거되는 온보딩 메시지다. 사용자가 가입하고 48시간 안에 설정을 마치지 않는다 — 에이전트가 정확히 어디서 멈췄는지를 언급하는 리마인더 초안을 작성하고, 사람이 검토해서 보내거나, 그 패턴을 신뢰하게 되면 자동으로 보낸다. 이는 지원 분류와 같은 기준을 통과한다: 성장할수록 양이 늘고, 트리거 조건이 명확히 정의되어 있으며, 잘못된 리마인더가 초래하는 비용은 무시된 이메일 한 통 수준밖에 되지 않는다.

여기서도 다른 자동화에 사용하는 DIY 단계 스택의 상당 부분이 그대로 적용된다 — 초안 작성에는 Claude, 트리거 로직에는 큐, 누가 언제 리마인더를 받았는지 추적하는 데는 Airtable이나 자체 데이터베이스를 쓴다. 이 중 어느 것도 SaaS 전용 도구를 필요로 하지 않는다 — 내가 운영하는 다른 모든 에이전트와 동일한 기본 구성 요소들이다.

표시만 하고 직접 행동하지는 않을 것: 사용량 이상과 이탈 위험

한 가지 중요한 제약 조건과 함께 구축할 가치가 있는 두 가지 카테고리가 더 있다: 에이전트는 표시만 하고, 사람이 결정한다.

사용량 이상 탐지 — 고객 사용량의 갑작스러운 급증이나 급감, 실패한 결제, 사기일 수도 있고 정당한 파워 유저일 수도 있는 특이한 패턴. 이탈 위험 표시 — 역사적으로 해지에 앞서 나타나는 사용량 감소. 둘 다 조기 경보 시스템으로서 진짜 가치가 있다. 하지만 둘 다 고객을 직접 상대하는 자동 행동을 촉발해서는 안 된다. 실패 비용이 높기 때문이다(전혀 문제없는 고객에게 “사용량이 줄어든 것 같은데 괜찮으신가요?”라는 오탐 메시지를 보내면 감시처럼 느껴진다). 그리고 그 계정을 실제로 어떻게 지킬지에 대한 판단은 템플릿이 아니라 사람 사이의 관계가 필요한 바로 그런 종류의 일이다.

이는 승인 게이트를 언제 추가할지에서 내가 긋는 것과 같은 구분선이다: 에이전트가 감독 없이 탐지 작업을 하는 것은 괜찮다. 놓치거나 지연된 신호의 비용은 저렴하기 때문이다. 하지만 에이전트가 감독 없이 고객을 직접 상대하는 행동을 취하는 것은 그렇지 않다. 유료 계정을 상대로 한 잘못된 한 수는 비용이 크고 되돌리기 어렵기 때문이다.

적어도 처음에는 완전히 피할 것들

더 쉬운 승리들이 실제로 작동하고 검증될 때까지 손대지 않을 세 가지 카테고리가 있다.

• 환불과 청구 분쟁. 사람의 결정 없이 돈이 움직이는 것은 매번 게이트를 둘 가치가 있는, 되돌릴 수 없고 실패 비용이 높은 행동의 전형이지, 완전 자동화의 후보가 아니다.
• 계약 및 보안 사고 관련 커뮤니케이션. 법적 또는 컴플라이언스 무게를 지닌 모든 것은 모델이 아니라 사람의 이름이 뒤에 있어야 한다.
• 지원 챗봇 자체. 분류가 잘 작동하고, 사람이 검토하고 승인한 답변 몇 달치가 데이터셋으로 쌓이고 나면, “검토용 초안 작성”에서 “가장 좁고 가장 확신이 높은 질문 카테고리에 한해 직접 답변”으로 격상하는 것은 합리적인 다음 단계다. 여기서부터 시작하는 것은 문제의 가장 어려운 버전을 맨 먼저 구축하는 셈이다.

최신 벤더 선택지는 어디서 확인할까

이 글은 프레임워크이지 벤더 목록이 아니다 — 벤더 카테고리와 현실적인 예산 범위는 꽤 자주 바뀌기 때문에, 여기서 금방 낡아버릴 숫자를 반복하는 대신 SaaS를 위한 AI 에이전트 페이지에서 최신 상태로 유지하고 있다. 낡을 걱정 없이 말할 수 있는 것은 이것이다: 위의 어떤 워크플로도 시작할 때 커스텀 멀티에이전트 단계를 필요로 하지 않는다. 지원 분류와 온보딩 리마인더는 둘 다 기술을 아는 창업자가 주말 동안 출시할 수 있는 티어 2 DIY 구축이며, 내가 운영하는 다른 모든 에이전트에 쓰는 것과 같은 스택 — Claude, 큐, 상태를 저장할 곳 — 을 사용한다.

당신에게 넘기지 않을 부분: Courtlines의 플레이북

Courtlines가 정확히 위에서 설명한 스택으로 돌아가는지 묻는 사람들이 있는데, 합리적인 질문이다. Courtlines의 구체적인 자동화 플레이북은 경쟁상의 이유로 비공개로 유지하고 있으며, 이는 그것을 어떻게 만들었는지에 대한 이야기에서도 비공개로 유지해온 것과 같다. 솔직하게 말할 수 있는 것은 이것이다: 실제 청구, 실제 지원 물량, 무언가 고장 났을 때 알아차리는 실제 고객을 가진 진짜 멀티테넌트 SaaS를 구축하고 운영해본 경험이야말로, 내가 이론적인 프레임워크가 아니라 이 프레임워크를 신뢰하는 바로 그 이유다. Claude와 함께 진지한 프로젝트를 실제로 어떻게 작업하는지에 대한 숨김없는 공개 버전을 원한다면, 더 작은 프로젝트를 통해 전부 문서화해두었다. 모바일 보드게임 Quads를 Claude와 함께 만든 이야기를 읽어보라.

FAQ

SaaS 창업자가 가장 먼저 구축해야 할 AI 에이전트는 무엇인가요?

지원 티켓 분류다 — 분류하고 초안을 작성하되, 전송은 사람이 한다 — 고객을 직접 상대하는 챗봇이 아니다. 양이 많고, 정의가 명확하며, 잘못된 분류의 비용은 고객 관계가 아니라 몇 분이다. 온보딩 리마인더는 같은 기준을 통과하며 보통 두 번째로 구축하는 것이 된다.

SaaS가 환불이나 청구 분쟁을 자동화해야 할까요?

사람의 승인 게이트 없이는 안 된다. 감독 없이 돈이 움직이는 것은 프로세스에 사람을 남겨둬야 하는 교과서적인 사례다 — 실패 비용이 높고 행동을 되돌리기 어렵다. 탐지와 초안 작성은 자동화하되, 결정은 사람에게 남겨둬라.

SaaS 자동화는 지역 비즈니스 자동화와 어떻게 다른가요?

성장할수록 계산이 당신에게 유리해진다. 지역 비즈니스의 작업량은 물리적 용량에 의해 제한되므로, 자동화가 한번 구축되면 회수율은 대체로 평평하다. SaaS의 티켓과 온보딩 물량은 고객 수에 비례해 늘어나므로, 같은 에이전트의 회수 기간은 성장할수록 계속 좋아진다 — 이것이 바로 물량이 실제로 통증을 주기 전에 지원과 온보딩 자동화를 구축해야 하는 가장 강력한 이유다.

SaaS를 자동화하는 데 커스텀 멀티에이전트 시스템이 필요한가요?

초기에는 거의 필요 없다. 지원 분류와 온보딩 리마인더는 둘 다 단일 목적의 티어 2 DIY 구축이다 — 모델 호출 한 번, 검색 한 번, 큐 하나. 멀티에이전트 오케스트레이션은 진짜 다단계이고 실제 조건 분기가 있는 워크플로를 위해 남겨두어라. 대부분의 SaaS 자동화 요구는 창업자 단계에서는 아직 거기까지 이르지 않는다.

AI 에이전트가 이탈을 직접 줄일 수 있나요?

기껏해야 간접적으로, 그리고 결정을 사람에게 남겨둘 때만 그렇다. 에이전트는 사용량 감소를 조기에 표시하고 그 계정과의 관계를 소유한 사람에게 전달할 수 있다. 에이전트가 고객 본인의 이탈 위험에 대해 고객에게 직접 메시지를 보내게 하는 것은 실패 비용의 불일치를 만든다 — 조기 발견의 이점은, 실제로는 전혀 위험하지 않았던 고객에게 잘못되거나 어긋난 자동 메시지가 얼마나 나쁜 인상을 줄 수 있는지를 상쇄하지 못한다.

---

다음 단계: 위의 단계 프레임워크와 루브릭은 실제로 작동하는 코드와 함께 내 초보자를 위한 AI 에이전트 코스에서 전부 다룬다. 워크플로 감사를 대신 받고 싶다면 30분 세션을 예약하라.