이직에 바로 쓰는 프론트엔드 AI 실무: 온콜 드릴(장애 대응 리허설) 운영 플레이북
요즘 Velog 트렌딩을 보면 AI 코딩 경험담이 계속 올라옵니다. 실제로 생산성은 빠르게 올라갑니다.
문제는 면접에서 나오는 다음 질문입니다.
- “장애 상황에서 AI를 어떻게 썼나요?”
- “복구 우선순위는 누가, 어떤 근거로 정했나요?”
- “속도 말고 안정성 개선은 어떻게 증명하나요?”
즉, 단순한 생성 속도보다 운영 신뢰도가 핵심입니다.
이번 글에서는 프론트엔드 이직 준비를 위해 바로 적용 가능한 온콜 드릴(On-call Drill) 방식을 정리합니다. 기존의 AI 디버깅 실무 런북, 배포 이후 모니터링 실전 체크리스트, AI 산출물 검증 스코어카드 운영법과 함께 쓰면 포트폴리오 설득력이 크게 올라갑니다.
왜 온콜 드릴이 이직에 강한가
사이드 프로젝트 포트폴리오에서 가장 취약한 구간은 “문제가 터졌을 때”입니다.
기능 개발 스토리는 누구나 준비합니다. 하지만 면접관은 다음을 봅니다.
- 장애를 재현할 수 있는가
- 탐지부터 복구까지 시간을 줄였는가
- 같은 사고가 다시 나지 않게 했는가
온콜 드릴은 이 3가지를 한 번에 보여줍니다.
- 재현성: 시나리오 기반으로 장애를 의도적으로 재현
- 측정 가능성: MTTD(탐지 시간), MTTR(복구 시간) 기록
- 재발 방지: 경보/가드레일/체크리스트 업데이트
면접에서 “AI를 잘 쓴다”보다 “AI를 통제해서 복구 품질을 높인다”가 훨씬 강합니다.
7일 온콜 드릴 운영 플랜 (이직 준비용)
Day 1 — 장애 시나리오 선정
아래처럼 사용자 영향이 큰 프론트엔드 사고부터 고릅니다.
- API는 성공인데 UI가 빈 상태로 고정되는 케이스
- 캐시 오염으로 이전 사용자 데이터가 잠깐 노출되는 케이스
- feature flag 미스매치로 결제 버튼이 숨겨지는 케이스
시나리오를 고를 때는 “신기한 버그”보다 면접에서 설명 가능한 사고가 좋습니다.
Day 2 — 관측 포인트 정의
최소 4가지만 고정하세요.
- 사용자 징후: 어떤 화면에서 어떤 증상이 보이는지
- 로그 키: 에러 코드, userId hash, release version
- 경보 조건: 5분 내 에러율 임계치
- 성공 기준: 복구 후 핵심 경로 E2E 통과
Day 3 — AI 초안 생성
AI에게 아래 작업만 맡깁니다.
- 재현 스크립트 초안
- 로그 필드 보강 코드 초안
- 임시 완화책(rollback, feature flag off) 문서 초안
핵심은 “AI가 제안한 코드”가 아니라 누가 승인했는가를 남기는 것입니다.
Day 4 — 드릴 실행
실제로 사고를 터뜨리고 시간을 잽니다.
- 사고 시작 시각
- 첫 탐지 시각 (MTTD)
- 임시 완화 완료 시각
- 근본 원인 패치 완료 시각 (MTTR)
Day 5 — 회고 문서화
아래 3줄이 반드시 있어야 합니다.
- 무엇이 늦었는가
- 무엇이 오탐이었는가
- 무엇을 자동화할 것인가
Day 6 — 가드레일 반영
- PR 템플릿에 장애 체크 항목 추가
- 릴리즈 체크리스트에 rollback 조건 추가
- 테스트 파이프라인에 회귀 시나리오 추가
Day 7 — 포트폴리오 카드 작성
한 장으로 끝내세요.
- 사고 요약 (Before)
- 대응 흐름 (During)
- 지표 개선 (After)
- 다음 분기 개선 계획
실무 템플릿: AI 온콜 드릴 로그
## AI On-call Drill Log
### 1) 시나리오
- 사고 유형:
- 사용자 영향:
- 재현 방법:
### 2) 탐지
- 최초 징후:
- 감지 채널(Sentry/Datadog/로그):
- MTTD:
### 3) 대응
- AI 제안:
- 사람이 채택한 대응:
- 반려한 대응 + 이유:
### 4) 복구
- 임시 완화 시각:
- 근본 원인 패치 시각:
- MTTR:
### 5) 재발 방지
- 추가한 가드레일:
- 테스트/모니터링 변경:
- 다음 드릴 일정:이 템플릿은 AI PR 리뷰 가드레일, AI 코드리뷰 실무 적용 플레이북과 연결하면 더 강해집니다.
면접 답변 예시 (STAR 구조)
S (Situation)
“신규 배포 후 특정 브라우저에서 주문 요약 패널이 비어 보이는 장애가 발생했습니다.”
T (Task)
“사용자 이탈을 막기 위해 30분 내 임시 완화, 당일 내 근본 원인 제거가 목표였습니다.”
A (Action)
- AI로 로그 필드 확장안과 rollback 체크리스트 초안을 생성
- 사람 판단으로 위험한 대규모 리팩터링 제안은 반려
- feature flag fallback + SSR 분기 수정으로 점진 복구
R (Result)
- MTTD 18분 → 6분
- MTTR 95분 → 31분
- 같은 유형 장애 재발 0건(4주)
이 구조가 강한 이유는 “AI를 썼다”가 아니라 운영 성과를 숫자로 증명하기 때문입니다.
자주 실패하는 패턴 3가지
1) AI 제안을 바로 핫픽스에 반영
장애 상황일수록 작은 변경이 원칙입니다. 대규모 구조 수정은 복구 이후로 미루세요.
2) 로그 필드 없이 증상만 기록
“안 됐다”는 기록은 면접에서 가치가 없습니다. 버전/환경/사용자 영향 범위를 반드시 남겨야 합니다.
3) 복구 후 회고 생략
회고 없는 복구는 같은 사고를 반복합니다. 최소한 드릴 로그 1회분은 남겨야 포트폴리오 자산이 됩니다.
마무리
이직 준비에서 AI 활용 포트폴리오의 핵심은 기능 수가 아닙니다.
- 사고를 탐지하고
- 제한된 시간에 복구하고
- 같은 실수를 반복하지 않는 체계를 만들었는가
온콜 드릴은 그 역량을 가장 짧은 시간에 증명하는 방법입니다. 이번 주에 작은 시나리오 하나만 돌려도, 다음 면접에서 답변의 밀도가 달라집니다.