사내 메세지큐 기술 스택 전환: Kafka → PGMQ(PostgreSQL Message Queue)

사내에서 기존 메세지큐 기술 스택으로 Kafka 를 사용하고 있습니다. 

Confluent사의 라이브러리를 사용하여 Kafka Consumer 와 Publisher 를 구성하고, 각 도메인에 맞는 토픽을 생성해 데이터 흐름을 분리해왔습니다. 메시지는 토픽 단위 스트림으로 발행되고, 컨슈머 그룹이 이를 병렬로 처리하는 구조입니다. 

 

 

이 방식은 대량 이벤트 처리나 로그 파이프라인처럼 “계속 흘러가는 데이터”를 소비하는 시나리오에서는 매우 강력합니다. 실제로 사내 초기 아키텍처 단계에서 Kafka는 전자상거래 주문 수집 로그, ERP 이벤트 브로드캐스팅 같은 데이터 중심 스트림 처리 영역에서 충분히 역할을 수행해왔습니다.

 

하지만, 시간이 흐르며 메시지 큐의 용도가 이벤트 스트림을 넘어 “업무 실행(Task Execution)” 영역으로 확장되기 시작했습니다. 외부 쇼핑몰 주문을 API로 수집하고, 이를 내부 ERP 도메인에 반영하며, 실패 시 재시도하거나 분기 처리하는 프로세스는 단순 이벤트 소비가 아니라 작업(work) 자체입니다. 하나의 메시지가 “이벤트”가 아니라 실행해야 할 행위(Action) 를 의미하기 시작한 것입니다.

 

이 지점에서 Kafka는 구조적으로 한계를 드러냅니다. Kafka는 이벤트 로그이며, 메시지는 append-only 스트림으로 저장됩니다. Consumer는 메시지를 읽었는가(Offset)만 판단할 뿐, 처리가 성공했는지, 실패했는지, 재시도 가능한지, 작업을 쪼개야 하는지를 시스템 자체는 알지 못합니다. 결국 이 모든 책임은 어플리케이션 코드에 귀속되고, 비즈니스 로직이 강하게 엮이게 됩니다. Worker는 Kafka API에 의존한 상태 머신처럼 변해버리고, 에러 발생 시 단편적 대응 외에는 도메인 기반의 복구가 어려워집니다.

특히 Action Timeout과 장기 실행 작업이 결합되는 순간 문제가 심각하게 드러납니다. 예를 들어 스크래핑 API 응답이 45초 이상 지연되면 서버는 타임아웃을 반환하고, 사용자는 실패를 경험합니다. 이 실패는 기술적 문제일 뿐 비즈니스 실패는 아니지만, Kafka 기반에서는 이 실패를 적절히 “회복 가능한 상태”로 옮기기 어렵습니다. 메시지는 이미 소비된 것으로 간주되고, 재시도는 별도 토픽 또는 DLQ를 거쳐야 하며, 재시도 과정 전체가 애플리케이션 레벨에서 커스텀 구현됩니다. 설계 난이도는 기하급수적으로 증가하고, 코드와 인프라가 단단히 결합됩니다.

 

 

이런 비즈니스 요구사항 문제점뿐 아니라 인프라 운영 관점에서도 조금 한계가 있었습니다. 저희 조직은 PostgreSQL을 비롯한 RDB 중심으로 구축된 ERP SaaS 회사입니다.
즉, DB 조직이 매우 강력합니다. DB 성능 최적화, 파티셔닝, 트랜잭션 튜닝, 인덱싱 전략 등에서 수많은 경험과 내재된 지식이 축적되어 있고, Postgres를 다루는 전문가는 많습니다.
하지만 Kafka 인프라를 안정적으로 관리하고, 토픽 재구성, consumer group migration 등을 엔터프라이즈 스케일에서 다룰 수 있는 엔지니어는 소수였습니다.

 

 

회사는 이러한 기술적·도메인적·조직적 문제를 종합적으로 인식했고, 메시징 시스템을 Kafka 중심의 스트림 처리 모델에서 업무(Task) 중심의 트랜잭션 처리 모델로 전환하기로 결정했습니다. 그 결과 선택된 것이 바로 PGMQ(PostgreSQL Message Queue) 입니다.

 

