🔨 Skill Spec [BE]

💡 전체적으로 가장 익숙한 툴을 우선적으로하여 활용 기술을 선정하였습니다.

⚙ 버전관리

버전관리 시스템
- Git


Git 웹 호스팅 서비스
- GitHub


이슈 관리 도구(이슈 트래커)
- GitHub Issues & Projects

버전관리 선정 이유

• Git: Git은 버전을 스냅샷으로 관리하여 성능 이슈가 적고, 브랜치를 도입할 수 있다. 또한 다른 버전관리 시스템에 비해 가장 익숙하다는 점에서 Git을 선택하게 되었다.
• GitHub: GitHub는 가장 대중적인 웹 호스팅 서비스로 현재 내게 가장 익숙한 서비스이다. 또한, GitHub 자체적으로 내장되어 있는 이슈 트래커를 포함한 풍부한 서비스를 활용할 수 있다고 판단했다.
• GitHub Issues & Projects: GitHub 자체 내에서 활용할 수 있다는 점이 가장 크다. 각 이슈에 대해 작업자를 assign 할 수 있으며, 커뮤니케이션과 라벨 활용, 이슈 상태 등을 구분하는 등 충분한 기능을 할용할 수 있다고 판단했다.

⚙ ComputeEngine 결정 & 서버 배포 및 배포 자동화

컴퓨팅 파워 출처
- 클라우드 플랫폼

클라우드 플랫폼
- AWS(Amazon Web Service)

컴퓨팅 엔진(AWS 기준)
- EC2(Elastic Compute Cloud)

컴퓨팅 엔진 결정 & 서버 배포 선정 이유

• 클라우드 플랫폼: 현재 서비스를 만드는 단계에서 가장 유동적으로 서버 환경을 설정할 수 있으며, 비용 또한 상황에 맞게 선택하여 서버를 구축할 수 있다는 점에서 클라우드 플랫폼을 선택하였다.
• AWS: 대중적이며 평소에 가장 자주 사용하고 익숙한 AWS 플랫폼을 활용하였다.
• EC2: 현재 가장 익숙한 컴퓨팅 엔진이다. 처음 데모 버전 서버를 구축하고 테스트 한다는 점에서는 충분하다고 판단하였다.

⚙ API 설계 원칙, 문서화 방식, 직렬화 포맷

API 설계 원칙
- HTTP API

API 문서화 방식
- Excel
- Postman

직렬화 포맷
- JSON

JSON key 네이밍 룰
- 카멜 케이스(Camel Case)를 사용한다. `ex) 'signinDate'`

API 설계 원칙, 문서화 방식, 직렬화 포맷 선정 이유

• HTTP API: 여기서 의미하는 HTTP API는 대중적으로 사용되는 REST API의 의미이다. 실제 REST API를 구현하기 위해서는 HATEOAS 원칙을 지켜야하기 때문에 HTTP API로도 충분하다고 판단되었다.
• Excel, Postman: 가장 익숙한 툴인 Excel을 선택하였다. 상시 업데이트를 위해 Google Sheets를 활용할 예정이다. 작업 시에는 Excel을 활용할 예정이며, 프론트와 공유 시에는 Postman 문서화를 통해 공유할 예정이다.
• JSON: 가장 익숙한 포맷이며, 타 직렬화 포맷에 비해 경량화되고, 가독성도 좋다. 결정적으로 협엽하는 프론트엔드 분도 JSON 포맷에 익숙한 점에서 선택하게 되었다.
• 카멜 케이스: Java 네이밍 컨벤션에 가장 적합하여 타 네이밍에 비해 사용하기 편리하며, 프론트 개발자와 상의 하에 결정하였다.

⚙ 사용자 인증 방식

인증 정보의 위치
- Authorization 헤더

인증 스키마
- [비표준] JWT, 또는 JWT를 사용하는 Bearer

사용자 인증 방식 선정 이유

• Authorization 헤더: 인증 데이터는 메타 데이터 성격이 강해 request body와 어울리지 않으며, 쿼리 파라미터의 경우 보안상 좋지 않다. 또한, 쿠키는 앱 개발 부분에서는 클라이언트가 쿠키 저장소를 따로 구현해야하기 때문에 Authorization 헤더가 가장 적합하다고 판단했다.
• JWT: 가장 익숙한 방법이며, 쉽게 전달될 수 있다. 서비스 내에서 로그인 유지 정보에 대한 필요성이 없으며, 세션에 대한 관리 부분과 서버 자원을 절약할 수 있다는 점에서 선택하였다.

