SaaS는 죽지 않았다. 죽은 것은 획일성이다

게시일: 2026년 10월 21일 | 원문 작성일: 2026년 8월 25일 | 저자: Chad Fowler | 출처: The Phoenix Architecture | 원문 보기

요즘 다들 SaaS는 죽었다고 말하고 싶어 해요.

Klarna가 Salesforce를 걷어 냈다는 이야기T1가 퍼진 건 분위기에 딱 맞아떨어졌기 때문이에요. “CRM을 대체했다”와 “그 밑의 데이터를 통합했다” 사이의 경계가 정확히 어디였는지는 상관없었죠. 에이전트는 예전에 사람이 애플리케이션을 클릭하며 하던 일을 하기 시작했어요. 좌석(seat)이 더는 일을 하지 않게 되면, 좌석당 가격 모델은 위태로워 보일 수밖에 없어요.

Gartner조차 이제 2030년까지 기업용 애플리케이션 지출 가운데 최대 2,340억 달러, 기업 SaaS 지출의 약 20퍼센트가 이른바 “에이전틱 차익 거래(agentic arbitrage)”에 노출될 수 있다고 추정해요.

그런데 Gartner 스스로도 종말론에는 선을 그어요. 다가오는 변화는 종말이라기보다 탈바꿈이라는 거예요.

저도 그렇게 생각해요.

그리고 SaaS가 무엇으로 바뀔지, 좀 더 구체적으로 예측해 보고 싶어요.

기업들은 앞으로도 다른 기업에 돈을 내고 중요한 소프트웨어를 맡길 거예요. 호스팅하고, 보안을 지키고, 운영하고, 권위 있는 데이터를 관리하고, 규제 변화를 따라가고, 외부 네트워크에 연결하고, 뭔가 고장 나면 전화를 받아 주는 일 말이에요.

반면 살아남을지 훨씬 불확실한 건, 서로 다른 만 개의 회사가 거의 같은 애플리케이션을 써야 한다는 전제예요.

다음 세대의 SaaS 회사는 서비스 하나 위에서 서로 다른 애플리케이션 만 개를 돌릴지도 몰라요.

• • •

변형이 비쌌기 때문에 소프트웨어를 표준화했다

여러분의 회사에 독특한 영업 프로세스가 있다고 해 보죠.

20년 전이라면 현실적인 선택지는 둘이었어요.

수천 개 회사를 위해 설계된 CRM을 사서, 우리가 일하는 방식에 대충 맞을 때까지 설정을 만지는 것.

아니면 직접 만드는 것.

두 번째 선택지는 그럴듯하게 들려요. 누군가 “직접 만든다”가 무슨 뜻인지 계산해 보기 전까지는요. 개발자, 디자이너, 프로덕트 관리, 보안, 호스팅, 연동, 업그레이드, 마이그레이션, 고객 지원, 당직 대응, 그리고 몇 년에 걸친 유지보수.

수백만 달러를 들여 Salesforce가 이미 하는 일의 열등한 버전을 만들고, 그걸 영원히 떠안는 셈이에요.

당연히 Salesforce를 샀죠.

같은 논리가 기업 전반에서 반복됐어요. 기업들은 SAP, Workday, Jira, ServiceNow, Oracle을 비롯해 수백 가지 제품을 사들였고, 그러고는 조금씩 자신을 소프트웨어에 맞춰 바꿨어요.

CRM에는 영업 기회, 단계, 계정, 연락처, 예측이라는 개념이 있어요. 프로젝트 관리 시스템에는 이슈, 에픽, 스프린트, 상태, 워크플로가 있고요. 인사 시스템에는 직원, 관리자, 조직, 결재, 평가에 대한 나름의 모델이 있어요.

좋은 추상화일 수 있어요. 그래도 여전히 선택이에요.

시간이 지나면 소프트웨어 벤더가 내린 선택이 그걸 쓰는 조직의 언어가 돼요.

우리는 흔히 이걸 표준화나 모범 사례라고 불러요. 실제로 그럴 때도 있어요.

수십 년 동안 그 거래는 너무나 당연히 옳았어요.

제대로 된 소프트웨어 제품은 첫 카피를 만드는 데 엄청난 돈이 들었어요. 만 번째 카피에는 거의 비용이 들지 않았고요.

