[goorm x SeSAC x 서울경제진흥원] 새싹톤 우수상 후기 - 어서와, 해커톤은 처음이지?

해커톤이 끝났다.

왜 도전했나?

시작은 "한 번 해커톤을 경험해보고 싶다"는 단순한 마음이었다. 밤을 새워가며 고군분투하는 청춘, 열기, 몰입, 집중, 단합, 갈등, 합의와 해결의 과정들을 경험해 보고 싶었다면 지나친 낭만일까? 사실 주변에선 해커톤 경험을 부정적으로 보는 시각이 더 강했다. 쓸데없다나. 실제로도 유지보수 가능한 품질 좋은 코드를 짜거나 기술적 고민들에 관한 시간은 거의 없었다. 해커톤의 목적은 짧은 시간내의 눈에 보이는 높은 완성도를 내고, 기획의 방향을 올바르게 가져가는 것이 더 중요했기 때문에, 시장조사에 맞춰 변하고 추가되는 기획에 따라 우선 굴러가는 코드를 빠르게 만드는 것이 더 중요했다.

현재 나는 한 교육프로그램에 참여 중인데 실제 해커톤 오프라인 행사는 단 하루임에도 불구하고 팀 모임을 위해 3주간 3번 이상 빠졌던 것 같다. 코어타임에는 카메라만 켜둔 채 몰래 해커톤 작업을 하기도 했다. 나만 유난스러웠던 건 아니었다. 팀원 중에는 천안에서 학교를 다니는데 오프 팀모임을 위해 주1회 이상 천안과 서울을 오가셨다. 또 다른 팀원은 재직중이셨는데 퇴근 후 시간을 내어 열성적으로 임하셨다. 시상식을 위해선 직장인들의 피같은 연차를 내어 참여하셨다. 남들이 보기엔 유난스러웠을 수도 있겠다는 생각이 든다. 그러든가 말든가 꼭 해보고 싶었던 도전이었고, 3주라는 짧다면 짧은 시간 안에 많은 것들을 강렬하게 마주할 수 있던 시간이었다.

어떻게 진행됐나?

새싹톤

치열했던 1차 서류. 그 후 80팀중 45팀을 걸러내던 2차를 지나, DDP에서 열린 시상식에서 본선 진출 8팀에 선정. 그 중 우수상. 이 모든 것이 3주안에 속전속결로 이루어졌다.

빠르게 이번 2023 새싹톤에 대해 간단히 설명하자면, 이번 해커톤은 서울시 대표 SW 교육 브랜드인 청년취업사관학교(SeSAC)와 개발자 성장 중심 생태계를 만들어가고 있는 구름이 함께 기획하고 서울경제진흥원의 후원을 받아 진행된 장장 3주간의 해커톤이었다. 구름은 카카오의 후원을 받아 제주도에서 열리는 해커톤인 구름톤을 주최하는 것으로 개발자 지망생들 사이에서는 이미 유명한데, 기존 구름톤과 새싹톤은 진행방식에서 약간의 차이가 있었다. 구름톤이 개인 지원을 받아 개인들끼리 자기PR을 통해 자발적으로 팀을 꾸리고 진행되는 2박 3일간의 단기 해커톤이었다면, 이번 새싹톤은 개인&팀 지원을 받고 개인 참가자들은 주최측에서 팀매칭해주는 식으로 진행됐다.

매칭된/참가한 팀들은 첫 1주간 각자의 아이디어를 통합하고 사업계획서를 주최측에 제출한다. 이 때 1차 서류 통과한 80여팀 중 45팀만 남게 된다. 이후 2주간 시장조사를 하며 아이디어와 구체 기능들을 디벨롭하고 MVP(최소기능제품)을 만들어 최종 제출한다. 이후 시상식까지 남은 1주는 부족한 부분을 개선한다. 시상식 현장에서 45팀이 심사위원들에게 직접 시연하고, 최종 8팀이 본선에 올라가 스피칭 기회를 얻게 된다. 남은 건 최종 결과뿐이다.

기획

2차 이후 3주간 매일매일 진행됐던 데일리 스탠드업

우리 <자유로운우리를봐>팀은 개인 참가자들이 랜덤매칭된 개인참가자 팀이었다. 랜덤 매칭이었음에도 불구하고 배울 점이 많고, 협력에 최선을 다하며, 성취와 성장에 욕심이 엄청난 멋진 분들을 만나게 되었다. 정말 운이 좋다고 생각하는 부분이다. 감사하게도 늘 인복이 있는 편이다. 자유분방하게 만난 우리들은 '서울시'와 '교통' 이 두 키워드를 바탕으로 '자유로운 이동의 시작, FreeWay'라는 아이템을 들고 출전하게 됐다.