⚙ 데이터베이스 선정

데이터베이스
- RDB

DB 호스팅 위치
- RDS(Relational Database Service)

데이터베이스 엔진
- MySQL

MySQL Driver(클라이언트)
- DataGrip

데이터베이스 선정 이유

• RDB: 가장 익숙한 RDB를 택하였다. 구현하려는 서비스 특성상 트래픽이 집중되는 서비스 보다는 안정적인 서비스로 가는 것이 좋을 것이라고 판단하여 RDB가 더 적합하다고 판단했다.
• RDS: EC2에 호스팅할 경우, 서버 문제가 DB까지 영향을 미칠 수 있으며, 무료로 제공되는 EC2의 성능을 고려했을 때 분리하는 것이 좋다고 판단되었다. 따라서, DB를 서버와 분리한 RDS를 활용하는게 적합하다고 판단했다.
• MySQL: 가장 많이 사용했으며, 익숙한 데이터베이스 엔진이기에 선택하였다.
• DataGrip: 데이터 추출과 저장이 간편하며, 쿼리 및 데이터 임시 저장 기능, 자동 완성 기능 등 편리한 기능을 많이 갖추고 있다.

⚙ 기술 스택 정의 & 의존성 관리도구

프로그래밍 언어
- Java11

프레임워크
- Spring Boot
- Spirng Web
- Spring Data

DB 접근 기술
- JPA
- 스프링 데이터 JPA
- QueryDSL

의존성 관리 도구
- gradle

라이브러리
- Lombok
- Bean Validation

기술 스택 정의 & 의존성 관리도구 선정 이유

• Java11: 가장 익숙한 언어이다. Java는 8버전 이후로 람다 표현식, 스트림 API, java.time 패키지 등 유용한 기능들이 많이 추가되었다. 11버전은 8버전과 함께 현재 많은 프로젝트에서 사용중인 버전으로 다른 모듈과의 호환성이 좋다. 11버전은 8버전에 비해 몇 가지 유용한 기능이 추가되었다. 특히, String 처리와 관련된 메서드가 추가되었으며, 9버전부터 HTTP2버전과 호환성을 제공한다.
• Spring Boot: 기본 Spring에 비해 라이브러리 관리, 설정의 자동화, 라이브러리 버전관리 자동화, 테스트 환경과 내장 Tomcat 등 환경 설정 부분에서 편리한 부분이 많기 때문에 선택하게 되었다.
• JPA: RDB에 사용하기 적합하며, 데이터를 객체와 매핑하여 다룰 수 있다는 점에서 효율적으로 관리할 수 있다고 생각함. 구현할 서비스가 통계 처리와 같은 복잡한 로직이 필요한 서비스가 아니기 때문에 JPA 내에서 충분히 구현이 가능할 수 있다고 생각하여, 생산성과 유지보수 등을 살리고자 했다.
• QueryDSL: JPA만으로는 다루기 힘든 동적 쿼리를 함께 다루고자 사용할 예정이다.
• gradle: Java에 맞는 의존성 관리 도구이며, maven에 비해 관리가 쉽고, 가독성이 좋다고 판단. 결정적으로 가장 익숙한 의존성 관리 도구이다.
• Lombok: 보다 편리한 어노테이션 관리를 하기 위함.
• Bean Validation: 검증 처리를 가장 생산성 있게, 효율적으로 할 수 있다고 판단. 검증부를 DTO에서 처리하기 때문에 검증 로직을 제외한 클린코드를 만들 수 있다고 생각된다.

⚙ 어플리케이션 레벨 의사결정

시각 데이터 저장 방식
- UTC 기준의 시각 문자열

시각 데이터 표현 방식
- YYYY-MM-DD HH:mm:ss.SSS

시각 데이터 선정 이유

• 시각 데이터 저장: UTC가 국제 표준시로서 기준점이 되기도 하며, 시각을 다루는 지역이 기준이 된다는 점에서 local timezone에 의존하며 생길 수 있는 실수를 방어하기에 좋다. 또한 데이터 저장의 경우에는 일반적인 시간 데이터에 UTC를 기준으로 한 차이값 데이터가 더해진 ISO 8601 표준을 사용하기에는 과한 부분이 있다고 판단했다.
• 시각 데이터 표현: 클라이언트와 상의 후, 저장된 UTC를 형태 그대로 활용할 수 있는 YYYY-MM-DD-HH:mm:ss.SSS 표현 방식을 선택했다.