equals와 hashCode를 올바르게 재정의하는 방법

자바에서 equals와 hashCode 메서드는 객체의 논리적 동치성과 해시 기반 컬렉션에서의 동작을 결정하는 핵심 요소입니다. Object 클래스에서 제공하는 기본 구현은 참조 동일성을 비교하지만, 논리적 동치성을 비교하려면 이를 적절히 재정의해야 합니다. 이 글에서는 equals와 hashCode를 재정의할 때 지켜야 할 규약과 주의 사항을 살펴보겠습니다.

equals를 재정의하지 않는 것이 좋은 경우

다음과 같은 상황에서는 equals 메서드를 재정의하지 않는 것이 적절합니다:

• 각 인스턴스가 본질적으로 고유한 경우
  예를 들어, Thread와 같이 각 객체가 고유한 식별성을 가지는 경우에는 논리적 동치성을 비교할 필요가 없습니다.
• 논리적 동치성을 검사할 필요가 없는 경우
  객체의 논리적 동치성을 비교할 일이 없는 클래스에서는 equals를 재정의할 필요가 없습니다.
• 상위 클래스의 equals가 하위 클래스에 적합한 경우
  상위 클래스에서 이미 적절히 재정의된 equals 메서드가 하위 클래스에서도 충분히 동작한다면 재정의가 필요 없습니다. 예: java.util.AbstractList의 equals는 하위 클래스에서도 잘 동작합니다.
• 클래스가 private 또는 package-private이고 equals 호출이 없는 경우
  equals 메서드가 호출될 일이 없는 클래스라면 재정의할 필요가 없습니다. 실수로 호출되는 것을 방지하기 위해 다음과 같이 방어적으로 작성할 수 있습니다:
• @Override public boolean equals(Object o) { throw new AssertionError("equals 메서드가 호출되지 않아야 합니다."); }

equals를 재정의하는 것이 좋은 경우

equals 메서드는 객체의 논리적 동치성을 비교해야 할 때 재정의해야 합니다. 특히, 상위 클래스의 equals가 논리적 동치성을 비교하도록 설계되지 않은 경우가 이에 해당합니다. 예를 들어, Set이나 Map의 키로 사용되는 객체는 논리적 동치성을 기반으로 동작하므로 equals를 적절히 재정의해야 합니다.

equals 메서드의 일반 규약

equals 메서드를 재정의할 때는 다음 다섯 가지 규약을 반드시 준수해야 합니다:

1. 반사성(reflexivity): null이 아닌 모든 참조 값 x에 대해, x.equals(x)는 true를 반환해야 합니다.
2. 대칭성(symmetry): null이 아닌 모든 참조 값 x, y에 대해, x.equals(y)가 true이면 y.equals(x)도 true여야 합니다.
3. 추이성(transitivity): null이 아닌 모든 참조 값 x, y, z에 대해, x.equals(y)가 true이고 y.equals(z)가 true이면, x.equals(z)도 true여야 합니다.
4. 일관성(consistency): null이 아닌 모든 참조 값 x, y에 대해, x.equals(y)를 반복 호출하면 항상 동일한 결과를 반환해야 합니다(객체의 상태가 변경되지 않는 한).
5. null-아님: null이 아닌 모든 참조 값 x에 대해, x.equals(null)은 false를 반환해야 합니다.

equals 재정의 시 주의 사항

• 구체 클래스의 확장과 값 추가: 구체 클래스를 확장하면서 새로운 값을 추가하는 경우, equals 규약을 만족시키는 것은 불가능합니다. 이를 해결하려면 상속 대신 컴포지션(composition)을 사용하세요.
• 신뢰할 수 없는 자원 사용 금지: equals 메서드는 클래스 내부의 필드만 사용해야 하며, 외부의 신뢰할 수 없는 자원(예: 파일, 네트워크)에 의존해서는 안 됩니다.
• 입력 타입은 Object여야 함: equals 메서드의 매개변수는 반드시 Object 타입이어야 하며, 특정 클래스 타입으로 제한하면 규약을 위반하게 됩니다.

equals 재정의 단계

equals 메서드를 재정의할 때는 다음 단계를 따르는 것이 좋습니다:

1. == 연산자로 참조 동일성 확인: 입력이 자기 자신의 참조인지 확인합니다.
2. instanceof 연산자로 타입 확인: 입력이 올바른 타입인지 확인합니다.
3. 형변환: 입력을 올바른 타입으로 형변환합니다.
4. 핵심 필드 비교: 입력 객체와 자기 자신의 대응되는 핵심 필드들이 모두 일치하는지 확인합니다.
5. float/double 비교: float와 double 필드는 각각 Float.compare(float, float)와 Double.compare(double, double)를 사용해 비교합니다.

예제: equals 메서드 구현

@Override
public boolean equals(Object o) {
    if (o == this) return true; // 참조 동일성 확인
    if (!(o instanceof MyClass)) return false; // 타입 확인
    MyClass other = (MyClass) o; // 형변환
    return this.field1 == other.field1 && // 핵심 필드 비교
           Objects.equals(this.field2, other.field2) &&
           Float.compare(this.field3, other.field3) == 0;
}

• Objects.equals: null 안전한 비교를 위해 사용.
• Float.compare/Double.compare: 부동소수점 비교 시 정확성을 보장.

hashCode를 재정의해야 하는 이유

equals 메서드를 재정의한 클래스는 반드시 hashCode 메서드도 재정의해야 합니다. 그렇지 않으면 HashMap, HashSet 같은 해시 기반 컬렉션에서 객체가 예상대로 동작하지 않을 수 있습니다. 이는 Object 클래스의 hashCode 일반 규약을 위반하기 때문입니다.

hashCode 일반 규약

Object 클래스의 API 문서에 명시된 hashCode의 규약은 다음과 같습니다:

1. 일관성: 동일한 객체에서 hashCode를 여러 번 호출하면, 객체의 상태가 변경되지 않는 한 항상 동일한 값을 반환해야 합니다.
2. equals와의 일치: equals 메서드에서 같은 객체로 판단되는 두 객체는 동일한 hashCode 값을 반환해야 합니다.
3. 분산성: equals로 다른 객체로 판단되는 객체들은 가능한 한 서로 다른 hashCode 값을 반환해야 합니다(필수는 아니지만 성능에 영향을 미침).

