2026년 대행사가 판매할 수 있는 AI 에이전트 서비스

[현장 운영자의 시각] 나는 Pickleland(텍사스주 플러거빌에 있는 9개 코트 규모의 실내 피클볼 시설)와 내 컨설팅 브랜드 사이에서 30개 이상의 AI 에이전트를 실제 운영하고 있다. 강연이 끝날 때마다 대행사들은 같은 질문을 한다 — “에이전트가 어떻게 작동하나요”가 아니라 “제 서비스 메뉴에 실제로 뭘 올려야 하나요”라는 질문이다. 이것이 그 메뉴다. 내가 직접 운영하는 자동화에서 바로 가져온 6가지 항목이며, 각각 제안서에 쓰는 방식 그대로 정리했다: 무엇인지, 누구에게 맞는지, 어느 단계에 속하는지, 무엇을 과도하게 약속하면 안 되는지.

이 글은 비즈니스 자동화 방법에 관한 글이 아니다 — 그건 이미 여기에 썼다. 가격 산정 메커니즘에 관한 글도 아니다 — 그건 고객에게 얼마를 청구할지에서 다룬 구축비 플러스 유지보수 리테이너 구조다. 이 글은 그 둘보다 한 단계 위에 있는 내용이다 — 잠재 고객이 AI 에이전트가 무엇인지 먼저 설명 듣지 않고도 그중 하나에 “네”라고 답할 수 있을 만큼 좁게 정의한 실제 서비스 이름들이다.

목차

목차 열기

• ”AI 에이전트 서비스”라는 카테고리 자체가 팔리지 않는 이유
• 서비스 메뉴
  • 1. 이벤트 및 소셜 홍보 초안 작성
  • 2. 댓글 및 수신함 분류와 답변 초안 작성
  • 3. 주간 운영 브리핑
  • 4. 뉴스레터 초안 작성
  • 5. 예약 확인 및 후속 조치의 신뢰성
• 메뉴를 단품 혼란이 아니라 단계별 패키지로 묶기
• 여섯 가지 모두를 뒷받침하는 스택
• 자주 묻는 질문
  • 대행사는 출시 시점에 이 중 몇 가지를 제공해야 하나
  • 사내에 개발자가 필요한가
  • 대행사가 이 메뉴를 판매할 때 저지르는 가장 큰 실수는 무엇인가
  • 이 항목들 모두 사람의 검토 단계가 있어야 하나
  • 잠재 고객이 이 중 하나를 살 준비가 정말 되었는지 어떻게 아는가

”AI 에이전트 서비스”라는 카테고리 자체가 팔리지 않는 이유

“우리는 AI 에이전트를 구축합니다”는 서비스가 아니다. 이것은 역량에 대한 선언이며, 잠재 고객은 역량 선언을 사지 않는다 — 이름이 있고 결과가 정의된 무언가를 산다. “지역 비즈니스를 위한 AI 에이전트를 구축합니다”와 “매주 이벤트 홍보 게시물을 자동으로 작성해 매주 일요일 검토 대기열에 넣어드립니다”를 비교해 보라. 후자는 사업주가 금요일까지 자기 계정에서 돌아가는 모습을 그려볼 수 있다.

해결책은 전문성을 상품화된 서비스로 패키징하는 방법에서 다룬 것과 같은 원칙이다: 고정된 범위, 고객이 한 문장 안에서 쓸 수 있는 이름, 그리고 포함된 것 주위에 그어진 명확한 경계선. 아래 내용은 모두 그 기준에 맞춰 썼다. 가격을 제시하기 전에 이 항목들 중 하나를 서명된 범위 문서로 바꾸는 문서 양식이 필요하다면, 그건 AI 에이전트 범위 문서 작성법이다.

서비스 메뉴

6가지 자동화. 각각은 이 패턴을 판매하기 전에 내가 직접 먼저 운영해 본 것들이다.

1. 이벤트 및 소셜 홍보 초안 작성

무엇인가: 고객의 다가오는 이벤트나 프로모션을 일정한 주기로 확인하는 예약 에이전트다 — 내 것은 매주 일요일 다음 주 분을 실행한다 — 그리고 장소나 브랜드에 맞는 홍보 게시물 초안을 검토 대기열에 작성한다. 사람이 승인 버튼을 누르지 않으면 아무것도 게시되지 않는다.

누구에게 맞는가: 홍보할 것이 반복적으로 있는 모든 고객 — 이벤트, 강좌, 주간 특가, 오픈하우스. 체육관, 행사장, 레스토랑, 지역 서비스업체. 일회성이고 불규칙한 출시 일정을 가진 고객에게는 맞지 않는다. 에이전트가 걸 수 있는 반복적 주기가 없기 때문이다.

