아마노 주차 상품 B2B 플랫폼 구조화 설계

아마노는 베스핀글로벌과 함께 2023년 10월부터 아마노의 기존 주차장 시스템 고도화 및 단계별 신규 플랫폼 개발 적용 프로젝트를 진행합니다.

이를 위해 1차 2023년 10월 17일~2023년 2월 15일, 2차 2024년 2월 16일~2024년 6월 14일에 걸친 총 8개월의 크라우드(AWS) 기반 통합 DB 구축 및 개발 프로젝트를 진행합니다. 이 1차, 2차 프로젝트를 통해 아마노 주차장 시스템 분석 및 이후 진행할 개발 로드맵을 작성하여 베스핀글로벌은 아마노와 3차 계약을 진행하였습니다.

3차 계약은 2차가 끝난 이후 2024년 6월 15일부터 진행되었습니다. 저의 경우 아마노와 베스핀글로벌의 3차 계약 프로젝트 진행 중간인 7월 22일에 1차와 2차를 진행하였던 기획자의 철수 준비와 함께 인수인계 후 작업을 위해 투입되었습니다.

아마노 3차 개발 범위와 문제

인수인계시 전달 받은 3차 개발 범위는 아마노의 모든 플랫폼의 계정과 권한을 관리하는 'AKC admin', 주차장을 관리하는 '통합주차관리', 아마노가 관리하는 주차장의 주차 상품을 외부의 '모두의주차장'과 같은 플랫폼에 판매하는 B2B 플랫폼인 '아마노쉐어'였습니다.

그러나 문제는 그래서 이 3개 플랫폼이 정확히 어떤 역할을 하는 플랫폼인지가 구체적으로 정의되어 있지 않았다는 점입니다.

'AKC admin'이 관리하는 계정과 권한이 어떤 것인지 구체적인 내용이 없었습니다. '통합주차관리'의 경우 관리 대상인 주차장 정보(데이터)에 대한 정의조차 없어서 어떤 데이터를 기반으로 주차장을 관리하는지 알 수 없었습니다. '아마노쉐어'의 경우 구체적으로 무슨 플랫폼인지 정확한 정의 조차되어 있지 않은 상태였습니다. 단지 아마노쉐어는 B2B 플랫폼이다가 전부인 상황이었습니다.

그런데 실제 3차 개발의 중심은 아마노쉐어였다는 점입니다. 아마노는 '모두의주차장', '카카오', '티맵'등 제휴사와 연동 관련 회의를 준비하고 있는 상태였습니다.

3차 개발 중심 - 아마노의 주차 상품 B2B 플랫폼 아마노쉐어

아마노쉐어의 비즈니스가 작동되기 위해서는 주차장 관리에 대한 부분이 되어 있어야 했습니다. 아마노가 관리 운영하는 모든 주차장의 모든 상품을 제휴 플랫폼이 판매할 수 있는 것은 아니기 때문입니다. 또한 주차권과 정기권 등 상품을 판매할 때도 구매자에게 주차장 관련 정보를 제공해야 하므로 주차장 정보 관리는 선 개발 조건이 됩니다.

더하여 주차 상품 B2B 제휴사에 따라 판매할 수 있는 상품과 판매량이 다르고, 주차장이 수용할 수 있는 주차 차량이 한정되어 있으므로 이에 대한 관리를 위해서도 '통합주차관리'에 대한 개발이 선행되어야 했습니다.

아마노 주차 상품 B2B 플랫폼 아마노쉐어 프로젝트의 문제

제가 문제라 생각하는 이유는 1차와 2차 프로젝트를 통해 베스핀글로벌에서 3차 프로젝트 범위와 내용을 정하여 아마노에 제안하여 결정된 3차 프로젝트였음에도 인수인계 시 기존 기획자에게 설명을 들어도 정확히 3차 프로젝트 범위와 내용에 대해 정리가 안된다는 점이었습니다.

심지어 가장 기본이 되고, 1차와 2차 통합 DB 구축을 통해 정리된 주차장과 주차장 상품 관련 데이터에 대하여 1차와 2차 작업을 한 DBA에게 물어보다도 모른다고 답할 뿐이라는 점입니다.

인수인계를 받은 후 8월 초 약 4일간 아마노로 PM, PL, DBA, 기존 기획자와 출근해서 퇴근까지 연속 회의를 해도 인수인계 시 전달받은 내용과 같은 말만 반복되었습니다. 그래서 무엇을 개발해야 하는지에 대한 설계에 대한 내용은 진척이 없었습니다.

