안녕하세요, 토스 클라이언트 엔지니어링 헤드 박서진, 프론트엔드 플랫폼 엔지니어 박성범입니다.

토스 서비스는 어떻게 개발되고 있을까?

토스에서는 100명이 넘는 프론트엔드 엔지니어들이 토스앱 안과 밖의 제품들을 개발하면서, 하루에 수백 번 제품을 업데이트 해가고 있어요.

제품의 숫자가 많고 종류도 다양하지만, 핵심적인 개발환경은 동일하게 유지하고 있습니다. 구체적으로는 아무리 오래된 제품이라고 하더라도 모두 최신 버전에 가까운, 동일한 버전의 React 19와 Next.js 15을 사용하고 있어요. 덕분에 사용자들은 React Concurrent Mode 및 React Server Components와 같은 최신 기능을 사용하며 좋은 경험을 하고 있죠.

동일한 버전의 라이브러리를 사용하고 있기 때문에, 여러 서비스 간 코드 공유도 무척 쉬워요. 토스앱 전체에 걸쳐서 영향을 미치는 라이브러리를 개발하고자 해도, 여러 React 버전 등을 고려할 필요 없이 쉽게 공유 코드를 만들 수 있어요.

또한 React나 Next.js 뿐만 아니라 TypeScript나 번들러, Linter 경험도 동일하게 유지하고 있어요. 구체적으로는, 모든 서비스는 빠짐없이 Go로 작성된 TypeScript 7를 사용하는 등 최신 개발환경의 사용성을 누리고 있어요.

이 모든 사용자 경험과 개발자 경험의 핵심에는 토스에서 중요하게 생각하는 ‘모노리포’가 있어요. 토스에서는 모든 모바일 제품을 개발하는 코드는 1개의 모노리포로 통합되어 있어요. 데스크톱 제품을 개발하는 코드도 비슷하고요. 모노리포를 활용하고 있기 때문에 전체 서비스의 형상을 거의 비슷하게 맞추고, 플랫폼 변경사항을 빠짐없이 편리하게 전파하고 있어요.

모노리포만으로는 모든 문제가 해결되지 않는다

그런데 모노리포를 사용한다고만 해서 이 모든 것이 가능할까요? 그렇지는 않았어요.

토스 프론트엔드는 총 인원이 5명일 때부터 모노리포를 사용해 왔지만, 100명이 넘는 인원이 되기까지 규모가 확장되며 다양한 문제를 마주해왔어요. 구체적으로는, 2025년 초 기준으로는 개발자 숫자가 지금보다 훨씬 더 적었음에도 여러 문제들이 있었어요.

먼저, 모노리포 안에서 사용되는 의존성이 매우 다양했어요. 어디는 최신 버전의 React를 쓰지만 어디는 아주 오래된 버전을 썼죠. React 뿐만이 아니라 모든 라이브러리가 이랬어요.

이러다 보니까 개발자 경험도 파편화되었어요. 어떤 서비스는 최신 버전의 새 개발환경을 사용해 개발 서버도 빨리 뜨고 쾌적하며, 최신 React API도 쓸 수 있는데, 어떤 서비스는 오래 전에 만들어졌다는 이유만으로 개발 경험이 많이 나빴어요.

의존성의 종류가 다양하다 보니, 설치에도 오랜 시간이 소요되었어요. 한 번 의존성을 설치하는 데에 이미 캐시가 있어도 1분 이상이 걸리기도 했어요.

플랫폼에서도 전체 서비스에 영향을 미치는 라이브러리를 만들기가 어려웠어요. 서비스마다 사용하는 의존성 버전이 무척 다양하다 보니까, 한 곳에서 잘 동작한다고 해서 다른 곳에서 동작한다고 보장하기 어려웠어요.

