AX 인재전쟁 본선: 세 시간 안에 문제를 좁히고 증명하기

본선에서 무신사가 낸 문제는 “패션·뷰티 트렌드를 남들보다 먼저 포착해 시장을 주도할 방법”을 설계하는 것이었다. 떠오르는 트렌드를 어떻게 정의할지부터 어떤 신호와 데이터를 확보해 어떤 행동으로 이을지까지 참가자가 직접 정해야 했다. 데이터는 따로 주어지지 않았고, 핵심 메커니즘 하나는 실제로 작동시켜야 했다.

문제를 풀고 제출하기까지 주어진 시간은 세 시간이었다. 최종 결과는 무신사 트랙 1등이었다. 이 글에서는 순위보다 그 세 시간 동안 무엇을 문제로 삼고, 어떤 주장을 버렸으며, 어디까지 증명했는지를 시간 순서대로 정리한다.

문제: 미래 트렌드를 남들보다 먼저 포착하라

선택: 예측 대신 MD의 작은 검증 기회 배정으로 좁혔다

결과: 같은 규칙으로 행동·보류·미배정을 가르는 App을 만들었고, 무신사 트랙 1등을 했다

이 글이 남기고 싶은 것은 “세 시간 만에 App을 만든 방법”이 아니라 열린 문제를 검증 가능한 결정으로 줄이는 방법, AI가 만든 첫 분석을 의심하는 방법, 성공 사례가 아니라 반례로 데모를 설계하는 방법이다.

문제를 받기 전, 답이 아니라 작업 환경을 준비했다

본선 문제는 당일 공개됐다. 어떤 문제가 나올지 예상해 솔루션을 미리 만들 수는 없었지만, 문제를 보고 나서 생각과 구현을 시작하기에는 세 시간이 너무 짧았다. 그래서 미리 준비한 것은 답이 아니라 반복해서 쓸 작업 방식이었다.

먼저 무신사가 어떤 회사인지 파악했다. 상품을 모아 파는 플랫폼으로만 보지 않고, 성장할 브랜드와 변화를 먼저 찾아내 키우는 사업이라는 관점에서 조직·재무·브랜드 전략과 패션 플랫폼 구조를 조사했다.

이 단계에서 솔루션을 상상하지는 않았다. 소비자는 상품과 브랜드 중 무엇을 찾는지, 플랫폼은 왜 브랜드 단위로 탐색을 설계하는지, 브랜드 발견과 구매는 어디에서 끊기는지, 양면 시장의 고객은 누구인지 같은 질문을 하나씩 문서로 만들었다. 기능을 미리 정해두기보다, 당일 문제를 해석할 관점을 쌓아두는 작업이었다.

문제 공개 직전에는 특정 가설에 맞추지 않고 공식 발표, DART, 뉴스, 인터뷰, 채용과 기술 자료를 동시에 모았다. 약 38분 동안 21개 파일과 형식을 통일한 출처 카드 241건을 만들고, 중복을 걸러낸 URL 283개의 접근 상태를 확인했다. 이 자료는 정답이 아니라 어떤 문제가 나와도 사실 관계를 빠르게 찾아볼 수 있는 바탕이었다.

실제 기록은 더 구체적이다. 37분 36초 동안 링크 283개를 정상 271건, 접근 차단 9건, 의도된 404 2건, 타임아웃 1건으로 갈랐고, 독립 QA에서 치명·중요 오류 0건으로 마감했다. 빠른 조사는 “많이 찾기”가 아니라 쓸 수 있는 근거와 쓸 수 없는 링크를 함께 분류하는 일이었다.

코드 쪽에서는 입력 형식을 모르는 상태에서도 파일 목록, 스키마와 품질을 확인할 수 있는 Python 분석 워크벤치와 Electron App 뼈대를 준비했다. 워크벤치는 합성 데이터 검증과 67개 테스트를 통과한 상태였다. 현장에서는 문제에 맞는 규칙과 데이터만 갈아 끼우면 되도록 했다.

작업 순서도 미리 정했다. 문제 의도와 현장 질의응답을 먼저 확인하고, 가설과 외부 근거를 견준 뒤 하나만 고른다. 그다음 해결책을 만들고 제출한다. 준비한 도구가 있다는 이유로 구현부터 손대지 않기 위한 제약이었다.

09:36–10:18, 구현보다 문제 정의에 시간을 썼다

현장 운영상 13시 이후에는 제출물을 고칠 수 없었다. 서둘러 먼저 내는 선택도 가능했지만, 나는 문제 정의와 제출 품질에 시간을 쓰는 쪽을 택했다. 기능을 넓게 벌이는 대신, 한 가지 결정의 경계 사례까지 파고들기로 했다.

