불확실성에 대한 두려움.
내 아이디어를 구체화하여 앱을 출시할 예정이다.
아직은 개발 환경을 구축하는 중이지만 이를 실행에 옮기기 까지 많은 고민들이 있었다.
내 앱의 이름(상표)이 법적 문제가 되진 않을지
이해관계에 해당하는 회사들과의 법적 문제
개발 환경 버전 문제
기능 개발하기도 바쁜데 1번 2번에 해당하는 법적 문제까지 고려하다보니 여간 힘든 게 아니다.
각 회사의 대표님들이 새삼 대단해 보였다.
나는 백엔드 개발자로서 운영에 가장 최적인 버전을 선택해야하고, 그 이유가 명확해야한다.
신규 프로젝트인데 자바 7,8 같은 너무 레거시는 사용하고 싶지 않았다. 최신 트렌드를 따라가야하는 직업 특성상 레거시를 사용하면 편하겠지만 도태될 것이다. 현재 자바 최신 버전은 17 LTS, 21 LTS, 24 이렇게 존재한다.
"24가 제일 최신이니 이게 가장 좋은 거 아니겠어?" -> 아니다.
24버전은 가장 최신이긴 하지만 non-LTS 버전으로 25년 9월에 지원이 종료되고 25버전이 나온다. 이는 운영 중 보안 업데이트 등 더이상 지원해주지 않는다는 치명적인 리스크가 있다. 따라서, 24는 후보에서 제외했다. 릴리즈 노트에 GC, 메모리 성능 향상 등에 대한 내용이 있어 구미가 당겼지만 25 버전을 기다려본다.
그 외 17, 21은 어떨지 조사해봤다.
둘 다 LTS 를 지원한다.
17 버전은 다양한 프로젝트에서 여전히 많이 쓰이지만, 신규 프로젝트엔 다소 뒤처진다.
17 버전은 보수적 채택에 최적이지만 21 대비 언어/런타임 이점은 적다고 판단했다.
나는 아래와 같은 기준으로 버전을 선택했다.
안정성
성능
지원 기간
Java 17 - 안정적이지만 구식(일반 지원 24년 9월 종료, 연장지원 29년 9월)
Java 21 - 신규 프로젝트에 적합한 균형잡힌 LTS 버전 (2031년까지 지원)
Java 24 - 신기능 많지만 불안정 및 짧은 지원기간(25년 9월 종료)
나는 안정성을 충족되면 성능을 보기 때문에 21 버전으로 선택했다.
버전을 선택했으니 끝이 아니다. 21 버전을 제공하는 다양한 벤더들이 있다.
Eclipse Temurin(adoptium) - 업계 기본 오픈 JDK 배포
Amazon Corretto - AWS 공식 배포, EC2에 최적
Oracle JDK - 성능 좋지만 26년 이후 유료 전환 리스크 존재.
등 다양한 벤더들이 있는데 어떤 기준으로 선택해야 할지 고민 했을 때, 내 앱은 AWS EC2 에 배포할 예정이기 때문에 호환성이 좋은 Amazon Corretto 를 선택했다.
그럼 이제 끝인가? 아니다. 이제 Spring Boot 버전을 선택해야한다.
현재 기준으로 주요 버전은
3.5.5 (현재 안정 버전)
4.0.0 (최신 메이저 버전)
또 다시 고민의 시간이다. Java 21을 선택한 만큼 이를 최대한 활용할 수 있는 Spring Boot 버전을 고려해야 했다.
Spring Boot 3.x vs 4.x 비교분석
Spring Boot 4.0.0은 매력적이었다. Java 21의 Virtual Thread, Pattern Matching 등 최신 기능을 완전히 지원하고, 성능상 이점도 상당하다. 하지만 출시된 지 얼마 되지 않아 production 환경에서의 검증이 부족하다는 우려가 있었다.
반면 Spring Boot 3.5.5는 충분히 검증된 안정성을 가지고 있고, Java 21과의 호환성도 보장된다. 다만 4.x 대비 최신 기능 활용도는 떨어진다.
결정 과정
서비스 안정성 우선: 신규 서비스는 사용자 유입이 중요한데, 예상치 못한 버그로 인한 서비스 중단은 치명적
팀 학습 곡선: 혼자 개발하는 상황에서 새로운 기능 학습보다는 빠른 개발이 우선
마이그레이션 계획: 추후 4.x가 안정화되면 단계적 업그레이드 예정
따라서 Spring Boot 3.5.5를 선택했다.
개발환경 구축에서 놓칠 수 없는 게 데이터베이스 선택이다.
MySQL 과 PostgreSQL 사이에서 고민했는데, 내 앱의 특성상 복잡한 JSON과 집계 쿼리 등 분석 기능이 많을 것으로 예상되어 JSON 친화적인 PostgreSQL을 선택했다.
그런데 여기서 또 다른 고민이 생겼다.
PostgreSQL 15 vs PostgreSQL 17
PostgreSQL 17은 2024년 9월 26일에 GA 릴리즈되었고, 성능상 상당한 개선이 있었다. 특히 I/O 레이어 성능 향상으로 고동시성 워크로드에서 최대 2배 더 나은 쓰기 처리량을 보여준다. 또한 새로운 스트리밍 I/O 인터페이스로 순차 스캔 속도가 향상되었고, JSON_TABLE 함수 추가로 JSON 데이터 처리 능력도 크게 개선되었다.
하지만 신규 서비스에 최신 버전을 사용하는 것은 리스크가 따른다. 운영 환경에서의 안정성이 확보되었는지 신중히 판단해야 했다.
PostgreSQL 17 안정성 검증 결과
AWS RDS와 Google Cloud SQL 등 주요 클라우드 제공업체들이 이미 공식 지원
현재 17.5까지 정기적인 보안 패치 릴리즈 중 (2025년 5월 기준)
커뮤니티의 엄격한 코드 리뷰 과정을 거쳐 안정성 확보
검토 결과, PostgreSQL 17이 이미 프로덕션 환경에서 충분히 검증되었다고 판단하여 PostgreSQL 17을 최종 선택했다. PostgreSQL의 강력한 JSON 지원, 윈도우 함수, Full-text search 기능과 더불어 17 버전의 성능 향상까지 얻을 수 있어 일석이조였다.
이번 개발환경 구축 과정에서 깨달은 몇 가지 원칙들이 있다.
1. 최신 != 최적
기술 트렌드를 따라가는 것은 중요하지만, 서비스의 안정성과 팀의 역량을 고려한 현실적 선택이 더 중요하다.
2. 의사결정에는 명확한 근거가 있어야 한다
"왠지 좋을 것 같아서"가 아닌, 비즈니스 요구사항과 기술적 제약사항을 종합한 논리적 판단이 필요하다.
3. 완벽한 선택은 없다
모든 기술 스택에는 trade-off가 있다. 중요한 것은 현재 상황에서 가장 적절한 균형점을 찾는 것이다.
4. 마이그레이션 가능성을 항상 염두에 둬야 한다
기술은 계속 발전한다. 현재 선택이 향후 기술 전환의 발목을 잡지 않도록 설계해야 한다.
한 달 간의 개발환경 구축 과정을 통해 단순히 코드를 작성하는 개발자에서 서비스를 책임지는 개발자로 한 걸음 성장했다고 생각한다.
앞으로 실제 개발 과정에서 이런 선택들이 얼마나 적절했는지 검증받게 될 것이다. 하지만 지금 이 순간, 충분히 고민하고 내린 결정이기에 후회는 없다.
기술 선택은 정답이 없는 영역이다. 하지만 그렇기에 더욱 신중해야 하고, 그 과정에서 개발자로서 성장할 수 있는 것 같다.
"좋은 개발자는 코드를 잘 짜는 사람이 아니라, 올바른 기술적 결정을 내릴 수 있는 사람이다."