To Be Continued

Terraform을 사용하는 이유

kinim329 — Wed, 13 May 2026 23:50:58 +0900

어제는 Terraform이 인프라를 코드로 관리하는 도구라는 것을 정리했다.

오늘은 Terraform을 왜 사용하는지에 대해 정리해보려고 한다.

인프라를 직접 만들 때의 문제

AWS에서 EC2를 만든다고 하면 콘솔에 들어가서 직접 설정을 선택해야 한다.

인스턴스 타입을 고르고, VPC와 서브넷을 선택하고, 보안 그룹을 만들고, 필요한 포트를 열어야 한다.

처음에는 크게 어렵지 않지만, 서버가 여러 개가 되면 문제가 생긴다.

어떤 설정으로 만들었는지 기억하기 어렵고, 사람이 직접 클릭해서 만들다 보면 설정이 조금씩 달라질 수 있다.

예를 들어 A 서버는 8080 포트가 열려 있는데, B 서버는 빠져 있을 수도 있다.

이런 차이는 나중에 배포나 운영 과정에서 예상하지 못한 오류로 이어질 수 있다.

Terraform을 사용하면 좋은 점

Terraform을 사용하면 인프라 설정을 코드로 남길 수 있다.

즉, EC2를 몇 개 만들지, 어떤 인스턴스 타입을 사용할지, 어떤 보안 그룹을 적용할지 등을 파일에 작성한다.

이렇게 하면 인프라 설정이 코드로 남기 때문에 나중에 다시 확인하기 쉽다.

또한 Git으로 관리할 수 있기 때문에 누가 언제 어떤 인프라 설정을 변경했는지도 추적할 수 있다.

원하는 상태를 기준으로 동작한다

Terraform의 중요한 특징은 “원하는 상태”를 기준으로 동작한다는 점이다.

예를 들어 코드에 EC2 인스턴스가 1개 필요하다고 작성되어 있는데 실제 AWS에는 없다면, Terraform은 EC2를 새로 생성한다.

반대로 코드에서 인스턴스 타입을 변경하면 Terraform은 현재 상태와 코드의 차이를 비교해서 변경이 필요한 부분을 알려준다.

이때 사용하는 명령어가 terraform plan이다.

terraform plan

이 명령어를 실행하면 실제로 적용하기 전에 어떤 리소스가 생성, 수정, 삭제될지 미리 확인할 수 있다.

그리고 문제가 없으면 다음 명령어로 실제 적용한다.

terraform apply

Terraform State

Terraform은 현재 인프라 상태를 기억하기 위해 State 파일을 사용한다.

이 파일에는 Terraform이 관리하는 리소스 정보가 저장된다.

예를 들어 어떤 EC2 인스턴스를 만들었는지, 어떤 보안 그룹을 만들었는지 같은 정보가 들어간다.

Terraform은 이 State 파일과 코드, 실제 인프라 상태를 비교해서 변경 사항을 판단한다.

그래서 State 파일은 Terraform에서 매우 중요하다.

혼자 테스트할 때는 로컬에 State 파일을 둘 수 있지만, 팀 프로젝트에서는 S3 같은 원격 저장소에 보관하는 경우가 많다.

그래야 여러 사람이 같은 인프라 상태를 기준으로 작업할 수 있다.

Terraform 개념 정리

kinim329 — Tue, 12 May 2026 22:32:06 +0900

Terraform이란

Terraform은 인프라를 코드로 관리할 수 있게 해주는 도구이다.

서버, 네트워크, 데이터베이스, 보안 그룹 같은 인프라 자원을 직접 콘솔에서 클릭해서 만드는 것이 아니라, 코드로 작성해서 생성하고 관리할 수 있다.

이런 방식을 IAC라고 한다.

IaC는 Infrastructure as Code의 약자이고 한국어로는 코드형 인프라라고 볼 수 있다.

기존 방식의 문제점

예를 들어 AWS EC2 서버를 만든다고 하면 보통은 AWS 콘솔에 들어가서 직접 설정을 선택한다.

인스턴스 타입을 고르고, 키 페어를 선택하고, 보안 그룹을 만들고, 포트를 열고, VPC나 서브넷을 설정한다.

