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 목업에 기록한다.

생성형 AI에 열어둔 구간은 prepare-only와 finalize 사이뿐이었다. 문장은 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, 실제 담당자가 매기는 문서 품질은 검증하지 못했다.

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

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