2022년 8월 19일 부산 BEXCO에서 열린 Junction Asia 2022 Hackathon에 관한 문서입니다.

😃 Day1

전 글에도 기술했듯이 우리 팀은 백엔드 개발자 2명(필자 포함), 프론트엔드 개발자 2명, 디자이너 1명으로 최종 빌딩되었다. 스케줄 표 대로 Opening Ceremony가 이루어졌다.

Track Announcement(트랙 소개)

저녁 8시부터는 드디어 각 Track Announcement가 진행되었는데 트랙은 총 4개로 AWS, MS, Chainapsis, ZEP이라는 기업들이 참여하였다. 각 트랙의 과제는 다음과 같았다.

• MS

  • 
  • MS365 / Azure / Power Platform 중 두 개 이상을 이용해 사용자 협업에 이용할 수 있는 통합된 ‘무언가’를 만들어라.
  • Power Platform은 처음 접한 소프트웨어였는데 당일 소개해주신 내용을 보면 Field Experts들이 제공하는 부분들을 Citizen Developer들이 코딩 없이 업무를 자동화하고 시스템을 구축할 수 있도록 도와주는 툴 이라고 했다. 아마 MS에서는 여러 협업 플랫폼이나 소프트웨어들이 분산되어있어 이를 통합해줄 수 있는 무언가를 원했던 것 같다.

• AWS

  • 
  • AWS를 이용한 Serverless 게임을 만들어라.
  • 게임 개발은 대학 시절에도 꽤 해봤던터라 사실 부담은 없었다. 다만, 아이디어가 얼마나 획기적인지가 관건인 것 같아 망설여졌다. 그럴듯한 아이디어가 생각나지 않았기 때문이다.

• Chainapsis
  • 
  • 자사 SDK인 Cosmos를 이용한 blockchain application을 만들어라.
  • 이전에는 Cosmos를 이용해 Donation 모듈 같은 것들을 만들었다고 했다. 사실 블록체인 기술에 대한 이해가 없어 쉽게 접근하기가 어려웠다. 팀내에서 아이디어는 제일 많이 나오고 또 재미있어 보이기도 했다.

• ZEP
  • 
  • ZEP Script로 ‘아무거나’ 만들기
  • ZEP은 네이버 zepeto 개발사와 게임개발사가 합작하여 만든 메타버스 플랫폼이다. ZEP도 당일 대회장에서 처음 보는 것이었는데 기존에 알고있던 gather town과 비슷하다는 느낌을 받았다. 요즘 많이 쓰이는 비대면 회의 플랫폼으로도 쓰이고, 기타 기업들의 프로모션, 강의와 같은 이벤트에 많이 사용되고 있었다.

트랙 아이디어

10시부터는 트랙 아이디어를 정하기 시작했다. 스케쥴표에 따르면 [MISSION1]이 Team building과 Track Choice라고 되어있다. 참가자들은 11시까지 팀빌딩(팀 이름까지)과 트랙 선택을 마치고 제출해야만 한다.

우리 팀은 각 트랙에 대한 아이디어를 내기 시작했다.

• MS

  • Teams에서 오고가는 메세지와 interaction들을 분석해 어떤 ‘단어’를 가장 많이 썼는지’ 사용자 별로 분석 리포팅을 해주자. (text analyzer가 필요할 것이다.)

• Chainapsis

  • 익명의 설문조사 서비스
  • ESG Index를 기업별로 확인할 수 있는 서비스
  • 익명 Dropbox
  • 블록체인 기반 (학위증명서, 자격증 등) 커리어 관리 서비스

• ZEP

  • rooom에 방문한 사용자들의 분포 및 이용 상황 등을 리포팅 해주는 서비스

• AWS

  • AWS는 특정한 아이디어가 나오기 보다는 두루뭉술하게 이야기가 오갔다. 그래도 계속 선택권 2위에 두었던 것 같다.

