index

에이전트 기반 FE 채용 과제 설계 및 자동 평가 시스템 구축 회고

2026.03.04 · 12min

에이전트 기반 FE 채용 과제 설계 및 자동 평가 시스템 구축 회고

AI 제품 FE 채용을 위해 진행한 과제 포트폴리오 설계 전 과정의 기록. 단순 과제 제작을 넘어, “무엇을 왜 측정하는가”에서 출발하여 자동 채점 시스템까지 구축한 과정.

1. 출발점: 1원칙에서 시작한 설계

AI 제품의 FE는 무엇이 다른가

일반 CRUD 앱과 달리, AI 워크플로우 빌더 같은 제품의 FE는 두 가지 본질적 특수성이 있다:

데이터가 비결정적이다 — AI 응답은 형태와 길이가 매번 다르고, 도착 순서가 보장되지 않는다
UI가 런타임에 결정된다 — 렌더링할 컴포넌트 타입이 사전에 정해져 있지 않다 (Generative UI)

이 두 조건으로부터 핵심 파이프라인을 도출했다:

비동기 데이터 수신 → 점진적 파싱 → 타입 결정 → 컴포넌트 렌더링

이 파이프라인이 과제 포트폴리오 전체의 설계 근거가 됐다. 모든 과제는 이 파이프라인의 어느 지점에서, 어느 깊이로 테스트하는지가 다를 뿐이다.

”무엇을 관찰해야 하는가”를 먼저 정했다

과제 주제를 먼저 고르지 않았다. 대신:

관찰 대상	핵심 질문
상태 설계	서로 다른 관심사를 어떻게 경계 짓는가
비결정적 데이터 처리	streaming 중간 상태를 어떻게 모델링하는가
동적 렌더링	런타임 데이터를 타입 안전하게 컴포넌트로 매핑하는가
판단의 근거	결과물보다 의사결정 과정이 재현 가능한 실력인가

이 네 가지를 정한 뒤, 각각을 드러내는 과제를 역산했다.

2. 시장 리서치와 핵심 발견

글로벌 벤치마크에서 얻은 것

Vercel, Linear: LeetCode 탈피, 실무 미러링 과제로 전환 중
OpenAI: “기존 제품의 일부를 JS 프레임워크로 구현” — 스트리밍 채팅이 대표 과제
Cursor: 온사이트에서 버그 포함 서버를 제공하고 FE가 대응하는 패턴 사용
Meta: 2025.10부터 AI-enabled coding interview 도입 — AI 사용 자체가 아닌 “AI 출력을 어떻게 검증하는가”를 평가

핵심 시사점: 코드 결과물만으로 실력 판단이 어려운 시대. “과정”을 평가하는 구조가 필요하다.

국내 주요 FE 과제 심층 분석

국내 탑티어 FE 사전과제를 실제 코드 수준에서 분석했다:

패턴	구체적 구현
테스트 = 스펙	Easy / Hard 분리. 수정 금지. 테스트가 요구사항을 정의
현실적 Mock	랜덤 에러, 레이트 리밋, 딜레이 — 해피패스만 구현하면 Hard 실패
스캐폴딩 전략	라우트, API 함수, 컴포넌트 제공. 페이지 구현은 비워둠
API spy 검증	`spyOn(remotes, 'getXxx')`로 올바른 API 호출 여부를 테스트가 검증

이 패턴에서 “테스트가 스펙이다”라는 아이디어를 가져왔다.

초기 설계의 약점 발견

초기에 설계한 과제가 글로벌 빅테크 면접 과제와 유사하다는 것을 리서치에서 발견했다. 면접 준비도와 1원칙 사고력의 구분이 어렵다는 결론 — 과제를 다시 설계했다.

3. 과제 포트폴리오 설계

세 평가 축

       설계 판단 (열린 요구사항)
            ↑
            │
            │    하이브리드 과제 ← 설계 + 테스트 동시 검증
            │
            │    테스트 기반 과제 ← 구현 정확성 중심
            │
            └──────────────────────────────────→ 구현 정확성 (테스트 통과)
                                   ↗
                         FE-서버 통합 (버그 대응)

경력별 복잡도를 차등화하되, 같은 핵심 파이프라인을 테스트하는 구조를 설계했다:

복잡도 축	주니어-미드	미드-시니어	시니어
상태 도메인	1-2개	2개	3개
스트리밍 난이도	1 스트림, 순서 보장	1 스트림, JSON 파싱	복수 스텝, 순서 뒤바뀜
설계 분기점	3-4개	6-7개	8-9개

“원사이즈핏올” 안티패턴을 피하면서도, 같은 역량의 다른 깊이를 측정하는 구조다.

4. 지원자 DX 설계 철학

테스트가 곧 스펙이다

가장 중요한 DX 원칙.

README.md에 요구사항을 글로 쓰는 것이 아니라
테스트 코드가 요구사항을 정의한다

지원자는 테스트 코드를 먼저 읽고 요구사항을 파악한다. 이 방식의 장점:

모호한 요구사항 해석 분쟁이 없다
1차 스크리닝을 npm test 결과 한 줄로 수행할 수 있다
테스트가 후보자에게 신뢰감을 준다 (“이 회사는 테스트를 씁니다”)

의도적 버그를 포함한 서버

Cursor의 온사이트 패턴에서 착안. 실무에서 흔히 발생하는 패턴의 서버 버그를 의도적으로 포함했다.

버그 설계 원칙:

모든 버그는 실제 프로덕션에서 발생하는 패턴 (인위적이지 않게)
로그(콘솔, 네트워크 탭)로 발견 가능한 수준 (숨겨진 퍼즐이 아님)
버그를 찾는 것이 목적이 아니라, 버그에 어떻게 대응하는 FE를 만드는가가 핵심

스캐폴딩 전략

너무 적으면 보일러플레이트에 시간 낭비, 너무 많으면 설계 판단 기회 제거.

제공: 라우트, API 함수, TypeScript 타입, 기본 UI 컴포넌트, 수정 금지 테스트 구현 필요: 페이지 컴포넌트 (3개)

이 경계가 “순수 FE 설계 역량”을 측정하는 데 최적화된 접점이다.

AI 투명성 3단계 프레임워크

LLM 시대에 코드 결과물만으로 실력 판단이 어렵다는 문제를 구조적으로 대응했다:

Level 1: AI_USAGE.md 구조화 — 위임 판단 기록 + AI 실패 사례 Level 2: AI 로그 선택 제출 — Claude Code 등 로컬 로그가 있는 도구 사용 시 Level 3: Git 이력 기반 객관 시그널 — 커밋 리듬, 크기, 메시지 품질로 교차 검증

5. 과제 Iteration

첫 번째 과제 버전(대시보드)에서 두 번째 버전(채팅 + 프리뷰)으로 개선하면서 얻은 교훈:

	v1 (대시보드)	v2 (채팅 + 프리뷰)
설계 판단	거의 없음 (역산으로 풀림)	상태 분리, 라이브러리 선택, 레이아웃
실무 유사도	낮음	높음 (SSE 챗봇은 AI 제품의 보편적 패턴)
AI로 풀기	30분이면 끝	판단 포인트가 많아 AI만으론 부족
지원자 경험	기계적	만들어가는 느낌

v2가 개선된 이유:

2패널 레이아웃은 Claude Artifacts, Cursor 같은 실제 AI 도구의 보편적 패턴
text_delta와 artifact_delta 분리는 자연스럽게 상태 설계 판단을 드러냄
라이브러리 선택이 “도구 선별력” 평가 포인트가 됨

6. Agentic Playbook 기반 자동 평가 시스템

아키텍처

Playwright 같은 별도 프레임워크 없이, Claude Code + DevTools MCP 조합으로 E2E 채점을 자동화했다.

setup.sh → 의존성 설치 → Unit Test 자동 실행 → 서버 기동
    ↓
PLAYBOOK.md → Claude Code에게 E2E 채점 위임
    ↓  (DevTools MCP로 브라우저 조작: snapshot → click/fill → wait_for)
    ↓
SCORECARD.md → 표준 채점표에 결과 기록

setup.sh의 역할

단일 명령(./setup.sh /path/to/submission)으로 전체 환경을 구성한다. 평가자 개입 없이 1분 이내에 환경이 완성된다.

PLAYBOOK.md: agent에게 주는 채점 프롬프트

7개 시나리오 각각에 구체적 조작 순서, 체크포인트(CP#-# 형식), 부분 점수 기준을 명시. 총 100점 배점(Unit Test 15 + E2E 85).

빠른 스크리닝 (5분)

1. npm test → 통과 개수 확인
2. 핵심 페이지 코드 → SSE/상태 처리 방식 확인
3. AI_USAGE.md → AI 활용 수준 파악

등급: Strong Hire(85+) / Hire(70-84) / Borderline(55-69) / No Hire(~54)

7. 시사점

“무엇을 측정하는가”를 먼저 정했다 — 과제 주제보다 관찰 대상이 먼저
하이브리드 평가 — “테스트 통과 ≠ 좋은 코드”를 제도적으로 인정
서버 버그 = 실무 시뮬레이션 — 완벽한 Mock API는 FE 역량 측정에 최적이 아님
AI 활용을 평가 구조 안으로 — 금지가 아닌 투명성 요구
자동 평가 = 채용 속도 — agent + DevTools MCP로 반복 가능하고 일관적인 채점
도구 선별력 — “어떤 도구를 골랐느냐”가 아니라 “선택이 의식적이었느냐”

8. 열린 리스크

소요시간 추정 정확성: 내부 파일럿 테스트로 검증 필요
테스트 코드 유지보수: 라이브러리 업데이트에 테스트가 깨질 수 있음
AI 저널 성실도: 지원 의향에 따라 달라질 수 있음 → 라이브 세션으로 교차 검증
도구 선별력 평가 왜곡: “우리 스택을 미리 아느냐”로 왜곡될 위험 → 루브릭에서 선택 이유에 가중치