SaaS 이후에 올 것.

서비스형 소프트웨어(SaaS)는 하나의 전제에서 탄생했다. 소프트웨어를 만드는 일은 너무 비쌌고, 이를 감당할 만한 가격으로 제공하는 유일한 방법은 제품 하나를 만들어 수천 개 조직에 파는 것이었다. 조직들은 이 거래를 받아들였다. 소프트웨어가 정한 방식대로 일하는 대가로, 저렴하고 즉시 쓸 수 있는 소프트웨어를 얻은 것이다.

20년 동안 이 거래는 충분히 남는 장사였다. 하지만 이제는 아니다. 이유는 세 가지다.

SaaS의 유일한 대안은 커스텀 개발을 맡기는 것이었다. 초기 비용이 크고, 느리며, 납품하는 날 그대로 굳어 버리는 방식이다. 대부분의 중소기업은 이 두 길 사이에서 있는 것으로 그럭저럭 버티고 있다. WhatsApp 문의에 일일이 손으로 답하고, 예약을 하나씩 확인하고, 서로 연결되지 않는 시스템 사이에서 데이터를 옮겨 적으며, 팀의 누군가가 모든 것을 기억해 주기만을 바란다.

TMaaS가 SaaS를 대체할 것이다.

소프트웨어를 만들고 고치는 비용이 예전의 극히 일부에 불과하다면, 모든 조직이 같은 소프트웨어를 써야 할 이유는 더 이상 없다. 조직마다 자기 운영을 위해 만들어지고 끊임없이 진화하는 고유한 시스템을 가질 수 있다.

TMaaS에서 조직은 더 이상 닫힌 제품을 사거나 종료일이 정해진 프로젝트를 발주하지 않는다. 자기 운영을 위해 구축되고, 전용 설치에서 실행되며, 조직이 바뀔 때마다 함께 바뀌는 시스템을 갖는다. SaaS처럼 서비스의 연속성을 누리면서도, 맞춤 양복점에서처럼 제 치수에 맞게 재단된 것을 얻는다.

이 이름은 Software as a Service의 구조를 빌려 단어 하나만 바꾼 것이다. 서비스로 제공되는 것은 더 이상 모두에게 똑같은 소프트웨어가 아니라, 조직마다 맞춤형으로 만든 소프트웨어다.

무엇을 대체하고, 무엇을 대체하지 않는가

TMaaS가 대체하는 것은 애플리케이션 SaaS다. 조직이 그 소프트웨어의 방식에 맞춰 일하도록 강요하는 CRM, 예약 관리 도구, 고객 응대 수신함, 업무 관리 소프트웨어가 여기에 속한다. 결제, 메시징, 클라우드, 나아가 AI 모델 자체 같은 인프라 서비스는 여전히 공유되는 구성 요소로 남는다. TMaaS 시스템은 그 위에 구축된다.

커스텀 개발의 문제는 언제나 비용이었지, 가치가 아니었다. 비싼 것은 일 그 자체, 즉 프로그래밍하고, 테스트하고, 문서화하고, 유지보수하는 작업이었다.

AI 코딩 에이전트가 그 계산을 바꿔 놓았다. AI와 함께 일하는 소수의 팀이 예전에는 몇 달 걸리던 것을 며칠이나 몇 주 만에 만들고, 예전에는 새 프로젝트가 필요했던 변경을 몇 시간 만에 해낸다.

이로부터 세 가지 결과가 뒤따른다.

1. 고유한 시스템은 더 이상 사치가 아니다. 예전에는 대규모 조직만 가질 수 있던 것이 이제 아무리 작은 조직이라도 손에 닿는 곳에 있다.
2. 변경은 더 이상 프로젝트가 아니다. 시스템을 수정하는 비용이 워낙 적어서, 조직이 바뀌는 대로 끊임없이 고쳐 나갈 수 있다.
3. 병목 지점이 옮겨 간다. 병목은 더 이상 코드 작성이 아니라, 각 조직을 제대로 이해하고, 무엇을 만들지 결정하고, 프로덕션에 반영되는 것을 책임지는 일에 있다.