문제 공개 직후 질의응답에서 가장 먼저 확인한 것은 결과물을 실제로 쓸 사람과 그 사람이 내릴 결정이었다. 무신사 측 답변에 따르면 주 사용자는 MD와 운영·사업 담당자였고, 이들은 트렌드를 발견한 뒤 구매와 생산 시한을 결정한다고 했다.

심사의 핵심도 큰 시스템이 아니라 문제를 어떻게 정의했는지, 제한된 시간에 자신의 직관을 뒷받침할 근거를 어떻게 보여주는지에 있었다. AI에 모든 판단을 넘기면 오히려 가장 낮은 평가를 받을 수 있다는 답도 들었다.

이 답변을 기준으로 사용자를 구매·생산 시한 전 주간 소싱 회의에 참여하는 MD로 좁혔다.

이 문장을 그날의 기준 문서에 적고 이후 모든 세션이 따를 유일한 기준으로 삼았다. 누구를 위한 어떤 결정인지 설명하지 못하는 기능은 만들지 않았고, 개념 증명도 한 시간 안에 핵심 메커니즘을 보여줄 범위로 제한했다.

10:18–11:00, 트렌드 예측을 포기했다

문제를 글자 그대로 받으면 “무엇이 유행할지 맞히는 시스템”을 만들기 쉽다. 하지만 세 시간 안에 미래 예측의 정확도를 증명할 방법은 없다. 검색량이 늘었다는 이유로 앞으로의 판매를 말하거나, 공개 데이터만으로 매출과 재고 효과를 주장하는 것도 비약이었다.

그래서 질문을 바꿨다.

무엇이 유행할까?

구매와 생산을 확정하기 전에, 어떤 후보에 제한된 검증 슬롯을 배정할 가치가 있을까?

최종 행동도 대규모 매입이나 생산량 추천이 아니었다. 이미 입점한 상품으로 작은 큐레이션 노출 테스트를 한 건 해볼지 정하는 데까지만 범위를 뒀다. 예측이 맞았다고 선언하는 대신, 다음 정보를 얻기 위한 작은 실험에 자리를 내주는 문제로 바꾼 것이다.

떠오르는 트렌드는 관심이 한동안 이어지고 서로 다른 공개 신호가 같은 방향을 가리키면서도, 무신사 공개 검색면에는 아직 흔하지 않은 스타일 × 착용 맥락 후보로 정의했다.

10:18–11:23, 정의와 데이터 수집을 분리해 병렬로 진행했다

한 세션에서는 사용자의 결정과 트렌드를 실제로 판정할 정의를 다듬고, 다른 세션에서는 공개 데이터를 모았다.

모은 신호는 저마다 역할이 달랐다. 세 신호를 하나의 숫자로 합치지 않고, 각각 무엇을 말할 수 있고 무엇을 말할 수 없는지부터 못 박았다.

신호	본 것	보지 않은 것
NAVER DataLab	검색 관심의 시간 변화	절대 검색량
Google News RSS	기사량과 발행처 분포	독립적인 소비 수요
무신사 공개 검색면	한 시점의 공개 상품 수	내부 재고·판매량

YouTube와 Pinterest 자료도 후보를 찾는 과정에서 모았지만, 모은 것을 전부 최종 판단에 밀어 넣지는 않았다. 어떤 기준으로 비교하는지와 데이터 품질을 설명할 수 있는 신호만 남겼다.

탐색 단계에서는 NAVER 701포인트, YouTube 344행, Google News 488행, 무신사 공개 상품 카드 1,615행과 Pinterest 성장률 39개를 모았다. 그러나 최종 정책에 넣은 것은 기준과 한계를 설명할 수 있는 세 신호뿐이었다. 여기서 갈린 것은 수집량이 아니라, 많이 모아둔 뒤에도 버릴 수 있는가였다.

처음 모은 결과도 그대로 쓰지 않았다. 따로 돌린 감사 세션에서 세 가지 문제가 드러났다.

첫째, NAVER 그래프 JSON에는 보이지 않던 값이 공식 XLSX에는 0으로 적혀 있었다. 화면에 안 보이는 것과 실제 0을 혼동할 수 있었다.

둘째, 띄어쓰기를 없애는 과정에서 서로 다른 동의어가 같은 값으로 정규화돼 중복됐다.

셋째, 카프리 팬츠 전체의 검색 관심과 데님 카프리 팬츠의 상품 수를 같은 단위인 것처럼 비교했다.

공식 XLSX를 기준 원천으로 삼아 다시 모았고, 검색 수요와 상품 공급은 서로 다른 쿼리 기준으로 갈랐다. 수집 실패와 실제 0도 다른 상태로 처리했다. AI가 만든 첫 결과를 다른 AI 세션에 반론과 감사의 시선으로 다시 보게 한 덕분에 찾은 오류였다.

