555. 이벤트 소싱 (Event Sourcing) - CRUD 대신 상태 변경 이력(Event) 자체를 추가(Append-only) 저장

핵심 인사이트 (3줄 요약)

1. 본질: 이벤트 소싱(Event Sourcing)은 데이터베이스에 현재의 최종 잔고(ex. 100만 원)만 덜렁 덮어쓰는(UPDATE/DELETE) 낡은 CRUD(상태 중심) 짓거리를 쓰레기통에 박아버리고, "50 입금함", "20 출금함" 이라는 과거부터 현재까지 일어난 '모든 상태 변경의 발자취(Event Log)' 자체를 단 1줄의 삭제 없이 무한히 기록(Append-only)하는 블록체인급 회계 장부 아키텍처다.
2. 가치: 데이터가 덮어씌워져 유실되지 않으므로 어떤 버그가 터져도 과거 100년 치의 로그를 처음부터 고속 재생(Replay)하면 **100% 무결점으로 현재 상태(State)가 다시 부활하는 극강의 재해 복구(Resilience)**를 달성하며, 버려지던 중간 과정 로그들이 AI 분석과 개인화 타겟팅을 위한 최고급 '데이터 금광'으로 뒤바뀐다.
3. 융합: 이벤트 100만 개를 덧셈해서 현재 잔고를 보여주면 조회(Read) 성능이 박살 나므로, 이를 해결하기 위해 상태 스냅샷(Snapshot)을 굽고, 완벽하게 분리된 읽기 전용 DB를 띄워주는 CQRS(554장) 아키텍처 및 사가(Saga) 패턴의 보상 트랜잭션과 융합되어 거대한 비동기 클라우드 시스템의 영혼(Source of Truth)으로 군림한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: 은행 통장 입출금 내역을 생각해 보라. 우리는 통장을 볼 때 현재 잔고 100만 원이라는 딱 1줄만 보지 않는다. 3월 1일 월급 200만 원 들어옴 ➡ 3월 2일 치킨 3만 원 씀 ➡ 3월 3일 월세 50만 원 빠짐 이 3줄의 이력(Event)을 차례대로 덧셈 뺄셈(Fold/Reduce)하면 결과적으로 147만 원이라는 현재 상태(State)가 수학적으로 도출된다. 이력만 꽉 쥐고 있으면 언제든 현재를 증명할 수 있다는 사상이 '이벤트 소싱'이다.

• 필요성(기존 CRUD의 치명적 한계): 지금까지 백엔드 개발자 99%는 JPA나 MyBatis로 UPDATE user SET balance = 50 이라는 SQL을 날렸다. 이 짓의 가장 큰 비극은? **"이전의 과거 데이터(History)가 영원히 증발해 날아가 버린다"**는 점이다. 해커가 뚫고 들어와서 잔고를 1억으로 UPDATE 쳐놨다. 회사 사장님이 "야! 어제 새벽 3시 상태로 당장 되돌려놔!" 소리치는데, DB에는 덮어 씌워진 1억 원 딱 1줄뿐이다. 과거를 되돌릴 타임머신이 물리적으로 아예 멸종해 버린 상태 중심(State-oriented) 설계의 끔찍한 결함이다. 이를 막으려면 모든 이력을 영원히 화석처럼 박제(Append)해야 한다.

• 💡 비유: CRUD 방식은 장기판의 **'말 위치만 덜렁 기억하는 것'**입니다. 체스판에 말이 쫙 깔려있는데 동생이 장난치느라 말을 다 엎어버렸습니다. 어디 있었는지 복구가 100% 불가능합니다. 이벤트 소싱(Event Sourcing)은 **'체스 경기 기보(기록지)'**를 빽빽하게 적어두는 것입니다. "1수: 폰 전진 ➡ 2수: 나이트 전진 ➡ 100수: 퀸 이동." 체스판(현재 DB 상태)이 산산조각이 나도 아무 걱정 없습니다. 그냥 빈 체스판을 가져와서 기보 1번부터 100번까지 1초 만에 촤르륵 다시 두어버리면(Replay), 완벽하게 엎어지기 1초 전의 체스판 세팅 상태가 100% 무결점으로 부활하는 타임머신 마술입니다.