바로 이것이 SaaS가 따라올 수 없는 강점이다. SaaS의 모델은 모든 조직이 같은 것을 쓴다는 데 기대고 있다. 조직마다 다른 것을 만드는 비용이 낮아지면, 범용 제품에 안주할 이유는 사라진다.

TMaaS에서 사람의 일은 이해하고, 결정하고, 책임지는 데 집중된다. 나머지는 AI가 맡는다.

일곱 가지 원칙이 TMaaS를 SaaS 및 기존 커스텀 개발과 구별한다.

1. I

   소프트웨어가 각 조직에 맞춘다

   각 조직의 규칙, 즉 응대하고, 결제를 받고, 확인하고, 다른 곳으로 연계하는 방식이 출발점이다. 남의 제품 안에 있는 설정 옵션 중 하나가 아니다.

2. II

   공통 기반, 맞춤 계층

   각 시스템은 검증되고 공유된 기반 위에 구축되며, 조직마다 고유한 부분은 별도의 계층에 놓인다. 공통 기반이 없으면 이 모델은 이름만 다른 에이전시일 뿐이다. 맞춤 계층이 없으면 그저 또 하나의 SaaS다.

3. III

   고객마다 하나의 설치

   각 조직은 독자적인 환경에서 운영되며, 데이터도 분리되어 보관된다. 한 조직에 일어난 변경은 다른 조직에 영향을 주지 않는다.

4. IV

   시스템은 조직과 함께 진화한다

   TMaaS 시스템은 납품된 뒤 굳어 버리지 않는다. 그 시스템이 뒷받침하는 운영의 속도에 맞춰 끊임없이 변한다.

5. V

   데이터는 운영자의 것이다

   운영에서 생겨나는 정보는 그것을 만들어 낸 조직의 것이지, 시스템을 구축한 쪽의 것이 아니다.

6. VI

   책임지는 사람, 구축하는 AI

   AI는 프로그래밍하고, 테스트하고, 문서화한다. 사람은 각 조직을 이해하고, 결정을 내리고, 프로덕션에 반영될 것을 승인한다. 언제나 책임지는 누군가가 있다.

7. VII

   도입 전과 후를 측정한다

   각 시스템은 개선하려는 지표의 기준선을 잡는 데서 시작한다. 그래야 맞춤형 시스템이 그것이 대체하는 범용 소프트웨어보다 나은 성과를 내는지 확인할 수 있다.

TMaaS는 전통적인 두 길에서 장점만 취한다. SaaS의 연속성과 커스텀 개발의 적합성이다. 그리고 각각의 단점, 곧 전자의 경직성과 후자의 노후화는 뒤에 남겨 둔다.

TMaaS 시스템은 납품으로 끝나지 않는다. 조직이 그 시스템을 쓰는 한, 구축 과정은 계속 되풀이된다.

3단계가 끝나면 모든 것을 다시 측정하고, 사이클이 처음부터 다시 시작된다.

TMaaS 시스템은 여러 계층으로 이루어진다. 아래 계층일수록 더 많이 공유되고, 위 계층일수록 각 조직에 더 고유하다.

이 모델을 작동하게 하는 규칙은 이것이다. 한 조직을 위해 만든 것이 다른 조직에도 쓸모가 있다면, 그것은 분야 모듈이나 공통 기반으로 올라간다. 그래서 새로운 시스템은 매번 이전 시스템보다 더 빨리 구축된다.

이 글은 초안 단계의 논제다. 아래 질문들에는 아직 확정된 답이 없다.

1. 조직들은 얼마나 빨리 지금 쓰는 SaaS를 떠날 것이며, 그 변화를 가로막는 것은 계약, 데이터, 습관 중 무엇인가?
2. 거대 SaaS 기업들은 어떻게 대응할 것인가? 제품을 맞춤화에 개방할 것인가, 아니면 새로운 시스템에 자리를 내줄 것인가?
3. 맞춤형 조정과 새로운 제품의 경계는 어디인가?
4. AI는 각 시스템을 이해하고 유지하는 데 필요한 사람의 일을 어디까지 줄일 것인가?
5. 같은 분야의 조직들이 모인 집단은 어느 시점에 사실상 버티컬 SaaS가 되는가?