핵심 오류를 찾아낸 것은 더 많은 데이터를 모은 세션이 아니라, 이미 끝났다고 생각한 결과를 깨뜨리라고 시킨 감사 세션이었다.

11:00–11:34, 결과를 보기 전에 판단 규칙을 잠갔다

여러 신호를 0점부터 100점까지 합산하는 종합 점수는 만들지 않았다. 검색 관심이 아무리 커도 이미 대중화된 스타일이라면 초기 검증 대상이 아니고, 기사량이 많아도 한 사건에 몰려 있다면 다른 높은 수치가 그 위험을 덮어선 안 된다고 봤다.

대신 여섯 개의 비보상형 게이트를 순서대로 통과시켰다.

1. 같은 조건으로 관측할 수 있는가
2. 관심이 한 번에 그치지 않고 이어졌는가
3. 검색과 콘텐츠 신호가 같은 방향인가
4. 한 제작자·사건·발행처에 지나치게 쏠려 있지 않은가
5. 무신사 공개 검색면에서 이미 대중화되지 않았는가
6. 작은 후속 검증으로 불확실성을 줄일 수 있는가

앞 게이트에서의 실패나 관측 불가를 뒤의 높은 값으로 메우지 않는다. 근거가 모자라거나 서로 어긋나면 안전한 기본 상태인 보류로 보낸다.

임계값은 무신사가 검증한 운영 정책이 아니었다. 이번 개념 증명을 돌리기 위해 정한 약속이었다. 원본 데이터의 분포를 확인한 뒤, 세 후보를 실제로 돌려보기 전에 정책 파일 musinsa-md-slot-v1-20260718에 적어뒀고, 결과를 보고 나서 대표 후보를 통과시키려고 고치지 않았다.

정책 파일에는 원칙을 말로만 적지 않고 실행에 쓰는 임계값까지 함께 잠갔다.

decision_policy:
  policy_id: musinsa-md-slot-v1-20260718
  thresholds:
    min_periods_per_source: 6
    min_rising_periods: 3
    min_agreeing_sources: 2
    max_contributor_share: 0.5
    max_saturation: 100
    required_metadata_fraction: 1.0
  reject_on_failure:
    - saturation

최종 상태는 세 가지로 고정했다.

• 검증 슬롯 배정: 지금 작은 실험으로 확인할 가치가 있음
• 보류: 근거가 부족하거나 충돌해 더 관찰해야 함
• 이번 사이클 미배정: 현재 근거에서는 검증 자원을 쓰지 않음

11:34–12:15, 같은 규칙으로 반례까지 실행했다

성공 사례 하나만 보여주면, 그 후보를 통과시키려고 규칙을 나중에 맞춰 만든 것은 아닌지 가려낼 수 없다. 그래서 대표 후보와 함께 두 가지 실패 시나리오를 같은 정책으로 돌렸다.

후보	결과	핵심 이유
데님 카프리 팬츠	검증 슬롯 배정	관심이 이어지고 공개 상품은 96개
포엣코어	보류	3월 정점 뒤 검색과 기사 신호가 함께 약해짐
발레코어	이번 사이클 미배정	공개 상품 852개로 포화 기준 100개 초과

데님 카프리 팬츠가 실제로 유행한다는 결론이 아니다. 지금의 공개 근거로는 작은 노출 테스트를 해볼 만큼의 정보 가치가 있다는 뜻이다.

검증 슬롯 배정은 “유행할 것이다”라는 예측이 아니다. 지금 적은 비용으로 더 알아볼 가치가 있다는 다음 행동이다.

포엣코어는 상품 수가 적은데도 관심이 이어졌는지와 교차 신호에서 걸렸다. 발레코어는 관심 신호가 남아 있어도 공개 상품 수 때문에 초기 기회가 아니라는 반례가 됐다. 같은 규칙이 서로 다른 이유로 행동과 보류, 미배정을 가른다는 점이 핵심이었다.

세 후보의 여섯 게이트마다 고유한 Evidence ID를 붙여 총 18개 근거를 남겼다. 입력과 정책의 SHA-256, 실행 기록과 산출물을 보존하고, 같은 입력과 정책으로 다시 돌렸을 때 결과가 일치하는지 확인했다.

App은 계산 결과를 예쁘게 보여주는 화면이 아니었다

Electron App인 MUSINSA Trend Gate는 세 화면으로 구성했다.

1. MD 의사결정에서 후보의 상태와 다음 행동을 본다.
2. 판단 근거에서 게이트별 수치, 이유, Evidence ID, 원출처와 반대 근거를 확인한다.
3. 실행 상태에서 입력·정책 파일 지문, 로그와 생성된 산출물을 확인한다.

App은 스스로 판단하지 않고 Python 엔진이 낸 산출물을 검증해 보여준다. Evidence ID가 빠지거나 겹치거나, 파일 지문과 정책이 맞지 않거나, 게이트 순서가 약속과 다르면 성공 결과를 띄우지 않는다.

