개발자의 이상적인 해커톤 준비 방법

서론

KAIST GDSC에서 개최하는 스파클링톤에 참여하게 되었다. 모교에서 해커톤을 2회 주최한 경험은 있어도 100% 참여자로써의 해커톤 경험은 처음이라 많은 기대를 하고 있다. 해커톤 개최 경험자로써 개발자의 이상적인 준비를 이야기해보고자 한다.

협업에 관한 내용도 개발 실력보다도 아주아주 중요하지만 개발 이야기만 해도 할 말이 많기 때문에 이번 글에서는 생략하겠다.

 

해커톤 참여자는 이래야 한다.

해커톤은 스펙보다는 재미, 협업 능력 향상, 무료 피자와 콜라를 목표로 하는 것이 옳다. 번뜩이는 아이디어를 빨리 구현해야 하는데 대용량 트래픽, 확장성 같은 경험을 채우고 싶어서 해커톤에 참여하는 것이라면 그다지 좋은 팀원으로 평가되지는 않을 것이다.

그렇다면 어떤 개발자가 좋은 해커톤 팀원일까? 의존하지 않아도 되는 팀원이다. 다음은 이번 해커톤에서 모집된 직무들이다. (4인 1팀)

노드는 직무, 간선은 의존성이다. 채도는 의존도라고 보면 된다. 해커톤 내의 변수가 많으니 이 그래프가 절대적 지표는 아니다.
의존성이 있으니 백엔드 개발자 관점에서 어떤 것에 집중해야할 지 생각해 보자.

• 기획자와 협업할 때, 해결해야 하는 문제와 솔루션을 확실하게 이해해야 한다. 확실한 이해를 위해 많은 의사소통을 해야 한다. 개발부의 의존성은 전적으로 당신에게 향해있다는 것을 명심하라.
• 디자이너와 협업할 때, UI에 따라 내가 어떤 정보를 프론트엔드에게 제공해야 하는지, 사용자의 스토리에 따라 어떤 정보가 필요할지도 계속 생각해야 한다. 디자인에 따라 처리해야 하는 알고리즘을 서버에서 처리할지 프론트에서 처리할 지도 이후 회의해야 한다.
• 프론트엔드 개발자와 협업할 때, 빠르게 API를 제공해야 한다. 사용자와 직접 의사소통하므로 가장 잔손이 많이 가는 작업을 맡으실 텐데 API 제공이 늦어진다면 그만큼 프론트엔드 개발자의 부담이 커진다.

 

다들 밤을 새우며 정신적으로 피곤해질 수밖에 없다. 해커톤을 개최하면서 싸우는 팀도 꽤나 봤어서 이를 방지하기 위해 좋은 팀원이 되는 것이 중요하다. 결국 참여자 모두 재밌고 행복하기 위해 존재하는 해커톤이니까.

 

백엔드라면 이것을 준비하라.

먼저, 보일러 플레이트를 준비하라. 보일러 플레이트는 거의 변경 없이 바로 사용 가능한 반복되는 코드를 말한다. 나한테만 도움 되는 것이 아니라 프론트엔드 개발자에게 도움 될 것이다. 예시를 들자면:

1. API 문서(e.g. 스웨거)
2. DB 세팅 및 ORM
3. 배포되어 있는 AWS, S3 컨테이너: 프론트엔드가 서버를 클론해서 로컬에서 작업하는 것은 말도 안 된다.
4. E2E 테스트: 단일, 결합 테스트는 미리 작성해도 거의 의미 없다. 어차피 기획이 나오면 변경될 내용이다. 해커톤 진행 시에도 E2E 테스트 외에는 개발이 완료되면 진행하자.
5. Docker Compose를 활용한 빠른 3rd Party 확장
6. 서버 자동 배포
7. 게시글 작성
8. 파일 업로드
9. 채팅 기능
10. 인증: 필요로 할 때 아니면 추가하지 말자. 보안 해커톤 같은 경우가 아니라면 프로젝트 개발 속도만 떨어뜨리는 족쇄다.

