DevOps 텍스트 교육

DevOps 조직과 소프트웨어 아키텍처를 어떻게 설계해야 하나요?

콘웨이의 법칙에 따르면 시스템을 설계하는 조직은 자체 의사소통 구조를 닮은 시스템을 만들 수밖에 없습니다. 다시 말해 소프트웨어가 팀의 의사소통과 상호작용 효율보다 나을 수는 없습니다. 따라서 팀 구성은 소프트웨어 아키텍처, IT, 나아가 비즈니스 성과에 영향을 미칩니다.

조직을 구성하는 방식에 따라 만들어지는 소프트웨어가 달라집니다

여러분의 회사를 포함한 대부분의 기업은 소프트웨어 제공 조직을 여러 팀으로 나누고, 결국 팀 수와 정확히 같은 계층 수를 가진 소프트웨어 아키텍처를 만듭니다. 통제된 실험에서도 6개 팀으로 이루어진 조직에 소프트웨어를 만들라고 하자 6계층 아키텍처가 나왔고, 3개 팀의 다른 조직에 완전히 같은 소프트웨어를 만들라고 하자 3계층 아키텍처가 나왔습니다. 비슷한 사례는 많습니다.

전 세계 직원이 86,000명인 유명 보험사의 한 IT 조직은 고객, 계약, 청구서 및 서비스를 관리하는 백엔드를 제공했는데, 공교롭게도 두 개의 주요 기능별 팀으로 구성되었습니다. 한 팀은 Java를, 다른 팀은 PL/SQL 저장 프로시저를 담당했습니다. 또 전사 중앙 집중형 IT 운영, 데이터베이스 관리자, IT 인프라, 네트워킹, 보안 및 품질 보증 서비스 데스크에 의존하여 소프트웨어를 안전하게 제공하기가 더 어려웠습니다.

또 다른 문제는 팀이 나뉘어 있어도 Java의 비즈니스 오케스트레이션 로직과 PL/SQL의 데이터 접근 로직을 아키텍처에서 제대로 분리하지 못했다는 것입니다. 수백 가지 기능을 제공했고, 기능마다 Java와 PL/SQL 코드가 뒤엉켜 있었습니다. 변경과 새 기능을 요청할 때마다 팀 간에 수십 번 인계해야 했으므로 사소한 변경도 대기열과 리드 타임이 길어졌습니다. 이 복잡한 환경에서는 사소한 변경이 전체에 미치는 영향도 예측하기 어려웠습니다. 기존 프로덕션 기능이 계속 망가지고 가동이 중단되어 해결에 긴 시간, 재작업, 상위 보고, 스트레스가 따랐습니다.

이 업무 방식을 바꾸기 위해 두 기능별 팀을 하나의 제품 팀으로 합쳤습니다. 데이터 접근 계층을 API 함수 집합으로 바꾸며 소프트웨어를 점진적으로 재설계했습니다. 데이터 접근 API의 내부 동작과 완전히 분리한 새 비즈니스 시스템도 구축했습니다. Java와 PL/SQL 전문가가 예전 소속 부문의 이해관계를 떠나 공통 제품 팀의 성공을 위해 일하기 시작해 초기부터 팀 사기가 좋아졌습니다. 느슨하게 결합한 아키텍처를 구축하니 변경의 영향을 파악하기 쉬워지고, 변경 구현이 더 쉽고 빨라졌으며 결함도 더 쉽게 찾고 수정할 수 있었습니다. 그 결과 새 기능의 평균 리드 타임은 4개월에서 3주로 줄었습니다. 팀의 인시던트 대기열도 거의 비어, 확보한 여력으로 코드베이스를 더 검토하고 리팩터링하며 개선합니다.

매트릭스 조직, 기능별 팀, 비용 최적화의 착각

기업은 데이터베이스, 네트워킹, 운영, 정보 보안, 품질 보증, 릴리스 관리, 프로젝트 관리, 제품 관리 등 다양한 전문 분야를 중심으로 여러 기능별 팀을 구성합니다. 프로젝트 팀은 서로 고립된 기능 부문의 인력으로 구성됩니다. 비즈니스 제품과 서비스를 제공하는 이런 매트릭스 프로젝트 조직에서 프로젝트 관리자는 보통 무언가를 제공할 책임을 맡고, 제품 관리자는 올바른 것을 제공하는지 확인합니다.

이 조직 구성의 문제는 기능별 팀이 자신이 기여하는 전체 업무 범위를 거의 또는 전혀 모른다는 것입니다. 극단적이지만 흔한 경우, 기능별 팀은 전체 상황에도, 자신들이 기여하는 제품과 서비스의 전반적인 IT 및 비즈니스 처리량에도 관심이 없습니다. 프로젝트가 틀어지고 서로에게 책임을 돌리기 시작할 때 자기 쪽에 책임이 돌아오지 않게 하는 데만 신경 씁니다.

