equals() :

• 두 객체 비교, true면 hashCode()도 같아야 함
• 객체 주소가 같으면 True
• == 는 값만 판단 가능, 같은 객체인지 판단하려면 equals 사용 필수
• String 객체에서는 주소가 같으면 True, 오버라이딩된 equals 함수를 사용하기 때문

hashCode() :

• hashCode()가 같다고 해서 equals()가 true일 필요는 없음
• 동일한 객체들이 해시 기반 컬렉션에서 같은 버켓에 가도록 보장

Java

equals():

• Object.equals()는 참조 비교
• 같은 타입 객체여도 같은 인스턴스가 아니라면 false

equals()를 오버라이드할 때 중요한 점

• hasCode() 오버라이드 필수: hashCode()를 오버라이드하지 않는다면 기본 Object.hashCode()가 사용됨 -> 이럴 경우 equals에서 같다고 판정이 나더라도 해시값이 다를수가 있음 -> hashSet에서 contain 여부를 조회할 때, false가 반환될 수 있음
• 자기 자신 비교, 타입 체크, 필드 비교, hashCode도 같은 필드 기준 계산 필요

  import java.util.Objects;
  

public class Member { private final String name; private final int age;

public Member(String name, int age) {
    this.name = name;
    this.age = age;
}

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (!(o instanceof Member)) return false;
    Member member = (Member) o;
    return age == member.age &&
            Objects.equals(name, member.name);
}

@Override
public int hashCode() {
    return Objects.hash(name, age);
}

}

단점
- equals만 오버라이드하고, hashCode를 만들지 않는다면 버그 발생하기 때문에 번거로움
- equalsI()와 hashCode()가  다른 필드를 보게 되면 계약이 깨짐
- mutable 필드를 기준으로 hashCode()를 생성하게 되면 문제가 생길 수 있음
    - 추후 HashSet에 해당 객체를 넣고, mutable 필드를 수정하면 hash값이 넣었을 때와 변경 이후가 다르기 때문에 문제가 생길 수 있음
    - 해시 기반 컬렉션의 key가 되는 객체는 불변이 안전함

```java
class Member {
    String name;
}


Set<Member> set = new HashSet<>();
Member m = new Member("kim");
set.add(m);

m.name = "lee";

set.contains(m); // 이상 동작 가능

Kotlin

equals보다는 == , === 를 사용한 equality 를 위한 연산자 문법 사용이 권장된다.

• == : equals() 기반 비교, 내부적으로 equals 사용

  • Kotlin의 모든 클래스는 기본적으로 Any를 상속하는데, 자바 Object처럼..

  • Any에는 이미 equals 함수가 있는데, 같은 인스턴스면 true, 다르면 false

    // 기본 equals 함수
    open operator fun equals(other: Any?): Boolean
    
    // 오버라이드 equals 함수
    override fun equals(other: Any?): Boolean
    

• === : 참조 동일성 비교, 같은 인스턴스인지 비교

• Any.equals(): 참조 동일성 성격

• data class는equals()와 hashCode() 자동 생성

  • 같은 타입이라면 true

• data class의 경우

data class Member(
    val name: String,
    val age: Int
)

val m1 = Member("kim", 20)
val m2 = Member("kim", 20)

println(m1 == m2)   // true
println(m1 === m2)  // false

• 일반 클래스에서 오버라이드할 경우 - hashCode() 오버라이드 필수

  class Money(val amount: Int) {
    override fun equals(other: Any?): Boolean {
        if (this === other) return true
        if (other !is Money) return false
        return this.amount == other.amount
    }
  
    override fun hashCode(): Int {
        return amount
    }
  }
  

```

주의할 점

• 일반 클래스는 자동 값 비교가 아님, 데이터클래스만 해당
• 배열 비교의 경우 equals()보다는 contentEquals()로 비교

이번에 모니터링을 평소 하던 AWS가 아닌 Railway와 연결해서 하면서, 어떤 모니터링 방식으로 메트릭 수집을 하면 좋을지 생각해보게 되었다.

메트릭은 매 이벤트를 전송하는 게 아니라, 애플리케이션 메모리 안에서 숫자를 계속 누적하거나 갱신하다가 일정 주기마다 스냅샷을 보내는 구조였다.

이번 글에서는 Spring Boot Actuator, Micrometer, OTLP, Grafana까지 메트릭이 흘러가는 과정을 한 번에 정리한다.

전체 흐름

Spring Boot 애플리케이션에서 JVM 메트릭이 Grafana 같은 백엔드까지 가는 흐름은 대략 이렇다.

JVM 내부 상태
-> Micrometer 계측/집계
-> OTLP registry가 주기적으로 전송
-> Grafana 같은 백엔드에서 저장/조회

중요한 점은 요청마다 외부로 메트릭을 보내지 않는다는 것이다.

애플리케이션 안의 MeterRegistry가 숫자를 관리하고, OtlpMeterRegistry 같은 registry가 설정된 주기마다 현재 상태를 묶어서 전송한다. 예를 들어 step이 30초라면 30초마다 한 번씩 스냅샷을 보낸다.

그래서 트래픽이 많아져도 메트릭 전송량이 요청 수만큼 폭증하지 않는다. 전송량은 주로 메트릭 개수, 라벨 조합 수, 전송 주기에 영향을 받는다.

JVM 상태

JVM은 내부 상태를 MXBean, 즉 JMX 기반 인터페이스로 노출한다.

대표적으로 이런 값들이 있다.

• MemoryMXBean: 힙/논힙 메모리 사용량
• GarbageCollectorMXBean: GC 횟수, 누적 시간
• OperatingSystemMXBean: CPU 사용률
• ThreadMXBean: 스레드 수

Spring Boot Actuator를 붙이면 기동 시 여러 MeterBinder가 자동으로 등록된다.

• JvmMemoryMetrics
• JvmGcMetrics
• ProcessorMetrics
• JvmThreadMetrics

이 Binder들이 JVM의 MXBean 값을 읽어서 Micrometer의 Meter로 연결한다. 그래서 애플리케이션에서 jvm.memory.used, process.cpu.usage, jvm.threads.live 같은 메트릭을 볼 수 있게 된다.

Micrometer로 값 관리

Micrometer는 계측 추상화 계층이다. 중심에는 MeterRegistry가 있고, 그 안에 여러 Meter가 등록된다.

대표적인 Meter는 세 가지다.

여기서 헷갈리기 쉬운 점은 계측과 전송이 분리되어 있다는 것이다.

Micrometer는 앱 안에서 값을 관리한다. 외부로 보내는 일은 Prometheus registry, OTLP registry 같은 구현체가 맡는다.

OTLP는 어떻게 전송하는지?

OTLP 방식에서 OtlpMeterRegistry는 push 방식으로 동작한다.

앱이 시작되면 백그라운드 스레드가 돌고, 설정된 step마다 publish 과정이 실행된다.

1. Registry의 모든 Meter를 확인한다.
2. Gauge는 지금 값을 읽는다.
3. Counter, Timer는 누적값과 히스토그램 상태를 읽는다.
4. OTLP protobuf 포맷으로 직렬화한다.
5. 설정된 endpoint로 HTTP POST를 보낸다.

설정에서는 보통 이런 값이 중요하다.

management:
  otlp:
    metrics:
      export:
        url: https://example-otlp-endpoint
        step: 30s
        headers:
          Authorization: Bearer ${OTLP_TOKEN}

실제 속성 이름은 Spring Boot와 Micrometer 버전에 따라 확인이 필요하지만, 개념적으로는 "어디로", "얼마나 자주", "어떤 인증으로" 보낼지가 핵심이다.

Prometheus pull과 OTLP push의 차이

메트릭을 수집하는 방식은 크게 pull과 push로 나눠서 볼 수 있다.

Prometheus pull

Prometheus 방식은 수집기가 앱으로 들어와서 값을 가져간다.

Prometheus -> /actuator/prometheus -> Spring Boot App

앱은 /actuator/prometheus 같은 엔드포인트에 현재 값을 노출하고, Prometheus가 주기적으로 scrape한다.

Docker Compose나 Kubernetes처럼 내부 네트워크와 service discovery가 잘 잡힌 환경에서는 자연스럽다. 하지만 Railway처럼 외부 수집기가 앱 주소로 접근하거나 target을 관리하기 애매한 환경에서는 설정이 번거로울 수 있다.

OTLP push

OTLP 방식은 앱이 외부 endpoint로 직접 보낸다.

Spring Boot App -> OTLP endpoint -> Grafana Cloud

수집기가 앱으로 들어올 필요가 없다. 앱이 인증 정보를 들고 외부 endpoint로 POST를 보내면 된다.

그래서 PaaS 환경이나 외부 접근이 까다로운 환경에서는 push 방식이 더 단순할 수 있다.

Grafana에서는 어떻게 보이는지?

Grafana 같은 백엔드는 받은 숫자를 시계열로 저장한다.

시계열은 보통 다음 조합으로 구분된다.

메트릭 이름 + 라벨 조합

예를 들어 같은 jvm.memory.used라도 라벨이 다르면 다른 시계열이다.

• area=heap
• area=nonheap
• id=G1 Eden Space
• application=gerd

management.metrics.tags.application=gerd처럼 공통 라벨을 붙여두면 나중에 Grafana에서 특정 앱만 필터링하기 좋다.

PromQL에서는 이런 식으로 조회할 수 있다.

process_cpu_usage

rate(jvm_gc_pause_seconds_sum[5m])

미리 만들어진 JVM 대시보드를 가져오면 heap, GC pause, CPU, thread 같은 기본 패널을 빠르게 구성할 수 있다.

Better Stack이랑 다른점

Better Stack은 로그 수집, 업타임 모니터링, 온콜까지 한 번에 묶기 좋다. 별도로 Loki나 알림 시스템을 붙이지 않아도 시작하기 쉽다는 장점이 있다.

대신 메트릭 대시보드는 Grafana의 PromQL 대시보드를 그대로 쓰기보다 Better Stack의 SQL 방언에 맞춰 직접 패널을 구성해야 할 수 있다.

예를 들어 진단용으로는 이런 패널을 만들 수 있다.

• Heap used vs max
• Live threads
• GC pause p50/p95/p99
• CPU usage
• Disk free
• Logback events by level

Better Stack 쿼리에서는 게이지 값에 avgMerge(value_avg)를 쓰거나, 라벨을 label('level')처럼 꺼내는 식의 차이가 있다. 히스토그램 quantile도 저장소 방언에 맞춰 확인해야 한다.

여기서 중요한 건 쿼리를 외우는 게 아니라, 실제 저장된 metric name과 label을 먼저 확인하는 것이다. Micrometer에서 보던 이름, Prometheus 이름, OTLP 저장소에서 보이는 이름이 조금씩 다를 수 있다.

커스텀 대시보드 구성

Better Stack은 그라파냐처럼 spring boot 전용 세팅되어있는게 없다. 그래서 확인할 항목을 골라서 커스텀으로 쿼리를 입력해서 직접 만들어야 한다.

다음과 같은 순서로 제작했다.

1. Better Stack Source 만들기

Telemetry -> Sources 탭에 들어가서 Connect Source를 누른다. Source를 만들면 Source token, url 이렇게 두개가 나온다.

curl -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer [token]' \
  -d '{"dt":"'"$(date -u +'%Y-%m-%d %T UTC')"'","message":"Hello from Better Stack!"}' \
  --insecure \
  https://[url]

management:
  endpoints:
    web:
      exposure:
        include: health,info,env,configprops  
  endpoint:
    health:
      show-details: never
      probes:
        enabled: true
  health:
    diskspace:
      enabled: true
    ping:
      enabled: true
    livenessstate:
      enabled: true
    readinessstate:
      enabled: true
  metrics:
    tags:
      application: ${spring.application.name}
  otlp:
    metrics:
      export:
        enabled: true
        url: ${BETTERSTACK_OTLP_URL}/v1/metrics
        headers:
          Authorization: Bearer ${BETTERSTACK_SOURCE_TOKEN}
        step: 30s

각각 OTLP, SOURCE_TOKEN으로 넣어준다!

2. 커스텀 대시보드 만들기

해당 탭에서 Create dashboard로 들어간다. 그러면 처음에는 아예 대시보드가 비어있다.

맨 오른쪽의 플러스 버튼을 누르면 차트를 만들 수 있다.

source를 아까 만들었던것으로 절정하고, Query를 입력하고 Run query를 하면 설정한 차트 타입에 따라 볼 수 있다.

나는 다음과 같은 항목을 추가해줬다.

이렇게 항목을 달아주면...

완성이된다~!

정리

메트릭 수집의 핵심은 이벤트 전송이 아니라 숫자 상태의 주기적 스냅샷이다.

• JVM은 MXBean/JMX로 내부 상태를 노출한다.
• Spring Boot Actuator의 MeterBinder가 JVM 값을 Micrometer Meter로 연결한다.
• Micrometer는 앱 메모리의 MeterRegistry에서 값을 관리한다.
• OTLP registry는 step마다 protobuf로 직렬화해서 HTTP POST한다.
• Grafana나 Better Stack은 이를 시계열로 저장하고 label 기준으로 조회한다.

Prometheus pull이 좋은 환경도 있고, OTLP push가 더 단순한 환경도 있다. 지금 나같은 경우는 Railway를 사용하고 있기에 Better Stack을 사용했다.

가장 큰 사건 위주로 보면

• UMC 9기 수료 및 데모데이
• 새로운 프로젝트 백엔드 합류, 8월 런칭 예정
• UMC 스프링 파트장, 안드로이드 챌린저로 스터디 진행
• 개발동아리 프로그라피 11기 참여

등등등.. 이 있었다. 학교도 안다니면서 정말 다사다난했다!

1~2월

