[항해99 PM코스] 실전 프로젝트 찐후기 / STEP2. 개발 (우선순위설정 / 화면기획 / 개발)

안녕하세요! 연이음입니다.

오랜만에 블로그 포스팅으로 다시 찾아뵈었네요ㅎㅎ 요즘 저는 참여하고 있는 프로젝트가 우다다다 굴러가면서 바쁜 하루하루를 보내고 있는데, 오늘은! 시간을 내어 지난 글의 뒷 이야기를 소개드리려 해요☀️

 

지난 기획 step 1에서 문제정의 이후 mvp에서 검증하고자 하는 가설/목표 수립까지 이야기드렸는데요,

어떤 내용인 지 궁금하시다면 아래 글을 읽어보고 오시는 걸 추천드립니다! 왜냐..이번 글은 굉장히 재미있을 예정이기 때문 😈

이번 글에서는 mvp기능의 우선순위 설정, 화면기획, 개발 프로세스를 중심으로 소개해드릴게요. 특히 저는 이번 프로젝트에서 기획과 함께 개인 R&R로 개발을 담당했는데요, 약 일주일 안에 개발하고 빠르게 배포하였어요. 제가 웹플로우로 노코드 개발을 하면서 빠르고 효율적으로 개발하기 위해 어떤 것들을 고민했는 지도 자세하게 정리해보았어요 :)

 

MVP 기능의 우선순위 설정

📌 주요가설 : 사용자는 반려동물과 이별 이후 원하는 장례식장을 찾기 위해 산재되어 있는 장례 업체 정보를 한눈에 비교했을 때, 업체 문의 전환율이 30% 이상일 것이다.

 

저희 서비스는 반려인들이 이별의 순간에, 산재되어 있는 동물장례식장 정보로 업체를 선택하는 데 어려움을 겪고 있다는 문제를 설정했고, 이에 대해 산재된 정보를 모아주고 정보 비교를 비교하도록 돕는다는 가설을 설정하였어요. 따라서 Mvp 단계에서 이 핵심 가설을 검증하기 위해서 어떤 기능을 우선적으로 기획/개발할 것인지에 대한 의사결정이 필요했습니다. 저희는 빠르게 개발하여 지표를 보며 개선하자는 목표가 있었기 때문에 개발기간을 일주일로 설정하고, 가설 검증을 위해 Mvp 에서 꼭 전달하고자 하는 서비스의 가치에 집중했어요.

 

핵심 가치제안

👉 핵심가치제안 : 신뢰할 수 있는 정보의 손쉬운 비교 경험

 

저희가 해결하고 싶은 유저의 페인포인트를 쪼개었을 때, 핵심적으로 해결해야 하는 문제는 두가지로 나눌 수 있었어요. 따라서 mvp 에서는 이 두가지 문제해결에 집중하여, mvp 솔루션의 우선순위를 설정하였습니다.

• 합법/불법업체의 혼재로 인한 선택의 어려움 -> 합법업체 정보만 제공
• 산재된 업체 정보로 인한 비교의 어려움 -> 필터링 / 일관된 기준 설정

 

기획문서작성

DB 정보수집

저희는 정보를 제공하는 서비스이기 때문에, 정확하고 꼭 필요한 정보를 담고있는 데이터베이스 구축이 우선적으로 필요했습니다. 이를 위해 각자 파트를 나누어 동물장묘업 등록시스템 정보를 기반으로 국내 수도권의 ‘합법 동물장묘업체’를 정리한 뒤, 각 업체별로 제공하고 있는 서비스를 엑셀 시트에 모아서 정리했어요.

 

주요 고려사항

 

1. 합법업체 스크리닝

: 합법 장례업체 정보만 제공한다는 것이 1차 가치제안이기 때문에, 이 과정에서 문제가 없도록 ‘장묘허가’ 관련 정보를 업체별로 철저하게 스크리닝하였습니다.

 

2. 정보의 공통기준 도출

: 업체별로 제공하는 서비스와 가격 테이블이 모두 다르기 때문에, 업체 DB는 초안→ 2차 → 3차…..이렇게 공통 기준을 도출하여 분리하고 그룹핑하는 과정을 반복하며 유저들에게 전달할 정보DB를 구축해나갔어요.

 

기능요구사항 정의 (PRD 작성)

