두 번째 부트캠프 도전기, 프로젝트 POISON 회고록

2년 전, 개발을 시작해보고자 무작정 지원하여 하게된 부트캠프에서 리액트를 사용해 프론트엔드 개발을 시작한 것이 저의 개발자로서의 첫 발걸음이었습니다.

결과는 비록 제대로 완성되진 못했지만 팀원들과 무언가를 개발하여 결과물을 낸다는 것에 크게 흥미를 느꼈고, 그 이후부터 꾸준하게 공부와 프로젝트를 하며 이번 두번 째 부트캠프에 다시 도전하게 되었습니다.

그 과정속에서 겪었던 경험과 이슈들을 공유해보고자 합니다🙂

이번에는 팀 리더로서 활동하게 되었습니다.

잘할 수 있을까 걱정에 앞서 짧은 기간동안 아이디어 기획, 디자인, 개발까지 완료해야 하기 때문에 이전 부트캠프 경험을 살려 빠르게 아이디어 선정부터 해서 POC까지 진행하였습니다.

그렇게해서 최종적으로 선정된 아이디어가 독초 판별 웹서비스 POISON🥀 입니다

이번 프로젝트에서 기능 자체는 심플하게 가져가면서, 적용해보고 싶은 기술 스택들을 최대한 활용해보자 하는 마음으로 진행했습니다. 그 중에서 제가 처음 접해본 기술과 경험 위주로 공유해보도록 하겠습니다.

프론트엔드 에러 로그 트래킹 시스템 Sentry

클라이언트에서 발생하는 오류를 파악하는 가장 확실한 방법은 오류가 나는 해당 브라우저의 개발자 도구에서 오류 내용을 파악하는 것입니다.

하지만 개발 과정에서 오류가 발생할 때 마다 오류를 공유하기 위해 에러가 일어나는 유저의 화면을 공유하고 내용을 확인하기는 매우 번거로운 일입니다.

따라서 프론트엔드 단에서 에러 로그를 트래킹할 수 있는 Sentry를 도입하였습니다. 🙂

Sentry를 사용함으로써 저희 팀은 아래와 같은 이점을 얻을 수 있을 것이라고 판단하였습니다.

• 에러를 더 쉽게 찾을 수 있다
• 다른 사람이랑 줌으로 연결해서 이렇게 해라 저렇게 해라 하면서 오류 재현을 하지 않아도 됨
• 사용자가 오류를 리폿할 땐 이미 그 오류가 센트리에 잘 꽂혀있음
• 다른 팀원에게 물어봤어야 할 부분도 직접 먼저 캐치해서 알잘딱깔센하게 담당자한테 알려줄 수 있음
• 자주 나는 오류를 찾기도 더욱 편리함
• 플랫폼별 차이로 인해 발생하는 에러
• 예시: 익스플로러 환경에서는 호환되지 않는 코드
• API 연동 오류로 인해 발생하는 에러
• 예시: 꽃 유형 중 하나에 일부 데이터가 누락된 걸 찾을 수 있음

이번 프로젝트에는 무료버전으로 적용했지만 프로젝트 규모가 커진다면 충분히 유료버전으로 결제할만한 가치가 있다고 생각이 들었습니다 🙂

생산적인 FE개발, MSW

이번 부트캠프 팀들 중 저희팀은 다른팀보다 월등히 빠른 개발 속도를 자랑했습니다.

저는 빠르게 개발을 진행할 수 있었던 일등공신이 바로 MSW였다고 생각합니다.

프론트엔드 개발을 진행하면서, 필연적으로 백엔드와의 API통신은 이루어집니다.

하지만 아직 백엔드쪽에서 API 개발이 완성되지 않았다면?

그렇다면 프론트엔드는 더미데이터를 만들어 임시로 보여주거나 해당 부분은 배제하고 UI부터 개발하게 되고, API 개발이 완료된 후 API 통신 코드로 리팩토링하여 진행하게 될 것입니다.

