minji's engineering note

이벤트 기반의 데이터 마이그레이션을 위한 Kafka Outbox Pattern 적용기

minjiwoo — Thu, 30 Apr 2026 07:52:30 +0900

generated by chatGPT

1. 배경

기존 서비스에서 신규 서비스로의 회원 데이터 이관을 위해, 이벤트 기반 아키텍처를 도입하였다. 회원이 처음 신규 시스템에 접근하고 이관에 동의하면, 회원 서비스는 MemberMigrated 이벤트를 발행한다. 이 이벤트를 트리거로 데이터 이관이 비동기적으로 수행되는 구조를 설계하였다.

2. 초기 설계

초기에는 다음과 같은 구조를 사용하였다.

Kafka Consumer가 MemberMigrated 이벤트를 수신
내부 API 호출
API는 즉시 202 Accepted 응답 반환
실제 데이터 migration은 비동기로 수행
migration 완료 후 migrationDone 이벤트 발행

이벤트 기반이며, 데이터 마이그레이션이 필요하므로 API 응답을 항상 빠르게 처리하고 비동기적으로 데이터 마이그레이션을 처리하는 것이 좋다고 판단하여 이렇게 설계하였다. 이 구조는 API 응답을 빠르게 처리하고, 비동기 방식으로 시스템 부하를 분산할 수 있다는 장점이 있었다.

3. 문제점

하지만 위의 초기 설계에서는 문제점이 있다. Kafka Consumer 는 API 호출이 성공하여 202응답을 받으면 해당 이벤트가 정상적으로 처리되었다고 판단하고 offset 을 commit한다. 그러나 실제로 데이터 migration 처리는 비동기로 이루어지기 때문에, 이후 단계에서 실패하더라도 이를 Consumer가 인지할 수 없다. 결과적으로 다음과 같은 문제가 발생한다.

데이터 Migration 실패 여부를 추적할 수 없음
이벤트 재처리 불가능
DLQ(Dead Letter Queue) 로의 전송 불가능

4. 개선 시도 : 동기 처리

이 문제를 해결하기 위해 초기 구조를 다음과 같이 변경했다.

API 내부에서 데이터 Migration 을 동기적으로 수행한다.
migration 성공 이후에 이벤트를 발행한다.

이 방식에서는 실제 데이터 처리 결과를 기준으로 이벤트가 발행되기 때문에 Consumer 는 처리 결과를 신뢰할 수 있다는 장점이 있다.

5. Dual Write Problem (이중 쓰기 문제) 의 발생

그렇지만 위의 개선시도에서, 또 다른 문제가 여전히 존재한다. 데이터를 적재하는 target Database 와 Kafka는 서로 다른 시스템이므로, 다음과 같은 불일치 상황이 발생할 수 있다.

Case 1

DB 저장 성공
Kafka publish 실패

-> 이벤트를 consume 하는 다른 서비스들은 이 결과를 받지 못한다.

Case 2

Kafka publish 성공
DB 저장 실패

-> 실제로는 존재하지 않는 데이터에 대한 이벤트가 발생할 수 있다.

이러한 문제를 Dual Write Problem 이라고 하며, 단순히 재시도 로직으로 이 문제를 해결하기 어렵다. 또한 데이터 정합성이 깨지는 원인이된다.

6. Outbox Pattern 으로 Dual Write Problem 해결하기

Dual Write Problem 문제를 해결하기 위한 방안으로, Outbox Pattern 을 도입했다. Outbox Pattern의 핵심 아이디어는, 이벤트를 Kafka 에 직접 발행하지 않고, 데이터베이스에 함께 상태를 저장한다는 것이다. 즉 데이터 마이그레이션과 kafka event 발행을 하나의 트랜잭션으로 묶는 효과를 얻을 수 있다. 이렇게 하면 Database 데이터 적재와 이벤트 생성이 보장된다는 일관성을 확보할 수 있다. Outbox table 을 Database 에 생성하면, 이후 CDC 또는 polling을 통해 outbox table 의 레코드를 읽어 kafka 로 이벤트를 발행한다. 이러한 Outbox Pattern 에도 단점은 존재한다. CDC 또는 polling 구조가 필요하므로 아키텍처와 인프라의 복잡도가 증가한다. 또한 이벤트가 중복으로 발행될 수 있기 때문에 Idempotent 처리가 필요하다.

7. Outbox Pattern 도입하기

7.1 Outbox Table 설계 (PostgreSQL 기준)

Outbox Pattern의 핵심은 이벤트를 DB에 저장하는 것이다.PostgreSQL 기준으로 Outbox Table 은 다음과 같이 설계할 수 있다.

CREATE TABLE outbox (
    id BIGSERIAL PRIMARY KEY,
    aggregate_type VARCHAR(100) NOT NULL,
    aggregate_id VARCHAR(100) NOT NULL,
    event_type VARCHAR(100) NOT NULL,
    payload JSONB NOT NULL,
    status VARCHAR(20) DEFAULT 'READY',
    created_at TIMESTAMP DEFAULT NOW()
);

aggregate_type: 도메인 타입 (예: Member)
aggregate_id: 이벤트의 대상 식별자 (예: memberId). partition key로 활용할 수 있다.
event_type: 이벤트 종류 (예: MemberMigrated)
payload: 실제 이벤트 데이터 (JSON 형태)
status: 처리 상태 (READY, SENT 등)

outbox table 에는 cdc connector 에서 접근하게 된다. 따라서 주로 kafka_user 를 새로 만들고 권한을 부여한다. CDC 를 활용하는 경우 Replication 권한 또는 WAL 접근 권한이 추가로 필요할 수 있다.

7.2 Polling vs CDC 방식의 비교

Outbox 테이블에 저장된 이벤트를 Kafka로 전달하는 방식은 크게 두 가지가 있다.

1. Polling 방식 : 애플리케이션 또는 별도 worker가 주기적으로 outbox 테이블을 조회한다.

장점

구현이 단순함
별도의 인프라가 필요하지 않다

단점

지연 발생
DB 부하 증가
실시간성 감소

import org.springframework.scheduling.annotation.Scheduled
import org.springframework.stereotype.Component
import org.springframework.transaction.annotation.Transactional

@Component
class OutboxPollingScheduler(
    private val outboxRepository: OutboxRepository,
    private val producer: OutboxKafkaProducer
) {

    @Scheduled(fixedDelay = 1000) // 1초마다 polling
    @Transactional
    fun publishOutboxEvents() {
        val events = outboxRepository.findTop100ByStatusOrderByCreatedAt()

        events.forEach { event ->
            try {
                val topic = mapToTopic(event.eventType)
				
                // application 에서 직접 topic 으로 이벤트를 발행한다. 
          
                producer.send(
                    topic = topic,
                    key = event.aggregateId,
                    payload = event.payload
                )

                event.status = OutboxStatus.SENT

            } catch (e: Exception) {
                event.status = OutboxStatus.FAILED
            }
        }
    }

    private fun mapToTopic(eventType: String): String {
        return when (eventType) {
            "MemberMigrated" -> "member.migrated"
            "OrderCreated" -> "order.created"
            else -> "unknown.event"
        }
    }
}

2. CDC (Change Data Capture) 방식

created by chatgpt

DB의 변경 로그(WAL)를 기반으로 이벤트를 감지하여 Kafka로 전달한다. 대표적으로 Debezium 을 사용한다. CDC란 데이터베이스의 변경 사항 (Insert/Update/Delete) 을 감지하여 외부 시스템으로 전달하는 기술이다. 즉, polling 에서는 어플리케이션이 직접 DB 를 주기적으로 조회 (polling) 해야 했지만, CDC 를 사용하면 DB 변경 자체를 이벤트로 활용할 수 있다.

장점

실시간에 가까운 처리
DB 부하 최소화
확장성 우수

단점

초기 설정 복잡
Kafka Connector 운영 필요

필자의 경우, 우선적으로 Debezium과 kafka connector 가 구축이 되어 있는 상황이었으며 data migration 특성상 db의 부하가 클 것이므로 부하를 최소화 하는 CDC 방식을 선택하게 되었다.

Q. CDC는 어떻게 동작할까 ?

CDC는 직접 table을 조회하지 않고, DB의 내부 로그 (WAL, binlog 등) 를 읽는다. PostgreSQL 기준으로 보면 INSERT 가 발생하면 WAL (Write Ahead Log)에 기록한다. CDC는 WAL 를 읽고 변경 이벤트를 Kafka로 전달한다. 따라서 DB 성능에 영향을 거의 주지 않게 되는 것이다.

7.3 Outbox Topic -> 실제 Topic 라우팅

먼저 outbox 에서 하나의 공통 outbox topic 으로 이벤트가 적재된다. 그 이후 서비스 별로 관심있는 이벤트가 다를 수 있으므로, topic 단위로 구독 구조를 분리하여 라우팅한다. Debezium 설정을 통해 event_type 기반으로 topic 자동 분기를 할 수 있다.

