04_ (패스트캠퍼스X야놀자 프론트엔드 개발 부트캠프) 숙박 예약 사이트 *기업연계*

프로젝트를 시작하며

패스트캠퍼스 X 야놀자 프론트엔드 부트캠프 참여하고, 첫 번째 기업연계 프로젝트이다.

3번째 프로젝트로 부트캠프에선 토이 프로젝트2(웹소켓을 활용한 채팅 사이트)를 진행했지만 나는 그 시기에 과정 외 프로젝트를 진행해서 API연동을 해보지 못한 상태로 투입됐다. 그리고 백엔드와 첫 협업을 진행하는 것이기에 걱정이 됐었다.

 

하지만 "하면 된다" 마인드로 냅다 시작 🔥

 

 

프로젝트 결과

빨리 잡아! (숙박 예약 사이트)

깃허브 주소

 

 

 

초점을 두고 준비했던 부분

1. 백엔드와 소통

2. 최적화

3. 코드리뷰 꼼꼼히 하기

 

---

 

<  PREVIEW  >

 

 

< 내가 작업한 부분 - 숙박 상세 페이지 >

 

개별 숙박 상품 상세 조회

• • 이름, 주소, 예약 가능 여부, 전화번호, 소개, 위치, 옵션, 객실 표시
  • useQuery를 이용해 효율적으로 데이터 관리 
   

• kakao map api 연동 및 편의시설(은행,카페,편의점) 조회 기능 

 

룸 조회

• • swiper library & lodash debounce : 검색 버튼 클릭 시 api를 호출하므로 단시간 많은 클릭 불가하게 만들어 둠
  • 일정과 인원수에 따른 룸 조회 및 예약 마감 표시 

• 일정 및 인원수에 따른 가격 변동 

 

장바구니 담기

• • debouncing : 장바구니 버튼을 매우 빠르게 클릭할 때 모든 동작이 상품 담기로 이어지는 것을 방지
  • 비로그인 시 로그인 페이지로 이동
  • 성공/실패를 판단할 수 있는 toast 

 

즉시 결제하기

• • 결제할 때 사용되는 데이터를 전역으로 상태 관리해서 전달
  • 비로그인 시 로그인 페이지로 이동 

 

 

 

---

 

 

< 회고 - 1. 백엔드와 협업 >

 

가장 신경썼던 부분이다.

 

 첫 번째는 타임라인이 이상적으로 진행되지 않았다는 문제가 있었다.

프론트엔드 측에선 이미 퍼블리싱을 마친 상태임에도 불구하고 API가 나오지 않아서 그 공백을 채우기 위해 노력을 많이 했던 것 같다. 카카오맵 카테고리 검색 기능도 이때 추가했다 ㅋㅋ

 MSW를 이용해서 나중에 url만 갈아끼울 수 있게 코드를 짜두는 것은 백엔드와 협업에서 "필수"라는 생각이 들었다. 

 

한 가지 주의해야할 점은 API명세서에서 변수명을 어떻게 할건지 꼼꼼하게 얘기 나누어야한다는 점이다. 시간을 절약하기 위해서 MSW를 이용해 API연동 코드를 미리 작성해둔 것인데, 변수명이 달라져버리면 수작업으로 하나하나 수정을 해야하는 상황이 생겨서 생산성이 떨어진다. (시간 낭비 ↑↑↑↑ )

 

관련해서 글을 남겨두었었다.

https://sol-mi.tistory.com/79

백엔드와 협업할 때 API를 못 받았다면? MSW mocking서버를 이용해보자! (feat. React & TypeScript)

 

 두 번째는 백엔드 <-> 프론트엔드 서로 간 지식을 모르니 문제가 발생했을 때 해결이 더뎠다. (어느 쪽에서 해결해야 하는 문제인가?)

 

두 가지 큰 이슈가 생겼었다. (큰 이슈는 작업이 올스탑될 정도의 일을 말한다..ㅠㅠ)

결과적으론 두 가지 문제 모두 서버쪽 이슈였지만, 이거를 어느 쪽에서 해결해야할지 몰라서 프론트쪽에서도 정말 많은 시행착오와 고민을 했던 것 같다. 

