간략 소개
이 프로젝트는 스터디 멤버들과 함께 풀스택으로 진행했다.
내가 맡은 역할은 다음과 같다.
① auth - 회원 가입, 탈퇴, 로그인, 로그아웃
② 공용 api 및 시간 남을 때 팀원 돕기
FE에서는 SWR, jwt 를 처음 사용해보았고 BE 쪽에서는 Nodejs를 TypeScript로 사용했다.
다들 타입스크립트를 사용해본 경험이 없어서 FE보다는 비교적 BE 코드가 간단해 이쪽에 사용해보자는 의견이 나와서였다.
나는 BE쪽에서 Model, Controller, Service로 코드를 나눠서 작성하자고 의견을 냈고 이대로 진행하게 되었다.
이런 의견을 낸 이유는 MVC 패턴을 사용하는 이점을 경험해보기 위해서였고, 좀 더 높은 짜임새의 코드를 만들고 싶다는 욕심 때문이었다.
Nodejs를 공부하던 중 발견한 아래 블로그 글을 본 것도 한몫했다.
책임 분리를 통해 코드 가독성 및 유지 보수성 증가, 모듈화로 재사용성 증가, 테스트, 혹시 모를 확장까지 대비한다니 안 할 이유가 없었다.
지난 프로젝트들에서 삽질을 하고 진한 현자 타임을 보낸 결과 그나마 초보 개발자다운 아이디어를 낸 것이었다. 나름 장족의 발전이었다.
MVC 패턴으로 코드를 나누는 것에서는 좀 어려움을 겪었다. 정확히는 Controller와 Service의 분리가 어려웠다.
그래서 일단 Controller에 코드를 전부 때려 박고 Service에 해당하는 부분을 계란 노른자 분리하듯 분리하면서 감을 익혔다.
그 결과 다음과 같은 나름의 기준점을 세울 수 있었다.
『컨트롤러는 서비스를 호출해서 값을 넘겨준다, 서비스는 컨트롤러에서 값을 받고 검증과 에러처리를 한다.』
이렇게 나름 막힌 혈을 뚫으니 복잡하던 라우터 분리도 감을 잡을 수 있었다.
(사실은 하나도 복잡한 게 아니라 어렵다고 생각하니 복잡해 보였던 것임을 얼마 후에 깨달았다...)
이 때를 기점으로 Nodejs 숙련도가 좀 쌓였고 자신감도 생겼다.
CORS 연결, 라우터 분리, 스키마 및 모델 분리 구성, MVC, 데이터 검증을 겪은 덕분이었다.
하지만 여전히 타입스크립트를 능숙하게 사용하지는 못했다.
솔직히 말하자면 타입스크립트라는 벽돌로 집을 만든 게 아니라 색만 칠한 느낌이었다. 향만 첨가된 느낌의 과자랄까.
FE 작업에서도 다양한 경험을 했다.
jwt와 SWR을 처음 써보면서 우여곡절도 많았고 배우는데 시간도 좀 걸렸지만 한번 사용해보고 나니 '이래서 쓰는군'하고 고개를 절로 끄덕이는 부분들이 있었다.
만약 이 기능을 내가 직접 구현해야한다면? 벌써 두통이 온다.
jwt와 SWR을 사용하면서 배운 점은 아래에서 자세히 서술하겠다.
axios와 SWR을 같이 사용하는데서 오는 문제점에 대해 트러블 슈팅 글을 써보기도 했다. swr + axios interceptor 오류
개인적으로 내가 많이 부족해서 팀원들이 많은 에로 사항을 겪었던 프로젝트다. 아직도 미안하게 생각한다.
배운 점
- FE 측면
① stale-while-revalidate의 중요성
SWR과 jwt 사이에는 공통점이 있었다. 그건 바로 '신선하고 신뢰 가능한 데이터'를 다룬다는 것.
토큰은 신뢰성 있는 최신의 유저 정보를 요구하고 그를 토대로 자격을 준다.
그리고 유저는 주어진 자격을 토대로 서비스에 접근하며 신뢰성 있는 최신의 데이터를 경험하기를 원한다.
위와 같은 부분을 깨닫고 나니 이제 눈이 조금 트여 데이터 불변성, mutate, cache와 같은 개념들이 왜 나오게 되었는지 감을 잡았다.
검증, 확인, 필요시 최신화, 특정 요청에 대한 선별적 처리...
재료 상태를 항상 확인하는 요리사가 제대로 된 요리를 내놓듯, 데이터에 대해 생각하는 개발자가 제대로 된 서비스를 내놓을 수 있다.
② 기본 기능에 대한 경험치가 있어야 한다.
내가 맡은 기능은 auth였다.
이 기능이 빨리 완성 되어야 로그인 된 유저 정보를 기반으로한 다른 기능의 테스트가 가능했다.
그런데 auth를 처음 개발해보고 swr이나 jwt도 처음 접해보다보니 개발 속도가 생각보다 더 느렸다.
그렇다보니 다른 팀원들이 내 기능을 기다리느라 조금씩 일정이 늦춰지고 말았다.
그래서 이 때 땀을 뻘뻘 흘리며 깨달았다.
기본 기능 구현은 빠르게 이루어져야 하며 앞으로를 위해 기본 기능을 구현해보는 경험치를 쌓아 둬야 한다는 것을.
- BE 측면
① 관심사 분리의 중요성
MVC 패턴을 차용하면서 자연스레 코드 분리가 가능해졌고 괜히 개발자들이 아키텍처를 연구하는 게 아니라는 걸 알았다.
특히 비즈니스 로직을 잘 분리해두니 유지 보수가 편했다.
그렇다고 해서 MVC가 치트키라고 생각하진 않는다. 다만 우리 서비스에 적절한 패턴이었다고 여긴다.