서비스를 만드는 개발자 입장에서도 플랫폼 라이브러리가 잘못 동작할 가능성이 높다 보니까 라이브러리 버전 업데이트를 꺼리게 되었어요. 업데이트 비용이 무척 높았던 것이죠. 결국 만들어진지 오래된 서비스는 낡은 의존성을 쓰는 구조가 고착화되었어요.

이렇게 서비스 개발자는 의존성 설치가 오래 걸리거나, 오래된 버전의 라이브러리를 사용해야 해서 힘들고, 플랫폼을 관리하는 개발자는 테스트 난이도가 너무 높아서 변경사항을 만들기 어려운 상태였어요.

모노리포 vs. 폴리리포

토스 프론트엔드 플랫폼 팀은 이 문제를 어떻게 해결해야 할지 고민했어요. 가장 직관적으로 바로 떠오르는 방법 중 하나는 큰 리포를 여러 개의 리포로 쪼개는 것이었어요. 이른바 폴리리포 전략으로 코드를 관리하는 것이죠.

이렇게 되면 각 서비스들이 완전히 독립적인 리포에서 운영되다 보니까, 각 리포지토리를 매우 가볍게 가져갈 수 있었어요. 설치 시간이 오래 걸리는 것처럼 의존성이 단순히 많아서 생기는 문제들을 해소할 수 있었어요.

그렇지만 폴리리포로 쪼개는 것으로는 모든 문제가 해결되지 않는다고 판단했어요. 오히려 대부분의 문제는 그대로 남았어요. 예를 들어 각 서비스마다 개발환경이 파편화된 문제는 여전히 남았어요. 그래서 서비스마다 개발 경험이 다르고, 공통 코드를 만들거나 업데이트하는 비용이 비싼 문제는 지속될 것으로 보였어요. 그리고 오히려 폴리리포이기 때문에 파편화의 문제가 더 심해질 것으로 보였어요.

이에 토스 프론트엔드 플랫폼은 프론트엔드 개발자들의 개발 경험을 책임지는 팀으로서, 앞으로 지속적으로 플랫폼을 유지보수해가며 업데이트하기 위해서 폴리리포는 답이 아니라고 판단했어요. 대신 기존의 모노리포의 문제점을 해소하는 기술을 도입하기로 했어요.

복잡한 의존성 트리 단순하게 하기

토스 프론트엔드 개발환경이 겪고 있는 문제는 무엇일지 골똘히 생각했어요. 생각해보니까 가장 핵심적인 문제는 ‘서비스마다 가지고 있는 의존성 버전이 모두 다르다’ 였어요.

구체적으로 이야기했을 때, 토스에서 ATM 현금 찾기를 위해서 사용하는 React 버전과, 행운복권을 뽑기 위해서 사용하는 React 버전이 달랐어요. 그리고 React 버전만 다른 것이 아니었어요.

일반적으로 개발하기 위해서 사용하는 라이브러리는 무척 다양해요. Shadcn(토스에서는 TDS)처럼 컴포넌트 라이브러리도 있고, Jotai처럼 상태 관리를 하기 위해서 쓰는 라이브러리도 있고, TypeScript나 ESLint처럼 코드를 안정적으로 유지하기 위해서 쓰는 라이브러리도 있어요. 계산해 보니까 이런 라이브러리가 토스에서 10~20개 정도는 있었어요. 서비스에서 선택할 수 있는 라이브러리나 버전이 너무 많다 보니까 파편화가 될 수밖에 없는 구조였어요. 여기에서 모든 문제가 생겼어요.

그런데 만약에 서비스가 사용하는 핵심 의존성이 모두 같다면 어떨까요? 예를 들어 React, Shadcn 등의 라이브러리 버전을 거의 맞출 수 있다면 앞서서 겪은 문제를 많이 해결할 수 있을 것 같았어요.