이후 Mvp 기능 개발에 필요한 요구사항을 정리하였어요. 이 문서는 사실 이후 와이어프레임을 그리면서 지속적으로 수정되었는데요, 문서 자체를 완벽하게 작성하는 것이 목적이라기보단, 문서를 작성하며 팀원들과 의견을 모으는 데에 보다 집중했어요. (개인적인 생각인데) 화면을 그리면서 이야기를 나누면 생각이 화면 안에 한정되는 경향이 있기도 해서, 문서를 바탕으로 논의했을 때는 화면 단위에 한정되지 않고 좀 더 디테일한 부분을 챙길 수 있었던 것 같습니다. (다만 이렇게 문서작성하는 프로세스가 비효율적인 부분도 있어서, 요즘은 와이어프레임과 하나로 합쳐 진행하는 경향도 크더라고요!) 

 

 

와이어프레임 (화면기획)

이렇게 작성된 기능명세서를 바탕으로 프론트에 노출되는 화면을 기획하였습니다. 저희는 모두 기획자이기 때문에 디자인/개발의 역할이 분담되어 있다고 해도 모두 기획맥락을 알고 있었는데요, 이에 따라 PRD 문서를 작성한 이후의 소통은 피그마를 활용하여 기획-디자인-개발의 커뮤니케이션 리소스를 최대한 줄이고자 했어요. 이를 위해, PRD를 바탕으로 타이틀 바로 플로우별 화면을 묶어 플로우를 확인할 수 있도록 하고, 화면별로 공유되어야 하는 설계내용을 추가하여 모두가 화면별 기획을 한눈에 파악할 수 있도록 했어요.

IA (정보구조도) / 플로우차트 작성

 

기능명세서를 바탕으로 IA, 플로우차트를 작성하였어요. IA를 통해 작성하여 구성되는 정보의 연관성을 빠르게 파악할 수 있었고, 플로우차트를 기반으로 플로우가 자연스러운지 체크하고 흐름상 엣지케이스를 미리 고려해볼 수 있었어요. 이후 저는 DB설계초안을 작성하였는데요, 정보구조도와 DB초안을 비교하며 테이블간 연관성이 효율적으로 설계되었는 지도 함께 파악할 수 있었습니다.

 

DB 구축

저는 프로젝트의 세부R&R로 개발을 담당하였는데요, DB 정보값들이 모아진 문서를 기반으로 데이터베이스 기본구조를 설계하고 관련 문서를 작성하였어요. 저는 개발자가 아니지만, 이 과정을 통해 PM으로서 정보값들의 데이터 속성과 기능구현을 고려하여 좋은 데이터베이스를 설계하는 법에 대해 고민해볼 수 있었고, DB와 프론트가 어떻게 연결되는 지를 보다 명확하게 알아갈 수 있었던 정말 좋은 기회였어요😊 

 

DB 구조 설계시 고려한 점

저는 리스크를 최대한 잘..관리하면서 (그러면서도 빠르게..) 일하는 걸 좋아하는 사람이라, 현업 개발자들은 좋은 DB를 설계하기 위해 어떤 요인을 우선하는 지 찾아보았어요. 이 과정에서 '파워 오브 데이터베이스'의 저자인 20년 경력의 개발자 마이클 J. 헤르난데즈를 알게되었는데요, 그는 좋은 데이터베이스를 설계하기 위해선 다음 세가지 목적을 반드시 고려하라고 말합니다. 저 역시 포옥 서비스 DB를 설계 시 이 세 원칙을 염두하였어요. 

1. 무결성 - 데이터베이스 내에 모든 값은 언제나 정확한 값을 유지할 것
2. 유연성 - 데이터베이스 구조는 요구사항 변화에 대한 수정이 쉬울 것
3. 확장성 - 데이터베이스 구조는 기능 확장에 대한 수정이 쉬울 것

 

DB 구조 설계

1. 예비 필드/ 테이블 목록 작성

먼저 어떤 데이터가 수집되고 어떤 데이터 노출이 필요할 지 예상하면서 예상되는 테이블 별로 필드 목록을 작성하였어요. 이 때 앞서 작성한 와이어프레임과 IA 문서를 적절히 참고하였고, 팀원 공유를 위해 문서에 표시해두었어요.

 

 

 

 

2. 테이블 관계 설정

예비 테이블 목록을 기반으로, 테이블간 관계를 정의해주며 테이블 구조를 보다 촘촘하게 설정했어요. 하나의 필드 안에 여러 속성이 포함되거나, 중복되는 경우에는 확장성과 유연성을 고려하여, 이후 업데이트나 수정이 수월하도록 최대한 관계형 테이블로 정리해주었어요.

관계형 테이블 설계 시 ‘일대일 관계’, ‘일대다 관계’, ‘다대다 관계’ 가 헷갈릴 때는 아래처럼 질문하며 관계를 정립해나갔어요. 

