[우테코 Lv2] 레벨2 미션4 방탈출 결제 / 배포 회고

깨알 홍보

레벨 2 마지막 회고글에 들어가기 앞서 홍보 하나 하겠습니다 😎 깃 좀 써봤다 하면 재밌게 들을 수 있는 내용입니다. 많관부~!

👇👇👇

https://youtu.be/K45jv8DbB88?si=mgoRHQ3UNIcHP8Q7

🏃‍♂️ 미션 4: 방탈출 결제 / 배포

레벨 2의 마지막 미션은 "방탈출 결제 / 배포"이다. 토스 페이먼츠 연결, AWS EC2로 배포하기, 문서화와 로깅 등 2주 동안 많은 것을 배울 수 있었다. 그런데 너무 많은 걸 한 탓일까 배웠다기보다는 찍먹 한 느낌ㅎㅎ 또한 레벨 2 마지막 주였다 보니 글쓰기 회고, 원온원, 회식 등등 다양한 활동들과 병행하면서 더 후딱 지나간 것 같다. 그래도 무엇을 했는지 한 번 정리하고 넘어가 보자.

미션 소개

• 사용자가 방탈출 예약 시, 결제를 진행하면 예약이 완료되도록 구현하세요.
• 결제 기능은 외부의 결제 서비스 API를 활용하여 연동합니다.
• 사용자가 내 예약 페이지에서 결제 관련 정보를 예약정보와 함께 볼 수 있도록 제공합니다.

✏️ 학습 목표 체크

이번 회고글에서는 학습 목표 체크를 먼저 하고, 각 단계에서 어떤 것을 경험하고 느꼈는지를 위주로 작성해보겠다.

학습 목표

1. 외부 API(thirdy party API)를 연동하는 경험 ✅
   
   • API 문서를 읽고, 이해하여 API를 연동하는 작업을 진행할 수 있다. ✅
   • 외부 API를 호출하기 위해 REST Client 도구를 선택하고 활용할 수 있다. ✅
2. 외부 API(third party API) 연동 시, 에러 핸들링 ⚠️
   • API 호출 실패 케이스를 검토하고, 안전하게 예외 처리하는 코드를 작성할 수 있다. ⚠️
   • custom exception을 활용하여, 유저에게 유용한 에러 응답을 전달할 수 있다. ✅
3. 신규 도메인 추가 시, 설계 및 구현 ⚠️
   
   • 외부 API의 응답에서 필요한 데이터를 선택적으로 저장할 수 있다. ✅
   • 자신만의 기준을 세워 신규 도메인과 DB 테이블을 설계할 수 있다. ⚠️
4. 외부 API 연동 시, 테스트 전략 ⚠️
   • 외부 API 연동 시 필요한 테스트를 결정하고 수행할 수 있다. ⚠️
   • 외부 API 연동 로직이 포함된 기존 기능을 테스트할 수 있다. ✅

기준을 좀 빡빡하게 잡아서 ⚠️ 가 많다ㅎㅎ 다 경험해 보기는 했는데, 확실히 내 것으로 만들지는 못한 부분이 많은 것 같다. 시간 적으로도 1단계에서 모든 것을 정복하기는 어려웠다. 

🪜 단계별로 살펴보기

STEP1: 1단계 PR

1단계 - 예약 시 결제단계 추가

기존의 예약 시스템에 토스 페이먼츠 API를 활용해 결제 기능을 추가하는 미션이었다.

 

이 미션은 피글렛과 함께 페어로 진행했다. 피글렛과 페어가 된 것은 정말 행운이었다. 피글렛은 레벨1 같은 데일리조 크루이자 레벨2 유강스 가족이다. 덕분에 마지막 페어를 즐겁게 진행할 수 있었다. 편안함이 뒷받침 되었다 보니, 정말 작고 사소한 의견도 마음껏 낼 수 있었다.

외부 API 연동 학습

