- Published on
멋쟁이사자처럼 대학 10주년 해커톤 후기 (feat. 은상 수상 🥈)
해커톤은 항상 짜릿하다. 특히 이번 해커톤이 더욱 그랬다. 아이디어 기획부터 개발, 그리고 무박 2일 해커톤 현장에 이르기까지의 생생한 후기를 기록하고자 한다.
목차
서비스 소개
이번 해커톤에서 우리 팀이 제안한 서비스는 바로 토큰형 앨범 및 온라인 앨범 구매ˑ보관 플랫폼이다. 내가 고안한 아이디어이다. 시대가 바뀌며 역할도 바뀌었지만 유통과 생산 방식은 그대로인 현재의 CD형 음반 대신, 소비자가 진짜로 찾는 핵심만을 절감된 가격에 판매함으로써 소비자(원하는 것만을 저렴하게 구매), 기업(원가 및 물류비 절감), 나아가 사회에도(자원 낭비 최소화) 긍정적 변화를 줄 수 있는 새로운 형태의 음반과 그 유통 플랫폼을 제안했다.
문제 상황, 서비스 아이디어, 비즈니스 모델 등 당시 나의 아이디어 초기 기획안은 여기에서 볼 수 있다. PDF로 변환해보니 거의 A4 용지 세 페이지 분량이 나왔다! 😮
백엔드 팀 개발 이야기
이렇게 아이디어 기획이 끝나고, 본격적으로 개발에 들어갔다. 나는 백엔드 팀을 이끄는 백엔드 팀장의 역할을 추가로 맡았다. 해커톤 팀장을 해본 적은 많지만 이 정도의 다인원 팀에서 백엔드 장을 맡은 것은 처음이었기 때문에 유능한 팀원들을 잘 이끌고 도울 수 있을지 걱정이 앞서기도 했다.
개발 플랜을 짤 때는 DB와 API 설계에 비중을 두었다. 여러 아티스트, 앨범, 각 앨범에 해당하는 노래와 포토카드, 구매 내역 등 DB에 담을 정보가 많았고 테이블들이 서로 관계를 맺고 있는 것이 많았기 때문에 (ex. 아티스트-앨범, 앨범-포토카드, 앨범-수록곡 ..) 짧은 개발 기간 동안 혼란 없이 효율적으로 개발을 하기 위해서는 기초 설계가 탄탄해야 한다고 생각했다. 설계 과정에서 여러 케이스가 고려되고 다양한 피드백도 거치고 나니(ex. 구매 정보를 담당하는 테이블을 따로 분리할 것을 제안했다), 실제로도 이 부분에서 꼬이는 경우는 적었다. 시간이 맞지 않아 이 작업을 다같이 하지 못하고 일부 팀원들이 맡아 주게 되었는데, 그 팀원들이 정말 고생을 많이 했다 🥲 멋진 우리 팀원들..! 👍
나의 역할
1. API 개발
나는 유저가 아티스트를 구독/삭제하는 API와 마이페이지에서 정보 수정을 할 때 사용하는 API를 맡아 개발했다. 아티스트 구독/삭제 API는 각각 PATCH /sub_artist/userid와 DELETE /sub_artist/userid로 설계되었다. 유저 모델에서 각 유저의 구독 아티스트를 저장하는 ManyToMany 필드에 해당 아티스트(요청으로 넘어온 아티스트)가 add 및 remove 되도록 개발했다.
마이페이지의 유저 정보 수정 API는 PATCH /userinfo/userid로 개발하였으며, 유저 정보 조회 API를 개발한 팀원이 설정한 UserSerializer를 여기서도 활용하였다.
2. loaddata를 활용한 데이터 생성 및 삽입 자동화 구현
사실 API 개발보다도 이 작업에 시간을 더 많이 썼다. 우리 서비스는 미리 DB에 넣어 놓아야 할 상품 정보가 많았다. 아티스트, 앨범, 포토카드, 각 앨범의 수록곡 등.. 이 데이터들을 기획·디자인 팀으로부터 넘겨 받아 DB에 저장해두고 시작해야 했다.
🤔 어떻게 많은 데이터를 넣을까?
문제는 '어떻게 넣느냐?'였다. 다른 팀원들에게 그동안 데이터를 어떻게 DB에 저장했는지 물어보니 직접 수작업으로 입력했다고 했다. 그러나 수작업으로 입력할 수 있는 크기가 아니었다. 서비스하는 아티스트는 12팀이고, 모든 멤버들을 더하면 총 73명이다. 각 팀당 앨범이 2~3개 정도 들어간다. 그리고 각각의 앨범에는 앨범의 수록곡들이 모두 저장되어야 하며, 앨범에서 멤버들의 포토카드가 랜덤하게 뽑힐 수 있도록 앨범-모든 멤버들의 셀카 사진(인당 7장)을 조합하여 포토카드 데이터도 미리 생성해 저장해두어야 한다. 대강 계산해봐도 몇 백 개 이상이다.
물론 실무에서는 큰 사이즈의 데이터가 아니겠지만, 실 서비스를 다루어보지 않은 내 입장에서는 처음 처리해보는 사이즈였고 많은 양의 데이터를 기획·디자인 팀으로부터 어떤 형태로 받아 어떻게 DB에 넣고, 백엔드 개발 인원 전체가 공유하며 사용할지 고민을 해야 했다. 어떤 DB를 사용할 것인지는 정해지지 않은 시점이었는데, Django에서 기본으로 제공하는 Sqlite3를 사용하든 아님 DB 서버를 하나 파고 연결해서 쿼리를 입력하든 대량의 데이터를 효율적으로 DB에 넣기 위한 방법은 필요할 것 같았다.
💡 json으로 만들어서 loaddata로 불러오자!
내가 고안한 해결책은 바로 Django의 loaddata를 사용하는 것이다. Django에서는 데이터 이전 작업을 간편하게 할 수 있는 dumpdata와 loaddata 기능을 제공한다. dumpdata는 현재 Django가 사용하고 있는 데이터를 json 형식으로 저장해주고, 반대로 loaddata는 덤프된 json 파일에 담긴 데이터를 Django의 DB에 넣어준다. 옳다구나, 그렇담 json으로 데이터를 만들어두고 나중에 loaddata로 불러오면 될 것이다.
나는 아티스트, 앨범, 수록곡, 그리고 포토카드 데이터를 자동으로 생성해 json으로 저장해주는 4개의 함수를 짰다. 이 함수들은 엑셀 파일에서 각각의 항목을 읽어와서, 이들을 모델의 구조에 맞게 딕셔너리 형태로 저장한다. 이미지 데이터 또한 AWS S3의 URL을 저장함으로써 문제 없이 저장할 수 있다. 이렇게 자동으로 만들어진 딕셔너리 형의 데이터들은 json 파일에 기록된다.
이렇게 데이터를 DB에 저장될 수 있는 구조로 바꾸는 작업을 자동화하면, 데이터가 담긴 json 파일이 빠르게 만들어진다. json 파일이 만들어지면 터미널에 단 한 줄의 명령어만을 입력하여 빠르게 자동으로 데이터를 불러와 저장할 수 있다.
천 명 앞에서 내 아이디어가 발표되던 순간
드디어 해커톤 D-Day! 막판 스퍼트 올려 개발도 하고, 여러 부스도 돌아다니면서 내 대학 생활 처음이자 마지막 오프라인 해커톤을 야무지게 즐겼다. 전국 멋사 10기들이 모두 모여 큰 강당에서 개발에 열중하는 모습을 보니 정말 떨렸다.
이 많은 사람들 중에 발표할 수 있는 사람이 10명 뿐이라니.. 우리 팀의 아이디어와 결과물에 꽤 자신이 있었던 나는 '제발 발표만이라도 할 수 있길..'하고 간절히 바랐다. 아마 거기 있던 천 명 모두가 같은 마음이었을 것이다. 심지어 다른 학교에서는 사전에 만든 홍보물을 뿌리며 홍보를 하기도 했다 😮
간절한 마음에 나도 즉석에서 PPT로 홍보물을 만들었다. 정말로 우리 서비스를 알아 주었으면 하는 마음에, 같은 팀원과 함께 노트북에 슬라이드를 띄워 놓고 돌아다니면서 우리 서비스를 홍보했다.
그리고 새벽 2시, 1차 투표에서 전체 73팀 중 BEST 10으로 선정되어 발표를 할 수 있게 되었다! 1000명의 사람들 앞에서 내 아이디어가, 내 손으로 만든 서비스가 발표되던 순간이었다.
은상(강남언니상) 수상
대망의 최종 발표. 긴장감이 고조되는 가운데 은상 수상에 우리 팀이 호명되었다! 내 아이디어를 담은 서비스였고, 백엔드 포지션에서 이룬 첫 수상인만큼 더욱 기뻤다.
물론 기획부터 배포까지의 단계가 마냥 순조롭게만 진행된 것은 아니다. 내가 제시한 아이디어는 특정 마이너 문화인 '팬덤 문화'를 타겟으로 하여 기존에 없던 개념을 제시한 것이다. 그렇다보니 거의 만장일치로 통과된 아이디어였음에도 불구하고, 막상 팀원들 모두가 이에 대해 동일한 이해를 갖고 출발하기는 쉽지 않았다.
또, 그저 하나의 웹 서비스를 제안함을 넘어서 이 서비스를 바탕으로 국내 음반 유통 시장과 새로운 팬덤 문화가 형성될 것을 전제했을 때 설명될 수 있는 아이디어이다 보니, 단기간에 결과물을 만들어 서비스를 보여주어야 하는 해커톤에서 이 아이디어를 어떤 식으로 풀어나가야 할지 고민이 필요했다. 그래서 우리 팀은 단순 온라인 앨범 구매ˑ보관 플랫폼을 넘어서, 이 서비스가 '나만의 온라인 덕질존'으로도 활용될 수 있도록 컨셉을 잡아갔다.
개발자로서 남는 아쉬움으로는.. 제일 큰 아쉬움은 상술한 데이터 생성 및 입력 작업에서 생각보다 많은 시간이 소요되었던 것이다. 데이터 생성 과정에서 아이돌 멤버의 포토카드 각각에 앨범을 랜덤하게 연결해주어야 했는데, 이 로직을 구현하기가 쉽지 않았고 결국 100% 완성은 못 했다. 이로 인해 프론트 단에서 기능 확인이 늦어져 정말 미안했다.
또, 데이터 작업을 진행한 브랜치를 develop 브랜치에 병합하려고 하면 자꾸 conflict가 났다. 해커톤 현장에서 당장 충돌 자체를 해결하긴 무리라고 판단되어, 결국 내가 작업한 브랜치에서 배포를 진행해 응급처치를 했다. 배포는 무사히 할 수 있었으나, 사실 올바른 방법은 아니다. 이거 나중에 해결 한 번 해봐야겠다.. 🤕
마지막으로 백엔드 팀장으로서, 백엔드 팀의 업무 분배와 소통과 관련한 아쉬움도 남는다. 당시 서비스 기획이 완료되기 전이었고, 또 다들 시간이 맞지 않아 본격적으로 개발에 들어가기 전에 모두가 서비스 전체에 대해 논의하는 구상하는 시간을 가질 수 없었다. 일정상 그 상태로 업무 분담을 우선적으로 해야 했다보니 업무 분배가 적절치 못하게 되는 문제가 있었다. 팀장을 맡은 내가 미리 사전에 예견하고 방지했어야 하는 부분인데 많이 부족했다는 생각이 든다. 또, 11명의 다인원이 온라인으로 소통을 하며 진행하다보니 소통 문제가 있었다. 서로 이해하고 있는 기획이 다르다거나, 개발 진행 상황이 전체에 잘 공유되지 못하거나 등등.. 팀장이라는 직책을 가진 만큼, 내가 더욱 책임을 느끼고 적극적으로 나섰어야 했는데 그런 점이 부족했던 것 같아 반성했다.
이렇게 크고 작은 어려움이 있었지만, 큰 성과를 얻을 수 있었던 이유는 바로 멋진 팀원들 덕분이다. 이 상은 절대로 내가 잘 해서 받은 상이 아니다. 이렇게 멋있는 사람들과 함께하지 않았더라면 절대로 혼자서 이런 성과를 얻을 수 없었을 것이다. 좋은 사람들과 성장의 경험을 공유하고, 빛나는 성과까지 얻어낼 수 있어 감사했던 경험이었다. 부족한 나와 함께 해준 팀원들과 도움을 준 많은 사람들에게 감사하다.