SaaS

소프트웨어를 물건처럼 사던 시절이 있었습니다. 값을 한 번에 치르면 프로그램 한 벌을 쓸 권리를 받았고, 그 한 벌은 산 회사의 서버에 얹혀 그 회사 것으로 살았습니다. 만든 쪽 손을 떠난 뒤로는 고객사마다 따로 자라는 셈이라, 같은 제품인데도 어느 회사에서 어떻게 돌고 있는지를 만든 쪽이 알 수 없었습니다.

그래서 계약서에 도장을 찍은 날과 실제로 쓰기 시작하는 날 사이가 멀었습니다. 고객사 전산실에 서버를 들이고, 엔지니어가 출장을 가서 설치하고, 사내 규정에 맞게 설정을 고치고 나서야 첫 화면이 열렸습니다. 두세 달이 예사였습니다. 판 쪽도 편하지 않았습니다. 오류 하나를 고쳐도 고객사 300곳에 각각 패치 파일을 보내 설치해 달라고 부탁해야 했고, 어떤 곳은 3.2 버전, 어떤 곳은 4.1 버전을 쓰고 있어 같은 문의에도 답이 달랐습니다. 신입 상담원이 가장 먼저 배우는 일이 "지금 쓰시는 버전이 어떻게 되나요" 였습니다.

돈이 들어오는 모양도 이 방식을 오래 끌기 어렵게 만들었습니다. 계약한 해에 3억이 한 번 들어오고 다음 해부터는 유지보수료 6천만 원만 들어옵니다. 올해 잘 팔았다고 내년이 편해지지 않으니 매해 처음부터 다시 파는 회사가 됩니다. 고객 쪽 사정도 비슷했습니다. 3억을 먼저 내고 두 달을 설치에 쓴 다음에야 이 제품이 우리한테 맞는지 알게 되는데, 안 맞아도 물릴 방법이 없었습니다. 그래서 결정이 무거워졌고, 무거운 결정은 오래 걸렸습니다. 도입 검토에만 반년을 쓰고 결국 안 사기로 하는 일이 흔했습니다.

SaaS 는 이 구조를 반대로 세운 것입니다. 소프트웨어를 고객에게 넘기지 않고 만든 쪽이 계속 들고 돌립니다. 고객은 브라우저 주소창에 주소를 치고 들어와 쓴 기간만큼 돈을 냅니다. 설치가 없으니 계약 다음 날부터 쓰고, 고칠 것이 생기면 만든 쪽 서버 한 곳만 고치면 모든 고객이 같은 날 고쳐진 것을 씁니다. 돈도 매달 조금씩 들어와 쌓이는 모양이 되는데, 이렇게 해마다 반복해서 들어오는 금액을 따로 세는 연 반복 매출이라는 단위가 생긴 것도 이 변화 때문입니다.

바뀐 것이 전달 방식만은 아닙니다. 고객이 한 번 사고 끝내지 않고 매달 계속 살지 말지를 다시 정하게 됐으니, 파는 쪽은 계약 이후에도 고객이 제품을 잘 쓰고 있는지를 계속 봐야 합니다. 예전에는 도장을 찍는 날이 끝이었는데 이제는 시작이 됐습니다.

SaaS 아래에는 용어 여섯 개가 있고 두 갈래로 나뉩니다. 한 벌의 소프트웨어를 여러 고객에게 어떻게 나눠 주느냐를 다루는 배포 구조가 넷, 같은 방식으로 인프라와 개발 환경까지 빌려 주는 인접 개념이 둘입니다.

배포 구조는 고객사끼리 무엇을 함께 쓰고 무엇을 갈라 두느냐로 나뉩니다. 화면은 똑같아 보여도 그 뒤에서 서버와 데이터가 어떻게 놓여 있는지가 다르고, 그 차이가 원가와 보안 심사 통과 여부를 가릅니다.