FreeWay가 나오기 전 시니어 크리에이터 커뮤니티 서비스, 취약계층을 위한 헬스케어 서비스, 일회성 커피컵 수거 서비스 등 다양한 아이디어가 제기됐다. 결론적으로는 Why: 무엇이 문제인가 -> How: 어떻게 해결할 수 있을 것인가 -> What: 무엇을 만들것인가. 의 순서를 따라가다보니 서울시 바퀴달린 이용수단을 사용하는 모든 교통약자들(ex.휠체어, 유모차)이 지하철 이용시 엘레베이터 정보에 대한 부족으로 이용에 어려움이 있었고, 대안으로 리프트를 택하다 사고로 이어지는 문제에 마주했다. 기사와 인터뷰를 통해 이것이 우리의 일명 '뇌피셜'이 아니라 실존하고, 해결 수요가 있는 문제임을 확인했다.

이제 바퀴를 발로 하는 서울시 교통약자들의 지하철 이동권 보장이 우리가 풀어야할 문제(Why)임을 확인했다. 다음은 어떻게(How) 해결할 수 있을지에 대한 고민이었다. 각 팀원이 어떤 데이터와 API를 사용할 것인지 조사에 착수했다. 해결이 필요한 실제문제라도 그걸 주어진 리소스(시간, 실력 등)내에서 해결가능한 문제인지에 대한 검토도 필요했다. 리서치를 하며 생각했던 기능들 중 어떤 부분이 가능하고 불가능한 지를 논의했다. 결과적으로는 바퀴 달린 이용수단을 이용하는 서울시 교통약자들에게 실시간 엘레베이터 고장여부와 편의시설을 제공하고, 보다 시각화되고 depth가 낮아 접근성과 이용성이 좋은 교통약자 전용 지하철앱(What)을 만들기로 했다. 이름은, 모두의 자유로운 이동권을 보장한다는 데에서 'FreeWay'로 붙였다.

개인적으로는 이 '팩트체크' 시간이 정말 중요했다고 생각한다. 열정 넘치는 팀원들이 만나 아이디어를 발산하다보면, '우리 아이디어 진짜 신박해. 최고야.' 늪에 빠져 실제 사용자들이 원하는 것과는 거리가 먼 서비스를 만들어 버릴 수 있기 때문이다. 실제 행사장엔 배너, 팸플릿, 시연을 위한 와이드 모니터와 각종 휴대폰 기기들까지 화려하게 준비한 팀들도 있었지만, 결국 본선 진출은 그런거 하나 없었던 우리팀이었던 걸 보면, 심사위원들이 봤던 것은 결국 '현실의 문제를 해결하는 실현가능한 아이디어'였지 않았을까 조심스레 추측해본다.

개발

이렇게 기획을 마친 후 나름의 구체화된 아이디어와 구현 방식을 잘 정리해 2차 과제로 제출했다. 합격. 2차 합격부터 시상식 전까지 매일 스크럼을 온라인으로 진행했고, 주1회 스터디룸을 빌려 대면 미팅을 진행했다. 그 때부터는 개발, 개발, 개발이었다. 마지막 주차 오프미팅 때는 지옥의 QA하면서 밤새고 새벽 4시에 택시타고 집에 갔다.

깃헙 세팅
세팅에 들어갔다. 지금껏 했던 사이드프로젝트에서는 경력이 있으신 분들이 주도해 레포를 파시고 Git규칙을 설정하시고 린트 등 깔고 머지 관리를 하셨다. 그러다보니 한 번도 팀활동시 Git을 제대로 경험해본 적이 없었다. 그래서 내가 하겠다고 자원했다. 이 때 처음 Git Flow를 학습했고, husky 등을 이용해 커밋 규칙을 설정했다. global style도 적용했다. 그런데 아뿔싸, invalid hook warning을 해결하지 못하고 설정을 마쳤는데 이 warning이 개발 기간 계속 남아있어 흐린눈 뜨고 애써 모른 체하며 작업하게 됐다. 멋있게 하겠다고 나섰는데 어설픈 초보티가 어쩔 수 없이 남아 이 자리를 빌어 같은 프론트팀 그린에게 미안하다는 말을 전하고 싶다. 어쨌거나 Git convention에 대한 이야기도 나눴다. 모노레포까지는 겁이 나서 도전을 못해봤는데 다음에 꼭 학습해서 적용해보고 싶다.

검색 파트
겁도 없이 검색 파트를 맡겠다고 했다. 이유는 경험해보지 않았던 부분이어서 배울 것이 많아보였다. 지도 파트는 지난 팀 프로젝트에서 이미 해봤었던 부분이어서 안정적이겠지만 그만큼 배울 부분은 적어보였다. 결과적으로는 이 선택에 후회한다. 개인이 아닌 팀 프로젝트였던 만큼 확실히 책임질 수 있는 부분을 졌어야 하지 않았나 하는 생각이 든다.

