Skip to content

백엔드 기술 스택

HoYeon edited this page Jul 11, 2024 · 4 revisions

Spring Boot

용도

웹 애플리케이션 개발에 사용합니다.

선택 이유

쉬운 설정

Spring Initializer를 통해 빠른 설정이 가능하고, 대부분의 설정을 자동으로 처리해주어 개발자가 설정에 소모하는 시간을 줄일 수 있고, 빠르게 개발을 시작할 수 있습니다.

레퍼런스

공식 문서, Baeldung과 더불어 한글로 된 자료를 찾아보기 수월하기 때문에, 필요한 내용들을 빠르게 찾아볼 수 있다는 장점이 있습니다.

⭐️학습한 내용의 활용

우아한테크코스의 레벨 1에서는 자바와 객체지향, 레벨 2에서는 스프링을 이용한 웹 구현을 학습했습니다. 지금의 프로젝트에서 Spring Boot 이외의 다른 프레임워크도 사용이 가능하지만, 그동안 학습한 내용을 활용해 볼 수 있으며 새로운 기술을 배워야 하는 부담 없이 프로젝트를 빠르게 시작할 수 있습니다.

버전

스크린샷 2024-07-08 오후 3 36 45

본 프로젝트는 정해진 프로젝트 기간 이후에도 계속 유지하고자 하는 마음으로 기획하였습니다. 따라서 프로젝트 종료 기간과 겹치는 3.2.x 버전보다, 그 이후까지 지원되는 3.3.x 버전을 선택하였습니다. 참고

스크린샷 2024-07-08 오후 3 36 56

따라서, 현재 가능한 3.3.x 버전 중 GA(General Availability) 버전인 3.3.1을 사용합니다. 참고


Java

선택 이유

Spring Boot는 Kotlin 등의 다른 언어도 지원합니다. Kotlin이 주는 간결함과 같은 장점들이 존재하지만, 기존에 팀원들이 학습해온 Java를 선택했을 때 오는 새로운 언어를 학습하지 않아도 된다라는 장점이 더 크게 느껴졌기 때문에 Java를 선택하였습니다.

버전

스크린샷 2024-07-08 오후 4 02 03

전에 선택했던 Spring Boot 3.3.1 은 Java 17, 21, 22를 지원합니다. 이중 LTS가 아닌 22를 제외하고, Java 21에서 지원하는 Virtual Thread 와 같은 새로운 기술을 사용할 계획이 현재로서는 없기 때문에 기존에 사용했던 Java 17을 선택하였습니다.


API 문서화

Swagger

용도

API 문서화에 사용합니다.

고려한 기술

Spring Rest Docs

장점

  • API 문서가 테스트 기반으로 생성되기 때문에 작성된 문서를 신뢰할 수 있습니다.
  • 프로덕션 코드에 영향을 주지 않습니다.

단점

  • 처음 설정하고 사용하기 복잡하며, 익숙해지는 시간이 필요합니다.
  • Swagger에 비해 자동 생성 기능이 부족합니다.
  • 자체적인 UI를 지원하지 않습니다.

Swagger

장점

  • 어노테이션 만으로 API 문서를 자동으로 생성할 수 있습니다.
  • 자체 UI를 지원하며, API를 문서에서 직접 테스트할 수 있습니다.
  • Spring 기반인 Rest Docs에 비해 범용적입니다.

단점

  • 프로덕션 코드가 복잡해질 수 있습니다.
  • 프로젝트 규모가 커질수록, 설정과 관리가 복잡해질 수 있습니다.

선택 이유

Swagger는 프로젝트 규모가 커질수록 관리가 복잡하다는 문제가 있지만, 현재의 프로젝트 규모 하에서는 크게 문제가 없을거라 생각했습니다. 또한 Rest Docs를 익히는데 소요되는 시간, 프론트엔드 팀원들이 Swagger에 익숙하다는 점 역시 현 프로젝트에서 Swagger를 사용하는게 더 효율적이라고 판단했습니다.


데이터베이스

운영 서버: MySQL

용도

서비스 제공에 필요한 데이터를 저장할 때 사용합니다.

고려한 기술