특히 E2E 테스트를 강조하는 이유는 당신의 신뢰성을 보여주기 때문이다. 해커톤에는 부담도되고 긴장도 되고 즐겁기도 평소와 다른 흥분한 상태일 것이다. 그런 상황에서 내 작은 실수가 크게 느껴질 수 있다.

이를 E2E 테스트가 검증해 줄 것이다. 스웨거 배포, API 동작 확인 등 프론트엔드 개발자에게 보여질 부분을 테스트하라. 또한 망각의 동물인 우리에게 테스트를 먼저 작성함으로써 제약사항이나 팀원끼리 정한 솔루션을 망각하는 실수를 줄일 수 있다.

 

두 번째로는 오픈소스와 외부 API를 사용해 보라. 해커톤에서 해결해야 하는 방법이 단순히 솔루션만 있다고 해결되지는 않는 경우도 많다. 이런 경우에는 "데이터"나 "복잡한 알고리즘"이 필요할 수 있다. 이런 부분은 오픈소스와 외부 API가 제공해 줄 것이다. 카카오의 구름톤의 교육에서 항상 빠지지 않고 나오는 주제이다.

사용방법을 읽어보는 것 또한 비용이다. 미리 할 수 있는 것은 해커톤 전에 한번 정도 사용해 보는 것이 옳다.

데이터 부분은 이를 참고하라.

• 한국 공공데이터
• 국가 별 공공테이터
• Data.gov: 미국 정부의 공공 데이터 포털로, 경제, 환경, 교육 등 다양한 카테고리의 데이터를 제공
• awesome-public-datasets

외부 API는 이를 참고하라.

• Rapid API
• Public API
• API Layer
• ChatGPT API

Node.js계열을 사용한다면 Nest.js 웹 프레임워크도 권장한다. 의존성을 Module 단위로 관리하기 때문에 보일러플레이트의 추가 기능 관리에 효율적이다.

 

세 번째로는 시제품(MVP)을 개발한다는 생각으로 프로젝트를 개발하여야 한다.

올바른 MVP

자동차라는 MVP를 만들 때는 자전거부터 시작하는 게 아니라, 최소한 자동차가 구현되어야 한다.

1. 1번 케이스, 4단계까지 진행될 때까지 협업이 불가능하다.
2. 2번 케이스, 우리가 만들고자 하는 기능을 확실하게 알라. 이동수단이라면 1단계로도 충분하다. 자동차라면 바로 4단계를 만들어라.
3. 3번 케이스, 1단계부터 바로 목표였던 자동차를 만들었다.

3번 케이스가 MVP다. 많은 개발자들이 2번으로 착각하고 있는데 MVP는 최소 기능 제품이다. 굳이 최소 기능을 여러 번 분리해서 개발할 이유가 있을까? 바로 시제품을 만드는 것을 목적으로 하라. MVP는 변경될 여지가 적다.

더 중요한 것은 4단계에서는 동작하는 것이 확실하지만 1-3단계까지는 완벽하게 동작하지 않아도 된다는 점이다. 적절한 결과물(e.g. json)부터 빨리 프론트엔드에게 제공하여 개발이 진행되도록 하자. 프론트엔드 개발자도 서버의 API 처리 부분보다는 UI를 먼저 만들라.

 

네 번째로는 Git 버저닝 전략이다. 대부분의 개발자들이 Git Flow를 사용하는데 빠른 개발을 해야 하는 해커톤에서는 Github Flow 전략을 권장한다. Git Flow는 대규모 팀에서 적합한 반면 Github Flow는 1-3인 정도의 소규모 팀 

Github Flow는 Main 브랜치 + n개의 기능 브랜치로 관리하는 방법이다. 운영 관련 브랜치가 포함된 Git Flow보다 훨씬 개발속도가 빠를 것이다.