1)서비스와 데이터 구조화의 기본: 앱과 웹 개발 설계

유저에게 제공되는 서비스를 통해서 데이터는 발생합니다. 그러기에 '어떤 형태의 앱과 웹을 개발할 것인가'에 대한 결정과 '어떻게 개발할 것인가' 진행은 시장에서 유저에게 서비스가 특정되기 위한 구조화의 기본이라 할 수 있습니다.

즉, 서비스 애플리케이션으로 앱과 웹에 대한 개발을 위한 비즈니스 정책과 데이터 흐름, 시스템 연동 규칙 설계 등의 논리적 구조화와 UI/UX 화면 구현, 코딩의 물리적 구조화가 결합되어 유지가 인식하는 앱/웹의 구조가 됩니다.

그런데 서비스는 내외적 요인으로 변화합니다.

사용자의 변화하는 니즈에 따라 서비스의 코드는 수정되기도 하고 새로운 기능을 추가하기도 합니다. 심지어 이용 유저의 수(트래픽)가 증가함에 따라 이전에 최적화된 코드가 불안정해지기도 합니다.

그러므로 앱과 웹의 서비스 상품 기준으로 서비스와 데이터 구조화는 정적 개념이 아닌 동적 개념이 되어야 합니다.

이 글에서는 이러한 서비스와 데이터 구조화의 개념을 앱과 웹 개발이라는 측면에서 살펴보겠습니다.

앱과 웹 개발 방식은 직접 개발하는 것과 외주 개발하는 것으로 구분할 수 있습니다. 많은 경우 일부 직접과 일부 외주를 하이브리드로 진행하지만 여기서는 상황의 간략화를 통한 변수 영향을 최소화하여 이해를 증진시키기 위하여 두 경우로만 개발이 진행된다고만 가정하겠습니다.

서비스 기업 자체 개발과 외주 개발 시 엔트로피 상승 원인과 관리 방안

1.앱과 웹 개발 방식에 따른 서비스/데이터 구조화 진행

예를 들어 '토스'와 같은 서비스 기업이 자신의 앱과 웹을 개발할 때와 SI 기업이 계약을 통해 고객사의 서비스를 위한 앱과 웹을 개발할 때를 구분하여 어떻게 구조화가 진행되는지 정리하겠습니다.

흔히 인식하는 개발에서 구조화는 특정 앱과 웹이라는 유저가 이용하는 인터넷 애플리케이션을 물리적 구조 형성을 의미합니다. 간단히 앱/웹 화면과 기능이 서비스 가능하도록 물리적 실체화 하는 것입니다.

하지만 앱과 웹이 코드로 실체화 되기 위하여는 비즈니스와 데이터, 서비스 시스템 등의 논리적 구조화가 선행되어야 합니다.

1-1.서비스 기업의 앱과 웹 개발 프로세스로 보는 구조화 특징

서비스 기업의 앱/웹 개발의 목적은 개발된 앱과 웹을 이용할 유저의 페인 포인트 해결을 통한 수익(점유율, 매출)성 확보에 있습니다.

개발을 위한 대상이 되는 유저는 다수입니다. 그렇기에 일일히 이들의 니즈를 직접적으로 전달받을 수 없습니다. 토스가 새로운 기능을 개발하는데 수 천만명의 유저에게 모두 직접적으로 묻고 들어서 니즈를 파악할 수는 없습니다.

이 때문에 서비스 기업은 가설에 기반하여 서비스를 개발하고 배포합니다. 그리고 가설에 대한 검증을 진행합니다.

이 프로세스를 정리하면 다음과 같습니다.

1. 페인 포인트 발굴

2. 가설 및 MVP 로드맵 수립

3. 앱/웹 설계 및 개발

4. 서비스 (기능) 론칭 및 검증(측정)

5. 학습 및 개선

서비스 기업의 개발은 불확실성 하에서 진행되기에 짧은 기간 반복적으로 진행하면서 각 개발 사항의 시장 타당성을 확인하면서 PMF를 맞추어 갑니다.

