AX 인재전쟁 예선: 공개 근거에서 실행 가능한 문제를 찾기

예선 과제는 참여 기업의 공개되고 검증 가능한 문제를 찾고, 이를 해결하는 Codex 플러그인을 만드는 것이었다. 기업 내부 데이터나 개인적인 경험은 근거로 인정되지 않았다. 실행되는 플러그인뿐 아니라 원본 AI 대화 로그와 다섯 문항의 설명도 함께 제출해야 했다.

이 조건에서 가장 먼저 풀어야 할 문제는 코딩이 아니었다.

공개 자료만으로 실제 업무의 막히는 지점을 어디까지 말할 수 있는가?

결론부터 말하면, 상품 자료 하나를 파트너 보완 요청서와 내부 검토 요청서로 나누고, 판단 근거를 검수 기록으로 남기는 Codex 플러그인을 만들었다. 흔한 “상품 설명을 검사하는 AI”가 아니라, 한 자료를 읽은 뒤 서로 다른 사람에게 정확히 인계하는 지점을 제품으로 잡았다.

이 글의 흐름은 단순하다. 근거를 먼저 모으고 → 업무의 인계 지점을 찾고 → 코드와 AI의 책임을 분리하고 → 경계 사례로 검증했다.

솔루션보다 근거를 먼저 모았다

처음에는 AI가 네 가지 문제 후보를 제안했다. 하지만 그 시점에는 무신사를 충분히 조사하지 않은 상태였다. 아이디어가 그럴듯해도 자료보다 먼저 나온 가설을 문제 정의로 채택할 수는 없었다. 이후 작업에서 그 네 가지를 참조하지 않도록 명시하고 조사를 다시 시작했다.

공식 사이트, 파트너 가이드, 뉴스룸과 채용 자료를 중심으로 보고, 소비자 자료와 법령·공공기관 자료로 바깥에서 확인되는 문제를 보완했다. 조사 작업은 출처 유형별로 나눠 병렬로 진행했지만, 수집한 링크를 바로 주장으로 사용하지 않았다. 회사가 직접 밝힌 사실인지, 외부에서 관찰한 신호인지, 추론에 불과한지를 나눠 기록했다.

공식 사이트 46건, 채용·구성원 자료 44건, 소비자 관점 자료 31건, 공개 프로필 자료 31건을 분리해 모았다. 차이는 152건을 모았다는 숫자가 아니라, 그 넓은 표면에서 최종적으로 한 자료를 두 수신자에게 인계하는 좁은 업무 하나만 남긴 것이었다.

링크 수가 많다고 근거가 강해지는 것도 아니었다. 같은 보도 자료를 옮겨 쓴 기사들은 하나의 근거 묶음으로 보고, 각 자료를 출처 → 관찰 사실 → 지지하는 주장 → 가능한 추론 → 해서는 안 되는 추론 순서로 정리했다. 공식 답변이 있다는 사실도 문제가 크다는 증거가 아니라, 이미 대응 체계가 있다는 반대 해석까지 함께 남겼다.

이 작업은 일회성 대화에만 두지 않았다. 조사 계획, 출처의 신뢰도와 후보를 버린 이유를 작업 Wiki에 기록했다. 여러 AI 세션이 자료를 나눠 찾더라도 다음 세션이 결론만 물려받지 않고, 결론까지의 경로를 다시 확인할 수 있게 하기 위해서였다.

자료가 많아진 뒤에도 후보를 기능의 화려함으로 고르지 않았다. 다음 다섯 기준으로 비교했다.

기준	확인한 질문
근거 강도	공개 자료만으로 문제를 입증할 수 있는가
플러그인 적합성	일반 챗봇보다 반복 가능한 작업 흐름이 필요한가
시연 명확성	입력과 출력의 차이를 짧게 보여줄 수 있는가
구현 가능성	제한된 시간에 예외 처리까지 만들 수 있는가
전달력	문제와 결과의 연결을 심사자가 바로 이해할 수 있는가

