데브코스 수료식에서 12개의 프로젝트 중 1등을 했다. 날카롭게 평가하는 자리는 아니었고 다른 팀 결과물도 열심히 구경하라는 이벤트로 진행된 것이었지만 그래도 기분 좋은 마무리를 할 수 있었다. 디자인이 깔끔해서 좋았다는 의견이 있어서 팀원들이 고맙게도 내가 했던 디자인이 큰 역할을 했다고 이야기해주었다. 하지만 아이디어, 사용자 경험, 코드 퀄리티, 문서화, 발표 영상 등 종합적인 평가에서 좋은 점수를 받을 수 있었던 진짜 이유는 짧은 기간 안에 실현 가능한 프로젝트 계획을 세워서 프로젝트를 완성했기 때문이라고 생각한다.
최종 프로젝트의 프로젝트 기간은 4주로 중간 프로젝트보다 2주 길어졌지만 백엔드와 함께 개발해야 했다. 프론트엔드와 백엔드가 함께 개발하는 경험이 이번 프로젝트가 처음인 팀원이 과반수인 상황이었다. 프론트엔드와 백엔드가 커뮤니케이션하는데 필요한 시간을 예상해서 꼭 필요하지 않은 요소는 포기하거나 뒤로 미뤄야 했다.
화면을 기획하면서 반응형 디자인을 하지 않기로 결정했다. 반응형 디자인은 화면 크기별로 달라져야하기 때문에 디자인 과정에 시간을 더 많이 써야 한다. 하지만 디자인 시안이 빨리 정해져야지 이후 과정을 효율적으로 진행할 수 있기 때문에 카카오프렌즈샵처럼 웹뷰용 화면 크기(640px) 하나만 개발하기로 정했다. 지금와서 보면 프론트엔드와 백엔드의 커뮤니케이션을 더 쉬워지게 만든 선택이었다. API 협의 과정에서 프론트엔드와 백엔드가 피그마 화면을 보고 이야기할 때가 많았다. 어떤 데이터를 받아서 어떻게 표현할 것인지 의논할 때 명확하게 한 가지 기준만 있었던 것이 경험이 부족한 팀에게 다행이었다는 생각이 든다.
기술 스택을 정하면서 버튼과 인풋 등 공통으로 재사용되는 컴포넌트를 직접 구현하는 대신 MUI를 도입하기로 했다. 공통 컴포넌트를 잘 만드는 것은 솔직히 말해 어렵고 시간이 오래 걸린다. 제대로 정의하지 않으면 여럿이 사용할 때 불편하고, 많은 곳에서 사용되어 작은 것을 수정하더라도 고려할 것이 많아진다. 프로젝트 기간이 짧고, 주로 비동기적으로 의사소통하는 상황에서 이번 프로젝트는 공통 컴포넌트를 직접 구현하는 것보단 잘 만들어진 라이브러리를 가져와 모범 사례를 적용하는 것이 낫다고 판단했다.
하지만 프론트엔드 5명 중 3명이 이전에 MUI를 사용해본 적이 없었다. 팀이 전반적으로 미숙한 상태에서 사용 방법이 복잡하면 UI 라이브러리를 도입한 의미가 무색하게 제멋대로 적용될 수도 있다고 생각했다. 그래서 화면을 피그마로 디자인하는 동시에 화면의 각 요소를 MUI에서 어떤 컴포넌트로 구현하는 것이 좋을지, MUI의 테마를 커스터마이징해서 컴포넌트의 스타일을 일괄적으로 제어할 수 있는지를 테스트했다. 이후 프론트엔드 개발에 들어가자마자 MUI에서 주로 사용할 부분만 공통 컴포넌트로 추출하고 가이드라인이 될 수 있게 Storybook으로 문서화해서 공유했다.
MUI를 도입한 것은 결과적으로 신의 한 수였다. 의도했던 대로 공통 컴포넌트에 고민할 시간을 단축하고 바로 페이지 단위 개발을 시작할 수 있었다. 그래서 다른 팀보다 시작이 순조로웠던 것 같고, 이후 각자 맡은 ‘숙제’에 집중할 시간을 확보할 수 있었다.