해커톤 팀빌딩의 판을 바꾸다 – 600명 규모 팀 구성 시스템의 기획과 운영 이야기

✨ 해커톤 팀빌딩, 어떤 방식이 있을까요?

지금까지 제가 참가했던 해커톤의 대부분은 다음 두 가지 방식 중 하나로 팀을 구성했습니다.
1. 현장 즉석 팀빌딩 혹은 사전 커뮤니티를 통한 “같이 나갈 분 구해요!” 방식
2. 지인 또는 같은 학교 사람들과 사전 팀 구성

하지만 이런 방식에는 분명 아쉬움이 있습니다.
예를 들어, 팀을 꾸렸는데 제 관심사와 전혀 맞지 않는 주제를 하게 된다면,
과연 진정으로 몰입하고 애정을 가질 수 있을까요?

🎯 해커톤의 진짜 목적은 무엇일까요?

누군가는 상을 타기 위해,
누군가는 새로운 사람과의 협업을 위해,
또 누군가는 한 번뿐인 경험을 위해 참가합니다.

그래서 IT 연합 동아리 ‘구름톤 유니브’에서는 이러한 목적을 아우르면서도,
기존과는 다른 새로운 팀빌딩 방식을 고민하게 되었습니다.

🌀 팀빌딩이 기획된 배경

☁ 구름톤 유니브란,

구름톤 유니브는 "Being All Seasons With"이라는 슬로건 아래,
전국의 학생들이 구름톤 유니브와 함께 사회 문제를 해결하며, IT 인재로 성장할 수 있게 하는 것을 꿈꾸고 있습니다.

현재 구름톤 유니브 4기는 전국 62개 대학, 약 800여 명의 미르미와 함께 하고 있습니다.

*미르미 : 구름톤 유니브 구성원 애칭

🧩 구름톤 유니브만의 특별한 팀빌딩 방식

1기부터 현재 4기까지 ‘아이디어 기반 팀빌딩’ 방식을 유지하고 있습니다.

✅ 방식 요약

• 참가자가 아이디어(주제)를 등록하고, 팀원을 모집합니다.
• 참여자는 흥미 있는 아이디어에 최대 3지망까지 지원합니다.
• 팀장은 지원자 중 팀원으로 수락하거나 거절합니다.
• 이 과정을 3라운드(n차 팀빌딩)에 걸쳐 반복합니다.

💡 이 방식의 장점

• 다양한 학교/배경의 사람들과 교류
• 흥미 있는 아이디어 중심의 팀빌딩으로 몰입도 ↑
• 자발적 참여로 인한 책임감 및 협업 집중도 ↑

이런 방식으로 실제로 1, 2기 때는 매우 만족도 높은 팀빌딩이 이루어졌습니다.
특히 1기 때는 직접 오프라인에서 서로 어필하고, 아이디어를 홍보하고, 그런 교류 활동이 활발하게 이루어졌습니다.

*1기 당시 사진입니다.

❗️ 3기부터 드러난 문제들

참여 인원이 300~400명 규모로 급격히 증가하면서 수기 방식의 한계가 드러났습니다.

❌ 기존 방식의 문제점

• 팀장 입장에서 지원자가 몇 명인지, 마감 여부를 파악하기 어려움
• 운영진도 팀빌딩 완료 여부를 실시간으로 파악할 수 없음
• 인재풀은 가나다 순으로 되어 있어 상위 노출 문제 발생
• 프로세스가 너무 자유로워서 참여율/책임감 저하

이러한 문제점들로 인해 참가자도, 운영진도, 신선한 팀빌딩 방식이지만, 그만큼 너무나도 큰 리소스를 투자해야하는 상황이 생겨버렸습니다.

💻 그래서, 우리는 플랫폼을 만들기로 했습니다.

이 모든 문제를 해결하고자, 구름톤 유니브 공식 사이트 내에
팀빌딩 전용 플랫폼을 새롭게 구축하기로 결정했습니다.

운영진의 수작업을 줄이고, 참가자는 직관적인 UI로 빠르게 지원/수락 흐름을 확인할 수 있도록 기획했습니다.

이 팀빌딩 플랫폼을 정리하면 다음과 같았습니다.

• 아이디어 게시판: 주제를 등록하고 지원을 받을 수 있는 UI
• 지원 기능: 사용자는 관심 있는 아이디어에 1~6지망까지 지원 가능
• 마이페이지: markdown으로 자기소개 작성, PR 페이지
• 지원 내역 뷰: 팀장은 나에게 지원한 사람을 확인하고 수락/거절
• 내 팀 구성 확인: 확정된 팀원 리스트 확인

