📌 목차
DEPlog는 “IT 프로젝트 동아리 DEPth의 기술 블로그”로 기획, 디자인, 개발 각 분야의 회원들이 공부한 내용을 모두와 공유할 수 있는 서비스입니다.
다양한 기업들이 자신들만의 기술 블로그를 통해 정보를 공유하고 있고, 기술 공유 목적과 더불어 해당 기업들의 브랜드 이미지를 홍보하기 위해 기술 블로그를 운영하기도 합니다. 이러한 기업들은 기술 블로그를 통해 만든 이미지로 전략적 이점을 얻고 있으며, "DEPth의 질 높은 정보를 공유함으로써 브랜드 이미지를 강화하자"는 취지로 프로젝트를 시작하게 되었습니다.
- Nginx를 리버스 프록시로 사용하였으며, 로드밸런싱을 설정을 통해 2개의 스프링 애플리케이션으로 트래픽 분산
- 이미지 저장을 위한 AWS S3 저장소
- Github Actions와 Docker를 사용한 빌드, 테스트 및 배포 자동화 구축
팀 내 API 문서 공유를 위해 Swagger를 적용했습니다. 아래는 문서 내용 일부로, 전체 문서는 여기에서 확인하실 수 있습니다.
Notion vs Spring REST docs vs Swagger
일정 관리부터 팀 내 정보 공유와 같은 대부분의 기록을 Notion으로 하고 있었기에 프로젝트 초기에는 Notion을 사용하여 API 문서화를 진행하는 것이 타 파트와의 소통 면에서 가장 효과적일 것이라고 생각했습니다. 하지만, 손수 작성해야 한다는 번거로움과 MVP 개발의 짧은 기간 때문에 Notion은 후보에서 제외하게 되었습니다.
코드 상에서 문서화 할 수 있도록 Swagger를 적용하여 개발을 하였으나, Swagger 코드가 섞여 코드의 가독성이 떨어진다는 불편함이 발생하여 Spring REST docs의 도입을 고민하게 되었습니다.
코드에 문서화를 위한 내용이 섞이지 않는 점과 높은 자유도가 강력하게 느껴졌습니다. 하지만, 짧은 기간에 빠르게 개발해야 하는 상황에서 테스트 코드가 강제된다는 점이 도입에 어려움을 주었고, Swagger를 사용하여 API 문서화를 이어가도록 결정했습니다.
사용자 인증 부분은 JWT를 사용하여 Access Token과 Refresh Token을 통해 구현했습니다.
이전 프로젝트에서 MySQL에 Refresh Token 테이블을 생성하여 관리했을 때와 다르게 Redis를 토큰 저장소로 사용한 이유는 아래와 같습니다.
- 자동 로그인 기능으로 인해 빈번히 발생하는 Refresh Token 검증 과정에서 잦은 RDBMS 접근 발생
- 유효 시간이 만료된 토큰의 불필요한 저장 공간 차지
- 로그아웃 시 해당 토큰을 Redis에 Blacklist 처리하여 만료되지 않은 Access Token의 오용 방지
이 문제들은 Redis에 Refresh Token을 저장하고 TTL기능을 사용하여 구현하면 간단하게 처리할 수 있었습니다. 또한, Redis가 잠시 꺼지더라도 괜찮은 정보들을 저장하는 것이기에 토큰 저장소로 Redis를 사용하게 되었습니다.
개발 환경에서는 jpa의 ddl-auto 기능을 create 혹은 update로 설정해놓아도 문제가 발생하지 않았습니다. 하지만, 배포 후 운영 환경에서는 ddl을 validate 또는 none 옵션을 사용하는 것이 안전하고, DB 스키마의 변경은 일일이 ddl 스크립트를 작성하여 기록해두어야 했습니다.
이후 기능이 추가되고 변경되면서 DB 구조가 변경되는 일이 잦았고, 매번 일일이 ddl 스크립트를 관리하는 것이 번거로울 뿐 아니라 ddl-auto 옵션 설정의 실수 가능성을 줄이기 위해 Flyway를 도입하여 데이터베이스 형상 관리를 진행했습니다.
HTTPS 설정과 로드밸런서 역할을 위해 Nginx를 사용했습니다. MVP 개발 시점에서는 서버가 큰 상황이 아니지만, 무중단 배포와 정적 이미지 캐싱, 압축 등을 비롯하여 확장성 면에서 가능성을 열어두고자 Nginx를 도입했습니다.
초기 구축을 빠르게 진행하고, 실행되는 컨테이너들이 동일한 환경에서 실행되는 것을 보장하기 위해 Docker 이미지를 통해 배포를 진행했습니다. Docker hub를 이미지 레지스트리로 사용하여 배포 자동화를 쉽게 구축할 수 있다는 점으로 인해 사용했습니다.
프로젝트를 진행하며 빠른 수정과 반영을 위해 빌드 및 배포 자동화가 필요했습니다. Jenkins와 Github Actions라는 두 후보가 있었는데, 아래와 같은 이유로 Github Actions를 선택했습니다.
젠킨스는 아이템 별 스크립트의 진행 상황을 별도 대시보드에서 확인할 수 있다는 점이 좋았습니다. 하지만, 메모리 소모가 큰 편이라 구축 시 스프링 서버와 별도로 추가적인 서버를 위한 비용이 필요하다는 점과 초기 구축에 번거로움이 있다는 점으로 인해 보류하게 되었습니다. 더욱이 젠킨스의 큰 장점인 여러 플러그인을 통한 호환성과 복잡한 경우에서의 커스터마이징이 해당 프로젝트에는 필요성이 떨어졌습니다.
GitHub Actions는 깃허브를 사용하고 있고, 깃허브에서 바로 확인할 수 있다는 점이 좋았습니다. 프로젝트 경험이 적은 팀원과 협업 시에도 한 눈에 확인할 수 있었고, 설정이 간편해 프로젝트 초기부터 빠르게 적용할 수 있었습니다. 복잡한 상황에서의 커스터마이징이 필요하지 않았고, 추가적인 비용이 필요하지 않다는 점이 팀의 기술 선택에 가장 큰 이유입니다.
- 회원가입, 로그인, 이메일 인증
- 마이페이지 : 내 정보, 스크랩 한 게시글 목록
- 아바타 설정 : 몸통, 눈, 코, 입 설정
- 메인 화면 : 분야(기획, 디자인, 개발) 별 게시글 목록
- 게시글 상세 : 게시글 제목, 내용, 작성자 및 댓글 목록
- 게시글 작성 : 작성 중 게시글 내용, 임시 저장된 게시글