사례로 살펴보는 개발 기획 방법론

제가 진행했던 앱/웹 시스템 개발 관련 기획을 사례로 밀크런을 가지고 개발 기획 방법에 대해 설명하고자 합니다. 밀크런 관련해서는 이 블로그에 몇 개의 글이 있으니 참고하여 주십시오. 여기서는 사업 기획이나 서비스 기획은 언급하지 않을 것입니다. 오직 개발 기획에 대한 방법만 이야기할 것입니다.  

 

 

 

아는 것을 하는 것은 별로 어려운 기획이 아니다

 

IT 시스템에서 같은 것을 개발하더라도 기업이 다르다면, 개발 시간이 다르다면, 함께 하는 개발자가 다르다면 똑같은 시스템이라도 개발은 달라집니다. 

 

실제 기획 현장에서 과거에 작업하였던 경험을 토대로 그대로 하는 것은 낮은 수준에 기획입니다. 과거와 같이 그대로 기획을 하면 된다면 경력에 따라 기획 수준은 올라가게 될 것입니다. 그러나 실제 기획을 경험해 보면 그렇지 않다는 것을 알 수 있습니다.

 

앱이나 웹 같은 시장의 기획이 사용자의 문제 더 잘 해결해서 이익을 올리기 위한 것이라고 할 때, 스타트업이 잘한다는 생각이 든다면 위의 생각에 동의하시는 것입니다.

 

그리고 국내 여러 시장에서 쇼핑, 유통, 배달/물류 시장의 계속 일을 해 와서 가장 잘 알고 있는 전통 대기업들이 쿠팡에 위협을 받고 있는 이유도 바로 여기에 있습니다.

 

국내 쇼핑, 유통, 배달/물류 시장에서 가장 아는 것이 많은 기업은 신세계/이마트, 롯데, 대한통운 등일 것입니다. 이미 국내 시장을 장악하고 있을 뿐 아니라 지금도 사업을 하고 있기 때문입니다.

 

그러나 과거의 아는 것, 지식은 미래를 여는데 때로는 방해가 됩니다. 시장의 미래는 과거와 같지 않기 때문입니다. SSG닷컴과 롯데온 고전하면서 전체 그룹의 쇼핑 부분 매출이 온라인만 하는 쿠팡에 역전당하고 있는 상황도, 택배물류 강자인 CJ대한통운 쿠팡 로켓 배송에 위협을 받고 있는 상황도 시장이 변했기 때문입니다.

 

그러기에 기획은 해당 시장에 대한 과거의 지식도 중요하지만 여기에 창의력이 추가되지 않는다면 그냥 그런 기획이 될 수밖에 없습니다. 결코 시장을 변화시키는 기획은 할 수 없습니다. 단지 과거 시장의 연장선의 기획만 가능할 뿐입니다.

 

밀크런 사례를 통해 개발 기획을 이야기한다고 하면서 이렇게 별 상관없어 보이는 말을 길게 한 것은 제가 밀크런에 대하여 전혀 모르는 상태에서 시스템을 기획했기 때문입니다.

 

만약 밀크런 사업 기획이나 서비스 기획을 한다고 했으면 해당 비즈니스 도메인 지식이 더 있어야 했을 것입니다. 그러나 개발은 그렇지 않습니다. 이미 변수가 확정되어 있고 기회자는 이 변수의 상호 작용과 작동이 되게 끔 기획을 하면 되기 때문입니다.

 

이에 대해 왜 그런지 정리해 보겠습니다.

 

 

 

밀크런 시스템 개발을 위한 첫 미팅

 

밀크런 미팅은 해당 시스템이 개발되면 운영할 회사인 파스토의 PO를 포함한 3분의 분들과 진행되었습니다. 개발 쪽에서는 기획자인 저와 개발 PL, PM, 영업 이사, 개발 회사 기획 팀장 등 총 5명이 참석한 것으로 기억합니다.

 

미팅은 개발사에서 했습니다. 개발사가 삼성역 근처에 있어 파스토와 가까웠기에 파스토에서 개발사로 찾아왔습니다.

 

저는 밀크런에 대해 전혀 몰랐기에 미팅 전에 인터넷으로 공부를 했습니다. 일단 파스토가 하는 물류 사업에 대해 몰랐습니다. 과거 풀필먼트와 유사한 3자 물류를 프로모션 관련 제품을 전국 본부와 대리점에 보내는 것 때문에 관리한 적은 있어도 이 또한 이미 20년 전의 일입니다. 그러기에 밀크런은 물론 파스토 사업에 대해 처음이라고 하는 것이 더 정확할 것입니다.

 

