Stawefolio - 2차 프로젝트 전체 회고

위코드에서의 두 번째 프로젝트가 끝났다.

두 번째 프로젝트는 여행지에서 머물고 싶은 좋은 스테이 큐레이팅 서비스, stayfolio를 모티브로,

여행지에서 감성을 더해줄 음악 section(time to vives)을 추가한 감성숙소 추천 서비스 stawefolio를 만들어보았다.

 

- 기간 : 2022년 11월 28일 ~ 12월 9일

- 팀원 : FE 3명, BE 2명

1. 프로덕트 기획 및 스케쥴링

1.1 기획

프로덕트, 고객 관점으로 서비스를 생각하기 위해 노력

팀원들과 사이트를 살펴보며 어떤 것을 제안하면 고객의 경험에 도움이 될까 생각했다.

어쩌면 여행은 여행을 계획하는 순간부터 시작되는 것은 아닐까,

여행지에서 머무를 곳을 정하는 것도 여행의 여정이라면 그 여정을 즐겁게 해주자! 라는 기획 포인트가 나왔다.

그래서 고객의 여행과 숙박 목적에 따라 어울리는 음악을 함께 큐레이션 해주기로 하고

메인 페이지에서 “여행지에서 감성을 더해줄 음악” 섹션을 할애했다.

프로젝트 사이트의 메인페이지

 

 

사이트 컨셉을 정한 뒤에는 1차 프로젝트에서 진행했던 웹 사이트 페이지의 레이아웃과

백,프론트가 통신할 데이터를 러프하게 정리하는 시간을 가졌다.

 

012345

 

이렇게 정리하면 우리 서비스의 what why how가 정리되어서

앞으로 팀원 간 소통에 굉장히 유용하다고 생각했는데,

1차 때 같은 팀을 했던 팀원들이 같은 방법론으로 처음 기획을 가져갔다는 소식을 들으니 생각에 공감해준 것 같아 뿌듯했다~!

 

1.2 스케쥴링 및 기록

스케쥴링과 프로젝트 진행 내용을 기록하는 것은 1차 때는 잘 신경쓰지 못했던 부분이었다.

PM이었던 수정님의 노고 덕분에 trello, notion등의 툴을 활용해 프로젝트 동안 팀원과 나의 tesk 진행 상황을 잘 스케쥴링 할 수 있었다.

누가 어떤 기능을 담당하고, 진행 정도가 어떻게 되는지 각자가 갖는 블록요인은 무엇인지 등

굳이 구두로 묻지 않아도 기록되어 있는 내용이 있으니 소통에 많은 리소스를 절약할 수 있었고 회고에도 도움이 되었다.

 

2. DB 모델링

DB를 모델링 하는 것은 첫 프로젝트보다 훨씬 수월하게 진행할 수 있었다. 첫 프로젝트에서는 멘토님의 대대적인 수술?? 덕분에 모델링이 완료될 수 있었다면, 이번에는 달랐다.

백엔드 팀원 은영님과 서비스 로직에 대해 고민하면서, 서비스 운영에 필요한 데이터 테이블의 큰 틀을 잡고 데이터 컬럼을 넣은 뒤 세세하게 정규화를 진행했고 그 과정은 이전보다 50% 이상 단축되었다.물론, 스무 개도 안되는 테이블이었지만 다른 작업보다 많은 어려움을 겪었던 DB 모델링이었기 때문에, 전보다 빠르고 수월하게 해냈다는 것에 당시에는 뿌듯했다.

하지만, 중간에 종종 DB 테이블을 수정건으로 작업 진행 속도를 꽤 많이 잡아먹었다. 꼼꼼히 체크하고 최대한 수정이 없게 모델링하려고 노력했지만 아직 디테일에서 많이 부족하다는 것을 느꼈다. 앞으로는 테이블에서 빠뜨린 데이터 컬럼이 있는지 꼼꼼히 확인하고, 시간이 걸리더라도 데이터 타입까지 처음부터 설계해야겠다고 생각했다.

3. API 제작

이번에는 API를 작성하기 전에 API 명세서 작성부터 작성했다.

1차 때는 내가 프론트엔드에 보내주는 데이터의 형태가 어떻게 나올지 상상이 되지 않아서 API 작성 이후에 명세서를 전달했었다.

그래서 프론트엔드와 백엔드의 첫 통신에서 서로의 fit을 맞추는데 굉장한 리소스가 소요되었었다.

 

