[Musinsa] 무신사 AI Rookies 공채 합격 후기

오늘 온 입사 안내 메일

 

 

무신사 AI Rookies 공채에 합격하여 합격 후기글을 간단하게 작성해보려고 합니다.

채용 여정이 꽤 빠르게 약 한 달 반? 정도만에 끝나서 사실 실감이 잘 안나기도 합니다. 나중에 비슷한 채용 과정이 있을 때 이 후기가 도움이 됐으면 좋겠습니다.

 

---

 

채용 여정

 

1차 코딩 테스트

 

1차 코딩 테스트는 크게 어렵지 않았습니다. 기본적인 코딩 구현 능력을 시험해보는 것 같았습니다. 플랫폼은 구름쪽이었고, 구름 플랫폼 특성 상 입출력을 직접 받아야하는 BOJ 형식이기 때문에, 입출력이나 파싱을 조심해야겠다는 생각이 먼저 들었습니다.

그리고 시험 안내 메일을 읽었을 때도, 조건이 많은 구현이 나올 것 같은 느낌이 들어서… 조건들을 문자열로 주고, 문자열 파싱이나 Map(dict)을 사용한 문제가 나올 것 같았습니다.

 

원래 코딩 테스트 언어를 C++, Java, Python, Kotlin(코틀린은 아주 일부 쉬운 문제만 제출해봤네요) 으로 문제에 맞춰서 선택하는 편입니다. 이번에는 입출력과 구현, 문자열 처리까지 깔끔하고 쉽게 짜기에 Python이 제일 나을 것 같았습니다. 별다른 준비는 안하고, 그냥 구현 문제를 직전에 한~두개 풀고 들어갔던 것 같습니다.

 

문제는 총 2개이고 1시간 구현 타임어택이었습니다. (문제는 아래에서 확인 가능)

https://github.com/musinsatech/2026-musinsa-rookie/tree/main/1%EC%B0%A8%20%EB%AC%B8%EC%A0%9C

2026-musinsa-rookie/1차 문제 at main · musinsatech/2026-musinsa-rookie

 

 

두 문제 모두 문자열 파싱 + Map에 정확한 정보 매핑 + 조건 여러 경우를 나눠서 깔끔하게 처리하는 문제였습니다.

• 문자열 파싱 잘 해주고 여러 info를 Map(저는 파이썬이라 dictionary)에 잘 매핑해서 넣으면 됩니다.
• 조건 여러 개인 경우를 구분해서 구현해주면 됩니다. 디폴트 응답값 부터, 순서대로 조건문에 걸리도록 분기를 잘 짜면 됐던 것 같습니다.
• 다만, 두 번째 문제가 조건 처리(API 응답 구분 처리) 4개가 있었어서 구현이 빠른 편이 아니라면 시간이 모자랐을 수 있겠습니다.

 

---

 

2차 코딩테스트

 

AI Coding Agent를 전체 시험 인원에게 제공하는 새로운 코딩 테스트 방식이었습니다.

사실, 이 과정이 궁금해서 지원해본 것도 있습니다. 어떤 문제가 나오고, 어떻게 채점할까? 순수한 호기심이 앞섰던 과정이었습니다. 자세히 이야기 드리고 싶지만, 너무 내용이 길어질 것 같아 핵심만 정리했습니다.

 

 

사전 준비

 

• AI 구현 문제가 나온다는 소식을 듣고, 3시간 이라면 적당한 웹 서비스 구현이 제일 그럴듯하다고 생각했습니다.
• 그래서 프롬프트도 웹 서비스 구현 쪽으로 준비했습니다. (만약 다른게 나오면 완전 임기응변으로 대처한다는 마인드)
• AI Agent는 제가 기존에 결제해서 사용하던 Codex 5.2 ver를 사용했습니다.
  • 사실 시험 당시에 5.3 version이 나온걸로 아는데 제가 업데이트를 미리 안해놔서 그냥(?) 5.2로 했습니다…?
  • 제 개인 노트북은 윈도우라 wsl2 + IntelliJ + Codex CLI 환경을 사용했습니다.
  • wsl2가 반응성이 느려서 살짝 아쉬운건 있었습니다. (회사가면 Mac 사랑꾼 될거에요 ㅇㅅㅇ)
  • 무슨 자신감인진 몰라도… gpt pro 요금제만으로 Claude Max 결제한 친구들 이길 수 있다는 마인드였던 것 같습니다. (codex는 토큰 가성비가 대단하기 때문이죠)