이는 서비스 기업의 개발 목적이 특정 기능의 완성이 아니라 비즈니스 수익에 있기 때문입니다. 그러므로 서비스 (기능) 론칭 후 데이터를 통해 이용률, 유지율(리텐션), 신규 가입자 등의 변화를 측정하여 가설을 검증한 후 다음 개발 프로세스에 반영합니다.

또한 토스나 네이버 같은 거대 플랫폼의 경우 각 메뉴와 기능을 담당하는 팀이 각각 개발과 운영을 진행하므로 전체 시스템의 안정성과 통합성을 고려하고 개발을 진행합니다.

1-2.외주 앱과 웹 개발 프로세스 개발 프로세스로 보는 구조화 특징

외주로 진행되는 앱과 웹 개발의 목적은 고객사와 계약을 통해 돈을 받고 계약에 의해 정해진 성능, 기능, 화면의 앱/웹을 이전하는 것입니다.

그러기에 외주 개발의 대상은 서비스 기업의 대상인 유저(2차 고객)에 앞서 고객사 담당자(1차 고객)가 됩니다.

이는 B2C와 B2B 고객의 차이입니다.

그러므로 외주 개발은 고객사 담당자와 협의를 통해 정확한 요구 사항을 파악하고 개발 범위를 확정한 후 개발을 진행하게 됩니다.

이러한 외주 개발의 특징은 '확실성하의 개발'이라는 것입니다. 이런 외주 개발은 그렇기에 서비스 기업의 개발과 다음과 같은 프로세스 차이를 보입니다.

1. 요구 사항 분석과 범위 확정

2. 정책, 메뉴, IA, 화면 목록 작성

3. 화면 설계서

4. 디자인, 개발 설계

5. 본격 코딩

6. 통합 테스트

7. 오픈/이관 및 산출물 정리

외주 개발은 B2B 계약에 기반한 비용과 기간이 미리 확정되어 있습니다. 또한 요구 사항 상세화 과정을 통해 개발 대상을 명확히 합니다. 이 때문에 외주 개발은 확실성하의 개발이 됩니다.

외주 개발은 고객사 담당자라는 니즈를 맞추어야 하는 대상이 소수라는 점에서 직접적 인터뷰를 통해 니즈를 모두 반영할 수 있게 됩니다. 이 때문에 개발은 확실성하의 개발이 됩니다.

그러나 고객 담당자와 요구 사항 상세화 작업이 제대로 되지 않을 경우 100% 문제가 발생된다는 점도 존재합니다.

이러한 문제는 유저 니즈를 모두 확인할 수 없다는 불완전 개발 관련 정보에 따른 불확실성과는 다른 상호작용/커뮤니케이션 오류, 인지 에러 등에서 발생된다는 특징이 있습니다.

그러므로 외주 개발의 경우 요구 사항 정리와 범위 확정을 위한 BA 작업이 매우 중요합니다.

2.서비스/데이터 구조화 방법에 따른 엔트로피 관리 방안

서비스 기업의 개발이 유저 페인 포인트 해결을 위한 반복적인 개발이 지속적으로 이루어지는 애자일 개발에 따른 시스템 엔트로피 증가가 있다면,

외주 개발의 경우 고객사의 요구 사항을 제대로 파악하지 못한 채 진행된 개발이 진행됨에 따라 발생되는 시작 오차로 인한 엔트로피 증가합니다.

2-1.서비스 기업의 개발 엔트로피 관리를 위한 서비스/데이터 구조화 방안

서비스 기업이 운영하는 플랫폼은 여러 팀이 나누어 각 기능과 화면 개발 프로젝트를 대략 1~2개월에 거쳐 여러 번 반복적으로 진행합니다. 이 과정에서 시스템 엔트로피는 상승하게 되어 시스템 불안정과 성능 저하가 발생합니다.

여러 팀의 개발과 배포의 반복에 따른 전체 시스템 관점의 문제를 방지하고 또한 빠르게 기존 시스템에 적용을 하기 위하여 서비스 기업은 각 팀들의 단위 개발에 앞서 지속적 통합과 배포(CICD) 방법론은 먼저 수립하게 됩니다.