이 과정을 거쳐 상품 등록 자료를 검수하는 과정으로 범위를 좁혔다.

후보를 남긴 기준은 “문제가 커 보이는가”가 아니라, 공개 근거만으로 누가 무엇을 인계받는지 설명하고 실행할 수 있는가였다.

중간에는 무신사 밖의 패션 생태계까지 넓히거나, 상품 정보 전체의 신뢰를 한 번에 다루는 후보도 있었다. 문제의 의미는 컸지만 공개 자료만으로 업무의 시작과 끝을 특정하기 어려웠고, 제한된 시간에 작동하는 흐름으로 증명하기도 어려웠다. 범위를 넓히는 대신 누가, 언제, 무엇을 인계받는가를 답할 수 있는 후보를 남겼다.

읽는 일이 아니라 나누고 인계하는 일이 문제였다

무신사 파트너 가이드에는 표준 옵션, 실측 사이즈와 시험성적서처럼 상품 등록에 필요한 필드가 공개돼 있다. 뉴스룸에는 다운·캐시미어 상품의 소재 혼용률을 검사한 사례도 있었다. 공개된 사례에서는 7,968개 상품을 전수검사해 약 8.5%의 오기재·표기 오류를 확인하고 시정했다. 안전거래센터와 그린워싱 가이드 같은 검토 표면도 확인할 수 있었다.

여기서 단순히 “상품 정보를 검사하는 AI”를 만드는 것은 충분하지 않았다. 한 상품 자료에는 처리 방법이 다른 두 종류의 문제가 섞여 있었다.

첫째는 혼용률, 사이즈표, 증빙 링크처럼 무엇을 보완해야 하는지 자료만으로 확인할 수 있는 항목이다. 이 경우 파트너에게 구체적인 보완을 요청하면 된다.

둘째는 친환경, 정품, 캐시미어, 반품 보장처럼 자료만으로 맞고 틀림을 단정하기 어려운 표현이다. 충분한 근거가 있는지, 정책이나 법무 검토가 필요한지는 내부 담당자가 판단해야 한다.

따라서 병목을 단순히 “누락을 찾는 일”이 아니라 다음과 같이 정의했다.

하나의 상품 등록 자료에서 바로 고칠 항목과 사람이 판단할 항목을 구분하고, 서로 다른 수신자에게 보낼 문서와 검수 기록으로 인계하는 일

이 정의를 기준으로 상품등록 보완요청서 Codex 플러그인을 만들었다.

결정적인 사실과 문서 작성을 분리했다

플러그인은 상품 자료를 받아 세 단계로 처리한다.

1. 스크립트가 입력 형식을 검사하고 자료를 정규화한다.
2. 고정된 규칙이 보완 항목과 내부 검토 항목을 분류한다.
3. Codex가 구조화된 결과를 읽어 수신자별 문서를 작성하고, 검증을 거쳐 MCP 목업에 검수 기록을 저장한다.

입력 자료
  → [코드] 형식 검증·정규화·이슈 분류
  → [Codex] 수신자별 한국어 문서 작성
  → [코드] 출력 계약 검증·검수 기록 저장

이 구조에서 AI가 모든 것을 판단하게 하지 않았다. 필수 필드, 증빙 규칙, 이슈 분류와 출력 계약처럼 반복돼야 하는 사실 판단은 코드와 기계 판독 가능한 JSON 규칙에 두었다. Codex는 그 결과를 사람이 읽을 수 있는 한국어 문서로 바꾸는 역할을 맡았다.

최종 산출물은 세 가지였다.

• 파트너가 바로 고칠 항목을 담은 보완 요청서
• 단정하지 않고 담당자 판단을 요청하는 내부 검토 요청서
• 어떤 근거로 어떻게 나뉘었는지 남기는 검수 기록

자료가 깨졌다면 요청서와 기록을 만들지 않는다. 정보가 빠졌다면 원고에서 추측해 채우지 않는다. 민감 표현은 위법, 허위나 정책 위반으로 단정하지 않는다. 플러그인이 승인·반려·제재나 실제 발송까지 수행하지도 않는다.

