기술 스택 정하기

본격적으로 프로젝트 개발에 들어가기에 앞서, 백엔드 팀원과 함께 기술스택을 정하는 시간을 가졌습니다.

스프링 부트 3.1.x

스프링 부트의 버전을 정하는 것이 모든 팀들에게 핫 포테이토 였습니다. 그 이유는 스프링 3.X 버전은 자바 17버전 이상부터 지원하기 때문입니다. 즉, 팀원들 모두 익숙하게 이용했던 자바 11버전을 이용하지 못하게 되는 것이었습니다.

그럼에도 이번 프로젝트에서는 3.1.1 버전을 도입하기로 했습니다. 그 이유는 다음과 같습니다.

본 프로젝트를 토이 프로젝트처럼 단기간의 프로젝트로 끝내는 것이 아닌 
지속적으로 운영하기 위해 현재 지원기간이 가장 긴 최신버전을 선택했습니다. 

참고: https://spring.io/projects/spring-boot#support

JAVA 17

java 17버전을 택한 이유 중 가장 큰 이유는 앞서 말한 것과 같이 Spring boot 3.0 부터는 자바 17버전이상을 지원하기 때문입니다. 사실 이 부분은 스프링 부트 3.0을 이용하기 위해서는 필수적인 부분이었습니다.

저는 자바 17버전에서 가장 와닿았던 부분은 Stream 라이브러에서 직접 toList()를 제공하는 것이었습니다. 기존에는 Collectors에서 기능을 찾아서 사용했어야 했지만 17버전 부터는 바로 호출이 가능해서 보다 가독성이 좋아질 것이라고 느껴졌습니다.

반면 Record class는 이용하지 않을 것 같습니다. Record class는 Immutable 객체를 생성하는 유형의 클래스로 기존 toString, equals, hasCode, get 메소드를 지원해줍니다.

public record People(Long id, String name, int age) {
}
// 위와 같은 방식으로 불변 객체를 생성할 수 있습니다. 

간편해보이는 record지만 사용하지 않으려는 이유는 다음과 같습니다. (익숙하지 않은 것일 수도 있지만)오히려 클래스만 보고 무엇을 하려고 하는 것인지 쉽게 파악이 되지 않는 것 같습니다. 또한 equals의 기본 구현은 모든 필드가 같은 경우로 구현되어 있어서 커스텀하기 위해서는 결국에 재정의 과정이 필요합니다. 마지막은 사소한 부분이지만 getter의 경우 getXXX()으로 생성되는 것이 아닌 필드 이름(ex people.name(), people.age())으로 바로 접근이 가능한데 이 부분이 가독성을 떨어뜨릴 것 같습니다.

이 모든 부분을 고려해 팀에서는 record를 사용하는 것 대신에 스프링부트에서 제공하는 Lombok을 이용하기로 했습니다.

Spring Data JPA

이번 프로젝트에서는 JdbcTemplate 대신에 JPA를 이용하기로 팀원들과 함께 결정했습니다.

JPA를 택하게 된 가장 큰 이유는 도메인 설계와 DB 설계의 간극에서 찾아오는 불편함이었습니다. JdbcTemplate에서는 이를 직접 SqlMapper를 통해서 직접 도메인과 테이블을 서로 매핑해주어야 했습니다. 이 때 서로의 간극이 커질 수록 코드의 가독성이 떨어지게 되어 코드 유지보수의 어려움을 느꼈었습니다.

두번째 이유는 코드가 DB에 의존되기 때문에 도메인에서 변경사항이 생긴다면 모든 쿼리문을 직접 수정해야한다는 것이었습니다. 도메인이 수정되게 되면 불가피하게 쿼리문을 수정해야하는데 이는 도메인이 복잡해지면 복잡해질수록 단순 쿼리 수정 과정에 많은 리소스를 부여해야 했습니다. 그래서 저희팀은 프로젝트 중에 최대한 비즈니스 로직에 집중하기 위해 jpa를 이용하고자 했습니다.

마지막 이유는 jpa를 이용하면 데이터베이스 벤더사를 고려할 필요가 없다는 것입니다. 벤더사 마다 지원하는 쿼리 문법이 다르다 보니 JdbcTemplate을 이용하면 데이터베이스가 변경될 때마다 쿼리문을 수정해주어야 하지만 jpa를 이용하면 자동으로 쿼리문을 적용해주어서 jpa를 사용하기로 했습니다.

H2 DB(로컬 상황에서 테스트 용도)

개발환경에서 테스트 상황에서는 H2 데이터베이스를 이용하고자 했습니다. 그 이유는 다음과 같습니다.

스프링 부트에서 간편한 설정을 통해 H2 인메모리 데이터베이스를 이용할 수 있다는 것이었습니다. 개발 단계의 기능 테스트 과정에서는 대량의 데이터가 필요하지 않으며 그 데이터를 굳이 파일로 데이터를 가지고 있을 필요 역시 없다고 생각했기 때문에 개발하는 단계에서는 H2 데이터베이스를 이용하기로 했습니다.

MySQL

본 프로젝트에서 MySQL 데이터 베이스를 운영서버에서 이용하려는 이유는 MySQL의 경우 대량의 데이터를 처리하는데 장점을 가지고 있다는 점입니다. 예를 들면 조회를 하는 과정에서 인덱스를 활용하면 보다 성능을 높일 수 있습니다.

또한 기술적으로는 팀원들 모두가 다른 데이터베이스보다 MySQL에 익숙하여 문제가 발생했을 때 트러블 슈팅이 보다 쉽게 가능하다는 장점이 있었습니다.

마지막으로는 저희 프로젝트에서는 이미지나 동영상과 같은 비정형 데이터를 대량으로 다루지 않기 때문에 NoSQL 데이터베이스를 이용하지 않고 MySQL를 이용하고자 했습니다.

느낀점

현재는 다음과 같이 필요한 부분에 대해서 기술 스택을 정했습니다. 팀원들과 함께 기술 스택을 정하는 과정에서 그 기술 스택이 꼭 필요한 것인지에 대해 서로 토론해보는 시간이 되어서 좋았습니다.(단순하게 그 기술을 이용하고 싶어서 사용하는 것이 아니라 타당한 이유가 존재하는 것이 좋았습니다.) 현재 정한 기술 스택이 최종 기술 스택은 아니며 개발이 진행되고 기존의 기술 스택으로 직면한 문제를 해결하기 어려운 상황에서는 새로운 기술을 적용해 나갈 예정입니다.