SaaS는 그 비대칭을 지금까지 나온 비즈니스 모델 가운데 손꼽히게 좋은 모델로 바꿔 놓았어요.

• • •

“커스터마이즈하지 말고 설정하라”는 경제 법칙이었다

SaaS가 한 일은 애플리케이션을 브라우저로 옮긴 데서 그치지 않아요.

SaaS 덕분에 획일성은 운영 면에서도 값진 것이 됐어요.

돌아가는 시스템은 벤더가 통제했어요. 모두를 한꺼번에 업그레이드할 수 있었어요. 보안 패치는 중앙에서 배포됐고, 기능은 쉬지 않고 출시됐어요. 벤더는 더 이상 알아볼 수 없을 만큼 뜯어고친 고객 설치본 수백 개를 지원하지 않아도 됐어요.

커스터마이즈는 포크를 낳았어요.

고객이 소프트웨어를 바꿔요. 그다음 벤더가 소프트웨어를 바꿔요. 누군가는 둘을 맞춰야 해요.

이걸 몇 년 되풀이하면 고객은 아무도 온전히 이해하지 못하는 수정 사항 더미를 안은 채 아주 오래된 릴리스에 발이 묶여요.

설정은 변형을 제한해서 그 문제를 풀었어요. 무엇이 달라도 되는지는 벤더가 미리 정했어요. 필드, 권한, 워크플로 상태, 플러그인, 연동, 기능 플래그 같은 것들이요.

고객은 서로 다를 수 있었지만, 제품이 예상한 방식으로만 다를 수 있었어요.

훌륭한 타협이었어요.

하지만 소프트웨어 공학의 법칙은 아니었어요.

“커스터마이즈하지 말고 설정하라”는 코드가 비쌀 때의 대처법이었어요.

고객 전용 소프트웨어를 만드는 일도, 그걸 다시 만드는 일도 싸진다면 그 거래는 달라져요.

• • •

이제 소프트웨어는 시장이 없어도 존재할 자격이 있다

쉰 명이 쓰는 사내 결재 프로세스를 떠올려 보세요.

두 번의 인수합병, 세 곳의 관할 지역, 오래전의 규제 당국 합의, 그리고 제정신인 프로덕트 매니저라면 처음부터 절대 설계하지 않았을 권한 구조 때문에 그 회사에만 있는 독특한 프로세스예요.

오늘날 그 회사는 아마 범용 워크플로 플랫폼을 사서 몇 달 동안 설정할 거예요.

이제 작은 사내 팀이 며칠 만에 그 목적에 딱 맞는 애플리케이션을 만들 수 있다고 상상해 보세요.

회사의 ID 시스템은 이미 있어요. 필요한 데이터는 안정적인 인터페이스로 꺼내 쓸 수 있어요. 권한 규칙은 명시돼 있어요. 호스팅, 관측성, 보안, 배포는 공유 플랫폼이 맡아요.

이 애플리케이션은 다른 고객 오천 곳의 마음을 끌 필요가 없어요.

로드맵도 필요 없어요.

전체 시장 규모(TAM)도 필요 없어요.

이 쉰 명의 이 문제만 풀면 돼요.

그러면 경제적으로 만들 만한 소프트웨어의 범위가 달라져요.

소프트웨어 역사 대부분의 기간 동안 애플리케이션은 제작 비용만큼의 값어치를 증명해야 했어요. 충분히 많은 사람이 대체로 같은 것을 필요로 하거나, 맞춤 개발을 정당화할 만큼 중요한 문제여야 했죠.

제작 비용이 떨어지면 최소 기능 시장(minimum viable market)이 줄어들어요.

조직 하나. 부서 하나. 결국 어떤 소프트웨어는 사람 한 명.

어느 보험사가 내년에 아주 구체적인 사내 애플리케이션 스무 개를 생성하고, 그중 어느 것도 외부에 공개하지 않을 수 있어요. 그중 세 개가 기존 SaaS 계약을 대체한다면, 세상에는 소프트웨어가 더 많아지는 동시에 상용 소프트웨어 지출은 줄어들어요.

우리가 겪어 온 소프트웨어 경제와는 아주 다른 역학이에요.