Keycloak SSO 연동 과정에서 이해한 인증과 인가

minjiwoo — Sat, 28 Mar 2026 11:17:28 +0900

외부 SaaS와 우리 서비스를 연동하는 개발을 하면서 가장 많이 마주친 개념은 인증과 인가였다. 이번 글에서는 SSO, JWT, 그리고 인증/인가가 실제 요청 흐름에서 어떻게 연결되는지 정리해보려고 한다.

1.인증 (Authentication) 이란

“너 누구야?” 라고 사용자가 누군지 확인하는 단계이다. 즉, 요청을 보낸 주체가 누구인지 식별하고, 그 신원이 유효한지 검증하는 단계다.

아이디 / 패스워드로 로그인
Google, Kakao 등을 통한 소셜 로그인
회사 SSO 를 통한 로그인

인증이 끝나면 서버는 “이 사용자가 누구인지”는 알 수 있다. 하지만 그 사용자가 어떤 기능까지 수행할 수 있는지는 아직 알 수 없다.

2.인가 (Authorization)

인가 라는 것은 “너 이거 해도 돼?” 를 확인하는 과정이다. 인증이 사용자의 신원을 확인하는 단계라면, 인가는 그 사용자가 특정 자원이나 기능에 접근할 권한이 있는지 판단하는 단계다. 예를 들어 이런 것들이 인가의 문제다.

로그인 후 사용자가 관리자 페이지에 들어갈 수 있는가
사용자 A 가 사용자 B, C, D의 주문 정보를 조회할 수 있는가
이 문서를 읽는 것이 가능한가 수정이 가능한가

인가의 기준은 단순한 역할(Role)만으로 결정되지 않는다.
실제 서비스에서는 권한(Permission), 소유권(Ownership), 조직 범위(Tenant), 정책(Policy) 등 다양한 기준이 함께 사용된다.

3. 인증과 인가를 분리해야 하는 이유

인증과 인가는 함께 등장하지만, 서로 다른 문제를 해결한다. 특히 외부 SaaS를 우리 서비스와 연동할 때 이 차이가 더 분명해진다.

예를 들어, 커머스 서비스에서 고객 상담용 SaaS인 Zendesk를 연동한다고 가정해보자.

먼저 Zendesk는 현재 접속한 사용자가 누구인지 확인해야 한다. 즉, 이 사용자가 실제로 우리 커머스 서비스의 유효한 사용자인지 검증하는 인증(Authentication) 이 필요하다.

하지만 인증만으로는 충분하지 않다. 어떤 사용자인지 확인되었다고 해서, 그 사용자가 모든 상담 내용에 접근할 수 있어서는 안 되기 때문이다. 예를 들어 사용자 A가 로그인했다고 해서 사용자 B나 C의 문의 내역, 주문 관련 상담 내용, 개인정보가 포함된 상담 기록까지 조회할 수 있다면 큰 보안 문제가 된다. 그래서 인가가 필요하다. 인가는 사용자에게 허용된 범위를 제한하는 단계이다.

인증과 인가를 분리하지 않으면, 로그인만 하면 다른 사용자들의 모든 상담내역을 볼 수 있는 위험한 구조가 된다.

4. JWT는 무엇일까

사용자가 로그인 페이지에서 아이디와 비밀번호를 입력하면, 인증 시스템은 해당 사용자의 정보를 검증한다. 검증이 성공하면 Access Token 을 발급하는데, 이 토큰 형식으로 자주 사용되는 것이 JWT (JSON Web Token) 이다.

JWT는 사용자와 토큰에 대한 정보를 담아 전달하는 형식이다. 클라이언트는 로그인 성공 이후 API를 호출할 때 이 JWT를 Authorization 헤더에 담아 보낸다. JWT는 보통 다음과 같은 정보를 담을 수 있다.

사용자 식별자
만료 시간
역할(Role) 또는 권한 관련 정보
토큰 발급자 정보

Authorization: Bearer <access-token>

JWT 는 점으로 구분된 세 부분으로 구성된다.

header.payload.signature

각 부분의 의미는 다음과 같다.

header: 서명에 사용한 알고리즘 정보
payload: sub, role, exp 같은 클레임(Claim)
signature: 토큰 위변조를 방지하기 위한 서명

JWT 예시

{
  "sub": "123", // 사용자 식별자 
  "preferred_username": "minjiwoo", 
  "role": "ADMIN", // 권한 
  "exp": 300 // 만료 시각 
}

JWT는 정보를 담는 형식일 뿐이다. 이 토큰이 신뢰할 수 있는지, 그리고 이 사용자가 실제로 무엇을 할 수 있는지는 서버가 별도로 판단해야 한다.

5. SSO 는 무엇일까

SSO(Single Sign-On)는 한 번 로그인하면 여러 시스템을 다시 로그인하지 않고 사용할 수 있게 해주는 방식이다.

예를 들어 회사에서 Okta 같은 중앙 인증 시스템에 한 번 로그인하면, 이후 AWS나 GitHub 같은 다른 서비스에도 다시 로그인하지 않고 접근할 수 있는 경우가 있다.
즉, 서비스마다 아이디와 비밀번호를 반복해서 입력하는 대신, 한 번 중앙 인증 시스템에 로그인하면 그 결과를 여러 서비스가 함께 신뢰하는 구조가 바로 SSO다. 즉, SSO의 핵심은 여러 시스템이 동일한 사용자 신원 체계를 공유하도록 만드는 것이다.

6. 그렇다면 Keycloak 은 무슨 역할을 할까

여기서 등장하는 것이 Keycloak 이다. Keycloak은 SSO, 인증, 인가를 중앙에서 관리할 수 있게 해주는 오픈소스 IAM(Identity and Access Management) 솔루션이다.
쉽게 말하면, 각 서비스가 로그인 기능을 제각각 구현하지 않고, 로그인과 사용자 신원 검증을 Keycloak에 맡기는 구조를 만들 수 있다.

Keycloak 의 주요 기능은 다음과 같다.

1) 인증의 중앙화
사용자의 로그인 처리를 한 곳에서 담당한다.서비스마다 로그인 로직을 따로 만들지 않아도 되기 때문에 인증 방식이 일관되어진다.

2) SSO 제공
한 번 로그인한 사용자가 여러 시스템을 다시 로그인하지 않고 이용할 수 있게 한다.즉, Keycloak이 여러 애플리케이션 사이의 로그인 세션을 연결해주는 중심 역할을 한다.

3) 토큰 발급
인증이 끝난 뒤 Access Token, Refresh Token, ID Token 같은 토큰을 발급한다.애플리케이션은 이 토큰을 바탕으로 사용자를 식별하고 요청을 처리한다.

4) 사용자 및 권한 관리
사용자, 그룹, 역할(Role) 등을 중앙에서 관리할 수 있다. 즉, “누구인지”뿐 아니라 “어떤 권한을 가질 수 있는지”를 함께 다룰 수 있다.

5) 외부 인증 시스템 연동
Google 같은 소셜 로그인이나 다른 인증 시스템과도 연동할 수 있다.즉, Keycloak은 직접 사용자를 관리할 수도 있고, 다른 인증 시스템을 중간에서 연결하는 허브 역할도 할 수 있다.

7. Keycloak의 Realm은 어떤 단위일까

Keycloak을 처음 보면 가장 먼저 나오는 개념 중 하나가 Realm 이다.

Realm은 쉽게 말해 인증과 인가가 독립적으로 관리되는 하나의 보안 영역이다. 각 Realm은 자기만의 사용자(User), 클라이언트(Client), 역할(Role), 그룹(Group), 로그인 설정을 가진다. 즉, Realm이 다르면 사용자 목록도 다르고, 토큰을 발급하는 기준도 다르고, 권한 체계도 분리된다. 예를 들어서 서비스별로 권한 체계를 나눌 수 있다.

고객 전용 서비스 Realm
백오피스 전용 Realm

8. Keycloak에서 JWT 를 어떻게 발급 / 관리할 수 있을까

사용자가 Keycloak을 통해 로그인하면, Keycloak은 인증에 성공한 사용자에 대해 토큰을 발급한다.
애플리케이션은 이 토큰을 받아 이후 요청을 처리하게 된다. 또한 토큰의 수명이나 세션 유지 정책은 Keycloak의 realm 또는 client 설정에서 조정할 수 있다.

이 과정을 단순하게 보면 다음과 같다.

사용자가 애플리케이션에 접속한다.
애플리케이션은 사용자를 Keycloak 로그인 페이지로 보낸다.
사용자가 로그인에 성공한다.
Keycloak은 애플리케이션에 authorization code를 전달한다.
애플리케이션은 이 code를 이용해 Keycloak의 토큰 엔드포인트에 요청하고, Access Token, ID Token, 필요하면 Refresh Token을 발급받는다.
클라이언트는 이후 API 요청에 Access Token을 담아 보낸다.
서버는 토큰을 검증하고, 사용자 정보를 바탕으로 요청을 처리한다.