• 모든 서비스가 거의 같은 의존성 버전을 사용하고 있기 때문에, 설치 시간도 크게 단축되고,
• 어떤 서비스이든지 거의 같은 개발자 경험을 제공하고, 이 API를 쓸 수 있는지/없는지를 고민할 필요가 없게 돼요.
• 플랫폼 개발자들이 공통 코드를 만들거나 변경해야 할 때도, 테스트해야 하는 환경(React 버전 등)이 정해져 있다 보니까 테스트 난이도가 낮아져요. 그래서 훨씬 꼼꼼히 테스트할 수 있게 돼요.
• 서비스의 플랫폼 라이브러리 버전을 업데이트하는 경로가 거의 동일하기 때문에, 플랫폼에서 업데이트를 돕는 도구를 만들어서 제공할 수 있어요. 그래서 라이브러리에 하위호환성을 깨뜨리는 파괴적 변경(Breaking changes)이 있더라도 자동으로 기존 코드를 변환해주는 스크립트나 호환성 레이어를 항상 제공해서 업데이트 난이도를 낮출 수 있어요.
• 서비스 개발자도 꼼꼼히 테스트된 플랫폼 라이브러리로 손쉽게 업데이트하는 것이기 때문에 업데이트 비용이 낮아지고, 더 높은 생산성과 좋은 사용자 경험을 제공하는 플랫폼 라이브러리로 업데이트할 유인이 커져요.

처음에는 ‘서비스에서 사용하는 라이브러리 버전을 정말 통일해도 괜찮을까?’ 라고 걱정이 들기도 했어요. 그런데 실제로 서비스를 만드는 개발자를 관찰했을 때, 대부분은 ‘React가 필요하다’, ‘Jotai가 필요하다’ 와 같은 의사결정은 해도, 구체적인 버전을 지정해서 필요한 경우는 거의 없었어요.

그래서 프론트엔드 플랫폼에서는 서비스 개발자들이 사용하는 표준 라이브러리 버전을 제공해보기로 했어요.

카탈로그

토스 프론트엔드 플랫폼에서는 모든 서비스에서 사용하기를 권장하는 표준 라이브러리 버전들을 ‘카탈로그(Catalog)’ 로 부르기로 했어요. 마침 pnpm, Yarn 같은 패키지 매니저에서 모노리포에서 표준 라이브러리 버전을 제공하는 버전을 카탈로그라고 하는 이름의 기능으로 제공하고 있었어요.

카탈로그란?

카탈로그란, 다음과 같이 모노리포의 pnpm-workspace.yml (또는 .yarnrc.yml) 파일에 정의한 라이브러리 버전을 말해요.

이렇게 카탈로그를 정의하면, 모노리포 안에 있는 서비스는 catalog: 프로토콜을 활용해서 그 라이브러리 버전을 참조할 수 있어요.

이후 패키지 매니저는 이미 정의되어 있는 카탈로그 버전에 따라서 자동으로 의존성 버전을 찾아 설치해 줘요.

카탈로그에 이름을 붙일 수도 있어요. 예를 들어 안정적인 카탈로그 stable 과, 실험적인 카탈로그 beta 를 만들고 싶다고 한다면, 다음과 같이 카탈로그를 정의해요.

그러면 서비스에서는 catalog: 프로토콜에 이름을 붙여서 정의된 카탈로그를 참조할 수 있어요.

토스에서는 서비스에서 주로 사용하는 핵심 라이브러리들을 카탈로그로 정의하기로 했어요. React, Next.js, TypeScript, TDS나 토스 앱 SDK처럼 서비스를 개발하는 데에 필수적으로 사용해야 하는 라이브러리들부터 시작했어요.

카탈로그에 편입된 라이브러리들에 대해서는 대부분의 주요 케이스에 대해서 테스트 페이지를 작성하고, 수정하고 릴리즈하기 전에 꼼꼼히 테스트했어요.

