AX 인재전쟁 회고: AI 시대의 Taste는 무엇을 버릴지 정하는 일

프롤로그에서 AI 시대에는 실행 능력만큼 Taste가 중요해질 것이라고 썼다. 많은 가능성 중 무엇을 문제로 삼고, 어떤 답을 받아들일지 결정하는 능력을 직접 시험해보고 싶어서 무신사 트랙 하나만 선택했다.

예선을 통과했고, 본선에서는 무신사 트랙 1등을 했다. 그렇다고 이 결과만으로 처음의 생각이 옳았다고 결론 내릴 수는 없다. 순위는 대회의 조건 안에서 받은 평가이지, 실제 업무 효과를 검증한 결과가 아니기 때문이다.

다만 두 번의 서로 다른 문제를 풀면서 Taste가 무엇인지 전보다 구체적으로 말할 수 있게 됐다. 좋은 아이디어를 떠올리는 감각보다, 무엇을 버리고 어디에서 멈추며 어떤 판단을 끝까지 내가 책임질지 정하는 기준에 가까웠다.

이 회고는 “AI를 잘 쓰는 법”에 대한 일반론이 아니다.

공개 자료만 있는 상황에서 문제를 고르는 법, 여러 AI 작업의 결과를 통제하는 법, 짧은 데모로도 과장 없이 신뢰를 만드는 법을 예선과 본선의 실제 선택으로 설명한다.

좋은 선택보다 버린 선택이 방향을 만들었다

예선과 본선 모두 처음 나온 아이디어가 최종 결과가 되지 않았다.

예선에서는 충분한 조사 전에 AI가 만든 문제 후보를 폐기했다. 공개 자료의 수가 아니라 출처와 주장 사이의 거리를 다시 따졌고, 넓은 상품 정보 신뢰 문제를 파트너 보완과 내부 검토를 나누어 인계하는 한 가지 업무로 좁혔다.

본선에서는 트렌드 예측을 버렸다. 공개 데이터만으로 미래 판매를 맞혔다고 주장할 수 없었고, 세 시간 안에 그 정확도를 검증할 수도 없었다. 대신 MD가 구매·생산을 확정하기 전에 어떤 후보에 작은 검증 기회를 줄지 결정하는 문제로 바꿨다.

생성형 AI를 최종 화면의 중심에 두는 선택도 하지 않았다. 대회가 AI 활용을 평가한다고 해서 결과물 안에 AI 기능이 반드시 보여야 한다고 생각하지 않았다. 같은 입력에 같은 판정이 필요한 부분은 규칙과 코드에 남겼다.

버린 선택	남긴 선택	판단 기준
조사보다 먼저 나온 문제 후보	공개 근거로 시작과 끝을 설명할 수 있는 업무	근거 가능성
유행 예측과 매입 추천	다음 검증 기회의 배정	검증 가능성
AI가 만드는 최종 판정	결과 전에 잠근 규칙과 결정적 코드	반복 가능성
많은 기능을 보여주는 데모	대표·보류·실패를 가르는 한 흐름	설명 가능성

결과를 알고 나면 모든 선택이 계획적이었던 것처럼 설명하기 쉽다. 그래서 중요했던 것은 기억이 아니라 당시의 기록이었다. 버린 후보와 이유, 최종 결과를 보기 전에 잠근 기준이 문서와 로그에 남아 있었기 때문에 사후 해석과 실제 선택을 구분할 수 있었다.

이 대회에서 내가 가장 많이 한 일은 AI에게 더 만들어달라고 요청하는 것이 아니라, 이미 만들어진 결과 중 무엇을 믿지 않을지 정하는 일이었다.

AI가 늘린 생산량은 새로운 검토 비용을 만들었다

AI 덕분에 혼자서는 같은 시간에 시도하기 어려운 규모로 조사하고 구현할 수 있었다. 본선 전에는 38분 동안 정형 출처 카드 241건을 만들고, 중복을 제거한 URL 283개의 접근 상태를 확인했다. 현장에서는 문제 정의, 데이터 수집, 반론, 구현과 발표 준비를 여러 세션에서 동시에 진행했다.

그러나 많이 만들 수 있다는 것과 많이 사용할 수 있다는 것은 달랐다. 최종 판단에 쓴 신호는 수집한 자료의 일부뿐이었다. 자료가 늘수록 중복 출처를 하나의 독립된 근거로 착각하거나, 서로 다른 단위의 수치를 같은 표에 놓을 위험도 커졌다.

본선에서 첫 분석의 오류를 찾은 것은 더 많은 데이터를 모은 세션이 아니라 완료된 결과를 의심하도록 맡긴 감사 세션이었다. 공식 XLSX와 화면용 JSON의 차이, 중복된 동의어, 검색 관심과 상품 수의 분석 단위 불일치가 그 과정에서 드러났다.

여기서 얻은 교훈은 “AI를 더 많이 쓰자”나 “적게 쓰자”가 아니었다.

