현실적인 조언: 3개월 교육 후 MSA 프로젝트
🎯 솔직한 현실 진단
┌─────────────────────────────────────────────────────────────────────┐
│ 현재 상황 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 📚 3개월 이론 교육 + AI 활용 가능 │
│ │
│ ✅ 가능한 것 │
│ • AI로 코드 생성 → 작업 속도 확보 │
│ • 인프라 셋업 → Terraform/CloudFormation 복붙 가능 │
│ • "돌아가게" 만드는 것 │
│ │
│ ⚠️ 위험한 것 │
│ • 면접에서 "이거 왜 이렇게 했어요?" → 대답 못함 │
│ • 장애 발생 시 → 어디가 문제인지 모름 │
│ • 블랙박스 프로젝트 → 오히려 마이너스 │
│ │
└─────────────────────────────────────────────────────────────────────┘
💡 전략 수정: “깊이 있는 작은 것” > “얕은 큰 것”
❌ 피해야 할 것
"저희 프로젝트는 Saga 패턴, CQRS, Event Sourcing,
Circuit Breaker를 모두 적용했습니다!"
면접관: "Saga에서 보상 트랜잭션 실패하면 어떻게 처리해요?"
나: "어... 그건..."
면접관: (이 사람 AI로 만들었구나...)
✅ 목표해야 할 것
"저희는 MSA의 핵심 문제인 '분산 트랜잭션'에 집중했습니다.
Saga 패턴을 직접 구현하면서 이런 고민들을 했는데요..."
면접관: "보상 트랜잭션 실패하면?"
나: "저희도 그 문제를 겪었는데요, Dead Letter Queue로
실패한 보상을 모으고, 수동 처리 대시보드를 만들었습니다.
실제로 테스트하면서 이런 엣지 케이스를 발견했거든요..."
면접관: (오 이 친구 직접 해봤네)
📋 현실적인 4주 프로젝트 스코프
핵심만 남기고 깊이 파기
┌─────────────────────────────────────────────────────────────────────┐
│ 현실적 스코프 (4인 / 4주) │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 🎯 핵심 서비스 3개만 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ [Order Service] ←→ [Payment Service] ←→ [Inventory] │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 🎯 패턴 2개만 제대로 │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Saga 패턴 │ │ Circuit Breaker │ │
│ │ (분산 트랜잭션) │ │ (장애 격리) │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ 🎯 관측성 2개만 │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ X-Ray 추적 │ │ CloudWatch │ │
│ │ (요청 흐름) │ │ (메트릭/알람) │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ ❌ 과감히 빼는 것 │
│ • CQRS (복잡도 ↑, 필수 아님) │
│ • Event Sourcing (학습 곡선 ↑) │
│ • Service Mesh (오버엔지니어링) │
│ • 글로벌/멀티리전 (스코프 초과) │
│ │
└─────────────────────────────────────────────────────────────────────┘
📚 “블랙박스 안 되려면” 공부 로드맵
Week 1-2: 기반 다지기 (프로젝트와 병행)
┌─────────────────────────────────────────────────────────────────────┐
│ MUST 이해해야 할 것 (AI 코드 쓰더라도) │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 📌 1. 왜 MSA인가? (모놀리식 vs MSA) │
│ ├── 장점: 독립 배포, 기술 다양성, 확장성 │
│ ├── 단점: 복잡도, 네트워크 이슈, 데이터 일관성 │
│ └── 💬 "우리 프로젝트에서 MSA가 필요한 이유"를 설명할 수 있어야 │
│ │
│ 📌 2. 동기 vs 비동기 통신 │
│ ├── REST API (동기) → 언제 쓰나? │
│ ├── 메시지 큐 (비동기) → 언제 쓰나? │
│ └── 💬 "왜 여기선 비동기로 했어요?" 답할 수 있어야 │
│ │
│ 📌 3. 분산 시스템의 함정 │
│ ├── 네트워크는 실패한다 │
│ ├── 순서 보장 안 된다 │
│ ├── 정확히 한 번 실행? 거의 불가능 │
│ └── 💬 "이 문제를 어떻게 해결했어요?" 답할 수 있어야 │
│ │
└─────────────────────────────────────────────────────────────────────┘
핵심 개념별 최소 공부량
# 1. Saga 패턴 - 이것만은 확실히!
"""
질문: Saga가 뭐예요?
답변: 분산 트랜잭션을 여러 로컬 트랜잭션으로 나누고,
실패 시 보상 트랜잭션으로 롤백하는 패턴
질문: Choreography vs Orchestration?
답변:
- Choreography: 각 서비스가 이벤트 듣고 알아서 반응
→ 단순하지만 흐름 파악 어려움
- Orchestration: 중앙 조율자가 순서 제어
→ 흐름 명확하지만 단일 장애점
우리는 Step Functions로 Orchestration 선택.
이유: 흐름이 명확하고, 실패 지점 추적 쉬움
질문: 보상 트랜잭션 실패하면?
답변: DLQ에 쌓이고, 알람 발생, 수동 처리 대시보드에서 확인
(이건 실제로 구현해서 보여줘야 함)
"""
# 2. Circuit Breaker - 왜 필요한지 체감해야 함
"""
질문: Circuit Breaker 왜 썼어요?
답변: Payment Service가 느려지면 Order Service도 같이 죽어요.
요청이 계속 쌓이면서 스레드 풀 고갈 → 전체 시스템 다운
Circuit Breaker로:
- 5번 실패하면 → 바로 에러 반환 (Fail Fast)
- Order Service는 살아있음
- 30초 후 다시 시도
질문: 상태가 뭐뭐 있어요?
답변: CLOSED(정상) → OPEN(차단) → HALF_OPEN(테스트)
질문: Hystrix 같은 라이브러리 왜 안 썼어요?
답변: (AWS라서 / 직접 구현해보고 싶어서 / 학습 목적)
→ 실제로 구현하면서 내부 동작 이해했습니다
"""🗓️ 현실적인 4주 일정
┌─────────────────────────────────────────────────────────────────────┐
│ Week 1: 기본기 + 단일 서비스 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 월-화: 환경 셋업 │
│ • ECS 클러스터 생성 (Terraform) │
│ • CI/CD 파이프라인 (GitHub Actions → ECR → ECS) │
│ • 🎓 공부: Docker, ECS 기본 개념 │
│ │
│ 수-목: Order Service 단독 개발 │
│ • CRUD API 구현 │
│ • Aurora 연결 │
│ • 🎓 공부: REST API 설계, DB 연결 │
│ │
│ 금: 배포 + 테스트 │
│ • 실제 배포해보기 │
│ • Postman으로 테스트 │
│ • 🎓 공부: 배포 과정 이해, 트러블슈팅 │
│ │
└─────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────┐
│ Week 2: 서비스 간 통신 + Saga │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 월-화: Payment, Inventory 서비스 추가 │
│ • 각각 독립 서비스로 개발 │
│ • 각자 DB 분리 │
│ • 🎓 공부: MSA에서 DB 분리 이유 │
│ │
│ 수-목: Step Functions로 Saga 구현 ⭐ │
│ • 주문 → 결제 → 재고 플로우 │
│ • 실패 시 보상 트랜잭션 │
│ • 🎓 공부: Saga 패턴 깊이 이해 (필수!) │
│ │
│ 금: 실패 케이스 테스트 │
│ • 일부러 실패시켜보기 │
│ • 보상 트랜잭션 동작 확인 │
│ • 🎓 공부: 엣지 케이스, 멱등성 │
│ │
└─────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────┐
│ Week 3: 장애 대응 + 모니터링 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 월-화: Circuit Breaker 구현 ⭐ │
│ • 직접 구현 or Resilience4j │
│ • Payment 서비스에 적용 │
│ • 🎓 공부: 왜 필요한지, 상태 전이 │
│ │
│ 수-목: X-Ray + CloudWatch │
│ • 분산 추적 설정 │
│ • 대시보드 구성 │
│ • 🎓 공부: 분산 추적 개념, 메트릭 의미 │
│ │
│ 금: 장애 주입 테스트 │
│ • 서비스 하나 죽여보기 │
│ • Circuit Breaker 동작 확인 │
│ • 🎓 공부: 장애 시나리오, 복구 과정 │
│ │
└─────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────┐
│ Week 4: 완성도 + 시연 준비 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 월-화: 버그 수정 + 안정화 │
│ • 엣지 케이스 처리 │
│ • 로깅 정리 │
│ │
│ 수-목: 시연 시나리오 준비 │
│ • 데모 스크립트 작성 │
│ • 리허설 │
│ │
│ 금: 문서화 + 면접 대비 │
│ • README 정리 │
│ • 예상 질문 답변 준비 │
│ • 🎓 공부: 전체 복습, 말로 설명하는 연습 │
│ │
└─────────────────────────────────────────────────────────────────────┘
🎯 면접에서 “진짜 해본 사람”처럼 보이는 법
1. 삽질 경험을 말하기
❌ "Saga 패턴으로 분산 트랜잭션 처리했습니다"
✅ "처음엔 그냥 API 호출로 했다가 결제는 됐는데
재고 차감이 실패하면 결제 취소가 안 되는 문제가 있었어요.
그래서 Saga 패턴을 찾아보게 됐고..."
2. 트레이드오프 설명하기
❌ "Step Functions 썼습니다"
✅ "Choreography와 Orchestration 중 고민했는데,
Choreography는 이벤트만 보고는 전체 흐름 파악이 어려워서
디버깅이 힘들 것 같았어요.
Step Functions는 비용이 좀 들지만
실행 흐름이 시각적으로 보여서 선택했습니다."
3. 실패 케이스 준비하기
면접관: "보상 트랜잭션도 실패하면요?"
✅ "저희도 테스트하다가 그 케이스 만났어요.
DLQ에 넣고 알람 발생시키는데,
실제 운영이라면 수동 처리 프로세스가 필요할 것 같아요.
이번 프로젝트에선 거기까진 못 했지만요."
(모르는 것도 인정하면서, 고민은 해봤다는 걸 보여주기)
📚 최소한의 공부 자료
꼭 읽어야 할 것 (각 1-2시간)
1. MSA 기본
• 마틴 파울러 - Microservices (원문 아티클)
• https://martinfowler.com/articles/microservices.html
2. Saga 패턴
• 마이크로서비스 패턴 (크리스 리처드슨) - Saga 챕터만
• 또는 유튜브 "Saga Pattern" 검색 (30분짜리)
3. Circuit Breaker
• 마틴 파울러 - Circuit Breaker
• https://martinfowler.com/bliki/CircuitBreaker.html
4. AWS 공식 문서
• Step Functions 개발자 가이드 (Saga 예제)
• X-Ray 개념
실습으로 체화할 것
# 이건 AI 없이 직접 쳐보기 (30분)
# Circuit Breaker 상태 전이 이해
class CircuitBreaker:
def __init__(self):
self.state = "CLOSED"
self.failure_count = 0
self.threshold = 5
def call(self, func):
if self.state == "OPEN":
raise Exception("Circuit is OPEN")
try:
result = func()
self.failure_count = 0
return result
except:
self.failure_count += 1
if self.failure_count >= self.threshold:
self.state = "OPEN"
raise
# 이 정도 코드는 면접에서 화이트보드에 쓸 수 있어야 함💪 결론
┌─────────────────────────────────────────────────────────────────────┐
│ 현실적인 목표 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ❌ 모든 MSA 패턴을 다 적용한 대단한 프로젝트 │
│ │
│ ✅ 핵심 패턴 2개를 직접 겪어보고 설명할 수 있는 프로젝트 │
│ │
│ "Saga 패턴 적용하면서 이런 문제가 있었고, │
│ 이렇게 해결했는데, 이런 한계가 있었습니다." │
│ │
│ → 이게 훨씬 좋은 인상 │
│ │
└─────────────────────────────────────────────────────────────────────┘
AI 활용 전략:
- 보일러플레이트, 인프라 코드 → AI로 빠르게
- 핵심 로직 (Saga, Circuit Breaker) → 직접 이해하면서
- 트러블슈팅 → 직접 겪어보기 (이게 진짜 실력)
화이팅입니다! 🚀 궁금한 거 있으면 더 물어보세요.