[AirAction][미니 프로젝트] 회고 기록

[AirAction][미니 프로젝트]

 

진행 기록에 이어 회고를 기록하려 한다.

진행 기록은 아래 첨부한다.

 

https://hooklee.tistory.com/69

[AirAction][미니 프로젝트] 진행 기록

---

1. 기획 부분

이번에 기획에 대해서는 80% 만족했다.

좋았던 점은 기획자가 생각보다 취지에 맞는 기획을 해주었다. 한 번 팀워크를 맞춰보는 것이었기에 간단한 기획이었으며 개인적으로 참신했다. 동생분과 산책하다가 오존도랑 미세먼지 등 여러 대기 정보를 보며 "기온이랑 습도는 알겠는데 나머지는 뭘 어떻게 하라는거지" 라는 말을 듣고 생각한 기획이라고 하셨는데, 배포를 계속 해둔다면 잘 쓰지 않을까 싶었다.

 

아쉬웠던 점은

소규모 단위의 헤커톤에서는 기획자가 PM을 역임한다. 하지만 기획자로서 해야하는 IA나 PM으로서 해야하는 API 명세서와 팀 체킹 부분이 부족했다. 첫 헤커톤이라고 하셨기에 헤커톤 경험자인 나와 프론트 파트장이 PM의 역할을 거의 전부 분담해서 진행했기에 아쉬움이 남았다. 나 또한 시간이 많이 부족했기에 API 명세서나 팀 노션 페이지 제작 및 구성의 역할은 쉽지 않았다.

---

2. 기술 검증

이 부분은 '잘 되어 다행이다'라고 생각했다.

사실 기술검증은 개발 구성원들이 함께 진행해야 하는데, 다른 팀원들이 기술검증이 무엇이고 어떻게 하는 것인지에 대한 이해가 부족했다. 그렇기에 백 파트장인 나와 프론트 파트장이 계속 논의하며 진행했지만, 나 또한 프론트와의 직접적인 논의 경험이 부족했기에 어디까지 프론트에서 할 수 있고 어디까지 백에서 할 수 있는지와 그 중간 지점에 대해 어떻게 하는지를 논의하는 과정이 어려웠다. 그럼에도 이런 과정을 경험하며 기획의 세부사항을 고려하다 보면 그 중간 지점의 해결책이 보인다는 점을 알 수 있었다.

---

3. 개발

음, 사실 재미있었지만 쉽지 않았다.

 

나 또한 쳇 지피티와 끊임없이 토론하고 수많은 기술 블로그를 정독하며 진행했다. 생성형 AI 처럼 필수로 작성해야 하는 코드 구성과 내용물이 많은 API는 작성 자체는 그렇게 어렵지 않았지만, 단순히 받아적는것이 아닌 한줄한줄 왜 이런 문장이 있고 왜 이게 필요하고 어떤 기능을 하는지를 계속 조사하고 공부하면서 진행하다보니 시간이 많이 소요되었다. 하지만 이렇게 하는 부분은 재미있었다.

문제는 분량이었다.

2주의 기간 중에 기획에서 5일을 사용해 실제로 9일 남짓한 시간이 개발 기간의 전부였다. 여기에 연동 및 최종 배포 과정까지 고려하면 5일이 실질적인 개발 기간이었다. 나는 서버 구축 및 관리도 해야했기에 나머지 백엔드 한 분과 작업 분량을 다음과 같이 나눴다. 내가 초반 프로젝트 구성부터 생성형 AI API를 다른 팀원이 카카오맵API와 환경공단 API를 맡았다.

난 기획이 끝나자마자 2일 내로(7일차) 담당 부분 개발이 끝냈지만 8일차에 갑자기 팀원이 계속 오류가 나는데 해결을 못하겠다는 의견을 전달했다. 지금까지 백엔드 팀원이 만든 API를 받아서 쓰려고 했지만 다양한 이유로 불가능한 상황이었고, 그때부터 아예 처음부터 다시 만들다 보니 결국 4일 내내 밤샘 개발이 그 결과였다. 

 

프론트 측은 페이지가 하나이다 보니 각자 개발한 부분을 프론트 파트장이 머지하여 한 번에 배포 및 연동을 하는 방향으로 진행했다.  

 

---

4. 배포 및 연동

이 부분은 거의 50시간동안 7시간만 자고 계속 프론트 파트장과 소통했던 기억이 남는다.

 

자동 배포 과정에서의 yml 파일 작성에서 가장 중요하게 여긴 부분은 캐시였다.

액션에서 예상보다 한 줄 한 줄 바꿀때마저 3~5분씩 걸리는 것을 보고

도커 허브와 함께  yml 파일에도 캐시 설정을 통해 최대한 매번 새로 이미지 빌드하는 것을 막아야 했다.

 

 

