무분별한 소프트웨어 확장을 관리하는 방법

무분별한 소프트웨어 확장의 증상은 처음에는 인식하기 어려울 수 있습니다. 증상은 더 높은 우선 순위를 위해 뒷전으로 밀려나는 사소한 성가심으로 시작할 수 있습니다. 하지만 이러한 증상을 방치하면 소프트웨어의 무분별한 확산이 인지 부하가 높은 개발 팀에 문제를 일으키고, 팀 참여도를 떨어뜨리며, 느슨하게 결합된 아키텍처 이점의 반대 영향을 미칠 수 있습니다. 속담처럼 “나무를 심기에 가장 좋은 시기는 20년 전이었습니다. 두 번째로 가장 적합한 시기는 바로 지금입니다.” 미래의 성공은 무분별한 소프트웨어 확장이 문제가 되기 전에 이를 관리하는 데 달려 있습니다.

소프트웨어의 무분별한 확장의 세 가지 신호와 혼돈을 극복하고 모든 팀의 잠재력을 발휘하도록 혁신적이고 역동적인 환경을 조성하기 위해 할 수 있는 일은 아래와 같습니다.

소프트웨어의 무분별한 확장의 초기 신호는 여러 건의 인시던트 후 검토(PIR)에서 인시던트의 근본 원인이 업스트림 변경이라고 나타나는 것입니다. 마이크로서비스가 늘어나고 환경 내 변화의 양이 증가하면 개발자 공동 작업과 변화 조정에 관한 기존 규범에 부담을 줄 수 있습니다. 최신화한 애플리케이션 하나에 대해 변경 빈도를 매달에서 매주로 조금만 늘려도 한 달에 릴리스가 100배 증가할 수 있습니다. 개발자들이 공동 작업 방식을 조정해야 한다는 것은 놀라운 일이 아닙니다. 급변하는 환경에서 개발자 공동 작업 규범이 규모에 맞게 조정되지 않으면 프로덕션 환경에서 인시던트가 발생할 가능성이 더 높습니다.

개발자들이 업스트림과 다운스트림의 변경 사항을 인지하는 데 방해가 되지 않는 방법을 만드는 것은 소프트웨어의 무분별한 확장의 영향을 줄이는 좋은 방법입니다. Atlassian에서는 팀이 분산 아키텍처를 탐색할 수 있는 개발자 포털인 Compass를 사용하여 업스트림 및 다운스트림 서비스의 주요 변경 사항에 대해 개발 팀에 앱 내 알림을 보냅니다. 이 알림을 수락하면 종속 서비스를 담당하는 팀이 변경 사항에 대해 알고 있다는 신호가 변경 사항을 개시한 팀원에게 전달됩니다. 그러면 이슈가 예상될 경우 변경 사항에 대해 공동 작업할 기회가 생겨 프로덕션에 의도치 않은 영향을 미칠 가능성이 낮아집니다. 역동적인 환경에서는 인시던트가 발생할 수밖에 없으므로 서비스를 신속하게 복원하려면 인시던트 발생 시 개발자 공동 작업이 중요합니다.

업스트림 변경이 근본 원인인 인시던트 사후 검토의 경우 서비스 복원 시간은 서비스를 소유한 팀이나 팀원뿐 아니라 문제가 있는 업스트림 변경 사항을 식별하는 데 걸리는 시간에 영향을 받는 것이 일반적입니다. 논리적으로, 문제가 되는 업스트림 변경을 식별하는 데 걸리는 시간을 줄이면 시간 경과에 따른 평균 복원 시간(MTTR)이 낮아집니다. 서비스에 풍부한 종속성 계층 구조가 있고 인시던트의 근본 원인이 스택의 어느 곳에나 있을 수 있는 느슨하게 결합된 아키텍처에서는 이것이 더 어렵습니다. 전통적으로 인시던트 대응자는 로그나 변경 기록을 샅샅이 뒤져 인시던트를 일으켰을 수 있는 변경 사항을 식별합니다. 변동이 큰 환경에서는 나를 문 개미를 찾으려고 개미굴을 해체하는 것과 같습니다.

