기고 | ‘SW는 온실 속 화초일수록 좋다’··· SaaS의 개발·배포 혁신 4가지

서비스형 소프트웨어(Software as a Service)는 더 나은 방식으로 SW를 개발 및 배포하도록 해줄 뿐만 아니라, 고객의 요구를 더 효과적으로 충족하도록 지원한다.   
 
인터넷 초창기에는 웹 애플리케이션이 거의 없었다. 윈도우, 리눅스, 매킨토시 운영체제용 앱이 압도적 대다수였다. 그 당시 소프트웨어 배포란 바이너리를 서버에 업로드 하거나 윈도우 인스톨러를 만들어 CM-ROM에 담아 상점에서 파는 식이었다. 

릴리즈 주기도 매우 길었다. 빨라야 1년에 한 번 정도였다. 개발 주기는 기껏해야 주 단위로 계획됐고 버그를 발견하고 해결하기까지는 몇 달이 걸렸다. 게다가 매 릴리즈는 모놀리식 방식이었다. 따라서 하나하나가 완벽해야 했다. 버그 픽스를 배포할 기회 자체가 드물었다. 

오늘날의 소프트웨어 개발 주기는 훨씬 더 빨라졌다. 서비스형 소프트웨어(SaaS) 애플리케이션 덕분이다. 요즘 개발되는 애플리케이션의 상당 부분이 이에 기반한다. SaaS 앱은 대개 JSON 기반의 백엔드 API로 모종의 브라우저와 통신한다. 애플 및 안드로이드 스마트폰의 네이티브 앱과도 통신할 수 있지만 점점 앱이 동작하는 하드웨어가 무관해지고 있다. 

아무튼, 프론트엔드의 상황과 별개로 SaaS 앱의 전체적인 접근방식은 윈도우 및 맥용 앱의 개발·배포 방식과 극적으로 다르다. 몇 달이 아닌 몇 분 안에 수정, 업데이트 그리고 배포까지 가능한 SaaS 앱은 소프트웨어 개발의 개념 자체를 바꿔 놓았다.

그렇다면 SaaS 앱은 구체적으로 어떻게 이렇게 널리 퍼졌으며 많은 개발자가 사랑하는 개발 방식으로 자리 잡았을까? 

다음 4가지 이유를 들 수 있다.
1.    개발 팀이 코드 실행 전부를 통제한다. 
2.    코드가 명확히 규정된, 고도로 통제된 환경에서 실행된다.
3.    즉각적이고 자주 업데이트를 배포할 수 있다.
4.    개발팀이 사용자의 소프트웨어 사용 방식을 관찰해 제품을 효과적으로 개선할 수 있다

개발팀의 손아귀 안에 있는 코드 
기존 클라이언트/서버 세계에서는 개발자가 회사 내에서 코드를 작성하고 컴파일했지만, 외부로 출시하고 나면 그 코드가 어떤 시스템, 운영체제 구성 환경에서 실행될지는 미지수였다. 물론 모든 코드나 대부분 윈도우와 맥에서 실행되었지만 각 기기의 환경이 모두 달랐고, 코드의 실행 방식이나 애플리케이션의 구성 방식에 대한 통제권이 거의 없었다. 게다가 애플리케이션의 설정이 여러 개 있다면, 개발자가 생각하지도 못했거나 심지어 믿기 힘든 방식으로 애플리케이션을 구성하는 사용자가 있을 수 있다.
 
하지만 SaaS 앱의 코드는 외부로 나가지 않는다. 백엔드 코드는 완전히 개발팀의 통제 속에 있으며, 구성, 통제, 그리고 수정까지 자유롭게 할 수 있는 환경에서 실행된다. 프론트엔드 코드도 개발팀의 서버에 상주하면서 네트워크 요청에 따라 한정된 수의 웹 브라우저에서 실행된다. 

명확히 규정된 환경 
시중의 브라우저는 다양하지만 그 숫자는 얼마 안 되며, 브라우저 자체가 대부분 예상 가능하고 테스트하기 쉬운 환경이다. 따라서 SaaS 애플리케이션은 한정된 수의 실행 환경만 접하며, 이 덕분에 개발팀은 전형적인 개발 모델보다 더 철저하게 코드를 테스트할 수 있다.
 
그래도 안드로이드 생태계의 복잡성은 여전히 작은 걸림돌로 남아 있다. 수많은 사양의 기기가 수많은 버전의 안드로이드 운영체제를 구동하고 있어 문제가 발생할 가능성이 있다. 그러나 이 또한 많은 개발자들이 웹 기반 솔루션으로 전환하면서 점차 해소되고 있다.

그리고 인터넷 익스플로러의 사망 선고도 개발 복잡성을 줄이는 데 한몫했다. 이제 남은 브라우저는 사실상 모두 웹 애플리케이션용 표준을 준수한다. 