기능별 팀은 대개 긴 티켓 대기열을 관리해야 해서 프로젝트를 지원할 때 리드 타임이 깁니다. 프로젝트가 기능별 자원을 두고 경쟁하므로 빨리 관심을 받으려면 상위 관리자에게 요청하는 수밖에 없습니다. 이런 일이 반복되면 업무 분위기와 팀 간 신뢰가 나빠집니다.

여러 팀을 거치는 인계, 지연, 품질 문제, 재작업, 병목, 스트레스가 일상이 되었습니다. 매트릭스 조직이 불투명하고 실체 없는 비용 최적화에 집중하는 한 나아지기 어렵습니다. 품질 문제와 재작업 및 지연을 고려하면 기능별 조직이 생각할 수 있는 다른 어떤 조직 구성보다 비쌀지도 모릅니다. 품질 보증이나 IT 운영처럼 중요한 역량을 멀리 떨어진 곳에 외주까지 맡겼다면, IT 조직은 안전하게 제공하고 비즈니스 연속성에 중요한 요구를 충족하기 위해 가까스로 버티고 있을 것입니다.

큰 문제입니다. DevOps는 어떻게 해결할까요? 제품 및 서비스 중심 팀으로 해결합니다

이를 해결하기 위해 DevOps는 기능별 팀의 비용 최적화라는 착각에서 벗어나 검증된 제공 속도 개선으로 전환하라고 권합니다. 제대로 실행하면 팀이 빠르고 지속적으로 제공하는 동시에 비용도 절감할 수 있습니다.

DevOps는 제품 및 서비스 중심 팀을 제안합니다. 이 팀은 독립적이고 교차 기능을 갖추며 자율적이고 자립할 수 있고 대체로 규모가 작습니다. 임시 프로젝트가 아니라 특정 제품과 서비스의 아키텍처, 상세 설계, 코딩, 테스트, 실험, 배포, 운영 및 유지보수 등 소프트웨어 엔지니어링 수명 주기 전체를 담당합니다. 그렇습니다. 제대로 읽으셨습니다. 만든 사람보다 소프트웨어를 더 잘 운영하고 유지할 사람이 있을까요? 당연히 없습니다. 따라서 Amazon과 Netflix의 가장 성공적인 DevOps 팀이 제품과 서비스를 릴리스한 뒤에도 손을 떼지 않는 것은 놀랍지 않습니다. 자체 프로덕션 시스템에서 소프트웨어의 운영과 유지보수도 맡습니다.

조직은 임시 프로젝트 대신 제품과 서비스에 자금을 지원합니다

비즈니스 성과를 높이기 위해 장기적으로 실질적인 성과를 평가하기 어려운 임시 프로젝트에 더 이상 자금을 지원하지 않습니다. DevOps를 통해 조직은 자신의 사명과 목적, 그와 관련된 제품 및 서비스에 자금을 지원합니다. 팀의 성공은 IT 및 비즈니스 성과에 따라 평가됩니다. 내부 및/또는 외부 고객에게 제품, 서비스, 마이크로서비스를 제공하는 각 사업 분야의 투자 수익률이 기준입니다. 이제 팀은 비즈니스 결과에 큰 관심이 없는 고립된 기능별 부서의 구성원이 아니라 자신이 만들고 제공하는 제품과 서비스의 주인으로 행동합니다.

DevOps 팀과 소프트웨어 아키텍처를 어떻게 구축하나요?

물론 DevOps는 진행 중인 모든 프로젝트를 단번에 해체하고 재편하라고 권하지 않습니다. 업무를 방해하지 않으면서 효과를 내려면 프로젝트 팀에 각 분야의 전문가를 배치합니다. 품질 보증, 정보 보안, 데이터베이스, 네트워크, 서버, 운영 등 필요한 분야의 전문가를 확보하면 각 팀이 독립적으로 제품과 서비스를 설계, 배포, 유지보수할 수 있습니다.

새 제품 및 서비스 중심 DevOps 팀에서 가용성, 품질, 성능, 정보 보안, 규정 준수는 모두의 일상 업무입니다. 설계와 개발을 끝낼 때까지 이런 비기능 요구사항에 주의를 기울이지 않으면 고객이 요구하는 부하와 압력을 견딜 고가용성, 보안성, 고품질의 애플리케이션을 어떻게 만들 수 있을까요? 어느 소프트웨어 엔지니어링 단계에도 참여하지 않은 외부 전문가가 애플리케이션의 보안과 품질을 얼마나 잘 판단하고 검증할 수 있을까요? 그래서 고성과 DevOps 팀은 외부 전문가에게 자문만 구하고, 모든 엔지니어링 단계의 비기능 요구사항에는 전적으로 책임을 집니다.