1. 멀티테넌시 — 고객사 여럿이 한 벌의 시스템을 나눠 쓰는 구조입니다. 300곳이 같은 서버와 같은 데이터베이스를 쓰고, 데이터는 줄마다 붙은 고객사 번호로만 갈라 둡니다. 서버를 한 벌만 돌리니 고객이 열 배 늘어도 비용은 열 배가 되지 않고, 새 기능을 올리면 300곳이 같은 날 같은 버전을 씁니다. 대부분의 SaaS 가 여기서 시작합니다.
2. 싱글 테넌시 — 고객사마다 서버와 데이터베이스를 따로 띄워 주는 구조입니다. 금융사나 공공기관처럼 우리 데이터가 남의 데이터와 같은 저장소에 있으면 안 된다는 조건을 건 고객을 받으려면 필요합니다. 대신 고객 100곳이면 환경 100벌을 운영해야 하고, 기능 하나를 올릴 때도 100번 올려야 합니다. 그래서 값을 몇 배로 매긴 별도 요금제에 붙입니다.
3. 온프레미스 — 고객사 자기 서버에 설치해 쓰는 방식입니다. SaaS 가 밀어낸 그 방식인데 사라지지 않았습니다. 외부 인터넷과 아예 끊어 놓은 망에서만 일하는 조직이 있고, 그런 고객은 아무리 좋은 SaaS 라도 접속 자체를 못 합니다. 계약 한 건이 수억 원이라 포기하기도 어려워서, 크는 회사일수록 이 요청을 어디까지 받을지가 골칫거리가 됩니다.
4. 화이트라벨 — 만든 쪽 이름을 지우고 고객사 브랜드를 달아 내보내는 방식입니다. 은행 앱 안에 들어 있는 상담 채팅창이 사실은 다른 회사 제품인 경우가 여기 해당합니다. 우리 이름이 사용자에게 보이지 않으니 브랜드는 못 쌓지만, 이미 고객을 많이 가진 회사의 화면 안으로 한 번에 들어갈 수 있습니다.

인접 개념 둘은 SaaS 와 같은 줄 위에 놓인 다른 층입니다. 빌리는 대상이 무엇이냐로 갈립니다. 다 만들어진 소프트웨어를 빌리면 SaaS, 그 소프트웨어를 만들어 돌릴 환경을 빌리면 PaaS, 서버와 저장 공간 자체를 빌리면 IaaS 입니다.

1. PaaS — 개발과 배포에 필요한 환경을 통째로 빌려 주는 형태입니다. 코드만 올리면 서버 설정과 배포, 늘어난 접속량에 맞춰 서버를 늘리는 일까지 빌려 준 쪽이 알아서 합니다. 빌린 쪽은 코드를 씁니다. 개발자 셋짜리 팀이 서버 관리자 없이 제품을 굴릴 수 있는 것이 이 층 덕분입니다.
2. IaaS — 서버, 저장 공간, 네트워크 같은 기반 설비만 빌려 주는 형태입니다. 그 위에 운영체제를 깔고 필요한 프로그램을 얹는 일은 빌린 쪽 몫입니다. 손이 가장 많이 가지만 대신 원하는 대로 짤 수 있어서, 규모가 커져 비용을 깎아야 하는 회사가 다시 이쪽으로 내려오기도 합니다.

세 층은 겹쳐 쌓입니다. 페이지덱은 IaaS 사업자에게서 서버를 빌리고, 그 위에 배포를 대신해 주는 도구를 얹어 쓰고, 그렇게 만든 문서 협업 제품을 SaaS 로 팝니다. 층이 올라갈수록 내가 손댈 수 있는 범위는 줄고 신경 쓸 일도 같이 줄어드는 교환입니다. 세 층을 한 줄로 늘어놓으면 흔히 쓰는 비유가 밥을 해결하는 방법입니다. 주방과 불만 빌리면 IaaS, 손질된 재료와 조리법까지 받으면 PaaS, 차려진 밥상에 앉으면 SaaS 입니다.

배포 구조 넷과 인접 개념 둘은 서로 다른 질문에 답합니다. 앞의 넷은 우리 제품을 어떤 모양으로 고객에게 줄지를 정하는 우리 쪽 선택이고, 뒤의 둘은 그 제품을 만들 때 우리가 무엇을 빌려 쓸지를 정하는 선택입니다. 페이지덱은 대부분의 고객에게 멀티테넌시로 팔면서 소수의 대기업에는 싱글 테넌시를 열어 주고, 그 두 가지를 모두 IaaS 위에 올려 돌립니다. 한 회사 안에서 네 갈래 중 둘을 동시에 쓰는 일이 드물지 않습니다.

"이 고객은 자기네 서버에 깔아 달라는데요. 우리는 SaaS 라서 그건 별도 개발입니다."

