📌 해커톤에 참여하게 되었습니다만

벌써 해커톤에 참여한 지 거의 일 년이 지나가버렸다.
그래서 기억이 온전하게 남아있는 것은 아니지만, 최대한 그때의 기억을 떠올리면 후기를 남기고자 한다.

1. 왜 해커톤일까?

해커톤은 개발에 입문한 사람들에게는 좋은 경험이라고 생각한다.
제한된 시간 내에 그 사람의 역량을 최대한으로 끌어내는 경험이라고 본다.

와글와글 해커톤 전에 나는 3rd University MakeUs Challenge 해커톤에 참여한 경험이 있었다.
그때 나는 개발에 막 입문한 상태여서, 다른 개발자들과 하나의 프로덕트를 만들어 낸다는 것 자체가 의미 있었고
무엇보다 깃 충돌을 실제로 경험한 것이 그때가 처음이었다.
해커톤이 아니었다면, 상대적으로 느긋하게 문제를 해결하고자 하였는데, 해커톤 상황에서 해당 문제를 겪자 집중력을 발휘하여 빠르게 문제를 해결해 나갔던 것 같다.
물론 힘은 들었지만, 짧은 시간 내에 성장했다는 인상이 강했고 그래서 또다시 해커톤에 참여하고 싶다는 마음이 컸다.

그런 이유에서 참여한 것이 바로 와글와글 해커톤이었다.

2. 우리 팀은 해커톤에서 어떤 전략을 취했을까?

크게 기획과 개발 측면에서 전략을 구분지었다.
각 측면마다 알맞은 전략을 취하고자 노력하였다.
다른 팀에 비해 상대적으로 이점을 가지고 있었던 점은, 팀원들이 나와 친한 친구들로 구성되었다는 사실이었다. 그래서 믿음이 바탕된 팀워크를 기반으로 전략을 세우고 실행했던 것 같다.

먼저 <기획>이다.
해커톤은 아이디어와 빠른 기획이 중요하다고 보았다.
시선을 끌 수 있는 아이디어와 빠르게 기획을 마무리 짓고 개발에 착수하는 것이 관건이라고 생각하였다.

따라서 1. 의사 결정은 한 명이 주축이 되어 빠르게 진행되는 방식을 선택하였다.
물론 팀원들과 오랜 시간 아이디어에 대한 의견을 나누고, 다채롭게 생각을 확장하는 방식은 팀원 전체의 의사를 반영한다는 점에서 의미를 가진다고 생각하였다.
하지만 우리는 기획을 빠르게 마무리하고 개발 착수 시점을 앞당기고자, 내 주도 하에 의사결정을 빠르게 내리는 방식을 선택하였다.
그래서 다른 팀에 비해 상대적으로 빠르게 기획을 끝내고 개발을 시작할 수 있었다.

다음으로 2. 구현 가능한 규모의 시선을 끌 만한 기획이다.
하지만 제한된 시간 내에 구현까지 할 수 있는 아이디어야 한다는 조건이 붙는다고 생각한다 그래서 구현 난이도가 낮은 일종의 카드 만들기 기능을 선택하였다.
하지만 해커톤에 흔하게 볼 수 있는 기능이었기에, 시선을 끌 만한 아이디어의 역할이 중요하였다. 당시 해커톤 주제는 '학교 생활에 접목하는 IT'였다. 따라서 타겟층을 대학교 재학생으로 잡고 그들의 관심 있어 할 주제를 잡아야 겠다고 생각하였다. 당시 창업학과인 코코네스쿨에 재학하면서 깨달은 사실이 유저의 공감대 수준에 따라 프로덕트의 시작점이 다르다는 것이었다. 예를 들어 가천대학교 민세림 학생과 가천대학교 이길여 총장님 두 사람에 대해 별도의 두 가지 프로덕트를 만든다면 다음과 같이 상상이 가능할 것이라고 본다. 이길여 총장님의 경우, 가천대학교 재학생이라면 모두 아는 인물이기 때문에 총장님에 대한 설명에 무게를 실을 필요없이 다른 마케팅에 더 집중할 수 있다. 하지만 가천대학교 민세림 학생의 경우, 해당 학생이 어떤 학생이 설명에서부터 시작해야 하고 학생들이 관심 있어야 할 요소를 조사하여 그것에 맞춰 민세림 학생을 설명하는 작업부터 돌입해야 할 것이다. 이러한 이유에서 유저가 형성할 수 있는 공감대의 수준이 중요하다고 보았다.
우리는 유저들의 공감대가 이미 충분히 형성되어 있고, 관심을 가질 만 한 아이디어를 찾았다. 그게 바로 이길여 총장님이었다. 카드 만들기로 구현 가능한 규모를 잡고 이길여 총장님으로 시선을 끌 만 한 아이디어 조건을 충족시켰다.

