페이스메이커를 찾아라
마라톤은 혼자 뛰는 종목이지만, 함께 달리며 기준이 되는 페이스를 만들어주는 페이스메이커가 존재한다. 혼자 완주하는 것과 페이스메이커와함께 완주하는 것은 결이 다르다. 해커톤도 마찬가지다. AI와 팀을 이뤄 혼자서도 참여할 수 있는 해커톤이 많아졌지만, 여전히 팀을 구성해 경쟁하는 대회가 주를 이룬다. 어떤 팀을 만나느냐가 완주의 질을 결정한다.
나에게 아이디어가 있냐 없냐, 그것이 문제로다
개인으로 참여하든, 팀으로 참여하든. 초보 프로덕트 디자이너가 해커톤 전략을 세울 때 갈림길이 되는 건 내게 아이디어와 기획이 있느냐 없느냐다.
만약 확실한 아이디어가 있다면, 기획자 포지션을 함께 가져가며 주도권을 잡는 것이 좋다. 내 머릿속에서 나온 아이디어인 만큼 UX/UI를 설계하는 데도 훨씬 수월하다. 팀빌딩 기간에 머릿속에 있던 기획을 꺼내 잘 정리한 뒤 팀원 모집 글을 올리면 된다. 반응이 없다면 직접 원하는 팀원에게 연락해 합류를 제안하자.
반면 아이디어가 없다면, 기획은 과감히 내려놓고 팀빌딩 기간에 공유되는 기획과 모집 글을 꼼꼼히 살펴봐야 한다. 나의 첫 해커톤 포지셔닝이 바로 이랬다. 모든 것이 처음이었기에, 기획이 가장 탄탄하고 가능성 있어 보이는 팀에 합류하는 것을 목표로 잡았다.
팀빌딩에서 가장 중요한 건 기획, 기획, 기획
팀을 고를 때 가장 먼저 봐야 할 것은 기획이다. 기획이 탄탄해야 문제 정의와 솔루션이 뚜렷하고, 심플하지만 명확한 서비스가 나올 수 있다. 기획이 흔들리면 디자인도, 개발도 방향을 잃는다. 특히 해커톤처럼 짧은 레이스에서 방향을 잃으면 결승선에 닿기 어렵다.
모든 해커톤이 같은 방식으로 진행되지는 않지만, 대부분 초반에 팀빌딩 기간이 주어진다. 처음부터 팀을 꾸려 참여했다면 상관없지만, 개인으로 참여했다면 이 기간이 가장 중요하다. 팀빌딩 기간 동안 참가자들은 슬랙이나 디스코드를 통해 아이디어와 기획을 공유한다. 그 기획을 중심으로 한두 명씩 팀원이 모이고, 자리가 차면 모집이 마감되기 때문에 빠르고 정확하게 훑어봐야 한다.
잠깐, 그래서 무엇을 봐야 하나요
해커톤에서 흔히 보이는 실수는 문제를 너무 크게 잡는 것이다. 거창한 아이디어보다 작고 뾰족한 문제를 잘 정의한 팀이 결국 완주한다. "모든 사람의 정보 접근성을 높이겠다"는 문제는 해커톤에서 풀 수 없다. 좋은 문제 정의는 좁고, 구체적이며, 실제로 불편함을 겪는 사람이 명확하다.
좋은 문제 정의의 구조는 대략 이렇다.
[누가] [어떤 상황에서] [무엇이 불편한가]. 우리는 [어떤 방식으로] [무엇]을 해결한다.
예를 들면, "취준생은 포트폴리오를 만들 때 레퍼런스를 찾는 데 너무 많은 시간을 쓴다. 우리는 직무별 레퍼런스를 AI로 큐레이션해주는 서비스를 만들어 취준생의 시간을 아낀다." 이런 식이다. 문제와 솔루션이 한 호흡으로 매끄럽게 연결되는 기획을 찾아야 한다. 그것이 함께 뛸 팀을 고르는 기준이 된다.
이상적인 팀 구성
기획자 외에도 챙겨야 할 부분이 있다. 프론트엔드 1명, 백엔드 1명은 기본이다. 개발 인력이 부족하면 아무리 좋은 기획과 디자인이 나와도 실제 출시로 이어지기 어렵다. 출시하지 못한 서비스는 포트폴리오에 담기도 애매하다.
한 가지 알아두면 좋은 것이 있다. 해커톤 참가자가 취준생만 있는 건 아니다. 현업에 있는 직장인도 상당수 참여한다. 직장인 팀원은 평일 낮 시간에 소통이 어려울 수 있지만, 실무 프로세스에 익숙한 만큼 실력 면에서는 든든한 동료가 된다.
기다리지 말고 먼저 뛰어라
팀빌딩에서 또 하나 조심할 것이 있다. 좋은 기획을 기다리다가 아무 팀에도 들어가지 못하는 경우다. 마라톤에서 페이스메이커를 고르다가 출발선을 놓치는 것과 같다.
슬랙에 올라오는 기획 공유 스레드에 적극적으로 댓글을 달고, 관심 있는 팀에는 먼저 DM을 보내야 한다. 팀장 입장에서는 먼저 연락해온 사람이 더 적극적으로 보인다. 어필이 필요하다면 포트폴리오를 함께 공유하자. 초보라도 준비된 초보와 그냥 초보는 다르다.
적극성 자체가 스펙이다.
TIP+ 초보 프디라면 손종원 셰프에 빙의해 촘촘한 타임테이블을 짜자
여기서 중요한 것이 하나 더 있다. WBS(Work Breakdown Structure), 즉 작업 일정표를 초반에 잡아두는 것이다. 정해진 기간 안에서 기획과 디자인이 늘어지면 개발할 시간이 없어진다. 개발 시간을 충분히 확보해줘야 실제 출시까지 이어진다. 초보 프디라면 팀 안에서 빠른 속도로 UX/UI를 설계하고 플로우를 완성해주는 것 자체가 팀에 대한 가장 큰 기여다.
이상적인 WBS (Work Breakdown Structure)
WBS란 전체 작업을 일정별로 쪼개놓은 작업 분류 체계다. 해커톤에서는 거창하게 만들 필요 없다. 핵심은 개발 시작일을 역산해서 디자인 마감일을 정하는 것이다.
실제 해커톤에서 적용했던 일정을 기준으로, 디자이너 롤에서 언제 무엇을 해야 하는지 정리하면 이렇다.
기간 | 디자이너 작업 |
D+0 ~ D+1 | 팀 합류 직후 기획자와 문제 정의 싱크, 타겟 유저 및 핵심 플로우 합의 |
D+1 ~ D+2 | IA(정보구조) 설계, 와이어프레임 초안 작성, 팀 내 플로우 리뷰 |
D+2 ~ D+3 | UI 컨셉 도출, 디자인 시스템(컬러·타이포·컴포넌트) 구축 |
D+3 ~ D+5 | 핵심 화면 UI 디자인, 페이지 트랜지션 작업, BI 작업 병행 |
D+5 | 디자인 핸드오프 → 개발 시작 (이 날짜를 반드시 사수) |
D+6 ~ D+7 | 서비스 소개서 초안 작성 및 디자인, 개발팀 QA 요청 사항 대응 |
D+8 | QA 작성 및 검수, 개발 결과물과 디자인 원본 비교 점검 |
D+9 | 발표 장표 디자인 완성, 최종 점검 |
D+10 | 발표 |
디자인이 D+5를 넘기면 개발 시간이 줄고, 개발 시간이 줄면 출시하지 못한 채 발표장에 서게 된다. 초보 프디가 팀에게 줄 수 있는 가장 큰 선물은 빠른 핸드오프다.
팀이 곧 완주력이다
결국 해커톤에서 완주의 절반은 팀빌딩에서 결정된다. 탄탄한 기획자, 든든한 개발팀, 그리고 빠르게 달릴 준비가 된 나. 이 세 가지가 갖춰졌을 때 비로소 출발 총성이 의미 있어진다.
팀을 고르는 데 신중하되, 너무 오래 고민하지는 말자. 팀빌딩 기간도 결국 레이스의 일부다.
자, 함께 달릴 팀을 찾았는가?