• • •

사라지는 것은 SaaS가 아니다

“SaaS는 죽었다”는 말에는 여러 가지 생각이 한데 묶여 있어요.

소프트웨어를 다른 누군가가 호스팅한다. 벤더가 운영하고 보안을 지킨다. 벤더가 권위 있는 데이터를 관리하고, 규제 로직을 갱신하고, 마이그레이션과 연동을 처리하고, 가용성과 고객 지원을 책임진다. 고객은 그 역량에 대해 기간 단위로 돈을 낸다.

그리고 역사적으로는 수천 명의 고객이 거의 같은 애플리케이션을 써 왔다는 점도요.

생성 비용이 싸지면서 가장 크게 흔들리는 건 바로 이 마지막 속성이에요.

에이전트가 결제 페이지를 만들어 줄 수 있다고 해서 제가 결제 네트워크를 직접 운영하고 싶지는 않아요.

에이전트가 급여 화면을 만들어 줄 수 있다고 해서 세율표를 직접 관리하고 싶지도 않고요.

모든 병원이 의료 기록에 대한 권위 있는 해석을 제각기 생성하는 것도 원하지 않아요.

현대 SaaS가 지닌 가치의 상당 부분은 눈에 보이는 애플리케이션과 놀라울 만큼 관계가 없어요.

그 가치는 데이터, 신뢰, 네트워크, 규제 준수, 운영 책임, 도메인 지식, 감사 가능성, 쌓여 온 이력, 그리고 현실이 복잡해졌을 때 책임지는 누군가에 있어요.

AI는 서비스로 들어가는 인터페이스를 없애면서, 그 밑에 있는 서비스의 수요는 키울 수 있어요.

그래서 좌석이나 화면이 사라진다고 벤더가 사라지는 건 아니에요.

• • •

가치는 처음부터 좌석에 있지 않았다

이건 가격 책정에도 중요해요.

전통적인 SaaS 가격은 사람이 애플리케이션을 쓰는 방식에 깔끔하게 대응하는 경우가 많아요.

좌석당. 사용자당. 상담원당.

그게 통한 건 애플리케이션이 일이 벌어지는 곳이면서 동시에 벤더가 가치를 거둬들이는 곳이었기 때문이에요.

에이전트가 등장하면서 그 연결이 느슨해져요.

직원이 급여 화면을 더 이상 열지 않는다고 급여 서비스 회사의 가치가 사라지지는 않아요. 고객은 여전히 급여를 정확히 계산하고, 세법 변화를 따라가고, 돈을 송금하고, 정부에 신고하고, 기록을 보관하고, 운영 책임을 지는 일에 돈을 내고 있어요.

그렇다면 그 회사는 점점 처리한 직원 수, 송금한 금액, 완료한 신고 건수, 지원하는 관할 지역 수, 보장한 결과를 기준으로 돈을 받게 될지도 몰라요.

결제 회사는 이미 좌석이 아니라 거래를 기준으로 요금을 매겨요. 데이터 회사는 정보, 권리, 양, 사용량을 기준으로 매길 수 있어요. 보안 회사는 보호하는 자산, 워크로드, ID, 리스크를 기준으로 매길 수 있고요.

기반(substrate) 회사는 자신이 실제로 공급하는 것에 값을 매겨야 해요.

화면 접근권을 팔아 먹고사는 SaaS 회사에게는 고통스러운 일이 될 거예요. 에이전트에게는 그 화면이 더 이상 필요 없으니까요.

진짜 가치가 줄곧 그 화면 뒤에 숨어 있던 회사에게는 아주 좋은 일일 수 있고요.

• • •

미래는 대량 맞춤형 SaaS다

새 모델을 가장 쉽게 그려 보는 방법은 애플리케이션을 페이스 레이어(pace layer)T2, 즉 변화 속도가 다른 층으로 나누는 거예요.

맨 아래에는 천천히 움직였으면 하는 것들이 있어요. 정체성과 권한, 권위 있는 데이터, 감사 이력, 핵심 도메인 의미, 규제 로직, 보안 경계, 외부 계약, 네트워크, 자금 이동, 그리고 쌓여 온 운영 지식.

마지막 항목은 처음 보기보다 중요해요.

