NotiNote의 2022 Solution Challenge Global Top 50 진출기 - (1)

이 글은 (1)과 (2)로 나누어집니다.

🤨 잠깐, Solution Challenge가 무엇인가요?

2022 Solution Challenge  |  Google Developers

솔루션 챌린지는 GDSC 소속 학생 한 명을 포함한 대학생 팀이 구글의 기술이나 플랫폼을 하나 이상 사용하여 지역 사회의 문제를 해결하는 솔루션을 만드는 대회다. GDSC의 가장 큰 연례 행사이며, 많은 GDSC에서 솔루션 챌린지 출품을 목표로 해커톤이나 아이디어톤, 디자인 데이 등의 다양한 행사를 기획한다. 올해의 주제는 작년과 동일하게 UN이 지정한 17가지 지속가능발전목표(SDGs) 중 하나 이상을 해결하는 것이었다.

2020년 가을부터 2021년 여름까지 활동했었던 GDSC Sookmyung 1기에서는 2팀이 진출하여 Top 50에 진출한 한국 팀 3팀 중 당당히 두 자리를 차지했으며, 21-22 GDSC Sookmyung 2기는 4팀이나 진출했다. 전세계에 GDSC 커뮤니티가 1200개가 넘고, 한국에서만 41개의 솔루션이 나왔다는 것을 생각해보면 어마어마한 성과다.

이번 포스트에서는 내가 소속되어 있는 NotiNote(팀명은 Answer인데 구글이 팀명 대신 프로젝트명으로 부르길래 그냥 앞으로 NotiNote팀이라고 적겠다.) 팀의 개발기를 정리해 보고자 한다. 어떻게 아이디어를 냈고, 어떻게 협업을 했으며, 우리가 생각하는 우리가 Top 50에 진출할 수 있었던 이유에 대해 한 번 적어보겠다.

 

주제: UN’s Sustainable Developer Goals (지속가능발전목표)

UN의 17가지 지속가능발전목표는 빈곤을 종식시키고 번영을 보장하며 지구를 보호하기 위해 2030년까지 달성하기로 지정한 목표다. 평등, 기아, 기후, 환경 등등 다양한 카테고리의 목표들이 있는데, 이 중 본인이 관심있는 목표를 하나 이상 선택하여 그것에 대한 솔루션을 만들어야 한다.

조건: 하나 이상의 Google 제품 혹은 플랫폼 사용

Android, Firebase, TensorFlow, Google Cloud, Flutter 등등 즐겨 사용하는 Google의 기술이나 플랫폼을 사용하여 솔루션을 구축해야 합니다. 솔루션 챌린지에 나가는 팀에게는 구글에서 GCP credit과 Google Domain을 제공해 준다. 당장 내가 사용할 수 있는 구글 기술이 없다면 매년 솔루션 챌린지마다 구글에서 구글 기술 학습을 위해 무료 강의들을 제공하고 있으니 멤버들과 함께 스터디하는 시간을 갖고 개발해도 좋다.

 

❄️ 솔챌을 준비하는 GDSC Sookmyung의 자세

GDSC Sookmyung에서는 자율 팀빌딩 이후 15일부터 23일까지 팀 미션을 수행했다. 이 기간동안 팀원들과 그라운드 룰을 정하고, 프로젝트 주제에 대해 이야기해보며 디자인 스프린트를 진행하도록 했다. 디자인 스프린트가 무엇인지 궁금하다면 이 글(구글 벤처스의 디자인 스프린트 방법론)을 읽어보면 좋을 듯하다.

팀 미션 일정

디자인 스프린트는 Phase 1: Understand(이해하기), Phase 2: Define(정의하기), Phase 3: Sketch(스케치하기), Phase 4: Decide(결정기), Phase 5: Prototype(프로토타입), Phase 6: Validate(검증)의 6단계로 나뉜다(5단계로 나누는 경우도 있다). 우리는 Mission 2에서 5단계인 프로토타입 제작까지 마치고 마지막 6단계인 검증은 모두 모여 정기 세션 시간에 진행하였다. 검증은 8개의 팀이 돌아가면서 프로젝트에 대해 소개하고 프로토타입을 공개하면 다른 팀에 소속된 멤버들이 이 팀의 주제의 장점, 단점을 적어보는 식으로 진행했다.

우리 팀 피드백

디자인 스프린트 구성과 피드백을 위한 질문은 작년 1기 활동에서 사용했던 것을 참고했다. '반대로, 이 주제를 선택했을 때 생길 수 있는 문제점이나 단점은 어떤 것이 있을까요?' 라는 질문에 대한 답변들이 이 프로젝트로 우리가 해결하고픈 문제를 해결할 수 있는지, 다른 더 좋은 방법은 없는지, 처음부터 해결하고자 하는 문제가 명확하지 못했던 것은 아닌지 고민하게 만들어서, 대부분의 팀이 피드백 데이를 기점으로 더 나은 주제를 가져왔다.

