첫 Claude 해커톤에 참가하고 나서 깨달은 점: 좋은 제품을 만드는 것과 해커톤에서 우승하는 것은 완전히 다른 문제다
Attended my first Claude hackathon and learned that building a good product and winning a hackathon are two very different things
핵심 요약
해커톤은 기술적 완성도보다 화려한 발표와 마케팅이 우승을 결정짓는 행사라는 현실을 깨달은 개발자의 후기입니다.
- 기술적 완성도 — 실제 기능보다 겉으로 보이는 화려한 데모가 더 높은 평가를 받음
- 평가 방식의 한계 — 심사위원들이 짧은 시간 내에 코드를 검토하므로 깊이 있는 기능 구현은 무시됨
- 발표와 네트워킹 — 기술적 복잡성보다 심사위원의 눈길을 끄는 마케팅 요소가 우승에 결정적임
- 해커톤의 본질 — 제품 개발보다는 아이디어를 판매하는 피칭 대회에 가까운 성격
최근에 Claude OC Impact Lab 해커톤에 다녀왔는데, 소프트웨어 엔지니어로서 해커톤을 바라보는 관점이 완전히 바뀌어버렸다.
난 원래 해커톤이 무슨 과학 전람회 같은 건 줄 알았다. 실용성, 정확성, 그리고 문제를 얼마나 잘 해결했는지를 기준으로 평가받는 그런 자리 말이다.
근데 막상 가보니까 전혀 아니더라.
참가한 31개 팀 중 29개 팀이 똑같은 과제를 골랐다. 의료진이 15~35페이지짜리 의료 문서를 검토해서 환자가 회복 치료 대상자인지 빠르게 판단할 수 있게 돕는 '진료 의뢰 접수 시스템'을 만드는 거였다.
평가 기준은 당장 현장에서 쓸 수 있는 임팩트, 사용성, 그리고 데모의 명확성이었다.
근데 내가 보기에 주최 측은 제출된 코드베이스를 Claude로 분석해서 평가했는데, 35개 팀 정도를 2시간도 안 되는 시간에 다 심사했다. 실제 기능이나 정확성을 얼마나 꼼꼼하게 따져봤을지 의문이 들 수밖에 없다.
제일 어이없었던 건, 우승한 두 팀의 결정적인 차별점이 웹사이트에 스페인어 지원을 추가한 거였다는 점이다.
오해는 마라. 다국어 접근성 좋은 거 맞고, 내가 만든 결과물에 그 기능을 넣었어도 우승 못 했을 거라는 건 안다. 근데 애초에 이 시스템의 주 사용자는 환자가 아니라 진료 의뢰 코디네이터였다. 인터페이스 번역하는 게 대체 자격 판정이나 처리 속도, 정확도랑 무슨 상관이 있냐? 특히 AI 써서 다국어 지원 넣는 건 일도 아닌데 말이다.
이번에 확실히 깨달은 점들이다:
-
실제 기능보다 '기능이 있어 보이는 것'이 훨씬 중요하다. 화려한 데모에 기능 잔뜩 때려 박은 게, 작지만 탄탄한 솔루션보다 훨씬 잘 먹힌다.
-
쉽지만 겉보기에 그럴싸한 기능이 가성비가 미쳤다. 반면 에러 핸들링, 유효성 검사, 백엔드 안정성 같은 건 눈에 보이지도 않는다.
-
발표랑 네트워킹이 전부다. 주최 측이랑 노가리 까면서 걔네가 뭘 좋아하는지 파악하는 게 기술적인 복잡함보다 훨씬 가치 있다.
-
팀원 잘 뽑아라. 하루짜리 해커톤에서 개발은 안 하고 회의만 하다가 시간 다 보내는 건 진짜 아니다.
아이러니한 건, 해커톤에서 우승하는 게 오히려 좋은 소프트웨어 엔지니어링과는 정반대의 길을 걷게 만든다는 거다. 안정성보다는 기능 추가, 기능보다는 겉모습, 정확성보다는 발표 실력이 우선시되니까.
심사위원들 시간이 부족하다는 건 이해하고, 우승 팀들이 자격이 없다는 건 아니다. 내가 못 본 그 팀들만의 강점이 있었을 수도 있겠지.
하지만 나는 진짜 쓸모 있는 걸 만들어보겠다고 갔다가, 해커톤은 결국 아이디어를 파는 장사라는 걸 깨닫고 돌아왔다.
원래 해커톤이 다 이런 거냐? 특히 비기술직이 심사하는 곳들은 더 심한 거냐?
