카카오테크 부트캠프 해커톤 회고록

2월 26일 ~ 2월 28일까지 총 3일간 해커톤이 진행되었다.

 

이 기간 이전부터 나는 운이 좋게도 밥팟이라는 아이디어를 가진 팀에서 백엔드로 같이하자는 제안이 왔고 함께 하기로 했다.

 

처음에는 내 실력으로 피해를 끼치는 게 아닌가 하고 걱정이 많았지만 이러한 순간을 돌파할 때마다 성장한다는 생각하에 열심히 하자고 스스로 마음먹었다.

 

우리 팀은 풀스택 3명, 인공지능 2명, 클라우드 1명으로 이루어져 있었으며 카카오테크 부트캠프에서 교육생들끼리 밥을 같이 먹는 파티를 생성하고 참여할 수 있는 아이디어로 진행되었다.

 

내가 맡은 건 Springboot, MySQL(RDS)를 이용한 밥팟 서비스의 API개발이었다.

 

해커톤이다 보니 짧은 시간 안에 만들어야 하는 기능이 정해져 있어 일단 돌아가는 것에 초점을 맞춰 개발하였다.

 

물론 객체지향적인 코드를 작성하고자 하는 욕심은 있었지만 주어진 기한안에 완성하는 게 가장 중요하다고 생각했다.

 

Springboot 서버의 경우 로그인, 회원가입, 밥팟 생성, 밥팟 조회, 밥팟 신청 API를 개발하면 되었고, 간단한 설계에 맞춰 빠르게 개발을 마쳤다. 내 기억으로 26일 수요일에 모든 기능을 완성하였다.

---

❗

여기서 아쉬웠던 건 프로젝트 전반의 볼륨을 낮추기 위해 토큰이나 세션기반의 인증 및 인가 처리 대신 단순 아이디 비밀번호를 비교하여 로그인을 진행하고 API를 요청한 유저의 id를 받아와 최소한의 인증 및 인가만 진행했다는 것이다.

→ 이 아쉬움은 팀원들도 느꼈기에 서비스 리팩토링을 통해 토큰 방식의 인증 및 인가를 진행해보고자 했다.

---

시간이 상대적으로 여유로웠던 터라 도움이 필요한 팀원들을 거리낌 없이 돕기 시작했다.

 

팀 프로젝트는 결국 나만 잘한다고 끝나는 게 아닌 모두가 마쳐야 온전히 끝난다는 것을 언제나 잊지 말자.

 

나는 몇 번 AWS와 Docker를 이용하여 서버 배포를 진행해 봤기 때문에 클라우드 팀원과 서버 및 프론트 배포를 하기 시작했다.

 

프론트에게 실제 배포된 서버로부터 응답을 받으며 개발을 진행하도록 하기 위해 최대한 빠르게 배포하였고 제일 먼저 선택한 방식은 다음과 같다.

• EC2 인스턴스에서 Springboot 레파지토리를 Clone 해와서 build후 jar파일을 실행

해당 방식자체에는 큰 어려움이 없었고, 추가로 babpat.com 도메인 구매 후 ALB와 ACM을 이용해서 HTTPS를 처리하고 도메인 작업을 진행하였다.

 

이를 통해 프론트 개발자가 로컬에서 Springboot 서버를 직접 돌리지 않고 배포된 서버로부터 손쉽게 데이터를 받아올 수 있게 하였다.

---

❗

개발 초기에 프론트 개발자가 직접 로컬에서 Springboot 서버를 돌리면서 작업을 진행했는데

각 백엔드와 프론트 개발자들이 자신의 개발에만 집중할 수 있도록 하기위해 초기 배포 설계 및 세팅이 매우 중요하다는 사실이 와닿았다.

---

Springboot의 배포가 끝났고 다시 어떤 걸 도울 수 있을지를 계속 찾기 위해 팀원들에게 도울 게 있는지 계속 물어보았다. 이를 통해

• 주변 식당을 크롤링을 통해 JSON으로 저장해 놨는데, 여기에서 빈 정보들이 있어서 이를 직접 찾아서 데이터를 메꾸기도 하였고,
• 클라우드 담당하시는 분과 함께 프론트 배포구조를 어떻게 가져가면 좋을지를 고민하다가 S3 및 CloudFront를 이용하여 배포하는걸 같이 결정하기도 하였다.