이후에 백엔드는 개발이 끝났고 배포까지 자동배포로 마무리했기에, 프론트가 로컬에서 연동해보고 배포해서 최종 연동하는 단계만 남은 상태였다.

 

여기서 순차적으로 2가지 큰 문제가 나타났다.

우선 프론트가 로컬에서 연동하는 과정에서  트래픽 과부화로 일일 키 사용 횟수가 만료되었다. 프론트 팀원 중 한 분이  요청과 응답에서 오류가 나면 될때까지 무한 요청을 하는 로직을 구현하였었고, 프론트 파트장이 직접 한 부분이 아니었기에 그분조차 예상못한 결과였다. 그렇게 새벽에 스웨거에서 기능이 갑자기 안된다는 말을 듣고 확인해보니 클라우스 서버와 로컬 서버 모두 기능에 문제가 생겼고, 그럼 키를 교체하면 되는 상황이라 생각해 키를 재발급받아 시험하였는데 여기서 갑자기 처음보는 오류가 계속 났다.

 

또한 이 오류를 해결하니 네트워크 보안 문제가 생겼다.

미니 프로젝트이기에 도메인을 구매하지 않았고, 당연히 고정 아이피로 서버 접속으로 해야했는데 이게 http로 되는 문제가 생겼다.

https로 만들려면 인증이 필요했고 그 인증에는 도메인이 필요했다. 물론 방법이 있는것 같기는 했지만, Nginx나 Load Balancer 를사용해 해결해보려 했지만 실패했다. 결국 프론트 측에서 cors 설정을 통해 보안 우회를 하는 방법으로 진행해야할 것 같다고 전달했고, 프론트 파트장도 처음 해보는 방법이라 거의 성과 공유회 당일 새벽까지 시도해보고 성공했다.

 

이런 오류 과정에서 다음과 같은 점들을 배웠다.

1, 백엔드 측에서 클라이언트의 과도한 요청을 제한할 수 있다. 필터를 사용하고 그 안에 아래의 핵심 코드를 통해 가능하다.

Bandwidth limit = Bandwidth.classic(8, Refill.intervally(8, Duration.ofSeconds(10)));

2, 정상작동되던 코드에서 키가 바뀌었을 때 작동이 안된다면, 키에 30번 키 인증 불가 외 22번 등의 오류 로그를 확인했다면 애초에 잘못된 코드가 운이 좋게 된 것일 수 있으니 자신있게 코드를 수정해야한다. ( 물론 기존 코드는 따로 보관해두고)

3, 물리 포트 번호와 URL 뒤의 포트 번호는 다르다. 지금까지 같다고 생각했지만 WebConfig 수정 과정에서 다름을 알 수 있었다.

4, 프론트라고 포트번호 3000번을 무조건 쓰는게 아니다. 리액트 로컬은 5173,4를 사용하고 Vercel 배포에선 도메인이 뜬다.

5, Nginx나 Load Balancer 중 프롬프트에 익숙하고 클라우드 인스턴스 공부가 깊다면 Nginx를 아니라면  Load Balancer를 활용한 인증이 접근성이 쉽다. 인스턴스 내 서버 구조에 대해 얕은 이해도로 Nginx를 활용하는 방법을 사용한다면 서버를 뒤죽박죽으로 만들 수 있다.

 

---

회고 마무리

 

그동안 기획과 PM을 맡아 헤커톤에 참여했었다.

프로젝트 팀을 경험하고 싶었지만 백엔드에 대한 공부가 입문 단계였기에, 팀원들에게 피해를 주지 않기 위해서였다.

하지만 불과 6개월이란 시간 동안 배포 파이프라인까지 담당할 수 있을 정도로 미친듯이 공부했고,

백엔드 파트장으로 참여하게 되었다.

 

이번 미니 프로젝트엔 기획에 관여하지 않았지만, 바로 이어서 진행 중인 멋쟁이사자처럼 헤커톤 기획엔 백엔드 파트장임에도 내가 우연히 기획 아이템을 만들어 빌드업을 기획자분이 진행해주시고 있다. 그렇기에 문득 이런 생각도 든다. 이젠 진짜 프론트 쪽만 공부하면 1인 개발이 가능해지겠다는 생각이.

우선 지금 하는것부터 더 공부해야 할 것 같지만 말이다.

 

헤커톤이 처음인 4명과 경험한 2명이 만나다보니 미니 프로젝트에선 비중 비율 조절이 실패해 아쉬웠지만

본 헤커톤 때는 많이 성장한 4명과의 합이 가장 기대된다.

또한 이렇게 업무량이 몰리는 경험이 처음이라 힘들었지만, 프론트 파트장과 내가 공유한 생각은 같았다.

오히려 이렇게 되어 더욱 많이 배웠고 실력도 늘어난 느낌이라 좋았다.