덧붙이자면, 구현 완성도와 수치화된 설명 또한 중요하다고 보았다. 그래서 최대한 구현을 완성하고자 노력하였고 해커톤 발표에서도 수치를 통한 발표를 진행하고자 노력하였다.

다음으로 <개발>이다. 나는 FE 개발을 담당하였기에, FE 기준으로 이야기를 해보려고 한다. 당시 개발과 관련된 자세한 이야기는 해당 링크를 통해 확인이 가능하다.

일부 내용만 발췌해보자면, 아래와 같다.

1.1. 기술 스택 선정 기준
기술 스택 선정은 다음과 같은 두 가지 측면을 기준으로 선택하였다.

1) 프로젝트 완성에 집중

프로젝트 진행 시, 개발자의 성장과 프로젝트의 완성도 간에 비율을 적절히 유지해야 한다고 보았다. 새로운 기술을 사용하여 개발자의 성장을 도모할 수도 있지만, 이에 몰두되면 프로젝트 완성도에는 방해가 될 수도 있다고 생각하였다. 따라서 프로젝트를 완성할 수 있을 정도의 수준 내에서, 개발자의 성장을 꾀할 수 있도록 기술 스택을 선정하였다. 나작길 베타 서비스의 경우, TypeScript라는 언어를 처음으로 사용해보는 대신 CSS 프레임워크의 경우 기존에 사용하던 styled-components를 채택하여, 개발자의 성장과 프로젝트의 완성도 간의 비율을 유지하고자 하였다.

2) 해커톤이라는 특수한 환경

해커톤에서는 제한된 시간 내에 결과물을 도출해야 한다고 보았다. 따라서 개발적인 측면에서는 변수를 최소화하는 것 역시 필요한 역량으로 생각하였다. 또한 기획 측면에서는 주어진 자원 내에서 해결이 가능한 지와 뚜렷한 기획 의도가 있는지(트래픽이 높은 프로젝트를 하고자 원했음)를 염두하였다.

3. 해커톤에 마주한 어려움들

1. "캔버스 크기가 이상해요"

나작길 프로젝트에 대해 설명해보자면, 총장님 꾸미기 서비스로 캔버스 위에서 총장님 캐릭터를 꾸미는 기능이 핵심이었다. 따라서 캔버스는 중요한 요소였는데, 캔버스 크기가 제대로 적용되지 않았다. 다시 말해 화면의 절반에서만 캔버스가 적용되어 화면 일부에서만 그림 그리기가 가능했던 것이다.

이때 배운 점은 검색 스킬이었다. 해당 이슈를 겪을 때, 해커톤에 참여 중인 멘토님께 도움을 청했다. 나와 동일하게 구글링을 하시다가, 내가 사용한 라이브러리 깃허브에 들어가서 이슈를 찾아 보시는 게 신선하게 느껴졌다. 당시 Fabric.js를 사용했기에 Fabric.js 깃허브에 들어가서 해당 이슈에 대해 검색하시는 것이 신기하였다. 항상 구글링만 하다가, 직접 해당 라이브러리 깃허브에 들어가서 이슈를 검색하는 것을 새로 배웠다.

2. "미리보기 화면에서 내가 꾸민 캐릭터를 어떻게 확인하죠?"

캐릭터 선택의 경우, Recoil로 선택한 값을 만들기 화면에서 미리보기 화면으로 넘겨주었지만, Fabric.js로 기능한 꾸미기 요소들은 Recoil을 사용하여 넘겨줄 수가 없었다.

이때 해결한 방식은 만들기 화면에서 해당 화면을 이미지화하여, base64 형태로 미리보기 화면으로 넘겨주는 것이었다. 해당 이슈에 대한 자세한 내용은 여기서 확인이 가능하다.

4. 해커톤 그 결과는

운이 좋게도...! 대상을 수상하게 되었다.

멘토 분 중 임효성 멘토님께서 운영 중이신 개발자라면 꼭 해본다는 밤샘 코딩🤯 이것이 젊음..? 해커톤 멘토 vlog에도 짤막하게 출연하게 되었다.

해커톤 수상 소감으로 '이길여 이길여 이길여'를 외치며, 수상에 대한 감사함을 이길여 총장님께 전하기도 하였다.

또한 완성 후 배포까지 꼭 하겠다고 하였는데... 과연 그 이후 행보는...?
To be continued...