2)서비스 기업의 자체 개발 시 구조화 설계 필요성에 대하여

앞선 글 '서비스와 데이터 구조화의 기본: 앱과 웹 개발 설계'를 통해 앱/웹 개발 방식에 따른 구조화와 구조화 방법에 따른 엔트로피 관리 방안에 대하여 알아보았습니다.

이 글에서는 서비스 기업이 자체 개발을 진행할 때 구조화 설계가 선행되어야 하는 필요성에 대하여 좀 더 정리해 보겠습니다.

1.서비스 기업의 자체 개발 목적 및 환경 그리고 구조화 설계

서비스 기업이 자체 개발을 할 때 구조화 설계를 해야 하는 필요성 파악을 위해서는 개발의 목적과 개발이 진행되는 환경을 파악해야 합니다.

이는 상황이론 측면에서 뿐 아니라 일반적으로 우리가 일상에서 경험하는 적응과 축구의 포메이션 같은 스포츠 전술을 통해서도 이해할 수 있습니다.

그러므로 서비스 기업이 자체 개발을 하는 목적과 개발 활동이 이루어지는 환경을 살펴본다면 구조화 설계를 왜 해야 하는지 필요성과 더 나아가 어떻게 해야 하는지에 대한 아이디어를 얻을 수 있을 것입니다.

1-1.서비스 기업 자체 개발의 목적과 구조화 설계 필요성

서비스 기업이 진행하는 앱과 웹의 개발은 비즈니스 활동입니다.

개발은 일종의 제품 생산으로 볼 수 있습니다. 이는 시장과 고객과 교환을 통한 매출을 목표로 합니다. 신규 이용자, 총 사용자, 유지율, MAU/DAU 등의 지표를 중요하게 보는 것은 온라인 서비스 제품의 성격 때문입니다.

결국 개발이 비즈니스를 위한 제품 생산 활동이라면 M/S(점유율)과 매출을 위한 과정의 한 부분이 됩니다. 개발 자체로는 의미를 가질 수 없고 개발이 M/S(점유율)와 매출을 발생시킬 때 의미가 있습니다.

그러므로 서비스 기업에서 진행되는 개발의 목적은 점유율과 매출이라 할 수 있습니다.

1-1-1.서비스 기업 자체 개발의 목적에서 파생되는 구조화 설계 필요

그런데 점유율과 매출을 달성하는데 문제는 고객(유저)의 마음(가치)을 알 수 없다는 것입니다. 물론 100명이나 1000명의 유저 마음은 알 수도 있을 것입니다. 그러나 서비스 유저가 100만명을 넘어 1000만명이 된다면 일일히 서비스에 대한 유저 마음(가치)을 파악하는 것은 불가능합니다.

그런데 서비스 시장 점유율과 매출을 높이기 위해서는 100만명이 아니라 1000만명 이상의 유저를 확보하고 이 유저들이 더 열심히 서비스를 이용할 수 있는 만족을 제공해야 한다는 문제에 부딪치게 됩니다.

이 문제를 타개하기 위해 서비스 기업은 자체 개발을 진행하기 전에 가설을 수립한 후 진행합니다. 그리고 가설은 100만명에서 1000만명 이상 유저로 확대되고 또 이들의 서비스 충성도가 강력해 질수 있는 핵심 포인트(제공 가치 또는 유저 문제 해결)와 성장 과정을 담고 있어야 합니다.

그런데 이를 개발 전 뿐 아니라 개발을 하는 중에도 서비스 기업은 가설이 맞는지 틀린지 알 수 없다는 것이 또 문제로 등장합니다.

그래서 서비스 기업은 짧은 기간 빠르게 가설에 기반하여 개발을 완료 한 후 유저에게 제공하여 서비스 만족을 측정하게 됩니다. 여기서 나온 데이터를 바탕으로 서비스를 검증하고 보완하여 다시 개발을 하는 짧은 과정을 반복합니다.

문제는 스타트업의 경우 한 팀이 이 작업을 반복하지만, 빅테크의 경우 매우 많은 여러 팀이 동시에 이 작업을 반복한다는 점에서 또 문제가 생깁니다.

짧은 기간에 빠르게 서비스 개발과 유저 제공을 반복하며 시간이 흐르게 되면 한 팀 정도 규모의 스타트업이라도 어느 순간 시스템 통합성 및 서비스 일관성이 어긋나는 일이 발생합니다. 그런데 10개 팀, 100개 팀이 연속적을 개발과 배포를 반복한다면 서비스 일관성을 넘어 시스템 정합성 이탈에 따른 플랫폼 에러도 발생하게 됩니다.