hashCode를 재정의하지 않을 때의 문제

equals를 재정의했지만 hashCode를 재정의하지 않으면, 논리적으로 동일한 객체가 다른 해시코드를 반환할 수 있습니다. 이는 HashMap이나 HashSet에서 객체를 찾거나 저장할 때 문제를 일으킵니다. 예를 들어:

• HashMap에서 키로 사용된 객체를 찾을 수 없음.
• HashSet에서 동일한 객체가 중복으로 추가됨.

hashCode 구현 가이드라인

1. 핵심 필드 사용: equals에서 사용하는 모든 핵심 필드를 hashCode 계산에 포함해야 합니다. 핵심 필드를 생략하면 논리적 동치성을 보장할 수 없습니다.
2. 효율성과 분산성 고려: 해시코드는 가능한 한 고르게 분포해야 하며, 계산이 너무 복잡하지 않아야 합니다.
3. API 문서에 계산 방식 비공개: hashCode의 구현 세부 사항을 API 문서에 공개하지 말아야 합니다. 이는 나중에 구현을 변경할 유연성을 제공합니다.

예제: hashCode 메서드 구현

@Override
public int hashCode() {
    int result = 17; // 초기값(소수 권장)
    result = 31 * result + field1; // 기본 타입
    result = 31 * result + Objects.hashCode(field2); // 객체 필드
    result = 31 * result + Float.floatToIntBits(field3); // 부동소수점
    return result;
}

• 31 사용 이유: 홀수 소수로 곱셈을 통해 해시 충돌 가능성을 줄입니다.
• Objects.hashCode: null 안전한 해시 계산.
• Float.floatToIntBits: 부동소수점 값을 정수로 변환.

추가 팁

• 너무 복잡하게 구현하지 말자: equals와 hashCode는 간단하고 명확하게 작성해야 유지보수가 쉽습니다.
• AutoValue 또는 IDE 활용: Google의 AutoValue 프레임워크나 IntelliJ, Eclipse 같은 IDE는 equals와 hashCode를 자동으로 생성해줍니다.
• 성능 최적화: 지나치게 복잡한 hashCode 계산은 성능을 저하시킬 수 있으므로 적절히 균형을 맞추세요.
• 캐싱 고려: 불변 객체의 경우 hashCode 값을 캐싱하여 성능을 최적화할 수 있습니다.

결론

equals 메서드를 재정의할 때는 반드시 hashCode도 재정의해야 합니다. 이는 해시 기반 컬렉션(HashMap, HashSet 등)에서 올바른 동작을 보장하기 위해 필수적입니다. equals와 hashCode는 일반 규약을 준수하고, equals에서 사용하는 핵심 필드를 모두 포함해야 합니다. AutoValue나 IDE의 자동 생성 기능을 활용하면 규약을 준수하는 equals와 hashCode를 쉽게 구현할 수 있습니다.

본 내용은 『Effective Java』를 참조하여 작성되었습니다.

Java NIO 이해하기: 버퍼, 채널, 셀렉터

Java NIO(New Input/Output)는 입출력 작업을 비동기적이고 효율적으로 처리하기 위한 강력한 API입니다. 기존 Java IO는 스트림과 멀티스레딩에 의존하여 다수의 클라이언트를 처리했지만, NIO는 버퍼, 채널, 셀렉터를 활용해 성능과 확장성을 최적화합니다. 이 글에서는 Java NIO의 핵심 구성 요소인 다이렉트/논다이렉트 버퍼, 채널, 셀렉터의 역할을 정리합니다.

다이렉트 버퍼 vs 논다이렉트 버퍼

NIO의 버퍼는 채널에서 데이터를 읽거나 쓰기 위해 사용됩니다. 버퍼는 다이렉트 버퍼와 논다이렉트 버퍼로 나뉘며, 각각의 특징은 다음과 같습니다:

버퍼의 특징

• 버퍼 생성 속도:
  • 논다이렉트 버퍼: JVM의 힙 메모리에 할당되므로 생성 속도가 빠릅니다.
  • 다이렉트 버퍼: 운영체제의 네이티브 메모리에 할당되므로 생성 속도가 느립니다.
• 입출력 성능:
  • 논다이렉트 버퍼: JVM 힙과 네이티브 메모리 간 데이터 복사로 인해 입출력 성능이 낮습니다.
  • 다이렉트 버퍼: 네이티브 메모리에 직접 접근하므로 입출력 성능이 더 뛰어납니다.
• 메모리 종류:
  • 논다이렉트 버퍼: JVM의 힙 메모리에 저장되며, 가비지 컬렉터에 의해 관리됩니다.
  • 다이렉트 버퍼: 운영체제의 네이티브 메모리에 할당되어 JVM 힙 관리를 우회합니다.

활용 사례: 다이렉트 버퍼는 네트워크나 파일 입출력과 같은 고성능 작업에 적합하며, 논다이렉트 버퍼는 입출력 부하가 적고 빠른 메모리 할당이 필요한 경우에 유용합니다.

NIO의 채널

기존 IO는 단방향 스트림(읽기 또는 쓰기 중 하나)을 사용하지만, NIO의 채널은 양방향으로 읽기와 쓰기를 모두 지원합니다. 채널은 항상 버퍼와 함께 사용되며, 데이터를 버퍼에 저장하거나 버퍼에서 읽어옵니다.

채널을 사용하는 이유

• 양방향성: 읽기와 쓰기를 동시에 지원하여 기존 IO 스트림보다 유연합니다.
• 비동기 처리: 비동기 모드를 지원해 단일 스레드로 다수의 클라이언트를 효율적으로 처리할 수 있습니다.
• 효율성: 버퍼와 함께 작동하여 데이터 복사를 최소화하고 입출력 효율성을 높입니다.

주요 채널 유형