검색파트를 구현하며 Web Speech API라는 것을 써서 음성인식기능을 구현했고, 자동검색기능과 더불어 최근검색기능을 구현하였다.

상태관리
어려웠던 점은 비동기로 진행되는 상태관리였다. 현재 입력한 키워드가 로컬에는 입력되었지만, 새로고침 전까지 화면에는 반영되지 않는 이슈라던가. 사실 상태가 변하면 리렌더링을 해줘야하는 기본적인 부분인데 기본기가 부족했다고 생각한다. 또 생각해야 할 엣지케이스가 많았다. 예를 들면 '강남역'과 '강남' 모두 '역'키워들을 생략하고 '강남'키워드로 입력되도록 해서 데이터를 받아왔는데, 이 과정에서 '역삼역'은 '역'으로 분류되어 검색 결과에서 제외되었다. 이런 엣지케이스들이 QA에서 발견될 때마다 자잘한 수정들을 했어야했다.

라이브러리 충돌 이슈
사용했던 react-speech-kit 라이브러리는 무려 3년전에 마지막 업데이트가 된 오래된 오래된 라이브러리였다. 이 라이브러리 설치 후 다른 의존성 패키지들을 설치하려할 때마다 peer depenedcy 에러가 발생했는데, 찾아보니 이 라이브러리의 peer dependency 중 리액트가 버전이 15였나, 16이었나... 현재 버전 18이 나온 상황에서 이 오류를 해결하기 위해 리액트를 다운그레이드할 수 는 없는 노릇이었다. 결국은 --force와 --legacy-peer-deps로 해결했지만, 앞으로 라이브러리를 선정할 때는 최근 업데이트 날짜를 확인하고 계속해서 유지보수가 되고 있는 라이브러리인지를 확인해야겠다.

Lottie 모바일 깨짐 이슈
음성인식의 애니메이션 효과로 Lottie파일을 이용했다. 애니메이션을 넣으니 한결 앱이 좋아보였다. 그런데 후에 배포해보니 모바일 환경에서는 Lottie파일이 깨지는 것이 아닌가. 해결은 react-lottie를 설치하면 되는 간단한 이슈였으나 이를 해결하기 위해 ngrok을 활용했던 것이 기억에 남는다. ngrok은 서버에 배포하지 않고도 로컬의 작업을 네트워크를 활용해 모바일에서 볼 수 있게 해주는 기술인데, 이를 통해 보다 편리하게 작업할 수 있었다. 웹뷰 개발을 위한 하나의 노하우를 터득한 것 같아 뿌듯했다.

검색 기능을 마치며 후에 드는 생각은 바닥부터 개발할 필요는 없었다는 것이다. Algolia 등 기능부터 UI부분까지 훨씬 퀄리티 높은 결과를 낼 수 있는 라이브러리들이 있었다. 발견 시점엔 도입하기에 너무 늦어 활용할 수 없었지만 차후에는 사전 리서치를 더 철저히 하고 활용 가능한 라이브러리를 적극적으로 활용해야겠다고 다짐한 계기가 되었다.

무엇을 배웠나?

1. 소통은 자주할 수록 비용이 절감된다.

마지막 주차에 지옥의 QA를 하고 새벽4시에 택시타고 들어갔다고 했었다. 상금 100만원 받았는데 세금 떼고 팀원들하고 분배하고 고기 먹고, 이 때 쓴 스터디룸비랑 택시비로 충당하면 끝날 것 같다.

왜 QA를 새벽까지 해야했을까? QA를 3주 중 2주차 주말에 처음 진행했는데, 나는 사실 개발하면서도 틈틈히 피드백을 받고 싶었었다. 그런데 내 작업물에 대한 부족한 자신감에 아무도 제안하지 않은 QA를 먼저 제안하는 것이 꺼려졌다. 그렇게 미루다 마지막 주차에서 진행한 QA에서는 부족했던 점들이 터져나왔다. 1) CSS가 피그마와 달랐고 2) 음성인식api가 모바일에서는 작동하지 않았다. 또한 3) 검색 기능에서 여러 엣지 케이스가 발견됐다. 터져나오는 오류에 팀원들은 난감한 기색이었다. 그날은 최종 시안 제출 1일 전이었고, 이 문제들을 어떻게든 해결했어야했다.