Gartner는 쓸모 있는 에이전틱 시스템이라면 깊은 조직 기억과 고객 맥락을 오랫동안 간직해야 한다고 주장해요. 해결한 예외 하나하나, 바로잡은 오류, 해석한 정책, 원인을 파악한 운영 장애가 모두 애플리케이션 밑에 있는 지속적인 역량의 일부가 될 수 있어요.

화면은 쓰고 버려도, 그 밑의 조직은 점점 똑똑해질 수 있어요.

그 느린 층 위에는 훨씬 빠르게 움직여도 되는 것들이 있어요. 워크플로, 인터페이스, 보고서, 결재, 자동화, 대시보드, 현장 단위의 정책, 오케스트레이션, 에이전트 동작, 팀 전용 도구.

오늘날의 SaaS 제품은 보통 두 층을 한데 묶어 팔고, 고객 간의 차이는 설정으로 표현해요.

생성형 SaaS 회사는 느린 층을 운영하면서 빠른 층의 상당 부분을 고객마다 따로 생성할 수 있어요.

벤더는 여전히 모든 것을 호스팅할 수 있어요. 여전히 보안을 지키고, 모니터링하고, 배포를 통제하고, 고객 지원을 할 수 있어요.

하지만 고객 A는 이 애플리케이션을, 고객 B는 저 애플리케이션을 받고, 고객 C는 주로 에이전트를 통해 상호작용할 수도 있어요.

소프트웨어는 맞춤형이고, 서비스는 공유돼요.

이건 SaaS의 죽음이 아니에요.

대량 맞춤형 SaaS예요.

• • •

획일성에는 진짜 가치가 있다

이 주장은 쉽게 과장될 수 있어요.

획일성이 가치 있는 이유가 변형이 비쌌다는 것 하나만은 아니에요.

사람들은 Salesforce나 Jira를 이미 알고 회사에 들어와요.

컨설턴트는 그걸 도입하는 법을 알아요. 그 주변으로 인력 시장이 형성돼요. 연동 제품은 그걸 겨냥해 만들어져요. 교육 과정과 자격증이 있어요. 답을 검색할 수 있어요. 수천 명의 고객이 함께 버그와 예외 상황을 찾아내요.

공통 워크플로를 따르다 보면 다른 곳에서 이미 검증된 관행 쪽으로 이끌려서 조직이 더 나아지기도 해요.

이런 효과는 실재해요.

미래는 “변형이 이긴다”가 아니에요.

모든 기업이 같은 결제 프로토콜을 써야 하는 이유는? 엄청난 이점이 있어요.

영업 방식이 근본적으로 다른 두 회사가 같은 영업 기회 검토 화면을 써야 하는 이유는?

설명하기가 훨씬 어려워요.

예전에는 두 번째 질문이 거의 문제가 되지 않았어요. 아무렇게나 달라지는 일 자체가 엄두도 못 낼 만큼 비쌌으니까요.

변형이 싸지면 획일성은 이유가 필요한 선택이 돼요.

• • •

페이스 레이어는 커스터마이즈가 혼돈이 되지 않게 막는다

제대로 된 맞춤형 기업 소프트웨어 시절을 기억할 만큼 연차가 있는 분이라면 여기서 불안해지실 거예요.

우리는 이미 모든 조직이 저마다의 소프트웨어를 갖게 해 본 적이 있어요.

그 결과 엄청난 양의 고고학 유물이 생겼죠. 정체불명의 스크립트, 자체 데이터베이스, 얼어붙은 벤더 포크, 핵심 인프라 노릇을 하는 스프레드시트, 아무도 감히 손대지 못하는 연동.

커스터마이즈는 국소적으로는 잘 맞고 전체로는 앞뒤가 안 맞는 시스템을 남겼어요.

AI는 그 재앙을 훨씬 빠르게 재현할 수 있어요.

답은 맞춤형 소프트웨어를 피하는 게 아니에요.

스택 전체를 맞춤형으로 만들지 않는 거예요.

여기서 스튜어트 브랜드(Stewart Brand)의 페이스 레이어 개념이 쓸모 있어요. 건강한 복잡계에는 서로 다른 속도로 변하는 부분들이 있어요. 빠른 층은 실험하고, 느린 층은 연속성을 제공해요.