1월에는 일단 UMC 데모데이를 위한 프로젝트 TAMINGO를 시작했다. 백엔드 5명은 처음이었고 팀장을 맡게 되었다. IOS와 연동하는 것도 처음이었기에 기대가 되었다. 그리고 프로젝트 자체가 LLM API 호출이나 Redis 캐싱이 많이 필요한 프로젝트라서 좀 애먹었던 것 같다. 생각보다 시간투자를 많이 해야 해서 힘들었다 .. 그리고 길찾기 API를 사용해서 도착 예상 시간을 매번 계산해야 했기에 지도 API는 이것저것 거의 다 만져본 것 같다.

그리고 런칭 준비 중인 독서 기록 서비스 NOOK의 리뉴얼 버전 개발을 시작했다. 기존 기능과 많이 달라지기도 했고 Rest Docs를 도입해서, 안좋았던 부분들을 다 버리고 시작하는 느낌이라 좀 기분이 좋았다 .. ^ㅡ^

2월 말! 드디어 UMC 데모데이를 했다. 생각보다 내가 맡은 기능 질문이 많이 들어와서 당황스러웠지만.. 하루종일 단체티 입고 다니면서 구경하니 재밌었다. 마지막으로 참여하는 스프링 부트 프로젝트였는데 꽤나 만족스러웠다!

3~4월

3월에는 역시 동아리 시작이다.. UMC 스프링부트 파트장으로서의 마지막 10기를 시작했다. 서류,면접,OT 등등 하니 시간이 빨리 갔다.

이번 기수에는 스프링부트가 아닌 Android 파트로 프로젝트에 참여하게 되었다. 코틀린 공부를 하려고 했지만 잘 안하게 되어서.. 강제로라도 하기 위해 한것도 있고, AX 시대에 풀스택 개발을 해보면 좋지 않을까? 해서 하게 되었다. 그리고 React도 공부를 해봤지만 재미가 없었기에.. 1학년때 하고 포기한 Android.. 를 다시 시작하게 되었다.

그리고 4월에는 새로운 동아리를 시작했다. 다른 개발 동아리들과 달리 과제를 받는게 흥미로웠고, 빨리 출시해서 돈을 벌어보고 싶다는 생각에 프로그라피 11기에 지원하게 되었다. 과제를 비록 전날에 시작해서 대충대충 해서 냈지만...! 면접까지 거쳐서 백엔드 파트로 합격하게 되었다~! 두근두근..

4월에는 또 새로운 프로젝트에 백엔드 파트로 합류하게 되었다. 알림 기능을 맡게 되었고, 필요하면 다른 기능도 맡기로 하고 들어가게 되었다.

5~6월

음.. 이제 내가 벌려놓은 일을 수습할 시간이다.

먼저 프로그라피에서는 5월에 기획 단계에 들어갔기에 초기 세팅 작업을 열심히 했다. AI 세팅, 코틀린 스프링 세팅 등등.. 을 진행했다. 이번에는 AWS가 아닌 Railway를 사용하면서 비용 절감에 집중해보려고 한다!

6월에는 많은 일이 있었다. 싸피 코딩테스트 응시 및 면접 준비(하느라 개발을 거의 못했다..), 프로그라피 백엔드 팀원 탈주로 인한 업무량 증가.. 이것때문에 코틀린 스프링을 우다다다다 해서 깨달은게 많다.

이것 말고도 다른 프로젝트를 간간히 진행했다.

그리고 매주 나를 힘들게했던 안드로이드 스터디가 끝났다. 스프링 스터디 피드백도! 프론트는 나랑 잘 안맞는다고 느꼈다. 그렇지만 내부 로직 짜는 건 재밌게 했던 것 같다.

회고록

졸업유예를 하고 코딩테스트,포트폴리오 제작,CS 공부 등등을 하려던 나의 목표가 프로젝트 기계(?)로 바뀌었지만 프로젝트를 하면서 많이 배웠다. 확실히 학교를 안다니면서 프로젝트를 하니 삶의 질이 달라지는 것 같다. ^^ 그렇지만 하반기에는 프로젝트를 많이 하더라도 공부를 꾸준히 병행해야겠다는 생각이 들었다. 코딩테스트 문제 풀기도 초반엔 열심히 했는데 나중에는 바빠서 거의 못했다.

하반기에 할일들

• 운동을 열심히 하자.주4회이상(중요)
• 성공적으로 프로젝트 런칭하기
• 공모전 참여하기
• CS 공부, 코딩테스트 공부 매일 꾸준히 하기
• 본격적 취준하기
• 안드로이드 프로젝트하기

sealed class는 상속 가능한 범위를 같은 파일로 제한하는 클래스다.

sealed class Shape
data class Circle(val radius: Double) : Shape()
data class Rectangle(val w: Double, val h: Double) : Shape()

컴파일러가 모든 하위 타입을 알고 있기 때문에, when 분기에서 else 없이도 모든 케이스를 강제 처리할 수 있다.

when (shape) {
    is Circle -> ...
    is Rectangle -> ...
    // else 불필요 — 누락 시 컴파일 에러
}

나중에 Triangle을 추가하면, 처리하지 않은 when에서 즉시 컴파일 에러가 발생한다. 런타임이 아닌 컴파일 타임에 누락을 잡아주는 게 핵심.

언제 쓰는지?

타입에 따라 가지고 있는 데이터 구조가 다를 때 유용하다.

실제 사용 예 — 타임라인 API 응답 DTO

요구사항

타임라인 아이템은 식사 기록이 1개인 SINGLE과 2개 이상인 GROUP 두 가지 타입이 있다. 문제는 등급(grade) 필드가 SINGLE일 때만 존재한다는 점이다. 또한 여러개이려면 대표 음식도 두개를 표시해야 한다. 그리고 같이 기록된 음식의 개수도 표시해야 한다.

이걸 하나의 DTO로 표현하면 이렇게 된다.

data class TimeLineItemDTO(
    val type: TimeLineType,
    val grade: String?,  // SINGLE이면 값 있고, GROUP이면 null
    ...
)

grade가 null인 이유가 타입 레벨에서 드러나지 않는다. 클라이언트는 왜 null인지 알 수 없고, 서버도 grade를 실수로 채워 보내도 컴파일러가 잡아주지 못한다. 즉 타입에 따라 해당하지 않는 필드를 null로 채우면 비효율적이라는 것이다.

sealed class로 분리하면 이 문제가 사라진다.

sealed class TimeLineItemDTO {
    data class Single(
        val grade: String,  // non-null 보장
        ...
    ) : TimeLineItemDTO()

    data class Group(
        // grade 자체가 없음
        ...
    ) : TimeLineItemDTO()
}

SINGLE이면 grade가 반드시 있고, GROUP이면 애초에 필드가 없다. nullable 대신 타입 구조로 제약을 표현한 것이다. 서비스 레이어에서 when 분기로 각 타입을 생성하면 컴파일러가 모든 케이스 처리를 강제한다.

abstract class와 비슷하지만 상속 범위 제한 + 분기 누락 검사 가 추가된 것으로 이해하면 된다.

abstract class는 누군가 다른 파일에서 Triangle : Shape()를 추가할 수도 있으니, 컴파일러는 when에 무조건 else를 강제한다. 즉 해당 요구사항에서는 두 타입만 올것인데 다른게 올 수 있다고 하는 것이다.

sealed class는 하위 타입을 전부 안다는 것이 보장되니까, when에서 모든 케이스를 빠짐없이 처리했는지를 컴파일러가 검사해줄 수 있다. 만약 Triangle을 새로 추가했는데 when에서 빼먹으면, 그 즉시 컴파일 에러가 난다는 점에서 abstract class와 차이가 있다.

문제

증상 생성/수정 후 Gemini 기반 패턴 분석을 비동기로 갱신하고 있었다.

기존 흐름은 다음과 같았다.

@Async("analysisTaskExecutor")
@Transactional(propagation = Propagation.REQUIRES_NEW)
fun refreshAsync(symptomId: String, userId: Long) {
    val symptom = symptomRepository.findByExternalIdAndUser_Id(symptomExternalId, userId) ?: return
    if (!symptom.isAnalysisDirty) return

    val result = symptomPatternAnalysisService.generate(symptom, userId)

    if (result.shouldUpdate) {
        symptom.updateAnalysis(result.analysisJson)
    }
}

이 구조에는 두 가지 문제가 있었다.

1. Gemini 호출이 DB 트랜잭션 안에서 실행된다.
2. 오래 걸린 이전 비동기 작업이 나중에 끝나면서 최신 분석 결과를 덮어쓸 수 있다.

요구사항 : 사용자가 증상 생성 시 증상에 대한 분석을 생성해야 한다. 결과는 anslysisJson이라는 컬럼으로 저장되며, 응답을 내려줄 때는 dto로 매핑한다.

예를 들어 사용자가 증상을 생성하면 분석 작업 A가 시작되고, 바로 메모를 수정하면 분석 작업 B가 다시 시작된다.
B가 먼저 끝나 최신 데이터 기준 분석을 저장했더라도, A가 늦게 끝나면 과거 데이터 기준 분석으로 analysisJson을 다시 덮어쓸 수 있었다.

원인

비동기 작업마다 “이 분석이 어떤 시점의 증상 상태를 기준으로 만든 결과인지”를 검증하지 않았다.

즉, 작업 시작 시점의 증상 상태와 결과 저장 시점의 증상 상태가 같은지 확인하는 장치가 없었다.

또한 @Transactional(REQUIRES_NEW)가 refresh 전체에 걸려 있어, DB 조회뿐 아니라 Gemini 외부 호출 중에도 트랜잭션이 유지될 수 있었다.

해결 방법

Symptom에 분석 전용 버전 필드인 analysisVersion을 추가했다.

증상 내용이 바뀌어 분석이 다시 필요해질 때마다 버전을 증가시킨다.

@Column(name = "analysis_version", nullable = false, columnDefinition = "bigint default 0")
var analysisVersion: Long = analysisVersion
    protected set

fun markAnalysisDirty() {
    isAnalysisDirty = true
    analysisVersion += 1
}

분석 결과를 저장할 때는 작업 시작 시점의 버전과 현재 버전이 같은 경우에만 반영한다.

fun updateAnalysis(analysisJson: String, expectedVersion: Long): Boolean {
    if (!isAnalysisDirty || analysisVersion != expectedVersion) return false

    this.analysisJson = analysisJson
    isAnalysisDirty = false
    return true
}

비동기 서비스에서는 작업 시작 시점의 버전을 캡처한다.

@Async("analysisTaskExecutor")
fun refreshAsync(symptomId: String, userId: Long) {
    val symptom = symptomRepository.findByExternalIdAndUser_Id(symptomExternalId, userId) ?: return
    if (!symptom.isAnalysisDirty) return

    val expectedVersion = symptom.analysisVersion

    val result = symptomPatternAnalysisService.generate(symptom, userId)

    if (result.shouldUpdate) {
        symptomAnalysisResultWriter.updateIfVersionMatches(
            symptomId = symptomId,
            userId = userId,
            expectedVersion = expectedVersion,
            analysisJson = result.analysisJson,
        )
    }
}

결과 저장은 별도 writer에서 짧은 쓰기 트랜잭션으로 처리했다.

@Service
class SymptomAnalysisResultWriter(
    private val symptomRepository: SymptomRepository,
) {
    @Transactional
    fun updateIfVersionMatches(
        symptomId: String,
        userId: Long,
        expectedVersion: Long,
        analysisJson: String,
    ): Boolean {
        val symptomExternalId = runCatching { UUID.fromString(symptomId) }.getOrNull() ?: return false
        val symptom = symptomRepository.findByExternalIdAndUser_Id(symptomExternalId, userId) ?: return false

        return symptom.updateAnalysis(analysisJson, expectedVersion)
    }
}

결과

오래된 비동기 작업이 늦게 끝나더라도, 그 사이 증상이 수정되어 analysisVersion이 증가했다면 결과를 저장하지 않는다.

즉, 최신 증상 상태에 기반한 분석만 반영된다.

또한 Gemini 호출을 감싼 긴 쓰기 트랜잭션을 제거하고, 최종 저장 시점에만 짧은 트랜잭션을 사용하도록 분리했다.

검증

오래된 분석 결과가 버려지는 테스트를 추가했다.

@Test
fun `작업 시작 이후 증상이 바뀌어 버전이 다르면 오래된 분석 결과를 버린다`() {
    val symptom = SymptomFixture.symptom(isAnalysisDirty = true, analysisVersion = 3L)

    whenever(symptomRepository.findByExternalIdAndUser_Id(SymptomFixture.SYMPTOM_EXTERNAL_ID, userId))
        .thenReturn(symptom)

    val updated = writer.updateIfVersionMatches(
        symptomId = SymptomFixture.SYMPTOM_EXTERNAL_ID.toString(),
        userId = userId,
        expectedVersion = 2L,
        analysisJson = """{"label":"오래된 결과"}""",
    )

    assertThat(updated).isFalse()
    assertThat(symptom.analysisJson).isNull()
    assertThat(symptom.isAnalysisDirty).isTrue()
    assertThat(symptom.analysisVersion).isEqualTo(3L)
}

이번에 테스트 환경을 보다가 찝찝한 지점이 있었다.

운영은 PostgreSQL을 쓰고 있는데, 테스트는 H2의 PostgreSQL mode로 돌고 있었다.

처음에는 PostgreSQL mode면 어느 정도 비슷하지 않나?라고 생각할 수 있다.
그런데 Repository 테스트나 JPA 매핑 테스트에서는 이 차이가 생각보다 크다. H2, PostgreSQL 예약어를 둘다 피해야 하고, 같은 환경이 아니므로 테스트 시 예외가 생길 수도 있는 것이다.

TestContainers란?

통합테스트의 중요성이 강조될수록 필요하다고 생각한다. 보통 통합 테스트를 위해서 인메모리나 임베디드를 사용한다. H2 인메모리 데이터베이스를 주로 통합테스트에 사용하는데, 통합테스트에 필요한 기능을 전부 지원하지 않을 수도 있다고 한다. 예를들어 PostgreSQL을 애플리케이션에서 사용한다고 하면 고급 기능을 지원하지 않을 수 있다는 것이다.