밀크런에 대해 공부 후 미팅에 참여하여 고객사인 파스토 PO 및 함께 오신 분들의 설명을 들은 후 궁금한 사항을 물어보았습니다. 그리고 정리된 요구 사항이 내역이 있으면 전달해 달라고 요청하였습니다. 파스토에서는 최종본은 없고 지금 정리 작성하고 있는 요구 사항 문서는 있는데 빠진 것이 많아 일단 메일로 전달하고, 다시 추가 정리되면 내용을 보내 주기로 했습니다.

 

 

 

밀크런 시스템 기획 시작과 끝 그리고 다음

  

첫 미팅 내용을 정리한 부분과 메일로 받은 빠진 부분이 많은 요구 사항 문서를 바탕으로 일단은 전체 밀크런 시스템을 설계하였습니다. 

 

물류, 풀필먼트 시스템 기획을 해 본 적도 없는데 처음 듣는 물류 개념인 밀크런 시스템을 어떻게 설계할 있는지 궁금할 수 있을 것 같습니다. 그래서 기획자에게는 창의력이 필요하다고 제가 주장하는 것입니다. 

 

저는 이번 프로젝트에서 밀크런이라는 말을 처음 들었습니다. 그런데 밀크런 시스템을 설계했고, 파스토와의 이번 프로젝트가 여러 사정으로 투입도 못되고 중단 되었지만, 파스토는 이 개발사에게 다음 프로젝트를 같이 하자 제안하면서 기획자를 투입해 달라고 요청하게 된 것입니다.

 

이렇게 파스토가 개발사에게 밀크런 프로젝트 중단을 알리면서도 1달 후에 있을 다음 프로젝트에 기획자를 넣어 달라고 한 것은 제게 설계하여 전달한 밀크런 프로세스 설계도가 나쁘지 않았다는 것을 의미한다 생각합니다.

 

아니 개발사는 인력을 투입도 못하고 개발사 사무실에서 작업한 내용만 전달하여 비용을 받지 못할까 걱정을 하고 있었습니다. 이미 저를 포한한 PM, 개발 PL 3명 분의 인건비는 나갔기 때문입니다. 그런데 파스토는 개발사의 이런 걱정이 무색하게 다음 프로젝트 참여를 요청한 것입니다.

 

그것도 기획자만 말입니다.

 

파스트 밀크런 프로젝트는 제대로 시작도 못하고 끝났습니다. 그래서 개발사는 그동안 쓴 인건비용도 못 받을까 걱정했는데 다음 프로젝트가 연결된 것입니다.

 

파스토와 다음 프로젝트 가능하게 한 기획 프로세스는 다음과 같습니다. 일단 밀크런과 관련해서입니다.

 

1. 밀크런 개념 정리
2. 기존 밀크런 시스템에 대한 타사의 설명 내용 검토
3. 파스토 요구 사항 정리
4. 밀크런 기능 정의서 작성
5. 밀크런 관련 시스템 구성 내용 정리
6. 기본 밀크런 프로세스 설계
7. 기본 프로세스 하위 구성 프로세스 도출
8.  몇 개의 하위 프로세스 설계
9. 밀크런 알고리즘 상 부족한 부분과 모호한 부분 체크

 

진행한 밀크런 관련 기획 세부 내역은 파스토 보안 사항일 수도 있어 일단 과거 일부 내용을 빼고 정리하여 올린 내용을 참고하여 주십시오.

제가 작업한 내용이 파스토 입장에서 중요하지 않을 수도 있습니다. 그러나 대부분의 기획의 설계는 고객 시스템 및 전략/전술의 중요한 부분을 다루는 경우가 많아 함부로 공개하면 문제가 될 수 있습니다.  

 

물론 많은 SI나 웹에이전시에서 기획자에게 과거 기획 내용을 포트폴리오로 요구하고 제출하기도 합니다. 이 경우는 대부분 화면 기획을 의미합니다. 과거 진행한 화면 설계는 앱이나 웹이 론칭되면 누구나 아는 부분이기에 포트폴리오 제출이 가능합니다.

 

그러나 시스템 설계, 프로세스 설계의 경우 앱이나 웹을 론칭했다고 해서 이용한 사용자 누구나 아는 것은 아닙니다. 이는 개발 코드 이상 보안 등급이 높은 자료입니다. 

 