• 등장 배경 및 발전 과정:

  1. 전통 회계 장부 사상: 컴퓨터가 나오기 100년 전부터 은행원들은 장부에 화이트(지우개)를 쓰면 감옥에 갔다. 실수로 100원을 더 줬으면 지우지 않고 마이너스(-) 전표를 한 장 더 끊어(Append) 밑에 이어붙였다.
  2. CQRS 패턴과의 융합 폭발: CQRS로 쓰기와 읽기 DB를 찢었는데, 동기화가 깨져 복구할 방법이 없자 아키텍트들이 멘붕에 빠졌다. "야, 아예 쓰기 DB를 UPDATE 못 치는 무한 로그 장부(이벤트 소싱)로 깔아버려! 그럼 언제든 재생해서 읽기 DB 100번 복원할 수 있잖아!"
  3. Event-Driven Architecture (EDA)의 궁극체: Kafka 시대가 열렸다. 이벤트를 쏴대는데, 그 쏘는 이벤트 텍스트 쪼가리 자체를 아예 RDBMS나 EventStore DB에 영구 보존 원장(Source of Truth)으로 삼아버리는 클라우드의 절대 표준으로 격상됐다.

• 📢 섹션 요약 비유: 기존 방식(CRUD)이 매일 화이트로 덧칠하며 **'숫자 하나만 덜렁 남긴 낡은 칠판'**이라면, 이벤트 소싱은 내가 태어날 때부터 지금까지 겪은 모든 대화를 초 단위로 녹음해 둔 **'비행기 블랙박스(Flight Data Recorder)'**입니다. 비행기(서버)가 산산조각이 나도 블랙박스만 주워 오면, 엔진이 왜 터졌고 조종사가 무슨 말을 했는지(디버깅) 초 단위로 완벽하게 100% 과거를 시뮬레이션할 수 있는 절대 무적의 아키텍처입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 이벤트 소싱의 동작 원리 (무한 Append-only 궤도)

UPDATE와 DELETE 쿼리 문법이 소스코드에서 완전히 말살된 100% INSERT(Append) 지향형 뇌 구조.

[ 🛡️ 장바구니 담기 도메인 시나리오 ]

1. 기존 CRUD (쓰레기): 장바구니 DB 테이블에 사과, 바나나 들어있음. 고객이 사과 빼고 포도 넣음. DB는 UPDATE 쳐져서 바나나, 포도만 덜렁 남음. (사과 뺐다는 소중한 이탈 데이터는 우주로 증발).
2. Event Sourcing (진정한 금광):
   • 1초: Event 1 = { action: "장바구니_생성", item: "사과" } INSERT 쾅!
   • 2초: Event 2 = { action: "상품_추가", item: "바나나" } INSERT 쾅!
   • 5초: Event 3 = { action: "상품_제거", item: "사과" } DELETE 안 함! 취소 이력을 INSERT 쾅!
   • 10초: Event 4 = { action: "상품_추가", item: "포도" } INSERT 쾅!
3. 상태 계산 (Reduce/Replay): 고객이 "장바구니 조회" 누르면, 저 4개의 로그를 1초 만에 덧셈/뺄셈 계산기 돌려서 [바나나, 포도]라는 현재 결과 뷰(View)를 뿅 하고 뱉어낸다. (물론 CQRS를 섞어야 빠름)

2. 극강의 타임머신 복구(Time Travel & Replay) 마술 💥

개발자의 목숨을 살려주는 이벤트 소싱의 핵심 무기.

• 상황: 새벽 3시에 주니어 개발자가 버그를 배포해서, 쿠폰 지급 함수가 "쿠폰 발급됨"이 아니라 "포인트 발급됨"으로 10만 건이 잘못 찍혀 들어갔다.

• 기존 CRUD의 파멸: 10만 명의 포인트가 UPDATE로 섞여버렸다. 백업용 DB 덤프를 덮어쓰려니, 그 찰나에 들어온 정상 유저 결제 내역까지 싹 다 날아간다. 퇴사.

