참가 접수

한창 교육 중인 K-DT 교육(KT 에이블스쿨)에서 함께 프로젝트를 진행했던 동료분이 함께 참가해보자고 해서 참여하게 되었다.

말은 해커톤이지만 장장 2달에 걸친 긴 기간동안 진행이 된다.

심사는 다음과 같이 총 3번 이루어졌다.
1. 참가팀 선발 (178팀 -> 61팀)
2. 예선심사 (61팀 -> 본선진출 8팀 + 장려상 6팀)
3. 본선심사

원래는 50팀 선발 예정이었으나 참가팀이 예상보다 많아 10팀을 더 뽑았다고 한다.

특이한 점은 본선에만 진출해도 최소 우수상이 확정된다는 점
그리고 예선까지는 순수 기획서로 심사를 진행한다는 점이다. (중요)

참가팀 선발

아이디어 도출

일찌감치 참가를 결정했던 만큼 4월 말부터 주 3~4회 회의를 진행하면서 아이디어를 도출했다.

회의는 이전에 비대면 스터디 때 사용했던 게더타운 공간이 있어 그곳에서 진행하였다.

아무래도 K-DT 수강을 병행하며 진행하는 만큼 수업 끝나고 저녁 9시쯔음 모이거나, 주말 저녁에 진행했는데, 생각보다 아이디어 도출 과정이 너무 어려워 자정을 넘어서까지 진행되는 경우가 많았다.

우선 브레인스토밍처럼 최대한 다양한 아이디어를 모아놓고, 각자 디벨롭하여 아이디어를 구체화 한 뒤 투표하는 것을 통해 결정했다.

mural이라는 웹 화이트보드 서비스를 이용해서 투표를 진행하여 최종 아이디어를 결정했다.
에이블스쿨에서 처음 배운 도구인데 꽤 여기저기 요긴하게 쓸 수 있는 것 같다.

공통적으로 아이디어를 선택할 때 다음과 같은 요소들을 많이 고려했다.

• 꼭 AI를 적용해야하는 것인지
• 사업성이 있는 것인지 (이걸 돈 받고 팔 때 사줄 사람이 있나?)
• 기존 아이디어들에 비해 차별성이 있는 것인지
• 구현 가능성이 보이는지

가장 어려운 것이 차별성이었는데, 어지간한 아이디어는 이미 서비스가 있거나 다른 공모전에 나온 것들이 많았다.

최종적으로 매일을 기록하여 일기를 요약해주는 서비스를 선정했다.

최초 아이디어는 다른 분이 제시하셨는데 (아마 인스타, 페북 게시글 써주는 서비스를 생각하신듯)
내가 평소에 일기를 많이 써봤던 사람으로써 굉장히 좋은 서비스라 생각하여 열심히 디벨롭하여 밀었고, 가장 많은 투표를 받게 되었다.

기획서 작성

가장 어렵고, 지긋지긋했던게 기획서 작성이었다.

선정 배경, 아이디어 설명, 기술 스택, 팀원 구성 및 개발 계획 등을 총 5페이지 이내로 요약해야 했는데, 쓰는 것도 쓰는 것이지만 5페이지에 맞게 줄이는 것도 너무 어려웠다.

제출일까지 평일, 주말 가리지 않고 매일 모여 새벽까지 문서작업을 진행했다.

작업은 DOCX 파일을 구글 독스에 업로드하여 공동 작업했다.
파일이 깨지거나, 날아갈 뻔 하는 불안한 상황이 종종 있었지만, 공동작업하기에는 구글 독스가 아직 최고인 것 같다. (렉 없음, 한글 잘 쳐짐 등)

전략

기획서는 최대한 사업적인 측면을 고려하여 작성했다.
쉽게 말해 왜 이 서비스가 필요하고, 왜 이 서비스가 이용자들이 돈을 지불해서라도 이용할 가치가 있는지를 많이 설명하려 노렸했다.

그 외에에 개발 관련 부문(서비스 아키텍처, 사용 기술, 서비스 플로우, UI/UX, 간트 차트 등)은 모두 도표나 다이어그램을 그려 사진 한 장으로 볼 수 있도록 하였다.

기획서 제출과 개발 시작

기획서를 제출하고 본격 개발을 시작하게 되었다.
사실 대체로 아이디어에 대한 확신이 없는 분위기였기 때문에 발표하고 시작하자는 말이 많았는데, 그 사이에 개발 환경을 구축해오신 팀장님... 정말 존경스럽다.

아무튼 결론은 참가팀 60팀에 선정되어 예선을 진행하게 되었다.

예선

개발

처음 접하는 Flutter

[노마드코더]Dart 시작하기
[노마드코더]Flutter 로 웹툰 앱 만들기

만들고자 하는 서비스가 앱 서비스고, 팀장님이 플러터 개발 경험이 있었기 때문에 Flutter를 개발 프레임워크로 선택했다.

물론 나는 경험이 없었기 때문에 단기간에 배울 수 있는 강의를 찾았고, 이전에 Javascript를 배울 때 정말 도움이 많이 되었던 노마드코더의 강의를 찾았다.

담당

