중앙대 UMC X GDG 연합 해커톤(청룡톤) 대상 수상 및 후기
안녕하세요 브로콜리입니다.
지난 2월 9-10일 간 중대 지부 UMC와 GDG가 연합하여 해커톤을 진행하였습니다. 저는 두 곳 모두 속해있지 않은 회원이었지만 다음과 같은 것들을 경험하고 싶어 백엔드로 지원하게 되었습니다.
0. 지원 동기
- 1. 괜찮은 프론트엔드 크루가 있다면 디베이트 타이머 팀에 영입제안을 하고 싶다.
- 2. 대학생들로 이루어진 동아리(ex) 멋사) 부원과 소통하며 내가 성장할 수 있는 환경인지 판단하고 싶다.
- 3. 짧은 시간 내에 크레이티브를 최대한 폭발시키는 과정을 경험하고 싶다.
특히 해커톤은 제 버킷리스트 중 하나로 적혀있을 만큼 개발을 공부하기 시작한 순간부터 어느정도의 로망이 있었습니다. 처음 지원하게 되는 해커톤에 마음이 설레기도 하였습니다.
1. 대회 일정과 팀 빌딩
대회는 2월 9일(토) 오후 1시 - 2월 10일(일) 오전 9시까지 총 21시간동안 진행되었습니다.
팀은 랜덤으로 구성되었으며 저를 포함한 BE 3명 / FE 2명 총 5인 1팀으로 해커톤에 참여하게 되었습니다.
그런데 아무리 생각해도 21시간 안에 서로의 기술 스택을 파악하고 디렉토리를 구성하고 서버를 올리는 것까지의 작업이 물리적으로 불가능하다는 판단이 들었습니다. 이에 먼저 하루 전에 만나 기술스택을 공유하고 기초적인 백엔드 개발에 대한 컨벤션을 정하는 것을 제안하였습니다.
그렇게 약 2시간 정도 백엔드 팀원들과 회의를 진행하였고 다음과 같은 이야기를 미리 나누었습니다.
- 기술 스택과 프로젝트 경험 (구현 가능한 범위)
- DB 선정 : 어떤 데이터 베이스를 사용할 것인지?
- 디렉토리 구조 : 도메인형 vs 계층형
- 서버 배포 : AWS or 다른 클라우드 서비스에 배포할 것인지?
- CI/CD 파이프라인 구축 : 자동 배포를 어떻게 진행할 것인지?
결과적으로 해당 회의는 해커톤 현장에서는 정말 많은 도움이 되었습니다. 기획 확정 후, 개발만 하도록 환경을 세팅해놓으니 사소한 부분에서 협의나 컨텍스트 공유 속도가 빨라졌고, 중간에 에러가 날 때는 CI/CD 파이프라인에서 1차적으로 검증을 하였기에 빠르게 에러 상황을 인지할 수 있었습니다.
2. 대회 당일
2-1)기획
2-1-1) 브레인 스토밍
해커톤 주제는 대회 당일 2시 반 쯤 주어졌습니다.
주제는 2월, 대학생/대학원생, 원, 이렇게 3가지였습니다.
원의 경우 화폐단위 원이던 도형 원이던 본인 입맛에 맞게 해석하면 되는 키워드였습니다.
그렇게 노션 페이지에서 6시까지 기획 회의를 진행하였습니다.
저는 먼저 2가지 기준을 제시하며 이건 진짜 피하자! 라는 기준을 정해놓았습니다.
- 애매한 문제정의 : 있으면 좋겠지만 없어도 상관없는 서비스를 피하자
- 핵심기능이 AI에게 넘어가 사실상 하는게 아무것도 없는 서비스
- 커뮤니티성 서비스 : 유저가 있어야지만 가치가 생기는 서비스보다 개인을 대상으로 한 서비스를 하자!
그렇게 치열한 회의가 오가던 중, 순간 제 뇌리를 스친 아이디어가 있으니, 바로 외부 장학금 정보 제공 대한 아이디어였습니다.
 |
 |