• Event Sourcing의 기적 (Replay):

  1. 버그 났던 새벽 3시 이후의 잘못된 이벤트 로그 10만 줄을 특정 꼬리표(Version/Timestamp)로 삭제 선(무효화) 그어버린다.
  2. 버그 난 소스코드를 고치고 핫픽스 배포한다.
  3. "자! 쿠폰 발급 1번 이벤트부터 다시 쏴라(Replay)!" 명령어 딱 1줄 친다.
  4. 인프라가 1번부터 10만 번 이벤트를 빛의 속도로 다시 덧셈하며 새로운 100% 무결점 상태(State) 장부를 허공에서 1초 만에 재창조(Materialized)해 낸다. 아무런 데이터 유실도, 사이드 이펙트도 없는 완벽한 타임 여행이다.

• 📢 섹션 요약 비유: 이 타임머신은 **'오케스트라 악보 연주'**와 같습니다. 연주(현재 상태)가 엉망이 되더라도 지휘자(개발자)는 빡칠 필요 없습니다. 악보(Event 원장)는 100% 무사히 남아있으니까요. 그냥 "야! 3악장 처음부터 다시 똑같이 연주해!(Replay)" 지시만 내리면, 오케스트라는 1번부터 똑같은 이벤트를 발생시키며 완벽한 곡(State)을 허공에 100% 무결점으로 다시 뽑아내어 그려줍니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 기존 RDBMS(CRUD) vs Event Sourcing 철학 비교

아키텍트가 DB 설계 사상을 바닥부터 뒤집을 때 설득해야 하는 표.

과목 융합 관점

• 소프트웨어 공학 (CQRS와의 절대적 공생 결합): 554장에서 봤듯, 이벤트 소싱은 쓰기(Command) 성능의 신이지만 조회(Query) 성능의 쓰레기다. 고객 잔고를 보려는데 10년 치 입출금 이벤트 100만 줄을 매번 SELECT 해서 덧셈(Fold)하면 디도스(DDoS) 공격이나 다름없다. 그래서 무조건 CQRS로 찢어야 한다! EventStore(쓰기)에 이벤트가 1줄 추가될 때마다 카프카로 툭 던지고, 반대편 읽기 전용 Redis 서버(View)가 그걸 받아 Balance = Balance + 50 1통짜리 JSON으로 예쁘게 구워(Materialized) 둔다. 유저는 빛의 속도로 Redis의 찰흙(스냅샷)만 보고 나가면 되는 천생연분 아키텍처다.

• 클라우드 / MSA 트랜잭션 (사가 패턴과 보상 트랜잭션의 오아시스): 551장의 보상 트랜잭션(환불)을 생각해 보라. CRUD 방식에서 환불(-100원) 코드를 수동으로 짜는 건 지옥의 엣지 케이스를 낳았다. 하지만 이벤트 소싱은 애초에 설계 바닥 철학 자체가 "이벤트는 취소할 수 없다. 오직 반대되는 이벤트를 추가할 뿐이다"라는 어펜드 온리(Append-only)다! 보상 트랜잭션이라는 끔찍한 난이도의 코딩이, 그저 평범하게 {"type": "환불_이벤트", "amount": -100} 1줄 딱지 써서 던지는 아주 우아하고 아름다운 기본 일상 행위로 녹아들어버리는 기적이 일어난다.