이후 서비스에서 라이브러리를 설치할 때는 카탈로그를 사용하는 것을 기본값으로 가져가기로 했어요. 새로운 서비스가 모노리포에서 스캐폴딩되면 라이브러리들이 최신 카탈로그를 참조하도록 했어요. 또한, 이후 서비스에서 yarn add 로 직접 의존성을 설치해도, 최신 버전이 아니라 현재 서비스에서 사용하고 있는 카탈로그를 참조하도록 했어요. 혹시라도 카탈로그에 편입된 라이브러리인데 실수로 카탈로그를 사용하지 않을 수 있도록 CI에서 자동으로 실수를 잡을 수 있도록 했어요.

이미 있는 서비스들을 카탈로그로 마이그레이션하는 작업도 필요했어요. 이 과정이 제일 어려웠지만, 서비스의 코드 오너 분들과 힘을 합쳐서 오프라인으로 모여서 꼼꼼히 동작을 체크하면서 라이브러리 버전이 모두 카탈로그를 참조하게끔 했어요. 이렇게 하니까 모든 서비스 코드들이 모두 카탈로그 버전을 참조하게 되었어요.

이후 지속적으로 새로운 버전의 카탈로그를 발행하는 것도 필요했어요. 예를 들어 Next.js의 메이저 버전을 업데이트하거나, Go 언어로 재작성된 TypeScript를 사용하게 되는 등의 변화를 만들어야 했어요.

모든 서비스가 카탈로그를 참조하고 있기에, 카탈로그에 이미 정의된 라이브러리 버전을 바꾸는 것은 위험했어요. 수정사항이 필요하면 항상 새로운 카탈로그 버전을 만들고, 일부 서비스들에서 먼저 테스트하도록 했어요. 이후 안정성이 확인되면 서비스들이 새로운 카탈로그 버전으로 수동 마이그레이션하도록 했어요.

카탈로그 업데이트의 비용을 줄이기 위해 손쉬운 업그레이드를 위한 코드 수정 스크립트 및 AI Skill을 만들고 배포했어요. 그래서 이전 버전을 사용하고 있는 서비스들도 쉽게 업데이트할 수 있도록 했어요.

이렇게 하니까 모든 서비스가 거의 비슷한 버전의 라이브러리 세트를 사용하고, 지속적으로 큰 노력을 들이지 않아도 라이브러리 버전을 최신화할 수 있는 환경이 마련되었어요.

카탈로그 100% 적용, 그 후

모든 서비스가 카탈로그를 통해 의존성을 사용하도록 마이그레이션을 마친 뒤, 모노리포에 많은 변화가 생겼어요. 서비스 모노리포에 카탈로그를 도입함으로써 얻은 효과는 크게 네 가지였어요.

첫 번째, 모노리포에서 설치해야 하는 의존성의 개수가 줄었어요. 모노리포에 서비스가 늘어나면 자연스럽게 설치해야 하는 의존성의 종류와 개수도 크게 증가하곤 해요. 문제의 원인은 여러 서비스가 같은 의존성을 사용하는 경우에도 통일되지 않은 버전을 사용하기 때문에 결과적으로 전체 의존성의 개수가 크게 늘어나기 때문이었어요.

카탈로그로 서비스에서 사용하는 의존성의 버전과 종류를 통일함으로써 의존성의 개수를 물리적으로 줄일 수 있었어요. 카탈로그 적용 전에는 패키지 매니저 Yarn PnP(Plug’n’Play)가 의존성의 정보를 기록해두는 .pnp.cjs 파일의 크기가 96MB였는데, 적용 후에는 15MB로 약 84% 절감되었어요. 또한 서비스의 개발 서버 실행 속도도 26.7초에서 20.3초로 약 23% 개선되었고, 모노리포 전체 의존성 설치에 소요되는 시간은 528.4초에서 249.9초로 약 52% 줄었어요.

