Kafka를 이해하려면 Log부터 이해하자 (feat. WAL, 메시지 로그, Event Sourcing)

로그는 왜 중요할까요?
단순한 기록처럼 보이던 로그가, 어떻게 시스템 간 데이터 흐름, 복구, 재처리, 확장을 가능하게 만드는 걸까요?

이 글에서는 Kafka와 함께, 로그 기반 아키텍처의 핵심 철학을 차근히 정리해보려 합니다.

 

들어가기에 앞서

우리는 서비스를 만들 때 다양한 시스템을 함께 사용합니다.

• 데이터베이스(DB): 사용자 정보, 거래 내역 등 구조화된 데이터를 저장
• 캐시(Redis 등): 빠른 응답을 위해 임시로 데이터를 저장
• 검색엔진(Elasticsearch): 텍스트 기반 검색과 분석을 지원
• 분석 시스템(Hadoop, Spark): 데이터를 수집하고 집계하여 비즈니스 인사이트를 도출

이 각각의 시스템은 서로 다른 목적과 다른 형식의 데이터 처리 방식을 갖고 있습니다.

 
문제는 여기서 시작됩니다.

이 시스템들이 하나의 흐름 속에서 유기적으로 연결되어야 함에도 불구하고, 현실은 다음과 같습니다.

• 어떤 시스템에서 데이터가 바뀌어도, 다른 시스템에는 즉시 반영되지 않음
• 시스템 간의 연결이 복잡한 수작업, 또는 ETL(Extract-Transform-Load) 프로세스로 이어짐
• 동일한 데이터를 여러 시스템에 중복 저장 및 재처리해야 함

예를 들어, 토스나 인터넷뱅킹 앱에서 계좌 잔액을 확인할 때, 방금 전에 ATM에서 돈을 인출했음에도 불구하고, 앱 화면에는 여전히 이전 잔액이 그대로 표시되는 경험을 해본 적 있으신가요?

이런 불일치는 단순히 “은행 점검 시간” 때문만은 아닙니다.
점검 시간과 무관하게도, ATM, 뱅킹 앱, 정산 시스템 등 여러 시스템이 각기 다른 시점의 데이터를 갖고 운영되기 때문입니다.

이는 ATM 시스템은 실시간으로 인출을 처리했지만,
앱은 여전히 30분 간격으로 동기화되는 복제본 DB나 캐시된 데이터를 조회하고 있을 수 있습니다.

그 결과, 사용자는 "뭐야? 나 돈 생각보다 많네?" 라는 착각을 하게 되고,
이는 자칫 불필요한 소비, 신뢰도 하락으로 이어질 수 있습니다.

 
ATM, 모바일 앱, 알림 서버, 정산 시스템 등은 각기 다른 목적과 기술 스택으로 구성된 분리된 시스템들이며,
이들이 실시간으로 연결되어 있지 않다면, 눈에 보이는 정보와 실제 상태는 언제든지 어긋날 수 있습니다. (일관성이 어긋남)

 

이로 인해 발생하는 문제는 단순한 불편을 넘어서, 데이터 불일치, 운영 복잡성 증가, 사용자 신뢰도 저하 등
서비스 전반에 영향을 주는 구조적 문제로 이어집니다.

 
이러한 문제를 해결하기 위한 핵심적인 발상의 전환은 다음과 같습니다.

시스템들의 현재 상태를 동기화하려 하지 말고, 변화의 흐름을 공유하자.

 
즉, 각 시스템이 제각각 상태를 갖는 것이 아니라
모든 데이터의 변경을 하나의 중앙 로그(log) 에 순서대로 기록하고,
각 시스템은 이 로그를 구독(subscribe) 하여 자신이 필요한 형태로 반영하게 하는 것입니다.
 

이렇게 중앙 로그 기반 시스템을 이용하면 다음과 같은 이점이 있습니다.

1. 시스템 간의 일관된 순서를 유지할 수 있습니다.
모든 데이터 변경이 중앙 로그에 시간 순서대로 기록되기 때문에,
각 시스템은 동일한 순서로 이벤트를 처리할 수 있고, 이로 인해 데이터의 일관성과 정합성이 자연스럽게 보장됩니다.
 