이런 지속적 통합과 배포 방법론은 서비스 구조와 전략 그리고 여기서 예상되는 변화 경로를 바탕으로 통합 시스템 측면에서 이루어져야 합니다.

바로 이 설계를 통합 시스템 구조 설계라 할 수 있습니다.

위의 5단계 개발 프로세스는 약 1달~2달 이루어집니다. 토스나 네이버 같은 기업에서 일어나는 개발 프로젝트의 총 합의 스타트업에서의 개발 프로젝트와 비교할 수 없이 많습니다.

토스와 네이버의 슈퍼 플랫폼에 이 각 팀의 단위 개발 프로세스는 통합 시스템 구조 및 CICD 구조를 기반으로 서비스 전략에 따른 정형화된 배포 경로와 규칙 하에 빠르고 반복적 개발과 배포가 이루어지는 것입니다.

토스와 네이버 같은 거대 서비스 기업의 단위 개발 프로젝트에서 관련 팀이 시스템 안정과 적용 방안 등 다른 고려 없이 발견된 유저 페인 포인트 해결을 위한 개발에만 몰두할 수 있는 이유는 기존 전체 시스템 구조 설계에 기반한 배포와 통합 규칙과 정책이 정리되어 있기 때문입니다.

만약 통합 시스템 구조 설계에 기반한 지속적 통합 및 배포 계획이 설정되어 있지 않다면, 유저 페인 포인트 해결 개발이 여러 팀에서 반복적으로 이루어지면, 전체 측면의 서비스 시스템의 엔트로피가 급격이 상승하여 결함과 속도 저하 등의 문제를 겪게 될 것입니다. 심지어 완성된 개발 사항이 전체 시스템에 적용하지 못하는 일도 발생됩니다.

2-2.외주 개발 엔트로피 관리를 위한 서비스/데이터 구조화 방안

서비스 기업에서 엔트로피가 다수의 단위 개발 프로젝트가 연속적으로 서로 다른 팀에서 발생됨에 따른 통합성 및 정합성 측면에서 발생하는 것이라면,

반면 외주 개발(SI)의 엔트로피는 '초기 요구사항 정의의 미세한 오차'에서 출발합니다. 출발선의 1도 오차는 출발점에서 10cm 거리에서는 미미해 보이지만, 10m 진행 지점(통합 테스트 시점)에서는 걷잡을 수 없는 거대한 경로 이탈로 나타납니다.

아무리 회의를 길게 해도 고객사와 개발사 간의 도메인 지식, 비즈니스 목적 등의 차이로 인해 커뮤니케이션 오류는 반드시 발생합니다.

이를 코딩이나 화면 디자인으로 해결하려고 하면 당장 보고 시점에는 해결된 듯 해도 결국 시스템 엔트로피 증가만 가속화 할 뿐입니다.

그렇기에 요구 사항 분석 이전에 고객사의 비즈니스 로직과 정책을 동기화 하는 비즈니스 아키텍처(BA) 작업을 통한 고객사 비즈니스에 대한 인지 세팅이 선행되어야 합니다.

심지어 이전 다른 유사 기업 프로젝트 경험에 기반하여 개발 진행을 하는 경우에도 각 기업이 가진 비즈니스 시스템 차이로 인한 오차는 발생하게 됩니다.

예를 들어 만약 은행 프로젝트를 많이 했다면 일반적인 은행 시스템 구조와 개발에 대하여 잘 알고 있을 것입니다. 하지만 각 은행마다 차이가 있는 금융 상품과 내부적인 상품 처리 프로세스에 대한 미세 튜닝을 진행하지 않고 개발을 진행한다면 초반에는 시원 시원하게 진행되지만 프로젝트 기간 중반 이후 점점 하나 둘 씩 문제가 나타나게 됩니다.

이는 코딩의 문제가 아닌 요구 사항 분석에서 이어지는 초반 시스템 설계의 오차에서 발생되는 현상인 것입니다.