처음 한 번은 괜찮지만 서버가 여러 개가 되거나, 같은 환경을 다시 만들어야 할 때 문제가 생긴다.

어떤 설정으로 만들었는지 기억하기 어렵고, 사람이 직접 설정하다 보면 실수도 생길 수 있다.

Terraform을 사용하면

erraform을 사용하면 이런 인프라 설정을 코드로 작성할 수 있다.

예를 들어 다음과 같은 내용을 코드로 작성할 수 있다.

resource "aws_instance" "app_server" {
  ami           = "ami-xxxxxx"
  instance_type = "t2.micro"
}

이 코드는 AWS EC2 인스턴스를 만들겠다는 의미이다.

즉, Terraform 파일을 작성하고 실행하면 코드에 적힌 내용대로 인프라가 생성된다.

Terraform과 GitHub Actions의 차이

Terraform은 서버나 네트워크 같은 인프라를 만드는 도구이다.

GitHub Actions는 빌드, 테스트, 배포 같은 작업을 자동화하는 도구이다.

즉, 둘의 역할은 다르다.

Terraform은 “서버를 만든다”에 가깝고, GitHub Actions는 “코드를 서버에 배포한다”에 가깝다.

그래서 실제 프로젝트에서는 Terraform으로 EC2, 보안 그룹 같은 인프라를 만들고, GitHub Actions로 애플리케이션을 배포하는 식으로 함께 사용할 수 있다.

Jenkins 개념 정리

kinim329 — Mon, 11 May 2026 23:24:10 +0900

Jenkins란?

Jenkins는 CI/CD를 자동화해주는 도구이다.

개발자가 코드를 GitHub에 push하면, Jenkins가 그 변경사항을 감지해서 자동으로 빌드, 테스트, 배포 같은 작업을 실행할 수 있다.

예를 들면 원래는 개발자가 직접 해야 하는 작업이 있다.

코드 pull 받기
프로젝트 빌드하기
테스트 실행하기
서버에 배포하기

Jenkins를 사용하면 이 과정을 자동화할 수 있다.

Github Push → Jenkins 실행 → Build → Test → Deploy

왜 사용할까?

프로젝트가 커질수록 매번 직접 빌드하고 배포하는 것은 번거롭고 실수도 생기기 쉽다.

예를 들어 배포할 때 테스트를 깜빡하거나, 잘못된 파일을 서버에 올릴 수 있다.

Jenkins는 정해진 절차대로 자동 실행되기 때문에 이런 실수를 줄일 수 있다.

로그 레벨

kinim329 — Sun, 10 May 2026 23:21:23 +0900

로그 레벨이란?

로그 레벨은 로그의 중요도나 목적에 따라
로그를 구분해서 남기는 기준이다.

모든 로그가 같은 의미를 가지는 것은 아니다.

단순히 흐름을 확인하기 위한 로그도 있고,
문제가 발생했을 때 반드시 확인해야 하는 로그도 있다.

그래서 로그를 남길 때는 상황에 맞게
info, warn, error 같은 레벨을 구분해서 사용한다.

로그 레벨을 나누는 이유

로그 레벨을 나누지 않고 모든 내용을 똑같이 남기면
중요한 로그와 덜 중요한 로그를 구분하기 어렵다.

예를 들어 정상적인 요청 처리 로그와
실제 장애가 발생한 로그가 같은 수준으로 남는다면,
문제가 생겼을 때 원인을 찾기 힘들어진다.

로그 레벨을 나누면 다음과 같은 장점이 있다.

정상 흐름과 오류 상황을 구분할 수 있다
운영 환경에서 필요한 로그만 확인할 수 있다
문제가 발생했을 때 중요한 로그를 빠르게 찾을 수 있다

info

info는 애플리케이션의 정상적인 주요 흐름을 기록할 때 사용한다.

예를 들어 사용자가 계좌 생성을 요청했거나,
매수 요청이 정상적으로 들어온 경우에 사용할 수 있다.

log.info("계좌 생성 요청 userId={}", userId);
log.info("매수 요청 accountId={}, stockCode={}", accountId, stockCode);

info는 에러가 아니라
정상적으로 진행된 중요한 이벤트를 남기는 용도이다.