• 프롬프트 & 컨텍스트 엔지니어링 능력을 볼 것 같아서 디테일하게 준비 했습니다.
  • 사전 설계 및 세팅 프롬프트 (백엔드 + 프론트 둘 다 나올 것 같아서 둘 다 준비를 했습니다. 결과적으로 백엔드 세팅과 프롬프트만 사용했습니다.)
  • 병렬 세션 오케스트레이션을 위한 프롬프트 (오케스트레이터 세션과 병렬 세션에 작업을 쪼갤 때 필요한 지시 프롬프트, 세팅 등)
  • 새로운 문제를 마주쳤을 때, 문제를 해석하고 파헤치는 과정이 중요할 것 같아서 설계 쪽 프롬프트를 꼼꼼히 준비했습니다. (e.g. 도메인 해체 분석, Usecase 쪼개기, 제약 조건 Clarification, Decision Making을 위한 주요 쟁점 정의 문서, API 명세서 틀 등등)

 

 

시험 중 ~ing

 

https://github.com/musinsatech/2026-musinsa-rookie/blob/main/PROBLEM.md

2026-musinsa-rookie/PROBLEM.md at main · musinsatech/2026-musinsa-rookie

 

 

• 요구사항을 보고 서버 구현인 것을 파악하고 나서 → 제가 가장 많이 개발했던 Java + Spring Boot + Docker-compose(MySQL container) 환경 세팅하여 진행했습니다.

 

• 수강 신청 동시성 제어
  • 문제 요구사항을 읽다 보면, “수강 신청”이 핵심 파트라는걸 알 수 있습니다. (물론 수강 취소에서도 동일한 제어 필요)
  • 수강 신청 안에는 아래와 같이 학생에 대한 조건 Validation이 들어가면서, 동시에 신청 인원에 대한 capacity 동시성 제어까지 되어야하기 때문입니다.
  • 학생에 대한 validation
    • 조건 1. 한 학생의 최대 학점은 18학점으로, 절대 18학점 넘어서 수강 신청 되어선 안된다.
    • 조건 2. 한 학생이 중복 수강 신청하는 것은 불가능하다. (같은 강의 중복 신청)
    • 조건 3. 한 학생이 시간이 겹치는 강의를 신청하는 것은 불가능하다. (시간 겹치는지 validation 필요)
  • 강의에 대한 처리
    • 조건 4. 아무리 요청이 몰려도, 한 강의에 대해 정해진 인원 수를 절대 넘어선 안된다. (capacity 제한 철저히)
• 사실 위 조건을 모두 지킬려면 Transaction이 꽤 복잡해집니다.

 

 

• 여러 개의 Validation 로직 안에서, 락을 어떻게 잡느냐도 꽤 중요한 문제였습니다.
  • 위 모든 조건을 안전하게 처리하기 위해서 락을 두 번 잡는다면 순서는? (학생과 강의에 대한 락 순서)
  • 락을 명시적으로 두 번 잡는다면, 혹시 락의 범위를 줄일수도 있을까?
    • 특히 강의는 동시에 여러 명이 락을 잡으려고 시도하는 경쟁이 클 텐데, 그걸 어떻게 최소화하지?
    • 여기서 강의 capacity 처리에 대해, 강의 락 범위를 최소한으로 줄이려는 시도 or 생각이 들면 성능까지 챙길 수 있습니다.
  • 근데, 꼭 명시적으로 비관적 락을 두 번 잡아야할까? 락 순서는? 데드락은?
    • 다른 로직에서 락 잡는 로직이 있다면(수강 취소나 다른 로직 확장 시) 데드락 위험도도 알아야합니다.
  • 저는 결론적으로, 학생에 대한 validation 처리가 중요하기 때문에, 먼저 학생 중심의 비관적 락을 잡고 / 강의 수강 인원 capacity는 조건부 원자적 update 문으로 로직을 마무리하여, 강의에 대한 레코드 락 잡는 시간을 최소화하는 방향으로 진행했습니다.
  • 이는 강의 레코드에 대해 update를 시도할 때 인원에 대한 조건절 체크를 원자적으로 처리하여 아주 짧은 시간 동안만 레코드 락을 잡아 강의에 대한 요청을 직렬화합니다.
  • 즉, 가장 짧게 락을 잡아 capacity의 정합성을 보장할 수 있는 방법입니다.
  • 실제로 무지성 비관적 락 두 번 (Student → Course)를 select for update 문으로 연속으로 잡는 로직보다 훨씬 지연이 적고 성능에 뛰어납니다 (경쟁이 심화될수록 p95, p99 수치 차이가 커집니다)

 

 