*해당 사진 내 아이디어는 GPT가 제작한 목업 데이터며, 실제 참가자의 아이디어와 무관합니다.

🛠 플랫폼 제작 기획 과정

👥 기획자 없이 단 3명이서 진행한 플랫폼

사실 저희의 TF팀은 기획자가 없었습니다. 디자이너 1명, 프론트엔드 1명, 백엔드 1명. 총 3명이서 만든 플랫폼이였습니다.
디자이너는 저번 기수에 운영단으로 함께했던 가영님, 백엔드는 저번 기수 참가자였던 동겸님. 그리고 저는 프론트엔드를 맡아 진행했는데요.

(이때 알았어야했습니다, 기획자의 소중함을...)

기획자 없이 진행하다보니 서로가 서로에게 데이터이기 때문에 대체불가한 인력들이라고 단톡방 이름도 지었습니다..ㅎㅎ

🎯 목표: 노션보다 불편하면 안 된다

우리가 만든 이 사이트가 이전 방식(노션이나 스프레드시트)보다 불편하다고 느껴지는 순간,
참가자들은 "굳이 이 플랫폼 써야 하나?"라는 의문을 가질 수밖에 없습니다.
가장 먼저 고민한 건 "이 플랫폼을 써야 하는 이유"였습니다.

그래서 다음과 같이 정리해보았습니다.

• 본인 소개 / 아이디어 소개: 마크다운 지원
• 참가자가 지원한 이력/경쟁률을 한눈에 파악 가능
• 팀장은 지원자 리스트를 보고 수락/거절 관리 가능
• 운영진은 전체 진행 상황을 실시간으로 확인 가능

이 네 가지만 충족되더라도 이전 기수보다 훨씬 더 편한 팀빌딩 시스템이 될 것이라고 생각했습니다.

*해당 사진 내 아이디어는 GPT가 제작한 목업 데이터며, 실제 참가자의 아이디어와 무관합니다.

📌 기본적인 팀빌딩 조건 정리

우선 팀빌딩 과정을 풀어내기 전, 기본적인 우리만의 팀빌딩 조건을 먼저 소개해보겠습니다.

저희 팀빌딩은 다음 조건을 지켜야합니다.

• 한 팀당 최소 3명 최대 6명이 한 팀이 될 수 있습니다.
• 기획자는 한 팀당 0~1명만 가능합니다.
• 디자이너는 한 팀당 0~1명만 가능합니다.
• 프론트엔드는 한 팀당 0~3명만 가능합니다.
• 백엔드는 한 팀당 0~3명만 가능합니다.
• 한 팀에 같은 학교는 최대 2명까지만 가능합니다.

🔄 권한/기간/역할별 조건 정리

📌 왜 권한 분리가 필요했을까요?

같은 플랫폼을 사용하더라도, 참가자마다 역할이 다르기 때문에 역할에 따라 권한을 분리해야 했습니다.
예를 들어,

• 아이디어를 등록하면 자동으로 ‘팀장’이 되어야 하며
• 팀장만 팀 이름 수정, 팀원 수락/거절 가능
• 참가자는 다른 아이디어에 지원했을 시 아이디어 등록이 되면 안됨

이처럼 작은 제약 조건들이 곧 플랫폼의 핵심 기능이었습니다.

⏳ 기간을 나눈 이유

구름톤 유니브의 팀빌딩은 n차 라운드로 구성되어 있고,
각 라운드마다 팀 빌딩이 부분적으로 진행될 수 있도록 설계되어 있습니다.

예를 들어, 1차 팀 구성 결과가 다음과 같다고 가정해봅시다.

파트	인원
기획	1명
디자인	0명
프론트엔드	2명
백엔드	1명

이 경우, 2차 라운드에서는 디자이너 1명과 백엔드 1명을 추가 모집할 수 있는 구조가 됩니다.

이렇게 기간을 나눈 이유는 다음과 같습니다.

• 무분별한 팀 지원 방지
• 참가자들의 팀 합류 현황을 알기 위함.

이제 이를 팀빌딩 사이트에서 도입을 하기 위해, 지원을 할 수 있는 기간을 주고자 했는데, 아래와 같은 문제가 있었습니다.

⚠️ 문제 발생: 실시간 수락의 부작용

초기에는 지원자가 팀장에게 지원하면 팀장이 실시간으로 수락하는 방식이었지만,
다음과 같은 문제가 발생했습니다.

상황 예시 : 만약 1차에서 지원을 했는데, 팀장이 나를 보고 바로 수락을 눌러 뽑는다면?