Atlassian에서는 MTTR을 줄이기 위해 Compass의 활동 피드를 사용합니다. 여기에는 업스트림 시스템의 모든 이벤트와 그것을 소유한 팀의 세부 정보가 보입니다. 이렇게 하면 인시던트 발생 시 개발자 공동 작업을 지원하여 분류 시간이 크게 단축됩니다. 인시던트는 발생하기 마련이지만 영향을 최소화하고 서비스를 신속하게 복구하려면 업스트림 변화를 인시던트의 근본 원인으로 적시에 식별하는 것이 중요합니다.

느슨하게 결합된 아키텍처로 이동하는 것은 팀 생산성과 만족의 핵심 요소로, 높은 수준의 자율성을 유지하면서 독립적으로 움직일 수 있는 능력입니다. 소프트웨어의 무분별한 확장을 방치하면 이점 중 일부가 반대로 작용할 수 있어 팀은 바쁘지만 생산성이 떨어지고 만족도가 낮아질 수 있습니다. 개발 팀과 이야기할 때 흔히 나오는 불만은 “다른 팀과 소통하기 전까지는 모든 게 잘 된다”는 것입니다. 이 현상은 소프트웨어의 무분별한 확장이 문제가 되면 증폭됩니다. 빠르게 확장되고 변화하는 환경은 개발자들이 업스트림 또는 다운스트림 종속성에 대해 누구를 참여시켜야 하는지 추적하는 능력을 떨어뜨리며 그 결과로 서비스를 신속하게 제공하려는 팀은 결국 속도가 느려지고 좌절감만 쌓이게 됩니다.

알파 스쿼드와 베타 스쿼드는 매주 같은 수의 이슈와 스토리 포인트를 Jira에서 '완료'로 옮긴다고 가정해 보겠습니다. 알파 스쿼드는 90%의 노력을 새 기능을 프로덕션에 적용하는 데 쓰며 베타 스쿼드는 30%를 새로운 기능에, 70%는 이들이 의존하는 다양한 업스트림 서비스에 참여하는 방법을 찾는 데 씁니다. 두 스쿼드의 출력 수준은 같지만 알파만 생산적으로 간주될 것입니다. 소프트웨어의 무분별한 확장은 팀 간 공동 작업의 필요성을 증폭시킵니다. 자율적인 팀이 온디맨드 방식으로 참여할 수 있는 스마트한 방법을 찾는 것이 느슨하게 결합된 환경의 힘을 발휘하는 데 핵심 요소입니다.

빠르게 성장하고 변화가 큰 환경에서 정보를 스스로 찾는 능력은 팀 생산성과 만족에 중요합니다. 이것을 달성하는 한 가지 방법은 분산형 관리가 포함된 중앙 집중식 소프트웨어 컴포넌트 카탈로그를 구현하는 것입니다. 즉, 각 팀이 자체 서비스를 만들고 업데이트하는 중앙 집중식 카탈로그입니다. 기존 환경에서는 보통 특정 팀이나 부서에서 관리하는 중앙 집중식 카탈로그가 있습니다. 하지만 분산된 환경의 변화 속도에 보조를 맞추지 못하여 결국 팀은 누가, 어떻게 참여해야 하는지에 대해 섀도우 위키를 만들게 됩니다. Atlassian에서는 분산된 접근 방식이 팀 전체의 보이지 않고 낭비되는 노력을 줄이고 셀프 서비스 기능을 개선하며 온디맨드 참여 환경을 만든다는 점을 발견했습니다. 업스트림 및 다운스트림 종속성에 대한 셀프 서비스 정보를 지원하여 무분별한 소프트웨어 확산을 방지하는 것은 팀 만족과 참여도에 보완적인 영향을 주면서 팀 생산성을 높이는 좋은 방법입니다.