[내일배움캠프 사전캠프] 8회차 TIL(7/1 화)

1. 오늘 학습 키워드

• 마이크로서비스 아키텍처 (MSA) 구조 설계
• Database per Service (서비스당 하나의 독립 DB 원칙)
• Spring Data JPA 커스텀 리포지토리 패턴 (RepositoryCustom, Impl)
• JPA 영속성 컨텍스트 메커니즘 (Persist vs Flush)
• @PrePersist 및 Spring Cloud OpenFeign

2. 오늘 학습 한 내용을 나만의 언어로 정리하기

• API Gateway와 데이터베이스 의존성 분리: MSA 환경에서 비즈니스 로직을 수행하는 서비스(Product, Order 등)는 독립된 자체 데이터베이스를 가져야 한다. 반면, API Gateway는 라우팅 및 교통정리 역할만 수행하므로 원칙적으로 DB 의존성이 필요 없다. 프로젝트 생성 시 데이터 JPA 라이브러리가 포함되면 구동 시 데이터소스 연결 예외가 발생하므로 의존성을 제거하거나 인메모리 DB로 격리해야 한다.
• Spring Data JPA Query Method 규칙: JpaRepository 인터페이스 내부에 커스텀 메서드를 선언할 때는 JPA의 명명 규칙을 엄격히 따라야 한다. 임의의 명칭(예: getProducts)으로 DTO를 직접 파라미터로 바인딩하면, JPA가 엔티티 내부 필드로 오인하여 컴파일 시점에 리포지토리 빈 생성 오류를 유발한다.
• 커스텀 리포지토리 구조 패턴: 단일 인터페이스로 해결하기 어려운 복잡한 동적 쿼리는 자바의 인터페이스 설계 원칙상 인터페이스 + Custom 인터페이스 + Impl 클래스 형태로 조각내어 구현한다. 스프링 데이터 JPA가 접미사(Impl) 규칙을 인식해 자동으로 단일 Bean으로 합체시켜 주며, 이를 통해 서비스 레이어에서는 단일 통로로 접근할 수 있다.
• 영속성 컨텍스트와 영속화 타이즘: save() 호출 시 데이터는 영속성 컨텍스트(Persistence Context)에 Persist 상태로 관리된다. 이때 엔티티 내부의 @PrePersist 라이프사이클 메서드가 트리거되는 자바 메모리상의 타이밍과, 실제 물리 데이터베이스에 SQL 쿼리가 전송되는 Flush 타이밍 사이의 매커니즘 차이를 이해해야 한다.

3. 학습하며 겪었던 문제점 & 에러

문제 1: 서버 실행 시 UnsatisfiedDependencyException / No property 'getProducts' found

• 문제&에러에 대한 정의: ProductRepository에 복잡한 검색 DTO를 인자로 받는 커스텀 메서드를 작성했으나, JPA 명명 규칙에 위배되어 애플리케이션 컨텍스트 초기화 단계에서 의존성 주입 실패 에러가 발생함.
• 내가 한 시도: 강사가 제시한 Impl 패턴의 아키텍처 구조를 분석하고, 타 프로젝트의 build.gradle 의존성 구성을 대조해 봄.
• 해결 방법: 복잡한 파일 분리 대신, 인터페이스 내부 메서드에 @Query 어노테이션을 선언하고 내부 속성들을 매핑하는 JPQL 동적 쿼리를 작성하여 단일 인터페이스 구조로 가볍게 해결함.
• 새롭게 알게 된 점: 실무 환경에서는 검색 조건과 필터가 매우 다양하므로 @Query 문자열만으로는 유지보수가 어려워, 파일이 늘어나더라도 Impl 구조나 QueryDSL을 도입해 자바 코드로 제어하는 것이 정석임을 이해함.
• 이 문제&에러를 다시 만나게 되었다면? 인터페이스에 커스텀 DTO를 파라미터로 넘길 때는 묵시적 쿼리 메서드에 의존하지 않고, @Query를 명시하거나 명확한 구현체(Impl) 클래스를 설계하여 쿼리 제어권을 확보하겠음. 이후 여유가 된다면 Impl로 수정해보도록 할것임.

문제 2: 데이터 생성(POST) 후 응답 데이터(ResponseDto)에서 createdAt이 null로 반환되는 현상

• 문제&에러에 대한 정의: 엔티티 클래스 내부에 생성 시점 시간을 주입하는 @PrePersist 라이프사이클 메서드를 구성했음에도, 실제 API 요청 결과 가방(DTO)에는 생성일자 데이터가 누락됨.
• 내가 한 시도: ProductApplication에 @EnableJpaAuditing 추가함.
• 해결 방법: 1. 매번 강제로 데이터베이스 통신(flush)을 유발하는 성능 부담을 피하기 위해, 엔티티의 정적 팩토리 메서드(createProduct) 내부에서 빌더 패턴을 통해 자바 코드로 직접 createdAt(LocalDateTime.now())을 선입력하도록 변경함. 2. 메인 클래스 상단에 @EnableJpaAuditing 설정이 누락되지 않았는지 최종 점검함.
• 새롭게 알게 된 점: save() 호출 직후 동일한 엔티티 인스턴스의 필드를 복사하는 시점과 영속성 컨텍스트 대기실에서 @PrePersist가 발동하는 조건 관계를 파악함. 특히 애플리케이션 메인 클래스에서 외부 감시 스위치(@EnableJpaAuditing)를 명확히 켜주어야만 내부 라이프사이클 메서드가 정상 트리거된다는 점을 마스터함.
• 이 문제&에러를 다시 만나게 되었다면? DB 플러시나 프레임워크 트리거 타이밍에 연동되는 기능에 전적으로 의존하기보다, 비즈니스 도메인 관점에서 반드시 보장되어야 하는 불변 값(생성일 등)은 객체 생성 인스턴스화 시점에 자바 코드로 명확히 초기화하거나 명확한 Auditing 설정을 확보하여 데이터 무결성을 보장하겠음.

4. 내일 학습 할 것은 무엇인지

• MSA의 주요 도메인인 Order (주문) 서비스 개발
• 프로젝트 입문 발제 듣기
• Git & PR(Pull Request) + CI/CD 관리 특강 듣기
• 코드카타
• TIL 작성