warn

warn은 당장 시스템이 멈추는 에러는 아니지만,
주의가 필요한 상황에서 사용한다.

예를 들어 요청 값이 이상하거나,
예상과 다른 상황이 발생했지만 처리는 가능한 경우에 사용할 수 있다.

log.warn("잔액 부족으로 매수 실패 accountId={}, balance={}", accountId, balance);

이 경우 서버가 죽은 것은 아니지만,
사용자의 요청이 정상적으로 처리되지 않았기 때문에
나중에 확인할 필요가 있다.

error

error는 실제 예외가 발생했거나,
기능이 정상적으로 처리되지 못한 경우에 사용한다.

예를 들어 DB 저장 실패, 외부 API 호출 실패,
예상하지 못한 예외가 발생한 경우에 사용할 수 있다.

try {
    accountService.createAccount(userId);
} catch (Exception e) {
    log.error("계좌 생성 실패 userId={}", userId, e);
    throw e;
}

error 로그에는 예외 객체 e를 함께 넘기는 것이 좋다.
그래야 어떤 예외가 발생했는지와 어디서 발생했는지 확인할 수 있다.

로그 찍기의 중요성

kinim329 — Sat, 9 May 2026 23:47:56 +0900

로그란?

로그는 애플리케이션이 실행되는 동안
어떤 일이 발생했는지 기록해두는 정보이다.

예를 들면 다음과 같은 내용을 남길 수 있다.

log.info("계좌 생성 요청 userId={}", userId);
log.error("계좌 생성 실패 userId={}", userId, e);

단순히 코드가 실행됐는지 확인하는 용도뿐만 아니라,
나중에 문제가 발생했을 때 원인을 찾기 위한 기록으로 사용된다.

왜 로그가 중요할까?

개발 중에는 디버거를 사용해서 코드를 한 줄씩 확인할 수 있다.

하지만 실제 서버에서는 사용자의 요청이 계속 들어오고,
문제가 언제 어디서 발생했는지 바로 알기 어렵다.

이때 로그가 없으면 다음과 같은 문제가 생긴다.

요청이 들어왔는지 모름
어디서 실패했는지 모름
어떤 데이터로 실패했는지 모름
예외가 왜 발생했는지 모름

결국 코드를 다시 추측하면서 확인해야 한다.

반대로 로그가 잘 남아 있으면
문제가 발생한 흐름을 따라가면서 원인을 빠르게 찾을 수 있다.

예시

계좌 생성 기능에서 에러가 발생했다고 가정해보자.

로그가 없다면 단순히 이런 결과만 보게 된다.

500 Internal Server Error

하지만 로그를 남겨두면 다음처럼 확인할 수 있다.

log.info("계좌 생성 요청 userId={}, competitionId={}", userId, competitionId);

try {
    accountService.createAccount(userId, competitionId);
} catch (Exception e) {
    log.error("계좌 생성 실패 userId={}, competitionId={}", userId, competitionId, e);
    throw e;
}

이렇게 하면 어떤 사용자의 요청에서 문제가 발생했는지,
어떤 대회 계좌를 생성하다 실패했는지 확인할 수 있다.

주의할 점

로그는 많이 찍는다고 무조건 좋은 것은 아니다.

너무 많은 로그는 오히려 중요한 정보를 찾기 어렵게 만든다.

또한 비밀번호, 토큰, 개인정보 같은 민감한 값은
절대 로그에 남기면 안 된다.

// 좋지 않은 예
log.info("로그인 요청 password={}", password);

로그는 문제를 해결하기 위한 정보만 적절히 남기는 것이 중요하다.

대회 종료 시 최종 자산 정산 고도화

kinim329 — Fri, 8 May 2026 16:22:32 +0900

배경

antcamp은 가상 주식 대회 플랫폼이다. 대회가 종료되면 모든 참가자의 최종 총자산을 계산해 순위를 확정해야 한다.

총자산은 아래 공식으로 계산된다.

총자산 = 현금 잔액 + (보유 종목별 확정가 × 보유 수량)

이때 확정가는 대회 종료 시점의 실제 주가여야 하므로, 한투(한국투자증권) API를 호출해 가격을 가져와야 한다.

