[WIL] 항해 99 12주차 회고록 - 실전 프로젝트 배포
어느덧 실전 프로젝트를 시작한 지도 5주가 지났다.
바쁘다는 핑계로 일주일마다 써야 하는 회고록도 미뤄왔으니 반성해야 할 게 이만저만이 아니다,,
원래 이번 주 수요일에 1차 배포를 하는 게 목표였지만 프론트엔드 쪽의 작업이 늦어지는 바람에
오늘이 되어서야 겨우 프로덕션 배포를 마칠 수 있었다.
다사다난했던 5주
항상 다사다난했던 건 아니지만 프로젝트의 시작과 마지막에는 크고 작은 이슈들이 있었다.
처음에는 서비스 기획 단계에서 의견을 좁히는 데에 있었고,
마지막에는 디자이너 분들과 커뮤니케이션 하는 과정에서 발생했다.
아무래도 프론트엔드와 백엔드도 디자이너와 협업하는 게 처음이고,
디자이너 분들도 개발하는 사람들과 협업하는 게 처음이다 보니 애로사항이 없을 수 없었던 것 같다.
그래도 처음에도, 마지막에도 잘 갈무리하고 마무리할 수 있게 되어 다행이라고 생각한다.
이 부분에는 팀장님이 정말 많이 고생하셨다.
스트레스 받는 일이 많았을 텐데도 내색 한 번 안 하신 팀장님께 압도적 감사하다.
배운 것들
1. 개발 외적인 것들
아이러니하게도 개발에 집중하기 위해 개발 외적인 것들을 도입하게 되었다.
첫 번째는 워크플로우 자동화를 위해 CI/CD (Github Actions)를 적용한 것이고,
두 번째는 에러와 성능을 기록하기 위해 sentry를 적용한 것이다.
특히 Github Actions를 적용하면서 막연하고 멀게만 느껴졌던 CI/CD에 대해서도 개념을 명확히 정립할 수 있게 되었다.
처음에는 https를 적용할 계획이 없어서 테스트 환경 브랜치에 push 액션이 일어나면
자동으로 빌드가 되고 S3 버킷까지만 업로드되도록 워크플로우 파일을 작성하였으나,
테스트 배포를 하고 보니 주소창에 함께 보이는 주의 요함 같은 보안과 관련된 경고 문구가 함께 보이는 게 불편했다.
사이트를 만든 나조차도 그렇게 느껴지는데, 모르는 사람이 보면 유해성 사이트라고 쉽게 오해할 만한 요소라고 생각되었다.
그래서 뒤늦게 AWS의 ACM과 cloudfront로 https를 적용하여 다시 배포하였고,
워크플로우 파일에도 cloudfront로 배포할 때 캐시를 무효화하는 단계를 추가함으로써
특정 브랜치에 머지만 하면 빌드 -> S3 업로드 -> cloudfront 무효화까지 자동으로 되어 개발 외에 들어가는 리소스를 줄일 수 있었다!
CI 서버를 구축하는 일까지는 힘들 것 같지만 다음에는 다른 툴도 사용해보고 싶다.
2. 컴포넌트 재사용
원래는 눈에 잘 들어오지 않던, 컴포넌트로 분리해서 재사용하면 좋을 것들이 눈에 들어오기 시작했다.
처음 기획 단계에서 프론트엔드 팀원들과 같이 논의해서 정했다면 더 좋았겠지만..이건 아직도 이른 감이 있는 것 같다.
자주 사용하게 되는 모달이나, 각 페이지의 타이틀, 헤더와 레이아웃 영역을 잡아줄 그리드 등등
작업을 하면서 중간 중간에 만든 것들도 있고, 배포한 뒤 혼자 리팩토링 하면서 나중에 만들게 된 것도 있지만
컴포넌트의 뎁스를 어디까지 잡아서 분리할 지는 아직도 나만의 기준점이 없어서 어렵지만
항상 상태관리에 유의하면서 분리하는 연습을 이어가야겠다.
3. CRUD
이번 프로젝트에서도 백엔드와의 협업에서 근간이 되는 CRUD를 할 일이 많았다.
데이터를 보내고, 받아 오고, 수정하고, 삭제하는 일이 더이상 어렵거나 버겁게 느껴지지 않는다.
다만 당연히 상태관리는 계속해서 공부해야 하고,
상태관리를 도와주는 라이브러리의 장단점과 특성을 잘 이해하고 어떤 라이브러리를 사용할 지 결정할 수 있도록 익혀야겠다.
반성할 것
1. 라이브러리 의존도를 낮추자
이번 프로젝트에서는 유독 라이브러리를 많이 사용한 것 같다.
처음부터 라이브러리를 사용하려던 건 아니었는데, 코드를 짜면서 어느 정도 붙잡고 있다가 안 되겠으면
시간이 없다는 핑계로 라이브러리를 찾아보고 설치해서 사용했다.
무턱대고 잘 알아보지도 않고 아무 라이브러리나 가져다 쓴 건 아니지만...
라이브러리에 의존을 너무 많이 하게 되면 내 코드가 더이상 내 코드가 아니게 되는 느낌이 들어서
항해가 끝나면 라이브러리를 사용하지 않고 똑같이 구현할 수 있도록 해봐야겠다.
2. 협업할 때 컨벤션은 미리미리, 촘촘하고, 세세하게
커밋 메시지 컨벤션은 정해놓고 정작 코드와 관련된 컨벤션에 대해서는 자세히 다루지 않아서
결국 제각각의 스타일대로 코드가 작성되어 있다.
변수, 함수, 클래스 네이밍부터 스타일 적용 방법까지 처음부터 세세하게 정하고 시작해야 한다는 걸 배우게 되었다.
아직 다같이 리팩토링을 시작하지는 않았지만, 이 부분에 대해서도 팀원들과 같이 얘기해보면 좋을 것 같다.
3. 커뮤니케이션
커뮤니케이션이라고 해야 할 지...
나는 정말 중요한 프로젝트이니 만큼 완성도 있는 결과물이 나오기를 바랐고,
그러기 위해서는 서로 의견을 주고 받으며 서비스 기획이 되었든, 디자인이 되었든, 기술 또는 기능적인 것이 되었든
더 좋은 방향으로 나아가길 바랐다.
아마 이거는 개개인의 성격 문제겠지만, 우리 팀은 누군가 의견을 내면 거기서 바로 결정되고 끝나는 일이 많았다.
내가 자유롭게 의논하는 분위기가 형성되기를 바랐으면 내가 주도했으면 됐을 일인데 그러지 못했던 것 같다.
이 부분이 가장 아쉬움이 크다.
이제 항해 99도 2주밖에 남지 않았다.
아마 다음 주도 최종발표와 프로젝트를 개선하느라도 정신 없이 흘러갈 것이고,
그 다음주도 포트폴리오와 이력서를 작성하느라 바쁘게 지내야 할 것 같다.
다른 분들과 얘기하다 보면 다들 비슷한 고민과 걱정을 가지고 있다는 걸 알게 된다.
다들 지금까지 열심히 해 온 만큼 항해를 수료하고 나서 좋은 결과가 있기를 바란다..!