시작하기 전에 멈춘 파스토 밀크런 프로젝트의 예로 살펴보는 기획

시작하기 전에 멈춘 파스토 밀크런 프로젝트의 예로 살펴보는 기획

   

이커머스 밀크런 서비스 기획 연습

이커머스 밀크런 서비스 기획 연습

 

      

 

개발 기획 방법론

 

마지막으로 시스템 개발 기획 방법론에 대하여 간단히 정리하고 마치겠습니다. 여기서 시스템이란 ERP 같은 BTOB 뿐 아니라 앱/웹 같은 BTOC 등 최종 개발 시스템 외에 이에 활용되는 중간 시스템도 모두 포함합니다. 공통 개발 기획 방법론을 이야기하는데 예시 사례가 단지 밀크런일 뿐 다를 것은 없습니다. 

 

그럼 간단하게 방법론에 대해 정리해 보겠습니다.

 

 

 

시스템 개발의 목적과 무엇인지 파악

 

간단히 무엇을 위한 시스템인지 파악해야 합니다. 이를 위해서는 해당 시스템이 작동되는 영역의 비즈니스 도메인에 대한 어느 정도 지식은 확보해야 합니다.

 

기본적으로 시스템 구성 요소와 작동 및 피드백 결과를 이해하기 위한 것은 물론 개발을 위한 고객과 커뮤니케이션을 하기 위해서는 해당 시스템 비즈니스 도메인 지식은 필요합니다.

 

그렇다고 사업 기획이나 서비스 기획을 위한 수준까지는 아닙니다. 단지 대화를 이해하고 개발적으로 적용하기 위한 정도의 지식은 반드시 필요합니다.

 

그러나 이러한 사전 스터디는 기획자의 프로젝트 내용을 보면 너무 당연한 것입니다. 아무리 동일 분야에 똑같은 시스템만을 개발해 온 기획자라도 기술 트렌드나 신기술뿐 아니라 시장 참여 기업들의 개발 상황에 따라 개발 상황은 변화하게 됩니다. 신규 사업 분야 개발을 기획하는 것은 당연히 새로운 비즈니스 분야에 대한 시스템을 개발해야 하므로 스터디해야 하는 것은 당연합니다.

 

하늘 아래 시간의 흐름 속에 살아하고 비즈니스 하는 상황 속에 기획적으로 똑같은 상황은 절대 존재할 수 없습니다.

 

 

 

시스템 구성 요소 추출 및 구조 배치

 

처음 기획자가 요구 사항을 분석하는 이유가 여기에 있습니다. 시스템이 어떻게 작동되는지, 어떤 구성 요소들로 이루어졌는지 모른다면 개발은 불가능합니다.

 

앱이나 웹 사이트처럼 때로는 참고할 화면이 이미 시장에 있을 수도 있습니다. 그렇다고 이 화면이 어떻게 작동되는지는 알 수 없습니다. 그래서 과거 경험과 지식 그리고 이를 다시 통합하여 추론하여 논리를 재 구성할 창의력이 필요한 것입니다.

 

아마 참고 앱/웹 화면을 보고 과거 개발 경험을 바탕으로 기획한다면 그 앱/웹은 이상하게 잘 작동되지 않을 것입니다. 과거의 그때와 지금의 개발 구성이 다르고, 참고 앱/웹 기업의 자원과 지금 개발하는 기업의 자원이 다르기 때문입니다.

 

심지어 참고 앱/웹은 개발 순간 원형이 아니라 서비스 운영에서 나오는 피드백을 바탕으로 계속 업그레이드 한 결과물일 수도 있습니다. 또한 이를 한 번에 개발한다는 가정조차 여러 시간에 걸쳐 정리된 복잡성을 단시간에 압축 개발하는 것은 과도하게 복잡성을 높이는 것이어서 개발 난이도 및 안정성을 위협하게 됩니다.  

  

개발도 그렇지만 기획도 복잡도를 낮추는 것이 실력입니다. 

 

최근 테슬라가 자율 주행에 AI를 적용하면서 수 만 줄의 코드를 획기적으로 줄인 사실을 발표하였습니다. 코드를 줄였다는 것은 같은 작동을 기준으로 버그 가능성을 줄였다는 것과 반응 시간을 줄였다는 것을 의미합니다. 이는 시스템 안정성과 UX에 획기적 향상을 의미하기도 합니다.

 

