실전 프로젝트 4일 회고

SaGo_MunGcci·2022년 8월 29일

Practice Project

실전 프로젝트

목록 보기

3/19

Today do list

MVP 작성
다중 파일 업로드
form-data에서 파일업로드 및 Dto 동시에 처리하기.

TIL

trade-off

트레이드오프란 객체의 어느 한부분의 품질을 높이거나 낮추는게, 다른 부분의 품질을 높이거나 낮추는데 영향을 끼치는 상황을 이야기한다. 일반적으로 한쪽의 품질을 높이면, 다른쪽의 품질은 떨어지는 방향으로 흐른다.
소프트웨어 개발을 예로들어보자. 일반적으로 개발시간을 늘리면 제품의 완성도는 높아지겠지만, 개발시간이 늘어날 수록 비용이 증가하게 된다. 그러므로 시간과 비용을 비교해 가면서 최적의 타협점을 찾아내어야 한다. 이것을 트레이드오프라고 한다.

MVP

최소 기능 제품(Minimum Viable Product, MVP)는 고객의 피드백을 받아 최소한의 기능(features)을 구현한 제품이다.

우리가 작성한 MVP

MVP 설계 방법(피드백 내용 정리)

MVP 은 구체적이어야 한다.

MVP는 추후 프로젝트 진행 방식과 개발 의지에 직결

구체화되지 못한 MVP 는 각 피쳐별 개발에 필요한 공수(스코프) 계산이 되지 않으니, 추후에 생각한것과 너무 다른 수준의 개발량으로 기획했던것들 중 몇 피쳐를 개발하지 못하게 되는 상황이 발생할 수도 있다.
이가 하나둘 빠지다보면 생각했던 서비스를 아예 못만들게되거나, 개발 의지가 꺽이기도 한다. 그 과정중에서 많은 조율이 발생하며 개발자인지 기획자인지 모를 상황이 무조건 발생한다.
예를 들면 개발에 집중하기도 부족한 마당에 만나서 어떤 부분들을 쳐낼지가 주가 되는 상황이 발생한다.
사이드 프로젝트의 경우에 2달 프로젝트가 1년을 질질끌게되는 상황도 봐왔습니다.(매니저님 말씀)

MVP 는 유즈케이스에서 Bottom-up 으로 기획/설계한다.

예를 들어 사원 관리 서비스의 MVP 를 설계한다고 가정하면, 가장 첫 MVP 는 사원 관리 정보를 단순 텍스트를 입력하도록 만들고, 그 다음 여러 폼들로 기입할 정보들을 구체화하며 실제 사용자들의 피드백을 받아, DB 스키마를 더 구체화해나간다.
그 다음 기입한 정보들을 필터를 통해 원하는 정보만 조회하여 관리할 수 있는 피쳐를 붙이는 격이다. 이렇게 총 3단계의 MVP 가 구성되었다. MVP 설계는 유즈케이스 기반으로 설계된다.
Top-down 이 아니라 유저가 어떤 행동을 할지에 대한 정의 후에 Bottom-up 으로 MVP 요소들이 정리되어야한다. Top-down 의 단점은 너무 많은것들이 누락된다는 점이다.
개발 속도와 시간적인 여유가 충분하다면 3단계까지 모두 마칠 수 있을테고, 시간이 부족하더라도 2단계 상에서 실제 유저들에게 Product 로 제공할 수 있게 된다.

한번에 모든것을 만들 생각을 내려놓고 정말 기본적인것들이 기능할만한 것들을 순차적으로 구체화해 나간다고 생각하면 된다.

MVP 는 Minimum Viable Features 가 아니다 “Product” 단수 명사다. 물론 개발자들에게 기획자의 역량을 갖추라고 하는건 욕심이겠지만, 기획 이해능력이야 말로 개발자 본인이 야근하지 않을 수 있는 최소한의 방패라는 점을 유념해야된다.

MVP 에 따른 DB 유형 선택 및 테이블 스키마가 가능해진다.

명확한 MVP 는 그 자체로 DB 테이블 스키마 설계를 가능하게 한다. 테이블 스키마에 따라 나열된 MVP 와 각각에 해당하는 구체 페이지와 연결하게 되면 그것이 API 설계가 되는것이다. 다시 한번 구체적인 MVP야 말로 앞으로 프로젝트의 모든 개발의 베이스라인이라는 점을 유념해라.

Retrospection

어제는 일요일이라서 쉬었고 오늘 4일차인데 오늘 나를 제외한 모든 팀원들이 실제로 오프라인에서 만나서 같이 게더에서 회의를 진행했다.
팀원들께 고마운것이 내가 올라가지 못해도 이해해주셨고, 오히려 나를 위해서 팀원들이 모인 스터티카페의 화이트보드를 볼 수있도록 노트북 한대를 화이트 보드에 고정시켜 주셨다.
오늘 회의중에 있었던 일은 원래 땅땅 경매의 주제가 누구나 실시간으로 물품을 경매에 붙일 수 있는 것이었는데, 기존의 테마에서 리셀로 한번 전환해보자는 의견이 나와서 그것에 대해서 논의 해보았다.
나는 개인적으로 리셀이라는 테마가 굉장히 마음에 들었는데, 누구나 물품을 올리고 경매에 붙이는 것도 좋지만 실제로 리셀상품을 취급하면 희소성이 있는 웹앱같아서 였다. 그리고 충분한 시장조사가 이루어 지고 사용자의 요구에 맞추면 충분히 좋은 어플리케이션이 될 수 있을 것 같았다.
그러나 현실적으로 6주라는 시간에 이미 짜놓은 api명세서와 mvp에 따른 논리적인 구조와 와이어프래임 그리고 특히 카테고리와 지역을 수정해야 되는 부분에 있어서 리셀로 바꾸기는 어려웠다. 그래서 팀원들이 다수결로 리셀로 갈것이냐 아니면 기존 그대로 갈것이냐 다수결로 했는데, 고민을 생각보다 많이 들었다. 아이템 자체가 즉, 리셀 자체가 너무 좋았기때문이었다.
이번 회의를 하면서 정말 백앤드와 프런트가 만나서 나누는 기술적인 부분 그리고 디자인부분들이 정말 실제로 개발하는 서비스를 다루는 것 같아서 정말 좋았다. 그리고 협업을 이렇게 하는구나라는 경험을 한것 같아서 정말 좋았다.
포기하면 잊혀진다라고 했던, 팀원분이 아직까지 나와 함께 공부를 하고 계신다. 자신이 얼마나 성장했는지 모르고 계시지만, 정말 6주뒤 이 팀원 분뿐만 아니라 나와 함께 이때까지 달려왔던 다른 팀원들 모두 그리고 나 포함 얼마나 성장할지 모르겠다.
부디 부디 다들 더도말고 덜도말고 자신이 노력한만큼 꼭 성장해서 좋은 결과가 있기를 바란다...
다중이미지와 reqestdto를 한번에 response하는 것을 공부하다가 시간이 늦어서 지금 TIL을 작성해 본다.
아 공부한것은 많은데 정리하질 못해서 너무 너무 아쉽지만, 틈틈히 시간내서 정리해야겠다.