[우아한테크캠프] 키오스크 프로젝트

4번째 프로젝트도 2주간 진행됐다. 주제는 카페 키오스크 주문 서비스였는데, 운동을 좋아해서 헬스 키오스크 컨셉으로 프로젝트를 진행했다.

프로젝트 주요 기능은 키오스크 주문 시스템처럼 카테고리 별 상품이 존재하고, 상품을 클릭하면 상품 정보와 함께 부가적인 옵션과 수량을 선택할 수 있다. 선택된 상품은 장바구니 리스트에 보이고 최종적으로 결제를 누르면 결제 내역과 함께 결제가 진행된다.

 

프로젝트 후기

이번 프로젝트에는 큰 제약이나 요구사항이 없었다.

프론트는 React + TypeScript, 백엔드는 Nest.js + TypeORM으로 개발을 진행했다.

 

환경 세팅

이번 프로젝트에서는 React, Nest를 사용하는데, 별도로 배포를 진행했어야 했기 때문에 프로젝트 폴더를 어떻게 구상할까 고민하다가 다른 동료들과 토론 과정에서 모노레포라는 것을 알게 됐다. 

프론트, 백엔드 둘다 공통적인 node모듈을 사용하기 때문에 최상위에서 공통으로 관리하면 효율적이라 생각했다.

또한 prettier 설정도 전역으로 관리할 수 있어서 편리하다고 판단했다.

모노레포란 버전 관리 시스템에서 두 개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략

그래서 해당 관련 자료를 찾아보면서 구성을 했다. 제일 간단한 yarn workspace를 이용해서 모노레포를 구축했고, 간단한 환경 설정과 함께 보일러 플레이트로 만들어서 다른 동료들에게 공유했다. (다른 동료들에게 도움을 줬다는 사실이 굉장히 뿌듯했다.)

 

개발 (레포주소)

좌) 상품 리스트  우) 상품 정보

상품 장바구니

개발 이슈

결제 관련 기능은 구현하지 못했다. 처음 프로젝트 기획 당시 컴포넌트 재활용을 신경써보자는 생각에 아토믹 디자인 패턴을 생각하여 바텀-업 방식으로 개발을 진행했다. 하지만 확장성을 위한 props나 컴포넌트 설계에 너무 많은 시간이 소요되어 중간 과정에서 이를 포기하고, 탑-다운 방식으로 개발로 진행을 바꿨다. 이 과정에서 컴포넌트 설계가 꼬이면서 컴포넌트 리팩토링 하는데 많은 시간이 소요됐다. 그리고, 이번 프로젝트 목표가 테스트 코드를 작성해 보자는 목표를 가지고 있어서 마지막 하루는 테스트 코드를 학습하고 적용했다. 핑계라면 핑계인 이와 같은 이유들 때문에 기능 개발은 전부 하지 못했지만, 내가 생각한 목표를 이룰 수 있었다.

 

테스트 코드

컴포넌트가 정상적으로 렌더링 되고 있는지, 사용자 행동에 따른 컴포넌트가 정상적으로 수행되는지 판단하기 위해 테스트 코드와 API 데이터 모킹 작업을 수행했다. (해당 내용은 별도로 정리했기 때문에 여기에서 확인)

 

협업

개인 프로젝트로 진행했지만, 여러 명에서 협업을 진행하고 싶어서 같은 조로 짜인 분들과 협업을 진행했다.

erd, 기능 명세, 자료 등을 같이 작성하면서 협업을 진행했고, 코드 리뷰를 통해 서로의 성장을 도모했다.

(협업 자료는 여기에서 확인 가능하다)

 

 

아토믹 디자인

도입 이유 : 현재 프로젝트에서도 아토믹 디자인 패턴을 기반하여 작성하게 된다면, 버튼, 모달, 메뉴 정보 등 재사용할 것이 많다고 판단해서 간략하게 도입을 생각했다.

 

어려웠던 점