• ServerSocketChannel: 서버에서 클라이언트 연결 요청을 수신하는 데 사용됩니다. 비동기 모드로 설정해 다수의 클라이언트 연결을 효율적으로 처리하며, 셀렉터와 함께 사용됩니다.
• SocketChannel: 클라이언트와 서버 간의 단일 연결을 관리하며 데이터를 읽고 쓰는 데 사용됩니다. 비동기 모드를 지원해 높은 동시성을 제공합니다.

셀렉터(Selector)의 역할

셀렉터는 단일 스레드로 다수의 채널을 관리할 수 있게 해주는 NIO의 핵심 구성 요소입니다. 셀렉터는 채널의 특정 이벤트(예: 연결 요청, 데이터 읽기 준비, 데이터 쓰기 준비)를 모니터링하고, 이벤트 발생 시 애플리케이션에 알립니다.

셀렉터를 사용하는 이유

• 멀티플렉싱: 단일 스레드로 다수의 채널을 관리하여 기존 IO의 스레드당 클라이언트 처리 방식을 대체합니다. 이는 수천 개의 동시 연결을 처리하는 서버에 적합합니다.
• 비동기 입출력: 비동기 모드의 채널과 함께 작동하여 준비된 채널만 처리하므로 리소스 사용을 최적화합니다.
• 효율성: 셀렉터는 준비된 채널만 선택적으로 처리해 성능을 향상시킵니다.

셀렉터 동작 방식

1. ServerSocketChannel을 셀렉터에 등록하여 연결 요청(OP_ACCEPT)을 감시합니다.
2. 클라이언트 연결이 발생하면 셀렉터가 이를 감지하고, 애플리케이션은 연결을 수락해 SocketChannel을 생성합니다.
3. SocketChannel을 셀렉터에 등록하여 읽기(OP_READ) 또는 쓰기(OP_WRITE)를 감시합니다.
4. 셀렉터는 등록된 모든 채널을 지속적으로 모니터링하며 준비된 채널을 애플리케이션에 알립니다.

ServerSocketChannel과 SocketChannel의 역할

• ServerSocketChannel:
  • 목적: 서버에서 클라이언트의 연결 요청을 수신합니다.
  • 비동기 지원: 비동기 모드로 다수의 연결 요청을 단일 스레드로 처리할 수 있습니다.
  • 활용 사례: 확장 가능한 서버 구축에 필수적이며, 다수의 클라이언트 연결을 효율적으로 관리합니다.
• SocketChannel:
  • 목적: 클라이언트와 서버 간의 단일 연결에서 데이터 읽기와 쓰기를 처리합니다.
  • 비동기 지원: 비동기 모드로 동작하여 스레드를 블록하지 않고 입출력을 처리합니다.
  • 활용 사례: TCP 연결을 통한 클라이언트-서버 통신에 사용됩니다.

기존 IO vs NIO

기존 Java IO:

• 클라이언트당 전용 스레드가 필요하여 다수의 클라이언트를 처리할 때 리소스 소모가 큽니다.
• 스트림은 단방향(읽기 또는 쓰기)만 지원합니다.

Java NIO:

• 채널과 셀렉터를 활용해 단일 스레드로 다수의 클라이언트를 처리하여 확장성을 높입니다.
• 양방향 채널을 지원하여 읽기와 쓰기를 동시에 처리할 수 있습니다.
• 다이렉트 버퍼를 통해 입출력 성능을 최적화합니다.

결론

Java NIO는 다이렉트/논다이렉트 버퍼, 양방향 채널, 셀렉터를 통해 고성능, 확장 가능한 애플리케이션 개발을 가능하게 합니다. ServerSocketChannel과 SocketChannel을 셀렉터와 함께 사용하면 다수의 클라이언트를 효율적으로 관리할 수 있습니다. NIO의 이러한 특징을 이해하고 활용하면 네트워크 프로그래밍에서 높은 성능과 확장성을 달성할 수 있습니다.

개발을 하다 보면 JPA와 Hibernate를 사용하는 환경에서 LazyInitializationException을 마주치게 될 때가 있습니다. 특히 연관 데이터를 지연 로딩(Lazy Loading)으로 설정했을 때 트랜잭션 종료 이후 데이터를 로드하려 하면 이 문제가 발생합니다. 이번 글에서는 LazyInitializationException이 무엇인지, 왜 발생하는지, 그리고 이를 해결하기 위해 필요한 트랜잭션, 영속성 컨텍스트, 준영속성에 대해 설명합니다.

1. LazyInitializationException이란?

LazyInitializationException은 JPA에서 지연 로딩(Lazy Loading)으로 설정된 연관 데이터를 트랜잭션 종료 이후 로드하려고 할 때 발생하는 예외입니다. Lazy Loading은 실제로 데이터가 필요할 때만 쿼리를 실행하여 데이터를 가져오는 방식이지만, 트랜잭션이 종료된 후에는 영속성 컨텍스트가 닫혀 데이터베이스에 접근할 수 없으므로 예외가 발생합니다.

2. 예제 코드

Circle 엔티티와 CircleSchedule 엔티티를 사용한 예제를 통해 설명합니다.

@Entity
class Circle(
    @Id
    @GeneratedValue
    val id: UUID = UUID.randomUUID(),

    val title: String,

    @OneToMany(mappedBy = "circle", fetch = FetchType.LAZY, cascade = [CascadeType.ALL])
    val circleSchedules: MutableList<CircleSchedule> = mutableListOf()
)

CircleSchedule 엔티티

@Entity
class CircleSchedule(
    @Id
    @GeneratedValue
    val id: UUID = UUID.randomUUID(),

    @ManyToOne(fetch = FetchType.LAZY)
    val circle: Circle,

    val dayOfWeek: String,
    val startTime: String,
    val endTime: String
)

3. 문제 상황: LazyInitializationException 발생

아래 코드에서 circle.circleSchedules는 Lazy Loading으로 설정되어 있습니다. 트랜잭션이 종료된 후 circleSchedules에 접근하려 하면 LazyInitializationException이 발생합니다.

문제 코드

fun getCircleSchedules(circleId: UUID): List<CircleSchedule> {
    val circle = circleRepository.findById(circleId)
        .orElseThrow { NotExistException("Circle not found") }
    return circle.circleSchedules // LazyInitializationException 발생 가능
}