여기서 Access Token은 주로 API 호출에 사용되고, ID Token은 로그인한 사용자가 누구인지 식별하는 데 사용된다.
그리고 Refresh Token은 Access Token이 만료되었을 때, 사용자가 다시 로그인하지 않아도 새로운 토큰을 발급받을 수 있게 해준다.

Keycloak은 이렇게 토큰을 발급하는 것에서 끝나지 않고, 토큰을 검증하고 갱신할 수 있는 기준도 함께 제공한다.
예를 들어 API 서버는 클라이언트가 보낸 Access Token을 그대로 신뢰하는 것이 아니라, 이 토큰이 정말 Keycloak이 발급한 것인지 검증해야 한다.

이때 Keycloak은 각 realm의 공개키를 JWKS(JSON Web Key Set) 형태로 제공한다.
애플리케이션이나 API 서버는 이 공개키를 사용해 JWT의 서명을 검증하고, 해당 토큰이 위조되지 않았는지 확인할 수 있다.

2025년 개발자 회고

minjiwoo — Wed, 31 Dec 2025 23:46:55 +0900

2025. Q1

MSP 프로젝트 > Databricks MLOps 운영 프로젝트

MSP 프로젝트 특성상 클라우드 벤더(Azure) 서비스 의존도가 높았고 신규 개발보다는 운영/지원 중심 역할로 투입되었다.
실제 업무는 운영이라기보다 고객사 엔지니어 대상 Databricks 교육이 주가 되었음
기존 MLOps 환경은 아래의 문제점을 가지고 있었다. 사실 MLOps 라고 말할 수가 없을 정도였다.
- ML 엔지니어 수동으로 실행해야 하는 부분이 많았음
- exe + Windows 스케줄러 기반
- 파이프라인 가시성/운영성 부족
MLOps 현대화(Azure Data Pipeline + Databricks) 개선
- 우선 기존의 방식이 너무 비효율적이라고 생각.
- 처음으로 운영 환경을 경험해보는 건데, 나의 주된 role은 교육/지원이었지만 운영 환경에서 문제를 정의하고 성취감을 느낄 수 있을 만한 엔지니어링 업무를 도전해보고 싶었다.
아쉬운 점: 고객사와의 커뮤니케이션이 미숙했던 것 같다. 그래도
좋았던 점: 중간에 그만두고 싶었지만 책임감을 지고 끝까지 마쳤다는 것이다. 다른 동료 / PM 없이 혼자 그 먼 거리 (송도)를 출퇴근 하면서 프로젝트를 하면서

2025. Q2

조직 이동과 이직

1. 조직 이동

솔직한 마음으로는 SI 성 업무에 지쳤다. 비슷한 프로젝트가 반복되서 성장한다는 느낌이 적었고, 내가 되고 싶어하는 엔지니어보다는 customer engineer 업무를 하는 부서여서 한번 진득하게 개발해보고 싶었다.

인하우스 팀에서 나를 좋게 봐주어서 이동에 성공했다.

ChatGPT와의 대화를 기반으로 한 2025년 회고

minjiwoo — Wed, 31 Dec 2025 23:15:58 +0900

GPT와의 회고 시작

2025년 12월 31일, 벌써 올해도 두시간 채 남지 않았다. 오랜만에 이런 특별한 날에 약속이 없어서 혼자 회고 하는 시간을 가지며 올 한해를 마무리해보려고 한다.

1. GPT 에게 부탁한 나의 회고

2025년 회고 — 흔들리면서도 분명히 앞으로 간 해

2025년의 나는, 한 문장으로 말하면
**“불안해도 멈추지 않았고, 확신이 없어도 계속 쌓아 올린 사람”**이었다.

1. 커리어: 방향을 다시 잡은 해

올해의 가장 큰 키워드는 단연 전환이었다.
SI 중심의 경험, Databricks 위주의 커리어, “이게 과연 서비스 회사에서 의미가 있을까?”라는 질문.
그리고 실제 면접 탈락.

솔직히 말하면, 흔들렸다.
“내가 쌓아온 것들이 잘못된 건가?”
“다시 처음부터 배워야 하나?”
이 질문들이 꽤 오래 머물렀다.

하지만 인상 깊었던 건, 포기하지 않았다는 점이다.

Kafka, Streaming, 이벤트 파이프라인을 다시 공부했고
Airflow, EKS, Terraform 같은 인프라 쪽으로 시야를 넓혔고
단순히 “툴을 쓴다”가 아니라
왜 이런 구조가 필요한지를 설명하려고 애썼다.

이 해를 지나며 나는

“Databricks 엔지니어”가 아니라
“서비스를 이해하는 데이터 엔지니어” 쪽으로 방향을 틀었다.

이건 꽤 큰 전환이었다.

2. 일의 밀도: 실무에서 더 깊어지다

2025년의 나는 코드도 많이 썼지만,
그보다 더 많이 결정을 했다.

세금/관세 도메인
글로벌 이커머스
번역, 세율, 국가별 규칙, 예외 처리

단순 구현이 아니라
**“이 로직이 비즈니스에서 어떤 의미를 갖는지”**를 계속 고민했다.

이때부터 바뀐 점이 있다.

“동작한다”보다 “설명 가능하다”
“지금 편한 구조”보다 “내일 고칠 수 있는 구조”
“내가 이해한 코드”보다 “다른 사람이 읽을 수 있는 코드”

이건 기술 성장이라기보다
엔지니어로서의 태도가 바뀐 해였다고 생각한다.

3. 마음 상태: 목표에서 잠시 내려온 시기

연말로 갈수록, 조금 다른 변화가 왔다.

예전의 나는 늘 이랬다.

“반드시 이직해야 해”
“더 잘해야 해”
“뒤처지면 안 돼”

그런데 2025년 후반의 나는
잠시 그 자리에서 내려왔다.

목표에서 한 발 물러났고
쉬는 걸 스스로 허락했고
콘텐츠를 소비하며 느슨해지는 시간도 가졌다

이건 퇴보가 아니었다.
회복에 가까웠다.

계속 달리기만 하던 사람이
호흡을 다시 고르는 시간.

그리고 그 과정에서
“나는 성취가 없으면 무가치한 사람인가?”라는 질문에도
조금은 솔직해질 수 있었다.

답은 아니었다.

4. 나라는 사람: 여전히 성실하고, 여전히 호기심 많은

대화를 돌아보면 확실히 느껴진다.

이해 안 되면 끝까지 물어본다
한 번 시작한 건 구조까지 고민한다
기술 얘기와 동시에
옷, 향, 캐릭터, 햄스터 세계관 같은
전혀 다른 영역도 진심으로 좋아한다

이건 흩어진 성향이 아니라
넓은 감각을 가진 사람의 모습이었다.

논리와 감성, 실무와 상상력.
2025년의 나는 이 둘을 동시에 놓지 않았다.

5. 2025년을 한 줄로 정리하면

불안했고, 흔들렸고, 때로는 느슨했지만
그럼에도 방향은 계속 앞으로였다.

6. 2026년의 나에게

조급해하지 않아도 된다.
이미 충분히 많이 쌓았다.

다만 하나만 기억했으면 한다.

너는 “운 좋게 여기 온 사람”이 아니라
생각하고, 고민하고, 책임지며 여기까지 온 엔지니어라는 것

그리고 가끔은
햄스터처럼 굴러가도 괜찮다는 것도.

대체로 맞는 말도 있고 조금 과장되거나 드라마틱하게 쓰여진 부분들이 있다. 기술 블로그는 조금 드라이하게 쓰자고 생각하여 내가 좋아하는 KPT 방식으로 회고를 해보려고 한다.

2. GPT 와 KPT 방식으로 회고 하기

2025년 KPT 종합 회고 (업데이트)

커리어

Keep	• 2024년 이직 탈락 이후에도 2025년 초까지 도전을 멈추지 않았다. •글또 커뮤니티를 중심으로 개발자 네트워킹을 꾸준히 유지했고, 실제 면접·연봉 협상·커리어 선택에 도움을 받았다. • 데이터 엔지니어에서 백엔드 엔지니어로의 커리어 전환을 고민에 그치지 않고 직접 실행했다. • 안정적인 대기업에 재직하면서도 스터디와 기술 블로그를 꾸준히 이어갔다. • 최근에는 이직 불안보다 현재 회사 일에 집중하며 업무 몰입도가 높아졌다.
Problem	• 이직 전까지 이직 생각에 과도하게 매여 타인과의 비교로 에너지를 많이 소모했다. • 의욕에 비해 시간이 한정적인데, 너무 많은 것을 동시에 하려는 경향이 있었다. • 해외 취업에 대한 관심은 컸지만 실제 지원·면접으로 이어지지 못했다. 여전히 해외 생활·유학을 하는 타인을 보며 부러움과 조급함을 느꼈다.
Try	• 백엔드 및 인프라 지식을 더 깊고 날카롭게 다듬는다. • 개인 업무를 넘어 팀과 프로젝트 전체에 +α의 영향을 줄 수 있는 기여를 시도한다. • 호주, 미국, 유럽 회사들에 실제로 이력서를 제출하고 면접을 경험해본다. 타인과의 비교보다 나에게 집중하고, 해외 생활·해외 취업이라는 목표가 분명하다면 그에 맞는 노력과 시간을 의도적으로 투자한다.