이 당시에는 우리 팀의 주제가 난독증 치료 애플리케이션이었는데, 피드백으로 받은 질문들에 대해 고민하면서 주제를 완전히 바꾸게 되었다. 다문화가정 학부모를 위한 가정통신문 관리 서비스로..

---

00. 시작

사실 작년에 희언니, 은지언니, 지연언니와 함께 솔루션 챌린지를 나가려고 했었다. 그러다가 이런저런 일로 갑자기 바빠져 2021 GDSC KR 겨울 해커톤만 같이 나가고 2021 솔루션 챌린지에는 나 없이 3명이서 나갔다. 그래서 올해에는 꼭 언니들과 같은 팀으로 솔루션 챌린지에 나가고 싶었고, 코어 멤버 중 내가 점찍어두었던 현애를 데려와 서 나, 희언니, 지연언니, 현애 이렇게 4인 팀이 구성되었다. 희언니는 GDSC 2기 활동을 하지 않아서 솔챌에 같이 참여해줄지 걱정했는데, 물어보자마자 흔쾌히 좋다고 해줬다. ㅎㅎ

오은영 박사님이 반겨주는 우리 노션

첫 회의에서 그라운드 룰과 협업 규칙을 정했다. 작년 첫 DSC 플젝 후 내가 참여하는 프로젝트의 그라운드 룰에 빠지지 않는 게 있는데, 바로 매주 회의 시작 전 10분간 프로젝트와 전혀 상관없는 사적인 근황 이야기를 하는 것이다. 매일 회의가 기다려지는 효과가 있으며.. 팀원들끼리 빠르게 친해질 수 있다. 특히 프로젝트를 통해서 처음 만난 사이라면 이 규칙이 더 효과가 좋다. 서로 조금씩 가까워지면서 채팅도 활발해지고 팀 분위기도 좋아졌다.

버전 관리는 깃헙, 디자인 툴은 피그마를, 소통은 주로 디스코드를 통해서 했다. 브랜치 전략은 git-flow 방식을 채택해서 기능별로 브랜치를 만들고 해당 브랜치에서 작업, 업데이트가 있을 때마다 PR을 보내고 같은 스택을 담당하는 팀원이 리뷰 후 머지하는 식으로 진행했다. 구현해야 하는 기능들은 issue로 관리하고, 커밋과 PR에서 구현한 기능의 issue 번호를 붙여 어떤 기능을 구현했는지 표시했다. 지금 생각해보면 굳이 기능별 브랜치도 파고 이슈 번호까지 붙여야 했었나 싶다. 프로젝트 후반으로 갈수록 이슈 번호는 생략하고 커밋하는 경우가 늘어났었는데, 다음 프로젝트부터는 둘 중 하나만 해야겠다. 기능을 이슈로 관리하는 건 github-flow에 더 잘 맞는 것 같다.

 

02. 기획 기획 그리고 기획

많이 미안해하는 번역 API

우리 팀의 첫 아이디어는 독해 장애 학생의 학습 도움 서비스였다. 저번 가을-겨울동안 BERT 모델 스터디를 진행했었기도 했고 당시 나는 AI대학원에 갈 생각이었기 때문에 NLP 기술을 꼭 쓰고 싶어서 그것에 초점을 맞춰 생각하다가 나온 아이디어였다. 난독증 학생들의 치료 방법에 대해서 많이 찾아보고, 인공지능으로 구현할 수 있을만한 치료 방법 3가지 정도를 골라서 구현하려고 했으나... 1)우리의 목적에 맞는 한글 데이터셋이 턱없이 부족했으며 2)데이터를 온라인에서 크롤링하기도 애매하였고 3)무엇보다 난독증 학생들은 아무리 AI가 도와준다고 하더라도 문제나 글의 이해를 도와줄 선생님이나 부모의 도움이 필요하기 때문에 우리 서비스의 임팩트가 작아질 것 같다는 문제가 있었다.