개발초기 내가 담당한 부분은 다음과 같다.

1. 유저가 앱을 종료해도 하루 동안 유저가 이동하는 위치를 기록해 저장하기
2. 기록한 위치를 바탕으로 유저가 방문한 장소 알아내기
3. 방문한 장소 후보를 사용자에게 보여주어 정확한 장소 선택하게 하기

난관

1. Geolocator 오차

var currentPosition = await Geolocator.getCurrentPosition(
      desiredAccuracy: LocationAccuracy.bestForNavigation);

우선 유저가 같은 장소에 오래 머물 것을 고려해 15분마다 위치를 찍어 같은 장소면 카운트를 증가시키고, 아니면 새로 저장하도록 하였다.

가장 정확도가 높다는 bestForNavigation을 이용했으나, 최대 30~50m 수준의 오차가 발생하였고, 이로인해 가만히 있어도 매번 장소가 다르게 찍히는 문제가 발생했다.

우선 수식을 통해 127.083313 형식으로 저장되는 좌표정보를 시'분''초'''로 변환하고, 대략 50m의 범위를 하나의 위치로 간주하도록 하였다.

2. 지도 API의 문제점

카테고리별 검색이 가능하다는 이점 때문에 위치좌표를 바탕으로 장소를 검색할 때 카카오 로컬 API를 이용하였다.

그런데, 실제 가게가 있는 위치와 지도가 나타내주는 위치가 달라서 원하는 장소를 못 불러오는 경우가 많았다.

여러번 실험해보니 구글 지도가 비교적 정확했지만, 구글은 아주 기초적인 정보(장소명과 주소) 정도만 제공해줘서 인공지능에 활용할 정도로 충분한 정보를 제공해주지 못했다.

그래서 둘 다 이용하는 방법을 택했다.

1. 우선 구글 API를 이용해 장소 정보를 가져옴 (좁은 범위 검색)

• 장소명 : 비안빈 Bianbean Cafe, 어머니 손맛 닭갈비

2. 카카오 API의 검색어로 넣기 위해 문자열을 파싱함

• 장소명 : 비안빈, 어머니
• 이렇게 한 이유는 구글에 등록된 장소명에는 영어도 섞여있고, 카카오와 다른 경우가 많아 통채로 검색어를 넣으면 못찾는 경우가 많았기 때문

3. 카카오 API로 검색어를 검색하여 자세한 장소 정보를 가져옴 (비교적 넓은 범위 검색)

이렇게 하여 사용자가 있는 장소를 거의 항상 들고올 수 있게 되었다.

3. 너무 많은 결과

GPS 오차 때문에 넓은 범위를 하나의 좌표로 퉁치고, 또 검색되는 키워드는 죄다 들고오니 좌표 하나에 30개가 넘는 장소 정보가 저장된다는 문제가 있었다.

대체로 부동산, 회사 사무실, 공중전화 부스 등의 장소들이 많았고, 이건 그냥 하드코딩을 해서 특정 키워드가 들어간 장소는 아예 저장되지 않도록 하였다.

이렇게 해서 많아야 10개 정도, 평균 5~6개의 장소가 저장되도록 하였다.

4. 사용자에게 보여줄 장소 선정

사용자가 방문할 장소 모두를 죄다 일기로 만들어 줄 수 없기 때문에, 중요도 기반으로 3개의 장소를 뽑기로 하였다.

문제는 그 중요도를 어떻게 매기냐는 것인데
처음엔 이를 처리하는 머신러닝 모델을 이용할까 했지만, 관련된 데이터를 찾기 어려워 결국 규칙기반으로 처리하기로 했다.

1. 추출된 장소가 일정 갯수 이상이면서
2. 사용자가 오랫동안 머문 공간(count가 높은 공간) 상위 3개

간단하지만 꽤 효과적이었다.
사용자가 이동하면서 들르는 장소는 대부분 걸러졌고, 집 같이 주변에 검색될 만한 장소가 적은 곳은 대체로 걸러지는 효과를 얻었다.

기획서 (중요)

개발도 개발이지만 결국 심사는 기획서로 이루어지기 때문에 오히려 개발보다 기획서에 더 많은 시간을 투자해야 했다.

참가 팀 선발때와 동일한 양식의 기획서지만, 작성 분량이 10장으로 늘어난다.

이런 기획서를 적어본 팀원이 적었기 때문에 우리는 최대한 해커톤에서 제공하는 4번의 멘토링 기회를 최대한 활용해보고자 하였다.

멘토링 (중요!!)

다른 참가팀들은 멘토링 때 어떤 점을 피드백 받았는지는 모르겠지만, 우리 팀은 4번의 멘토링 기회 모두를 기획서 보완에 사용했다. (개발은 구글과 스택오버플로우라는 훌륭한 멘토가 이미 계시므로...)

멘토링 때마다 언급된 피드백은 다음과 같았다.

• 아이디어는 참신한데 일기 써주는 서비스를 사람들이 돈 주고 이용할 지 잘 모르겠다.
• 일기 생성해주는 서비스 하나만으로 너무 약하다.
• 서비스 플로우가 잘 설명되어있지 않다 (잘 이해되지 않는다)
• 결국 사회적 효과보다는 수익성을 노리는건데, 사업 모델이 잘 설명되어있지 않다.

