RSS Feed

URL Shortener

Mon, 19 Jan 2026 00:00:00 GMT

URL Shortener란?

URL Shortener는 긴 URL을 짧은 URL로 변환해주는 서비스다.

이 글에서는 URL Shortener에 대해 정리해보고, 구현 시 고민했던 문제들을 살펴본다.

기능 정의

URL Shortener는 다음의 두 가지 기능을 갖는다.

1. Short URL 생성

입력받은 URL로 Short URL을 생성한다.

2. Short URL 접속 시 원본 URL 리다이렉트

Short URL로 접속하면 원본 URL로 리다이렉트한다.

Data Modeling

기능 요구사항을 충족하려면 어떤 데이터를 저장해야 할까?

먼저 원본 URL, 이와 매핑되는 Short URL을 저장하는 테이블이 하나 필요하다.

URL Shortener는 하나의 원본 URL로 여러 개의 Short URL을 생성할 수 있는데, 이를 통해 각 유입 경로별 클릭 수와 같은 마케팅 지표도 수집 가능하다.

반영하면 URL 매핑과 통계 지표 수집 이라는 관심사를 분리하여 테이블을 분리할 수 있다.

Short URL 생성 방식

Short URL은 고유성을 보장해야 한다. 기본 구조는 다음과 같다.

Short URL에는 Base62 인코딩을 적용하는데, 다음의 문자들로 구성된다.

만약 해시 값을 통해 생성하면 해시 충돌에 의해 중복이 발생할 수 있으므로 별도 처리가 필요하다.

또 다른 방법으로는, ID (Auto Increment) 값을 기반으로 인코딩하는 방식이 있다. 이 방식을 적용하여 URL을 생성하는 기본 아이디어는 다음과 같다.

시퀀스 번호에 따라 문자열의 길이는 늘어난다. 최대 7자리까지의 고유한 URL을 발행한다고 가정하고 계산해보자.

Base62 인코딩으로 7자리 문자열을 생성하면 대략 3.5조 개를 표현할 수 있다.

다만 이 방법을 채택할 경우, Sequence Number를 어떤 방식으로 생성하고 관리할지를 결정해야 한다.

다음의 3가지 방법을 살펴보자.

1. Redis (INCR)

모든 서버가 Redis를 통해 Sequence를 생성하는 방식이다. 레디스의 연산은 원자적이므로 간단하게 구현할 수 있는 것이 장점이다. 다만 중앙 집중 방식이기 때문에 단일 장애점 (SPOF)이 될 수 있다.

2. Snowflake ID

64비트를 timestamp / datacenter / machine ID / sequence로 나눠서 생성하는 방식이다. 분산 환경에서 각 서버가 독립적인 ID 생성을 할 수 있다는 장점이 있다. 또한 timestamp가 반영되므로 시간순 정렬이 가능하다.

3. Machine ID + Sequence Number

Snowflake ID는 64비트를 사용하므로 약 11자리의 URL이 생성된다.

Snowflake ID 방식을 간소화하여 Machine ID + Sequence Number 조합으로 생성하면, 구조를 단순화하면서도 더 짧은 길이(약 7자리)의 ID를 생성할 수 있다.

조회 성능 최적화

URL Shortener의 주요 컴포넌트는 다음과 같이 구성된다.

URL Shortener는 생성보다 조회 연산이 훨씬 많다.

URL은 불변 값이기 때문에, 캐시를 사용하기에 적합하다. Cache-Aside 패턴을 적용하면 DB 부하를 줄이고 조회 성능을 크게 높일 수 있다.

References

Transactional Outbox Pattern 알아보기

Wed, 14 Jan 2026 00:00:00 GMT

이중 쓰기(Dual Write)란 하나의 비즈니스 로직에서 둘 이상의 시스템에 데이터를 쓰는 작업이다. 이 방식은 서로 다른 시스템에 데이터를 쓰기 때문에 원자성을 보장하지 못하고 정합성이 훼손될 수 있다.

Transactional Outbox Pattern은 이 문제를 해결할 수 있는 방법 중 하나다.