동작 원리

도커 컨테이너로 래핑된 실제 서비스와의 통합 테스트를 위해서, 간단한 API를 제공하는 테스트 라이브러리이다.

• TestContainers API를 사용해서 도커 컨테이너 시작
• 서비스를 사용해서 테스트 실행
• 사용된 서비스 컨테이너 파괴, 성공 여부와 상관없음

즉 테스트를 성공하려면 도커가 설치되어있어야 한다.

왜 H2를 사용하지 않는지

H2 PostgreSQL mode는 PostgreSQL을 완전히 재현하지 않는다.
PostgreSQL처럼 보이게 일부 문법을 맞춰주는 것에 가깝다.

그래서 다음 같은 부분에서 차이가 생길 수 있다.

• @SQLRestriction 기반 소프트 삭제 필터
• native query
• PostgreSQL 전용 타입이나 함수
• @MapsId 공유 PK 매핑
• FK, unique, not null 같은 제약 조건
• cascade, orphan removal 동작

예를 들어 이런 native query가 있다고 하자.

SELECT COUNT(*)
FROM users
WHERE user_id = ?

H2에서는 통과했는데 PostgreSQL에서는 식별자, 타입, 문법 차이 때문에 실패할 수 있다.
이러면 테스트는 통과인데 운영에서 깨지는 상황이 생긴다.

그래서 테스트 DB도 운영과 같은 PostgreSQL 16으로 맞추기로 했다.

선택한 방식: jdbc:tc URL

이번에는 Testcontainers의 JDBC URL 방식을 썼다.

spring:
  datasource:
    url: jdbc:tc:postgresql:16:///testdb
    username: test
    password: test
  test:
    database:
      replace: none

jdbc:tc:postgresql:16:///testdb는 Testcontainers가 제공하는 특수한 JDBC URL이다.
애플리케이션이 이 datasource로 연결하려고 하면 Testcontainers가 PostgreSQL 컨테이너를 띄워준다.

이 방식의 장점은 설정이 가볍다는 것이다.

dependencies {
    testImplementation("org.testcontainers:junit-jupiter")
    testImplementation("org.testcontainers:postgresql")
}

컨테이너를 직접 생성하는 테스트 설정 클래스를 만들 필요가 없다.
지금처럼 PostgreSQL 하나만 필요한 상황에서는 가장 단순하다.

@ActiveProfiles("test") 추가하기

놓치기 쉬운 부분이 있다.

application-test.yml에 Testcontainers datasource를 잡아도, 테스트가 test profile로 실행되지 않으면 해당 설정을 읽지 않는다.

그래서 Repository 테스트나 통합 테스트에 profile을 명시했다.

@DataJpaTest
@ActiveProfiles("test")
class UserRepositoryTest {
    // ...
}

통합 테스트도 마찬가지다.

@SpringBootTest
@ActiveProfiles("test")
class HealthControllerTests {
    // ...
}

그리고 @DataJpaTest 같은 slice test에서는 Spring Boot가 datasource를 임베디드 DB로 바꾸려고 할 수 있다.
그래서 다음 설정도 같이 둔다.

spring:
  test:
    database:
      replace: none

이 설정이 없으면 열심히 Testcontainers datasource를 잡아놓고도 테스트에서는 다른 DB를 볼 수 있다.

@ServiceConnection

Spring Boot에서는 @ServiceConnection으로 Testcontainers 연결 정보를 자동 등록할 수도 있다.

@TestConfiguration(proxyBeanMethods = false)
class TestcontainersConfig {

    @Bean
    @ServiceConnection
    fun postgresContainer(): PostgreSQLContainer<*> =
        PostgreSQLContainer("postgres:16")
}

이 방식은 컨테이너를 코드로 직접 다룬다.
그래서 다음 상황에서는 JDBC URL보다 더 낫다.

• PostgreSQL 외에 Redis, Kafka 같은 컨테이너가 추가된다.
• 컨테이너 옵션을 코드로 제어해야 한다.
• datasource 외의 연결 정보도 함께 등록해야 한다.
• 테스트별 컨테이너 생명주기를 명확하게 관리해야 한다.

즉 이번 선택 기준은 이렇게 잡았다.

@ServiceConnection을 쓰기 어려운 경우에는 @DynamicPropertySource로 직접 datasource property를 넣을 수도 있다.

@Testcontainers
@SpringBootTest
class UserIntegrationTest {

    companion object {
        @Container
        val postgres = PostgreSQLContainer("postgres:16")

        @JvmStatic
        @DynamicPropertySource
        fun properties(registry: DynamicPropertyRegistry) {
            registry.add("spring.datasource.url", postgres::getJdbcUrl)
            registry.add("spring.datasource.username", postgres::getUsername)
            registry.add("spring.datasource.password", postgres::getPassword)
        }
    }
}

트레이드오프

Testcontainers를 쓰면 분명 H2보다 느리다.

첫 실행 때는 Docker 이미지 pull이 필요할 수 있고, 컨테이너 기동 시간도 있다.
또 로컬이나 CI에 Docker가 없으면 테스트가 돌지 않는다.

하지만 DB 통합 테스트의 목적이 운영 DB와의 정합성 검증이라면 이 비용은 낼 만하다.

정리하면 이렇다.

CI에서는?

GitHub Actions의 ubuntu-latest runner는 Docker를 사용할 수 있다.
그래서 일반적인 Testcontainers 기반 테스트는 별도의 PostgreSQL service를 workflow에 띄우지 않아도 동작한다.

물론 Docker가 필요한 테스트가 된다는 점은 명확히 해야 한다.
로컬 개발자 환경이나 CI runner가 Docker를 지원하지 않으면 테스트가 실패한다.

정리

• 운영이 PostgreSQL이면 DB 통합 테스트도 PostgreSQL에서 돌리는 편이 낫다.
• H2 PostgreSQL mode는 PostgreSQL과 같지 않다.
• jdbc:tc:postgresql:16:///testdb는 단일 DB 컨테이너 테스트에 가장 가볍다.
• @DataJpaTest에서는 spring.test.database.replace: none을 확인해야 한다.
• application-test.yml을 쓰려면 @ActiveProfiles("test")가 필요하다.
• Redis, Kafka 등 컨테이너가 늘어나면 @ServiceConnection이나 @DynamicPropertySource로 넘어가는 게 낫다.

테스트 속도만 보면 H2가 더 좋다.
하지만 운영에서 깨질 가능성을 줄이는 테스트라면, 조금 느려도 실제 DB에서 검증하는 쪽이 더 낫다고 판단해서 도입하게 되었다.

출처

https://java.testcontainers.org/modules/databases/jdbc/ https://java.testcontainers.org/modules/databases/postgres/ https://docs.spring.io/spring-boot/reference/testing/testcontainers.html https://docs.spring.io/spring-boot/api/java/org/springframework/boot/test/autoconfigure/jdbc/AutoConfigureTestDatabase.Replace.html

PageRequest.of(0, size)를 쓰면 offset이 0이니까 cursor 기반 조회에서 사실상 limit size처럼 동작하는 것 아닌가?
그럼 Limit.of(size)랑 뭐가 다른가?
또 Slice는 hasNext()가 있으니까 cursor pagination처럼 써도 되는 걸까?

정리해보니 핵심은 이거였다.

Page, Slice, PageRequest는 Spring Data의 페이징 추상화이고, cursor pagination은 조회 전략이다.

PageRequest에 대해 살펴보기

PageRequest는 Pageable의 구현체다.

구조를 단순화하면 다음과 같다.

AbstractPageRequest
  - int page
  - int size

PageRequest
  - Sort sort

즉 PageRequest는 사실상 다음 세 가지를 가진다.

page + size + sort

여기서 중요한 점은 offset을 필드로 저장하지 않는다는 것이다.
offset은 필요할 때 계산된다.

val request = PageRequest.of(2, 500)

request.pageNumber // 2
request.pageSize   // 500
request.offset     // 1000

계산식은 단순하다.

offset = page * size

그래서 다음 요청은:

PageRequest.of(2, 500)

SQL로 보면 대략 이런 의미가 된다.

limit 500 offset 1000

PageRequest.of(0, size)는 Limit.of(size)와 같을까?

완전히 같지는 않다.

PageRequest.of(0, size)
Limit.of(size)

둘 다 "size개만 가져온다"는 결과만 보면 비슷할 수 있다.
하지만 표현하는 정보가 다르다.

PageRequest는 다음 정보를 가진다.

• page number
• page size
• offset
• sort
• 다음/이전 페이지 요청 생성 메서드

반면 Limit은 말 그대로 개수 제한만 표현한다.

그래서 cursor 기반 조회에서 PageRequest.of(0, size)를 쓰면 offset은 항상 0이다.
이동은 offset이 아니라 cursor 조건이 담당한다.

fun findNextUsers(lastUserId: Long?, pageable: Pageable): List<User> {
    return queryFactory
        .selectFrom(user)
        .where(
            lastUserId?.let { user.id.gt(it) }
        )
        .orderBy(user.id.asc())
        .offset(pageable.offset)
        .limit(pageable.pageSize.toLong())
        .fetch()
}

findNextUsers(
    lastUserId = 1000L,
    pageable = PageRequest.of(0, 100),
)

이 경우 offset은 0이고, 실제 다음 페이지 이동은 id > 1000 조건이 담당한다.

다만 개인적으로는 cursor 조회라면 PageRequest보다 명시적인 size, Limit, 또는 CursorRequest 같은 타입이 더 읽기 좋다고 생각한다.
PageRequest라는 이름 자체가 offset 기반 페이지를 떠올리게 만들기 때문이다.

Page와 Slice 차이

Spring Data에서 Page와 Slice는 비슷해 보이지만 목적이 다르다.

Page

Page는 현재 페이지 데이터뿐 아니라 전체 개수와 전체 페이지 수를 알고 있다.

val page: Page<User> = userRepository.findAll(PageRequest.of(0, 20))

page.content
page.totalElements
page.totalPages
page.hasNext()

여기서 헷갈렸던 부분이 있다.

Page도 hasNext()를 가지고 있을까?

정답은 가지고 있다.

Page는 Slice를 상속하기 때문에 hasNext()를 사용할 수 있다.

다만 Page는 전체 개수와 전체 페이지 수를 알기 위해 count query가 추가로 실행될 수 있다.
그래서 전체 개수가 필요 없는 상황이라면 굳이 Page를 쓸 필요가 없다.

Slice

Slice는 전체 개수는 모른다.

대신 다음 slice가 있는지만 알 수 있다.

val slice: Slice<User> = userRepository.findByActiveTrue(PageRequest.of(0, 20))

slice.content
slice.hasNext()
slice.number
slice.size

그래서 다음 같은 상황에 적합하다.

• 무한 스크롤
• 더보기 버튼
• 전체 페이지 수가 필요 없는 목록
• count query 비용을 줄이고 싶은 경우

Slice는 cursor pagination이 아니다

여기서 중요한 점이 있다.

Slice는 반환 타입이다.
cursor pagination은 조회 방식이다.

다음 코드는 Slice를 반환하지만 cursor pagination은 아니다.

fun findByActiveTrue(pageable: Pageable): Slice<User>

val first = repository.findByActiveTrue(PageRequest.of(0, 100))
val second = repository.findByActiveTrue(first.nextPageable())

first.nextPageable()을 쓰면 다음 요청은 page가 1이 된다.

page = 1
size = 100
offset = 100

즉 여전히 offset 기반이다.

cursor pagination은 마지막으로 읽은 값을 다음 조회 조건으로 넘겨야 한다.

fun findNextUsers(lastUserId: Long?, size: Int): List<User> {
    return queryFactory
        .selectFrom(user)
        .where(
            lastUserId?.let { user.id.gt(it) }
        )
        .orderBy(user.id.asc())
        .limit(size.toLong() + 1)
        .fetch()
}

보통은 size + 1개를 조회해서 다음 데이터가 있는지 판단한다.

data class CursorPage<T>(
    val items: List<T>,
    val nextCursor: Long?,
    val hasNext: Boolean,
)

fun toCursorPage(rows: List<User>, size: Int): CursorPage<User> {
    val hasNext = rows.size > size
    val items = rows.take(size)

    return CursorPage(
        items = items,
        nextCursor = if (hasNext) items.lastOrNull()?.id else null,
        hasNext = hasNext,
    )
}

삭제가 섞이면 offset은 위험하다

offset 기반 pagination이 특히 위험한 상황은 조회하면서 데이터를 삭제하거나 상태를 바꾸는 경우다.

예를 들어 FCM 토큰 발송 실패 데이터를 조회해서 삭제한다고 해보자.

처음 데이터: [1, 2, 3, 4, 5, 6]
page=0, size=2 조회: [1, 2]
처리 후 1, 2 삭제
남은 데이터: [3, 4, 5, 6]
page=1, size=2 조회: offset 2부터 조회 -> [5, 6]

이러면 [3, 4]를 건너뛰게 된다.

이런 경우에는 page나 slice보다 cursor 기반 조회가 낫다.

var cursor: Long? = null

while (true) {
    val rows = tokenRepository.findFailedTokensAfter(
        lastId = cursor,
        limit = batchSize + 1,
    )

    val hasNext = rows.size > batchSize
    val targets = rows.take(batchSize)

    if (targets.isEmpty()) break

    tokenRepository.deleteAll(targets)
    cursor = targets.last().id

    if (!hasNext) break
}

핵심은 다음 페이지를 몇 개 건너뛸지로 찾지 않는다는 것이다.
마지막으로 처리한 id 이후를 찾는다. 이렇게 되면 중간에 삭제되더라도 offset이 밀리지 않는다.

상황에 따른 정리

마지막으로 다시 정리하면,

