test - Team-Wordi/Wordi GitHub Wiki

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

---

버전관리 시스템

• Git
• SVN
• Mercurial

Git 웹 호스팅 서비스

• GitHub
• GitLab
• BitBucket

이슈 관리 도구(이슈 트래커)

• Asana
• Jira
• Trello
• GitHub Issues & Projects

Git GUI

• GitHub Desktop
• SourceTree
• GitKraken

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

---

컴퓨팅 파워 출처

• PC
• 서버용 하드웨어를 구입해 홈서버 운영
• 서버호스팅
• 클라우드 플랫폼

클라우드 플랫폼

• AWS(Amazon Web Service)
• GCP(Google Cloud Platform)
• Microsoft Azure

컴퓨팅 엔진(AWS 기준)

• EC2(Elastic Compute Cloud)
• Beanstalk
• ECS(Elastic Container Service)
• ECS+Fargate
• Lightsail
• Lambda

배포 자동화 서비스

• Travis-CI
• CircleCI
• Amazon CodeBuild와 CodeDeploy를 함께 사용
• Amazon CodeBuild만 사용

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

---

API 설계 원칙

• HTTP API
• REST API
• GraphQL

API 문서화 방식

• Excel
• Swagger
• 소스코드에 문서 임베딩
• ReDoc을 직접 관리
• ReDoc을 GitHub Pages(github.io)에서 관리
• Slate를 직접 관리
• Slate를 GitHub Pages(github.io)에서 관리
• GitBook

직렬화 포맷

• XML
• JSON
• YAML
• Protocol Buffer(Protobuf)

JSON key 네이밍 룰

• 신경쓰지 않는다. ex) 'signindate'
• 공백으로 분리한다. ex) 'signin date'
• 카멜 케이스(Camel Case)를 사용한다. ex) 'signinDate'
• 파스칼 케이스(Pascal Case)를 사용한다. ex) 'SigninDate'
• 스네이크 케이스(Snake Case)를 사용한다. ex) 'signin_date'

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

---

인증 정보의 위치

• request body
• 요청의 query parameter
• Cookie 헤더
• Authorization 헤더

인증 스키마

• Basic
• [비표준] OAuth 1.0a를 사용하는 Bearer
• OAuth 2.0을 사용하는 Bearer
• [비표준] JWT, 또는 JWT를 사용하는 Bearer
• Digest
• HOBA

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

---

데이터베이스

• RDB
• NoSQL

DB 호스팅 위치

• EC2
• RDS(Relational Database Service)

데이터베이스 엔진

• Aurora
• MySQL
• MariaDB
• PostgreSQL
• Oracle
• SQL Server

MySQL Driver(클라이언트)

• HeidlSQL
• MySQL Workbench
• DataGrip

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

---

프로그래밍 언어

• Python
• Scala
• Java
• Go
• Node.js

프레임워크

• Spring Boot
• Spirng Web
• Spring Security
• Spring Data
• Spring Batch
• Spring Cloud

DB 접근 기술

• JDBC
• JdbcTemplate
• Mybatis
• JPA
• 스프링 데이터 JPA
• QueryDSL

의존성 관리 도구

• .pip
• npm
• yarn
• gem
• maven
• gradle

라이브러리

• Lombok
• Springfox Boot Starter
• Bean Validation
• Thymeleaf

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

---

시각 데이터 저장 방식

• Unix time
• Asia/Seoul 기준의 시각 문자열
• UTC 기준의 시각 문자열
• ISO 8601 format 문자열

시각 데이터 표현 방식

• YYYY-MM-DD HH:mm:ss.SSS
• Unix time
• YY-MM-DD HH:mm:ss.SSS
• ISO 8601 format(YYYY-MM-DDTHH:mm:ss.SSS±hh:mm)
• RFC 3339 format

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