이 세가지를 보완하기 위해 많은 노력을 기울였다.

지금 돌이켜보면 멘토링을 잘 활용하고, 받은 피드백들을 보완하려 노력했던 것이 수상의 핵심이지 않았나 싶다.

지옥의 기획서 회의

아이디어 도출에 이어서 매주 월, 수, 금 + 주말 이틀마다 자정넘은 시간까지 다같이 모여 기획서를 작성하는 지옥주가 계속 되었다.

팀원 전부가 하나의 문서에 달라붙어 작업하다보니 작업 효율은 진짜 꽝이었는데, 그만큼 세세한 부분까지 놓치지 않고 고쳐나갈 수 있었다.

그렇게 예선 심사 과제를 제출하였다.
본선 발표까지 3일? 정도의 시간이 있었는데

개인적으로 본선 진출 가능성이 낮다고 생각했는데, 그래도 서비스는 완성해보고 싶어서 개발 발표 때까지 꾸준히 개발을 진행했다.

본선

이게 되네

한창 수업을 듣던 중 예상했던 발표시간보다 빨리 문자가 왔는데
대뜸 합격했다는 소식에 이게 꿈인가 싶었다.

단순히 서비스 소개나 기술을 나열하지 않고, 진심으로 사업할 것 처럼 철저히 기획서를 작성했던게 합격에 많은 도움이 된 것 같다.

개발 + 발표 준비

이제 결과 발표까지 2주 조금 안되는 시간이 남았는데
문제는 개발 진도가 매우 더뎠다는 점이다.

심지어 서비스가 약하다는 피드백을 받고 '교환일기'라는 새로운 서비스를 추가한 상태인데, 이쪽은 아예 개발을 시작도 못했었다.

한편으로는 이 기간동안 발표와 PPT를 준비해야한다는 문제도 있었다.

그래서 아예 담당을 개발에 집중할 3명, 발표 + PPT에 집중할 3명으로 나누어서 각자 진행하였다.

물론 소통은 중요하기 때문에 주 3회 짧은 회의와, 주말에 다같이 모이는 것을 통해 각자 진행도를 체크하고, 서로 필요한 것을 공유하는 시간을 가졌다.

새로운 담당과 개발 지옥주

나는 개발쪽에 집중하게 되었다.

장소를 불러오는 것은 개발이 얼추 끝난 상태였기 때문에 새롭게 기획한 서비스인 '교환일기' 기능 개발을 맡게 되었다.

서비스 하나를 통째로 개발해야 했는데,
다행인 것은 단순 교환일기는 어느정도 유사한 서비스가 많았다는 것이다.
이들을 참고하면서 비교적 수월하게 개발을 진행할 수 있었다.

그리고 뒷일 생각안하고 예쁜 코드보다는 일단 동작하는 더러운 코드를 만들어서 일단 현재의 개발 효율을 최대한 땡기려고 했다.

결과적으로 합치면 대략 1,500줄 정도의 코드 뭉치들이 완성되었다.
최소한의 양심은 있었기 때문에 위젯이나 api단위의 코드들은 분리를 해서 1,500줄이 모두 하나의 파일에 들어가는 불상사는 발생하지 않았다. (최대 420줄..)

나머지 팀원 분들도 하루 2~3시간만 자는 강행군을 지속하면서 각자 맡은 부분을 완수해 오셨다. 대단!!

그 결과 발표 당일에는 어떻게든 시연이 가능한 수준의 프로토 타입이 완성되었다.

그리고 본선 당일...

대상

진짜 감격스럽게도 대상을 받게 되었다.

수상 이후 뜬 뉴스 기사들을 보니 단순히 배리어 프리가 아니라 비교적 참신했던 아이디어를 들고 온 점, 그리고 진지하게 사업적인 측면을 고려한 점이 높은 평가를 받았던 것 같다.

솔직히 우수상까지 온 것만으로 기적이라 생각하지만
그동안 고생했던 것들도 생각나고... 그냥 너무 기뻤다.

느낀점 (배운점?)

사실 회고는 따로 작성할 예정이고, 이건 그냥 생각난대로 적어본 정리되지 않은 후기이기 때문에 이것도 그냥 생각나는 대로 적어보려고 한다.

• 아이디어 도출에 진짜 시간 많이 써야하고, 망설임 없이 갈아 엎어야 한다.
• 처음 써보는 프로그래밍 언어라도 익숙하지 않거나 함수 이름이 헷갈릴 뿐, 몰라서 못하지는 않는다. 너무 두려워 하지 말자
• 기술을 적용하기 위한 서비스가 되서는 안된다. 기술이 수단임을 잊지 말자
• 다같이 모이는 회의시간이 진짜 꼭 필요한 시간이다. 자주자주 갖자
• 멘토링 적극적으로 활용하자. 생각지도 못했던 점을 잘 짚어주신다.
• 안될 것 같은 것도 시간을 갈아넣으면 어떻게든 되긴 한다...