👨💻 8th Ne(o)rdinary 해커톤 참여
지난 5월 17일부터 18일까지, 무박 2일 동안 진행된 8th Ne(o)rdinary 해커톤에 참여했다. 이 해커톤은 UMC와 CMC가 함께 주최한 행사로, UMC는 대학생 중심, CMC는 대학생부터 취준생, 현직자까지 다양한 사람들이 함께하는 커뮤니티다.
나는 과거 UMC에서 활동했던 경험이 있고, 취준 중에도 사이드 프로젝트를 하며 개발자로서의 역량을 발전시키고자 CMC에 지원했고 운 좋게 합격해서 활동 중이다. 그 활동 중 하나로 이번 해커톤에 참여하게 되었다.
해커톤은 아래 타임 테이블에 따라 진행됐고, 운영진분들께서 야식, 간식, 아침까지 꼼꼼하게 챙겨주시고, 지속적으로 소통해주신 덕분에 정말 ‘입이 심심할 틈 없이’ 작업에 몰입할 수 있었다. 진심으로 감사드립니다 🙇♂️
주제 선정과 아이디어
해커톤은 ESG를 주제로 한 10개의 미션 중 하나를 선택해 프로젝트를 완성하는 구조였다. 레크리에이션을 통해 팀마다 주제 선택 순서를 정했고, 우리 팀 디자이너 분의 활약으로 두 번째로 주제를 고를 수 있는 기회를 얻었다.
우리가 선택한 주제는 “Zero Waste”.
단순한 정보 제공형 서비스가 아닌, 제로 웨이스트 챌린지를 통해 실천을 유도하고, 미션 달성에 따라 보상을 제공하는 구조로 사용자 참여를 끌어내는 방향으로 기획했다.
팀 구성과 역할 분담
우리 팀은 총 7명으로 구성되었다.
- PM: 1명
- 디자이너: 1명
- iOS 개발자: 2명
- 서버 개발자: 3명
나는 백엔드 개발자로 참여했고, 서버 팀원 분들 중 해커톤 경험이 가장 많다 보니 자연스럽게 서버 파트를 리드하게 되었다.
백엔드 전략과 초기 태스크
해커톤은 시간 싸움이기 때문에 다음과 같은 전략으로 빠르게 움직이고자 했다.
-
DB 설계 & API 명세는 큰 그림만 그린다
→ 기획이 수시로 변경되기 때문에 너무 디테일하게 설계하지 않고 유연하게 대처할 수 있도록 구조 설계에 집중했다.
-
초기 인프라 구성 & CI/CD 파이프라인 먼저 구축한다
→ 백엔드 측에서 API가 나오는 즉시 서버에 반영되도록 인프라를 먼저 구축했다. 이렇게 함으로써 IOS 개발자 분들이 바로바로 API를 연동할 수 있었다.
-
주요 조회 API부터 빠르게 구현
→ 최소 시연 가능한 상태를 목표로, 사용자가 처음 보게 될 메인 화면에 필요한 조회 API부터 작업했다. 시간이 부족할 경우 등록/수정은 DB 조작으로 대체할 수 있다.
위의 원칙에 기반하여 초기 태스크는 아래와 같이 정의했다.
- ERD 설계 (1명)
테이블 간의 관계를 중심으로 빠르게 도출하고, 각 컬럼까지 정확히 정의할 필요는 없었다. 기획이 유동적인 상황이므로, 핵심 테이블과 관계 위주로 가볍게 설계했다.
- API 명세 (1명)
주요 기능과 엔드포인트 정도만 간단히 정리했고, 요청 및 응답 데이터는 작업하면서 유동적으로 대응했다. 시간 대비 효율을 고려해 필수 항목만 정리했다.
- 초기 프로젝트 세팅 & 인프라 구성 및 배포 파이프라인 구축(1명, 내 담당)
실제 운영하는 서비스가 아니기 때문에 Public / Private Subnet을 나누지 않고, Public Subnet에 WAS와 DB를 구성했다.
EC2에서 서버를 구동하고, Docker로 애플리케이션을 컨테이너라이징했으며, MySQL과 S3(이미지 업로드)도 연동했다.
GitHub Actions를 활용해 커밋 SHA 기반의 이미지 태깅으로 Docker 이미지를 자동 빌드/배포하도록 구성했다.
초기 태스크를 진행한 이후에는 기획 변경에 따라 유연하게 기능을 추가 및 수정하는 식으로 진행되었다.
예상치 못한 문제들과 위기 상황
하지만 순조롭기만 하진 않았다.
기획 동기화 실패
 기획 v1 |
 기획 v2 |
