프로젝트의 기술 동물원: 정의, 원인 및 해결 방법

프로젝트에서 기술 동물원이란

기술 동물원은 프로젝트나 회사가 동일한 작업을 해결하기 위해 과도한 수의 이질적인 도구를 사용하는 상황입니다. 예를 들어, 세 가지 다른 HTTP 클라이언트(Alamofire, OkHttp, Ktor), 두 가지 상태 관리자(Redux, MobX), 세 가지 데이터베이스(Realm, CoreData, SQLite) 등이 있습니다.

동물원과 다른 작업을 위한 다른 도구의 의도적인 선택 사이의 차이는 전략의 부재입니다. 팀 A가 React Native를 선택하고, 팀 B가 Flutter를 선택하고, 팀 C가 Kotlin Multiplatform을 공통 결정 없이 선택한다면 — 그것이 동물원입니다. 다양성 자체는 해롭지 않으며, 통제되지 않은 특성이 해롭습니다.

프로젝트의 각 새 스택은 개발자의 인지 부하를 증가시킵니다. 효과적으로 작업하려면 사용된 모든 기술의 미묘한 차이를 기억해야 합니다. Google(2024)에 따르면, 다른 스택 간의 컨텍스트 스위칭은 통합된 기술 환경에서 작업하는 것과 비교하여 개발자 생산성을 23% 감소시킵니다.

기술 동물원의 원인

분산된 의사 결정이 주요 원인입니다. 각 팀은 전체 전략을 고려하지 않고 자체 프로젝트를 위한 기술을 선택합니다. 백엔드 팀은 Kotlin을, ML 팀은 Python을, 모바일 팀은 Flutter를 사용합니다. 개별적으로는 올바른 결정이지만, 함께 모여 동물원을 만듭니다.

합병 및 인수(M&A) — 회사가 다른 회사를 인수하면 기술 스택이 합쳐집니다. 두 시스템이 동일한 문제를 다른 방식으로 해결합니다. 예시: 스타트업을 인수한 후, 대기업은 내부 표준이 Java Spring임에도 불구하고 Ruby on Rails 스택을 얻게 됩니다. 다시 작성할 것인지, 두 스택을 병렬로 유지할 것인지의 문제가 발생합니다.

유행 기술의 변화 — 각 hype 사이클이 새 스택을 추가합니다. 2015년에는 모두가 AngularJS로 작성했고, 2017년에는 React로, 2020년에는 Svelte로 작성했습니다. 규율 없이 프로젝트는 다른 시대의 레이어를 축적합니다. 작동하지만 지원되지 않는 레거시 모듈은 빠르게 제거할 능력 없이 이질성을 추가합니다.

동물원이 팀과 비즈니스에 위험한 이유

새 개발자 온보딩은 하나 대신 5개 이상의 다른 기술을 배우는 것으로 변합니다. 프로젝트에 적응하는 데 일주일 대신, 신규자는 사용된 모든 도구를 마스터하는 데 한 달을 보냅니다. 생산성까지의 시간은 프로젝트의 스택 수에 비례하여 증가합니다.

컨텍스트 스위칭 — 하루에 3개 이상의 스택으로 작업하는 개발자는 각 전환 후 컨텍스트를 복원하는 데 최대 30%의 시간을 소비합니다. 캘리포니아 대학교(2023)에 따르면, 각 전환 후 원래 생산성 수준으로 돌아가는 데 23분이 걸립니다. 하루 5회 전환 시 — 거의 2시간 손실됩니다.

보안 위험 — 각 스택은 업데이트, 취약점 모니터링 및 모범 사례에 대한 지식이 필요합니다. 팀이 모든 기술에 동시에 전문가가 될 수는 없습니다. 의존성 피로 — 사용되는 라이브러리 수가 팀의 추적 및 업데이트 능력을 초과할 때 — 제품 보안에 직접적인 위협입니다.

인프라 복잡성 — CI/CD를 각 스택에 대해 구성해야 합니다. 다른 빌드 시스템(Gradle, CocoaPods, npm, pip), 다른 환경 요구 사항. 인프라 팀은 파이프라인을 개선하는 대신 이질적인 파이프라인 유지에 리소스를 소비합니다.

프로젝트에서 문제를 진단하는 방법

스택 인벤토리 — 사용된 기술의 전체 목록을 작성합니다: 언어, 프레임워크, 데이터베이스, CI/CD, 모니터링 시스템. 각 기술에 대해 프로젝트/모듈 수, 지원 수준 및 전문가 수준에서 능숙한 개발자 수를 기록합니다.

Technology Radar — ThoughtWorks의 방법으로 기술을 4개 사분면으로 나눕니다: Adopt, Trial, Assess, Hold. Adopt — 권장 스택, Trial — 실험적, Assess — 평가 중, Hold — 사용 비권장. 예시: Flutter가 Adopt, React Native가 Hold — 팀은 무엇을 선택해야 할지 이해합니다.

유지보수 비용 메트릭 — 매월 각 스택 유지에 얼마나 많은 엔지니어링 시간이 소비되는지 추정합니다. 스택이 리소스의 10%를 소비하지만 모듈의 2%에서만 사용된다면 — 교체 대상입니다. 축이 "프로젝트 수" vs "유지보수 복잡성"인 스택 히트맵은 문제 영역을 명확히 보여줍니다.

기술 스택을 표준화하는 방법

Architecture Decision Records(ADR) — 기술 선택의 근거를 포함한 아키텍처 결정 문서화. 각 ADR에는 컨텍스트, 고려된 대안, 선택의 논거가 포함됩니다. Michael Nygard(2022)가 이 접근 방식을 대중화했으며, 오늘날 ADR은 기술 다양성을 관리하는 팀의 표준입니다.

Technology Review Board — 프로젝트의 새 기술을 승인하는 선임 개발자 위원회. 기존 스택과의 호환성, 커뮤니티 지원, 마이그레이션 비용, 인재 가용성 등의 기준에 따라 결정됩니다. Spotify는 2018년부터 유사한 위원회를 사용하고 있습니다.

신규 프로젝트 게이트웨이 — 규칙: 모든 새 서비스나 모듈은 승인된 스택만 사용합니다. 예외는 근거를 포함한 ADR을 통해 가능합니다. 예시: 팀이 Java가 이 작업에 적합하지 않음을 증명하는 경우에만 새 마이크로서비스를 Kotlin으로 작성할 수 있습니다. 모든 기술의 무제한 사용은 금지됩니다.

스택 다양성의 단계적 감소

1단계: 중단 — 지원되지 않는 스택의 신규 프로젝트가 중지됩니다. Hold 사분면의 각 스택에 폐기 예정일이 설정됩니다. 새 기능은 승인된 스택에서만 작성됩니다. 레거시 모듈은 계속 작동하지만 확장되지 않습니다.

2단계: 통합 — 각 작업에 하나의 도구가 선택됩니다. 하나의 HTTP 클라이언트, 하나의 상태 관리자, 하나의 데이터베이스. 대체 스택의 모듈은 우선순위에 따라 마이그레이션이 예약됩니다. Strangler Fig 패턴은 시스템 중단 없이 교체하는 주요 방법입니다.

3단계: 마이그레이션 — 각 스프린트에서 팀은 시간의 20%를 구식 스택에서 승인된 스택으로 중요 모듈을 다시 작성하는 데 할당합니다. 대상 아키텍처는 문서화되며 위원회의 결정 없이 변경되지 않습니다. 프로세스는 동물원의 규모에 따라 6~24개월이 소요됩니다.

예시: HTTP 클라이언트 마이그레이션

// Before: 3 different HTTP clients in one project
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}