[구름톤 13기 후기] 1부: 프론트엔드의 GDS 도전과 새벽 3시의 고비

정말 가고 싶었던 해커톤 중 하나였던 구름톤!
참여하면서 팀워크, 문제 해결 능력, 빠른 의사 결정이 얼마나 중요한지를 깨달았다. 제한된 시간 안에 기획부터 개발, 최종 발표까지 진행해야 하니 몸이 힘들었지만, 그만큼 뜻깊고 즐거운 경험이었다.
 
이번 글에서는 구름톤을 준비하는 방법부터 실제 진행 과정, 개발 중 맞닥뜨린 문제와 해결 과정까지 다뤄보려고 한다. 특히, 프론트엔드 개발자의 관점에서 경험한 점들을 중심으로 이야기 할 예정이니, 구름톤을 준비하는 분들에게 도움이 되길 바란다.

 

 

 

 

1. 구름톤 지원 & 준비

1) 지원서 작성 팁

구름톤에 다녀온 분에게 "어떻게 합격했나요?"라고 물어보면 "4시간 정도 지원서에 공을 들이면 된다"는 답변이 있었다. 그래서 나도 지원서 항목을 꼼꼼히 살펴보며 정성스럽게 작성했다.

이번 구름톤은 기존과 다르게 '디자인 시스템' 관련 질문이 추가되었는데, 처음엔 '왜 이게 추가됐지?' 싶었지만, 이후 구름 디자인 시스템 교육을 듣게 되면서 이유를 알 수 있었다. 평소 디자인 시스템을 깊게 공부하지 않았지만, 두루두루 접해본 경험이 있어 그 부분을 강조해서 작성했다.
또한, 구름톤 후기를 참고하여 '제주도의 사회문제', '사회문제를 해결하기 위한 서비스', '나의 장점', '구름톤을 통해 얻고 싶은 것'등의 질문을 보고 이에 대한 답변을 작성했다.

 

 

2) 보일러 플레이트 준비

개발 환경을 빠르게 세팅하기 위해 미리 보일러플레이트를 준비했다. 폰트 설정까지 할까 고민했지만, 너무 과한 것 같아 적절한 수준에서 마무리 했다.
평소처럼 설정했는데 작동하지 않아서 찾아보니, Tailwind CSS가 v4로 업데이트되면서 설정 방식이 달라졌다는 것을 알게 됐다. 역시 공식 문서를 확인하는 것이 정답이다!
또한, React와 Next.js를 따로 준비했는데, 해커톤에서 팀마다 프론트엔드 개발자가 2명 정도 배정되기 때문에 기술 스택을 오랫동안 협의하는 것보다 선택지를 넓히는 것이 좋다고 판단했다.

보일러플레이트 구성
- React, TypeScript, Sass, emotion, styled-components, Tailwind CSS, Vite
- Next.js, TypeScript, Tailwind CSS

 

 

3) 체력 관리

해커톤은 체력 싸움이기 때문에 미리 체력을 어떻게 안배할지 고민했다. 하지만 현실적으로 해커톤 전에 너무 바빠서 체력 관리를 할 시간이 없었다...😅
다행히 대학생 시절부터 밤샘 경험이 많아서 내 몸의 패턴을 데이터화해 두었다. 예를 들면, 밤을 새우면 인후통이 생기기 때문에 집에서 약을 챙기고, 제주도에서도 약국에서 추가로 구비했다.(참고로 해커톤 끝나고 2주 뒤에 결국 이비인후과에 다녀왔다...)
또한, 함께 지원했던 친구도 합격해서 글루콤(포도당 보충제)을 선물 받았는데, 효과가 좋았다. 구름톤을 준비하는 분들은 참고하면 좋을 듯하다!

 

 

4) 짐 싸기 꿀팁(겨울 버전) ⭐ ⭐ ⭐