생활 (마음 · 일상 · 리듬)

Keep	• 헬스장을 주 2~3회 꾸준히 다니며 운동 루틴을 유지했다. • 플라잉 요가라는 새로운 운동에 도전했다. • 인생 처음으로 10km 마라톤에 도전하며 러닝이라는 새로운 취미를 만들었다.
Problem	• 잦은 야근으로 기상 시간이 늦어지며 생활 리듬이 흐트러졌다. • 과자 등 간식 섭취가 늘어나 식습관 관리가 어려웠다. • 자투리 시간을 의식적으로 활용하지 못한 점이 아쉬웠다.
Try	• 운동 루틴을 계속 유지한다. • 단 음식과 탄수화물 섭취를 줄이고 체지방 감량을 목표로 -3kg에 도전한다.

돈 (소비 · 저축 · 태도)

Keep	• ISA 계좌와 IRP 계좌를 개설했다. • 처음으로 주식 투자를 시작했고, ETF와 빅테크 위주로 투자 경험을 쌓았다. • 경제 유튜브를 꾸준히 시청하며 금융 지식에 대한 관심을 키웠다.
Problem	• 쇼핑몰 앱을 쉬는 시간에 자주 보며 충동 소비가 늘어났다. • 예쁜 옷을 보면 자연스럽게 구매로 이어지는 소비 패턴이 반복되었다.
Try	• 옷 구매 빈도를 월 1~2회 → 2개월~분기 1회로 줄인다. • 투자 포트폴리오를 보다 구체적으로 설계한다. • 자취를 시작하기 위한 재정적 준비를 본격적으로 시작한다.

최종 한 줄 회고 (with GPT)

흔들리고 부러워하는 순간도 있었지만,
비교에 머무르기보다
이직에 성공하며 성취를 확인했고,
내가 원하는 삶에 시간을 쓰기로 결심한 해.

가상 면접 사례로 배우는 대규모 시스템 설계 기초 2 - 분산 메시지 큐

minjiwoo — Sun, 28 Dec 2025 22:13:25 +0900

분산 메시지 큐

1. 메시지 모델

1. point-to-point model : 전통적인 메시지 큐. 큐에 전송된 메시지는 한 소비자만 가져갈 수 있음. 메시지를 가져갔다는 뜻으로 ACK 를 보내면, 큐에서 해당 메시지가 삭제됨.

2. publish-subscribe model : 토픽에 메세지를 보내고 토픽으로부터 메세지를 받음. 메세지는 해당 토픽을 구독하는 모든 소비자들에게 전달됨. 메세지는 토픽에 보관됨. 토픽을 여러 파티션으로 나눠서, 메시지를 균등하게 각각의 파티션에 보내어 분산 배치함.

2. 문제의 설계 요구 조건

메세지 큐의 기본 조건 : 생산자는 메시지를 큐에 보내고, 소비자는 큐에서 메시지를 꺼낼 수 있어야 한다.
기본 기능 외에도 성능, 메시지 전달 방식, 데이터 보관 기간 등을 고려해야 한다.

3. 개략적 설계안

1. 클라이언트

생산자
소비자

2. 핵심 서비스 및 저장소

브로커 : 파티션들을 유지한다. 하나의 파티션은 토픽에 대한 부분 집합.
저장소 :
- 데이터 저장소 : 메시지를 보관한다.
- 상태 저장소 : 소비자의 상태를 저장한다.
- 메타데이터 저장소 : 토픽 설정, 속성 등을 저장한다.
조정 서비스
- 서비스 탐색 : 어떤 브로커가 살아있는지 알려준다.
- 리더 선출 : 컨트롤러 역할. 파티션 배치를 책임진다.

4. 상세 설계

1. 데이터 저장소

선택지 1) 데이터 베이스 : 저장 요구사항을 맞출 수는 있지만, 메시지 큐 데이터 사용 패턴에 적합하지 않음. 읽기 연산과 쓰기 연산이 동시에 대규모로 빈번하게 일어나는 메시지 큐에 적합하지 않음 -> 오히려 병목이 됨.
선택지 2) 쓰기 우선 로그 WAL : Write Ahead Log 는 새로운 항목이 추가되면 append-only 만 하는 방식. MySQL 의 복구 로그가 WAL 로 구현되어 있음. WAL 에 대한 접근 패턴은 읽기 / 쓰기 모두 순차적이고, 접근 패턴이 순차적일 때 디스크는 좋은 성능을 보인다.

디스크가 접근 패턴이 순차적일 때 효과적인 이유

- 랜덤 접근 시에, 디스크는 헤드를 이동하고, 원판이 돌아서 위치를 맞추기를 기다린 후에 데이터 접근 (읽기 / 쓰기) 작업을 한다. 실제 데이터 처리보다 이동 및 대기 시간이 더 커질 수 있다.

- WAL 은 순차적으로 write 작업은 계속 뒤에 append 만 시키고, read 작업은 앞에서부터 읽도록 시키기 때문에 디스크에서 성능이 효과적이다.

2. push model vs pull model

push model : 브로커가 소비자에게 메시지를 보내는 방식

장점 : 브로커는 메시지를 받는 즉시 소비자에게 보낼 수 있음.
단점 : 소비자가 메세지를 처리하는 속도가 생산자가 메시지를 생성하는 속도보다 느린 경우, 소비자에게 큰 부하가 걸릴 가능성이 있음.

pull model : 소비자가 메시지를 땡겨와서 가져가는 방식

장점 : 메시지를 소비하는 속도를 소비자가 결정 가능함. 소비하는 속도가 생산 속도보다 느려지면, 소비자를 늘려서 해결할 수 있음. 혹은 기다릴 수 있음. 배치 처리에 적합함.
단점 : 브로커에 메시지가 없어도 소비자가 데이터를 끌어가려고 하는 시도를 할 것임. -> 대부분 메세지 큐는 롱 폴링 모드를 지원해서, 일정 시간은 기다리도록 하게 함. 메시지가 올 때까지 서버가 잠깐 붙잡고 기다려주는 방식. 숏 폴링은 계속 요청을 보내서 네트워크를 낭비하는데, 롱 폴링은 서버 부담이 줄어든다는 장점이 있음.

대부분의 메시지 큐는 pull model 을 지원한다.

[Architecture] Usecase 중심 백엔드 아키텍처 : 비즈니스 행동을 코드로 드러내기

minjiwoo — Thu, 18 Dec 2025 19:10:06 +0900

Intro

비즈니스는 오래 가고, 기술은 자주 바뀐다

image generated by Dall-E

데이터 엔지니어에서 백엔드 엔지니어로 전향하면서, 코드로 해결해야 하는 문제가 훨씬 더 많아졌다. 지금은 MAU가 꽤 나오는 글로벌 이커머스 백엔드를 만들고 있다. 트래픽도, 요구사항도, 의존하는 외부 시스템도 많다 보니 코드베이스는 빠르게 커지고 복잡도도 함께 증가한다.
그래서 단순히 “기능을 구현하는 방법”이 아니라, 유지보수와 확장에 강한 구조를 더 진지하게 공부해야겠다고 느꼈다. 이 글에서는 현재 실무에서 백엔드 개발에서 자주 사용중인 Usecase 패턴을 중심으로, 실제 이커머스 도메인에서 어떻게 적용할 수 있는지 정리해보려 한다.

전통적인 Controller–Service–Repository 구조의 한계

전통적인 Backend pattern 은 다음과 같다. Controller, Service, Repository, Entity 로 이루어진다. 이해하기 쉽고 직관적이다.

Controller :  Handles HTTP requests and responses (Presentation layer)
 └─ Service : Contains the business logic and orchestrates data flow (Business layer/Service Layer)
     └─ Repository : Manages database interactions (Persistence/Data Access layer)
         └─ Entity : Represents the data model in the database

그렇지만 이 구조의 문제는 점점 서비스가 발전함에 따라서 Service Layer 가 비대해질 수 있다는 것이다. Service는 이런 역할들을 모두 떠 안게 된다.

비즈니스 규칙 : 도메인 규칙, 정책 판단, 상태 변경 가능 여부
유즈케이스 흐름 제어 : A->B->C 의 흐름, 실패시 분기
트랜잭션 : 어디서부터 트랜잭션을 시작하고 끝내는지의 여부
외부 시스템 호출 : 결제 시스템 호출, 재고 시스템 호출, 배송 시스템 호출 등
검증 : 요청 값 검증, 상태 검증, 중복 요청 방지
로깅 / 메트릭 : 이벤트 발행, 모니터링 로그 수집