문제

캐싱 전 이미지 삽입

단순하게 구현하면 참가자 수 × 보유 종목 수만큼 한투 API를 호출하게 된다.

예를 들어 참가자 100명이 각자 5개 종목을 보유하고 있다면 최대 500번 API를 호출해야 한다.

이 방식에는 두 가지 문제가 있다.

한투 API에는 **호출 횟수 제한(Rate Limit)**이 있어 초과 시 오류가 발생한다.
외부 API 호출이 많을수록 정산 처리 시간이 길어진다.

해결 — Redis 캐싱으로 중복 호출 제거

캐싱 후 이미지 삽입

같은 종목은 어느 참가자가 보유하든 대회 종료 시점의 가격이 동일하다. 삼성전자를 50명이 들고 있어도 그 시점의 가격은 하나다.

이 점을 활용해 Redis를 캐시로 사용했다. 종목 가격을 처음 조회할 때만 한투 API를 호출하고, 이후 같은 종목이 나오면 저장해둔 값을 그대로 꺼내 쓴다.

String cacheKey = "stock:price:" + competitionId + ":" + stockCode;
Long price = redisTemplate.opsForValue().get(cacheKey);

if (price == null) {
    // 캐시에 없을 때만 한투 API 호출
    price = stockPriceClient.getPriceAt(stockCode, endedAt).getData().longValue();
    redisTemplate.opsForValue().set(cacheKey, price, 1, TimeUnit.HOURS);
}
priceCache.put(stockCode, price); // 인메모리 Map에도 저장해 Redis 조회도 줄임

처리가 끝나면 Redis에 저장해둔 가격 데이터를 즉시 삭제해 불필요한 데이터가 남지 않도록 했다.

결과

개선 전개선 후

한투 API 호출 수	참가자 수 × 보유 종목 수	고유 종목 수
100명 × 5종목 기준	최대 500번	최대 20번

같은 데이터를 반복해서 가져올 필요가 없다는 점에서 출발한 단순한 아이디어지만, API 호출 횟수를 크게 줄여 Rate Limit 위험을 없애고 정산 속도도 높일 수 있었다.

Redis로 분산락 거는 방법

kinim329 — Thu, 7 May 2026 23:50:20 +0900

어제는 분산락이 왜 필요한지 정리했다.

오늘은 Redis를 사용해서 분산락을 어떻게 거는지 간단히 정리해보려고 한다.

락의 기준 정하기

분산락을 걸 때는 먼저 무엇을 기준으로 잠글지 정해야 한다.

주식 매수 기능에서는 같은 계좌의 잔액이 동시에 변경되면 문제가 생길 수 있다.

그래서 계좌 ID 기준으로 락을 걸 수 있다.

lock:account:{accountId}

예를 들어 계좌 ID가 1이면 다음 key를 사용한다.

lock:account:1

Redis로 락 걸기

Redis에서는 보통 SET NX EX 방식을 사용한다.

SET lock:account:1 random-value NX EX 3

NX는 key가 없을 때만 저장한다는 의미이다.

이미 같은 key가 있으면 락 획득에 실패한다.

EX 3은 3초 뒤에 락이 자동으로 사라지게 하는 설정이다.

서버가 작업 중 죽어도 락이 계속 남는 것을 막기 위해 만료 시간이 필요하다.

처리 흐름

요청이 들어온다.
Redis에 lock key 생성을 시도한다.
성공하면 로직을 실행한다.
끝나면 락을 해제한다.
실패하면 이미 처리 중인 요청으로 본다.

분산락

kinim329 — Wed, 6 May 2026 22:19:26 +0900

분산락이란?

분산락은 여러 서버나 여러 프로세스가 동시에 같은 자원에 접근하지 못하도록 막는 잠금 방식이다.

일반적인 synchronized나 Java Lock은 하나의 애플리케이션 안에서는 동작하지만, 서버가 여러 대로 늘어나면 한계가 있다.

예를 들어 서버가 1대라면 아래처럼 처리할 수 있다.

synchronized void buyStock() {
    // 매수 처리
}

하지만 서버가 2대 이상이면 문제가 생긴다.

