리뷰는 끝이 아니라 대화의 시작입니다

Meta 개발 문화에서 배운 것, 우리가 실천할 수 있는 것

by 오유나

Apr 17. 2025

이 글은 Pragmatic Engineer 뉴스레터 – Stacked Diffs and Tooling at Meta를 바탕으로,
제가 느낀 인사이트와 실천할 수 있는 방법을 정리해 본 글입니다.

개발자라면 누구나 한 번쯤은 “다른 회사들은 어떤 식으로 개발할까?”라는 궁금증을 가져본 적이 있을 것입니다.

특히 대형 테크 기업들이 어떻게 빠르게 개발하고, 수많은 개발자들이 어떻게 충돌 없이 협업하는지에 대한 궁금증은 저에게 꽤 오래된 주제이기도 합니다.

이번 뉴스레터는 Meta의 전직 개발자이자 현재 Graphite 공동 창업자인 Thomas Rainer와의 인터뷰를 통해,

Meta 내부의 코드 리뷰 방식, CI/CD, 배포 흐름, 그리고 개발자의 생산성을 높이기 위한 다양한 툴과 문화적 선택들을 깊이 있게 다뤘습니다.

그리고 무엇보다 흥미로웠던 점은
“우리는 Meta처럼 거대한 도구를 가질 수는 없지만, 그들의 철학과 관점을 가져올 수는 있다”는 사실이었습니다.

Meta는 ‘도구’보다 ‘연결’을 만들었다

Meta에서는 PR이라는 용어 대신 Diff라는 단어를 사용합니다.

이는 리뷰 요청이 아니라, 변경 자체에 집중한 언어입니다.

그리고 그 변경은 단순히 코드 몇 줄의 차이가 아니라,

CI(Build), 배포 상태, 실험 결과, 번역 여부, 기능 플래그 활성화 등 시스템 전반과 연결된 정보의 흐름으로 구성됩니다.

Fabricator라는 내부 코드 리뷰 도구는 Sandcastle(내부 CI), OnDemand(개발 환경), Landcastle(배포 도구)와 자연스럽게 연결되어 있습니다.
한 줄의 코드가 시스템 전체에서 어떤 영향을 미치는지, 개발자는 하나의 UI에서 실시간으로 확인할 수 있습니다.

이런 통합 환경은 말 그대로 ‘코드 리뷰가 끝이 아니라 시작’인 구조입니다.
배포 이후 기능이 어떤 영향을 주는지, 실험 결과가 어떤지, 번역은 완료되었는지까지 함께 보는 리뷰 흐름은
우리가 흔히 겪는 “승인만 해주는 리뷰”와는 전혀 다른 차원의 일입니다.

스택 디프(Stacked Diffs)는 단순한 기능이 아니라,

더 나은 협업을 위한 사고방식이다

Meta에서 널리 사용되는 개발 방식 중 하나는 바로 스택 디프(또는 Stack PR)입니다.
여러 개의 작은 변경사항을 순차적으로 브랜치로 나누고,
앞선 변경이 머지되지 않았더라도 그 위에 계속해서 기능을 쌓아가며 리뷰를 받는 방식입니다.

이 방식의 가장 큰 장점은,
“작게 쪼개고, 병렬로 리뷰를 받고, 개발자는 기다리지 않고 다음 작업으로 넘어갈 수 있다”는 점입니다.
일반적인 개발 흐름에서는 리뷰가 끝날 때까지 기다리거나, 모든 기능을 한꺼번에 올리는 선택을 하게 됩니다.

하지만 스택 디프는 리뷰 병목을 줄이고, 코드의 맥락을 명확히 나눠줄 수 있어 리뷰어에게도 훨씬 부담이 적은 구조입니다.

저는 개인적으로 이 방식이 개발자에게 ‘심리적인 자유’를 준다고 생각합니다.
기능 하나를 완성해야만 다음으로 넘어갈 수 있는 압박감 대신,
“여기까진 정리됐고, 다음은 이 흐름을 바탕으로 확장해 보겠습니다”라는 식의 유연한 개발이 가능해집니다.

하지만 우리가 Fabricator를 쓸 수는 없다

그렇다면 무엇을 가져올 수 있을까요?

Meta의 도구는 대부분 사내 전용입니다.
우리는 GitHub과 Slack, Jira, Notion 같은 도구들을 조합해 사용하는 구조입니다.
모노레포를 시도하는 회사도 있지만, 여전히 다수의 스타트업은 여러 개의 리포지토리를 나눠 관리하며
툴 간의 연결은 개발자들이 ‘수작업’으로 처리해야 하는 상황입니다.