백엔드‐기술 스택 선택 및 이유

Jump to bottom

ashsty edited this page Jul 26, 2024 · 10 revisions

2024.07.25 변경 사항

개발용 데이터 관리를 위한 h2 항목이 추가되었습니다.
배포 인프라 구축을 위한 AWS 항목이 추가되었습니다.
프론트엔드와 백엔드 상호 소통을 위한 Docker 항목이 추가되었습니다.

자바

선택지: 8, 11, 17, 21

record, 텍스트 블록 등의 기술이 지원되지 않는 17 미만의 버전을 사용할 이유가 없음
21 버전에서 등장한 virtual thread 등의 새로운 기술을 사용할 이유가 없음
SpringBoot 3.0 프레임워크가 Java 17 이상의 버전부터 호환 가능함
⭐️ 레벨 1, 레벨 2의 과정을 거치며 전원이 기존 러닝커브와 작업 환경을 갖추고 있음

→ 17 버전을 사용하기로 결정

빌드 툴

선택지: gradle, maven, …

maven 보다 빠른 속도
DSL 사용으로 인한 가독성 향상
⭐️ 레벨 1, 레벨 2의 과정을 거치며 전원이 기존 러닝커브와 작업 환경을 갖추고 있음

참고 자료 - Gradle 공식 사이트 (gradle vs maven)
참고 자료 - Gradle 공식 사이트 (gradle과 maven의 성능 비교)

스프링 및 스프링부트

선택지: 3.2.4, 3.3.0

⭐️ SpringBoot 프레임워크의 지원 기간 라이프 사이클이 짧음(12개월~3년)
- 지원이 종료된 프레임워크의 경우 아래와 같은 추가 비용이 발생
  - 보안 취약성
  - 호환성 문제
  - 업데이트(마이그레이션)
→ 추후 서비스 가능성을 위해서라도 최신 버전을 선택하기로 결정

참고 자료 - Spring 공식 사이트 (스프링부트 지원 기간)

DBMS (추후 변경)

선택지: h2, MySQL, PostgreSQL, MongoDB…

개발용 기본 데이터베이스로 h2를 사용함
- ⭐️ 빠르고 가벼운 In-Memory DB
- 설치와 활용이 간편하다
- 단위 테스트 및 초기 프로젝트 설정에 용이하다
- 하지만 낮은 안정성 때문에 실제 운영 서버의 DB 역할을 수행하기에는 부적합하다고 판단됨으로 이후 변경할 예정
참고 자료 - H2 공식 사이트(homepage)
이후 서비스용 DB 스택 별도 선택 예정

Lombok

⭐️ 작업 능률을 올릴 수 있음
- 게터, 생성자 등 작성 불필요
- 반복작업 최소화
백엔드 팀원들 중 기존 사용 경험이 있는 2명(조이썬, 뽀로로)이 위와 같은 장점을 피력, 남은 2명(무빈, 애쉬)도 새로운 스택을 사용해보고 싶다는 기조로 동의

참고 자료 - lombok 공식 사이트(feature)

SpringDataJpa

⭐️ 작업 능률을 올릴 수 있음
- 쿼리 작성 시간 절약
- JDBC 연결 등을 관리하는 데에 드는 비용 절약
- 편리한 transaction 처리 가능

→ 비즈니스 로직에 집중 가능

API 문서화

선택지: SpringDocs, RestDocs, Notion…

⭐️ swagger 문서 내에서 테스트 가능
- 프론트엔드 단에서 api 테스트 가능
  - 소통 과정 간소화
⭐️ Controller 단위 테스트를 작성하지 않아도 됨
- 불필요한 테스트 작성 시간 생략
테스트 문서 작성 시간 최소화
- Notion과 같은 경우 개발자 수동 업데이트 필요
- ⭐️ RestDocs의 경우 백엔드 전원 관련 경험이 없어 swagger에 비해 투자 시간이 늘어남

JUnit 5

⭐️ 편리한 가독성
전원 기존 사용 경험이 존재하여 추가 투자 시간 없이 도입 가능

RestAssured

⭐️ 실제 요청을 기반으로 한 사용자 스토리 검증
전원 기존 사용 경험이 존재하여 추가 투자 시간 없이 도입 가능

Sonarlint

⭐️ 정적 코드 분석을 통한 최소한의 코드 퀄리티 보장
- 다인 프로젝트의 코드 품질 향상 & 균일화
- 컨벤션에 맞지 않는 코드 수정 제안 기능 지원
- 변경 사항 commit 전 전체 코드 자동 검사 기능 지원
팀원(조이썬)의 기존 사용 경험이 긍정적이고, 경험이 없는 기타 팀원들도 새로운 스택을 사용해보고 싶다는 기조로 동의

참고 자료 - sonarlint 공식 사이트 (homepage)

AWS

선택지: EC2, S3, CloudFront, ElastiCache, ES/OpenSearch, Lambda, SNS, SQS, SES, ACM, CloudWatch, CodeBuild, CodeDeploy, CodePipeline, RDS

EC2: 배포 서버로 사용
S3: 리소스 및 빌드 파일 업로드용으로 사용
CodeBuild, CodeDeploy, CodePipeline: 백엔드 지속적 배포(CD) 자동화를 위해 사용
- ⭐️ Github Action 등의 기타 플랫폼을 경유하지 않고 AWS의 기능만으로 코드 push 시 자동 빌드와 배포를 가능하게 함
  - self-hosted runner의 경우 pulling을 통해 깃허브 코드 변화를 감지하기 때문에 추가 서버 리소스가 발생함
- CodePipeline: 블루/그린 배포와 같은 무중단 배포 기능을 AWS의 기능만으로 설정할 수 있음
참고 자료 - AWS 공식 문서(ECS & Code Deploy Blue/Green)

Docker

⭐️ 백엔드, 프론트엔드의 서로 다른 개발 환경을 하나로 통합하여 관리하기 위함
일종의 개발 서버 역할을 기대
전원 기존 사용 경험이 존재하여 추가 투자 시간 없이 도입 가능