사용자 요청 1 → asset-service 서버 A
사용자 요청 2 → asset-service 서버 B

이 경우 서버 A와 서버 B는 서로의 메모리를 공유하지 않는다.

그래서 서버 A에서 락을 걸어도 서버 B는 그 사실을 모른다.

이럴 때 Redis같은 외부 저장소를 이용해서 여러 서버가 공통으로 확인할 수 있는 락을 거는 방식이 분산락이다.

왜 필요할까?

분산 환경에서는 같은 데이터에 동시에 접근하는 상황이 자주 발생한다.

예를 들어 주식 매수 요청이 거의 동시에 두번 들어왔다고 가정해보자.

현재 잔액이 10000원이고, 주식 1주 가격이 7000원이라면 정상적으로는 한 번만 매수되어야한다.

하지만 동시에 요청이 들어오면 두 요청이 모두 같은 잔액을 조회할 수 있다.

요청 A: 잔액 10000원 조회
요청 B: 잔액 10000원 조회
요청 A: 7000원 매수 가능 판단
요청 B: 7000원 매수 가능 판단

결과적으로 실제 잔액보다 더 많은 금액이 사용될 수 있다.

이런 문제를 막기 위해 특정 사용자 계좌나 특정 주식 보유 정보에 대해 한 번에 하나의 요청만 처리되도록 잠금을 걸어야 한다.

N+1문제

kinim329 — Tue, 5 May 2026 23:50:20 +0900

오늘은 개발에서 자주 언급되는 N+1 문제에 대해 정리했다.

N+1 문제는 어떤 데이터를 한 번 조회한 뒤,
그 데이터와 관련된 정보를 가져오기 위해 추가 요청이 여러 번 반복되는 문제를 말한다.

여기서 N은 처음 조회한 데이터의 개수이고,
+1은 처음 데이터를 조회한 요청 1번을 의미한다.

즉, 처음 목록을 가져오기 위한 요청 1번과
목록에 포함된 각 데이터의 추가 정보를 가져오기 위한 요청 N번이 더해져
총 N+1번의 요청이 발생하는 상황이다.

예시로 이해하기

예를 들어 게시글 목록과 작성자 정보를 화면에 보여줘야 한다고 해보자.

먼저 게시글 목록을 가져온다.

게시글 목록 조회 1번

조회 결과가 5개라면 다음과 같은 게시글이 있다고 볼 수 있다.

게시글 1
게시글 2
게시글 3
게시글 4
게시글 5

그런데 각 게시글의 작성자 이름도 필요하다면,
게시글마다 작성자 정보를 다시 가져올 수 있다.

게시글 1의 작성자 조회
게시글 2의 작성자 조회
게시글 3의 작성자 조회
게시글 4의 작성자 조회
게시글 5의 작성자 조회

결과적으로 요청은 다음과 같이 발생한다.

게시글 목록 조회 1번
작성자 정보 조회 5번

총 6번 요청

처음 조회한 게시글이 5개라서 1 + 5,
즉 N+1 문제가 발생한 것이다.

왜 문제가 될까?

데이터가 적을 때는 큰 문제가 없어 보일 수 있다.

하지만 게시글이 5개가 아니라 100개라면 어떻게 될까?

게시글 목록 조회 1번
작성자 정보 조회 100번

총 101번 요청

게시글이 1000개라면 요청은 1001번까지 늘어날 수 있다.

이렇게 요청이 많아지면 다음과 같은 문제가 생길 수 있다.

응답 속도 저하
서버 부하 증가
데이터베이스 부하 증가
불필요한 네트워크 비용 증가

즉, N+1 문제는 기능이 동작하지 않는 오류라기보다는
성능을 떨어뜨리는 구조적인 문제에 가깝다.

해결 방향

N+1 문제를 해결하는 핵심은
반복해서 가져올 정보를 한 번에 가져오도록 구조를 바꾸는 것이다.

1. 처음 조회할 때 필요한 정보를 함께 가져오기

게시글 목록을 가져올 때 작성자 정보도 함께 가져오면
작성자 정보를 게시글마다 다시 조회하지 않아도 된다.

게시글 + 작성자 정보를 한 번에 조회