AI가 작업을 만드는 속도가 내가 검토하고 책임질 수 있는 속도보다 빨라지면, 생산량은 곧 검토 부채가 된다.

다음에는 병렬 조사를 시작하기 전에 각 작업에 네 가지를 붙일 것이다.

• 이 자료가 바꿀 수 있는 결정
• 필요한 최소 근거 수준
• 같은 결론의 출처를 몇 개 확인하면 멈출지
• 결과가 없거나 충돌할 때 남길 상태

출처를 더 찾는 능력만큼 그만 찾을 조건이 필요하다.

결정 기록은 AI의 기억이 아니라 변경을 통제했다

긴 작업에서는 세션마다 표현과 기준이 조금씩 달라졌다. 예선에서는 작업 Wiki에 조사 근거와 후보의 변경을 쌓았고, 본선에서는 사용자·결정·게이트· 상태·주장·한계를 하나의 기준서에 모았다.

이 문서는 AI에게 맥락을 전달하는 용도로만 쓰이지 않았다. 이미 정한 범위를 편의상 넓히거나, 대표 후보를 통과시키려고 임계값을 바꾸거나, 검증하지 않은 내용을 완료로 적지 못하게 하는 제약이었다.

기록이 항상 맞았던 것도 아니다. 본선 App 기준서에는 한때 Electron E2E가 통과했다고 적혔다. 이후 최신 번들을 다시 검사하면서 개발 경로와 선택자 문제가 발견됐고, 통과 주장을 철회했다. 기록이 있었기 때문에 앞뒤의 주장이 충돌한다는 사실과 정정 이유가 함께 남았다.

이 경험으로 결정 기록을 결과 정리 문서가 아니라 실행 중인 상태 관리로 보게 됐다. 다만 문서의 양은 과했다. 다음에는 긴 조사 문서보다 아래 여섯 항목이 한 화면에 들어가는 기준서를 먼저 만들 것이다.

1. 지금 답하려는 질문
2. 한 명의 사용자와 한 번의 결정 시점
3. 포함할 것과 제외할 것
4. 사용할 수 있는 입력과 근거
5. 결과 상태와 실패 시 기본값
6. 증명할 주장과 증명하지 않을 주장

다음 작업에서 사용할 최소 기준서는 이 정도면 충분하다.

question: 지금 답하려는 질문
user:
  role: 한 명의 사용자
  moment: 결정을 내리는 시점
scope:
  include: 이번에 다룰 범위
  exclude: 의도적으로 풀지 않을 범위
evidence:
  allowed: 사용할 수 있는 입력과 근거
outcomes:
  states: [action, hold, stop]
  safe_default: hold
claims:
  prove: 이번 결과로 증명할 것
  do_not_claim: 아직 증명하지 못한 것

세부 자료는 이 기준의 근거로 연결하면 된다. 기준서 자체가 다시 읽기 어려울 만큼 커지면 통제 장치로서의 역할도 약해진다.

AI를 통제한다는 것은 사용량이 아니라 권한의 문제였다

두 결과물에서 AI의 위치는 달랐다.

예선 플러그인은 코드가 입력과 이슈 유형을 판정하고, Codex가 그 사실을 수신자별 한국어 문서로 작성했다. 본선 App은 최종 상태까지 고정 규칙이 결정했고, AI는 문제 탐색, 데이터 수집과 감사, 구현과 문서화를 가속했다.

어떤 부분에 생성형 AI를 쓰고 쓰지 않을지는 기술 취향으로 정하지 않았다. 출력의 변동을 허용할 수 있는지, 잘못됐을 때 사람이 확인할 수 있는지, 같은 결과를 반복해야 하는지를 기준으로 나눴다.

작업의 성격	맡긴 주체
대안을 넓히고 반례를 찾는 탐색	AI
구조화된 사실을 사람이 읽는 문장으로 바꾸는 일	AI와 검증 코드
같은 입력에 같은 분류와 상태를 내는 일	결정적 코드
문제 범위, 허용할 근거와 최종 책임을 정하는 일	사람

AI를 최종 판정에서 제외했다고 해서 AI를 적게 쓴 것은 아니다. 반대로 AI를 많이 사용했다고 해서 모든 판단을 넘긴 것도 아니다. 통제는 호출 횟수를 줄이는 일이 아니라, 실패 비용에 따라 권한을 배치하고 결과를 다시 확인할 수 있게 만드는 일이었다.

처음 세운 “AI로 문제를 풀어도 결과물에 AI가 들어갈 필요는 없다”는 생각도 조금 수정됐다. 중요한 것은 AI가 화면에 보이는지가 아니라, 문제 정의부터 최종 결과까지 AI가 맡은 역할과 맡지 않은 책임을 설명할 수 있는가였다.

설득력 있는 데모는 거절하는 장면을 보여줬다

예선은 정상, 파트너 보완, 내부 검토, 혼합과 형식 오류를 같은 계약으로 실행했다. 본선은 대표 후보뿐 아니라 관심이 한 번만 튄 후보와 이미 대중화된 후보를 같은 여섯 기준으로 비교했다.