PGMQ는 사내 DB 전문가들이 보유한 역량을 그대로 활용하면서, 메시지 자체를 PostgreSQL의 Row와 트랜잭션으로 다루는 방식을 채택했습니다.

PostgreSQL Message Queue를 저수준에서 직접 구현함으로써, 회사의 비즈니스 도메인에 맞게 메시지 처리 구조를 커스텀하고 필요한 옵션을 유연하게 확장할 수 있도록 설계했습니다.

 

 

이번 메시지 큐 기술 스택 전환 프로젝트에서 제가 담당했던 핵심 작업은 크게 세 가지였습니다.
첫째, FOR UPDATE SKIP LOCKED와 pg_notify() 등 SQL 잠금 절(Locking Clause)과 내장 함수를 사내 ORM 프레임워크에서 직접 사용할 수 있도록 지원했습니다. 

둘째, 기존 Kafka 중심의 메시징 인프라를 PostgreSQL Message Queue(PGMQ)로 전환됨에 따라, 메시지를 “로그 스트림”이 아닌 트랜잭션 데이터로 다루도록 변경하였습니다.

셋째, 메시지 처리 과정에서 체이닝(Chaining) 옵션을 활용해 Task chaining 자동화했고, 이를 통해 메시지 페이로드 크기를 줄이는 동시에 대규모 작업을 작은 Task 단위로 분리해 전체 처리 성공률을 크게 개선(67%)했습니다.

이번 글에서는 이러한 전환 과정에서 필요했던 핵심 SQL 패턴, PGMQ 구조, 그리고 실제 서비스 환경에서의 성능 향상 사례를 중심으로 공유하고자 합니다.

 

 

 

🪈카프카와 PGMQ 란?

 

Apache Kafka

Apache Kafka는 본질적으로 분산 로그(distributed commit log) 시스템입니다. 메시지 데이터는 append-only 구조로 파티션에 순차적으로 기록되고, 컨슈머는 스스로의 오프셋을 기반으로 읽기를 진행합니다. 이 구조는 높은 쓰기 처리량을 보장하며, 파티션을 통한 수평적 확장성이 우수합니다.

 

이벤트 스트림 분석·대규모 로그 처리·CDC 처럼 단일 메시지 처리량보다 “지속적인 데이터 흐름”의 처리에 초점을 둔 도메인에서 Kafka는 압도적으로 강력합니다. 그래서 많은 기업들의 데이터 플랫폼에서 Kafka가 기본 인프라처럼 사용되는 이유도 여기에 있습니다.

 

카프카의 데이터 흐름을 논리적인 큐 형태로 표현하면 아래 이미지와 같습니다.

 

 

하지만 논리적인 표현일 뿐 실제로는 컨슈머가 메세지를 가져가 처리하는게 아닌, 오프셋이 움직이는 구조입니다.

아래는 좀더 물리적으로 가까운 표현입니다.

 

Topic Partition (.../CreateScrapingOriginAction)

┌──────────────────────────────────────────────────────────────────┐
│  MSG-0  │  MSG-1  │  MSG-2  │  MSG-3  │  MSG-4  │  MSG-5  │ ...  │
└──────────────────────────────────────────────────────────────────┘
 ↑
 Append Only (끝에만 추가)

 

• 큐처럼 가장 앞에서 꺼내가는 구조가 아닙니다.
• 파일 끝에 계속 기록되는 로그
• 메시지는 “삭제”가 아니라 retention 정책에 의해 만료

 

Topic Partition (.../CreateScrapingOriginAction)

┌──────────────────────────────────────────────────────────────────┐
│  MSG-0  │  MSG-1  │  MSG-2  │  MSG-3  │  MSG-4  │  MSG-5  │ ...  │
└──────────────────────────────────────────────────────────────────┘
             ▲
             │
        Consumer Offset

• Consumer는 데이터를 “가져가는 것”이 아니라 “읽고 offset을 이동”
• Consumer는 MSG-1까지 읽었음 → offset=1 이라는 의미 (Consumer는 파일을 따라 읽는 커서(offset))
• 메시지는 읽었다고 삭제하는 것이 아니라 남아 있습니다. (삭제 X)
• 동일한 Consumer Group 내부에서는 offset을 공유

 

Topic Partition (.../CreateScrapingOriginAction)