• 멀티탭 챙겼지만 필요 없었음. 구름톤 장소마다 콘센트가 충분했다.
• 이동이 많아 짐을 최소화하는 것이 좋다. 필자는 제주시청 근처 게스트하우스에 묵었고, 구름스퀘어까지 택시로 10분 거리였다. 대신 숙박비는 아꼈다.
• 따뜻하지만 바닷바람이 차가워서 가디건은 꼭 필요하다.
• 해커톤에서 제공하는 굿즈 고려하여 캐리어 절반은 비워 가는 걸 추천 한다.
• 감기 예방을 위해 얇고 따뜻한 목도리 챙겨가는게 좋다.
• 해커톤이 끝난 후 짐이 늘어나기 때문에 가볍게 들고 다닐 보조 가방이 있으면 유용하다.

 

 

 

 

2. 구름톤 첫째 날

1) 자기소개 & 구름톤 주제 발표

 
해커톤 첫날, 도착하자마자 자리 배정이 이루어졌다.
참가자들에게 작은 선물과 함께 조 번호표가 제공되었고,
해당 번호에 맞는 자리에 앉으며 자연스럽게 주변 사람들과 대화를 시작하게 되었다.

 

우리 조에는 기획자, 디자이너, 백엔드 개발자 1명, 프론트엔드 개발자 2명이 포함되어 있었고,
특히 제주도민 참가자가 있어서 제주도에 대한 이야기도 들을 수 있었다.

곧 자기소개 시간이 시작되었는데... 사실 나는 자기소개를 하루 전날 밤, 제주도에 도착해서야 부랴부랴 작성했었다. 원래는 미리 준비하려 했지만, 일정이 너무 바빠 뒤늦게 마무리하게 된 셈이다.

 

그리고 이렇게 만든 자기소개 덕분에, 어색한 분위기 속에서도 자연스럽게 웃음을 유도할 수 있었다.

 

이후 구름톤톤의 주제가 발표되었는데, 핵심 키워드는 '제주, 클라우드, 공유경제'였다. 이 키워드를 기반으로 참가자들이 해결할 문제를 정의해야 했다.

 

 

2) GDS 교육 후기

 
구름톤 주제 발표가 끝난 후, 참가자들은 역할에 따라 교육을 받았다.

• 백엔드 개발자 -> Krampoline(컨테이너 기반 개발·운영 환경) 교육
• 기획자·디자이너·프론트엔드 개발자 -> GDS(구름 디자인 시스템) 교육

교육을 다 들은 후에, 기획자들은 따로 운영진들과 커피챗을 진행했고,
GDS(구름 디자인 시스템) 실습은 디자이너와 프론트엔드 개발자들만 참여했다.
 
나는 처음 사용해보는 GDS 문서를 보면서 실습을 따라갔는데,
문서와 실제 적용 방식이 조금 달라서 예상보다 시간이 걸렸다.

 

 

 

 

3. 구름톤 둘째 날

1) 아이디어 발표:와 팀빌딩 과정

둘째 날의 시작은 30명의 아이디어 발표로 열렸다. 발표 시간은 단 2분. 모두가 짧은 시간 안에 자신의 아이디어를 어필해야 했기 때문에 긴장된 분위기가 가득했다. 특히 기획자와 디자이너들의 긴장감이 더 두드러졌다.
 
발표된 아이디어 중 몇 개는 꽤 인상적이었지만, 한 가지 아쉬운 점이 있었다. 아이디어와 발표자가 잘 매칭되지 않아서 나중에 팀을 구성할 때, 원하는 아이디어를 제안한 사람이 누구인지 기억하기 어려웠다. 만약 특정 아이디어에 관심이 있다면, 반드시 그 발표자의 이름과 얼굴을 기억하는 것이 중요하다. 운영진이 팀을 매칭해주는 것이 아니라 참가들이 직접 어필하며 팀을 구성하는 방식이었다. 팀빌딩 시간에 나와 눈이 마주친 사람이 있었다.
그 사람이 속한 팀은 기획자, 디자이너, 백엔드 개발자로 구성되어 있었고, 프론트엔드 개발자가 없는 상태였다.
기획자님과 대화를 나누면서, 유연한 사고를 가지신 분이라는 인상을 받았다.
팀에서도 프론트엔드 개발자가 필요했기에, 함께하기로 결정했다.

 

 

