이직에 바로 쓰는 프론트엔드 AI 실무: 하네스 엔지니어링으로 PR 품질 고정하기
요즘 Velog 트렌딩을 보면 AI 글이 꾸준히 상위에 있습니다. 특히 최근에는 다음 유형이 반응이 좋습니다.
- AI 코딩 도구 사용기 자체보다 실패/복구 기록이 있는 글
- “프롬프트 팁”보다 실제 운영 규칙을 보여주는 글
- 개인 생산성 자랑보다 팀에서 재사용 가능한 방식을 다룬 글
이 흐름에서 프론트엔드 이직 준비자가 가져가야 할 핵심은 하나입니다.
“나는 AI를 잘 쓰는 사람이 아니라, AI가 만든 결과의 품질을 운영할 수 있는 사람이다.”
이번 글은 그 메시지를 가장 잘 보여주는 방법인 하네스 엔지니어링(Harness Engineering) 관점으로, PR 품질을 일정하게 유지하는 실무 루틴을 정리합니다.
하네스 엔지니어링이 왜 이직에서 강한가
프롬프트 엔지니어링은 “좋은 답을 요청하는 기술”에 가깝습니다. 반면 하네스 엔지니어링은 “나쁜 답이 들어와도 품질을 지키는 시스템”에 가깝습니다.
면접관이 궁금한 것도 결국 이쪽입니다.
- AI 산출물이 흔들려도 품질 기준을 지킬 수 있는가
- 코드리뷰/테스트/배포를 일관된 절차로 운영하는가
- 개인 역량을 팀 프로세스로 확장할 수 있는가
즉, 이직에서 점수를 주는 건 도구 숙련도 자체보다 품질 통제 능력입니다.
코드 리뷰 관점은 프론트엔드 AI 코드리뷰 실무 적용 플레이북, 릴리즈 직전 통제 기준은 이직에 바로 쓰는 프론트엔드 AI 실무: 릴리즈 준비도 체크리스트와 연결해서 보면 더 탄탄해집니다.
하네스의 최소 구성: 4단계만 고정해도 효과가 난다
복잡한 플랫폼 없이도 아래 4가지만 고정하면, PR 품질 편차가 확 줄어듭니다.
1) 입력 경계 정의 (Context Contract)
AI에게 넘기는 컨텍스트를 제한합니다.
- 수정 가능한 파일 범위
- 금지 영역(인증/결제/공통 유틸)
- 완료 기준(테스트, 접근성, 성능)
컨텍스트 계약을 먼저 고정하면, “그럴듯하지만 위험한 수정”을 초반에 잘라낼 수 있습니다.
관련해서는 이직에 바로 쓰는 프론트엔드 AI 실무: 컨텍스트 계약서 작성법을 함께 참고하세요.
2) 자동 검증 체인 고정
최소한 아래는 PR마다 동일하게 돌립니다.
- 정적 검사(lint/typecheck)
- 핵심 플로우 테스트(단위 또는 E2E 축약본)
- 빌드 성공 여부
여기서 중요한 건 “많이 검사”가 아니라 항상 같은 순서로 검사하는 것입니다.
3) 사람 리뷰 체크리스트
AI 코드의 첫 번째 위험은 동작 실패보다 설계 일관성 붕괴입니다. 아래 세 가지만 사람 리뷰에서 반드시 확인합니다.
- 기존 아키텍처 경계를 깨지 않았는가
- 에러/로딩/빈 상태 처리가 누락되지 않았는가
- 비즈니스 규칙이 코드에 하드코딩되지 않았는가
4) PR 설명 템플릿 고정
PR 본문 형식을 고정하면, 면접에서도 그대로 “재현 가능한 실무 방식”으로 설명할 수 있습니다.
## 변경 요약
- 무엇을 바꿨는지
- 왜 바꿨는지
## AI 사용 범위
- 초안 생성:
- 사람이 직접 수정:
- 반려한 제안:
## 검증 결과
- lint/typecheck:
- test:
- build:
## 리스크와 후속 작업
- 남은 리스크:
- 다음 액션:실무 시나리오: 검색 필터 페이지 개선 PR
예시로 “검색 필터 + 정렬 + URL 동기화” PR을 가정해 보겠습니다.
입력 경계
- 수정 허용:
app/search/*,app/lib/search/* - 수정 금지: 인증 미들웨어, 공통 API 클라이언트
- 완료 기준: URL 공유 재현 가능 + 빈 상태 UI + 빌드 통과
AI 초안에서 자주 생기는 문제
- 상태를 과도하게 전역화해서 복잡도가 증가
- useEffect 체인이 늘어나서 추적이 어려워짐
- 쿼리 파싱 예외 케이스 누락
하네스 적용 후 결정
- 상태는 로컬 + URL 동기화로 유지
- 파싱 로직은 순수 함수로 분리 후 단위 테스트 추가
- 빈 결과/에러 상태를 분리된 UI 블록으로 명시
이렇게 결정하면 “코드가 돌아간다”에서 끝나지 않고, 왜 이 설계를 택했는지를 PR과 면접에서 모두 설명할 수 있습니다.
이직 포트폴리오에 바로 반영하는 법
하네스 엔지니어링은 화려한 데모보다, 다음 3가지를 남겼을 때 강해집니다.
- 운영 규칙 문서: 어떤 기준으로 AI 산출물을 통제하는지
- 증거 PR: 규칙이 실제로 적용된 변경 이력
- 회고 로그: 실패 패턴과 다음 개선점
포트폴리오 문장도 이렇게 바꾸면 좋습니다.
- 나쁜 문장: “AI로 개발 속도를 크게 높였습니다.”
- 좋은 문장: “AI 산출물 품질 편차를 줄이기 위해 하네스(입력 경계·검증 체인·리뷰 체크리스트)를 운영했고, PR 리드타임 대비 회귀 이슈를 낮췄습니다.”
숫자가 있다면 더 좋지만, 숫자가 없어도 판단 구조를 보여주면 충분히 경쟁력이 생깁니다.
7일 실전 루틴 (취준/이직 모드)
Day 1
- 최근 PR 1개 선택
- 입력 경계/완료 기준 문서화
Day 2~3
- AI로 동일 작업 재시도
- 하네스 없이 만든 결과와 비교
Day 4~5
- 검증 체인 고정 (
lint → test → build) - 실패 패턴 3개 기록
Day 6
- PR 템플릿 적용 후 설명 문장 다듬기
Day 7
- 면접 답변 1분 버전 작성
- “도구 사용”이 아니라 “품질 운영” 중심으로 리허설
면접에서 바로 쓰는 30초 답변
“AI로 코드를 빠르게 만드는 것보다, 품질 편차를 통제하는 데 집중했습니다. 그래서 입력 경계와 검증 체인을 하네스로 고정했고, PR마다 같은 기준으로 리뷰했습니다. 덕분에 구현 속도뿐 아니라 회귀 위험을 줄인 근거를 로그와 PR로 설명할 수 있습니다.”
이 답변의 장점은 간단합니다. 도구 유행이 바뀌어도 당신의 실무 역량은 남는다는 걸 보여줍니다.
마무리
지금 이직 시장에서 AI 활용은 이미 기본값입니다. 차이를 만드는 건 “무슨 도구를 쓰는가”가 아니라, 아래를 운영할 수 있는가입니다.
- 품질 기준을 먼저 고정하는가
- 실패를 검증 가능한 형태로 기록하는가
- 개인 요령을 팀 프로세스로 전환하는가
이번 주에는 새 도구를 더 배우기보다, 기존 프로젝트 PR 하나에 하네스를 얹어보세요. 그 한 번의 실험이 포트폴리오의 밀도를 눈에 띄게 바꿔줄 겁니다.