JUNCTION ASIA 최종 우승 후기

우리가 우승할 줄 몰랐다. 새벽까지 팀원과 논쟁하고 주제를 바꾸기 전까지는.

JUNCTION ASIA 최종 우승 후기

작년 말, 우리 팀(Bitter Sweet!)은 JUNCTION ASIA 2022에서 우승하며 유럽 최대 해커톤인 Junction 2022에 참가할 자격을 얻었다. 이런 기회를 주었던 해커톤, JUNCTION ASIA 2022 이야기를 풀어보려고 한다.

해커톤 소개

JUNCTION ASIA 2022 포스터

JUNCTION ASIA 2022(이하 정션 아시아)는 4개 주제 중 하나를 골라 48시간동안 서비스를 만드는 해커톤이다. 개발자, 디자이너, 기획자 등 300명 이상이 참여해 최대 5명이 한 팀을 이루어 경쟁한다.

SHIFT팀이 운영하며, 부산광역시를 포함해 AWS, 인생네컷, Microsoft, ZEP 등 다양한 기업이 스폰서로 참여한다.

참가자가 온라인으로 참가 신청서를 작성하면, 운영진이 심사를 통해 참가자를 선발한다. 본 행사는 8월 19일부터 21일까지 3일간 부산 벡스코에서 오프라인으로 진행한다.

💡
Junction Asia 2023 신청 기간은 2023년 7월 3일부터 21일까지이다.

우연한 참가, 그리고 팀 빌딩

어느 날 사내 메신저에 알림이 하나 울린다.

Special thanks to @harrydrippin

해커톤이라니. 이런 재밌는 행사에 내가 빠질 수 없었다. 나는 이 메세지를 보는 즉시 참여 의사를 밝혔다. 문제는 참여를 희망하는 사람은 많은데, 특정 직군(특히 디자이너, 프론트엔드)은 사람이 매우 적었다는 점이다.

적극적으로 사전 팀빌딩을 해야 하는 타이밍이었지만, 나는 굼뜨게 움직였다. 그리고 곧 부지런한 팀원이 모여 첫 번째 팀이 결성됐다(참고로 이 팀은 다른 트랙에서 1위를 했다). 나는 여전히 팀이 없었다.

한편, 빠른 99년생(소문에 의하면 본인은 18학번이라고 종종 으름장을 놓는다고 한다) 한 명이 바삐 동갑내기 팀원에게 DM을 보낸다. 아마 프론트엔드 직군이 부족하다는걸 일찍이 눈치챈 듯 하다.

그렇게 전설이 된 "너, 내 동료가 돼라".

이제 준성이형(ML 엔지니어), 동훈이형(프론트엔드 엔지니어)은 팀이 되었다.

이제서야 팀을 찾아야겠다고 생각한 나는 준성이형에게 찾아가 팀 제안을 했고, 그렇게 3번째 멤버가 되었다.

문제가 하나 생겼다. 디자이너가 없었다. 회사 내에는 디자이너가 3명 있었는데, 모두 팀이 있거나 참여가 어렵다고 했다. 회사 밖에서 사람을 찾아야 했다. 우리는 각자 디자이너 지인에게 연락을 하기 시작했다.

다행히도 얼마 지나지 않아 우리는 디자이너를 찾을 수 있었다. 그렇게 네 번째 멤버인 찬수형이 참여하게 되었다. 동훈이형의 이전 회사 동료였다. 정션 아시아의 정원은 5명이었지만, 우리는 근거 없는 자신감으로 4명이서 해커톤에 참여하기로 한다.

자, 떠나자. 부산으로

그리고 해커톤 당일, 예매한 KTX를 타고 부산으로 떠났다.

설레는 마음으로 기차에 오른다.

우린 부산에 해커톤 시작 시간보다 일찍 도착했고, 행사장이었던 벡스코에 짐을 놓고 부산을 즐기기로 한다. 그렇게 찾아간 곳은 바로 송정 해수욕장.

바다를 본 뒤, 즉석에서 해수욕장 근처 횟집을 찾아 이동했다. 계획형(J)인 내가 즉흥형(P)인 나머지 3명과 싸우다 포기했기 때문에 계획같은 건 없었다.

여기서 중요한 사건이 하나 발생한다. 이다.

