WEHICLE Project

KREAM을 참고한 중고차 거래 경매 중개 플랫폼, WEHICLE 프로젝트

1. Project를 진행하며

2023년 1월 30일부터 2023년 2월 10일까지, 2주간 KREAM 홈페이지를 기반으로 디벨롭하여 중고차 거래 경매 중개 플랫폼을 구현하였다.

호가 거래의 특성상, 물건이 모두 동일하다는 전제 하에 새 상품만을 파는 KREAM과는 달리, 중고차를 파는 홈페이지를 구현하다보니 KREAM과는 다른 방향으로 조금씩 진행하게 되었고, 자동차의 특성 상 많은 옵션이 존재한다는 것 때문에 초반에 DB 모델링에 큰 애를 먹었다.

게다가 KREAM 상품 상세 페이지의 꽃이라고 할 수 있는 시세 그래프를 어떻게 구현해야할지 가장 많은 고민을 하였다. 처음엔 너무 어렵게만 생각하였는데, 결국엔 지금까지 거래가 체결된 해당 상품(차종)의 거래 체결 가격을 DB에서 가져오면 되겠다고 깨닫고나니 정말 제 자신이 바보처럼 느껴지기도 했다. 괜히 어렵겠구나 겁을 먹었던 것을 반성하기도 했다. 덕분에 앞으로의 프로젝트에서도 '괜히 겁먹지 말자. 모든 것을 쉽게 생각하면 답이 나올 것이다.' 라고 생각할 수 있게 되었다.

구현 사항에 대한 설명은 깃허브 README.md에 작성되어 있다. (현재 수정 중)

2. 이번 프로젝트의 KPT

프로젝트 데모데이가 끝난 후, 팀원들과 KPT 회고 시간을 가졌다. 이 회고를 통해 나온 것들을 위주로 이번 회고를 작성해보고자 한다.

2-1. KEEP

2-1-1. 트렐로 사용

• 트렐로 티켓 설정이 너무나도 잘 되었다. 서로 구현해야할 것들과 추가로 구현하고 싶은 것들까지 모두 티켓으로 만들어두었고, 서로의 진행 상황을 한 눈에 볼 수 있어 좋았다. 트렐로 덕분인지 추가 구현까지 프로젝트 직전까지 해낼 수 있었다고 생각한다.

2-1-2. 프론트엔드와 백엔드의 소통

• 백엔드에서 미리 구현해놓은 API를 프론트엔드에서 구현할 때, 백엔드에서 Postman을 사용하여 데이터를 주고 받는 형식을 캡처하여 프론트에게 전해주어 프론트에드에서 해당 사항을 구현할 때 큰 시간이 걸리지 않았다.

2-1-3. 중요한 건 꺾이지 않는 마음

• 다른 팀들보다 프론트엔드의 인원이 1명 더 적었다. 그래서 처음에 일단 큰 틀만이라도 구현하자, 시간이 부족할 것 같으니 추가 구현으로 티켓을 빼놓자고 이야기하였다. 나 또한 Mypage는 추가 구현으로 하겠다고 생각했었다. 하지만 나 뿐만 아니라 팀원 모두가 추가 구현, 추추가 구현으로 생각했던 것들까지 구현해내었다. 모두 해낼 수 있다는 마음 하나로 프로젝트를 임했기 때문에 가능했던 것이 아닌가 싶다.

2-1-4. console.log!!!

• 1차 프로젝트에도 중요하게 생각했던 콘솔의 중요성. 이번 프로젝트에서도 뼈저리게 느꼈다. 되야하는 코드가 되지 않을 때 콘솔을 controller, service, dao에 모두 찍어보면서 어디에 문제가 있는지 찾아보았고, 이외에도 클라이언트 쪽에서 와야하는 req.body가 왜 서버로 들어오지 않는지(이런 경우는 대부분 사소한 실수였다. 예를 들면 오타라든지... 오타라든지... 또 오타라든지...) 하나씩 찾아가가며 코드를 수정하고, API를 더 제대로 구현해낼 수 있었다.

2-2. PROBLEM

2-2-1. API Documentation의 부재

• 1차 프로젝트에는 API Documentation을 바로바로 업데이트하며 프로젝트를 진행했었다. 하지만 2차에는 PR 리뷰 이후 바뀌는 것들도 꽤 있었고, 나 또한 마음이 너무 바쁘다보니 제대로 작성하지 못하였다. 때문에 프론트에서 쿼리 스트링을 보낼 때 ""를 제외하고 서버로 보내야하는데 ""까지 보내게 되어 필터링이 제대로 구현되지 않았던 경험도 있고, key 이름을 카멜 케이스로 통일하였지만, 이 또한 제대로 전달되지 않았었다. 그래서 코드 자체엔 아무 문제가 없는데 왜 되지 않는지 찾아내느라 시간을 허비하기도 하였다. API 명세만 있었다면 이러 시간 소모를 줄일 수 있었을 것이다.

