성장 중심의 아키텍처 플레이북은 더 이상 모든 상황에 적합하지 않습니다. Amazon, Google, Netflix, Facebook과 같은 FAANG 기업에서 유래한 마이크로서비스, 팀 자율성, 서비스 경계와 같은 개념들은 인력 증강을 전제로 합니다. 하지만 대부분의 기업은 FAANG처럼 지속적으로 성장하지 않으며, 인력 증감 주기를 겪습니다. 이러한 환경에서 단순히 팀이 많다는 이유로 시스템을 분할하는 것은 팀이 사라졌을 때 막대한 유지보수 부담을 남깁니다. 본문은 이러한 문제의식을 바탕으로 다음과 같은 핵심 내용을 제시합니다.
엔지니어 대 리포지토리 비율의 중요성
-
엔지니어 15명이 50개의 리포지토리를 책임지는 상황은 비정상적입니다. 이는 대부분 한 명의 ‘하이퍼 동기 부여된’ 엔지니어에게 의존하게 되며, 그가 떠나면 해당 리포지토리들은 소유자 없이 방치됩니다.
-
모든 리포지토리는 유지보수, 의존성 패치, CI/CD 파이프라인 관리 등 추가적인 비용과 복잡성을 발생시킵니다.
-
플랫폼 팀이 이러한 문제를 해결할 수 있지만, 소규모 팀은 제품 개발과 인프라 관리를 모두 담당해야 하는 이중고를 겪습니다.
불필요한 복잡성(Excess)과 회복탄력성(Redundancy)
-
회복탄력성(Redundancy)은 시스템이 아닌 사람에 대한 중복성을 의미합니다. 두 명이 배포 가능하고, 세 명이 결제 흐름을 이해하는 등 특정 인력에 대한 의존도를 낮춰 ‘버스 팩터’에 대비하는 것입니다.
-
불필요한 복잡성(Excess)은 10개 서비스로 충분한 것을 3개로 만들거나, 1개 리포지토리로 충분한 것을 4개로 만드는 등 과도한 분할과 조율 오버헤드를 의미합니다. 우리는 회복탄력성은 필요하지만, 불필요한 복잡성은 감당할 수 없습니다.
축소를 위한 아키텍처 설계 원칙
-
모놀리스 선호: 명확한 이유가 없다면 모놀리스를 선호하여 조정 비용을 최소화합니다. ‘미래에 엔지니어를 더 고용할 수도 있다’는 충분한 이유가 아닙니다.
-
리포지토리 수 관리: 현재 리포지토리 수를 파악하고, 엔지니어 대 리포지토리 비율이 팀 규모가 축소되어도 지속 가능한지 평가합니다.
-
움직이는 부품 최소화: 모든 서비스는 배포, 모니터링, 유지보수 비용을 발생시키므로, 가능한 한 적은 수의 구성 요소로 시스템을 구축합니다.
-
인수인계 고려 설계: 개발자가 퇴사하거나 휴가를 갈 것을 가정하여, 특정 인력 없이도 시스템이 유지될 수 있도록 설계합니다.
-
인지 부하 감소: 온보딩에 3주가 걸린다면 아키텍처가 너무 복잡한 것입니다. 3일 이내로 단축할 수 있도록 단순화해야 합니다.
-
과도한 선행 설계 지양: 현재 20명의 엔지니어 팀에 100명 규모의 아키텍처를 미리 설계할 필요는 없습니다.