---

❗

여기서 나는 다시 한번 ‘소통’의 중요성을 배울 수 있었다.

 

만약 내가 내 할 일을 끝내고 가만히 있었다면 상대적으로 중요성이 덜한 JSON 데이터 처리와 같은 작업들이 계속 미뤄졌을 것이다.

 

이는 전체적인 프로젝트의 마감을 늦추게 되고 마음에 드는 결과물이 나올 확률이 적어진다.

 

따라서, 내가 팀 내에서 누군가를 도와줄 수 있는 상황이라면 “제가 뭐 해드릴 게 있을까요?”와 같이 먼저 도움을 준다면 해당 팀원이 어떤 일을 하고 있고 진행도는 어느 정도 되었는지를 체크할 수 있고 전체 프로젝트의 마감도 당길 수 있는 긍정적 영향을 미치게 된다.

---

이후 인공지능 서버인 Fast API의 개발이 완료되어 해당 서버를 어떻게 배포할지를 클라우드분과 함께 고민하였다.

 

하지만 이때 시간이 마감 7시간 전이다 보니 마음이 급해졌고 어떻게 하면 빠르게 배포를 할 수 있을지를 고민하다가 Docker를 통해 다음과 같이 배포하는 방식을 선택하였다.

 

1. Fast API를 Dockerfile을 통해 도커 이미지로 빌드
2. 해당 이미지를 Docker hub에 업로드
3. EC2에서 Docker hub에 올라와있는 이미지를 PULL 해와서 실행

이 방식도 순조롭게 진행되었지만 문제는 같은 EC2 안에 SpringBoot와 Fast API 총 2개의 서버가 존재하다 보니 어떻게 하면 로드밸런서에서 요청을 분기할 수 있을지 감이 안 잡혔다.

 

머리로는 로드밸런서에서 URL을 통해 조건절을 이용한 요청 분산을 이용하면 되지 않을까? 했지만 마감이 점점 다가와서 급한 대로 EC2 인스턴스를 새로 만들었고 그 인스턴스에서 Docker 이미지를 실행시켰다.

 

이렇게 다된 줄 알았지만 문제는 해당 시점에 프론트에서도 이미 배포가 끝났고 HTTPS를 기반으로 Springboot에서 데이터를 받아오는 상태라 Fast API 서버 또한 HTTPS의 적용이 필요했다.

 

마감 시간이 4시간 정도 남은 터라 마음이 급해졌지만, 그래도 최대한 침착하게 진행하였다. 다행히도 순조롭게 HTTPS가 적용이 되었고 프론트엔드에서의 API 요청 응답이 문제없이 잘 작동하였다.

---

❗

여기서 너무 비효율적으로 배포구조를 구성한 게 아닌가 하는 아쉬움이 남는다.

 

물론 이는 클라우드분 또한 아꼈던 아쉬움이었기 때문에 서비스의 확장과 동시에 클라우드 구조를 다시 잡고 싶어 하셨다.

EC2 안에 두 서버를 배포하고 요청 URL을 통해 요청을 각 서버로 분기시키는 방식에 대해 고민하고 적용해보고자 한다.

---

이렇게 정신없이 보내다 보니 3박 4일의 해커톤이 종료되는 순간이 왔다.

지금까지 2~3 개의 해커톤을 진행해 보았지만 이번이 가장 즐거웠고 많이 성장했다고 느낀다.

 

운이 좋게 본선에 진출하게 되었고 수상을 했다는 것도 열심히 한 나 자신에게 큰 자신감을 얻게 해 주었다.

 

또한 자신이 맡은 일을 열심히 해주면서 누구 하나 불만 없이 원활하게 해 준 팀원들이 너무 멋지고 내가 바라던 동료들의 이상향을 보여준 거 같아 나 자신도 되돌아보는 시간을 가졌다.

 

막상 팀 제안이 왔을 때는 내가 잘할 수 있을지에 의문이 많이 들었는데 해커톤을 진행하며 “왜 이렇게 잘하세요..” “너무 감사해요” 와 같은 말을 듣다 보니 자신감을 만땅 충전하였다.

 

걱정하던 순간을 돌파하며 성장한 거 같아 너무나 뜻깊은 시간이 되었다.