그림을 누르면 확대됩니당

 

 

• 위 로직과 동시에, validation을 더 안전하고 빠르고 효과적으로 하기 위해서 도메인을 더 풍부하게 만들었습니다.
  • 도메인 규칙을 코드로 보장하여 더 안전하게 + DB 도메인 무결성까지 챙기고자 했습니다.
  • 특히 수강 신청 시, 시간이 겹치면 안되기 때문에 시간표를 담당하는 TimeSlot 도메인을 별도로 만들었습니다.
  • 이 TimeSlot 도메인 안에는 요일, 교시, 시간 등 주요 정보가 담겨있고, Course 도메인과 TimeSlot 사이의 중간 테이블을 만들었습니다.
  • 또한, StudentScheduleSlot 이라는, StudentId와 TimeSlotId를 함께 들고있는 도메인을 만들고, 유니크 제약 조건을 걸어 시간표 겹침 문제를 DB 유니크 인덱스의 무결성으로 보장하게끔 만들었습니다.
    • 이는, 시간표 겹침을 허용하지 않는 도메인 규칙을 DB 수준에서도 보장하기 위한 것으로, 안정성을 더한 설계입니다.
    • 이렇게 설계하면, 각 학생 별로 특정 교시(e.g. 월요일 2교시, 목요일 1교시 등)에 대해 값을 가지고 있는지 아닌지 여부를 깔끔하게 판단할 수 있습니다.
    • 또한, 단순히 시간표를 숫자 비교나 문자열 파싱하여 비교하는 위험한 로직에 기대지 않을 수 있습니다.
    • 파싱은 언제든지 에러가 날 수 있습니다. 입출력에 대한 보완도 까다로워지고요... 도메인 규칙화하는게 더 안전하다고 판단했습니다.
    • 물론, 유니크 인덱스 자체가 별도의 인덱스 관리 비용이 들고, 과하지 않나? 싶을 수 있지만 저의 판단 우선 순위는 안전한 수강 신청 구현 및 풍부한 도메인 표현력이었기에 일관된 설계 기준을 가지고 진행했습니다.

 

 

• 인증/인가나 캐싱 등 다른 기술 추가는 왜 안했는지? (이건 면접 때 질문인데 제 판단을 아래와 같이 답변했습니다)
  • 인증/인가는 우선 요구 사항에 없었고, 토큰 방식이든 세션 방식이든 제대로 구현하려면 품이 많이 드는 작업입니다.
    • 인증/인가 자체를 별도의 도메인으로 보고, validation, reissue, expiry 작업을 모두 꼼꼼하게 만들어야 하기 때문에 이걸 할 시간에 시험에서 요구했던 본질에 더 집중하자고 판단했습니다.
    • 또한, 자동 채점할 때 사전 회원 가입 - 로그인 - 인증 까지 이어지는 과정이 까다로울 것 같다고 판단했습니다.
  • 캐싱은?
    • 정적인 정보를 캐싱해두면 정말 좋겠지만 (e.g. 교수님 목록)
    • 수강 신청 상황을 생각해보면, update되는 정보가 꽤 많습니다. (e.g. 학생의 현재 학점, 학생의 현재 수강 강의 목록, 강의의 현재 수강 인원/잔여 인원 등)
    • 즉, 수강 신청이 이루어지는 동안은 캐시와 DB 사이의 일관성을 지키기가 쉽지 않습니다.
      • 일관성을 지키고자하면, DB 갱신과 함께 캐시 갱신까지 일어나야하므로 시간이 더 소요되고,
      • 일관성을 살짝 포기하고 주기적으로/비동기적으로 update 한다면 1분 1초가 급박한 수강 신청 상황에서의 의미가 별로 없을 것 같다고 판단하여 과감하게 고려조차 하지 않았습니다.

 

 

