마이너스 속도: 복잡성 한계를 높이는 방법

복잡성 한계에 도달하는 것은 어쩔 수 없다고 느껴질 수도 있지만 팀이 한계에 가까워지고 있다는 몇 가지 지표가 있습니다. 설명하기에 앞서 복잡성 한계에 얼마나 가까워졌는지 알려주는 절대적 척도는 없다는 것을 알려드립니다. 하지만 이 메트릭을 통해 복잡성 한계에 얼마나 가까워졌는지 파악할 수 있습니다.

팀이 복잡성 한계에 도달했다는 가장 분명한 지표는 집중해야 할 복잡한 문제를 해결하는 것보다 조직의 복잡성을 탐색하는 데 더 많은 시간을 들일 때입니다. 변경(속도)에 대한 DORA 리드 타임 동향과 변경 실패율(품질) 메트릭을 보면 시간이 지나면서 팀의 속도가 느려지거나 빨라지는 것을 알 수 있습니다. 이 메트릭에 영향을 미치는 다른 요인도 있지만 이 메트릭은 팀 효율성을 나타내는 좋은 지표입니다.

개발자 만족도는 소프트웨어 팀이 조직 차원의 복잡성을 얼마나 헤쳐나가고 있는지 보여주는 또 다른 지표입니다. 다른 어떤 역할보다도 개발자는 까다로운 문제를 해결하는 데 시간을 쓰는 것을 좋아하는 동시에 방해가 되는 불필요한 작업도 싫어합니다. 낮은 개발자 만족도는 조직의 복잡성이 소프트웨어 팀에 문제를 유발하고 있다는 것을 보여주는 좋은 증거입니다.

팀이 복잡성에 빠져 있다는 것을 깨닫는 회사는 조직의 단순성을 회복하는 것을 목표로 "단순화 프로젝트"를 시작하는 경우가 많습니다. 단순화가 실패하는 전략인 이유로는 두 가지가 있습니다. 복잡성은 조직이 환경을 단순화할 수 있는 속도보다 빠르게 증가하고 "단순화 프로젝트"는 단순화하려는 바로 그 복잡한 환경에서 운영되기 때문입니다.

단순화의 일반적인 출발점은 가능한 경우 애플리케이션을 폐기하거나 통합하여 그 수를 줄이는 것입니다. 애플리케이션을 폐기하려면 팀이 모든 업스트림 및 다운스트림 종속성, 애플리케이션을 누가 사용하는지, 기능을 어떻게 교체하는지, 데이터를 어디에 어떻게 보관 또는 마이그레이션할지 이해하고 이것과 같은 유형의 작업에서 발생하는 여러 복잡한 문제를 처리해야 합니다. 안타깝게도 이렇게 하는 데 필요한 노력을 많이 투자해도 복잡성이 그만큼 크게 줄어들지는 않습니다. 회사가 핵심 비즈니스나 사용자 경험에 영향을 주지 않고 폐기할 수 있는 애플리케이션의 양에는 제한이 있지만 엔지니어가 새로 만들 수 있는 소프트웨어 컴포넌트의 수에는 제한이 없습니다. 애플리케이션 하나를 폐기하는 데 걸리는 12개월 동안 수백 개의 새로운 마이크로서비스가 만들어질 수 있습니다. 건전한 기술 환경은 시간이 지나면서 성장하므로 복잡성을 줄이기 위해 환경에서 고정된 수의 애플리케이션 또는 소프트웨어 컴포넌트만 유지하는 것은 실용적이지 않습니다.

단순화 프로젝트에는 보통 커뮤니케이션 흐름의 복잡성을 없애기 위한 조직 구조 재작업이 포함됩니다. 가장 덜 복잡한 조직 구조는 모든 직원이 같은 위치에 있는 대규모 계층형 팀입니다. 가장 복잡한 조직 구조는 소규모의 분산된 자율적인 팀입니다. 콘웨이의 법칙에 따르면 계층적으로 구성된 대규모 팀은 모놀리식 애플리케이션을 만들 가능성이 높은 반면, 분산된 소규모 팀은 마이크로서비스 같은 모듈식 아키텍처를 사용하여 애플리케이션을 만들 가능성이 높습니다. 높은 품질의 소프트웨어를 빠른 속도로 생산하는 것은 마이크로서비스 아키텍처와 같은 모듈식 아키텍처 패턴에 의해 가능합니다. 즉, 조직 구조가 복잡할수록 성공으로 이어질 가능성이 높습니다. 조직 구조를 "단순화"하면 이해하기는 더 쉬워지지만 단순화 프로젝트의 최종 목표에는 역효과를 낳습니다.

단순화는 중요하고 가치 있는 일이지만 한 번 하고 끝나는 활동이 아니라 소프트웨어 팀(및 팀들의 팀)을 위한 지속적인 개선으로 기본 제공되는 것이 가장 좋습니다. 단순화는 복잡성 한계에 도달하는 것을 지연시킬 수 있지만 스타트업 환경에서 누리는 빠른 속도의 자유를 조직에 회복해 주지는 못합니다.

소프트웨어 팀 효율성에 대한 이야기로 돌아가자면 조직은 복잡성 한계를 높여야 합니다. 복잡성 한계를 높인다는 것은 기본적으로 복잡성이 업무 만족도와 팀이 소프트웨어를 제공하는 품질 및 속도에 영향을 미치기 전에 각 팀이 헤쳐나갈 수 있는 조직 차원의 복잡성을 높이는 것을 의미합니다.

플랫폼 엔지니어링은 조직의 복잡성 한계를 높이는 데 중요한 개념입니다. 강력한 플랫폼 엔지니어링 팀은 일상 업무에서 조직의 복잡성을 추상화하여 소프트웨어 팀의 인지 부하를 줄이는 데 집중합니다. 플랫폼 엔지니어링을 제대로 구현하면 팀이 조직 차원의 복잡성을 헤쳐나가는 데 들이는 시간을 줄이면서 까다로운 문제를 해결하는 데 드는 노력의 균형을 다시 조정할 수 있습니다.