• Page도 hasNext()를 가진다.
• Page는 전체 개수 계산을 위해 count query가 붙을 수 있다.
• Slice는 전체 개수를 모르고 다음 slice 존재 여부만 안다.
• Slice를 쓴다고 cursor pagination이 되는 것은 아니다.
• PageRequest.of(0, size)는 cursor 조건과 함께 쓰면 offset 0이라 limit처럼 동작할 수 있다.
• 하지만 cursor 의도를 명확히 하려면 별도 CursorRequest, Limit, size 파라미터를 고려하는 게 좋다.

결국 중요한 건 반환 타입 이름이 아니라 조회 방식이다.
데이터가 중간에 바뀔 수 있는지, 전체 개수가 필요한지, 다음 페이지 판단만 필요한지를 보고 선택해야 한다.

User마다 한개씩만 생성되어야 하는 엔티티들이 있다. 기존에는 기본키를 따로 두고 user를 FK로 두는 방식으로 진행했다.

그렇지만 기본키를 많이 안쓰고 findByUserId 식의 메서드를 많이 사용한다면 컬럼 낭비라고 생각하여 전략을 변경해보게 되었다.

전략

기존 방식은 다음과 같다.

@OneToOne + id + user_id

  @Entity
  @Table(name = "user_notification_settings")
  class UserNotificationSetting(

      // 자체 PK
      @Id
      @GeneratedValue(strategy = GenerationType.IDENTITY)
      @Column(name = "notification_setting_id")
      val id: Long? = null,                           

      // user FK
      @OneToOne(fetch = FetchType.LAZY, optional = false)
      @JoinColumn(name = "user_id", nullable = false, unique = true)
      @OnDelete(action = OnDeleteAction.CASCADE)
      val user: User,                                

      // ...
  )

• user_id를 unique 제약 조건으로 두면서도 불필요한 notification_setting_id가 존재하는 방식이다.

@MapsId를 사용해서 개선하고자 한다.

MapsId

• 부모 엔티티의 PK를 자식 엔티티의 PK로 공유하는 패턴이다.
• 즉 별도의 id 컬럼을 생성하지 않고 외래 키가 곧 기본키가 된다.

부모 - User

  @Entity
  @Table(name = "users")
  class User(
      @Id
      @GeneratedValue(strategy = GenerationType.IDENTITY)
      @Column(name = "user_id")
      val id: Long? = null,
      // ...
  )

자식 - UserNotificationSetting

• 신규 저장 시 DB가 user_id를 자동 생성한다.
• user에서 가져온 PK를 @Id 필드에서 자동으로 채우는 방식이다.
• DB 레벨에서 User 삭제 시 해당 엔티티도 자동 삭제된다.

  @Entity
  @Table(name = "user_notification_settings")
  class UserNotificationSetting(

      // 
      @MapsId
      @OneToOne(fetch = FetchType.LAZY, optional = false)
      @JoinColumn(name = "user_id", nullable = false)
      @OnDelete(action = OnDeleteAction.CASCADE)
      val user: User,

      @Id
      @Column(name = "user_id")
      val userId: Long? = null,                        

      // ...
  )

저장 방법은 다음과 같다.

  // UserAccountRegistrar.kt
  // user를 먼저 저장
  val user = userRepository.save(buildUser())   
  // MapsId가 user.id를 읽어서 user_notification_settings.user_id에 자동 세팅 
  notificationSettingRepository.save(
      UserNotificationSetting(user = user)            
  )
  // @MapsId가 user.id를 읽어서 user_notification_settings.user_id에
  자동 세팅

• user의 자식이기 때문에 user가 null인 상태에서는 절대 저장할 수 없다.

결론적으로 @MapsId 방식에서는 컬럼이 하나다. user_id가 PK면서 동시에 FK이기 때문이다.

일대일 매핑을 할 때 무지성 중간테이블 기본키 + 외래키 해서 추가 컬럼을 만들기보다는 이런 식으로 하면 컬럼 낭비를 줄일 수 있을 것 같다.

자바 스프링 -> 코틀린 스프링으로 갈아타면서, Slf4j을 당연하게 사용했는데 코틀린은 롬북을 잘 사용하지 않기도 하고, 이참에 다른 로거와의 성능을 비교해서 써보자 하고 다른 로그 작성 방법을 찾아보게 되었다.

로거 종류

SLF4J 기본 parameterized

• 로그 수준에 따라서 로그가 남겨진다. 즉 logger.info, logger.debug로 지정하면 레벨에 따라 표시 여부가 졀정된다.
• 문제점은 로그가 현재 로그 수준에 해당하지 않으면 남겨지지 않는데, 로그에서 호출하는 객체의 메서드는 그대로 호출된다.
• 즉 비용이 있는 메서드면 쓸데없는 성능 저하로 이어진다.
• String 결합만 막힐 뿐, 인자 평가 자체는 막지 못한다 → 불완전한 Lazy
• Object, 비싼 메서드는 실행이 되긴 한다는 것

해결..?

• 람다를 사용하면 로그 수준 조건문을 사용하지 않아도 성능 영향 없이 가능하다. -> but Object 가변인자만 받을 수 있고, 람다를 사용할 방법은 없다.. 결국 조건문 사용해야한다.

