<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할 수있다. 

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

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

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

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

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

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

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

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