Close

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

소프트웨어가 무분별하게 확장되고 있다는 세 가지 징후와 이것에 대해 할 수 있는 일

Andrew Boyagi 얼굴 사진
Andrew Boyagi

선임 에반젤리스트


모놀리스가 빠르게 사라지고 있습니다. 전 세계적으로 셀 수 없이 많은 회사에서 소프트웨어 개발에 느슨하게 결합된 아키텍처를 채택하고 있습니다. 분산된 자율 팀은 모놀리식 애플리케이션을 마이크로서비스와 같은 컴포넌트의 집합으로 나누고 있습니다.

왜 그럴까요? 느슨하게 결합된 아키텍처는 새로운 애플리케이션 기능을 제공하기 위한 위험과 리드 타임을 줄이면서 소프트웨어 성능과 복원력을 쉽게 확장할 수 있도록 만들어 줍니다. 이점은 소프트웨어에서 그치지 않습니다. 느슨하게 결합된 아키텍처를 사용하면 팀이 독립적으로 움직이고 사용자에게 도움이 되는 변경 사항을 자주 릴리스할 수 있습니다. 느슨하게 결합된 아키텍처에서 소프트웨어를 만드는 자율적인 팀은 만족도, 참여도, 생산성이 더 높습니다.

하지만 새로운 업무 방식에는 새로운 도전이 따릅니다. 개별 컴포넌트가 서로 독립적으로 구축되는 역동적이고 확장 가능한 환경을 만들면 복잡성이 높아져 소프트웨어의 무분별한 확장이라는 새로운 유형의 과제가 생겨납니다.

Compass 로고.

무료로 Compass 사용해 보기

개발자 경험을 개선하고 모든 서비스를 카탈로그화하고 소프트웨어 상태를 향상하세요.

블록 일러스트레이션

소프트웨어의 무분별한 확장이란?


소프트웨어의 무분별한 확장이란 환경 내의 애플리케이션이나 소프트웨어 컴포넌트의 수가 빠르게 커지고 변화하여 복잡성이 크게 증가하고 기존 소프트웨어 관리 방법이 실패하는 경우를 말합니다. 이 시나리오는 일반적으로 분산 소프트웨어 아키텍처에서 속도가 빨라질 때 발생합니다.

하나의 모놀리식 애플리케이션이라도 최신화하면 새로운 기능을 독립적으로 자주 프로덕션에 릴리스하는 여러 팀이 수백 개의 마이크로서비스를 관리하는 결과로 이어질 가능성이 높습니다. 이것을 애플리케이션 포트폴리오로 확장하면 여러 개발 팀에 걸쳐 수천 개의 마이크로서비스를 도입하게 될 수도 있습니다. 작은 애플리케이션 포트폴리오를 관리하는 전통적인 방법이 장기적으로 성공할 가능성이 낮다는 것은 놀라운 일이 아닙니다. Atlassian이 오늘날 우리 제품을 뒷받침하는 수천 개의 마이크로서비스를 향해 나아가는 동안 우리는 느슨하게 결합된 아키텍처와 자율적 팀의 힘을 발휘하기 위해서는 무분별한 소프트웨어 확산을 방지하는 것이 핵심이라는 점을 알게 되었습니다.

코드-스토어 아이콘
관련 자료

마이크로서비스와 모놀리식 아키텍처 비교

세 개의 고리 아이콘
솔루션 보기

Compass로 DevEx 개선

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

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

인시던트 후 검토에서 업스트림 변화를 근본 원인으로 식별


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

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

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

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

소프트웨어의 무분별한 확장

Compass의 활동 피드에는 업스트림 시스템의 모든 이벤트가 표시되어 인시던트 발생 시 분류 시간이 단축됩니다.

높은 팀 성과, 낮은 작업 완료율


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

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

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

Compass 사용자 서비스 스크린샷.

Compass는 개발자가 소유하고 의존하는 소프트웨어 컴포넌트에 대한 개발자별 정보를 볼 수 있는 중앙 집중식 위치입니다.

병목 현상이 되는 변경 관리


소프트웨어의 무분별한 확장의 또다른 주요 신호는 변경 관리나 사이버 보안과 같은 거버넌스 기능이 프로덕션 시스템에 변경 사항을 전달하는 데 점점 더 병목 현상이 되어가는 것입니다. 이 기능은 변경 사항을 프로덕션에 적용하기 전에 조직의 표준과 기대치를 충족하는 데 중추적인 역할을 합니다. 하지만 소프트웨어의 무분별한 확장이 발생하면 효과가 낮아집니다. 소프트웨어의 무분별한 확장으로 어려움을 겪고 있는 환경에서는 변화의 속도가 빨라지면서 거버넌스 기능이 점차 압도되어 변경 사항과 검토 요청이 백로그로 쌓여 프로덕션 배포가 지연됩니다. 2022년 DevOps 현황 보고서에 따르면 설문조사 응답자 중 56%는 조직의 소프트웨어 보안 프로세스가 개발 프로세스를 느리게 만든다고 생각했습니다.