결국 8월 중순 제가 아마노에 출근하여 고객 인터뷰 및 고객 시스템, 비즈니스 분석 등 제로 베이스에서 다시 시작하기로 결정합니다.

아마노는 8월 말 경 최대 제휴사인 '쏘카/모두의주차장'과 서울숲의 '쏘카/모두의주차장' 본사에서 B2B 관련 미팅을 하기로 했으므로 빠른 정리가 필요했습니다.

아마노 주차 상품 B2B 플랫폼의 비즈니스 구조화

가장 먼저 한 일은 '아마노'가 '모두의주차장'과 같은 제휴사와 어떻게 일을 하는지 파악하는 것이었습니다. 물론 아마노와 베스핀글로벌이 3차 프로젝트에 대하여 어떻게 계약했는지도 파악하였습니다.

여기서도 지금까지 진행의 문제가 나타났습니다.

• 문제 1 : 3차 프로젝트 범위와 내용을 알 수 없다.

• 문제 2: 가장 기본이 되는 주차장과 주차 상품 데이터를 알수 없다.

• 문제 3: 계약서 상 3차 프로젝트 계약은 API가 핵심이었다.

그런데 지금까지 기획 작업은 API가 아닌 화면 설계 중심으로 진행되었고, 또 인수인계 되었다는 사실입니다.

저는 계약서 내용을 파악한 후 아마노 주차 상품 B2B 플랫폼 개발을 위한 API 사항을 정리하는 작업을 우선 진행하였습니다.

API 관련 여러 다른 사항도 있겠지만 B2B 플랫폼에서는 제휴사와 연동되어 처리되는 비즈니스가 중심이므로 이에 대한 정리를 우선 작업하기로 저는 정합니다.

8월 19일 고객사인 아마노에 출근하여 B2B 비즈니스를 파악하는 작업을 시작하였습니다. 우선 전달받은 현재 아마노가 '모두의주차장', '카카오', '티맵' 같은 제휴사와 수동으로 업무를 처리하는데 사용되고 있었던 게시판을 분석했습니다.

제휴사와 아마노의 업무용 게시판 분석을 통해 주차권, 정기권, 카쉐어(쏘카 등 카쉐어링 업체가 이용하는 주차 정기권) 업무를 저는 구조화 하였습니다.

그리고 이에 따른 단계적 업무 처리를 데이터와 결합하여 '업무 트리'(업무 트리는 제가 붙인 이름입니다)라는 이름의 비즈니스 구조화 로직을 설계하였습니다.

아마노 B2B 비즈니스 구조 중 일부_주차권 로직 일부

업무 트리는 위의 이미지와 같이 정리된 비즈니스 구조와 업무 프로세스를 기반으로 선후 작업, 필수 선행 조건 등을 기반으로 각각의 업무 간 데이터 전달되는 데이터를 추가하여 만들어집니다.

업무 트리는 일종의 비즈니스 구성 측면의 WBS라 할 수 있습니다. 단지 비즈니스적 직관성이 있으면서 어떤 업무가 어떻게 이루어지는지 한눈에 볼수 있게 합니다. 이러한 비즈니스 업무 흐름을 웹 시스템 상으로 개발 구현하기 위한 업무 분할 구조도가 WBS입니다.

그러므로 업무 트리는 엄밀히 BA 문서 중 하나라 볼 수 있습니다.

주차 상품 B2B 플랫폼 비즈니스 구조화 성과

이 업무 트리를 가지고 8월 29일 '모두의주차장', '쏘카'와 그 동안 미루어왔던 API 미팅을 성공적으로 진행합니다.

이후 진행되는 모든 협의는 이 업무 트리를 바탕으로 합니다. 보안, 처리 규칙 등 세부 사항 역시 업무 트리 상 비즈니스 로직에 기반하여 추가/반영됩니다.

구조화 설계가 중요한 이유

여전히 외주 개발 현장의 설계는 화면 설계 단계에 멈추어져 있는 상황입니다. 원하는 화면을 그리면 개발자가 이를 보고 코딩하는 순서의 작업이 현재이 외주 개발의 일반적 작업 프로세스입니다.

이 경우 로직이 간단한 경우 큰 문제가 되지 않습니다. 그러나 로직이 복잡한 경우 개발은 진행되지 못하는 경우도 생깁니다.

특히 어떤 기업이 독자적인 비즈니스 로직을 가지고 있다거나, 화면만 보고는 어떻게 화면에서의 요청이 처리되는지 파악하기 어렵다면 화면 설계만으로 개발 구현을 한다는 것은 불가능해집니다.