• 혹시나 그 팀장이 나를 수락 눌렀는데 내가 다른 팀에도 지원한 상황에 끌려가버린다면? -> 반강제적 팀 합류
• 혹은 동시에 팀장이 나를 수락 누르자마자 다른 팀장이 나를 수락을 눌러버린다면? -> 동시성 문제 발생

어느정도의 참가자 자율성을 보장하기 위해서는 절대 선착순으로 상호작용을 한다던가, 동시성 문제가 발생하면 더더욱 안되었습니다.

✅ 해결 방법: 기간 분리 + 지망 시스템

문제 해결을 위해 팀빌딩 각 차시를 두 단계로 분리했습니다.

• 1차 지원 기간 (지원자 -> 팀장) : 지원자가 팀장에게 지원할 수 있는 기간
• 1차 합불 결정 기간 (팀장 -> 지원자) : 팀장이 지원자를 뽑을지 말지, 수락과 거절 버튼을 누를 수 있는 기간

하지만 문제는 여기서 끝나지 않았는데요, 그렇다면 합불 결정 기간에 선착순으로 누르면 합류되는거 아니냐는 의문은 여전히 풀리지 않게됩니다.

🥇 지망 기반 지원 시스템

그래서 우리는 이렇게 해결하기로 했습니다.

• 참가자는 차시별 최대 3개 팀에 지원 가능
• 각 지원 시 1~3지망을 중복 없이 선택해야 함
• 팀장이 수락을 눌러도, 지망이 더 높은 팀에서 수락받았다면 해당 팀에 자동 합류

예를 들어보겠습니다.

지망	수락 여부
1지망	거절
2지망	수락
3지망	거절

만약 지원자의 기준으로 다음과 같이 결과가 나왔다면, 2지망으로 수락되어 2지망 팀에 합류하게 됩니다. 그렇기 때문에 참가자 개개인의 지망이 매우 중요해지는 시스템이기도 했습니다.

팀장 입장의 경우,

지망	이름	합격 여부
1지망	홍길동	확정
2지망	김구름	타 팀 합류
3지망	이단풍	거절

이렇게 2지망인 김구름을 수락했어도, 김구름이 1지망 팀에서도 수락 콜을 받았다면, 김구름은 우리 팀에 들어오지 못하게됩니다. 이 뷰는 n차 합불 결정 기간 이후 n+1차 지원 기간에 알게 됩니다.
합불 결정 기간에는 팀장들의 의사를 파악하고, 다음 차시때 최종 결과 알고리즘이 작동해야만 동시성 문제도 해결하기 때문이였죠.

💭 최종 시스템 핵심 정리

사실 이 시스템의 핵심은 다음 3가지입니다:
1. 지망 시스템
2. 지원/합불 기간 분리
3. 권한/제약 조건 기반의 롤 분리

이 구조를 처음 설계할 때,
저희 TF팀 셋은 정말 머리를 싸매고 토론했던 기억이 납니다.
이래서 기획자가 중요하다는 걸 다시 한 번 느꼈죠…

🧙 플랫폼 내 어드민 기획

TF팀 3명이 기획·디자인·개발을 모두 맡았지만,
저를 제외한 두 분은 운영단이 아니었기 때문에,
운영 중 발생하는 CS 처리나 데이터 수정은 결국 운영단의 몫이었습니다.

그래서 운영단이 직접 데이터를 수정하고 관리할 수 있는 어드민 페이지가 꼭 필요했습니다.

👶 어드민 개발, 처음이라서…

사실 저는 어드민 개발이 처음이었습니다.
"어드민에 뭘 넣어야 하지?" 고민하던 중, 함께 개발을 맡은 백엔드 동겸님이 이렇게 말하셨습니다

어드민은 못하는 게 없어야 해. 어드민은 신이야.

이 말을 100번도 넘게 듣고 나니,
정말 어드민이라면 무엇이든 할 수 있어야겠다는 생각이 들더라고요 😅

⏰ 개발 시작이 늦었다

문제는, 어드민 개발을 너무 늦게 시작했다는 점입니다.
7월 초까지 완성되어야 했지만, 실제 개발은 6월 중순부터 시작하게 되었고,
시간이 부족했던 만큼 운영에 꼭 필요한 핵심 기능 위주로 구현을 시작했습니다.

🛠 어드민 핵심 기능 정리

• 참가자 전체 정보(CRUD), 검색, 필터링 등
• 팀 정보(CRUD), 검색, 필터링 등
• 팀빌딩 정보 기간 수정
• 아이디어는 Read와 Delete만. (어드민은 아이디어를 등록할 필요도, 수정할 필요도 없기 때문!)
• 해커톤 주제 등록(아이디어 등록 때 필요)
• 아이디어 최대 개수(최대로 만들어지는 팀 수가 있기 때문에 이를 넘어서는 안됨)