성공 사례 하나만 보여주면 시스템이 준비된 정답을 출력한다는 것밖에 증명하지 못한다. 반례를 함께 보여주면 어떤 근거가 부족할 때 멈추고, 어떤 높은 수치도 실패를 덮을 수 없는지 설명할 수 있다.

내가 데모에서 먼저 보여준 것은 정답이 아니라 거절이었다. 검색이 급등한 후보를 보류하고, 관심이 남은 후보도 이미 대중화됐다면 미배정하는 장면이 통과 사례보다 규칙의 성격을 더 빨리 설명했다.

특히 AI를 활용한 결과물은 자연스러운 문장이 판단의 빈틈을 가리기 쉽다. 그래서 보류, 이번 사이클 미배정, 입력 오류처럼 행동하지 않는 상태가 신뢰의 일부였다. 잘 만든 데모는 무엇을 할 수 있는지만 보여주는 것이 아니라, 무엇을 하지 않는지도 보여줘야 했다.

앞으로도 최소 세 장면을 먼저 설계하려 한다.

1. 기대한 행동으로 이어지는 대표 사례
2. 일부 신호는 좋아 보여도 보류하는 경계 사례
3. 입력이나 근거가 부족해 실행하지 않는 실패 사례

이 세 사례를 같은 기준으로 설명할 수 없다면 기능을 더 만들기 전에 판단 계약부터 다시 봐야 한다.

1등이 증명한 것과 증명하지 않은 것

무신사 트랙 1등이라는 결과만으로 심사 항목별로 어떤 선택이 얼마나 좋은 평가를 받았는지는 알 수 없다. 안전하게 말할 수 있는 것은 문제 정의, 작동하는 결과물과 발표를 묶은 전체 제출물이 그날의 무신사 트랙에서 선택됐다는 사실까지다.

이 결과는 실제 검수 담당자가 예선 문서를 유용하다고 평가했다는 증거가 아니다. 본선의 게이트가 미래 트렌드를 정확히 찾거나 매출과 재고를 개선한다는 증거도 아니다. 두 결과물 모두 공개 자료와 합성 또는 대리 데이터를 사용했고, 실제 인증·권한·운영 데이터와 장기 성과는 검증하지 못했다.

그러므로 순위는 제품 검증의 끝이 아니라 문제와 증거를 전달하는 방식에 대한 하나의 신호로 받아들이는 편이 정확하다. 다음 검증은 대회 밖의 사용자와 데이터에서 시작해야 한다.

• 예선 결과물은 실제 검수 담당자에게 분류와 문서의 유용성을 평가받는다.
• 본선 결과물은 과거 내부 사례가 있다면 게이트와 임계값을 검증한다.
• 검증 슬롯 배정 뒤 실제 노출 실험과 판단 결과를 연결한다.
• 패키징 환경의 Electron E2E를 고치고 재계산부터 내보내기까지 확인한다.

다음에도 유지할 것과 바꿀 것

이번 방식을 그대로 반복할 생각은 없다. 효과가 있었던 원칙은 남기고, 속도를 위해 만든 과잉도 함께 줄여야 한다.

유지할 것	바꿀 것
사용자와 결정부터 한 문장으로 고정	넓은 조사 전에 중단 조건부터 정하기
생성과 독립 감사를 다른 역할로 분리	문서 수를 줄이고 한 장의 기준서를 먼저 만들기
결과 전에 규칙과 변경 절차를 기록	패키징과 E2E를 구현 막바지가 아니라 초기에 확인하기
대표·경계·실패 사례를 같은 계약으로 실행	기술 검증 다음에 실제 사용자 검증을 바로 설계하기
증명하지 못한 효과를 명시	모든 수집 자료를 결과물에 넣으려 하지 않기

대회 전에는 Taste를 좋은 문제를 알아보는 안목이라고 생각했다. 지금은 조금 더 구체적이다. Taste는 그럴듯한 선택지 사이에서 하나를 고르는 순간뿐 아니라, 근거 없는 주장을 버리고, AI에 넘기지 않을 책임을 정하고, 충분히 검증했다면 더 만들지 않고 멈추는 과정 전체에 있었다.

AI는 더 많은 시도를 가능하게 했다. 그만큼 무엇을 결과로 인정할지에 대한 책임은 더 커졌다. 두 작업에서 반복해서 드러난 강점도 여기에 있었다. 낯선 도메인에서 빠르게 많은 결과를 만드는 데서 끝나지 않고, 그 결과를 깨뜨릴 역할을 따로 두고, 사람이 책임질 결정만 남겨 실행 가능한 계약으로 바꾸는 것이다.

결국 차이는 프롬프트의 화려함이나 생성량에서 나오지 않았다. 많이 사용하고도 왜 이 문제인지, 왜 이 규칙인지, 어디부터는 모르는지를 설명할 수 있는 작업 방식에서 나왔다.