해커톤 아이디어은(는) 무엇을 하나요?
우리는 특정 사용자를 위해 실제 문제의 근본 원인을 해결하는 아이디어를 만듭니다. 그 문제의 존재를 입증하는 증거와 기존의 일반적인 접근 방식이 실패하는 지점에서 이 해결책을 작동하게 만드는 인사이트(비자명한 사실)에 기반합니다. 작고 단순한 것은 환영하지만, 평범한 것은 환영하지 않습니다. 아이디어가 자리 잡으려면 해커톤이 끝난 후에도 여전히 의미가 있어야 하며, 심사위원이 트랙 이름만으로는 그 아이디어를 짐작할 수 없어야 합니다.
해커톤은 심사 기준, 마감 기한 안에서, 그리고 데모 순간(비디오나 라이브 데모에서 심사위원이 결과물이 작동하는 모습을 보고 이해하는 몇 초)을 통해 승부가 결정됩니다. 해커톤에 관한 모든 사실은 공식 페이지에서 가져오며, 링크로 출처를 밝힙니다.
단계
- 브리프 읽기. 공식 해커톤 페이지, 규칙 및 FAQ(링크가 없으면 요청)에서 출처 링크와 함께 다음을 기록합니다: 트랙과 상금, 심사 기준 및 가중치, 필수 또는 스폰서 기술, 자격 요건 및 실격 조건(팀 규모, 기존 코드, 지역, 라이선스), 제출 요구사항(비디오 길이, 저장소, 라이브 데모, 문서), 마감 기한과 남은 시간. 그런 다음 브리프만으로 알 수 없는 내용(팀 규모와 기술, 사용 가능한 시간, 직접 알고 있는 도메인 또는 선호하는 트랙)을 최대 3개의 질문으로 사용자에게 묻습니다. 위의 모든 항목이 인용된 값으로 채워지거나 "공개되지 않음"으로 표시되면 완료됩니다. 심사 기준이 공개되지 않은 경우, 해커톤 평가표에서 흔히 사용되는 네 가지 동등한 기준(아이디어 독창성, 기술 구현, 잠재적 영향력, 디자인 및 발표)을 사용하고 출력물에서 이를 우리의 대체 기준임을 표시합니다.
- 자명한 목록 작성. 조사 전에, 대부분의 팀이 이 트랙과 기술로 제출할 10가지 아이디어(누구나 먼저 떠올릴 법한 것)를 작성합니다. 이 아이디어들과 그와 약간 다른 변형은 5단계에서 제외됩니다.
- 실제 문제 찾기. 이것이 가장 깊이 있는 단계이며, 가장 많은 노력을 기울여야 합니다. 트랙과 팀의 직접 경험이 가리키는 도메인 내에서 사람들이 자신의 문제를 자신의 언어로 설명하는 곳으로 가십시오: 포럼, 서브레딧, GitHub 이슈, 지원 및 커뮤니티 스레드, 앱 스토어 리뷰, 전문가 그룹, 공개 불만 및 규제 기관 보고서. 특히 **해결 방법(workarounds)**을 찾으십시오: 스프레드시트, 스크립트, 수동 이중 입력, 인쇄물, 그룹 채팅, 기계가 할 일을 하는 유급 도우미; 각 해결 방법은 사람들이 이미 시간을 지불하고 있는 문제를 나타냅니다. 각 문제에 대해, 증상이 아닌 구조적 원인에 도달할 때까지 "왜"를 반복해서 질문합니다. 메모에 최소 10개의 개별 문제가 있고, 각각 특정 사용자와 상황이 있으며, 적어도 하나의 인용문 또는 데이터 포인트와 링크, 현재 사용하는 해결 방법, 근본 원인이 있으면 완료됩니다.
- 분야 조사. 이 해커톤 또는 시리즈의 과거 수상작(예: Devpost의 프로젝트 갤러리), 스폰서의 최근 출시 및 필수 기술에 대한 언급된 바람, 그리고 현재 에디션에 이미 제출된 공개 출품작을 읽습니다. 메모에 링크와 함께 최소 5개의 과거 또는 현재 프로젝트와 스폰서의 명시된 우선순위가 나열되면 완료됩니다.
- 생성한 후 엄격히 제거. 3단계의 각 문제에서 하나씩 구축된 최소 20개의 아이디어를 작성합니다.
각 아이디어는 다음을 명시합니다: 사용자와 상황, 증거 링크, 제거하는 근본 원인, 인사이트, 수행하는 작업, 데모 순간, 그리고 필수 기술이 없이는 해결책이 할 수 없는 것에 기여하는 바.
그런 다음 각 아이디어에 대해 한 줄의 이유와 함께 다음에 해당하는 모든 아이디어를 제거합니다:
- 자명한 목록에 있거나 그와 약간 다른 변형인 경우;
- 특정 사용자와 상황을 명시할 수 없거나 증거 링크가 없는 경우;
- 근본 원인은 그대로 두고 증상만 치료하는 경우;
- 얇은 포장지(wrapper)에 불과하여 필수 기술이나 AI를 큰 손실 없이 양식, 검색 상자 또는 템플릿으로 대체할 수 있는 경우;
- 누구나 먼저 말할 법한 인사이트를 가진 경우;
- 기존 제품, 과거 수상작 또는 현재 출품작과 매우 유사한 경우(가장 가까운 이웃을 검색하여 기록);
- 규칙을 위반하거나, 남은 시간 안에 이 팀의 기술로 작동하는 데모 순간에 도달할 수 없는 경우. 모든 아이디어가 이유와 함께 제거되거나 유지되고, 최소 5개가 유지되면 완료됩니다. 생존자가 더 적을 경우, 기준을 완화하는 대신 3단계로 돌아가 더 많은 문제를 찾습니다.
- 생존자 점수 매기기. 유지된 각 아이디어에 대해 모든 심사 기준에 1~5점을 부여하고, 해커톤의 가중치와 점수당 한 줄의 정당성을 기재하며, 또한 우리 고유의 기준 세 가지(깊이-증거의 강도와 근본 원인을 얼마나 완전히 제거하는지, 남은 시간 안에 구축 가능성, 데모 강도)를 추가합니다. 가중 심사 점수에 깊이를 더한 값으로 순위를 매기고, 동점 시 구축 가능성으로 순위를 결정합니다.
- 최종 후보 목록 작성. 상위 3개 아이디어에 대해 다음을 작성합니다:
- 피치: 심사위원이 반복할 한 문장.
- 문제: 사용자, 상황, 링크가 포함된 증거 인용문, 현재의 해결 방법, 근본 원인.
- 인사이트: 비자명한 사실과 기존 도구가 이를 놓치는 이유.
- 가장 가까운 유사 제품: 발견된 가장 유사한 기존 제품 또는 프로젝트와 구체적인 차이점.
- 대상: 경쟁하는 트랙과 상금.
- 점수: 6단계의 점수 표.
- 데모 스크립트: 비디오의 처음 30초 동안 발생하는 일, 사용자의 문제와 그 해결을 보여줌.
- 컷 라인: 데모를 위해 반드시 작동해야 하는 것과 있으면 좋은 것. 시간이 부족할 때 팀이 무엇을 포기해야 하는지 알 수 있도록 합니다.
- 가장 위험한 가정: 실패할 가능성이 가장 높은 기술적 또는 제품적 가정과, 전념하기 전에 한 시간 이내에 이를 테스트하는 스파이크(spike).
출력
해커톤당 하나의 파일을 docs/hackathons/<이벤트-슬러그>.md에 작성하고, 이후 실행 시 업데이트합니다: 링크가 포함된 브리프, 자명한 목록, 증거가 있는 문제 메모, 분야 조사, 제거 이유가 있는 모든 생성된 아이디어, 점수 표, 최종 후보 목록.
세션 중에는 최종 후보 목록과 마감일을 보여주고, 사용자에게 하나의 아이디어를 선택하도록 요청합니다.
팀이 아이디어에 전념하면, 심사위원 외의 사람이 사용하기 전에 app-compliance 스킬을 통과하고, showcase 스킬이 데모 비디오와 README를 제출용으로 만듭니다.