• 📢 섹션 요약 비유: CRUD 방식의 락(Lock) 경합은 **'칠판 하나에 10명의 학생이 달려들어 지우개와 분필로 숫자(잔고)를 서로 지우고 쓰려다 주먹다짐 나는 짓'**입니다. 한 명씩 써야 하니 느려 터집니다. 이벤트 소싱(Append)은 **'10명의 학생이 그냥 자기가 한 행동(쪽지)을 커다란 항아리 구멍(큐)에 미친 듯이 집어던지는 짓'**입니다. 아무도 기다리지 않습니다. 지우지도 않습니다. 그냥 던지고 튀면, 밤에 선생님(뷰 리졸버)이 쏟아진 쪽지 100장을 쫙 펼쳐서 계산기로 합계(현재 상태)를 두드려주는 압도적 속도와 충돌 회피술입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — '스냅샷(Snapshot)' 부재로 인한 10년 치 Replay 서버 부팅 무한 대기: 3년 동안 굴러간 핀테크 앱의 이벤트 소싱 DB에 계좌 입출금 이벤트가 1억 줄 쌓였다. 서버를 재부팅(K8s Pod 롤링 배포)했다. 새 서버 메모리에 유저의 '현재 잔고(State)'를 올려야 해서 DB에서 이벤트를 긁어와 재생(Replay)하기 시작했다. 1억 줄을 For 루프 돌리면서 덧셈 뺄셈 치느라 1대 서버 켜지는데 부팅 타임이 30분이 걸렸다! 그동안 트래픽은 다 막히고 서비스가 뻗어버리는 극악의 부팅 딜레마(Event Hydration Hell)가 터졌다.

   • 아키텍트의 해결책: 주기적인 상태 스냅샷(Snapshotting) 강제 융합이다. 매번 태초마을(1번 이벤트)부터 덧셈할 순 없다. 아키텍트는 1,000번째 이벤트가 쌓일 때마다 당시의 덧셈 결과물인 [1,000번 상태 스냅샷: 잔고 5만 원] 찰흙 덩어리를 찰칵! 찍어서 보조 테이블에 따로 저장해 둔다. 이제 서버가 재부팅되면? 태초부터 계산 안 한다. 가장 최근 스냅샷(1,000번)을 0.01초 만에 퍼 올린 뒤, 1,001번째부터 1,005번째까지의 짜투리 이벤트 딱 5개만 덧셈해서 0.1초 만에 부팅과 State 세팅을 끝내버리는 스마트 무결점 복구망을 짠다.

2. 시나리오 — 이벤트 스키마(Schema) 진화의 파국, 옛날 데이터 파싱 에러: 스타트업에서 작년에 짠 이벤트 로그는 {"userid": "A", "price": 100} 이었다. 올해 기획이 바뀌어 통화(Currency) 개념을 추가하며 {"userid": "A", "amount": {"krw": 100}} 로 구조(Schema)를 싹 갈아엎었다. 1년 뒤, 타임머신(Replay) 기능을 돌렸다! 그런데 작년에 쌓아둔 옛날 낡은 이벤트 텍스트를 파싱하다가 NullPointerException (amount 필드 없음)이 터지며 무결점 복구기능 전체가 박살 나버렸다. "아씨, 이미 써버린(Append) 과거의 로그 텍스트를 UPDATE 칠 수도 없고 어쩌냐?!" (Event Upcasting의 지옥).

   • 아키텍트의 해결책: 이벤트 업캐스팅(Event Upcasting) 파이프라인 방어다. 낡은 이벤트를 물리적으로 수정하는 건(UPDATE) 이벤트 소싱 헌법 위반(불법)이다. 아키텍트는 서버 코드 바닥에 Upcaster(변환기) 미들웨어를 깔아야 한다. DB에서 옛날 V1 이벤트를 퍼 올리는 찰나의 순간(On the fly), 메모리 위에서 V1 텍스트의 price를 V2의 amount.krw 껍데기로 0.001초 만에 씌워서(Migrate) 최신 비즈니스 로직으로 넘겨주는 릴레이 변환 렌즈를 세팅해 둬야 과거와 현재의 영원한 공존이 가능해진다.

도입 체크리스트