이번 부트캠프 특성상 짧은 기간내에 개발을 완성해야 하기 때문에 백엔드에 의존적이지 않게 Mocking API를 만들어 개발할 수 있는 MSW를 도입하게 되었습니다.

MSW는 브라우저에서 일어나는 네트워크 요청을 가로채어 실제 서버가 아닌 클라이언트 사이드에 있는 MSW 라이브러리에 전달되어 등록된 핸들러를 통해 Response를 브라우저에 응답하는 방식으로 작동합니다.

따라서 실제 Mock 서버를 구현하지 않고도 네트워크 수준에서 API를 Mocking할 수 있는 환경을 제공할 수 있습니다!

작성된 API명세서를 토대로 프론트엔드 측에서 테스트할 API를 만들어 백엔드에 의존적이지 않게 개발할 수 있었고 API 개발이 완료되었다면 Request URL만 바꿔주면 되니 개발속도를 엄청나게 단축시킬 수 있었습니다!

Docker Compose와 Github Actions, 서비스 배포

Docker Compose와 Github Actions는 이전에도 사용을 해봤지만 Docker Compose 환경의 애플리케이션을 AWS EC2에 배포하고 CI/CD를 적용해 본 적은 이번이 처음이었습니다.

❓frontend 컨테이너와 nginx 컨테이너간에 정적 파일을 어떻게 매핑할까?

각각 컨테이너로 분리되어 있기 때문에 frontend의 정적 파일을 nginx 컨테이너에 어떻게 넘겨줄까 고민이었습니다.

멘토님들과 다양한 레퍼런스를 찾아본 결과 volumes를 통해 컨테이너간 파일을 매핑할 수 있었습니다.

build_folder라는 볼륨을 만들고 frontend의 정적파일과 매핑한 후, nginx 설정파일에서 지정한 정적파일을 읽는 경로와 다시 매핑시켜 nginx에서 frontend의 빌드 결과물을 읽을 수 있도록 하였습니다.

❓CI/CD 파이프라인을 어떤 방식으로 구축해야 할까?

docker compose 애플리케이션에서 CI/CD를 적용하기 위한 깃허브 액션의 workflow는 크게 두가지로 나눠볼 수 있었는데

1. compose파일을 Image로 만들고 Docker hub에 배포 후 EC2에서 이미지를 받아 compose up 하기
2. EC2에서 깃허브 레파지토리를 pull받아 compose up하기

1번 방식을 적용하기에는 우리 프로젝트에 맞는 레퍼런스를 찾기 어려웠습니다.

멘토님의 추천으로 비교적 간단하게 작성할 수 있는 2번 방식을 채택하여 workflow를 작성하고, 동작할 스크립트를 작성해 주었습니다.

물론 더 효율적인 방법이 있었겠지만 개발 기간이 짧았기 때문에 이대로 진행하게 되었습니다.

마치며..

회고에는 담지 못했지만 비동기 분산 처리를 위한 프론트엔드의 polling 적용, useInfiniteQuery훅을 사용한 무한스크롤 구현, Storybook을 사용한 UI 인터렉팅 테스트 등 이번 부트캠프 프로젝트에서 다양하게 많은 기술들을 접목하여 개발해보는 경험을 가졌습니다.

다양한 기술을 써보는것에 초점을 맞추어 개발하다보니 서비스 기능의 단순함과 UI 부분이 살짝 아쉬웠습니다.

힘들었던것과 별개로 5주동안 팀원들과 밤새 같이 개발하고 고민하는 시간이 너무 즐거웠고 잊지 못할 추억으로 남아있습니다.

부족한 리더를 잘 따라와준 팀원들 덕분에 무사히 프로젝트를 완성할 수 있었습니다. (팀원분들 감사해요 👍)



프로젝트에 더 궁금한 내용이 있다면 편하게 커피챗 걸어주셔도 좋습니다! ☕️

감사합니다 🙇‍♂️