[UMC] 4th UMC 해커톤 후기

🌏 해커톤 과정

✅ 날짜 : 2023년 7월 3일 (월) 13:00 ~ 7월 4일 (화) 10:00 (무박 2일)

✅ 주제 : '자유로움' / '트러블슈팅' / '플레이그라운드' 중에서 하나 이상의 키워드를 조합해서 주제 선정

 

UMC는 대학교 연합 IT 동아리인데, 이번 해커톤은 UMC에 참여하는 모든 대학교가 참여해 상당히 큰 규모로 열린 대회였다.

태어나서 처음 경험해 본 해커톤이었다! 과연 내가 밤을 새서 코딩할 수 있을지.. (고민하며 전날 일부러 4시에 잠을 잤다 ㅋㅋㅋ)

 

팀은 랜덤 매칭이었다! 총 10개의 팀으로 나누어졌고 각 팀마다 일정한 비율로 정해진 직군이 있다.

각자 PM / 디자이너 / 프론트(Web, Android, iOS) / 서버(Spring, Node) 직군 중 하나를 가지는데,

우리 팀은  PM 1 + 디자이너 1 (디자이너가 없는 팀도 있었다) + 프론트(iOS) 3 + 서버(Spring) 3  으로 구성되었다.

🌕 플레이볼!

입장은 13시, 본격적인 해커톤 시작은 14시부터 시작되었다. 14시부터 바로 "시작!" 하면서 타이머가 굴러갔다.

내가 팀 프로젝트 경험이 적지는 않지만, 이렇게 "시작!" 하고 바로 맨땅에 건물을 지으라고 하는 것은 조금 당황스럽기도 했다.

우리 팀은 먼저 '아이디어 도출' 과 '협업 방식에 대한 논의' 에 대한 이야기를 나누었다.

 

아이디어 구체화하고 확정하기까지는 대략 2시간이 걸렸는데, 중점적으로 고려한 부분은 '공통 관심사를 고려하자' 였다.

팀원 대부분이 야구를 좋아했는데, 좌석을 예매하고 이에 대한 정보를 일일이 찾아보는 것이 불편하다고 생각하여

좌석 후기를 공유하고 (개인화 서비스도 필요하다고 생각함) 나만의 직관 일기까지 작성할 수 있는 앱을 만들기로 하였다.

 

협업 방식에 있어서는 API 명세서나 기능 명세서와 같은 문서를 만들어 적극 활용하자고 내가 먼저 제안하였다.

참신한 주제로 만드는 것도 좋지만, 해커톤의 본질은 정해진 시간 안에 협업을 통해 목표로 하는 결과물을 만드는 것이라 생각했다.

3학년 1학기 때 '소프트웨어공학' 수업을 들었는데, 소프트웨어를 개발하는데 있어 문서가 매우 중요하다는 사실을 배웠다.

팀플을 진행하며 요구사항 명세를 통해 기능 명세서를 정리했고, API 명세서를 작성해 프론트 연동 시 원활한 소통이 가능했다.

 

이런 점을 미리 알고 있었기 때문에, 정해진 시간 안에 결과물을 만들어내려면 체계적인 문서 정리의 필요성을 느꼈고,

또한 어떤 과정으로 만들었는지 어필하는 것도 수상 가능성을 높이는데 중요하기 때문에 노션에 이를 정리하자고 제안하였다.

 

✅ 요구사항 및 기능 명세서 [링크 🖇️]

✅ API 명세서 [링크 🖇️]

✅ 백엔드 설계 문서 [링크 🖇️]

✨ 수상

다들 열심히 고생한 결과는..! 총 10팀 중  최우수상(2등) 을 수상했다! 🥈🥈

쉬지 않고 밤을 새었기 때문에 시상식 때는 비몽사몽했다. 그래서 최우수상에 우리 팀 이름이 불렸을 때 믿기지 않았다 🤤🤤

 

해커톤 명찰도 여름여름한 계절감이 느껴져서 엄청 예뻤다 🏖️🏖️

 

사실 나도 그렇고 다들 코딩하는데 바쁘고 정신도 없어서 사진을 많이 찍어놓지 못해 좀 아쉽긴하다 🥲🥲

이건 TMI지만 팀원 대부분이 맥북이었고.. 신기하게도 모두 스페이스 그레이 컬러였다.. (맥북은 역시 스그가 국룰!?)

 

해커톤 진행 중에 ERD 설계와 API 명세서를 작성하고 있을 때 캡쳐한 사진이다! 문서를 잘 남겨놓으려고 노력했다.

그리고 이제 가장 중요한..! 해커톤을 통해 성장한 내용과 아쉬웠던 내용을 정리하겠다!

☄️ 성장한 내용

[기술 관련 1] API Response 구조에 대한 고민

그동안 혼자 백엔드를 공부했을 때는, API Response 구조에 대해 크게 고민하지 않았다.