1,2차 투표를 통해 아이디어를 정했고, 최종적으로 ZEP 트랙을 선택했다. 사실 ZEP 트랙 아이디어는 내가 낸 거였는데, ZEP이 낸 과제만 보면 자유도가 커보이지만, API 문서만 보면 할 수 있는게 ‘콘텐츠’ 위주의 제작 밖에 없을 것 같았다. 나도 처음엔 그 쪽으로 생각했다. 하지만, Side bar example을 보고 굳이 ‘콘텐츠’로 접근할 필요는 없어보였다. 오히려 여기서 나온 데이터로 무언가를 할 수 있지 않을까? 라는 물음이 들었고, ZEP을 사용하는 기업들이 단순히 event를 여는 것만 아니라 이 이벤트를 통해서 어떤 목적을 달성해야 하는 것일텐데 그럴려면 행사 진행을 통해 나온 데이터로 insight를 얻어야 그것이 가능할 것 같았다. 사용자들의 좌표값만 얻어서 다른 데이터랑 같이 db에 쌓기만 하면 되지 않을까 생각했다. 결과적으로는 구상한대로 구현할 수 없었지만 어쨌든 이 아이디어가 떠올랐다는 건 운이 좋았던게 아닌가 싶다.
Chainapsis의 트랙도 흥미가 있었다. 하지만, 블록체인에 대한 이해도가 낮아 2박 3일이라는 시간 안에 프로토타입까지 만들기에는 러닝커브가 너무 커보였다. 나중에 꼭 한 번 해보고싶다.

우리는 트랙 선택과 팀 이름 정하고 MISSION1을 제출했다.(팀 이름은 Tonight Spark로 정했다.) 일단 최종 경쟁률은 다음과 같았다.

• AWS - 1 : 5
• Chainapsis - 1 : 15
• Microsoft - 1 : 19
• ZEP - 1 : 26

1차 공지된 것은 1 : 28 이었는데 다들 똑같이 생각했는지 ZEP으로 많이 몰렸던 것 같다.

기획 내용

위에서 살짝 얘기하긴 했던대로 우리의 초기 기획 내용(flow)은 다음과 같았지만 생각한대로 구현할 수는 없었다.

1. ZEP 내에 특정 영역까지 임의의 id를 부여한다.
2. 사용자는 admin에 들어와 임의의 id에 대한 영역 이름을 지정한다.
3. ZEP 내의 특정 영역을 방문할 때, api를 통해 방문 정보를 logging한다.
   • 이 때, 이탈률까지 계산해야하므로 visit과 leave의 경우를 모두 쌓는다.
   • addOnLocationTouched 이용

보여주는 건 백단에서 알아서 처리할 수 있지만 데이터를 logging 하는게 가장 문제였기 때문에 위의 내용을 만드는 것이 관건이었다. 이를 위해 우리는 zep 트랙 부스를 왔다갔다거리며 개발자분들을 계속 괴롭혔다… 우리가 작성한 테스트 코드가 이렇게도 되는지 저렇게도 되는지 계속 여쭤봤는데 zep script 상에서 처리가 안 되는 것들만 여쭤봐서 좀 민망했다😅. 그래도 한 시간 넘게 부스에 상주했더니 대충 갈피가 잡혔던 것 같았다. zep script 내에서 해결할 수 없는 문제들은 (가령 지정영역의 이름 or 좌표를 가져온다든가, map의 이름을 가져온다든가) 프론트 쪽에서 긁어오는 형식으로라도 데이터를 적재하기로 했다.

Day1 종료

이렇게 대충 정리를 해놓으니 새벽 3시가 다 되어갔다. 그래도 이 날은 첫 날이라 무리하지 않으려고 했는데 예상보다 늦어져서 체력보충을 위해 얼른 호텔로 가서 잤다.

🤔 Day2

개발 시작

둘째 날부터는 개발을 시작하기로 했다. 우리 팀원들은 어찌 체력이 그렇게 좋은지 아침에 하는 요가 클래스까지 듣고 일찍 자리에 앉아있었다. 나는 9시까지 자다 갔는데..
기술 스택은 미리 파트너 백엔드 개발자 분과 상의해둔터라 바로 세팅부터 시작했다. 우리 팀의 최종 기술 스택은 다음과 같다.