2) 팀원 소개 & 첫인상

우리 팀은 기획자 1명, 디자이너 1명, 백엔드 1명, 그리고 프론트엔드 2명 이렇게 총 5명으로 구성되었다. 재미있던 점은 나를 제외한 모든 팀원이 I(내향형) 성향을 가지고 있었다는 것.

팀 빌딩 후 점심을 함께 먹었는데...
정말 아무 말도 안 했다.ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
내가 말 걸때만 대답해주시고 그 이후로
정적. 침묵. 고요.ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
 
솔직히 처음에는 조금 당황스러웠지만, 한편으로는 협업에 대한 기대감도 컸다. 조용한 분위기 덕분에 각자의 역할을 확실히 수행할 것 같았다. 사실 해커톤에서는 불필요한 대화보다 빠르게 기획하고 개발하는 것이 더 중요하기 때문에, 이런 분위기가 오히려 도움이 될 수도 있다고 생각했다. 마지막 날에는 함께 식사를 했는데, 처음 만났을 때보다 조금 더 편하게 이야기를 나눌 수 있었다.

 

 

3) 기술 스택 & 협업 방식 논의

1. UI 라이브러리: GDS(구름 디자인 시스템) 선택

운영진에서 GDS를 사용하면 가산점을 준다고 해서 UI 라이브러리로 선택했다.
솔직히 가산점이 아니었다면 GDS를 썼을까? 🤔
아마도 안 썼을 것 같다.
 
GDS의 의도나 방향성 자체는 괜찮다고 느꼈지만, 교육을 받을 때 공식 문서를 읽기가 불편했다. 퍼블리싱하는 데 시간이 오래 걸릴 것 같다는 걱정도 있었고. 그래도 팀원들이 GDS를 써보자는 의견이 더 강했고, 새로운 걸 경험해보는 것도 나쁘지 않겠다는 생각이 들어 결국 사용하기로 했다.
 
다만, GDS가 오픈소스가 아니라 프라이빗 npm 라이브러리라서 나중에 문제가 생기면 대처하기 까다롭겠다는 느낌이 들었다.
 
그래도 팀원들과 같이 고민하고 해결책을 찾아가는 과정 자체가 의미 있었다고 생각했었다. 당시에는 새로운 걸 빠르게 익히고 실전에 적용하는 경험, 그리고 협업하면서 문제를 풀어나가는 것이 가장 중요하다고 느꼈다.

2. 백엔드와 프론트엔드 코드 관리 방식: 멀티레포 선택

백엔드와 프론트엔드를 어떻게 관리할 것인가? 이 부분도 중요한 논의였다.

• 모노레포: 한 레포에서 관리 기능을 한눈에 볼 수 있지만, Git 충돌 위험 증가
• 멀티레포: 각자가 독립적으로 작업 협업이 번거로울 수 있지만, 개발 속도 유지

나는 멀티레포를 강하게 주장했다. 이유는 해커톤에서는 속도가 생명이기 때문이다.
Git 충돌이 자주 발생하면 기능 개발 속도가 느려지고, 결국 프로젝트 완성도에도 영향을 미칠 수 있다.
특히, 짧은 기간 동안 빠르게 구현해야 하는 해커톤에서는 리스크를 최소화하는 것이 핵심이라고 생각했다.

 

 

4) 다시 시작하는 아이디어 회의

인생을 살다 보면 예상치 못한 순간이 온다. 구름톤도 마찬가지다.
처음에는 방향이 정해진 듯했지만, 논의가 길어지면서 기존 아이디어의 현실적인 문제들이 하나둘 드러났다.
결국, 아이디어를 다시 짜기로 결정했다.

해커톤의 주제가 ‘제주, 클라우드, 공유경제’였기 때문에 이 범위 내에서 적절한 아이템을 찾아야 했지만,
처음부터 다시 시작하는 만큼 감을 잡기가 쉽지 않았다.
회의가 1시간 넘게 공회전하던 중, 기획 멘토님이 브레인스토밍을 제안했다.
흐름이 막혀 있는 상태에서 단순한 토론만으로는 답이 나오지 않을 것 같았다.
그래서 내가 직접 MC 역할을 맡아 "5분 줄 테니, 각자 관심 있는 걸 적어보아요"라고 제안했다.