두 번째, 의존성을 믿고 사용할 수 있게 되었어요. 카탈로그로 관리하는 패키지는 릴리즈 전에 적어도 한 개 이상의 서비스에서 동작을 검증해야 한다는 제약을 만들었어요. 덕분에 대부분의 서비스 개발자는 카탈로그에 있는 패키지는 다른 서비스에서 검증이 되었다는 신뢰를 가지고 패키지를 사용할 수 있게 되었어요.

또한 기존에는 패키지들이 서로에게 의존하는 경우 패키지 간의 의존 관계를 통제하기가 어려웠고, 이 때문에 예상치 못한 문제가 많이 발생했어요. 예를 들어 A 패키지가 B 패키지 v1 버전에 의존하는데, 개발자가 이 사실을 모르고 B 패키지 v2 버전을 사용하는 바람에 A 패키지의 잘못된 동작을 유발할 수 있었어요. 카탈로그를 이용하면 패키지 버전을 엄격히 관리하고, 플랫폼 팀이 카탈로그에 포함된 패키지간 의존 관계의 무결성을 검증함으로써 이러한 불일치를 예방할 수 있어요.

세 번째, 패키지 개발자가 구조적인 개선을 만들기 쉬워졌어요. 패키지 개발자와 서비스 개발자를 비롯해서 모든 개발자에게 메이저 버전을 업데이트하는 것은 너무나 두려운 일이었어요. 패키지 개발자 입장에서는 기존 아키텍처나 인터페이스를 변경했을 때 어떤 파급효과가 일어날지 예측할 수 없었고, 서비스 개발자 입장에서는 패키지를 업데이트했을 때 어떤 부작용이 일어날지 예측할 수 없었어요.

카탈로그를 적용한 이후에는 수 많은 서비스가 사용하는 패키지의 종류와 버전이 통일되었고, 어떤 서비스가 어떤 버전의 패키지를 사용하는지 훨씬 쉽게 파악할 수 있게 되었어요. 모노리포 전반에서 의존성에 대한 가시성이 확보되면서 패키지 개발자가 적극적으로 구조적인 개선을 추진하고, 기존 인터페이스를 개편할 수 있게 되었어요. 덕분에 지난 하반기 토스 프론트엔드 챕터는 RSC와 TypeScript 7, Rspack, E2E 테스트 등 급진적인 개선을 빠른 기간에 안정적으로 시도할 수 있었어요.

네 번째, 서비스가 최신 플랫폼의 혜택을 빠르게 받아 볼 수 있게 되었어요. 플랫폼에서 패키지를 개선해도 서비스에서 사용하지 않는다면 의미있는 변화를 만들어낼 수 없을거예요. 기존에는 패키지 개발자가 자신의 패키지에서 사용하는 Next.js의 메이저 버전을 업그레이드 하면 서비스에서 사용하는 다른 의존성들이 이 패키지의 변경사항으로 인해 어떤 문제를 일으킬지 파악하기가 너무나 어려웠어요. 설령 성공적으로 Next.js의 메이저 버전을 업그레이드해서 패키지를 릴리즈해도 서비스 개발자가 이 패키지를 사용하려면 더 큰 위험을 감수해야 하기 때문에 이러한 업그레이드를 잘 전파할 수도 없었어요.

카탈로그를 적용한 덕분에 쉽게 패키지를 수 많은 서비스에 쉽게 전파할 수 있었어요. 카탈로그를 확인하면 이 모노리포에서 어떤 패키지가 주로 사용되고 있는지 알 수 있고, 어떤 서비스가 어떤 버전을 사용하고 있는지도 어렵지 않게 추적할 수 있어요. 이렇게 확보한 가시성을 바탕으로 플랫폼 팀이 카탈로그에 포함된 패키지의 안정성을 꼼꼼히 검증하고 있기 때문에 서비스 개발자 입장에서 의존성을 업데이트하는 것이 더 이상 위험하지 않은 일이 되었어요. 또한 패키지 개발자 입장에서도 새로운 메이저 버전을 릴리즈한 뒤 카탈로그에 명시된 버전만 변경하면 모든 서비스가 새 버전을 사용하게 되기 때문에 릴리즈 전파가 쉬워졌어요. 이제는 모노레포의 모든 서비스들이 카탈로그를 통해 플랫폼이 제공하는 혜택을 빠르게 받아보고, TypeScript 7, Rspack 등 프론트엔드 생태계의 최신 기술을 어렵지 않게 도입할 수 있게 되었어요. 뿐만 아니라 공급망 공격으로 Third-party 패키지에서 보안 문제가 발생했을 때에도 패치 버전을 카탈로그에 적용해 신속히 대응할 수 있었어요.