시험 마무리 및 아쉬운 점

 

• 코드 품질은 크게 신경쓰지 않고, 주어진 조건을 구현하는데 집중하라는 요구사항을 충실하게 따랐습니다.
• 그러나 코드 품질에 신경을 못쓴게 계속 아쉬워서 나중에 따로 개인적으로 리팩토링 했습니다. (코드 개선하면서 겸사겸사 면접 준비도 하고..)
• 원래는 개발 할 때 병렬 세션을 좀 더 적극적으로 써보고 싶었는데, 중간에 병렬 세션 세팅하는데 드는 오버헤드가 아깝다고 생각하여 최종적으로 세션은 2개만 사용했습니다.
• 오케스트레이션 세션은 codex-high, 쪼개서 구현하는 세션은 codex-medium으로 두었습니다.
  • 나중에 회사가면 Claude 지원 받을 수 있으니… 얼른 Claude Agent Team으로 모든 세팅을 옮기고 싶습니다.

 

 

 

---

 

3차 면접

 

 

면접 내용을 복기한 자료가 있지만, 사실 면접 과정이 면접관과 지원자 사이의 상호 작용하는 과정이라고 생각하고, 아직 회사의 방침을 몰라서 간단하게 적겠습니다.

(추후 자세하게 적을 기회가 있다면 그 때 추가글을 쓰려고 합니다.)

 

 

우선 분위기가 좋았고, 친절하게 대해주셔서 하나도 떨지 않고 편안하게 진행할 수 있었습니다.

면접관님 스타일이 차분하셨고 MBTI I와 같은 느낌을 받아서, 어떻게 하면 이 면접을 즐겁고 편안하게 대화하는 (긍정적인 상호작용을) 할 수 있을지 잠시 고민했습니다.

저는 진짜 “대화” 처럼 이어가면 좋겠다고 생각했기에… 좀 더 활기차고 적극적으로 대답했던 것 같습니다.

예를 들어, “혹시 시간이 괜찮다면 이 부분에 대해서 좀 더 상세하게 말씀드려도 될까요? ㅎㅎ”

아니면 “혹시 기술 선택의 이유를 덧붙여도 괜찮을까요? ㅎㅎ” 이런식으로 긴장 안하고 능동적으로 + 기술 인터뷰 자체를 흥미로워하는 스탠스로 이어갔던 것 같습니다.

 

 

내용은 거의 기술 질문(2차 코딩 테스트)이 대부분이었습니다. 제가 수강 신청 동시성 제어를 왜 이렇게 구현했는지, 전체 로직부터 내부를 해체 분석하며 세세한 선택의 이유를 물어보셨습니다.

특히, 제가 트랜잭션 내부를 디테일하게 설명해야하는 상황이 있었는데, 말로 하면 장황하고 길어질 것 같아 화이트보드를 사용해도 되는지 정중하게 묻고, 직접 보드에 로직 시퀀스를 그리면서 설명했던 것 같습니다.

사실 이전 면접(카카오 모 계열사의 수시채용)에서 화이트보드 앞에서 한 30분 서있었던 경험이 있어서 그 때를 회상하면서 열심히 해보았습니다….ㅠㅠ

 

 

또, DB쪽 질문도 많이 들어왔습니다.

• DB 선택의 트레이드 오프
• DB 격리 수준 설명과 비교
• DB 클러스터 운영 같이 데이터베이스와 관련된 질문도 많이 받았습니다.
• 사용자가 많아질 경우 Scale-out 같은 일반적인 운영 상황을 가정한 질문 답변이 오갔습니다.

 

 

AI 활용 방식에 대한 질문도 2~3개 나왔습니다.

