주말 48시간으로
해커톤 참가한 경험담
금요일 밤 9시 시작, 일요일 오후 9시 데모 — 그 사이에 있었던 일들
왜 해커톤이었나
해커톤 참가를 결심한 건 지인의 한 마디였다. "48시간 안에 뭔가를 만들어서 발표한다는 게 신기하지 않아?" 신기했다. 동시에 무섭기도 했다. 실무에서 기능 하나 만드는 데 스프린트 2주가 걸리는데, 48시간 안에 제품을 만든다는 게 가능하기나 한 건지 궁금했다.
팀 구성은 커뮤니티 오픈채팅방에서 모집했다. "해커톤 같이 할 분 구합니다, 프론트엔드 현직자"라고 올렸더니 하루 만에 세 명이 연락왔다. 백엔드 개발자 한 명, 디자이너 한 명, 그리고 기획 경험 있는 개발자 한 명. 처음 만나는 사람들과 48시간을 보내야 했다.
팀원 구성
처음 보는 사람들이었는데 각자 역할이 명확했던 게 다행이었다. 해커톤 팀 구성에서 가장 중요한 건 기술 스택보다 "이 사람이 갑자기 나가도 나머지가 완성할 수 있냐"다. 4명 전원이 할 수 있는 게 있어야 한다.
48시간 실시간 기록
21:00
주제: "일상의 불편함을 해결하는 AI 서비스". 팀원 넷이서 포스트잇 한 판. 아이디어 20개 나왔고, 30분 투표로 세 개로 좁혔다. "회의록 자동 요약 AI", "냉장고 사진으로 레시피 추천", "한국어 이메일 영문 번역 + 톤 조정". 마지막 것으로 결정.
22:30
Next.js 14 App Router + Supabase + Claude API. 소연이 Figma에서 와이어프레임 시작. 준혁이 백엔드 엔드포인트 설계. 나는 레포 초기 세팅 + 공통 컴포넌트. 민수는 PRD(제품 요구사항) 문서를 노션에 정리했다.
01:00
이메일 입력 → AI 번역 → 톤 선택 → 결과 출력 흐름이 대략 돌아갔다. Claude API 연동이 생각보다 빨리 됐다. 팀이 처음 만나는 사람들이라 커뮤니케이션 오버헤드가 있었지만, 각자 역할이 명확해서 블로킹이 적었다.
03:30
특정 이메일 내용에서 번역 결과가 빈 문자열로 오는 버그. 원인을 30분 동안 못 잡았다. 나중에 알고 보니 Claude API 프롬프트에서 특수문자 처리 이슈였다. 그 30분이 새벽 3시 반에 가장 긴 시간처럼 느껴졌다.
05:00
소연과 민수가 먼저 쉬고, 나와 준혁이 코드 유지. 2시간 후 교대. 미리 협의하지 않았는데 자연스럽게 나왔다. 해커톤에서 팀워크가 가장 빛나는 순간이었다.
09:00
메인 번역 기능 완성. 이력 저장, 즐겨찾기, 팀 공유 기능 논의. 민수가 "지금 있는 거 제대로 만드는 게 낫다"고 했다. 맞는 말이었다. 3개 추가 기능 중 1개(이력 저장)만 선택하고 나머지는 버렸다.
15:00
소연이 Figma 컴포넌트를 코드에 반영했다. 기능 위주였던 화면이 실제 서비스처럼 보이기 시작했다. "이게 해커톤 수준이야?"라는 말이 팀에서 나왔다. 디자이너가 팀에 있을 때의 차이를 처음 실감했다.
18:00
Vercel 배포는 됐는데 Supabase 환경변수 설정이 누락됐다. 이력 저장 기능이 전부 500 에러. 발표 3시간 전. 준혁이 15분 만에 잡았다. 환경변수를 Production에만 설정하고 Preview에 안 넣은 거였다. 가슴이 한 번 내려앉았다.
21:00
민수가 발표를 맡았다. 문제 정의 1분, 데모 1분 30초, Q&A 30초. 심사위원이 "왜 이 문제를 골랐냐"고 물었다. 준비한 답이 있었다. 결과 발표에서 3위. 1위 팀은 뭔가를 만들지 않고 기존 API를 기가 막히게 조합한 서비스였다.
실제로 만든 것 — 코드 단편
export async function POST(req: Request) { const { email, tone } = await req.json() // 새벽 2시에 짠 프롬프트 — 지금 보면 개선할 게 10개는 됨 const prompt = ` 다음 한국어 이메일을 영어로 번역해줘. 톤: ${tone} (formal / casual / friendly) 이메일: ${email} 번역만 출력해. 설명 없이. ` const response = await fetch('https://api.anthropic.com/v1/messages', { method: 'POST', headers: { ... }, body: JSON.stringify({ model: 'claude-sonnet-4-6', max_tokens: 1000, messages: [{ role: 'user', content: prompt }] }) }) // try-catch 없음 ← 해커톤의 현실 const data = await response.json() return Response.json({ translated: data.content[0].text }) }
try-catch 없음, 타입 검증 없음, 에러 핸들링 없음, 환경변수 하드코딩 직전까지 감. 이게 48시간 코드의 현실이다. 실무라면 코드 리뷰에서 전부 반려됐을 코드. 그래도 동작했고, 발표에서 에러 하나 안 났다. 목적이 다른 코드다.
3위로 끝난 이유 — 솔직한 분석
1위 팀의 서비스는 기술적으로 우리보다 간단했다. 오히려 기존 API를 조합한 수준이었다. 그런데 문제 정의가 훨씬 구체적이었다. 타겟 사용자가 "중소기업 CS 담당자"로 명확했고, "하루에 100개 이상 들어오는 반복적인 CS 문의를 자동 분류하는" 문제를 풀었다.
우리 서비스는 "이메일 번역이 필요한 사람"이 타겟이었다. 너무 넓었다. 심사위원들이 "이거 누가 쓰냐"는 질문에 우리가 명확하게 답을 못 했다. 기능이 아니라 문제 정의가 더 중요했다.
해커톤에서 이기는 건 가장 많은 기능을 만드는 팀이 아니었다. 가장 선명한 문제를 푼 팀이었다.
48시간이 가르쳐준 것들
처음 아이디어는 항상 48시간보다 크다. 두 번째 날 아침에 "이것만 완성하자"를 결정하는 게 핵심이다. 추가 기능을 포기하는 용기가 제품을 완성시킨다.
"누가 왜 이게 필요한가"가 선명하지 않으면 심사위원이 "이거 왜 만들었어요?"를 묻는다. 기술은 도구고, 문제가 목적이다. 해커톤에서도, 실무에서도 같다.
갈등이 없었던 게 아니었다. 오후 5시에 기능 추가 여부로 잠깐 의견이 갈렸다. 그 순간 "우리 목표가 뭔지"로 돌아가는 게 해결책이었다.
해커톤에서 기술 결정은 10분 안에 난다. 실무에서 일주일 토론하는 것들이 "일단 해보자"로 결론 난다. 그리고 대부분 그게 맞다. 완벽보다 완성이 먼저다.
새벽 3시 반에 잡지 못한 버그를 2시간 자고 일어난 후 10분 만에 잡았다. 잠을 줄이면 더 만들 것 같지만, 피곤한 상태의 코드는 더 많은 버그를 만든다.
소연이 합류하기 전과 후의 화면이 완전히 달랐다. 심사위원들이 "완성도가 높다"고 한 게 디자이너의 기여였다. 스타트업에서 디자이너 없이 개발자만 있을 때 놓치는 것이 이거다.
다음 번에 달리 할 것들
아이디어 선정에 더 시간을 쓴다. 이번에 아이디어 고르는 데 30분을 썼다. 다음엔 1시간을 써도 아깝지 않다. 아이디어가 흔들리면 48시간 내내 흔들린다. "이 문제가 실제로 있는가", "우리가 이 기간 안에 풀 수 있는가" 두 가지를 철저히 검토해야 한다.
발표 연습을 빌드와 병행한다. 마지막 2시간 동안 발표 준비를 했는데, 그 시간이 많이 부족했다. 오후 6시부터 발표 스크립트를 짜고, 2시간에 한 번씩 30초 피치를 연습하는 루틴을 만들어야겠다.
MVP 범위를 더 좁게 잡는다. "이메일 번역"보다 "글로벌 고객한테 보내는 항의 이메일을 공손하게 영문으로"처럼 훨씬 좁게 잡았어야 했다. 좁을수록 문제가 선명하고, 선명한 문제가 심사위원을 설득한다.
결과보다 과정이 더 남는다. 3위를 했지만 그 48시간에서 얻은 것들 — 처음 만난 사람들과 협업하는 것, 빠른 의사결정, 스코프를 자르는 능력, 완성도와 속도의 균형 — 이게 전부 실무에 그대로 적용됐다. 순위 상관없이 한 번은 경험해볼 가치가 확실히 있다.
월요일 아침에 출근하면서 이상한 감정이 있었다. 피곤했는데 상쾌했다. 주말을 날렸는데 뭔가를 얻은 느낌이었다. 48시간 동안 아이디어에서 배포까지 간 경험이, 6개월 스프린트보다 더 선명한 성취감을 줬다.
그 팀원들과 지금도 연락한다. 소연은 프리랜서 협업 제안이 왔을 때 가장 먼저 연락한 디자이너가 됐고, 준혁은 기술 이야기 나누는 슬랙 그룹에 함께 있다. 결과물보다 사람이 더 남았다. 그게 해커톤의 진짜 수확이었다.
💬 해커톤 경험이 있으신가요?
참가 경험, 인상 깊었던 순간, 다음엔 다르게 하고 싶은 것들을 댓글로 나눠주세요. 처음 도전하려는 분들에게도 "그래도 해볼 만한가"에 대한 경험담이 큰 도움이 될 것 같습니다.
'개발자 > 사이드프로젝트 창업' 카테고리의 다른 글
| 개발자가 유튜브·블로그로 부수입 만든 방법 (1) | 2026.07.25 |
|---|---|
| 오픈소스 프로젝트 만들어서 스타 100개 받기까지 (0) | 2026.07.18 |
| 개발자가 부업으로 외주 받아본 현실 후기 (0) | 2026.07.11 |
| 개발자 둘이서 창업했을 때 갈라진 이유 (0) | 2026.07.04 |
| 1인 SaaS 만들어서 월 수익 낸 이야기, 퇴근 후 6개월 (1) | 2026.06.27 |