발생 이유

1. circle.circleSchedules는 FetchType.LAZY로 설정되어 있어, 기본적으로 데이터베이스 쿼리를 실행하지 않습니다.
2. 트랜잭션이 종료되면 영속성 컨텍스트도 종료되므로, 지연 로딩된 데이터를 가져올 수 없습니다.

4. LazyInitializationException 해결 방법

1) @Transactional 사용

트랜잭션 내에서 지연 로딩 데이터에 접근하도록 @Transactional을 적용합니다.

@Transactional(readOnly = true)
fun getCircleSchedules(circleId: UUID): List<CircleSchedule> {
    val circle = circleRepository.findById(circleId)
        .orElseThrow { NotExistException("Circle not found") }
    return circle.circleSchedules // Lazy Loading 가능
}

2) Open-Session-In-View 설정

Spring Boot에서 spring.jpa.open-in-view 설정을 활성화하면 트랜잭션이 종료된 이후에도 Lazy Loading이 가능합니다. 하지만 이 방법은 권장되지 않습니다.

application.yml 설정:

spring:
  jpa:
    open-in-view: true

5. 영속성 컨텍스트와 트랜잭션

영속성 컨텍스트(Persistence Context)

영속성 컨텍스트는 JPA 엔티티를 관리하며 데이터베이스와의 상호작용을 처리하는 캐시 역할을 합니다.

• 트랜잭션이 시작되면 영속성 컨텍스트가 활성화됩니다.
• 트랜잭션이 종료되면 영속성 컨텍스트도 종료됩니다.
• Lazy Loading은 영속성 컨텍스트 내에서만 작동합니다.

트랜잭션 종료 이후의 Lazy Loading

트랜잭션이 종료되면 영속성 컨텍스트가 종료되고, Lazy Loading 데이터는 로드할 수 없습니다. 이를 방지하려면 트랜잭션 내부에서 데이터를 로드해야 합니다.

6. 결론

• LazyInitializationException은 트랜잭션 종료 이후 Lazy Loading 데이터를 로드하려 할 때 발생합니다.
• @Transactional 등을 활용하여 LazyInitializationException을 방지할 수 있습니다.
• 영속성 컨텍스트와 트랜잭션의 생명주기를 이해하면 Lazy Loading 문제를 더 잘 해결할 수 있습니다.

프로젝트를 진행하다 보면 다양한 조건을 기반으로 데이터를 검색해야 할 때가 많습니다. 예를 들어, title, englishLevel, city와 같은 조건을 이용해 Circle 데이터를 검색할 때, 이들 조건이 null일 경우 해당 조건을 무시하고 싶을 수 있습니다. 이런 경우 Kotlin JDSL에서는 null 값 조건을 쉽게 무시하는 방법을 제공하며, 이번 글에서는 이를 어떻게 적용할 수 있는지 설명드리겠습니다.

문제 상황

아래와 같은 쿼리를 작성했다고 가정해보겠습니다.

override fun findCirclesByPagination(pageable: Pageable, request: CircleSearchRequest?)
: Page<CirclePageResponse?> {
    return kotlinJdslJpqlExecutor.findPage(pageable) {
        selectNew<CirclePageResponse>(
                path(Circle::id),
                path(Circle::thumbnailUrl),
                path(Circle::title),
                path(Circle::introduction),
                path(Member::profile).`as`(expression("leaderProfile")),
                path(Member::nickname).`as`(expression("leaderName")),
                path(Circle::englishLevel),
                path(Circle::city),
                path(Circle::capacity),
                path(Circle::totalView),
                path(Circle::totalLike),
        ).from(
                entity(Circle::class),
                join(Circle::leader)
        ).whereAnd(
                path(Circle::title).like("%${request?.title}%"),
                path(Circle::englishLevel).eq(request?.level),
                path(Circle::city).eq(request?.city)
        )
    }
}

여기서 우리는 title, englishLevel, city 세 가지 조건을 사용하고 있습니다. 하지만 이 필드들 중 하나라도 null일 경우 쿼리에서 해당 조건을 무시해야 할 때 어떻게 해야 할까요?

해결 방법: 조건을 let으로 감싸기

Kotlin JDSL에서는 whereAnd 블록 내에서 조건을 동적으로 추가할 수 있습니다. let 함수를 활용해 각 조건이 null이 아닐 때만 적용되도록 설정해보겠습니다.

override fun findCirclesByPagination(pageable: Pageable, request: CircleSearchRequest?)
: Page<CirclePageResponse?> {
    return kotlinJdslJpqlExecutor.findPage(pageable) {
        selectNew<CirclePageResponse>(
                path(Circle::id),
                path(Circle::thumbnailUrl),
                path(Circle::title),
                path(Circle::introduction),
                path(Member::profile).`as`(expression("leaderProfile")),
                path(Member::nickname).`as`(expression("leaderName")),
                path(Circle::englishLevel),
                path(Circle::city),
                path(Circle::capacity),
                path(Circle::totalView),
                path(Circle::totalLike),
        ).from(
                entity(Circle::class),
                join(Circle::leader)
        ).whereAnd(
                request?.title?.let { path(Circle::title).like("%$it%") },
                request?.level?.let { path(Circle::englishLevel).eq(it) },
                request?.city?.let { path(Circle::city).eq(it) }
        )
    }
}

코드 설명

1. 조건 추가를 위한 let 사용: request?.title, request?.level, request?.city가 각각 null이 아닐 때만 let 블록 내부의 조건이 실행되어 쿼리에 추가됩니다.
2. null 값 무시: title, level, city 중 하나라도 null이면 해당 조건은 자동으로 쿼리에서 제외됩니다.

동작 방식 예시

• title만 null인 경우: englishLevel과 city만 조건으로 포함됩니다.
• 모든 값이 null인 경우: 조건 없이 전체 결과가 반환됩니다.

이를 통해 null 조건을 유연하게 무시하고 원하는 조건에 따라 필터링된 결과를 반환받을 수 있습니다.

마무리

