<stdio.han>

1. @Query와 leftjoin (JPQL)
엔티티들을 한번의 SQL쿼리로 조회
장점 : 간단함
단점 : JOIN FETCH 많이 사용하면 쿼리 복잡도 증가. 연관된 엔티티가 많으면 쿼리 실행 시간 증가.

2. EntityGraph
EntityGraph는 JPA에서 제공하는 기능,
특정 연관 관계를미리 로딩하도록 지정 가능
장점 : JPA표준기능이라 여러 쿼리에서 사용가능
재사용성 높음
단점 : 동적 쿼리나 매우 복잡한쿼리에는 부적함

3. @OneToMany 에서 FetchType.LAZY가 아닌 FetchType.EAGER
비추천
장점 : 간단함
단점 : 성능 저하

4. Batch Fetching
연관된 엔티티들을 한 번에 묶어서 가져오는 방식
장점 : 연관된 엔티티들을 한 번에 묶어서 조회할 수 있어 성능 최적화 가능
BatchSize를 통해 배치 크기 조절 가능
단점 : 메모리 사용량 증가

5. QueryDSL
동적 쿼리를 작성할때 JOIN을 사용해 연관된 엔티티들을 한 번에 가져오는 방식
장점 : 동적쿼리작성가능, 코드의 가독성이 높음. 실무에서 많이 사용함.
단점 : 어려움

6. 서브쿼리
장점 : 메인쿼리 단순하게 유지가능
단점 : 복잡한 sql

7. NativeQuery
SQL을 직접작성하여 원하는 데이터를 직접 가져오기.
장점 : sql을 직접작성하므로 최적화 작업을 자유롭게 가능
JPA, JPQL보다 SQL에 대한 더 높은 제어권을 가짐
단점 : JPA와 통합 어려움
DB의존적임. DB에 종속적이므로 DB를 변경할 경우 쿼리를 수정해야함
clear, flush를 자주 사용해야하고 잘 사용해야함

8. EntityGraph와 JOIN FETCH의 결합
장점 : 동적 조정가능
단점 : 복잡한 쿼리, 메모리 사용량 증가

data.sql 은 Spring Boot 를 실행할 때 자동으로 실행되는 SQL 파일이다. 주로 애플리케이션을 실행할 때 데이터베이스에 기본 데이터를 삽입하거나 테스트 데이터를 설정하는데 사용된다. 이 파일은 src/main/resources 디렉토리에 위치한다.

data.sql 의 장점

• 자동 데이터삽입 : data.sql을 활용하면 애플리케이션 실행 시 data.sql 이 자동으로 실행해 별도로 데이터를 삽입할 필요 없이 자동으로 데이터베이스 초기화가 이루어진다. 이를 통해 개발 초기 상태를 쉽게 만들 수 있다.
• 테스트 데이터 관리 : 개발 및 테스트 환경에서 반복적으로 사용할 데이터베이스 초기 데이터를 관리할 수 있다. 실행마다 동일한 데이터를 쉽게 삽입하기 때문에 데이터베이스의 일관성을 유지할 수 있다.
• 간편한 데이터 삽입 : SQL문을 직접 작성할 수 있기 때문에 직관적이고 빠르다.

비슷한 테스트 데이터 삽입 방법으로 TestDataRunner가 있다. TestDataRunner 의 차이점은 다음과 같다.

data.sql 을 사용하기위해서 application.properties 를 설정해 주어야 한다.

spring.datasource.initialization-mode=always

spring.datasource.initialization-mode: 데이터베이스 초기화 모드를 설정합니다. always로 설정하면 애플리케이션 시작 시 data.sql을 실행하게 됩니다.

이는 스키마가 이미 존재할 때 사용해야 한다. 스키마 도 새로 설정해야한다면 스키마 설정과 데이터도 추가해 줘야한다. 나는 스키마는 있었으므로 데이터만 추가했었다.

개발 프로젝트를 관리하는것은 복잡하고 어려운 일이다. 이를 좀 더 쉽고 효율적으로 관리하기위해 많은 프로젝트 관리 도구가 있다. 대표적인 예로 Jira, Github Project가 있다. 그 중에서 Github Project에 관해 작성해보겠다.

Github Project의 장점 : 

• Github Project의 가장 큰 장점 중 하나는 코드 저장소와 프로젝트 관리 도구가 하나의 플랫폼에 통합되어 있다는 것이다. 코드를 저장하고 관리할때 Github를 통해 관리하니 한번에 관리할 수 있어 좋다. 이는 개발자들이 코드 작업과 프로젝트 진행 상황을 동시에 관리할 수 있어 작업 흐름이 매우 자연스럽다.

• Github Project는 유연한 칸반 보드 시스템을 제공한다. 팀원들은 자신들의 워크 플로우에 맞게 칸반 보드를 구성해서 팀의 특정 요구사항에 맞는 사용자 정의 열을 추가할 수 있다.

위 사진처럼 Todo, In Progress, Done 보드 3개로 간단하게 구성해서 사용할 수 있다. 생성된 Issue를 Close하면 자동으로 Done 으로 이동하게된다.

또한, Issue를 생성할 때 템플릿을 설정해 좀더 가독성 좋고 간단하게 이슈를 생성하고 PR할 수있다. 

이번에 새로 진행할 프로젝트는 '음식 주문 관리 플랫폼' 개발이다.

우리팀은 백엔드 개발팀으로서 프로젝트에 참여했다.(라고 상상하며 시작하자)