고생 끝에 낙이 온다는 말이 있다. 이 철학을 술에 녹여 탄생한게 바로 '고진감래주'이다. 맥주잔 속에 콜라와 소주가 담긴 소주잔을 넣고 한 번에 들이키는 것이다. 고진감래주라는 이름답게 소주로 고생하다 보면 콜라의 단맛이 혀를 달래준다.

고진감래, 고생 끝에 낙이 온다.

뜬금없이 술 얘기를 하는 이유는, 이 "고진감래"가 바로 우리의 팀 이름이 되었기 때문이다. 이후 핀란드에서 참여한 Junction 2022에서도 이를 직역한 "Bitter Sweet!"을 팀 이름으로 사용했다.

Let's hack!

그렇게 취기가 채 가시지 않은 채 우리 팀은 다시 벡스코로 이동했다. 이제는 진짜 해커톤을 할 시간이다. 우리는 물품 보관함에서 가방을 꺼내 들었고, 곧바로 행사장 입구로 향했다.

아까는 한산했던 행사장 입구가 해커톤 참여로 설레 하는 개발자, 디자이너, 기획자 등으로 붐볐다. COVID-19가 아직 종식되지 않은 시기라서 입장하기 위해서 관련 서류를 제출해야 했고, 모두 이 종이를 들고 있었다.

특이하게 입장은 온라인에서 사전 등록을 하고 받은 참가 확인증을 사용했다. 아래 사진에 나와있는 QR 코드로 인증하고 네임 태그와 함께 웰컴 키트를 받았다. (해커톤에 너무 집중한 나머지 웰컴 키트 사진은 깜빡했다.)‌

정션 아시아 행사장은 생각보다 너무 거대했다.

입장 줄부터 사람이 붐볐기에 규모가 꽤 클거라고 예상은 했지만, 자리에 앉아 행사장을 봤을 때 나는 그 압도적인 규모에 저절로 감탄사를 내뱉었다. 내가 봤던 모든 해커톤 중에서 가장 컸다. 300명 이상이 참가한 해커톤이란 걸 생각해보면 우리나라에서 손에 꼽히는 규모가 아니었을까 싶다.

내가 생각했던 것보다 더 규모가 컸던

이 때쯤에도 나는 우리 팀이 우승할 거라고는 예상하지 못했다. 단지 그 큰 규모에 압도되어 있었다.

우리 어떤 거 만들지?

4개의 기업에서 각각 주제를 던졌다. 이번 정션 아시아는 이 주제(트랙) 중 하나를 골라 해결하는 해커톤이다. 전체 해커톤 행사는 48시간이었지만, 운영 시간을 제외하고 38시간 남짓한 시간이 우리에게 주어졌다. 심지어 마감 전까지 시연 동영상과 PPT를 동시에 제출해야 했다. 각 기업과 제시한 주제는 다음과 같았다.

  • Microsoft - Build Collaborative Apps for More Business Values and Productivities
  • ZEP - Make ANYTHING with ZEP Script!
  • AWS GameTech - 'Zero-operation' game on AWS
  • Chainapsis - Building your first crypto product

정션 아시아는 각 기업에서 트랙 1, 2, 3위(Track Winner)를 선정하고, 참가자의 상호 평가를 통해 최종 우승 팀(Final Winner)을 선정한다.

우리는 전략적으로 Track Winner를 노리며 ZEP 트랙을 선택한다. Final Winner는 ZEP이라는 플랫폼 내에서는 참가자 모두를 공감시킬 수 있는 제품을 내는게 불가능하다고 판단했기 때문에 일찍이 포기했다.

(물론, 우리는 최종적으로 AWS GameTech 트랙으로 노선을 틀었고, Track Winner와 Final Winner 모두를 수상하는 쾌거를 이뤘다.)

메타바-스?

https://zep.us

처음으로 선정했던 주제는 ZEP이었다. 사실 처음에는 어느 주제도 와닿지 않았다. 우리 팀원은 웹 프론트엔드 - 백엔드 - ML 엔지니어 - 디자이너로 이루어져 있다. 능력을 가장 잘 발휘할 수 있는 웹 개발 스택을 맞추기는 어디든 어려웠다.

특히 Microsoft는 사용하지도 않을 업무 도구를 다룬다는 점에서 재미가 없어보였고, AWS는 게임을 한 번도 만들어본 적이 없어 도전조차 못했고, Chainapsis는 블록체인이라는 기술을 만져본 적도, 이해하고 있지도 않기 때문에 선택하기 어려웠다.