이 글에서는 Outbox Pattern이 무엇인지 알아보고, 원자성 및 정합성 문제를 어떻게 해결하는지 살펴본다.

Dual Write Problem

MSA 환경에서 DB에 데이터를 저장하고 메시지 브로커를 통해 이벤트를 다른 서비스로 전파하는 경우, 다음의 시나리오가 모두 발생할 수 있다.

DB 저장(O), 이벤트 발행(O)
DB 저장(O), 이벤트 발행(X)
DB 저장(X), 이벤트 발행(O)
DB 저장(X), 이벤트 발행(X)

1번과 같은 정상 케이스를 제외한 2, 3, 4번 모두 시스템 간 데이터 정합성을 지킬 수 없게 된다.

이 문제의 근본적인 원인은 DB와 메시지 브로커가 서로 다른 트랜잭션 경계를 가지기 때문이다. 결국 두 작업을 하나의 원자적 연산으로 처리할 방법이 필요하다.

Transactional Outbox Pattern

Outbox Pattern은 메시지를 외부 시스템에 직접 발행하지 않는다. 그 대신 동일 DB 내 별도 Outbox 테이블에 이벤트와 관련 정보를 저장한다.

동일 트랜잭션 내에서 데이터 처리와 이벤트 저장이 동시에 발생하기 때문에 원자성을 보장할 수 있는 것이다.

Outbox Pattern의 동작 과정은 다음과 같다.

데이터 변경 시점에 Outbox 테이블에 이벤트를 함께 저장한다.
별도 프로세스(Message Relay)가 주기적으로 Outbox 테이블을 읽는다.
Outbox 테이블에서 조회한 이벤트를 메시지 브로커로 발행한다. 발행이 성공하면 Outbox 테이블의 해당 이벤트를 처리 완료 상태로 변경한다.
컨슈머에서 발행된 이벤트를 처리한다.

이제 간단한 코드 구현을 통해 Outbox Pattern을 적용해보자.

enum class AggregateType { ORDER, PAYMENT }

enum class EventType { ORDER_CREATED, ORDER_CANCELLED }

enum class OutboxStatus { PENDING, COMPLETED, FAILED }

@Entity
class OutboxEvent(

  @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
  val id: Long = 0,

  @Enumerated(EnumType.STRING)
  val aggregateType: AggregateType,

  val aggregateId: String,

  @Enumerated(EnumType.STRING)
  val eventType: EventType,

  val payload: String,

  @Enumerated(EnumType.STRING)
  var status: OutboxStatus,

  val createdAt: LocalDateTime
)

Outbox Pattern의 핵심은 데이터 처리와 이벤트 저장을 동일 트랜잭션 내에서 수행하는 것이다. 주문 저장과 Outbox 데이터 저장이 모두 같은 트랜잭션에서 실행된다. 둘 중 하나라도 실패하면 모두 롤백된다.

data class OrderCreatedEvent(
  val orderId: Long,
  val productId: Long,
  val quantity: Int
)

@Service
class OrderService(
    private val orderRepository: OrderRepository,
    private val outboxEventRepository: OutboxRepository,
    private val objectMapper: ObjectMapper
) {
    @Transactional
    fun createOrder(productId: Long, quantity: Int): Order {
      val order = orderRepository.save(
          Order(productId = productId, quantity = quantity)
      )

      val event = OrderCreatedEvent(
          orderId = order.id,
          productId = order.productId,
          quantity = order.quantity
      )

      outboxEventRepository.save(
          OutboxEvent(
              aggregateType = AggregateType.ORDER,
              aggregateId = order.id.toString(),
              eventType = EventType.ORDER_CREATED,
              payload = objectMapper.writeValueAsString(event)
          )
      )

      return order
    }
}

저장된 이벤트는 Message Relay 컴포넌트가 별도 프로세스에서 조회한다. 조회된 이벤트는 메시지 브로커에 발행한다.

아래는 Relay의 간단한 예시 코드이다.

