경기창고는 2025년 5월 31일부터 10월 18일까지 이어진 청소년 AI 해커톤 장기 프로그램이었습니다. 22개 팀, 약 80명의 학생으로 시작해 마지막에는 10개 팀이 demo booth와 pitching을 진행했습니다.
다섯 달 가까운 프로그램에서 Working Backwards는 아이디어를 만드는 첫날의 활동이 아니었습니다. 팀과 멘토가 여러 번 바뀌는 상황에서도 지난 결정과 다음 실험을 이어 주는 운영 언어로 사용했습니다.
팀마다 결과는 달라도 점검 질문은 같게 했다
프로젝트에는 사물 감지 장갑, 균열 감지, 소비기한 관리와 recipe 추천처럼 다른 문제와 구현 방식이 있었습니다. 모든 팀에게 같은 화면이나 model을 요구하면, 자신의 사용자보다 제출 형식에 맞추게 됩니다.
대신 어느 주제든 답해야 하는 질문을 같게 했습니다.
- 이 문제를 가장 먼저 겪는 사람은 누구인가
- 그 사람이 지금 취하는 우회 행동은 무엇인가
- 이번 단계에서 확인할 한 가지 변화는 무엇인가
- 다음 점검까지 의도적으로 만들지 않을 것은 무엇인가
사물 감지 팀은 인식 가능한 object 수보다 사용자가 어느 거리에서 어떤 alert를 받고 행동하는지를, 균열 감지 팀은 model accuracy보다 누가 위험 후보를 검토하고 어떤 조치로 넘기는지를 설명해야 했습니다. 결과물은 달라도 product decision의 구조는 비교할 수 있었습니다.
프로그램의 각 활동을 다음 결정과 연결했다
교육, 멘토링, 특강, 기업 탐방이 각각 좋은 경험으로 끝나면 프로젝트의 중심이 쉽게 흩어집니다. 각 활동 뒤에는 다음 회의에서 사용할 문장 하나를 남겼습니다.
- 교육 뒤: 새로 확인할 고객 문제
- 멘토링 뒤: 이번 주에 줄이거나 검증할 범위
- 특강과 탐방 뒤: architecture 또는 운영 가정에 적용할 점
- 중간 발표 뒤: 유지할 가설과 버릴 가설
이 기록은 팀원이 바뀌거나 일정이 지연됐을 때 handoff가 됐습니다. 멘토의 조언도 “기능을 더 넣자”가 아니라 기존 고객 약속의 어느 문장을 수정하는지로 남겼습니다.
중간 점검은 완성도가 아니라 불확실성을 봤다
장기 프로그램의 중간 발표는 UI와 model이 얼마나 완성됐는지 평가하기 쉽습니다. 그러나 이 시기에는 아직 확인하지 못한 가정이 더 중요한 정보였습니다.
팀은 데이터가 실제로 존재하는지, 사용자가 결과를 믿지 않을 때 확인 경로가 있는지, 위험한 결정을 자동화하고 있지는 않은지, hardware나 외부 API가 demo 환경 밖에서도 동작할지 기록했습니다.
답하지 못한 질문은 감점 요소가 아니라 다음 experiment가 됐습니다. 일정이 밀려도 모든 가정을 구현으로 덮지 않고, 고객 약속에 직접 필요한 uncertainty부터 줄일 수 있었습니다.
마지막에는 기능을 더하기보다 전달 경로를 완성했다
Final demo가 다가오면 로그인, 통계, 추가 화면과 model feature를 넣고 싶어집니다. 마지막 점검에서는 새 기능보다 입력, 오류, 결과 근거와 고객의 다음 행동이 끊기지 않는지 봤습니다.
기능이 없어도 핵심 변화가 보인다면 보류했습니다. 대신 이미 만든 흐름에서 sample data와 실제 data의 경계, 잘못된 예측의 처리, 사용자가 결과를 이해하는 설명을 보강했습니다.
10개 팀의 booth와 pitching은 최종 출력이었지만, 장기 프로그램의 전체 성과를 발표 팀 수로만 볼 수는 없습니다. 22개 팀이 각자의 속도에서 다음 판단을 기록하고, 왜 scope를 바꿨는지 설명할 수 있게 되는 것도 중요한 결과였습니다.
경기창고 사례는 Working Backwards가 한 번의 workshop canvas보다 프로젝트 governance에 가깝게 쓰일 수 있음을 보여 줬습니다. 긴 프로그램에서 필요한 것은 처음의 열정을 유지하라는 구호가 아니라, 여러 달 동안 무엇을 확인했고 왜 다음 결정을 내리는지 잃지 않는 기록이었습니다.
댓글