📑 목차
- 해커톤 MVP, 왜 항상 시간에 쫓길까? 테크리드의 고민
- 아이디어 구체화: 성공적인 MVP의 첫 단추
- 체크리스트 1: 핵심 가치 정의와 기능 최소화
- 체크리스트 2: 기술적 타당성 검토 및 제약 사항 파악
- 기술 스택 선정: 시간과 리소스를 아끼는 현명한 선택
- 체크리스트 3: 개발 속도를 극대화하는 스택 선택
- 체크리스트 4: 클라우드 서비스 활용 전략
- 개발 프로세스 최적화: 속도와 효율을 동시에 잡는 법
- 체크리스트 5: 애자일 원칙의 최소화된 적용
- 체크리스트 6: CI/CD 파이프라인 구축의 중요성
- 배포 전략: MVP를 현실로 만드는 마지막 단계
- 체크리스트 7: 무중단 배포를 위한 최소한의 전략
- 체크리스트 8: 도메인 및 SSL 설정 간소화
- 팀워크와 커뮤니케이션: 보이지 않는 성공의 열쇠
- 체크리스트 9: 명확한 역할 분담과 책임 의식
- 체크리스트 10: 효율적인 커뮤니케이션 채널 구축
- 결론: 해커톤 MVP, 더 이상 두렵지 않다
Image by Boskampi on Pixabay
해커톤 MVP, 왜 항상 시간에 쫓길까? 테크리드의 고민
안녕하세요, 수많은 해커톤을 경험하며 팀의 MVP(Minimum Viable Product) 구축을 이끌어온 엔지니어링 리더입니다. 해커톤은 짧은 시간 안에 아이디어를 실제 서비스로 구현해야 하는 압박감 속에서 팀의 역량을 최대한 끌어내야 하는 도전적인 경험이죠. 늘 "시간이 부족하다", "이 기능은 꼭 들어가야 하는데" 같은 고민을 안고 시작하게 됩니다. 특히 테크리드나 엔지니어링 매니저의 입장에서는 단순히 코드를 잘 짜는 것을 넘어, 제한된 시간과 리소스 속에서 팀원들의 역량을 최대로 발휘하게 하고, 최종적으로 가치 있는 결과물을 만들어내야 하는 막중한 책임감을 느낄 겁니다.
이 글에서는 제가 직접 팀을 이끌고 해커톤 MVP를 성공적으로 구축했던 경험을 바탕으로, 아이디어 구체화부터 기술 스택 선정, 개발 프로세스 최적화, 그리고 배포까지 단계별 실전 점검 항목들을 공유하고자 합니다. 이 가이드가 여러분의 다음 해커톤에서 시간 관리의 압박을 줄이고, 팀의 잠재력을 폭발시키며, 더 견고하고 인상적인 MVP를 만들어내는 데 실질적인 도움이 되기를 바랍니다.
우리의 목표는 단순히 작동하는 프로토타입이 아니라, 핵심 가치를 명확히 전달하고 잠재력을 보여줄 수 있는 MVP를 만드는 것입니다. 자, 그럼 실전으로 들어가 볼까요?
아이디어 구체화: 성공적인 MVP의 첫 단추
해커톤의 성패는 아이디어 단계에서부터 결정됩니다. 너무 거창한 아이디어는 필연적으로 시간 부족과 기능 미구현으로 이어지기 쉽습니다. 테크리드로서 가장 먼저 해야 할 일은 아이디어를 뾰족하게 다듬고, MVP의 핵심 가치를 명확히 정의하는 것입니다.
체크리스트 1: 핵심 가치 정의와 기능 최소화
- 무엇을 해결하는가? (Problem Statement): 우리가 해결하고자 하는 문제가 무엇인지, 그리고 그 문제가 얼마나 절실한지 명확히 정의해야 합니다. 이 정의가 명확할수록 불필요한 기능 추가를 막을 수 있습니다.
- 누구를 위한 서비스인가? (Target Audience): 우리의 서비스가 누구에게 가장 큰 가치를 제공할 것인지 구체적인 사용자 페르소나를 설정합니다. 이를 통해 기능 우선순위를 더 쉽게 결정할 수 있습니다.
- 가장 중요한 기능은 무엇인가? (Core Feature Identification): MVP는 '최소 기능 제품'입니다. 아이디어의 핵심 가치를 전달하기 위해 '반드시' 필요한 기능만을 선별해야 합니다. "이것 없이는 아이디어가 작동하지 않는다"고 할 수 있는 기능이 무엇인지 팀원들과 합의합니다. 보통 1~2개의 핵심 기능에 집중하는 것이 좋습니다.
- 스코프 크립(Scope Creep) 방지: 해커톤 기간 중 새로운 아이디어가 계속 떠오르더라도, 최초 합의된 핵심 기능 범위를 엄격하게 지키는 훈련이 필요합니다. "나중에 추가해도 될 기능" 목록을 별도로 관리하며 유혹을 이겨내세요. 저희 팀에서는 항상 'Must-have', 'Should-have', 'Could-have'로 기능을 분류하고, 해커톤 기간에는 'Must-have'에만 집중했습니다.
실제로 적용해 본 결과: 한 해커톤에서 저희 팀은 "AI 기반의 맞춤형 건강 식단 추천 서비스"를 기획했습니다. 처음에는 식단 추천, 레시피 제공, 영양 분석, 운동 연동 등 다양한 기능을 고려했죠. 하지만 테크리드로서 저는 팀원들에게 "가장 핵심적인 가치는 무엇인가?"를 끊임없이 질문했습니다. 결국 '사용자의 식단 데이터를 기반으로 개인화된 추천을 해주는 AI 코어 로직'이 핵심이라고 결론 내렸고, 레시피 제공은 최소한의 형태로, 운동 연동은 다음 단계로 미뤘습니다. 그 결과, AI 모델 개발과 추천 시스템 구현에 집중할 수 있었고, 짧은 시간 안에 명확한 가치를 가진 MVP를 선보일 수 있었습니다.
체크리스트 2: 기술적 타당성 검토 및 제약 사항 파악
- 팀의 역량과 기술 스택: 팀원들이 가장 익숙하고 빠르게 개발할 수 있는 기술 스택이 무엇인지 파악합니다. 새로운 기술을 도입하는 것은 학습 곡선 때문에 예상보다 훨씬 많은 시간을 소요하게 할 수 있습니다.
- 데이터 접근성 및 수집 계획: 아이디어를 구현하기 위해 어떤 데이터가 필요한지, 그리고 그 데이터를 어떻게 얻을 것인지 구체적인 계획을 세웁니다. 공공 API, 크롤링, 수동 입력 등 가능한 옵션을 검토합니다. 해커톤 기간에는 데이터 수집 자체에 너무 많은 시간을 할애하지 않도록 주의해야 합니다.
- 외부 서비스/API 활용 가능성: 모든 것을 처음부터 만들려고 하지 마세요. 결제, 인증, 지도, AI 모델 등 이미 잘 만들어진 외부 서비스나 API를 적극적으로 활용하는 것이 개발 속도를 비약적으로 높일 수 있는 방법입니다. 예를 들어, 소셜 로그인 기능을 직접 구현하기보다 OAuth를 제공하는 서비스를 연동하는 것이 훨씬 효율적입니다.
제가 직접 써보니: 데이터 수집이 관건인 해커톤에서, 저희 팀은 웹 크롤링 대신 공개된 데이터셋을 활용하거나, 데이터가 없는 부분은 더미 데이터로 대체하여 핵심 로직 개발에 집중했습니다. "데이터가 완벽해야 한다"는 강박을 버리고, "핵심 가치를 보여주기에 충분한 데이터"라는 관점으로 접근하는 것이 중요합니다.
기술 스택 선정: 시간과 리소스를 아끼는 현명한 선택
테크리드의 가장 중요한 역할 중 하나는 최적의 기술 스택을 선정하는 것입니다. 해커톤에서는 '가장 세련된 기술'보다는 '가장 빠르게 결과물을 낼 수 있는 기술'을 선택해야 합니다. 이는 단순히 개발 속도뿐만 아니라, 예상치 못한 문제 발생 시 해결 시간을 최소화하는 데에도 영향을 미칩니다.
체크리스트 3: 개발 속도를 극대화하는 스택 선택
- 팀원들의 숙련도 최우선: 팀원들이 가장 자신 있고 빠르게 개발할 수 있는 언어, 프레임워크, 라이브러리를 선택합니다. 학습 시간이 적고, 문제 발생 시 빠른 디버깅이 가능하기 때문입니다.
- 생산성 높은 프레임워크/라이브러리: 풀스택 프레임워크나 개발 생산성이 높은 라이브러리를 고려합니다. 예를 들어, 백엔드에서는 Python의 Django/Flask, Node.js의 Express, Go의 Echo/Gin 등을, 프론트엔드에서는 React, Vue, Svelte와 같은 SPA(Single Page Application) 프레임워크나 Next.js, Nuxt.js와 같은 풀스택 프레임워크를 활용할 수 있습니다. 보일러플레이트 코드를 줄여주는 도구는 언제나 환영입니다.
- 커뮤니티 지원 및 문서화: 문제가 발생했을 때 빠르게 해결책을 찾을 수 있도록 활발한 커뮤니티 지원과 잘 정리된 문서화를 갖춘 기술 스택을 선택하는 것이 좋습니다.
제가 직접 써보니: 저희 팀은 주로 React와 Node.js 기반으로 개발해왔기에, 해커톤에서는 Next.js와 Express.js 조합을 선호합니다. Next.js는 프론트엔드 개발 속도를 높여줄 뿐만 아니라, API 라우트를 통해 간단한 백엔드 기능까지 커버할 수 있어 초기 MVP 구축에 매우 유리합니다. 이 조합은 팀원들이 익숙하고, 개발 환경 설정에 드는 시간을 최소화할 수 있었습니다.
체크리스트 4: 클라우드 서비스 활용 전략
- 관리형 서비스(Managed Service) 적극 활용: 데이터베이스, 인증, 스토리지 등 인프라 구축 및 관리에 시간을 쏟기보다는 AWS, GCP, Azure 등의 클라우드에서 제공하는 관리형 서비스를 적극 활용합니다. 예를 들어, 데이터베이스는 RDS(AWS), Cloud SQL(GCP)을, 인증은 Cognito(AWS), Firebase Authentication(GCP)을 사용하는 식입니다. 서버리스(Serverless) 함수(Lambda, Cloud Functions)는 백엔드 구축 시간을 대폭 줄여줍니다.
- NoSQL 데이터베이스 고려: 관계형 데이터베이스의 스키마 설계 및 마이그레이션은 생각보다 많은 시간을 소요할 수 있습니다. 해커톤에서는 유연한 스키마를 가진 NoSQL 데이터베이스(MongoDB, DynamoDB, Firestore)가 더 빠르고 적합할 수 있습니다.
- 오픈소스 라이브러리 vs. 클라우드 서비스: 기능 구현 시, 직접 오픈소스 라이브러리를 가져와 구축할지, 클라우드 서비스를 사용할지 전략적으로 판단해야 합니다. 클라우드 서비스는 초기 비용이 들 수 있지만, 설정 및 유지보수 시간을 절약해줍니다.
비교: 빠른 MVP 구축을 위한 기술 스택 (예시)
| 구분 | 선택 1: 풀스택 프레임워크 | 선택 2: SPA + API (관리형 서비스) |
|---|---|---|
| 프론트엔드/백엔드 통합 | Django(Python), Rails(Ruby), Next.js(Node.js) | React/Vue/Svelte + Express/Flask/Lambda |
| 데이터베이스 | PostgreSQL, MySQL (직접 관리 또는 RDS) | MongoDB, Firestore, DynamoDB (관리형 NoSQL) |
| 인증/스토리지 | 직접 구현 또는 오픈소스 라이브러리 | Firebase Auth, AWS Cognito, S3 등 관리형 서비스 |
| 배포 | EC2, DigitalOcean Droplet (수동 설정) | Vercel, Netlify, Heroku, AWS Amplify, Cloud Run (서버리스/PaaS) |
| 장점 | 하나의 언어로 풀스택 개발, 빠른 초기 프로토타이핑 | 높은 확장성, 인프라 관리 부담 감소, 빠른 배포 |
| 단점 | 프레임워크 학습 곡선, 인프라 직접 관리 부담 | 초기 설정 복잡성, 서비스 간 연동 학습 필요 |
테크리드 관점: 해커톤에서는 "선택 2"가 더 유리한 경우가 많습니다. 인프라 설정 및 관리에 드는 시간을 대폭 줄여주어, 팀원들이 오직 핵심 기능 개발에만 집중할 수 있도록 지원하기 때문입니다.
Image by 15079075 on Pixabay
개발 프로세스 최적화: 속도와 효율을 동시에 잡는 법
기술 스택을 정했다면, 이제 팀이 가장 효율적으로 움직일 수 있는 개발 프로세스를 구축해야 합니다. 해커톤은 '애자일'의 극단적인 형태라고 볼 수 있으며, 이를 위해선 간결하고 효과적인 프로세스가 필수적입니다.
체크리스트 5: 애자일 원칙의 최소화된 적용
- 간소화된 태스크 관리: Jira나 Notion 같은 복잡한 도구보다는 Trello, GitHub Projects, 또는 화이트보드를 활용하여 태스크를 시각적으로 관리합니다. 'To Do', 'In Progress', 'Done' 세 단계만으로도 충분합니다. 각 태스크는 최대 2~4시간 내에 완료 가능한 단위로 잘게 쪼개는 것이 중요합니다.
- 짧은 데일리 스크럼: 매일 아침 또는 점심시간에 10~15분 이내로 짧은 스크럼을 진행합니다. 어제 한 일, 오늘 할 일, 그리고 현재 겪고 있는 문제점(블로커)을 공유하고, 테크리드는 블로커 해결에 집중해야 합니다.
- 페어 프로그래밍(Pair Programming) 및 코드 리뷰: 시간이 제한적이지만, 중요한 로직이나 복잡한 부분에서는 페어 프로그래밍을 통해 지식 공유와 오류 감소를 꾀할 수 있습니다. 코드 리뷰는 너무 엄격하게 하기보다는, 주요 로직의 결함 방지와 빠른 피드백에 초점을 맞춥니다.
- 버전 관리 시스템 활용: Git은 기본 중의 기본입니다. 명확한 브랜칭 전략(예: main/develop, feature 브랜치)을 수립하고, 자주 커밋하며, 의미 있는 커밋 메시지를 작성하도록 독려합니다. 충돌(Conflict)을 최소화하기 위해 작은 단위로 개발하고 자주 머지하는 것이 중요합니다.
실제로 적용해 본 결과: 저희 팀은 해커톤 시작 시점, 모든 기능을 작은 태스크로 분할하고 각 태스크에 예상 시간을 부여합니다. 그리고 화이트보드에 포스트잇으로 붙여 시각화했습니다. 매 스크럼마다 포스트잇을 옮기며 진행 상황을 한눈에 파악하고, 지연되는 태스크는 즉시 팀원 재배치나 스코프 조정을 통해 대응했습니다. 이러한 방식은 진행 상황 투명성을 높여 팀원들의 오너십을 강화하고, 병목 현상을 빠르게 식별하는 데 큰 도움이 되었습니다.
체크리스트 6: CI/CD 파이프라인 구축의 중요성
- 자동화된 빌드 및 테스트: 해커톤에서 테스트 코드를 완벽하게 작성하기는 어렵습니다. 하지만 최소한의 유닛 테스트나 통합 테스트를 자동화하여 기본적인 기능의 오작동을 방지해야 합니다. 빌드 프로세스 역시 자동화하여 개발 시간을 절약합니다.
- 빠른 배포 환경 구축: 수동 배포는 실수를 유발하고 시간을 잡아먹습니다. CI/CD 파이프라인을 구축하여 코드 푸시 시 자동으로 빌드, 테스트, 배포가 이루어지도록 설정합니다. GitHub Actions, GitLab CI/CD, CircleCI 등 다양한 도구를 활용할 수 있습니다. 이는 팀원들이 개발에만 집중할 수 있게 하며, '배포가 가능한 상태'를 항상 유지하는 데 필수적입니다.
제가 직접 써보니: 해커톤 시작 전에 기본적인 CI/CD 템플릿을 미리 준비해두는 것이 좋습니다. 예를 들어, GitHub Actions를 사용하여 main 브랜치에 푸시될 때마다 자동으로 빌드하고, Docker 이미지를 생성하여 클라우드에 배포하는 워크플로우를 설정해두면 개발 초기부터 배포 준비를 마칠 수 있습니다.
name: CI/CD Pipeline for MVP
on:
push:
branches:
- main
jobs:
build_and_deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v2
with:
node-version: '16'
- name: Install dependencies
run: npm ci
- name: Run tests (if any)
run: npm test || true # Allow failure for quick hackathon
- name: Build project
run: npm run build
- name: Deploy to Vercel (Example)
if: success()
run: |
npm i -g vercel
vercel --prod --token=${{ secrets.VERCEL_TOKEN }}
env:
VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
위 예시 코드는 GitHub Actions를 통해 main 브랜치에 코드가 푸시될 때마다 자동으로 빌드하고 Vercel에 배포하는 간단한 CI/CD 파이프라인입니다. 해커톤에서는 빠른 배포와 확인이 중요하므로, Vercel, Netlify, Heroku 등 배포가 간편한 서비스를 활용하는 것을 강력히 추천합니다.
배포 전략: MVP를 현실로 만드는 마지막 단계
아무리 좋은 MVP도 배포되지 않으면 의미가 없습니다. 해커톤에서는 복잡한 인프라 구성보다는 빠르고 안정적인 배포에 초점을 맞춰야 합니다. 독자들에게 실제로 작동하는 서비스를 보여주는 것이 중요합니다.
체크리스트 7: 무중단 배포를 위한 최소한의 전략
- 간편한 PaaS/Serverless 플랫폼 활용: 앞서 언급했듯이 Vercel, Netlify, Heroku, Firebase Hosting, AWS Amplify, Google Cloud Run 등은 배포 과정을 극도로 단순화시켜줍니다. Git 저장소와 연동하여 커밋만으로 배포가 이루어지도록 설정하는 것이 이상적입니다.
- 환경 변수 관리: API 키, 데이터베이스 연결 정보 등 민감한 정보는 환경 변수로 관리하고, 배포 플랫폼에서 이를 쉽게 설정할 수 있도록 준비합니다. 하드코딩은 절대 금물입니다.
- 로깅 및 모니터링: 최소한의 로깅 시스템을 구축하여 서비스가 제대로 작동하는지 확인하고, 문제가 발생했을 때 빠르게 디버깅할 수 있도록 준비합니다. Sentry, Datadog 같은 전문 도구까지는 아니더라도, 배포 플랫폼에서 제공하는 기본 로깅 기능이라도 활용해야 합니다.
제가 직접 써보니: 저희 팀은 프론트엔드는 Vercel, 백엔드는 AWS Lambda와 API Gateway 조합을 즐겨 사용합니다. Vercel은 GitHub 연동만으로 수분 내에 배포가 가능하고, Lambda는 서버 관리에 대한 부담이 전혀 없어 백엔드 개발에만 집중할 수 있게 해줍니다. 이 조합은 인프라 지식 없이도 안정적인 배포 환경을 구축할 수 있게 해주어 해커톤에 최적화되어 있습니다.
체크리스트 8: 도메인 및 SSL 설정 간소화
- 임시 도메인 활용: 해커톤 기간 동안에는 굳이 복잡하게 커스텀 도메인을 설정하기보다는, 배포 플랫폼에서 제공하는 임시 도메인(예: vercel.app, herokuapp.com)을 활용하는 것이 좋습니다. 이는 시간을 절약할 뿐만 아니라, DNS 설정 오류로 인한 문제 발생 가능성을 줄여줍니다.
- 무료 SSL 인증서 자동 적용: 대부분의 PaaS/Serverless 플랫폼은 Let's Encrypt를 통한 무료 SSL 인증서를 자동으로 적용해줍니다. HTTPS는 보안뿐만 아니라 사용자 신뢰도에도 영향을 미치므로, 반드시 적용해야 합니다.
테크리드 관점: 배포는 팀의 개발 결과물을 세상에 공개하는 마지막 단계입니다. 이 과정에서 발생하는 작은 문제 하나가 전체 프로젝트의 인상에 큰 영향을 미칠 수 있으므로, 간소화와 자동화를 최우선으로 고려해야 합니다.
Image by jdblack on Pixabay
팀워크와 커뮤니케이션: 보이지 않는 성공의 열쇠
아무리 기술 전략이 뛰어나더라도, 팀원 간의 원활한 소통과 협업 없이는 해커톤에서 성공하기 어렵습니다. 테크리드/엔지니어링 매니저는 기술적인 리딩뿐만 아니라, 팀의 사기를 북돋우고 효율적인 협업 환경을 조성하는 데 집중해야 합니다.
체크리스트 9: 명확한 역할 분담과 책임 의식
- 역할 및 책임(R&R) 명확화: 해커톤 시작 전, 각 팀원의 역할(프론트엔드, 백엔드, 디자이너, PM 등)과 각자의 책임 영역을 명확히 정의합니다. "누가 무엇을 담당하는가"에 대한 혼란은 시간 낭비와 갈등의 원인이 됩니다.
- 오너십 부여: 각 팀원에게 자신이 맡은 기능이나 모듈에 대한 완전한 오너십을 부여합니다. 이는 책임감을 높이고, 더 나아가 문제 해결 능력과 주도성을 키우는 데 도움이 됩니다.
- 백업 플랜: 특정 팀원이 예상치 못한 문제로 개발이 지연될 경우를 대비하여, 서로의 업무를 이해하고 도와줄 수 있는 백업 플랜을 마련해두는 것이 좋습니다. 페어 프로그래밍이 좋은 대안이 될 수 있습니다.
제가 직접 써보니: 저희 팀은 각자 맡은 기능의 '기술 리더'가 되도록 독려합니다. 예를 들어, 인증 기능을 맡은 개발자는 해당 기능에 대한 모든 기술적 결정을 주도하고, 다른 팀원들은 필요시 지원하는 식입니다. 이는 의사결정 속도를 높이고, 각자의 전문성을 강화하는 데 효과적이었습니다.
체크리스트 10: 효율적인 커뮤니케이션 채널 구축
- 중앙 집중식 커뮤니케이션: Slack, Discord, Microsoft Teams 등 하나의 채널에 모든 커뮤니케이션을 집중시킵니다. 여러 채널에 정보가 분산되면 중요한 내용을 놓치기 쉽습니다.
- 정기적인 동기화: 짧은 데일리 스크럼 외에도, 필요할 때마다 비공식적인 동기화 세션을 가집니다. 특히 프론트엔드와 백엔드 간의 API 명세 협의 등은 자주 진행될수록 좋습니다.
- 문서화의 최소화: 해커톤에서는 방대한 문서화보다는 핵심 정보(API 명세, 데이터 모델)만 간결하게 공유하는 것이 효율적입니다. Notion, Google Docs 등에서 실시간 협업이 가능한 도구를 활용합니다.
실제로 적용해 본 결과: 저희 팀은 해커톤 시작과 동시에 Slack 채널을 만들고, 모든 질문과 답변, 결정 사항을 그곳에 공유합니다. 특히, "질문은 개인 메시지 대신 공개 채널에"라는 원칙을 세워, 다른 팀원들도 정보를 얻고 비슷한 질문을 반복하는 것을 막았습니다. 또한, API 명세는 Swagger나 Postman Collection으로 빠르게 공유하여 프론트엔드와 백엔드 개발자가 동시에 작업을 시작할 수 있도록 했습니다.
결론: 해커톤 MVP, 더 이상 두렵지 않다
해커톤에서 MVP를 빠르게 구축하는 것은 단순히 코딩 실력 이상의 전략적인 사고와 팀 리딩 역량을 요구합니다. 이 글에서 제시된 점검 항목들을 통해 여러분은 아이디어 구체화부터 기술 스택 선정, 개발 프로세스 최적화, 배포, 그리고 팀 운영에 이르기까지 전 과정을 체계적으로 관리할 수 있을 것입니다.
핵심은 '최소한의 것으로 최대한의 가치를' 이라는 MVP 정신을 잊지 않는 것입니다. 복잡성을 줄이고, 자동화를 통해 시간을 절약하며, 팀원들이 핵심 기능 개발에만 집중할 수 있는 환경을 조성하는 것이 테크리드의 가장 중요한 역할입니다. 제가 직접 경험하며 쌓아온 노하우들이 여러분의 다음 해커톤에서 빛나는 결과물을 만들어내는 데 큰 도움이 되기를 진심으로 바랍니다.
여러분은 해커톤에서 어떤 전략으로 MVP를 구축하시나요? 혹은 어떤 어려움을 겪으셨나요? 댓글로 여러분의 경험과 생각을 공유해주세요. 함께 배우고 성장하는 기회가 되기를 바랍니다.