학습 테스트를 통해 Rest Template, Rest Client 사용법을 학습했다. 이후 주어진 뼈대 코드와 토스 페이먼츠 API 문서를 활용해 결제 승인 API 작동 과정을 학습했다. 문서가 워낙 친절해서 학습하는데 크게 어려움이 없었다. 레벨2 최종 미션을 하면서 다시 한 번 느꼈다. 그 당시 사용했던 외부 API는 사용하는데 정말 문제가 많았다 🤣 토스 최고ㅎㅎ

Rest Client

외부 API와 통신할 도구를 선택하기 위해 RestTemplate, RestClient, WebClient 세 가지를 비교했고, 최종적으로 RestClient를 선택했다. 선택 이유에 대해서는 프롤로그에 다음과 같이 작성했다.

가장 대표적으로 언급되는 RestTemplate, RestClient, WebClient 3가지를 고려했고, 최종적으로 RestClient를 선택했습니다.

RestTemplate이 가장 오래 사용 된 HTTP Client로 가장 많은 자료가 있습니다. 하지만 RestTemplate 을 대체할 RestClient가 출시되었고 현재 RestTemplate은 deprecated 예정이라고 해서 후보에서 제외되었습니다.

WebClient는 비동기/논블로킹 방식의 클라이언트로 메모리와 스레드 효율이 높다는 특징 있습니다. 외부 API와 대량의 데이터를 주고 받을 때 사용하기 좋은 HTTP Client입니다. 하지만 지금 프로젝트에서는 간단한 요청을 주고 받고 있고, WebClient는 학습 곡선이 있다고 판단해 후보에서 제외되었습니다.

RestClient는 메서드 체이닝을 사용해 간결한 표현이 가능합니다. HTTP status 를 이용해서 간결한 예외 처리가 가능합니다. RestClient.Builder를 이용해 클라이언트 커스터마이징을 제공합니다. 또한 MockRestServiceServer 를 사용해 손쉽게 테스트 더블을 만들 수 있습니다.

 

미션을 구현하고 나서는 생각이 좀 바뀌었다ㅎㅎ 처음 기술을 선택할 때 구기술과 신기술 중에 선택하라면 당연히 신기술을 선택하는게 맞다고 생각했다. 하지만 다음에 또 같은 상황이 오면 RestTemplate을 사용할 것이다.

 

우선 RestClient는 인터넷에서 찾을 수 있는 자료의 양이 많이 부족했다. RestTemplate은 2009년에 등장한 기술이고 RestClient는 2023년에 등장한 기술이다. RestClient가 아주 최신 기술이다 보니, 서칭이 잘 되지 않았고 대부분 RestTemplate을 기반으로 설명한 자료가 많았다. 그렇다보니 AI가 답변하는 내용의 질 또한 달랐다. 또한 RestTemplate이 deprecated 될 예정이라는 것은 잘못된 정보였다. Deprecated 될 기술이 아니면 더더욱, 오랜 시간 검증이 되었고, 관련 자료가 많은 RestTemplate을 선택할 것 같다.

에러 응답 처리

토스 페이먼츠 API를 사용할 때, 성공 응답 뿐만 아니라 에러 응답과 타임아웃에 대한 처리도 했다. 토스 페이먼츠의 에러 응답 또한 굉장히 깔끔하게 잘 정리가 되어있다. 이 응답 메시지를 그대로 보여줄지, 필터링 해서 보여줄지에 대해 생각해 볼 수 있었다. 이에 대한 대답은 사용하는 API에 따라, 팀에 따라 달라질 것 같다.

테스트 & 트러블 슈팅

외부 API가 포함된 기능을 테스트하기 위해서 추가적인 테스트 방식들을 학습했다. 토스 페이먼츠 서버를 스터빙 하기 위해 MockRestServiceServer를 사용했다. RestClient가 보내는 요청을 목서버로 가도록 하기 위해 @TestConfiguration 어노테이션을 사용해 테스트용 빈 설정을 추가했다. 빈 사이의 생성 순서를 보장할 필요가 있어서 @DependsOn 어노테이션도 사용했다. 이외에도 테스트 개선을 위해 @SpringBootTest, @DirtyContext 옵션들의 차이에 대해서 직접 테스트를 돌려보면서 학습을 했다.

 