Kotlin JDSL에서 조건을 동적으로 설정하는 것은 상당히 직관적이며, let 함수와 같은 Kotlin의 기능을 활용해 쿼리의 가독성을 높일 수 있습니다. 이 방식은 특히 검색 기능을 구현할 때 유용하며, nullable 필드를 조건으로 사용할 때 코드의 안정성과 효율성을 높여줍니다.

이번 글에서는 Kotlin JDSL을 사용해 조건이 null인 경우 쿼리에서 해당 조건을 제외하는 방법을 살펴보았습니다. 앞으로 JDSL을 활용해 다양한 쿼리를 동적으로 구성할 때 큰 도움이 되길 바랍니다.

최근 프로젝트에서 Kotlin JDSL을 도입하며, 특히 페이지네이션된 데이터를 반환할 때 몇 가지 문제에 직면했습니다. 자료가 부족하거나 오래되어 직접 구현하기 쉽지 않았지만, 공식 문서와 GitHub 테스트 코드를 참고하여 문제를 해결할 수 있었습니다. 이번 글에서는 해결 과정을 코드와 함께 공유하고자 합니다.

문제 해결 과정: Page 타입 응답 구현

페이지네이션된 데이터를 반환하기 위해 KotlinJdslJpqlExecutor의 findPage 메서드와 selectNew를 사용했습니다. selectNew 메서드는 엔티티가 아닌 사용자 정의 DTO로 데이터를 매핑할 수 있어 매우 유용합니다. 아래는 구현한 코드입니다

@Repository
class CustomCircleRepositoryImpl(
    private val kotlinJdslJpqlExecutor: KotlinJdslJpqlExecutor
) : CustomCircleRepository {

    override fun findCirclesByPagination(pageable: Pageable): Page<CirclePageResponse?> {
        return kotlinJdslJpqlExecutor.findPage(pageable) {
            selectNew<CirclePageResponse>(
                path(Circle::id),
                path(Circle::thumbnailUrl),
                path(Circle::title),
                path(Circle::introduction),
                path(Member::profile).`as`(expression("leaderProfile")),
                path(Member::nickname).`as`(expression("leaderName")),
                path(Circle::englishLevel),
                path(Circle::city),
                path(Circle::capacity),
                path(Circle::totalView),
                path(Circle::totalLike)
            ).from(
                entity(Circle::class),
                join(Circle::leader)
            )
        }
    }
}

코드 설명

1. CustomCircleRepositoryImpl 클래스: KotlinJdslJpqlExecutor를 주입받아 findCirclesByPagination 메서드를 구현한 커스텀 리포지토리입니다.
2. findCirclesByPagination 메서드: Pageable 객체를 인자로 받아 Page<CirclePageResponse?> 타입의 응답을 반환합니다. 이 메서드는 JPA의 Page 기능을 활용해 페이지네이션된 데이터를 반환하도록 설계되었습니다.
3. selectNew 메서드: Kotlin JDSL의 핵심 기능 중 하나로, CirclePageResponse라는 사용자 정의 DTO에 엔티티 데이터를 매핑합니다. path 메서드를 통해 각 필드를 선택하며, DTO 필드와 일치하도록 매핑합니다. Member 엔티티에서 리더의 프로필과 닉네임을 가져오기 위해 join을 사용했습니다.

DTO 설계와 발생한 이슈

페이지네이션을 위해 사용하는 CirclePageResponse는 다음과 같은 구조를 가지고 있습니다:

@Schema(description = "서클 페이지 조회 응답")
data class CirclePageResponse(
    val id: UUID,
    val thumbnailUrl: String? = null,
    val title: String,
    val introduction: String = "",
    val leaderProfile: String? = null,
    val leaderName: String,
    val englishLevel: EnglishLevel,
    val city: City,
    val capacity: Int,
    val totalView: Int,
    val totalLike: Int,
    val likedByMe: Boolean = false
)

이슈: selectNew 메서드의 제한 사항

selectNew를 사용할 때, DTO의 생성자 파라미터에 정확히 일치하는 개수와 순서대로 값을 할당해야 합니다. likedByMe 필드는 기본값이 false로 설정되어 있었지만, selectNew는 기본값을 무시하고 모든 파라미터에 값을 전달하도록 강제합니다. 이로 인해 초기 코드에서 오류가 발생했습니다.

해결 방법

이 문제를 해결하기 위해 likedByMe 필드를 생성자 밖으로 이동하여 기본값을 설정하도록 변경했습니다. 수정된 DTO는 다음과 같습니다.

@Schema(description = "서클 페이지 조회 응답")
data class CirclePageResponse(
    val id: UUID,
    val thumbnailUrl: String? = null,
    val title: String,
    val introduction: String = "",
    val leaderProfile: String? = null,
    val leaderName: String,
    val englishLevel: EnglishLevel,
    val city: City,
    val capacity: Int,
    val totalView: Int,
    val totalLike: Int
) {
    val likedByMe: Boolean = false
}

이제 selectNew는 DTO의 모든 생성자 파라미터에 값을 할당할 필요가 없어졌습니다. likedByMe 필드는 클래스 바디에 정의되어 기본값 false로 설정됩니다. 이로써 selectNew의 제한 사항을 우회하면서 원하는 데이터를 매핑할 수 있었습니다.

들어가며

React에서 "A component is changing an uncontrolled input to be controlled"*라는 경고 메시지를 만난 적이 있나요? 이 에러는 보통 input 요소가 uncontrolled 상태로 시작했다가, 이후 controlled 상태로 변환될 때 발생합니다. 이러한 경고는 개발 환경에서만 표시되지만, 무시하고 넘어가면 앱의 일관성과 안정성에 문제가 생길 수 있습니다.

이번 글에서는 이 문제를 해결하는 방법을 예시 코드와 함께 알아보겠습니다.

Uncontrolled와 Controlled Input 차이

Uncontrolled input은 React가 그 값을 관리하지 않는 입력 요소를 의미합니다. 사용자가 입력한 값을 직접적으로 DOM이 관리하고, React의 상태로부터 독립적인 상태로 동작합니다. 반대로 Controlled input은 React 상태에 의해 관리되는 입력 요소로, 사용자가 입력한 값이 항상 React의 state에 저장되며 상태에 따라 값이 동적으로 변화합니다.

