SaaS: 머나먼 소프트웨어 "다품종 소량 생산"의 길

클라우드 소프트웨어 서비스 산업이란 장르에서 아직 정제되지 않은 우리의 진보에 대해 기록하려고 한다. 이 글은 개념적으로 잘 정제된 용어나 기술을 다루는 대신에 타이밍을 다투는 비즈니스 시장에서 벌어지는 실제 이야기를 담는데 그 가치를 두려 한다. 또한, 중국시장에서 한국 개발자가 주도하여 중국 개발자들과 함께 이제 막 열리고 있는 SaaS 시장에 도전하는 우리의 과정을 알리고자 글을 쓴다.

3년을 보내고, 이제는 시즌2

Micro Service, Docker로 할 수 밖에 없었던 사연에서 다뤄진 우리의 시작은 다양한 시행착오속에서 많은 결과물을 만들어냈다. 사실 출발은 무엇을 만들겠다에 있지 않았다. 우리를 초대한 중국회사의 한국인 법인장님 목표가 개발자들이 경쟁력을 갖추도록 도와달라는 것이었기 때문이다. 생각보다 빠르게 1차 목표는 달성했다. 그 탄력을 이용하여 다음 과정으로 나아가는 우리에게 하나의 커다란 산이 느껴졌다. 한국인과 중국인, 언어와 사고 방식이 다른 사람들이 섞여 일하고 있다는 겉으로 드러나는 차이가 아니었다. 지향하는 가치와 경험이 상이하니 자연스럽게 제품에 대한 다른 생각, 협업 방식에 대한 현격한 입장 차이가 있었는데, 마치 빙산의 일각 같았던 그런 인식의 차이가 커다란 갈등으로 드러났다.

봄/여름/가을/겨울과 같이 계절이 변하는 일처럼 혹은 사람이 성장하면서 유아기와 소년기를 거쳐 청년이 되는 과정에서 사춘기를 거치는 것처럼 반드시 겪어야 할 일이 조직에도 당도한듯 느껴졌다. 필자는 소프트웨어를 개발한다는 일이 갖는 유기적인 면을 다년간 몸으로 겪고 조정해온 노하우와 한국에서 대기업 조직변화를 시도하다 실패해본 경험을 밑천으로 3년간 그럭저럭 임기응변 능력을 발휘했다. 하지만, 이제 그 밑천을 다 사용한 듯 보인다.

이제 나 스스로도 과거의 나를 극복하여 성장^[1]해야 하고, 우리 조직을 끌어가는 리더들이 바뀌고, 숨은 리더들이 탄생해야 할 시점이다.

정비의 시작은 비즈니스 판을 보고

다행히 우리의 갈등이 파국의 양상에 도래하기 전에 진화에 나섰다. 변화의 열쇠를 쥐고 있다고 보는 몇몇과 체제를 바꾸는 회의를 했다. 사실 일회적인 미팅으로 설명할 수 있는 것은 아니었다. 여러 개의 소수 그룹이 다양한 관점에서 자구책을 논의했다. 그 중에서 엔지니어링 관점의 변화를 논의하는 자리가 첫 번째 결정적인 자리가 되었다. 먼저 우리가 약 3개월의 짧은 기간동안 이정표로 삼을만한 비즈니스 이벤트와 주목할만한 비즈니스 활동과 의미를 빠르게 스케치했다. 3개월이라는 기간은 그 정도 안에 우리가 국면을 바꿨다는 가시적 징후를 보기 위함이다. 비교적 짧은 시간을 전제하고 비즈니스 요구 수용과 체제 정비를 함께 말하는 의도 안에는 우선순위에 대한 공감을 좁히려는 생각이 담겨 있었다.

이미 진행중이거나 진행 가능한 비즈니스 상황을 간략히 설명하기

다른 엔지니어와 기획자의 질문이 이어졌다.

레거시 코드와 제품화 코드의 역할 분담

그리고 나서 우리 CTO님의 서비스 발전 방안 스케치가 이어졌다. 약자로 이뤄진 우리의 시스템 혹은 서비스명이 나열된다. 그리고, 상관관계가 설명되고, 코드 분기를 결정하는 논리가 예시로 설명되어 지고 있었다. 실행 담당자가 아닌 탓인지 개괄적인 전개 시나리오에 공감하다가 문득 감탄에 이르렀다.

코드 운영으로 시장 검증을 거치고 표준화로 제품으로 향하는 서비스의 형상 변화를 설명한 내용

우리가 3년만에 도달한 수준이 레거시 시스템의 일부를 모바일 기반에서 사용하는 새로운 프로그램 형태로 옮기고, 그렇게 옮겨진 프로그램이 비즈니스 현장에 대한 고려를 수용하도록 베타 서비스 형태로 돌아갔던 상황이 그려졌다. 이것은 그냥 상상이 아니라 일정부분은 실제로 했거나 할 수 있는 일이 그려지고 있다. 그리고 이를 통합하여 여러 태넌트가 쓸 수 있는 범용 제품으로 발전시키는 우리의 과정이 단계적으로 그려졌다.