• 비즈니스적: "과거에 유저가 무엇을 했는지(이탈 경로, 행동 패턴) 궤적 자체가 비즈니스의 돈 줄(Data Goldmine)인가?" 토스나 토이 프로젝트 게시판에 이벤트 소싱 바르면 개발자 다 도망간다. 하지만 '증권사 거래소, 암호화폐(비트코인) 장부, 쿠팡의 장바구니 행동 트래킹' 같은 도메인은? 유저가 1초 전에 장바구니에 100만 원어치 넣었다가 뺀 이력 자체가 나중에 AI 추천 알고리즘을 먹여 타겟팅 쿠폰을 쏠 수 있는 수백억짜리 금광 데이터다. 즉, **"과거 상태가 덮어씌워져 날아가는 게 너무나 배가 아픈 초고부가가치 도메인"**에만 메스를 들이대야 한다.
• 기술적: 도메인 주도 설계(DDD)와 애그리거트(Aggregate) 단위 쪼개기가 완벽한가? 이벤트 소싱은 DDD 없이 쓰면 100% 폭망한다. 거대한 1통짜리 객체에 이벤트를 쏘면 덧셈하다가 램(RAM) 다 터진다. 반드시 Order Aggregate 하나에만 철저히 바운더리 락(Boundary)을 치고, 거기 관련된 OrderCreated, ItemAdded 이벤트만 쪼르륵 붙여서 계산하는 극강의 객체지향 캡슐화 훈련을 3달 이상 받은 조직에서만 이 무기를 자유자재로 다룰 수 있다.

안티패턴

• "과거 이벤트(Event Log)를 실수했다고 몰래 UPDATE 쳐서 지우거나 수정하기 (Rewrite History)": 주니어가 개발하다 버그 나서, DB 툴 열고 과거에 쏴버린 1년 전 이벤트 로우(Row)를 강제로 DELETE 치거나 UPDATE로 금액을 조작해 버리는 미친 짓. 블록체인 원장을 해킹하는 것과 같다. 중간 이빨이 하나 빠지는 순간 전체 이력을 덧셈한 해시(State) 정합성이 영구적으로 개박살 난다. "명심해라. 이벤트 스토어(Event Store)는 신의 영역이다. 절대 덧그리거나 지울 수 없다. 오직 내가 실수를 저질렀다는 부끄러운 마이너스 보상 이벤트(Compensation Event) 1줄을 맨 밑에 새로 고개 숙여 추가(Append)하는 것만이 유일한 사죄의 방법이다."

• 📢 섹션 요약 비유: 이벤트 소싱 장부에 손을 대는(UPDATE) 짓은, 은행 CCTV 녹화본에 도둑이 찍혔는데 **'CCTV 원본 테이프를 가위로 오려내고(DELETE) 그 위에 모자이크를 덮어쓰는 범죄 은폐 행위'**와 같습니다. 원본 테이프(Event)는 절대 1바이트도 수정되어선 안 됩니다. 도둑 맞은 게 팩트면 그냥 두세요. 그게 진실입니다. 대신 경찰을 불러 돈을 찾아다 금고에 다시 넣었다는 새로운 CCTV 영상을 맨 뒤에 추가 촬영(Append)하는 것이 진정한 클라우드 수사 기법입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• Event Store 전용 데이터베이스의 떡상 (EventStoreDB): 옛날엔 오라클이나 MySQL에 억지로 event_id, payload_json 컬럼 파놓고 이벤트 소싱을 흉내 냈다. 하지만 RDBMS는 무지막지한 로그 Append 덧셈 속도에 최적화된 엔진이 아니다. 이젠 아예 태생부터 "난 이벤트 덧셈(Replay)과 카프카 쏘는 것에 미친놈이야!" 라며 만들어진 전용 NoSQL 엔진인 EventStoreDB 나 **Apache Kafka(자체를 DB 원장으로 씀)**가 차세대 글로벌 원장 인프라로 떡상하고 있다.
• AI 딥러닝 타겟팅과의 극강의 시너지: 옛날엔 데이터 분석가들이 로그 분석하려면 백엔드 DB 몰래 퍼가서 데이터 레이크(Data Lake) 쑤셔 넣느라 1주일 걸렸다. 이벤트 소싱 시대엔 굳이 퍼갈 것도 없다. 본체(Source of Truth) 자체가 100% 행동 이력 로그다. 머신러닝 AI가 이 카프카 이벤트 스트리밍 원장에 빨대를 탁 꽂는 순간, 고객이 3분 전에 빨간 구두를 장바구니에 1초 담았다 뺀 그 아쉬움의 찰나까지 AI가 실시간 낚아채서 0.5초 만에 "빨간 구두 10% 쿠폰"을 화면에 쏴버리는 초연결 개인화 로직이 0초 딜레이로 완성되는 메가-아키텍처의 혁명이 도래했다.

