이직에 바로 쓰는 프론트엔드 AI 실무: 스펙 드리프트 방지 가드레일 플레이북
최근 Velog 트렌딩 신호를 보면 AI 주제에서도 반응이 큰 글은 공통점이 있습니다.
- “어떤 모델이 좋다”보다 어떻게 실패를 줄였는지
- “생산성이 올랐다”보다 품질/요구사항 이탈을 어떻게 통제했는지
- “툴 소개”보다 팀에서 재현 가능한 운영 방식
프론트엔드 실무에서 AI를 쓰면 가장 자주 터지는 문제가 스펙 드리프트(spec drift) 입니다.
스펙 드리프트 = 기능은 돌아가는데, 요구사항의 핵심에서 살짝씩 벗어나는 현상
이번 글은 이직 준비 관점에서, 면접에서도 설명 가능한 형태로 스펙 드리프트를 줄이는 가드레일을 정리합니다.
왜 스펙 드리프트가 이직 면접에서 치명적인가
면접에서 “AI로 작업했다”고 말하면 거의 항상 아래 질문이 따라옵니다.
- AI가 만든 코드가 요구사항을 정확히 충족하는지 어떻게 검증했나요?
- 빠르게 만든 대신 놓친 조건은 없었나요?
- 팀 단위로 같은 품질을 재현할 수 있나요?
이때 “감으로 리뷰했다”는 답변은 약합니다. 대신 가드레일 기반 운영을 보여주면 강해집니다.
- 요구사항 이탈을 조기에 탐지
- PR 단계에서 수정 비용 최소화
- 실패 패턴을 다음 작업에 재사용
AI 코드 품질 기준 자체를 먼저 정리하고 싶다면 AI 코드리뷰 실무 적용 플레이북, PR 품질 체계를 먼저 만들고 싶다면 Harness 기반 PR 품질 운영 가이드를 함께 보세요.
실무에서 쓰는 스펙 드리프트 4가지 패턴
1) 상태 누락형
정상 플로우는 구현됐는데 빈 상태/에러 상태/권한 거부 상태가 빠집니다.
- 증상: 데모에서는 잘 되지만 운영에서 예외 처리 부족
- 원인: 프롬프트에 비정상 시나리오가 명시되지 않음
2) 경계 침범형
서버에서 처리해야 할 로직이 클라이언트로 밀리거나 반대로 넘어갑니다.
- 증상: 번들 증가, 렌더링 비용 상승
- 원인: App Router 경계 조건을 프롬프트에 못 박지 않음
서버/클라이언트 분리 기준은 Next.js Server vs Client Components 실무 가이드를 기준선으로 두면 안정적입니다.
3) UX 단축형
동작은 되지만 접근성, 로딩 피드백, 복구 동선이 약합니다.
- 증상: 키보드 사용성 저하, 에러 복구 어려움
- 원인: “동작 구현” 중심 프롬프트, UX 제약 누락
4) 측정 실종형
기능은 머지됐는데 성공/실패를 추적할 로그와 지표가 없습니다.
- 증상: 배포 후 문제를 재현하기 어려움
- 원인: 관측 가능성 항목이 PR 정의에 없음
관측 지표를 붙이는 방법은 배포 후 관측 가능성 런북에서 더 자세히 다뤘습니다.
스펙 드리프트 방지 가드레일 (바로 적용 가능)
아래 5개를 PR 템플릿에 고정하면 체감 효과가 큽니다.
가드레일 1) Spec Contract를 PR 본문 첫 줄에 고정
PR 상단에 요구사항 계약을 짧게 박습니다.
## Spec Contract
- 필수 시나리오: 로그인 사용자, 비로그인 사용자
- 예외 시나리오: API 4xx/5xx, 네트워크 타임아웃
- 제외 범위: 관리자 화면 확장핵심은 “무엇을 했는지”가 아니라 무엇을 반드시 지켰는지를 먼저 선언하는 것입니다.
가드레일 2) AI 프롬프트에 금지사항(Do Not) 포함
AI에게 구현만 지시하면 경계가 흔들립니다. 금지 조건을 같이 명시하세요.
Do Not:
- 서버 컴포넌트를 클라이언트로 강제 전환하지 말 것
- 기존 API 스키마를 임의 변경하지 말 것
- 접근성 속성(role/aria-label) 삭제하지 말 것가드레일 3) Diff Review를 “변경”이 아니라 “이탈” 기준으로
코드 리뷰 질문을 바꿔야 합니다.
- 이 변경이 요구사항 계약에서 벗어난 부분은 없는가?
- 테스트가 기능 성공이 아니라 요구사항 충족을 증명하는가?
- 문서/로그가 다음 작업자에게 재현 가능한가?
가드레일 4) 릴리즈 직전 10분 체크
머지 직전에 아래만 확인해도 이탈률이 크게 줄어듭니다.
- 예외 상태 UI 존재 여부
- 에러 추적 키(예: feature, flow, action) 포함 여부
- 성능 회귀(번들/LCP/INP) 최소 확인
릴리즈 전 체크 프레임은 릴리즈 준비도 체크리스트와 같이 쓰면 좋습니다.
가드레일 5) 실패 로그를 포트폴리오 자산으로 전환
실패한 사례를 감추지 말고 구조화하세요.
- 문제: 어떤 요구사항이 왜 이탈됐는지
- 대응: 어떤 가드레일을 추가했는지
- 결과: 재발률이 어떻게 줄었는지
면접에서는 성공담보다 실패 통제 경험이 더 강한 신뢰를 만듭니다.
실전 예시: 검색 필터 패널 개선
상황: “카테고리 + 가격대 필터” 기능을 AI로 구현.
1차 결과 (빠르지만 위험)
- 기능 동작: ✅
- 빈 결과 처리: ❌
- 키보드 탐색: ⚠️
- API 실패 복구: ❌
- 로그 태깅: ❌
판정: 스펙 드리프트 발생
2차 개선 (가드레일 적용)
- Spec Contract를 PR 본문에 선언
- 프롬프트 Do Not 조건 추가
- 실패 케이스 테스트 3개 추가
- 에러 이벤트에
feature=product-filter태깅
판정: 머지 가능 + 면접 설명 가능
면접에서 이렇게 답하면 강하다
질문: “AI로 개발하면 품질이 흔들리지 않나요?”
답변 구조:
- 문제 정의: 속도는 올랐지만 스펙 드리프트가 반복됐다
- 가드레일 도입: Spec Contract + Do Not + 이탈 중심 리뷰
- 측정 지표: 재오픈 PR 비율, 예외 처리 누락 건수, 릴리즈 후 hotfix 수
- 결과: 품질을 유지하면서 리드타임 단축
이 구조는 AI 포트폴리오 임팩트 메트릭 플레이북과 함께 쓰면 더 설득력 있습니다.
7일 적용 플랜
Day 1~2
- 최근 PR 3개를 스펙 드리프트 관점으로 재평가
- 공통 실패 패턴 2개 추출
Day 3~5
- PR 템플릿에 Spec Contract/Do Not 섹션 추가
- 신규 기능 1개에 강제 적용
Day 6~7
- 전/후 지표 비교(재오픈, hotfix, 리뷰 코멘트)
- 면접 답변 스크립트로 정리
마무리
AI 시대 프론트엔드 이직 경쟁력은 “얼마나 빨리 만들었는가”가 아닙니다.
- 요구사항 이탈을 줄이는 운영 능력
- 실패를 팀 자산으로 전환하는 문서화 습관
- 결과를 지표로 설명하는 실무 커뮤니케이션
오늘부터는 기능 개수보다 스펙 드리프트를 줄인 기록을 쌓아보세요. 포트폴리오와 면접에서 바로 힘이 됩니다.