Oracle 가장 유명한 RDBMS 중 Oracle 과 MySQL 두 가지를 고민했습니다. 모우다의 프로젝트 사이즈를 고민해봤을 때 비교적 가볍고 간단한 MySQL 이 적합하다고 생각했습니다.

선택 이유

  1. MySQL은 오픈 소스이므로 무료로 사용할 수 있으며 소스 코드는 대중에게 공개됩니다. 이 때문에 많은 문서가 있습니다.
  2. 조회 등의 단순한 작업에서 높은 성능을 보여줍니다.
  3. 팀원들의 러닝 커브를 고려하여 가장 익숙한 MySQL을 선택했습니다.

개발 서버: H2 Database

용도

서비스 제공에 필요한 데이터를 저장할 때 사용합니다.

고려한 기술

MySQL과 고민을 했습니다. 하지만 개발용 서버에서는 가벼운 데이터베이스를 가져가 빨리 테스트를 해보는 것이 더 중요하다고 생각했습니다.

선택 이유

  1. H2 Database는 용량이 가벼운 디스크 기반 인메모리 데이터베이스 입니다. 애플리케이션에 내장되어 있어 따로 설치할 필요없이 사용할 수 있습니다.
  2. 브라우저에서 접속이 가능한 콘솔이 제공되어 UI를 통해 쉽게 DB의 데이터를 확인할 수 있습니다.
  3. In-memory 모드에선 휘발성이라는 단점이 있지만 개발용 혹은 테스트용으로 사용하기 때문에 문제가 없습니다.

Spring Data JPA

용도

어플리케이션의 객체와 데이터베이스 사이의 연결을 위해 사용합니다.

선택 이유

JPA는 자바 진영의 ORM 기술 표준입니다. Spring Data JPA는 JPA를 더 쉽게 사용하기 위해 스프링에서 제공하고 있는 프레임워크 입니다.

  1. Spring Data JPA의 주요 이점 중 하나는 감소된 상용구 코드입니다. Repository 인터페이스를 상속 받아 기본적인 CRUD 코드를 제공합니다.
  2. Spring Data JPA는 메서드 이름에서 직접 쿼리를 작성하게 도와줍니다. 예를 들어 'findById'라는 메서드는 자동으로 where 절의 조건문을 포함한 조회 쿼리를 날려줍니다.

테스트

Junit Jupiter

용도

단위 테스트를 생성, 구성 및 실행할 때 사용합니다.

선택 이유

지속적인 업데이트와 대규모 지원 커뮤니티가 활발히 이루어지는 표준 단위 테스트 프레임워크입니다. JUnit은 간단하면서도 강력한 어노테이션 기반 구문을 통해 신속하게 테스트 방법을 정의하고, 테스트 컨텍스트를 설정 및 해제할 수 있습니다.


AssertJ

용도

Junit이 추천한 third-party 라이브러리로, 성능을 향상시키고 더 나은 가독성을 통해 JUnit의 단점을 보완할 수 있습니다.

선택이유

JUnit Jupiter가 제공해주는 assertion은 많은 테스트 시나리오에서 부족할 수 있습니다.

메서드 체인 형태로 코드를 자동 완성하여 검증 대상에 따라 지원되는 메소드들을 쉽게 파악할 수 있습니다.

자연어 문장 스타일의 에러 메시지를 제공해 가독성이 좋습니다.


RestAssured

용도

REST 웹 서비스를 검증하기 위한 라이브러리이며 대부분 End-to-End Test(전 구간 테스트)에 사용합니다.

선택 이유

  1. json data를 보다 쉽게 검증이 가능하며 json data를 다루는 많은 메소드를 제공합니다.
  2. BDD(Behavior Driven Development) 스타일로 작성되어 있어 가독성이 MockMvc에 비해 좋습니다.

CI / CD

Github Actions

용도

빌드 및 배포 자동화에 사용합니다.

고려한 기술

Jenkins

장점

  • 참고할 문서가 많습니다.
  • 외부 서비스에 의존하지 않습니다.
  • 커스텀이 쉬우며, 확장성이 좋습니다.
  • 파이프라인을 한 곳에서 관리할 수 있습니다.

단점

  • 별도의 서버를 두어 운영해야 하고, 러닝 커브가 높아 빠르게 적용하기에 어렵다는 단점이 있습니다.

