스터닝 채용 과제, 직접 만들어봤습니다

안녕하세요, 스터닝의 개발자 이준구입니다!

이번 글에서는 저희가 채용 과제를 설계할 때 단순한 구현 과제가 아닌 실제 업무 시뮬레이션 형태로 만든 이유,

그리고 E2E 자동 채점 시스템을 만들며 겪은 시행착오를 공유하려 합니다.

“채용 과제는 CRUD면 되지?” 🤔

많은 팀이 기술 과제를 만들 때 가장 먼저 떠올리는 건, 단순한 CRUD(Create, Read, Update, Delete)입니다.

하지만 저희는 거기서 한 발 더 나아가 보기로 했습니다 사실 저희 프론트엔드 과제의 평가 포인트는 명확합니다.

1. 데이터를 UI로 변환하는 능력 — 복잡한 데이터 구조를 사용자 친화적인 인터페이스로 얼마나 효과적으로 표현하는가
2. 예외 상황 처리의 완성도 — 네트워크 지연, API 실패 등의 예외 상황에서도 일관된 사용자 경험을 제공하는가
3. 협업을 고려한 코드 품질 — 명확한 네이밍, 적절한 주석, 일관된 패턴 등 다른 개발자가 이해하고 확장하기 쉬운 코드인가
4. 지속 가능한 아키텍처 — 요구사항 변경과 기능 확장에 유연하게 대응할 수 있는 구조인가

이 기준을 만족하는 과제를 만들다 보면, 자연스럽게 이런 고민이 따라옵니다.

• 그냥 CRUD 하나 출제하면 되는 거 아닌가?
• 기술 스택 맞춰서 예제 앱만 만들게 하면 되지 않나?

그런데 저희는 이렇게 생각했습니다.

“지원자가 실제 우리 팀에서 마주칠 문제를, 미리 경험하게 하자.”

이 접근이 주는 장점은 명확합니다.

지원자 입장에서는

→ “아, 이 회사에서는 이런 문제를 이런 식으로 푸는구나.”

팀 입장에서는

→ “이 분이 실제 투입되면 이렇게 문제를 풀겠구나.”

즉, 단순 구현 능력보다 문제를 대하는 태도와 구조적 사고력을 더 잘 볼 수 있는 방식이죠.

실무 시뮬레이션 과제 설계

저희는 실제 라우드(LOUD) 서비스에서 사용하는 UI, API, 로직을 간소화한 형태로 재구성한 과제를 만들기로 했습니다.

시나리오는 단순히 “목업” 수준이 아니라, 프론트엔드 실무에서 자주 마주치는 문제 상황을 압축해 담았습니다.

• 리스트 & 조건부 렌더링
• 데이터 캐싱 및 가공 로직
• API 응답 지연 & 실패 처리
• 반응형 UI & 상태 관리
• 멀티스텝 폼 & 유효성 검사

이런 구조를 통해

지원자는 “현실감 있는 문제를 직접 해결하는 경험”을 하게 되고, 저희는 “실제 협업 상황에서의 사고방식과 문제 접근법”을 보다 투명하게 볼 수 있습니다.

요구사항 속 숨은 장치 🧩

그냥 기능만 구현하는 과제는 재미도 없고 배울점도 없죠?

그래서 실제 서비스 개발 중 마주할 수 있는 몇 가지 상황을 의도적으로 심어뒀습니다.

• 랜덤 API 에러 → 예외 처리 능력 검증
• 응답 지연 → 로딩 상태와 UX 설계 능력
• 불완전 데이터 → 데이터 가공 및 캐싱 전략
• 의존 API 호출 → 비동기 흐름 제어 및 구조 설계

이런 장치들은 단순히 “트랩”이 아니라, 지원자가 문제를 얼마나 유연하게 다루는지를 드러내는 중요한 힌트입니다.

E2E 자동 채점 시스템 ⚡

과거에는 제출된 과제를 하나하나 직접 설치하고, 실행하고, 확인했습니다.문제는 — 시간이 너무 오래 걸리고, 심사자마다 기준이 조금씩 다를 수밖에 없었다는 점이었습니다.

그래서 “자동 채점 시스템을 도입해보자”는 결론에 이르렀습니다. 도입 목표는 명확했습니다.

1. 일관된 채점 기준 확보
2. 최소 요구사항 충족 여부의 빠른 판별
3. 반복적인 검증 작업 감소 → 코드 리뷰에 더 많은 시간 투자

일관된 채점 기준 확보

구분 내용 기본 요구사항 필수 기능 구현 자율 구현사항 UX 개선, 에러 처리, 최적화 등

저희는 평가를 ‘기본 구현’과 ‘도전 과제’로 명확히 분리했습니다.

이렇게 하면 참가자들이 공통적으로 충족해야 할 최소 기준을 먼저 검증하고,

