-
Notifications
You must be signed in to change notification settings - Fork 15
기술 문서
이름: JAVA
버전: 17
백엔드 어플리케이션 개발 언어
개발 언어로 Java 11과 Java 17을 고려하였습니다.
장점
- 오랜 기간 사용되어 왔기 때문에 안정성이 보장되어 있다.
- 참고할 수 있는 문서가 많다.
단점
- 지원 기간이 얼마 남지 않았다.
- 스프링부트 3을 사용할 수 없다.
장점
- GC의 성능이 개선되었다.
- toList(), Record등의 사용이 가능하다.
- 지원 기간이 길다.
- 스프링부트 3을 사용할 수 있다.
Java 17과 11은 사용 방식에 큰 차이가 없기 때문에 참고할 수 있는 문서가 많다는 11의 장점은 메리트가 적다고 판단하였습니다. 따라서, 미세하지만 성능이 개선되었고 toList(), Record 등을 더 간편하게 사용할 수 있는 Java 17을 선택하였습니다. 더불어 지원 기간이 길고 스프링 부트 3을 사용할 수 있다는 점 또한 프로젝트를 시작하는 단계인 저희에게 가능성을 넓혀 줄 수 있는 선택이라고 생각하였습니다.
이름: Springboot
버전: 3.1.1.
백엔드 웹 프레임워크
스프링부트는 내장 서버를 제공하고, 별도의 설정 없이도 빠르게 개발이 가능합니다. 또한 오픈소스인 덕에 많은 사용자와 다양한 참고 문서들이 존재하기 때문에 저희 팀이 사용할 프레임워크로 적합하다고 판단하였습니다. 다만 어떤 버전의 스프링부트를 사용할 것 인지가 논점이었는데, 저희 팀은 자바17을 사용 가능한 2.7과 3.1 사이에서 고민하였습니다.
장점
- 오랜 기간 사용되어 왔기 때문에 안전성이 검증되고, 참고할 수 있는 문서가 많다.
- 기존에 개발되어있던 라이브러리들과 호환성이 보장된다.
장점
- AOT 엔진(최적화 도구)를 제공한다. 즉, 메모리 사용을 줄일 수 있다.
단점
- 비교적 최근에 출시되었기 때문에 상대적으로 문서가 적다.
2에 비해 3의 문서가 적긴 하지만, 3도 많이 사용되는 추세이기 때문에 저희가 개발하는 과정에서 큰 문제가 발생할 정도는 아닐 것이라고 예상하였고 이 과정에서 트러블 슈팅을 경험하는 것 또한 공부가 되기 때문에 3의 단점은 크지 않다고 결론내렸습니다. 결론적으로, 저희는 2.7과 3.1 모두 저희가 요구하는 서비스의 구현에 문제가 없을 것이라고 판단하였기 때문에, 최근에 출시된 버전인 3.1을 사용하는 것으로 결정하였습니다.
이름: MySQL
버전: 8.0.33
서비스 제공에 필요한 데이터를 저장하는 용도입니다.
저희가 사용하는 데이터들은 정형화된 구조이며, 스키마가 고정되어 있기 때문에 RDBMS가 적합합니다. 따라서 RDBMS 중에서 보편적으로 사용되는 MySQL을 선택하였습니다.
MySQL은 오픈소스라는 특성 상 무료이고, 참고할 수 있는 커뮤니티가 활성화 되어 있습니다. 또한 조회 등의 단순한 작업에서 높은 성능을 보여줍니다. 이에 더해, 설치와 관리가 쉬우며 저희 개발 인원들에게 가장 친숙한 DBMS라는 점 또한 MySQL을 선택하는 데에 주요한 이유가 되었습니다.
이름: JPA
버전: -
어플리케이션의 객체와 데이터베이스 사이의 연결을 위해 사용합니다.
장점
- JPA에 비해 성능적으로 우세하다.
- 익숙하다.
단점
- 쿼리를 직접 작성해야한다.
장점
- 작성해야 하는 쿼리의 양이 크게 줄어든다.
- 기본적인 CRUD를 직접 만들 필요가 없다.
- SQL상의 구조를 어노테이션을 사용해 관리하므로, SQL 의존성이 줄어든다.
단점
- JdbcTemplate보다 성능이 떨어질 수 있다. 특히, 복잡한 조건의 쿼리일수록 크게 나타난다.
- 비즈니스 로직이 복잡해질 수 있다.
- 사용법에 익숙하지 않다.
기록 서비스라는 프로젝트의 특성 상 다양한 CRUD 작업이 필요하기 때문에, 해당 부분의 구현과 유지보수에 대한 부담을 크게 덜어줄 수 있는 JPA를 사용하기로 하였습니다.
이름: Spring REST Docs
버전: -
개발 및 배포 완료된 API의 명세를 프론트엔드측과 빠르고 정확하게 공유하기 위해, 자동 문서화 라이브러리인 RestDocs를 사용하였습니다.
장점
- 문서상에서 API를 테스트 할 수 있다.
- 테스트 코드 없이 적용이 가능해서 간편하다.
단점
- 프로덕션 코드에 swagger를 위한 코드를 작성해야 하므로, 가독성이 떨어질 수 있다.
장점
- 테스트 코드에 작성하므로 프로덕션 코드가 오염되지 않는다.
- 테스트가 통과하지 않으면 문서화가 되지 않으므로, 항상 정확한 API 명세를 제공할 수 있을 뿐 아니라 코드의 검증 까지 보장할 수 있다.
단점
- 적용에 더 많은 노력이 필요하다.
Swagger에 비해 RestDocs의 적용이 더 어렵지만, API 명세는 정확한 문서를 보장하는 것이 가장 중요하다고 생각하여 RestDocs를 사용하는 것으로 결정하였습니다.
추가로, Request시 각 필드 별 제약 조건등을 커스텀으로 추가하여 기재하는 방식으로 더 디테일한 문서를 만들었습니다.
이름: Nginx
버전: -
EC2에 저장된 정적 콘텐츠를 배포하는 데에 사용됩니다.
Nginx는 비동기 이벤트 기반 구조로, 요청을 대기하는 프로세스가 없기 때문에 이 때 낭비되는 자원이 없습니다. 따라서 적은 수의 스레드를 사용하는 경량화된 서버 프로그램입니다.
다른 동적 컨텐츠를 지원하는 서버의 경우 그에 따라 메모리 사용량이 많기 때문에, 이미지, html등 정적 콘텐츠만 제공하려는 저희에겐 불필요하다고 판단하였습니다.
이미지라는 정적 콘텐츠만 제공하는 목적이기 때문에 동기적 구조가 필요하지 않았습니다. 따라서 메모리 낭비가 적고 안정적인 Nginx 를 사용하였습니다.