굿닥에서 지속 가능한 데이터 분석하기. (3)

굿닥은 데이터 중심과 데이터 기반의 플랫폼을 구축 중입니다.

참, 미묘합니다. '지속 가능한'이라는 문장의 의미가 정말 미묘합니다.

서비스 아키텍처를 디자인하고, 실현할 때에도 비슷한 케이스로 고민을 하게 됩니다.

1. 현재의 문제를 해결하는 최소의 리소스와 최선의 개발 방식을 택하지만, 곧바로 레거시가 되는 시스템의 구조가 맞는가?

2. 미래의 변화 요인을 어느 정도는 커버 가능하도록 서비스 아키텍처를 구사하고, 레거시 변환에 대비하도록 구조적으로 변화를 취할 수 있는 서비스로 구성을 해야 하는가?

3. 꾸준하게 지속적으로 서비스 아키텍처가 변화할 수 있도록 시스템 아키텍처를 관리하고, 레거시가 되지 않을 환경을 최대한 유지하도록 서비스를 구성해야 하는가?

보통 이 문제를 스타트업이 만나게 되면 어떤 선택을 하게 될까요? 특히. 비개발자이거나 경험이 부족한 개발자라면 이런 답변을 할 것입니다.

'2번'

그런데, 아이러니하게도 결과부터 이야기드리면, '2번'의 방법이란 존재하지 않는다는 것입니다.

'어느 정도'라는 전제조건은 '소프트웨어 개발에 있어서 존재하지 않는 미지의 변수 X'가 되어서, 시스템을 가장 극도로 복잡한 환경이 되기도 하고, 각 개발자들의 '어느 정도'라는 경계선과 '목표'의 불명확성 때문에 시스템을 가장 너저분하고, 복잡한 레거시로 만들게 되는 가장 잘못된 선택입니다.

제가 스타트업의 전문 CTO를 꽤 오랫동안 하고, 기술 자문을 하다 보면, 이렇게 2번으로 선택된 시스템들을 무수하게 만나게 됩니다.

2번이 왜 최악인지 몇 가지 설명드리겠습니다.

하나. 서비스 구현을 하고 있는 서버 개발자들 간의 구체적인 비기능적이 상황과 기획자들과 협의된 서비스의 규약과 약속에 대해서 매우 불명확한 관계로 결정이 되는 경우가 다반사로 만들어지게 됩니다.

둘. 결국, 어떤 서비스는 개발자의 선택에 의해서 복잡해지고, 어떤 개발자는 매우 단순하게 만들고, 이에 따라서 특정 기획이 틀어지고 아키텍처가 변경되면서 개발자는 자신이 만들게 된 구조가 새롭게 변경된 구조와 맞지 않는 상황에서 좌절하거나, 포기하게 되는 경우가 발생합니다.

셋. 레거시는 만들어지게 됩니다. 구조적인 부분을 최대한 영향을 주지 않으면서 애플리케이션 쪽에서 기능 확대를 하다가, 그 한계가 명확해질 때에 레거시 선언을 하고 구조 변경을 하게 되죠.

똑같습니다.

지속적인 데이터 플랫폼을 만들고 운영하고 유지 보수하는 것에 대해서 얼마나 투입하고 유지할 것인가에 대해서 고민하고 결정해야 합니다.

소프트웨어 아키텍처를 결정하는 동일한 상황에서 정말 의미 있는 판단을 해야 합니다.

1. 해당 데이터 플랫폼이 정말 지속 가능해야 하는가? 

2. 비개발자인 경영진을 설득하기 위한 실험적인 도입으로 끝날 가능성이 있지 아니 한가?

3. 당장은 데이터의 가치보다 비즈니스 구현과 서비스 개발이 더 중요한 단계인 것 아닌가?

4. 서비스 개발과 비즈니스 모델을 통해서 구체적인 수익이 나고 있는 상황이어서, 데이터 기반의 작업이 가능한 BM이 구체화되었는가?

5. 비즈니스, 데이터, 서비스의 우선순위를 구체적으로 결정할 수 있는 의사결정 체계가 완성이 되었거나, 그 단계로 가기 위해서 조직이 유연하게 변화하고 있는가?

6. 현재 서비스의 구체화를 위한 리소스의 배분과 미래를 고민할 수 있는 단계인가?

.

.

.

지속 가능한 서비스는 언제나 어려운 고민과 결정을 하게 됩니다.

그것을 

꾸준하게 유지할 수 있는 체계를 만드는 것부터 시작해야 합니다.