---

 

첫 번째는 CORS에러이다.

 

문제 상황)

 CORS는 직역하면 "교차 출처 리소스 공유 정책"이다. 여기서 출처, 즉 Origin 이란 프로토콜 + 호스트 + 포트 번호(ex: http-프로토콜, localhost-호스트, 5173-포트번호 =>  오리진 - http://localhost:5173)를 합친 것을 말하는데, 같은 Origin에서 오는 요청은 받을 수 있지만, 다른 Origin에서 오는 요청은 보안상 막아서 CORS 에러가 생기는 것이다.

 

 서버는 EC2 서버 호스트와 80 포트에서 돌아가는데, 프론트엔드에서 로컬로 테스트 할 땐 클라이언트의 호스트는 localhost 와 5173이란 포트로 요청을 보내서 막혔기 때문에 에러가 발생한 것이다.

 

사실 이 문제는 백엔드 쪽에서 해결해야 할 문제라고 생각하긴 했지만, 프론트 측에서 api요청을 잘못한 것인지를 여러번 확인하느라 시간을 많이 소비했다..

 

임시 해결 방법)

 마감기한은 가까워오니 얼른 해결해야 이어서 작업을 할 수 있는데, 이 문제가 해결되지 않아서 완전 올 스탑된 상태였다.

멘토님께 여쭤보니 이런 경우 proxy 서버를 이용해서 우선 작업을 하고, 그동안 백엔드에서 해결하도록 시간을 주는 방향이 좋을 것이라고 말씀해주셨다.

관련해서 정리했던 글이다.

https://sol-mi.tistory.com/81

proxy 서버 띄워 작업하기 (feat. vite)

 

근본적 해결 방법)

백엔드 단에서 web config설정을 하여 localhost:5173 으로 오는 요청을 열어 두어 문제를 해결했다.

사실 이미 web config 설정을 해두셨는데, 시큐리티 쪽 cors가 시큐리티가 요청이 올때 필터로 거르는 작업이 있는데 이때 웹 컨피그로 설정해둔 것까지 걸러버렸기 때문에 cors 열어둔게 없다고 보고  cors 에러가 생겼었던 것이다. 이 부분을 인지하고 추가로 수정해주셨다!

---

 

두 번째는 mixed-content 에러이다.

 

문제 상황)

최종적으로 프론트엔드와 백엔드의 작업이 끝나, vercel에 배포된 프론트엔드 배포 사이트와 백엔드 서버인 EC2 인스턴스를 연동시켰을 때 발생했다.

 

 최초 HTML이 안전한 HTTPS 연결을 통해 로드될 때 혼합 콘텐츠가 발생하지만 다른 리소스(예: 이미지, 동영상, 스타일시트, 스크립트)는 안전하지 않은 HTTP 연결을 통해 로드된다. 이는 HTTP 콘텐츠와 HTTPS 콘텐츠가 함께 로드되어 동일한 페이지를 표시하므로 혼합 콘텐츠라고 하는데, 최초의 요청은 HTTPS 연결을 통해 보안 처리되었다. 최신 브라우저는 이 유형의 콘텐츠에 대한 경고를 표시하여 해당 페이지에 보안되지 않은 리소스가 포함되어 있음을 사용자에게 알려 준다.

 즉, HTTPS 요청 내에서 API를 사용할 때 HTTPS 요청을 보내야 하는데 HTTP 요청을 보내고 있어서 Mixed content 에러가 나타 난것이다.

 

임시 해결 방법)

프론트 측에서 해결할 수 있는 방은은 meta 태그를 추가하는 것이라고 한다. 아래 태그를 html head에 추가해주면된다.

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

 

이 메타 태그를 넣으면 해결될 줄 알았지만, 해결되지 않았다. 우리가 하는 HTTP 요청은 이미지나 동영상 컨텐츠를 불러오는 요청이 아닌 API 요청이기에 메타 태그를 넣어도 작동하지 않는게 당연했다.

 

근본적 해결 방법)