먼저 기획자가 알려준 개발 요구사항 명세서를 확인해보자. 

• 요구사항을 확인해보고 필수기능을 먼저 만들기위해 대략적인 API 명세서, 테이블 명세서, ERD 명세서, 인프라 설계서를 만들어봐야 할 것 같다. 요구사항이 어느정도 나와있어서 ERD 설계를 먼저 해보기로 했다. 

ERD 설계서

그리고 위의 ERD 설계서를 보고 API 명세서를 작성해보았다.

API 명세는 최대한 RESTful API 원칙에 따라 작성해 프론트 엔드 개발자가 API 문서만 보고도 개발 할 수 있게 작성을 해보았다. 일부 Search 기능에는 페이지네이션기능을 추가해주었다. 각 엔티티 별로 필요한만한 API들을 만들었다.

API 명세서

더보기

 

 

그리고 다음은 ERD 명세서와 API 명세서를 바탕으로 테이블 명세서를 작성해 주었다.

테이블 명세서는 요구사항에 맞게 각 테이블명의 시작은 p_table로 시작한다. 그리고 유저 ID는 최소 4자 ~ 10자. 다른 테이블의 id는 UUID로 정의했다. 모든 테이블은 데이터 감사 로그를 기록해야하므로 created_at, created_by, updated_at, updated_by, deleted_at, deleted_by 필드를 추가했다.

테이블 명세서

더보기

 

마지막으로 인프라 설계서를 작성해주었다. 최대한 간단하게 표현하기 위해 프론트, Docker 등을 제외하고 백엔드 관점에서의 시스템 아키텍처만 작성해주었다.

인프라 설계서

MSA (Microservice Architecture)는 하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포, 유지보수를 용이하게 하는 소프트웨어 아키텍처 스타일이다. 각 서비스는 특정 비지니스 기능을 수행하며, 서로 독립적으로 배포되고 확장될 수 있다.

Monolithic Architecture는 하나의 큰 코드베이스로 구성된 애플리케이션으로 모든 기능이 하나의 애플리케이션 내에 포함된다. 이로인해 배포가 단순하고 하나의 DB를 사용해 데이터 일관성을 쉽게 유지할 수 있다. 하지만 특정 기능을 확장하려면 전체를 확장해야 하므로 확장성이 부족한다. 비슷한 맥락으로 작은 변경 사항에도 전체를 다시 배포해야한다.  또한 새로운 기술 도입이 어렵고 특정 모듈에 종속적이다.

MSA 는 모놀리틱의 대표적인 단점들을 극복해 특정 서비스만 확장하여 성능을 최적화할 수 있고 개별 서비스의 변경 사항을 독립적으로 배포할 수 있다. 또한 서비스 별로 적합한 기술 스택을 선택할 수 있다. 하지만 장점만 있지는 않다. 여러개의 서비스로 나눈만큼 서비스 간 통신, 데이터 일관성 유지, 트랜잭션 관리등의 복잡성이 증가한다. 추가로 그에대한 모니터링, 로깅, 장애 대응 등을 개별적으로 관리해야 하므로 운영 비용이 증가한다. DB또한 분산되어 있어 데이터 일관성 유지가 어려울 수 있다. 각 서비스 간의 통신이 네트워크를 통해 이루어지므로 지연 시간이 발생할 수 있다.

언뜻 보기엔 MSA로 개발하는게 무조건 좋다는것 처럼 보이기도 한다. 하지만 개발엔 정답이 없다. 프로젝트의 방향에 따라 개발의 크기, 기능의 구성 등 정말 다양한 사항들이 결정된다. 앞으로 입사할 회사들의 개발된 레거시의 구조, 신규 프로젝트에서의 합의된 구조를 잘 파악하고 따라 가는것이 중요하다. 그래야 유지보수도 수월할 것이고 추가 투입 인원이 있다면 수월하게 진입할 수 있다.

특히 MSA는 너무 많은 것들이 사용되며, 정책 설정을 해야 할 것이 많다. 빠르게 프로젝트의 프로토 타입을 만들어야 한다면 모놀리틱 아키텍쳐를 사용하고, 후에 부분부분 전환하는 것도 방법이다.

저번 면접시에 받았던 질문이 있다. 우리회사엔 레거시가 좀 많은데 레거시에 대해서 어떻게 생각하는지? 였다.

이에대한 대답중 하나로 기존 레거시가 최신기술 혹은 내가알고있는 패턴과 많이 다르다고해서 레거시를 최신기술로 변경한다거나 하는것은 오히려 안좋을 수 있다. 기존의 있는 패턴을 최대한 유지해야한다고 생각한다. 그 이유는 만약 내가 변경하려는 프로젝트는 다른 누군가가 같은 프로젝트를 보고있다면 갑자기 2개의 패턴이 되버리는 것이다. 그리고 또 다른 누군가가 2개가 되버린 패턴을 보고 혼동이 와서 다른 패턴으로 개발을 시작해버린다면 3개가 되버리는것이다. 

만약 내가 기존의 프로젝트에 투입되게 된다면 기존 코드의 'CRUD Search'를 한번 샘플로 만들어보는것이다. 이처럼 기존 프로젝트를 파악할 때 CRUD관점으로  파악하면 좀더 쉬울 수 있다. Restful한 API라면 이미CRUD로 되어있을것이고 Restful 하지 않은 API라도 Restful하게 CRUD관점에서 보는게 더 파악하기 쉽다.