JAVA 버전 (JDK 벤더)은 17 LTS 버전을 사용한다.

• 이전 버전과의 비교에서 17 버전의 특징 중 텍스트 블록과 Record의 등장을 이유로 서비스 구현이 훨씬 용이할 것이라 판단하였다.
• 다만 최근 LTS로 등장한 21 버전과의 선택에서 면밀히 검토하였다.
  • 결론적으로 17을 사용하기로 하였는데 이유는 다음과 같다.
    • 프로젝트 팀원 모두 21의 특징과 장단점에 대한 사전 지식이 없어 100% 사용하려면 학습하는데 리소스가 소모될 것이라 판단했다.
    • 또한 초기 구현 단계에서 21의 특징 (virtual Thread, switch문 개선) 등 장점을 적용할 구간이 비교적 적다고 판단했다.

Gradle 선택 이유( vs Maven)

• XML이 아닌 Groovy 를 기반으로 동작하여 훨씬 코드가 간결하고 작성하기 쉽다.
• Gradle은 어떤 task가 업데이트되었는지를 체크하기 때문에 증분 빌드가 가능하다.
  • Maven은 증분 빌드가 불가능하여 프로젝트 규모가 커질수록 Gradle과 빌드 시간 차이가 증가한다.
  • Gradle 공식 사이트 기준 일반적인 라이브러리 프로젝트로 테스트했을 때 테스트 실행 속도 1.7배, 빌드 캐시 사용 시 최대 30배 더 빠르다.

Swagger 선택 이유 ( vs RestDocs)

• Swagger와 RestDocs의 장단점은 아래와 같다.

  	Swagger	RestDocs
  장점	어노테이션 기반으로, 문서화 과정이 간편하다.	테스트 코드가 통과해야만 문서화가 된다.
  때문에 API의 안전성을 보장할 수 있다.
  	만들어진 문서를 통해 실제로 API를 실행시킬 수 있다.	프로덕션 코드에 문서화를 위한 코드를 작성할 필요가 없다.
  단점	테스트 코드의 성공 여부 상관없이 문서가 작성되어, API의 안전성을 보장할 수 없다. (→ API 문서를 통해서 우리가 잘못된 API를 확인해야 하는 것이 아니지 않을까?)	문서화 과정이 번거롭다.
  	프로덕션 코드에 문서화를 위한 코드를 작성해야 한다. 프로덕션 코드가 복잡해 보일 수 있다.	실제 API를 작동시켜서 확인해 볼 수 없다.

• 아래와 같은 이유로 swagger를 선택했다.

  • 문서화의 목적은 API문서가 팀원 모두에게 쉽게 읽히도록 하는 것이다. 팀 모모의 프론트엔드는 swagger가 익숙하기 때문에 이에 맞춰서 swagger를 사용한다.
  • 개발 초기 단계인 만큼, 문서화보다는 빠른 기능 개발이 목적이다. 때문에 초기 세팅이나 문서를 작성하는데 오랜 시간이 걸리는 RestDocs 대신 간편하고 빠른 방식인 Swagger로 문서화를 진행한다.
  • Swagger는 직접 API를 실행할 수 있다. 이를 통해, API문서도 테스트해볼 수 있는 실용적인 문서를 제공할 수 있다.

• 단점 보완

  • Swagger는 테스트 성공 여부와 관련 없이 문서화가 이루어지기 때문에, 제대로 작동하지 않은 API또한 문서화가 될 수 있다. 이에 대한 대안책으로 API문서화를 진행하는 컨트롤러는 테스트 코드를 완벽히 작성하는 것으로 한다.
  • 프로덕션 코드에 문서화를 위한 코드를 작성하다 보면, 프로덕션 코드가 복잡해 보일 수 있다. 이를 해결하기 위해 어노테이션을 커스텀 하거나 인터페이스를 추상화하여 좀 더 단순하게 코드를 작성할 수 있다.

DBMS는 MySQL을 사용한다.

• RDBMS를 선택하는 이유

  • momo 서비스의 도메인 특성 상, 데이터(공유 링크, 사용자, 날짜 및 시간)의 관계를 맺고 테이블 형식으로 저장해서 관리할 필요가 있다고 판단하였다.
  • MVP 모델 특성상 데이터 구조가 변경될 가능성이 적고, 대규모 데이터 처리 및 빠른 응답 속도가 장점인 NoSQL을 사용했을 때 얻을 수 있는 장점은 거의 없을 것으로 예상하였다.
  • 다만, 추후 기능을 확장 했을 때 발생할 수 있는 성능적인 이슈, 비정형 데이터를 관리할 상황이 발생한 경우 추가로 NoSQL을 활용할 수 있을 것이라 예상한다.

• MySQL을 선택하는 이유

  • RDBMS는 MySQL을 선택하였는데 비교군으로는 Oracle DB, PostgreSQL, MariaDB가 있다.
  • vs Oracle DB
    • 유료
    • 팀의 기술적 경험상 부적절.
    • 현재 시점으로 높은 러닝커브 요구.
  • vs PostgreSQL
    • 팀의 기술적 경험상 부적절.
    • 현재 시점으로 높은 러닝커브 요구.
    • 멀티 프로세스 기반 작동 방식으로 MySQL에 비해 오버헤드가 크지만, 복잡하거나 대규모 쿼리를 처리하는데 특화되어있다. 그래서 복잡한 트랜잭션을 처리하고 정확한 데이터 무결성이 필요한 환경에서 주로 사용된다.
    • momo 서비스 특성을 고려하고 소, 중규모 프로젝트인 것을 감안했을 때 PostgreSQL은 부적합할 것으로 판단된다.
  • vs MariaDB
    • MySQL 기반 오픈소스 DB.
    • MySQL의 여러가지 성능을 개선했지만, MySQL에 비해 부족한 커뮤니티 활성화.
    • 그래서 버그가 발생했을 때 참고할 수 있는 자료들이 비교적 적은 것이 가장 큰 우려사항.
    • 팀원들 대부분이 MySQL을 계속 경험해 왔으며, MySQL과 MariaDB가 SQL 문법이 동일하다고는 하지만 사용해보지 않은 기술을 프로젝트에 바로 적용하는 것은 위험하다고 판단하였다.
  • 8.x 대 버전 사용 (2024-04-30 LTS 8.4)
    • 이전의 메이저 버전인 5.7이 2023년 10월부터 커뮤니티에서 지원이 종료되었다.
    • 8.0 버전부터 상당히 많은 기능들이 개선되거나 추가되었다.
      • 메타데이터 및 시스템 테이블이 InnoDB 엔진에 저장되도록 개선
      • 언두 로그 공간 사용 효율성 개선
      • 인덱스 스킵 스캔 기능 추가
      • 히스토그램 지원
      • JSON 데이터 타입 지원 강화
      • 윈도우 함수 지원
      • 이하 생략
    • 8.4 버전이 8.x 의 LTS로 확정됨

SpringBoot 버전은 3.3.x 버전을 사용한다.

• LTS 최신 버전이다.
• 이전 버전은 spring initializer가 지원하지 않음