해결 시도 1 - 조건문

  if (logger.isDebugEnabled()) {

  if (logger.isDebugEnabled()) {
      logger.debug("{}", foo.veryExpensiveMethod());
  }

-> 문장마다 매번 체크 붙여줘야 해서 귀찮다..

SLF4J Supplier (2.0+)

logger.debug("{}", () -> foo.veryExpensiveMethod());

• 이렇게 하면 인자를 람다로 감싸게 됨, 조건문에 걸려야 실행된다.
• 그렇지만 인자를 람다로 감싸야 진짜 Lazy 방법이다.
• 그런데 인자를 감싸면 인자가 많을수록 람다도 여러 개 필요해서 아주 번거롭다.

Kotlin-logging

사용 방법

 logger.debug { "${foo.veryExpensiveMethod()}" }

• 위의 문제 해결하려면 인자마다 람다로 감싸야 하는데, 코틀린에서는 함수 자체가 람다를 인자로 받는 구조라서 해결된다.
• {} 안의 코드 전체가 하나의 람다 블록이다. 함수 호출을 포함한 문자열 생성 자체가 람다 안에 있어서, debug 레벨이 활성화됐을 때만 블록 전체가 실행된다. 내부적으로 if (isDebugEnabled) logger.debug(msg().toString()) 으로 동작한다.

결론

Kotlin-logging은 조건문과 SLF4J Supplier와 동일한 효과를 가지면서, 매번 조건문을 쓰지 않아도 되고 인자마다 람다를 감싸지 않아도 된다.

Android - Jetpack Compose 에서 Lazy 레이아웃 사용하기

개념정리

RecyclerView vs Lazy 레이아웃의 차이

RecyclerView는 기존 View 방식

• RecyclerView, Adapter, ViewHolder, 각 항목의 레이아웃 XML이 필요하다.
• 즉 XML파일, 코틀린 파일 분리해서 관리해야 한다.

Lazy 레이아웃

• LazyColumn, LazyRow로 전부 대체 가능
• Compose에서는 화면에 보이는 영역에 보이는 아이템만 컴포즈하고 배치
• 스크롤로 화면 밖을 벗어난 아이템은 컴포지션에서 제거됨
  • Lazy 레이아웃은 컴포즈의 컴포지션 단계를 제어함
    • 컴포지션(Composition) → 레이아웃(Layout) → 그리기(Drawing)
  • 일반 컬럼에서는 화면 밖이더라도 컴포즈됨
  • LazyColumn은 화면 밖에 있다면 컴포지션 트리에 존재하지 않음
  • 즉 스크롤할 때 화면 밖으로 나가면 컴포지션에서도 제거되며, onDispose 호출 + remember로 들고 있던 상태도 사라짐
  • 스크롤하면서 새로 화면에 보이게된 요소는 새로 컴포즈될 때 상태가 초기화됨
• 즉 화면에 보이지 않는 아이템은 컴포지션 트리에서도 존재하지 않기 때문에, 메모리나 CPU 낭비가 없다.
• Key를 통한 아이템 재배치
  • Key가 없다면 위치 기반으로 상태를 추적한다. 이렇게되면 아이템 순서가 바뀔 수 있기 때문에, id 기반으로 상태를 추적해서 순서가 변경된다면 key에 따라서 재배치되어 정확성이 보장됨

LazyColumn / LazyRow의 기본 사용법 숙지

LazyColumn

• 아이템을 수직으로 배치해서 세로 스크롤을 지원

  LazyColumn {
    item { Text("헤더") }
    items(5) { index -> Text("Item $index") }
    item { Text("푸터") }
  }

LazyRow

• 아이템 수평으로 배치해서 가로 스크롤 지원

  LazyRow {
    items(photos) { photo -> PhotoCard(photo) }
  }

• 대부분의 Compose 레이아웃은 @Composable 콘텐츠 블록을 직접 받지만, Lazy 컴포넌트는 LazyListScope.() DSL 블록을 받음
• 레이아웃과 스크롤 위치에 따라 필요한 아이템을 알아서 추가

옵션

Content Padding — 콘텐츠 가장자리 여백

• LazyColumn 자체가 아닌 아이템들에 패딩이 적용됨
• Modifier.padding()으로 직접 붙이면 컴포저블 자체에 여백이 생김
• contentPadding은 스크롤 가능한 콘텐츠 영역에 여백 추가

  LazyColumn(
    contentPadding = PaddingValues(horizontal = 16.dp, vertical = 8.dp),
  ) { /* ... */ }

Content Spacing — 아이템 간격

• Arrangement.spacedBy() 사용
• 아이템 사이에 간격을 줌

LazyColumn(verticalArrangement = Arrangement.spacedBy(4.dp)) { /* ... */ }
LazyRow(horizontalArrangement = Arrangement.spacedBy(4.dp)) { /* ... */ }

LazyListScope DSL의 다양한 함수 활용

• 레이아웃 내에 아이템 관련 다양한 함수 제공

• item(){} : 단일 아이템

• item(count){} : 개수로 아이템 추가

• item(list): 컬렉션으로 아이템 추가

• itemIndexed(): 인덱스로 아이템 추가, 아이템의 순서가 필요할 때 사용

• contentType: 성능 최적화, 다양한 타입 아이템이 혼재할 때 지정하면 컴포즈가 동일 타입끼리만 컴포즈 재사용해서 성능을 높일 수 있음

LazyVerticalGrid / LazyHorizontalGrid 그리드 레이아웃 이해

• 아이템을 그리드 형태로 표시할 때 사용

GridCells.Adaptive — 최소 너비로 열 수 자동 결정

• 화면 너비에 따라 열 수가 자동으로 결정됨

• 다양한 화면 크기를 설정할 수 있음

    LazyVerticalGrid(
    columns = GridCells.Adaptive(minSize = 128.dp)
    ) {
        items(photos) { photo -> PhotoItem(photo) }
    }

GridCells.Fixed — 고정 열 수

LazyVerticalGrid(
    columns = GridCells.Fixed(2),
    verticalArrangement = Arrangement.spacedBy(16.dp),
    horizontalArrangement = Arrangement.spacedBy(16.dp)
) {
    items(photos) { item -> PhotoItem(item) }
}

GridItemSpan - 특정 아이템에 커스텀 span 적용

• 특정 아이템이 여러 열을 차지하게 할 때 span 파라미터를 활용
• 아이템이 몇 칸을 차지할지 span 파라미터로 지정
• maxLineSpan은 현재 행의 전체 컬럼 수 -> 한 행을 통째로 점유 가능

LazyVerticalGrid(columns = GridCells.Adaptive(minSize = 30.dp)) {
    item(span = { GridItemSpan(maxLineSpan) }) {
        CategoryCard("Fruits")  // 전체 행을 차지
    }
    items(items) { item -> ItemCard(item) }
}

LazyVerticalStaggeredGrid

• 각 아이템의 높이 또는 너비가 다를 수 있는 그리드
• 핀터레스트처럼 불규칙한 높이를 가진 그리드를 생성
• 벽돌을 쌓듯이 빈 공간을 채움
• 짧은 컬럼에 다음 아이템을 채우는 방식

columns = StaggeredGridCells.Adaptive(200.dp)

• 각 컬럼이 최소 200dp가 되도록 화면 너비에 따라 컬럼 수 자동 결정
• 고정하고 싶으면 StaggeredGridCells.Fixed(2)처럼 개수 지정

verticalItemSpacing = 4.dp

• 세로 방향 아이템 간 간격
• 같은 컬럼 내 위/아래 아이템 사이 여백

horizontalArrangement = Arrangement.spacedBy(4.dp)

• 가로 방향 컬럼 간 간격

아이템 블록

modifier = Modifier.fillMaxWidth().wrapContentHeight()

• fillMaxWidth(): 컬럼 너비를 꽉 채움
• wrapContentHeight(): 이미지 원본 비율에 맞춰 높이 결정, staggered 효과가 생김

아이템 Key, 애니메이션, Sticky Header 등 심화 기능 활용

아이템 Key

• 각 아이템의 상태는 리스트에서 아이템의 위치를 키로 사용해서, 데이터가 변경되면 위치가 바뀐 아이템은 상태를 잃을 수 있음
• 아이템에서 Key를 사용하면, 아이템 위치가 변경되더라도 컴포즈가 상태(remember한 값 등)를 아이템과 함께 이동시킴

LazyColumn {
    items(
        items = messages,
        key = { message -> message.id }  // key 사용
    ) { message ->
        MessageRow(message)
    }
}

아이템 변경 애니메이션

• animateItem() modifier를 사용하면 아이템 추가·삭제·이동 시 애니메이션을 자동으로 적용할 수 있음, Key와 함게 사용해야 효과적

    LazyColumn {
        items(messages, key = { it.id }) { message ->
            MessageRow(
                message,
                modifier = Modifier.animateItem()
            )
        }
    }

Sticky Header — 고정 헤더

• 그룹화된 데이터를 표시할 때 유용함
• stickyHeader()를 사용

단일 헤더

@Composable
fun ListWithHeader(items: List<Item>) {
    LazyColumn {
        stickyHeader { Header() }
        items(items) { item -> ItemRow(item) }
    }
}

여러 헤더 (이름 첫 글자별 그룹)

• groupBy: 리스트를 어떤 기준으로 묶어서 Map으로 만들어 줌
• Key는 첫글자, value는 첫글자로 시작하는 연락처 목록 -> Map으로 선언
• 그룹별로 선언하고, CharacterHeader로 해당 그룹의 헤더를 그림, 스크롤해도 상단에 붙어있게 할 수 있음

// 그룹핑은 ViewModel에서 처리하는 것을 권장
val grouped = contacts.groupBy { it.firstName[0] }

@Composable
fun ContactsList(grouped: Map<Char, List<Contact>>) {
    LazyColumn {
        grouped.forEach { (initial, contactsForInitial) ->
            stickyHeader { CharacterHeader(initial) }
            items(contactsForInitial) { contact -> ContactListItem(contact) }
        }
    }
}

주의 - 같은 방향 스크롤 중첩 금지

• 크기가 정해지지 않은 LazyColumn을 세로 스크롤 Column 안에 중첩하면 IllegalStateException이 발생
• 방향이 다른 경우 허용: 가로 스크롤 Row 안에 세로 LazyColumn 은 가능

주의 - 하나의 item 블록에 여러 요소 넣지 않기

• 하나의 item { } 블록에 여러 컴포저블을 넣으면 하나의 단위로 취급되어 성능이 안좋아짐
• Divider는 이전 아이템과 같은 블록에 넣어도 됨

스크롤 상태 제어 (LazyListState) 이해

• LazyListState: LazyColumn, Row의 현재 상태를 담고 있는 객체 - 스크롤, 아이템
• state 파라미터에 상태를 넘겨주면 , 상태를 통해 리스트를 조회하거나 조작할 수 있음
• 리스트의 스크롤 상태를 읽거나 제어하고 싶을 때 사용

@Composable
fun MessageList(messages: List<Message>) {
    val listState = rememberLazyListState()
    val coroutineScope = rememberCoroutineScope()

    LazyColumn(state = listState) { /* ... */ }

    ScrollToTopButton(
        onClick = {
            coroutineScope.launch {
                listState.animateScrollToItem(index = 0)  // 부드럽게 상단으로
            }
        }
    )
}

• scrollToItem()과 animateScrollToItem() 모두 suspend 함수이므로 반드시 코루틴 내에서 호출해야 함
• 코루틴으로 해야하는 이유: 부드럽게 스크롤을 하는 함수인데 시간이 걸리는 작업이라서, 코루틴을 시작하고 그 안에서 호출 가능
• rememberCoroutineScope() : 해당 컴포저블이 살아있는 동안 사용하는 코루틴

derivedStateOf 최적화

• firstVisibleItemIndex는 스크롤하면 계속 바뀌는 값인데, 컴포즈에서 State값이 바뀌면 그걸 읽는 컴포저블은 리컴포지션되어 다시 그러짐

• 즉 인덱스가 바뀔 때마다 매번 화면을 다시 그림, 결과가 똑같으면 매번 다시 그릴 필요가 없음

• derivedStateOf: 결과값을 감지해서, 변경이 된다고 하면 그때 리컴포지션이 일어남

• 즉 스크롤할때마다 리컴포지션이 발생하지 않고, 값이 실제로 바뀔때만 된다~

• 스크롤 이벤트는 매우 빈번하게 발생하므로, firstVisibleItemIndex를 읽을 때는 derivedStateOf로 감싸 결과값이 실제로 변경될 때만 Recomposition이 발생하도록 최적화해야 함

• rememberLazyListState() — LazyListState를 컴포지션에 기억

• rememberCoroutineScope() — 컴포저블 수명에 묶인 코루틴 스코프

• derivedStateOf — 다른 State에서 파생된 State, 변화 감지 최적화

• Arrangement — 아이템 배치 전략 (spacedBy, Center, SpaceBetween 등)

• PaddingValues — contentPadding에 사용하는 패딩 값 래퍼

구현 내용

화면 구성

• 홈: 메인 배너 이미지 + What's new 가로 스크롤 상품 목록
• 구매하기: 탭 바(전체/Tops&T-Shirts/sale) + 2열 상품 그리드, BestSeller 뱃지
• 위시리스트: 좋아요한 상품만 필터링해서 표시, 비어있을 때 빈 상태 처리
• 상품 상세: 이미지, 상품 정보, 뒤로가기

아키텍처

• Route/Screen 분리: Route에서 ViewModel 연결 및 상태 관리, Screen은 UI만 담당
• Hilt: ViewModel 의존성 주입
• UiState: 각 화면마다 sealed class로 상태 관리

네비게이션

• @Serializable data object/class 기반 타입 안전 네비게이션
• navigation<MainGraph>로 중첩 그래프 구성
• 하단 탭 바: 현재 route 기반으로 선택 탭 자동 반영

기타

• Coil: AsyncImage로 네트워크 이미지 로딩
• BackHandler: 홈 화면에서 2초 내 두 번 뒤로가기 시 앱 종료
• Mock 데이터: 실제 API 연동 전 Mock 데이터로 UI 검증
• Desgin System: 자주 사용하는 Color, text style을 디자인 시스템 패키지로 분리

트러블 슈팅

1 . Navigation Graph Scope 방식으로 변경해서 ViewModel 공유

문제

좋아요 뷰모델을 만들어서 여러 화면에서 사용하려고 했는데, 이러면 Main에 등록해야 하는데, 공식문서를 찾아보니까 좋은 방식이 아니었다.

• MainScreen → AppNavHost → 각 Route로 계속 파라미터 전달해야 함
• ViewModel 생명주기가 Activity 전체에 묶임 (앱 켜있는 내내 살아있음)
• 공식 Android에서 권장하지 않는 방향..

해결

Navigation Graph Scope 방식으로 변경, hiltViewModel로 같은 NavGraph 안에서 동일한 인스턴스를 공유하도록 해서 좋아요 상태가 공유되도록 설정했다.

val parentEntry = remember(backStackEntry) {
    navController.getBackStackEntry<MainGraph>()
}
val favoriteViewModel: FavoriteViewModel = hiltViewModel(parentEntry)

• 좋아요 클릭 -> FavoirteViewModel.toggleLike(id) 호출
• Wish 화면에서 likedProductsIds를 받아오므로, 변경 감지해서 해당 상품 표시되도록
• 같은 그래프 내부이므로 뷰모델이 같은 인스턴스라서 상태가 공유된다.
• MainGraph를 벗어나면 ViewModel도 자동 소멸하는 방식이다.

2. ## 상세 페이지 진입 시 하단 탭 구매하기 유지

• 상품 상세 페이지로 이동하면 하단 탭이 아무것도 선택되지 않은 상태가 되어버린다.
• this?.hasRoute<PurchaseDetail>() == true -> BottomNavItem.PURCHASE
• 이렇게 하면 상세보기의 경우에도 구매하기 탭 선택된 상태로 매핑된다.

this?.hasRoute<PurchaseDetail>() == true -> BottomNavItem.PURCHASE

3. AsyncImage 큰 사이즈 적용 안됨

Box 안에서 이미지를 사용하는 방식으로 구현했는데, AsyncImage에서 직접 사이즈 지정했는데 적용이 안되었다. . Box에서 사이즈 고정, 이미지에서 max로 채우도록 변경했다.

Box(  
    modifier = Modifier  
        .size(314.dp)  
        .background(Color(0xFFF5F5F5))  
        .aspectRatio(1f)  
) {  
    AsyncImage(  
        model = item.productImage,  
        contentDescription = item.name,  
        modifier = Modifier.fillMaxSize(),  
        contentScale = ContentScale.Crop  
    )  
}

4. TabBar 언더라인이 화면 전체를 채움 / Text기준으로 채워지지도 않음

문제

탭을 왼쪽 정렬하려고 weight(1f)를 제거했더니 선택된 탭의 언더라인이 화면 전체 너비를 채워버렸다 ...

원인

weight(1f) 제거 후에 Column에 너비 제약이 없어지면서 내부 fillMaxWidth()가 부모의 max constraint을 그대로 사용해버렸다.

해결

• Row: fillMaxWidth() + weight(1f) 제거 → 탭이 왼쪽부터 붙음, padding(start = 9.dp) 은 유지
• Column: Modifier.width(IntrinsicSize.Max)로 Column을 텍스트 너비로 고정해 해결,
  horizontal 패딩은 Column에서 Text로 이동해 언더라인이 탭 전체 너비를 정확히 채우도록 수정함

안드로이드,스프링에서 코틀린을 많이 사용하게 되었는데, 자바랑 비슷한 것 같다가도 너무 다른 것 같은데 지식 없이 사용하자니 어떤 실수를 하는지도 모르는 것 같아서 빠르게 기초를 공부하고자 한다.

변수

• var, val이 있는데 val을 주로 사용한다. final 같은 느낌이다.

• 객체는 new 없이 생성 가능하다.

Null

• Safe Call: null이 아닌 경우에만 호출한다. ?.로 호출하면 null이면 null을 반환한다.

• Not-null assertion: null이 절대 아니라면 !!로 단언 가능하다. null이라면 NPE를 던진다.

• 엘비스 연산자: ?:는 null이라면 이 값으로 정의한다. 즉 null일 때만 호출된다.

• ****?.let { }****: null이 아닐 때만 블록을 실행한다.

• 플랫폼 타입: 코틀린이 null 관련 정보를 알 수 없는 타입은 exception이 날 수 있다. 자바 코드 사용 시 유의한다.

• null 검사를 한 번 하면 non-null임을 컴파일러가 알 수 있다.

Type

기본 타입

• 기본값을 보고 타입을 추론한다. L이 붙으면 Long, f가 붙으면 Float이다.

• 코틀린에서 타입 변환은 명시적으로 이루어져야 한다. 자바는 암시적으로 큰 타입으로 자동 변형되지만, 코틀린은 타입이 안 맞으면 에러가 난다. to변환타입()을 반드시 사용한다.

• 결과를 타입 변환할 때 자바는 괄호를 사용하지만, 코틀린은 결과.to변환타입()으로 한다.

• 변수가 nullable이면 적절한 처리가 필요하다.

타입 캐스팅

• instanceOf 대신 is로 해당 타입인지 true/false를 반환한다.

• value as Type: 괄호 대신 as로 타입 캐스팅한다. 타입이 아니면 예외를 던진다.

• value as? Type: value가 해당 타입이 아니거나 null이면 null을 반환한다. 안전한 타입 형변환 방법이다.

• 스마트 캐스트: is를 통과했다면 as를 생략하고 바로 해당 타입으로 써도 된다. 컴파일러가 이를 기억하기 때문이다.

• !is는 instanceOf의 반대이다.

코틀린의 특이한 타입

• Any

    - Java의 Object 역할로, 모든 객체와 모든 원시타입의 최상위 타입이다.

    - equals, hashCode, toString이 존재한다.

    - Any 자체는 null을 포함하지 못한다. 포함하려면 Any?로 쓴다.

• Unit

    - Java의 void와 동일한 역할을 한다.

    - Unit은 그 자체로 타입 인자로 사용 가능하다. 제네릭 void를 하려면 Void를 써야 하는데, Unit은 그냥 쓰면 된다.

    - 코틀린의 Unit은 실제로 존재하는 타입이다.

• Nothing

    - 함수가 정상적으로 끝나지 않았다는 사실을 표현하는 역할을 한다.

    - 무조건 예외 반환하거나 무한 루프인 함수에 사용한다.

    - 잘 사용하지 않는다.

String interpolation / String indexing

• ${변수}를 사용하면 값이 들어간다.

• 자바에서는 String.format으로 문자열 포맷을 했어야 했다.

• 단일 변수라면 중괄호를 생략할 수도 있다.

• 그런데 변수 이름만 사용하더라도 ${변수}로 쓰는 것이 가독성, 정규식 활용, 통일성 측면에서 좋다.

• 여러 줄에 걸친 문자열 작성 시 """ """.trimIndent()로 한다. 자바에서는 StringBuilder의 append를 써야 했다.

• 문자열에서 특정 문자 가져오기: 자바에서는 charAt을 사용했지만, 코틀린에서는 배열처럼 str[인덱스]로 가져온다.

연산자

• **단항, 산술 연산자: 자바와 완전히 동일하다.

• 비교 연산자와 동등성, 동일성

    - 비교 연산자는 사용법이 완전히 동일하다.

    - 객체에 비교 연산자를 사용하면 compareTo를 자동으로 호출한다. 자바는 무조건 compareTo를 직접 사용했어야 했다.

    - 동등성: 두 객체의 값이 같은지를 본다.

    - 동일성: 객체가 동일한지, 즉 주소가 같은지를 본다.

    - 코틀린에서는 동일성에 ===, 동등성에 ==를 사용한다. == 호출 시 간접적으로 equals를 호출해준다.

    - ==은 값 비교, ===은 주소까지 같은지를 본다.

• 논리 연산자: 자바와 동일하게 lazy 연산을 한다. or 연산 시 앞 내용이 true면 뒤를 수행하지 않고 바로 본문으로 이동하고, and 연산 시 앞 내용이 false면 수행하지 않고 바로 이동한다.

• 코틀린의 특이한 연산자

    - in / !in: 컬렉션이나 범위에 포함되어 있는지/아닌지를 본다.

    - a..b: a부터 b까지의 범위 객체를 생성한다.

    - a[i]: 특정 인덱스 i로 값을 가져온다.

    - a[i] = b: i에 b를 넣는다.

• 연산자 오버로딩

    - 코틀린에서는 객체마다 연산자를 직접 정의할 수 있다.

    - 자바에서는 객체 안 요소에서 연산자를 쓰려면 함수를 만들어야 했다. 코틀린에서도 함수를 정의하면 되지만, 한 번 정의하면 해당 연산자를 그대로 사용 가능하다. 대신 내부적으로 해당 연산의 함수가 호출되며, 연산마다 정해진 이름의 함수여야 한다.

매월 1일에 생성되는 Report에서 OOM 원인을 분석하고, 스프링 배치 도입을 고려한다. OOM은 out of Memory로, 힙 메모리를 더 이상 확보하지 못해서 터지는 상황이다. 다음 코드에서 예상 원인의 흐름을 찾아보면 다음과 같다.

// 유저의 Report를 자동 생성
@Override
@Transactional
public void generateMonthlyReportForAllUsers() {
    YearMonth prevMonth = YearMonth.now().minusMonths(1);
    String month = prevMonth.toString();
    String thumbnailUrl = thumbnailUrlProvider.getUrlForMonth("report", month);
// findAll()로 유저를 한 번에 다 메모리에 올린다
    List<Users> users = userRepository.findAll();
    for (Users user : users) {
        if (reportRepository.existsByUserAndMonth(user, month)) continue;
        // 하나의 긴 트랜잭션 안에서 Report를 계속 생성한다
        Report report = Report.builder()
                .user(user)
                .month(month)
                .thumbnailUrl(thumbnailUrl)
                .build();
        // 영속성 컨텍스트 1차 캐시에 엔티티가 계속 쌓인다
        reportRepository.save(report);
        reportTopLogService.calculateAndSaveTopLogs(user.getId(), report);

        // 커밋 이후에 외부 추천 비동기 실행 (레이스 방지)
        Long rid = report.getReportId();
        TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
            @Override
            public void afterCommit() {
                externalRecommendMaterializer.generateAndStoreExternalAsync(rid);
            }
        });
    }
}