이 문제를 사전에 해결할 수는 없었을까? 팀원들은 내 업무소화능력을 지난 소개로 어림짐작할 뿐 정확히 파악할 수는 없었다. 맡겨달라해서 믿고 맡겼을 뿐. 자신이 없었다면 오히려 더 나서서 'QA를 먼저 하며 피드백을 더 자주 받고 싶다'고 얘기했어야 한다. 이렇게 하면 더 완성도 높은 결과를 낼 수 있지 않았을까? '매도 빨리 맞는 놈이 낫다'와 'QA는 빨리 받을 수록 좋다'를 뼈로 새기며, 앞으로는 더 신중하게 일을 맡되 더 적극적으로 팀원들의 피드백을 요청할 것을 다짐한다.

2. 안 될 이유보단 '어떻게 되게 할 것인가'

나는 왜 더 많은 기술을 알아보지 않았을까? 차후 다른 팀 작품들을 보며 알았지만, 러닝커브가 높지 않은 OpenAPI들이 정말 많았다. 또 검색기능에서 써먹을 좋은 라이브러리들이 많았다. 하지만 실력에 대한 자신감 부족 때문에 최대한 아는 선에서 부담없이 처리하고 싶었고, '아, 그 기술은 아직 안써봐서...'라는 핑계를 대며 이런저런 새로운 시도에 주저했었던 것 같다. 결국 최선의 결과는 내지 못했던 거 아닌가 하는 아쉬움이 남는다. 이 기회를 통해 앞으로는 써보지 않은 기술에 대한 과감한 도전도 연습해나가려 한다.

3. 절감한 기획의 힘: 자원을 투자할 가치가 있는가?

이번 해커톤 참가를 통해 가장 임팩트있게 다가왔던 부분이었다. '사용자들은 정말 우리의 서비스가 원하는가?(우리의 뇌피셜이 아닌가?)'의 확인 여부는 서비스의 성공 여부에 가장 중요한 부분이었다. 기획에서 꼼꼼히 챙겨가시는 팀원분들을 보며 많은 것을 배웠다.

4. 백엔드 기술이 있는 프론트엔드가 되자.

백엔드 출신 프론트엔드분이 자유롭게 백엔드와 소통하시는 모습을 보며, '프론트만 해서는 안되는구나'를 절감했다. 이번엔 저 분이 계셔서 백엔드와의 소통 불능으로 자원낭비하는 일이 없었지만, 만약 나 혼자였다면 안겪어도 됐을 소통 장애들을 몇 번이나 겪지 않았을까. 특히 CI/CD(Github Action)와 배포, 서버 개발을 학습해보며 추후에 있을 백엔드와의 협업을 대비해야겠다고 느꼈다.

5. CSS는 피그마에 있는 그대로.

'1px만 옆으로 옮겨주세요'는 도시괴담이 아닌 사실이었다. 디자이너님은 어떻게 14px인지 15px인지 찾아내는 걸까? 하지만 확실한 건, 디자이너님이 그리신대로 정확히 css를 했더니 앱이 훨씬 살아났다는 것. QA때 아옹다옹하지말고 처음부터 잘하자. 애초에 피그마에 있는 그대로 구현하는 것에 집착하며 작업해보자.

팀원들에게

'자유로운우리를봐'팀 그린, 레드, 블랙, 옐로우 다들 잘 지내고 있나요? 벌써 시간이 이렇게 흘러 해커톤이 끝난 지 일주일이 지났네요. 3주간 매일 했던 스크럼...아직까지도 저녁 9시만 되면 디코에 접속하고 노션에 오늘 했던 작업을 적어야할 것 같은 기분이 들어요. 팀을 위해 더 좋은 프론트엔드 개발자가 되지 못한 것 같아 미안하고 고마워요.

천안과 서울을 오가며 시험기간과 병행했지만 힘든 내색 하나 없이 긍정 에너지를 팀에 심어주던 막내 리더 레드, 디자인 천재, 소통의 만재, 날카로운 통찰로 기획까지 캐리하시던 만능 인재 블랙, 백엔드 지식과 만렙 소통 스킬로 적극적으로 요구사항 반영 및 구현하던 든든한 프론트, 그린. 철저한 사전 조사와 불같은 실행력으로 끝까지 열정적으로 임하셨던 우리팀의 아르기닌, 기획자 옐로우.

제게 과분한 팀이었어요. 덕분에 많은 것을 배우고, 느끼고, 성장할 수 있었어요. 감사합니다.

마무리 하며...

출처 - 새싹톤. DDP(동대문 디자인 플라자)에서 열린 시상식.

모두의 열정에 자극받았던 시간이었다. 팀 내에서 프론트엔드 개발자의 역할을 고민하며 얻었던 개인적인 성장과 더불어 수상의 결과까지 얻어 더욱 값졌던 경험이었다.

이런 좋은 기회를 준 2023 새싹톤을 기획 및 운영하느라 수고해주신 모든 분들께 감사 인사를 드리고 싶다. 또한 참여하여 모든 열정을 나눠주신 자라나는 새싹팀들에게도.