이를 위해 화면 밑의 작동 로직의 설계가 필요합니다.

때로는 기업 내 여러 부서간 상호 협의에 따라 결정되거나 추가되는 정책에 따라 화면의 처리 로직이 완전히 달라지기도 합니다. 단순히 어떻게 하자는 정책의 변화가 말로만 끝나서는 시스템이 작동되지 않는 것입니다.

이는 특정 기업의 비즈니스 내용과 구조에 따라 화면으로 처리해야 하는 사항이 추가 될 수도, 축소 될 수도 있음을 의미합니다. 기업마다 차이가 있는 미묘한 비즈니스 로직, 서로 다른 정책은 화면 구성의 분화 뿐 아니라 데이터와 처리 프로세스의 차이를 형성하는 것입니다.

이러한 설계에 대한 기본적인 이해가 없이 단지 화면만을 구성하려 하니까 아마노 3차 프로젝트는 진행이되지 않고 있었던 것입니다.

구조화 설계 없이는 코딩도 없다는 것이 증명된 프로젝트

저는 개인적으로 AI 시대에는 구조화 설계가 더 중요해 진다고 생각합니다.

아마노 3차 프로젝트에서 아마노의 B2B 비즈니스 업무에 대한 분석을 하고 이를 구조화 한 후 API 로직을 설계 했습니다. 이 프로그램 개발과 직접 연관 없어 보이는 선행 작업의 완성이 개발할 대상의 내용과 범위를 구체화하여 진행이 가능하게 했습니다.

이를 바탕으로 처리에 필요한 화면을 구성하고 각 화면이 어떤 일을 하는지 정리했습니다.

업무 트리 기본이 되는 프로세스는 PPT로 만들었지만 업무 트리는 엑셀 파일로 작성했습니다. 업무에 따라 과정이 어떻고, 각 단계별로 어떤 데이터가 어떻게 이동하는지 정리했습니다.

이러한 정리는 각각의 화면의 입력/출력 데이터 뿐 아니라 어떻게 화면이 배치되어야 하는지도 정리됩니다. 또한 작업의 로직이 명확히 보여집니다.

이를 바탕으로 코딩 작업이 진행되었습니다.

구조화 설계가 없이 코딩은 할 수 없다는 사실이 아마노 3차 프로젝트를 통해 검증되었습니다. 복잡하고 난이도가 있는 프로그램의 경우 더욱 그럴 것입니다.

멀지 않은 미래에는 구조화 설계서를 바탕으로 코딩은 AI가 해 줄 것 같기도 합니다.

설계 역량의 중요성에 대한 의견

정확히 저는 구조화 설계를 10일만에 해결하였습니다. 근무일수로 치면 8일 정도 걸렸습니다.

그렇다면 제가 주차장과 주차장 상품에 대한 도메인 지식이 있었기에 할 수 있었던 것일까요?

어떻게 사전 프로젝트를 8개월 하고 추가로 약 2개월의 기간이 더 주어진 팀이 못한 일을 들어온지 얼마 안된 기획자 한 명이 바로 처리할 수 있었던 것일까요?

참고로 저는 운전면허 조차 없고, 주차장 관련 프로젝트는 아마노가 처음입니다.

단지 저는 데이터를 바탕으로 분석하고 설계를 한 것입니다. 이는 경험이나 도메인 지식으로 해결할 수 있는 것이 아니라 생각합니다.

요즘 수 십억 원, 수 백억 원 연봉을 받는 AI 개발자가 20대와 30대라는 점도 경험과 도메인 지식으로 구조화 설계를 완성하는데 한계가 있음을 잘 보여주는 것이라 생각합니다.

저는 업무 트리라는 개념을 이번 아마노 B2B 플랫폼 프로젝트를 하면서 처음 적용했습니다. 아마 다른 프로젝트에서는 필요에 따라 또 다른 방법론을 만들어 낼 것입니다. 저는 프로젝트를 분석하고 최적의 방법을 조합하거나 만들어 냈기 때문입니다.

제 경험으로 반복적 업무의 효율은 경험으로 향상될 수 있지만 문제 인식, 해석, 해결 능력은 경험으로 향상되지 않습니다.

지금의 해결해야 하는 문제가 과거와 같은 것이라면 경험이 중요하지만, 과거와 다른 것이라면 경험 이상의 창의력과 문제 해결 능력이 필요합니다.