너무 큰 작업은 task를 쪼개 MVP로 만들기

 

어제 TIL을 올린 직후 게시글 리스트 화면과 게시글 상세정보 조회 화면을 구현하기 위해 작업 설계를 시작했다.

프로토타이핑 화면을 바탕으로 구현하려면 먼저 썸네일에서 나타나는 데이터를 갖춰야 할 것 같아 먼저 모델을 정의하려 했다.

 

 

작업 Catalog를 만들 때는 모델을 계획하는 순서를 게시글, 모집 포지션, 사용자 순으로 짜는 것을 계획했었다.

 

작업을 설계하기 시작하면서 느낀 점은 모델을 정의하는 것은 사실상 데이터베이스 테이블들을 설계하는 것과 같다는 것이었다. 직접 모델을 설계해보니 모델이 다른 모델의 정보를 가져와야 할 때 연결성을 어떻게 부여해야 할지 설계를 하는 단계인데도 쉽지 않게 느껴졌다.

 

모니터 화면에 글로만 적는 것은 한계가 느껴져서 도장에 일찍 나와서 구조도를 직접 그려보기로 했다.

 

 

 

마침 도장에 동료분께서 일찍 나와 계셨고, 동료분 앞에서 설계 계획을 가볍게 설명해드릴 기회가 있었다.

 

동료분과 이야기를 나눠보면서 현재 너무 크게 잡고 있는 모델링 계획을 최소화해 가장 필요한 내용만으로 모델들을 구성하고, MVP를 구현하면서 단계별로 구현을 확대해 나가는 방식으로 수정하기로 결정했다. 작업 단위가 너무 크다 보니 뽀모도로 기준 시간마다 피드백을 얻을 수 있는 수준의 결과물이 나오기 어렵고, 결과물을 보면서 피드백을 얻고 다음 작업 때 부족한 부분을 개선하는 방식이 낫겠다는 판단이었다.

 

동료분의 도움을 받아 모델을 극단적으로 최소화해 보았다. 처음 MVP는 '이것까지도 빠진다고?' 싶을 정도로 극단적으로 모델을 최소화했고, 몇 단계에 걸쳐 모델을 확장하는 식으로 틀을 잡았다.

 

 

그 결과 1차적으로 구현한 모델은 아래 사진에 나타나는 수준으로 크기가 줄어들었다.

 

 

주간에 작업을 진행하면서 MVP로 작업을 축소하기 잘했다는 생각이 들었다. 모델의 크기 단위는 최소한이었지만, MVP라 하더라도 일단 동작하는 웹 애플리케이션의 기준인 프론트엔드와 백엔드 구조가 갖춰진 상태로 구현이 되어야 했다. 컴포넌트 >> 페이지 >> 스토어 >> API >> 컨트롤러 >> 서비스 >> 데이터베이스 순으로 연결되는 한 번의 구조를 갖추는 데에만 오늘 하루를 거의 모두 사용했다. 모델 정의를 최소화하지 않았으면 오늘 안에 프론트엔드 결과물은 낼 수 있었을까 하는 생각도 든다.

 

최종 복잡도는 정해져있는 만큼 오늘 집에 가기 전까지는 1차 MVP 구현을 마치고 주말에는 단계를 나눠 모델의 확장을 시도해야 할 것이다. 구현하다 보면 기획 때는 생각하지 못했던 추가로 구현해야 하는 부분이 나타날 수도 있을 것 같다.

 

이번 주 목표를 잘 마치고 다음 주에는 나도 얼른 모두에게 찾아본 기술에 대해 공유할 수 있는 때가 왔으면 좋겠다.