여기서 가정은 과거와 같이 작동이 된다는 것이 존재합니다.

 

 

 

프로세스

 

시스템 프로세스는 작동 과정이라는 측면에서 두 가지 입장이 있습니다.

 

• 하나는 사용자 이용하는 프로세스입니다. 이 또한 시스템이 작동되는 흐름에 따른 상호 작용 내용을 의미합니다.  
• 둘은 정보의 입력과 처리되는 프로세스입니다. 기능은 작동되고 사용자가 원하는 결과를 시스템을 통해 받아 볼 수 있게 하는 처리 논리 흐름에 대한 것입니다.

어떤 기준으로 시스템 프로세스를 설계하느냐에 따라 조금씩 다른 표현이 이루어질 것입니다. 하지만 앞서 시스템 개발의 목적과 시스템이 무엇인지 정의, 목적 달성을 위한 시스템 구성 요소와 각 변수들의 상호 관계 속 배치에 대해 정리되었다면 시작 관점은 다를 지언적 결과물의 수준은 비슷해질 것입니다.

 

여기까지 왔다면 스토리보드를 그리는 것은 어려운 일이 아닙니다. 이 정도까지 기획했으면 2024년 출시되는 생성형 AI가 알아서 스토리보드는 그려줄 수도 있을 것이라 생각 듭니다. 

 

앞으로 기획자의 창의력에 대한 요구는 더 커질 것입니다. 바로 생성형 AI 때문입니다. 기억에 의존하는 과거 기획 지식, 시장에 나와 있는 레퍼런스 앱/웹 화면 등은 이미 생성형 AI에 대해 더 잘 수집하고, 파악하고, 정리될 것입니다. 이를 통해 화면 설계하는 것은 아마 AI가 다 해줄 것이라 생각합니다.

 

그럼 기획자는 무엇을 해야 할까요?

 

개발의 핵심이자 많은 비용이 투입되는 코딩에 있어 구글 관련 뉴스 중 제미나이(Gemini) alphacode2에서는 사람 개발자의 85% 수준까지 능력이 향상되었다는 것 또한 있습니다. 수학, 물리를 적용한 코딩 또한 구글 발표에 따르면 제미나이(Gemini)는 평균의 개발자를 뛰어넘었다고 합니다.

 

먼저 공개되어 선풍적 관심을 끌었던 chat GPT에서는 PPT도 만들어주고 이미지나 영상도 만들어주는 등의 기능은 보여 주었습니다. 유튜브에 나와 AI를 설명해 주는 교수님 말로는 이제 더 이상 chat GPT 같은 AI로 인해 조교가 필요 없어졌다는 말이 나오기도 한 것을 보았습니다.

 

결국 아무리 전문적 일이라도 기억에 의존하거나, 계산을 잘하거나 하는 등의 것은 이제 AI가 대체할 것으로 보입니다. 그러므로 코딩의 경우도 많은 사람이 아닌 핵심적인 개발자 몇 명과 AI만 있으면 충분히 개발이 가능하게 될 것으로 보입니다. 개발자는 설계하고 AI 명령하여 나온 코드를 검토하고 다시 인공 지능에 수정 명령하는 형식으로 개발 프로세스가 변할 수도 있습니다.

 

기획의 경우도 요구 사항을 분석하고 기능정의서나 화면정의서로 정리한 후 스토리보드를 그리는 것은 AI로 다 대체될 수 있을 것이라 생각됩니다.

 

사람인 기획자는 창의적 시스템을 구성하고 프로세스를 설계하는 정도의 일만 하게 될 것입니다. 개발 분야에서 이 기획조차도 언젠가는 AI가 더 잘하게 될 것 같기는 합니다. 몇 년 내 IT 서비스 관련 기획은 사업 기획과 서비스 기획만 하여 자료를 AI에 입력하면 알아서 앱/웹 설계를 해주는 날도 멀지 않은 것 같습니다.

 

그러므로 기획자에게 앞으로 요구되는 것은 벤치마킹이나 트렌드를 따라 화면을 설계하는 것이 아닌 더 창의적인 기획을 하는 것이라 생각합니다.

 

위에서 제가 시스템 개발 기획 관련하여 프로세스를 정리했다면, 그리고 이 프로세가 논리적을 합당하다면 이는 이미 AI 대체 가능성이 존재하는 일인 것입니다. 구체적 방법론과 공통 체계가 있다는 것은 AI가 학습하기 더할 나위 없이 좋기 때문입니다.