ZEP은 그렇게 선정됐다. ZEP은 웹 메타버스 서비스로, 한국판 게더타운이라고 생각하면 된다. 스페이스를 만들고, 꾸미고, 서로 링크를 통해 가상 공간에 접속해 컨텐츠를 즐긴다. 이 때 플러그인 시스템을 통해 다양한 기능, 맵 등을 추가할 수 있다.

우리는 ZEP 스페이스에서 관리자가 편하게 사용자를 관리할 수 있도록 제재 시스템을 만들고자 했다.

제재 시스템 기획을 논의하던 회의록

마인크래프트에서 플러그인만 3년 이상 만들며 쌓아온 나의 노하우를 사용하고자 했다.

하지만 당시 ZEP의 플러그인 시스템은 너무나도 미약하고, 버그도 자주 발생했다. 소스 코드를 '압축'해서 사이트에 업로드해야 했을 뿐만 아니라, 채팅을 중간에 가로채서 욕설 등을 탐지해 채팅을 취소할 수도 없었다.

그럼에도 우리는 열심히 답을 찾아가기 위해 노력했다. 당시 ZEP 부스가 있었는데, 직접 찾아가 문서에 안 적혀있는 내용을 문의하거나(당시 ZEP 트랙은 참가자가 아니라 ZEP 개발자들의 해커톤이라고도 불렸다), 다른 ZEP 스페이스를 돌아다니면서 돌파구를 찾으려고 노력했다.

이거 아니잖아!

첩첩산중으로 빠지는 것 같았다. 약 9시쯤에 시작한 개발은 새벽 1시가 되어서까지 그럴싸한 결과물이 나오지 않았다. 우리는 이러한 현실을 보고 모두 지쳐있었다. 우리는 결국 자리를 정리하고 정션 아시아에서 제공해준 호텔(무려 부산 센텀 프리미어 호텔을 2인 1실로 제공해줬다)로 돌아가 다시 상황을 정리하기로 한다.

그리고 그 날 새벽. 해커톤 악동들의 작당모의가 시작됐다.

우리 모두가 서로에게 질문을 퍼부었는데, 이 내용이 상당히 재미있다. 새벽 2시쯤 시작된 논의는 새벽 4시까지 한 순간도 쉬지 않고 진행됐다. 10개월이 넘어간 지금 이 순간에도 이러한 질문들이 아직도 기억에 남는다.

  • Track Winner를 하고 싶은건가? Final Winner를 하고 싶은건가?
  • 즐기기 위해 온거 아닌가?
  • 애초에 만들고 싶은 서비스인가?
  • 지금 재미있나?
  • Track을 변경한다면, 어떤걸 하는게 제일 재미있을까?
  • 각 Track별로 무엇을 어떻게 평가하고, 어떤 점을 높게 쳐줄까? (실제로 주제 발표 영상을 돌려보며 곱씹었다)

물론 몇몇 기획적인 질문들도 오고갔다. 하지만 내가 아직도 이 질문들이 기억에 남는 이유는 우리가 해커톤을 하며 동기를 부여받는 근본적인 이유를 찾고자 했기 때문이다. 우리는 제재 시스템을 재미없어 했다. 그리고 우승할 거란 확신도 안들었다.

고생의 흔적을 잘 보여주는 회의록 목록

그렇게 우리는 다양한 새로운 아이디어를 제안하기 시작했다. 하지만 ZEP을 사용한 재미있는 아이디어는 더이상 찾지 못했다. 그 때 눈에 들어온 트랙이 바로 AWS다.

우리는 게임을 만들어본 적이 없다. 하지만 웹서비스는 만들어봤다. 어라? "웹 게임을 만들면 되는 거 아닌가?" 당장 크롬의 dino(크롬 공룡게임)가 있지 않은가? 나는 즉시 '끄투(나무위키: 끄투)'의 사례를 던졌다.

준성이형이 당시 주목을 받는 이미지 생성 모델인 'DALL-E'를 언급한다. 또 wordle같이 간단한 게임을 만들고 싶다는 얘기가 나왔다.

유레카! AI의 생각을 사람이 맞추는 게임, Imagin Games는 이렇게 탄생했다.

🤪
참고로 'imagine'이 아니라 'imagin'인 이유는 내가 도메인을 사며 오타를 냈기 때문이다.