@Component
class MessageRelay(
    private val outboxRepository: OutboxRepository,
    private val kafkaTemplate: KafkaTemplate<String, String>
) {
    private val logger = LoggerFactory.getLogger(javaClass)

    @Scheduled(fixedDelay = 1000)
    @Transactional
    fun publish() {
        val events = outboxRepository.findByStatus(OutboxStatus.PENDING)

        events.forEach { event ->
            try {
                kafkaTemplate.send(
                  "order-events",
                  event.aggregateId,
                  event.payload
                )
                event.status = OutboxStatus.COMPLETED
            } catch (e: Exception) {
                logger.error("Failed to publish event: ${event.id}", e)
                event.status = OutboxStatus.FAILED
            }
        }
    }
}

지금까지 Outbox Pattern을 간단한 예시 코드로 살펴보았다.

위 구현에는 몇 가지 고려해야 할 점이 있다.

MessageRelay가 이벤트를 발행한 후 상태 변경 전 장애가 발생하면, 같은 이벤트가 중복 발행될 수 있다.
여러 이벤트가 동시에 처리되면 순서가 보장되지 않을 수 있다.

이 문제의 해결 방법을 살펴보자.

멱등성

멱등성이란 동일한 연산을 몇 번 하더라도 결과가 동일함을 보장하는 성질이다. 그럼 Outbox Pattern에서 멱등성을 보장하기 위해서는 어떻게 해야 할까?

각 Outbox Event는 고유한 id 값을 갖는다. 따라서 메시지를 소비하는 쪽에서 이벤트 식별자를 저장해두고, 처리 시마다 처리된 이력이 있는지 조회하면 된다.

만약 이미 처리된 이력이 있는 경우 해당 이벤트를 무시하고, 없는 경우 이벤트 ID를 저장하고 처리한다. 이를 코드에 적용해보면 다음과 같다.

@Entity
class DomainEventLog(
  @Id
  val eventId: Long,

  val createdAt: LocalDateTime = LocalDateTime.now()
)

@Service
class OrderEventConsumer(
    private val domainEventLogRepository: DomainEventLogRepository,
    private val inventoryService: InventoryService
) {
    @KafkaListener(topics = ["order-events"])
    @Transactional
    fun consume(message: String, @Header("eventId") eventId: Long) {
        if (domainEventLogRepository.existsByEventId(eventId)) {
          return
        }

        val event = objectMapper.readValue(message, OrderCreatedEvent::class.java)
        inventoryService.decreaseStock(event.productId, event.quantity)

        domainEventLogRepository.save(DomainEventLog(eventId = eventId))
    }
}

순서 보장

여러 이벤트가 동시에 발행되면 순서가 보장되지 않을 수 있다.

예를 들어 같은 주문에 대해 생성, 취소 이벤트가 발생할 수 있다. 만약 두 이벤트가 순서대로 처리되지 않으면, 데이터 정합성이 훼손된다.

Kafka와 같은 메시지 브로커는 같은 파티션 내에서의 메시지 순서를 보장한다.

앞선 코드 예시에서는 aggregateId 값을 파티션 키로 사용하면, 같은 aggregate 내에서 처리 순서를 보장할 수 있다.

kafkaTemplate.send(
  "order-events",
  event.aggregateId,  // 같은 파티션 키를 사용하면 동일한 파티션으로 전송된다.
  event.payload
)

References

Cache Stampede 알아보기

Sun, 11 Jan 2026 00:00:00 GMT

Cache Stampede는 캐시가 만료되는 순간, 다수의 요청이 DB로 몰리는 현상이다. 이는 캐시를 활용하고 있음에도 DB에 부하를 주며, 장애로 이어질 수 있다.

이 글에서는 구체적인 발생 원인과 해결 방법을 다룬다.

Cache Stampede 발생 원인

보통 변경이 빈번하지 않은 데이터는 조회 시 Cache Aside 패턴을 적용하기 때문에 DB를 직접 조회하는 빈도가 낮다. 하지만 캐시가 만료되는 순간, 해당 데이터를 조회하는 모든 요청이 순간적으로 DB에 집중될 수 있다.

