들어가며
작년에 이어 올해 2년차 운영진으로 참가하게 된 멋사 중앙해커톤 참여 후기. 개발 인생 2년에서 가장 열심히 집약적으로 개발한 시간이며 그만큼 느낀 점이 많았습니다. 바로 가시죠.
1. 수상을 목표로 참가하다
올해 중앙해커톤은 이전과 다르게 한 달 전부터 개발을 시작할 수 있게 진행 방식이 바뀌었음을 미리 안내해줬습니다. 팀원 구성에도 제약이 없어, 운영진 6명이서 제대로 된 프로젝트를 하자는 의견이 자연스레 모여졌습니다.
그 밖에도 동기부여는 충분했습니다.
- 개발 2년차에 접어들어 왠만한 앱은 만들 수 있는 실력이 갖춰짐
- 무엇보다도 긴 호흡 같이 달려갈 좋은 동료 친구들을 어려움 없이 얻었음
- 중앙해커톤 수상을 목표로 아기사자(부원)들에게 좋은 본보기를 보여줄 수 있다는 취지
등의 큼지막한 이유가 있었고, 제 개인적인 상황도 슬슬 취업 준비를 위해 굵직한 프로젝트를 쌓아야하는 시기였기 때문에 동기부여는 차고 넘쳤던 것 같습니다.
7월 중순 전까지 실력을 정비할 수 있는 시간도 많았고, 트랙별 세션과 미니해커톤 등 여러 작은 이벤트들을 함께하면서 팀워크도 다져져 프로젝트를 시작하기에 더할 나위 없는 환경이었습니다. 그렇게 주제가 공개되고 개발이 시작되었습니다.
2. 자기효능감이 높아졌던 개발기간
이번 해커톤 주제는 디지털 격차를 해소할 수 있는 서비스를 개발하는 것이었습니다. 그 중에서도 4가지 분야를 정해주었는데,
- 이커머스
- 소셜미디어
- 공공 서비스
- 블록체인 온체인 서비스
위 네 가지 분야에 해당되는 서비스여야 했습니다. 그래서 저희 팀은 시장 내 택시 호출 서비스들의 불편하고 복잡한 절차로 인해 특히나 취약계층이 택시 이용에 어려움을 겪고 있다는 점을 포착, 미리 장소가 정해진 QR코드를 스캔한 뒤 전화번호만 입력하면 주변에 있는 택시를 호출할 수 있게 해주는 서비스(큐택)를 기획하게 됩니다.
이 서비스의 아이디어는 팀원의 자료조사 중 중국에서 이미 서비스 중인 '아폴로'를 벤치마킹해온 것이었습니다. 원 아이디어는 대기업인 '바이두'의 프로덕트로 단순히 QR코드 스캔이 주 소구점이 아니라 '무인 택시'를 이용하는 방법으로 제시된 장치였으나, 저희 조는 QR코드 스캔의 간편성에 집중해 디지털 격차 해소를 위한 서비스로 제작하기로 결정했습니다.
그렇게 주제를 정하고, 디자이너나 PM이 없어 해당하는 테스크들을 분담하고 처리한 뒤 실제로 개발에 착수하기까지는 1주일이 걸렸습니다. 다행히 모두 동기부여가 충만했고 비슷한 대처 경험이 있어 주먹구구식으로라도 해결해 개발을 시작했지만, 만약 동기부여가 충분하지 않았더라면 더 촉박했을 것을 상상하니 절실히 PM/디자이너의 필요성을 느끼는 순간이었습니다..
웹소켓, Push API, PWA
우선 저희 팀은 웹 뿐만 아니라 앱(iOS)을 제작할 수 있는 팀원이 있었기 때문에 아래와 같은 이원화 구조로 서비스를 디자인할 수 있었습니다.
승객(웹앱) - 기사(네이티브 앱)
승객 서비스(택시 호출)는 접근성을 최대화하기 위해 설치가 필요없는 웹앱으로, 택시 기사 서비스는 서비스의 안정성을 위해 네이티브 앱으로 제작하는 것이 낫겠다는 결론이었죠.
대략적인 서비스 플로우는 다음과 같습니다.
웹에서 택시 호출 -> 서버에서 배치 알고리즘으로 주위 기사 앱에 콜 노출 -> 앱에서 수락 -> 웹 소켓 통신으로 사용자에게 전달 -> ...
승객과 기사 간의 실시간 양방향 소통이 서비스의 코어였기 때문에 프론트엔드에서는 웹소켓 API를 채택해 즉각적으로 서버에서 오는 상태 메세지에 따라 화면을 단계 별로 노출시키는 과제가 주어졌습니다. 이 프로젝트를 시작하기 전엔 웹소켓이 채팅 서비스에 적용되는 기술이라고만 알고 있었는데, 실제로 서버와 소켓 연결을 통해 통신을 주고받으니 개발하는 재미가 쏠쏠했습니다.
또한 중앙해커톤 5일 전 추가적으로 호출 상태가 바뀔 때마다 상응하는 내용의 알림을 사용자의 디바이스에 푸쉬하면 UX 측면에서 매우 좋을 것이란 의견이 나와 부리나케 Push API를 도입하기도 하였습니다. 이 과정에서 서비스 워커의 존재, Firebase 그리고 PWA 제작까지 정말 많은 새로운 분야들을 경험할 수 있었습니다(여러 기능을 도입하면서 느꼈던 자세한 점들은 따로 글을 작성할 예정입니다). 그리고 Push API의 경우 직접 안드로이드/아이폰 환경에서 수없이 테스트를 해보며 결과적으로 그럴싸한 푸시 알림을 띄우는데 성공하면서 팀의 분위기는 최고조에 이르렀습니다..!
3. 그러나 결과는...
그렇게 자신감에 가득찬 채로 행사장이었던 양재 aT센터에 당도한 저희 팀은 프로젝트 제출 마감기한 전까지 수정의 수정을 거듭했습니다. 허허벌판이었던 랜딩 페이지에 서비스 가이드와 테스트 가이드 내용을 채워넣었고, 열심히 준비한 저희 팀 작품을 쉽게 이해할 수 있도록 7장 분량의 PPT에 서비스 설명을 갈아넣었습니다.
그리고 제출이 끝나자 저희는 노트북을 닫고 심사위원들이 테스트하는 로그를 본선 진출 발표인 04시 이후에 까보기로 하였습니다.
안타깝게도 저희의 꿈은 본선 진출 발표가 시작되면서 서서히 무너졌습니다. 300팀 중에 8팀이 본선에 진출하고, 그 중 4팀만이 수상하는 굉장히 야박한 구조였습니다. 발표는 신의 장난처럼 가나다 순으로 발표되는 듯 했고, 한 팀 한 팀 호명될 때마다 곧바로 무대에서 PT를 하는 쫄깃한 방식으로 진행되었습니다. 저희팀은 '한국외국어대'이므로 맨 마지막 시드에 가능성을 걸어야 했고, 호명된 팀들의 서비스 PT를 보면서 기대는 점점 우려로 바뀌기 시작했습니다.
왜냐하면 본선 진출 팀들의 서비스들이 하나같이 다 '인공지능','AI' 혹은 '가상화폐' 키워드를 달고 나왔기 때문이었습니다. 개중에는 간혹 '수화 서비스'나 '휠체어 전용 지도 경로 서비스' 등 그 쪽과 관련 없는 순수 '디지털 격차 해소' 주제가 나오기도 했지만, 절반 이상은 이미 메인 스폰서인 '위메이드' 소속 인사들이 대거 포진해있는 심사위원들이 원하는 바가 무엇인지 아는 것마냥 그런 달콤한 키워드가 끼워져있었습니다.
결국 저희 팀 프로젝트는 본선 진출에 실패하고 말았습니다. 저희 팀 본선 진출과는 별개로 수상한 팀들의 프로젝트는 전부 높은 퀄리티의 좋은 작품들이었습니다. 그리고 PT를 보면서 저희 팀의 발표자료도 본선 진출 팀들에 비해 매우 부족하다는 점도 발견했습니다. 물론 발표자료 제작은 기획/디자인 파트가 없어도 충분히 만들 순 있지만, 이러한 테스크들을 전담하는 인력이 있었더라면... 하는 아쉬움은 지워지지 않았던 것 같습니다.
현타
하지만 본선 진출 실패보다도 더 충격적인 점은 따로 있었습니다. 서버 로그를 열어보니 단 한 번도 저희 서비스에 접속한 기록이 없었다는 것을 발견했기 때문이었죠.
믿기지가 않았습니다. 아무리 예선 팀이 많더라도 적어도 한 번은 접속해서 사용해볼만한 서비스를 만들었다고 생각했는데, 단 한 명의 심사위원도 들어가볼 생각을 하게 만들지 못할 정도로 별로였나? 라는 생각이 들었습니다.
아무리 생각해도 주제가 식상하지도 않고 완성도도 꽤나 높은 것 같은데 이렇게 비참한 결말을 맞이하게 된 원인이 무엇인지 알 수 없었습니다. 억지로라도 'AI' 키워드를 끼워넣었으면 열어보기라도 하셨을까요?
프로젝트 시작 초기에 한 팀원이 공유한 해커톤 가이드 중에서 '반드시 주최 측과 스폰서가 어떤 단체인지 확인하고 시작할 것'이라는 충고 문구가 존재했음을 뒤늦게 깨달았습니다. 팔은 안으로 굽는다는 속담이 생각나는 순간이었습니다 😔.
결론
여러모로 느끼는 바가 많았던 해커톤이었습니다. 준비기간 동안 팀원들과 하루하루 열심히 개발하면서 프로덕트가 나날이 갈수록 변해가는 모습을 보면서 개발에 미쳐살 수 있었던 좋은 기회이기도 했고, 더더욱 멋사에 없는 정마저 떨어지는 순간이기도 했습니다 ㅋ
이 글을 혹시 중앙해커톤 전에 읽어보시는 분들은 부디 메인스폰서가 어느 회사인지, 그 회사와 멋사가 어떤 비즈니스에 몰두하고 있는지 꼭! 파악하신 다음 심사위원들의 입맛에 맞는 프로젝트를 개발하시는 것을 추천드립니다. 그게 아니라면 너무 개발에만 몰두하지 마시고 발표자료에도 정성을 들이시는게 나을 것 입니다. 아무리 열심히 만들어봤자 입맛에 안맞으면 간조차 보지 않을테니까요.
