이직에 유리한 프론트엔드 AI 실무: 디버깅 런북(Observability + Agent) 구축하기
최근 Velog 트렌딩/최신 흐름을 보면, AI 코딩 도구 사용기에서 한 단계 올라가 MCP·에이전트·실무 자동화를 다루는 글이 꾸준히 주목받고 있습니다. 공통점은 단순 생성이 아니라, “문제를 얼마나 빨리 해결했는가”에 초점이 있다는 점입니다.
프론트엔드 채용에서도 비슷합니다.
“AI로 구현은 빨랐는데, 장애 났을 때 어떻게 잡았나요?”
이 질문에 답하려면 **디버깅 런북(runbook)**이 필요합니다. 이번 글에서는 재현 → 원인 축소 → 복구 → 회고를 AI 에이전트와 관측성 도구로 연결하는 실무 루프를 정리합니다.
왜 지금은 “생성 속도”보다 “복구 속도”가 점수가 높은가
AI가 만든 코드로 기능 구현 속도는 상향 평준화되었습니다. 그래서 면접관은 다음을 더 보고 싶어 합니다.
- 장애를 재현 가능한 형태로 남길 수 있는가
- 원인을 시스템적으로 좁힐 수 있는가
- 같은 장애를 다시 막는 프로세스를 만들 수 있는가
즉, 이직 시장에서 강한 신호는 “많이 만들었다”가 아니라 운영 가능한 품질을 만들었다입니다.
관련 맥락은 AI 코드리뷰 실무 적용 플레이북, Playwright 기반 E2E Eval 운영 가이드와 함께 보면 전체 그림이 더 선명해집니다.
프론트엔드 AI 디버깅 런북: 4단계 표준 루프
1) 재현: “에러 메시지”가 아니라 “사용자 흐름”으로 캡처
재현이 흔들리면 나머지 단계가 전부 느려집니다. 아래 3가지를 기본 세트로 수집하세요.
- 세션 리플레이 링크 (사용자 행동 순서)
- 환경 정보 (브라우저, OS, 배포 버전, 기능 플래그)
- 네트워크/콘솔 스냅샷
핵심은 “어디서 터졌는지”보다 어떤 흐름에서 터졌는지를 남기는 것입니다.
2) 원인 축소: AI 에이전트에는 “증거 묶음”만 준다
에이전트에게 막연히 “왜 깨졌어?”라고 묻기보다 아래처럼 입력을 고정해야 정확도가 올라갑니다.
- 스택트레이스
- 해당 커밋 범위(diff)
- 실패한 E2E 시나리오
- 관련 컴포넌트 의존 관계
AI는 가설 생성 속도는 빠르지만, 사실 검증은 사람이 해야 합니다. 따라서 AI의 결과물은 “정답”이 아니라 우선순위가 붙은 가설 리스트로 다루는 게 안전합니다.
3) 복구: 핫픽스보다 “롤백 가능한 작은 변경” 우선
장애 상황에서 큰 리팩터링은 위험합니다. 다음 원칙을 지키면 복구 속도가 빨라집니다.
- 단일 책임 PR로 쪼개기
- 기존 동작을 보존하는 가드 코드 먼저 추가
- 복구 후에 구조 개선 PR 분리
브랜치 전략은 GitHub Flow나 Trunk Based Development를 기준으로 팀 규칙을 명확히 두는 편이 좋습니다.
4) 회고: 장애를 “개인 실수”가 아니라 “시스템 개선 티켓”으로 전환
회고에서 반드시 남길 항목:
- 탐지까지 걸린 시간(MTTD)
- 복구까지 걸린 시간(MTTR)
- 재발 방지 액션(테스트/알림/가드레일)
이 데이터가 쌓이면 면접에서 “장애를 겪었다”가 아니라 장애 대응 체계를 운영했다고 설명할 수 있습니다.
바로 적용 가능한 실무 템플릿
## FE 장애 대응 카드
### Incident
- 증상:
- 최초 감지 시각:
- 영향 범위(사용자/매출/핵심 KPI):
### Evidence
- 세션 리플레이:
- Sentry 이슈:
- 실패 테스트/로그:
- 관련 커밋 범위:
### Hypotheses (AI + Human)
1. [ ] 가설 A / 검증 결과
2. [ ] 가설 B / 검증 결과
3. [ ] 가설 C / 검증 결과
### Mitigation
- [ ] 임시 완화(Feature Flag, Guard)
- [ ] 영구 수정 PR 링크
- [ ] 롤백 계획 확인
### Prevention
- [ ] E2E 회귀 케이스 추가
- [ ] 알림 룰 업데이트
- [ ] 문서/런북 업데이트채용 포트폴리오에 녹이는 방법
1) “문제-증거-조치-결과” 4칸 구조로 작성
- 문제: 실제 사용자 영향
- 증거: 로그/리플레이/테스트 실패
- 조치: 복구 PR + 검증 방법
- 결과: MTTD/MTTR 개선 수치
2) AI 사용 내역은 “결정 로그”로 남기기
면접에서 좋은 인상을 주는 포인트는 도구 이름이 아니라 의사결정입니다.
- 어떤 입력을 줬는지
- 어떤 가설을 채택/기각했는지
- 최종 판단을 왜 했는지
3) 기술 스택 연결고리 만들기
관측성/품질 체계를 단독으로 두지 말고 기존 글/프로젝트와 이어서 설명하세요.
“문제 재현-렌더링 특성-모니터링”이 연결되면 실무 깊이가 확실히 드러납니다.
2주 실행 플랜 (이직 준비 버전)
1주차: 장애 대응 최소 루프 구축
- Sentry/리플레이 기본 수집 세팅
- 핵심 사용자 플로우 2~3개 E2E 스모크 추가
- 장애 대응 카드 템플릿 저장소에 포함
2주차: 데이터 기반 개선
- 실제 이슈 1건 이상 회고 문서화
- MTTD/MTTR 베이스라인 측정
- 재발 방지 테스트와 알림 룰 적용
2주만 해도 “AI를 쓴 개발자”를 넘어 AI 시대의 운영형 프론트엔드 개발자라는 포지셔닝이 가능합니다.
마무리
앞으로 프론트엔드 이직 경쟁력은 더 분명해질 겁니다.
- 생성 속도: 대부분 비슷해짐
- 디버깅/복구 체계: 사람마다 큰 격차
오늘부터는 기능 데모만 쌓지 말고, 장애 대응 런북을 같이 쌓아 보세요.
면접에서 강한 개발자는 “무엇을 만들었는지”보다 “문제가 났을 때 어떻게 시스템적으로 복구했는지”를 증명하는 사람입니다.