소프트웨어도 다르지 않아요.

대시보드는 내일 바뀔 수 있어요. 팀의 워크플로는 다음 달에 바뀔 수 있어요. ‘고객’의 권위 있는 정의는 몇 년을 버텨야 할 수도 있어요. 정체성과 권한은 여러 세대의 애플리케이션을 거쳐도 살아남을 수 있어요.

문제는 이 층들이 한데 녹아붙을 때 생겨요.

임시 워크플로가 데이터 모델에 굳어 버려요. 조직도가 권한 체계로 새어 들어가요. UI에 대한 가정이 API 계약이 돼요. 어떤 사내 연동이 중요한 업무 규칙이 존재하는 유일한 장소가 돼요.

그러면 빠른 변화가 느린 의미를 질질 끌고 다니기 시작해요.

강한 아키텍처의 목적은 커스터마이즈를 막는 데 있지 않아요.

시스템의 일관성을 해치지 않으면서 커스터마이즈 비용을 낮추는 데 있어요.

느린 층은 생성된 소프트웨어가 기댈 버팀목이 돼요.

보험금 청구 인터페이스는 바뀔 수 있어요. 하지만 ‘청구’의 의미가 덩달아 쉽게 바뀌어서는 안 돼요.

팀의 워크플로는 다음 주에 다시 생성할 수 있어요. 하지만 생성기가 다른 표현이 더 편하다고 판단했다고 해서 그 밑의 정체성 모델까지 새로 발명해서는 안 돼요.

임시 보고용 애플리케이션은 사라져도 돼요. 하지만 권위 있는 재무 데이터와 감사 기록까지 함께 사라질 수는 없어요.

값싼 변형은 오래가는 무언가가 그걸 붙잡아 줄 때만 안전해요.

• • •

포크 없는 커스터마이즈

예전 맞춤형 시대에는 또 하나의 문제가 있었어요. 커스터마이즈 하나하나가 유지보수해야 하는 짐이 됐다는 거예요.

고객이 4.2 버전을 수정해요. 벤더가 4.3을 내놓아요. 이제 누군가는 변경 사항을 병합해야 해요.

시간이 지날수록 맞춤형 소프트웨어는 무게가 쌓였어요.

생성형 소프트웨어는 다른 가능성을 열어 줘요.

오래 남는 게 생성된 구현 자체가 아니라고 해 봐요. 대신 고객의 의도, 적용되는 정책, 아키텍처 제약, 쓸 수 있는 역량, 데이터 계약, 출처 기록(provenance), 그리고 어떤 동작이 허용되는지 판정하는 평가가 남는 거죠.

구현은 그 산출물들에서 도출할 수 있어요.

워크플로가 바뀌면? 다시 생성해요.

플랫폼이 바뀌면? 다시 생성해요.

회사가 조직 개편을 하면? 다시 생성해요.

여기에는 아주 큰 가정이 숨어 있어요.

의도, 제약, 출처 기록, 평가가 실제로 구현을 다시 생성할 수 있을 만큼 오래 유지돼야 해요. 그것들이 불완전하거나, 낡았거나, 틀렸다면 재생성은 틀린 소프트웨어를 충실하게 만들어 낼 거예요.

제가 The Phoenix Architecture와 재생 소프트웨어(Regenerative Software) 작업에서 탐구해 온 문제가 바로 이거예요. 코드가 쓰고 버리는 것이 된다면, 코드를 다시 만드는 데 필요한 지식이 코드 안에 갇혀 있어서는 안 돼요.

그 문제를 충분히 풀 수 있다면 경제학이 극적으로 바뀌어요.

벤더는 더 이상 서로 갈라지는 구현 만 개를 손으로 유지보수하지 않아도 돼요.

공유 기반에 더해, 변형 만 개를 만들어 내는 데 필요한 지속적인 지식을 유지보수하면 돼요.

구현은 교체 가능해져요.

• • •

애플리케이션 만 개에도 지원은 필요하다

운영 쪽에서 나올 반론은 뻔해요.

서로 다른 애플리케이션 만 개를 누가 지원하죠?

누가 테스트하죠?