현장에서는 심사자가 설치하자마자 반례까지 확인할 수 있도록 세 시나리오의 잠긴 산출물을 App에 넣어뒀다. 일반적인 제품이라면 입력을 내장하는 것은 좋지 않은 설계지만, 세 시간짜리 해커톤에서는 재현되는 데모가 더 중요하다고 보고 일부러 택한 절충이었다. 화면에도 이 값이 지금 이 기기에서 계산된 것처럼 보이지 않도록 저장된 검증 결과라고 적었다.

Python 없이 바로 열리는 이 스냅샷과 실제 재계산은 따로 뒀다. 내장 시나리오는 파일 크기, 해시, 경로 이탈과 심볼릭 링크를 검사한다. 같은 공개 데이터로 다시 계산할 때는 App에 넣어둔 macOS arm64 실행 파일을 따로 호출한다.

최종적으로 App 단위 테스트 24개, 판단 엔진 단위 테스트 72개, TypeScript 타입 검사, 프로덕션 빌드와 macOS arm64 패키징을 통과했다. 연구 데이터 36개 CSV·4,463행도 다시 검사해 오류와 경고가 없음을 확인했다. 자동 Electron E2E는 개발 환경의 내장 카탈로그 경로와 중복 텍스트 선택자 문제로 끝까지 돌지 못했다. 시연할 수 있다는 사실과 E2E가 통과했다는 주장은 다른 이야기이므로, 뒤엣것은 완료 목록에서 뺐다.

12:08–12:48, 기술 설명보다 막으려 한 오판을 앞세웠다

제출문에서는 프레임워크나 기능 목록보다 이 시스템이 막으려 한 오류를 먼저 설명했다.

• 한 번의 급등을 이어지는 관심으로 오해하는 일
• 한 발행처나 사건에 몰린 기사를 넓은 확산으로 읽는 일
• 이미 대중화된 스타일을 초기 기회로 고르는 일
• 빠진 값과 수집 실패를 0으로 처리하는 일
• 서로 다른 검색 범위를 같은 단위로 비교하는 일
• 결과를 본 뒤에 임계값을 바꾸는 일
• AI의 매끄러운 설명이 규칙의 결과를 덮어버리는 일

제품의 한계도 함께 적었다. 공개 데이터와 한 시점의 검색면만 썼기 때문에 미래 예측 정확도, 매출·재고 개선, 인과관계, 무신사 내부 업무 방식, 전 카테고리 적용 가능성은 증명하지 않았다. 어떤 브랜드와 실험할지 이어주는 단계도 구현하지 못했다.

15:44–16:39, 발표 환경에 맞춰 전달 방식을 바꿨다

도메인 챔피언 발표를 앞두고는 기능을 더 붙이지 않았다. 발표 전체를 2분 피치와 2분 App 시연으로 줄이고, 예상 질문 26개에 짧게 답할 수 있도록 준비했다.

현장 프로젝터가 어둡다는 것을 확인한 뒤에는 발표 자료를 고대비 테마로 바꾸고 기존 파일은 백업해뒀다. 재계산은 얼마나 걸릴지 알 수 없어 시연 중에 직접 누르지 않고, 바로 열리는 스냅샷과 실행 상태 화면으로 재현 근거를 보여주는 방식으로 바꿨다.

발표의 중심 문장은 이랬다.

이 시스템은 무엇이 뜰지 대신 맞혀주지 않는다. MD가 섣부른 확신 없이, 지금 확인할 가치가 있는 후보만 작게 시험해 보게 한다.

무신사 트랙 1등이 확인해준 것

결과는 무신사 트랙 1등이었다. 하지만 순위가 모든 기술적 선택이 옳았다는 뜻은 아니다. 이번 결과가 확인해준 것은, 세 시간 안에 가장 많은 기능을 만드는 전략보다 열린 문제를 한 사람의 한 가지 결정으로 좁히고 그 결정의 반례와 근거를 실행 가능한 형태로 보여주는 전략이 더 잘 전달됐다는 사실이다.

AI를 최종 판정에서 뺐다고 해서 AI를 적게 쓴 것은 아니다. 문제 탐색, 반론, 데이터 수집과 감사, 구현과 문서화에 AI를 폭넓게 썼다. 여러 세션과 보조 에이전트에 역할을 나눴고, 감사 세션에는 앞선 결론을 뒷받침하지 말고 깨뜨리라고 주문했다. 다만 결과를 바꿀 권한만은 잠긴 정책과 고정 규칙 코드에 묶어뒀다.

세 시간 동안 만든 것은 트렌드 예측기가 아니었다. 불완전한 신호 앞에서 섣불리 확신하지 않으면서도, 다음 검증을 시작할 때를 놓치지 않기 위한 의사결정 도구였다.