미니 프로젝트 회고

1주일 동안 진행한 미니 프로젝트가 어제 마무리되었다.
프로젝트 마감 3시간 전인 새벽 6시까지 불태우고 멋진 팀장형님의 발표가 끝난후 기절했다가 이제야 일어나서 회고를 쓴다.

1. 프로젝트 소개

일단 프로젝트 시작 약 2~3일전 주제와 팀원이 먼저 공개되었다.
이때 대략적인 주제를 각자 생각해오고 토의를 나누고 있던 중, 주제가 '뉴스'에 국한될 필요는 없다고 운영진측에서 알려주었다.
주제에 대한 가닥이 잡혀진 이후라서 그대로 진행하기로 했지만, 지금 생각해보면 뉴스에 국한되었던게 조금 아쉽게 느껴지네요...

우리 조의 주제는 주식과 뉴스, 그리고 AI의 감정분석을 사용한 주식관련 뉴스의 공유 플랫폼을 만드는 것으로 결정됐다.

👉프로젝트 깃허브 보러가기

2. 기술스택

프론트엔드

• JavaScript
• React

백엔드

• Spring Boot
• Spring Cloud

Devops

• Docker
• Docker-compose

협업 툴

• Slack
• Github
• Figma
• ErdCloud
• Github Projects

그리고 Discord와 Slack중 고민을 했고, 당시에는 물흐르듯 Slack을 채택했지만, 현재 회고를 작성하며 궁금해서 찾아보니 Slack과 Discord는 프로젝트 기반vs계정 기반으로 접근방식의 차이가 난다는 것을 알게 되었다.

+ 회사에서는 오프라인에서 사용하다보니 전혀 몰랐는데 허들기능에서 화면공유/마이크/캠 뿐만 아닌 화면공유를 할 때 그리기 기능이 지원되어서 이슈 해결을 할 때 매우 큰 도움이 되었다.
+ 말벌아저씨처럼 이슈가 발생했다는 말이 있으면 허들을 열어서 빠르게 이슈를 해결할 수 있었다.

또한 2주만에 빠르게 진행해야할 프로젝트였기 때문에, 코드와 프로젝트 관리가 통합된 Github Projects가 더 직관적이고 효율적이라 판단하여 Github Projects를 사용하자고 제안했다.

3. 진행하며 겪은 이슈 & 해결방법

1. 처음 마주한 에러는 역시 CORS에러이다.
   이 문제는 서로 간의 이해와 경험이 부족했던 점에서 발생한 문제였다. Spring의 Security에서 CORS 설정을 할 때 프론트엔드의 포트를 3000번으로 지정했었다. 나중에 이슈가 발생했다는 소식을 듣고 확인해보니 5173 포트에서 동작하고 있었다.
   

회사에서 vite + electron을 사용할 때는 브라우저 없이 요청을 처리하기 때문에 cors에러가 발생하지 않기도 했고 브라우저를 사용하지 않기에 포트번호를 알 필요가 없었다. Vite의 기본 포트가 5173이고, webpack의 기본포트가 3000이라는 것을 이번 기회에 되었다.

또한 프론트엔드에서 API를 호출할 때 axios를 사용했는데, 우리는 JWT를 사용했기에 Axios에 withCredentials: true 옵션을 추가해주니 문제가 해결되었다.

2. 이미지 업로드/다운로드 문제
   이 문제는 내가 구현한 코드에서 발생한 문제였다. 해당 문제를 추적한 로그를 살펴보니 FileNotFoundException이 발생한 것으로 나타났다. Dockerizing 이전, 로컬에서만 테스트할 때는 폴더 경로를 c:\\uploads로 정의했었는데, Docker에서 실행하며 경로가 맞지 않아 예외가 발생했고, 이로 인해 API 호출 시 예외가 발생하게 되었다.

3. 인코딩 관련 문제
   이 문제도 내가 구현한 코드에서 발생한 문제이다. API연동을 진행하고 보니 화면에서 공백 문자열이 +로 변환되는 것을 발견하였다.
   당시에 이를 해결하려고 GPT에게 물어봤더니, 사용자의 입력을 저장할 때 encodeURIComponent 메서드를 적용하면 해결된다 하여 이를 적용했지만, 오히려 이중 인코딩이 되어버렸다.

   약 1시간 동안 오류를 해결하려 고생하다가, 다른 프론트엔드 코드를 확인해보니 별다른 처리 없이 한글 입력이 잘 적용되는 것을 알게 되었다. 또한, DB에서도 한글로 데이터가 잘 저장되는 것을 확인했었다. 결국, 백엔드 부분에서 불필요한 인코딩을 처리하고 있음을 발견할 수 있었다.

   해당 문제 때문에 팀장님을 붙잡고 시간을 꽤 소모하게 되었다.

   이때 1시간 동안 고민하며 느낀 점은, 일단 검색하기보다는 비슷한 기능의 코드를 먼저 살펴봤어야 했다는 것이다.
   (이때 정말 부끄러웠다. 죄송합니다 팀장님!!)