지금 구조로는 팔 수 없고, 팔려면 제품을 다시 만들어야 한다는 뜻입니다.

"SaaS 라서 좋은 게, 어제 고친 걸 오늘 전 고객이 씁니다."

고객마다 버전이 달라 하나씩 패치를 보내던 일이 없어졌다는 말입니다.

"무료 체험만 늘고 유료 전환이 안 붙으면 SaaS 로는 못 버팁니다."

한 번 크게 받는 구조가 아니라 매달 조금씩 쌓아 굴러가는 구조라, 쌓이는 쪽이 막히면 곧 바닥이 보인다는 지적입니다.

페이지덱은 지난 분기에 이 문제를 정면으로 만났습니다. 수아가 가져온 대기업 고객이 계약 조건으로 자기네 데이터를 다른 고객사와 같은 저장소에 두지 말 것을 걸었습니다. 연 4억짜리 계약이라 수아는 받자고 했고, 태오는 고객사 전용 환경을 따로 띄우면 운영 비용이 얼마나 늘어나는지를 계산해 왔습니다. 지현은 이 조건을 한 곳에만 열어 주면 다음 대기업 고객도 같은 것을 요구한다는 점을 짚었습니다.

규원이 내린 결정은 전용 환경을 별도 요금제로 만들고 기존 요금의 세 배를 받는 것이었습니다. 받을 수 있는 계약과 받으면 안 되는 계약을 사람 판단이 아니라 가격으로 갈라 두자는 뜻이었습니다. 이 결정 이후 페이지덱의 요금표에는 여러 고객이 함께 쓰는 기본 요금제와 전용 환경 요금제가 나란히 붙게 됐습니다.

같은 회의에서 온프레미스 요청은 받지 않기로 정리했습니다. 전용 환경은 페이지덱이 여전히 직접 돌리는 서버라 고치는 속도가 그대로지만, 고객사 서버에 설치하는 순간 버전이 갈라지고 그 갈라진 버전을 몇 년씩 따로 봐 줘야 하기 때문입니다. 수아는 이 기준을 그대로 영업 자료에 적어 두었습니다. 거절할 조건을 미리 문서에 써 두면 매번 같은 논쟁을 하지 않아도 됩니다.

웹 브라우저로 접속하면 다 SaaS 라고 보는 오해가 가장 흔합니다. 화면이 브라우저에 뜨고 설치 파일이 없으니 그렇게 보이는 것이 자연스럽습니다. 하지만 갈라지는 자리는 화면이 아니라 돈을 받는 방식과 운영을 누가 지느냐입니다. 라이선스를 한 번에 팔고 고객사 서버에 웹 프로그램을 깔아 주는 회사도 있는데, 화면은 똑같이 브라우저에 뜨지만 이것은 SaaS 가 아닙니다. 이 구분을 놓치면 투자 검토나 사업 유형 정리 자리에서 우리 회사를 SaaS 라고 소개한 뒤, 반복 매출이 얼마냐는 질문에 답할 숫자가 없어 대화가 멈춥니다.

두 번째는 SaaS 가 언제나 더 싸다는 생각입니다. 처음에 큰돈이 안 나가니 그렇게 느껴집니다. 실제로는 기간을 길게 잡으면 뒤집히는 일이 자주 있습니다. 50명이 쓰는 도구를 1인당 월 2만 원에 쓰면 5년에 6천만 원이 나가는데, 같은 기능을 한 번에 4천만 원에 사서 자체 서버에 올리는 선택지가 있었다면 5년 뒤에는 그쪽이 쌉니다. 그래서 값을 비교할 때는 월 단가가 아니라 쓸 기간 전체의 합계를 놓고 보며, 여기에 서버 관리 인력과 정전 대비까지 넣으면 다시 SaaS 쪽으로 기울기도 합니다. 싸다는 말을 검증 없이 받아들이면 3년 차에 예산 회의에서 이 항목이 왜 이렇게 늘었느냐는 질문을 받게 됩니다. 파는 쪽에서도 같은 착각이 일어납니다. 구독료가 싸 보이니 값을 낮게 매겨 놓고, 서버 비용과 상담 인력이 고객 수에 따라 같이 늘어난다는 사실을 나중에 알아차리는 경우입니다.