지루한 것이 예측 가능하다

사이드 프로젝트를 하고 있다.
서점 사이트에서 책 구절을 몇 문장 정도 긁어와서 뿌려주고,
그 구절을 Paraphrase(또는 요약)해서 저장할 수 있는 기능이 메인이다.

스크래핑(크롤링)을 해보고 싶기도 했고, 내가 보고 쓰기에 재밌는 걸 만들고 싶었다.
(이것저것 기획만 머릿속으로 2주 정도 하다가 겨우 골랐다.)
NoSQL을 써보고 싶기도 했다.

아직 데이터 뿌려주는 것까지만 되어 있다. 새로고침을 하면 데이터 목록이 바뀐다.

프론트엔드 해본 지가 너무 오래 돼서… 리액트로 부트스트래핑하고 초기 리렌더링 방지하는 것도 꽤나 버벅댔다.

물론 서버도… 현재의 라우터랑 플러그인 구조로 바꾸기 전에 몇 번 다른 방식으로 짜봤다.

Node.js와 Fastify는 회사에서 써본 것들이지만, 익숙한 방식대로 뼈대를 만들다가 좀 석연치 않은 부분들이 있어서 공식 문서와 깃헙 등을 찾아봤다.

(초기 설계를 새로 해볼 수 있다는 게 개인 프로젝트의 장점이니까..
그리고 내가 회사에서 못해본 걸 퇴사했을 때 해야한다고도 생각했다.)

보다보니 Fastify의 메인테이너 중 한 명이 운영하는 fastify-example이라는 레포를 발견..
fastify로 작성된 best practice를 보여주기 위해 만든 작은 URL shortener 애플리케이션이었다.

이 프로젝트는 plugins, routes라는 두 개의 최상위 폴더를 갖고 있는데,
플러그인에는 인증 같은 앱 전체에서 공유하는 모듈이, 라우트에는 라우팅을 포함한 모든 비즈니스 로직이 포함된다.

(물론 컨트롤러, 서비스 등의 레이어가 나누어져 있지 않지만, 작은 프로젝트이기도 하고 이런 아키텍처는 fastify에만 국한된 것이 아니기에 굳이 필요없었던 듯하다.)

다소 오래된 코드고 javascript로 되어있긴 하지만, fastify 설계 철학을 보기엔 충분했다.
내가 써왔던 fastify 프레임워크의 사용법과는 다른 부분이 좀 있었다.
디렉토리 구조부터, 다양한 fastify 생태계의 라이브러리를 활용하는 것까지.

프레임워크에 너무 의존적인 코드도 안 좋다고는 하지만,
그렇다고 express와 fastify를 차이 없이 쓰는 것도 좀 이상한 것 같다.

무엇보다 프레임워크의 철학과 핵심 개념을 알수록 한계나 오류 또한 인지하고 대비할 수 있는 것일테니..
해당 프레임워크의 라이프사이클과 특수한 기능을 아는 것은 확실히 도움이 되는 것 같다.

상기 프로젝트의 주석을 보다가 좀 무릎을 친 부분이 있다.

One of the unwritten core principles with Fastify is "keep things boring",
it will help you keep the complexity low,
scale well in heterogeneous teams and lower the barrier of entry.
...(중략)...
Why we designed Fastify in this way? Because boring things are predictable.

Fastify의 비공식 핵심 원칙 중 하나는 "지루함"이에요.
복잡성을 낮추고, 이질적인 팀에서 코드에 대한 진입 장벽을 낮추어 확장하는 데 도움이 되거든요.

왜 이런 식으로 디자인했냐고요? 지루한 것은 예측 가능하기 때문이죠.

대충 이 정도로 번역할 수 있겠다.

지루한 것은 예측 가능하다.
예측 가능한 것은 이해하기 쉽다.
이해하기 쉬운 것은 고치기(만들기) 쉽다.

이 얼마나.. 아름다운.. 순환인지?

내 작고 소중하고 하찮은 사이드 프로젝트도 지루해서 예측 가능하고, 이해하기 쉽고, 고치기 쉽도록 만들고 싶다.

혹시 또 모르잖아.. 나 말고 사용자.. 있을지도^^