👩🏻‍💻기술 스택

backend

• Spring Boot 2.5.6
• Java 11
• JPA
• Docker
• MariaDB
• AWS ubuntu

frontend

• React
• TypeScript
• recoil
• styled-component
• chart.js
• react-query

design

• Framer
• Figma

Architecture

간단하게 아키텍처를 설명해보자면 client 쪽에서 분석하고자 하는 map의 url을 입력하면, 해당 map의 데이터 수집을 할 수 있는 환경이 세팅이 되고, player가 특정 위치에 오고 갈 때 마다, map hash code를 통해 player의 위치정보, 권한, player ID 값을 logging한다. 리포팅(이탈률, 권한 별 방문 수 및 시각화)은 백 쪽 서버 API들을 통해 뿌려진다. user들이 play하는 환경은 기본적으로 javascript로 구현이 되어있지만, 뒤 쪽에서 C#으로 컴파일 되는 형태로 구성되어있다. (그리고 그림에선 생략했지만, post call에 문제가 있어 중간에 node.js로 get -> post로 변환하는 모듈을 따로 만들었다..ㅠ)

누가 먼저 말하지도 않았는데 파트너 백엔드 분과는 손발 척척 분업이 잘 되어서 일이 좀 수월하게 진행됐다. 다만 좀 답답했던건 장내 네트워크 환경이 무선이고 또, 많은 사람들이 사용하다보니 IaaS 환경에서 작업하기에는 좀 무리가 있었다.(속도면에서) 안 그래도 빠른 시간 안에 작업해야 하는 것이 목표인지라..다음부터는 PaaS로 CI/CD를 빠르게 자동화 할 수 있도록 여러 방법을 좀 익혀놔야겠다고 생각했다.(실제로 파트너사 중에서는 해당 부분을 해커톤 기간 내에 무료로 대여해주기도 했다.)

일단 docker를 사용한 이유는 빠르게 db 세팅을 위한 것도 있지만, 서비스 환경 상 다수의 사용자들이 동시에 접속하는 부분도 있었기 때문에 우리 API 서버가 트래픽이 많아질 때를 대비해 scale-out에 용이하게 하려는 것도 있었다. (아직 kuber를 추가하진 않았지만) ZEP쪽의 개발자분께서도 추후 고려할 사항이라고 언급하셨다.

명세 작성 및 개발

환경세팅이 마무리 되고 나서는 API 서버 개발을 시작했다. 이 부분은 어려운 부분이 딱히 없었다.

그래서 개발하면서 간간히 commit 된 코드 재배포해주고 프론트 쪽하고 주고받을 형식, 방향 수정에 대한 부분 의논, 반영하고 이 작업을 계속 반복했다.
배포가 완료된 API에 대한 명세에는 Notion에 바로바로 업데이트(✅)해서 작업 상태를 공유하도록 했다.

오후 10시 쯤 되어서야 page2의 API 작업에 들어갔는데 이 때쯤 되니 머리가 안 돌아가기 시작했다. 오전 10시부터 화장실 간 것 말고는 점심, 저녁도 대충 떼우고 작업했기 때문에 (근데 잘 먹었음) 약간 뇌가 부담스러워하는 것 같았다. 그래도 어떻게 해.. 해야지

Day2 종료

[MISSION2]는 다음과 같은 내용을 정리해서 11시 50분까지 제출하는 것이었다. 아래는 우리가 제출한 Script이다.

Our service name is ZEP.SIGHT.
We target our product to support the map administrator of ZEP by providing meaningful insights with organized charts.
Through our service, ZEP administrators can see the object-related data, classified by participants, time, and areas.
For instance, they can monitor the number of visitors in a specific area over a certain amount of time.
Our product can track these indexes and provide organized and integrated visualization charts.
Team TonightSpark strongly believes that our product can collect meaningful data from a massive ZEP community, and it will bring out the significant business value of the community.