✔️ A라는 테이블의 하나의 레코드가 B라는 테이블의 몇 개의 레코드와 연관될 수 있을까?
1) 일대일관계 - 하나당 하나씩 연결 → Reference 필드
2) 일대다/다대다 - 최소 0개부터 여러개 연결 → Multi-Reference 필드

 

예를 들어 포옥 서비스의 업체 테이블에는 권역 필드가 포함되는데요, 권역은 가설검증을 위한 테스트의 일부였기 때문에 이후 변경이 필요할 때 필드를 하나씩 수정해줘야 하는 어려움이 있을 거 같았어요. 따라서 권역 테이블을 따로 만들고 업체 테이블과 일대일 관계를 맺어주어 해결했어요. 실제로 권역은 이터레이션을 거치며 세분화되었는데요, 이때 권역 테이블 내의 필드만 변경 해주면 되었기에 훨~씬 수월했습니다.

또한 태그, 주요 서비스, 특이사항과 같이 업체별 특징을 보여주는 부분은 mvp 주요 가설에 따라 자주 변경되며 테스트 될 수 있고, 업체가 새로 정보를 업데이트함에 지속적으로 확장될 부분이라고 판단했어요. 따라서 별도 테이블로 빼주고 업체 테이블과 일대다 관계를 맺어주어 노출되는 내용이 변경되어도 빠르게 대응할 수 있도록 했습니다.

 

 

이후 개발까지 진행하면서 느낀 바로는…이렇게 테이블 구조를 짠 것이 90% 는 적절한 선택이었고 가설검증도 무리없이 진행할 수 있었어요! 다만 한가지 아쉬운 선택도 있었는데, 웹플로우 환경상 일대다/다대다 관계 설정 갯수에 제한이 있었는데요, 기능적 한계를 사전에 인지했다면 다양한 태그를 제한없이 보여주기 위한 테이블 설계 방식도 함께 고민해볼수 있었을 것이라는 아쉬움이 있었습니다. 처음엔 DB구조가 프론트와 어떻게 연결되는 지 감을 잡는 데 시간이 걸렸지만 점점 초반 설계의 중요성을 느끼면서, PM은 기본적인 서버 구조와 개발 환경을 꼭 알고 있어야 한다는 생각이 들었습니다.

 

CMS (Content Management System) 작업

테이블 별로 DB 정보값 정제

이후 테이블에 따라 처음 수집한 DB 정보값들을 분리 배치하고, 정제하는 작업을 거쳤어요. 저희는 합법업체를 스크리닝하는 과정이 필요하고 베타 서비스는 수도권 기준으로 진행하여 업체수가 많지 않았기 때문에 따로 크롤링을 하진 않았어요. 이에 따라 팀원 모두가..분배하여 정보를 분리하고 정제했습니다. ㅎㅎ 다른 팀은 크롤링을 해서 가져오기도 하던데, 저희는 고민없이 휴먼러닝을 선택한 것이 좀 더 빠르고 효율적이었던 것 같아요. ㅎㅎㅎㅎㅎ

 

 

이렇게 정리된 정보들을 웹플로우 CMS (DB) 에 넣어두는동안, 저는 본격적으로 프론트 개발을 시작했습니다.

 

프론트엔드 개발

개발 환경 세팅

디자인-개발까지 일주일이라는 기간에 맞춰 출시하기 위해, 프로젝트를 병렬적으로 진행할 필요성이 컸어요. 이에 따라 저는 디자인이 완료되는 동안 개발 환경을 먼저 세팅해두며, 두가지 작업을 진행했어요.

1. 기본 화면 구조 개발

: 먼저, 와이어프레임을 바탕으로 기본 화면 구조를 개발해두고 디자인이 완료되었을 때 바로 시안을 입힐 수 있도록 준비해두었어요.

2. 스타일 시트 개발

스타일 시트를 작업한 이유는..? DB 구축과 마찬가지로, 프론트개발 시에도 제가 최우선으로 고려했던 점은 한 가지였기 때문이에요. 

 

변경과 확장에 최대한 빠르게 대응할 것_…… → 비효율을 지양할 것

저는 디자이너 출신이다보니, 이후 컬러값이나 폰트 크기 등 디자인이 (99%확률로) 변경될 때 해당 스타일이 적용된 부분을 일일이 변경해주는 건 너무 (하기싫은) 비효율적이라는 것을 몸소 알고 있기에… 팀 내 디자이너님과 디자인 시스템 작업이 선 진행될 수 있도록 합의 후, 스타일 시트를 먼저 만들었어요. 웹플로우에서 디자인시스템을 만든다고? 라고 놀라실 수 있지만..다 가능했어요ㅎㅎ

 

