카카오 면접관이 알려주는 MSA 관점에서의 분산 트랜잭션 패턴
개발 · 프로그래밍 · 백엔드
서비스는 나눴는데
트랜잭션은 못 나눴습니다
서비스마다 데이터베이스를 따로 두는 순간, 하나의 커밋으로 묶을 수 있는 범위가 끝납니다. 결제는 됐는데 재고가 안 줄었을 때 무엇으로 되돌릴 것인가. 이 강의는 그 질문에 SAGA 패턴으로 답합니다.
- 난이도 입문
- 실습 포함
- Spring Boot · Kafka
- 섹션별 퀴즈
- 수강기한 무제한
- 개념부터 구현까지분산 트랜잭션의 한계 · SAGA · TCC · 3PC
- 전자 결제 예제Docker Compose로 띄우고 세 애플리케이션을 직접 만듭니다
- 현직 개발자 2인카카오 본사 12년차 면접관 · 판교 플랫폼 서버 개발
SAGA는 하나의 큰 트랜잭션을 여러 개의 로컬 트랜잭션으로 쪼개고, 실패하면 보상 트랜잭션으로 되돌리는 패턴입니다
이 강의가 출발하는 자리
롤백해 줄 사람이 사라집니다
한 덩어리일 때
커밋 하나로 끝
실패하면 데이터베이스가 알아서 되돌립니다. 개발자가 손댈 일이 없습니다.
per Service
서비스를 나눈 뒤
되돌릴 주체가 없다
세 번째 서비스에서 실패해도 앞의 둘은 이미 각자 커밋돼 있습니다.
분산 환경에서는 롤백이 저절로 오지 않습니다. 되돌리는 일을 우리가 코드로 만들어야 하고, 그 방법이 보상 트랜잭션입니다.
이 강의가 시작된 자리
실제로 오간 대화입니다
면접관으로 활동하는 카카오 개발자가 먼저 이 주제를 꺼냈습니다.
카카오 면접관이 먼저 주제를 꺼냈습니다.
SAGA가 하는 일
쪼개고, 실패하면 거꾸로 되돌립니다
하나의 주문을 처리하려면 여러 서비스를 거칩니다. 각 서비스는 자기 데이터베이스에 로컬 트랜잭션을 커밋합니다. 중간에서 실패하면 앞에서 성공한 것들을 하나씩 취소하는 작업을 반대 방향으로 실행합니다.
되돌리는 방법이 하나가 아닙니다. 데이터베이스가 해 주는 Rollback과 우리가 만드는 Compensation은 다른 일이고, 섹션 4에서 그 차이부터 짚습니다.
무엇을 배우나
한계 · 패턴 · 비교 · 구현 순서로
- 왜 문제가 되는가MSA 관점에서 ACID가 왜 서비스 경계를 못 넘는지부터
- SAGA 핵심 개념로컬 트랜잭션과 보상 트랜잭션. 현대적 SAGA와 전통적 ACID의 비교
- Choreography중앙 조정자 없이 서비스가 이벤트를 보고 스스로 움직이는 방식
- Orchestration가운데서 순서를 지시하는 방식. 둘의 장단점을 상세 비교합니다
- Rollback vs Compensation되돌림이라는 말이 가리키는 두 가지
- TCC와 3PCSAGA 말고 다른 선택지. TCC는 MySQL 설계까지 함께 봅니다
- 전자 결제 실습Docker Compose로 환경을 만들고 세 애플리케이션을 직접 구현합니다
두 가지 구현체
공화제냐 군주제냐
SAGA를 구현하는 방식은 크게 둘입니다. 면접에서 가장 자주 갈리는 지점이기도 합니다.
- 중앙 조정자가 없습니다. 각 서비스가 이벤트를 보고 스스로 다음 일을 합니다
- 서비스끼리 느슨하게 붙습니다
- 흐름이 코드 한 곳에 없어 전체를 파악하기 어렵습니다
- 서비스가 늘어날수록 이벤트가 얽힙니다
- 가운데 오케스트레이터가 순서를 지시합니다
- 흐름이 한 곳에 모여 있어 읽기 쉽습니다
- 실패했을 때 보상 순서도 한 곳에서 관리됩니다
- 대신 그 가운데가 단일 장애 지점이 될 수 있습니다
둘 중 하나만 배우지 않습니다. 섹션 3에서 각각의 성공·실패 흐름과 장단점을 비교하고, 마지막 섹션에서 같은 예제를 두 방식으로 만들어 봅니다.
실습 환경
무엇으로 만드나
전자 결제 예제를 세 개의 애플리케이션으로 나눠 만듭니다. 환경은 Docker Compose로 한 번에 띄웁니다.
- Spring Boot 3.2
- Java 17
- Docker Compose
- Kafka
- MySQL
- IntelliJ IDEA
스켈레톤 코드와 완성본이 모두 자료로 들어 있습니다. 처음부터 치기 부담스러우면 스켈레톤부터 시작하면 됩니다.
이론에서 끝나지 않습니다
마지막 섹션에서 세 애플리케이션을 직접 만들고 두 방식으로 돌려 봅니다.
커리큘럼 보기커리큘럼
무엇을 어떤 순서로 다루나
앞쪽에서 왜 문제가 되는지와 패턴을 잡고, 뒤쪽에서 환경을 만들어 직접 구현합니다.
01강의 소개
- 강의 소개
- 스켈레톤 실습 코드
- 완성본에 대한 실습 코드
- 강의 정리 파일
- 같이보면 좋은 자료
02분산 트랜잭션의 문제와 한계 & MSA 관점에서의 ACID의 한계 그에따른 분산 트랜잭션 패턴
- SAGA 패턴은 어떤 문제를 해결 할 수 있을까
- 대체 왜 분산 트랜잭션이 문제가 있을까
- 현대적 분산 트랜잭션에서 SAGA를 구현하는데에 있어 알아야하는 핵심 개념
- 현대적인 SAGA 패턴 vs 전통의 ACID
- SAGA 패턴의 장단점과 적합한 상황 시나리오
- 섹션 2 퀴즈
03SAGA의 대표적인 구현체 (Choreography vs Orchestration)
- SAGA 패턴의 첫번째 독립적인 Choreography 성공과 실패 그에따른 고려점
- SAGA 패턴 공화제 독립적인 Choreography의 장단점
- SAGA 패턴 군주제 중앙 집중식 Orchestration
- SAGA 패턴 군주제 중앙 집중식 Orchestration 장단점
- Choreography vs Orchestration 패턴 상세비교
- 섹션 3 퀴즈
04SAGA와는 다른 장단점을 가지고 있는 분산 트랜잭션 기법
- SAGA의 Rollback vs Compensation
- TCC (Try-Confirm-Cancel) 패턴과 그에따른 실제 MySQL 디자인 설계
- 3PC (Three-Phase Commit) 비교
- 섹션 4 퀴즈
05SAGA의 실습 준비 및 환경 구성하기
- 전자 결제 예시를 통한 실습할 아키텍처 및 구현체에 대한 전반적인 설명
- docker-compose를 활용한 경량화된 환경 구축 및 아키텍처
- MSA 관점에서의 Common 모듈의 필요성과 목적
- 섹션 5 퀴즈
06SAGA의 실습 진행하기 (Choreography vs Orchestration)
- 모든 요청의 출입구이자 탈출구 역할을 수행하는 첫번째 애플리케이션
- 중간 단계의 처리를 수행하는 두번째 애플리케이션
- 유실이 허용되는 마지막 애플리케이션 및 테스트
- 섹션 6 퀴즈
이런 분께
이 강의는 누구를 위한 강의인가요
- 비전공자 개발자이지만 대용량 트래픽 설계에 도전하고 싶은 분
- MSA와 SAGA는 들어봤지만 구체적인 설계 방법을 몰랐던 분
- 트래픽 확장성과 장애 복원력을 고민하는 백엔드 개발자
- 단순한 마이크로서비스를 넘어 복잡한 분산 트랜잭션을 설계하고 싶은 개발자
지금 시장
AI가 개발자를 대체한다는 이야기
신입 채용은 줄고, 기업은 검증된 사람만 뽑으려 합니다. 최근 몇 달 사이 나온 기사들입니다.
- 사상 최대 실적을 낸 크래프톤이 인력 감원에 나섰습니다. 'AI 퍼스트' 기업으로 전환하겠다는 이유였습니다.
- SW 전문기업들이 신입 개발자 채용을 중단하고 있습니다. 초급 개발자 채용이 77% 급감할 것이라는 전망도 나왔습니다.
- 게임 디자이너의 53%가 "AI가 내 일을 대체할 것"이라고 답했습니다. 권고사직 사례도 보고됐습니다.
기업이 불안한 만큼, 뽑히는 쪽은 더 분명한 차이를 보여줘야 합니다. 공부는 결국 스스로 하는 것이지만, 무엇을 어떤 관점으로 보느냐에 따라 같은 시간을 쓰고도 설명할 수 있는 깊이가 달라집니다. 이 강의는 그 관점을 넘기려고 만들었습니다.
수강평
먼저 들은 분들의 이야기
인프런 수강평에서 그대로 옮겼습니다.
"강의 너무 잘 봤습니다. 초기에 정말 수많은 다이어그램을 보여 주시면서 전반적인 아키텍처와 그에 따른 설명이 너무 마음에 들었고, 부족할 만한 지식과 정리할 만한 개념은 따로 강의 요약 파일을 통해 확인도 가능했습니다. 또한 복습하는 과정도 하나하나 다시 설명해 주시고, 현실적인 이야기와 실무적인 관점에서의 이야기도 너무 유익했다고 생각합니다."
개발에 미친자 · 92% 수강 후 작성
"개인적으로 인프런에서 가장 유익한 강의 중 하나가 아닐까 생각이 드네요. 그만큼 내용도 알차게 학습할 수 있었습니다. 감사합니다."
keny · 92% 수강 후 작성
"분산 트랜잭션에 대해 공부할 수 있는 좋은 시간이 되었습니다!"
파이리이2 · 100% 수강 후 작성
강사
현직 개발자 둘이 함께 만들었습니다
카카오 본사에서 서버를 개발하며 면접관으로도 활동하는 12년차 개발자 Choi와, 판교 플랫폼 서버 개발자 Hong이 함께 만들었습니다.
Choi
카카오 본사에서 서버를 개발하는 12년차 백엔드 개발자이고, 면접관으로도 활동하고 있습니다. 면접에서는 프로그래밍 문법보다 설계를 할 수 있는지를 주로 봅니다. 그 관점을 강의에 그대로 옮겼어요.
"면접에서 프로그래밍 문법은 거의 안 묻습니다. 설계를 할 수 있느냐를 봅니다."
現 카카오 본사 서버 개발자 · 면접관 · 컴퓨터공학 전공
Hong
판교에서 플랫폼 서버 개발을 담당하고 있습니다. 직접 공부한 방법과 실무에서 마주치는 문제·해결책을 나누려고 지식공유자 활동을 이어가고 있어요. 강의는 혼자가 아니라 현업의 여러 개발자와 함께 만듭니다.
"서비스를 나누는 건 쉬운데, 나눈 다음에 실패를 어떻게 다룰지가 어렵습니다."
자주 묻는 질문
분산 트랜잭션 강의 자주 묻는 질문
Q.MSA 경험이 없어도 들을 수 있나요?
⌄
Q.Choreography와 Orchestration 중 무엇을 배우나요?
⌄
Q.실습은 무엇을 만드나요?
⌄
Q.SAGA 말고 다른 패턴도 다루나요?
⌄
Q.면접 준비에 도움이 되나요?
⌄
되돌리는 일을 코드로 만듭니다
서비스를 나눈 뒤에 필요한 것은 더 큰 트랜잭션이 아니라 다른 설계입니다.
결정하기 전에 커리큘럼 다시 훑어보기함께 이야기 나눠요
개발자 오픈채팅 커뮤니티
혼자 막히면 오래 걸립니다. 강의를 듣다 걸리는 부분, 자기 서비스에 적용하면서 생기는 질문, 커리어와 현업 이야기까지 편하게 나누는 공간이 따로 있습니다.
무엇을 나누나요
실무에서 실제로 겪는 문제, 다른 분들이 어떤 구조를 골랐는지, 그리고 개발자 커리어에 대한 이야기를 나눕니다. 강의 관련 질문도 환영합니다.
"막히는 자리는 대체로 남들도 막힙니다. 먼저 지나간 사람에게 물어보는 게 제일 빠릅니다."