• findAll()로 유저를 한 번에 다 메모리에 올린다
• 하나의 긴 트랜잭션 안에서 Report를 계속 생성한다
• 영속성 컨텍스트 1차 캐시에 엔티티가 계속 쌓인다
• for 루프가 길어질수록 메모리 사용량이 커진다
• 결국 힙을 버티지 못하면 OOM이 난다

해결방안 분석하기

하나의 트랜잭션으로 묶여 있는 로직 안에서 findAll로 유저를 한 번에 다 가지고 오고 있다. 그리고 그 안에서 Report 존재 여부 조회, Report 저장, Report 계산까지 하나에서 다 하고 있다. 이걸 하나의 트랜잭션에서 다 하게 되면 1차 캐시에 Report 엔티티가 다 누적되어 메모리를 잡아먹을 가능성이 높다.

해결 방안은 다음과 같다.

• 유저별로 별도의 트랜잭션으로 분리한다.
• 페이징을 해서 유저를 가져온다. 한 번에 findAll로 가져오면 모든 유저가 한 번에 메모리에 올라가게 된다.
• afterCommit 방식이 너무 옛날 방식이라서 listener 방식으로 구현한다. listener를 생성하고, 외부 추천은 비동기로 Report 저장이 제대로 되었을 때 진행한다.

그런데 Spring Batch가 이 모든 것을 해결해 준다.

Job
 └─ Step: generateReportStep
       Reader: JpaPagingItemReader<Users>     (페이징 자동)
       Processor: User → Report               (existsByUserAndMonth 체크)
       Writer: chunk 단위 저장 + 이벤트 발행

Spring Batch

대량 데이터를 끊어서 안전하게 처리하는 프레임워크다.

• 중간에 실패하게 되면, JobRepository 메타테이블에 자동 기록된다.
• 일반적으로 운영 환경에서 이 테이블을 그라파나 대시보드에 연결하고, 실패 시 알림을 전송한다.

기본 개념 간단 정리

Job: 배치 실행 단위
Step: Job을 구성하는 단계
chunk: 읽기, 처리, 저장 후 커밋하는 묶음 단위
reader: 데이터를 읽는 컴포넌트
processor: 읽은 데이터를 가공하거나 필터링하는 컴포넌트
writer: 처리 결과를 저장하는 컴포넌트

Chunk size 튜닝 방법론

• 기본은 동기 방식으로 청크 1, 2, 3 이런 식의 단일 스레드 순차 방식이다.
• 청크는 적절히 튜닝하는 게 중요하다.
• 청크가 너무 작으면 청크마다 커밋 오버헤드가 발생하고 DB 왕복이 많아진다.
• 청크가 너무 크면 한 청크의 메모리 점유가 커지고, 실패 시 재처리 비용도 커진다.

관련 튜닝 방법들은 다음과 같다.

• 메모리: chunk 안의 아이템이 차지하는 메모리 * chunk size * 스레드 수 < 가용 힙
• 트랜잭션 시간: chunk 처리 시간이 DB 트랜잭션 타임아웃보다 짧아야 한다.
• 재처리 비용: 실패 시 chunk 통째로 다시 처리하므로 너무 크면 손해다.
• JDBC batch size: hibernate.jdbc.batch_size와 chunk size를 맞춰야 효과가 있다. 둘이 다르면 batch insert가 안 된다.
• 외부 시스템 한도: FCM처럼 한 호출에 N개 제한이 있으면 그게 상한이다.

Reader 캐시, 청크에 모이는 것의 차이

• Reader의 내부 캐시에서는 JpaPagingItemReader가 효율을 위해 내부적으로 페이지 단위로 미리 가져온다.
• Reader를 호출할 때는 한 개씩 받는 것처럼 보이고, 처음 호출할 때만 한 번씩 가져오고, 필요 시 1개씩 캐시에서 꺼내서 반환한다.
• 100개까지 Reader 캐싱되도록 설정해놨다고 치면, 101번째에서는 100개씩 가져오는 쿼리를 실행한다.
• Reader 페이지 캐시는 Reader 내부 최적화 방식이고, DB 쿼리를 줄이기 위함이다.

pageSize = 100 설정
  ↓
read() 첫 호출 시 → DB에 "SELECT ... LIMIT 100 OFFSET 0" 쿼리 1번
  → 결과 100개를 Reader 내부 List에 저장 (이게 캐시)
  → 그 중 1개 반환

read() 2번째 호출 → 캐시에서 꺼냄 (쿼리 안 함)
read() 3번째 호출 → 캐시에서 꺼냄
...
read() 101번째 호출 → 캐시 다 떨어짐 → "SELECT ... LIMIT 100 OFFSET 100" 쿼리

• 청크는 Step에서의 처리 단위이고, Writer가 한 번에 받는 묶음이며, 트랜잭션 단위다.
• 청크와 Reader의 pageSize는 다른 개념이고 보통 같게 맞추는 편이다.

Processor

• Processor에서는 Reader가 읽어준 것을 입력으로 받아서 Writer로 넘긴다.
• 즉 유저 조회, 유저와 관련된 Report 저장이 있다고 하면, 유저 조회 결과를 받아서 만들지 말지를 판단한다.
• 조금 더 효율적인 조회가 필요한데, 현재 로직은 유저 조회 → 존재 여부 조회 → 생성 순서로 되어 있다. 이렇게 하면 존재 여부 조회에서 N번 쿼리가 실행되기 때문에, 유저를 조회할 때 존재 여부까지 같이 조회해서 중복되지 않게 Set을 들고 있게 한다.
• 즉 프로세서의 역할은 "만들지 말지" 결정이다. 존재 여부까지 프로세서가 실행하게 된다면 비효율적이기 때문에, Reader에서 이를 같이 처리하도록 한다.

ItemProcessor<Users, Report> processor = user -> {
    // input: Reader가 읽어준 User 한 명

    // 처리 로직
    if (reportRepository.existsByUserAndMonth(user, month)) {
        return null;  // null 반환 = 이 아이템 skip
    }

    Report report = Report.builder()
            .user(user)
            .month(month)
            .thumbnailUrl(thumbnailUrl)
            .build();

    // output: Writer에 넘길 Report 한 개
    return report;
};

Writer

• 청크 단위로 묶어서 동작한다.
• JpaItemWriter에서는 내부적으로 100개를 영속화만 한다.

ItemWriter<Report> writer = chunk -> {
    // chunk = Report 100개가 담긴 묶음
    // 100개를 한 번에 저장
    for (Report report : chunk) {
        entityManager.persist(report);  // 영속화만 함, 아직 DB 안 감
    }
    entityManager.flush();  // 그제서야 한 번에 DB로
};

단일 vs 멀티 차이

단일과 멀티 방식의 차이는 taskExecutor를 주입한다는 것이다. 기본은 단일 스레드로, 청크를 하나씩 차례대로 처리한다.

대부분의 경우 단일 스레드 + chunk size 튜닝으로 충분하다. 멀티스레드는 정말 처리량이 부족할 때만 사용한다.

• chunk를 여러 스레드가 병렬로 처리한다.
• Reader는 thread-safe해야 한다.
• JpaPagingItemReader는 thread-safe가 아니므로, SynchronizedItemStreamReader로 감싸야 한다.

// 단일 (기본)
return new StepBuilder("step", jobRepository)
        .<Users, Report>chunk(100, txManager)
        .reader(reader)
        .processor(processor)
        .writer(writer)
        .build();

// 멀티 (taskExecutor 추가만)
return new StepBuilder("step", jobRepository)
        .<Users, Report>chunk(100, txManager)
        .reader(reader)
        .processor(processor)
        .writer(writer)
        .taskExecutor(taskExecutor)     // taskExecutor를 주입받음
        .build();

FaultTolerant에 대해서

종류는 다음과 같다.

• retry: 같은 아이템 다시 시도한다. 3번까지 같은 방식으로 일시적 네트워크 오류에 유효하다.
• skip: 그 아이템만 건너뛰고 계속 진행한다. 100건까지 같은 방식으로 잘못된 데이터에 유효하다.
• fail: 즉시 Job 실패다.

이걸 적용해보면 다음과 같다. 알림 전송 배치 작업 로직이다.

return new StepBuilder("sendNotificationStep", jobRepository)
        .<Report, Report>chunk(100, txManager)
        .reader(reportReader)
        .writer(fcmWriter)
        .faultTolerant()
        .retry(FcmServerException.class).retryLimit(3)       // FCM 5xx → 3번 재시도
        .skip(InvalidTokenException.class).skipLimit(1000)   // 만료 토큰 → 1000건까지 skip
        .build();

동작은 다음과 같다.

• chunk 처리 중 FcmServerException이 발생하면 같은 chunk를 다시 시도한다. 최대 3번이다.
• 3번 다 실패하면 skip 정책을 확인한다.
• InvalidTokenException이 발생하면 그 아이템을 skip하고 카운터를 1 증가시킨다.
• skip 카운터가 1000을 넘으면 Step이 실패한다.
• 그 외 예외는 즉시 실패한다.

Tasklet

단일 작업을 수행하는 Step의 다른 형태다. 배치에서 일반적인 Reader-Processor-Writer 사이클 없이, 메서드를 하나 실행하고 끝이다.

@Bean
public Tasklet cleanupTasklet() {
    return (contribution, chunkContext) -> {
        log.info("임시 파일 정리 시작");
        fileService.cleanupTempFiles();
        log.info("완료");
        return RepeatStatus.FINISHED;
    };
}

@Bean
public Step cleanupStep(Tasklet cleanupTasklet) {
    return new StepBuilder("cleanupStep", jobRepository)
            .tasklet(cleanupTasklet, txManager)
            .build();
}

용도는 다음과 같다.

• 작업 시작 전 준비: 임시 테이블 truncate, 디렉토리 생성
• 작업 끝난 후 정리: 임시 파일 삭제, 캐시 무효화
• 단일 외부 호출: 이번 달 환율 한 번 가져와서 저장
• 알림 1회: Job 완료됐다고 Slack에 한 번 메시지

다음에는 직접 만들어보려고 한다.

문제 사이트

SQL 게임이 있다고 해서, 특히 추리 게임이라는 게 흥미로워서 풀어봤다. SQLite 기반인데, 자주 사용한 MySQL이랑 유사해서 금방 풀었다.

전체 ERD가 주어지고, 그걸 보고 알아서 sql문을 작성해서 solution 테이블에 insert하고 최종 확인하는 그런 방식이다.

ERD는 다음과 같이 주어진다.

사건 개요

2018년 1월 15일, SQL City에서 살인 사건이 발생했다. 단서는 한 줄도 주어지지 않고, 오직 SQL 쿼리만으로 범인을 추적해야 한다.

Step 1. 범죄 현장 보고서 조회

처음에 주어진게 날짜와 장소밖에 없어서, 먼저 리포트를 조회해보기로 했다.

먼저 crime_scene_report 테이블에서 사건 당일, 해당 도시의 기록을 조회했다.

SELECT description 
FROM crime_scene_report
WHERE city LIKE '%SQL City%'
  AND date = 20180115;

여기서 사건 유형(murder)과 목격자 단서를 확인했다.

CCTV 분석 결과 목격자는 두 명:

• 첫 번째 목격자: Northwestern Dr의 마지막 집 거주자
• 두 번째 목격자: Franklin Ave에 사는 Annabel

Step 2. Annabel의 진술 확보

이름 단서가 있는 Annabel부터. person 테이블에서 ID를 찾고 interview 테이블과 조인했다.

SELECT it.transcript
FROM interview it
JOIN person p ON p.id = it.person_id
WHERE p.name LIKE '%Annabel%';

진술:

I saw the murder happen, and I recognized the killer from my gym when I was working out last week on January the 9th. (살인이 일어나는 걸 봤고, 지난주 1월 9일에 운동하던 헬스장에서 범인을 알아봤어요.)

→ 범인은 Get Fit Now Gym 회원이며, 1월 9일에 헬스장에 있었다.

Step 3. 첫 번째 목격자의 진술

Northwestern Dr의 마지막 집 거주자도 같은 방식으로 인터뷰를 조회했다.

진술:

총소리가 들린 후 한 남자가 뛰쳐나오는 것을 봤다. "Get Fit Now Gym" 가방을 들고 있었고, 가방의 회원 번호는 "48Z"로 시작했다. 골드 회원만 그 가방을 사용한다. 그 남자는 번호판에 "H42W"가 포함된 차에 탔다.

