이직에 바로 쓰는 프론트엔드 AI 실무: 레거시 마이그레이션 리허설 플레이북

최근 Velog 트렌딩을 보면 두 가지 흐름이 강합니다.

• Claude Code/Artifacts 같은 AI 개발 도구 사용기
• 이직 준비 맥락의 면접 대비 실전 사례

문제는 여기서 자주 멈춘다는 점입니다.

“AI로 빨리 바꿨다”까진 많은데, “운영 리스크를 어떻게 통제했는지”는 부족합니다.

이직 시장에서 프론트엔드 채용은 여전히 보수적입니다. 특히 레거시 마이그레이션 경험을 묻는 면접에서는 속도보다 아래를 봅니다.

1. 회귀를 어떻게 막았는가
2. 점진적 전환 전략이 있었는가
3. 팀이 따라 할 수 있는 문서가 남았는가

이번 글은 이 질문에 답하기 위한 마이그레이션 리허설 플레이북입니다. 기존 AI 코드리뷰 실무 적용 플레이북, AI 산출물 검증 스코어카드 운영법, Playwright 기반 E2E Eval 운영 가이드와 함께 보면 바로 적용 가능합니다.

왜 “리허설”이 핵심인가

실무 마이그레이션이 실패하는 가장 흔한 패턴은 한 번에 갈아엎는 방식입니다.

• 코드량은 줄었는데 장애가 늘어남
• 테스트는 통과했는데 사용자 행동 지표가 악화됨
• 롤백 시나리오가 없어 배포 결정을 미룸

AI는 초안을 빠르게 만듭니다. 하지만 배포 가능성은 사람이 운영 설계로 만들어야 합니다.

그래서 본 작업을 “마이그레이션”이 아니라 “마이그레이션 리허설”로 정의합니다.

• 실제 배포 전, 동일 조건에서 가짜 배포를 반복
• 실패 패턴을 먼저 수집
• 배포/보류 기준을 숫자로 고정

이 구조를 쓰면 면접에서도 “시도했다”가 아니라 “통제했다”로 설명할 수 있습니다.

4단계 마이그레이션 리허설 프레임

1) 범위 고정: 기능 단위로 자르기

“페이지 전체 전환” 같은 목표는 금지합니다. 아래처럼 쪼개야 리허설이 돌아갑니다.

• 검색 필터 영역
• 카드 렌더러 1종
• API 응답 파서

범위 정의 템플릿:

- 사용자 영향: 검색 결과 정확도/속도
- 기술 범위: state 관리 + 렌더 분기
- 제외 범위: 디자인 변경, API 스키마 변경

2) AI 초안 생성: 제약을 먼저 주기

프롬프트에서 “잘 만들어줘”보다 중요한 건 금지 조건입니다.

• 기존 URL 쿼리 포맷 유지
• 접근성 속성(aria-*) 제거 금지
• 에러 로깅 경로 변경 금지

이렇게 주면 AI 산출물의 품질 편차를 크게 줄일 수 있습니다.

3) 리허설 검증: 성공/실패를 수치화

리허설에서 최소한 아래 3가지는 고정하세요.

• 기능 회귀: 핵심 E2E 시나리오 통과율
• 사용자 체감: LCP/INP/CLS 전후 비교
• 운영 안정성: 에러율/경고 로그 변화

이때 검증 기준은 문장보다 표가 좋습니다.

4) 최종 결정: 배포/보류/부분 배포

결정은 감이 아니라 규칙으로 내립니다.

• 배포: 핵심 기능 회귀 0건 + 지표 악화 없음
• 부분 배포: 기능 통과, 성능 경계값 근접
• 보류: 회귀 1건 이상 또는 모니터링 이상치

결정 근거를 남겨야 다음 면접에서 재현 가능합니다.

실무 예시: CSR 페이지를 RSC 혼합 구조로 전환할 때

상황

• 기존: 클라이언트 컴포넌트 중심 페이지
• 목표: 데이터 로딩을 서버 컴포넌트로 일부 이동
• 제약: 검색 필터 UX와 공유 URL 유지

AI 초안의 장점

• 데이터 페칭 경로 단순화
• 번들 크기 감소 가능성 제시
• 중복 로딩 로직 제거

AI 초안의 위험

• 클라이언트 상호작용 지점 분리 실패 가능
• hydration mismatch 리스크
• error boundary 범위 누락

리허설에서 한 결정

• 데이터 읽기는 RSC로 이동
• 필터 상호작용은 클라이언트 유지
• URL 동기화 계층은 기존 훅 재사용

결과적으로 “전면 전환” 대신 “하이브리드 전환”을 선택했고, 회귀 없이 단계적 배포가 가능했습니다.

이직 포트폴리오에 그대로 붙이는 산출물 세트

면접관은 코드보다 판단 근거를 빨리 확인하고 싶어 합니다. 아래 3개면 충분합니다.

1) 전/후 아키텍처 다이어그램 1장

• Before: 병목 지점 표시
• After: 책임 분리 표시
• 유지한 제약 명시

2) 리허설 결과표 1장

• 테스트/성능/로그 지표
• 배포 기준 충족 여부

3) 결정 로그 1페이지

• 채택한 AI 제안
• 반려한 AI 제안
• 반려 사유(운영/보안/성능)

이 구조는 AI 면접 증빙 로그북 운영법과 묶었을 때 특히 강합니다.

면접 답변 템플릿 (30초 버전)

“레거시 전환에서 AI로 초안을 만들었지만, 리허설 단계를 두고 회귀 기준을 먼저 고정했습니다. 핵심 E2E와 성능 지표를 통과한 범위만 부분 배포했고, 보류 사유까지 문서화해서 다음 반복의 리스크를 줄였습니다.”

이 답변의 포인트는 기술 스택이 아니라 운영 가능한 개발자라는 신호입니다.

바로 실행할 수 있는 주간 루틴

• 월요일: 범위 1개 정의 + AI 초안 생성
• 수요일: 리허설 1회 + 실패 패턴 기록
• 금요일: 배포/보류 결정 + 포트폴리오 반영

3주만 반복하면, 이직용 스토리가 “기능 나열”에서 “의사결정 품질”로 바뀝니다.

마무리

AI 시대 프론트엔드 이직에서 차이를 만드는 건, 누가 더 화려한 도구를 썼는지가 아닙니다.

• 리스크를 먼저 정의했는가
• 실패를 리허설에서 소진했는가
• 그 과정을 팀이 재사용할 수 있게 남겼는가

마이그레이션 리허설은 느려 보이지만, 실제로는 가장 빠른 안전 경로입니다. 그리고 이게 바로 면접에서 신뢰를 얻는 방식입니다.