그 즉시 디스코드로 정션 아시아 운영진에게 트랙 변경을 요청하고 기획 구체화에 들어갔다. 이 때부터 우리는 말 그대로 제품에 미쳤다. 3시간동안 단 1분도 쉬지 않고 노션에 기획을 정리하고, ML 모델을 테스트해보고, 직접 문제를 만들어 풀어보며 PoC를 진행했다.

심지어 우리는 그 뒤로 새벽 5시에 잠들고 아침 9시에 나와 25시간 가까이 한 자리에 앉아서 서비스를 개발하고, 디자인하고, 프롬프트 엔지니어링을 하고, PPT를 만드는 기염을 토했다.


이 때 우리는 모두 이 생각을 했다.
‌‌"우리, 우승할 것 같아."


서비스 개발

위에서 설명했던대로 우리는 제출 마감시간인 3일차 낮 12시까지 달렸다. 부산에 도착하고 마감시간 전까지 6시간 이상 수면을 취한 사람은 없었다.

초안

그렇게 나온 서비스 기획 초안은 이러했다.

사전 준비 과정 - 먼저, 텍스트 생성 모델(GPT-3)을 통해 적당한 문장을 여러 개 생성한다. 그리고, 이 문장을 가지고 이미지 생성 모델(DALL-E)로 이미지를 4장 생성한다. 이렇게 하면 사전 준비는 끝난다.

게임 - 유저들이 게임 사이트에 접속한다. 그리고 모두가 동일한 사진들을 보고 원본 문장을 맞혀야 한다. 다만, 누군가 한 명이 성공하면 모두가 다음 문제로 넘어가며, 모든 입력 시도는 다른 사람들에게 보여진다.

개선

우리끼리 논의하고, 테스트해보며 기획을 다듬었다.

  • 단어 단위로 맞힐 수 있으며, 맞힌 단어는 다시 맞히지 않아도 된다.
  • 제일 처음으로 문장을 맞힌 유저는 기본 점수 외에 시간 보너스를 지급한다.
  • 문장 일부를 맞힌 유저는 맞힌 단어 수 비율만큼 기본 점수를 받는다.
  • 서로 순위를 확인하고 경쟁할 수 있게 리더보드를 추가했다.

서비스 개발

나와 동훈이형은 각각 백엔드 개발 및 프론트엔드 개발을 진행했다. 동훈이형이 먼저 노션 API 문서를 작성하면 내가 그걸 보고 백엔드 서비스를 개발했다. 기술적인 내용은 번외 챕터에서 자세하게 다룰 예정이다.

그 시각, 준성이형은 열심히 문제들을 만들고 있었다. 프롬프트를 수정하고 결과를 보면서 다양한 문제를 만들어냈다. 문제를 만들면서 밸런스도 잡았다. 원래 한 번에 문장 전체를 맞혀야 했는데, 이 때 단어 단위로 맞힐 수 있게 했다.

디자인

그리고 찬수형에 의해 디자인이 완성되어 가고 있었다.

서비스 디자인 초안: 문제풀이 화면

또 하나의 묘수: 선공개

이렇게 우리는 우리는 계획대로 개발을 진행하고 있었다. 한창 생성 모델과 프롬프트로 싸우고 있는 준성이형이 아이디어를 하나 제시했다.

"우리 서비스 미리 공개해서 반응을 받아보자"

참가자들에게 미리 서비스를 공개해 우리 팀을 인지시키면서, 동시에 반응을 보고 데이터를 활용하자는 제안이었다. 모두가 공감했다. 그렇게 서비스가 모습을 드러낸 3일차 오전(제출 2시간 전), 디스코드에 메세지가 하나 올라온다.

디스코드에 미리 서비스를 공개해 반응을 확인했다.

이 전략은 여러 방면에서 큰 도움이 됐다. 2시간 남짓한 시간동안 118명이 접속해 1,160번 플레이했다. 우리는 이 사실을 PPT에 추가했다. 아마 발표의 신뢰도에 큰 영향을 줬으리라. 여담으로 해커톤이 끝나고 이 메세지를 타고 게임 너무 재밌다고 서비스 계속 열어달라는 디스코드 DM이 오기도 했다.

제출 완료

이렇게 약 38시간에 걸친 대장정이 제출 완료 시점을 끝으로 막을 내렸다.

모두가 박수 갈채를 날리며 서로의 고생을 다독였다. 몇몇은 24시간 넘게 한 자리에서 서비스를 만드는 것이 절대 쉬운 일이 아니라며 고충을 나누기도 했다. (4명 중 2명은 해커톤 자체가 처음이다.)