그래서 자연스럽게 이거는 오롯이 백엔드 쪽에서 해결해줘야하는 문제로 넘어갔다.

백엔드 측에서 API 요청이 HTTPS 프로토콜에서도 가능하게 해야했다. ( HTTP에서 HTTPS 요청은 가능해도 HTTPS 에서 HTTP 요청은 보안의 문제도 되지 않기 때문이다 )

 

 AWS 의 서비스인 Route53과 ACM(AWS Certificate Manager) 로 인증서를 발급받고 보안 통신을 할 수 있는 방법을 이용해서 HTTPS 통신이 가능하게 해결해주셨다.

 

 

어디서 문제가 생겼고, 이를 어떻게 해결해야될지 파악하려면 네트워크 등의 CS 공부가 필요하겠구나 느끼게 해준 이슈였다. 또한 프론트엔드 개발자를 희망한다하더라도 소통을 위해 백엔드에서 하는 작업에 대해 기초 정도는 알고 있어야겠다 생각했다.

 

 

 

 세 번째는 변동사항이 즉각공유되지 않는 경우가 있었다. (소통의 어려움)

 

API 명세서를 노션으로 관리했는데, 그러다보니 문서가 바뀌었다고 고지해주는 것이 정말 중요했다.

말도 없이 url이나 변수명을 바꿔버리시면 에러가 나기에 (후반부에는 에러가 나면  API명세서부터 확인했지만,  초반에는 됐던 코드가 갑자기 작동이 안되니 내가 뭘 잘못 건드렸나하고 헤맸었다ㅜㅜ) 아주 중요한 부분이다.

 

그래서 우리는 여기에서 문제점을 인식하고 디스코드에 항상 상주하며 언제든지 궁금한 점이 생겼을 때 공유하고, 해결할 수 있도록 환경을 조성했다. 또한 매일 아침에 진행상황, 제안/요청할 사항들, 궁금한 점과 함께 회의록을 전달해 백엔드<-> 프론트엔드 서로가 어떻게 작업하고 있는지 파악할 수 있게 하자고 제안했다. 그리고 한 기능으로 엮인 프론트와 백 개발자는 회의방을 따로 만들어 더욱 긴밀한 연락을 할 수 있게 만들었다.

 

위 방법들을 이용해 소통에서 오는 문제를 대폭 줄일 수 있었다.

 

추가적으로 다음 협업 땐 Spring Rest Docs 또는 Spring Swagger를 사용해서 API 명세서를 자동 업데이트 시켜주시면 너무 좋을 것 같다 히히

 

 

---

< 회고 - 2. 최적화 >

 

 최적화는 이번에 처음 도전하는 거였다. 방법도 다양하고, 성능을 측정하는 툴도 다양해서 어떤 것을 목표로 잡아야될지에 대해 고민을 했었다.

결론적으론 Lighthouse를 이용해서 성능을 측정하고, 성능 점수를 95점 위로 올리는 것을 목표로 잡았다.
(카카오맵 api 때문에 100점은 어려울 것이라 생각했다.)

그리고 그에 관련해 작성한 글이다. 

https://sol-mi.tistory.com/87

Lighthouse 점수 어떻게 올리는 건데~! (feat. 성능 최적화)

 

---

 

< 회고 - 3. 코드리뷰 >

 

 코드리뷰는 강추강추강강추이자 필수필수필필수!

 

지난 Calit 프로젝트를 할 땐 6주 중에 5주는 대면으로 작업을 진행했었다. (주말까지 반납하고 💦😥 그래도 덕분에 많은 것을 얻었다 ><) 대면으로 하니 전체적인 상황을 팀원 모두가 공유하고 있었고, 결과적으로 문제가 생겼을 때 빠른 해결을 할 수 있었다. 그리고 PR 코드리뷰를 1순위로 두고 작업을 했기에 더욱 단단하게 프로젝트를 파악하고 있을 수 있었다.

 

여기서 느낀게 많아서 이번 프로젝트 때에도 코드리뷰를 빡!시게 했다.