┌────────────────────────────────────────────────────────────────────────────┐
│ MSG-0 │ MSG-1 │ MSG-2 │ MSG-3 │ MSG-4 │ MSG-5 │ MSG-6 │ MSG-7 │ ...        │
└────────────────────────────────────────────────────────────────────────────┘
         ▲                ▲                    ▲
         │                │                    │
      Group A         Group B              Group C
    Offset=1          Offset=3            Offset=5

• Consumer Group 관점에선 “각 그룹이 독립된 오프셋(Offset)을 가집니다”
• 메시지는 단 한 번만 존재
• 각 Consumer Group은 독립적인 Offset 포인터를 가집니다.
• 다른 시스템이 동일 데이터를 독립적으로 재처리할 수 있습니다.

 

PGMQ(PostgreSQL Message Queue)

PGMQ는 말 그대로 PostgreSQL 위에 설계된 메시지 큐입니다.
Kafka가 메시지를 log stream으로 취급한다면, PGMQ는 메시지를 row 데이터로 취급합니다.
이 차이는 단순한 구현 방식의 차원이 아니라, 도메인 구조에서의 메시지 의미 자체를 바꿉니다.

 

PGMQ의 핵심은 메시지는 데이터이고, 데이터는 트랜잭션으로 관리돼야 한다 입니다.
Kafka에서는 메시지 처리 상태를 consumer가 추적하지만, PGMQ에서는 메시지가 테이블 row로 존재하며 상태 전이가 완전히 DB 내부에서 관리됩니다.

• insert → 메시지 생성
• fetch → 대기중 메시지 잠금(lease)
• ack → 처리 완료
• retry / dead → 실패 or lease timeout

DB가 ACID를 보장하므로, 저장과 처리 상태가 동일 스토리지 내에 일관적으로 남게 됩니다.
컨슈머가 죽어도, 서버가 롤백되어도, worker가 restart되어도 메시지 상태는 그대로 입니다.


PGMQ도 논리적 이미지로는 큐 형식으로 표현할 수 있습니다.

 

 

하지만 더 저수준으로 표현하자면, 저렇게 토픽별로 나누어져 있는 큐가 아닌, 한 곳에 데이터가 다 같이 있는 테이블 형식입니다.

 

 

PGMQ는 토픽(Queue)별로 저장된 메시지 row를 직접 SELECT 하여 가져오는 방식으로 동작합니다.
이때 메시지는 단순 조회가 아니라 처리 중인 row를 건너뛰며 잠금(lock)을 획득하여 이중 처리 되지 않게 해야하는 데 이때 필요한 절이 FOR UPDATE SKIP LOCKED 입니다.

이 절을 통해 동일 큐를 여러 Worker가 병렬로 처리하더라도 하나의 메시지가 두 번 집행되지 않도록 DB 레벨에서 동시성 제어를 보장합니다.

 

 

FOR UPDATE SKIP LOCKED

PostgreSQL의 FOR UPDATE SKIP LOCKED는 동시성 처리 환경에서 특정 레코드(row)를 잠그되, 이미 다른 트랜잭션이 잠근 레코드를 무시하고 “처리 가능한 레코드만” 가져오는 방식을 의미합니다.

"잠겨 있으면 그냥 건너뛰고 다른 row 가져올게" 느낌으로 Kafka나 Queue처럼 메시지를 빼와 처리하는 느낌을 DB row 잠금으로 구현한 것입니다.

• SELECT로 row를 가져오면서 동시에 잠근다 (FOR UPDATE)
• 다음 조회시 이미 잠긴 row는 건너뛴다 (SKIP LOCKED)
• 이로 인해 다른 worker가 같은 데이터를 중복 처리하지 않는다.
• Deadlock 없이 병렬 처리량을 극대화한다.

 

SQL을 예시로 보자면 다음과 같습니다.

SELECT *
FROM mq_message
WHERE status = 'wait'
ORDER BY process_available_dtm
FOR UPDATE SKIP LOCKED
LIMIT 1;

 

• 가장 먼저 처리 가능한 메시지를 잠그면서 가져옴
• 이미 다른 worker가 처리 중인 row는 자동으로 제외

 

pg_notify()

pg_notify()는 PostgreSQL이 제공하는 비동기 내장 함수입니다. 특정 채널(channel)에 문자열(payload)을 보내면,
해당 채널을 구독하고 있는 세션(listener)에게 이벤트를 push합니다.
DB 내부에서 이벤트를 발행하고, 이를 LISTEN 중인 애플리케이션이 실시간으로 받을 수 있게 하는 핵심 함수입니다.

 