무엇을 하는지뿐 아니라 무엇을 하지 않는지도 제품 계약에 포함했다.

AI에게 맡긴 일과 직접 정한 일을 구분했다

AI에는 공개 자료 조사, 구현과 테스트, 문서 초안 작성을 맡겼다. 자료 수집은 여러 보조 에이전트로 나눠 속도를 높였고, 세션 사이에서 결정이 사라지지 않도록 작업 Wiki에 근거와 변경 내역을 쌓았다.

사람이 직접 정한 것은 문제의 범위, 두 종류의 인계 방식, 최종 출력과 가드레일이었다. 특히 다음 역할 분리는 구현 전에 고정했다.

판단	담당
입력이 계약에 맞는가	코드
어떤 유형의 이슈인가	고정 규칙
수신자가 읽을 문장을 어떻게 쓸까	Codex
결론을 단정해도 되는가	단정하지 않고 담당자에게 인계

AI의 제안을 받아들이지 않은 순간도 중요했다. 조사 전에 만들어진 문제 후보는 폐기했고, 스크립트가 문서 템플릿까지 완성하는 초기 구조도 수정했다. 후자는 실행은 일관됐지만 Codex 플러그인으로서 AI가 맡을 일이 거의 남지 않았다. 그래서 코드는 초안에 필요한 사실을 준비하고, Codex가 문서를 작성한 뒤 다시 코드가 검증하는 구조로 바꿨다.

스크립트 실행과 플러그인 실행을 구분했다

초기 구현은 스크립트가 두 요청서까지 템플릿으로 완성했다. 결과는 일관됐지만, 이대로라면 Codex 플러그인이 할 일은 명령을 대신 실행하는 것뿐이었다. 그래서 실행 계약을 두 단계로 바꿨다.

먼저 prepare-only 단계에서 코드가 입력과 규칙을 검증하고, 문서 작성에 필요한 사실만 JSON으로 내보낸다. 그다음 Codex가 그 사실을 바탕으로 한국어 요청서를 직접 작성한다. 마지막 finalize 단계에서 코드가 문서의 구조와 표현을 다시 검사하고 MCP 목업에 기록한다.

prepare-only와 finalize 사이만 생성형 AI에 열어두었다. AI가 문장을 작성하되, 입력 사실과 최종 출력 계약까지 바꾸지는 못하게 한 경계였다.

실제 실행도 하나의 만능 명령이 아니라 두 단계로 나눴다.

# 1. 결정적 사실만 준비한다.
python3 src/tools/run_review.py \
  --packet-dir src/fixtures/mixed-correction-and-review \
  --artifacts-dir /tmp/musinsa-review/runs/mixed-correction-and-review \
  --mock-store /tmp/musinsa-review/mock-store \
  --case-id mixed-correction-and-review \
  --prepare-only

# 2. Codex가 문서를 쓴 뒤 검증하고 기록한다.
python3 src/tools/finalize_review.py \
  --packet-dir src/fixtures/mixed-correction-and-review \
  --artifacts-dir /tmp/musinsa-review/runs/mixed-correction-and-review \
  --mock-store /tmp/musinsa-review/mock-store \
  --case-id mixed-correction-and-review

테스트 스크립트가 통과하는 것만으로는 실제 플러그인이 작동한다고 보지 않았다. 설치된 Codex 환경에서 스킬이 자동으로 선택되는지, 준비 단계 뒤 Codex가 쓴 문서가 수정 없이 보존되는지, 최종 기록까지 이어지는지를 별도로 실행했다. 결정적 판정은 코드에 남기면서도 자연어 작성에는 AI를 실제로 쓰는 경계를 찾은 셈이다.

마지막에는 플러그인을 실제 Codex CLI에 설치하고 새 세션에서 혼합 사례를 처음부터 실행했다. 스킬이 자동으로 선택됐고, Codex가 파트너 요청서와 내부 요청서를 작성했으며, finalize 검증 결과는 오류 없이 valid였다. 테스트가 구현을 호출하는 수준을 넘어, 사용자가 플러그인을 부르는 실제 경로까지 확인했다.

