소프트웨어 잼(Jam)이 망가진 이유, 그리고 다시 살릴 수 있을까
AI 기반 ChatGPT 래퍼가 심사위원들의 눈을 사로잡아 해커톤 우승을 가져가는 풍경, 이제는 낯설지 않다. 열정을 쏟아 만든 프로젝트보다 그럴싸한 데모 하나가 더 높은 평가를 받는 현실은 소프트웨어 잼 문화 자체를 흔들고 있다. 게임 잼(Game Jam)은 여전히 활발하게 운영되는데, 왜 소프트웨어 잼만 이토록 어색해졌을까?
문제의 핵심은 평가 기준의 붕괴다. 게임 잼은 플레이어블한 결과물이 있고, 심사 기준이 명확하며, 직접 플레이해보는 검증이 가능하다. 반면 소프트웨어 잼은 "인상적인 데모"가 곧 평가 기준이 되어버렸고, AI 도구의 급속한 발전으로 인해 실제 개발 역량과 무관하게 그럴듯한 프로덕트처럼 보이는 것을 만드는 일이 너무 쉬워졌다. 컴파일러를 AI로 단번에 완성할 수 없다는 사실처럼, 소프트웨어가 해결된 문제가 아님에도 불구하고 해커톤 현장에서는 그 복잡성이 보이지 않는다.
운영자 입장에서 마주하는 현실적인 어려움
해커톤을 직접 운영하는 입장에서는 평가 문제 외에도 재원 확보라는 근본적인 문제가 따라온다. 일반적인 해커톤 운영 파이프라인은 지역 기업들을 설득해 스폰서십을 유치하는 방식이었다. 하지만 AI 붐과 기술 업계의 구조적 변화 이후, 이 경로가 예전만큼 작동하지 않는다.
비영리 단체처럼 펀딩 구조가 정해진 경우에는 제약이 더욱 뚜렷하다. 참가자가 실제로 코딩에 투자한 시간에 비례해 상금을 배분하는 방식을 택할 경우, 시간 측정 자체가 새로운 문제가 된다. 자기 보고(self-report) 방식은 인센티브가 생기는 순간 신뢰성을 잃는다. 더 많은 시간을 기록할수록 더 많은 보상을 받는다면, 정확한 측정이 아닌 허수 입력이 발생하는 건 자연스러운 결과다.
그래도 소프트웨어 잼을 포기하지 않으려면
이 문제를 정면으로 다루려면 평가 방식의 재설계가 필요하다. 몇 가지 실무적 방향을 생각해볼 수 있다.
- 결과물 중심 검증 강화: 데모가 아닌 실제 코드 실행, 빌드 과정, 기술적 의사결정 설명을 평가에 포함
- 시간 측정의 객관화: 커밋 히스토리, IDE 플러그인 기반 활동 로그 등 자기 보고 외 보조 수단 활용
- 주제 제약 설계: 특정 저수준 기술 스택 사용, 외부 API 제한 등 AI 위임이 어려운 조건 부여
- 게임 잼 구조 벤치마킹: 플레이어블한 결과물처럼 명확히 체험 가능한 산출물 정의
# 예: 커밋 기반 활동 시간 간이 산정
git log --oneline --after="2025-06-01" --before="2025-06-03" \
--format="%ad" --date=format:"%Y-%m-%d %H:%M" | head -20
물론 이것이 완전한 해답은 아니다. 그러나 규칙 설계 단계에서부터 "무엇을 측정할 것인가"를 명확히 하지 않으면, 어떤 형태의 잼도 왜곡된 인센티브 앞에서 무너지기 쉽다.
정리
- AI 도구의 확산으로 소프트웨어 해커톤의 평가 기준이 실질적으로 붕괴되었으며, 결과물의 진정성을 판별하기 어려워졌다
- 자기 보고 방식의 시간 측정은 인센티브 구조와 결합될 경우 신뢰성을 잃으므로, 객관적 측정 보조 수단이 필요하다
- 잼을 다시 의미 있게 만들려면 평가 설계 단계에서 "무엇을 측정할 것인가"를 명확히 정의하는 것이 핵심이다