보안 관행이 개발 프로세스에 포함되는 것이 이상적이지만 실제로 많은 조직에서는 프로덕션 배포 전에 누군가 수동으로 변경 사항을 검토하게 됩니다. 분산 환경에서 필요한 규모에서는 이 방법이 효과적이지 않습니다. 변경 사항을 적용하는 조직의 능력을 느리게 만들 뿐만 아니라 개발 팀과 조직 표준을 충족하도록 보장할 책임이 있는 담당자 간에 마찰이 생길 수 있습니다.

소프트웨어의 무분별한 확장으로 어려움을 겪고 있는 환경에서는 원하는 조직 표준을 규모에 맞게 달성하면서 빠른 속도를 지원하는 것이 중요합니다. 자동 또는 반자동 성과 기록표는 조직 표준을 전달하고 환경 전반의 컴플라이언스를 검사하기 위한 방해가 되지 않는 방법을 제공하는 좋은 방법입니다. Atlassian에서는 Compass를 사용하여 조직의 품질 기준과 기대치를 설정합니다. 각 소프트웨어 컴포넌트 성과 기록표는 컴플라이언스에 대한 조직의 투명성을 보여줍니다. 팀과 엔지니어링 리더는 성과 기록표에 제품별 표준을 추가하여 조직 내 누구나 조직의 품질 기대치와 상태를 전체적으로 볼 수 있습니다. 이것은 제공 주기가 끝날 때 거버넌스 및 컴플라이언스 검사에서 기대치를 조기에 설정하고 팀이 개발 프로세스 전반에 걸쳐 이를 충족할 수 있도록 하는 것으로의 중대한 변화 입니다. 거버넌스 팀은 역동적인 환경에서 기대치를 설정할 수 있고 제공 팀은 제공 주기 동안 요구 사항을 이해하고 충족할 기회를 얻습니다. 소프트웨어의 무분별한 확장의 영향은 소프트웨어 제공 팀과 거버넌스 팀 모두에 해로울 수 있기 때문에 성과 기록표는 무분별한 확장을 관리할 기회를 제공합니다.

데이터 보안 이미지

Compass 성과 기록표는 정의된 기대치를 기준으로 소프트웨어 컴포넌트 상태를 파악하는 데 사용됩니다.

결론...


소프트웨어의 무분별한 확산을 막을 수 있는 만병통치약은 없습니다. 하지만 장기적인 성공은 소프트웨어의 무분별한 확산의 영향을 조기에 식별하고 해결하는 데 달려 있습니다. 소프트웨어의 무분별한 확장의 초기 지표로는 업스트림 또는 다운스트림 변경 사항으로 인한 여러 인시던트, 목표를 달성하지 못하는 바쁜 팀, 거버넌스 병목 현상 등이 있습니다. 소프트웨어의 무분별한 확장을 식별하는 가장 좋은 방법은 개발자들과 대화하여 이들이 마주한 문제를 이해하는 것입니다.

Atlassian은 회사가 규모를 조정하면서 분산 아키텍처의 복잡성을 관리하여 소프트웨어의 무분별한 확장을 해결할 수 있도록 Compass를 개발했습니다. Compass는 확장 가능한 개발자 경험 플랫폼으로, 모든 엔지니어링 결과물에 대한 단절된 정보와 팀 차원의 공동 작업을 검색 가능한 중앙 집중식 위치로 모아줍니다.

Compass에 대해 자세히 알아보기

Andrew Boyagi
Andrew Boyagi

Andrew는 Atlassian의 DevOps 전도 책임자로, 엔터프라이즈 조직의 소프트웨어 제공 및 서비스 관리 분야에서 20년 이상의 경험을 갖추고 있습니다. 실제 경험을 바탕으로 팀 및 조직이 애자일 DevOps의 이점을 최대화할 수 있는 방법에 대한 실용적인 관점을 제시합니다.


이 문서 공유
다음 토픽

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

DevOps 일러스트레이션

Compass 커뮤니티

장애물 극복 일러스트레이션

자습서: 컴포넌트 만들기

맵 일러스트레이션

Compass 무료로 시작하기

DevOps 뉴스레터 신청

Thank you for signing up