정상 사례보다 경계를 검증했다

대표 시나리오는 Sustainable cashmere cardigan이라는 합성 상품 자료였다. 소재 혼용률이 비어 있고, 실측 사이즈표와 증빙이 연결되지 않은 상태에서 캐시미어, 지속가능성, 반품 보장 같은 표현이 함께 들어 있었다.

플러그인은 바로 고칠 세 항목과 내부 검토가 필요한 표현을 분리해 두 요청서를 만들고 하나의 검수 기록 아래 연결했다.

대표 시나리오만 성공시키지 않았다. 다음 다섯 종류의 입력을 픽스처로 만들었다.

• 문제가 없어 요청서가 필요 없는 정상 자료
• 파트너 보완만 필요한 자료
• 내부 검토만 필요한 자료
• 두 종류가 함께 있는 자료
• 형식이 깨져 처리를 중단해야 하는 자료

구현은 TDD로 진행했다. 먼저 실패 10건과 에러 11건이 있는 RED 상태를 남긴 뒤, 스크립트·MCP 단위 및 통합 테스트, 플러그인·스킬 계약, E2E와 실제 Codex CLI 실행까지 확인했다. 최종 제출 시점의 검증 명령은 26개 테스트와 플러그인 검증을 통과했다.

정상 사례보다 경계 사례가 더 많은 것을 설명했다. 무엇을 만들어내는지 뿐 아니라, 어떤 입력에서 멈추고 어떤 표현을 사람에게 넘기는지가 플러그인의 신뢰 범위였다.

테스트 과정에서 사용자 문서에 product.materials.fiber_composition 같은 시스템 필드가 그대로 드러나는 문제도 발견했다. 추적용 원본 경로는 내부 JSON에 유지하되, 요청서에는 소재 혼용률, 실측 사이즈표처럼 업무 용어만 쓰도록 검증 규칙을 추가했다. 서로 다른 상태인데도 같은 문장이 반복되는 문제와, “내부 메타 정보” 같은 구현자 관점의 표현도 같은 방식으로 제거했다.

깨진 입력에서는 문서와 기록을 전혀 남기지 않는지, prepare-only에서 아직 문서나 MCP 기록이 생기지 않는지, Codex가 작성한 문서를 finalize가 임의로 고쳐 쓰지 않는지도 테스트했다. 마지막에는 제출 압축본을 새 경로에서 풀어 절대 경로 없이 검증기가 실행되는지까지 확인했다.

실행된 것과 가정한 것을 나눴다

플러그인은 입력 검증, 분류, 문서 작성, 결과 검증과 검수 기록 저장까지 실행됐다. 설치된 Codex 환경에서도 혼합 사례를 처리해 두 문서를 작성하고 검증 결과가 유효한지 확인했다.

하지만 상품 자료 스키마와 내부 시스템은 실제 무신사 환경이 아닌 합성 입력과 로컬 MCP 목업이었다. 인증, 권한, 운영 API, 실제 담당자의 문서 품질 평가는 검증하지 못했다.

이 한계를 숨기지 않는 것이 중요했다. 공개 자료로 실제 문제의 가능성은 보일 수 있지만, 내부 프로세스가 정확히 이 방식이라고 주장할 수는 없다. 그래서 제출물은 기존 업무를 대체하는 제품이 아니라, 공개 근거를 바탕으로 만든 실행 가능한 업무 흐름 제안으로 위치시켰다.

예선을 통과하며 확인한 것은 복잡한 플러그인을 만들 수 있다는 사실보다, 자료에서 문제 정의로, 문제 정의에서 역할 분리로, 역할 분리에서 검증 가능한 산출물로 이어지는 연결이 끊기지 않았다는 점이었다. 본선에서는 같은 원칙을 훨씬 짧은 시간과 더 열린 문제에 적용해야 했다.