이렇게 하면 요청 흐름이 다음처럼 바뀐다.

기존 방식:
게시글 목록 조회 1번
작성자 조회 N번

개선 방식:
게시글과 작성자 정보를 함께 조회 1번

2. 여러 개의 추가 정보를 묶어서 가져오기

각 게시글마다 작성자를 하나씩 조회하는 대신,
필요한 작성자 ID를 모아서 한 번에 조회할 수도 있다.

작성자 ID 1, 2, 3, 4, 5를 모아서 한 번에 조회

이렇게 하면 요청이 다음처럼 줄어든다.

기존 방식:
작성자 조회 5번

개선 방식:
작성자 목록 조회 1번

3. 화면에 정말 필요한 데이터만 가져오기

처음부터 모든 관련 정보를 가져오는 것이 항상 좋은 것은 아니다.

필요하지 않은 정보까지 많이 가져오면
그 자체로 성능 문제가 될 수 있다.

따라서 화면이나 기능에서 실제로 필요한 데이터가 무엇인지 먼저 확인하고,
그 데이터만 적절한 방식으로 가져오는 것이 중요하다.

Kafka 역직렬화 에러 해결하기

kinim329 — Mon, 4 May 2026 23:33:28 +0900

문제 상황

asset-service에서 Kafka Consumer를 실행하던 중 다음과 같은 에러가 발생했다

Error deserializing VALUE for partition competition.ticked-0

그리고 핵심 원인은 아래 코드였다

No type information in headers and no default type provided

처음에는 Kafka 연결 문제나 Producer 설정 문제라고 생각했지만, 로그를 확인해보니 실제 원인은 Consumer가 Kafka 메시지를 객체로 변환하지 못하는 문제였다.

문제가 발생한 코드

asset-service에는 competition.ticked 토픽을 구독하는 Consumer가 있었다.

@Slf4j
@Component
@RequiredArgsConstructor
public class CompetitionTickedEventConsumer {

    private final RankingService rankingService;

    @KafkaListener(
            topics = "${topics.competition.ticked}",
            groupId = "${spring.kafka.consumer.group-id}"
    )
    public void handleCompetitionTicked(CompetitionTicked payload) {
        rankingService.updateRanking(payload.competitionId());
    }
}

이 코드는 Kafka에서 메시지를 받아 CompetitionTicked 객체로 바로 변환하려고 한다.

문제는 Spring Kafka의 JsonDeserializer가 이 메시지를 어떤 클래스 타입으로 변환해야 하는지 알 수 없었다는 점이다.

왜 이런 문제가 발생했을까?

Kafka 메시지는 내부적으로 바이트 형태로 저장된다.

Producer가 객체를 Kafka에 보낼 때는 객체를 JSON 같은 형태로 변환해서 보내고, Consumer는 다시 그 JSON을 Java 객체로 변환해야 한다.

이 과정을 각각 다음과 같이 부른다.

Producer: 직렬화
Consumer: 역직렬화

이번 문제는 Consumer 쪽에서 발생했다.

즉, 메시지는 Kafka에 들어왔지만 Consumer가 다음을 알지 못했다.

이 JSON을 어떤 Java 클래스에 담아야 하지?

그래서 다음과 같은 에러가 발생했다.

No type information in headers and no default type provided

의미는 다음과 같다.

Kafka 메시지 헤더에 타입 정보가 없고,
Consumer 설정에도 기본 타입이 지정되어 있지 않다.

해결방법 1

가장 간단한 해결 방법은 application.yml에 기본 역직렬화 타입을 지정하는 것이다.

CompetitionTicked의 패키지가 다음과 같다면:

io.antcamp.assetservice.domain.event.payload.CompetitionTicked

yml에 아래 설정을 추가할 수 있다.

spring:
  kafka:
    consumer:
      group-id: asset-service
      auto-offset-reset: earliest
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer
      properties:
        spring.json.trusted.packages: "*"
        spring.json.value.default.type: io.antcamp.assetservice.domain.event.payload.CompetitionTicked

이렇게 설정하면 Consumer는 Kafka 메시지를 읽을 때 기본적으로 CompetitionTicked 타입으로 변환하려고 한다.

해결방법 2

