📌 목차
전시로그를 통해 각 전시회의 세부 정보를 확인할 수 있고 별점과 감상평을 통해 자신의 생각과 경험을 나눌 수 있어요
전시로그를 통해 전시회 경험을 쌓아보세요!
- Nginx를 리버스 프록시로 사용
- 배포를 위한 jar 파일 및 이미지 저장을 위한 AWS S3 저장소
- Github Actions와 AWS Code Deploy를 사용한 빌드, 테스트 및 배포 자동화 구축
팀 내 API 문서 공유를 위해 Swagger를 적용했습니다. 아래는 문서 내용 일부입니다.
Notion vs Spring REST docs vs Swagger
일정 관리부터 팀 내 정보 공유와 같은 대부분의 기록을 Notion으로 하고 있었기에 프로젝트 초기에는 Notion을 사용하여 API 문서화를 진행하는 것이 타 파트와의 소통 면에서 가장 효과적일 것이라고 생각했습니다. 하지만, 손수 작성해야 한다는 번거로움과 MVP 개발의 짧은 기간 때문에 Notion은 후보에서 제외하게 되었습니다.
코드 상에서 문서화 할 수 있도록 Swagger를 적용하여 개발을 하였으나, Swagger 코드가 섞여 코드의 가독성이 떨어진다는 불편함이 발생하여 Spring REST docs의 도입을 고민하게 되었습니다.
코드에 문서화를 위한 내용이 섞이지 않는 점과 높은 자유도가 강력하게 느껴졌습니다. 하지만, 짧은 기간에 빠르게 개발해야 하는 상황에서 테스트 코드가 강제된다는 점이 도입에 어려움을 주었고, Swagger를 사용하여 API 문서화를 이어가도록 결정했습니다.
HTTPS와 리버스 프록시 설정을 위해 Nginx를 사용했습니다. MVP 개발 시점에서는 서버가 큰 상황이 아니지만, 무중단 배포와 정적 이미지 캐싱, 압축을 비롯하여 확장성 면에서 가능성을 열어두고자 Nginx를 도입했습니다.
프로젝트를 진행하며 빠른 수정과 반영을 위해 빌드 및 배포 자동화가 필요했습니다. Jenkins와 Github Actions라는 두 후보가 있었는데, 아래와 같은 이유로 Github Actions를 선택했습니다.
젠킨스는 아이템 별 스크립트의 진행 상황을 별도 대시보드에서 확인할 수 있다는 점이 좋았습니다. 하지만, 메모리 소모가 큰 편이라 구축 시 스프링 서버와 별도로 추가적인 서버를 위한 비용이 필요하다는 점과 초기 구축에 번거로움이 있다는 점으로 인해 보류하게 되었습니다. 더욱이 젠킨스의 큰 장점인 여러 플러그인을 통한 호환성과 복잡한 경우에서의 커스터마이징이 해당 프로젝트에는 필요성이 떨어졌습니다.
GitHub Actions는 깃허브를 사용하고 있고, 깃허브에서 바로 확인할 수 있다는 점이 좋았습니다. 프로젝트 경험이 적은 팀원과 협업 시에도 한 눈에 확인할 수 있었고, 설정이 간편해 프로젝트 초기부터 빠르게 적용할 수 있었습니다. 복잡한 상황에서의 커스터마이징이 필요하지 않았고, 추가적인 비용이 필요하지 않다는 점이 팀의 기술 선택에 가장 큰 이유입니다.
| 스플래시 | 로그인 | 약관동의 | 회원가입 |
|---|---|---|---|
 |
 |
 |
 |
| 홈 | 상세정보 | 포스터 다운로드 | 감상평 작성 | 댓글 작성 | 전시장 |
|---|---|---|---|---|---|
 |
 |
 |
 |
 |
 |
| 검색 | 검색 결과 | 포토캘린더 | 포스터 불러오기 | 관리자 페이지 | 신고 |
|---|---|---|---|---|---|
 |
 |
 |
 |
 |
 |
| 내 별점 | 내 감상평 | 내 즐겨찾기 | 설정 |
|---|---|---|---|
 |
 |
 |
 |
| 타 유저 포토캘린더 | 팔로잉 & 팔로워 | 활동 알림 | 전시 리마인더 알림 |
|---|---|---|---|
 |
 |
 |
 |