회사에 RFC를 던지기 전에, 나는 주말에 먼저 만들어본다

Module Federation을 사내에 도입하자는 RFC를 쓰기 전, 나는 주말에 mfp라는 학습 레포부터 만들었다. 회사 코드였다면 팀 컨벤션 합의, 다른 팀원 학습 비용, production 안전성 검증, 배포 파이프라인 호환까지 — 라이브러리 하나 추가에 RFC와 논의로 3주가 걸린다. 합당한 가드레일이지만, "이게 우리한테 맞는지"를 모르는 채로 그 3주를 시작할 수는 없었다.

그래서 먼저 만들어봤다. 학습 레포는 가드레일이 0이다. production에 안 나가니 안전성 검증도, 컨벤션 결정도 필요 없다. 주말 하나를 들여 module loader를 직접 짜보니, 문서엔 안 나오는 한계와 함정이 손에 잡혔다. 그 경험을 근거로 쓴 RFC는 짧았고, 팀은 "왜 우리한테 적용하나"라는 질문에 막히지 않았다. 실제로 만져본 사람만이 trade-off를 설명할 수 있다.

이게 내가 반복적으로 쓰는 방식이다. 주말에 spike하고, 한계를 파악하고, 회사 코드에서 작은 적용 자리를 찾고, 짧은 RFC로 합의를 받는다. 학습 레포 없이 회사에 RFC를 던지면 설득력이 비는데, 그 빈자리를 나는 주말의 손맛으로 채운다.

같은 경로로 회사에 흘러간 것들이 있다. 사이드 프로젝트에서 익숙해진 zod이 API 응답 boundary 검증으로 자연스럽게 자리잡았고, 홈레이더에서 쓰던 bottleneck rate limit 패턴은 외부 API 통합의 안정성 근거가 됐다. chalk·boxen으로 학습 레포 출력을 꾸며본 경험은 사내 CLI 도구의 UX를 손보는 데 그대로 쓰였다. 회사 코드는 안전한 일관성을 맡고, 학습 레포는 새로움을 맡는다. 둘은 짝이다.

물론 이 방식에도 빠지기 쉬운 함정이 있고, 6년간 30개 넘는 레포를 쌓아본 입장에서 몸으로 배웠다. spike는 한 주말 안에 끝낼 크기여야 한다 — "이번엔 풀스택 앱"은 한 달 뒤에도 안 끝난다. 결과물은 짧은 README와 main.js 정도면 충분하고, "완성"에 대한 강박은 학습 속도만 떨어뜨린다. 무엇보다, 시작할 때 회사 적용 자리를 하나는 정해둔다. 그러지 않으면 학습이 즐거움에서 멈추고 자산이 되지 못한다. 학습은 도구지 목적이 아니다. 그래서 분기마다 한 번, 1년 안 만진 데다 학습 가치도 없는 레포는 archive한다.

나에게 학습 레포는 회사 코드의 안전망 위에서는 만들 수 없는 것을 미리 만들어보는 곳이다. 새 기술을 회사에 들이는 가장 빠른 길은, 누가 시키기 전에 주말에 먼저 만들어보는 사람이 되는 것이었다.

관련

/notes/spike-throwaway-code — spike의 일반 패턴