실제로 토스가 카탈로그를 운영하는 방법

토스 프론트엔드 챕터는 기술적으로 카탈로그를 도입하는 것을 넘어서, 카탈로그 위에 토스의 모노리포에 적합한 운영 정책을 만드는 데에도 많은 노력을 기울였어요.

토스의 모노레포에서는 여러 카탈로그를 버저닝해 사용하고 있어요. 그래서 카탈로그의 이름에는 해당 카탈로그를 발행한 연도와 월이 포함되어 있어요.

한 번 버전을 붙여 발행한 카탈로그에서 어떤 패키지의 버전을 변경할 때는 절대로 파괴적 변경을 포함해서는 안 된다는 제약이 있어요. 만약 이미 발행된 카탈로그에서 패키지의 버전을 함부로 1.0.0에서 2.0.0으로 업그레이드한다면 해당 카탈로그를 사용하는 서비스들은 원치 않게 의존성의 버전을 업그레이드한 셈이 되어버리고, 예상치 못하게 파괴적 변경에 대응해야 할거예요.

기존에 발행한 카탈로그에서 어떤 패키지의 버전을 변경할 때 파괴적 변경이 있어서 메이저 버전을 업데이트해야 한다면 새로운 카탈로그를 발행해야 해요. 서비스가 파괴적 변경을 너무 자주 겪지 않도록 새 카탈로그는 한 달에 최대 한 번만 발행하도록 제한하고 있어요. 카탈로그를 발행하기 전, 사내 패키지 메인테이너들은 매월 초 한 번씩 모여 예정된 변경 사항을 논의해요. 만약 하나 이상의 패키지에 파괴적 변경이 있다면 이번 달에 새로운 카탈로그를 발행하고, 파괴적 변경에 대응해 자동으로 코드를 변환해주는 스크립트를 작성해요.

개발자 입장에서는 서비스의 카탈로그 버전을 stable-26.07에서 stable-26.08로 업그레이드할 때 파괴적 변경의 가능성을 직관적으로 알 수 있어요. 또한 두 카탈로그 사이에 파괴적 변경이 있어도 항상 자동으로 코드를 변환해주는 스크립트를 제공하기 때문에 어렵지 않게 새로운 카탈로그로 업그레이드할 수 있어요.

한 발 더 나아가서 카탈로그 운영 정책을 코드로 관리하고, 자동화하기 위해 토스는 자체적인 Yarn 플러그인과 CLI 도구를 개발해 사용하고 있어요. 예를 들어 다음과 같은 명령을 실행하면 자동으로 서비스가 사용하는 카탈로그를 stable-26.08로 변경하고, 코드를 마이그레이션할 수 있어요.

모노리포 전체에서 일관된 카탈로그 정책을 전파하기 위해 만든 Yarn 플러그인 yarn-plugin-catalogs는 기본적인 카탈로그 동작 위에 다양한 확장 기능을 제공해요. 예를 들어 TypeScript 7.0.0 버전을 사용하는 stable-26.07 카탈로그를 기반으로 일부 서비스에서 TypeScript 7.0.2-rc 버전을 미리 사용해보고 싶다면 stable-26.07/canary 카탈로그를 발행하면 돼요. 아래와 같이 catalogs.yml 파일에 플러그인이 제공하는 확장 문법으로 카탈로그를 정의하고 yarn catalogs apply 명령을 실행하면 yarnrc.yml 파일에 Yarn 공식 카탈로그 문법으로 자동 변환할 수 있어요.

