엔지니어링 전략 수립

22장 Stripe의 개발자, API 및 고객 확보 전략

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

2010년대 초고속 성장 기업들은 빠른 확장으로 인한 기술적 복잡성에 압도되지 않고 빠르게 성장하는 비즈니스 운영의 제약과 균형을 맞추기 위해 여러 가지 기법 을 채택했습니다. 한 가지 일반적인 기법은 모놀리스를 분해하는 것이었고, 다른 기법은 부족한 기능을 가진 기존 회사를 인수하는 것이었습니다. 두 가지 방법 모두 개념적으로는 간단하지만 많은 채택 기업에서 실패로 돌아갔습니다.

이 장에서는 그 시기에 직면했던 세 가지 특정 문제에 대한 Stripe의 다소 비정형적인 접근 방식에 초점을 맞춥니다: API 사용 중단, 대규모 모놀리식 코드베이스 관리, 인덱스 수집 통합입니다. 예를 들어, Stripe는 엔지니어 수가 3,000명을 넘어서면서 성장하는 동안 모놀리식 Ruby 코드베이스를 분해하지 않고 중앙 집중식 코드베이스를 고수했습니다. 2025년에도 Stripe은 정적 유형 언어로 마이그레이션하거나 고립된 코드베이스로 분해하는 대신 Sorbet 정적 유형 검사기를 만드는 등의 기술에 의존해 왔습니다.

이 문서들은 전략에서 세부 사항이 얼마나 중요한지, 즉 다른 곳에서 이러한 접근 방식을 채택했다면 일관되게 작동하지 않았을 것이라는 점과 지속적인 전략의 가치를 보여주는 특별한 증거입니다. 이러한 전략이 1~2년만 지속되었다면 그 영향력은 거의 대부분 약화되었을 것이지만, 10년 동안 꾸준히 적용되면서 그 효과는 놀랍습니다.

이 문서 읽기

이 장의 문서는 다음과 같습니다:

문서 22-1: Stripe는 API를 어떻게 폐기해야 하나요?

Stripe은 Sorbet 타이퍼 프로젝트를 만든 것 등으로 널리 인정받고 있지만, 개인적으로 가장 흥미로운 전략은 API 안정성을 상당히 우선시하려는 의지가 가장 미묘한 부분이라고 생각합니다. 이 전략은 외부에서는 거의 보이지 않습니다. 내부적으로도 이에 대한 논의가 빈번하고 상세하게 이루어졌지만, 대부분 API 설계에 관한 논의에 국한되어 있었습니다. API 안정성은 단순한 기술 설계상의 문제가 아니라 API 중심 비즈니스에서 가장 기본적인 결정이며, Stripe의 비즈니스 성공의 숨은 공로자 중 하나라고 생각합니다.

문서 22-2: API 사용 중단의 시스템 모델

사용 중단과 이탈의 상관관계를 파악할 수 있는 내부 데이터가 있었지만, 이 경우 상관관계와 인과관계가 일치한다고 판단할 수 있도록 이 모델을 구축했습니다. 이 모델의 전체 구현은 GitHub에서 확인할 수 있습니다.

문서 22-3: Stripe는 왜 소르베를 구축했을까요?

이 전략은 Stripe 이 그토록 오랫동안 분해를 지연하기로 선택한 이유와 제품 인프라 팀이 빠른 채용으로 인해 평균 재직 기간이 짧은 대규모 소프트웨어 엔지니어링 팀이 관리하는 대규모 Ruby 코드베이스의 문제를 해결하기 위해 개발자 생산성에 투자한 방법을 설명합니다. ...