이직에 강한 프론트엔드 포트폴리오: AI 산출물 검증 스코어카드 운영법
최근 Velog 트렌딩을 보면 AI 관련 글이 크게 두 갈래입니다.
- “어떤 모델이 더 잘 쓰인다” 같은 도구 비교
- “AI로 실제로 무엇을 만들었고 무엇이 어려웠는지” 같은 운영 경험
문제는 이직 시장에서 후자도 아직 부족하다는 점입니다. 대부분 “만들었다”에서 끝나고, 품질을 어떻게 통제했는지가 빠져 있습니다.
그래서 이번 글에서는 AI 코딩 도구(Codex, Claude, Cursor 등)로 만든 결과물을 프론트엔드 팀 기준으로 검증하는 스코어카드 방식을 소개합니다. 핵심은 단순합니다.
생성 속도는 AI가 담당하고, 품질 신뢰도는 사람이 숫자로 증명한다.
왜 스코어카드가 이직에 유리한가
면접에서 기술적으로 좋은 인상을 주는 포인트는 기능 데모 자체보다 다음 질문에 답할 때 나옵니다.
- 이 구현이 배포 가능한 수준인지 어떻게 판단했나요?
- AI가 만든 코드의 리스크를 어떻게 줄였나요?
- 같은 방식으로 팀 전체 생산성을 올릴 수 있나요?
스코어카드는 이 세 질문을 한 번에 해결합니다.
- 기준이 문서화되어 재현 가능하고
- 점수가 누적되어 개선 흐름을 보여줄 수 있고
- 결과를 숫자로 설명할 수 있습니다
코드리뷰 기준이 아직 없다면 먼저 AI 코드리뷰 실무 적용 플레이북을 보고, E2E 품질 측정은 Playwright 기반 E2E Eval 운영 가이드를 함께 읽는 걸 추천합니다.
스코어카드 구조: 4개 축만 고정해도 충분하다
처음부터 복잡하게 만들 필요는 없습니다. 아래 4개 축으로 시작하면 실무에 바로 적용됩니다.
1) 기능 정확성 (Functional)
- 요구사항 충족 여부
- 예외/빈 상태 처리 여부
- API 실패 시 사용자 피드백
2) 사용자 경험 (UX/A11y)
- 키보드 접근 가능 여부
- 폼 에러 메시지의 명확성
- 로딩/빈 상태/오류 상태 일관성
3) 성능 안정성 (Performance)
- 주요 페이지 LCP/INP/CLS 추이
- 불필요한 렌더링 증가 여부
- 번들 크기 급증 여부
4) 운영 안정성 (Ops)
- 에러 추적(Sentry 등) 연결 여부
- 롤백 가능한 PR 단위인지
- 장애 시 관측 로그가 남는지
각 항목을 0~2점으로 두면 총 8점 만점이 됩니다.
- 0점: 기준 미충족
- 1점: 부분 충족(보완 필요)
- 2점: 배포 가능 수준
실전 운영 예시: 검색 자동완성 기능
예를 들어 AI에게 “검색 자동완성 드롭다운”을 생성하게 했다고 가정해 봅시다.
1차 평가
- 기능 정확성: 2점 (기본 동작 OK)
- UX/A11y: 0점 (키보드 탐색 불가)
- 성능 안정성: 1점 (입력마다 API 호출)
- 운영 안정성: 0점 (에러 로깅 없음)
총점: 3/8
이 점수만으로도 무엇을 먼저 고쳐야 할지 선명해집니다.
개선 후 2차 평가
- 기능 정확성: 2점
- UX/A11y: 2점 (Arrow/Enter/Escape, aria-activedescendant 적용)
- 성능 안정성: 2점 (debounce + 취소 토큰)
- 운영 안정성: 1점 (에러 로깅 연결, 대시보드 미완)
총점: 7/8
면접에서는 이 흐름을 “문제 발견 → 기준 적용 → 점수 개선”으로 설명하면 설득력이 높습니다.
PR 템플릿에 바로 붙일 수 있는 스코어카드
## AI 산출물 검증 스코어카드 (8점 만점)
- 기능 정확성: 0|1|2
- UX/접근성: 0|1|2
- 성능 안정성: 0|1|2
- 운영 안정성: 0|1|2
총점: X/8
### 근거
- 테스트 결과:
- 측정 지표(LCP/INP/CLS):
- 에러 로그 링크:
- 남은 리스크:이 템플릿이 좋은 이유는 “잘 만들었다”라는 감상 대신, 근거 있는 결정 로그를 남기기 때문입니다.
브랜치 운영은 Trunk Based Development 가이드처럼 작은 단위 병합을 유지하면 가장 잘 맞습니다.
이직 포트폴리오에 넣는 방법
포트폴리오 README 또는 프로젝트 소개 문서에 아래 3가지를 넣어보세요.
- 검증 기준 표: 4개 축과 점수 정의
- 개선 전/후 점수 변화: 최소 2개 기능 사례
- 실패 사례 1개: 점수는 올랐지만 배포 보류한 이유
특히 실패 사례가 중요합니다. AI 시대에는 “항상 성공했다”보다, 배포 보류를 결정한 기준이 있다는 개발자가 더 신뢰받습니다.
2주 적용 플랜
1주차: 기준 고정
- 자주 수정되는 UI 기능 1개 선택
- 스코어카드 항목 4개 정의
- PR 본문에 점수와 근거를 의무화
2주차: 지표 연결
- Lighthouse 또는 Web Vitals 수치 기록
- 에러 로깅 링크를 PR에 첨부
- 2회 이상 점수 추이를 남기고 회고 작성
짧게 운영해도 “AI를 쓴 경험”이 “AI를 통제한 경험”으로 바뀝니다.
마무리
AI 코딩 생산성은 이제 기본 역량이 되어가고 있습니다. 이직에서 차이를 만드는 건 다음입니다.
- 빠르게 만들 수 있는가
- 위험을 줄일 수 있는가
- 그 판단을 팀이 재사용할 수 있는 형태로 남길 수 있는가
스코어카드는 이 세 가지를 동시에 보여줍니다.
다음 프로젝트부터는 “어떤 모델을 썼는지”보다, 어떤 기준으로 배포를 결정했는지를 기록해 보세요. 그 기록이 결국 실무형 포트폴리오의 핵심 자산이 됩니다.