빠르고 즉각적인 업데이트 
기존 소프트웨어 개발자들은 고객에게 이미 제공한 소프트웨어에 미처 발견 못했던 치명적인 버그가 발생하더라도 몇 주, 혹은 몇 달 동안이나 패치를 배포하지 못할 수도 있다는 두려움에 시달렸다.
 
SaaS 앱 개발자는 이런 걱정을 할 필요가 없다. 만일 치명적인 버그가 개발 파이프라인을 피해 최종 제품까지 침투한다고 해도 개발팀은 버그 발생 시 바로 조처를 할 수 있다. 사용자가 알아차리기도 전에 검증된 버전으로 롤백하거나 해당 기능을 비활성화하면 된다. 대부분의 경우 개발팀은 단 몇 분 안에 버그를 수정하고 업데이트를 배포한다. 몇 달을 소요하지 않아도 된다.

SaaS 애플리케이션 개발 방식의 장점은 신속한 버그 수정뿐만이 아니다. 기존처럼 새로 개발한 기능을 인벤토리로 붙잡아 둔 채 다음 주요 업데이트로 미룰 필요가 없어졌다. 예전에는 주요 업데이트 후 몇 주 안에 새 기능을 개발하더라도 사용자에게 전달하기까지 몇 달은 족히 걸렸다. 하지만 오늘날 SaaS 앱 환경에서는 새 기능이 준비되자마자 사용자에게 배포된다.

높은 관찰가능성과 고객 이해 
SaaS 애플리케이션은 한정된 브라우저에서만 실행되므로 환경 내에서 일어나는 일을 관찰하기 쉽다. 데이터독(Datadog), 다이나트레이스(Dynatrace) 같은 도구를 사용하면 애플리케이션 내부에서 일어나는 모든 사항을 관찰하고 추적할 수 있다. 롤바(Rollbar) 같은 도구로 오류를 모니터링하면 클라이언트 쪽에서 오류가 발생하자마자 즉각 보고된다. 오류를 파악하는 데 걸리는 평균 시간이 극적으로 줄어든다.

따라서 관찰가능성은 고객이 문제를 보고해야만 알 수 있는 간접적 관찰이 아니라 실시간 관찰이 된다. SaaS 애플리케이션은 브라우저가 있는 컴퓨터든 모바일 기기든 인터넷에 연결된 장치에서 실행되므로 모든 사항을 빠짐없이 기록하고 보고할 수 있다. 오류를 비롯해 사용 패턴이나 앱의 상태 등의 갖가지 정보를 전달해 관찰가능성을 높여준다. 

클라우드/서버 시대에 전형적인 소프트웨어 회사는 사용자층을 정확히 파악하는 데도 애를 먹었다. 구체적으로 어떤 작업을 하는지, 얼마나 자주 사용하는지는 가늠조차 어려웠다. 즉 사용자는 단지 소프트웨어를 구매한 뒤 이를 설치해 사용하면 끝이었다. 아무도 사용자가 소프트웨어로 어떤 작업을 어떻게 하는지 알 수 없었다. 
 
반대로 SaaS 애플리케이션은 사용자가 하는 거의 모든 작업을 볼 수 있게 해준다. 모든 데이터가 서버에 저장되므로 사용자의 현재 작업은 물론 이전 작업 이력도 모두 기록된다.

여기서 빅 브라더의 감시나 개인 정보에 대한 우려가 나올 수 있다. 하지만 SaaS 앱은 개인식별정보를 저장하지 않는다. 행동 모니터링은 오히려 고객과 더욱 평등하고 긴밀한 파트너십을 맺게 해준다. 고객의 사용 패턴과 데이터를 기반으로 제품을 효과적으로 개선해나갈 수 있기 때문이다.

결과적으로 개발팀은 사용자 활동 데이터를 종합해 사용량이 높은 부분에 더 신경 쓸 수 있다. 또한, 사용자가 제품을 어떻게 사용하는지, 그리고 어떨 때 사용하지 않는지도 파악 가능하다. 사용자가 제품을 더 잘 활용하도록 돕고, 어느 지점에서 베스트 프랙티스 방식대로 사용하는지, 혹은 하지 않는지 확인할 수 있다. 정리하자면, 우선순위가 높은 사용자에게 더 많은 자원을 투입할 수 있어 전반적인 생산성이 크게 올라간다.

고객층과 사용자의 행동에 대한 정보는 모든 기업에게 금광과도 같다. SaaS 애플리케이션은 바로 이런 정보를 제공한다. 회사와 사용자 모두 득을 보는 ‘윈윈’ 전략을 가능케 해주는 셈이다. SaaS는 더 나은 소프트웨어 개발 및 배포 방식일 뿐만 아니라 고객의 만족도를 높이는 지름길이다.

*Nick Hodges는 소프트웨어 오류 추적 및 모니터링 솔루션 업체 롤바에서 디벨로버 애드보케이트(developer advocate)로 재직 중이다. 오랜 델파이(Delphi) 개발자인 닉은 지난 몇 년간 타입스크립트(TypeScript)와 앵귤러(Angular)에 빠져 있다. ciokr@idg.co.kr