2022년쯤 한국 프론트엔드 커뮤니티에서 가장 뜨거웠던 주제가 Yarn Berry였다. PnP로 node_modules를 없애고, Zero-Install로 CI를 날렵하게 만들고, 유령 의존성(ghost dependency)을 원천 차단한다. 기술 블로그마다 도입기가 올라왔고, 컨퍼런스 발표 슬롯도 꿰찼다. 그런데 2024년 하반기부터 분위기가 바뀌기 시작했다. AB180, 원티드랩, 카카오페이, SK 계열사 — 하나둘 "우리는 pnpm으로 갈아탔습니다" 포스트가 올라온다. 무슨 일이 있었나.
PnP가 현실을 만났을 때
Yarn Berry의 PnP는 기술적으로 우아한 접근이었다. node_modules 평탄화(hoisting)의 근본 문제를 해결하고, .pnp.cjs 하나로 의존성 해석을 처리한다. 이론상 완벽하다. 문제는 이 우아함이 실무 팀에 부과하는 세금이었다.
AB180의 Airbridge 사례가 적나라하다. PnP 모드에서 .yarn/cache에 압축된 패키지 파일들이 Git에 누적된다. 커밋 1만 개가 넘는 레포에서 바이너리 포함 패키지가 계속 쌓이면 .git/objects가 뚱뚱해지고, checkout이나 브랜치 전환이 체감될 정도로 느려진다. Zero-Install의 장점 — "clone하면 바로 실행" — 을 위해 Git 자체가 무거워지는 역설이 발생한 것이다.
호환성 벽도 높았다. PnP에서는 require.resolve를 직접 호출하는 라이브러리가 깨진다. 대부분은 패치로 해결할 수 있지만, "대부분"이 아닌 나머지가 금요일 오후의 온콜 티켓이 됐다. nodeLinker: node-modules 폴백을 쓰는 팀이 하나둘 늘어갔고, 그 시점에서 PnP를 쓰는 이유의 절반이 증발한다. 엄격한 의존성 관리를 위해 PnP를 도입했는데, 호환성 때문에 엄격함을 포기하면 뭐가 남나.
AB180은 여기에 모노레포 워크스페이스 문제까지 겪었다. Yarn Berry의 플러그인 시스템 버그, 패키지 간 의존성 중복 저장, 설치 시간 증가. 결국 세 가지 이유를 들어 pnpm으로 전환했고, 패키지 설치 시간이 30초에서 1분 줄었다고 보고했다.
pnpm은 왜 먹히나
짧게 말하면 "기존 규칙을 안 깨서"다.
pnpm의 content-addressable storage는 패키지를 글로벌 저장소에 한 번 저장하고 심볼릭 링크로 연결한다. node_modules 구조를 유지하면서 디스크를 아끼고, 명시적으로 선언하지 않은 의존성은 접근 불가하게 만든다. Yarn Berry PnP처럼 생태계 전체에 새로운 해석 규칙을 요구하지 않는다. 기존의 바닥 위에서 효율만 올리는 접근이다. 원티드랩은 Yarn Classic에서 pnpm + TurboRepo 조합으로 넘어갔고, 마이그레이션에 특별한 고통은 없었다고 쓰고 있다. 그게 핵심이다 — pnpm 전환은 대부분 30분이면 끝난다.
토스만 Yarn Berry를 잡고 있는 이유
여기서 흥미로운 건 토스의 선택이다. 한국 프론트엔드 생태계의 pnpm 수렴 속에서 토스는 Yarn Berry를 고수하고 있다. 고수할 뿐 아니라 자체 플러그인을 여러 개 만들어 쓰고 있다.
토스가 Yarn Berry에 남는 논리는 명확하다. Resolution, Fetch, Link 단계가 깔끔하게 분리된 모듈화 아키텍처. PnP의 엄격성이 대규모 모노레포에서 보장하는 안정성. 플러그인으로 확장 가능한 구조. 이 세 가지를 SLASH 컨퍼런스에서 직접 꺼내 설명했다.
여기서 놓치면 안 되는 맥락이 있다. 토스 규모의 조직이라면 PnP 호환성 이슈를 내부에서 패치할 여력이 있다. "이 라이브러리 PnP에서 안 돌아요"를 플러그인 하나 짜서 해결하는 게 가능하다. 프론트엔드 엔지니어 수십 명이 하나의 모노레포를 관리하는 환경과, 3~5명이 여러 서비스를 굴리는 스타트업은 같은 도구를 써도 경험이 완전히 다르다.
다만 토스도 Zero-Install은 끄는 방향으로 전환 중이다. AB180이 부딪힌 Git 비대화 문제를 토스 역시 인식하고 있다는 뜻이다. Yarn Berry의 철학은 유지하되, 가장 논란이 됐던 Zero-Install은 내려놓은 셈이다.
이 흐름에서 읽히는 것
패키지 매니저 전환 자체는 사소해 보인다. 하지만 이 대이동이 보여주는 건 한국 프론트엔드 생태계의 의사결정 기준이 바뀌었다는 점이다.
2022년에는 "새로운 패러다임이니 도입하자"가 통했다. 2026년의 기조는 다르다. "우리 팀 규모에서 유지보수 비용이 얼마인가"가 먼저 나온다. AB180은 블로그에서 "1년 써보니 후회 없다"고 쓰지, "pnpm이 기술적으로 우월하다"고 쓰지 않는다. 원티드도 "TurboRepo와 궁합"을 말하지, "Yarn의 한계"를 디스하지 않는다. 도구를 팀의 현실에 맞추는 실용주의. pnpm이 "최고의 도구"가 아니라 "적정 기술"로 선택되고 있다는 게, 어쩌면 이 생태계가 성숙해졌다는 가장 확실한 신호다.