이 현상은 다음 조건에 해당 될 때 발생한다.

Hot Key : 특정 키에 요청이 집중된다.
TTL 만료 : 해당 키의 캐시가 만료된다.
높은 트래픽 (동시 요청) : 만료 시점에 다수의 요청이 들어온다.

Cache Aside 패턴의 한계

Cache Aside 패턴의 핵심 로직은 다음과 같다.

캐시에서 데이터를 조회한다.
데이터가 캐시에 있으면 바로 반환한다.
만약 데이터가 없다면, DB에서 원본 데이터를 조회 후 캐시에 저장한 뒤 반환한다.

문제는 3번에서 발생한다. 캐시 미스가 발생하면 모든 요청은 독립적으로 각자 DB를 직접 조회한다. 요청 간 'DB를 조회하는 상태'를 공유하지 않기 때문이다.

초당 1000건의 요청이 발생한다고 가정하면, 캐시가 만료되는 순간 1000개의 동일한 DB 조회가 발생한다. 첫 번째 요청이 캐시에 데이터를 다시 저장하기 전까지 나머지 999개의 요청도 캐시 미스를 겪게 되고, 결국 DB를 조회하게 되는 것이다.

즉, Cache Stampede 문제를 해결하기 위해서는 '동시에 여러 요청이 DB에 접근하는 것'을 막으면 된다.

이를 위한 몇 가지 해결 방법을 알아보자.

Cache Stampede 해결 방법

1. Lock (Mutex)

Cache miss가 발생하면 하나의 요청만 DB를 조회하고, 나머지는 대기한다.

첫 번째 요청이 DB에서 데이터를 가져와서 캐시에 데이터를 저장하면, 대기 중이던 요청은 캐시에서 데이터를 즉시 조회할 수 있다.

fun retrieveData(key: String): Data {
    // 1. 캐시에서 데이터를 조회한다. 존재하면 즉시 반환한다.
    cache.get(key)?.let { return it }

    // 2. 캐시에 데이터가 없으면 락 획득을 시도한다.
    val lock = redisLockRegistry.obtain(key)
    if (lock.tryLock(3, TimeUnit.SECONDS)) {
        try {
            // 3. 락을 획득한 사이 다른 요청이 캐시에 저장했을 수 있으므로 다시 확인한다.
            cache.get(key)?.let { return it }

            // 4. DB에서 데이터를 조회하고, 캐시에 저장한다.
            val data = db.findBy(key)
            cache.put(key, data, Duration.ofMinutes(5))

            return data
        } finally {
            lock.unlock()
        }
    }

    // 5. 락 획득에 실패하면 잠시 대기 후 재시도한다.
    Thread.sleep(100)
    return retrieveData(key)
}

단, 락을 획득하지 못한 요청은 대기해야 하므로 응답 지연이 발생 할 수 있다.

2. PER (Probabilistic Early Recomputation)

캐시가 만료되기 전에 미리 갱신하는 방식이다. 확률적 갱신을 적용하며, TTL이 적게 남을수록 확률이 높아진다.

만료전에 캐시를 갱신한다는 점, 모든 요청이 갱신하는 것이 아닌 특정 확률로 동작한다는 점에서 Stampede 현상을 방지할 수 있다.

fun retrieveData(key: String): Data {
    // 1. 캐시에서 데이터와 메타정보를 조회한다.
    val cached = cache.getWithMetadata(key)
        ?: run {
            // 2. 캐시 미스 시 DB에서 조회 후 저장한다.
            val start = System.currentTimeMillis()
            val data = db.findBy(key)
            val queryTime = System.currentTimeMillis() - start

            cache.put(key, data, Duration.ofMinutes(5), queryTime)

            return data
        }

    // 3. 만료 전 갱신이 필요한지 확률적으로 계산한다.
    val ttlRemaining = cached.ttl.toSeconds()
    // `BETA`는 갱신 적극성을 조절하는 상수로, 일반적으로 1.0을 사용한다.
    val threshold = cached.queryTime * BETA * (-Random.nextDouble())

    // 4. TTL이 적게 남을수록 갱신 확률이 높아진다.
    if (ttlRemaining + threshold <= 0) {
        refreshAsync(key)
    }

    return cached.data
}

