콘텐츠로 이동

시즌 2 시나리오 브리핑

"오늘부터 여러분은 다시 한밭푸드 인프라팀입니다. 1년 사이 회사도, 시스템도, 여러분도 바뀌었습니다. 이번엔 진짜 운영을 배울 차례입니다."

읽는 시간 10분


1년 뒤의 한밭푸드

항목 시즌 1 (1년 전) 시즌 2 (지금)
직원 수 120명 150명 (15% 증가)
연매출 약 200억 원 약 260억 원
IT 직원 개발 5 / 인프라 3 개발 8 / 인프라 4
주문 시스템 Docker Compose on VM Azure Container Apps (이관 완료)
결제 시스템 PHP 모놀리식 Python FastAPI로 분리 중 (최근 완료)

인프라팀 구성 (업데이트)

이름 직책 변동 특기
김팀장 인프라팀장 유임 온프레미스 전문, 이번엔 K8s 학습 중
이대리 시스템 엔지니어 승진 ACA 운영 경험 1년 누적
박대리 시스템 엔지니어 신입 → 박대리 승진 시즌 1 이관의 주역
최인턴 신입 신규 입사 CS 전공, Docker 기초만 아는 상태

실습에서 여러분의 역할

여러분은 이제 박대리입니다. 시즌 1의 박주임에서 한 단계 성장했고, 이번엔 최인턴에게 설명할 수 있을 정도로 개념까지 이해해야 합니다.


지난 목요일의 사건

시간순 요약

시각 사건
13:58 결제 API에서 외부 PG사 응답 지연 시작 (평균 500ms → 8초)
14:02 주문 조회 API가 결제 API를 호출하는 로직에서 타임아웃 급증
14:05 주문 조회 API 워커가 모두 점유되어 신규 요청 처리 불가
14:07 고객 문의 폭주. CS팀 전화 먹통
14:18 PG사 복구, 결제 API 정상화
14:25 주문 조회 API는 여전히 느림 (스레드 풀 포화 상태)
14:42 서비스 전체 정상화 — 총 장애 시간 44분

CTO의 진단

"결제 API가 느려지는 건 어쩔 수 없습니다. 외부 PG사 문제니까. 그런데 왜 주문 조회까지 같이 죽었을까요? 이게 설계 문제라는 걸 이번에 배웠으면 합니다."


이번 분기 3대 숙제

숙제 1 — 장애 전파 차단

질문 답해야 할 내용
무엇을 바꾸나? 주문 조회 API가 결제 API를 호출하는 로직
어떻게 바꾸나? Timeout + Retry + Circuit Breaker
성공 기준 결제 API 장애 시 주문 조회는 부분 기능으로 계속 동작

숙제 2 — 사람 손이 덜 가는 배포

질문 답해야 할 내용
현재 문제 이대리가 매번 az containerapp update를 수동으로 실행 중
목표 git push 한 번으로 빌드 → 테스트 → 배포까지 자동
도구 GitHub Actions (CI) + ArgoCD (CD)
플랫폼 AKS (이번 분기 CTO 지시사항)

왜 이번엔 AKS를 쓰나?

CTO가 "GitOps를 제대로 해보자"라고 결정했습니다. ArgoCD는 Kubernetes 네이티브 도구라 ACA에는 붙지 않습니다. 이번 분기에는 AKS 미니 클러스터를 새로 만들어 GitOps를 체험하고, Phase 7에서 "앞으로 ACA를 계속 쓸지, AKS로 전환할지" 의사결정합니다.

숙제 3 — AI Agent 운영 검토

질문 답해야 할 내용
본사 요구 "LLM이 아니라 Agent가 뭔지, 운영에 쓸 수 있는지 검토"
플랫폼 Azure OpenAI
결과물 간단한 장애 분석 Agent + Multi-Agent 설계 제안서

이번엔 답이 정해져있지 않습니다

시즌 1은 "ACA로 이관한다"라는 확실한 결론이 있었습니다. 시즌 2, 특히 숙제 3은 "해볼지 말지를 여러분이 제안"해야 합니다. Phase 7 제안서에 여러분의 판단을 담으세요.


예상 난이도

Phase 난이도 왜?
1–2 (장애 대응) ⭐⭐ 개념은 쉽지만 "Retry가 왜 나쁠 수 있는지"까지 체감해야 함
3–4 (CI/CD) ⭐⭐⭐ YAML, GitHub Actions, ArgoCD 세 가지 학습 곡선
5–6 (Agentic AI) ⭐⭐⭐ 새로운 개념(ReAct, Tool calling), 정답이 없는 설계
7 (회고) ⭐⭐ 기술보다 "왜"를 정리하는 능력

다음 단계

시작하기 AS-IS vs TO-BE 아키텍처