마감 하루 전에 한번에 1000줄을 올린 PR은 확인하지 못했지만 마감 이틀전까지는 최대한 꼼꼼히 코드리뷰를 진행했다.

 

코드리뷰 내용은 아래 3가지 정도였다.

- 다른 더 좋은 방법에 대한 제안

- 그렇게 코드를 작성한 이유

- 이론적인 부분에 대한 질문

 

그리고 내가 느꼈던 장점

- 전체적인 코드의 통일성 향상

- 의미없는 코드들 솎아내기

- 효율적인 코드 작성 → 남의 코드를 리뷰하면서 배우는 것도 있고, 내 코드에 대한 리뷰에서도 배우는 점이 있다!

- 문제나 고민이 생겼을 때 공유가 쉽다

- 소통이 활발해짐 → 꿀팁 / 새로 알게된 이론 공유 활발, 의문점이 생겼을 때 질문하기 좋은 환경

 

솔직히 코드리뷰하면서 공부가 제일 많이 되었던 것 같다.

 

이후 코드리뷰할 때 조금 더 신경써야겠다고 느낀 점

- 다른 방법에 대해 제안할 땐 간단한 예시 코드 제시해주기
  : 만약 해당 방법을 처음 써보는 상황일 때, 예시 코드가 없다면 따로 공부를 하느라 시간이 소모되는 경우들을 보았다. 
    간단하게라도 예시 코드를 제시해주면 그런 시간을 조금 더 단축시키는 데 도움이 될 것 같다 생각했다.

 

다음 번에는 페어 프로그래밍을 진행해보고 싶은 생각이 있는데, 

비슷한 개념으로 PR을 할 때도 짝꿍이 있다면 내 코드를 더 꼼꼼히 봐주는 사람이 있을 것 같아서 한번 시도해보고 싶다!

 

 

---

 개선할 사항 

 

useCallback, useMemo, React.Memo에 대한 나만의 기준 세우고 한 번 더 최적화 도전하기

 

 

---

 마무리 하며 

 

• 짧은 프로젝트 기간으로 인해 백엔드와 더욱 긴밀한 소통을 해볼 수 있는 값진 경험이 되었습니다. 원활한 소통을 위한 방법과 개발 기간을 효율적으로 사용하는 방법에 대해 많은 고민을 해보았습니다. 이슈나 궁금증이 생겼을 때 즉각적으로 소통할 수 있는 창구를 만들어 놓는 것이 중요한 것 같습니다. 저희는 디스코드에 항상 상주해 실시간으로 소통할 수 있도록 했고, 이는 프론트엔드 사이에서도, 프론트&백 사이에서 이슈가 생겼을 때 모두 빠르게 참여해 해결할 수 있는 환경을 만들어주었습니다.또한 코드리뷰를 매번 꼼꼼히 하는 환경을 조성해서 서로의 코드를 파악하고 있다보니 전체적으로 코드의 통일성도 높아지고, 큰 이슈 없이 프로젝트를 마칠 수 있었습니다.

 

• lighthouse 점수를 높이는 것을 목표로 리팩토링을 진행해보았는데, 같은 동작을 하더라도 어떤 방식으로 코드를 짜고, 설계하는지에 따라 점수 차이가 큰 것이 와닿았었습니다. 코드 스플리팅과 font 최적화가 가장 큰 영향을 주었습니다. font가 주는 부담을 줄이기 위해서는 dynamic subset과 preload를 적용해보았습니다.

 

•  같은 동작을 하는 코드를 다양한 방식으로 다시 짜보고, 백엔드와 일정 조율에 있어서 이슈가 생겼을 땐 MSW도 도입해보며 성장하는 시간을 보낸 것 같습니다. 또한 재활용할 수 있는 공통 컴포넌트들을 여럿 제작해보며 확장성이 좋은 컴포넌트를 만드는 힘을 기를 수 있었습니다. 팀원분들께서 좋은 코드를 많이 짜주셔서 코드리뷰를 하면서도 많이 배울 수 있었습니다. 또한 늦은 시간에도 정성스런 답변을 해주신 멘토님께도 감사드립니다 :)