우리는 차세대와 같은 식으로 단발성으로 프로그램 개선을 논하는 수준의 작전을 짜고 있지 않았다. 우리는 한 발씩 시스템을 진화시키는 과정을 걸어왔고, 아직 가보지 않은 다음 스텝에 대해서 가정을 하고 나아가는 작전을 짜고 있었다. 그때 나는 우리 중에서 아무도 가보지 않은 다품종 소량 생산 소프트웨어 서비스 구축의 길에 우리가 올라와 있음을 직감했다. 짜릿했다.

조립(?) 공정이 두 개로 나눠지는 순간

개발자들이 만드는 코드가 두 개의 완전히 다른 제품으로 출시해야 하는 상황에 모두 공감했다. 생산라인에 비유하면, 같은 부품을 공유하지만 결과적으로 다른 제품으로 나가야 한다. 조금 더 프로그래머에게 친숙한 표현을 쓰면 git 기반으로 관리하던 코드의 조합이 어떤 경우는 A라는 제품으로 나가고, 어떤 경우는 B라는 제품으로 나가도록 해야한다. Jenkins, Docker, Kubernetes  같은 도구를 활용하지만, 결국 개발자간의 약속과 협업이 중심을 이루는 '다품종' 조립 공정을 만들기로 결정하는 순간이다.

형상관리와 Jenkins 정비 작업에 대한 CTO의 조언

조립은 빌드와 배포만의 문제가 아니다

당연한 이야기지만 비슷한 기능을 만들었다고 해도 빌드와 배포만 잘 가르면 여러 제품이 만들어지는 것은 아니다. 비슷한 제품을 기반으로 약간의 옵션만 붙인 제품이 다품종 소량생산이라고 우길 수 없는 이치와 같다. 사실은 최종적으로 보여지는 모습 즉, UI 측면에서 전혀 다른 경험을 줄 수 있어야 자신있게(?) 다품종 소량생산이라고 할 수 있지 않을까? 이상이 그렇다는 말이다. 현실은 한참 멀었다. 비슷한 기능이 아주 다른 생각을 갖고 전혀 다른 쓰임새를 배경으로 하여 만들어져 있음을 확인하는 순간이 자주 찾아온다. 나의 진정성을 묻게 되는 순간이다. :) (다른 말로는 좌절이라 한다.)

유사한 베타 서비스에서 일관성을 결여한 모습

응용 계층의 계층화 필요성 등장

또한, 여러 기업이 쓸 수 있는 제품, 소위 말하는 멀티 태넌시를 구축하려다 보면 사용자 테일러링이 가능한 구간을 만들어야 한다. 개발자 작업 없이 다른 조건으로 같은 코드가 동작하게 하는 것이다. 아이러니하게 이런 부분은 초기 설계에서 고려할 수는 있지만, 구체적인 쓰임새를 먼저 정의하기 어렵다. 그렇다 보니 개발자에게 이해시키기도 어렵다. 필연적으로 약간의 과잉 기획이나 구조 개선 수준의 리팩토링이 뒤따르는 일이다.

실제 우리의 경우는 후자로 애초부터 계층을 넣으려던 것은 아니었다. 점포 관리라는 단위 기능을 만드는데, 태넌트의 사용자를 점포에 할당하는 부분과 태넌트에서 사용자를 할당할 어떤 단위(우리는 Workplace라고 부른다)를 만들고, 그 단위 중에 한 가지 유형이 '점포'일 때는 연관없는 코드사이에 의존이 생겨 해당 개발자가 프로그램 유지보수에 어려움을 토로했다.

그래서, 함께 머리를 맞대고 상의를 하다가 태넌트별로 작업 공간_Workplace의 유형을 정하는 층과 점포라고 이미 정해진 작업 공간을 태넌트에서 택했을 때 나타나는 관련 서비스(예를 들면, 점포 관리)를 계층으로 구분하는 일로 개념적 합의에 도달했다.

아키텍트 역할을 하는 동료에게 계층을 만들고 모듈화 협업 작전을 설명하는 메모

길 위에서

아직 우리는 그리고 나는 커다란 숙제를 앞에 놓고 있다. 지금은 내가 가려고 하는 길이 무엇인지 맛을 조금 보았을 뿐이다. 그럼에도 불구하고 갈 것인지 물음을 스스로에게 던지는 시간이 올해 상반기에 있었다. 그리고, 올해 하반기에는 나의 의지를 말이나 글이 아니라 행동으로 보여줘야 한다. 하지만, 나는 결과를 지금을 충분히 나답게 살고 있다. 비록, 버겁기도 하고 잘 해낼 자신도 없지만, 지금이 어느 때보다 어른스러운 행동을 자주한다.

그래서, 우리의 도전의 결과와 상관없이 나에게 이런 기회를 준 모든 분들과 지금 내 곁에서 각자의 도전을 하고 있는 동료들에게 감사를 표한다. 언젠가 시간이 흘러 이 경기의 결과를 알게 되었을 때, 안주감으로 이 글을 읽을 날을 추억하며...

주석

[1] 이 글을 쓰는 시점에 사티아 나델라의 <히트 리프레시>가 주로 정신적인 면에서 상당한 도움을 주었음을 밝혀둔다.