지난 10여 년 동안 기업용 소프트웨어의 중심에는 SaaS(Software as a Service)가 있었다. CRM은 영업 조직의 표준 도구가 되었고, ERP는 재무와 구매 흐름을 관리했으며, HRIS(Human Resources Information System)는 사람과 조직의 정보를 기록했다. 사용자는 브라우저에 로그인해 화면을 보고, 메뉴를 찾고, 버튼을 누르며 업무를 처리하면 됐다.

우리 회사도 다양한 SaaS를 오랜 기간동안 써왔다. 인사&평가 관리는 Workday, 전자 계약서 작성은 DocuSign, 회계 및 재무 처리는 SAP 등 이러한 SaaS는 기업에서 여러 분야의 필요한 각각의 영역을 전문적으로 대신해 주고, 기업이 본질적인 사업에 집중할 수 있도록 많은 도움을 주었다.

하지만 AI 에이전트가 등장하면서, SaaS를 사용하는 기업 및 고객은 조금씩 줄어들고 있다. 사용자는 더 이상 “CRM에 들어가서 고객 목록을 필터링해줘”라고 생각하지 않는다. 대신 “이번 분기 매출 리스크가 큰 고객을 찾아 대응안을 제안해줘”라고 말하고 싶어 한다. 원하는 것은 소프트웨어 사용 자체가 아니라 업무의 완료다.

섣불리 생각해서 이러한 변화가 곧 CRM, ERP, HRIS의 종말을 뜻한다고 속단할 수는 없다. a16z가 지적하듯이 이런 시스템 오브 레코드는 단순한 데이터베이스가 아니다. 그 안에는 회사의 공식 데이터, 승인 절차, 권한 구조, 예외 처리, 컴플라이언스 요구사항이 들어 있다. AI가 화면이라는 “머리”를 바꿀 수는 있어도, 기업 운영의 몸통까지 쉽게 대체하기는 어렵다.

따라서 AI 시대의 변화는 기존 SaaS가 사라지는 것이 아니라, 그 위에 새로운 추론과 실행 계층이 올라가는 것에 가깝다. 앞으로의 소프트웨어는 사람만 쓰는 도구가 아니라, 사람과 AI 에이전트가 함께 사용하는 업무 시스템이 되어야 한다.

그렇다면 에이전트가 잘 사용할 수 있는 SaaS를 만들려면 우리는 어떠한 부분을 신경 써야 할까? 이번 글에서는 이 주제에 대한 생각들을 이야기해 보고자 한다.

에이전트 친화적인 SaaS는 무엇이 달라야 하는가

에이전트 친화적인 SaaS란 사람이 쓰기에도 좋고, AI가 대신 쓰기에도 좋은 소프트웨어다. 여기서 중요한 점은 AI가 사람처럼 화면을 클릭하게 만드는 것이 최선은 아니라는 점이다. 화면은 사람에게는 편하지만 AI에게는 불안정하다. 버튼 위치가 바뀌거나 팝업이 뜨는 것만으로도 작업이 실패할 수 있다.

나의 경우, 이전에 자동으로 이메일을 보내는 에이전트 작업을 해본 경험이 있다. 이메일 앱에서 주소를 입력하고 필요한 정보(제목, 본문 등)를 입력해서 이메일을 발송해야 하는데, 브라우저 MCP가 엉뚱한 입력창에 값을 넣는다는지, 전송 버튼을 못 찾아서 시간을 허비한다든지 하는 사례가 있었다. 이러한 작업은 앞으로 이렇게 에이전트가 브라우저를 탐색해서 하는 것이 아니라, 메일 작성, 메일 전송 등의 작업을 수행하는 API를 찾아서 인증 후 요청하는 방식으로 처리해야 빠르고 깔끔하다는 것을 알게 되었다.

최근 SaaS-Bench 연구에서도 실제 SaaS 환경에서 AI 에이전트가 긴 업무 흐름을 끝까지 수행하는 데 여전히 어려움을 겪는다는 결과가 나왔다. 이는 AI가 부족해서라기보다, 현재의 SaaS가 에이전트가 안정적으로 이해하고 실행하기에는 너무 사람 중심으로 설계되어 있다는 뜻이기도 하다.

그렇다면 SaaS는 어떻게 바뀌어야 할까?

1) UI/UX: 작업 화면에서 감독 화면으로

전통적인 SaaS UI는 사용자가 직접 조작하는 것을 전제로 했다. 메뉴, 버튼, 입력 폼, 대시보드가 핵심이었다. 하지만 AI 시대의 UI는 사용자가 모든 것을 직접 클릭하는 공간이 아니라, AI가 무엇을 하려는지 이해하고 승인하는 공간이 되어야 한다.