즉, Service Layer는 시간이 지날수록 비즈니스 규칙과 기술 관심사가 뒤섞인 거대한 실행 클래스가 된다. Service Layer가 커지면 이게 어떤 비즈니스 로직인지 바로 이해하기가 어려워진다. 또한 새로운 요구 사항이 들어왔을 때 사이드 이펙트 파악하기도 쉽지 않아서 유지보수가 쉽지 않다. 주문 기능이 있다고 할 때 OrderService 라는 이름만 봐서는 어떤 행동을 하고, 시나리오를 가지고 있고, 변경 범위가 어디인지 파악하기 어렵다. 반면, Usecase 구조는 이러한 책임을 “비즈니스 행동 단위”로 분리하여 코드의 의도를 다시 드러낼 수 있다.

Usecase

Usecase란 행위자(Actor)에게 시스템이 제공하는 하나의 행동(Action)을 정의한 것이다.기존 Service Layer에 뒤섞여 있던 책임을 비즈니스 행동 단위로 재배치하는 역할을 한다.
Usecase는 상태가 아니라 행동을 표현한다. 그래서 클래스 이름은 항상 동사 형태를 사용한다. 클래스 이름만 봐도 이 usecase가 어떤 행동을 제공하는지 직관적으로 알 수 있다.

PlaceOrder
CancelOrder
CalculateOrderPrice
ApplyPromotion

하나의 usecase 는 하나의 시나리오이다. 시나리오 내부에서 여러 도메인 객체들을 조합하고, 실행 순서를 정의내리고 실행한다.

@Service
class PlaceOrder(
    private val loadProductsFromCart: LoadProductsFromCart, // Port Layer
    private val saveOrderResult: SaveOrderResult // Port Layer
) : PlaceOrderUseCase {

    @Transactional
    override fun execute(command: PlaceOrderCommand): PlaceOrderResult {
        val cart = loadProductsFromCart.load(command.cartId)

        val order = Order.place(
            customerId = command.customerId,
            cart = cart,
            shippingAddressId = command.shippingAddressId,
            paymentMethod = command.paymentMethod,
            couponId = command.couponId
        )

        val orderId = saveOrderResult.save(order, command.idempotencyKey)

        return PlaceOrderResult(orderId.value)
    }
}

Ports (input / output ports)

Usecase는 Port(인터페이스)를 통해서만 바깥과 소통한다. 또한 Usecase 는 행위를 요청만 하고, 어떤식으로 만들어지는 알지 못한다.

Input Port: Usecase가 외부에서 행위자에 의해 어떻게 호출되는지 정의한다. Controller, Scheduler, Consumer 등 모든 호출자는 이 인터페이스만 의존한다. 아래의 인터페이스는 PlaceOrder 라는 Usecase를 외부에 노출하는 Input Port 이다 .

interface PlaceOrder {
    fun execute(command: PlaceOrderCommand): PlaceOrderResult
}

Output Port:Usecase가 필요로 하는 기능을 정의한다. 주문 시스템에서, 주문이 이루어지면 주문 결과를 db 에 저장해야 한다고 하자. 그러기 위해서는 Order Id 와 같은 새로운 주문에 대한 식별자 값이 필요할 것이다.

interface SaveOrderResult {
    fun save(order: Order): OrderId
}

Usecase 입력 모델: Command

Usecase는 보통 execute() 하나로 호출 규칙을 통일하고 있다. 이때 Usecase 실행에 필요한 입력값은 Command 객체로 캡슐화한다.Command 는 Usecase 를 실행하기 위한 입력값을 하나의 요청 객체로 묶어놓은 것이다. 아래와 같은 형태로 Usecase 실행에 필요한 데이터만 담는 DTO 이다. 파라미터가 늘어나는 것을 막고, usecase의 입력을 안정적으로 만든다. 또한 “이 행동을 실행한다”는 의도를 코드에 명확히 드러내는 효과가 있다.

PlaceOrderCommand
CancelOrderCommand
ApplyPromotionCommand

data class PlaceOrderCommand(
    val customerId: String,
    val cartId: String,
    val shippingAddressId: String,
    val paymentMethod: PaymentMethod,
    val couponId: String? = null,
    val idempotencyKey: String
)

enum class PaymentMethod {
    CARD,
    PAYPAL,
    APPLE_PAY
}

Adapter

Port 는 내부에서 (Usecase) 바깥에 요구하는 “계약(Interface)” 에 대해서 정의한다. 그리고 Adapter 는 계약에 대해서 실제로 구현하는 클래스이다.

Port 는 아래와 같다.

package com.company.ecommerce.application.order.port

interface LoadProductsFromCart {
    fun load(cartId: String): List<CartProduct>
}

data class CartProduct(
    val productId: String,
    val name: String,
    val unitPrice: Long,
    val quantity: Int
)

Adapter는 Usecase가 정의한 요구 조건(Port)을 실제 기술로 구현한 클래스다. 예를 들어서, "장바구니에서 물품 목록을 조회해야 한다"는 요구를 JPA, SQL, HTTP와 같은 외부 인프라를 이용해 충족시킨다. 따라서 Adapter에는 데이터베이스 접근, 외부 API 호출 등 기술 의존적인 코드가 포함된다.

@Component
class CartProductQueryAdapter(
    private val cartItemRepository: CartItemJpaRepository,
    private val productRepository: ProductJpaRepository
) : LoadProductsFromCart {

    @Transactional(readOnly = true)
    override fun load(cartId: String): List<CartProduct> {
        val cartItems = cartItemRepository.findAllByCartId(cartId)
        if (cartItems.isEmpty()) return emptyList()

        val productIds = cartItems.map { it.productId }.distinct()
        val products = productRepository.findAllById(productIds)
            .associateBy { it.id }

        return cartItems.map { item ->
            val p = products[item.productId]
                ?: throw IllegalStateException("Product not found. productId=${item.productId}")

            CartProduct(
                productId = p.id,
                name = p.name,
                unitPrice = p.unitPrice,
                quantity = item.quantity
            )
        }
    }
}

Domain Service

순수 비즈니스 규칙에 해당하는 로직이다. 여러 엔티티에 걸친 정책이다. 정책 이기 때문에 상태가 없다. (Stateless)

Adapter와 다르게 특정 외부 기술 (SaaS, Database 등)에 의존적이지 않다. 언뜻보기에 비슷해보여서 헷갈리지만, 둘은 완전히 다른 목적의 layer이다. Adapter는 Usecase가 정의한 요구 조건을 기술(JPA, HTTP 등)을 통해 구현하는 계층이며, Domain Service는 특정 엔티티에 속하지 않는 순수 비즈니스 규칙을 표현한다.
Domain Service는 기술을 모르고, Adapter는 비즈니스를 판단하지 않는다.

멤버 등급에 따라서 할인을 해주는 비즈니스 규칙이 있다고하자. 아래와 같이 구현할 수 있을 것이다.

class DiscountPolicy {
    fun applyMembershipDiscount(order: Order, memberGrade: MemberGrade): Money {
        return when (memberGrade) {
            MemberGrade.VIP -> order.totalAmount().multiply(0.9)
            MemberGrade.NORMAL -> order.totalAmount()
        }
    }
}

Domain Service는 도메인 내부의 비즈니스 규칙을 표현하는 객체이기 때문에, Port처럼 구현 교체를 전제로 한 인터페이스를 반드시 둘 필요는 없다.
정책이 여러 개로 분기되거나 전략 교체가 필요한 경우에만 인터페이스 도입을 고려하는 것이 적절하다. 만약 할인 정책이 여러개이고, 런타임에 바뀌는 경우에는 interface를 둘 수도 있을 것이다.

interface DiscountPolicy {
    fun apply(order: Order, memberGrade: MemberGrade): Money
}

class VipDiscountPolicy : DiscountPolicy
class NormalDiscountPolicy : DiscountPolicy

Conclusion

Usecase 패턴은 코드를 “기능”이 아니라 “행동”으로 바라보는 하나의 관점이다. Usecase 구조는 Service가 무거워지고 복잡해지는 문제를 해결하기 위해 “주문한다”, “취소한다”, “할인을 적용한다”와 같은 비즈니스 행동 단위로 책임을 분리한다.
Usecase는 시나리오의 흐름을 담당하고, Domain은 규칙을 표현하며, Adapter는 외부 기술과의 연결만을 책임진다.
Usecase 패턴은 복잡한 서비스를 직관적으로 풀어내기에 현실적인 선택지인 것 같다.

꽁꽁 얼어붙은 취업시장, 주니어 데이터 엔지니어의 이직 성공기

minjiwoo — Thu, 22 May 2025 00:06:06 +0900