2. 중앙 로그만 유지하면 장애 복구나 과거 재처리도 가능합니다.
어떤 시스템이 일시적으로 다운되었더라도,
다시 시작할 때 해당 로그 지점부터 데이터를 이어받아 처리할 수 있어 복구 과정이 간단하고 안정적입니다.
또한 과거 로그를 다시 읽는 방식으로 데이터 재처리나 백필 작업도 손쉽게 수행할 수 있습니다.
 
3. 신규 시스템 추가 시에도 기존 시스템을 변경할 필요가 없습니다.
새로운 시스템은 단순히 중앙 로그를 구독하기만 하면 되고,
별도의 API 연동이나 양방향 인터페이스를 설계할 필요가 없습니다.
이로 인해 전체 아키텍처는 더 유연해지고, 서비스 확장이 빠르고 안전해집니다.

---

목차

1. 로그란 무엇인가?
    1.1 append-only 구조
    1.2 시간 순서대로 정렬된 이벤트 흐름
    1.3 파일, DB, 메시징 시스템 등 다양한 영역에서의 존재
2. 로그는 왜 중요한가?
    2.1 데이터베이스에서의 Write-Ahead Log (WAL)
    2.2 복구 가능성, 재처리 가능성
    2.3 상태 = 로그의 누적
3. 로그와 상태(State)의 관계
    3.1 “현재 상태는 로그의 결과물이다”라는 철학
    3.2 Event Sourcing 개념 소개
    3.3 흐름을 저장하고, 상태는 계산한다 – Event Sourcing의 본질
4. 로그의 종류
    4.1 데이터베이스 로그 (WAL, Undo/Redo Log)
    4.2 메시지 로그 - 데이터를 전달하는 또 하나의 로그
    4.3 애플리케이션 로그 vs 시스템 로그 vs 데이터 로그
5. Kafka는 로그를 어떻게 다루는가?
    5.1 Partition, Offset, Segment 구조
    5.2 Kafka가 로그 기반으로 얼마나 강력한 유연성을 제공하는지
6. 참고 자료

---

1. 로그란 무엇인가?

우리는 “로그(log)”라는 단어를 자주 듣습니다.
로그인이 실패했을 때 서버 로그를 보고, 애플리케이션에서 로그를 찍어 디버깅하고,
Kafka 같은 시스템에서는 로그 기반 메시징 구조를 이야기하죠.
 
하지만 여기서 말하는 “로그”는 단순한 오류 메시지 모음이 아닙니다.
시스템의 상태와 흐름을 표현하는 가장 단순하고 강력한 데이터 구조입니다.
이제부터 로그가 무엇인지, 왜 중요한지를 구조적으로 살펴보겠습니다.

1.1 append-only 구조

로그는 본질적으로 append-only 데이터 구조입니다.

• 새로운 기록은 항상 맨 끝에만 추가되고,
• 한 번 기록된 내용은 수정하거나 삭제하지 않습니다.

이러한 구조는 단순하지만 강력합니다.
데이터를 수정하지 않기 때문에, 언제든지 이전에 무슨 일이 있었는지를 정확히 추적할 수 있고,
문제가 생겼을 때 “언제, 무엇이, 어떻게 발생했는가”를 되짚는 근거가 됩니다.
 
이 구조는 시간적인 의미를 내포합니다.
앞에 있는 데이터는 항상 뒤에 있는 데이터보다 먼저 발생한 이벤트이며, 그 자체로 이벤트의 순서와 흐름을 보장해 줍니다.

즉, 로그는 단순한 목록이 아니라 시간 순서대로 정렬된 이벤트의 흐름입니다.

 

1.2 시간 순서대로 정렬된 이벤트 흐름

로그의 중요한 특징은 시간 순서 보장입니다.
모든 이벤트는 정해진 순서대로 기록되며, 그 순서 자체가 곧 이벤트의 의미와 맥락을 결정합니다.
 
예를 들어 다음 두 이벤트가 있습니다.

[1001] 사용자 A 로그인
[1002] 사용자 A 로그아웃

이 순서가 바뀐다면 의미도 완전히 달라집니다.
로그는 이런 식으로 “순서가 곧 법”인 세계입니다. (When in Rome, do as the Romans do.)
따라서 이벤트의 순서를 지키는 것만으로도 시스템의 상태 변화 과정을 완벽히 재구성할 수 있습니다.
 

1.3 파일, DB, 메시징 시스템 등 다양한 영역에서의 존재