그래서 유저의 서비스 인식 관련 전략 측면에서 서비스가 여러 기능의 추가와 화면 개발, 보완 등의 연속된 작업속에서도 일관성을 유지하기 위하여 서비스 구조화 설계는 필요한 것입니다.

또한 여러 팀의 반복적인 개발과 배포의 속도와 안정성(지속적 통합과 배포/CICD)을 위해서도 구조화 설계는 필요합니다.

• 기능과 화면 추가 개발의 반복에도 서비스 경쟁 전략이 의도한 유저 인식의 동일성을 유지 하기 위해 서비스 구조화는 필요.

• 여러 팀의 반복적인 개발과 배포속에서 시스템 안정성을 확보하고 개발 된 내용이 빠르게 서비스 플랫폼에 적용될 수 있게 하기 위하여 구조화 필요.

1-2.구조화 설계 없이 서비스 기업이 개발을 지속한다면 운영하는 앱과 웹은 어떻게 될까?

시스템 엔트로피는 상호작용 시간과 성장, 분화(또는 기능, 요소 등의 추가)에 의하여 상승합니다. 이는 온라인 애플리케이션이자 서비스 시스템인 앱과 웹에서도 같습니다.

• 사용 유저가 많아지고, 이용이 증가하면 서비스 시스템 엔트로피는 증가합니다.

• 코드와 기능이 추가되고 메뉴가 늘어나면 서비스 시스템 엔트로피는 증가합니다.

이는 단지 프로그램 측면 뿐 아니라 유저가 서비스를 인지하는 측면의 엔트로피 증가 또한 발생합니다.

이 엔트로피 상승을 방치하면 서비스는 불안정해지고, 유저는 이 서비스에 대한 가치(문제 해결) 기대가 모호해지기 시작합니다. 이러한 현상은 기존 유저 이탈과 신규 유저 유입 하락으로 나타납니다.

서비스 기업 자체 개발 시 구조화 설계 필요성 정리

2.구조화 설계 시 주의점

구조화 설계 또한 시스템적 관점에서 이루어져야 합니다. 여기서 시스템적 관점은 앱과 웹의 기능과 화면이 작동되는 물리적 인프라, 코드 관점의 시스템과 유저가 서비스를 인지하는 관점의 시스템을 통합하여 유기적(시스템)으로 바라보는 것을 의미합니다.

여기에 작동되는 프로그램으로의 시스템과 유저가 인지하는 서비스로의 시스템을 연결하는 화면, UI, 여정(경험을 형성하는 과정)으로 시스템을 추가로 고려하여 구조화 설계를 해야 합니다.

1. 앱과 웹 프로그램이 작동되기 위한 인프라, 코드 등의 유기적 결합으로 시스템

2. 앱과 웹을 이용하는 유저가 서비스로서 가치와 구성, 기대 등이 인지 네트워크로 시스템

3. 앱과 웹 프로그램과 유저 기억을 구성하는 서비스 시스템을 연결하는 경험 시스템

만약 구조화 설계의 중심이 프로그램 시스템 측면으로 치우친다면 시간이 흐름에 따라 특정 문제 해결의 여러 대안 서비스 중 유저는 해당 서비스를 먼저 떠올리거나, 그 서비스의 차별적 가치를 느끼지 못하게 될 수 있습니다.

이는 인프라, 코딩, AI 등 기술적 우위 및 객관적 편리성과 별개의 가치입니다.

반대로 너무 유저 기대 측면의 시스템에만 치우칠 경우 프로그램 불안정 및 유지/보수 어려움 등을 겪게 될 수 있습니다.

이러한 문제는 짧은 기간에 나타나지 않는다는 점에서 서비스 기업 자체 개발 시 논의 되지 않을 수 있습니다.

국내 전통 기업 조직 문화 측면에서 3년, 5년 후 PO나 CTO, 설계자, 개발자는 단기 성과를 토대로 승진하여 문제가 조금씩 나타날 때 쯤 해당 부문에 없을 가능성이 큽니다.

IT 인사/조직 특성 상 단기 성과를 기반으로 다른 기업으로 더 나은 조건으로 이직을 한 상태일 수 있습니다.

그러나 시스템 엔트로피 측면에서 구조화 설계의 허점은 시간과 상호작용에 비례하여 문제가 분명히 됩니다.

단지 이 시점 스타트업이 사라지거나 피벗했거나, 단기 성공을 바탕으로 거액의 투자를 받은 후 전체 시스템을 재 설계/개발 했거나, 더 많은 인력을 투입해서 하드 코딩 등의 땜빵으로 시스템을 유지하면서 차세대라는 명목으로 새로운 사용자 경험의 동일성을 유지하면서 프로그램 시스템을 개발하고 있을 수도 있습니다.