구축 단계: 단일 워크플로 에이전트 — 트리거 하나(시계), 데이터 소스 하나(고객의 캘린더나 예약 시스템), 출력 하나(대기열의 초안). 내 가격 체계에서 단일 워크플로 단계의 하위 범위에 해당한다.

과도하게 약속하면 안 되는 것: “소셜 미디어 관리”로 팔지 마라. 당신이 파는 것은 초안 생성이지, 전략도, 커뮤니티 운영도, 광고비 집행도 아니다. 범위 문서에 정확히 그렇게 써라. “소셜 미디어”라는 표현 자체가, 고객이 댓글 응대까지 맡기고 싶어 하는 순간 범위 확장을 부추기기 때문이다 — 그건 아래에서 다룰 별개의 항목이다.

2. 댓글 및 수신함 분류와 답변 초안 작성

무엇인가: 새 댓글이나 수신 메시지가 도착하면 웹훅으로 작동하는 에이전트로, 의도를 분류하고(질문/불만/칭찬/스팸, 또는 채널에 따라 질문/불만/예약/기타) 신뢰도 임계값을 넘는 항목에 대해 답변 초안을 작성한다. 칭찬은 기록되고, 스팸은 억제되며, 나머지는 모두 사람의 검토 대기열로 간다.

누구에게 맞는가: 사람이 수작업으로 분류할 만큼 수신량이 충분한 모든 고객 — 댓글이 활발한 페이스북 페이지, 공유 수신함, 예전에는 누군가 모든 메시지를 처음부터 읽어야 했던 문의 양식. 정말 수신량이 적은 계정에는 맞지 않는다. 주당 몇 건 이하라면 검토 대기열의 오버헤드가 그만한 가치가 없다.

구축 단계: 한 개 이상의 채널(예: 페이스북 댓글과 이메일)을 아우르거나 두 번째 분류 단계가 필요하면 다단계 에이전트, 하나의 채널에 하나의 출력 동작이면 단일 워크플로다. 단계는 메시지 양이 아니라 채널 수로 가격을 매겨라 — 양은 운영 비용을 바꾸지, 구축 비용을 바꾸지 않는다.

과도하게 약속하면 안 되는 것: 이것은 실제로 고객과 대화하는 사람을 대체하지 않는다. FAQ 성격의 질문과 명백한 스팸이라는 쉬운 80%를 정리해, 대기열을 검토하는 사람이 판단력이 필요한 메시지에 시간을 쓰도록 만든다. 제안 단계에서 이 점을 분명히 말하라. 고객 서비스 대체품을 산다고 생각한 고객은 두 달째에 실망한다.

3. 주간 운영 브리핑

무엇인가: 예약 건수, 취소율, 가동률 등 고객의 핵심 지표가 무엇이든 그 몇 가지 운영 수치와 표시된 이상 징후를 가져와, 매주 월요일 아침 사업주가 실제로 읽는 곳(Notion, 이메일, Slack)에 다섯 개 항목짜리 브리핑으로 정리해 전달하는 예약 에이전트다.

누구에게 맞는가: 지금은 두세 개의 대시보드에 로그인해 직접 계산해서 이 그림을 얻고 있거나, 아무도 정리할 시간이 없어서 아예 얻지 못하는 모든 사업주-운영자. AI 에이전트 전반에 회의적인 고객에게는 강력한 첫 판매 항목이다 — 리스크가 낮고, 아무것도 그를 대신해 행동하지 않으며, 첫 주부터 가치가 뚜렷하게 보인다.

구축 단계: 데이터 소스가 에이전트가 직접 읽을 수 있는 시스템(예약 플랫폼의 API, 스프레드시트 내보내기, 분석 계정)이라면 단일 워크플로다. 고객 데이터가 깔끔한 읽기 접근이 없는 곳에 있어 맞춤 스크래핑이나 수동 내보내기 처리가 필요하다면 한 단계 올려라.

과도하게 약속하면 안 되는 것: 브리핑은 보고할 뿐 결정하지 않는다. 고객이 “이상 징후 탐지”를 “에이전트가 매출이 왜 떨어졌는지 알려준다”로 읽지 않게 하라. 이것은 어떤 숫자가 정상 범위를 벗어났다는 것을 표시할 뿐이다. 왜인지는 여전히 사업주의 몫이며, 다만 더 빨리 거기 도달하게 해준 브리핑의 정보를 바탕으로 한다.

4. 뉴스레터 초안 작성