참고 표준

• Martin Fowler의 Event Sourcing: 이벤트 소싱을 소프트웨어 아키텍처의 주류 학문으로 끌어올린 전설의 문서. "상태(State)를 저장하지 마라. 상태를 바꾸는 궤적(Event)을 저장해라. 그러면 과거로 무한 회귀하는 신의 능력을 얻으리라."
• Event-Driven Architecture (EDA): 이벤트 소싱이 빛을 발하는 모태. 이벤트 소싱으로 내 DB에 이벤트를 적는 순간(Write), 동시에 그 이벤트가 Kafka를 타고 사방 50개 서버로 날아가 춤추며(Choreography) 세상을 바꾸는 EDA의 심장.

이벤트 소싱 (Event Sourcing)은 소프트웨어 공학이 '결과 지상주의(현재 상태 덮어쓰기)'의 무식함을 버리고, '과정의 미학(모든 변화 궤적의 존중)'을 아키텍처의 근본으로 숭배하게 된 가장 경이로운 철학적 진화다. 우리는 무수한 세월 동안 효율성이라는 핑계로 UPDATE 쿼리를 남발하며 소중한 과거의 시간(데이터)을 잔혹하게 덮어쓰고 살해해 왔다. 그 결과, 장애가 터졌을 때 왜 데이터가 꼬였는지 추론할 증거(History)가 없어 뜬눈으로 밤을 새우는 형벌을 받았다. 이벤트 소싱은 데이터 살인을 멈추라는 절대 명령이다. 유저의 마우스 클릭 한 번, 결제 실패 한 번조차 모두 삭제할 수 없는 거룩한 텍스트(Append-only Event)로 돌판에 새겨라. 1억 줄의 쓰레기 로그가 쌓여 하드디스크를 삼킬지라도 쫄지 마라. 클라우드 시대의 스토리지(S3)는 휴지 조각만큼 싸다. 그 1억 줄의 로그 더미는 시스템이 불타 박살 나는 최악의 셧다운 속에서, "Replay" 단 한 줄의 명령어로 당신의 비즈니스를 단 1%의 유실도 없이 완벽한 부활로 이끌어내는 불멸의 타임머신이자, 진실을 수호하는 단 하나의 성경(Source of Truth)으로 영원히 빛날 것이다.

• 📢 섹션 요약 비유: 기존 방식은 통장에 **'연필로 100만 원 적어놓고, 5만 원 쓰면 지우개로 지우고 95만 원 덮어쓰는 구멍가게 장부'**입니다. 지우개로 빡빡 지운 흔적을 도둑이 조작해 10억으로 써놔도 아무도 모릅니다. 이벤트 소싱은 **'절대 안 지워지는 타자기로 매번 밑줄에 새롭게 추가(+100, -5, -3)하는 블록체인급 무결점 회계 장부'**입니다. 누가 끝에 10억을 몰래 적어놔도, 위에서부터 다시 계산기 덧셈(Replay)을 쳐보면 1초 만에 "야 이거 위조장부네!" 뽀록이 나는 절대 조작 불가능의 방어술입니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 일기장에 글을 쓸 때, "어제 사과 먹음"을 쓰고 다음 날 그 줄을 지우개로 싹싹 지워버리고(UPDATE) "오늘 포도 먹음"이라고 덮어쓰는 게 옛날 컴퓨터 방식이었어요. (과거가 다 날아가요!)
2. 그래서 똑똑한 컴퓨터는 절대 지우개를 버리고, 만년필을 써서 "1일: 사과 먹음 ➡ 2일: 포도 먹음" 이라고 매일매일 밑줄에 새로 추가만(Append) 하는 방식을 발명했어요!
3. 나중에 누가 "너 3일 전에 뭐 했어?" 물어보면, 처음부터 쭈욱~ 글씨를 읽어 내려가며(재생/Replay) 단 1초의 거짓말도 없이 옛날로 돌아갈 수 있는 무적의 일기장 쓰기 방법을 **'이벤트 소싱'**이라고 부른답니다!