프로젝트 Github 주소
https://github.com/HanSeulChung/CafeApp
GitHub - HanSeulChung/CafeApp: CafeApp REST API
CafeApp REST API. Contribute to HanSeulChung/CafeApp development by creating an account on GitHub.
github.com
-> 해당 github에 readme.md에 프로젝트 기능 설계와 ERD를 기록해놨습니다.
프로젝트 개요
카페앱: ' 해당 카페의 메뉴(음식, 음료, MD 굿즈)를 미리 결제하고 주문하는 서비스'을 개인 프로젝트으로 약 4주간 진행했다.
개인적으로 정말 애착이 갔던 프로젝트이다. 왜냐하면 내가 백엔드에 대해서 관심이 깊어진 것이 실제 카페 주문앱을 만들고 싶었던 것이기 때문이다. (TMI: 수많은 사람들이 회사 가기전 출근길에 포장으로 메뉴를 결제하고 가는 모습을 보고 든 생각은 "정말 사용하는 사람이 많구나." 였다. 그럼 나만 불편함을 느끼는게 아니라 다른 사람들도 이 앱에 대해서 불편함을 느끼고 있었겠구나라는 생각이들면서 모두가 편리한 서비스를 만들고 싶은 생각이 들었다. 그래서 백엔드 학습과정을 시작했었다.)
그래서 완성된 모습이 아쉽긴하다. 그저 반복된 CRUD뿐이고 별다른 기술을 접목하지 못했다. 당연히 있어야할 동시성 제어조차 다루지 못했다. 그리고 제일 하고 싶었던 알람 기능을 넣지 못해서 정말 아쉬웠다. 그럼에도 해당 개인 프로젝트로 배운점이 많다.
배운 점
매직넘버
매직넘버에 대한 지향/지양에 대한 의견은 분분하나 나는 매직넘버에 대해서 생각하지 않았기때문에 이번 프로젝트로 한 클래스 안에 의미있는 숫자나 final String 값 같은 경우에는 enum처리말고도 매직넘버 처리를 하면 된다는 것을 배웠다.
하지만 0같은 경우에는 나는 매직넘버 처리를 꼭 해야하나 의문은 갖고있어서 처리하지 않았다. 예를 들어 주문을 할때 재고 + 주문 양이 0보다 작으면 주문을 하지 못하게 해야하는데 이때 그냥 if (재고 + 주문 양 < 0) 이라고 두는 것이 나는 더 직관적이라고 생각하는데 이건 협업시 서로 의사소통해서 넘겨짚으면 좋을 것 같다.
MVC 분리
컨트롤단에서 message(주문완료 메시지)를 넣는 과정을 넣어놨는데 이는 mvc 분리가 안되는 것이므로 수정했다.
그저 간단한 message 값을 OrderResponse.toResponse(orderDto, message); 이렇게 넣는 것이라 안일하게 생각했으나
컨트롤러는 컨트롤러의 책임만, 서비스는 서비스의 책임만, 서로 겹치지 않도록 주의해야한다.
테스트 코드
테스트코드의 중요성은 모두가 안다고 생각한다.
그러나 습관화하는 것은 쉽지 않았다. 각 서비스나 컨트롤러마다 테스트코드를 만들기에는 시간이 너무 역부족이었다.
그래서 컨트롤러단에서 테스트코드는 진행하지 않았고, 서비스단에서만 테스트 코드를 진행하였다.
이번엔 @SpringBootTest가 아니라 Mock 테스트를 연습하고 싶었기에 mock 테스트만 작성했다.
그러나 진행 중에 나는 mock에 대해서 의문을 가지게 되었다.
테스트하고 싶은 코드에서 가짜 객체를 만들고 when().thenReturn()으로 나오는 것을 지정해 두는 것이 정확성이 있는 테스트인지 궁금했다. 그저 답지를 펼쳐놓고 채점하는 기분 같아서 멘토님께도 여쭤보고 구글링을 해봤다.
결론적으로 mock 테스트는 직접 구현한 비즈니스 로직에 대해서 테스트를 하는 것이기 때문에 로직 안에 있는 객체들을 가짜로 정해두고 로직을 테스트하는 것이기 때문에 제대로 된 방법인 것을 알게됐다.
내가 찝찝했던 객체 자체를 테스트하고 싶다면, JPA 하이버네이트가 제공하는 메서드 자체를 @DataJpaTest를 통해 테스트를 진행하면 된다.
그리고 인스턴스의 변환이나, 값의 변경 등 Java 소스 내에서 이뤄지는 로직만을 분리해서 테스트가 진행되어야 비로소 단위테스트(mock 테스트)가 의미가 있는데, 나의 경우에는 대부분의 로직이 DB와의 상호작용을 하는 로직이었기 때문에 Integration testing에 대해서 더 생각했어야 좋은 테스트 코드였다.
마지막으로 테스트 코드를 진행하면서 영속성 컨텍스트에 대해서 더 가깝게 느낄 수 있었다. 영속성에 대해서 데이터베이스에대해서 공부할때도 제일 많이나오고 처음나와서 간과했었는데 본질적으로 다시 학습해야한다고 또 느꼈다. 영속성에 대해서도 정리를 해봐야겠다.
Git
git과 원격저장소 github에 대해서 정말 많이 생각하게 된 계기다. 회사다닐 때는 회사 내에서 SVN을 썼기 때문에 Git으로 형상관리를 하지 않았다. 그리고 예전에 국비학원 당시에도 팀프로젝트를 했지만 별다른 브랜치 전략이 없었다. 각자 이름으로 브랜치를 따서 main에 merge하는 형식이거나 jupyter_notebook, colab을 공유 하는 식으로 진행했었다. 그러나 해당 프로젝트시 PR(pull request)진행을 해야했기 때문에 따로 고정적으로 변화값을 merge할 브랜치가 있어야했다. 그래서 인터넷에서 git flow에 대해서 알게 되었고 나는 팀프로젝트(협업)가 아니라 개인프로젝트지만, 훗날 팀프로젝트와 회사에서 잘 적응하기 위해 내가 지금부터라도 숙지해야겠다는 생각을 했다.
그리고 내 인텔리제이에서 git 기록을 보는데 많은 브랜치를 머지하고 생성하는 과정에서 너무 지저분하다고 생각했다..
물론 다른 시각에서는 이정도는 괜찮다고 생각될수도 있지만, 여러명이 있으면 분명 더 지저분할거라고 생각이 들어서
나부터 깃 머지전략에 대해서 정립을 어느정도 해놔야겠다고 생각을 했다.
Git flow에 대해서 참고 자료 : https://techblog.woowahan.com/2553/
우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그
{{item.name}} 안녕하세요. 우아한형제들 배민프론트개발팀에서 안드로이드 앱 개발을 하고 있는 나동호입니다. 오늘은 저희 안드로이드 파트에서 사용하고 있는 Git 브랜치 전략을 소개하려고 합
techblog.woowahan.com
Git merge 전략
나는 우선 main브랜치를 기준으로 두고 거기에 dev 브랜치를 생성하고 기능 구현할 때마다 feature/기능1 브랜치를 생성하고 merge하는 전략을 취했다. 나는 배포없이 진행했기 때문에 생성하면 merge하고 끝인 전략이다. 후에는 dev에서 feature 브랜치에 fetch도 해야하고 더 복잡해지겠지만 우선 해당 깃 머지 전략을 두고 학습하고 연습했다.
1. main <- dev : PR을 통한 일반 create merge
2. dev <- feature
2번에 대해서 고민을 많이 했다. 사람들 마다 선호하는 merge전략도 다르고 해서 우선 둘다 해봤다.
squash merge전략과 rebase merge 전략을 두개다 진행했다. 이것이 개인프로젝트의 장점,,
Squash merge 전략
훨씬 예뻐지고 내가 어떻게 브랜치를 만들었는지 직관적으로 보여줘서 마음이 한결 평안해졌었다.
Rebase merge 전략
처음 squash merge 전략을 하고나서 너무 만족했는데 merge하고 남은 내 local에서 해당 feature 브랜치를 삭제하려면 강제로 삭제해야해서 (나는 강제가 무섭다...) rebase로 진행했다.. 하지만 내가 어떤 기능구현을 위해 feature 브랜치를 생성했었고 merge를 했는지 명확하게 보이는 건 squash merge인 것 같다.
rebase merge 전략시 주의해야할 점
트러블 슈팅에도 명시했지만 rebase merge 전략을 취하기로 했으면 원격 저장소에 push 하면 안된다. rebase가 깔끔하게 되는 이유가 해당 커밋을 해시값을 변경해 다른 커밋 값으로 간주하기 때문에 합쳐질 수 있는 것이다. 그러나 원격 저장소에 올려두면 그게 독이된다. 같은 커밋 값인데 컴퓨터는 해시값으로만 보고 다른 커밋으로 알고 다 기록해두기 때문이다.
그래서 나는 rebase merge 전략을 취했을 때는 feature 브랜치를 원격 저장소에 push하지 않았다.
티켓번호
비밀번호 변경, 로그아웃, 로그인시 토큰 발행과 같이 하나의 기능으로 간주 될때 티켓번호를 발행했다.
그러나 여기서 나는 티켓번호를 자동화해주는 tool을 알지 못했으나 지인이 "너 이거 설마 수동으로 해?"라고 해서 찾아보게 됐다. 후에 깃 후크로 티켓번호를 조작 학습을 할 것이다.
수동으로 해서 내가 실수를 겪었기 때문에 자동화 tool 학습에 대한 중요성도 알게됐다.
merge 전 commit에서는 카운팅을 잘해서 FEAT-017, FEAT-018으로 써놓고 merge할때 16,17으로 commit, push 한것이다.. 너무 거슬려서 --force를 이용해서 강제로 바꿀까도 했지만 개인프로젝트에서만 프로젝트를 할것이 아니기때문에 기억해두고 잘 숙지하자라는 마음으로 남겨 놨다..
Pull Request
PR 덕분에 내가 놓치고 있던 부분을 알려주시는 멘토님과 다른 학우들 덕에 다른 시각으로 볼 수 있었지만 개인적으로 내게 이번 프로젝트는 pr이 조금 아쉬웠다고 생각된다.
이번 pr은 멘토님 1분과 함께 같이 학습하는 학우들끼리 pr해주기로 했었다. 나도 학우들의 프로젝트에서 코드리뷰를 내가 아는선에서 많이 해주고 싶었으나 아예 올리지 않는 친구들도 있어서 해주지 못한 적도 있다. 많은 사람들과 다양한 코드리뷰를 주고받지 못한 점이 아쉬웠다.
그리고 해당 pull request를 처음 진행하면서 commit 수를 최대한 기능별로 세분화 해야 보기 명확하다는 것을 알았고 commit message가 어떤것을 의미하는지 정확하게 써야 코드리뷰하기도 편하다는 것을 알았다.
아쉬운 점
관계자 회원가입
실제 배포하고 사용자가 있는 서비스를 구현하는 것은 아니었으나 내 타겟은 개인카페가 아닌 프렌차이즈점 카페로 생각해뒀고 카페 관계자들 중에서 해당 서비스를 이용(메뉴 등록, 수량 변경 등등)할 사람들은 매니저직급 이상부터 가능하도록 혼자 진지하게 설계했다.
일하는 매니저들이 따로 회원가입을 통해 id, password를 설정하기 보다 특정 지점에서 새로운 매니저가 들어왔을 때 회원가입을 회사에 신청하는 구조로 설계해뒀다 ㅋㅋ. 그래서 sql문으로 우선 database에 넣어두고 비밀번호만 변경 가능하도록해뒀다.
2024/02 ~ 1차 리팩토링 후 변경
-> sql문을 없애고 관계자도 회원가입이 가능하도록 구현했다. auth 관련 공통적인 서비스(admin이나 member의 repository를 따로 들어가는 것이 아닌 것들)과 admin과 member 별 따로 구현해야하는 서비스별로 인터페이스를 나눠 해당 인터페이스를 구현하도록 했다.
JPA의 N + 1 문제 fetch로 해결
인터넷에 많이 나오는 방법인 fetch로 해결할 수 있는 것을 인지했으나 아직 영속성 컨텍스트에 대해 더 깊게 이해한 뒤 적용하고 싶어 미적용 했다.
배포
시간 관계상 배포는 하지 못했다.
2024/02~ 1차 리팩토링 후 변경
설계부터 기능구현 그리고 배포까지 역량을 갖춘 신입 백엔드 개발자가 되고자 리팩토링 기간에 EC2서버와 RDS, docker를 이용해 배포를 완료하였다.
swagger docs를 정리하진 못했지만 http://3.34.126.99:8080/swagger-ui/index.html 에서 확인 가능하다.
프로젝트 Github 주소
https://github.com/HanSeulChung/CafeApp
GitHub - HanSeulChung/CafeApp: CafeApp REST API
CafeApp REST API. Contribute to HanSeulChung/CafeApp development by creating an account on GitHub.
github.com
-> 해당 github에 readme.md에 프로젝트 기능 설계와 ERD를 기록해놨습니다.
프로젝트 개요
카페앱: ' 해당 카페의 메뉴(음식, 음료, MD 굿즈)를 미리 결제하고 주문하는 서비스'을 개인 프로젝트으로 약 4주간 진행했다.
개인적으로 정말 애착이 갔던 프로젝트이다. 왜냐하면 내가 백엔드에 대해서 관심이 깊어진 것이 실제 카페 주문앱을 만들고 싶었던 것이기 때문이다. (TMI: 수많은 사람들이 회사 가기전 출근길에 포장으로 메뉴를 결제하고 가는 모습을 보고 든 생각은 "정말 사용하는 사람이 많구나." 였다. 그럼 나만 불편함을 느끼는게 아니라 다른 사람들도 이 앱에 대해서 불편함을 느끼고 있었겠구나라는 생각이들면서 모두가 편리한 서비스를 만들고 싶은 생각이 들었다. 그래서 백엔드 학습과정을 시작했었다.)
그래서 완성된 모습이 아쉽긴하다. 그저 반복된 CRUD뿐이고 별다른 기술을 접목하지 못했다. 당연히 있어야할 동시성 제어조차 다루지 못했다. 그리고 제일 하고 싶었던 알람 기능을 넣지 못해서 정말 아쉬웠다. 그럼에도 해당 개인 프로젝트로 배운점이 많다.
배운 점
매직넘버
매직넘버에 대한 지향/지양에 대한 의견은 분분하나 나는 매직넘버에 대해서 생각하지 않았기때문에 이번 프로젝트로 한 클래스 안에 의미있는 숫자나 final String 값 같은 경우에는 enum처리말고도 매직넘버 처리를 하면 된다는 것을 배웠다.
하지만 0같은 경우에는 나는 매직넘버 처리를 꼭 해야하나 의문은 갖고있어서 처리하지 않았다. 예를 들어 주문을 할때 재고 + 주문 양이 0보다 작으면 주문을 하지 못하게 해야하는데 이때 그냥 if (재고 + 주문 양 < 0) 이라고 두는 것이 나는 더 직관적이라고 생각하는데 이건 협업시 서로 의사소통해서 넘겨짚으면 좋을 것 같다.
MVC 분리
컨트롤단에서 message(주문완료 메시지)를 넣는 과정을 넣어놨는데 이는 mvc 분리가 안되는 것이므로 수정했다.
그저 간단한 message 값을 OrderResponse.toResponse(orderDto, message); 이렇게 넣는 것이라 안일하게 생각했으나
컨트롤러는 컨트롤러의 책임만, 서비스는 서비스의 책임만, 서로 겹치지 않도록 주의해야한다.
테스트 코드
테스트코드의 중요성은 모두가 안다고 생각한다.
그러나 습관화하는 것은 쉽지 않았다. 각 서비스나 컨트롤러마다 테스트코드를 만들기에는 시간이 너무 역부족이었다.
그래서 컨트롤러단에서 테스트코드는 진행하지 않았고, 서비스단에서만 테스트 코드를 진행하였다.
이번엔 @SpringBootTest가 아니라 Mock 테스트를 연습하고 싶었기에 mock 테스트만 작성했다.
그러나 진행 중에 나는 mock에 대해서 의문을 가지게 되었다.
테스트하고 싶은 코드에서 가짜 객체를 만들고 when().thenReturn()으로 나오는 것을 지정해 두는 것이 정확성이 있는 테스트인지 궁금했다. 그저 답지를 펼쳐놓고 채점하는 기분 같아서 멘토님께도 여쭤보고 구글링을 해봤다.
결론적으로 mock 테스트는 직접 구현한 비즈니스 로직에 대해서 테스트를 하는 것이기 때문에 로직 안에 있는 객체들을 가짜로 정해두고 로직을 테스트하는 것이기 때문에 제대로 된 방법인 것을 알게됐다.
내가 찝찝했던 객체 자체를 테스트하고 싶다면, JPA 하이버네이트가 제공하는 메서드 자체를 @DataJpaTest를 통해 테스트를 진행하면 된다.
그리고 인스턴스의 변환이나, 값의 변경 등 Java 소스 내에서 이뤄지는 로직만을 분리해서 테스트가 진행되어야 비로소 단위테스트(mock 테스트)가 의미가 있는데, 나의 경우에는 대부분의 로직이 DB와의 상호작용을 하는 로직이었기 때문에 Integration testing에 대해서 더 생각했어야 좋은 테스트 코드였다.
마지막으로 테스트 코드를 진행하면서 영속성 컨텍스트에 대해서 더 가깝게 느낄 수 있었다. 영속성에 대해서 데이터베이스에대해서 공부할때도 제일 많이나오고 처음나와서 간과했었는데 본질적으로 다시 학습해야한다고 또 느꼈다. 영속성에 대해서도 정리를 해봐야겠다.
Git
git과 원격저장소 github에 대해서 정말 많이 생각하게 된 계기다. 회사다닐 때는 회사 내에서 SVN을 썼기 때문에 Git으로 형상관리를 하지 않았다. 그리고 예전에 국비학원 당시에도 팀프로젝트를 했지만 별다른 브랜치 전략이 없었다. 각자 이름으로 브랜치를 따서 main에 merge하는 형식이거나 jupyter_notebook, colab을 공유 하는 식으로 진행했었다. 그러나 해당 프로젝트시 PR(pull request)진행을 해야했기 때문에 따로 고정적으로 변화값을 merge할 브랜치가 있어야했다. 그래서 인터넷에서 git flow에 대해서 알게 되었고 나는 팀프로젝트(협업)가 아니라 개인프로젝트지만, 훗날 팀프로젝트와 회사에서 잘 적응하기 위해 내가 지금부터라도 숙지해야겠다는 생각을 했다.
그리고 내 인텔리제이에서 git 기록을 보는데 많은 브랜치를 머지하고 생성하는 과정에서 너무 지저분하다고 생각했다..
물론 다른 시각에서는 이정도는 괜찮다고 생각될수도 있지만, 여러명이 있으면 분명 더 지저분할거라고 생각이 들어서
나부터 깃 머지전략에 대해서 정립을 어느정도 해놔야겠다고 생각을 했다.
Git flow에 대해서 참고 자료 : https://techblog.woowahan.com/2553/
우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그
{{item.name}} 안녕하세요. 우아한형제들 배민프론트개발팀에서 안드로이드 앱 개발을 하고 있는 나동호입니다. 오늘은 저희 안드로이드 파트에서 사용하고 있는 Git 브랜치 전략을 소개하려고 합
techblog.woowahan.com
Git merge 전략
나는 우선 main브랜치를 기준으로 두고 거기에 dev 브랜치를 생성하고 기능 구현할 때마다 feature/기능1 브랜치를 생성하고 merge하는 전략을 취했다. 나는 배포없이 진행했기 때문에 생성하면 merge하고 끝인 전략이다. 후에는 dev에서 feature 브랜치에 fetch도 해야하고 더 복잡해지겠지만 우선 해당 깃 머지 전략을 두고 학습하고 연습했다.
1. main <- dev : PR을 통한 일반 create merge
2. dev <- feature
2번에 대해서 고민을 많이 했다. 사람들 마다 선호하는 merge전략도 다르고 해서 우선 둘다 해봤다.
squash merge전략과 rebase merge 전략을 두개다 진행했다. 이것이 개인프로젝트의 장점,,
Squash merge 전략
훨씬 예뻐지고 내가 어떻게 브랜치를 만들었는지 직관적으로 보여줘서 마음이 한결 평안해졌었다.
Rebase merge 전략
처음 squash merge 전략을 하고나서 너무 만족했는데 merge하고 남은 내 local에서 해당 feature 브랜치를 삭제하려면 강제로 삭제해야해서 (나는 강제가 무섭다...) rebase로 진행했다.. 하지만 내가 어떤 기능구현을 위해 feature 브랜치를 생성했었고 merge를 했는지 명확하게 보이는 건 squash merge인 것 같다.
rebase merge 전략시 주의해야할 점
트러블 슈팅에도 명시했지만 rebase merge 전략을 취하기로 했으면 원격 저장소에 push 하면 안된다. rebase가 깔끔하게 되는 이유가 해당 커밋을 해시값을 변경해 다른 커밋 값으로 간주하기 때문에 합쳐질 수 있는 것이다. 그러나 원격 저장소에 올려두면 그게 독이된다. 같은 커밋 값인데 컴퓨터는 해시값으로만 보고 다른 커밋으로 알고 다 기록해두기 때문이다.
그래서 나는 rebase merge 전략을 취했을 때는 feature 브랜치를 원격 저장소에 push하지 않았다.
티켓번호
비밀번호 변경, 로그아웃, 로그인시 토큰 발행과 같이 하나의 기능으로 간주 될때 티켓번호를 발행했다.
그러나 여기서 나는 티켓번호를 자동화해주는 tool을 알지 못했으나 지인이 "너 이거 설마 수동으로 해?"라고 해서 찾아보게 됐다. 후에 깃 후크로 티켓번호를 조작 학습을 할 것이다.
수동으로 해서 내가 실수를 겪었기 때문에 자동화 tool 학습에 대한 중요성도 알게됐다.
merge 전 commit에서는 카운팅을 잘해서 FEAT-017, FEAT-018으로 써놓고 merge할때 16,17으로 commit, push 한것이다.. 너무 거슬려서 --force를 이용해서 강제로 바꿀까도 했지만 개인프로젝트에서만 프로젝트를 할것이 아니기때문에 기억해두고 잘 숙지하자라는 마음으로 남겨 놨다..
Pull Request
PR 덕분에 내가 놓치고 있던 부분을 알려주시는 멘토님과 다른 학우들 덕에 다른 시각으로 볼 수 있었지만 개인적으로 내게 이번 프로젝트는 pr이 조금 아쉬웠다고 생각된다.
이번 pr은 멘토님 1분과 함께 같이 학습하는 학우들끼리 pr해주기로 했었다. 나도 학우들의 프로젝트에서 코드리뷰를 내가 아는선에서 많이 해주고 싶었으나 아예 올리지 않는 친구들도 있어서 해주지 못한 적도 있다. 많은 사람들과 다양한 코드리뷰를 주고받지 못한 점이 아쉬웠다.
그리고 해당 pull request를 처음 진행하면서 commit 수를 최대한 기능별로 세분화 해야 보기 명확하다는 것을 알았고 commit message가 어떤것을 의미하는지 정확하게 써야 코드리뷰하기도 편하다는 것을 알았다.
아쉬운 점
관계자 회원가입
실제 배포하고 사용자가 있는 서비스를 구현하는 것은 아니었으나 내 타겟은 개인카페가 아닌 프렌차이즈점 카페로 생각해뒀고 카페 관계자들 중에서 해당 서비스를 이용(메뉴 등록, 수량 변경 등등)할 사람들은 매니저직급 이상부터 가능하도록 혼자 진지하게 설계했다.
일하는 매니저들이 따로 회원가입을 통해 id, password를 설정하기 보다 특정 지점에서 새로운 매니저가 들어왔을 때 회원가입을 회사에 신청하는 구조로 설계해뒀다 ㅋㅋ. 그래서 sql문으로 우선 database에 넣어두고 비밀번호만 변경 가능하도록해뒀다.
2024/02 ~ 1차 리팩토링 후 변경
-> sql문을 없애고 관계자도 회원가입이 가능하도록 구현했다. auth 관련 공통적인 서비스(admin이나 member의 repository를 따로 들어가는 것이 아닌 것들)과 admin과 member 별 따로 구현해야하는 서비스별로 인터페이스를 나눠 해당 인터페이스를 구현하도록 했다.
JPA의 N + 1 문제 fetch로 해결
인터넷에 많이 나오는 방법인 fetch로 해결할 수 있는 것을 인지했으나 아직 영속성 컨텍스트에 대해 더 깊게 이해한 뒤 적용하고 싶어 미적용 했다.
배포
시간 관계상 배포는 하지 못했다.
2024/02~ 1차 리팩토링 후 변경
설계부터 기능구현 그리고 배포까지 역량을 갖춘 신입 백엔드 개발자가 되고자 리팩토링 기간에 EC2서버와 RDS, docker를 이용해 배포를 완료하였다.
swagger docs를 정리하진 못했지만 http://3.34.126.99:8080/swagger-ui/index.html 에서 확인 가능하다.