주제를 바꿔야겠다는 이야기가 나온 후 2차 아이데이션을 진행했고, 이 때 좋은 아이디어들이 꽤 나왔으나 여기에 적지는 않겠다. 거의 한 달 가까이 주제 고민을 하다 결국 프로젝트 제출 마감까지 한달 반 정도밖에 남지 않은 시점, 지금의 가정통신문 번역 및 일정 관리 서비스로 확정되었다. (쌰라웃 투 마이 맘) 아직까지도 초등학교~고등학교 까지의 학부모-학교 간 소통은 대부분 가정통신문을 통해 이루어지며, 가정통신문에서 사용하는 단어들이나 어투가 일상에서 쉽게 접할 수 없는 것들이고, 지역 교육청에서 다문화가정을 위한 가정통신문 번역 사업을 진행하고 있긴 하나 번역 소요시간이 최대 2일이나 걸리며 상시로 운영되지 않는다. 문제가 확실하고 이것을 해결할만한 솔루션을 우리가 만들 수 있다고 판단하여 이 주제로 진행하게 되었다.

 

03. 개발

위 구조는 Top 50 발표 이후 추가 개발이 이루어진 다음 만든 것인데, 첫 제출 때에는 여기에 ML 모델이 없고 FastAPI 내부에서 날짜와 이벤트를 추출하는 구조였다.

 

왜 이런 기술을 사용했는가?

플랫폼을 모바일로 결정한 후 리액트 네이티브와 플러터 사이에서 꽤 많은 고민을 했으나 결론적으로 리액트 네이티브를 사용하게 되었다. 솔루션 챌린지는 구글에서 하는 대회이니 구글 기술을 하나라도 더 사용하는 것이 왠지 좋을 것 같았지만, 이미 기획하는 데 시간을 많이 써버려서 새로운 기술을 익힐 시간이 없었다. 리액트 네이티브도 사용해 본 적이 없는 건 마찬가지였지만 우리는 리액트를 쓸 줄 알았기 때문에 금방 실전에 써먹을 수 있을 것 같았고, 실제로 한 이틀만에 금방 적용하여 잘 사용했다.

날짜와 이벤트 추출을 담당할 서버는 FastAPI를 골랐다. 개발 초기에는 괜찮은 사전학습된 모델을 찾아서 추가학습시켜 사용하려고 했기 때문에 Django, Flask, FastAPI 등의 파이썬 기반 서버 프레임워크가 필요했고, 그 중에 내가 사용해본 경험이 있는 FastAPI를 선택했다. 이 서버가 할 일은 가정통신문 텍스트를 받아 이벤트와 날짜를 추출하여 매칭하고 리턴하는 일밖에 없었기 때문에 복잡한 아키텍처를 사용하지 않아도 된다는 것도 선택에 영향을 주었다.

WAS 서버는 백엔드 팀원들이 가장 자신있어 하는 스프링으로 결정했고, 클라우드 같은 경우 별다른 고민 없이 GCP를 사용했다. 구글 기술을 하나 이상 사용해야 하는데 여태까지 사용한 구글 기술이 별로 없기 때문이었다. 게다가 우리에게 필요한 OCR, Translate, Calendar API까지 모두 제공하니 안 쓸 이유가 없었다.

 

어떤 난관이 있었나?

위에서 언급했다시피 개발 초기에는 괜찮은 사전학습된 모델(아마 BERT)을 찾아서 추가로 학습시켜 사용하려고 했었다. 하지만 학습에 사용할 괜찮은 데이터셋을 찾지 못했고, 가정통신문 사진을 왕창 다운받아 글자를 추출하고 라벨링을 하기에는 시간이 부족하여 모델을 학습시키지 못했다. 우리 팀은 ML 파트를 담당하는 팀원이 따로 있지 않고 프론트엔드 개발자 2명이 ML도 같이 맡고 있었는데 예상외로 프론트엔드 개발만으로도 일정이 빡셌기 때문이다(사실 예상하고 있었을지도..). 어찌됐든 이벤트 일정 추출은 우리 서비스의 핵심 기능이기에 이 기능을 포기할 수는 없었다. 그래서 인공지능대신 인간능지로 코딩하여 이벤트 추출 기능을 구현하였다. 어떻게 구현했냐면..

 

어떻게 해결했는가?