3. TTL Jitter

동일한 TTL을 여러 키에 부여하면, 동시에 다수의 키가 만료될 수 있다.

TTL Jitter는 만료 시간을 분산시켜서 Stampede 현상을 방지하는 방법이다. 캐시 만료 시간에 랜덤 값을 추가하는 방식으로 구현한다.

fun cache(key: String, data: Data, ttl: Duration) {
    // TTL에 +- 10% 범위에서 무작위 값을 추가한다.
    val jitterRange = ttl.toMillis() * 0.1
    val jitter = (Random.nextDouble() * 2 - 1) * jitterRange
    val actualTtl = ttl.toMillis() + jitter.toLong()

    cache.put(key, data, Duration.ofMillis(actualTtl))
}

References

Java Annotation

Sun, 10 Mar 2024 00:00:00 GMT

스프링을 사용해서 개발을 하다보면 @RestController @Service @Component 같은 Annotation을 자주 접하게 된다. 스프링에서는 이러한 Annotation들을 컴포넌트 스캔 과정에서 메타 정보로 활용하고, 빈을 생성하여 IoC 컨테이너를 구성한다. 이처럼 어노테이션은 코드의 메타 데이터를 제공하는 역할을 한다.

어노테이션을 활용하면 컴파일 타임, 실행 시점에 해당 메타 정보를 제공하여 동적으로 특정 코드를 생성하거나 기능을 수행시킬 수 있다.

본 글에서는 어노테이션을 구성하는 각 요소들과 커스텀 어노테이션 생성 방법을 정리해보고자 한다.

Annotation

어노테이션을 정의 할때는 Java에 내장된 몇 가지 메타 어노테이션들을 같이 활용한다. 자주 사용되는 메타 어노테이션은 다음과 같다.

@Retention : 컴파일 ~ 런타임 과정 중 어느 단계까지 유지되어야 하는지를 결정한다.
@Target : 어노테이션 선언이 가능한 위치 정보를 설정한다.
@Documented : Javadoc에 관련 정보를 함께 생성할 것인지 여부를 결정한다.
@Inherited : 상위 타입에 어노테이션이 적용되어 있는 경우, 하위 타입에 이를 전파할 것인지 결정한다.

@Target({ElementType.TYPE, ElementType.METHOD})
@Inherited
@Documented
@Retention(RetentionPolicy.RUNTIME)
public @interface ExampleAnnotation {

    String value() default "This is example.";

    boolean visible() default true;
}

@Retention

Java는 소스 코드를 작성하고, 작성된 소스 코드를 컴파일하고, 컴파일 된 바이트 코드가 클래스 로더에 의해 JVM에 올라가는 과정을 거쳐서 실행된다.

여기서 @Retention 은 Annotation이 어느 단계까지 유지되어야 하는지를 결정한다. SOURCE, CLASS, RUNTIME 세가지 타입이 있다.

RetentionPolicy.SOURCE

컴파일 단계에서 컴파일러게 관련 정보를 제공하지만, 바이트 코드(.class)에는 기록되지 않는다 익숙한 @Override로 예를 들어보면, 서브 타입에서 메서드 오버라이딩을 하는 경우, @Override 가 선언되어 있다면 컴파일 타임에 메서드 시그니처가 잘 선언되어 있는지 검증한다. 그러나 바이트 코드에는 @Override가 남아있지 않다.

RetentionPolicy.CLASS

컴파일 단계를 거쳐 바이트 코드까지 유지되지만 런타임에는 유지되지 않는다.

RetentionPolicy.RUNTIME

런타임까지 유지되며, 리플렉션을 통해 해당 메타 정보에 접근할 수 있다.

CLASS VS RUNTIME

CLASS와 RUNTIME 의 중요한 차이점은 리플렉션 활용 가능 여부이다. RUNTIME으로 선언되어야만 실행 중에도 해당 메타 정보를 활용할 수 있다.

