Hertz의 6,000% Throughput 향상을 이끈 아키텍처
(dev.to)Hertz는 30-40년 된 레거시 시스템과 코볼 기반의 기술 스택으로 운영되며 심각한 비즈니스 위협에 직면했습니다. 3,200만 달러를 들인 액센츄어와의 디지털 전환은 실패로 끝났으나, 이후 사내 개발자가 주도하여 '강한 일관성'이 필요 없는 가격 조회 시스템에 '결과적 일관성' 아키텍처를 도입해 6,000%의 처리량 향상을 달성했습니다.
- 1Hertz는 30-40년 된 IBM AS/400 메인프레임과 COBOL 기반 레거시 시스템으로 운영되었으며, 신제품 추가 시 18번의 시스템 변경이 필요했습니다.
- 2첫 디지털 전환 시도였던 액센츄어와의 계약은 3,200만 달러의 비용을 썼음에도 실패로 끝났습니다.
- 3레거시 시스템은 초기 300 요청/초(RPS) 수준의 처리량과 1분 이상의 p90 응답 시간을 보였습니다.
- 4가격 조회 시스템에 '강한 일관성' 대신 '결과적 일관성' 아키텍처를 도입하여 6,000%의 처리량 향상을 달성했습니다.
- 5Hertz는 최종적으로 수년간의 기술 전환에 4억 달러 이상을 투자했습니다.
왜 중요한가
배경과 맥락
업계 영향
한국 시장 시사점
Hertz의 사례는 모든 스타트업 창업자들이 명심해야 할 경고이자 기회입니다. 기술 부채는 단순한 비용 문제가 아니라, 기업의 생존을 위협하는 '실존적 부채'로 진화할 수 있습니다. 특히, 액센츄어와의 3,200만 달러짜리 실패는 외부 컨설팅에만 의존하는 것이 얼마나 위험한지 보여줍니다. 핵심 기술 역량을 외부에 아웃소싱하는 것은 일시적인 해결책일 뿐, 장기적으로는 기업의 성장 동력을 훼손하고 비즈니스 민첩성을 떨어뜨립니다. 스타트업은 '린(Lean)'하게 시작하더라도, 핵심 비즈니스 로직과 관련된 아키텍처 설계는 반드시 내부에서 주도해야 합니다.
이 기사의 핵심 통찰은 '강한 일관성'에 대한 맹목적인 추종을 멈추고, 각 유스케이스에 적합한 '일관성 모델'을 선택하는 것입니다. 스타트업의 경우, 초기에 빠른 개발을 위해 강한 일관성을 기본으로 설정하는 경우가 많지만, 사용자 수가 늘어나고 서비스가 복잡해지면서 병목 현상에 직면하게 됩니다. 가격 조회나 콘텐츠 피드처럼 '읽기'가 압도적으로 많은 서비스는 결과적 일관성으로 충분하며, 이는 확장성과 성능에 엄청난 이점을 가져다줍니다. 이 통찰은 개발 초기 단계부터 아키텍처를 설계할 때 반드시 고려해야 할 부분입니다.
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.