문제는 다음과 같은 상황에서 발생합니다:

• input 필드가 처음에 undefined 또는 null 값으로 설정되어 uncontrolled로 시작된 후, 나중에 controlled 상태로 변경되는 경우입니다.

경고 메시지

에러 메시지는 다음과 같은 형태로 나타납니다:

이러한 경고는 필드의 value가 처음에 정의되지 않았기 때문에 uncontrolled로 시작하고, 이후에 정의된 값이 할당되면서 controlled 상태로 전환될 때 발생합니다.

문제 해결 방법

문제를 해결하려면 input 필드의 value를 항상 정의된 값으로 초기화해야 합니다. 즉, 빈 문자열('')을 사용하여 controlled 상태를 유지하는 것이 중요합니다.

예를 들어, 다음과 같은 코드를 살펴보겠습니다:

useEffect(() => {
  if (!profile) {
    setProfile({
      name: '',
      nickname: '',
      email: '',
      password: '',
      newPassword: '',
      confirmNewPassword: '',
      profileImage: '', // 빈 문자열로 초기화
      isMarketingAgreed: false // 기본값 false
    })
  }
}, [])

위 코드는 profile 값이 undefined일 경우, setProfile을 호출하여 빈 문자열로 모든 필드를 초기화하는 방법입니다. 이렇게 함으로써 React는 input 요소를 항상 controlled 상태로 유지할 수 있습니다.

이번 주에는 마이 페이지에서 사용자의 프로필 사진을 업데이트하는 기능을 개발하게 되었습니다. 이미지를 저장하기 위해 여러 방법을 고려했는데, 그중 로컬 서버 대신 안정적이고 확장성이 높은 클라우드 스토리지인 AWS S3를 선택하게 되었습니다. AWS S3를 사용하는 방법에 대한 글은 많이 찾아볼 수 있지만, 이번 글에서는 S3를 사용하면서 마주쳤던 문제들과 그 해결 과정에 대해 회고해보려 합니다.

S3 접근 권한 설정

S3 버킷에 파일을 업로드하려면 먼저 해당 버킷에 접근할 수 있는 권한이 필요합니다. 이때 엑세스 키와 시크릿 키라는 두 개의 키가 사용됩니다. 키는 AWS에서 직접 발급할 수 있지만, 보안상 매우 중요한 문제입니다. 만약 키가 외부로 노출된다면, 누군가가 이를 악용해 우리가 모르는 사이 비트코인 채굴 등의 작업을 수행하거나, 막대한 서버 비용을 초래할 수 있습니다.

따라서 절대로 AWS Root 계정으로 발급된 키를 사용해서는 안 됩니다. 대신, S3에만 접근할 수 있는 최소한의 권한을 가진 사용자를 별도로 만들어 그 키를 사용하는 것이 안전합니다. 이를 위해 AWS의 Identity and Access Management(IAM)에서 사용자 그룹을 생성하고, 해당 그룹에 AmazonS3FullAccess 권한을 할당합니다. 이후, 그 그룹에 속한 사용자에게만 엑세스 키를 발급하면, S3 버킷에 대한 안전한 접근이 가능합니다.

IAM에서 권한을 부여하고 키를 발급하는 과정은 다음과 같습니다:

1. AWS 관리 콘솔에서 IAM 대시보드로 이동합니다.
2. 사용자 그룹을 생성하고, AmazonS3FullAccess 권한을 해당 그룹에 할당합니다.
3. 해당 그룹에서 사용자를 생성하고, 그 사용자에게 엑세스 키를 발급합니다.

이제, 이 엑세스 키와 시크릿 키를 사용하여 S3에 접근할 수 있게 됩니다.

GitHub에서의 보안 관리

S3 접근 키를 발급받았다면, 이를 서버에서 안전하게 사용할 방법을 고민해야 합니다. 특히 GitHub에 소스 코드를 올릴 때는 더욱 주의가 필요합니다. 퍼블릭 레포지토리에 키가 노출되면 외부에서 악용될 가능성이 높습니다. 이를 방지하기 위해 GitHub의 Secrets 기능을 활용해 환경 변수를 설정할 수 있습니다. 이렇게 하면 키가 소스 코드에 포함되지 않고도 안전하게 사용할 수 있습니다.

로컬 환경에서는 application.yml 파일을 사용해 키를 관리하는 것이 일반적입니다. 그러나 application.yml 파일이 git ignore에 등록되지 않으면, 실수로 이 파일이 퍼블릭 레포지토리에 노출될 수 있습니다. 이를 방지하기 위해, application-local.yml, application-dev.yml, application-prod.yml처럼 환경별로 파일을 분리하고, application-prod.yml만 실제 서버에 배포하도록 설정하는 것이 좋습니다. 이 방법은 Spring Boot를 사용하는 개발자들에게 특히 유용합니다.

S3 파일 업로드 기능 구현

이제 S3 버킷에 접근하기 위한 설정을 마쳤으니, 본격적으로 파일을 업로드하는 기능을 구현해보겠습니다. 우선, 필요한 의존성을 추가해야 합니다.

Gradle 의존성 추가

S3 파일 업로드를 위해 AWS SDK를 의존성에 추가해야 합니다. Kotlin과 Spring Boot 환경에서 다음과 같이 의존성을 추가할 수 있습니다.

implementation("org.springframework.cloud:spring-cloud-starter-aws:2.2.6.RELEASE")​

application.yml 설정

application.yml 파일에 S3와 관련된 설정 정보를 입력합니다. 여기에서 stack.auto를 false로 설정하여 Spring Boot가 AWS 인프라를 자동으로 구성하지 않도록 해야 합니다. 또한, region.static 값을 ap-northeast-2로 설정하여 S3 버킷의 리전을 서울로 지정합니다.

cloud:
  aws:
    s3:
      bucket: 본인의 버킷 명
    stack.auto: false
    region.static: ap-northeast-2
    credentials:
      accessKey: 본인의 엑세스 키
      secretKey: 본인의 시크릿 키

S3Config 설정 클래스