오전 12시가 되고 Day2의 일정이 종료되었다. 그래도 회장의 사람들은 떠날 생각이 없어보였고 거의 모든 팀이(우리 팀도 마찬가지로) 밤을 새며 작업하는 진풍경을 볼 수 있었다.

😫Day3

진행 상황 및 버그 수정

1차 시도, native query로 잘 짜보려 했으나 백엔드 파트너가 했던 map 형식에 우겨넣는 방식이 일단 빨라보여 노선을 변경했다.(리팩토링 할거니까..해커톤이니까.. 일단 작업 속도가 중요하니까..)
2차 시도, 그래서 위 방법대로 잘 우겨넣어보았다. 이 작업이 끝난게 오전 7시였는데 내가 막혔던거 처리하고 다른 백엔드 분이 마무리 작업을 해주셨다.
나는 이 때 부터 버그 작업과 배포에 신경을 쏟기 시작했다.

사실 대회장이 오전 6시~7시에는 방역작업으로 쓸 수 없어서 호텔로 돌아가야했는데, 팀원들끼리 이대로 잘 수는 없다.. 해서 호텔방 하나에 모여서 침대에서 위 작업을 진행했다. 정말 색다른 경험이었다. 대학 때도 이렇게 열정적으로 작업을 했던 적이 있던가 하는 생각을 문득 했던 것 같다.

우리는 대충 배포작업까지 마치고 체크아웃을 하고 다시 회장으로 돌아왔다.

자료 제출 준비

우리는 슬슬 [MISSION3]에 맞춰 자료를 준비하기 시작했다. 대충 정리가 되었다고 생각하니 좀 마음이 놓였다. 자료는 기본적으로 source 코드와 발표 자료였다. demo 영상도 있다면 함께 제출할 수 있는데 마감 시간에 맞춰 upload 하게 되면 트래픽이 몰리니 다음 해에 참가할 의사가 있다면 미리미리 작업해두는 것을 추천한다. 우리 팀은 demo 영상 작업을 마감 시간에 맞춰 아슬아슬하게 끝낸터라 업로드를 하지 못 했다.. 아래는 바로 그 demo 영상이다.

Demo Expo

제출을 하고나서는 바로 Demo Expo가 진행되는데, 각 트랙의 개발자분들이 오셔서 우리의 프레젠테이션을 듣고 평가한다. 기본적으로 영어로 진행되지만, 추가 질문에 대한 답변은 한국어로 해도 된다. (덕분에 나도 Q&A에는 그럭저럭 대응할 수 있었다.)
ZEP 개발자분들은 우리 팀으로 가장 먼저 오셨다. 헉, 왜 우리 팀으로 먼저 오셨지?! 하는 생각이 들 찰나 바로 발표가 시작되었다. 발표는 프론트엔드 개발자 및 팀 리더를 담당하신 분이 맡아주셨다. 그 옆에서는 개발한 demo를 함께 play했다.
추가 질문까지 다 받은 후의 리액션이 너무 좋았고 칭찬도 많이 받아서, 사실 ZEP 트랙을 선택한 모든 팀에게 이렇게 호의적인 반응인건가. 라는 생각을 했었다.

Track Winner Announcement

그런데 아니었다. 2박 3일동안 고생했으니 격려 차원에서 그런 것이 아니라 진짜로 맘에 드셨던 모양이다. 프레젠테이션까지 다 마친 우리 팀은 대회장 뒤에 비치된 빈백에서 그로기 상태로 앉아있었는데 (사실 살짝 잠들었다.) 팀의 디자이너였던 성인이가 불러서 비몽사몽 상태로 다시 자리로 돌아왔다. 가보니 ZEP CEO님이 다시 오셔서 우리 작업물을 보여달라고 요청하셨다. 나중에 말하길 팀원들은 이 때 우리가 순위권에 들었다는 것을 확신했다고 했다.