그리고 여기서 한 가지 짚고 넘어가고 싶은 부분이 있다. 바로 정션 아시아의 행사 경험이다. 입장하는 순간부터 나는 일상에서 벗어나 정션 아시아라고 하는 하나의 가상 공간에 들어왔다고 느꼈다.

해커톤이 아니라 하나의 서비스를 제공받는 느낌도 들었다. 모든 구조물, 디자인, 조명, 일정의 짜임까지 일관된 경험을 제공했고, 행사에 몰입할 수 있었다. 이러한 느낌을 어스름하게 느끼다 명확히 인지한 순간이 바로 제출 시점이다.

38시간동안 앞만 보고 달렸던 우리에게 이제는 끝이라는걸 조심스럽게 인지시켜줬다. 카운트다운을 하며 들뜬 마음을 가라앉힐 수 있었고, 힘찬 목소리와 시각적인 효과까지 더해 마지막 순간을 집중하며 느낄 수 있었다.

0:00
/
제출 마감 카운트다운

대회를 몇 번 운영해본 입장에서 이러한 경험 설계가 대단하다고 느껴졌다. 블로그를 쓰기 위해 사진들을 돌아보고 있는데, 지금 다시 보더라도 운영진이 얼마나 많은 고민과 고생을 했을지 상상이 안된다.

Demo Expo

본론으로 다시 돌아와서, 제출을 완료한 이후에는 데모 엑스포가 진행됐다. 각 트랙 심사자가 찾아오면 약 5분동안 영어로 서비스를 설명해야 했다. 설명은 영어를 잘하는 준성이형이 했다.

각 트랙 심사자가 70팀을 모두 돌아보며 설명을 듣고 질의응답을 해야 하기 때문에 우리 입장에서는 시간이 많이 남았다. 이 시간에 참가팀끼리 서로의 서비스를 구경하고 친목을 다지거나, 행사장 한쪽에 설치된 인생네컷 부스에 가서 사진을 찍기도 했다.

제출 완료하고 다같이 찍은 인생네컷

우승 후보라고요??

데모 엑스포가 끝날 무렵, 슬슬 결과에 대한 기대치가 높아지고 있었다. 우리는 후회 없이 개발했다며 상을 받지 못해도 재밌었다고 했지만, 동시에 모두가 수상할 것을 기대하고 있었다.

그리고 나는 잠들었다.

그렇다. 잠들었다. 너무나도 피곤한 나머지 꾸벅꾸벅 졸다가 아예 책상에 엎드려 자고 있었다. 그러던 와중 옆에 있던 준성이형이 잠을 깨운다. 최종 우승 후보로 선정되었으니 발표를 준비하라는 소식을 전하고 갔단다.

각 트랙별로 기업이 Finalist를 한 팀씩 뽑고, Finalist deck을 진행한 다음, 여기서 Peer Review를 통해 최종 우승(Final Winner)를 거머쥐게 된다. 이 Finalist deck을 준비하라고 미리 알려준 것이다. 발표는 영어를 잘하는 준성이형이 맡기로 했고, 열심히 발표 스크립트 작성을 시작했다.

Track Winner

Finalist 진출과 Track Winner가 별개라고 이해했는데(아닐 수도 있다), 결과적으로 모든 Finalist 팀이 Track Winner가 되었다.

그렇기 때문에 우리도 당연히 Track Winner를 수상했다.

AWS Track Winner

신기했다. 우리가 한 트랙에서 우승을 했다는 사실이. 동시에 우리는 Final Winner 수상도 해볼만 하다고 생각하기 시작했고, 기대가 차올랐다.

최종 우승이라는 벽

최종 우승을 하기 위해서는 각 트랙에서 가장 뛰어난 3개의 팀과 정면으로 충돌해 싸워야 했다. 특히 우리는 같은 회사에서 출전했던 Chainapsis 트랙의 Seoul Parrot팀을 견제하고 있었다. 블록체인 기반의 오픈소스 음악 공유 플랫폼이었다.

최종 우승자는 핀란드에서 열리는 Junction 2022에 참가할 수 있는 티켓과 핀란드로 가는 비행기값 일부를 지원받을 수 있었다.

Finalist deck

준성이형의 발표는 너무 멋있었고, 깔끔했다.

Finalist deck 발표 (영상: 유튜브)

그리고... Final Winner!