S3에 접근하기 위한 클라이언트를 설정하는 S3Config 클래스를 작성합니다. 이 클래스는 S3 클라이언트를 Spring 애플리케이션에서 빈으로 등록하여 다른 곳에서 재사용할 수 있게 해줍니다.

@Configuration
class S3Config(
        @Value("\${cloud.aws.credentials.access-key}") private val accessKey: String,
        @Value("\${cloud.aws.credentials.secret-key}") private val secretKey: String,
        @Value("\${cloud.aws.region.static}") private val region: String
) {

    @Bean
    fun amazonS3Client(): AmazonS3Client {
        val awsCredentials = BasicAWSCredentials(accessKey, secretKey)
        return AmazonS3ClientBuilder.standard()
                .withRegion(region)
                .withCredentials(AWSStaticCredentialsProvider(awsCredentials))
                .build() as AmazonS3Client
    }
}

파일 업로드 서비스

S3 버킷에 파일을 업로드하기 위한 서비스 클래스를 작성합니다. 이 클래스에서는 파일을 업로드하고, 업로드된 파일의 URL을 반환하는 기능을 구현합니다.

@Service
class S3ImageUploadService(
        private val amazonS3Client: AmazonS3
) {

    @Value("\${cloud.aws.s3.bucket}")
    private lateinit var bucket: String

    @Throws(IOException::class)
    fun uploadFile(file: MultipartFile): String {
        val fileName = generateFileName(file.originalFilename!!)
        val metadata = ObjectMetadata()
        metadata.contentLength = file.size

        amazonS3Client.putObject(bucket, fileName, file.inputStream, metadata)
        return amazonS3Client.getUrl(bucket, fileName).toString() // 업로드된 파일의 URL 반환
    }

    private fun generateFileName(originalFilename: String): String {
        val fileExtension = originalFilename.substringAfterLast(".")
        return "${UUID.randomUUID()}.$fileExtension"
    }
}

마무리

이 글을 통해 AWS S3를 사용하여 이미지를 업로드하는 방법과, 그 과정에서 발생할 수 있는 보안 문제에 대해 다루었습니다. 특히 IAM 권한 관리와 GitHub 보안 설정에 대한 부분은 꼭 주의해야 할 사항입니다. 이를 통해 AWS S3를 효율적이고 안전하게 사용할 수 있기를 바랍니다.

이번에 새로운 사이드 프로젝트를 진행하면서 Kotlin, JPA, Spring Boot를 활용하게 되었다. 관련 예제 코드를 찾아보니, Kotlin과 JPA로 작성된 Entity 클래스는 보통 아래와 같은 형태로 많이 작성된다.

@Entity
data class Article(
    var slug: String = "",
    var title: String = "",
    var description: String = "",
    var body: String = "",
    @ManyToMany
    val tagList: MutableList<Tag> = mutableListOf(),
    var createdAt: OffsetDateTime = OffsetDateTime.now(),
    var updatedAt: OffsetDateTime = OffsetDateTime.now(),
    @ManyToMany
    var favorited: MutableList<User> = mutableListOf(),
    @ManyToOne
    var author: User = User(),
    @Id @GeneratedValue(strategy = GenerationType.AUTO)
    var id: Long = 0
) {
    fun favoritesCount() = favorited.size
}

Kotlin의 data class에서는 생성자에 var와 val 키워드를 사용하면, 생성자 파라미터와 클래스 변수를 동시에 선언할 수 있다. 이를 통해 작성해야 할 코드 양을 줄일 수 있는 장점이 있다. 그러나 이 방식은 엔티티의 값을 외부에서 쉽게 변경할 수 있는 가능성을 열어두기 때문에, 좋은 설계라고 볼 수 없다. 그렇다면, 어떻게 엔티티 클래스를 작성하는 것이 더 나은 방식일까?

var와 val의 차이점

Kotlin에서 var는 변수의 값을 변경할 수 있게 만들고, val은 초기화된 후 값을 변경할 수 없도록 만든다. 따라서, 변경되지 않아야 할 필드에는 val을 사용하고, 외부에서 변경이 가능한 필드는 var를 사용하게 된다.

변경이 불필요한 필드는 val을 사용하여 불변성을 유지하는 것이 좋지만, JPA Entity에서는 모든 필드를 val로 선언할 수는 없다. 예를 들어, 엔티티의 식별자(id)는 데이터베이스에서 자동 생성되므로, 코드에서 변경할 수 없게 막을 수 없다. 또한, JPA는 기본 생성자와 함께 동작하는 특성이 있으므로, data class보다는 일반 클래스를 사용하는 것이 더 적합할 때가 많다.

개선된 설계1: 불변성을 고려한 엔티티 작성

아래는 JPA와 Kotlin에서 엔티티 설계를 개선한 예시다. var를 최소화하고, setter는 외부에서 호출할 수 없도록 protected로 제한하여 불필요한 변경을 방지한다.

@Entity
class Article(
    slug: String = "",
    title: String = "",
    description: String = "",
    body: String = "",
    @ManyToMany
    val tagList: MutableList<Tag> = mutableListOf(),
    createdAt: OffsetDateTime = OffsetDateTime.now(),
    updatedAt: OffsetDateTime = OffsetDateTime.now(),
    @ManyToOne
    val author: User = User()
) {
    var slug: String = slug
        protected set
    var title: String = title
        protected set
    var description: String = description
        protected set
    var createdAt: OffsetDateTime = createdAt
        protected set
    var updatedAt: OffsetDateTime = updatedAt
        protected set

    @ManyToMany
    var favorited: MutableList<User> = mutableListOf()
        protected set

    @Id @GeneratedValue(strategy = GenerationType.AUTO)
    var id: Long = 0
        protected set

    fun favoritesCount() = favorited.size
}

이 방식은 외부에서 함부로 필드 값을 변경하지 못하게 막으면서, 엔티티의 불변성을 유지할 수 있다. slug, title, description 등은 외부에서 접근은 가능하지만, 값을 변경할 수는 없다. 대신, 비즈니스 로직 내에서 값이 필요할 때만 변경할 수 있다. 하지만 val을 사용하는 변수만 클래스의 생성자에 두는 것은 코드의 일관성이 떨어지게 만들 수 있다 생각한다.