이제 결정적인 단서가 모두 모였다:

Step 4. 범인 특정

세 테이블을 조인해서 조건을 만족하는 사람을 찾았다.

SELECT p.id, p.name
FROM get_fit_now_member gfm
JOIN person p ON gfm.person_id = p.id
JOIN drivers_license d ON p.license_id = d.id
WHERE d.plate_number LIKE '%H42W%'
  AND gfm.membership_status = 'gold';

get_fit_now_member → person → drivers_license로 이어지는 조인 한 번으로 범인이 특정됐다.

더 엄밀하게 가려면 gfm.id LIKE '48Z%' 조건과 get_fit_now_check_in 테이블에서 check_in_date = 20180109 까지 걸어주면 좋다. 단서를 다 활용해야 운에 의존하지 않는다. 그렇지만 이렇게 하고 풀기는 했다.. ^^

이렇게 해서 범인 이름이 나왔다!

음.. 그런데 풀고 나니까 배후가 있단다.

축하합니다, 범인을 찾았네요! 하지만 끝이 아닙니다... 도전할 준비가 됐다면, 범인의 인터뷰 기록을 조회해서 이 범죄의 진짜 흑막을 찾아보세요. SQL 실력에 자신 있다면, 이 마지막 단계를 쿼리 2개 이내로 완료해보세요. 새 용의자로 동일한 INSERT 문을 사용해 정답을 확인할 수 있습니다.

Step 5: 사건의 전말 찾기

일단 범인이 배후를 불었을 테니? 인터뷰 내용을 찾아봤다.

SELECT transcript
FROM interview
WHERE person_id = 67318;

돈 많은 여자한테 고용됐다. 이름은 모르지만 키는 약 5'5"(65인치) ~ 5'7"(67인치), 빨간 머리, 테슬라 모델 S를 몬다. 그 여자가 2017년 12월에 SQL Symphony Concert에 3번 참석했다는 건 안다.

진짜 배후를 특정할 단서는 다음과 같다.

쿼리 1개로 해결하는 방법이 있다.

• 외형 단서(키, 머리색, 성별, 차량)는 person + drivers_license 조인으로 거른다.
• 콘서트 단서는 facebook_event_checkin에서 event_name = 'SQL Symphony Concert'이고 date가 2017년 12월(20171201 ~ 20171231)인 row를 person_id로 GROUP BY해서 COUNT(*) = 3인 사람을 찾는다.
• 수익은 income을 묶어서 order by로 높은 순서로 정렬한다. 돈이 많은 여자이기 때문이다.!
• income은 없는 사람도 있어서, 아니면 진범이 수익 테이블에 안나와 있을 수도 있어서 left 조인으로 했다. 없으면 null로 뜬다.

SELECT p.id, p.name, i.annual_income
FROM person p
JOIN drivers_license d ON p.license_id = d.id
JOIN facebook_event_checkin fec ON fec.person_id = p.id
LEFT JOIN income i ON i.ssn = p.ssn
WHERE d.gender = 'female'
  AND d.hair_color = 'red'
  AND d.car_make = 'Tesla'
  AND d.car_model = 'Model S'
  AND d.height BETWEEN 65 AND 67
  AND fec.event_name = 'SQL Symphony Concert'
  AND fec.date BETWEEN 20171201 AND 20171231
GROUP BY p.id, p.name, i.annual_income
HAVING COUNT(*) = 3
ORDER BY i.annual_income DESC;

이렇게 최종 SQL문을 입력했더니 범인이 딱 나왔다.

흑막까지 맞추니까 축하해줬다.

배운 점 , 후기

• LIKE '%...%'는 텍스트 단서를 다룰 때 강력하다. 부분 일치 하나로 후보를 빠르게 좁힐 수 있다.
• 도메인 모델이 잘 잡혀 있으면 복잡한 조사도 결국 JOIN 몇 번이다. person ↔ membership ↔ license처럼 식별자 중심으로 연결돼 있으면 추적 경로가 한눈에 보인다.
• 음.. SQL 코테 보는 것 같기도 하고, 재밌었다 .. ^^

자바 코드 다음과 같은 자바 코드를 Kotlin으로 전환해 볼 것이다.

@Getter
public class CursorResponse<T, C> {

    private final List<T> items;
    private final C nextCursor;
    private final boolean hasNext;

    public CursorResponse(
            List<T> items,
            C nextCursor,
            boolean hasNext
    ) {
        this.items = items;
        this.nextCursor = nextCursor;
        this.hasNext = hasNext;
    }

    public static <T, C> CursorResponse<T, C> of(
            List<T> items,
            C nextCursor,
            boolean hasNext
    ) {
        return new CursorResponse<>(items, nextCursor, hasNext);
    }
}

방법1 : 일반 클래스로 변환

class CursorResponse<T, C>(
    val items: List<T>,
    val nextCursor: C,
    val hasNext: Boolean,
) {
    companion object {
        fun <T, C> of(
            items: List<T>,
            nextCursor: C,
            hasNext: Boolean,
        ): CursorResponse<T, C> {
            return CursorResponse(items, nextCursor, hasNext)
        }
    }
}

val과 var

private final 필드와 public getter, 생성자 할당을 합친 게 val이다. var로 선언하게 되면 private 필드, public getter/setter 이렇게 생성된다.

companion object

자바의 public static class 대용으로 사용한다고 보면 된다. 클래스 안에 companion object를 두고, 그 안에 메서드를 구현한다. 호출 방식은 자바 static 메서드와 똑같다.

이 방식도 돌아가기는 하지만 코틀린스럽지는 않다. 코틀린 장점을 잘 못 살렸다고 볼 수 있는 코드다.

방법2: 데이터 클래스로 변환

자바에서는 record 클래스 방식이랑 유사하다. 단순 데이터를 담는 Response 이므로 data class가 조금 더 적합하다고 판단했다.

data class CursorResponse<T, C>(
    val items: List<T>,
    val nextCursor: C? = null,
    val hasNext: Boolean = nextCursor != null,
) {
    companion object {
        /**
         * size + 1 만큼 조회된 결과로부터 다음 커서를 추출하여 응답을 만든다.
         * 마지막 항목이 cutoff 역할
         */
        fun <T, C> from(
            items: List<T>,
            pageSize: Int,
            cursorExtractor: (T) -> C,
        ): CursorResponse<T, C> {
            val hasNext = items.size > pageSize
            val pagedItems = if (hasNext) items.take(pageSize) else items
            val nextCursor = if (hasNext) cursorExtractor(pagedItems.last()) else null
            return CursorResponse(pagedItems, nextCursor, hasNext)
        }
    }
}

data class를 생성하면 컴파일러가 자동으로 만들어준다.

• equals() / hashCode() : 필드 기반 비교
• toString() — CursorResponse(items=[...], nextCursor=..., hasNext=true)
• copy() : 일부 필드만 바꿔서 복사 (response.copy(hasNext = false))
• componentN() : 구조 분해 (val (items, cursor, hasNext) = response)

java의 Lombok @Data와 비슷한 역할이다.

정적 팩터리 메서드 생성 불필요

자바에서는 of, create와 같은 정적 팩터리 메서드를 생성하는 방식을 주로 사용한다. new 키워드로 생성하지 않고 기본값을 고정해두기 위해서다. 그런데 코틀린에서는 이게 불필요해서 제거해도 된다.

왜냐.. 코틀린에서는 new 키워드가 없다. 그래서 생성자 호출 자체가 깔끔해지고, 제네릭 추론 자체가 자바보다 더 유연하다. 람다 안에서 하더라도 명시를 딱히 안해줘도 되고, 양방향 추론도 된다. 자바는 거꾸로 쓰면 안된다 ...

코틀린

val list = listOf(1, 2, 3)              // List<Int>로 추론
val map = mapOf("a" to 1, "b" to 2)     // Map<String, Int>로 추론
val pair = "key" to 42                  // Pair<String, Int>로 추론

자바 자바는 List, Map 선언 시 타입 명시가 강제된다.

List<Integer> list = List.of(1, 2, 3);
Map<String, Integer> map = Map.of("a", 1, "b", 2);

이 점 때문에 of가 있었던 것이다. 커서 페이징에서 변환 로직 같은게 아니라면.. 이제 생략해도 될 것 같다.

// 컴파일 에러
var createdAt: LocalDateTime
// "Property must be initialized"

// null로 초기화 (nullable 타입)
var createdAt: LocalDateTime? = null

// lateinit (non-null 타입이지만 나중에 초기화)
lateinit var createdAt: LocalDateTime

자바에서는 LocalDateTime createdAt;이라고 하면 자동으로 null로 초기화돼서 신경 쓸 일이 없다. 근데 Kotlin은 모든 프로퍼티를 명시적으로 초기화해야 컴파일이 된다. 자바에서는 다음과 같이 정의한다. 이렇게 하면 null로 초기화가 되는데 코틀린에서는 자동으로 안된다.

@MappedSuperclass  
@QuerySupertype // QClass 생기지 않도록 설정  
@EntityListeners(AuditingEntityListener::class)  
class BaseEntity {  
    @CreatedDate  
    @JsonFormat(  
        shape = JsonFormat.Shape.STRING,  
        pattern = "yyyy-MM-dd HH:mm:ss",  
        timezone = "Asia/Seoul")  
    var createdAt: LocalDateTime? = null;  

    @LastModifiedDate  
    @JsonFormat(  
        shape = JsonFormat.Shape.STRING,  
        pattern = "yyyy-MM-dd HH:mm:ss",  
        timezone = "Asia/Seoul")  
    var modifiedAt: LocalDateTime? = null;

그렇다면 lateinit이라는 게 있는데 이걸 안 쓰는 이유가 궁금할 것이다.

나중에 초기화를 하는 게 lateinit인데, JPA Auditing에는 부적합하다.

1. lateinit은 non-null 타입에만 가능하다. primitive, nullable 타입에 사용할 수 없다.

   • modifiedAt은 초기에 null이 될 수 있기 때문에

2. 초기화 전 접근 시 예외

   • JPA에서 초기화하기 전에 읽게 되면 UninitializedPropertyAccessException 예외가 터진다. 예를 들어 save() 호출 전에 로그를 찍으면 안된다.

3. 데이터베이스에 null이 들어갈 수도 있는데 어쩌다가.. 이걸 아예 non null로 받으면 터짐

-> 그렇지만 null로 초기화하게 되면 , 웬만하면 createdAt이 있을 텐데도 nullable 체크를 매번 해줘야 하는 번거로움이 있다.

대안

1. 초기값을 now()로 설정
2. protected set으로 외부 변경 차단
   • var로 두게 되면 외부에서도 변경 가능한 public인 셈이다.
   • JPA Auditing이 reflection으로 값을 주입할 수 있으려면 setter가 있어야 하는데 , 외부에서는 변경이 불가능하게 protected set으로 설정한다.
   • 이렇게 하면 같은 패키지와 하위 클래스만 접근이 가능하고, 다른 코드에서는 read only만 가능하다.
   • 참고: protected는 코틀린에서 패키지 무관하게 하위 클래스만 접근 가능하다.

     var createdAt: LocalDateTime = LocalDateTime.now()
     protected set

3. @Prepersist 사용
   • 이 방법은 JpaAuditing을 안쓰고 persist를 직접 해줘야 한다.
   • entityManager.persist(entity) 를 호출하고 실제 SQL insert 실행 사이에 끼어들어서 메서드를 실행한다.
   • Insert 직전에 다시 한번 now로 초기화한다.
   • 이렇게 하면 두 번이나 초기화가 된다. 객체 생성 시, insert 직전 이렇게 두번! -> 두 시점 사이 시간차가 있을 수 있으므로
   • Auditing을 안써서 별도 설정이 필요 없지만 직접 제어해야 해서 불편하다. Update도 별도로 설정해줘야한다.

Getter와 Setter

protected set이란 그럼 무엇인가..

var의 동작 원리

kotlin에서 var로 선언한 변수는 컴파일러가 자동으로 getter, setter를 생성해준다. 다음 두 버전이 동일한 내용이라고 보면 된다.

코틀린 작성 코드

var createdAt: LocalDateTime? = LocalDateTime.now()

자바 작성 코드

Lombok의 @Getter, @Setter를 사용해줄 수도 있다.

private LocalDateTime createdAt = LocalDateTime.now();

public LocalDateTime getCreatedAt() {        // getter
    return createdAt;
}

public void setCreatedAt(LocalDateTime value) {  // setter
    this.createdAt = value;
}

코틀린에서의 가시성 분리 문법

kotlin은 getter, setter의 가시성을 다르게 지정할 수가 있다. getter는 public, setter는 protected로 하고 싶다면 protected set으로 명시해주면 되는 것이다.

최종 BaseEntity

@MappedSuperclass  
@QuerySupertype // QClass 생기지 않도록 설정  
@EntityListeners(AuditingEntityListener::class)  
class BaseEntity {  
    @CreatedDate  
    @JsonFormat(  
        shape = JsonFormat.Shape.STRING,  
        pattern = "yyyy-MM-dd HH:mm:ss",  
        timezone = "Asia/Seoul")  
    var createdAt: LocalDateTime? = LocalDateTime.now()  
            protected set  