고객 A와 고객 B가 서로 다르게 생성된 인터페이스와 워크플로를 돌리고 있다면, SOC 2나 HIPAAT3 인증은 무엇을 의미하죠?

포크 없는 커스터마이즈는 소스 유지보수 문제를 풀어요. 지원, 테스트, 보안, 규제 준수 문제까지 저절로 풀어 주지는 않아요.

모든 변형이 아무 제약 없는 눈송이라면, 대량 맞춤형 SaaS는 자체 운영 비용에 짓눌려 무너질 거예요.

그래서 느린 층에는 API 말고도 더 많은 것이 들어가야 해요.

통제된 실행 환경이 필요해요. 공통 ID와 권한 부여, 텔레메트리, 배포 통제, 데이터 계약, 보안 경계, 정책 강제, 평가 프레임워크를 갖춘 환경이요.

고객의 소프트웨어는 제멋대로가 아니면서도 다를 수 있어요.

클라우드 플랫폼은 이미 한 층 아래에서 비슷한 일을 하고 있어요. 수백만 개의 애플리케이션이 서로 다를 수 있는 건, 그 밑의 인프라가 운영 방식을 충분히 표준화해서 그 다양성을 감당할 수 있게 해 주기 때문이에요.

다음 세대의 SaaS는 인프라 층 위에서 같은 일을 할 수 있어요.

애플리케이션은 제각각.

보장은 공통.

지원 방식도 바뀌어요. 고객마다 생성된 소스 코드를 지원 엔지니어가 일일이 리버스 엔지니어링해야 하는 상황이 돼서는 안 돼요. 벤더에게 필요한 건 무엇이 생성됐는지, 왜 생성됐는지, 무엇이 바뀌었는지, 그리고 여전히 지원 범위 안에 있는지 답할 수 있을 만큼의 출처 기록, 텔레메트리, 제약, 재현성이에요.

그렇지 않으면 우리는 그저 컨설팅웨어T4를 AI 속도로 재발명한 셈이 돼요.

• • •

SaaS 회사는 기반이 된다

이렇게 보면 소프트웨어 회사의 전략적 질문이 달라져요.

고객은 실제로 무엇에 돈을 내고 있나요?

답이 주로 CRUD 화면, 범용 워크플로, 대시보드, 양식, 결재 로직, 보고서, 설정 가능한 데이터베이스라면, 발밑의 땅이 움직이고 있는 거예요.

그런 것들은 여전히 쓸모 있어요. 하지만 그 역사적 가치의 일부는 누군가 그걸 작성하고 유지보수해야 했다는 사실에서 나왔어요.

답이 신뢰받는 네트워크, 권위 있는 데이터, 규제 전문성, 자금 이동, 기록 시스템(system of record), 생태계, 쌓여 온 조직 지식, 감사 가능성, 운영 책임이라면, 값싼 코드로는 그 중요한 부분을 복제할 수 없어요.

눈에 보이는 애플리케이션은 줄어들어도 기반은 더 가치 있어질 수 있어요.

IDC는 이런 미래의 한 가지 버전을 SaaS 애플리케이션이 “피처웨어(featureware)”가 되는 것으로 묘사했어요. 상호작용은 점점 더 에이전트가 맡고, 기존 애플리케이션은 그 밑에서 통제된 기록 시스템이자 역량으로 남는다는 거예요.

하지만 저는 에이전트 뒤로 밀려나는 강등을 받아들이는 것보다 더 야심 찬 기회가 있다고 생각해요.

최고의 SaaS 회사는 의도적으로 기반 회사가 될 수 있어요.

그들은 느린 층을 소유해요.

그리고 빠른 층을 안전하게 생성할 수 있게 해 줘요.

• • •

SaaS 창업자에게 불편한 질문

이 질문은 애플리케이션과 그 밑에서 오래가는 사업을 갈라 줘요.

Stripe라면 답이 결제 양식이 아닌 건 분명해요.

급여 회사라면 직원 테이블이 아니에요.

금융 정보 회사라면 대시보드가 아니에요.

어떤 회사에게는 답이 상당할 거예요.

다른 회사에게는 제품의 대부분이 빠른 층에 있었다는 게 드러날 수도 있어요.

그렇다고 그 회사들이 내일 사라진다는 뜻은 아니에요.