STEP2: 2단계 ~ 4단계

2단계 - 내 예약 페이지 변경 / 3단계 - 배포하기 / 4단계 - 문서화, 로깅

3단계 배포하기에서는 EC2 환경에 스프링 프로젝트를 배포하는 경험을 했다. 배포 스크립트도 간단히 경험해봤다.

 

4단계에서는 완성된 프로젝트에 API 문서와 로깅을 더하는 미션이 주어졌다. 4단계는 요구사항이 거의 없어서 이번 레벨 통틀어서 가장 자유도가 높았던 단계였다 🤓

문서화

문서화 도구로 Rest Docs를 선택했다. 신뢰할 수 있는 문서, 높은 자유도, 무엇보다 프로덕션 코드를 침투하지 않는 다는 점에서 마음에 들었다. 워낙 자유도가 높은 도구이다 보니 학습할 부분이 많았다. 다행히 공식 문서가 잘 되어있어서 공식 문서의 도움을 많이 받았다. 자유도가 높다 보니 오히려 나만의 방법을 만들어 보자는 욕심이 생겼고, 꽤 몰입해서 공부를 할 수 있었다.

 

문서화 피드백 자료에 있는 내용 중 아래 내용이 특히 기억에 남는다.

이번 미션에서 베스트 프랙티스에 가까운 친절한 토스 API 문서를 참고해 개발해본 경험은 어떠셨나요?
✅ 토스 API 문서는 어떤 점에서 친절하다고 느꼈나요?
✅ 내 문서는 다른 개발자가 읽고 바로 작업 할 수 있을만큼 친절한가요?
문서 작성 도구나 방법보다 문서 내용이 더 중요하다!
- 어떤 문서화 도구를 사용했는지는 2순위
- 문서에 필요한 내용이 담겼는지, 친절하고 가독성이 좋은지가 더 중요하다.
- 문서화 도구 선택 시 유지 보수, 사용성 등을 고려하여 선택한다.

 

처음 미션을 하는 과정에서는 문서화 도구를 선택하는 것에 큰 초점을 맞췄다. 하지만 중요한 것은 도구보단 그 내용이다. 실제 프로젝트를 할 때 API 문서에 어떤 내용이 담기는게 좋을 지에 대해서도 팀원들과 이야기를 해보고 싶다.

로깅

로깅은 간단하게 에러 상황에 대해서만 로깅을 남겼다. 모든 요청에 대해서 로깅을 남길 수도 있고, 특정 API에 대해서만 로깅을 남길 수도 있다. 그런데 아직 에러 상황이 아닌 경우에 남긴 로깅의 필요성을 실감하지 못해서 구현하지는 않았다. 항상 개발 과정에서 무엇을 도입할 때 그 필요성을 느끼지 못하면 쉽게 손이 가지 않는 것 같다. 하지만 이번 미션에서는 학습 목적으로 최대한 많은 로깅을 남겨보면 어땠을까 하는 생각도 든다. 하지만 어쩌겠어 이미 지났는걸ㅎㅎ 후회하는건 아니지만, 살짝 반성해본다 😉

🎬 레벨 2를 마무리하며

눈 깜짝할 새에 레벨 2가 끝났다. 레벨 2는 8주 동안 4가지 미션을 통해 하나의 완전한 웹 서비스를 만드는 경험을 할 수 있었다. 그 과정에서 학습하는 방법과 함께하는 방법 또한 배웠다. AI 특강을 통해 AI 도구에 대한 시선도 한 층 넓힐 수 있었다. 또 여러 크루, 리뷰어, 코치와의 대화를 통해 내가 가야할 목표에 대해서 다시 한 번 점검해볼 수 있었다. 이 많은 걸 8주 만에 하다니 정말 귀한 경험을 하고 있구나 다시 한 번 느낀다 😄