[MUSINSA techblog] The Machine: AI가 AI 활용 코드를 평가하다

 

이 글은 무신사가 AI 네이티브 채용을 실제 운영 수준으로 끌어올리기 위해, 지원자가 작성한 코드를 사람이 감으로 보는 대신 AI가 체계적으로 평가하는 시스템을 만든 사례를 설명한다. 핵심은 단순히 “AI를 활용했다”는 사실을 보는 것이 아니라, AI를 어떤 방식으로 활용했고 그 결과물이 얼마나 실무적으로 타당한지를 평가하는 데 있다.

글의 배경과 문제의식
무신사의 문제의식은 명확하다. 이제 개발자는 코드를 직접 많이 작성하는 사람이라기보다, AI 도구를 적절히 지휘해 문제를 해결하는 사람에 가깝다. 이런 환경에서는 기존 면접처럼 알고리즘을 잘 푸는지, 문법을 얼마나 아는지보다 AI와의 협업 능력, 요구사항을 분해하는 능력, 결과물을 검증하는 능력이 더 중요해진다. 그래서 이 글은 채용을 위한 과제 자체를 AI 시대에 맞게 다시 설계한 과정에 초점을 둔다.

기존 과제 평가는 사람이 일일이 코드를 읽고 판단해야 하므로 시간이 많이 들고, 평가자마다 기준이 달라질 수 있다. 특히 AI 활용 과제는 단순히 결과 코드만 봐서는 지원자가 어떤 프롬프트를 썼는지, 중간에 어떤 판단을 했는지, AI의 오류를 어떻게 수정했는지를 파악하기 어렵다. 무신사는 이 문제를 해결하기 위해, 산출물의 최종 코드만 보는 방식이 아니라 과정 전체를 구조화해 평가하려 한다.

평가 대상의 확장
이 글에서 중요한 점은 평가 대상을 코드 하나로 한정하지 않는다는 것이다. 무신사는 지원자가 제출한 코드, 설명 문서, 프롬프트, 실행 결과를 함께 본다. 이는 AI 활용 과제에서는 최종 결과보다도 문제 정의와 지시 설계 능력이 중요하기 때문이다. 같은 기능을 구현하더라도, 어떤 프롬프트를 통해 AI를 유도했는지, 그 결과를 어떻게 검토하고 수정했는지에 따라 실제 역량 차이가 크게 드러난다.

즉, AI가 코드를 생성했더라도 그 코드가 바로 정답이 되는 것은 아니다. 지원자가 생성된 코드를 검토하며 논리적 오류를 찾아내고, 품질을 개선하고, 요구사항에 맞게 다듬는 과정이 있어야 한다. 무신사의 평가 체계는 바로 이 지점을 포착하려는 방식이다. 따라서 이 글은 “AI를 써도 된다” 수준이 아니라, AI를 잘 쓰는 사람을 어떻게 구별할 것인가에 대한 실질적인 설계 문서에 가깝다.

자동 평가 시스템의 구조
글의 기술적 핵심은 AI가 또 다른 AI 활용 코드를 평가하는 구조이다. 즉, AI가 생성한 코드를 사람이 직접 채점하는 대신, 평가용 AI가 일정한 기준에 따라 분석하고 점수를 매긴다. 이를 위해 무신사는 평가 절차를 표준화하고, 평가 기준을 세분화해 자동화 가능한 영역을 넓혔다. 이 구조는 대량의 지원자를 보다 일관되게 평가할 수 있게 해준다.

이 평가 시스템은 보통 다음과 같은 흐름으로 이해할 수 있다. 먼저 지원자의 제출물을 수집하고, 그 안에서 코드와 문서, 메타정보를 분리한다. 다음으로 평가 기준에 맞게 각 항목을 분석한다. 예를 들어 기능 충족 여부, 코드 구조, 가독성, 예외 처리, 테스트 가능성, AI 사용 흔적의 적절성 같은 요소를 나눠 본다. 마지막으로 이 항목들을 종합해 총점을 매기고, 필요하면 코멘트까지 생성한다. 중요한 점은 이 모든 과정이 사람이 하던 판단을 최대한 구조화했다는 것이다.

이 방식의 장점은 평가 일관성이다. 사람은 피로도나 선입견, 선호하는 스타일에 따라 판단이 달라질 수 있다. 반면 잘 설계된 자동 평가는 같은 기준을 반복적으로 적용할 수 있다. 또한 평가 속도도 빨라진다. 지원자 수가 많아질수록 사람 손으로만 평가하기는 어렵기 때문에, 자동화는 채용 규모를 감당하기 위한 현실적인 해법이 된다.