저는 한국지도자육성장학재단 53기 장학생으로 선정되어 3-4학년간 모든 수업료 장학금과 더불어 학기당 100만원의 생활보조금을 받고 있습니다. 그러나, 이렇게 좋은 혜택을 많은 학생들이 관심을 가지지 않아 학교에서 외부장학금 접수기한을 연장하는 일이 빈번하였고 저 또한 경쟁없이 거의 프리패스로 장학금 수혜를 받을 수 있었습니다. 또한 장학금 정보를 제공하는 사이트들을 방대한 자료를 나열할 뿐이라 일일이 공고를 찾아보며 개인이 지원 가능한 장학정보를 찾아보아야 한다는 점이 정말 귀찮았습니다.
이에 장학정보에 대한 낮은 접근성 과 장학정보가 일일이 나에게 맞는지 확인해야 하는 문제를 인식하였습니다.
2-1-2) 진짜 문제가 맞나? : 주변인 인터뷰 & 유사서비스 분석
이후, 이번에 외부 장학금을 알아보느라 저에게 조언을 구했던 후배가 생각나 후배에게 간단한 인터뷰 질문들을 보내고, 그동안 장학금을 알아보며 느꼈던 불편함을 적어 보내달라 요청하였습니다. 그리고 이를 요약한 결과는 다음과 같습니다.
또한, 한국장학재단, 드림스폰, 중학대 장학페이지를 유사 서비스로 잡고 분석해본 결과, 개인의 관심사를 반영한 검색 기능이 부재하고 그저 정보들을 나열하기만 할 뿐이었습니다. 이는 문제가 실존한다는 것을 방증하는 신호이기도 하였습니다.
이때 문제에 대한 확신을 얻을 수 있었고, 프로젝트의 지향 가치(TO-BE)를 정하였습니다.
이 작업까지 합의를 보고 끝낸 순간이 오후 6시, 즉 기획회의를 약 4시간동안 진행했습니다. 개인적으로 해커톤에서 가장 중요하다 생각했던 지점이 바로 기획과 문제정의의 명료성이라 생각했기에 굉장히 잘한 선택이 아니었나 싶었습니다.
궁극적으로 이를 통해 기존에 정보를 적극적으로 탐색해야 했던 소비자들을 그저 정보를 소비하는 소비자로 바꾸는 것이 제 1목적이었습니다.
2-2) 와이어 프레임 작성 및 핵심기능 수렴
이후, 식사를 하고오니 왜인지 모르게 팀원들끼리 백엔드는 API 문서를 뽑고, 프론트는 디자인을 하자는 역할 분담을 미리 해놓았습니다. 처음에는 분담한대로 따랐으나 점차 서로가 생각하는 기획의 방향이 다르다는 생각이 들었고, 한 방향을 바라보도록 통일하는 작업이 필수적으로 필요하다는 생각이 들었습니다.
그래서 팀원들에게 지금 하는 작업들을 올스탑하고 와이어 프레임부터 같이 작성하자는 제안을 했습니다. 팀원 중 몇 분들은 시간 부족을 우려하셨으나 서로가 다른 생각을 기반으로 구현했을 때 얼마나 서비스를 리팩터링하기가 힘들지 알고있기에 팀 전원이 참여하는 와이어 프레임 회의를 밀어부쳤습니다.
그렇게 엑스칼리드로우에 모여 모든 팀원들의 생각이 일치될 수 있도록 와이어프레임을 구성하며 기획의 방향성을 수렴해나아갔습니다.
그 결과 다음과 같은 두 가지 핵심기능을 추출할 수 있었습니다.
 |
 |
| 원하는 조건에 따라 장학금 검색 + 중앙대 장학 캘린더와 연계 | |
첫번째는 개인 관심사에 따라 원하는 장학정보를 필터링할 수 있는 기능으로, 마감순-장학금액순 등 각각 원하는 정보 기준 반영해 장학 정보를 찾아볼 수 있도록 하는 기능이었습니다. 또한 '신청하기' 버튼을 클릭하면 중앙대학교 장학 캘린더로 리다이렉트 되도록 하여 장학금 신청까지의 유저 플로우를 유연하게 잇도록 노력하였습니다.
 |
 |