이번에는 어떤 형태로 데이터를 보내주어야 프론트에서 접근이 편한지,

res에 담아 보내주는 데이터의 구조, 타입등을 해당 기능 담당 프론트엔드와 논의하면서 함께 설계한 후 명세서를 작성했다.

그래서 프론트에서도 명세서에 담겨 있는 변수명을 활용해 목데이터를 만들어 작업을 시작할 수 있었다.

 

 

하지만, API 명세의 작은 수정이 잦았고 변경사항을 담당 팀원이 더블 체크 해야했기에,해당 팀원에게 피로감을 주기도 했다.

또한 그만큼 놓치기 쉬운 부분이었기 때문에 상호 통신 간 에러의 원인으로 자주 나타나기도 했기 때문에 아쉬운 점으로 남는다.

 

그리고 통합 테스트를 해보았는데, 처음에는 이것을 굳이 왜 하지? 라는 의문이 있었지만

그것은 내가 제대로 유닛테스트를 제대로 하지 못해서 였던 것으로 결론을 내렸다.

오히려 유닛테스트를 하면서 평소 크게 신경쓰지 못했던 예외 처리를 세심하게 할 수 있었고,

코드를 수정하면 테스트코드도 수정해야 하기 때문에 리펙토링을 안정적으로 할 수 있었다.

 

어려웠던 점은, 유닛테스트는 하나의 모듈을 독립적으로 진행하기 때문에 목킹 객체를 넣어줘야 했는데,

처음에는 카카오 서버와 통신하는 과정을 mocking으로 대체하는 것이 어려워서 생각보다 쉽지 않았다.

 

하지만 끝내 테스트를 해냈다는 점은 뿌듯했고, 통합 테스트라는 block을 넘어서니 테스트를 통과할 때 꽤 짜릿함?을 느낄 수 있었다.

 

3.1 간편 Login 인증(GET)/ 토큰 검증 인가(middleware)

이번에도 인증/인가 API를 맡았다.

1차와 달랐던 것은, OAuth 2.0 기반의 소셜 간편 로그인을 구현했다는 점이다.

1차때, 사용자의 불편을 줄이기 위해 회원가입 시 자동 로그인이 되도록 로직을 구현했었는데,

OAuth2.0 방식의 간편 로그인 기능은 더욱 편리했다는 점, 처음 외부와 통신하여 API를 제작한다는 점,

그리고 권한 부여 승인 코드 방식의 로직에 흥미를 느껴서 이 기능을 맡았다.

 

로직은, 내부 DB에 인증 요청을 한 사용자의 정보가 없을 경우

카카오 서버에서 제공 받은 정보로 자동 회원가입이 되도록 인증 처리한 후 JWT 토큰을 발급하여 인가 처리를 했다.

그리고 간단한 통합 테스트를 통해 의도한 대로 code가 잘 작동하는지 확인하며 API를 제작했다.

 

KaKao 간편 로그인 기능을 구현하면서 OAuth2.0 방식의 로직에 대해 배울 수 있었지만

아직 개념적으로 깊이 있는 이해를 하지는 못한 것 같아서 추가 공부가 필요할 것 같다.

 

3.2 숙소 리스트 조회(GET)

products 부분에서는 1차때 해보지 못했던 상품 조회 API를 제작했다.

체크인&체크아웃 날짜, 지역, 게스트 수, 가격, 숙소 타입, 테마 등으로 숙소를 필터링하여 조회하고

조회된 상품을 가격 오름차순, 내림차순, 최신 순으로 정렬할 수 있도록 쿼리를 작성했다.

여기에 숙소의 지역과 세부주소, 숙소 이름으로 상품을 검색할 수 있도록 하였다.

 

이 모든 기능을 하나의 쿼리로 작성해야했기 때문에, 쿼리문을 만들어주는 별도의 모듈을 만들어 dao단에 import시켜 활용했다.

추후 기능이 늘어나면서 작성해야할 쿼리가 늘어나면 querybuild 모듈의 활용성이 더욱 높아질 것이기 때문에

추후에 빌드 모듈을 고도화 시킬 필요가 있겠다는 생각이 들었다.

이외에도 controller 단에서 체크인&아웃 날짜와 가격 데이터가 올바르지 않은 경우,

조회 요청 결과 데이터가 없는 경우의 예외처리를 해주었고 dao단에서 쿼리 파라미터에 잘못된 타입이 전달된 경우의 에러처리를 해주었다. 그리고 간단한 통합 테스트를 통해 의도한 대로 code가 잘 작동하는지 확인하며 API를 제작했다.