Github Actions

장점

  • Github을 사용해 코드를 관리하고 있으므로 연동이 편리합니다.
  • 빌드 작업을 EC2에서 하지 않기 때문에 정해진 자원을 효율적으로 사용할 수 있습니다.

단점

  • Github Runner라는 Third-Party에 의존하고 있습니다.
  • 복잡한 아키텍처인 경우 UI 상으로 파악하기 어렵다는 단점이 있습니다.

선택 이유

필요하지 않은 시점에서 학습 곡선이 크고 복잡한 시스템에서 사용되는 Jenkins를 도입할 이유가 없어 보였습니다. 또한 서버 자원에 대한 제한이 있기 때문에 배포를 위한 별도의 서버를 유지하는 것은 무리라고 판단하였습니다. 가볍고 빠르게 적용이 가능한 Github Actions를 사용해 CI/CD 파이프라인을 구축합니다. 시스템이 고도화되고 Github Actions 만을 사용한 배포 파이프라인 유지가 힘들다고 판단될 때 Jenkins 등을 사용한 아키텍처 수정을 염두에 두고 있습니다.


Nginx

용도

HTTP 요청을 효율적으로 처리하기 위해 사용합니다.

고려한 기술

Nginx

장점

  • 이벤트 기반의 비동기 아키텍처를 사용하여 동시 연결을 효율적으로 메모리를 사용할 수 있습니다.

단점

  • 동적 모듈을 로드할 수 없습니다.

Apache HTTP Server (httpd)

장점

  • 동적으로 로드 가능한 여러 가지 공식 모듈을 제공합니다.

단점

  • 프로세스 기반 아키텍처이기 때문에 동시 연결을 처리하는 경우 메모리 사용량이 증가합니다.

선택 이유

사용자에게 성능 상 이점을 제공하기 위해 비동기 구조인 Nginx를 선택하였습니다. 사용 경험이 있기 때문에 학습 곡선 없이 바로 적용이 가능하다는 것도 이점입니다. HTTP 요청을 받아 정적 및 동적 컨텐츠를 제공하고, 캐시나 로드 밸런서의 역할을 수행할 예정입니다.


로깅

Log4j2

용도

오류가 발생했을 때 원인을 분석하는 등 모니터링을 위해 로그를 남기기 위해 사용합니다. 시스템의 상태나 동작 과정을 기록할 수 있습니다.

고려한 기술

Logback

장점

  • SLF4j 기반으로 만들어졌으며 설정이 간단하다는 장점이 있습니다.
  • 필터링이나 로그 레벨 설정에 대해 자동 리로딩 기능을 제공합니다.

단점

  • 동기 방식의 로깅 처리로 인해 시간 효율 상의 이점을 확보할 수 없다.

Log4j2

장점

  • 고급 로그 레벨 설정 기능을 제공합니다.
  • 람다 표현식을 사용해 로그 메시지를 지연 결합되기 때문에 성능이 좋습니다.
  • 별도의 스레드에서 비동기 로깅을 지원하기 때문에 성능이 좋습니다.

단점

  • 로깅 과정에서 문제가 발생했을 때 해당 에러를 핸들링하기에 어려움이 있습니다.

선택 이유

로깅 자체가 비즈니스 로직에 중요한 부분이지 않기 때문에 에러 핸들링은 큰 문제가 아니라고 판단했습니다. 비즈니스 로직 흐름에서 문제가 발생했을 때 로깅을 남기는 것이 중요한데, 이를 성능 상으로 영향을 주지 않기 위해 비동기 로거를 사용하는 것이 좋다고 판단하였습니다. 따라서 Logback 대신 Log4j2를 사용하는 것으로 채택하였습니다.


기타

Lombok

용도

반복적인 코드 작성을 줄이고 생산성과 가독성을 높이기 위해 사용합니다.

선택 이유

  1. Lombok은 Java 개발에서 반복적으로 작성해야 하는 getter, setter, toString, equals, hashCode 등의 메서드를 자동으로 생성해줍니다. 이를 통해 개발자는 이러한 반복 코드를 직접 작성할 필요가 없어집니다.
  2. Lombok을 사용하면 코드가 간결해지기 때문에 가독성이 높아집니다.