Agent as a Service(AaaS): 소프트웨어를 사는 시대에서 성과를 구독하는 시대로
YField··13 min read
요약
지난 15년간 기업 소프트웨어의 표준은 SaaS였습니다. 서버를 사지 않고 계정을 사고, 라이선스를 사지 않고 월 구독료를 냈습니다. 그런데 SaaS가 판매한 것은 결국 '도구'였습니다. 도구를 켜고, 데이터를 입력하고, 판단하고, 다음 단계로 넘기는 일은 여전히 사람의 몫이었습니다.
Agent as a Service(AaaS, 서비스형 에이전트)는 이 전제를 바꿉니다. 기업이 구매하는 대상이 '사람이 쓰는 도구'에서 '스스로 일하는 실행 주체'로 이동합니다. 계정 수가 아니라 처리된 업무량과 만들어진 성과로 값을 매기는 방식입니다. 경영진 관점에서 AaaS는 기술 트렌드가 아니라 비용 구조와 인력 구조를 동시에 건드리는 운영 모델의 변화입니다.
1. AaaS란 무엇인가
AaaS는 자율적으로 판단하고 행동하는 AI 에이전트를 클라우드 서비스 형태로 제공하는 전달 모델(delivery model)입니다. 기업은 모델을 직접 학습시키거나 오케스트레이션 계층을 구축하지 않고, API·플랫폼·기존 시스템 내 임베드 형태로 에이전트를 도입해 정해진 업무를 맡깁니다.
핵심 특성은 세 가지입니다.
| 특성 | 의미 | 기존 소프트웨어와의 차이 |
|---|---|---|
| 자율성(Autonomy) | 목표를 받으면 수행 방법을 스스로 설계 | 단계별 명령이 필요 없음 |
| 능동성(Proactivity) | 트리거를 감시하다가 먼저 행동 | 사람이 로그인해야 작동하지 않음 |
| 결과 지향(Outcome) | 완료된 업무 단위로 가치가 측정됨 | 기능 사용 여부가 아니라 처리 결과가 기준 |
중요한 것은 AaaS가 제품 카테고리가 아니라 판매·전달 방식이라는 점입니다. 챗봇도, RPA도, 코파일럿도 AaaS가 될 수 있고, 반대로 아무리 뛰어난 에이전트라도 자체 구축·자체 운영이라면 AaaS가 아닙니다. 구분 기준은 "누가 인프라와 운영 책임을 지는가"입니다.
2. SaaS와 AaaS는 무엇이 다른가
| 구분 | SaaS | AaaS |
|---|---|---|
| 작동 방식 | 수동적. 사람이 열고 조작해야 동작 | 능동적. 조건을 감지해 스스로 실행 |
| 가치 단위 | 로그인한 사용자 1명 | 완료된 업무 1건 또는 달성된 성과 |
| 과금 기준 | 좌석당 월 구독료 | 사용량 기반 또는 성과 기반(건당, 티켓당, 에이전트 가동 시간당) |
| 사람의 개입 | 전 과정에 지속 필요 | 예외 처리와 승인 지점에만 개입 |
| 확장 방식 | 인원이 늘어야 처리량이 늘어남 | 인원 증가 없이 처리량 확장 가능 |
| 도입 리스크 | 사용률 저조(shelf-ware) | 잘못된 자율 실행, 권한 관리 실패 |
한 줄로 정리하면 이렇습니다. SaaS는 도구를 줬고, AaaS는 일손을 줍니다.
이 차이는 IT 예산 편성 방식까지 바꿉니다. SaaS는 IT 비용(라이선스)이었지만, AaaS는 실질적으로 운영 비용(업무 처리 원가)에 가깝습니다. 즉 비교 대상이 '경쟁 솔루션의 구독료'가 아니라 '해당 업무를 사람이 처리할 때의 인건비'가 됩니다. 도입 검토의 언어 자체가 달라지는 것입니다.
3. AaaS가 지금 부상하는 이유
3.1 SaaS 과금 모델의 균열
좌석 기반 과금은 "쓰는 사람이 많을수록 가치가 크다"는 가정 위에 서 있습니다. 그런데 에이전트가 사람을 대신해 일하기 시작하면 이 가정이 무너집니다. 사용자 수는 줄어드는데 처리량은 늘어나는 구간이 생기기 때문입니다.
실제로 SaaS 업계의 가격 정책은 이미 이동 중입니다. 정액제와 좌석 기반 모델의 비중이 하락하고, 고정 구독료에 사용량 요소를 결합한 하이브리드 모델이 가장 높은 채택률을 보이고 있습니다. 성과 기반 과금은 현재 소수에 머물러 있지만, 향후 몇 년 내 채택률이 다섯 배 수준으로 확대될 것으로 전망됩니다.
3.2 모델 비용의 하락
에이전트를 실용적으로 만드는 것은 정확도만이 아니라 단가입니다. 동일 성능 기준 추론 비용이 빠르게 하락하면서, 이전에는 경제성이 나오지 않던 반복 업무까지 에이전트로 처리할 수 있는 구간에 들어왔습니다. 오픈 모델과 폐쇄형 모델의 성능 격차도 좁혀지며 선택지가 넓어졌습니다.
3.3 도입 부담의 실체
에이전트를 자체 구축하려면 모델 선택, 오케스트레이션, 도구 연동, 평가 체계, 관측 가능성, 보안 거버넌스까지 최소 여섯 개 계층을 동시에 감당해야 합니다. 대부분의 기업에게 이는 AI 조직을 새로 만드는 일과 같습니다. AaaS는 이 부담을 외부화하는 대신, 기업이 자사 업무 정의와 데이터 품질에 집중하도록 만듭니다.
4. AaaS의 구성 요소
AaaS 서비스를 평가할 때는 아래 다섯 계층을 기준으로 보는 것이 실무적으로 유용합니다.
| 계층 | 역할 | 검토 포인트 |
|---|---|---|
| 추론 계층 | 목표 해석, 계획 수립, 판단 | 멀티 모델 지원 여부, 한국어 처리 품질 |
| 오케스트레이션 계층 | 다단계 작업 분해, 에이전트 간 협업 | 실패 시 재시도·롤백 정책 |
| 도구·통합 계층 | ERP, CRM, 그룹웨어, 사내 DB 연결 | 국내 SI 환경 및 온프레미스 연동 가능 여부 |
| 지식 계층 | 사내 문서·데이터 검색(RAG) | 한국어 임베딩 품질, 문서 갱신 주기 |
| 거버넌스·관측 계층 | 권한, 감사 로그, 성능 모니터링 | 개인정보 처리 경로, 행동 추적 가능성 |
특히 마지막 계층은 도입 검토에서 가장 자주 과소평가되는 영역입니다. 에이전트는 실행 주체이므로, 무엇을 근거로 어떤 판단을 내려 어떤 시스템을 건드렸는지 사후 추적할 수 없다면 사고 시 책임 소재를 규명할 방법이 없습니다. 에이전트 관측 가능성(observability) 시장이 별도 카테고리로 빠르게 성장하는 이유입니다.
5. 어디에 먼저 적용되는가
AaaS의 초기 성과는 '규칙이 명확하고 반복되며 결과 측정이 쉬운' 업무에서 나옵니다.
| 영역 | 에이전트가 맡는 일 | 측정 가능한 성과 지표 |
|---|---|---|
| 고객 지원 | 문의 분류, 단순 문의 자동 해결, 복합 건 에스컬레이션 | 자동 해결률, 평균 처리 시간, 인당 처리 건수 |
| 영업 | CRM 기록 갱신, 리드 스코어링, 후속 메일 발송 | 영업 활동 기록률, 리드 응답 속도 |
| 재무·백오피스 | 세금계산서 대사, 지출 검증, 예외 건 플래깅 | 자동 대사율, 마감 소요일 |
| 공급망 | 이상 징후 탐지, 대체 운송 경로 및 재고 조정안 제시 | 납기 준수율, 지연 손실 비용 |
| IT 운영 | 인프라 모니터링, 1차 장애 대응, 티켓 라우팅 | MTTR, 야간 호출 건수 |
| 문서 업무 | 보고서 초안 작성, 회의 일정 조율 및 안내 발송 | 문서 작성 소요 시간 |
국내에서도 이 패턴이 그대로 나타나고 있습니다. 삼성SDS는 디지털 물류 플랫폼에 에이전틱 AI 공급망을 접목해 이상 징후 탐지와 대체 경로 제안을 자동화하고 있고, 생성형 AI 플랫폼 패브릭스(FabriX)와 업무 협업 솔루션 브리티(Brity)를 축으로 기업·공공 AX 사업을 확장하고 있습니다. LG CNS는 에이전틱 AI 플랫폼 '에이전틱웍스'와 자체 AI 에이전트를 앞세워 제조·금융·유통·공공 영역에 공급하고 있습니다. 공공 부문에서는 데이터 검색부터 보고서 작성, 회의 일정 조율과 참석 요청 메일 발송까지 하나의 흐름으로 처리하는 사례가 이미 시연 단계를 넘어섰습니다.
6. 도입 전 반드시 짚어야 할 다섯 가지
6.1 자율성의 범위를 문서로 정의하라
"에이전트가 어디까지 스스로 결정할 수 있는가"는 기술 설정이 아니라 경영 의사결정입니다. 금액 기준, 고객 등급 기준, 되돌릴 수 없는 행위(환불, 계약 발송, 데이터 삭제) 기준으로 승인 지점을 명시해야 합니다.
6.2 데이터 준비가 성패를 가른다
에이전트의 성능 상한선은 모델이 아니라 사내 데이터의 정합성이 결정합니다. 부서별로 다른 용어, 갱신되지 않은 정책 문서, 시스템 간 불일치는 그대로 오답으로 되돌아옵니다. 파일럿 이전에 대상 업무의 데이터 정비 범위를 먼저 확정해야 합니다.
6.3 한국어와 국내 규제 환경
한국어 업무 문서는 존댓말, 축약, 부서 은어, 영문 혼용이 뒤섞여 있어 범용 처리 파이프라인만으로는 정확도가 떨어집니다. 한국어 특화 임베딩과 도메인 사전 구축이 필요합니다. 동시에 개인정보보호법(PIPA) 관점에서 에이전트가 접근하는 데이터의 처리 위탁 구조, 국외 이전 여부, 보관 기간을 계약 단계에서 확정해야 합니다.
6.4 성과 기반 과금은 측정 체계가 전제다
성과 기반 계약은 매력적이지만, '성과'의 정의가 모호하면 분쟁으로 이어집니다. 자동 해결로 집계되는 조건, 재문의 발생 시 처리, 에이전트 오판으로 인한 손실의 부담 주체를 사전에 합의해야 합니다.
6.5 TCO는 구독료가 전부가 아니다
실제 비용에는 구독료 외에 연동 개발, 데이터 정비, 예외 처리 인력, 모니터링 도구, 재교육 비용이 포함됩니다. 반대로 편익에는 인건비 절감뿐 아니라 처리 속도 개선에 따른 매출 기여가 포함되어야 합니다. 한쪽만 계산하면 판단이 왜곡됩니다.
7. 단계별 도입 로드맵
| 단계 | 기간(권장) | 핵심 과제 | 완료 기준 |
|---|---|---|---|
| 1. 업무 진단 | 4~6주 | 반복도·측정 용이성·리스크 기준으로 후보 업무 선별 | 우선순위 업무 2~3개 확정, 현행 KPI 기준선 확보 |
| 2. 파일럿 | 8~12주 | 단일 업무, 제한된 자율성, 사람 승인 병행 | 정확도와 처리 시간이 기준선 대비 개선 확인 |
| 3. 운영 전환 | 3~6개월 | 권한·감사 체계 정비, 예외 처리 프로세스 정착 | 자동 처리 비중 목표 달성, 사고 대응 절차 검증 |
| 4. 확장 | 6개월 이후 | 인접 업무로 확대, 에이전트 간 연계 | 부서 간 워크플로 자동화, 과금 모델 재협상 |
가장 흔한 실패는 2단계를 건너뛰고 전사 확산부터 시도하는 경우입니다. 에이전트는 실행 권한을 갖기 때문에, 오류의 파급 범위가 조회형 AI와는 비교할 수 없습니다.
8. 경영진을 위한 다섯 가지 질문
새로운 AaaS 제안을 검토할 때 다음 질문에 답이 나오지 않는다면 도입을 늦추는 편이 낫습니다.
- 이 에이전트가 대체하는 업무의 현재 처리 원가는 얼마인가
- 성과를 어떤 지표로, 누가, 어떤 주기로 측정하는가
- 에이전트가 잘못 실행했을 때 되돌릴 수 있는가, 그 책임은 누구에게 있는가
- 우리 데이터가 어디에 저장되고 누구에게 위탁되는가
- 공급사를 교체할 경우, 축적된 업무 지식과 로그를 가져올 수 있는가
마지막 질문은 특히 중요합니다. AaaS는 편의성이 높은 만큼 종속성도 큽니다. 업무 정의와 프롬프트, 평가 데이터셋을 기업이 자산으로 보유하는 구조인지 확인해야 합니다.
마치며
AaaS는 "AI를 도입할 것인가"라는 질문을 "어떤 업무를 사람이 아닌 시스템에 맡길 것인가"라는 질문으로 바꿉니다. 이는 도구 선택의 문제가 아니라 조직 설계의 문제입니다.
지금 시점에서 현실적인 접근은 전면 전환이 아니라, 측정 가능한 업무 두세 개를 골라 성과를 숫자로 증명하고, 그 숫자를 근거로 확장 범위와 과금 구조를 협상하는 것입니다. 에이전트가 처리한 업무량이 곧 계약 조건이 되는 시대에는, 측정 체계를 먼저 갖춘 기업이 협상력을 갖습니다.
와이필드는 AI 에이전트 설계, 데이터 파이프라인 구축, 운영 거버넌스 수립을 아우르는 도입 여정을 지원합니다. 어떤 업무부터 시작해야 할지 판단이 서지 않는다면, 업무 진단 단계부터 함께 검토해 보시기 바랍니다.