추가 시연까지 마치고 팀원들끼리 얘기를 나누고 있었는데, SHIFT(정션 진행팀) 관계자분이 우리 팀을 확인 하시더니 나를 따로 부르셨다.

’Track 1등 하셔서 지금 발표를 준비해야되거든요. 혹시 demo 자료 준비해두신 거 있나요?’

이 말을 듣자마자 나는 침착함을 잃지 않으려 애썼다. 나는 해당 소식을 우리 팀에게 바로 전했고, 내 말을 듣자마자 팀원들은 일사불란하게 움직였다.
사실 기쁜 것도 기뻤지만, 영어 speech를 준비해야 한다는 생각에 손이 발발 떨리기 시작했다. 팀 리더 분은 바로 script 짜기에 돌입했고 우리는 각각 작업한 기술적인 부분을 한국어로 써서 전달했다. (팀 리더에게 발표 부분을 많이 의지한 것 같아 죄송했다.)

한 가지 아쉬운 점은 우리가 순위에 들 것을 예상하지 못한 채 스크린 샷 하나 없이 발표 자료를 작성했다는 것이다. 때문에, 다른 팀들이 우리 팀의 수상에 의문을 가질까봐 걱정됐다. 그래도 Peer Review 후반부 쯤 Discord에 우리 Demo와 영상을 업로드 할 수 있었고, 추가 설명이 필요하면 우리 팀으로 오라고 메세지를 남기는 식으로 해결했다.

Speech

피칭은 Track별 1위만 진행한다. (총 4팀) 순서상 ZEP 트랙이 항상 마지막이었기 때문에 우리 팀이 가장 마지막으로 발표를 진행했다. 앞의 3트랙들의 발표도 제대로 듣고 싶었는데 긴장돼서 잘 못봤다. 다들 영어도 수준급으로 잘 하셨다.

우리 팀 리더 분도 준비한대로 발표를 잘 진행하셨고, 추가 Q&A까지 마무리 한채 내려왔다. (이 때, 영어 공부에 대한 필요성을 정말 절실히 느꼈던 거 같다.)

🥇 시상

시상은 Final Winner 발표 후에 이루어졌다. 우리 팀이 Final Winner가 되지 못한 것은 아쉽지만, TOP4에 들 수 있어서 행복했고 정말 좋은 경험이었다고 생각한다.

📔소감

About 작업

• 

• 일단 처음 보는 사람들임에도 불구하고 팀원들과 합이 너무 잘 맞았다. 첫째 날 팀 리더 분이 해커톤 기간에 말을 놓자고 제안하셨던게 정말 많은 도움이 되었던 것 같다. 다들 아 하면 어 하고 어 하면 아 하는 눈치와 작업 속도 덕분에 협업 부분에서 물 흐르듯이 진행될 수 있었다.
• 짧은 시간 안에 결과물을 내야하기 때문에 코드 효율성에 신경쓰지 못한게 조금 아쉽다. 리팩토링을 진행 할 예정이다.
• 실시간 사용자가 증가할 경우 트래픽을 어떻게 감당해야하는지 서버 쪽 설계 확장을 생각해 볼 필요가 있을 것 같다. 이 쪽은 경험이 없어 많은 분들에게 자문해보면 좋을 것 같다.

개인적 소감

• 

• 내가 이렇게 극한의 집중력을 낼 수 있다는 사실에 놀랐다. 사실 최근 개발 공부에 약간 매너리즘이 와서 새로운 전환점이 필요했는데, 확신과 열정을 재정립할 수 있었던 좋은 기회였던 것 같다.
• 영어 공부에 대한 욕구가 강해졌다. 앞으로 2년은 영어 스피치를 할 수 있을 정도로 목표를 잡고 공부 계획을 세워볼 예정이다.
• 처음 참가한 해커톤에서 (그것도 내가 낸 아이디어로!!) 좋은 결과를 낼 수 있어서 정말 뜻깊고 감사하다. 운도 좋았지만, 지금까지 내가 열심히 해온 것이 빛을 발한 순간인 것 같다.

Source code

front
back