2024년 11월 1~2일 동덕여자대학교에서 열린 AI & Big Data 융합 솔루션 개발 해커톤에 퍼실리테이터로 참여했습니다. 데이터 해커톤에서는 사용할 dataset과 model이 아이디어의 출발점이 되기 쉽습니다. 이번 세션에서는 순서를 바꿔 누가 어떤 결정을 더 잘 내려야 하는가를 먼저 정했습니다.
“이 데이터로 무엇을 만들까”를 “어떤 결정을 바꿀까”로 바꿨다
팀이 dataset을 먼저 보면 dashboard, 예측, 추천처럼 익숙한 output을 빠르게 떠올립니다. 그러나 그 output을 누가 언제 사용하는지 빠지면, chart가 많아져도 제품의 성공을 측정할 수 없습니다.
첫 문장은 data source가 아니라 사용자의 결정으로 쓰게 했습니다.
지역 상권 데이터를 시각화한다
→ 처음 매장을 준비하는 예비 창업자가
후보 지역 두 곳 중 어디를 먼저 현장 조사할지 고른다이렇게 바꾸면 필요한 데이터도 달라집니다. 모든 상권 지표를 모으는 대신, 첫 선택을 바꿀 수 있는 유동 인구·업종 밀도·시간대 변화와 데이터 갱신 시점을 먼저 확인하게 됩니다.
지표는 서비스 성과가 아니라 가설의 증거였다
예측 정확도 하나만으로는 사용자 가치가 증명되지 않습니다. model의 offline metric이 좋아도 사용자가 결과를 이해하지 못하거나 행동하지 않으면 고객 약속은 달성되지 않습니다.
팀은 기술 지표와 사용 지표를 나눴습니다.
- model이 얼마나 정확하고 안정적인가
- 필요한 시점까지 결과가 도착하는가
- 사용자가 추천 근거를 이해하는가
- 결과를 보고 실제 선택을 바꾸는가
- 잘못된 결과를 사람이 알아차릴 수 있는가
데모에서도 정확도 수치를 먼저 보여 주기보다, 입력된 상황이 어떤 근거와 결과로 바뀌고 사용자가 어떤 결정을 내리는지 연결했습니다.
데이터 품질을 마지막 예외 처리로 미루지 않았다
AI·Big Data 프로젝트는 결측치, 편향, 갱신 주기, label 품질 같은 문제를 구현 막바지에 만나는 경우가 많습니다. 이번에는 FAQ에서 먼저 제품 약속과 연결했습니다.
- 특정 지역 데이터가 비면 추천을 중단할 것인가
- 오래된 데이터임을 사용자에게 어떻게 알릴 것인가
- 표본이 적은 집단에서 confidence를 어떻게 제한할 것인가
- 개인 정보와 민감 속성은 어느 단계에서 제거할 것인가
이 질문의 답은 preprocessing task만 만들지 않았습니다. UI의 warning, fallback flow, confidence 표시, 데모 범위까지 바꿨습니다. 데이터 품질은 backend의 내부 문제가 아니라 고객이 결과를 믿어도 되는 조건이 됐습니다.
이틀 안에는 완전한 분석보다 한 번의 결정 흐름을 남겼다
해커톤의 시간 안에 dataset을 완전히 정제하고 model을 최적화할 수는 없습니다. 그래서 최종 산출물은 많은 chart가 아니라 하나의 decision flow에 집중했습니다.
사용자 상황 입력
→ 필요한 데이터와 model output
→ 근거와 한계 표시
→ 사용자의 선택
→ 선택 결과를 검증할 다음 지표심사와 피드백에서도 dataset의 크기보다 이 연결을 봤습니다. 어떤 데이터가 고객의 어떤 판단을 바꿨는지 설명할 수 있어야, 해커톤 이후 model 개선과 data pipeline 투자가 같은 방향을 가집니다.
동덕여대 사례에서 Working Backwards는 data-driven을 “데이터가 많은 제품”으로 해석하지 않게 했습니다. 사용자의 결정에서 출발해 필요한 data와 metric을 거꾸로 정하는 것이 이틀 동안 가장 중요한 설계 변화였습니다.
댓글