재사용성을 위해 props를 어디까지 허용하고 줘야 하는지 판단하기가 힘들었다. 버튼 컴포넌트를 활용하여 이곳저곳에서 사용되는데 디자인과 기능이 제각각 다른데 큰 버튼, 작은 버튼, 부가적인 기능을 하는 버튼 등의 목적에 따라 다 나누자니, 재활용에 장점이 잃는 것 같고, 그렇다고 props로 전부 해결하자니 너무 로직이 더러워져서 무엇이 더 좋을지 고민하는데 많은 시간이 할애됐다.

그래서 아토믹 디자인 패턴을 잠시 접어두고 상단 페이지부터 개발하기 시작했다.
처음에는 개발 속도가 조금 높았지만, 시간이 갈수록 똑같은 컴포넌트를 이곳저곳에서 사용되는 문제점이 있었다. 그리고 구조 설계를 생각 없이 하다 보니, props drilling이 많이 일어나게 됐다.
이를 해결하기 위해 컴포넌트 구조를 다시 설계하고 리팩토링을 진행하는 과정에서 많은 시간이 할애됐다.

 

이미지 hover시 변경 이벤트

이미지에 마우스를 hover 할 경우 다른 이미지로 바뀌고 떼었을 경우 원래 이미지로 돌아오는 로직을 구상했다.

그래서 이미지 컴포넌트에 moveOver, moveOut 함수를 통해 이미지를 변경했다.

하지만 이렇게 할 경우 hover 시 url이 변경됨에 따라 이미지 네트워크가 지속적으로 새로 요청하는 현상이 있었다.

이를 개선하고자 다른 동료들과 토론을 했고, 토론 과정에서 여러 가지 해결 방법이 나왔다.

 

처음부터 두 개의 이미지를 보여주는데 z-index로 구분을 지어서 나타내는 방법의 제안이 있었다. 하지만 이렇게 할 경우 hover를 하지 않더라도 모든 이미지를 불러와야 하는 단점이 있었다.

끊임없는 토론 과정에서 단순하게 css로 처리하는 방법에 대한 의견이 나왔다. emotion를 사용하고 있었기 때문에 props로 전달하여 hover 시 해당 속성의 값을 바꾸는 식으로 문제를 해결할 수 있었다. 이를 통해 hover 시 단 한 번만 두 번째 이미지가 요청되고 이후에는 캐싱 된 이미지를 사용해 네트워크 비용을 절감할 수 있었다.

토론 과정에서 똑같은 결과지만 다양한 접근법이 있다는 것을 알 수 있었다. 그리고 토론을 통해 점점 향상된 결과물이 될 수 있었다. 이를 통해 혼자 문제를 해결하는 것보다 함께 해결하는 것이 더 나은 결과를 만들어낼 수 있음을 깨달을 수 있었던 계기였다.

(사실상 단순한 문제와 해결법이지만, 당시에는 그런 생각이 나지 않았고 이를 다른 분들과 해결하는 과정이 재밌었기에 작성했다.) 

 

5~6주차 전체 회고

개인 프로젝트지만, 협업을 주도하여 같이 erd, 기능 명세를 고민하고 작성하는 경험이 재밌었고, 실무적인 활동을 하는 느낌을 받아서 매우 좋았다. 또 각자 잘하는 부분이 있었기에 동료들의 장점을 활용하여 개발할 수 있어서 편했다 ㅎㅎ.

그리고 이번 프로젝트를 기획할 때, 아토믹 디자인을 생각하며 바텀-업으로 개발하는 것과 테스트 코드를 작성하는 것이 목표였다. 테스트 코드는 목표한 바를 이뤘지만, 아토믹은 잘 활용하지 못해서 매우 아쉬웠다.

타입스크립트 또한 많이 사용해 보지 않아서 많은 문제를 겪었지만 해결하는 과정에서 타입스크립트와 조금이나마 친해질 수 있어서 좋았다.

+ 뜬금없이 나타난 Nest.js 때문에 고생을 많이했다. 학습하기 제일 어려웠다. (스프링의 객체지향 관점으로 만들어졌기 때문에 어려웠다.) 그리고 TypeORM으로 query문 작성하는 것도 어려웠다. 동료들이 없었으면 백엔드 포기했을지도...