무엇인가: 고객의 정기 뉴스레터를, 고객이 제공하는 원본 자료(최근 게시물, 다가오는 이벤트, 계속 작성 중인 메모 문서 등)를 바탕으로 이메일 플랫폼의 초안 상태로 직접 작성하는 에이전트로, 사람의 편집과 발송을 기다리는 상태로 준비된다.

누구에게 맞는가: 이미 정기 뉴스레터 발송을 약속했지만 백지 문제가 시간을 잡아먹어 불규칙하게 발송하는 모든 고객. 아직 뉴스레터의 목적을 정하지 못한 고객에게는 맞지 않는다 — 초안 작성은 기존 습관을 가속할 뿐, 편집 판단력을 무에서 만들어내지 않는다.

구축 단계: 에이전트가 플랫폼의 네이티브 초안 상태에 직접 쓸 수 있다면(대부분의 최신 이메일 서비스 제공업체가 이를 지원한다) 단일 워크플로에 복잡도가 낮다. 수동 복사-붙여넣기 인계가 필요한 경우가 아니라면 말이다. 사용 가능한 API가 없는 이메일 서비스와 연동해야 한다면, 그건 추가 통합 작업이며 단계를 끌어올린다.

과도하게 약속하면 안 되는 것: 이것은 초안을 작성할 뿐, 사람이 매번 여전히 편집하고 발송한다. “저희가 대신 뉴스레터를 운영해 드립니다”로 포지셔닝하지 마라 — 그건 에이전트가 하지 않는 전략과 주기 결정에 대한 소유권을 암시한다. “첫 초안 작성이 병목이 아니게 되어서 뉴스레터가 제때 나간다”로 포지셔닝하라.

5. 예약 확인 및 후속 조치의 신뢰성

무엇인가: 모든 예약이 확인을 받고, 필요하면 시점에 맞춘 후속 조치까지 받도록 보장하는 에이전트다. 사람이 수작업으로 확인을 보내는 것은 보통날에는 충분히 빠르다 — 여기서의 가치는 에이전트에게는 컨디션이 나쁜 날이 없고 절대 하나도 놓치지 않는다는 점이다.

누구에게 맞는가: 예약이나 접수 흐름이 지금은 누군가 수동 확인 메시지 보내는 것을 기억하는 데 의존하고 있는 모든 고객. 서비스업체, 예약 기반 비즈니스, 확인 누락이 노쇼나 예약이 안 됐다고 착각하고 떠나는 고객으로 이어지는 모든 경우.

구축 단계: 다단계 — 트리거(신규 예약), 읽기(고객 및 예약 세부 정보), 쓰기(확인 및/또는 예정된 후속 조치), 그리고 보통 직원에게 알림까지. 검토용 텍스트를 초안만 작성하는 게 아니라 실제 예약 시스템이나 CRM을 건드리기 때문에 통합이 포함된 다단계 단계에 확실히 속한다.

과도하게 약속하면 안 되는 것: 절약되는 시간으로 팔지 마라 — 확인 이메일을 수동으로 보내는 데는 30초밖에 걸리지 않으므로, 시간만 기준으로 한 회수 계산은 약하다. 이것이 제거하는 실패 모드로 팔아라: 컨디션이 나쁜 날 사람이 확인을 놓치고 고객이 떠나 버리는 것. 에이전트에게는 컨디션이 나쁜 날이 없다. 이것이 진짜 판매 포인트이며, 내 자신의 비즈니스를 위해 이 패턴을 구축하는 근거로 쓰는 것과 같은 보험 가치 논리이기 때문에 정직하다.

메뉴를 단품 혼란이 아니라 단계별 패키지로 묶기

6개 항목은 메뉴이지, 6번의 별개 영업 대화가 아니다. 각각을 따로 제안하기보다 두세 개의 패키지로 묶는 편이 낫다.

• 스타터 패키지: 고객이 이미 잘못하고 있거나 아예 하지 않고 있는, 마찰이 가장 큰 작업 하나를 고른다 — 보통 주간 브리핑이나 홍보 초안 작성이다. 둘 다 리스크가 낮고 가치가 빨리 보이기 때문이다.
• 성장 패키지: 스타터 패키지가 신뢰를 쌓은 뒤 분류·응답 에이전트를 추가한다. 첫 번째 패키지에서 생긴 검토 대기열 습관이 이어지기 때문에, 고객이 여기서부터 복리 효과를 느끼기 시작한다.
• 신뢰성 패키지: 고객이 보호할 가치가 있는 실제 예약이나 접수 시스템을 갖추게 되면 예약 확인 에이전트를 단독으로 판매한다 — 이는 종종 가장 가치가 높지만 가장 화려하지 않은 판매이며, 고객이 먼저 리스크가 낮은 무언가에서 에이전트가 신뢰할 만하게 작동하는 것을 본 뒤에 더 잘 성사된다.

