한 줄 정의

SaaS는 제공자가 클라우드에서 애플리케이션을 운영하고, 사용자는 브라우저나 API로 그 소프트웨어를 쓰는 제공 방식이야. NIST의 정의로 보면 사용자는 제공자의 애플리케이션을 쓰지만, 네트워크, 서버, OS, 스토리지 같은 밑단 인프라는 직접 관리하지 않아.

그래서 SaaS는 “AI 기능이 있다”는 말보다 운영 책임을 가르는 말에 가까워. 누가 앱을 배포하고, 누가 업데이트와 보안 패치를 하고, 데이터가 어느 서버에 남는지 보는 거야. 이걸 놓치면 API 서비스, self-host 도구, open-weight 모델을 전부 같은 구독 앱처럼 읽게 돼.

어떻게 작동하나

SaaS에서는 제공자가 애플리케이션 소프트웨어와 기반 인프라를 운영해. GSA는 이메일, 캘린더, 오피스 도구, CRM, ERP, 문서 관리처럼 사용자가 웹으로 접속해 쓰는 완성형 업무 앱을 예로 들어. 사용자는 서버를 설치하지 않고 계정, 좌석 수, 권한, 설정값을 관리하는 쪽에 더 가까워.

API가 붙으면 경계가 조금 헷갈려져. 어떤 서비스가 REST API나 webhook을 제공해도 API 자체가 SaaS라는 뜻은 아니야. API는 호출 규약이고, SaaS는 애플리케이션을 제공자가 운영하는 방식이야. 예를 들어 자동화 서버가 SaaS 계정의 API를 호출하면, 자동화 흐름은 내 서버에서 돌더라도 데이터와 권한 일부는 SaaS 쪽에 걸린다.

AI 쪽에서는 open-weight 모델과 비교하면 더 선명해져. OpenAI Privacy Filter는 2026년 4월 22일 공개된 개인정보 탐지·마스킹 모델이고, Hugging Face에는 Apache 2.0 라이선스의 openai/privacy-filter로 올라와 있어. 1.5B total parameters, 50M active parameters, 128,000 token context window 같은 숫자는 모델 구성요소의 성격을 말해. 이 모델을 누군가 호스팅해서 웹 서비스로 팔면 그 서비스는 SaaS가 될 수 있지만, 모델 파일 자체는 SaaS가 아니야.

왜 중요한가

SaaS를 제대로 가르면 도입 질문이 달라져. “이 기능이 있나?”에서 끝나지 않고 “이 데이터를 외부 제공자에게 맡겨도 되나?”, “사용자 계정과 권한을 어떻게 회수하나?”, “장애와 로그를 누가 설명하나?”로 넘어가게 돼. AI 업무자동화에서는 이 차이가 꽤 커. Agent가 Gmail, Slack, CRM, 결제 시스템 같은 SaaS 계정을 대신 다루기 시작하면, 단순 구독 앱이 아니라 권한이 붙은 실행 환경이 된다.

Activepieces나 n8n 같은 자동화 도구를 볼 때도 같은 기준이 필요해. 관리형 클라우드로 쓰면 SaaS에 가깝고, 직접 서버에 설치하면 업데이트, queue, secret, backup을 직접 맡는 self-host 운영이 돼. 같은 제품 이름이어도 실행 위치가 바뀌면 비용과 보안 책임이 같이 달라져.

개인정보 흐름에서도 SaaS 여부는 먼저 봐야 해. OpenAI는 Privacy Filter가 8개 privacy span category를 감지하고 한 번의 forward pass로 긴 입력을 처리한다고 설명하지만, 동시에 익명화 도구나 compliance certification은 아니라고 제한해. 이건 좋은 경계야. 로컬에서 먼저 마스킹하고 SaaS API로 보내는 구조와, 원문 데이터를 바로 SaaS에 올리는 구조는 위험이 다르다.

주의해서 볼 점

첫째, “클라우드에서 쓴다”와 “SaaS다”를 바로 같게 보면 안 돼. NIST SP 500-322는 클라우드 서비스를 SaaS, PaaS, IaaS로 나눠 분류하려는 문서야. 같은 클라우드라도 제공되는 능력이 완성형 애플리케이션인지, 개발 플랫폼인지, 서버·스토리지 같은 인프라인지에 따라 책임선이 달라져.

둘째, SaaS가 보안 책임을 없애 주지는 않아. 제공자가 인프라와 패치를 맡아도 조직은 계정 생명주기, SSO, OAuth scope, 퇴사자 권한 회수, 로그 보관, 데이터 삭제 요청을 봐야 해. Agent Identity가 필요한 이유도 여기서 나와. 에이전트가 누구 권한으로 SaaS API를 호출했는지 남지 않으면 사고가 났을 때 설명하기 어렵다.

셋째, open-source나 open-weight라는 말과 SaaS를 섞으면 판단이 흐려져. Privacy Filter처럼 로컬 실행이 가능한 구성요소는 SaaS 안으로 들어갈 수도 있고, SaaS 밖에서 데이터를 줄이는 전처리 단계가 될 수도 있어. 중요한 건 이름표가 아니라 실제 실행 위치와 업데이트 책임이야.

넷째, 가격표만 보지 말고 데이터 경로를 같이 봐야 해. 좌석당 월 과금이나 사용량 과금은 구매 판단에 필요하지만, AI 워크플로에서는 프롬프트, 파일, 로그, tool output이 어느 SaaS에 남는지가 더 먼저 문제될 때가 있어. 특히 고객 데이터나 비밀값이 섞이면 “구독하면 끝”이 아니라 접근권한과 삭제 절차부터 확인해야 해.

관련 용어

  • activepieces: 관리형 SaaS 자동화로 쓸지, 직접 서버에 설치하는 자동화 런타임으로 볼지 비교할 때 바로 맞닿아.
  • n8n: SaaS 계정과 내부 API를 워크플로로 묶는 도구라서, 클라우드 사용과 self-host 운영의 차이를 같이 보게 해.
  • API: SaaS 앱이 외부 서비스와 연결되는 호출 규약이지만, API 자체가 곧 SaaS라는 뜻은 아니야.
  • OAuth: SaaS 계정 권한을 외부 앱이나 agent에게 넘길 때 scope, token, revoke 경로를 따져 보게 해.
  • agent-identity: agent가 SaaS 계정으로 작업할 때 누구의 권한인지, 어떤 감사 로그를 남기는지 가르는 기준이야.
  • privacy-filter: SaaS에 원문 데이터를 바로 보내기 전 로컬 마스킹을 넣을 수 있는 대비 사례야.