그리고 최종 우승팀 발표만이 남았다. 불이 꺼지고, 모두가 숨죽여 정면의 모니터를 응시하고 있었다. 그 때의 상황과 감정은 이 영상이 너무 잘 표현하고 있다.

0:00
/
Congraturation! Team Bitter Sweet!

그렇게 우리는 JUNCTION ASIA 2022에서 우승했다.

해커톤을 준비하며 "우리 핀란드 가야지"라고 농담을 줄곧 했었는데, 현실이 되었다. 아드레날린이 치사량까지 솟구쳤다. 서비스를 만들기까지 힘들었던 모든 순간들은 물론, 잠을 못자서 느끼던 피로까지 잊혀졌다.

이 때 너무 기쁜 마음을 주체하지 못하고 부산역으로 가는 택시에서 기사님께 대회에서 1등했다고, 핀란드 가게 됐다고 자랑을 했던 기억이 있다. (다행히 진심으로 축하해주셨다 ㅋㅋ)

마치며

팀으로 뭉쳐 서비스를 몰입하며 만들어낸 시간이 너무나도 좋았다. 개발하는 와중에도 얼른 사람들에게 공유해서 반응을 보고 싶다는 설렘이 가득했다. 심지어 트랙 우승, 최종 우승까지 하게 되었다. 나 스스로가 대견했고, 멋졌다. 앞으로도 이런 기회가 있다면 계속 참여하고 싶다.

서비스를 만들 때는 감정적으로 솔직하면서도 논리적으로 생산적인 논의를 할 수 있는 팀이 필요하다. 이 해커톤에서는 이러한 논의가 정말 잘 이루어졌고, 우승할 수 있었던 중요한 요인 중 하나였다. 이를 위해서는 서로의 약점을 투명하게 공개하고, 뾰족한 강점을 상호 존중하는 '지독한 솔직함'이 중요하다고 생각한다. 요건 나중에 기회가 되면 따로 생각을 정리해 글을 올리고 싶다.

해커톤

해커톤은 제품 개발을 사랑하는 사람들이 즐기는 대회다. 우리가 그랬듯 우리가 공감가는, 재미있는 제품을 만들어야 하고, 그럴 때 시너지가 미친듯이 폭발한다. 혹시 해커톤에 참여하는 독자가 이 글을 본다면 나는 이렇게 조언해주고 싶다.

  1. 해커톤은 마감 시간이 정해져있다 - 불필요한 디테일은 과감하게 포기하고 핵심 가치만 전달할 수 있어야 한다.
  2. 만들고 싶은걸 만들어야 한다 - 특정 산업군 사람들을 위해, 이름 모를 누군가를 위해서가 아니라 내가 쓰고 싶은걸 만들어야 한다.
  3. 팀원과 과감하게 싸워야 한다 - 아닌 것 같을 때 아니라고 말할 수 있어야 하고, 내 아이디어 또한 거절당할 수 있다는걸 인정해야 한다.

물론 이게 정답은 아닐 수 있고, 사바사 케바케 팀바팀이 존재한다. 다만 우리 팀은 이 방식으로 우승했고, 이 방식이 동작한다는걸 증명했다.

나에게 보내는 위로

나는 지금까지 내가 하고싶은 걸 하며 살아왔다. 이는 강한 동기부여로 이어지기 때문에 뭘 하든 꽤 좋은 성적을 받았다. 하지만 중요한 건 방향이라고 생각한다. 정션 아시아에서는 팀원과 알맞은 방향을 끊임없이 찾아가는 과정덕분에 좋은 결과를 얻었다고 생각한다. 인생에서도 부디 마음 속 깊은 곳에서부터 올라온 목표를 찾을 수 있길 바란다.

그리고 내가 지금 좋아하는 일을 하고 있는 것 같지 않다면, 언제든 멈추고 나를 돌아볼 수 있어야 한다. 정션 아시아에서 중간에 트랙을 바꾸며 Pivoting을 했던 것처럼 말이다. 나 스스로를 돌아보는 연습을 많이 해두자.

발표 슬라이드 - Imaginar.ai

[번외] 백엔드 개발

나는 서비스를 만들며 주로 인프라와 백엔드 개발을 담당했다. AWS에서 실시간 게임 서버를 서버리스로 구축했던 과정을 소개하겠다.