고려할 만한 다른 방법

Google은 매우 성공적인 DevOps 조직으로서 제품 및 서비스 중심 DevOps 팀과 기능별 팀을 함께 폭넓게 사용합니다. 두 팀은 제품 및 서비스를 통해 조직의 사명을 달성하는 것을 공동 목표로 봅니다. 기능별 팀은 템플릿, 체크리스트, 애플리케이션 뼈대 같은 청사진과, 서버와 네트워크를 독립적으로 프로비저닝하고 구성할 수 있는 셀프서비스 시스템을 구축합니다. 제품 및 서비스 팀의 속도를 떨어뜨리는 병목이 되지 않기 위해서입니다. Google의 기능별 팀은 엔지니어링 수명 주기의 초기부터 제품 및 서비스 팀과 협력하고 지원하며, 설계와 코드 및 테스트를 건설적으로 동료 검토하고 지속적으로 자문합니다.

DevOps 팀의 적정 규모는 얼마인가요?

이상적인 DevOps 팀 규모는 5~10명입니다. 규모가 작으면 의사소통과 조율의 복잡성이 줄어듭니다. 팀 리더와 구성원이 잡무와 간접 업무에 많은 시간을 낭비하지도 않습니다. 팀이 맡는 제품 및 서비스의 규모도 일정 범위로 제한되어 애플리케이션의 복잡성과 유지보수 및 운영의 난도가 낮아집니다. 모든 팀원이 전체 상황을 파악하고, 조직의 중요한 사명에 참여하면서 조금씩 리더십 경험을 얻습니다. 팀 리더는 상위 경영진과 협력해 목표를 이해하고 팀원에게 전달합니다.

최대 10명으로 제품과 서비스를 더 이상 감당할 수 없다면 어떻게 하나요?

새 제품과 서비스를 분리하여 이를 맡을 또 다른 DevOps 팀을 구성하세요. 제품과 서비스는 비용을 지불하는 외부 고객에게만 제공되는 것이 아닙니다. 내부 고객을 위한 제품, 서비스 또는 ‘마이크로서비스 API’와 담당 DevOps 팀도 자유롭게 만들 수 있습니다. 예를 들어 청구 시스템이 최대 10명인 팀이 맡기에는 너무 커지면, 데이터베이스 접근 API를 담당할 새 팀을 만듭니다. 온라인 결제 API를 맡을 팀, 배치 프로세스를 맡을 팀을 추가할 수도 있습니다. 지속적 통합과 빠른 제공, 조직의 성공을 위해 모든 팀은 공통 코드 저장소와 공동 배포 파이프라인을 사용해야 합니다.

강하게 결합된 아키텍처에서는 한 애플리케이션의 작은 변경이 여러 작업 흐름에 악영향을 줄 수 있습니다. 따라서 제품과 서비스, 마이크로서비스 API는 느슨하게 결합되어야 합니다. 각 DevOps 팀은 이 아키텍처의 한 부분만 담당하고, 소프트웨어를 독립적으로 설계하고 개발하고 배포할 수 있어야 합니다. 배포 파이프라인의 조기 경보는 코드 체크인의 잠재적 부작용을 팀에 자동으로 신속하게 알려야 합니다.

최대 10명의 작은 팀이 아키텍처부터 운영까지 소프트웨어 엔지니어링 수명 주기의 모든 단계를 어떻게 독립적으로 처리할 수 있나요?

모든 팀원이 제너럴리스트가 되도록 권장하세요. 새로운 기술을 지속적으로 기를 수 있도록 격려하고 지원하세요.

현재 지식과 경험에 관계없이 배우고 성장하려는 사람만 채용하세요. 고정된 역할과 책임을 기준으로 평가받기를 기대하는 사람은 채용하지 않아야 합니다. 조직도 제품과 서비스도 그대로 머물지 않는다는 점을 알고 계실 것입니다.

오늘이 아니더라도 내일은 수요가 바뀝니다.

결론

이 장에서는 매트릭스 조직과 그에 따른 기능 부문의 고립이 낳는 좋지 않은 결과와, 이를 해결하는 DevOps의 방법을 설명했습니다.

DevOps는 제품, 서비스 또는 마이크로서비스 API를 중심으로 최대 10명의 소규모 팀을 구성할 것을 제안합니다.

이 DevOps 팀은 설계부터 유지보수까지 엔지니어링 수명 주기의 전 단계를 스스로 담당할 수 있는 풀스택 소프트웨어 엔지니어 제너럴리스트로 구성해야 합니다.

DevOps는 느슨하게 결합된 서비스 지향 아키텍처(SOA)에 의존하며, 각 DevOps 팀은 그 아키텍처의 한 부분을 소유하고 운영합니다.