진행 방식

1. 5분 동안 각자 떠오르는 아이디어를 메모
2. 각자가 적은 아이디어를 공유하면서 겹치는 부분을 정리
3. 가능성이 높은 아이템들을 추려서 현실적인 검토 진행
4. 팀원들의 선호도와 개발 가능성을 고려해 최종 결정

이렇게 진행하자 막연하게 이야기하던 흐름이 정리되었고, 각자의 생각이 구체화되면서 자연스럽게 논의가 진행되기 시작했다.

처음에는 막막했지만, 이 방식이 효과적이었는지 2시간 만에 아이디어가 확정되었다.

그렇게 브레인스토밍 끝에 도출된 다양한 아이디어 중, 팀원 모두가 공감한 주제는 '제주의 향토음식 문화' 였다.

 

우리는 이 주제를 바탕으로, '제주의 향토음식'을 주제로 한 공유 클래스 서비스를 기획했다.

 

 

 

 

4. 구름톤 셋째 날

본격적인 개발이 시작됐다.
구름톤을 준비하면서 다양한 개발 환경을 고려해 React와 Next.js 기반의 보일러플레이트를 미리 만들어 두었다.
같은 팀의 프론트엔드 개발자와 논의한 결과, React, TypeScript, Tailwind CSS로 세팅하기로 결정했다.
덕분에 개발 환경을 빠르게 구성할 수 있었다.
다만, 폰트를 미리 설치하지 않은 것이 조금 아쉬웠다.
하지만 다행히도 GDS에서 기본 폰트로 Pretendard를 제공했기 때문에 따로 신경 쓰지 않아도 됐다.
그리고 라우팅과 레이아웃 작업은 예상보다 수월하게 진행됐다.
이전 프로젝트들을 참고해 적용하고, 공식 문서를 확인하면서 바뀐 부분만 정리했더니 예상보다 빠르게 끝낼 수 있었다.
 
  

1) GDS(구름 디자인 시스템)를 사용하며 겪은 시행착오들

GDS를 처음 사용하면서 여러 가지 시행착오를 겪었다.
특히, 문서에서 원하는 정보를 빠르게 찾기가 어려웠고, Tailwind CSS와 연동하는 과정에서도 고민이 많았다.

 

1. 아이콘 버튼 사용 시 아이콘 크기 설정

GDS에서 아이콘 버튼을 사용하면서 아이콘 크기 조절 방법을 찾느라 한참 헤맸다.
처음에는 GDS 문서에 아이콘 관련 가이드가 따로 있을 거라고 생각했지만, 원하는 정보를 쉽게 찾을 수 없었다.
결국 프론트엔드 멘토님께 질문하러 갔고, "usage -> icon-usage" 메뉴에 관련 내용이 있다는 걸 알게 되었다.
알고 보니 당연히 있을 만한 곳에 있었지만, 나는 처음부터 'Icon' 메뉴에 있을 줄 알고 그 안에서만 찾고 있었다.
다시 보니 'Icon' 메뉴 안에 icon-usage로 넘어가는 버튼이 있었는데, 그걸 놓쳤던 것 같다.

왜 못찾았을까....

 

2. GDS 색상 변수를 Tailwind CSS에서 적용하는 방법

공식 문서를 보니 색상 변수를 복사하는 기능이 있었지만, npm 라이브러리에서 색상 변수가 제공되는지 궁금해서 멘토님께 질문하러 갔다. 멘토님께서는 GDS에서는 색상 변수를 제공하지만, 기본적으로 순수 CSS 사용을 권장하고 있다고 말씀하셨다.
사실 이 이야기만 듣고 돌아가려고 했는데, 멘토님께서 어떤 CSS를 사용하는지, 왜 이 변수를 적용하려는지 되물어 주셨다. 그러면서 Tailwind CSS v4 기준으로 GDS 색상 변수를 사용하는 방법을 찾아주셨고, 덕분에 예상보다 빠르게 해결할 수 있었다. 만약 이 정보를 몰랐다면, 직접 찾는 과정에서 많은 시간을 허비했을 것 같다.