개선된 설계2: 모든 필드를 클래스 내부에서 선언하기

아래는 val과 var 모두를 생성자가 아닌 클래스 내부에 선언하여 관리하는 방식의 예시다. 이 방식은 코드의 구조를 더 명확하게 하고, 엔티티의 불변성을 강력하게 유지할 수 있다.

@Entity
class Article(
    slug: String = "",
    title: String = "",
    description: String = "",
    body: String = "",
    tagList: MutableList<Tag> = mutableListOf(),
    createdAt: OffsetDateTime = OffsetDateTime.now(),
    updatedAt: OffsetDateTime = OffsetDateTime.now(),
    author: User = User()
) {
    var slug: String = slug
        protected set
    var title: String = title
        protected set
    var description: String = description
        protected set
    var body: String = body
        protected set

    @ManyToMany
    val tagList: MutableList<Tag> = tagList
        protected set

    var createdAt: OffsetDateTime = createdAt
        protected set
    var updatedAt: OffsetDateTime = updatedAt
        protected set

    @ManyToMany
    var favorited: MutableList<User> = mutableListOf()
        protected set

    @ManyToOne
    var author: User = author
        protected set

    @Id @GeneratedValue(strategy = GenerationType.AUTO)
    var id: Long = 0
        protected set

    fun favoritesCount() = favorited.size
}

위와 같이 모든 필드를 클래스 내부에서 선언하면, 외부에서 접근할 수 있는 경로를 명확히 제한할 수 있다. 불필요한 수정이 불가능해지며, 엔티티의 일관성이 더욱 강화된다.

리눅스 서버를 운영하면서 로그 분석은 매우 중요한 작업 중 하나입니다. 서버의 상태를 모니터링하고, 문제를 신속하게 해결하기 위해서는 로그 파일을 효율적으로 분석할 수 있어야 합니다. 이번 글에서는 로그 분석에 유용한 주요 리눅스 명령어들을 정리해보았습니다.

1. grep – 텍스트 검색의 기본

로그 분석의 시작은 원하는 정보가 포함된 라인을 찾아내는 것입니다. grep 명령어는 특정 패턴을 포함한 텍스트를 파일에서 검색하는 데 사용됩니다.

• 기본 사용법:

grep "검색할 패턴" 파일명

• 예시:

grep "userId=" 7827540

위 명령어는 7827540 파일에서 userId=를 포함하는 모든 라인을 출력합니다.

유용한 옵션들

• -i: 대소문자를 구분하지 않고 검색
• -r 또는 -R: 디렉토리 내의 파일들을 재귀적으로 검색
• -n: 검색된 라인의 번호를 함께 출력
• --color=auto: 매칭된 부분을 색깔로 강조하여 보여줍니다.

2. awk – 텍스트 처리의 강력한 도구

awk는 로그에서 특정 필드를 추출하거나 조작하는 데 유용한 명령어입니다. 특히, grep과 함께 사용하여 필터링된 결과에서 필요한 부분만 선택할 수 있습니다.

• 기본 사용법:

awk '{ print $필드번호 }' 파일명

• 예시:

grep "userId=" 7827540 | awk '{ print $3 }'

이 명령어는 grep으로 필터링한 후, 세 번째 필드만 출력합니다. 필드에 대한 설명을 좀 더 해보겠습니다.
예를 들어, 다음과 같은 로그 라인이 있다고 가정해 보겠습니다:

2024-08-30 12:34:56 INFO userId=12345 action=login status=success

이 라인을 awk로 처리한다고 할 때:

• 첫 번째 필드는 2024-08-30
• 두 번째 필드는 12:34:56
• 세 번째 필드는 INFO
• 네 번째 필드는 userId=12345

이런 식으로, 공백을 기준으로 라인이 분리되고 각 부분이 필드로 간주됩니다. 따라서 awk '{ print $3 }'는 이 라인에서 INFO를 출력하게 됩니다.

3. cat – 파일 내용 출력

cat은 파일의 내용을 터미널에 출력하는 명령어입니다. 단순히 파일을 읽거나, 여러 파일을 연결하여 출력하는 데 사용됩니다.

• 기본 사용법:

cat 파일명

• 예시:

cat 7827540

이 명령어는 7827540 파일의 모든 내용을 출력합니다.

4. less – 대용량 파일 탐색

로그 파일이 클 때는 less 명령어가 유용합니다. less는 파일 내용을 페이지 단위로 출력하여 한 번에 보기 편하게 해줍니다.

• 기본 사용법:

less /var/log/syslog

• 예시:

less 파일명

이 명령어로 syslog 파일을 페이지 단위로 탐색할 수 있으며, q 키를 눌러 종료할 수 있습니다.

5. tail – 실시간 로그 모니터링

tail 명령어는 파일의 마지막 몇 줄을 출력합니다. 특히, 실시간으로 로그를 모니터링하고자 할 때 유용합니다.

• 기본 사용법: 

tail -f /app/logs/tomcat/tsolution.log

실시간 로그 확인:

tail -f 파일명

예시:

tail -f /app/logs/tomcat/tsolution.log

이 명령어는 tsolution.log 파일의 마지막 부분을 실시간으로 출력합니다.

6. find – 파일 검색

find 명령어는 특정 조건에 맞는 파일을 검색하는 데 사용됩니다. 예를 들어, 로그 파일의 위치를 찾을 때 유용합니다.

• 기본 사용법:

find 디렉토리 -name "파일명"

예시:

find /app/logs/ -name "tsolution.2024-07*"

이 명령어는 /app/logs/ 디렉토리 내에서 tsolution.2024-07로 시작하는 파일들을 검색합니다.

이처럼 리눅스의 다양한 명령어를 활용하면 로그 분석 작업을 훨씬 더 효율적으로 수행할 수 있습니다. 명령어들 간의 조합과 파이프(|)를 활용한 유연한 분석 방법을 익히면, 로그 파일에서 필요한 정보를 빠르게 추출하고 문제를 해결하는 데 큰 도움이 될 것입니다.

이 글이 리눅스 로그 분석을 시작하는 데 유용한 가이드가 되기를 바랍니다!