AI 시대, SaaS는 어떻게 진화해야 할까?

AI 에이전트의 부상은 기존 SaaS(Software as a Service)의 역할을 근본적으로 재정의하고 있음. 사용자는 더 이상 소프트웨어 자체를 사용하는 것이 아니라, AI 에이전트를 통해 업무를 완료하기를 원함. 예를 들어, CRM에 접속해 고객 목록을 필터링하는 대신, "매출 리스크가 큰 고객을 찾아 대응안을 제안해달라"는 식의 자연어 요청을 통해 원하는 결과를 얻고자 함. 이는 소프트웨어의 초점이 화면 조작에서 업무 맥락 이해 및 실행으로 이동하고 있음을 시사함. a16z가 지적하듯이, CRM, ERP 등은 단순 데이터베이스를 넘어 회사의 공식 데이터, 승인 절차, 컴플라이언스 요구사항을 포함하는 복잡한 시스템 오브 레코드(System of Record)로서, AI가 이를 완전히 대체하기보다는 추론 및 실행 계층을 통해 협업하는 형태로 발전할 것임.

AI 에이전트가 안정적으로 작동하는 SaaS를 만들기 위해서는 사람 중심 설계에서 벗어나야 함. AI는 사람처럼 화면을 클릭하는 방식(UI Automation)에 취약하며, UI 변경만으로도 작업 실패 가능성이 높음. 실제 이메일 자동 발송 에이전트 경험에서 보듯, API 기반의 직접적인 작업 수행이 훨씬 안정적이고 효율적임. SaaS-Bench 연구 결과 역시 현재 SaaS가 에이전트가 안정적으로 이해하고 실행하기에는 사람 중심으로 설계되었음을 보여줌. 따라서 미래 SaaS는 AI가 이해하고 실행할 수 있는 안정적인 API와 실행 계층을 제공하는 데 집중해야 하며, 이는 단순히 부가 기능이 아닌 핵심 인터페이스가 될 것임.

AI 에이전트의 등장으로 SaaS의 UI는 '작업 도구(Tool)'에서 '감독 도구(Supervisor)'로 변화해야 함. 사용자는 더 이상 모든 필드를 직접 채우는 주체가 아니라, AI가 제안한 작업 계획을 검토하고 위험한 실행을 승인하는 역할을 맡게 됨. 예를 들어, AI가 이탈 가능성 높은 고객을 선별하고 메일 초안을 작성했을 때, UI는 단순히 결과만 보여주는 것이 아니라 판단 근거, 위험군 선정 이유, 발송 전 승인 항목 등을 명확히 제시해야 함. TechRadar가 지적했듯, 기업 AI는 투명한 작동 방식과 통제 지점을 제공해야 신뢰를 얻을 수 있으며, 이를 위해 AI의 작업 계획, 변경 전후 비교, 승인 단계, 실행 로그, 되돌리기 기능이 제품 경험의 일부로 통합되어야 함.

AI 에이전트가 SaaS를 안전하게 사용하기 위해서는 별도의 정체성과 제한된 권한(Limited Permissions) 설계가 필수적임. 사용자의 계정을 그대로 AI에게 넘겨주는 것은 심각한 보안 위험을 초래할 수 있음. OAuth와 같은 프로토콜을 활용하여 AI에게 특정 작업만 허용하는 제한된 열쇠(Restricted Key)를 발급해야 함. 예를 들어, '고객 목록 조회는 가능하나 계약서 다운로드는 불가', '메일 초안 작성은 가능하나 발송은 사람 승인 필요'와 같은 권한 제어가 필요함. 또한, RBAC(Role-Based Access Control)를 통해 영업 지원, 재무 검토 등 역할별로 세분화된 접근 권한을 부여하고, 로그에는 'AI 에이전트가 수행함'이 아닌 '사용자 요청을 받아 AI 에이전트가 수행함'과 같이 명확한 추적 정보를 남겨야 함. Salesforce 역시 데이터와 가드레일 부족 시 위험을 경고한 바 있음.

AI 에이전트가 SaaS를 효과적으로 사용하기 위해 API는 핵심 인터페이스로서 더욱 중요해짐. 과거 외부 개발자 연동 수단이었던 API는 이제 AI 에이전트가 제품을 사용하는 주된 통로가 될 수 있음. AI는 사람과 달리 문맥 추론 능력이 부족하므로, API 문서는 기계가 읽을 수 있는 명세(Machine-Readable Specification)를 넘어, 실제 업무 단위(Business Unit)의 API를 명확히 설명해야 함. 예를 들어, PATCH /customers/{id} API는 단순히 '고객 정보 수정'을 넘어, 수정 가능한 필드, 알림 여부, 감사 로그, 되돌리기 가능성, 대량 수정 제한 등 상세 정보를 포함해야 함. 이는 AI가 복잡한 업무를 안전하고 정확하게 수행하기 위한 필수 조건이며, 개발자는 테스트 코드, 주석 코드 등을 통해 AI가 이해할 수 있는 상세 설명을 제공해야 함.

AI 에이전트가 화면 조작을 대신하면서 기존의 사용자 인터페이스(UI) 기반의 락인(Lock-in) 효과는 약화될 것임. 메뉴 위치나 버튼 사용법을 외울 필요가 줄어들기 때문임. 따라서 SaaS의 새로운 해자(Moat)는 데이터, 권한, 워크플로, 컴플라이언스, 그리고 고객사의 운영 맥락(Operational Context)이 될 것임. Bain은 AI 에이전트가 SaaS 간의 비싼 조정 업무를 자동화할 가능성이 크다고 봄. 즉, 소프트웨어 회사는 '예쁜 화면'보다 '업무 맥락을 얼마나 잘 구조화했는가'로 경쟁하게 될 것임. 또한, 가격 모델도 좌석 수(Seat-based) 과금에서 결과 기반(Outcome-based) 모델로 변화해야 함. Zendesk의 AI 상담 성공 건당 과금 모델처럼, 고객이 원하는 것은 더 많은 기능이 아니라 더 적은 시간, 더 빠른 업무 완료이므로, 소프트웨어 가치는 '완료된 업무'를 기준으로 평가받게 될 것임.