다만 다른 누군가가 알아내기 전에, UI 밑에서 자신이 무엇을 소유하고 있는지 아마 서둘러 알아내야 한다는 뜻이긴 해요.

• • •

사내 소프트웨어의 귀환

같은 경제학이 “만들기 전에 사라”는 조언도 바꿔 놓아요.

그 조언은 사내 애플리케이션을 만든다는 게 소프트웨어 프로젝트에 끝없이 인력을 대야 한다는 뜻일 때 말이 됐어요.

하지만 직원 쉰 명이 자기들에게 잘 맞지 않는 워크플로 때문에 하루 20분씩 손해를 본다고 생각해 보세요.

그걸로 여섯 달짜리 맞춤 개발을 정당화하기는 어려울 수 있어요.

하지만 기존 기반 위에서 며칠 동안 생성으로 개발하는 건 충분히 정당화할 수 있어요.

사내 소프트웨어의 르네상스가 올 수 있어요.

거대한 IT 부서가 SAP를 다시 만드는 게 아니에요.

작은 팀이 튼튼한 공유 기반을 유지하면서 그 주변에 아주 구체적인 도구들을 만들어 내는 거예요.

그들의 강점은 SaaS 벤더보다 코드를 더 잘 짜는 데 있지 않아요.

조직을 안다는 데 있어요. 조직의 언어, 정책, 데이터, 권한 구조, 예외, 역사를요.

범용 소프트웨어가 늘 추상화해서 지워 버려야 했던 바로 그 세부 사항들이에요.

차이가 사내 팀의 비교 우위가 돼요.

• • •

현실을 책임지는 누군가는 여전히 필요하다

이 모든 이야기에는 악몽 버전도 있어요.

모든 팀이 애플리케이션을 생성하기 시작해요. 저마다 고객 정체성을 또 다른 방식으로 표현하고, 권한 모델을 또 하나 발명하고, 중요한 데이터의 편리한 사본을 또 하나 만들어요. 모든 에이전트는 당장의 작업을 가장 쉽게 해 주는 접근 권한을 받아요.

1년 안에 회사는 애플리케이션 천 개를 떠안게 돼요. 하나하나는 그럴듯하지만, 기본적인 현실을 두고 서로 말이 다른 것들이요.

생성 기술 덕분에 이런 일은 어려워지기는커녕 더 쉬워져요.

그러니 누군가는 여전히 느린 층을 책임져야 해요.

권위 있는 데이터, 공통 의미가 중요한 곳의 공유 도메인 개념, 안정적인 역량, 권한 경계, 프로토콜, 그리고 생성된 소프트웨어가 해도 되는 일에 대한 제약이 있어야 해요.

거버넌스는 속도에 맞춰야 해요.

팀은 아키텍처 위원회 없이 자기 대시보드를 다시 생성할 수 있어야 해요.

회사 돈을 누가 옮길 수 있는지를 다시 정하는 건 얘기가 달라요.

모든 변경에 중앙 승인이 필요하면 커스터마이즈가 죽어요.

아무것도 승인이 필요 없으면 일관성이 죽어요.

어느 쪽이 어느 쪽인지 알려 주는 게 좋은 아키텍처예요.

• • •

‘만들까, 살까’는 이제 너무 거친 질문이다

그 단위가 너무 클 수 있어요.

네트워크는 사요.

권위 있는 데이터는 공유해요.

정체성은 표준화해요.

규제 엔진은 재사용해요.

떠안고 싶지 않은 운영 책임은 외주로 맡겨요.

워크플로, 인터페이스, 보고서, 오케스트레이션은 생성해요.

요구 사항이 빨리 바뀌는 것은 다시 생성해요.

의미가 안정적으로 유지돼야 하는 것은 보존해요.

의료 기록은 천천히 움직여야 해요. 그 주변에서 한 진료팀이 쓰는 애플리케이션은 끊임없이 움직여도 돼요.

회계 원장은 천천히 움직여야 해요. CFO가 지금 보는 보고 화면은 아마 그럴 필요가 없겠죠.

고객 정체성은 오래가야 해요. 그걸 둘러싼 영업 워크플로는 한 회사에만 있는 독특한 것이어도 돼요.

