AI 시대에 기획자가 개발자와 효과적으로 소통하려면, AI가 어떤 조건에서 잘 작동하고 어디서 실패하는지를 체감해야 한다. 본 리포트는 "OpenClaw Lets Run" AI 해커톤에서 경마 예측을 수행하며 관찰한 AI 의사결정의 구조적 특성을 정리한다. 4경주 실전 검증을 통해 (1) 요구사항 해상도가 AI 출력 품질을 결정한다는 것, (2) 데이터 분석과 현장 신호가 충돌할 때 사람의 판단이 필요하다는 것, (3) 기획자가 "AI로 되나요?"보다 "어떤 조건에서 되나요?"로 질문을 바꿔야 한다는 것을 확인하였다.
격변하는 AI 시대에서 기획자-개발자 간 소통의 질은 곧 제품의 질이 된다. 기획자가 "이거 AI로 되나요?"라고 물을 때, 그 질문의 해상도가 낮으면 개발자도 명확한 답을 줄 수 없다. 더 나은 질문을 하려면 AI가 실제로 어떻게 작동하고, 어디서 실패하는지를 직접 겪어봐야 한다.
"OpenClaw Lets Run" 해커톤은 이를 체험할 수 있는 구조였다. 오직 AI 채팅만 허용되고, 사람이 할 수 있는 건 "AI한테 뭘 시키느냐"를 결정하는 것뿐이었다. 프롬프트를 어떻게 쓰느냐, 결과를 어떻게 판단하느냐, AI가 틀렸을 때 어떻게 대응하느냐 -- 이 세 가지가 기획서에서 요구사항을 정의하고, 검수하고, 피드백하는 것과 구조적으로 동일했다.
"AI한테 일을 시키는 과정에서, 기획자가 개발자 소통에 활용할 수 있는 구조적 패턴이 있는가?"
KRA(한국마사회) 출마표 PDF에서 다음 정보를 추출하여 AI에게 전달했다:
| 카테고리 | 항목 | 기획 관점에서의 의미 |
|---|---|---|
| 실력 | KRA 레이팅 | "정량 지표"만으로 판단하면 어떻게 되는가 |
| 거리 적성 | 해당 거리 승/준/복 횟수 | "맥락에 맞는 경험"이 수치보다 중요한가 |
| 컨디션 | 마체중 변화, 부상이력 | "현재 상태"와 "과거 성적"의 괴리 |
| 기수/조교사 | 통산 성적, 승률 | "실행자의 역량"이 결과에 미치는 영향 |
| 시장 신호 | 실시간 배당 변화율 | "데이터에 없는 정보"가 시장에 있을 때 |
여기서 가장 큰 교훈이 나왔다. 처음에 "이거 분석해줘"라고 던졌을 때, AI는 모든 데이터를 나열만 했다. 요구사항이 모호하면, 결과도 모호하다.
v1 (모호): "이 출마표 분석해서 추천 마필 알려줘"
결과: 모든 말의 장단점을 나열. 판단 불가.
v2 (구체): "1800m 거리 경험이 있는 말만 뽑아줘. 최근 3회 성적 + 종반 200m 기록 기준으로 순위. 배당이 30분 전 대비 30% 이상 떨어진 말 별도 표시."
결과: 의미 있는 후보 3마리 도출. 판단 가능.
기획서에 "사용자가 쉽게 비교할 수 있게"라고 쓰는 것과 같은 문제. "쉽게"가 뭔지, "비교" 기준이 뭔지 정의하지 않으면 개발자(든 AI든) 각자 해석한다. 요구사항의 해상도가 결과물의 품질을 결정한다.
| 경주 | 거리 | Model A (데이터만) | Model C (데이터+시장) | Baseline (시장만) | 실제 결과 | A | C | Base |
|---|---|---|---|---|---|---|---|---|
| 5R | 1400M | 2, 5 | 2, 5 | 1, 2 | 2-5-6 | 1-2착 | 1-2착 | 부분 |
| 6R | 1300M | 5, 8 | 5, 8 | 3 | 3-9-1 | 전멸 | 전멸 | 1착 |
| 7R | 1600M | 3, 4 | 2, 3, 4 | 4, 3 | 2-3-4 | 복연승 | 3착 이내 | 부분 |
| 8R | 1800M | 9, 6 | 9, 11 | 11, 9 | 11-9-7 | 부분 | 1-2착 | 1-2착 |
| 모델 | 1착 적중 | 2착 이내 | 3착 이내 |
|---|---|---|---|
| Baseline (시장만) | 2/4 (50%) | 2/4 (50%) | 3/4 (75%) |
| Model A (데이터만) | 1/4 (25%) | 2/4 (50%) | 3/4 (75%) |
| Model C (데이터+시장) | 1/4 (25%) | 3/4 (75%) | 4/4 (100%) |
데이터만 보면(Model A) 시장만 보는 것(Baseline)과 비슷한 수준에 머문다. 데이터와 현장 신호를 결합했을 때(Model C) 가장 안정적인 결과가 나왔다. 서비스 기획에서도 정량 데이터(대시보드)와 정성 데이터(사용자 피드백)를 함께 봐야 하는 것과 같은 구조.
3번 마필의 배당 변화:
마감 30분전 8.9배 -> 5분전 2.8배 (변화율: -68.5%)
AI 판단: "데이터상으로는 3번은 별로인데요?"
실제 결과: 1착
AI는 정적 데이터(레이팅, 과거 성적)에서 3번 마필의 우위를 찾지 못했다. 하지만 마감 직전 배당 급락은 "데이터에 포착되지 않는 정보를 가진 사람들"이 대규모로 베팅했다는 의미였다. AI가 "데이터상 별로"라고 해도, 현장의 신호가 반대라면 한 발 물러서야 하는 순간이 있다.
서비스 기획에서도 같은 상황이 발생한다. 대시보드의 사용률 지표가 "이 기능은 안 쓰인다"고 말해도, CS 채널에서 "이 기능 없으면 안 돼요"라는 신호가 올 수 있다. "AI가 이렇게 말했으니까"로 의사결정하면, 6R 전멸과 같은 결과가 나온다.
현장/실시간 정보가 전체 중요도의 55%를 차지했다. 과거 데이터 중에서는 단순 레이팅(5%)보다 맥락에 맞는 경험(거리 적성, 25%)이 훨씬 중요했다.
사용자 리서치에서도 동일한 패턴이 나온다. 정량 지표(NPS, DAU)보다 맥락이 담긴 정성 데이터(인터뷰, CS 로그)가 실제 의사결정에 더 큰 영향을 미치는 경우가 많다. "숫자가 높은 게 좋은 것"이 아니라 "이 맥락에서 의미 있는 숫자가 뭔지"를 판단하는 게 기획자의 역할.
해커톤에서 가장 먼저 체감한 것: 프롬프트의 구체성이 AI 출력의 품질을 결정한다는 것. 이건 기획서에서 요구사항의 해상도가 개발 결과물의 품질을 결정하는 것과 정확히 같은 구조다.
| 해커톤에서 | 서비스 기획에서 |
|---|---|
| "분석해줘" -> 정보 나열 | "쉽게 비교할 수 있게" -> 해석이 분분한 결과물 |
| "이 거리 경험 있는 말, 최근 3회 성적 기준 순위" -> 판단 가능한 결과 | "전략별 수익률을 기간/벤치마크 대비로, 소수점 2자리까지" -> 명확한 결과물 |
| AI가 해석을 잘못했을 때 프롬프트를 수정 | 구현이 기대와 다를 때 요구사항을 수정 |
6R 전멸은 이 해커톤에서 가장 값진 교훈이었다. AI가 "데이터상 별로"라고 한 말이 1착으로 들어왔을 때, 깨달은 것:
서비스 기획에서 AI 기능을 설계할 때, 이 경계를 명확히 해야 한다. "AI가 추천한 결과를 그대로 보여줄 것인가, 사람이 검토할 단계를 넣을 것인가"는 제품의 신뢰도를 결정하는 핵심 설계 판단이다.
4경주에 걸쳐 전략이 진화한 과정:
| 경주 | 전략 | 결과 | 배운 것 |
|---|---|---|---|
| 5R | 정적 데이터 기반 추천 그대로 따름 | 적중 | "데이터가 되네?" (과신의 시작) |
| 6R | AI 추천에 크게 베팅, 시장 신호 무시 | 전멸 | 시장 신호를 무시하면 안 된다 |
| 7R | 복연승 보험 추가 + 시장 신호 반영 | 적중 | 리스크 분산 + 현장 신호 결합 |
| 8R | 데이터+시장 앙상블 + 분산 배팅 | 적중 | 검증된 전략의 반복 |
이건 스프린트에서의 이터레이션과 같은 구조다. 첫 시도(5R)의 성공에 과신하지 않고, 실패(6R)에서 빠르게 원인을 파악하고, 다음 시도(7R)에 개선점을 반영하고, 검증된 것(8R)을 반복하는 것. "완벽한 분석"을 기다리는 것보다 "충분히 좋은 판단"을 빠르게 내리는 것이 더 나은 결과를 만들었다.
이 해커톤 이후, 기획자로서 AI 관련 의사결정을 할 때 이 기준을 쓰게 됐다:
| # | 원칙 | 해커톤에서 배운 것 | 기획에 적용하면 |
|---|---|---|---|
| 1 | 요구사항의 해상도를 높여라 | "분석해줘" -> "이 조건에서 이 기준으로" | 기획서에서 "쉽게", "빠르게"를 구체적 기준으로 바꾸기 |
| 2 | AI 출력을 그대로 신뢰하지 마라 | 데이터상 완벽 -> 6R 전멸 | AI 기능에 사람 검토 단계(Human-in-the-Loop) 설계 |
| 3 | 데이터에 없는 신호도 존재한다 | 배당 급등 = 데이터 밖의 정보 | 정량(대시보드) + 정성(사용자 목소리) 함께 보기 |
| 4 | 완벽한 분석보다 빠른 이터레이션 | 4경주 만에 전략이 진화 | MVP 먼저, 피드백 기반 개선의 반복 |
| 5 | 같은 조건에서 직접 겪어봐라 | "되나요?" -> "어떤 조건에서 되나요?" | AI 도구를 직접 써보고 기획의 현실성 검증 |
기획자가 개발자와 같은 언어로 말하려면, 같은 경험을 공유해야 한다. 경마장에서의 하루는 그 경험을 압축적으로 제공해줬다.