시작하며

회원 가입 전, 서비스를 둘러보는 '게스트모드'에 대한 아이디어가 나왔다.

전환율을 조금이라도 높이기 위해, 미리 체험시키는 것이다.

게스트모드에선 서비스 핵심 기능인 '그룹 챗'을 제외한 다른 기능을 사용할 수 있도록 했다.

즉, TODO를 작성하고 완료 시 Reaction을 할 수 있어야 했는데, 이에 대해 내가 온전히 작업을 담당하게 되었다.

이유는 배포 시기까지 시간이 없었는데, BE 주요 작업이 진행중이었고, FE에서 온전히 처리할 아이디어가 있었기 때문이었다.

사실, 나중에 FE 경험 많은 친구에게 물어보니, 애초에 이 방식은 잘못된 접근이었다고 한다. BE에서 맡았어야 할 작업이었다고.

그러나, 어쨌든 아이디어를 내서 동작 시켰기에 이대로 잊어버리기 아쉬워 기록하게 되었다.

회고록

배경 상황

FE 입장에선, 그룹챗을 뺀 기능을 동작하게 하면서 API를 사용하지 않는게 좋아보였다.

우리 서버는 성능면에서 제한이 많았던 것이다.
(기억상, 사비를 들였던 것으로 기억한다.)

따라서, 로컬 공간인 IndexedDB를 사용하면서, 기존에 개발된 API 관련 동작을 활용해 최대한 비용이 적게 기능을 개발하려 하니, MSW를 사용해 보자는 아이디어를 떠올리게 되었다.

DB 처리하기

IndexedDB를 꼭 사용해보고 싶었기 때문에 좋은 기회라 생각했다.

사용방법을 알아보니, IndexedDB는 NOSQL이라 API동작만 잘 짜두면 됐다.

스웨거를 통해 사용되고 있는 스토어를 확인했고,
CRUD관련 메서드들을 AI 도움을 받아 작성했다.

둘러보기 적용하기

우선, 기존에 사용되던 authStore를 사용하여 guest모드를 체크 후 MSW를 활성화 하는 컴포넌트를 마운트 시켰다.

각 API관련 각종 메서드 내용은 AI를 통해 빠르게 생성할 수 있었다.

msw를 활성화 시키는 메서드를 제작해 브라우저 환경에서 Dynamic Import후 실행될 수 있도록 했다.

회고

당시에는 괜찮은 방법이라 생각했고, IndexedDB까지 사용해볼 계기가 되어 좋다 여겼으나 지금 생각해보니 그렇지 못한 것 같다.

우선, 친구 말대로 이건 BE에서 담당했어야 하는 일은 분명하다.

API 동작을 FE에서 작성하는 것이 말이 안되기 때문이다.

나의 경우는 AI로 작성해서 크게 불편함을 못 느꼈을 수 있었지만, 명백히 책임 범위에서 벗어나는 행위이다.

또한, 만약 BE API 수정이 있었다면 이걸 MSW용 API에 다시 적용해야 했다는 점도 위를 시사한다.

애초에 MSW의 목적은 테스트 용이고, 배포에 나타나면 안된다는 것이다.

마치며

회고해보니 부끄러운 경험이었다.

당시의 상황도, 나의 판단도, 그리고 이를 쓸만하다 여겼던 생각도 전부 다 말이다.

난 창의적인 결과물은, 관습보다 조건과 정의에 집중해서 해결책을 찾는 과정에서 나온다고 생각했었기에 의도적으로 관습을 고려하지 않았었는데, 이것이 문제가 되었던 것 같다.

관습이 생긴 이유가 있을 것이므로 어느정도 고려하는 것은 분명 필요한 것이다.

그래도 회고를 통해 부족한 점을 느낄 수 있어 좋았고, 필요한 부분에 대해서는 누구의 책임인지 명확히 하고 이를 요구할 수 있어야 겠다.