3.3 숙소 상세정보 조회(GET)

1차때도 제작해봤던 상세정보 조회 API 였지만 API를 제작하기 전에 먼저 API 명세를 작성했기 때문에, 내가 보내주겠다고 front에게 약속한 대로 데이터를 보내주는 것은 꽤 도전적인 과제였다. 하지만, Subquery에 JSON_ARRAYAGG, JSON_OBJECT를 활용하여 차근차근 데이터를 붙여나가는 식으로 쿼리를 작성하니 한결 수월하게 작성할 수 있었고 API 작성 중 가장 적은 시간이 소요되었다. 예외처리는 Dao단에서 조회된 데이터가 없거나, 잘못된 path parameter 값이 들어오는 경우를 처리했고 마찬가지로 간단한 통합 테스트를 통해 의도한 대로 code가 잘 작동하는지 확인하며 API를 제작했다.

 

4. 회고 종합

전반적으로 백엔드, 프론트엔드 팀원들이 맡았던 기능은 스스로에게 모두 도전적인 것이었다. 그래서 팀 프로젝트의 속도가 생각만큼 나지 않아서, 정해진 기한 내에 aws 배포 ~ CI/CD의 개념학습까지는 완료했으나, 실제 프로젝트로 실행하지 못한 점이 가장 아쉽다. 하지만, 통합 테스트를 진행하면서 API를 작성하고, 새로운 학습(kakao restapi, axios 등)과 API 로직(querybuild)을 고민하는 과정에서도 많은 것을 얻은 프로젝트였다.

• 잘한 점
  • 협업을 위해 프론트엔드 개발에 대해 물어보고 알아가려 했던 자세
    → 빠른 문제해결을 위해. 둘다 자바스크립트를 쓴다는 것이 얼마나 유리한가!?
  • 나의 욕심 이전에 팀의 목표 달성을 우선했던 자세
  • 카카오 공식문서를 스스로의 힘으로 읽고 API를 구현한 것
  • API 명세 먼저 작성하고 시작 한 것
  • 프로젝트 내내 내가 잘 하고 있는건지 고민했던 것
    → 1차 프로젝트 때와 동일하게 ERD를 짜고, API를 작성하고 완성하는 과정에서 이게 맞나 싶었어요. 이게 전부가 아닐텐데.. 코더가 아니라 개발자로서 사고하려고 노력했습니다.
• 성장점 및 액션플랜
  • 기능 구현으로 끝난 것이 아니다. 리펙토링을 틈틈히 꼭 해야 한다.
    → 자바스크립트 클린코드 번역판 github을 공부한다.
  • 수정되는 내용에 대한 공유가 원활히 이루어지지 않았음 → 모든 공유는 팀원이 ‘글’로 확인하고 ‘확인 여부 체크’를 할 수 있도록 규칙을 정한다.
  • 정해진 기한 내에 작업을 완수하지 못 함
    → 기한 설정 자체가 잘못되었을 수도 있고, 효율적으로 진행하지 못해서 일수도 있다. 하지만, 결국 “내 능력”을 스스로 얼마나 잘 알고있는지에 대한 문제이므로 관련 메타인지를 높여야겠다. 그리고 작업량을 정할 때, 내 능력보다 20%만 높여서 도전적으로 설정하자.
  • 내가 알고 있는 내용들만 가지고 코드를 작성함.
    → 더 좋은 코드, 편한 구현 방법, 라이브러리 등을 찾아보고 적용할 생각을 해보지 않았다.(ex. 예약 라이브러리) 내 손으로 직접 만들어보는 것도 좋지만, 경우에 따라 효율을 선택할 줄 알아야 한다.
  • 순간 순간 떠오르는 기억, 인사이트들을 정리, 기록하지 못함
    → 1차때는 잘 했던 내용인데, 2차 때는 잘 하지 못했다. 매일매일 TIL 작성을 하거나 일지를 작성하는 것까지는 어렵더라도 무슨 일을 하던지 메모장을 켜놓는 습관을 들이자.
• 기업 협업 프로젝트에서 해보고 싶은 경험
  • 프로덕트 관점에서 다양한 문제들을 기술적으로 해결해보는 경험, 관점의 성장
  • 고객 관점에서 다양한 문제들을 기술적으로 해결해보는 경험, 관점의 성장
  • 현업의 개발자가 잘 쓴 좋은 코드를 보고 배우고 싶다.

•