8개 평가 영역
글에서 눈에 띄는 부분은 코드를 단순히 “좋다, 나쁘다”로 보지 않고, 8개 영역으로 나누어 평가한다는 점이다. 이 방식은 AI 활용 과제의 성격상 매우 중요하다. 한 부분이 잘되어 있다고 해서 전체가 좋은 것은 아니고, 반대로 코드 스타일이 조금 거칠더라도 문제 해결 핵심이 뛰어날 수 있기 때문이다. 따라서 다면적인 평가 체계가 필요하다.

8개 영역은 글의 맥락상 대체로 다음과 같은 성격을 가진다. 첫째, 요구사항을 제대로 이해했는지 본다. 둘째, 기능이 실제로 동작하는지 본다. 셋째, 코드 구조와 설계가 적절한지 본다. 넷째, 유지보수성과 가독성이 괜찮은지 본다. 다섯째, 오류 처리와 예외 대응이 충분한지 본다. 여섯째, 테스트나 검증이 들어갔는지 본다. 일곱째, AI 활용 방식이 적절한지 본다. 여덟째, 최종 결과가 실무적으로 쓸 수 있는 수준인지 본다.

이런 분해는 평가를 더 공정하게 만든다. 예를 들어 기능은 완성됐지만 테스트가 부족한 경우와, 테스트는 잘했지만 설계가 부실한 경우를 구분할 수 있다. 즉, 총점만 보는 것이 아니라 어떤 역량이 강하고 약한지 세분화해 파악할 수 있다. 이는 채용 이후에도 어떤 지원자가 어떤 역할에 적합한지 판단하는 데 도움이 된다.

프롬프트와 사고 과정의 중요성
이 글의 또 다른 핵심은 프롬프트를 단순한 입력 문장이 아니라 역량의 일부로 본다는 점이다. AI 활용 시대에는 질문을 잘 만드는 능력이 곧 문제 해결 능력이다. 지원자가 어떤 요구사항을 어떤 순서로 AI에게 전달했는지, AI가 잘못 이해한 부분을 어떻게 재지시했는지, 결과물을 어떤 기준으로 검증했는지가 실무 역량을 드러낸다.

무신사는 따라서 결과 코드만 보지 않고, 프롬프트의 품질과 반복 수정 과정을 함께 본다. 좋은 프롬프트는 막연한 지시가 아니라, 목표를 분명히 하고 제약 조건을 명확히 하며, 기대하는 출력 형식을 구체적으로 제시한다. 또한 중간 결과를 검토하며 점진적으로 개선해야 한다. 이런 과정이 잘 드러나면, 지원자는 단순히 AI가 준 답을 복붙한 사람이 아니라 AI를 도구로 다룰 줄 아는 사람으로 평가받게 된다.

실무적 의미
이 글이 중요한 이유는 채용에만 국한되지 않기 때문이다. 이 방식은 앞으로 개발 조직이 어떤 인재를 필요로 하는지 보여준다. 즉, 미래의 개발자는 모든 코드를 손으로 직접 쓰는 사람이 아니라, AI를 활용해 빠르게 시도하고, 결과를 검증하고, 필요한 부분만 정교하게 다듬는 사람이다. 무신사는 그 기준을 채용 과정에 먼저 반영한 것이다.

또한 이 사례는 조직 내부의 평가 문화에도 영향을 준다. AI가 평가를 돕는 구조가 만들어지면, 사람은 더 높은 수준의 판단에 집중할 수 있다. 예를 들어 단순 문법 오류나 반복적인 품질 문제는 자동화하고, 사람은 지원자의 설계 사고, 협업 능력, 문제 접근 방식 같은 더 본질적인 요소를 본다. 이 글은 바로 그 전환을 보여주는 사례이다.

정리
결국 이 글은 AI를 사용하는 개발자를 어떻게 평가할 것인가에 대한 답을 제시한다. 무신사는 코드 결과물만 보는 전통적 방식에서 벗어나, 코드·문서·프롬프트·검증 과정까지 함께 분석하는 자동 평가 체계를 만들었다. 그리고 이를 8개 영역으로 나누어 세분화함으로써, AI 시대에 맞는 인재 선별 방식을 구체화했다.

요약하면, 이 글의 메시지는 분명하다. 앞으로 중요한 것은 코드를 직접 많이 치는 능력이 아니라, AI를 정확히 지시하고 결과를 비판적으로 검증하는 능력이다. 무신사는 이 변화를 채용 시스템에 먼저 반영했고, 그 구현 방식이 바로 “AI가 AI 활용 코드를 평가하는” 시스템이다.

 

 

 

 

[출처]

https://techblog.musinsa.com/the-machine-ai%EA%B0%80-ai-%ED%99%9C%EC%9A%A9-%EC%BD%94%EB%93%9C%EB%A5%BC-%ED%8F%89%EA%B0%80%ED%95%98%EB%8B%A4-c2345aab5b7a