예를 들어, AI 에이전트가 “이탈 가능성이 높은 고객을 선별하고 후속 메일 초안을 작성했다”고 하자. 좋은 UI라면 단순히 결과 목록만 보여줘서는 안 된다. 어떤 데이터를 근거로 판단했는지, 어떤 고객을 위험군으로 봤는지, 어떤 메일을 보내려는지, 실제 발송 전에 사람이 승인해야 하는 항목은 무엇인지 보여줘야 한다.

즉, UI는 “작업 도구”에서 “감독 도구”로 바뀌어야 한다. 사용자는 모든 필드를 직접 채우는 사람이 아니라, AI가 제안한 작업 계획을 검토하고 위험한 실행을 승인하는 사람이 된다.

이를 위해서는 AI의 작업 계획, 변경 전후 비교, 승인 단계, 실행 로그, 되돌리기 기능이 제품 경험의 일부가 되어야 한다. TechRadar가 최근 지적한 것처럼 기업 AI가 “개인 생산성 도구”에 머무르면 신뢰를 얻기 어렵다. 조직의 워크플로 안에서 투명하게 작동하고, 통제 지점이 있어야 실제 업무에 들어갈 수 있다.

2) 인증과 권한: AI에게도 별도의 신분증이 필요하다

AI 에이전트가 SaaS를 사용하려면 인증과 권한 설계가 훨씬 중요해진다. 가장 위험한 방식은 사용자의 계정을 AI에게 그대로 넘겨주는 것이다. 사용자가 관리자 권한을 가지고 있다고 해서, AI가 모든 관리자 작업을 자동으로 실행해도 된다는 뜻은 아니다.

예를 들어, 한 기술 스타트업의 CTO가 깃허브의 레포지토리를 삭제할 권한이 있다고 가정해 보자. 레포 삭제를 할 권한이 있지만, 그렇다고 마음대로 레포 삭제를 해도 된다는 뜻은 아니다. 사람은 이러한 판단을 할 수 있지만 에이전트는 이렇게 판단하지 못하고 “레포 삭제 권한이 있어? 그러면 삭제할게.” 라고 1초도 안 되는 순간에 판단 해 버릴지도 모른다.

AI에게는 별도의 정체성과 제한된 권한이 필요하다. OAuth는 비밀번호를 넘기지 않고 특정 작업만 허용하는 제한된 열쇠를 발급하는 방식이다. 예를 들어 AI에게 “고객 목록은 조회할 수 있지만 계약서는 다운로드할 수 없다”, “메일 초안은 만들 수 있지만 발송은 사람이 승인해야 한다” 같은 권한을 줄 수 있다.

RBAC(Rule Based Access Control), 즉 역할 기반 접근 제어도 더 세밀해져야 한다. 영업 지원 에이전트, 재무 검토 에이전트, 고객 응대 에이전트는 서로 다른 데이터와 실행 권한을 가져야 한다. 또한 로그에는 “김 대리가 했다”가 아니라 “김 대리의 요청을 받아 영업 분석 에이전트가 수행했다”는 식으로 남아야 한다.

Salesforce 측에서도 AI를 잘못 도입하면 데이터와 가드레일 부족으로 큰 위험이 생길 수 있다고 경고한 바 있다. 기업용 AI에서 핵심은 “AI가 얼마나 똑똑한가”만이 아니다. AI가 어떤 권한으로 무엇을 했는지 추적할 수 있는가, 위험한 작업을 사람이 승인할 수 있는가, 문제가 생겼을 때 복구할 수 있는가가 더 중요하다.

3) API 명세와 문서: AI가 읽을 수 있는 제품 설명서

에이전트 친화적인 SaaS에서 API는 부가 기능이 아니라 핵심 인터페이스다. 과거에는 API가 외부 개발자나 파트너를 위한 연동 수단이었다면, 앞으로는 AI 에이전트가 제품을 사용하는 주된 통로가 될 수 있다.

사람은 화면을 보며 문맥을 추론할 수 있다. 하지만 AI가 안정적으로 일하려면 API의 의미가 명확해야 한다. 어떤 API가 어떤 업무 목적을 갖는지, 어떤 권한이 필요한지, 호출하면 실제 상태가 바뀌는지, 실패했을 때 어떻게 재시도해야 하는지가 문서에 드러나야 한다.

예를 들어, PATCH /customers/{id}라는 API가 있다고 하자. 단순히 “고객 정보 수정”이라고 적는 것만으로는 부족하다. 어떤 필드를 바꿀 수 있는지, 고객에게 알림이 가는지, 감사 로그가 남는지, 되돌릴 수 있는지, 대량 수정 시 제한은 무엇인지까지 설명해야 한다.