색상 변수를 복사하는 기능

 

3. 컴포넌트별 색상 이름이 제각각이라 혼란

GDS에서 제공하는 색상 변수 이름이 컴포넌트마다 다르게 적용되어 있어서, props에 전달할 color 값을 찾는 게 쉽지 않았다.
특히, 피그마에서 Text 컴포넌트의 색상이 gray-100, gray-500 이런 식으로 되어 있었기 때문에, 해당 색상이 GDS 공식 문서의 색상 변수와 일치하는 지 일일이 확인해야 했다.
그런데 해커톤에서는 빠른 작업이 중요하다 보니, 결국... 공식 문서에서 비슷한 색상을 찾아서 대충 때려 맞췄다.
(코난인줄...이건 비밀이다.)

Text 컴포넌트 색상 찾기 대소동...

 

 

2) 새벽 3시, Dialog가 말을 안 듣는다.

"이제 다 됐겠지?" 생각하며 Dialog 컴포넌트를 마무리하면 끝날 줄 알았다.
그런데... 갑자기 콘솔이 빨갛게 물들며 경고 메시지가 폭탄처럼 쏟아졌다.

Warning: Function components cannot be given refs. Attempts to access this ref will fail. Did you mean to use React.forwardRef()?

 "이거 뭐야...?" 순간 멍해졌다.
이미 새벽 3시, 머리는 굳어가고, 눈은 감기는데...
Dialog는 도무지 말을 듣지 않았다.

 

원인찾기

일단 침착하게.. 내가 추가했던 요소들을 하나씩 제거하면서 문제점을 찾았다.

<Dialog.Trigger asChild>
  <Button
    size="xl"
    color="danger"
    stretch
    disabled={currentParticipants >= maxParticipants}
  >
    {currentParticipants >= maxParticipants ? '참여 마감' : '배우러 가기'}
  </Button>
</Dialog.Trigger>

 이 부분이 문제였다. 하지만 새벽이라 머리는 제대로 돌아가지 않았다.
생각이 한계가 다다라서 같은 팀 프론트엔드 개발자에게 물어봤다.
"이거 ref 에러 해결해야 할까요?"
그리고 돌아온 답.
"warning이니까 그냥 들어가서 자요."
그때가 아침 7시였다.
이 말을 듣고 그냥 페이지 4개 마무리하고 잤다.

 

문제의 원인

이 문제는 당시 사용 중이던 GDS의 Dialog 컴포넌트에서 발생한 것이다. Dialog.Trigger 내부에 ref를 전달하려 했는데, Button 컴포넌트가 함수형이라 ref를 받을 수 없어서 생긴 경고였다.

이후 GDS의 토큰 만료 문제로 전체 UI 라이브러리를 shadcn/ui로 교체하면서, Dialog 컴포넌트도 shadcn의 것으로 바꿨다.

그래서 지금은 같은 문제가 발생하지 않지만, 혹시 shadcn/ui에서도 유사한 구조를 쓴다면 같은 ref 충돌 이슈가 발생할 수 있으니 구조를 미리 점검해두는 것이 좋다.

 

 

 

 

5. 해커톤에서 완벽보다는 속도

해커톤에서는 최대한 빨리 문제를 해결하고 결정해야 한다.
처음 써보는 GDS도, 익숙하지 않은 Tailwind CSS v4도, 그리고 새벽 3시 Dialog 버그....
결국 어떻게든 해결해 나갔다.
하지만, 중요한 건 완벽한 코드를 짜는 게 중요한 게 아니라, 마감 전까지 결과물을 만들어 내는 것이 가장 중요했다.
이제 남은 건 프론트 배포, API 연결, 그리고 발표...
구름톤의 마지막 날, 과연 우리는 무사히 완성할 수 있을까?
2부에서 계속됩니다...