각 패키지에는 AI 에이전트 구축에 고객에게 얼마를 청구할지에서 설명한 방식대로 가격을 매겨라 — 시간당 견적이 아니라 패키지당 고정 구축비 플러스 유지보수 리테이너다. 그리고 고객을 위해 무언가를 구축하기 전에, 내가 스스로를 위해 이것들을 구축할지 결정할 때 쓰는 것과 같은 4단계 회수 점검 — 수작업 비용, 구축 비용, 운영 비용, 유지보수 세금 — 을 거쳐라. 자세한 내용은 ROI 프레임워크에 있다. 이 메뉴의 어떤 항목이 특정 고객에게 합리적인 회수 기간을 통과하지 못한다면, 그 고객에게는 팔지 마라 — 통과하는 항목을 팔아라.

여섯 가지 모두를 뒷받침하는 스택

여섯 가지 모두 내가 내 자신의 비즈니스에서 쓰는 것과 같은 가벼운 스택 위에서 돌아간다: 모델 계층으로는 Claude, 예약 및 웹훅 트리거를 위한 Cloudflare Workers, 그리고 개발자가 아닌 사람도 실제로 들여다볼 수 있는 검토 대기열과 작업 상태의 근간으로서 Airtable이다. 이 중 어느 것도 엔터프라이즈 소프트웨어나 대규모 팀을 필요로 하지 않는다 — 이것이 대기업 계정이 아니라 중소 고객에게 판매하는 대행사에게 이 경제성이 성립하는 이유의 일부다.

자주 묻는 질문

대행사는 출시 시점에 이 중 몇 가지를 제공해야 하나

여섯 개 전부가 아니라 두세 개다. 이미 보유한 고객군에 맞는 것을 골라라 — 고객군이 주로 소셜 프로필이 활발한 지역 서비스업체라면 홍보 초안 작성과 댓글 분류부터 시작하라. 처음 두 개를 잘 전달한 뒤 나머지를 추가하는 편이, 여섯 개를 동시에 출시해 어느 것도 제대로 전달하지 못하는 것보다 쉽다.

사내에 개발자가 필요한가

단일 워크플로 단계(홍보 초안 작성, 주간 브리핑, 뉴스레터 초안 작성)는 스크립팅과 API 문서에 어느 정도 익숙한 사람이면 구축할 수 있다. 시니어 엔지니어가 필요하지 않다. 다단계 단계(채널 간 분류, 예약 확인)는 실제 개발 경험의 도움을 받는다. 주로 실제 예약 시스템을 건드리는 것의 프로덕션 신뢰성이 검토용 텍스트만 초안 작성하는 것보다 더 중요하기 때문이다.

대행사가 이 메뉴를 판매할 때 저지르는 가장 큰 실수는 무엇인가

결과가 아니라 역량을 파는 것이다 — “AI 에이전트 서비스”가 아니라 “당신의 이벤트 홍보물은 이미 작성되어 매주 일요일 아침 당신의 승인을 기다리고 있습니다”라고 말해야 한다. 후자는 고객이 머릿속에 그릴 수 있는 서비스다. 전자는 영업 회의일 뿐이다.

이 항목들 모두 사람의 검토 단계가 있어야 하나

처음 네 개는 그렇다 — 모두 사람이 승인해야 하는 초안을 만들어낸다. 예약 확인 에이전트는 예외다. 확인은 리스크가 낮고 시간에 민감해서 검토 대기열이 오히려 목적 자체를 무력화하기 때문이다. 어떤 출력물에 검토가 필요하고 어떤 것에는 필요 없는지를 구분하는 것은 모든 범위 문서에 명시할 가치가 있다. 자세한 내용은 AI 에이전트 범위 문서 작성법에서 더 깊이 다룬다.

잠재 고객이 이 중 하나를 살 준비가 정말 되었는지 어떻게 아는가

이미 그 기본 작업을 수작업으로 하고 있고, 그것을 당신에게 구체적으로 설명할 수 있다 — 무엇이 그것을 촉발하는지, 대략 얼마나 걸리는지, 좋은 결과물이 어떤 모습인지. 현재 프로세스를 설명하지 못하는 잠재 고객은 에이전트를 도입할 준비가 안 된 것이다 — 먼저 그 프로세스를 정의하는 대화를 할 준비가 된 것이며, 그것은 별개의, 더 작은 작업이다.