*미르미분들의 소중한 개인정보는 따로 가렸습니다

⚙️ 플랫폼 운영 과정

🧪 테스트 과정

이번 팀빌딩 플랫폼은 재미있지만, 예외 처리가 실패할 경우 리스크가 큰 구조였습니다.
단 하나의 조건 누락만 있어도 참가자가 잘못 배정되거나, CS가 폭발할 수 있었죠.

그래서 개발 완료 직후, 1차 테스트는 제가 직접 전 역할을 수행하며 수동으로 진행했습니다.

• 기간에 따라 다른 화면과 동작 조건
• 사용자 권한: 팀장/지원자에 따른 UI 차이
• 조건 충족 여부에 따른 예외 처리 등

확인해야 할 변수와 시나리오가 너무 많아, 일일이 기록해가며 테스트 케이스를 수립했고,
버그가 발견되면 곧바로 백엔드 개발자에게 공유해 수정하는 방식으로 반복했습니다.

🔍 QA 과정

QA는 일정상 기획, 개발과 거의 동시에 진행되었습니다.
주로 디자이너 가영님께서 UI/UX 흐름과 동선 검수, 작은 문구나 정렬 하나까지 꼼꼼하게 체크해주셨습니다.

덕분에 많은 부분을 안정적으로 개선할 수 있었고, 플랫폼의 완성도가 한층 높아졌습니다.
꼼꼼한 QA로 플랫폼을 다듬어주신 디자이너 가영님께 진심으로 감사드립니다.

테스터 모집 및 유저 테스트 진행

테스터는 시즌톤에 참여하지 않는 분들 중 유니브 대표분들을 중심으로 약 20명을 모집했습니다.

• 유니브 대표 약 7~8명
• 운영단 내부 인원 12명

다만, 우리 플랫폼은 자유롭게 ‘아이디어 등록’ 또는 ‘지원’이 가능한 구조이다 보니,
테스트 목적에 맞게 역할을 분배한 시나리오 테스트가 필요했습니다.

✅ 테스트 설계 예:

• 소수만 아이디어 등록(팀장 역할)
• 다수는 지원자 역할
• 마이페이지 작성, 아이디어 수정, 인원 조정 등 실제처럼 행동 유도

사실 너무 복잡해서 GPT에게 테스트 케이스 생성을 부탁했지만,
우리 시스템 구조가 너무 특이한 탓인지 GPT조차 포기하더라고요… 😅

그래도 결과적으로는 예상보다 많은 피드백을 수용할 수 있었고,
예외 상황에 대한 실전 검증도 성공적으로 마무리되었습니다.

📘 팀빌딩 방식 가이드북 제작

플랫폼과 팀빌딩 구조를 직접 설계하며 가장 걱정됐던 점은, "참가자들이 과연 이 구조를 쉽게 이해할 수 있을까?"였습니다.

이전 기수를 경험한 미르미들은 괜찮겠지만, 처음 참가하는 미르미들은 당연히 낯설 수밖에 없었습니다.
그래서 운영단 디자인팀과 함께 팀빌딩 방식과 플랫폼 사용법을 설명하는 가이드북을 제작했습니다.

기획 내용을 글과 시각 언어로 정리하는 작업은 저에게는 처음이였는데,
제작 과정에서 디자인팀 세인님께서 주신 피드백들이 특히 인상 깊었습니다.

• "이 책자의 목적이 웹 플랫폼을 설명하려는 건가요, 아니면 팀빌딩 방식을 설명하려는 건가요?"
• "독자가 팀장인지, 지원자인지에 따라 내용을 분리하는 것이 좋을 것 같아요. 팀장이 굳이 지원자 뷰를 모두 볼 필요는 없잖아요?"
• "이 팀빌딩 방식을 가장 깊이 이해하고 있는 사람은 본인이잖아요. 다른 사람도 그렇게 이해할 수 있도록 설명했는지 꼼꼼히 점검해봐요."

이러한 피드백을 통해,
저는 단순히 정보를 전달하는 것이 아니라 '어떤 사람이 어떤 맥락에서 읽는가'를 고려하는 기획이 필요하다는 것을 깊이 느꼈습니다.

웹 플랫폼을 직접 개발하며 알게 된 흐름을 처음 보는 사람도 이해할 수 있도록 풀어내는 일,
독자별로 정보를 분리하되 깊이는 유지하는 설계의 중요성을 배웠습니다.

