42서울에서 진행하는 42 서울을 위한 프로젝트 개발기

다섯 번째 이야기
📅 (2021 / 03 / 29 ~ 2021 / 04 / 19)

💻 프로토타입 개발 어디서부터 시작…?

기획부터 하나 하나 문서화하면서 결과적으로 시퀀스 다이어그램과 API 명세가 나온 상태에서 개발을 하는 것을 떠올렸었다. 그런데 갑작스럽게 시퀀스 다이어그램과 API 명세가 없이 프로토타입을 개발하게 됐다.

그래서 우리 팀은 프론트엔드와 백엔드팀의 협업을 위한 최소한의 API 명세만 작성하고 각각 개발을 진행하기로 결정했다. 그리하여 지난 번 무결성이 깨진? API 명세를 재활용하고 와이어 프레임을 이용하여 아주 간단한 API 명세를 작성했다. 아래는 작성한 API 명세의 일부이다. 전혀 Restful 하지 않고 아주 단순한 HTTP API 명세이다..😅

HTTP API 명세

기간은 프론트엔드와 백엔드 팀이 각자 필요한 지식을 쌓는 시간과 개발 기한을 합친 2주를 산정해서 진행을 하게됐다.

프론트 팀이 테스트하기 위한 더미서버는 프론트팀이 내부적으로 만들어서 테스트를 해보는 방식으로 얘기가 됐다.

(필자가 프로토타입 백엔드를 개발하면서 공부한 내용은 추후 블로그에 올릴 예정이다.)

당연히도 위에 API 명세로 인한 문제가 빈번히 발생했다. 결정하지 않은 내용들이 부분 부분 들어났다. (이것을 경험하기위해 멘토님이 프로토타입을 만들어 보라고 하신 것 같다..) 이 내용으로 인해 의사결정을 계속하면서 조금씩 개발이 딜레이가 되기도 했다.

프로토타입이 프론트와 백엔드 팀 별로 완성이 되고나서 백엔드에 정적으로 빌드된 프론트엔드 결과물을 넣어 합치는 과정을 진행하면서도 httpOnly와 같은 보안과 실패 케이스의 경우 발생하는 오류와 같은 문제들이 발생했다.

📄 성공 목표와 지표 설정

프로토타입 개발을 진행하면서 성공 목표와 지표 설정에 관한 회의도 같이 진행을 했다.

설정한 MVP를 토대로 개발을 하고 배포를 했을 때 우리 팀의 결과물이 성공적인 인지 아닌지에 대한 피드백 지표이기 때문에 굉장히 난해하면서 어려웠다. 실제 의미있는 지표를 생각하는 것이 가장 어려웠다.

1차원적으로 생각을 했을 때 유저가 서비스를 이용하면서 생기는 트래픽을 떠올릴 수 있었는데, 우리 팀이 정한 서비스는 검색 엔진과 같이 수시로 들어와서 내용을 찾는 것이 아닌 팀 매칭을 예약을 해두고 매칭이 완료됐을 때 결과만 확인하면 되는 서비스이기 때문에 서비스와 맞지 않았다.

그래서 고객보유율/재방문율을 살펴보는 팀 매칭 재 이용률과 품질지수 방향으로 팀 매칭이 끝난후 피드백을 받는 프로세스를 추가하여 고객의 의견을 들어보는 것, 로그인을 한 고객 대비 팀 매칭을 한 고객이 얼마나 되는 지 전환률 등을 회의를 하며 생각을 해보았다.

이 내용은 글을 적는 지금까지도 결론이 나오지 않았고 멘토님으로부터 린 분석이라는 책을 읽어보고 결정해보라는 피드백을 받아서 책을 읽어보고 진행하는 방식으로 결정되었다.

😭 프로토타입의 결과

프로토타입을 만들고나서 우리 팀 모두가 많은 것을 깨닫게 되었다.

가장 큰 문제는 유저들에게 지금의 MVP처럼 단순한 기능이 필요할 까? 너무 기능이 부족하다고 느껴지지 않을까 ? 에 대한 문제였다.

프로토타입을 개발하고 실제 개발된 결과물을 보면서 팀 내부적으로 우리의 MVP가 너무 단순하다는 피드백들이 생기게 되었다. 특히 프론트엔드 팀 입장에서는 해야할 일이 거의 없다. 라는 것이였다. 또한, 멘토님의 피드백으로 유저에게 너무 불친절하다. 라는 내용을 알 수 있었다.

어찌보면 프로토타입 개발을 잘했다고 느껴지는 순간이기도 했다. 그래서 우리 팀은 MVP를 조금 더 확장해보기로 했다. 그리고 기능적인 것을 구현한 프로토타입을 만드는 것이 아닌 웹 애플리케이션이 동작하는 것처럼 보이는 단순한 프로토타입을 만들어 보기로 했다.

🚦 진행 내용 짧은 평가

평가 점수 🔴

프로토타입 개발에 부딪혀 보았고 좋지 않은 결과가 나왔다. 당연한 결과지만 시퀀스 다이어그램과 API 명세가 제대로 되지않아 개발한 프로덕트 자체의 문제가 많았다. 그리고 MVP 내용이 부실하다는 문제가 있었다.

또한 성공 목표와 지표 설정이 해결되지 않고 남았다. 이쪽으로는 아는 내용 더 부족하기 때문에 더 시간을 들이는 방법 밖에 없을 것 같다.

다행스러운 점은 프로토타입 개발로 실제 개발을 했을 때 걸리는 시간을 계산할 수 있는 기준이 하나 생겼다는 것이다. MVP가 확정이 되고 최종적으로 시퀀스 다이어그램과 API 명세가 나오고나서 개발을 진행할 때 기한 산정에 도움이 될 것 같다.

앞으로의 계획은 MVP를 확장해보고 프로토타입을 결과를 가지고 MVP를 수정하는 과정을 계속 진행할 예정이다.

⤧  Next post Spring과 Design Pattern - 1 ⤧  Previous post Spring과 DI