코드를 통해 확인해보자.

RetentionPolicy.CLASS

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.CLASS)
public @interface ClassRetentionAnnotation {

}

@ClassRetentionAnnotation
public class ClassRetentionTarget {

}

class ReflectionTest {

    @Test
    void doClassRetentionTest() {
        ClassRetentionAnnotation annotation = ClassRetentionTarget.class.getAnnotation(ClassRetentionAnnotation.class);

		// RetentionPolicy.CLASS 인 경우 리플렉션으로 활용 불가
        then(annotation).isNull();
    }

RetentionPolicy.RUNTIME

@Retention(RetentionPolicy.RUNTIME)
public @interface RuntimeRetentionAnnotation {

}

@RuntimeRetentionAnnotation
public class RuntimeRetentionTarget {

}

class ReflectionTest {

    @Test
    void doRuntimeRetentionTest() {
        RuntimeRetentionAnnotation annotation = RuntimeRetentionTarget.class.getAnnotation(RuntimeRetentionAnnotation.class);

        then(annotation).isNotNull();
    }
}

@Target

어노테이션이 어디에 위치할 수 있는지를 결정한다. 하고, 메서드에 적용하기 위해서는 ElementType.METHOD 가 필요하다. 타겟은 여러개 지정 가능하며 다음과 같이 선언한다.

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.SOURCE)
public @interface MultipleTargetAnnotation {

	// ...
}

ElementType	Description
`TYPE`	클래스, 인터페이스, 어노테이션 타입, 열거 타입에 적용
`FIELD`	필드(멤버 변수)에 적용
`METHOD`	메서드에 적용
`PARAMETER`	메서드 파라미터에 적용
`CONSTRUCTOR`	생성자에 적용
`LOCAL_VARIABLE`	지역 변수에 적용
`ANNOTATION_TYPE`	어노테이션에 적용
`PACKAGE`	패키지 선언에 적용
`TYPE_PARAMETER`	제네릭 타입 선언의 타입 파라미터 (클래스, 메서드) (Java 8 이상)
`TYPE_USE`	필드, 메서드 리턴 타입, 메서드 파라미터, 생성자 파라미터 등 타입 사용의 모든 경우에 적용 가능 (Java 8 이상)
`MODULE`	모듈 선언 파일 (module-info.java)에 적용 (Java 9 이상)
`RECORD_COMPONENT`	레코드의 각 컴포넌트(레코드 내에 선언된 필드)에 적용 가능 (Java 16이상)

Element

어노테이션 내부에 요소들을 정의하고, 어노테이션이 사용되는 선언부에 특정 값을 할당하여 사용할 수 있다. 해당 메타 정보들은 런타임에 리플렉션을 통해 접근 할 수 있다. Element는 반환 타입, 참조 될 이름, 기본 값 으로 구성된다.

// ...
public @interface ExampleAnnotation {

	/**
	 * Element 1
	 */
    String value() default "This is example.";

	/**
	 * Element 2
	 */
	boolean visible() default true;
}

첫 번째 요소인 value 에는 기본 값으로 This is example. 이 설정되어있고, visible 에는 true가 지정되어 있다.

만약 다음과 같이 value에 다른 값을 할당하면 value 에는 해당 값이 저장된다. 반면 visible에는 별도 값을 지정하지 않았기 때문에 기본 값으로 설정되어 있는 true가 유지된다.

@ExampleAnnotation(value = "This is value.")
public class ExampleAnnotationTarget {

}

class AnnotationElementTest {

    @Test
    void doTest() {
        ExampleAnnotation annotation = ExampleAnnotationTarget.class.getAnnotation(ExampleAnnotation.class);

        // value에 지정한 값을 참조한다.
        then(annotation.value()).isEqualTo("This is value.");

        // visible에 default로 선언된 true 값을 가진다.
        then(annotation.visible()).isTrue();
    }
}

@Documented