AWS GameTech의 주제는 'Zero-operation' game on AWS였다. 사실 제대로 슬라이드를 본건 아니라 모르겠지만 아마 AWS에서 게임 서버와 관련된 스택이 있었을 것이다. 하지만 나는 '서버리스'로 구성하면 서버 증설을 신경쓰지 않아도 되기에 'Zero-operation'으로 볼 수 있다고 생각했다.

그렇게 구성한 아키텍처는 이렇다.

Imagin Games AWS 아키텍처

인증 시스템 구현

인증 시스템은 Google ID Platform를 통해 빠르게 구현했다. 자체 인증 로직을 만들기엔 시간이 없을 뿐더러 사용성도 해친다고 생각했다. 프론트엔드에서 토큰을 넘겨주면 백엔드에서 이를 검증하는 일반적인 형태로 구현했다.

최근 사용 | Authentication | Google for Developers

또한 로그인 토큰을 각 엔드포인트 API에서 관리할 수 없으니 API Gateway의 authorizer 기능을 사용했다. 소스코드도 같이 첨부했다.

Use API Gateway Lambda authorizers - Amazon API Gateway
Enable an Amazon API Gateway Lambda authorizer to authenticate API requests.
Imagin Games - API Gateway authorizer lambda source code
Imagin Games - API Gateway authorizer lambda source code - authorizer.py

메인 게임 로직 구현

Imagin games는 기본적으로 각 엔드포인트를 모두 AWS Lambda로 구현했고, 상태관리는 모두 DocumentDB가 담당했다. 다행히도 동시성 문제가 발생하는건 정답을 입력하는 단 한 개의 엔드포인트밖에 없었다. 그 외 대부분의 엔드포인트는 상태를 읽기만 하면 된다.

게임 Tick 구현

게임의 최소 시간 단위(Tick)는 1초였고, 이 때마다 특정 로직을 처리해야 한다. 이는 EventBridge에서 1분에 한 번씩 Step Functions를 호출하고, Step Functions 안에서는 1초에 한 번씩 총 60번 반복하며 Tick Lambda를 실행하도록 했다.

A serverless solution for invoking AWS Lambda at a sub-minute frequency | Amazon Web Services
If you’ve used Amazon CloudWatch Events to schedule the invocation of a Lambda function at regular intervals, you may have noticed that the highest frequency possible is one invocation per minute. However, in some cases, you may need to invoke Lambda more often than that. In this blog post, I’ll cov…
이 블로그를 참고해 구현했다.

기타 구현

  • 프론트엔드는 React를 사용해 개발했으며, distribution 파일들을 S3 - CloudFront 스택을 사용해 배포했다.
  • 도메인은 namecheap에서 구매했고, DNS를 연결해 Route 53을 통해 관리했다.
  • ACM을 통해 인증서를 발급하고, 관리했다.
  • 모델 테스트를 위해 us-east-1 리전에 평범한 g5 EC2 인스턴스를 띄워줬다. (아쉽게도 적절한 모델을 찾지 못해 DALL-E API를 사용했다)

아쉬운 점

한 가지 아쉬운 점이 있다면, AWS에서 제공하는 완전 관리형 DB인 DynamoDB를 사용하지 못했다는 것이다. 지금 구조에 의하면 사용자가 늘어났을 때 DocumentDB 인스턴스를 Scale-up 하거나 읽기 전용 Replica를 만들어야 한다. 완전 Zero-operation을 위해서라면 DynamoDB 마이그레이션이 필요할 것이다.

그리고... 시간이 생명인 해커톤에서는 Terraform과 같은 IaC 도구 쓰지 말자. 모두가 도구에 전문가 급으로 익숙한게 아닌 이상 인프라를 수정할 때 오히려 오버헤드가 심하다. 우리도 모든 인프라를 Terraform으로 관리하려다가 시간에 쫓겨 중간에 버렸다. Terraform과 같은 IaC 도구는 '인프라 유지보수'를 목적으로 한다는걸 잊지 말자.

Fxxk CORS

그리고... CORS 이슈는 어떤 서비스를 개발하던 한 번쯤은 만나는 것 같다.

준성이형이 인스타 스토리에 CORS로 고생하는 내 모습을 올렸다.

진짜 마무리

긴 글 읽어주셔서 감사합니다. 반응이 좋으면 Junction 2022, 그리고 런던-핀란드 여행기도 적어보도록 하겠습니다. 궁금한 점이 있다면 댓글이나 이메일 남겨주시고, 다음 소식도 기대가 된다면 아래에서 메일 구독 부탁드립니다.