그 위에서 얼마나 사용자 경험과 구조적 완성도를 높였는지를 명확히 평가할 수 있습니다.

결과적으로, 심사 과정에서의 일관성 있는 기준을 확보하면서도 지원자의 기본기와 센스를 분리해 평가할 수 있게 되었습니다.

E2E 채점도 이 두 부분을 나눠서 진행합니다.

→ 실무 경험이 적은 분도 완주 가능,

→ 경험 많은 분은 자율 구현에서 역량 발휘 가능.

Mock API vs 로컬에서 띄우는 서버 API

실제 로컬 서버를 띄워서 사용할 수 있는 API를 쓸까 고민했지만, 결국 Mock API를 사용하는 쪽으로 결정했습니다 이유는 아주 단순했는데요?

복잡한 서버 세팅 없이 바로 개발 가능

실제 서버를 띄우려면 환경 설정, DB 연결, 인증 등 사소하지만 귀찮은 작업들이 많습니다. Mock API를 쓰면 이런 준비 과정 없이 바로 화면 개발에 집중할 수 있죠.

응답 모델을 단순하게 유지할 수 있음

서버 개발과 동시에 스펙이 바뀌는 경우가 많은데, Mock API를 사용하면 필요한 필드만 빠르게 정의하고 수정할 수 있습니다. 즉, 프론트 개발에 최적화된 형태로 데이터를 가짜로 만들어 쓸 수 있다는 거예요.

프로젝트 전체 규모를 작게 유지할 수 있음

서버를 따로 관리하지 않아도 되기 때문에, 초기 개발 속도는 물론 유지보수 부담도 훨씬 줄어듭니다. MVP나 프로토타입 단계에서는 이 단순함이 오히려 큰 장점으로 작용하죠.

결국 “빠르게 만들고, 빠르게 확인하자”라는 목적에 가장 잘 맞는 선택이 Mock API였습니다.

성공/실패 시나리오 분리

서비스 환경에서는 항상 성공과 실패 두 가지 시나리오를 다뤄야 합니다.

하지만 실제 API를 바로 붙여버리면, 실패 케이스를 재현하기가 생각보다 쉽지 않죠.

그래서 msw(Mock Service Worker) 환경에서 환경 변수를 참조하도록 구조를 설계했습니다.

ERROR_RATE=10
DELAY_TIME=300

위와 같이 환경 변수를 설정해두면, 요청의 일부를 의도적으로 실패시킬 수도 있고, 지연 시간을 추가해 네트워크 환경을 시뮬레이션할 수도 있습니다.

덕분에 E2E 테스트나 QA 단계에서 “실패율 10%”, “300ms 네트워크 지연” 같은 현실적인 시나리오 테스트가 가능해졌어요.

즉, 단순히 성공만 확인하는 게 아니라 실제 서비스 운영 환경에 가까운 상황을 모킹으로 만들어볼 수 있다는 것이죠.

결과적으로 개발 단계에서도 안정성 높은 코드를 만들 수 있었고,

“실패했을 때 UI가 어떻게 반응하는가” 같은 세밀한 부분까지 미리 점검할 수 있었습니다.

동작 흐름

지원자 PR → Docker 빌드 → E2E 실행 → JSON 리포트 → 채점 결과

1. 지원자가 채점용 브랜치에 PR 제출
2. 도커에서 앱 빌드 & 기동
3. 데스크톱 / 모바일 해상도로 병렬 E2E 실행
4. 테스트 결과 JSON 리포트 저장
5. 리포트를 파싱해 채점 결과 Summary 및 Artifact 저장

최종적으로 아래와 같은 채점 결과가 Summary에 저장됩니다 이로써 단지 브랜치에 들어가 보는 것 만으로 채점 결과를 확인할 수 있어 개발팀의 노고를 줄일 수 있었습니다

Recap

얻은 점

• 지원자 필터링 속도가 눈에 띄게 단축
• 면접 시간을 코드 리뷰·기술 대화 중심으로 재편
• “잠시나마 스터닝 개발팀의 일원이 된 기분이었다”는 피드백

개선 아이디어

• 브라우저 퍼포먼스 로깅 추가
• E2E 스크린샷 비교 자동화

저희는 여전히 완벽한 정답보다 문제를 해결해 가는 과정을 더 중요하게 봅니다.

이번 채용 과제와 자동 채점 시스템을 통해,

• 지원자는 실제 업무에 가까운 경험을,
• 우리는 더 정확한 판단 근거를 얻을 수 있었습니다.

결국 채용은 단순한 평가가 아니라 서로를 알아가는 시간이어야 한다고 믿습니다.

앞으로도 그 시간을 더 의미 있게 만들기 위해 계속 실험하고 다듬어 나가겠습니다. ✨