만약 @Documented가 선언되어 있는 경우, Javadoc에 해당 어노테이션 정보를 함께 기록한다.

@Target({ElementType.TYPE, ElementType.METHOD})
@Documented   // <-
@Retention(RetentionPolicy.RUNTIME)
public @interface ExampleAnnotation {

    String value() default "This is example.";

    boolean visible() default true;
}

/**
 *  `@ExampleAnnotation`에 `@Documented` 가 선언되어 있는 경우
 *   `ExampleAnnotationTarget`의 Javadoc에
 *   어노테이션 정보가 추가된다.
 */
@ExampleAnnotation(value = "This is value.")
public class ExampleAnnotationTarget {

}

만약 @Documented 가 없는 경우, 아래와 같이 @ExampleAnnotation 정보를 찾을 수 없다.

@Inherited

@Inherited 는 서브 타입으로의 어노테이션 전파 여부를 결정한다. 만약 어노테이션에 @Inherited 가 선언되어 있다면 하위 클래스에 직접 선언하지 않더라도 해당 어노테이션이 동일하게 적용된다.

@Target(ElementType.TYPE)
@Inherited
@Retention(RetentionPolicy.RUNTIME)
public @interface ParentAnnotation {

}

@ParentAnnotation
public class ParentClass {

}

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface ChildAnnotation {

}

/**
 *  `@ParentAnnotation`이 선언되어 있지 않다.
 */
@ChildAnnotation
public class ChildClass extends ParentClass {

}

class InheritedAnnotationTest {

    @Test
    void doTest() {
        ParentAnnotation parentAnnotation = ChildClass.class.getAnnotation(ParentAnnotation.class);
        ChildAnnotation childAnnotation = ChildClass.class.getAnnotation(ChildAnnotation.class);

		/**
		 *  ChilClass에 `@ParentAnnotation`이 없음에도
		 *  직접 참조할 수 있다.
		 */
        then(parentAnnotation).isNotNull();
        then(childAnnotation).isNotNull();
    }
}

만약 @ParentAnnotation에 선언되어 있는 @Inherited 를 제거하면, 아래와 같이 테스트가 실패하게 된다.

Custom Annotation 생성 및 적용 예시

지금까지 어노테이션 관련 기본 내용들을 살펴보았다. 지금부터는 커스텀한 어노테이션을 직접 재정의 해보면서 해당 내용들을 다시 해당 예시에서는 기존에 익숙하게 사용했을 법한 @Transactional 어노테이션을 활용하였다.

JPA를 사용할 때 데이터 읽기 작업만을 수행하는 경우, 불필요한 더티 체킹이 발생하지 않도록 @Transactional(readOnly=true) 를 지정한다.

이를 커스텀한 어노테이션으로 재정의하고 사용해보자.

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Transactional(readOnly = true)
public @interface ReadOnlyTransactional {

}

@Target : 기존 @Transactional 과 동일하게 클래스, 메서드에 모두 사용할 수 있도록 ElementType.TYPE, ElementType.METHOD 를 속성으로 지정하였다.
@Retention : 런타임에 참조될 수 있도록 하기 위해 RetentionPolicy.RUNTIME 을 설정하였다.

@Service
public class TransactionService {

	/**
	 * `@Transactional(readOnly=true)`과 동일한 동작을 한다.
	 */
    @ReadOnlyTransactional
    public boolean isReadOnlyTransaction() {
        return TransactionSynchronizationManager.isCurrentTransactionReadOnly();
    }
}

@SpringBootTest
class TransactionServiceTest {

    @Autowired
    private TransactionService transactionService;

    @Test
    void readOnlyTransactionTest() {
        boolean readOnlyTransaction = transactionService.isReadOnlyTransaction();

        then(readOnlyTransaction).isTrue();
    }
}

References

About

Mon, 01 Jan 2024 00:00:00 GMT

Backend Engineer

Default Private

Mon, 01 Jan 2024 00:00:00 GMT

Default Private Posts

This is a default private post. It's recommended not to delete this posts 😵

(현재 이 포스트는 삭제하지 말아주세요.)