2-2-2. 소통의 부족

• 매일 아침 Daily Standup Meeting을 진행하여야 했으나, 내부 사정으로 인해 진행하지 못했던 날들이 있었다. 서로 가까운 자리에 앉아 있으니 궁금한 건 바로 물어보면 되지 않을까라고 생각하기도 하였고, 트렐로를 보면 서로의 진행 사항을 알 수 있으니 한두번의 미팅은 하지 않아도 크게 문제될 것이 없을 거라 생각하였다. 하지만 이런 일들이 반복되다보니 2-2-1에서 언급하였던 상황들도 생기게 된 것 같다.

2-2-3. 본인이 하는 것에 집중

• 이게 무슨 문제일까라고 생각할 수도 있겠지만, 그리고 본인이 하는 것에 집중하였기 때문에 프로젝트를 무사히 끝낼 수 있었다고도 생각하지만, 본인이 하는 것에 너무 집중한 것이 우리 팀의 문제 사항이었다. 나 같은 경우엔 같은 백엔드 팀원이 승수님이 자리에 있지 않을 때, 프론트엔드 팀원이 어떤 것을 물어볼 때마다 "제가 한 게 아니라 잘 모르겠어요."라고 대답한 적이 꽤 있다. 내가 한 게 아니더라도 백엔드의 진행 상황을 모두 알고 있었다면 그 질문에 쉽게 답할 수 있었을 것이라고 생각한다.

2-2-4. DB 테이블

• 처음 DB 모델링을 할 때, 테이블 개수를 줄일 수 있으면 최대한 줄여보자고 승수님과 이야기하였다. 1차 프로젝트 때 테이블이 스무개가 넘는 다른 팀들이 고생하는 모습도 보았고, 나 또한 JOIN으로 여러 테이블들을 엮는 것보단 깔끔하게 쿼리문을 쓰고 싶다고 생각했었다. 하지만 이건 나의 오만이었다. 정규화를 제대로 진행하였다면 1시간동안 고민하며 쓸 쿼리문을 10분 이내로 쓸 수 있었을 것이다. 테이블을 줄이는 것이 능사가 아니라는 것을 깨닫게 되었다.

2-3. TRY

2-3-1. 더 많은 소통

• 협업의 가장 중요한 것 중 하나는 소통일 것이다. 이번 프로젝트를 발판 삼아 다음 프로젝트를 진행할 때에는 Daily Standup Meeting과 같은 자리를 통해 프론트와 백의 소통을 원활히 진행할 것이다.

2-3-2. API Documentation 작성

• 1차 때 API Documentation 덕분에 무사히 진행 된 프로젝트의 경험과 2차때 API Documentation의 부재 덕분에 겨우 문제점을 찾아낸 경험을 토대로 다음 프로젝트를 진행할 때에는 API Documentation을 먼저 만든 후 API를 구현할 생각이다. API를 구현한 즉시 API 명세를 업데이트하고, Postman을 캡처하여 프론트에 전달하는 것까지 포함할 것이다. 시간을 줄일 수 있는 곳에서 줄이는 것이 가장 큰 목표이다.

2-3-3. TDD

• 1차와 2차의 가장 큰 차이는 테스트 코드의 유무이다. 테스트 코드 덕분에 쿼리문을 잘못 작성했다는 것을 깨닫고 수정한 상황도 있었고, 테스트 코드를 작성해보며 jest를 공부할 수 있었다. 하지만 TDD(Test Driven Development)가 아니었다는 게 아쉬웠다. 테스트 주도 개발이 아니라, 그저 테스트 코드를 작성하는데에 급급했었기 때문이다. 다음 프로젝트에서는 TDD를 생각하며 테스트 주도 개발을 할 수 있도록 노력해야겠다.

2-3-4. 테이블 정규화, 테이블 반정규화

• 2-2-4의 경험을 토대로 테이블 수를 줄이는 것이 능사는 아니라는 것을 항상 마음 속에 새기고 DB 모델링을 할 때 테이블 정규화와 반정규화를 꼭 거쳐야겠다. API 구현 전 가장 중요한 것이 DB 모델링이기 때문에, DB 모델링이 제대로 되어 있어야 더욱 좋은 쿼리문을 작성할 수 있고, 내가 원하는 데이터 CRUD가 될 수 있다는 것을 기억할 것이다.