

1. 제품에서 인프라로: SaaS의 근본적 전환
과거 SaaS의 성공 방정식은 명확했다. 사용자의 클릭 하나하나를 해부하고 최적의 경로를 설계하는 것, 즉 인간의 인지적, 행동적 특성에 기반한 사용자 경험(UX)을 극대화하는 것이었다. Salesforce, Slack, Notion과 같은 거인들은 사용자가 더 적은 노력으로 더 많은 것을 성취할 수 있도록 돕는 화려하고 직관적인 인터페이스(UI)를 경쟁력의 원천으로 삼았다. 이 시대의 SaaS는 그 자체로 완결된 디지털 작업 공간이었다. 사용자는 특정 과업을 해결하기 위해 해당 SaaS에 로그인하여, 그 안에서 제공하는 기능의 조합을 통해 원하는 결과를 얻어냈다.
그러나 AI, 특히 스스로 사고하고 실행하는 AI 에이전트(AI Agent)의 등장은 이 모든 전제를 뿌리부터 뒤흔들고 있다. 이제 SaaS의 주된 사용자는 모니터 앞에서 마우스를 움직이는 사람이 아닐 수도 있다. 대신, 복잡한 목표(예를 들면 "이번 분기 예상 매출이 가장 높은 잠재고객 10곳을 찾아내고, 맞춤형 영업 이메일 초안을 작성한 뒤, 내일 오전 미팅 일정을 조율해줘")를 부여받은 AI 에이전트가 그 자리를 차지하게 될 것이다. 이 새로운 사용자는 UI를 보지 않으며, 클릭 대신 API 호출로 소통한다. 따라서 SaaS의 역할은 인간을 위한 친절한 제품에서, AI 에이전트가 작업을 수행하기 위해 의존하는 견고하고 예측 가능한 기능 인프라로의 근본적인 전환을 맞이하고 있다.
이러한 전환은 단순히 기존 기능을 API로 포장하는 수준을 넘어선다. 이는 AI가 명확하게 이해하고, 예측하며, 호출할 수 있는 구조를 갖추는 것을 의미한다. 예를 들어, AI 에이전트가 고객 정보를 업데이트해야 할 때, 하나의 거대한 updateCustomer
API를 호출하는 것이 아니다. 대신, findCustomerByName
, getCustomerDetails
, updateSpecificField
, addInteractionLog
와 같이 잘게 쪼개진 원자적 기능들의 조합을 통해 과업을 수행한다. 각 기능의 이름과 필요한 정보(Parameters)는 AI가 해석할 수 있을 만큼 명확해야 하며, 그 결과는 일관된 데이터 구조로 반환되어야 한다.
결과적으로 SaaS의 가치를 평가하는 척도는 달라지고 있다. 얼마나 아름다운 UI를 가졌는가, 얼마나 편리한 UX 동선을 설계했는가는 더 이상 핵심이 아니다. 이제 경쟁력은 눈에 보이지 않는 영역에서 판가름 난다.
API의 신뢰성과 속도: AI 에이전트의 워크플로우를 지연 없이 처리할 수 있는가?
데이터의 정합성과 품질: AI가 신뢰하고 가공할 수 있는 깨끗한 데이터를 제공하는가?
맥락(Context)의 풍부함: 단순히 요청된 결과값만 돌려주는 것이 아니라, AI가 다음 행동을 추론하는 데 필요한 맥락적 정보를 함께 제공하는가? (예를 들어 일정 등록 API가 단순히 "성공"을 반환하는 대신, "생성된 일정 ID, 참여자들의 참석 가능 여부, 화상회의 링크"를 함께 돌려주는 것)
이처럼 미래의 SaaS는 사용자의 눈에는 보이지 않는 무대 뒤의 스태프와 같을 것이다. 화려한 조명을 받는 주연 배우는 AI 에이전트이지만, 그 배우가 최고의 연기를 펼칠 수 있도록 모든 소품과 장치를 정확한 타이밍에 제공하는 것, 그것이 바로 인프라로 진화한 SaaS의 새로운 사명이자 본질이라고 할 수 있다.
2. 생존 전략으로서의 AI 호출 가능성
많은 SaaS 기업들이 경쟁적으로 자체 AI 기능을 선보이고 있다. 문서 자동 요약, 데이터 기반 추천, 이미지 자동 태깅 등은 이제 사용자들에게 익숙한 기능이 되었다. 이는 분명 의미 있는 발전이지만, 다가오는 AI 시대의 본질적인 변화를 대비하기엔 부족하다. 이러한 기능들은 대부분 해당 SaaS라는 닫힌 생태계 안에서만 작동하며, 인간 사용자의 편의성을 높이는 데 초점이 맞춰져 있다.
진정으로 중요한 질문은 내부가 아닌 외부를 향해 있다. "우리의 SaaS는, 외부의 AI 에이전트가 자신의 목적을 달성하기 위한 도구로써 자유롭게 호출할 수 있도록 설계되어 있는가?"
AI 시대에 지속 가능한 성장을 이룰 SaaS는 단순히 AI 기능을 품은 똑똑한 제품이 아니다. 여러 AI와 서비스의 워크플로우를 관통하는 AI가 기꺼이 부르는 핵심 부품이다. 이를 위한 구체적인 조건들은 다음과 같다.
가. Function Calling 표준 대응: AI의 언어로 말하라
AI 에이전트(GPT, Gemini 등)는 스스로 API를 호출할 수 없다. 대신 'Function Calling'이라는 표준화된 메뉴판(명세서)을 읽고, 어떤 기능을 사용할 수 있는지, 각 기능을 사용하려면 어떤 정보가 필요한지를 학습한다. 만약 우리 SaaS의 API가 이 메뉴판 규격에 맞지 않다면, AI에게 우리 서비스는 존재하지 않는 것이나 마찬가지다.
무엇을 해야 하는가?: OpenAI의 Function Calling, Google의 Tool aalling 등에 사용되는 JSON Schema 형식에 맞춰 API의 기능, 파라미터, 반환값 등을 명확하게 정의해야 한다.
구체적인 예시 (CRM SaaS):
나쁜 예시:
https://api.mycrm.com/v1/process?action=new_lead&name=...
**좋은 예시 (AI가 이해하는 명세):**JSON
{ "name": "create_new_lead", "description": "새로운 잠재고객 정보를 시스템에 등록합니다.", "parameters": { "type": "object", "properties": { "company_name": {"type": "string", "description": "고객의 소속 회사명"}, "contact_person": {"type": "string", "description": "담당자 이름"}, "email": {"type": "string", "description": "담당자의 이메일 주소"} }, "required": ["company_name", "contact_person"] } }
AI 에이전트는 이 명세를 보고 "ACME사의 제인 도우를 잠재고객으로 등록해줘"라는 자연어 명령을
create_new_lead(company_name="ACME", contact_person="Jane Doe", ...)
와 같은 정확한 함수 호출로 변환할 수 있게 된다.
나. Webhook 기반 자동화 지원: 부르기 전에 알려주기
API 호출이 AI가 필요할 때마다 SaaS에 정보를 요청(Pull)하는 방식이라면, 웹훅은 특정 사건이 발생했을 때 SaaS가 AI에게 정보를 먼저 알려주는(Push) 방식이다. 능동적이고 자율적인 AI 에이전트에게 이는 필수적인 기능이다. 실시간 반응성이 필요한 워크플로우를 가능하게 하기 때문이다.
무엇을 해야 하는가?: '신규 고객 등록 시', '결제 완료 시', '프로젝트 상태 변경 시' 등 의미 있는 이벤트가 발생할 때마다 지정된 URL로 정형화된 데이터를 전송하는 웹훅 시스템을 제공해야 한다.
구체적인 예시 (이커머스 SaaS): AI 에이전트의 목표가 'VIP 고객이 100만원 이상 주문 시, 담당 매니저에게 즉시 슬랙 알림 보내기'라고 가정해보자. AI가 1초마다 API를 호출해 모든 주문 내역을 확인할 수는 없다. 대신, AI는 주문 완료(order_completed) 웹훅을 구독한다. 이커머스 SaaS는 주문이 완료되는 즉시 주문 정보를 담은 데이터(Payload)를 AI에게 전송하고, AI는 이 데이터를 받아 VIP 고객인지, 100만원 이상인지 판별한 뒤 슬랙 API를 호출한다. 웹훅이 없다면 이러한 실시간 자동화는 불가능에 가깝다.
다. 명확한 문서화와 예측 가능한 오류 처리: AI를 위한 사용 설명서
인간 개발자에게 API 문서는 참고 자료이지만, AI 에이전트에게 표준화된 API 문서는 그 자체로 교과서이자 실행 코드다. 마찬가지로, 예측 불가능한 오류는 AI 워크플로우 전체를 마비시키는 심각한 장애물이다.
무엇을 해야 하는가?: 모든 API 엔드포인트, 파라미터, 인증 방식, 응답 예시 등을 OpenAPI(Swagger) Specification과 같은 기계가 읽을 수 있는(Machine-readable) 표준으로 작성해야 한다. 또한,
401 Unauthorized
(인증 실패),400 Bad Request
(요청값 오류),404 Not Found
(데이터 없음) 등 표준 HTTP 상태 코드와 함께, 무엇이 문제인지 명확히 알려주는 오류 메시지를 반환해야 한다.구체적인 예시 (오류 처리):
나쁜 예시:
{"status": "failed"}
좋은 예시:JSON
{ "error_code": "INVALID_PARAMETER", "message": "The 'email' field must be a valid email address.", "request_id": "req_a1b2c3d4" }
이러한 응답을 받은 AI는 단순히 실패로 끝나는 것이 아니라, '이메일 형식이 잘못되었으니 수정을 요청하거나 다른 정보를 찾아야겠다'는 다음 행동을 스스로 계획할 수 있다.
라. 컨텍스트 친화적 응답: 다음 행동을 암시하라
성공적인 API 응답은 단순히 요청받은 결과만 툭 던져주는 것이 아니라, 연쇄적으로 이어질 AI의 다음 행동을 예측하고 그에 필요한 맥락을 함께 제공하는 것이다. 이는 전체 워크플로우의 효율성을 극적으로 높인다.
무엇을 해야 하는가?: API 응답 설계 시, '이 데이터를 받은 AI는 다음에 무엇을 하려고 할까?'를 고민해야 한다. 관련 데이터의 ID, 직접 접근 가능한 URL, 다음에 호출 가능한 관련 API 목록 등을 포함시켜 불필요한 추가 API 호출을 줄여줘야 한다.
구체적인 예시 (프로젝트 관리 SaaS): AI가 '신규 프로젝트 생성' API를 호출했을 때,
나쁜 예시:
{"success": true, "project_id": "prj-12345"}
좋은 예시 (컨텍스트 포함):JSON
{ "success": true, "project": { "id": "prj-12345", "name": "4분기 마케팅 캠페인", "dashboard_url": "<https://pm.mytool.com/prj-12345>" }, "next_actions": { "add_member_api": "/projects/prj-12345/members", "create_task_api": "/projects/prj-12345/tasks" } }
이 응답을 받은 AI는 프로젝트 ID만 아는 것이 아니라, 생성된 프로젝트 대시보드 링크를 사용자에게 바로 공유할 수 있고, 다음 단계로 멤버를 추가하거나 태스크를 생성하기 위해 어떤 API를 호출해야 하는지 즉시 알 수 있다.
이처럼 AI 시대의 SaaS는 AI 에이전트가 그저 쓸 수 있는 수많은 제품 중 하나가 아니라, 복잡한 문제를 해결하기 위해 반드시 써야만 하는 핵심 기반이 되어야 한다. 그 열쇠는 바로 AI와의 소통 능력, 즉 AI 호출 가능성에 달려 있다.
3. 보이지 않는 SaaS의 시대
미래의 업무 환경에서 사용자는 더 이상 수많은 SaaS 애플리케이션의 아이콘을 클릭하며 창을 옮겨 다니지 않을 것이다. 대신, 단일한 AI 에이전트 인터페이스에 "10월 신규 고객 대상 만족도 조사를 설계하고, 발송한 뒤, 결과를 취합해 주간 보고서에 포함시켜줘" 와 같이 목표 지향적인 명령을 내리게 된다. AI 에이전트는 이 명령을 해석해 설문조사 SaaS(예: 왈라, 타입폼, 서베이몽키 등)의 API를 호출해 설문을 생성하고, 이메일 발송 SaaS(예: 메일침프)의 API로 고객 목록을 불러와 발송한 뒤, 응답이 들어올 때마다 스프레드시트 SaaS(예: 구글 시트)에 데이터를 정리하고, 최종적으로 문서 작성 SaaS(예: 구글 독스)에 보고서를 작성한다.
이 과정에서 사용자는 개별 SaaS의 로고나 UI를 전혀 보지 못할 수도 있다. 각각의 SaaS는 마치 우리가 전등을 켤 때 발전소의 존재를 의식하지 않는 것처럼, 거대한 워크플로우의 보이지 않는 톱니바퀴로서 기능한다. 눈에 보이는 화려함 대신, AI의 지시를 얼마나 빠르고 정확하게 수행하는지가 유일한 가치 척도가 된다. 이처럼 SaaS는 사용자의 스크린에서 사라지는 대신, 모든 AI 기반 자동화의 실질적인 실행 주체로 자리매김하게 된다.
이미 시장의 선두 주자들은 이러한 '보이지 않는 SaaS'로의 전환을 명확히 보여주고 있다.
Zapier / Make (구 Integromat)
이들은 자동화 시장의 개척자로서, 수천 개의 앱을 API 레벨에서 연결하는 허브 역할을 해왔다. 이제 이들의 방대한 액션 라이브러리는 인간이 설정하는 자동화를 넘어, AI 에이전트가 사용할 수 있는 가장 강력한 도구상자가 되고 있다. AI는 Zapier를 통해 세상의 거의 모든 SaaS에 손을 뻗을 수 있게 된 것이다.
OpenAI Plugins / GPTs
이는 '보이지 않는 SaaS' 시대를 가장 명시적으로 보여주는 모델이다. 수많은 SaaS 기업들이 자체 UI가 아닌, 오직 ChatGPT와의 연결을 위해 플러그인을 개발한다. 사용자는 Expedia 플러그인을 통해 "다음 주 제주도 가는 가장 저렴한 항공편 찾아줘"라고 말할 뿐, Expedia 웹사이트에 직접 방문하지 않는다. 성공적인 플러그인은 화려한 디자인이 아니라, AI의 질문에 얼마나 정확하고 유용한 데이터를 돌려주는지에 따라 결정된다.
Notion AI
이는 한 제품 안에서 AI와 기능 인프라가 어떻게 결합되는지를 보여주는 훌륭한 사례다. Notion AI가 단순히 글만 써주는 것이 아니라 '/' 명령어를 통해 데이터베이스를 생성하고, 표를 만들고, 페이지를 요약하는 등 Notion 내부의 기능을 자유자재로 활용한다. 이는 Notion의 핵심 기능들이 이미 AI가 호출할 수 있는 내부 API처럼 모듈화되어 있음을 시사한다.
LangChain / LlamaIndex
이들은 AI 개발 프레임워크로서, 개발자들이 AI 에이전트를 만들 때 외부 SaaS API를 도구로써 쉽게 통합할 수 있도록 지원한다. 특정 SaaS가 LangChain과의 연동 라이브러리를 공식적으로 제공한다면, 이는 전 세계 AI 개발자들에게 "우리는 당신의 AI 에이전트가 사용할 준비가 된, 신뢰할 수 있는 부품입니다"라고 선언하는 것과 같다.
이러한 선도적인 흐름들은 세 가지 공통적인 전략을 가리키고 있다.
기능의 원자화
이들은 서비스를 거대한 단일 기능이 아닌, AI가 레고 블록처럼 자유롭게 조립할 수 있도록 잘게 쪼개진 원자적 기능의 API 집합으로 재구성한다. '고객 관리'라는 큰 덩어리가 아니라, '고객 검색', '연락처 추가', '태그 변경' 등 독립적으로 호출 가능한 작은 단위로 제공된다.
연결성의 최우선주의
제품 개발 로드맵의 최우선 과제가 새로운 UI/UX 개선에서 AI 에이전트와의 연결성 강화로 이동한다. API의 응답 속도를 10ms 단축하는 것이 새로운 버튼을 추가하는 것보다 중요해지며, 개발팀의 핵심 성과 지표(KPI)는 API 호출 성공률, 안정성, 문서의 명확성 등이 된다.
AI 중심의 사용성 설계
사용자 경험(UX)의 개념이 AI 경험(AIX)으로 확장된다. AI에게 좋은 경험이란, 얼마나 API 명세가 명확하여 쉽게 학습할 수 있는지, 얼마나 오류 메시지가 구체적이어서 스스로 문제를 해결할 수 있는지, 그리고 얼마나 적은 호출로 원하는 결과를 얻을 수 있는지에 의해 결정된다. 이제 SaaS 설계자는 인간의 인지 부하가 아닌, AI의 연산 부하와 워크플로우 효율성을 고민해야 한다.
4. SaaS의 미래는 사용자 제품이 아니라 AI 인프라다
"SaaS는 죽었다"는 성급한 진단이 곳곳에서 들려온다. 하지만 이는 현상의 절반만 본 것이다. SaaS는 죽지 않았다. 다만, 역사적인 대분기점에 도달했을 뿐이다. 지금까지의 성공 공식이 더 이상 유효하지 않은, 완전히 새로운 시대로의 거대한 전환이 시작된 것이다.
이 전환의 중심에는 사용자의 재정의가 있다. 지난 20년간 SaaS의 사용자는 당연히 사람이었다. 그러나 이제 우리 앞에는 지치지 않고, 24시간 일하며, 감정이 아닌 오직 효율성과 신뢰성만을 기준으로 판단하는 새로운 사용자, AI 에이전트가 등장했다. 이 새로운 사용자는 아름다운 UI에 감동하지 않으며, 편리한 UX에 감사하지 않는다. 그들은 클릭하는 대신 호출하며, 시각적 인터페이스가 아닌 기계가 읽을 수 있는 API를 찾는다.
인간 사용자는 약간의 불편함이나 느린 속도를 용납할 수 있지만, AI 에이전트는 그렇지 않는다. 수십, 수백 개의 기능을 엮어 복잡한 워크플로우를 처리하는 AI에게 하나의 API라도 불안정하거나 응답이 느리다면, 그 SaaS는 즉시 사용할 수 없는 도구로 분류되어 외면받을 것이다. 브랜드 충성도가 아닌, 오직 기능적 완벽함만이 유일한 선택 기준이 된다.
따라서 이 거대한 변화 속에서 모든 SaaS 기업은 스스로에게 단 하나의 질문을 던져야만 한다. 이 질문이 향후 10년의 생존과 성장을 가를 시금석이 될 것이다.
"우리의 SaaS는, AI 에이전트가 가장 먼저 찾고, 가장 우선적으로 호출하고 싶은 핵심 기능인가?"
이 질문에 대한 당신의 대답이 미래의 경로를 결정할 것이다. '아니오'라면, 당신의 SaaS는 점점 더 고립되는 기능의 섬이 될 위험이 있다. 아무리 강력한 기능을 가졌더라도, AI라는 거대한 대륙과 연결되지 않은 채 인간 사용자들만의 리그에 머물다 서서히 잊혀갈지 모른다.
하지만 만약 자신 있게 "네"라고 답할 수 있다면, 당신의 SaaS는 이미 다음 시대로의 진화를 시작한 것이다. 눈에 보이는 제품의 왕좌를 AI에게 내어주는 대신, 눈에 보이지 않지만 모든 것을 가능하게 하는 미래의 인프라로 거듭나게 될 것이다. 스크린 위의 화려한 스타가 되는 대신, 새로운 경제 시스템의 혈관과 신경계를 이루는, 대체 불가능한 존재가 되는 길이다.
당신의 SaaS는 AI 시대의 가장 신뢰받는 부품이 될 준비가 되었는가? 그 대답에 모든 미래가 있다.
1. 제품에서 인프라로: SaaS의 근본적 전환
과거 SaaS의 성공 방정식은 명확했다. 사용자의 클릭 하나하나를 해부하고 최적의 경로를 설계하는 것, 즉 인간의 인지적, 행동적 특성에 기반한 사용자 경험(UX)을 극대화하는 것이었다. Salesforce, Slack, Notion과 같은 거인들은 사용자가 더 적은 노력으로 더 많은 것을 성취할 수 있도록 돕는 화려하고 직관적인 인터페이스(UI)를 경쟁력의 원천으로 삼았다. 이 시대의 SaaS는 그 자체로 완결된 디지털 작업 공간이었다. 사용자는 특정 과업을 해결하기 위해 해당 SaaS에 로그인하여, 그 안에서 제공하는 기능의 조합을 통해 원하는 결과를 얻어냈다.
그러나 AI, 특히 스스로 사고하고 실행하는 AI 에이전트(AI Agent)의 등장은 이 모든 전제를 뿌리부터 뒤흔들고 있다. 이제 SaaS의 주된 사용자는 모니터 앞에서 마우스를 움직이는 사람이 아닐 수도 있다. 대신, 복잡한 목표(예를 들면 "이번 분기 예상 매출이 가장 높은 잠재고객 10곳을 찾아내고, 맞춤형 영업 이메일 초안을 작성한 뒤, 내일 오전 미팅 일정을 조율해줘")를 부여받은 AI 에이전트가 그 자리를 차지하게 될 것이다. 이 새로운 사용자는 UI를 보지 않으며, 클릭 대신 API 호출로 소통한다. 따라서 SaaS의 역할은 인간을 위한 친절한 제품에서, AI 에이전트가 작업을 수행하기 위해 의존하는 견고하고 예측 가능한 기능 인프라로의 근본적인 전환을 맞이하고 있다.
이러한 전환은 단순히 기존 기능을 API로 포장하는 수준을 넘어선다. 이는 AI가 명확하게 이해하고, 예측하며, 호출할 수 있는 구조를 갖추는 것을 의미한다. 예를 들어, AI 에이전트가 고객 정보를 업데이트해야 할 때, 하나의 거대한 updateCustomer
API를 호출하는 것이 아니다. 대신, findCustomerByName
, getCustomerDetails
, updateSpecificField
, addInteractionLog
와 같이 잘게 쪼개진 원자적 기능들의 조합을 통해 과업을 수행한다. 각 기능의 이름과 필요한 정보(Parameters)는 AI가 해석할 수 있을 만큼 명확해야 하며, 그 결과는 일관된 데이터 구조로 반환되어야 한다.
결과적으로 SaaS의 가치를 평가하는 척도는 달라지고 있다. 얼마나 아름다운 UI를 가졌는가, 얼마나 편리한 UX 동선을 설계했는가는 더 이상 핵심이 아니다. 이제 경쟁력은 눈에 보이지 않는 영역에서 판가름 난다.
API의 신뢰성과 속도: AI 에이전트의 워크플로우를 지연 없이 처리할 수 있는가?
데이터의 정합성과 품질: AI가 신뢰하고 가공할 수 있는 깨끗한 데이터를 제공하는가?
맥락(Context)의 풍부함: 단순히 요청된 결과값만 돌려주는 것이 아니라, AI가 다음 행동을 추론하는 데 필요한 맥락적 정보를 함께 제공하는가? (예를 들어 일정 등록 API가 단순히 "성공"을 반환하는 대신, "생성된 일정 ID, 참여자들의 참석 가능 여부, 화상회의 링크"를 함께 돌려주는 것)
이처럼 미래의 SaaS는 사용자의 눈에는 보이지 않는 무대 뒤의 스태프와 같을 것이다. 화려한 조명을 받는 주연 배우는 AI 에이전트이지만, 그 배우가 최고의 연기를 펼칠 수 있도록 모든 소품과 장치를 정확한 타이밍에 제공하는 것, 그것이 바로 인프라로 진화한 SaaS의 새로운 사명이자 본질이라고 할 수 있다.
2. 생존 전략으로서의 AI 호출 가능성
많은 SaaS 기업들이 경쟁적으로 자체 AI 기능을 선보이고 있다. 문서 자동 요약, 데이터 기반 추천, 이미지 자동 태깅 등은 이제 사용자들에게 익숙한 기능이 되었다. 이는 분명 의미 있는 발전이지만, 다가오는 AI 시대의 본질적인 변화를 대비하기엔 부족하다. 이러한 기능들은 대부분 해당 SaaS라는 닫힌 생태계 안에서만 작동하며, 인간 사용자의 편의성을 높이는 데 초점이 맞춰져 있다.
진정으로 중요한 질문은 내부가 아닌 외부를 향해 있다. "우리의 SaaS는, 외부의 AI 에이전트가 자신의 목적을 달성하기 위한 도구로써 자유롭게 호출할 수 있도록 설계되어 있는가?"
AI 시대에 지속 가능한 성장을 이룰 SaaS는 단순히 AI 기능을 품은 똑똑한 제품이 아니다. 여러 AI와 서비스의 워크플로우를 관통하는 AI가 기꺼이 부르는 핵심 부품이다. 이를 위한 구체적인 조건들은 다음과 같다.
가. Function Calling 표준 대응: AI의 언어로 말하라
AI 에이전트(GPT, Gemini 등)는 스스로 API를 호출할 수 없다. 대신 'Function Calling'이라는 표준화된 메뉴판(명세서)을 읽고, 어떤 기능을 사용할 수 있는지, 각 기능을 사용하려면 어떤 정보가 필요한지를 학습한다. 만약 우리 SaaS의 API가 이 메뉴판 규격에 맞지 않다면, AI에게 우리 서비스는 존재하지 않는 것이나 마찬가지다.
무엇을 해야 하는가?: OpenAI의 Function Calling, Google의 Tool aalling 등에 사용되는 JSON Schema 형식에 맞춰 API의 기능, 파라미터, 반환값 등을 명확하게 정의해야 한다.
구체적인 예시 (CRM SaaS):
나쁜 예시:
https://api.mycrm.com/v1/process?action=new_lead&name=...
**좋은 예시 (AI가 이해하는 명세):**JSON
{ "name": "create_new_lead", "description": "새로운 잠재고객 정보를 시스템에 등록합니다.", "parameters": { "type": "object", "properties": { "company_name": {"type": "string", "description": "고객의 소속 회사명"}, "contact_person": {"type": "string", "description": "담당자 이름"}, "email": {"type": "string", "description": "담당자의 이메일 주소"} }, "required": ["company_name", "contact_person"] } }
AI 에이전트는 이 명세를 보고 "ACME사의 제인 도우를 잠재고객으로 등록해줘"라는 자연어 명령을
create_new_lead(company_name="ACME", contact_person="Jane Doe", ...)
와 같은 정확한 함수 호출로 변환할 수 있게 된다.
나. Webhook 기반 자동화 지원: 부르기 전에 알려주기
API 호출이 AI가 필요할 때마다 SaaS에 정보를 요청(Pull)하는 방식이라면, 웹훅은 특정 사건이 발생했을 때 SaaS가 AI에게 정보를 먼저 알려주는(Push) 방식이다. 능동적이고 자율적인 AI 에이전트에게 이는 필수적인 기능이다. 실시간 반응성이 필요한 워크플로우를 가능하게 하기 때문이다.
무엇을 해야 하는가?: '신규 고객 등록 시', '결제 완료 시', '프로젝트 상태 변경 시' 등 의미 있는 이벤트가 발생할 때마다 지정된 URL로 정형화된 데이터를 전송하는 웹훅 시스템을 제공해야 한다.
구체적인 예시 (이커머스 SaaS): AI 에이전트의 목표가 'VIP 고객이 100만원 이상 주문 시, 담당 매니저에게 즉시 슬랙 알림 보내기'라고 가정해보자. AI가 1초마다 API를 호출해 모든 주문 내역을 확인할 수는 없다. 대신, AI는 주문 완료(order_completed) 웹훅을 구독한다. 이커머스 SaaS는 주문이 완료되는 즉시 주문 정보를 담은 데이터(Payload)를 AI에게 전송하고, AI는 이 데이터를 받아 VIP 고객인지, 100만원 이상인지 판별한 뒤 슬랙 API를 호출한다. 웹훅이 없다면 이러한 실시간 자동화는 불가능에 가깝다.
다. 명확한 문서화와 예측 가능한 오류 처리: AI를 위한 사용 설명서
인간 개발자에게 API 문서는 참고 자료이지만, AI 에이전트에게 표준화된 API 문서는 그 자체로 교과서이자 실행 코드다. 마찬가지로, 예측 불가능한 오류는 AI 워크플로우 전체를 마비시키는 심각한 장애물이다.
무엇을 해야 하는가?: 모든 API 엔드포인트, 파라미터, 인증 방식, 응답 예시 등을 OpenAPI(Swagger) Specification과 같은 기계가 읽을 수 있는(Machine-readable) 표준으로 작성해야 한다. 또한,
401 Unauthorized
(인증 실패),400 Bad Request
(요청값 오류),404 Not Found
(데이터 없음) 등 표준 HTTP 상태 코드와 함께, 무엇이 문제인지 명확히 알려주는 오류 메시지를 반환해야 한다.구체적인 예시 (오류 처리):
나쁜 예시:
{"status": "failed"}
좋은 예시:JSON
{ "error_code": "INVALID_PARAMETER", "message": "The 'email' field must be a valid email address.", "request_id": "req_a1b2c3d4" }
이러한 응답을 받은 AI는 단순히 실패로 끝나는 것이 아니라, '이메일 형식이 잘못되었으니 수정을 요청하거나 다른 정보를 찾아야겠다'는 다음 행동을 스스로 계획할 수 있다.
라. 컨텍스트 친화적 응답: 다음 행동을 암시하라
성공적인 API 응답은 단순히 요청받은 결과만 툭 던져주는 것이 아니라, 연쇄적으로 이어질 AI의 다음 행동을 예측하고 그에 필요한 맥락을 함께 제공하는 것이다. 이는 전체 워크플로우의 효율성을 극적으로 높인다.
무엇을 해야 하는가?: API 응답 설계 시, '이 데이터를 받은 AI는 다음에 무엇을 하려고 할까?'를 고민해야 한다. 관련 데이터의 ID, 직접 접근 가능한 URL, 다음에 호출 가능한 관련 API 목록 등을 포함시켜 불필요한 추가 API 호출을 줄여줘야 한다.
구체적인 예시 (프로젝트 관리 SaaS): AI가 '신규 프로젝트 생성' API를 호출했을 때,
나쁜 예시:
{"success": true, "project_id": "prj-12345"}
좋은 예시 (컨텍스트 포함):JSON
{ "success": true, "project": { "id": "prj-12345", "name": "4분기 마케팅 캠페인", "dashboard_url": "<https://pm.mytool.com/prj-12345>" }, "next_actions": { "add_member_api": "/projects/prj-12345/members", "create_task_api": "/projects/prj-12345/tasks" } }
이 응답을 받은 AI는 프로젝트 ID만 아는 것이 아니라, 생성된 프로젝트 대시보드 링크를 사용자에게 바로 공유할 수 있고, 다음 단계로 멤버를 추가하거나 태스크를 생성하기 위해 어떤 API를 호출해야 하는지 즉시 알 수 있다.
이처럼 AI 시대의 SaaS는 AI 에이전트가 그저 쓸 수 있는 수많은 제품 중 하나가 아니라, 복잡한 문제를 해결하기 위해 반드시 써야만 하는 핵심 기반이 되어야 한다. 그 열쇠는 바로 AI와의 소통 능력, 즉 AI 호출 가능성에 달려 있다.
3. 보이지 않는 SaaS의 시대
미래의 업무 환경에서 사용자는 더 이상 수많은 SaaS 애플리케이션의 아이콘을 클릭하며 창을 옮겨 다니지 않을 것이다. 대신, 단일한 AI 에이전트 인터페이스에 "10월 신규 고객 대상 만족도 조사를 설계하고, 발송한 뒤, 결과를 취합해 주간 보고서에 포함시켜줘" 와 같이 목표 지향적인 명령을 내리게 된다. AI 에이전트는 이 명령을 해석해 설문조사 SaaS(예: 왈라, 타입폼, 서베이몽키 등)의 API를 호출해 설문을 생성하고, 이메일 발송 SaaS(예: 메일침프)의 API로 고객 목록을 불러와 발송한 뒤, 응답이 들어올 때마다 스프레드시트 SaaS(예: 구글 시트)에 데이터를 정리하고, 최종적으로 문서 작성 SaaS(예: 구글 독스)에 보고서를 작성한다.
이 과정에서 사용자는 개별 SaaS의 로고나 UI를 전혀 보지 못할 수도 있다. 각각의 SaaS는 마치 우리가 전등을 켤 때 발전소의 존재를 의식하지 않는 것처럼, 거대한 워크플로우의 보이지 않는 톱니바퀴로서 기능한다. 눈에 보이는 화려함 대신, AI의 지시를 얼마나 빠르고 정확하게 수행하는지가 유일한 가치 척도가 된다. 이처럼 SaaS는 사용자의 스크린에서 사라지는 대신, 모든 AI 기반 자동화의 실질적인 실행 주체로 자리매김하게 된다.
이미 시장의 선두 주자들은 이러한 '보이지 않는 SaaS'로의 전환을 명확히 보여주고 있다.
Zapier / Make (구 Integromat)
이들은 자동화 시장의 개척자로서, 수천 개의 앱을 API 레벨에서 연결하는 허브 역할을 해왔다. 이제 이들의 방대한 액션 라이브러리는 인간이 설정하는 자동화를 넘어, AI 에이전트가 사용할 수 있는 가장 강력한 도구상자가 되고 있다. AI는 Zapier를 통해 세상의 거의 모든 SaaS에 손을 뻗을 수 있게 된 것이다.
OpenAI Plugins / GPTs
이는 '보이지 않는 SaaS' 시대를 가장 명시적으로 보여주는 모델이다. 수많은 SaaS 기업들이 자체 UI가 아닌, 오직 ChatGPT와의 연결을 위해 플러그인을 개발한다. 사용자는 Expedia 플러그인을 통해 "다음 주 제주도 가는 가장 저렴한 항공편 찾아줘"라고 말할 뿐, Expedia 웹사이트에 직접 방문하지 않는다. 성공적인 플러그인은 화려한 디자인이 아니라, AI의 질문에 얼마나 정확하고 유용한 데이터를 돌려주는지에 따라 결정된다.
Notion AI
이는 한 제품 안에서 AI와 기능 인프라가 어떻게 결합되는지를 보여주는 훌륭한 사례다. Notion AI가 단순히 글만 써주는 것이 아니라 '/' 명령어를 통해 데이터베이스를 생성하고, 표를 만들고, 페이지를 요약하는 등 Notion 내부의 기능을 자유자재로 활용한다. 이는 Notion의 핵심 기능들이 이미 AI가 호출할 수 있는 내부 API처럼 모듈화되어 있음을 시사한다.
LangChain / LlamaIndex
이들은 AI 개발 프레임워크로서, 개발자들이 AI 에이전트를 만들 때 외부 SaaS API를 도구로써 쉽게 통합할 수 있도록 지원한다. 특정 SaaS가 LangChain과의 연동 라이브러리를 공식적으로 제공한다면, 이는 전 세계 AI 개발자들에게 "우리는 당신의 AI 에이전트가 사용할 준비가 된, 신뢰할 수 있는 부품입니다"라고 선언하는 것과 같다.
이러한 선도적인 흐름들은 세 가지 공통적인 전략을 가리키고 있다.
기능의 원자화
이들은 서비스를 거대한 단일 기능이 아닌, AI가 레고 블록처럼 자유롭게 조립할 수 있도록 잘게 쪼개진 원자적 기능의 API 집합으로 재구성한다. '고객 관리'라는 큰 덩어리가 아니라, '고객 검색', '연락처 추가', '태그 변경' 등 독립적으로 호출 가능한 작은 단위로 제공된다.
연결성의 최우선주의
제품 개발 로드맵의 최우선 과제가 새로운 UI/UX 개선에서 AI 에이전트와의 연결성 강화로 이동한다. API의 응답 속도를 10ms 단축하는 것이 새로운 버튼을 추가하는 것보다 중요해지며, 개발팀의 핵심 성과 지표(KPI)는 API 호출 성공률, 안정성, 문서의 명확성 등이 된다.
AI 중심의 사용성 설계
사용자 경험(UX)의 개념이 AI 경험(AIX)으로 확장된다. AI에게 좋은 경험이란, 얼마나 API 명세가 명확하여 쉽게 학습할 수 있는지, 얼마나 오류 메시지가 구체적이어서 스스로 문제를 해결할 수 있는지, 그리고 얼마나 적은 호출로 원하는 결과를 얻을 수 있는지에 의해 결정된다. 이제 SaaS 설계자는 인간의 인지 부하가 아닌, AI의 연산 부하와 워크플로우 효율성을 고민해야 한다.
4. SaaS의 미래는 사용자 제품이 아니라 AI 인프라다
"SaaS는 죽었다"는 성급한 진단이 곳곳에서 들려온다. 하지만 이는 현상의 절반만 본 것이다. SaaS는 죽지 않았다. 다만, 역사적인 대분기점에 도달했을 뿐이다. 지금까지의 성공 공식이 더 이상 유효하지 않은, 완전히 새로운 시대로의 거대한 전환이 시작된 것이다.
이 전환의 중심에는 사용자의 재정의가 있다. 지난 20년간 SaaS의 사용자는 당연히 사람이었다. 그러나 이제 우리 앞에는 지치지 않고, 24시간 일하며, 감정이 아닌 오직 효율성과 신뢰성만을 기준으로 판단하는 새로운 사용자, AI 에이전트가 등장했다. 이 새로운 사용자는 아름다운 UI에 감동하지 않으며, 편리한 UX에 감사하지 않는다. 그들은 클릭하는 대신 호출하며, 시각적 인터페이스가 아닌 기계가 읽을 수 있는 API를 찾는다.
인간 사용자는 약간의 불편함이나 느린 속도를 용납할 수 있지만, AI 에이전트는 그렇지 않는다. 수십, 수백 개의 기능을 엮어 복잡한 워크플로우를 처리하는 AI에게 하나의 API라도 불안정하거나 응답이 느리다면, 그 SaaS는 즉시 사용할 수 없는 도구로 분류되어 외면받을 것이다. 브랜드 충성도가 아닌, 오직 기능적 완벽함만이 유일한 선택 기준이 된다.
따라서 이 거대한 변화 속에서 모든 SaaS 기업은 스스로에게 단 하나의 질문을 던져야만 한다. 이 질문이 향후 10년의 생존과 성장을 가를 시금석이 될 것이다.
"우리의 SaaS는, AI 에이전트가 가장 먼저 찾고, 가장 우선적으로 호출하고 싶은 핵심 기능인가?"
이 질문에 대한 당신의 대답이 미래의 경로를 결정할 것이다. '아니오'라면, 당신의 SaaS는 점점 더 고립되는 기능의 섬이 될 위험이 있다. 아무리 강력한 기능을 가졌더라도, AI라는 거대한 대륙과 연결되지 않은 채 인간 사용자들만의 리그에 머물다 서서히 잊혀갈지 모른다.
하지만 만약 자신 있게 "네"라고 답할 수 있다면, 당신의 SaaS는 이미 다음 시대로의 진화를 시작한 것이다. 눈에 보이는 제품의 왕좌를 AI에게 내어주는 대신, 눈에 보이지 않지만 모든 것을 가능하게 하는 미래의 인프라로 거듭나게 될 것이다. 스크린 위의 화려한 스타가 되는 대신, 새로운 경제 시스템의 혈관과 신경계를 이루는, 대체 불가능한 존재가 되는 길이다.
당신의 SaaS는 AI 시대의 가장 신뢰받는 부품이 될 준비가 되었는가? 그 대답에 모든 미래가 있다.
Continue Reading