    @LastModifiedDate  
    @JsonFormat(  
        shape = JsonFormat.Shape.STRING,  
        pattern = "yyyy-MM-dd HH:mm:ss",  
        timezone = "Asia/Seoul")  
    var modifiedAt: LocalDateTime? = LocalDateTime.now()  
            protected set  
}

기능 개발 - level 2

import java.util.*;

class Solution {
    public int[] solution(int[] progresses, int[] speeds) {
        int[] answer = {};
        Queue<Integer> q = new ArrayDeque<>();
        int n = progresses.length;

        for(int i = 0; i < n;i++){
            int days = (100 - progresses[i] + speeds[i] - 1) / speeds[i];
            q.offer(days);
        }

        List<Integer> list = new ArrayList<>();

        while(!q.isEmpty()){
            int count = 1;
            int job = q.poll();
            // 작업완료된 기능보다 더 빨리 아니면 같은날에 배포가 가능하다면 같이 poll
            while(!q.isEmpty() && q.peek() <= job){
                q.poll();
                count++;
            }
            list.add(count);
        }

        answer = new int[list.size()];
        for (int i = 0; i < list.size();i++){
            answer[i] = list.get(i);
        }
        return answer;
    }
}

푼 방법

• 책이랑 조금 다르게 배포 전까지의 최소 날짜를 큐에 넣었다.
• 먼저 끝내도 배포를 못하기 때문에 순서대로 큐에 넣고, 다음 작업의 최소 남은 일수가 현재 끝낸 작업의 일수보다 작거나 같으면 같이 배포하는 걸로 처리한다.

회고

• 큐를 써서 풀긴 했는데 꼭 쓸 필요는 없는 것 같다.
• 핵심 아이디어? 가 딱히 없는 것 같아서 금방 풀었다. 그냥 배포 가능하면 같이 한다 정도..?
• stream을 쓰면 코드가 간결해서 쓰려고 했는데 성능이 안좋아지는 것 같아서 그냥 stream 없이 했다.

구명 보트 - Level 2

class Solution {
    public int solution(int[] people, int limit) {
        int answer = 0;

        Arrays.sort(people);

        int n = people.length;

        int left = 0;
        int right = people.length - 1;

        while(left <= right){
            if(people[left] + people[right] <= limit){
                left++;
            }
            right--;
            answer++;
        }

        return answer;
    }
}

푼 방법

• 오름차순으로 정렬을 한다.
• left, right로 각각 한명씩 선택하고, 만족을 못하면 이동하는 방식으로 한다.
• left 인덱스가 right보다 커지면 종료하므로 전체를 다 돌게 된다.
• 가장 가벼운 사람 선택하고, 가장 무거운 사람과 합쳐서 limit보다 작거난 같으면 선택하고 아니면 옆으로 이동한다.

20 30 70 80 이런식으로 있다고 가정한다. limit은 100이다.

20을 선택하면 80과 같이 태워야 가장 효율적이다. 그러므로 20을 선택하면 80을 선택하도록 설계해야 한다. 그래서 가장 가벼운 사람을 고르고, 그 사람과 가장 무거운 사람을 비교하고 초과하면 두번째로 무거운 사람과 비교하는 식으로 했다. 가벼운 사람을 고르는 건 오름차순이므로 left, 무거운 사람을 고르는 건 오른쪽이므로 right로 해서 left는 둘을 태우게 되면 이동하는 식으로, 가벼운 사람 기준으로 같이 태울 사람을 정하는 식으로 했다.

회고

• 처음에 아이디어 자체는 빨리 떠올렸던 것 같다. 가벼운 사람 한명 태우고, 가장 무거운 사람을 내림차순으로 검사하는 방식으로..
• 처음이 이중 for문으로 돌아가면서 선택해야 하나 싶었는데 생각해보니 모두 돌 필요가 없고 두명을 고르는 것이기 때문에 반씩 돌면 되니까, 두 변수를 두고 아니면 이동하는 식으로 구현했다. 근데 이 방식을 생각하는게 조금 걸렸다.

표 편집 - Level 3

문제 보기

import java.util.Stack;
import java.util.StringBuilder;


class Solution {
    public String solution(int n, int k, String[] cmd) {
        int current = k;
        // 삭제된 노드 보관하는 스택
        Stack<Integer> deleted = new Stack<>();
        // 해당 인덱스의 이전 노드, 첫 번재 인덱스는 이전 노드 없으므로 -1이 들어감
        int[] prev = new int[n];
        // 해당 인덱스의 이후 노드 
        int[] next = new int[n];
        // 삭제 여부를 관리하는 배열
        boolean[] removed = new boolean[n];

        // 초기화
        for(int i = 0; i < n; i++){
            prev[i] = i - 1;
            next[i] = i + 1;
        }
        // 마지막 인덱스는 이후 노드가 없으므로 -1을 넣어줌
        next[n - 1] = -1;

        int x;

        for(String s: cmd){
            String[] command = s.split(" ");
            switch(command[0]){
                case "U":
                    x = Integer.parseInt(command[1]);
                    for(int i = 0; i < x;i++) current = prev[current];
                    break;
                case "D":
                    x = Integer.parseInt(command[1]);
                    for(int i = 0; i < x;i++) current = next[current];
                    break;
                case "C":
                    deleted.push(current);
                    removed[current] = true;
                    if(prev[current]!= -1) next[prev[current]] = next[current];
                    if(next[current]!=-1) prev[next[current]] = prev[current];
                    current = (next[current]!=-1) ? next[current] : prev[current];
                    break;
                case "Z":
                    if(!deleted.isEmpty()){
                        int restored = deleted.pop();
                        removed[restored] = false;
                        // 복구 시에는 양옆이 restored를 가리키게 해야 함
                        // 이전 인덱스의 next를 복구하려는 인덱스로 설정
                        if(prev[restored]!=-1) next[prev[restored]] = restored;
                        // 다음 인덱스의 prev를 복구하려는 인덱스로 설정
                        if(next[restored]!=-1) prev[next[restored]] = restored;
                    }
                    break;
            }
        }
        StringBuilder sb = new StringBuilder();

            for(boolean r: removed){
                sb.append(r ? "X" : "O");
            }

        return sb.toString();
    }
}

푼 방법

1. 초기화

• 이중 연결리스트를 구현했다.
• Stack<Integer> deleted : 삭제된 노드를 보관하는 스택
• int[] prev : i번째 노드의 이전 값들을 보관하는 배열, 첫번째 노드는 이전 노드가 없으므로 -1을 넣는다.
• int[] next : i번째 노드의 다음 값들을 보관하는 배열, 마지막 노드는 다음 노드가 없으므로 -1을 넣는다.
• boolean[] removed : 최종 출력시에 삭제 여부 관리하는 배열

즉 prev,next는 연결 관계를 유지해야한다.

인덱스 이동

x만큼 위/아래로 현재 인덱스를 이동시킨다고 할 때, 반복문을 돌려서 prev과 next의 현재값을 하나씩 옮겨준다.

1  -  2  -  3  - 4

지금 현재 인덱스가 1이고 2만큼 아래로 옮겨야 하면 반복문 한턴이 돌았을 때,

current가 이렇게 2번째 인덱스를 가리키려면 다음 인덱스를 가져가야 한다. 반대로 위로 옮기려면 이전 인덱스를 가져가야 한다. 그래서 위로 이동할 때는 prev, 아래로 이동할 때는 next를 사용해준다.

1  -  2  -  3  - 4

           cur

인덱스 삭제

이것도 간단하게 생각하면 삭제를 해주고 이어 붙여주면 된다.

1  -  2  -  3  - 4

이렇게 있을 때 2를 삭제해야 한다고 가정해 보면, 1의 다음 인덱스를 3의 이전 인덱스로 설정해줘야 한다. 즉 next[prev[current]] 는 이전 인덱스의 다음 인덱스 값이므로, 이거를 삭제하려는 인덱스의 다음 값으로 바꿔준다.

이렇게만 해주면 [삭제노드] 의 이전 인덱스만 처리를 해준 것이다. 다음 인덱스의 prev 배열도 처리해주면 삭제 노드가 없어지고 이어붙여진다.

이렇게 값을 삭제하고 나서 stack에 push해줘야 한다. 영구적으로 삭제한 게 아니고 Z 명령어가 나오면 다시 넣어줘야 하기 때문이다. removed에 true 처리도 해줘야 한다. 마지막 표시용으로..

// 이전 인덱스의 next 처리
if(prev[current]!= -1) next[prev[current]] = next[current];
// 다음 인덱스의 prev 처리
if(next[current]!=-1) prev[next[current]] = prev[current];

인덱스 복구

인덱스 복구도 삭제랑 비슷한 느낌으로 구현하면 되는데, 이전 인덱스의 next와 다음 인덱스 prev가 복구하려는 인덱스를 가리키게 하면 된다.

먼저 삭제해둔 인덱스를 복구처리해준다. 가장 최근에 삭제된 인덱스를 stack에서 pop하고 removed 배열도 false처리해준다.

회고

• 처음에 연결리스트로 풀어서 간단하게 풀릴 줄 알았는데 시간초과가 났다 .. 다른 방법 찾아보니까 배열로 이중 연결리스트를 만드는 방법이 있어서 이렇게 하면 시간초과가 안날 것 같아서 시도해 봤다.
• 책에서는 마지막에 StringBuilder를 사용하지 않고 arrays fill 방법을 사용했다. 그다지 성능에 많은 차이가 날 것 같지는 않은데 StringBuilder를 남발하는 습관때문에 그런 것 같다. 최대한 util을 안쓰고 하는 방법을 항상 생각해봐야겠다.
• 책에서 switch case 말고 else if를 사용했는데 이것도 괜찮은 방법 같은게 C,Z는 숫자 매개변수가 딱히 없는 연산이라서.. 그렇지만 switch문이 뭔가 보기 깔끔해서 그냥 썼다.

크레인 인형뽑기

문제 보기

import java.util.*;

class Solution {
    public int solution(int[][] board, int[] moves) {
        int answer = 0;

        // n-1,0 계열부터 넣고, n-2,0 계열부터 다음에 넣기 
        // 그러면 n-1,0 n-2, 1 이렇게 순서대로 넣기
        int n = board[0].length;
        Stack<Integer> picked = new Stack<>();

        // 초기화 
        List<Stack<Integer>> stacks = new ArrayList<>();
        for(int i = 0; i < n;i++){
            Stack<Integer> stack = new Stack<>();
            for(int j = n-1; j >= 0; j--){
                int current = board[j][i];
                if(current == 0){
                    continue;
                }
                stack.push(current);
            }
            stacks.add(stack);
        }

        // 움직일 때마다 stack에 넣기
        for(int m : moves){
             // 가장 위에있는거랑 지금 넣을거랑 같으면 둘다 삭제
            if(!picked.isEmpty() && !stacks.get(m-1).isEmpty()){
                if(stacks.get(m-1).peek() == picked.peek()){
                    answer+=2;
                    stacks.get(m-1).pop();
                    picked.pop();
                } else{
                    // 같지 않으면 picked에 넣기 
                    picked.push(stacks.get(m-1).pop());
                }
            } else if (!stacks.get(m-1).isEmpty()){
                picked.push(stacks.get(m-1).pop());
            } else if (stacks.get(m-1).isEmpty()){
                continue;
            }
        }

        return answer;
    }
}

푼 방법

• 초기화: 세로 라인별로 stack을 만들어서 리스트에 저장한다.
• 스택에 먼저 넣기: [n-1][0]이 제일 끝부분에 들어가야 하므로 n-1,n-2 이렇게 해서 해당 라인 stack에 저장한다.
• 크레인을 돌아다니면서 뽑기: 뽑은 것을 picked stack에 넣는다.

이건 세 가지 경우가 있는데

1. picked의 peek(제일 위에 있는 것)이 현재 위에 있는거랑 다르면 라인이랑 뽑힌 것에서 삭제
2. 같지 않으면 picked에 넣기
3. 라인 자체가 안비어있으면 picked에 넣고 라인에서 삭제

개선할 점

stack에 넣기 전에 그냥 검사해서 하는 방법도 괜찮을 것 같은데 코드가 너무 길어진 것 같다.. 그래도 숫자 범위 자체가 그렇게 크지는 않아서 별 차이가 없을 것 같다.

세계적인 호텔인 형택 호텔의 사장인 김형택은 이번에 수입을 조금 늘리기 위해서 홍보를 하려고 한다. 형택이가 홍보를 할 수 있는 도시가 주어지고, 각 도시별로 홍보하는데 드는 비용과, 그 때 몇 명의 호텔 고객이 늘어나는지에 대한 정보가 있다. 예를 들어, “어떤 도시에서 9원을 들여서 홍보하면 3명의 고객이 늘어난다.”와 같은 정보이다. 이때, 이러한 정보에 나타난 돈에 정수배 만큼을 투자할 수 있다. 즉, 9원을 들여서 3명의 고객, 18원을 들여서 6명의 고객, 27원을 들여서 9명의 고객을 늘어나게 할 수 있지만, 3원을 들여서 홍보해서 1명의 고객, 12원을 들여서 4명의 고객을 늘어나게 할 수는 없다. 각 도시에는 무한 명의 잠재적인 고객이 있다. 이때, 호텔의 고객을 적어도 C명 늘이기 위해 형택이가 투자해야 하는 돈의 최솟값을 구하는 프로그램을 작성하시오.

import java.util.*;
import java.io.*;

class Main {
    static int[] dp;
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st;
        st = new StringTokenizer(br.readLine());
        int c = Integer.parseInt(st.nextToken());
        int n = Integer.parseInt(st.nextToken());

        // 큰 값으로 지정 및 초기화 
        int INF = 1_000_000_000;
        dp = new int[c+100];
        Arrays.fill(dp, INF);
        dp[0] = 0;

        for(int i = 0; i < n;i++) {
            st = new StringTokenizer(br.readLine());
            int value = Integer.parseInt(st.nextToken());
            int weight = Integer.parseInt(st.nextToken());
            for(int w = weight; w < dp.length;w++){
                dp[w] = Math.min(dp[w], dp[w - weight] + value);
            }
        }

        int answer = INF;
        for (int i = c; i < dp.length; i++) {
            answer = Math.min(answer, dp[i]);
        }
        System.out.println(answer);
    }
}

문제 분석

• DP 유형 중 요소를 여러 개 사용해도 되는 배낭 문제이다.

삽질한 이유

• DP문제를 풀 때마다 초기화하는걸 자꾸 까먹는다 .. 최솟값을 구하는 문제이므로 큰 값으로 초기화해주기
• 손님 수 이상이 되어도 상관 없고 적어도 c명 이상이라는걸 간과하고 처음에 dp 배열 크기를 잘못 잡았다.