이직에 바로 먹히는 프론트엔드 AI 실무: Context Contract로 산출물 품질 고정하기
최근 Velog 트렌딩을 보면 AI 관련 글의 결이 꽤 명확합니다.
- “AI로 코드 3만 라인 작성”
- “출퇴근 시간에 에이전트로 기능 구현”
- “모델 경쟁보다 하네스 경쟁”
즉, 빠르게 만드는 경험은 이미 대중화됐습니다. 이제 이직 시장에서 차이를 만드는 질문은 다음입니다.
“AI가 만든 결과물을 팀 품질 기준에 맞게 반복 가능하게 운영해봤나요?”
이번 글은 이 질문에 답하기 위한 실무 장치, Context Contract(컨텍스트 계약서) 운영법을 정리합니다.
Context Contract가 왜 필요한가
AI 활용 프로젝트가 실패하는 패턴은 대부분 비슷합니다.
- 첫 주: 생산성 폭증
- 둘째 주: 코드 스타일 붕괴
- 셋째 주: 회귀 버그 + 리뷰 피로 누적
원인은 단순합니다. 모델이 똑똑하지 않아서가 아니라, 입력 기준이 불안정하기 때문입니다.
Context Contract는 “에이전트에게 매번 전달되는 고정 규칙”입니다. 핵심은 아래 3가지입니다.
- 기술적 경계: 어떤 스택/패턴을 허용할지
- 품질 기준: lint/build/test 통과 조건
- 산출물 형식: PR 설명, 체크리스트, 로그 포맷
이걸 문서화하면 AI가 생성한 코드가 사람마다 달라지는 문제를 줄일 수 있습니다.
관련 배경은 이직에 강한 프론트엔드 포트폴리오: AI PRD를 티켓으로 전환하는 실전 운영법, 이직에 바로 먹히는 프론트엔드 AI 실무: 코드리뷰 운영 플레이북을 먼저 보면 더 빠르게 연결됩니다.
실무 템플릿: 최소 Context Contract
아래 정도만 있어도 체감 품질이 크게 달라집니다.
# Context Contract v1
## Stack
- Next.js App Router + TypeScript
- 스타일: Tailwind 우선
- 상태관리: 서버 상태는 React Query, 전역 상태 최소화
## Rules
- any 금지, 타입 단언 최소화
- 비즈니스 로직은 UI 컴포넌트 밖으로 분리
- 접근성: 버튼/링크 role, label 누락 금지
## Done Criteria
- pnpm lint 통과
- pnpm build 통과
- 핵심 E2E smoke 3개 통과
## Output Format
- 변경 요약 5줄 이내
- 리스크/롤백 포인트 1개 이상
- 테스트 로그 링크 첨부포인트는 완벽함이 아니라 일관성입니다. 규칙이 50개인 문서보다, 10개 규칙을 모든 작업에 일관 적용하는 문서가 더 강합니다.
적용 순서: 2주만에 포트폴리오화하기
1주차: 계약서 고정 + 작은 기능 2개 적용
- Context Contract 초안 작성
- AI로 기능 2개 구현
- PR마다 “규칙 위반 항목” 체크
이 단계에서 중요한 건 속도가 아니라 위반 유형 수집입니다.
예시:
- 타입 누수 (암시적 any)
- 서버/클라이언트 경계 오용
- 접근성 속성 누락
2주차: 품질 게이트 자동화
- PR 템플릿에 Contract 체크리스트 추가
- lint/build/E2E smoke를 필수 게이트로 설정
- 실패 로그를 회고 문서에 누적
이렇게 하면 “AI를 썼다”가 아니라 AI 작업을 운영 통제했다는 이력으로 바뀝니다.
E2E 운영은 Playwright 기반 E2E Eval 운영 가이드, UI 회귀 통제는 시각 회귀 테스트 실전 플레이북과 같이 묶으면 완성도가 올라갑니다.
면접에서 먹히는 설명 프레임
면접관이 듣고 싶은 건 도구 이름이 아니라 운영 역량입니다.
다음 순서로 답하면 전달력이 좋습니다.
- 문제 정의: AI 도입 후 생산성은 늘었지만 코드 일관성이 무너졌다.
- 개입 방식: Context Contract를 도입해 입력 규격을 고정했다.
- 운영 결과: 리뷰 재작업률/회귀 이슈를 낮췄다.
- 확장 계획: E2E + 시각 회귀 + 디버깅 런북으로 연결했다.
숫자가 있으면 더 강합니다.
- “리뷰 재요청 비율 38% → 17%”
- “배포 후 UI 회귀 이슈 주 4건 → 주 1건”
자주 하는 실수 3가지
1) 프롬프트를 문학처럼 길게 쓰기
길수록 좋은 게 아닙니다. 모델이 지켜야 할 우선순위가 흐려집니다.
2) 팀 규칙보다 개인 취향을 앞세우기
Context Contract는 개인 최적화 문서가 아니라 팀 합의의 압축본이어야 합니다.
3) 실패 로그를 남기지 않기
실패를 기록하지 않으면 품질 개선이 아니라 감으로 일하게 됩니다. 최소한 실패 원인 카테고리(타입/상태/네트워크/접근성)는 분리하세요.
오늘 바로 실행할 체크리스트
- 현재 프로젝트 규칙 10줄로 요약
- PR 템플릿에 Done Criteria 3개 추가
- 다음 기능 1개를 Contract 기반으로만 구현
- 실패 로그 1건 이상 기록
이 네 가지면 “AI 활용 경험”이 “운영 가능한 엔지니어링 경험”으로 전환됩니다.
마무리
이제 프론트엔드 채용에서 “AI 써봤다”는 기본값입니다. 차이는 재현 가능한 품질 운영 체계에서 납니다.
Context Contract는 거창한 프레임워크가 아닙니다. 하지만 이직 관점에서는 강력한 증거가 됩니다.
- 나는 생성 속도만 올린 사람이 아니라,
- 생성 결과를 팀 품질로 고정한 사람이다.
이 한 문장을 포트폴리오와 면접에서 보여줄 수 있으면, 같은 AI 사용자 안에서도 확실히 구분됩니다.