이 자리를 빌려, 날카롭고 따뜻한 피드백을 아끼지 않으신
디자인팀 세인님께 감사의 말씀 전합니다. 🙏

🧾 어드민 페이지를 통한 CS처리와 인원관리

이번 시즌톤부터는 기존처럼 스프레드시트나 노션이 아닌,
어드민 페이지를 통한 인원 관리를 도입했습니다.

• 지원자 중간 이탈 처리
• 수동 팀 이동, 아이디어 삭제 등

모든 작업을 어드민에서 처리할 수 있도록 구성했습니다.

또한 어드민에는 엑셀 Export 기능도 탑재했기 때문에,
각 라운드 종료 후 언제든 팀 빌딩 현황을 시트로 저장하고 트래킹할 수 있었습니다.

이 기능 덕분에 운영 효율이 비약적으로 올라갔고,
운영단 내부에서도 "이 많은 인원이 시스템 안에서 작동되어서 너무 다행이다"라는 피드백을 받을 수 있었습니다.

🧭 기획 및 운영을 마치며 느낀점

🎯 개인적인 평가

이번 팀빌딩 방식은 구름톤 유니브만의 정체성을 잘 담고 있는, 실험적이고 매력적인 시스템이었다고 생각합니다.
여러 기수에 걸쳐 운영하면서 참가자들의 반응은 분명하게 갈렸습니다.

👍 긍정적인 반응

• "재미있다! 신선한 팀빌딩 방식이다"
• "팀 결속력이 확실히 올라간다"
• "다양한 학교 사람들과 함께 네트워킹할 수 있어 좋다"
• "아이디어 중심이라 몰입도가 높다"

이처럼 플랫폼이 단순한 팀 매칭을 넘어, 진정한 협업의 시작점이 되었다는 피드백이 많았습니다.

👎 아쉬운 반응

• "팀빌딩 과정이 너무 긴장된다"
• "여러 번 떨어지고 나니 자신감이 떨어졌다"
• "해커톤 시작 전에 기빨리는 느낌…"

특히 지망제 기반 구조가 누군가에겐 자존감 이슈로 이어질 수도 있다는 점,
그리고 시간적으로 긴 호흡의 팀빌딩이 피로감을 줄 수 있다는 점도 분명 고려해야 할 부분이었습니다.

⚖️ 파트별 비율 불균형 문제

4기에서는 백엔드 지원자가 다른 파트의 2배 이상 몰리며 구조적인 어려움이 발생했습니다.

• 백엔드는 팀을 구하지 못하고 3차까지 넘어가는 사례 다수
• 랜덤 팀빌딩에서도 백엔드 인원이 과도하게 편중
• 그로 인한 참가자의 박탈감, 시스템에 대한 불만 증가

이 문제는 향후에도 반복될 수 있는 만큼,
초기 모집 단계에서 비율 조정 혹은 파트별 정원 기반 설계가 필요하다고 느꼈습니다.

---

✨ 이번 경험에서 느낀 점

구름톤 유니브 중앙운영단은 늘 이런 분위기입니다.

"필요하다면, 우리가 직접 만든다."

실제로 희찬님께서 운영중이신 나만의 네컷도 그렇고, 해커톤 입장 QR 스캐너를 만드는 것도 그렇고, 모두 운영에 필요로 의해 만들어진 서비스였습니다.

이번 팀빌딩 플랫폼 역시 그런 철학에서 시작되었고,
단 3명, 기획자 없이 기획부터 운영까지 완주한 경험은 정말 값진 시간이었습니다.

사실 개발보다 더 오래 걸린 건
수많은 조건을 설계하고, 경우의 수를 고려하고, 사용자 흐름을 끝없이 고민한 기획 그 자체였습니다.

덕분에 저희는 단순히 '사이트를 만든다'에서 멈추지 않고,
'사용자의 흐름, 운영자의 업무, 시스템의 책임까지 설계하는 법'을 배웠습니다.

이 플랫폼은 무사히 운영을 마쳤지만,
그 안에서 함께 만든 흐름, 배움, 그리고 연결은 계속될 것이라 믿습니다.

우리가 만든 방식이 완벽하지는 않았지만,
"개선하고 싶은 무언가가 있다면 직접 만들어보자"는 개발자의 태도는,
앞으로도 제가 어떤 프로젝트를 만나더라도 잊지 않고 가지고 갈 생각입니다.

이번 글은 기획과 운영을 시점으로 작성해보았는데요, 기회가 된다면 개발의 시점에서도 글을 작성해보려 합니다!
긴 글 읽어주셔서 감사드립니다.