뿐만 아니라 모노리포의 특정 워크스페이스에서 카탈로그를 반드시 사용하도록 강제하거나, 사용하지 못하도록 제한할 수도 있어요. 플러그인이 제공하는 기능은 모두 대규모 모노리포 전반에서 플랫폼 정책을 시행, 전파하기 위한 것들이에요.

서비스 모노리포에 카탈로그가 자리 잡은 뒤에는 카탈로그를 더욱 안정적으로 운영하기 위해 사내 패키지들을 하나의 모노리포에 통합하기도 했어요. 서비스가 모노리포에 모여있던 것과 달리 사내 패키지는 폴리리포로 여기저기에 흩어져 있었어요. 그렇다보니 사내에 어떤 패키지가 있는지, 그 패키지가 잘 관리되는지, 누가 패키지를 관리하는지 파악하는 것이 항상 어려웠어요. 그래서 흩어져 있던 사내 패키지들을 하나씩 모아서 패키지 모노리포를 만들었어요. 패키지 모노리포에는 패키지의 매니페스트와 설정을 검사하는 패키지 린트 도구, PR에 파괴적 변경이 포함되어 있으면 메이저 버전 업데이트를 권고하는 검사기 등 패키지 개발을 위해 플랫폼 팀이 만든 각종 도구와 E2E 테스트 환경, 릴리즈 워크플로우가 모두 갖춰져 있어요. 카탈로그에 포함된 패키지를 모노리포에서 관리함으로써 의존성의 예측 가능성과 가시성을 높인다는 카탈로그의 취지와 효과를 극대화할 수 있었어요.

마무리

카탈로그 적용 전 모노리포에서 겪는 문제의 근원은 모노리포라는 구조 자체보다는 일관된 정책과 기능을 광범위하게 전파할 방법이 마땅치 않았고, 서비스가 모노리포 안에 있어도 충분히 가시성을 확보하지 못해 개발 환경을 예측할 수 없다는 데 있었어요. 이런 문제는 모노리포를 쪼개도 해결할 수 없는 문제였어요.

그래서 토스 프론트엔드 플랫폼 팀은 모노리포를 지키면서 개발 환경의 파편화를 해결하는 길을 택했고, 그 방법이 카탈로그였어요. 모든 서비스가 표준 라이브러리 버전을 참조하게 되자 의존성의 종류와 개수가 물리적으로 줄어 개발 환경의 성능이 개선되었고, 카탈로그의 가시성을 바탕으로 플래폼 팀이 검증한 패키지를 신뢰할 수 있게 되었어요. 서비스 개발자는 최신 플랫폼의 혜택을 빠르고 안전하게 누릴 수 있게 되었고, 패키지 개발자는 두려움 없이 구조적인 패키지를 개편해 전파할 수 있게 되었어요.

물론 카탈로그라는 기능을 도입한 것만으로 변화가 만들어진 것은 아니에요. 한 달에 한 번씩 카탈로그를 발행하는 버저닝 정책, 정책을 코드로 강제하는 개발 도구, 패키지 개발자들이 변경 사항을 공유하는 정기 미팅과 패키지 모노리포까지, 토스의 카탈로그는 기술 위에 운영을 쌓아 올린 1년이 있었기에 가능했어요.

그 결과 100명이 넘는 프론트엔드 개발자가 하루에 수백 번씩 제품을 배포하면서도 모두가 동일한 최신 개발 환경을 누릴 수 있게 되었어요. 만약 대규모 모노리포에서 문제를 겪고 있다면 폴리리포로 전환하기 전에 현재 겪고 있는 문제를 명확히 정의해보세요. 모노리포의 강력한 장점을 포기하지 않으면서도 문제를 해결할 수 있을거예요.