-- 이벤트 구독 (LISTEN)
LISTEN mq_event;

-- 이벤트 발행 (pg_notify)
SELECT pg_notify('message_id', 'meta_data');

 

pg_notify는 메시지 저장 시스템이 아니라 알림 시스템입니다.

그래서

• 메시지 본문 = PGMQ 테이블
• 알림 signal = pg_notify()

이라는 구조로 설계하는 것이 정석입니다.

 

전체 흐름을 보자면 다음과 같습니다.

메세지 Row 저장(INSERT) → pg_notify()로 워커 깨우기 → 워커가 SELECT ... FOR UPDATE SKIP LOCKED

 

 

 

 

 

🔄️ Kafka에서 PGMQ 로 전환

 

PGMQ는 내부 구현체(Producer/Consumer)는 완전히 다르지만, 메시지를 사용하는 개발 경험은 Kafka와 거의 동일하게 유지했습니다. 메시지를 생성하고, ("채널명", "토픽명")을 지정하여 발행하면 됩니다.
Kafka에서도 동일하게 선언하고 메시지를 보내기 때문에, 사용자 입장에서는 학습 비용 없이 전환이 가능했습니다.

단, PGMQ는 내부 메시지 처리 엔진을 저수준부터 직접 구현했기 때문에, Kafka에서는 제공되지 않거나 구현 난도가 매우 높은 다양한 실행 옵션을 비즈니스 로직 레벨에서 커스텀할 수 있었습니다.

 

대표적으로 Retry 커스텀, Debounce Limit, Delay 커스텀, Serial Execution, Chaining, Execute Result  등이 있습니다.

 

 

1️⃣ Retry - 실패 시 재시도 (Worker 레벨 Retry)

• 역할 : Action 실행 중 Exception 발생 시 지정 횟수만큼 자동 재발행.

 

2️⃣ Debounce Limit - 과도한 발행 제어

• 역할 : 특정 workId 기준 일정 기간 내 발행 횟수를 제한.

 

3️⃣ Delay - 지연 실행 / 예약 실행

• 역할 : 작업을 특정 시간 이후 또는 명시적 시점에 실행.
           scheduleAfter: N초 이후 실행
           scheduleAt: 특정 날짜/시간에 실행

 

4️⃣ Serial Execution - 그룹 단위 순차 실행

• 역할 : 여러 메시지를 하나의 그룹으로 묶어 순차적으로 실행. “전체 개수를 알고 있고, 순서대로 처리”

 

5️⃣ Chaining - 실행 결과에 따라 다음 Task 연결

• 역할 : 페이지네이션 스크래핑 / API rate-limit 상황 대응 / 장기 워크플로우 분해

 

6️⃣ Execute Result - 메시지 간 결과 공유

• 역할 : 연결된 작업 그룹 내부에서 결과 값을 저장/조회.

 

 

 

🪄Task Chaining 기반 Payload 최적화  - “데이터를 운반하지 말고, 저장된 데이터를 참조하기”

 

장시간 실행되는 대용량 작업(예: 카드 내역 25~200건 Scraping, ERP 데이터 배치 변환 등)을 액션 타임아웃 없이 처리하기 위해 작업을 여러 단계(Chunk)로 나누어 체이닝하는 경우가 빈번합니다.

이때 메시지 기반 시스템에서 Task Chaining 을 설계할 때 가장 쉽게 빠지는 함정은 이전 메시지의 모든 결과를 다음 메시지 payload에 싣는 방식입니다.

기존 사내 Kafka 시스템을 사용할 때는 이런 접근 방법이 필연적이었습니다.
Kafka는 메시지를 append-only log로 저장할 뿐, 중간 상태를 자체적으로 보관하거나 다음 task가 이전 메시지의 실행 결과를 조회할 수 있는 구조를 제공하지 않기 때문입니다.

결과적으로 개발자는 체인이 깊어질수록 payload를 계속 누적시키게 됩니다.

• 첫 번째 메시지 결과 → 다음 메시지 payload에 embed
• 두 번째 메시지 결과 + 이전 결과 → 다음 메시지 payload embed
• 세 번째 메시지 결과 + 이전 2개의 결과 → 다음 메시지 payload embed

 

