모바일 청첩장 서비스 개발(1)

옒·2022년 9월 28일

Project

목록 보기

8/11

모바일 청첩장 서비스 개발하면서 겪은 내용을 적어보려 한다. 아직 현재 진행 중이라 띄엄띄엄 올라올 것이다.

먼저 디자이너의 역할을 내가 맡았기에 피그마부터 공부했다. 기능을 공부하고 디자인하면서 나름 자주 쓰이는 부분은 디자인 시스템으로 등록하고 컴포넌트도 분리해뒀다. 여기서 잘 못하면 어차피 개발할 때 내가 힘드니까 코딩할 때 편할 수 있도록 하려고 노력했다.

광고물만 해봤지 UI 디자인을 해본 적이 없어서 모바일에서 자주 사용되는 글자 크기 등 디자인 관련 내용도 찾아볼 것이 많아 2주 정도 걸렸다.

내가 디자이너 겸 프런트엔드 개발자였기에 두 가지 일은 동시에 진행될 수 없었다. 그래서 개발을 시작할 땐 이미 시간이 어느 정도 흐른 뒤였다.

개발을 시작하며 프레임워크를 선택하려 했다. 바로바로 오류를 알려주는 게 좋아 타입스크립트를 사용하고 리액트와 next.js 중에서 고민했다.

정보를 찾다 SSR과 CSR을 알아봤고

이런 이유로 모두 가능한 next.js를 선택했다.

상태 관리 도구도 고민했는데 업데이트가 많지 않고 단순히 props drilling을 그만두고 싶은 경우라면 context API만으로도 충분하다고 해서 다른 툴은 사용하지 않기로 했다.

처음에는 백엔드랑 API 응답 형식을 정하고 개발을 시작하려 했었는데... 상황상 그게 안돼서 직접 데이터 형태를 정하면서 개발하기로 했다.

내가 데이터 형태를 만드는 게 낯설어 바로 볼 수 있게 하려고 데이터가 사용되는 컴포넌트마다 상단에 객체로 선언을 해뒀는데 이게 나중에 수많은 코드 수정을 불러왔다.

상품이 되는 모바일 청첩장을 생각해 보면 사용자들은 그냥 스크롤 하면서 구경할 뿐이다. 방명록을 제외하곤 그냥 서버에서 받은 데이터를 렌더링 하는 게 끝이어서 props drilling이 세 단계 이상 나오지 않을 거라 예상했다.

경험이 적은 사람이 그렇게 쉽게 생각해선 안됐던 건데...............😭

컴포넌트를 분리하다 보니 예상보다 뎁스가 깊어졌고 전역 상태로 관리하고 필요한 부분에서 해당 데이터를 커스텀 훅으로 가져오는 게 좋을 것 같았다.

이때서야 상태 관리 도구를 어떤 걸 사용할지 고민했고 나는 context API 밖에 사용해 보지 않은 상태였다. 그래서 사실 다른 도구 사용해 보고 싶었는데 우리 프로젝트가 그렇게 크지 않아서 고민이 됐다.

그래서 찾아봤더니 업데이트가 많지 않은 경우와 리덕스에서 제공하는 기능들이 필요하지 않으면 context API로도 충분하다고 해서 이번에도...다른 도구는...안녕....그래...useReducer도 잘 안 써봤으니까...

그런데 여기서 문제가 생겼다. 사실 모두 느끼고 있었던 부분인데... 우리 제품이 상품성이 없어 보인다......ㅎ...출시까지가 목표인데 너무 큰 흠이 아닌가?

일단 꼭 필요한 부분을 출시하고 소비자의 피드백을 듣고 고치면서 점점 추가하라고 하는데 꼭 필요한 부분을 만들면...경쟁력이 너무 없어 보였다.

우리가 가설도 세우고 일단 먼저 팔고 하려고 아무리 생각해 봐도 우리 제품을 살 거라는 가설이 세워지지 않았다.

다른 업체들은 이미 식전 영상이나 다른 제품으로 웨딩 업계에 있으면서 고객을 모으기 위해 모바일 청첩장도 하는 건데 자본이나 제공되는 서비스나 다 너무 빈약했다. 그렇다고 차별화된 것도 아니고.

그래서 결국 엎기로 했다. 내 노동력...내 포트폴리오...라는 생각이 안 들었다면 거짓말이다.

하지만 처음이었던 우리에게 일어날 수밖에 없는 시행착오가 아니었을까 생각한다. 더 좋은 서비스를 만들기 위한 선택이니까.🥹

엎었다는 게 끝이라는 게 아니고 기획을 다시 해보기로 했다. 모바일 청첩장이라는 아이템은 동일하지만 "다른 업체가 제공하지 못하는 경험을 우리가 제공하자"라는 밑바탕으로 다시 생각 중이다.

앞에서 일단 해보자라고 시작했다 지금 상황으로 온 것이기 때문에 이번엔 시간이 더 걸리지 않을까 싶다.