새벽 4시쯤 프론트 개발자분과 소통 중, 뭔가 기획과 UI가 안 맞는다는 느낌을 받았다.
알고 보니 v2 기획 산출물이 피그마의 별도 워크스페이스에 따로 존재하고 있었고, 카톡에도 별도로 공유되지 않아 서버 팀은 여전히 v1 기준으로 개발 중이었다...
그 사실을 새벽 5시에 알게 되었고, 너무 당황스러웠다 ㅠㅠ
예상치 못한 DB 초기화 및 병합 충돌 이슈
서버 개발자분 중 한 분이 DB 데이터를 초기화하셨는데, 사전에 합의가 된 상황이 아니었어서 기존 데이터와 연결된 기능들이 깨졌다..
또한 그 분께서 마감 1시간 반 전에 깃허브 PR 병합 충돌 조치를 하다가 내가 기존에 메인 브랜치에 반영해놓았던 코드가 덮어씌워져 기존에 동작하던 메인 기능이 동작하지 않았다 ㅠ
마감 시간이 임박할 수록 아무래도 마음이 급해지니 소통이 부족한 부분으로 발생한 이슈라고 생각했다.
다행히 배포 파이프라인에서 커밋 SHA를 기반으로 이미지 태그를 관리했기 때문에, 병합 이전 상태의 이미지를 찾아 컨테이너를 롤백시켜 무사히 복구할 수 있었다.
그럼에도 해냈다
이러한 문제들을 겪으며 정신없이 새벽을 달렸다. 결국 모든 기능을 고치지는 못했지만, 일부 기능을 고치고 DB 더미 데이터도 다시 세팅하여 시연 가능할 정도의 수준은 되었다. 그리고 최종 발표 끝에 우수상 수상!
기획자분께서 발표를 잘해주신 것도 있지만, 디자인분께서 디자인도 기깔나게 해주셨고 마무리 단계에서 이슈가 있었음에도 프론트, 서버 개발자분들께서 끝까지 포기하지 않고 열심히 해주셨기 때문에 수상을 할 수 있었다고 생각한다!
다들 정말 감사했습니다 🙏
느낀점
이번 해커톤은 단순히 기능을 구현하는 것을 넘어, 팀워크의 중요성, 소통의 필요성, 그리고 리더십에 대한 고민을 많이 하게 만든 경험이었다.
짧은 시간 동안 빠르게 기획이 바뀌고, 예상치 못한 변수들이 생기다 보니 내가 맡은 역할에만 몰두하면 전체적인 싱크가 틀어질 수 있다는 걸 몸소 느꼈다.
특히 서버 개발 리더 역할을 하다 보니 내가 팀원들에게 어떤 정보를 공유하고, 어떤 결정을 내려야 할지 고민이 많았고, 경험이 부족한 팀원들이 불안해하지 않도록 분위기를 잡는 것도 중요한 책임이라는 걸 배웠다.
또한, 배포 전략(Docker 이미지 버전 관리)을 초기에 잘 구성해둔 덕분에 위기 상황에서 빠르게 대처할 수 있었던 점은 앞으로도 큰 교훈으로 남을 것 같다.
그만큼 초반 준비의 중요성과, 예상하지 못한 상황에서의 침착한 대응력이 얼마나 중요한지도 체감했다.
무엇보다도, 부족한 부분이 많았음에도 불구하고 팀원들이 끝까지 포기하지 않고 각자의 자리에서 최선을 다해준 덕분에 좋은 결과를 얻을 수 있었던 것 같다.
협업이란 결국 서로를 믿고 도와주며 끝까지 해내는 과정이라는 걸 다시금 느꼈고, 그래서 더 보람차고 뜻깊은 해커톤이었다.
KPT 회고
마지막으로 KPT 회고 형식을 바탕으로 회고 해보려한다.
Keep (잘한 점)
- 초반에 인프라 & 배포 파이프라인을 빠르게 구성한 점
- 시연에 필요한 조회 API를 우선 구현하여 프로토타입 완성도를 높인 점
- 커밋 SHA 기반 이미지 버전 관리를 통해 문제 상황에 빠르게 대응할 수 있었던 점
Problem (아쉬운 점)
- 기획 변경 사항에 대한 소통 부재로 불필요한 비용이 발생함
- 전체적인 기획 및 진행 상황을 다른 파트와 공유하지 못해 일부 싱크 mismatch 발생
- 서버팀 내 협업 및 진행 상황 공유가 부족했음(깃허브 PR 리뷰시 조금 더 꼼꼼하게 확인할 필요!)
Try (다음엔 이렇게!)
- 주요 산출물(기획, 디자인 등)은 중앙 집중화된 공간에 명확히 공유하자 (ex. Notion, Slack 등)
- 모든 팀원들이 모여 진행 상황을 공유하는 시간을 수시로 가지자
- 인프라 담당 외의 인원에게도 배포 방식 및 운영 전략을 공유하여 공통 대응 능력을 기르자
