현재 활동중인 구름톤 유니브 3기 소속 대학교들이 모여서 한국공대를 주관으로 연합해커톤을 진행하였다. 이에 Server Spring 파트로 참여했다.
🙋♂️ 해커톤 정보
장소
판교 구름 스퀘어
일정
주제가 일주일 전에 공개되는 형태였으며 '구름'이라는 키워드로 프로젝트를 만드는 것이 과제였기에 굉장히 추상적이였다.
해커톤 당일은 약 12:00 ~ 다음날 09:00 (총 21시간) 정도의 개발과 발표 준비 기간이 있었다.
평가기준
평가기준이 기술적인 부분을 굉장히 많이 본다는 점이 특이했다.
👨💻 개발과정 & 나의 역할
역할 : CI/CD와 에러처리 로직, 배포
프로젝트 진행은 팀원을 모두 주제 '구름'이라는 키워드를 알려줌과 동시에 카톡방에 운영자 분이 초대해주시는 것 만으로 시작되었다.
최대한 개발 시간을 확보하고자 우리팀은 아이디어를 각자 내고 불편한 카톡대신 노션과 디스코드를 활용해서 의사소통을 원활히 했다.
9/23 월요일 (해커톤 D - 5)
각자 아이디어를 내고 하루만에 기획자님이 종합해서 기획안을 구체화해주셨다.
디스코드에서 온라인 회의를 진행해 기술적으로 가능한 부분과 불가능한 부분을 나누고, 기능들의 우선순위를 추려냈다.
9/24 화요일 (해커톤 D - 4)
기획이 구체화 되었기에 각자 역할을 분해하여 최대한 효율적으로 작업하려고 했다.
또한 다른 백엔드 개발자 분들 프론트 개발자 분들과의 협업을 위해 API 문서를 최우선으로 작성하기로 했다.
이때 기술선택과 개발환경에 있어 주요한 회의 내용들이 있었다.
- API 문서 작성툴 선정
swagger를 처음 고려하였으나, swagger는 API문서와 관련된 내용이 실제 코드에 반영된다는 점과 문서를 기능구현과 상관없이 최대한 우선적으로 설계하고 싶었다.
->노션에 직접 적는것으로 결정했다. - DB 선정
우리 서비스의 핵심 로직은 여행 경로를 저장하는 방식에 있었는데 이는 관계형 DB가 적합하다고 판단했다.
-> 대표적이며 다들 사용해본 MySQL을 채택 - 깃허브 컨벤션 및 브랜치 전략
컨벤션의 경우 특정 블로그를 참고하여 공유하고 지키기로 사전에 약속했다.
브랜치의 경우 애자일하게 개발을 할 수 있도록 Gihub Branch 전략을 채택했다.9/25 ~ 9/27 (해커톤 D - 1)
각자 역할을 명확히 해두었기에 개인시간을 각자 활용해 작업을 진행하였다.
나는 덕분에 CI/CD와 배포세팅을 해둔 상태로 해커톤에 참여 할 수 있었다.
해당 파이프라인을 활용하여 CI/CD를 구현하였다.
CI의 경우 main 브랜치에 PR을 생성하면 테스트를 진행한다.
CD의 경우 main 브랜치에 push가 발생하면, 위의 파이프라인을 동작시킨 뒤 우리의 discord에 웹훅을 활용해 결과를 전송한다.9/28 ~ 9/29 (해커톤 D - DAY)
당일은 나머지 구현하지 못한 기능들과 프론트와의 연동을 위주로 진행했다
나는 에러처리 코드를 맡았다.
최대한 단순한 결과물이 활용하기 쉬울 것이라고 판단했기에 위와 같은 규칙으로 만들었다.
🚀 결과물
[WayGo 깃허브]
자신이 경험한 여행 경로를 저장하고 공유할 수 있는 커뮤니티 서비스 WayGo를 완성할 수 있었다.
✨ 제공 서비스
- 여행기 CRUD
- 여행기 검색
- 마이 페이지
- 댓글 CRUD
🌊 트러블 슈팅
https://github.com/KGU6/KGU6-back/wiki
크게 3가지 이슈를 만났고 이를 깃허브 이슈에 정리했다.
📝 배우고 느낀 점 & 아쉬운 점
밤을 새가며 해커톤은 처음 진행해보았는데, 정말 즐거운 경험이였다.
-
잘한 점
팀원들과의 소통이 협업에서 얼마나 중요한지 알고 있었기에, 최대한 적극적으로 팀원과 소통하려고 했고 덕분에 우리팀은 바로 작업을 시작한 것은 물론 회의도 굉장히 많이한 편이였다.
덕분에 설계를 충분히하고 진행할 수 있었고, 트러블이 생겼을때도 서로 친근한 분위기덕에 빠르게 사과하고 문제를 극복할 수 있었다. 이런건 처음엔 다소 비효율적인 행동처럼 보일 수 있겠지만, 작업과정에서 있을 시간낭비들을 정말 크게 줄여주었다.
덤으로 작업이 끝난 지금도 좋은 친구들이 되었다😉 -
아쉬운 점
크게 두 가지가 있었다.
-
나의 배포환경에서의 경험부족
스프링 리액트 구성의 프로젝트가 처음이였는데, CORS나 http/https와 같은 배포환경에서의 충돌문제를 사전에 예상했음에도 프레임워크별로 세팅방법이 다르기에 생각보다 시간을 많이 잡아먹혔다.
또한 트러블 슈팅 페이지에 정리해두었듯 배포환경에서의 경험부족으로 실제로 예상치 못한 문제를 겪기도 했다. -
팀 전체의 준비부족
해커톤이 사전에 주제를 공지하는 만큼 작업을 충분히하고 진행했어야 했으나, 개인시간 부족을 사유로 전체적인 설계를 제외한 디테일한 기능구현에서 시간을 너무 잡아먹었다. 때문에 완성도면에서 프로젝트가 아쉬웠다.
이번에 있었던 부족한 점들을 고려해, 다음엔 준비를 좀 더 열심히해서 진행해야겠다.
🖇 관련 링크