이 방식은 곱셈적 증가를 만들어냅니다.
각 단계에서 가져온 결과를 계속 payload에 누적시키면, 체인이 길어질수록 메시지 크기가 기하급수적으로 증가하게 되고, 이는 네트워크 전송 비용 · JSON deserialize 비용 · Worker 메모리 사용량 · GC 비용 등 시스템 전체에 악영향을 미칩니다.

 

● 예시) 기존 방식의 체이닝 메세지 모습

• 첫번째 메세지의 payload

{ card_no: 'xxxx-xxxx-xxxx-1234' }

• 두번째 메세지의 payload

{
  card_no: 'xxxx-xxxx-xxxx-1234',
  result: [
    { date: '20250101', amount: 20100, store: 'GS25' },
    { date: '20250102', amount: 15000, store: 'CU' },
  ]
}

• N번째 메세지의 payload

{
  card_no: 'xxxx-xxxx-xxxx-1234',
  result: [
    { date: '20250101', amount: 20100, store: 'GS25' },
    { date: '20250102', amount: 15000, store: 'CU' },
    ... (N건)
  ]
}

 

 

PGMQ 의  Chaining 옵션을 활용해 이 문제를 해결했습니다.

이 옵션을 사용하면 메시지는 실행 흐름만 전달하고, 결과는 큐 내부 상태로 저장하게 됩니다.
결국 메시지를 “데이터 배송 수단”이 아니라 “실행 트리거(Action)와 Context를 전달하는 수단”으로 볼 수 있게 됩니다.

 

Task Chaining은 다음과 같이 동작합니다

1. 컨슈머가 작업을 수행
2. 결과를 메시지 state에 저장 (PGMQ 내부 result 저장)
3. 다음 메시지가 발행될 때 payload에는 결과를 넣지 않는다
4. 컨슈머에서 실행되는 마지막 토픽에서 “저장된 결과”를 조회

 

 

🚀성과

 

국민 개인 카드 수집을 예시로 들었을 때, Scraping 결과가 25건만 되어도 Kafka 방식에서는 다음 단계 메시지 payload가 11,000 bytes까지 증가했습니다.
이는 결과 데이터 전체(JSON array + 필드 이름 + 중첩 구조)를 그대로 payload에 싣기 때문입니다.

card scraping이 100건, 300건이 되면 크기는 선형이 아니라 거의 누적 폭발 수준으로 커집니다.

 

 

반면 PGMQ Task Chaining 방식을 적용하면, 동일 조건(같은 카드·같은 기간)의 작업에서도 다음 체이닝 메시지 크기는 3,609 bytes에 불과했습니다.

 

payload 데이터 크기를 약 67% 절감한 결과입니다.

 

이런 성능 개선은 단순한 최적화가 아니라,

1. Worker 처리속도 개선
2. JSON parse 비용 감소
3. 네트워크 트래픽 크기 감소
4. CPU/GC 감소
5. 시스템 안정성 향상

으로 이어집니다. 더불어 이 모든 것이 체인 길이가 길어질수록 더 빛을 발합니다.

 

 

 

✨마무리

Kafka에서는 메시지가 “데이터를 운반하는 컨테이너”였기 때문에, 체이닝이 깊어질수록 payload가 누적되고 시스템 리소스 부담이 커질 수밖에 없었습니다.
반면 PGMQ는 메시지를 “작업 단위(Task)”로 재정의하고, 결과는 내부 상태로 저장하는 구조를 취함으로써 체이닝 단계가 늘어나더라도 payload는 최소 수준으로 유지됩니다.

이는 단지 메시지 크기를 줄였다는 수준의 개선이 아니라, 메시징 모델 자체를 ‘데이터 운반’에서 ‘업무 상태 저장’으로 전환한 결과입니다.
이 구조가 장기적으로 더 많은 처리량, 더 안정적인 Worker, 더 낮은 운영 비용을 보장합니다.

결국 PGMQ Task Chaining은 “실행의 흐름만 전달하고 데이터는 안전하게 저장한다”는 설계를 중심으로, 대규모 Scraping·Batch·ERP 연계 업무에서 지속 가능한 메시징 시스템을 구축하는 핵심 전략임을 확인할 수 있었습니다.