기획자가 직접 만든다는 것
나는 기획자다. 그런데 이번엔 그림만 그리지 않고, F1 데이터 대시보드를 데이터 수집부터 ML·배포까지 직접 손으로 끝까지 만들어 봤다. 그 과정에서 배운 건 기술 스택이 아니라, 판단의 태도였다.
오버엔지니어링을 피하는 법
배포를 앞두고 두 갈래가 있었다. (A) 지금 앱을 그대로 컨테이너에 담아 올린다. (B) 프론트를 Next.js로 분리해 제대로 만든다.
B가 더 "제대로"처럼 보였다. 하지만 질문을 뒤집었다 — 수요가 확인되지도 않은 제품에 왜 몇 주를 쓰나? 그래서 A로 싸게 띄우되, 유휴 시 비용이 0이 되는 구조(scale-to-zero)를 택했다. 수요는 재보고 나서 키우면 된다. 좋은 기획은 자주 "덜 만드는" 결정이다.
버그처럼 보인 진실
가장 많이 배운 건 검증에서였다.
- 리타이어율이 갑자기 40%로 튀었다. 버그인 줄 알았는데, 데이터 제공처가 어느 해부터 "+1 Lap"을 "Lapped"로 표기만 바꾼 탓이었다. 완주를 리타이어로 오분류하고 있었다.
- "20초 페널티가 순위를 12칸이나 떨어뜨렸다"는 결과도 처음엔 오류로 보였다. 그러나 그 경기는 17대가 23.6초 안에 완주한 초압축 레이스였다. 페널티의 순위 영향은 레이스가 얼마나 촘촘한지에 달려 있었다 — 버그가 아니라 통찰이었다.
두 번 다, 성급히 "이상하다"며 버렸다면 잘못된 분석을 냈거나 진짜 발견을 놓쳤을 것이다.
결론
결과물은 라이브로 돌아가지만, 내게 남은 건 화면이 아니라 이 문장이다 — 검증이 통찰을 지킨다. 숫자가 이상할 때 그것은 버그일 수도, 아직 못 본 진실일 수도 있다. 둘을 구분하는 힘이 결국 데이터로 무언가를 주장할 자격이다.