제로베이스에서 프론트엔드 스쿨 수료한 지 한 달이 되어가는 시점에서 백엔드와 협업했던 프로젝트에 대한 회고를 해볼까 한다. 실은 좀 더 일찍 했으면 좋았겠지만, 이력서니 포트폴리오니 스터디니 등등 미루던 중 백엔드 팀원분께서 추가 기능 구현을 하자는 연락이 와서, 시작 전에 회고하면 좋을 것 같아 작성해본다.
아이디어 선정
프론트엔드 3명과 백엔드 3명이 모여 아이디어 기획 회의가 가장 처음이었던 것으로 생각이 난다. 각자 아이디어를 한가지 들고 와서 소개하고 투표를 통해 아이디어를 선정했다. 나는 깃의 버전관리와 블로그 개념을 결합한 버전관리 블로그(?)를 생각해 왔지만, 나 자신도 이 아이디어에 대해 러프한 생각만 있었고, 이를 빌드업할 수 없어 선택받지 못했다. 우리 협업 팀의 팀장님께서 제안하신, 날씨와 계절 그리고 상황에 맞는 옷을 공유하는 패션 SNS가 채택되었다.
개발 과정
그렇게 아이디어는 정해졌고, 이름 선정에 모두 생각보다(?) 진심이어서 이번에도 내 아이디어는 채택되지 않았다. 바로 그 이름하여 찰칵이란 이름이었는데, 직관적이고 어렵지 않은 이름이라서 나중에는 몹시 마음에 들었다.
Next.js 와의 만남
아무튼, 이름 선정도 끝나고 프론트엔드 팀원들과 프레임워크를 정하던 중 프론트엔드 팀장님께서 Next.js를 제안하셨다. 사실 나는 Next.js 자체에 대해서 회의적이진 않았지만, 이 프레임워크를 채택함으로써 우리가 얻을 수 있는 점과 우리가 개발하려는 서비스가 Next.js와 적합한지였다. 솔직히 말해서 처음 시작하면서 프레임워크를 정하는 데에 적합한지를 따지기에는 시간이 촉박했고, 단지 한 번도 사용해보지 않았고, 요즘 자주 쓰이는 프레임워크라는 것에 의미를 두고 Next.js를 시작하였다.
Next.js는 대표적으로 알려진 CSR과 SSR 중 SSR으로 동작하는 프레임워크다. SNS는 기본적으로 사용자와 상호작용해야 할 일이 많을 거라 생각되어 염려가 앞섰지만, 결과적으로 사용자가 상호작용하기보단 정적으로 보여주어야 하는 것들이 많아 이러한 염려는 기우에 불과했다는 생각이 든다. 우리가 프로젝트를 막 시작하던 시기는 Next.js에 대대적인 업데이트가 돼서, 이전의 page router와는 다른 app router라는 것이 나오는 시점이었고, 결국 완전히 새로운 것은 정보의 부재가 있을 수 있다고 판단하여 주니어에도 못 미치는 실력을 갖추고 app router에 도전하는 것은 만용이라고 생각했고, 잘한 선택이었다.
Next.js 사용을 염려한 내가 부끄러울 정도로 매우 편리한 개발자 환경(?)을 제공한다고 생각을 아주 자주 했다. 순수 React를 사용했다면, Routes에 Route에 element에 일일이 작성해줘야 할 것을 폴더단위로 구분하면 알아서(?) 그 경로를 잡아주고 또, 파일명에 따라 동적 라우팅도 매우 간편하니 이건 뭐... 왜 이제야 사용했을까 싶은 생각도 들었다.
기능을 나누자
그래도, 이전에 다른 부트캠프를 해서였을까... 뭔가 새로운 것을 해보고 싶은 마음이 컸다고 생각이 된다. 처음 프로젝트 OT 때, 멘토님께서 MSW라는 것에 대해서 말씀해주셨다. 시간이 어느 정도 지나고, 서버가 닫히는 경우를 대비하고, 미리 이후에 만들어질 api에 맞춰서 테스트를 진행하기에 좋은 게 있다고 그렇게 설명을 들었다. 프론트엔드 팀원들과 파트를 나누면서, 내심 못 이기는 척 mocking API를 담당하고 싶다고 의견을 냈고, 결과적으로 mocking API, 팔로잉 페이지, 마이 페이지를 담당하게 되었다.
MSW야 미안해..
떨림 반 걱정 반의 마음을 가지고, MSW 공식문서를 정독하고, 관련 블로그 글을 몇 개 기웃거리면서 API mocking을 시작했다. 사실 생각보다 시작은 어렵지 않았다. msw 라이브러리를 설치하면 자동으로 mockServiceWorker 라는 파일이 생성되고, 임의의 폴더를 만들어서 ssr 인지 csr 인지에 따른 파일을 각각 생성 후에 조건문으로, 환경을 체크한 후, api 호출이 일어나면, handler에 작성한 응답이 일어난다.. 정도였다.
물론, 이렇게 끝까지 갔다면 얼마나 좋았을까...까...
사실 생각해보니 API를 mocking 하더라도 결국엔 CRUD 중 최소한 RUD를 하려면 C를 해야 하는데, 이걸 어디다 저장하는지였고... 결국 그전까지 자주 사용해왔고 다신 사용할 일이 없겠다는 생각을 한 firebase를 다시 사용하게 되었다. 그래도, 사실 만만 하게 생각하고 시작했다. firebase의 모든 기능을 사용해보진 않았지만, 그래도 firestore는 자주 사용해봤고, 그래서 할만하겠다 생각했지만 만만의 콩떡이었다.
사실 끝까지 완성은 못 했다. 그냥 혼자서 뚝딱거리면 할 수 있겠다는 막연한 생각도 있었지만, 실제로 해보니 생각보다 혼자서 할 수 없고, 이후에 실제 api와의 연동을 생각해서 post 요청에 쓰일 payload 값도 백엔드 팀원 및 프론트엔드 팀원들과 지속해서 소통을 해야했다. 물론, 이런 과정에서 소통은 당연한 과정이라고 생각하지만, 이마저도 msw로 api 요청 하나를 만들어봤자 사실 복잡하지 않은 코드가 대부분이었고, 그 때문에 소요되는 시간도 짧았는데, 문제는 다른 팀원들이 css나 레이아웃을 잡는 시간에 나는 mocking api를 진행하다 보니 그 간극(?)이 맞질 않았다. 이렇게 점점 간극이 틀어지다가 어느 순간 백엔드의 api 개발이 내가 api를 mocking 하는 속도보다 빨라져서 오히려 내가 그들의 발목을(?) 잡는 느낌이 들었고, 찍먹만 해봤다는 생각을 가지며 일단 msw와는 그렇게 잠시 안녕을 고했다. 후일담이지만, 백엔드 팀원분께서 향후 1년간 서버를 켜놓겠다는 아주 은혜로운 말씀을 해주셔서 지금까지도 미완의 상태로 남아있다..(sorry...)
팔로잉 페이지와 마이 페이지
익숙함에 속아 소중함을 잃지 말자.. 였던가..? 다른 팀원들보다 조금 늦게 react를 만난 나는 사실 매우 기분이 좋았다. 마치 그리워하던 연인을 재회했는데 좋은 기류가 흐르는 그런 느낌..? 아무튼, 프로젝트 이전에 익숙하게 작성했던 일반적인(?) 코드들을 작성하면서 낯선 느낌이 들면서 팔로잉 페이지와 마이 페이지 작성에 돌입했다.
팔로잉 페이지는 원래 메인 페이지와 같은 레이아웃으로 잡고 가려 했지만, 다른 분께서 소중하게 작성한 코드를 내가 날로 먹는 느낌이 들어 그 유혹을 뿌리치고 나만의 레이아웃을 잡자는 생각을 했다. 사실 지금에 와선 이 선택이 찰칵의 통일성을 깨트리는 게 아닌가 하는 생각도 들지만, 결과적으로 masonry 레이아웃을 구현하였고, 나름대로 만족스럽다는 생각이 든다.
마이 페이지는 사실 만만 하게 접근했다가 원 투 펀치를 얻어맞고, 최근에도 잽을 간간이 맞고 있다. 자잘한 버그가 아주 많이 발생했고, 매우 좋은 녀석인 줄 알았던 Next.js의 본모습(?)을 알게 됐다. hydration 에러와 나중에 언급할 아주 고약한 버그.. 물론 이 버그는 Next.js 때문은 아니지만, 어쩌겠는가? 당시의 내 마음이 그랬다는 말이다.
에러와의 만남 (이라 쓰고 트러블 슈팅 이야기라 읽음)
hydration error
hydration은 그 뜻을 해석하면 수화라는 의미이다. Next.js는 서버에서 미리 HTML를 만들고, 클라이언트에서 그 DOM tree에 이벤트를 바인딩하는 형식으로 페이지를 렌더링한다. 즉, 비워진 부분을 클라이언트에서 채우는 방식으로 페이지를 렌더링한다는 말이다. 그래서, 수화 즉 물로 채워지듯이 hydration 된다는 의미이다. 그런데, 바로 이것 때문에 조건부 렌더링을 할 때, 정말 이 에러를 밥 먹듯이 만났다. 결론부터 말하면, 당연히 Next.js에는 이러한 부분을 해결하기 위한 방법들이 준비되어 있었다. dynamic 메서드를 통해 ssr을 하지 않을 것을 명시할 수 있었고, 결과적으론 해결하긴 했다. 물론 지금 다시 만나면 안녕 만나서 반갑고, 다신 만나지 말자.
프로필 사진이 있었는데요..?
이건, 다른 팀원분께서 제보해주신 내용인데, 특정 조건에서 프로필 사진이 날아간다는 제보가 있었다. 문제가 일어나는 상황은 로그인을 진행한 후, 사용자 정보를 수정할 때, 프로필 사진을 건들지 않고 수정하면 프로필 사진이 날아간다는 거였다.(???)
문제를 접수하고, 재현을 시도했으나 나의 경우 재현이 되지 않았다. 더 떨리는 마음을 가지고, 여러 시도 끝에 문제가 발생하는 조건을 알아냈고, 위의 조건이 바로 그것이다. 처음에는 프로필 사진을 한번 변경하고 다시 다른 정보를 수정하게 되면 사진이 안 날아가고, 왜 로그인 직후에 프로필 사진만 변경하지 않고, 다른 정보만 변경했을 때 사진이 날아갔을까 하는 의문이 들었다. 이 경우의 원인은 우선, 아래와 같이 파악했다.
- 서버로부터 받아오는 데이터는 S3에 저장된 이미지 파일의 url이고, 이를 응답받아서 프로필 사진이나 네비게이션 바의 프로필 등을 렌더링한다.
- 서버로 이미지를 수정하기 위한 요청을 보낼 때는 File 객체 형태로 이미지를 전송한다.
- 결국 로그인 직후에는 파일을 드라이브에서 선택하기 전까지는 url 형태의 이미지를 File 객체의 형태로 바꿔야 하는데, 애초에 그런 방법이 있을 수 없다.
결론적으로, 클라이언트의 문제는 아니었다. formdata 에서 multipartFile 자체를 삭제하고 요청을 보내더라도 문제는 해결되지 않았다. 담당 백엔드 팀원분과 테스트한 결과 백엔드 로직에서 multipartFile을 체크할 때, multipartFile이 null이더라도, 그 값으로 DB에 반영이 된다는 것을 알게 되었고, 생각보다 허무하게 바로 수정이 되었다. 물론, 이 과정에서 multipartFile에는 반드시 File 객체가 담겨야 하지만, 현재의 로직에선 예기치 않은 값이 담겨서 갈 수 있었고, 이를 최종적으로 다시 한번 클라이언트에서 체크하여 삭제하고 요청을 보내는 방식으로 수정하였다. 사실, 결과적으론 내가 크게 이 에러를 해결하는 것에 기여한 것이 없다고 생각되지만, 프로젝트가 종료되고 몇 주가 지난 시점에 뭔가 개발자다운 고민과 탐구(?)를 통해 백엔드 팀원분과 이야기한 게 신났던 기분이 들어 이렇게 장황하게 작성해봤다.
마무리는 어떻게..?
백엔드와의 협업은 역시 프론트엔드 개발자끼리 개발하는 것보다 재밌는 것 같다는 생각이 들고, 흥미로운 상황(이라 쓰고 에러라 읽음)을 더 자주 접하게 돼서 여러모로 유익한 시간이라는 생각이 든다. 아무튼 이렇게 대략 6주간의 협업 프로젝트를 마지막으로 제로베이스 프론트엔드 스쿨의 여정이 끝이 났다.
아니 나야 하는데, 취업이 되어야 말이지...ㅎ.. 이력서와 포트폴리오 수정의 향연에 빠졌다. 물론, 새롭게 다시 팀원들과 딥다이브 스터디도 시작했고, 사놓고 미뤄둔 개발 서적도 읽고 있고, 그리고 알림 기능도 구현하자고 연락이 왔는데.. 나의 앞날이 밝았으면 좋겠다.