이건 더 이상 ‘만들까, 살까’가 아니에요.

만들고, 사고, 공유하고, 생성하고, 다시 생성하는 것. 각각을 알맞은 속도에 적용하는 거예요.

• • •

애플리케이션이 조직의 인스턴스가 된다

설정은 제품에서 출발해요.

여기 저희 애플리케이션이 있습니다.

고객님이 다를 수 있으리라 저희가 예상한 항목들은 이렇습니다.

원하시는 값을 알려 주세요.

생성은 다른 곳에서 출발할 수 있어요.

무엇을 이루려고 하나요?

어떤 데이터와 역량이 있나요?

그것들을 제약하는 정책은 무엇인가요?

성공은 어떤 모습인가요?

그에 맞는 것을 생성해요.

이건 소프트웨어와 조직의 관계를 뒤집어요.

수십 년 동안 조직은 점점 애플리케이션의 인스턴스가 되어 갔어요. 사들인 소프트웨어가 제공하는 명사와 워크플로와 화면에 자신을 끼워 맞췄죠.

모든 차이가 좋다는 뜻은 아니에요.

코드베이스가 하나 더 필요했을 거라는 이유만으로 차이를 거부할 필요가 더는 없다는 뜻이에요.

• • •

획일성은 제 몫을 증명해야 한다

비즈니스 소프트웨어의 역사는 세 시대로 보이기 시작해요.

첫 번째는 맞춤형 시대였어요. 각 조직에 딱 맞았지만 경제성은 끔찍했어요.

두 번째는 표준화 시대였어요. 패키지 소프트웨어와 SaaS는 엄청나게 많은 조직이 애플리케이션을 공유하도록 설득해서 놀라운 규모의 경제를 이뤘어요.

세 번째는 둘을 결합할 수도 있어요.

공유하는 느린 층. 맞춤형인 빠른 층. 중앙화된 운영. 현장에 맞는 소프트웨어. 안정적인 기반. 교체 가능한 애플리케이션.

첫 번째 SaaS 시대는 변형을 없애서 규모의 경제를 이뤘어요.

다음 시대는 변형을 되살리면서 규모의 경제를 이룰 수도 있어요.

그래서 저는 SaaS가 죽었다고 생각하지 않아요.

기업들은 여전히 소프트웨어를 서비스로 살 거예요. 벤더는 여전히 그걸 호스팅할 거고요. 많은 경우 더 많이 호스팅하게 될지도 몰라요.

바뀌는 건, 눈에 보이는 애플리케이션이 모두에게 거의 똑같아야 한다는 기본 전제예요.

서비스 하나.

애플리케이션 만 개.

SaaS는 죽지 않았어요.

죽은 건 획일성이에요.

역자 주

1. Klarna와 Salesforce: 스웨덴 핀테크 기업 Klarna는 2024년에 Salesforce 같은 외부 SaaS를 끊고 AI로 사내 시스템을 꾸리겠다고 밝혀 화제가 됐어요. 이후 실제로는 CRM을 통째로 대체했다기보다 흩어진 데이터를 자체 저장소로 통합한 쪽에 가깝다는 해명이 이어졌는데, 저자가 말하는 “경계”가 이 부분이에요. ↩

2. 페이스 레이어: 스튜어트 브랜드(Stewart Brand)가 건물과 문명을 설명하며 쓴 개념이에요. 문명을 유행, 상업, 인프라, 제도, 문화, 자연처럼 변화 속도가 다른 층으로 나누고, 빠른 층은 혁신을, 느린 층은 안정을 맡는다고 봐요. 본문 뒤쪽에서 저자가 직접 이 개념을 소개해요. ↩

3. SOC 2, HIPAA: SOC 2는 미국공인회계사협회(AICPA)가 정한 서비스 기업의 보안·가용성 통제 감사 기준이고, HIPAA는 의료 정보 보호를 규정한 미국 법이에요. 기업용 SaaS가 고객에게 신뢰를 증명할 때 흔히 내세우는 인증과 규제예요. ↩

4. 컨설팅웨어: 겉으로는 제품이지만 실제로는 고객마다 컨설턴트가 붙어 손으로 맞춰 줘야 돌아가는 소프트웨어를 낮춰 부르는 말이에요. ↩