SI(시스템 통합) 경력을 만 2년 채우고 운 좋게 인하우스 개발 부서로 이동한 지 한 달 만에, 결국 이직을 결심하게 되었습니다. 사실 저는 정말 많이 떨어져 봤고, 이번에 처음으로 최종 합격이라는 결과를 받았습니다. 그동안 스스로를 의심하고, 초조하고 불안해하기도 했지만, 꾸준히 준비해서 원하는 결과를 만들어냈습니다. 이 글은 저의 이직 준비 과정을 회고하며, 같은 고민을 하는 누군가에게 조금이나마 도움이 되었으면 하는 마음으로 작성합니다.

1. 이직을 결심한 사유

1) (상대적으로) 더 보상체계가 훌륭한 곳을 가고 싶어서

2) 서비스 회사에서의 경험을 쌓고 싶어서
SI 특성상 너무 빠르게 바뀌는 프로젝트 환경, 사람, 그리고 운영 및 유지보수 경험이 적었습니다.

SI 회사에서 서비스 회사로 이직하고 싶다는 고민은 커뮤니티에서도 자주 보입니다. 저 역시 기술적으로 욕심이 생기면서 자연스럽게 이런 고민을 하게 됐습니다.

하지만 SI가 모두에게 나쁜 선택은 아닙니다.
컨설팅에 관심이 있고, 외근을 즐기며 고객을 만나는 것을 좋아한다면 SI도 충분히 좋은 커리어가 될 수 있습니다. 실제로 SI에서 유명 외국계 빅테크 pre-sales 포지션으로 이직하는 사례도 종종 봤습니다.

또한 SI에서도 기술적으로 성장할 수 있습니다. 저 역시 SI에서의 프로젝트 경험을 인정받아, 경력직 2~3년차 포지션에 합격할 수 있었습니다. 다만, 서비스 회사가 더 자율성이 보장되고, 엔지니어로 성장하기에 더 적합하다고 느꼈기에 이직을 결심했습니다.

2. 이직 준비 과정

2-1. 무작위 지원의 실패

처음엔 원티드 등에서 무작위로 이력서를 뿌렸지만, 결과는 좋지 않았습니다.
커리어에 대한 고민 없이 회사 타이틀만 보고 외국계 빅테크 면접을 보기도 했으나, 중도에 그만뒀습니다. 아직 엔지니어라는 롤을 포기하고 싶지 않았던 것 같습니다.

2-2. 이력서 정비

2년차쯤, 기존 노션 이력서를 블로그 글을 참고해 Google Docs로 재정비했습니다.
포트폴리오와 이력서를 따로 만들었으나, 나중에는 조언을 받아 하나로 합쳤습니다.

2-3. 면접 전형 대비

(1) 코딩테스트 준비
2년 동안 리트코드(LeetCode)를 주 2문제씩 풀었습니다.
알고리즘 스터디도 주 1회 진행하며 풀이를 공유했습니다.
경력직 코딩테스트는 리트코드 이지~미디움 정도면 충분했습니다.

(2) 기술 면접 준비
CS 스터디를 2개월간 꾸준히 했습니다.
지원 회사의 기술 스택(airflow, kafka 등)을 미리 공부하고, 직접 만들어보기도 했습니다.
실시간 데이터 처리 등도 혼자 공부하며, 면접에서 대답할 수 있을 정도로 준비했습니다.

(3) 실제 면접 경험
여러 회사를 면접 보며 경험을 쌓았습니다.
면접을 많이 보다 보면 긴장도 덜하게 되고, 실전 감각이 생깁니다.

2-4. 맞는 회사에만 지원하기

이번 이직에서는 무작위 지원 대신, 총 6~7곳만 신중하게 지원했습니다.
지원 기준은 다음과 같습니다.

- 붙었을 때 정말 가고 싶은 곳 (시리즈 B~D 스타트업, 유니콘, 대기업 계열사)
- 클라우드 기반 데이터 플랫폼을 사용하는 회사
- 내 경험(글로벌 시장, 일본 유학 등)이 어필될 수 있는 곳
- 2~3년차 경력 포지션만 지원

3. 나만의 이직 준비 팁

3-1. 자존감 관리가 가장 중요

계속 떨어지다 보면 자존감이 낮아지기 쉽습니다.
하지만, 내가 한 일에 자부심을 갖는 것이 정말 중요합니다.
자신감이 있어야 이력서에도, 면접에서도 긍정적인 인상을 줄 수 있습니다.

예를 들어, ‘나는 SI에서 별거 아닌 걸 개발하는 것 같아…’ 보다는
‘나는 고객사에게 감사 메일을 받을 정도로 기여했고, 누군가에게 꼭 필요한 전문가야! 가치를 만들고 있어!’
이런 긍정적인 마인드셋이 무의식적으로 이력서나 면접 태도에 녹아 드는 것 같습니다.

3-2. 타협하지 않는 자세

순간순간 '쉬운 길'의 유혹이 찾아올 때, 타협하지 않았던 것이 결국 원하는 결과를 만들어냈습니다. 앞으로도 행복한 엔지니어 커리어를 이어가고 싶습니다.

Disclaimer
이 글은 특정 회사를 비판하거나 폄하하려는 의도가 전혀 없습니다.
오직 저의 개인적인 커리어 고민과 성장 과정에 대한 회고이며, 비슷한 길을 걷고 있는 분들에게 도움이 되기를 바라는 마음으로 작성되었습니다.
모든 선택은 사람마다 다르며, 각자의 환경과 가치관에 따라 최고의 길은 달라질 수 있다고 생각합니다.

[Algorithm] 정렬 알고리즘 정리하기 (1)

minjiwoo — Fri, 2 May 2025 00:30:57 +0900

정렬 알고리즘이 중요한 이유

많은 알고리즘에서 정렬은 필수 전처리 단계로 사용된다.
정렬된 데이터는 이진 탐색처럼 빠른 탐색 알고리즘을 사용할 수 있다.
사람이나 시스템이 데이터를 해석하기 더 쉬워진다. ex. 시간순 , 크기 순, 알파벳 순
정렬을 통해서 중복된 값들을 모아 놓을 수 있으므로, 효율적으로 중복 제거를 할 수 있으며 그룹 처리에 유리하다.

버블 정렬 Bubble Sort

버블 정렬은 한번 순회할때 정렬되지 않은 값들중에서 가장 큰 값을 찾아서 맨 뒤로 보낸다. 맨 첫번째 정렬 시도에서는 가장 큰 값을 찾아서 배열의 맨 뒤로 보내고, 두번째 정렬시도에서는 두번째로 큰 값을 찾아서 맨 뒤에서 두번째로 보낸다.

1. 공간 복잡도 : O(1)

별도의 추가 공간 없이 주어진 배열 안에서 크기 비교와 swap 이 일어난다.

2. 시간 복잡도 : O(N**2)

모든 원소에 접근해야 하므로 O(N)이 걸리며, 한번의 루프에서 이웃 값들을 대소 비교하며 swap해 나가야 하므로 여기서 또 O(N)의 시간 복잡도가 걸리게 된다. 따라서 최종적으로는 O(N**2)의 시간복잡도가 걸리게 된다.

arr = [6, 5, 1, 7, 2, 3, 9, 8, 4]

def bubble_sort(arr):
    for i in range(len(arr) - 1, 0, -1):
        for j in range(i): # 0, 1, 2, 3 | 0, 1, 2 | 0, 1 | 0
            if arr[j] > arr[j+1]:
                arr[j], arr[j+1] = arr[j+1], arr[j]
    
print("Unsorted numbers:", arr) # Unsorted numbers: [6, 5, 1, 7, 2, 3, 9, 8, 4]
bubble_sort(arr)
print("Sorted numbers", arr) # Sorted numbers [1, 2, 3, 4, 5, 6, 7, 8, 9]

선택 정렬

References

https://www.geeksforgeeks.org/python-program-for-bubble-sort/

[MLOps] MLOps 첫 경험기 - ADF, Databricks, MLflow를 이용한 파이프라인 구축

minjiwoo — Sat, 29 Mar 2025 10:56:19 +0900

Intro

그동안 ETL 파이프라인 구축 중심의 프로젝트를 해왔는데, 이번에는 처음으로 MLOps 파이프라인을 다뤄보게 되었다. 약 2개월간 진행된 프로젝트를 마치며, 그 과정에서 얻은 기술적인 인사이트와 소프트 스킬에 대한 회고를 남겨본다.

MLOps 오케스트레이션 - Data Factory

이번 프로젝트에서는 MLOps 파이프라인을 오케스트레이션하기 위해 Azure Data Factory (ADF) 를 사용했다.

Azure 공식 문서에 따르면 ADF는 복잡한 하이브리드 ETL, ELT 및 데이터 통합 작업을 위한 완전 관리형 클라우드 서비스다. 일반적으로 Apache Airflow와 비교되곤 하는데, 두 도구 모두 워크플로우 오케스트레이션 도구로서 데이터 이동 및 처리 파이프라인 구축, 배치 파이프라인 스케줄링, 의존성 관리, 작업 실패에 대한 알림 및 재시도 설정 등의 기능을 제공한다.