• 2차 코딩 테스트 때 썼던 방식 + 평소에 사용하는 방식 설명
• 병렬 세션 오케스트레이션에 대한 설명?
• AI가 틀린 답을 제공하거나, AI가 제공하는 방식이 적절하지 못한 경우 어떻게 대처하고 confirm하는지?

 

 

면접 후기 + 개인적으로 아쉬운 점을 남겨보자면

• 하고 싶은 말은 다 한 것 같아서 웃으면서 면접장을 나온 것 같습니다.
• 다만, 제 인터뷰 발화 습관을 좀 고치면 더 좋겠다는 생각(셀프 피드백)이 들었습니다. 답변을 두괄식으로 하는게 더 깔끔하고 좋았을 것 같습니다.
• 뭔가 사고 과정이라고 해야할까요..? 머릿속에 추론 chain이 엄청 빠르게 이어지는데, 그 사고 과정을 그대로 말로 옮기는 스타일이라서 장황하고 길어지는 것 같습니다.
• 중간에 스스로 알아차리고, 다듬어볼려고 했는데도 확실히 쉽지 않았습니다. 핵심 내용 위주로 발화를 정리하는 연습이 필요할 것 같습니다.
• 제가 말솜씨는 좀 부족했지만… 기술 내용을 잘 말해서 합격이 된 것 같네요… 다행입니다…. 회사 가서 구두 보고할 때 이러지 않도록 더 신경써야할 것 같습니다.

 

 

---

 

After…

 

 

앞으로에 대한 짧은 생각

https://www.linkedin.com/posts/tao-kim-4286543a_to-musinsa-rookie-notion-activity-7434778035104559104-rhVG?utm_source=share&utm_medium=member_desktop&rcm=ACoAAEJ5dEoBZiMgRPqak-DXytTqOHKTdgFU6eA

To. MUSINSA ROOKIE | Notion | Tao Kim

 

 

이번 채용을 주도적으로 이끌어주신 Tao Kim 님의 링크드인 글을 살펴보면, 앞으로 어떤 복잡한 도메인 문제를 풀어나가야하는지 간략하게 볼 수 있습니다.

 

 

우리 개발자들은 AI로 구현 속도가 정말 빨라졌음을 이미 체감했고, 앞으로 산재한 도메인 문제를 AI를 잘 활용해서 풀어나가야 합니다.

이번 채용 평가에서 최우선 순위로 둔 역량도 “명확하지 않은 요구사항을 스스로 명확하게 만들어서 도메인-로직-API로 구현하는 것”이었던 만큼, 회사에서 마주칠 여러 가지 복잡한 문제 상황들이 기대되는 것 같습니다.

물론 경험이 많이 쌓인 분들처럼, 처음부터 능숙하게 문제를 풀긴 어렵겠지만, 최대한 여러 상황을 고민하고 부딪혀보고 싶습니다.

 

 

아직도 저는 이전 회사의 도메인 문제를 붙들고 잠들지 못해 뜬 눈으로 지새운 날이 드문드문 생각나곤 합니다. 누가 알아주지도 않지만, 혼자 고민하는 시간은 꽤 값진 시간이었던 것 같습니다. 이 날을 계기로 일개 인턴이 R&D의 전체 방향성을 바꿔버리는 변화가 일어났었습니다. 그리고, 이런 밤을 또 보낼 수 있는 기회가 생긴 것이 기쁩니다.

 

 

3월 16일부터 온보딩과 새로운 조직 생활이 시작됩니다. 온보딩에서 어떤 활동을 할 지, 그리고 어떤 부서로 배치될지도 궁금합니다. 새로운 분들과 친해지려면 뭐해야할지 (우선 억텐을 준비해야겠다…) 동기분들과 빨리 친해져서 회사 생활이나 개발에 대한 이런저런 이야기를 나눌 수 있으면 좋겠습니다.

 

 

그리고 요즘 무신사랑 29cm를 들락날락 거리면서 친구의 코디에 맞춰 결제 버튼을 누르고 있습니다. 얼른 품위유지비도 받고싶어요 . . .>.<

 

 

긴 글 읽어주셔서 감사합니다. 도움이 되었으면 좋겠습니다...