에이전트를 만드는 개발자들은 그래서 필자도 그렇고 많은 경우에 실제로 동작하는 코드보다 그 코드를 검증하기 위한 테스트 코드, 그 코드를 설명하는 주석 코드를 훨씬 더 많이 적는 경향이 있다. 사람은 히스토리를 알면 이 맥락 안에서 이 로직이 무엇인지 알 수 있지만 에이전트는 이러한 내용을 최대한 자세하게 설명해 주어야 정확한 판단을 할 수 있기 때문이다.

AI 시대의 API 문서는 개발자를 위한 참고서가 아니라, AI가 읽는 제품 설명서에 가깝다. OpenAPI 같은 기계가 읽을 수 있는 명세는 기본이고, “견적서 생성”, “승인 요청”, “환불 검토”처럼 실제 업무 단위의 API가 필요하다. 단순 CRUD API만으로는 AI가 복잡한 업무를 안전하게 수행하기 어렵다.

4) 데이터와 업무 맥락: 진짜 해자는 화면이 아니라 운영 지식이다

AI가 화면 조작을 대신하면, 사용자가 특정 SaaS UI에 익숙해져 생기던 락인은 약해질 수 있다. 메뉴 위치나 버튼 사용법을 사람이 외울 필요가 줄어들기 때문이다. 그렇다면 무엇이 소프트웨어의 해자가 될까? 데이터, 권한, 워크플로, 컴플라이언스, 그리고 고객사의 운영 맥락이다.

Bain은 에이전트 AI가 SaaS를 없애기보다 SaaS 사이의 비싼 조정 업무를 자동화할 가능성이 크다고 본다. 예를 들어 ERP에서 데이터를 뽑고, 스프레드시트와 대조하고, 벤더 메일을 해석하고, 예외 상황을 판단해 담당자에게 넘기는 일이다. 이런 업무는 단일 SaaS 화면 안에서 끝나지 않는다. 여러 시스템, 사람, 규칙 사이를 오가야 한다.

따라서 AI 시대의 소프트웨어 회사는 “예쁜 화면”보다 “업무 맥락을 얼마나 잘 구조화했는가”로 경쟁하게 될 가능성이 크다. 고객사의 데이터가 무엇을 의미하는지, 어떤 승인 절차를 거쳐야 하는지, 어떤 예외가 중요한지, 어떤 작업은 자동화하면 안 되는지를 제품이 이해하고 있어야 한다.

5) 가격 모델: 좌석 수에서 결과 중심으로

AI 에이전트는 SaaS의 가격 모델도 바꾸고 있다. 전통적인 SaaS는 사용자가 많을수록 가치가 커진다고 보고 좌석 수 기준으로 과금했다. 하지만 AI가 여러 사람의 반복 업무를 대신한다면, 좌석 수만으로 가치를 설명하기 어려워진다.

Zendesk의 AI 상담 과금 모델은 이 변화를 잘 보여준다. Zendesk는 AI 에이전트가 고객 문의를 성공적으로 해결했을 때 과금하는 결과 기반 모델을 제시했다. 이는 소프트웨어가 “접근 권한”이 아니라 “완료된 업무”를 팔기 시작했다는 신호다.

Bain도 SaaS 기업들이 AI 시대에는 로그인 수가 아니라 결과에 맞춰 가격을 설계해야 한다고 말한다. 고객이 원하는 것은 더 많은 화면, 더 많은 기능, 더 많은 좌석이 아니다. 더 적은 시간, 더 적은 오류, 더 빠른 업무 완료다.

단순히 AI 기능을 붙이는 것만으로는 부족하다

AI 시대에 적합한 소프트웨어는 단순히 챗봇을 붙인 SaaS가 아니다. AI가 이해하고, 사용할 수 있고, 안전하게 실행할 수 있으며, 사람이 그 과정을 감독할 수 있는 소프트웨어다.

앞으로 소프트웨어 회사가 고민해야 할 방향은 다음과 같지 않을까 예상해 본다.

제품을 화면 중심이 아니라 업무 모델 중심으로 재설계해야 한다.
AI 에이전트가 사용할 수 있는 안정적인 API와 실행 계층을 제공해야 한다.
권한, 승인, 감사 로그, 복구 가능성을 기본값으로 만들어야 한다.
고객사의 데이터와 운영 맥락을 구조화해야 한다.
가격 모델을 좌석 수가 아니라 실제 업무 결과에 가깝게 바꿔야 한다.

AI 시대의 변화는 SaaS의 종말이라기보다 SaaS의 재정의에 가깝다. 기록하는 시스템에서 판단하고 실행하는 시스템으로, 클릭하는 도구에서 감독 가능한 업무 동료로, 사용자 수를 파는 제품에서 결과를 파는 제품으로 이동하는 것이다.

여러분이 만드는 혹은 사용하는 소프트웨어는 사람에게 초점이 맞춰져 있는가? 아니면 에이전트에게 초점이 맞춰져 있는가?

<참고>