단순히 "데이터만 넘기면 되는 것이 아닌가?" 라는 생각에 리턴 타입이 어떤 자료형일지만 생각했는데, 그게 아니었다.

 

이번 해커톤에서는 같은 백엔드 팀원이 알려주신 방법으로 위와 같이 API Response를 작성하였다.

그냥 데이터만 넘기는 것인줄 알았는데! 상태 코드, 결과, 메시지를 json 형식으로 같이 반환하는 것이었다!

 

결국 서버의 Response는 처리 결과를 간략하게 요약하고(code), 처리 결과를 보여주고(result),

이를 마주하는 사람에게 메시지를 주는(message) 형식을 가지는 것이 의무라고 한다!

앞으로 프로젝트를 진행하며 API Response 구조를 적극 활용하고, 어떻게 디자인하면 좋을지 생각해 볼 것이다!

 

[기술 관련 2] AWS 활용

구현 기능 중 사진을 올리고 조회하는 기능이 있는데, 이를 어떻게 구현할지 생각해보다가 AWS S3를 생각하였다.

AWS S3은 'AWS에서 제공하는 온라인 스토리지 웹 서비스' 인데, 여기에 사진을 올리고 받은 링크를 DB에 저장하여 구현하였다.

또한 해커톤 진행 중 AWS RDS 서비스도 사용해보았다! AWS 관련하여 이해도를 조금은 높일 수 있는 경험이었다!

 

[기술 관련 3] 클라우드타입 배포

평소 배포에 익숙하지 않았기에, 짧은 시간안에 배포까지 진행하기에는 한계가 있었다.

따라서 이번에는 몇 달 전에 전공 팀 프로젝트 팀원분께 배운 '클라우드타입' 을 사용하여 간단한 배포를 진행하였다.

깃허브에는 application.yml 파일을 올리지 않기 때문에, 환경 변수 관련하여 애를 많이 먹었지만 숱한 삽질 끝에 배포도 성공했다!

 

[협업 관련 1] 타 파트와 커뮤니케이션

협업에서 가장 중요한 것은? 바로 '커뮤니케이션' 이라고 생각한다! 아무리 팀원의 능력이 좋다한들 소통이 올바르지 않다면..

설계 초기 단계에 디자이너분께서 화면 구조에 대해 질문해주셨고, 백엔드 팀에서 간단하게 이해를 위한 그림을 그려드렸다!

또한 프론트엔드에서 ERD 관련 논의가 들어왔는데, 같이 협의하여 효율적인 ERD 설계를 위해 노력하였다.

 

[협업 관련 2] 깃허브 Branch, Issues, Pull Requests 활용

브랜치를 나누어 작업하는 것은 몇 번 해보았지만, Issues나 Pull Requests를 사용해본 적은 없었다.

백엔드 팀원 중 한 분이 이에 대해 능숙하셔서 먼저 사용하자고 제안해주셨고, 활용 방법을 학습하였다.

 

Issues에는 간단하게 어떤 기능을 포함하여 커밋하였는지 작성하였다.

이를 main (혹은 master) 브랜치에 merge 하기 위해서는 Pull Requests가 필요했고, 이를 사용하여 merge 하였다.

관련 내용을 더 찾아봐서 추후 진행할 팀 프로젝트에도 사용할 것이다!

 

[협업 관련 3] 협업을 위한 다양한 툴 사용

온라인 디자인 툴인 'Figma' 를 처음 마주하였다. 디자이너님께서 손수 Figma에 화면을 그려주셨고, 잘 활용할 수 있었다.

또한 ERD 설계 단계에서는 'ERDCloud' 를 사용하였다. 온라인에서 동시에 ERD를 설계할 수 있어서 편리했다.

지금도 팀 프로젝트를 하나 진행하고 있는데, 해커톤에서 위 툴을 미리 사용해봐서 현재 익숙하게 잘 사용하고 있다! 

💥 아쉬웠던 내용

일단 정식 배포까지는 진행하지 못 했다! AWS, 도커 등을 활용하여 배포하고 싶었지만, 능력이 많이 부족하였다.

이번 여름 방학 때 도커를 학습해보고 싶고, 실제 서비스까지 배포하려면 보안도 생각해야하기 때문에 VPC도 공부해야 한다!

 

코드 리팩토링을 하기에는 시간이 부족하였다. 일단 기능을 구현하는데 바빴기 때문에, 그동안 작성했던 코드를 활용하였다.

또한 백엔드 내에서도 기능 단위로 파트를 분배하였기 때문에, 밸런스 불균형이 있었다.

 

어쨌든 짧은 시간 안에 협업을 진행하며 많은 것을 배울 수 있었던 해커톤이었다!

나에게 많은 것을 알려준 팀원들에게 너무 고맙다! 이를 통해 꾸준한 성장을 이루고 싶다!

또한 좋은 기회를 잡은 것 같아서 뿌듯하고, 무엇보다 수상까지 이어져서 좋았다! 😏😏