2026 무신사 MUSINSA ROOKIE AI NATIVE ENGINEER(인턴) 1차, 2차 코딩 테스트 후기

황토소금·2026년 2월 18일

AI Native MUSINSA 과제 과제 AI 사용 무신사 무신사 MUSINSA ROOKIE AI NATIVE ENGINEER 코딩테스트 후기

들어가며

후기를 남겨도 된다고 안내 받아 후기 작성합니다.

2차 과제의 경우 문제는 아래에서 확인할 수 있습니다.
https://github.com/musinsatech/2026-musinsa-rookie

1차 코딩 테스트 후기

1시간 동안 두 문제를 풀어야 했습니다.
플랫폼은 구름이었고 언어는 Java, Kotlin, JavaScript, Python 중 선택이었습니다.
안내 메일에서 1차 코딩테스트의 방향성을 알려주었는데 핵심은 "문제의 지문을 정확히 읽고, 요구사항에 맞춰 논리적으로 구현"하는 것이었습니다.

첫번째 문제

여러 브랜드의 옷 사이즈 정보와 고객 정보가 주어지면, 고객에게 맞는 사이즈를 찾아 출력하는 구현 문제였습니다. 단순히 사이즈를 매칭하는 것에서 끝나지 않고, 범위를 벗어나는 경우나 브랜드가 존재하지 않는 경우 등 다양한 예외 케이스를 정확하게 처리해야 했습니다.

이 문제의 핵심은 꼼꼼함이었다고 생각합니다. 케이스가 세분화되어 있어서 하나라도 놓치면 틀리는 구조였습니다.

두번째 문제

현재 기억이 잘 나지 않습니다. 🥲

정리하면

안내 메일에서 "문제의 지문을 정확히 읽고, 요구사항에 맞춰 논리적으로 구현"하는 것이 핵심이라고 미리 알려줬는데, 실제 문제도 그 말 그대로였습니다. 평소에 구현 문제를 많이 접해두는 게 도움이 될 것 같고, 조건이 많은 문제일수록 꼼꼼하게 요구사항을 정리하고 들어가는 것이 중요하다고 느꼈습니다. 개인적으로는 코드를 바로 작성하기보다 요구사항을 주석으로 먼저 적어두면서 전체 흐름을 잡아놓는 방식으로 접근하였습니다.

2차 코딩 테스트 후기

과제 내용은 대학교 수강신청 시스템의 백엔드 REST API를 구현하는 것이었습니다. 핵심 요구사항은 "정원이 1명 남은 강좌에 100명이 동시에 신청해도 정확히 1명만 성공해야 한다" 는 동시성 제어였고, 제한 시간은 3시간이었습니다. (https://github.com/musinsatech/2026-musinsa-rookie)

저는 프론트엔드 위주 경험을 가지고 있어서 처음엔 막막했습니다.

워크플로우 구성

무작정 "수강신청 시스템 만들어줘"를 입력하지는 않았습니다. spec-kit 기반으로 커스텀한 오케스트레이션 워크플로우를 바탕으로 Claude Code를 메인 세션으로 운용했습니다. 요구사항 분석, 기술 스택 선정, 구현, 테스트, 문서화까지 거의 모든 작업이 이 메인 세션에서 이루어졌습니다.
기술 스택도 처음부터 정해두지 않았습니다. Claude Code와 대화하면서 결정했습니다. 과제 요구사항을 같이 읽고, 인메모리 DB 선택, 동시성 제어 방식, 트랜잭션 전략을 논의한 끝에 Spring Boot + Kotlin + H2로 확정했습니다.

서브 세션 운용

메인 세션 하나만이 아니라 서브 세션을 따로 운용했습니다.
Claude Code는 작업 도중 저에게 결정을 요구하는 질문을 던집니다. 예를 들어 이런 식이었습니다.

"동시성 전략을 어떻게 할까요? Course와 Student 양쪽 모두 Optimistic Lock으로 가는 방향도 있고, Student 축은 Pessimistic Lock으로 가는 방법도 있습니다."

이 질문에 그냥 "알아서 해줘"라고 답하는 건 의미가 없습니다. 제가 이해하고 결정해야 그 결정이 이후 구현 전체에 일관성 있게 반영되고, 문서로도 남길 수 있습니다. 그런데 백엔드 경험이 부족하다 보니 메인 세션에서 결정 요구가 올 때마다 그 공백이 드러났습니다.
그래서 서브 세션을 교차 검증 용도로 활용했습니다. 메인 세션에서 받은 질문을 그대로 가져가서 각 선택지가 이 상황에서 어떤 문제를 만드는지 물었습니다. 이해한 뒤 제 판단으로 메인 세션에 답을 줬습니다.
서브 세션은 작업을 대신하지 않았습니다. 제 이해의 빈틈을 채우고 결정에 근거를 주는 역할이었습니다.

3시간을 어떻게 썼나

과제 평가 기준에 흥미로운 대목이 있었습니다.

"AI 활용 영역의 비중은 코드 품질보다 큽니다."

동작하는 코드를 빠르게 뽑아내는 것보다, AI와 어떻게 협업했는지 그 과정이 더 중요하게 평가된다는 뜻이었습니다. 그리고 과제 요구사항 자체가 의도적으로 불완전하게 설계되어 있었습니다. 명시되지 않은 부분을 어떻게 판단하고 결정하는지를 보려는 것이었습니다.
그래서 3시간 중 절반 이상을 구현이 아니라 요구사항과 구현계획을 명확히 하고 깊이 탐구하는 데 썼습니다. 직접 구성한 워크플로우를 통해 요구사항 갭 분석을 먼저 돌렸습니다. 기획서에서 명시된 것, 암묵적으로 가정해야 하는 것, 직접 결정해야 하는 것을 구분하고 각 결정에 대한 근거를 문서로 남겼습니다.

정리하면

과제에서 AI 활용 비중이 코드 품질보다 높다고 명시되어 있었는데, 실제로 임하면서 그 의미를 체감했습니다. 단순히 구현을 해내는 것보다, AI와 협업하는 과정 자체를 얼마나 주도적으로 이끌었는지가 중요했다고 생각합니다. 개인적으로는 에이전트에게 바로 작업을 넘기기보다 요구사항 분석에 먼저 충분히 시간을 쓰고, 에이전트가 어떤 결정을 내리고 있는지 이해하면서 진행하는 방식이 도움이 됐습니다.