이렇게 스타일가이드 페이지를 별도로 만든 뒤, 사용되는 색상이나 타이포그래피, 버튼 형태를 미리 제작하여 클래스를 지정해나갑니다. 스타일 시트를 먼저 만들면 크게 두가지 이점이 있었어요.

 

1. 디자인 변경 및 업데이트에 빠르게 대응

- 피그마에서 디자인 시스템을 만들고 관리하는 것과 동일한 원리인데요, 디자인시스템을 기반으로 웹플로우에서 미리 스타일을 제작하여 모아두고, 이를 한 페이지에서 관리했을 때 추후 해당 부분만 변경해주면 전체에 적용되어 빠르게 업데이트에 대응할 수 있습니다.

 

2. 일관된 기준으로 클래스 관리

- 웹플로우는 스타일을 ‘클래스(class)’로 지정하여 저장하는데요, 각기 다른 스타일마다 다른 클래스를 적용하다보면 클래스가 무한정 늘어나 서비스 속도나 성능에 지장을 주게 됩니다. 스타일 시트를 먼저 만드는 작업은 클래스 추가 시 일관된 규칙으로 명칭을 지정하도록 도와, 추후 개발 시 수많은 클래스를 빠르게 적용하는 데 도움이 됩니다.

- 또한 콤보클래스, 차일드 속성을 적절히 사용하며 보다 일관된 규칙을 가지고 작업할 수 있기 때문에 클래스가 무한정 늘어나는 것을 방지할 수 있습니다.

 

 

배포 전 진행사항

개발이 마무리된 이후에도 몇가지 작업이 남아있었는데요, 크게 QA 와 서비스 검수를 진행했습니다. 저는 팀원들과 함께 진행할 QA를 위해 테스트 케이스 문서를 작성하고 퍼포먼스 체크 등 서비스 검수 및 디자이너님과 디자인 검수를 진행하였어요.

QA

먼저 테스트 케이스 문서를 작성했어요. 테스트 케이스 작성 시에는 이 문서를 통해 현 mvp 단계에서 무엇을 중점적으로 확인할 것인지 고려하며 작성하고자 했어요. 이유는 저희 팀의 QA는 디자인/기능검수와는 별개로, 기획과 가설이 제대로 구현되었는 지를 확인하기 위한 목적도 포함되었기 때문이에요. 이에 따라 QA할 기능과 테스트 플로우를 모두 목록화하되, 노란색 블럭으로 가설검증과 연관된 부분을 표시하여 해당 플로우가 가설 검증을 위해 유효한 지를 함께 확인하고자 했습니다. 이를 통해 저희가 mvp에서 사용자에게 최우선으로 전달하고자 하는 가치가 제대로 제공될 수 있는 지 한번 더 짚어볼 수 있었어요.

 

서비스 검수

 

이후 공동으로 검수해야 할 목록과 개발 별도 검수 목록을 작성하고 확인하였어요. 이 과정에서 SEO를 위한 H1태그 확인 및 페이지 구조, OG title 및 image, 사이트 품질 향상을 위한 작업 (로딩속도, 접근성, tag네임, alt text 설정 등), 구글 애널리틱스 연동 및 이벤트 확인 작업을 진행하였어요. 개발을 진행하며 최대한 구조화에 신경쓰긴 했지만, 한번 더 확인하며 서비스 체크 후 서비스 성능을 99까지 끌어올렸네요..ㅎㅎ

 

 

 

MVP 출시

그렇게 일주일간 DB구축부터 프론트엔드 작업까지 뚝딱뚝딱 만들고, 포옥 서비스의 mvp를 출시하였습니다. Mvp 우선순위에 따라 기능을 기획한대로, 자체 DB를 구축하여 산재된 정보 중 합법업체만 제공하고 업체별 정보를 일관된 기준으로 모아주었고요. 유저가 업체 선택 시 최우선기준이었던 지역(위치), 장례가능시간 및 픽업 유무를 1차 mvp에서 주요 필터링 옵션으로 제공하였어요.

 

이렇게 mvp 핵심 기능에 집중하여 기획/개발하니 정말 빠르게..출시하고 이후 마케팅 및 개선액션에 좀 더 집중할 수 있었습니다. 다음 글에서 어떤 식으로 저희가 마케팅을 진행하고, 또 서비스를 개선하였는 지 소개해드리겠습니다. 그럼 이만!!