다만 asset-service가 앞으로 여러 Kafka 이벤트를 받을 수 있다면 문제가 생길 수 있다.

예를 들어 다음과 같은 토픽을 모두 구독한다고 가정한다.

competition.started
competition.finished
competition.ticked

각 토픽의 payload 타입이 다르다면 spring.json.value.default.type 하나로 모든 메시지를 처리하기 어렵다.

이 경우에는 Kafka 메시지를 먼저 String으로 받고, Consumer 내부에서 직접 DTO로 변환하는 방식이 더 명확할 수 있다.

yml 설정:

spring:
  kafka:
    consumer:
      group-id: asset-service
      auto-offset-reset: earliest
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer

Consumer 코드:

@Slf4j
@Component
@RequiredArgsConstructor
public class CompetitionTickedEventConsumer {

    private final RankingService rankingService;
    private final ObjectMapper objectMapper;

    @KafkaListener(
            topics = "${topics.competition.ticked}",
            groupId = "${spring.kafka.consumer.group-id}"
    )
    public void handleCompetitionTicked(String message) {
        try {
            CompetitionTicked payload =
                    objectMapper.readValue(message, CompetitionTicked.class);

            rankingService.updateRanking(payload.competitionId());
        } catch (Exception e) {
            log.error("competition.ticked 이벤트 변환 실패. message={}", message, e);
        }
    }
}

이 방식은 각 Consumer마다 어떤 DTO로 변환할지 코드에서 직접 확인할 수 있다는 장점이 있다.

내가 선택한 방법

이번 상황에서는 해결방법 2인 Kafka 메시지를 String으로 받은 뒤 ObjectMapper로 직접 변환하는 방식을 선택했다.

asset-service는 앞으로 하나의 Kafka 이벤트만 받는 것이 아니라 여러 이벤트를 받을 수 있다.

예를 들어 다음과 같은 이벤트를 받을 수 있다.

competition.started
competition.finished
competition.ticked

각 이벤트는 역할이 다르고, payload 구조도 다를 수 있다.

이런 상황에서 spring.json.value.default.type으로 기본 타입을 하나만 지정하면 모든 Kafka 메시지를 하나의 DTO 타입으로 변환하려고 할 수 있다.

하지만 이벤트마다 payload 타입이 다르면 이 방식은 관리하기 어렵다.

그래서 Consumer에서는 메시지를 먼저 String으로 받고, 각 Consumer 내부에서 필요한 DTO로 직접 변환하도록 했다.

@Slf4j
@Component
@RequiredArgsConstructor
public class CompetitionTickedEventConsumer {

    private final RankingService rankingService;
    private final ObjectMapper objectMapper;

    @KafkaListener(
            topics = "${topics.competition.ticked}",
            groupId = "${spring.kafka.consumer.group-id}"
    )
    public void handleCompetitionTicked(String message) {
        try {
            CompetitionTicked payload =
                    objectMapper.readValue(message, CompetitionTicked.class);

            rankingService.updateRanking(payload.competitionId());
        } catch (Exception e) {
            log.error("competition.ticked 이벤트 변환 실패. message={}", message, e);
        }
    }
}

이렇게 하면 각 Consumer가 어떤 이벤트를 어떤 DTO로 변환하는지 코드에서 명확하게 확인할 수 있다.

정리

이번 문제는 Kafka 연결 문제가 아니라 Consumer 역직렬화 문제였다.

Kafka 메시지는 정상적으로 들어왔지만, Consumer가 JSON 메시지를 어떤 Java 객체로 변환해야 하는지 알 수 없어서 에러가 발생했다.

핵심 에러는 다음과 같았다.

No type information in headers and no default type provided

해결 방법은 크게 두 가지였다.

1. application.yml에 spring.json.value.default.type을 지정한다.
2. 메시지를 String으로 받은 뒤 ObjectMapper로 직접 변환한다.

이번 프로젝트에서는 여러 Kafka 이벤트를 받을 가능성이 있기 때문에 두 번째 방법을 선택했다.

이벤트마다 payload 구조가 다를 수 있으므로, 각 Consumer에서 필요한 DTO로 직접 변환하는 방식이 더 명확하다고 판단했다.