현대 소프트웨어 시스템에서 로그는 다양한 계층과 기술 스택에서 핵심 역할을 합니다.

• 파일 시스템에서는 파일 변경 이력을 추적하기 위해 로그를 사용합니다.
• 데이터베이스에서는 Write-Ahead Log(WAL)를 통해 트랜잭션 무결성과 복구를 보장합니다.
• 분산 메시징 시스템(예: Apache Kafka)에서는 로그를 중심 구조로 삼아 데이터 스트리밍을 처리합니다.
• 버전 관리 시스템(예: Git)도 사실상 커밋 로그의 집합입니다.

다양한 시스템의 목적은 전부 다르지만,
그 밑바닥에는 늘 “무슨 일이 언제 일어났는지”를 순서대로 저장하는 로그 구조가 자리 잡고 있는 셈입니다.

---

2. 로그는 왜 중요한가?

앞서 로그가 단순히 "시간 순서대로 쌓이는 데이터"라고 했지만, 단순함 속에 강력한 시스템적 역할이 숨어 있습니다.
실제로 많은 시스템들은 로그를 통해

• 데이터의 무결성을 지키고,
• 장애 발생 시 복구하며,
• 과거의 상태를 재현하거나 재처리합니다.

로그는 단순한 기록이 아니라, 시스템을 안정적이고 일관성 있게 만드는 핵심 구조입니다.
 

2.1 데이터베이스에서의 Write-Ahead Log (WAL)

데이터베이스는 트랜잭션의 원자성과 내구성을 보장해야 합니다.
이를 위해 대부분의 DB는 WAL (Write-Ahead Logging) 방식을 사용합니다.
 

WAL의 핵심 개념: “먼저 로그에 쓰고, 그 다음 실제 데이터를 변경한다.”

예를 들어 사용자가 은행 앱에서 계좌 이체를 할 경우, DB는 먼저 다음과 같은 로그를 기록합니다.

