안녕하세요 NOT-ERROR-064팀의 백엔드 개발자이자 前서비스기획자 황윤준입니다.
저희는 코드스테이츠 백엔드, 프론트엔드 수강생이 모여 현재 맞춤형 채식 쇼핑몰 프로젝트를 진행하고 있습니다. 저희 팀은 기획-개발 설계 과정을 거쳐 실제 구현 과정으로 들어와있는 상태인데요, 정말 어느 과정이든 쉽지 않은 것 같습니다. (팀원들 진짜 고생 많이 하고 있어요…..)
이번에는 조금 늦었지만, 저희 팀이 진행한 IT기획 전반에 대한 과정을 담고 어떤 기획물이 탄생하게 되었는지 남겨보도록 하겠습니다.
What to do?
일단 기획을 하기 위해선 기획의 재료인 ‘아이디어(Idea)’가 필요합니다. 기획은 영어로 Planning이나 Design이라고 하는데, 아이디어를 계획(Planning)하고 디자인(Design)하는 과정이 바로 기획이라고 생각합니다.
IT 기획은 ‘아이디어 발견(Ideation) → 비즈니스 모델 개발(BM) → 서비스 정책 정립(Service Policy Defining) → IA, 요구사항정의서, 메뉴트리, 플로우차트 제작 → 화면설계서/와이어프레임, 프로토타입 제작 → 개발’의 대략적인 과정으로 나눌 수 있습니다. 여기서 비즈니스 모델 개발을 제외한 나머지 과정을 대략적으로 프로젝트에 담았습니다.
이번에 진행하는 ‘채식주의자를 위한 맞춤형 쇼핑몰’이라 아이디어를 제가 어떻게 내게 되었는지 과정을 되짚으며 제가 아이디어를 내는 방식과 이를 구체적인 IT서비스 기획으로 어떻게 연결시켰는지에 대해 이야기 해보겠습니다.
첫 번째. 아이디어 발견(Ideation)
아무리 좋은 아이디어도 현실에 발을 딛지 않으면 아무런 의미가 없습니다.
제가 이번 IT 서비스 기획에서 아이디어 산출시 고려한 점은
- ‘시장 가치’
- ‘프로젝트 팀원들의 비전’
- ‘구현 가능성’
이 3가지였습니다.
시장가치(Market Value): 우리가 프로젝트로 채식 관련 이커머스(E-Commerce)를 선택한 이유
어떠한 서비스도 매출과 이익이 나지 않으면 지속가능성을 가질 수 없습니다. 우리는 자본시장에서 구매할 만한 매력이 있는, ‘시장 가치(Market Value)’가 있는 서비스를 만들고 운영하여 생을 영위합니다. 자본시장의 참여자인 개발자 또한 분명한 시장가치를 지닌 제품(Product)를 개발해야 하는 것이 숙명입니다.
💡 아마 제품의 시장가치와 개발자와는 거리가 멀어보일 수 있습니다. 하지만 개발자가 직접 기획하고 그 매출을 책임지는 일은 없을지는 몰라도 제품이 시장에 나오기 위해 필요한 시간, 금전비용을 최소화하여 개발 비용과 운영 비용을 최소화 하거나, 고객이 원하는 기능과 전략을 회사에 솔루션 형태로 제시하며 시장가치를 만들어갑니다.
시장가치가 있는 제품인지를 알아보는 과정은 ‘시장의 크기(Market Size)’, ‘고객 문제 발견(Customer Problem Definition, Pain Point)’, ‘고객 문제 해결 방안(Problem-Solution Fit)’ 과정을 거칩니다. 채식 관련 이커머스를 이에 대입해보겠습니다.
시장의 크기(Market Size)
물론 중요한건 주제 자체가 시장가치와 맞는 트렌드여야 하겠죠. 그런 의미에서 저는 날로 커지고 있는 채식주의 시장에 주목했습니다. 생태주의적 관점, 동물복지 관점, 환경보호 관점, 건강 관점 등 다양한 생각을 가지고 채식주의를 시작하는 사람들이 늘어나고 있습니다.
위 표에서 보듯 한국의 채식주의 시장은 날로 늘어가고 있습니다. 다만 우리의 채식주의 인프라가 이를 뒷받침 해주고 있을까요?
고객 문제 발견(Customer Problem Definition, Pain Point)
비거니즘, 채식주의를 실천하시는 분 들은 기존 시장에서 제품 가격과, 구입처, 종류에 대한 불만들이 상당히 많은 것을 알 수 있습니다. 다음은 기존 시장 경쟁자인 채식 전문 쇼핑몰의 메인페이지입니다.
분석 정리하자면 모두 비건(Vegan), 즉 엄격한 채식주의자의 식단과 기호에 서비스의 구성과 타겟 고객이 맞추어져 있습니다. 하지만 채식주의자(Vegetarian)는 단순히 엄격하게 채식만 하는 비건(Vegan)만 존재하는 것은 아닙니다.
위와 같이 매우 다양한 욕구를 가진 채식주의자들이 존재합니다
💡이 점에 있어 저는 채식주의자라는 말을 좋아하지 않습니다. 신념의 식습관을 나타내는 단어가 필요하지 않을까요? 하지만 편의성을 위해 앞으로 채식주의자로 모두 통칭하겠습니다.
고객 문제 해결 방안(Problem-Solution Fit)
따라서 이러한 다양한 유형의 채식주의자들의 니즈를 충족시키는 이커머스가 시장가치를 만들 수 있을 것이라는 가설을 세우게 되었습니다. 본인이 설정한 채식주의의 유형을 선택하면 모든 카테고리에서 고객이 설정한 유형이 먹을 수 있는 제품만 노출되어, 자신이 먹을 수 있는 제품인지 늘 공부해야하는 채식주의자들의 고민을 덜어주는 것으로 고객의 문제를 해결합니다.
결론적으로, 저희 팀은 다양한 유형의 채식주의자들의 소비 욕구에 맞는 개인 맞춤형 채식주의 쇼핑몰을 통해 시장가치를 만들어내는 것을 택했습니다.
프로젝트 팀원들의 비전: 왜 이커머스(E-Commerce)인가?
저희는 이 과정에서 기획자이자 개발자이며, 학습자이자 취업준비생이기도 합니다. 저는 개발자 취업준비생인 저희 팀원들이 이 프로젝트를 통해 좋은 포트폴리오를 가지고 취업시장에서 경쟁력을 갖길 원했습니다.
위 표와 같이 IT서비스 시장의 기본은 결국 이커머스에 있기에 첫 포트폴리오로서 이커머스에 대한 이해를 넓히는 주제를 택하게 되었습니다.
IT 서비스 시장에서 결코 빼 놓을 수 없는 것이 바로 이커머스(E-Commerce)죠. 우리가 너무나 잘 아는 서비스인 쿠팡, 아마존, 11번가, 브랜드 자체쇼핑몰, 위메프, 네이버, 11번가, 카카오 모두 이커머스를 통해 성장하였습니다. 따라서 이커머스라는 도메인(Domain, 영역)에 관련한 고민 경험과 지식을 가지고 있으면 팀원들이 더 좋은 경쟁력을 가질 수 있을 것이라 생각했습니다.
구현 가능성: 우리는 ‘개인 맞춤형’ 쇼핑몰을 만들 수 있을까?
처음 개발 프로젝트를 제대로 시작하는 팀원의 역량을 고려해 레퍼런스가 많이 있는 분야가 도전하기에 좋다고 느꼈습니다. 이미 인터넷, 깃허브에 많은 레퍼런스가 있는 쇼핑몰 제작 영역에서 우리들만의 아이디어인 개인 맞춤형 상품 노출을 유려하게 풀어내는 것을 기술적인 고민 영역으로 두어 본 프로젝트를 진행한다면, 기술적 도전과 구현이라는 두 마리 토끼를 잡기 좋은 주제라 여겼습니다. 이것이 바로 ‘개인 맞춤형 이커머스 서비스’인 것이죠.
문제는 ‘개인 맞춤형을 어떻게 제공할 것이냐’인 것이죠. 물론 많은 쇼핑몰에서 개인화된 쇼핑경험을 제공하고 있습니다. 특정 페이지에 머무르는 시간, 상품 유사도, 검색어 분석 등 수많은 고도화 기술을 사용해 고객의 재방문율과 구매를 유도하고 있습니다. 저희는 위와 같은 기술까진 적용하진 못하지만, 상품 노출을 개인의 기호에 맞게 저장한 정보를 이용해 제공한다는 단순하면서 흥미로운 주제를 통해 한정된 기간 안에 완성품을 내놓아야하는 입장에서 구현 가능성을 높였습니다. (물론 앞으로는 위와 같은 기술도 적용해 볼 수 있었으면 좋겠네요 정말로!)
💡아이데이션 정리과정
저희는 협업툴인 지라(Jira)와 연동되어 있는 컨플루언스(Confluence)를 통해 아이디어 문서를 정리하여 공유하였습니다 프로젝트 기획서와 사용자 중심 기획 캔버스, 자료조사, 아이디어 관련 회의 내용으로 정리하여 기획안에 대해 누구든 접근하여 볼 수 있도록 했는데요. 이를 통해 기획의 방향성을 잃지 않도록 하였습니다.
맞춤형 채식 쇼핑몰 아이디어 문서 및 기획서
두 번째. 서비스 정책 정립(Service Policy Defining)
비즈니스 모델을 정립하는 건 창업과 사업기획의 일이기에 넘어가도록 하겠습니다. 지금부터는 추상적인 사업안을 구체적인 서비스로 만드는 ‘서비스 기획’의 단계를 보겠습니다.
서비스 기획의 순서는 회사, 사람마다 다르지만, 저의 경우에는 타사 분석 과정(타사 서비스와 정책 분석, 벤치마킹 요소 발견)이 첫 번째라면, 자사 서비스 정책을 정립하는 것이 두 번째라고 생각합니다. 회원을 어떻게 정의할 것인지, 본 서비스는 어떤 서비스인지, 앞으로 이 서비스를 개발, 운영하며 사용할 용어는 어떻게 통일할 것인지, 회원으로부터 어떤 정보를 받고 어떤 서비스를 어떤 방식으로 제공할 것인지를 결정하는 단계죠.
일반적으로 정책은 고객의 관점에서 필요한 스토리 단위로 구성됩니다. 회원가입에 대한 정책, 회원 로그인에 대한 정책, 제품 구매 정책, 장바구니 관리 정책 등 고객이 실제로 어떤 식으로 서비스를 이용할지를 구상하여 그 고객의 필요에 맞춘 정책을 정의합니다.
맞춤형 채식 쇼핑몰 서비스 정책서&기술명세서
물론 그 과정을 제대로 한다면 정말 긴 문서가 나오겠지만, 이번에 저희는 팀 일정에 맞게 양식을 약식으로 빠르게 정책을 정의할 수 있도록 고치고, 모두 개발자인 점을 고려해 정책에 맞는 개발 명세서를 바로 정의해 놓는 식으로 진행했습니다.
바로 이 정책에 대한 구체화를 통해 필요한 기능이 나오게됩니다. 서비스를 정책으로 나누고 이를 또 정책을 구현하는 기능으로 나누는 구체화 과정인 것이죠. 이 다음 단계가 기능과 화면의 구조를 정의하는 요구사항정의서(Feature Requirements)와 정보구조설계서(IA, Information Architecture) 제작입니다.
세 번째. 요구사항정의서, 정보구조도, 메뉴트리, 플로우차트 제작
세 번째 과정을 알아보기 전 본 과정에서 필요한 지식에 대해 알아봅시다.
정보구조도(Information Architecture, IA)?
서비스 전체의 흐름을 정의하는 구조도입니다. 서비스 정보 체계 내의 네비게이션 체계, 레이블링, 조직화를 설계하는 문서죠. 계층 패턴, 탭 패턴, 허브 앤 스포크 패턴 등 다양한 패턴이 존재합니다. 한국에서는 보통 엑셀을 사용해서 상하위 관계를 나타내는 방식으로 많이 제작하고 있습니다.
플로우차트(FlowChart)?
https://brunch.co.kr/@firstevan/7
서비스 화면 흐름도라고도 하며 사용자가 제품을 어떤 순서로 사용하는지 파악하기 위한 다이어그램(Diagram)입니다.
요구사항정의서(Feature Requirements)?
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=mogni&logNo=220670564871
요구사항 정의서는 고객의 요청사항을 기능별로 정리하는 문서입니다. 일반적으로는 고객사나 서비스기획자가 업무설계 단계에서 요청한 기능 사항을 말합니다. 이 문서로 개발자들이 본인들의 작업을 결정하기 때문에 기획자와 개발자가 소통하는 문서로서 가장 중요한 문서가 아닐까 생각합니다. (물론 화면설계서(스토리보드, Storyboard)도 마찬가지입니다.
이제는 정책에 맞는 실제 기능과 구조, 고객 관점 이용 시나리오(플로우차트)를 그려내야합니다. (점점 우리의 아이디어가 구체화되어 갑니다!). 서비스 구체화를 위한 여러 문서들은 나름의 순서를 가지고 제작합니다. 저는 순서가 정보구조설계서, 메뉴트리 → 플로우차트 → 요구사항정의서 순으로 작성할 때 가장 좋다고 생각합니다. 물론 많은 곳에서 요구사항 정의서를 먼저 쓰는 경우가 많지만 말이죠.
‘정보구조 설계서와 메뉴트리’로 서비스 화면 구성을 그린 뒤, 고객이 사이트를 이용하는 여정에 대해 ‘플로우차트’로 도식화하고 그 여정마다 필요한 기능을 요구사항 정의서에 담는 것이죠. 결국 사용자 경험으로부터 출발해 그것을 기능으로 구체화하는 작업입니다.
물론 한 단계 단계가 모두 완성된 작업으로 한번에 끝나지는 않습니다. 뒷 순서에 있는 기획 문서를 작성하다 보면 앞서 작업한 결과물이나 정책서를 바꾸어주어야하는 경우가 빈번하게 발생합니다. 따라서 늘 확장성과 유연성을 가지고 문서 작업에 임해야 합니다.
저희는 메뉴트리를 제외하고 정보구조도와 요구사항정의서, 플로우차트에 집중하기로 했습니다.
맞춤형 채식 쇼핑몰 FlowChart
로그인 프로세스 예시입니다.
맞춤형 채식 쇼핑몰 IA(Information Architecture)
저희팀은 간단하게 문서형태로 IA를 그려냈습니다. IA에 익숙하지 않은 팀원들을 위해 각 내용에 대한 설명을 달아놓았지만 요구사항정의서와 중복되는 점이 많아 불필요하다고 생각되네요. 다음부터는 메뉴트리 형태로 그리는 것이 가장 좋지 않을까 생각합니다.
맞춤형 채식 쇼핑몰 요구사항정의서
저희는 개발자로서 요구사항정의서를 그리다보니 항목이 조금 더 늘어난 것이 있는데요, 화면별로 나눈 뒤 화면마다 필요한 세부 기능으로 나누었습니다. 그리고 그 세부 기능에 대한 설명과 화면 내 구성 프론트엔드 작업, 백엔드 작업, URI, API URI, 담당자, 완료일자 등으로 다양하게 나누어 저희 팀에 맞게 편집하여 사용했습니다.
네 번째. 화면설계서(스토리보드, StoryBoard), 와이어프레임(WireFrame), 프로토타입(Prototype) 제작
화면설계서(스토리보드, StoryBoard)?
구현하기전에 필요한 기능과 정책을 화면 내의 서비스 모든 요소에 대해 정의하여 서비스 화면 개발 이해를 돕기 위한 문서. 일종의 콘티라 할 수 있으며 와이어프레임을 포함합니다. 현업에서는 주로 파워포인트로 제작합니다.
와이어프레임(WireFrame)?
와이어프레임(’골격’이라고도 함)은 제품을 구성하는 서로 다른 레이아웃을 정적인 로우 피델리티 상태로 재현한 것으로, 간단한 모양만을 사용하여 인터페이스를 시각적으로 묘사한 것. 마치 와이어(선)으로 설계한 모양이라고 하여 와이어프레임이라는 이름이 붙었습니다. 와이어프레임을 그린 뒤 이에 대한 설명과 정책을 붙인 문서를 스토리보드, 화면설계서라 합니다.
프로토타입(Prototype)?
프로토타입은 실제 웹 사이트 또는 앱의 기능과 디자인 세부 사항을 시뮬레이션하는 인터랙티브한 프로토타입입니다. 하이 피델리티 단계의 프로토타이핑은 제품 디자인에 생기를 불어넣는 것으로, 이를 통해 사용자는 앱 또는 웹 사이트에 반응함은 물론 ‘느낌’까지 경험할 수 있습니다.
자 이제 개발 전 마지막 과정입니다. UIUX 디자이너와의 협의를 통해 기능의 화면 내 구성을 정의하고 개별 화면 구조를 그린 뒤 각 기능에 대한 설명을 개발자에게 전달합니다. 채색없이 디자인 뼈대만 있는 그림을 와이어프레임(WireFrame)이라고 하며, 이 것을 기능 설명, 메타데이터과 함께 담아 놓은 문서를 화면설계서(StoryBoard)라고 합니다.
이를 프로토타이핑 툴을 이용해 마치 실제 앱이나 서비스처럼 동작하도록 제작한 것을 프로토타입이라고 하죠. (한 때 어도비 XD 열심히 공부했는데… 많이 까먹었네요)
이전에 정의한 요구사항정의서의 내용을 소통이 쉽도록 구체적인 화면으로 그려내고 이를 프론트엔드 개발자, UIUX디자이너, 기획자, 경영진, 백엔드 개발자(옵션입니다)가 공유하는 것입니다. 서비스의 청사진이 가장 구체적으로 그려지는 과정이며 ‘개발설계/기획’를 위한 마지막 과정입니다.
저희 팀은 프로토타이핑 단계를 진행하지 않고 화면설계서와 와이어프레임 제작만 진행하였습니다.
맞춤형 채식 쇼핑몰 화면설계서(StoryBoard, 스토리보드)/와이어프레임(WireFrame)
스토리보드는 프론트엔드 개발자분께서 그려주셨습니다. 아무래도 프론트엔드에서 주로 볼 문서이기에 프론트엔드 분께서 직접 그리면서 개발사항을 정리하는 것이 가장 효율적인 방법이었습니다.
Conclusion…
이전에 잠깐 서비스기획자로 일했던 경험을 살려 프로젝트 기획에 대한 이야기를 남겨보았습니다. 이번에는 개발자의 시각으로 기획을 접하니 또 새로운 경험이었습니다.
개발자는 구체적인 0과 1의세계에서 프로그램이라는 추상적인 세계로 지향하는 사람이라면 기획자는 추상적인 사업을 구체적인 서비스와 기능으로 나누어주는 구체적인 세계를 지향하는 사람이라는 생각이 드네요. 그리고 그 추상과 구체의 접점에서 서비스 기획자와 개발자가 각종 문서를 통해 만나는 것이죠.
개발자 지망생들이 구체적인 기획을 한다는 것이 정말 어려운일이었지만, 이 과정을 통해 방향성을 확립하고 실제 코딩시에 코딩에만 집중할 수 있도록 하는 설계가 가능했습니다. 사실 이 과정 이후에도 개발 설계가 필요합니다. 백엔드라면 작업 분배, ERD 설계, 클래스 다이어그램 설계, 코드컨벤션 정의, 깃 브랜치 전략, 사용 환경-의존성 설정 등이 있죠.
다음에는 백엔드 개발 설계과정에 대한 이야기를 해보겠습니다. 그럼
'[ Team ] 기획' 카테고리의 다른 글
| [기획] 어떤 기획을 해야 할까? (1) | 2022.09.08 |
|---|