4. 도커 관련 문제
   API 연동을 할 때 이미지 저장소로 Docker hub를 사용했는데, 이때 Mac환경에서 작업중이던 팀원들이 이미지를 불러올 수 없다는 이슈를 알렸다.

   당시 해당 문제를 해결하고자 찾아보니 build 에서 --platform linux/arm64를 붙여주거나 pull에서--platform linux/arm64 옵션을 붙여주면 된다고하였다. 이때 빌드할 때 옵션을 붙여주니 해당 아키텍처를 찾을 수 없다는 오류가 출력되어 pull할때 옵션을 붙여주는 것으로 해결하였다.

   처음 Dockerizing을 했을 때는 monolithic하게 구축하여 단일 이미지였는데, 이후 Config/Eureka/Gateway 등 다양한 이미지가 추가되니 속도가 Docker의 문제가 부각되었다. 이때는 Docker-compose 에서 실패한 컨테이너를 직접 재실행하는 방식으로 해결하였는데, 프로젝트가 끝난후, 회고를 작성하며 찾아보았더니 build단계에서 부터 멀티플랫폼 지원을 하도록 설정하지 않으면 pull이 가능하더라도 최적화가 되지 않는다는 사실을 알게 되었다.
   

Mac사용자와 협업을 처음 진행해 보았기에 도커는 아키텍처에 의존하지 않는다고 착각했었는데, 이렇게 또 새로운 사실을 알게 되었다.

4. 시간 상 아쉬운 점 & 적용해 보았으면 좋았을 것들.

1. 먼저 Git Action의 적용이다.
   처음에는 빌드할 이미지가 하나 뿐이여서 메인 브랜치에 변경사항이 업데이트되면 팀장님이 처리할 수 있었지만, 이후 빌드해야될 이미지가 여러 개로 늘어나며 도커 허브 저장소를 제공하는 팀장에게 반복된 업무가 맡겨졌었다. 이런 상황을 예상했다면, 처음부터 시간을 조금 더 투자해서 도커 이미지를 자동 빌드하고 도커 허브로 업로드하는 CI 파이프라인을 구축해둘걸 하는 아쉬움이 남았다.

   처음에는 이번이 마지막 빌드야라는 생각으로 파이프라인을 구축하지 않았고, 오히려 더 많은 시간이 소요되는 결과가 되었다.

   이 부분이 제일 아쉬운 것 같다. 초기 단계에서 자동화를 구축해두었으면 좋았을 것 같다는 아쉬움이 남지만, 다음 프로젝트를 하게 된다면 이 경험이 생각날 것 같다.

2. 다음으로는 슬랙으로의 에러 알람 연동이다.
   그 동안 프로젝트를 하게되면 슬랙 알림 연동을 해봐야지라는 막연한 생각을 하고 있다가 이번에 적용하고자 하는 생각으로 구체적인 방법을 찾아보았더니 생각보다 간단히 적용할 수 있다는 것을 알게 되었다.
   Spring기준으로 GlobalExceptionHandler역할을 하는 RestControllerAdvice와 ExceptionHandler를 활용하면, Slack의 webhook과 연동만 해주면 되는 일이었다. 하지만 프로젝트 막바지에 아이디어가 더올랐고, 프로젝트의 완성이 더 급한 상황이라 상황상 적용하지는 못 했다.
   만약 실제 운영/관리되는 서비스였다면, 프로젝트에 슬랙 알림 연동을 적용해 실시간으로 에러 알림을 받아 대응할 수 있는 환경의 구축이 가능했을 것 같다.

느낀점

1주일이라는 짧은 시간이었지만, 팀원 모두가 적극 참여해 주었고, 바쁜 일정 속에서도 재밌게 프로젝트를 진행하며 성공적이로 마무리할 수 있었습니다. 자신감을 가지고 시작했지만, 아직 배워야 할 점이 많다는 것을 실감했습니다. 이번 경험을 통해 더 나은 개발자로 성장할 수 있을 것이라 위로하며 여기서 마무리하겠습니다.