[TX#1] 계좌 A → 계좌 B로 100,000원 송금 예정

그리고 나서야 실제 데이터베이스의 계좌 잔액을 변경합니다.
이렇게 하면 시스템이 갑자기 꺼지더라도, 다시 시작할 때 이 로그를 기반으로 "무슨 일이 있었는지"를 재현할 수 있습니다.

로그가 없다면, 장애가 발생했을 때 데이터의 일관성을 유지할 방법이 없습니다.

 

2.2 복구 가능성, 재처리 가능성

로그가 존재한다는 건, 과거에 어떤 일이 있었는지 전부 기록되어 있다는 뜻입니다.
이 덕분에 시스템은 단순히 현재 상태만 보고 추측하는 것이 아니라,
정확히 어떤 순서로 어떤 변화가 있었는지를 따라가며 문제를 복구하거나, 새로운 처리를 할 수 있습니다.

① 장애 복구

예를 들어, 특정 마이크로서비스가 일시적으로 장애로 중단되었다고 해봅시다.
만약 이 서비스가 중앙 로그에서 이벤트 스트림을 읽고 처리하는 구조였다면,
재시작 시 “내가 마지막으로 읽었던 위치(offset)는 어디였지?”만 확인하면 됩니다.
→ 그리고 거기서부터 다시 읽기 시작하면, 이전처럼 다시 데이터를 처리할 수 있습니다.
복잡한 재시도 로직 없이도, "로그가 남아 있기 때문에 다시 할 수 있는 것"입니다.

② 신규 시스템 초기화

새로운 서비스가 추가됐다고 가정해겠습니다.
예를 들어, 기존 주문 데이터를 분석해서 추천을 해주는 추천 시스템을 만든다고 할 때,
우리는 과거 데이터를 모두 가져와서 초기 모델을 학습시키는 작업이 필요하겠죠.
→ 이때 로그 기반 구조에서는 처음부터 로그를 읽기만 하면,
해당 초기 모델을 학습시키는 시스템도 과거 이벤트를 순서대로 따라가며 자신만의 초기 상태를 만들 수 있습니다.
별도 백업 파일을 불러올 필요 없이, “로그만 읽어도 스스로 상태를 만들 수 있는 구조”가 됩니다.

③ 잘못된 처리의 롤백/재실행

실제로 운영 중인 시스템에서는 “특정 날짜에 잘못된 코드가 배포돼서 엉뚱한 데이터가 저장되는”는 상황을 가정하겠습니다.
→ 이런 경우, 로그 기반 시스템에서는 문제가 생긴 시점 이전으로 돌아가 해당 구간의 이벤트만 다시 재처리하는 방식으로
데이터를 복원하거나 교정할 수 있습니다.
즉, 필터링 조건을 줘서 “이벤트 중 사용자 A의 것만 다시 실행”을 하는 것입니다.
이는 과거 이벤트가 순서와 함께 보존되어 있기 때문에 가능한 일입니다.
 
Kafka 같은 시스템이 로그를 중심에 두는 이유도 바로 여기에 있습니다. 데이터 흐름의 ‘이력’을 남기기 때문에 

• 장애 복구가 단순하고,
• 신규 시스템 추가가 유연하며,
• 문제 발생 시 재처리가 가능해

유연하고 안전하게 시스템을 유지보수할 수 있습니다.
 

2.3 로그의 누적 = 상태

로그의 누적은 상태(State)를 나타냅니다.

어떤 시스템이 지금 어떤 상태인지를 알고 싶다면, 단순히 현재 값만 보면 되는 게 아니라,
어떤 변화들이 있었는지를 알아야 정확히 이해할 수 있습니다.

 
예를 들어 계좌 잔액이 320,000원이라고 해도, 그 수치를 만든 건 다음과 같은 로그들의 누적입니다.

[1] +100,000
[2] +50,000
[3] -30,000
[4] +200,000

즉, 로그를 보면 왜 상태가 지금의 형태가 되었는지를 알 수 있고, 로그만 있으면 지금 상태를 다시 계산해낼 수도 있습니다.
이 사고방식은 Kafka뿐 아니라, Event Sourcing, CQRS, Git, 블록체인 같은 시스템들의 기본 철학이기도 합니다.

---

3. 로그와 상태(State)의 관계

3.1 “현재 상태는 로그의 결과물이다”라는 철학

전통적인 시스템에서는 상태(state)를 "현재 값"으로만 봅니다.
예를 들어 데이터베이스에서 SELECT * FROM users WHERE id = 1을 하면
그 시점의 User 정보를 보여줍니다.
 
하지만 로그 기반 시스템의 철학은 이와 다릅니다.

로그 기반 시스템의 철학: 현재 상태는 과거의 모든 이벤트가 순차적으로 누적된 결과일 뿐이다.

예를 들어, 특정 사용자의 포인트가 3,200점이라면, 이건 단순히 users 테이블의 값일 수도 있지만,
로그 기반 시스템에서는 다음과 같은 이벤트의 누적 결과입니다.

[Event 1] 사용자 가입
[Event 2] 출석 보너스 +1000
[Event 3] 상품 구매 포인트 +500
[Event 4] 리뷰 작성 +200
[Event 5] 사용 -500
[Event 6] 이벤트 참여 +2000

즉, 상태는 로그의 스냅샷이자 요약본입니다.
이런 사고방식을 따르면 시스템의 과거를 완벽하게 추적할 수 있고,
상태가 이상하면 “왜 이런 상태가 되었는지”를 로그를 통해 거슬러 올라가 확인할 수 있습니다.
 

3.2 Event Sourcing 개념 소개

출처: https://sabarada.tistory.com/231

이 철학을 체계적으로 구현한 대표적인 패턴이 바로 Event Sourcing입니다.
Event Sourcing은 상태(state)를 직접 저장하지 않고, 이벤트(event)의 흐름만 저장합니다.
그리고 필요할 때마다 이 이벤트들을 순서대로 적용해서 상태를 계산해냅니다.

마치 게임 리플레이처럼, 모든 동작을 처음부터 다시 재생하면 현재 상태가 똑같이 만들어지는 구조입니다.

 
이 방식의 장점은 다음과 같습니다.

• 언제든지 특정 시점의 상태로 되돌릴 수 있음 (time-travel debugging)
• 과거 이벤트를 새로운 방식으로 재해석할 수 있음 (새로운 기능 추가 시 유용)
• 상태가 아닌 변화의 이유 자체를 저장하므로 신뢰성과 추적 가능성이 높음
• 변경 이력이 그대로 남아 감사나 롤백에 유리함
• 새로운 시스템도 과거 이벤트를 처음부터 읽기만 하면 상태를 구성할 수 있음

하지만 단점도 존재합니다.

• 이벤트가 많아질수록 전체를 다시 재생하는 데 시간이 오래 걸릴 수 있음
  → 보통은 일정 주기마다 스냅샷(snapshot) 을 만들어두고 그 시점부터 이어서 재생합니다.
• 데이터 용량이 계속 증가하기 때문에 로그 보관 전략이 필요합니다 (압축, 아카이빙 등)
• 개념 자체가 어렵고, 모델링도 복잡할 수 있습니다
• 상태 계산을 위한 Read Model 또는 CQRS 구조가 필요해져 아키텍처가 복잡해질 수 있습니다
• 이벤트 순서 보장, 중복 처리 방지 등 정합성을 유지하기 위한 설계 고려가 필요합니다

따라서 Event Sourcing은 분명 강력한 패턴이지만, 모든 상황에 정답은 아닙니다.
시스템이 정확성・추적 가능성・재처리 가능성을 중요하게 여긴다면 훌륭한 선택이 될 수 있지만,
반대로 데이터 양이 많거나, 단순한 CRUD 중심의 서비스에는 오히려 복잡도와 비용을 높이는 요소가 될 수도 있습니다.
 

3.3 흐름을 저장하고, 상태는 계산한다 – Event Sourcing의 본질

결국 Event Sourcing은 단순한 설계 기법을 넘어,
로그를 중심으로 시스템을 바라보는 철학적 접근이자 아키텍처 전략입니다.
이러한 철학을 인프라 차원에서 구현하고 있는 대표적인 시스템이 바로 Kafka입니다.
 
Kafka 역시 상태를 직접 저장하지 않지만,
상태를 구성하는 데 필요한 이벤트 흐름 전체를 중앙에서 안정적으로 전달하고, 오랫동안 보존하는 역할을 합니다.
 
그렇다면 Kafka는 이 로그를 내부적으로 어떻게 저장하고, 다양한 시스템은 이 이벤트 흐름을 어떻게 구독하고 동기화할 수 있을까요?
그 구조적 기반은 [5. Kafka는 로그를 어떻게 다루는가?]에서 다루고 있습니다.

---

4. 로그의 종류

지금까지 "로그(log)"를 하나의 추상 개념처럼 다뤄왔지만, 실제 시스템에서는 로그의 형태와 목적이 매우 다양합니다.

• 어떤 로그는 시스템 복구를 위해 존재하고,
• 어떤 로그는 메시지를 전달하기 위한 핵심 기반이며,
• 어떤 로그는 단순한 기록일 뿐 사람이 보기 위한 용도입니다.

로그는 그 목적에 따라 다르게 설계되고, 다르게 쓰입니다.
이번 장에서는 대표적인 로그 종류들을 정리했습니다.

• 데이터베이스 로그
• 메시지 로그
• 애플리케이션 로그 vs 시스템 로그 vs 데이터 로그

 

4.1 데이터베이스 로그 (WAL, Undo/Redo Log)

데이터베이스 로그를 이해하기 위해 먼저 트랜잭션의 동작 구조를 짚고 넘어가겠습니다.

트랜잭션과 커밋

트랜잭션이란, 하나의 논리적 작업 단위를 말합니다.
예를 들어, 계좌 이체는 출금과 입금이 함께 이루어져야만 의미가 있는 작업입니다.
중간에 하나라도 실패하면 전체 작업을 취소해야 합니다.
이런 이유로 데이터베이스는 트랜잭션이라는 개념을 도입했고, 다음과 같은 흐름으로 처리됩니다.

1. 트랜잭션 시작 (BEGIN)
2. 여러 변경 작업 수행 (INSERT, UPDATE 등)
3. 트랜잭션 종료 → COMMIT 또는 ROLLBACK
4. 커밋된 변경 내용을 디스크에 반영

여기서 중요한 것은 바로 "커밋(Commit)"입니다.
커밋이 일어난다는 건, "이제 이 작업은 진짜 반영해도 괜찮다"는 최종 선언입니다.
 
하지만 문제는, 커밋 직전이나 직후에 장애가 발생했을 경우입니다. 이때 시스템이 무결성과 신뢰성을 유지하려면 어떻게 해야 할까요?
 

WAL과 Undo / Redo 로그의 역할

대부분의 관계형 데이터베이스(RDBMS)는 트랜잭션의 무결성(ACID)과 장애 복구(Recovery)를 위해 로그 기반 저장 전략을 사용합니다. 그중 대표적인 방식이 바로 WAL (Write-Ahead Logging)과 Undo / Redo 로그 구조입니다.
 

WAL (Write-Ahead Logging)

2.1에서 다뤘듯이,  WAL은 이름 그대로 "먼저 로그에 쓰고, 그 다음에 실제 데이터를 바꾼다"는 전략입니다.
 

WAL의 흐름은 다음과 같습니다.

1. 트랜잭션 실행 중, 변경 내용이 발생
2. 해당 변경을 WAL에 먼저 기록 (flush)
3. 로그 기록이 완료된 후에야 실제 데이터에 반영

이 과정 중 장애가 발생하더라도, 기록된 로그를 기반으로 다음과 같은 처리가 가능합니다.

• 실패한 트랜잭션 → Undo 로그로 되돌리기
• 커밋된 트랜잭션 → Redo 로그로 다시 반영하기

이처럼 WAL은 단순한 기록이 아니라, 복구와 무결성을 책임지는 핵심 메커니즘입니다.
 
* 중요
ACID의 A (Atomicity): 트랜잭션은 모두 성공하거나 전부 취소되어야 합니다.
→ WAL은 실패한 트랜잭션을 되돌리기 위해 Undo Log를 제공합니다.
 
ACID의 D (Durability): 커밋된 트랜잭션은 시스템이 꺼지더라도 반드시 유지되어야 합니다.
→ WAL은 커밋된 변경 내용을 Redo Log를 통해 끝까지 반영할 수 있도록 보장합니다.
 

Undo Log: 실패한 트랜잭션을 되돌리기

Undo Log는 “되돌리기용 백업본”입니다.
트랜잭션 도중 예외나 장애가 발생하면, 시스템은 해당 트랜잭션이 남긴 변경 사항을 모두 취소하고 이전 상태로 되돌려야 합니다
 

Undo Log 예시

• 계좌 잔액: 100,000원
• -30,000 인출 시도 중 장애 발생
• → Undo 로그 참고 → 100,000원으로 복원

Undo 로그는 변경 전의 값을 기록하고 있다가, 커밋되지 않은 트랜잭션이 실패하면 이를 이용해 상태를 복구합니다.

Undo Log 철학: "커밋하지 않았다면, 아무 일도 없었던 것처럼 되돌려야 한다."

 

Redo Log: 완료된 작업을 다시 반영

반대로, 트랜잭션이 커밋은 되었지만, 디스크 반영 전에 시스템이 다운되었다면 어떻게 해야 할까요?
이 경우에는 그 작업이 "정상적으로 완료된 작업"이므로, 시스템 재시작 시 반드시 끝까지 반영해야 합니다.
Redo Log는 커밋된 트랜잭션의 변경 내역을 기억하고 있다가, 시스템 재시작 시 이를 다시 적용합니다.

 
Redo Log 예시

• -30,000 인출 후 커밋 완료
• 디스크 반영 전에 서버 다운
• → Redo 로그 참고 → -30,000 다시 반영

Redo 로그는 성공한 트랜잭션의 결과를 끝까지 책임지는 역할을 합니다.

Redo Log 철학: "커밋됐다면, 반드시 적용되어야 한다."

 

Undo/Redo Log 요약

종류	목적	언제 쓰이나?
Undo Log	실패한 트랜잭션을 되돌리기	커밋 전 장애, 중단, 롤백 요청 등
Redo Log	커밋된 작업을 마저 반영하기	커밋은 됐는데, 반영 전 시스템 종료 시

이처럼 데이터베이스 로그는 단순한 기록을 넘어서, 시스템의 무결성과 복구 가능성을 보장하는 핵심 인프라입니다.
WAL, Undo, Redo 로그는 모두 ACID 특성 중 Atomicity(원자성)와 Durability(지속성)를 구현하기 위한 장치입니다.
 

4.2 메시지 로그 - 데이터를 전달하는 또 하나의 로그

앞서 데이터베이스는 시스템 내부 상태를 일관되게 유지하기 위해 로그를 사용했습니다.
하지만 오늘날의 서비스는 단일 시스템이 아닌, 여러 시스템이 서로 데이터를 주고받는 구조로 구성됩니다.
이때 데이터를 시스템 간에 전달하고 공유하기 위한 방식으로 등장한 것이 바로 메시지 로그(Message Log)입니다.

 

메시지 로그란 무엇인가?

메시지 로그는 이름 그대로, 시간 순서대로 메시지를 기록하고 전달하는 구조화된 로그 시스템입니다.

• 데이터는 append-only 형태로 저장되고,
• 각 수신자는 원하는 시점부터 메시지를 읽을 수 있으며,
• 기록된 메시지는 일정 시간 또는 용량 조건에 따라 보존됩니다.

즉, 메시지 로그는 단순한 통신 수단이 아니라 시간 흐름에 따라 발생한 데이터의 변화(이벤트)를 남기는 일종의 “전달용 타임라인”입니다.

 

메시지 로그가 필요한 이유

우리는 흔히 시스템 간 통신을 위해 다음과 같은 방식을 사용합니다.

• REST API: 시스템 A가 시스템 B의 HTTP 엔드포인트를 호출하여 요청/응답을 주고받는 구조
• RPC (Remote Procedure Call): 마치 로컬 함수를 호출하듯, 다른 시스템의 기능을 네트워크를 통해 호출하는 방식
  예시: gRPC, Thrift 등

이러한 방식은 요청한 시점에 즉시 응답을 받아야 하며, 동기적으로 동작하는 것이 기본입니다.
즉, "나 지금 물어봤으니까 너 바로 대답해줘”라는 구조입니다.
 
이 방식은 간단하고 직관적이지만, 다음과 같은 문제를 가지고 있습니다.

• 요청 시점에 상대 시스템이 죽어 있으면 통신 자체가 실패
• 실시간성이 강한 대신 장애 전파가 쉬움 (하나 멈추면 전체가 멈춤 - 강결합)
• 데이터를 다시 처리하거나 복구하는 데 불리함

여기서 메시지 로그가 등장합니다.

메시지 로그는 요청-응답 구조가 아닌, “이벤트를 남겨놓고 알아서 가져가라”는 구조입니다.
즉, 메시지 로그는 데이터를 직접 건네는 것이 아니라, 중앙 로그에 기록해두고 필요할 때 읽게 하는 방식입니다.
이로 인해 시스템 간 통신이 비동기적이고 유연하게 바뀌며,
장애 복구, 재처리, 확장성 측면에서 훨씬 더 강력한 아키텍처를 만들 수 있습니다.

일반 API 방식 (Rest API, RPC)	메시지 로그 방식
데이터를 직접 호출해서 전송	데이터를 로그에 적어두고, 수신자가 읽음
실시간 수신 실패 시 손실 가능	로그에 남아 있으므로 나중에 다시 읽을 수 있음
실시간성이 강하지만 유연성 부족	실시간 + 재처리 유연성 모두 확보 가능

 

메시지 로그의 일반적 구조

1. Producer가 메시지를 생성하여 로그에 기록합니다.
2. 메시지는 시간 순서대로 저장됩니다.
3. Consumer는 자신이 필요한 시점부터 메시지를 구독하여 처리합니다.

여기서 중요한 점은 “읽기와 쓰기가 느슨하게 분리되어 있다는 것”입니다.
이 덕분에 여러 Consumer가 각자 다른 속도로, 다른 목적에 맞게 메시지를 처리할 수 있습니다.

 

메시지 로그의 핵심 특징

• Append-only 구조
  데이터는 항상 끝에 추가되며, 중간 수정이나 삭제는 없습니다.
• 시간 순서 보장
  메시지는 기록된 순서대로 소비되므로 이벤트 순서를 보장할 수 있습니다.
• 복수 Consumer의 독립 처리
  하나의 메시지를 여러 시스템이 각자의 용도에 따라 처리할 수 있습니다.
• 재처리 가능성
  메시지가 삭제되지 않고 일정 기간 보존되기 때문에, 장애가 발생해도 다시 읽어 복구나 분석에 활용할 수 있습니다.

 

대표적인 메시지 로그 시스템 – Kafka

이러한 메시지 로그 개념을 실용적인 시스템으로 구현한 대표적인 예가 바로 Apache Kafka입니다.
Kafka는 메시지를 토픽(topic)이라는 단위로 나누어 각 토픽마다 append-only 로그를 유지합니다.
각 메시지는 고유한 offset을 가지며, Consumer는 이 offset을 기준으로 메시지를 순차적으로 읽을 수 있습니다.

Kafka는 단순한 메시지 큐가 아니라, 메시지 로그를 중심에 둔 데이터 전달 인프라라고 볼 수 있습니다.

그 외에도 NATS, Pulsar, Redpanda, AWS Kinesis 등 다양한 메시지 로그 시스템이 존재하며,
모두 공통적으로 시간 순서, 재처리, 비동기 처리라는 철학을 공유합니다.

 

메시지 로그 요약

• 메시지 로그는 시스템 간 데이터 흐름을 시간 순서대로 기록하고 공유하는 구조입니다.
• 직접 호출이 아닌, 중앙 로그를 기반으로 데이터를 전달하는 방식은 시스템 간 연결을 더 유연하고 느슨하게 만들어줍니다.
• 장애가 발생하거나 처리가 지연되더라도, 남아 있는 로그를 다시 읽어 복구하거나 재처리할 수 있습니다.
• Kafka는 이를 구현한 대표적인 시스템이지만, 메시지 로그는 그보다 더 범용적인 설계 개념입니다.

 

4.3 애플리케이션 로그 vs 시스템 로그 vs 데이터 로그

“로그”라는 단어는 개발 현장에서 정말 많이 사용되지만, 그 의미가 문맥에 따라 조금씩 다릅니다.
이번 장에서는 실무에서 자주 쓰이는 세 가지 로그 종류를 구분해서 정리해 보겠습니다.
 

애플리케이션 로그

애플리케이션 로그는 개발자가 코드 내부에서 직접 출력하는 로그입니다.

log.info("결제 요청 시작: orderId=123");
log.error("결제 실패: timeout");

 

예시:

 

• 서비스 흐름 추적
• 디버깅
• 오류 발생 시 원인 파악
• 모니터링 도구(Grafana, ELK, CloudWatch 등)와 연동

사람이 읽기 좋도록 쓰는 로그 → 개발자나 운영자가 문제 상황을 분석하는 데 초점

 

시스템 로그

운영체제, 서버, 네트워크 장비 등에서 자동으로 남기는 로그입니다.
예: syslog, dmesg, /var/log/messages, AWS EC2 인스턴스 상태 로그 등
 
주요 특징

• 하드웨어, 커널, 프로세스 상태에 대한 정보
• 시스템 수준의 장애 추적, 성능 분석
• 보안 감시 및 감사(Audit) 로그 포함

인프라 관점의 이벤트 기록 → DevOps나 시스템 관리자에게 중요한 로그

 

데이터 로그 (or 이벤트 로그)

앞서 설명한 Kafka 등의 메시지 로그 시스템에서 다루는 시간 순서대로 발생한 데이터 변경의 흐름을 기록한 로그입니다.
 
예시:

• 사용자 주문 생성 이벤트
• 결제 완료 이벤트
• 배송 출발 이벤트

이러한 로그는 단순 출력이 아니라, 시스템 간 데이터 동기화, 분석, 실시간 처리에 활용됩니다.

기계가 읽고, 다시 처리하는 구조화된 로그 → 이벤트 스트리밍, 데이터 파이프라인, 마이크로서비스 간 통신 등에 사용

 

요약 

로그 종류	목적	예시	읽는 대상
애플리케이션 로그	디버깅, 흐름 추적, 오류 분석	log.info(...)	개발자, 운영자
시스템 로그	OS/인프라 상태 추적	syslog, dmesg	시스템 관리자
데이터 로그	데이터 전파, 이벤트 처리, 분석용	Kafka 메시지 로그	시스템, 분석 엔진

이 세 가지 로그는 모두 "기록"을 다루지만, 용도와 설계 철학이 전혀 다릅니다.

• 애플리케이션/시스템 로그는 사람이 읽기 위한 로그
• 데이터 로그는 기계가 읽고 처리하기 위한 로그

따라서 로그 설계 시 다음과 같은 항목을 고민하는 것이 중요합니다.

• “이 로그는 누구를 위한 것인가?”,
• “읽고 다시 처리할 필요가 있는가?”,
• “실시간성이 필요한가?”

---

 

5. Kafka는 로그를 어떻게 다루는가?

    5.1 Partition, Offset, Segment 구조
    5.2 Kafka가 로그 기반으로 얼마나 강력한 유연성을 제공하는지
 

6. 참고 자료

The Log: What every software engineer should know about real-time data's unifying abstraction, by Jay Kreps, 2013