| 개인정보 입력 -> 지원가능한 장학정보를 15일마다 메일로 발송 | |
두번째는 내 조건에 알맞는 장학정보를 필터링하여 15일마다 메일로 정보를 제공해주는 기능이었습니다. 해당 기능은 메일 발송이란 경험해보지 못한 기능에 도전해야했지만 메일매일 서비스와 다른 레퍼런스를 참고하면 충분히 가능하다 판단하여 추진하였습니다.
2-3) API 문서 작성 + ERD 설계
 |
 |
이후 API 문서를 작성하고 ERD 설계를 진행하였습니다. 사실 도메인 자체가 굉장히 간단했기에 ERD와 구현해야 하는 API는 크게 부담되지 않는 수준이었습니다.
이때가 오후 9시였습니다.
2-4) 본격적인 개발 시작
먼저 백엔드에서는 역할을 분담하였습니다.
저는 메일 발송 기능을 맡도록 하였고, 나머지 두분은 기초적인 CRUD를 맡게 되셨습니다.
정말 다행이었던 점은 약 1시간 이내로 메일 발송 로직을 모두 구현했다는 것이었습니다. 자바에서는 JavaMailSender라는 객체를 지원해줄만큼 SMTP를 활용하면 설정값만 넣어주어도 쉽게 메일을 발송할 수 있었기에 오후 10시 30분쯤 메일 발송 기능 개발을 끝낼 수 있었습니다.
이후, 제가 했던 역할은 다음과 같았습니다.
- EC2 에 서버 올리고 Github Actions 기반 CI/CD 파이프라인 구축하기
- CORS 설정 및 Swagger 설정하기
- CRUD 로직에서 스펙과 맞지 않는 부분 수정하기
- 장학금 검색 로직 작성
특히, 따라오기 힘들어하시는 분들과는 페어프로그래밍을 통해 개발을 같이 진행하며 혼자 하기보다 최대한 같이 나아가는 해커톤이 되도록 노력했습니다.
3. PT 제작 및 발표
발표는 제가 맡기로 하였습니다. 다른 팀원들을 못믿어서가 아니라 제가 겪었던 문제이기에 잘 설명할 자신이 있었고 팀장이기도 하였기 때문이었습니다. 새벽 5시부터 기초 PT 제작을 맡았고, 흐름이 확정된 이후에는 프론트 엔드 팀원이 PT 디자인을 도와주었습니다.
발표 순서는 3분의 교수님을 대상으로 진행되었습니다. 저희 팀은 두번째로 진행되었으며 다음과 같은 질문들을 받았습니다.
Q : 유저가 몰리면 어떻게 인프라적으로 대처할 생각이세요?
A : 로드밸런서 붙이고 대상그룹 설정해서 오토 스케일링 되도록 할 예정입니다. 특히 장학금의 경우 11월 -2월간 공고가 많이 올라오는 만큼 해당 기준치를 11월-2월간에는 더 유하게 잡을 예정입니다.
Q : DB는 어떻게 채웠어요?
A : 우선 서비스의 가치를 보실 수 있도록 약 30개의 실제 장학정보를 더미데이터로 수기로 입력해 저장해놓은 상태입니다. 추후에는 관리자 권한을 추가해 장학정보를 포스팅하시는 장학처에서도 서비스에서 정보를 포스트 할 수 있도록 확장할 생각입니다.
Q : 기술적으로 아쉬워서 개선해보고 싶은 부분이 있다면?
A : 다양한 조건에 대한 동적 쿼리가 요구되는 만큼 QueryDsl을 활용해 개선해보고 싶고요. 메일의 경우 현재 외부 서버, 그리고 핵심 비즈니스 로직과 너무 강한 결합을 지니고 있어 추후 유저가 많아지면 메시지 큐를 통해 의존성을 낮추어보고 싶습니다.
Q : 입력 유효성 검사 안했네요?
A : 저희 팀원들이 대부분 스프링에 익숙하지 않은 상황이라 기능적 구현을 1순위로 삼았습니다. 추후에는 validation 의존성을 추가해 유효성 검사를 추가할 예정이며, 정말 기초적인 부분들을 해놓았습니다.
Q : 깃 안꼬였나요?
A : 네. 하루 전에 이슈 발행에 대해 제가 팀원들에게 잘 설명해놓았고 꼬였을 시, 체리픽하여 다시 풀어주었습니다. 또한 CI/CD 파이프라인을 구축해서 검증된 코드만 올라오도록 시스템을 구축해놓았습니다.
Q: 디자인에 대한 의견 차이는 없었어요?
A : 와이어 프레임을 먼저 작성하여 팀원들이 모두 동의할만한 디자인을 뽑았습니다.
4. 결과 및 느낀 점
이번 해커톤에서 저는 다음과 같은 역할을 맡았습니다.
- 팀장
- [기획] 기획 아이디어 제시 및 회의 진행
- [기획] 발표 진행
- [인프라] 서버 인프라 환경 구축
- [인프라] CI/CD 파이프라인 구축
- [개발] 메일 발송 기능 구현
- [개발] 조건별 일치하는 장학정보 검색 기능 구현
- [개발] CORS 설정
- [개발] Swagger 환경 설정 및 API 문서 작성
해커톤을 하며 결론적으로 느낀 점은 다음과 같았습니다.
- 백엔드 전부를 혼자 어느정도는 할 줄 알아야 한다.
: 만약 팀원들의 서버 관련 지식이 부족할 경우, 홀로 인프라부터 로직개발의 대부분을 맡아야 할 수도 있다는 사실을 알게 되었습니다. 해당 경험이 부담스러웠냐고 묻는다면 반은 맞고 반은 틀렸던 것 같습니다. 누군가를 리드하는 일은 항상 힘들지만 조금 느린 팀원을 기다리며 함께 나아가는 과정은 나름의 뿌듯함을 주기도 하였습니다.
- 결국 문제정의가 중요하다
: 저희팀의 디자인은 크게 인상적이진 않았습니다. 그럼에도 대상을 받을 수 있었던 이유는 기획회의에 많은 시간을 할얘하며, 정말 있는 문제를 해결하고자 했고 그 과정을 심사위원분들께 잘 전달했기 때문이 아니었나 싶습니다. 결국 문제를 얼마나 완성도 있게 해결하나? 보다 진짜 있는 문제를 지금과는 다른 방식으로 해결하려고 했나? 라는 질문이 중요하다고 생각했습니다.
- 소통과 협업 능력은 개발자에게 매우 중요하다.
: 창의성을 경험할 것이라는 첫 기대와는 다르게 어쩌면 소통방식과 협업의 중요성을 크게 느낀 경험이었습니다. 이런 점에서 밀어붙인 와이어 프레임 회의가 서로가 모두 같은 서비스를 그릴 수 있도록 도와주었고 API 문서를 미리 뽑아 프론트에게 공유하면서 아직 개발이 되지 않은 기능도 프론트가 미리 작업에 들어갈 수 있었습니다.
- 학습 키워드
: CORS, 스프링 프로젝트 세팅, H2 메모리 DB는 ddl-auto를 update로 해도 db가 날라간다는 점, csv 파일을 db에 읽히는 방법 등등 새롭게 보완해야 할 학습키워드들을 얻어간 하루이기도 하였습니다.
아쉬웠던 점
- 결국 경험에 따른 기여도 차이가 생길 수 밖에 없다.
시간이 촉박해지면서 결국 경험이 없는 팀원은 멀뚱멀뚱 서있게 되는 시간들이 생겼습니다. 팀원들에게 태스크를 할당해야 하는 팀장이었지만 너무 많은 태스크를 떠안고 있던 탓에 매순간 팀원들에게 적절한 태스크 분담을 해주지 못했다는 아쉬움이 남습니다.
- 컨디션 관리
: 또한 목감기가 심한 상태로 무박 2일을 지난 탓에 해커톤 중간에 예민해지는 경우도 있었습니다. 최대한 감정을 죽이고 침착하게 태스크로 돌아갔지만 조금은 더 좋은 컨디션에서 많이 이야기하며 해커톤을 이끌어갔다면 어땠을까 하는 아쉬움도 있습니다.
- 기본적인 코드 리뷰와 테스트 작성
: 중간에 시간이 없어 코드리뷰를 소홀히 한 결과, 결국 빌드에 실패하게 된 경위가 있었습니다. 기본적인 코드 리뷰와 테스트 작성은 해커톤에서 시간을 낭비하는 행위가 아니라 시간을 줄이는 투자라는 점을 재인식하게 되었습니다.