Web3 해커톤 정석: 2025년을 위한 실무 플레이북
· 약 10 분
요약
- 의도적으로 이벤트를 선택하세요. 이미 프로젝트를 빌딩하고 있는 에코시스템이나, 자신의 아이디어와 완벽하게 일치하는 심사위원 및 스폰서가 있는 이벤트를 선호하세요.
- 승리 조건을 결정하세요. 학습이 목적인가요, 특정 바운티인가요, 아니면 결승 진출인가요? 각 선택에 따라 팀 구성, 프로젝트 범위, 기술 스택이 달라집니다.
- 지루한 작업은 미리 준비하세요. 시간이 시작되기 전에 프로젝트 스캐폴드, 인증 플로우, 지갑 연결, 디자인 시스템, 데모 스크립트 초안을 미리 준비해 두세요.
- 가장 작고 매력적인 데모를 만드세요. 엔드 투 엔드로 작동하는 하나의 핵심 기능 루프를 보여주세요. 그 외의 모든 것은 내러티브와 슬라이드일 뿐입니다.
- 프로처럼 제출하세요. "새로 시작하기 (start fresh)" 규칙을 준수하고, 목표로 하는 모든 바운티 트랙에 공식적으로 등록하며, 간결한 영상과 명확한 README를 작성하기 위해 충분한 시간을 할애하세요.
Web3 해커톤이 주말을 투자할 가치가 있는 이유
- 압축된 학습: 단 한 번의 주말 동안 인프라, 스마트 컨트랙트, 프론트엔드 UX, 배포 파이프라인을 모두 다루게 됩니다. 이는 보통 몇 달이 걸릴 학습 곡선을 48시간 만에 완수하는 전체 개발 사이클입니다.
- 양질의 네트워킹: 멘토, 심사위원, 스폰서 엔지니어들은 웹사이트에 적힌 이름일 뿐만 아니라, 한 공간이나 Discord 서버에 모여 피드백을 줄 준비가 되어 있는 사람들입니다. 이는 여러분이 매일 사용하는 프로토콜의 핵심 개발자들과 직접 소통할 수 있는 기회입니다.
- 실제 펀딩 경로: 이것은 단지 명예만을 위한 것이 아닙니다. 상금 풀과 후속 그랜트는 프로젝트를 지속할 수 있는 의미 있는 자본을 제공할 수 있습니다. Solana의 Summer Camp와 같은 이벤트는 최대 500만 달러의 상금과 시드 펀딩을 제공하여 주말 프로젝트를 유망한 스타트업으로 탈바꿈시켰습니다.
- 증명된 포트폴리오: 기능적인 데모가 포함된 공개 GitHub 리포지토리는 이력서의 한 줄보다 훨씬 더 가치 있습니다. 이는 압박 속에서도 아이디어를 구축하고, 출시하고, 명확하게 설명할 수 있다는 실질적인 증거가 됩니다.
좋은 해커톤을 찾을 수 있는 곳
- ETHGlobal: 온/오프라인 이벤트 모두를 아우르는 골드 표준입니다. 견고한 심사 과정, 수준 높은 참가자, 영감을 얻기에 완벽한 공개 프로젝트 쇼케이스를 제공합니다.
- Devpost: 블록체인, 특정 프로토콜, 상금 트랙에 대한 강력한 필터링 기능을 갖춘 모든 종류의 해커톤을 위한 광범위한 마켓플레이스입니다. 에코시스템별 이벤트를 발견하기에 좋은 곳입니다.
- DoraHacks: 에코시스템 중심의 Web3 해커톤과 그랜트 라운드에 집중하는 플랫폼으로, 글로벌하고 커뮤니티 중심적인 분위기가 특징입니다.
팁: 기간은 매우 다양합니다. ETHOnline과 같은 장기 온라인 이벤트는 몇 주 동안 진행되는 반면, ETHDenver의 #BUIDLathon과 같은 연장된 오프라인 스프린트는 최대 9일 동안 지속될 수 있습니다. 프로젝트의 범위를 기간에 맞춰 계획해야 합니다.
규칙 해석 (실격 방지를 위해)
- "새로 시작하기 (Start Fresh)." 가장 일반적이고 중요한 규칙입니다. 대부분의 이벤트는 모든 실질적인 작업이 공식 시작 _이후_에 이루어질 것을 요구합니다. 핵심 로직에 이전에 작성된 코드를 사용하면 결승이나 파트너 상에서 실격될 수 있습니다. 보일러플레이트는 보통 허용되지만, 핵심 차별화 요소는 새로 개발해야 합니다.
- 심사 구조. 심사 과정을 이해하세요. 종종 비동기 스크리닝 라운드를 통해 수백 개의 프로젝트를 결승 진출 풀로 압축한 후 라이브 심사가 시작됩니다. 이를 알면 첫 번째 선발을 통과하기 위해 제출 영상과 README를 최대한 명확하게 만드는 데 집중할 수 있습니다.
- 팀 규모. 10명의 팀원으로 참여하지 마세요. 많은 이벤트가 제한을 둡니다. 예를 들어 ETHDenver에서 흔히 볼 수 있는 2 ~ 4명 규모의 팀이 일반적입니다. 이는 공정한 경쟁을 보장하고 긴밀한 협력을 장려합니다.
- 바운티 메커니즘. 등록하지 않은 상은 받을 수 없습니다. 스폰서 바운티를 목표로 한다면, 이벤트 플랫폼을 통해 각 특정 상에 프로젝트를 공식적으로 등록해야 하는 경우가 많습니다. 이는 많은 팀이 간과하는 간단하지만 중요한 단계입니다.
심사 기준: "좋은" 프로젝트의 모습
주요 주최측 전반에 걸쳐 심사위원들은 일반적으로 네 가지 항목을 통해 프로젝트를 평가합니다. 각 항목에서 높은 점수를 얻을 수 있도록 프로젝트 범위와 데모를 설계하세요.
- 기술력 (Technicality): 해결하려는 문제가 사소하지 않은가요? 솔루션에 기술의 독창적이거나 우아한 사용이 포함되어 있나요? 단일 스마트 컨트랙트 위에 단순한 프론트엔드 래퍼를 씌운 수준을 넘어섰나요?
- 독창성 (Originality): 새로운 메커니즘, 고유한 사용자 경험 또는 기존 프리미티브의 영리한 리믹스가 있나요? 이전에도 수백 번 본 것인가요, 아니면 신선한 시각을 제시하나요?
- 실용성 (Practicality): 누군가가 오늘 바로 이것을 사용할 수 있나요? 범위가 좁더라도 완전한 엔드 투 엔드 사용자 여정을 갖추는 것이 광범위하지만 미완성인 기능을 가진 프로젝트보다 훨씬 중요합니다.
- 사용성 (UI/UX/DX): 인터페이스가 명확하고 빠르며 사용하기 즐거운가요? 개발자 도구의 경우, 개발자 경험 (DX)은 얼마나 우수한가요? 매끄러운 온보딩과 명확한 에러 처리는 프로젝트를 돋보이게 할 수 있습니다.
팀 설계: 작고, 날카롭고, 상호 보완적인 구성
속도와 조율을 위해 2 ~ 4 명의 팀이 가장 이상적입니다. 업무를 병렬로 진행하기에 충분히 크면서도, 끝없는 논쟁 없이 신속하게 의사결정을 내릴 수 있을 만큼 작기 때문입니다.
- 스마트 컨트랙트 / 프로토콜: 온체인 로직을 담당합니다. 컨트랙트 작성, 테스트 및 배포를 책임집니다.
- 프론트엔드 / DX: 사용자 인터페이스를 구축합니다. 지갑 연결, 데이터 페칭, 에러 상태 관리, 그리고 프로젝트를 실감 나게 만드는 최종 데모의 완성도를 책임집니다.
- 제품 / 스토리: 범위 (Scope) 관리자이자 내레이터입니다. 팀이 핵심 루프에 집중하도록 유지하고, 프로젝트 설명을 작성하며, 최종 데모를 진행합니다.
- (선택 사항) 디자이너: 전담 디자이너는 프로젝트의 인지적 품질을 높여주는 컴포넌트, 아이콘, 마이크로 인터랙션을 준비하는 강력한 무기가 될 수 있습니다.
아이디어 선정: P-A-C-E 필터
단 한 줄의 코드를 작성하기 전에, 이 간단한 필터를 사용하여 아이디어를 검증해 보세요.
- 고통 (Pain): 이것이 개발자나 사용자의 실제 페인 포인트를 해결합니까? 지갑 UX, 데이터 인덱싱, MEV 보호 또는 수수료 추상화 등을 생각해 보세요. 문제를 찾고 있는 해결책은 피해야 합니다.
- 원자성 (Atomicity): 48 시간 내에 단일한 원자적 루프를 처음부터 끝까지 구축하고 데모할 수 있습니까? 전체 비전이 아니라, 하나의 완전하고 만족스러운 사용자 작업이면 충분합니다.
- 조합성 (Composable): 오라클, 계정 추상화 또는 크로스 체인 메시징과 같은 기존 프리미티브를 활용합니까? 이미 검증된 레고 블록을 사용하면 더 멀리, 더 빨리 갈 수 있습니다.
- 생태계 적합성 (Ecosystem fit): 프로젝트가 행사의 심사위원, 스폰서 및 청중에게 가시적이고 관련성이 있습니까? 게이밍 중심 트랙에서 복잡한 DeFi 프로토콜을 제안하지 마세요.
상금 (Bounty) 이 목적이라면, 하나의 주요 스폰서 트랙과 하나의 보조 스폰서 트랙을 선택하세요. 너무 많은 바운티에 집중을 분산시키면 깊이가 얕아지고 수상 가능성도 낮아집니다.
개발 속도를 늦추지 않는 기본 스택
참신함은 '어떻게' 만드느냐가 아니라 '무엇을' 만드느냐에 있어야 합니다. 지루하지만 신뢰할 수 있는 기술을 고수하세요.
EVM 트랙 (빠른 경로)
- 컨트랙트: Foundry (테스트, 스크립트 작성 및 로컬 노드 실행 속도가 빠름).
- 프론트엔드: Next.js 또는 Vite, 그리고
wagmi또는viem과 RainbowKit 또는 ConnectKit 같은 지갑 키트를 결합하여 모달과 커넥터를 구성합니다. - 데이터 / 인덱싱: 과거 데이터를 쿼리해야 하는 경우 호스팅된 인덱서나 서브그래프 서비스를 사용하세요. 자체 인프라를 직접 운영하는 것은 피하세요.
- 오프체인 트리거: 단순한 잡 러너 (Job runner) 나 전용 자동화 서비스를 사용하세요.
- 스토리지: 자산 및 메타데이터는 IPFS 또는 Filecoin 을, 세션 상태는 단순한 KV 스토어를 사용하세요.
Solana 트랙 (빠른 경로)
- 프로그램: Anchor (상용구 코드를 줄이고 더 안전한 기본 설정의 이점을 누림).
- 클라이언트: React 또는 Solana Mobile SDK 가 포함된 모바일 프레임워크. RPC 및 프로그램 호출을 위해 간단한 훅 (hook) 을 사용하세요.
- 데이터: 직접 RPC 호출이나 생태계 인덱서에 의존하세요. UI 를 기민하게 유지하기 위해 적극적으로 캐싱하세요.
- 스토리지: 필요한 경우 영구적인 자산 저장을 위해 Arweave 또는 IPFS 를 사용하세요.
현실적인 48 시간 계획
T-24 ~ T-0 (시작 전)
- 승리 조건 (학습, 바운티, 결선 진출 등) 과 타겟 트랙을 정렬합니다.
- 종이나 화이트보드에 전체 데모 루프를 스케치합니다. 각 단계에서 무엇을 클릭할지, 온체인과 오프체인에서 어떤 일이 일어나야 하는지 정확히 파악하세요.
- 컨트랙트와 프론트엔드 앱 모두를 위한 보일러플레이트가 포함된 깨끗한 모노레포 스캐폴드를 포크합니다.
- README 개요와 데모 스크립트 초안을 미리 작성합니다.
0 ~ 6 시간
- 행사 멘토 및 스폰서에게 범위 (Scope) 를 확인받습니다. 바운티 기준을 확인하고 아이디어가 적합한지 확신을 얻으세요.
- 엄격한 제약 조건을 설정하세요: 하나의 체인, 하나의 주요 사용 사례, 그리고 데모를 위한 하나의 "와우 (wow)" 포인트.
- 업무를 90 분 단위의 스프린트로 나눕니다. 목표는 6 시간 이내에 핵심 루프의 첫 번째 수직 슬라이스 (Vertical Slice) 를 완성하는 것입니다.
6 ~ 24 시간
- 핵심 경로를 강화합니다. 정상적인 경로 (Happy path) 와 일반적인 예외 상황을 모두 테스트하세요.
- 관측성 (Observability) 을 추가합니다. 신속하게 디버깅할 수 있도록 기본적인 로그, UI 토스트, 에러 바운더리를 구현하세요.
- 프로젝트의 "이유 (Why)" 를 명확하게 설명하는 최소한의 랜딩 페이지를 만듭니다.
24 ~ 40 시간
- 핵심 기능이 안정화되는 즉시 백업 데모 영상을 녹화하세요. 마지막 순간까지 기다리지 마세요.
- 최종 제출 텍스트, 비디오 및 README 를 작성하고 편집하기 시작합니다.
- 시간이 허락한다면 빈 상태 (Empty states) 처리, 가스비 없는 트랜잭션, 또는 문서 내의 유용한 코드 스니펫과 같이 세심한 디테일을 한두 개 추가하세요.
40 ~ 48 시간
- 모든 기능을 동결 (Freeze) 합니다. 더 이상의 새로운 코드는 없습니다.
- 비디오와 제출 패키지를 마무리합니다. 노련한 수상자들은 전체 시간의 약 15 % 를 다듬기와 비디오 제작에 할애할 것을 권장하며, 비디오는 문제 설명과 솔루션 데모를 60 / 40 비율로 구성하는 것이 좋습니다.
데모 및 제출: 심사위원을 편하게 만들기
- "이유" 로 시작하세요. 비디오와 README 의 시작 부분에 문제와 솔루션의 결과를 설명하는 한 문장을 넣으세요.
- 루프를 직접 보여주세요. 말로만 설명하지 말고 보여주세요. 단계를 건너뛰지 않고 처음부터 끝까지 신뢰할 수 있는 단일 사용자 여정을 따라가세요.
- 제약 조건에 대해 설명하세요. 구축하지 않은 부분과 그 이유를 인정하세요. "실제 사용자가 오늘 바로 플로우를 완료할 수 있도록 이 단일 사용 사례로 범위를 제한했습니다" 라고 말하는 것은 집중력과 성숙도를 보여줍니다.
- 명확한 표식을 남기세요. README 에는 아키텍처 다이어그램, 라이브 데모 및 배포된 컨트랙트 링크, 그리고 프로젝트를 로컬에서 실행하기 위한 간단한 원클릭 단계가 포함되어야 합니다.
- 비디오 기본 사항. 비디오를 미리 계획하고, 스크립트를 촘촘하게 짜고, 프로젝트가 무엇을 하는지, 어떤 문제를 해결하는지, 내부적으로 어떻게 작동하는지 명확하게 강조해야 합니다.
번아웃 없는 바운티 도전
- 목표로 하는 각 시상 항목 (prize) 에 등록하세요. 일부 플랫폼에서는 명시적으로 "작업 시작 (Start Work)" 버튼 클릭이 필요할 수 있습니다.
- 기술 스택에서 해당 기술들이 자연스럽게 겹치지 않는 한, 두 개 이상의 스폰서 바운티를 쫓지 마세요.
- 제출물에 그들의 심사 기준 (rubric) 을 반영하세요. 그들의 키워드를 사용하고, API 를 이름으로 참조하며, 특정 성공 지표를 어떻게 충족했는지 설명하세요.
해커톤 이후: 추진력을 트랙션 (traction) 으로 전환하기
- 데모 링크와 GitHub 레포지토리가 포함된 짧은 블로그 포스트 및 소셜 미디어 스레드를 게시하세요. 행사와 스폰서를 태그하세요.
- 해커톤 참가자 및 초기 단계 오픈 소스 프로젝트를 위해 설계된 그랜트 (grant) 와 액셀러레이터 라운드에 지원하세요.
- 반응이 좋다면 버그 수정, UX 개선, 소수의 사용자를 대상으로 한 작은 파일럿에 집중한 간단한 1주일 로드맵을 작성하세요. 추진력을 유지하기 위해 v0.1 릴리스 날짜를 확정하세요.
흔한 실수들 (그리고 해결책)
- "처음부터 시작 (start fresh)" 규칙 위반. 해결책: 이전 코드는 범위에서 완전히 제외하거나, 사용 중인 기존 라이브러리임을 명시적으로 선언하세요.
- 과도한 범위 설정 (Over-scoping). 해결책: 계획된 데모에 세 가지 주요 단계가 있다면 하나를 삭제하세요. 핵심 루프 (core loop) 에 집중하는 데 냉정해져야 합니다.
- 너무 이른 멀티 체인 확장. 해결책: 하나의 체인에서 완벽하게 출시 (ship) 하세요. 브릿지 및 크로스 체인 지원 계획은 README 의 "향후 계획 (What's next)" 섹션에서 언급하세요.
- 마지막 순간의 다듬기 비용 (polish tax). 해결책: 해커톤 종료 전 4~6시간을 README, 영상, 제출 양식 작성만을 위해 전용으로 할당하세요.
- 바운티 등록 누락. 해결책: 해커톤 시작 직후 가장 먼저 해야 할 일 중 하나로 설정하세요. 스폰서가 팀을 찾아 지원할 수 있도록 잠재적인 모든 시상 항목에 미리 등록하세요.
복사 가능한 체크리스트
제출 패키지
- 레포지토리 (MIT/Apache-2.0 라이선스), 간결한 README 및 로컬 실행 단계
- 짧은 Loom/MP4 데모 영상 + 백업 녹화본
- 간단한 아키텍처 다이어그램 (슬라이드 한 장 또는 이미지)
- 원페이저 (One-pager): 문제 → 해결책 → 가치 제안 → 향후 계획
- 링크: 라이브 프론트엔드, 블록 익스플로러 상의 컨트랙트 주소
오프라인 (IRL) 준비물 목록
- 멀티탭과 연장 코드
- 헤드폰 및 적절한 마이크
- HDMI/USB-C 디스플레이 동글
- 재사용 가능한 물병과 전해질 음료
- 선호하는 편안한 키보드/마우스 (민감한 경우)
규정 준수 확인
- 처음부터 시작 (Start-fresh) 정책 이해 및 준수
- 팀 규모가 행사 제한 범위 내에 있는지 확인 (해당하는 경우)
- 심사 흐름 (비동기 vs 라이브) 확인
- 모든 목표 바운티가 공식적으로 등록됨 ("작업 시작" 또는 그에 준하는 단계)
다음 해커톤을 위한 유용한 링크
- 행사 찾기: ETHGlobal 행사 캘린더, Devpost 블록체인 허브, DoraHacks 에서 다가오는 대회를 확인하세요.
- 영감 얻기: ETHGlobal Showcase 를 탐색하여 우승 데모를 확인하고 코드를 살펴보세요.
- EVM 스캐폴딩: Foundry 문서와 퀵스타트 가이드를 검토하세요.
- Solana 스캐폴딩: Anchor 문서와 "기본 (basics)" 가이드를 확인하세요.
- 영상 팁: 명확하고 설득력 있는 데모 영상을 제작하는 방법에 대한 가이드를 검색해 보세요.
마지막 노트
해커톤은 제약 속에서의 명확함에 보답합니다. 좁은 범위의 문제를 선택하고, 익숙한 도구에 의존하며, 단 하나의 즐거운 엔드 투 엔드 (end-to-end) 경험을 만드는 데 집중하세요. 그렇게 한다면 이번에 우승자 명단에 이름이 오르지 않더라도 엄청난 양을 배우게 될 것입니다. 그리고 만약 우승한다면, 충분히 그럴 자격이 있을 것입니다.