Live-Bidding이라는 이름으로 실시간 경매 플랫폼 토이 프로젝트를 시작했다. 본격적인 기능 개발에 앞서, 앞으로의 확장성과 안정적인 개발 경험을 위해 초기 환경을 구축하는 데 시간을 들였다. 이 글은 그 과정에서 했던 기술적 선택과 그 이유를 기록으로 남기기 위해 작성했다.
기술 스택 및 주요 의존성 선택
프로젝트의 방향을 결정하는 초기 기술 스택과 의존성은 신중하게 선택했다.
-
Java 21 & Spring Boot 3.x
Java 21을 선택한 가장 큰 이유는 가상 스레드(Virtual Threads) 때문이다. 실시간 경매 시스템에서는 다수의 동시 요청을 효율적으로 처리하는 것이 중요한데, 가상 스레드는 적은 리소스로 높은 처리량을 기대할 수 있게 해준다. 프로젝트의 확장성을 고려해 최신 LTS 버전을 선택하는 것이 합리적이라고 판단했다. 프레임워크는 Java 21과 호환성이 좋은 Spring Boot 3.x를 자연스럽게 선택했다. -
주요 의존성
- Spring Boot Starter Web: REST API 개발과 내장 Tomcat 서버를 제공하여 웹 애플리케이션의 기본을 구성한다.
- Spring Boot Starter Data JPA: DB 작업을 객체 지향적으로 처리하기 위해 선택했다. 내부적으로 JPA 구현체인 Hibernate와 DB 커넥션 풀 라이브러리인 HikariCP를 포함하고 있어 개발 생산성을 크게 높여준다.
- Spring Boot Starter Security: JWT 기반 인증/인가 구현을 위해 초기부터 도입했다. 보안은 나중에 추가하기보다 프로젝트 시작부터 고려해야 할 중요한 요소라고 생각했다.
- Lombok:
@Getter,@Builder등 어노테이션으로 반복적인 코드를 제거하여 코드 가독성과 유지보수성을 높이기 위해 사용했다.
-
Gradle
빌드 도구로는 Gradle을 선택했다. Groovy DSL이 Maven의 XML보다 간결하고, 캐싱을 통한 빌드 속도 또한 장점이라고 생각했다. -
데이터베이스 (MySQL)
관계형 데이터베이스로는 PostgreSQL과 MySQL을 두고 고민했다. PostgreSQL이 더 엄격한 표준을 따르고 기능적으로 풍부하다는 장점이 있지만, 최종적으로 MySQL을 선택했다. 가장 큰 이유는 웹 애플리케이션 생태계에서의 보편성이다. MySQL은 전 세계적으로 가장 널리 사용되는 RDBMS 중 하나로, 방대한 문서와 커뮤니티, 검증된 레퍼런스를 쉽게 찾아볼 수 있다. 기술적 특수성보다는 가장 일반적이고 대중적인 환경에서 발생하는 문제들을 해결하는 경험이 이번 프로젝트의 목표와 더 부합한다고 판단했다.
환경 분리
개발, 테스트, 운영 환경을 분리하기 위해 Spring Profile을 사용했다. dev 환경에서는 빠른 개발을 위해 ddl-auto: update를, test 환경에서는 독립적인 테스트를 위해 H2 인메모리 DB를 사용하도록 설정했다. prod 환경은 데이터 안정성을 위해 ddl-auto: validate로 설정하여 의도치 않은 DB 변경을 막고자 했다.
Docker를 이용한 DB 환경 구성
팀원 간, 혹은 다른 PC에서 작업할 때 발생할 수 있는 DB 환경 차이 문제를 해결하기 위해 MySQL을 Docker Compose로 관리하기로 했다. docker-compose.yml 파일을 통해 DB 버전과 설정을 코드로 관리하면, 누구나 docker-compose up 명령어로 동일한 DB 환경을 구성할 수 있다.
민감 정보 관리
DB 비밀번호 같은 민감 정보가 Git에 노출되는 것을 막기 위해 .env 파일을 사용했다. 설정 파일(.yml)에서는 ${...} 형태로 변수를 참조하고, 실제 값은 Git 추적에서 제외되는 .env 파일에 보관하는 방식이다.
CI (지속적 통합)
코드 변경 사항이 통합될 때마다 안정성을 검증하기 위해 GitHub Actions로 CI를 구축했다. develop 브랜치로 Pull Request를 보낼 때마다 자동으로 테스트와 빌드를 실행하도록 설정했다. 이를 통해 테스트를 통과한 코드만 develop 브랜치에 병합되도록 하여, 항상 안정적인 상태를 유지하는 것을 목표로 했다. main 브랜치용 CI도 분리해서 만들었는데, 이는 추후 배포 자동화(CD)를 추가할 것을 고려한 결정이다.
템플릿
마지막으로, 일관된 형식의 이슈와 Pull Request를 위해 템플릿을 추가했다. 정해진 양식은 협업 시 커뮤니케이션 비용을 줄여줄 것이라 생각한다.
이렇게 프로젝트의 초기 환경 설정이 마무리되었다. 각 기술을 왜 선택했는지 기록으로 남기는 과정에서 스스로도 더 명확하게 정리할 수 있었다. 이제 이 안정적인 기반 위에서 본격적인 기능 개발을 시작할 예정이다.