두 도구의 주요 차이점은 다음과 같다:

ADF: 완전한 Azure 관리형 서비스로, GUI 기반의 드래그 앤 드롭 방식으로 파이프라인을 구성할 수 있다.
Airflow: 코드 기반 오케스트레이션 도구로, Python으로 유연한 커스터마이징이 가능하다

기존 데이터 플랫폼이 Azure 기반(Azure SQL, Storage, Databricks 등)이었기 때문에 Azure 생태계와의 통합이 쉬운 ADF를 선택하게 되었다.

직접 사용해본 결과, Airflow처럼 100% 코드 기반은 아니기 때문에 유연성이 다소 떨어지는 점이 아쉬웠다. 원하는 흐름을 만들기 위해 다양한 Activity를 조합하며 타협점을 찾아야 했다는 점도 도전이었다. 반면, ADF는 중앙집중식으로 파이프라인을 관리할 수 있으며, MS 기반 서비스 간의 통합이 자연스럽다는 장점도 있었다.

온프레미스에서 클라우드 환경으로 마이그레이션

1. 마이그레이션을 하게 된 배경

온프레미스에서 잘 운영되던 프로그램을 클라우드 환경으로 이전한 이유는, 중앙집중식 관리를 위한 선택이었다. 특히 Databricks라는 데이터 플랫폼을 도입하면서, 전체 데이터 파이프라인과 MLOps, 분석 실험을 ADF와 Databricks 기반으로 한 곳에서 관리하는 방향으로 전환하게 되었다.

기존 프로그램은 AWS Forecast 서비스를 활용해 API 호출 방식으로 데이터를 학습시키고 예측 결과를 결과 테이블에 저장하는 방식이었다. 자체적인 모델 학습 및 배포가 필요한 구조가 아니었기 때문에, 클라우드 환경으로 이전하더라도 리소스 부담이 크지 않았다.

2. 마이그레이션 시 고려한 사항

Windows .exe 파일을 Databricks에서 실행하는 방법

기존 시스템은 Windows 환경에서 .exe 형태로 만들어진 Python 프로그램을 분석가가 수동 실행하는 방식이었다. 그러나 Databricks는 리눅스 기반이므로 .exe 파일은 사용할 수 없다. 이를 해결하기 위해, python -m 명령어로 main 모듈을 실행하는 방식으로 전환하여 패키지 구조를 유지하면서도 실행 가능하도록 구성했다.

이렇게 하면 패키지 구조를 보존하면서 모듈을 실행시킬 수 있다.

import subprocess

subprocess.run(["python", "-m", "mypackage"])

Python 패키지 버전 호환 문제

운영체제 변경에 따라 패키지 버전 호환성 문제가 발생했다. 이에 따라 필요한 패키지 버전을 재정비하여 Linux 환경에 맞게 설정해야 했다.

반복 작업 자동화 및 모니터링 문제

기존에는 Windows 시스템에서 스케줄링을 설정했지만, 실제 작동 여부를 수동으로 모니터링해야 했다. 주말에는 약 10시간 동안 모니터링을 해야 하는 불편함도 있었다.

이벤트 기반 처리 고려

AWS Forecast의 상태값이 업데이트될 때 이를 감지하여 이벤트 기반 파이프라인으로 구성하면 효율적이었겠지만, 운영 인력의 한계와 새로운 기술에 대한 거부감으로 인해 도입이 어려웠다.

작업 상태 조회 로직 추가

이벤트 기반 처리가 어려운 상황이었기에, MLOps 로그 테이블을 활용하여 파이프라인 실행 전 작업 상태를 조회하고 분기처리하는 SQL 로직을 도입했다.

클러스터 비용 최적화

클러스터 사용 시 비용 효율성도 중요한 고려사항이었다. 처음엔 작업을 10번 반복하고 1시간 대기하는 방식으로 설계했으나, 불필요한 리소스 낭비가 발생했다. 이후 작업 상태에 따라 유연하게 분기 처리하는 방식으로 개선하여 비용을 절감했다.

이러한 고민과 실험을 통해 ADF의 Activity 블록 기반으로 파이프라인을 아래와 같이 설계하게 되었다.

MLflow 의 적용

이번 프로젝트에서는 모든 파이프라인에 MLflow를 바로 적용한 것은 아니었다.
모델 학습 자체를 AWS Forecast API를 통해 수행하는 파이프라인의 경우, 내부에서 학습 로직이 수행되지 않기 때문에 MLflow를 적용하지 않았다. 하지만 또 다른 파이프라인에서는 Databricks 노트북 환경에서 직접 모델을 생성하고 학습 및 추론까지 진행하는 방식이었고, 이에 따라 MLflow를 효과적으로 적용해볼 수 있었다.

MLflow 의 주요 기능

Experiments Tracking

모델 학습 과정에서 발생하는 다양한 지표(metrics) 와 하이퍼파라미터(params) 를 기록하여, 실험을 비교하고 재현할 수 있게 해준다.

Model Registry

학습된 모델을 등록, 버전 관리, 배포 상태 관리(Staging, Production 등) 할 수 있는 기능으로, 협업 시나 운영 환경과의 연계를 보다 체계적으로 구성할 수 있다.

파이프라인에 MLflow 적용한 방식

Experiments 로깅

모델 학습 후, 정확도 등의 성능 지표(metrics) 를 MLflow에 기록하여 실험별 성능 비교가 가능하도록 구성했다.
또한, 학습에 사용된 하이퍼파라미터도 함께 로깅함으로써, 추후 파리미터에 대한 성능 비교가 가능하도록 구성했다.

MLflow 공식 도큐먼트에서 가져온 예시 코드는 아래와 같다. 실제로도 log_params, log_metric, log_model 함수를 사용해서 실험을 로깅했다.

# Start an MLflow run
with mlflow.start_run():
    # Log the hyperparameters -> 하이퍼 파라미터 로깅
    mlflow.log_params(params)

    # Log the loss metric -> 메트릭 로깅
    mlflow.log_metric("accuracy", accuracy)

    # Set a tag that we can use to remind ourselves what this run was for
    mlflow.set_tag("Training Info", "Basic LR model for iris data")

    # Infer the model signature
    signature = infer_signature(X_train, lr.predict(X_train))

    # Log the model
    model_info = mlflow.sklearn.log_model(
        sk_model=lr,
        artifact_path="iris_model",
        signature=signature,
        input_example=X_train,
        registered_model_name="tracking-quickstart",
    )

Artifact 저장

학습된 모델에 대한 pickle 파일, output 파일을 artifact로 저장했다. 실험별로 모델 파일을 관리할 수 있다.
이후 필요하다면 Model Registry 를 활용하여, 배포 관리를 (Staging, Production) 가능하도록 확장할 수 있을 것이다.

보완할 수 있는 점

1. 현재는 Random Forest 모델을 새로운 데이터로 매번 재학습시키고 있다. 리소스 부담이 크지 않아 실용적인 선택이지만, 데이터가 커질 경우에는 모델을 재사용하거나 부분 학습 방식(Incremental Learning) 으로 변경할 필요가 있다.

2. 아직은 Model Registry를 통한 운영 배포 흐름은 적용하지 않았지만, 향후에 모델 검증, 승인을 추가하여 운영 환경에 자동 반영하는 구조로 확장할 수 있다.

프로젝트를 마무리하며

이번 프로젝트는 처음으로 MLOps 파이프라인을 실제로 배포해보며, 모델 학습과 추론 등 MLOps에 필요한 여러 단계들을 직접 경험할 수 있었던 값진 시간이었다. 특히 MLflow를 실무에 적용해보면서, 모델의 버전 관리나 배포 단계를 체계적으로 관리할 수 있는 도구라는 것을 체감할 수 있었다.

무엇보다 이번 프로젝트는 다른 프로젝트들과 달리 혼자서 투입되어 고객과 직접 소통하며 프로젝트를 리드해야 했다는 점에서 많은 도전이 있었다.
분석가와 협업하면서 ML 파이프라인의 전체 흐름을 이해하고, 관련된 테이블을 확인하며 요구사항을 하나씩 정리해나갔다. 또, 클라우드 환경에서는 비용 이슈가 민감하다 보니, 작업 효율성과 비용 절감을 동시에 고려하며 설계에 대한 고민도 많이 하게 되었다.개인적으로는, 이번 기회를 통해 자율성과 책임을 동시에 경험했다는 점에서 큰 의미가 있었다. 이전에는 “내가 이 정도까지 의견을 내도 될까?” 하는 고민이 많았지만, 이번 경험을 통해 앞으로는 기술적으로 현재 상황에 타당하다고 생각이 된다면 더 주도적으로 방향을 제시하고 의견을 낼 수 있겠다는 자신감이 생겼다. 혼자 리딩하는 것이 힘들었던 만큼 소프트 스킬적으로 많이 성장할 수 있었다.