출처: 화암고등학교(http://hwaam.hs.kr/_mdl/popup/hwaam-h/2195)

FastAPI에서는 OCR로 읽은 텍스트를 받아서 이벤트 일정 정보를 추출해야 한다. 이벤트 추출은 텍스트 내에서 수작업으로 작성한 이벤트 딕셔너리에 있는 이벤트를 모두 추출하고, FastAPI에서는 한국어 문서는 주로 주어 다음 목적어가 나온다는 것을 활용해서 텍스트에서 이벤트가 등장했을 때 이벤트 이후에 나오는 날짜 중 가장 거리가 가까운 날짜를 선택하는 방법으로 이벤트와 날짜를 매칭했다.

1. 이벤트 딕셔너리에 있는 이벤트 중 본문에 등장하는 이벤트를 모두 추출하여 시작 인덱스를 키로 하여 딕셔너리에 저장한다.
2. 정규식을 사용해 본문에서 날짜를 모두 추출해 시작 인덱스를 키로 하여 딕셔너리에 저장한다.
3. 추출된 날짜 딕셔너리를 순회하며 날짜 텍스트와 가장 가까우며 인덱스상 날짜 텍스트의 등장 위치보다 왼쪽에 등장하는 이벤트를 선택하여 날짜와 매칭한 후 응답 목록에 추가한다.

이벤트를 기준으로 가장 가까우면서도 이벤트의 오른편에 등장하는 날짜와 매칭하지 않고, 날짜를 기준으로 가장 가까우면서도 날짜의 왼편에 등장하는 방식을 사용한 이유는 행사명같은 경우 한 가정통신문 내에서 여러번 등장하는 경우가 많은데 날짜는 한번만 등장하기 때문이다.

GitHub - dsc-sookmyung/2022-Answer-SolutionChallenge: [Top 50] 2022 Solution Challenge Repository for Team Answer

하지만 이 코드의 문제점은 정규식과 맞지 않는 형태의 날짜 텍스트는 인식하지 못하고, 같은 날 진행하는 이벤트가 2개 이상 있다면 둘 중 나중에 등장한 이벤트만 날짜와 매칭되어 등록한다. 또한 간혹 날짜가 먼저 나오고 행사 이름이 나중에 나오는 경우 아예 이벤트 정보를 추출하지 못한다. 이 문제는 세미파이널 진출 이후 QA 모델을 사용하여 해결하였다. 이 내용은 (2)편에서 계속...

 

04. 데모 준비

솔루션 챌린지 데모 영상은 2분 이내로 제작해야 하며, 프로젝트를 이해하기 위한 백그라운드 지식은 영상에서 최대한 생략하는 대신 폼에서 자세하게 설명을 해야 하고, 서비스의 실행 영상을 최대한 많이 보여줘야 한다. 영상을 어떻게 제작해야 할까 고민이 많이 됐었는데, 우리 팀은 피그마로 화면을 만들고 이걸 파워포인트로 옮겨 자연스럽게 실행한 것을 녹화해서 영상을 만들었다. 유튜브에서 다른 팀들의 데모 영상을 보니 역시 한국팀들이 영상 퀄리티가 아주 좋았다. 역시 팀플과 과제로 다져진 K-대학생 !

데모 영상은 아래에서 확인할 수 있다.

 

05. Submit!

프로젝트를 마무리하고 폼과 데모 영상을 제작하는 데에만 쌩으로 이틀을 쏟아부은 후 드디어 submission form을 제출하고 2개월간의 대장정의 막을 내렸다. 중간에 제출 마감 기한이 연장되었지만 이미 온 힘을 다 쏟아부은 우리 팀은 그냥.. 아무것도 하지 않았다. 그렇게 제출 결과가 나오기까지 한 달을 묵묵히 기다렸다.

 

06. Top 50 발표

결론적으로, 우리 팀은 Global Top 50 안에 들어 세미파이널을 준비하게 되었다.

지원한 팀이 너무 많아 엔지니어들과 스태프가 리뷰하는 데 시간이 오래 걸려 결과 발표가 미뤄지고 있다는 내용의 메일만 2개를 받고 반포기 상태가 되었는데, 5월 11일 오전 10시 40분쯤 코어 멤버 한 명이 솔루션 챌린지 결과를 봤냐며 나에게 카톡을 보냈다. 무슨 일이냐고 물어봐도 그냥 대박이라는 말밖에 안해줘서 뭔 일인가 싶었는데, GDSC Sookmyung에서 4팀이나 진출하게 된 것이다. 놀랍게도 그 중에는 우리 팀도 있었다. 이것이 정말 말도 안되는 일인 것이, 전 세계에는 1200개가 넘는 GDSC 클럽이 있으며 올 해에는 GDSC가 생긴 지 3년밖에 되지 않은 한국에서만 42개의 솔루션을 제출했다. 작년 Top 50 진출팀 중 한국팀이 3팀이었는데, 올해에는 한국에서 8팀이 진출하였고 그 중 절반이 GDSC Sookmyung에서 나온 것이다. 아니 그냥 각설하고 구글이 우리 솔루션이 마음에 든다는데 광대가 씰룩씰룩할 수밖에... 앞으로 받게 될 구글 굿즈들, Top 50 뱃지, 구글러와의 멘토링 등등 모든 것이 기대되고 설레었다.

곧 작성될 (2)에서는 여기서 적지 못했던 세미파이널 진출 이후 구글러와의 멘토링(너무 유익했음)과 개선 방향, 개선 결과와 전체적인 후기에 대해서 적어보려 한다. (2)까지 많관부