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를 폭넓게 사용했다. 여러 세션과 보조 에이전트에 역할을 나눴고, 별도의 감사 세션에는 앞선 결론을 지지하는 대신 깨뜨리라고 요청했다. 다만 결과를 바꾸는 권한은 잠긴 정책과 결정적 코드로 제한했다.

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