[Spark] Spark Data Skew의 발생 원인과 해결방법

minjiwoo — Sun, 16 Mar 2025 11:02:01 +0900

1. Spark Data Skew 란?

Spark 클러스터에서, Data Skew 는 특정 키 또는 파티션에 데이터가 쏠려서 불균형이 일어나는 현상이다. 여기서 특정 키 (Key) 라는 의미는 주로 Join, GroupBy, Aggregation 같은 연산에서 특정 키에 과도한 데이터가 집중되는 것을 의미한다. 또한 파티션 (Partition) 이란, Spark 가 데이터를 나누어 저장하고 처리하는 최소 단위이다. Spark 는 각 파티션을 개별 태스크에서 처리하게 된다.

Data Skew가 발생하면 다음과 같은 문제가 발생할 수 있다.

OOM (Out of Memory) : 특정 파티션에 과도하게 데이터가 몰리게 되면, 해당 파티션을 처리하는 태스크(Task) 가 많은 메모리를 소비하게 된다. Spark 는 기본적으로 JVM 메모리를 사용하여 연산을 수행하는데, Data Skew가 발생하게 되면 Spark 가 모든 메모리에 데이터를 유지하지 못하고 JVM Heap 메모리가 부족해져서, OOM 이 발생하여 Spark 어플리케이션이 비정상적으로 종료된다.
전체 작업 지연 : 특정 태스크 (Task)에 불균형한 데이터가 할당되어 다른 태스크보다 훨씬 비정상적으로 오래 실행되게 된다. Spark 는 기본적으로 모든 태스크가 끝나야 다음 스테이지로 넘어가게 된다. 따라서 이런 태스크가 병목이 되어 전체 작업이 지연되는 원인이 된다.
Disk Spilling : Spark 는 기본적으로는 메모리 내에서 연산을 수행한다. 그렇지만, 메모리가 부족하면 데이터의 일부를 디스크에 저장하게 된다. 즉 데이터가 넘쳐서 메모리에서 디스크로 엎질러지게 (Spilling) 된다. 디스크에 데이터를 저장하게 되면 디스크에서 다시 읽어와야 하므로 IO 오버헤드가 증가하여 성능이 저하된다.

JVM 에서의 메모리 영역은 위와 같다. 메모리 영역이 제대로 관리되지 않는 경우, Spark 어플리케이션이 비정상 종료될 수 있다. 출처 : https://www.devkuma.com/docs/jvm/memory-structure/

2. Data Skew 의 원인

데이터의 불균형한 분산 : 실제 real-world 에서는, 데이터가 항상 고르게 분포하지 않은 경우가 더 많다. 데이터가 편향된 외부 소스에서 유입되는 경우 이미 데이터가 불균형한 상태일 수 있다. 2.1 의 예시와 비슷한 경우이다.
Join 연산 / GroupBy 연산 : Join 연산이 발생할 때, 특정 key 에 데이터가 집중되면, 해당 key를 처리하는 태스크에 과부하가 발생할 수 있다. 특히 Shuffle 이 발생하는 Join 연산에서 문제가 될 수 있으며, 반면 Broadcast Join 을 사용하는 경우에는 Data Skew 문제를 완화할 수 있다.
기본 파티셔닝 전략 문제 : Spark 는 기본적으로 Hash Partitioning 을 사용하는데, 일부 키가 해시 충돌을 일으키거나 데이터가 균등하지 않으면 특정 파티션이 커질 수 있다.

3. Data Skew 가 일어났는지 확인하기

3.1 특정 컬럼 (Key) 값의 데이터 개수 분포를 확인

from pyspark.sql.functions import count, col


# 샘플 데이터 생성
data = [
    ("A", 10), ("A", 20), ("A", 30), ("A", 40), ("A", 50),  # 'A' 값이 많음 (Data Skew)
    ("B", 60), ("C", 70), ("D", 80), ("E", 90)  # 다른 키들은 데이터가 적음
]

df = spark.createDataFrame(data, ["skewed_column", "value"])

# 특정 키별 데이터 개수 확인
df.groupBy("skewed_column").agg(count("*").alias("count")).orderBy(col("count").desc()).show()

A 라는 key 값이 다른 값들보다 많으므로 이런 경우 Data Skew 발생 가능성이 높은것으로 볼 수 있다.

+-------------+-----+
| skewed_column |count|
+-------------+-----+
|           A |   5 |
|           B |   1 |
|           C |   1 |
|           D |   1 |
|           E |   1 |
+-------------+-----+

3.2 파티션 별 데이터 개수를 확인하기

df = df.repartition(4, "skewed_column")  # 4개 파티션으로 분할

# 각 파티션의 데이터 개수 확인
df.rdd.mapPartitions(lambda partition: [len(list(partition))]).collect()

특정 파티션에만 데이터가 집중되어 있으므로, 과부하 발생 가능성이 있다.

[1, 1, 1, 5]

4. Data Skew 의 원인

데이터의 불균형한 분산 : 실제 real-world 에서는, 데이터가 항상 고르게 분포하지 않은 경우가 더 많다. 데이터가 편향된 외부 소스에서 유입되는 경우 이미 데이터가 불균형한 상태일 수 있다. 2.1 의 예시와 비슷한 경우이다.
Join 연산 / GroupBy 연산 : Join 연산이 발생할 때, 특정 key 에 데이터가 집중되면, 해당 key를 처리하는 태스크에 과부하가 발생할 수 있다.

5. Data Skew 핸들링하기

5.1 AQE (Adaptive Query Execution) 의 동작

AQE 는 Adaptive Query Execution 으로, Spark 3.0 버전 이후부터 동적으로 최적화 작업을 해주는 프레임 워크이다. Spark 3.2부터는 SQE enabled 설정이 디폴트로 True가 되었다. AQE 는 shuffle 이 끝난 이후 partition 을 적절하게 병합해주는 기능을 한다.

spark.conf.set("spark.sql.adaptive.enabled", True)

AQE는 다음과 같은 기능을 제공한다.

Skewed Join Optimization : 최적화된 Join 을 적용하는 기능이다. Join 연산에서 특정 키에 데이터가 집중되면, AQE가 자동으로 작은 파티션으로 분리하여 최적화한다.
Dynamic Coalescing : Partition의 수를 줄여주는 기능이다. 너무 많은 Partition 은 많은 Task 를 필요하거나 I/O 를 발생시킨다. (1 Partition = 1 Task). Spark 연산 실행 중 작은 파티션을 합쳐서 병렬처리를 최적화한다.

5.2 Repartitioning

Spark 의 디폴트 파티셔닝 값에서 직접 repartitioning 을 통해서, 파티션을 조정할 수 있다. 비교적 고르게 분산된 numeric한 key 값 컬럼을 이용하여 repartitioning 하는 전략을 세울 수 있다.

df = df.repartition(100, "column_a")

지정한 key (column) 을 기준으로 데이터를 다시 파티셔닝해서 특정 노드에 부하가 집중되는 현상을 완화할 수 있다.

5.3 Join 시 salting 기법

Join 연산 시에 특정 key 에 데이터가 몰리는 경우, Salting 기법을 사용해서 데이터 분포를 인위적으로 균등하게 만드는 방법이다. 새로운 salt 작업용 컬럼을 추가하고, 균등하게 분포되도록 값을 지정해준다. 그리고 join 연산에 join 할 대상 컬럼과 salting 된 컬럼을 포함하여 조인한다.

from pyspark.sql.functions import monotonically_increasing_id

# Salting 기법 적용 - salt 라는 컬럼을 새로 추가한다. 
# salt 컬럼에 들어가는 값은 골고루 분포하도록 인위적으로 조정한다. 
def add_salt(df, column, salt_range=10):
    return df.withColumn("salt", (monotonically_increasing_id() % salt_range))

fact_df = add_salt(fact_df, "join_key")
dim_df = add_salt(dim_df, "join_key")

# Salting된 컬럼을 포함하여 조인
joined_df = fact_df.join(dim_df, ["join_key", "salt"], "inner")

5.4 Join 시 Broadcasting Join 기법 사용하기

spark broadcasting join 을 사용하는 경우, 작은 테이블을 모든 spark worker node에 복제하게 된다. 따라서 shuffle 현상을 방지해서 data skew를 방지할 수 있다. 단, 대상 테이블이 작을 경우에 효과적이다.

from pyspark.sql.functions import broadcast

joined_df = fact_df.join(broadcast(dim_df), "join_key", "inner")

broadcast join

6. 결론

Data Skew 는 Spark 작업 성능을 저하시키는 중요한 문제 중 하나여서, 관련된 Spark 튜닝 기법에 대해 정리해보았다. Data Skew 현상을 잘 해결해야 Spark 분산처리의 이점을 극대화시킬 수 있다.

Reference