# 운영 모델 2x2 표현
이러한 운영 모델 2x2 표현을 살펴보면 조직의 환경 내에서 팀 간 관계를 이해하는 데 도움이 됩니다. 이 그림은 각 팀이 담당하는 역할과 팀 간 관계를 중점적으로 다루지만, 이 예제의 맥락에서 거버넌스와 의사 결정에 대해서도 설명합니다.
팀은 지원하는 워크로드에 따라 다양한 모델의 여러 부분에서 책임을 맡을 수 있습니다. 설명된 상위 영역보다 더 전문적인 분야로 세분화하기를 원할 수 있습니다. 활동을 분리 또는 합치거나 팀을 추가하고 더 구체적인 세부 정보를 제공하면서 이러한 모델을 무한하게 변형시킬 수 있습니다.
여러 팀 간에 중복되거나 인식되지 않은 기능을 식별할 수 있습니다. 그러면 이를 통해 효율성을 높이거나 추가적인 이점을 제공할 수 있습니다. 또한 조직에서 충족되지 않은 요구 사항을 확인 및 해결할 수도 있습니다.
조직의 변화를 평가할 때는 모델 간의 장단점은 무엇인지, 변화 전후의 모델에서 개별 팀은 어떤 역할을 맡는지, 팀의 관계와 책임이 어떻게 바뀌는지 그리고 변화에 따른 이점이 조직에 영향을 미치는지 여부를 조사합니다.
다음과 같은 네 가지 각각의 운영 모델을 사용하면 성공적으로 운영할 수 있습니다. 일부 모델은 개발 과정의 특정 시점이나 특정 사용 사례에 더 적합할 수 있습니다. 이러한 모델 중 일부는 현재 조직 환경에서 사용하는 모델보다 더 유용할 수 있습니다.
**Topics**
+ [완전분리형 운영 모델](fully-separated-operating-model.md)
+ [클라우드 관리형 서비스 제공업체를 통한 DevOps](devops-with-cloud-managed-service-provider.md)
+ [클라우드 운영 및 플랫폼 지원(COPE)](cloud-operations-and-platform-enablement.md)
+ [분산된 DevOps](distributed-devops.md)
+ [탈중앙화된 DevOps](decentralized-devops.md)
+ [운영 모델 개선](evolving-your-ops-model.md)
# 완전분리형 운영 모델
다음 그림의 세로 축에는 애플리케이션과 플랫폼이 있습니다. 애플리케이션은 비즈니스 성과를 지원하는 워크로드를 말하며, 맞춤형으로 개발하거나 구매한 소프트웨어일 수 있습니다. 플랫폼은 물리적 인프라와 가상 인프라 그리고 해당 워크로드를 지원하는 기타 소프트웨어를 말합니다.
가로 축에는 엔지니어링과 운영이 있습니다. 엔지니어링은 애플리케이션 및 인프라의 개발, 구축 및 테스트를 말합니다. 운영은 애플리케이션 및 인프라의 배포, 업데이트 및 지속적 지원을 말합니다.
![\[기존 모델 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png)
과거에는 조직이 ITIL과 같은 프레임워크나 ISO와 같은 표준을 수용하고 이를 중심으로 운영 활동을 구성했습니다. 그래서 토폴로지가 완전히 분리되는 경우가 많았습니다. 이 모델에서 각 사분면의 활동은 별도의 팀이 수행합니다. 작업 요청, 대기열 및 티켓과 같은 메커니즘 또는 IT 서비스 관리 시스템(ITSM)을 사용하여 팀 간에 작업이 전달됩니다.
다른 팀으로 또는 여러 팀 간에 작업을 이양하면 복잡성이 늘고 병목 현상과 지연이 발생합니다. 요청은 우선시될 때까지 지연될 수 있습니다. 결함이 뒤늦게 발견되면 상당한 재작업이 필요하며, 동일한 팀과 부서의 검사를 다시 거쳐야 할 수도 있습니다. 엔지니어링 팀의 조치가 필요한 인시던트가 있다면 이미 착수된 활동으로 인해 대응이 지연됩니다.
수행 중인 활동이나 기능을 중심으로 사업, 개발 및 운영 팀을 구성하면 서로 조율되지 않을 위험이 큽니다. 이로 인해 팀이 사업 성과가 아니라, 맡은 책임에만 집중하게 될 수 있습니다. 팀의 전문 분야가 협소하거나, 팀이 물리적으로 또는 논리적으로 격리되어 있으면, 커뮤니케이션과 협업을 저해할 수 있습니다.
# 클라우드 관리형 서비스 제공업체를 통한 DevOps
클라우드 관리형 서비스 제공업체를 통한 DevOps 모델은 애플리케이션 팀을 위한 *구축 및 실행* 방법론을 따릅니다. 그러나 조직에 전담 플랫폼 엔지니어링 및 운영 팀을 지원할 기술이나 팀원이 갖추어져 있지 않거나, 여기에 시간과 노력을 투자하고 싶지 않을 수도 있습니다.
또는 비즈니스를 차별화하는 기능을 제작하는 데 초점을 맞춘 플랫폼 팀을 두는 동시에 획일적인 일상 업무는 아웃소싱 업체에 맡기고 싶을 수도 있습니다.
관리형 서비스 제공업체(예: [AWS Managed Services](https://aws.amazon.com/managed-services/) 또는 [AWS Partner Network](https://aws.amazon.com/partners/find/results/?keyword=Managed+Service+Provider)의 제공업체)를 통해 클라우드 환경을 전문적으로 구현할 수 있으며, 보안 및 규정 준수 요구 사항과 비즈니스 목표를 지원받을 수 있습니다.
![\[클라우드 관리형 서비스 제공업체를 통한 DevOps\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png)
이 모델의 경우 AWS Organizations 및 AWS Control Tower에서 계정 생성과 정책을 관리하고, 플랫폼 팀은 중앙 집중식으로 거버넌스를 관리하도록 구현하려고 합니다.
이 모델에서는 서비스 공급업체의 업무에 맞추어 메커니즘을 수정해야 합니다. 이 모델에서는 서비스 공급업체를 비롯한 팀 간의 작업 이양으로 인해 발생하는 병목 현상과 지연 또는 뒤늦은 결함 발견과 관련된 잠재적 재작업 문제가 해결되지 않습니다.
공급자의 표준, 모범 사례, 프로세스 및 전문성을 활용하여 이 문제를 해결할 수 있습니다. 또한 이들이 지속적으로 개발하는 서비스 오퍼링의 이점을 얻을 수 있습니다.
관리형 서비스를 운영 모델에 추가하면 시간과 리소스를 절약할 수 있으며, 새로운 기술과 기능을 개발하는 대신 내부 팀이 비즈니스를 차별화하는 전략적 결과에 집중할 수 있습니다. 또한 클라우드 마이그레이션 프로그램의 속도를 늦추지 않으면서 자체 플랫폼 기능을 구축하고 성숙시킬 수 있는 시간을 제공할 수 있습니다.
# 클라우드 운영 및 플랫폼 지원(COPE)
이 클라우드 운영 및 플랫폼 지원(COPE) 모델은 DevOps 문화를 채택하여 애플리케이션 팀이 워크로드에 대한 엔지니어링 및 운영 활동을 수행할 수 있도록 지원함으로써 *구축 및 실행* 방법론을 확립하고자 합니다.
애플리케이션 팀은 마이그레이션, 클라우드 채택 또는 워크로드 현대화 업무를 맡을 수 있지만 클라우드 아키텍처 및 운영을 적절하게 지원할 수 있는 기존 기술이 없을 수 있습니다. 이렇게 애플리케이션 팀의 역량과 친숙도가 부족하면 조직의 민첩성이 저하되고 비즈니스 성과에 영향을 미칠 수 있습니다.
이 문제를 해결하려면 조직 내 기존 운영 전문 지식을 활용하여 애플리케이션 팀이 클라우드 운영으로 전환할 수 있도록 지원합니다. 전문가로 구성된 전담 팀일 수도 있고 조직 전체에서 선발한 참가자로 가상 팀을 구성할 수도 있습니다. 그러나 목표는 동일합니다. 자동화라는 클라우드 우선 원칙을 사용하여 차별화되지 않은 과도한 작업을 없애고 표준화된 패턴을 제공하고 자율성을 장려하며 워크로드 팀의 역량을 구축하는 운영 지원을 제공하는 것입니다. 목표는 클라우드 기능 전반에 걸쳐 충분한 성숙도를 구축하고 운영 책임의 장벽을 낮추어 애플리케이션 팀이 더 이상 추가 지원을 필요로 하지 않도록 하는 것입니다.
COPE 모델은 워크로드 수준에 중점을 둡니다. 한 번에 여러 팀에서 이 접근 방식이 필요하거나 복잡한 대규모, 다년간의 마이그레이션 프로젝트를 수행하거나 이러한 이니셔티브를 지원하는 플랫폼을 구축하는 경우 클라우드 혁신 센터(CCoE) 사용을 고려하세요. 이는 클라우드로의 마이그레이션을 가속화하고 조직을 광범위하게 트랜스포메이션하고자 할 때 많은 사람들이 성공을 거둔 메커니즘입니다.
![\[클라우드 운영 및 플랫폼 지원(COPE) 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png)
플랫폼 엔지니어링 팀은 애플리케이션 팀이 채택하고 COPE 팀에서 제공하는 미리 정의된 표준을 기반으로 하는 핵심 공유 플랫폼 기능을 가벼운 계층으로 구축합니다. 플랫폼 엔지니어링 팀은 셀프 서비스 메커니즘을 통해 애플리케이션 팀에 제공되는 엔터프라이즈 참조 아키텍처와 패턴을 체계화합니다. 애플리케이션 팀은 AWS Service Catalog와 같은 서비스를 사용하여 기본적으로 중앙 집중식 거버넌스 및 보안 표준을 준수하는 승인된 참조 아키텍처, 패턴, 서비스 및 구성을 배포할 수 있습니다.
또한 플랫폼 엔지니어링 팀은 표준화된 서비스 세트(예: 개발 도구, 관찰성 도구, 백업 및 복구 도구, 네트워킹)를 애플리케이션 팀에 제공합니다.
COPE 팀은 표준화된 서비스를 관리 및 지원하며 참조 아키텍처 및 패턴을 기반으로 클라우드 입지를 구축하는 애플리케이션 팀을 지원합니다. 이들은 애플리케이션 팀과 협력하여 기본 운영을 수립하는 데 도움을 줍니다. 이 과정에서 시간이 지날수록 애플리케이션 팀은 시스템과 리소스에 대해 점점 더 많은 책임을 지게 됩니다. COPE 팀은 플랫폼 엔지니어링 팀과 함께 지속적인 개선을 주도하고 애플리케이션 팀을 지지하는 역할을 합니다.
애플리케이션 팀은 필요한 경우 COPE 팀과 통합하여 환경, CI/CD 파이프라인, 변경 관리, 관찰성을 설정하고 인시던트 및 이벤트 관리 프로세스를 모니터링 및 수립하는 데 지원을 받습니다. COPE 팀은 애플리케이션 팀과 함께 이러한 운영 활동을 수행하며, 시간이 지남에 따라 애플리케이션 팀이 소유권을 갖게 되면 COPE 팀 참여를 단계적으로 축소합니다.
애플리케이션 팀은 COPE 팀의 기술 이점과 조직에서 학습한 교훈을 최대한 활용합니다. 중앙 집중식 거버넌스를 통해 수립된 가드레일로 보호됩니다. 애플리케이션 팀은 인정받은 성공을 기반으로 구축되며 채택한 조직 표준을 지속적으로 개발함으로써 이점을 얻습니다. 관찰성 설정 및 모니터링 프로세스를 통해 워크로드 운영에 대한 보다 효율적인 인사이트를 확보하고, 변경 사항이 워크로드에 미치는 영향을 더 잘 이해할 수 있습니다.
또한 COPE 팀은 운영 활동을 지원하는 데 필요한 액세스 권한을 유지하고, 애플리케이션 팀 전반에 걸친 엔터프라이즈 운영 뷰를 제공하며, 중요한 인시던트 관리 지원을 제공할 수 있습니다. COPE 팀은 차별화되지 않은 과도한 업무로 간주되는 활동에 대한 책임을 맡습니다. 대규모로 지원 가능한 표준 솔루션을 통해 이를 충복할 수 있습니다. 또한 애플리케이션 팀이 애플리케이션을 차별화하는 데 집중할 수 있도록 애플리케이션 팀을 위해 알기 쉬운 프로그래밍 방식 및 자동화된 운영 활동을 지속적으로 관리합니다.
팀의 성공에서 도출된 조직의 표준, 모범 사례, 프로세스 및 전문 지식을 최대한 활용합니다. 새로운 팀이 클라우드를 채택하거나 현대화할 수 있도록 이러한 성공적인 패턴을 재현할 수 있는 메커니즘을 수립합니다. 이 모델은 애플리케이션 팀이 지식과 아티팩트를 확립하고 전환하도록 지원하는 COPE 팀의 능력에 중점을 둡니다. 이 모델은 애플리케이션 팀의 독립성이 저하될 수 있는 위험과 함께 애플리케이션 팀의 운영 부담을 줄여줍니다. 플랫폼 엔지니어링, COPE 및 애플리케이션 팀 간의 관계를 구축하여 향후 발전과 혁신을 지원하는 피드백 루프를 생성합니다.
조직 전반의 표준을 정의하면서 플랫폼 엔지니어링 팀과 COPE 팀을 구성하면 클라우드 채택을 촉진하고 현대화 노력을 지원할 수 있습니다. 애플리케이션 팀의 컨설턴트 및 파트너 역할을 하는 COPE 팀의 추가 지원을 제공함으로써 애플리케이션 팀은 유용한 클라우드 기능의 채택을 지연시키는 워크로드 수준의 장벽을 제거할 수 있습니다.
# 분산된 DevOps
분산 DevOps 모델은 [COPE 방법론](cloud-operations-and-platform-enablement.md)에 따라 엔지니어링 팀 전체에서 애플리케이션 엔지니어링 운영 및 인프라 엔지니어링 운영 책임을 분리(또는 분산)합니다.
애플리케이션 엔지니어가 워크로드의 운영과 엔지니어링을 모두 수행합니다. 마찬가지로, 인프라 엔지니어는 애플리케이션 팀을 지원하는 데 사용하는 플랫폼의 운영과 엔지니어링을 모두 수행합니다.
![\[분산된 DevOps 모델 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/operational-excellence-pillar/images/distributed-devops.en.png)
이 예제에서는 거버넌스가 조직 내 다른 곳에서 중앙 집중화되었다고 간주합니다. 표준은 여러 애플리케이션 및 플랫폼 팀에 제공되거나 배포되거나 공유됩니다.
여러 계정에 걸쳐 환경을 중앙 집중식으로 관리할 수 있는 도구나 서비스를 사용합니다(예: [AWS Organizations](https://aws.amazon.com/organizations/)). [AWS Control Tower](https://aws.amazon.com/controltower/features/)와 같은 서비스는 계정 설정을 위한 블루프린트(운영 모델 지원)를 정의하고, AWS Organizations를 통해 지속적으로 거버넌스를 적용하며, 새로운 계정의 프로비저닝을 자동화할 수 있도록 함으로써 이 관리 기능을 확장합니다.
*자체적으로 구축하고 실행*한다고 해서 애플리케이션 팀이 풀 스택, 도구 체인 및 플랫폼을 책임진다는 의미는 아닙니다.
플랫폼 엔지니어링 팀이 표준화된 서비스 세트(예: 개발 도구, 모니터링 도구, 백업 및 복구 도구, 네트워킹)를 애플리케이션 팀에 제공합니다. 플랫폼 팀은 승인된 클라우드 공급자 서비스, 동일한 서비스의 특정 구성 또는 둘 모두에 대한 접근 권한을 애플리케이션 팀에 제공할 수도 있습니다.
Service Catalog와 같이 승인된 서비스 및 구성을 배포하기 위한 셀프 서비스 기능을 제공하는 메커니즘은 거버넌스를 시행하는 동시에 이행 요청과 관련된 지연을 제한하는 데 도움이 될 수 있습니다.
플랫폼 팀은 전체 스택의 가시성을 지원하므로, 이를 통해 애플리케이션 팀은 애플리케이션 구성 요소에서 발생한 문제와 애플리케이션에 사용되는 서비스 및 인프라 구성 요소에서 발생한 문제를 서로 구분할 수 있습니다. 또한 플랫폼 팀은 이러한 서비스 구성을 지원하고 애플리케이션 팀의 운영을 개선하는 방법에 대한 지침을 제공할 수 있습니다.
앞서 언급한 바와 같이, 애플리케이션 팀이 활동과 애플리케이션 혁신을 지원하는 데 있어서 표준의 추가, 변경 및 예외 처리를 요청할 수 있는 메커니즘이 갖추어져야 합니다.
분산된 DevOps 모델은 애플리케이션 팀에 강력한 피드백 루프를 제공합니다. 일상적인 워크로드 운영에서는 지원 및 기능 요청을 통한 직접적 또는 간접적인 상호 작용으로 인해 고객과의 접촉이 늘어나기 마련입니다. 이와 같이 가시성이 높아지는 덕분에 애플리케이션 팀은 문제를 보다 신속하게 해결할 수 있습니다. 더 긴밀해지는 고객의 참여와 고객과의 관계는 고객 요구 사항에 대한 인사이트를 얻고 더 빠르게 혁신할 수 있게 해줍니다.
이 모든 것은 애플리케이션 팀을 지원하는 플랫폼 팀의 경우에도 마찬가지입니다. 플랫폼 팀이 이러한 애플리케이션 팀을 고객으로 간주해야 하기 때문입니다.
채택된 표준은 사전 승인을 받게 되므로, 프로덕션 환경에 적용하는 데 필요한 검토 작업량을 줄일 수 있습니다. 플랫폼 팀에서 제공하는 테스트를 거쳐 지원되는 표준을 사용하면 이러한 서비스 관련 문제의 발생 빈도가 줄어들 수 있습니다. 표준을 채택하면 애플리케이션 팀이 워크로드를 차별화하는 데 집중할 수 있습니다.
# 탈중앙화된 DevOps
탈중앙화된 DevOps 모델은 *구축 및 실행* 방법론의 변형으로, 운영이 주로 워크로드 팀의 소유 아래에 있습니다.
애플리케이션 엔지니어가 워크로드의 운영과 엔지니어링을 모두 수행합니다. 마찬가지로, 인프라 엔지니어는 애플리케이션 팀을 지원하는 데 사용하는 플랫폼의 운영과 엔지니어링을 모두 수행합니다.
![\[분산 DevOps 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/operational-excellence-pillar/images/decentralized-devops.en.png)
이 예제에서는 거버넌스를 탈중앙화되었다고 간주합니다. 표준은 여전히 플랫폼 팀에 의해 애플리케이션 팀에 배포, 제공 또는 공유되지만, 애플리케이션 팀이 워크로드를 지원하는 데 있어서 새로운 플랫폼 기능을 자유롭게 운영하고 엔지니어링할 수 있습니다.
이 모델에서는 애플리케이션 팀의 제약이 더 적지만, 책임은 더 늘어납니다. 플랫폼 기능을 추가로 지원하려면 추가적인 기술이 필요하고 잠재적으로 팀원이 더 필요할 수도 있습니다. 기술 세트가 적절하지 않고 결함이 조기에 파악되지 않으면 재작업 발생의 위험이 상당히 커집니다.
애플리케이션 팀에 명시적으로 위임되지 않은 정책을 적용합니다. 여러 계정에 걸쳐 환경을 중앙 집중식으로 관리할 수 있는 도구나 서비스를 사용합니다(예: [AWS Organizations](https://aws.amazon.com/organizations/)). [AWS Control Tower](https://aws.amazon.com/controltower/features/)와 같은 서비스는 계정 설정을 위한 블루프린트(운영 모델 지원)를 정의하고, AWS Organizations를 통해 지속적으로 거버넌스를 적용하며, 새로운 계정의 프로비저닝을 자동화할 수 있도록 함으로써 이 관리 기능을 확장합니다.
애플리케이션 팀이 표준에 추가 및 변경을 요청할 수 있는 메커니즘을 갖추는 것이 좋습니다. 이들은 새로운 표준을 만드는 데에도 기여할 수 있으며, 이는 다른 애플리케이션 팀에 도움이 될 수 있습니다. 플랫폼 팀은 이러한 추가 기능에 대한 직접적인 지원을 제공하는 것이 비즈니스 성과를 효과적으로 지원하는 방법이라고 판단할 수 있습니다.
이 모델은 기술 및 팀원에 대한 요구 사항이 상당히 높으므로 혁신에 있어서 제약이 덜합니다. 팀 간의 작업 이양으로 인해 발생하는 많은 병목 현상과 지연을 해결하는 동시에, 팀과 고객 간 관계 구축을 효과적으로 촉진할 수 있습니다.
# 운영 모델 개선
제공되는 모델은 피자 두 판 팀 원칙에 따라 워크로드 수준에서 점점 더 자율성을 높이는 방향으로 나아가고 있습니다. 기존의 접근 방식에서 탈중앙화된 DevOps를 향한 여정(피자 두 판 팀 모델로의 지속적인 진화를 위한 토대)은 시간이 걸리고 여러 기능 전반에 걸쳐 성숙도를 구축해야 한다는 점을 이해하는 것이 중요합니다. 그래서 팀과 조직이 엔터프라이즈 트랜스포메이션 여정을 진행하면서 모델 간에 전환할 수 있는 방법에 대한 예를 제공했습니다. 변경 사항 또는 모델마다 보다 자율적이면서도 여전히 조직적으로 연계된 팀으로 진화하고 있습니다.
![\[온프레미스에서 자동화된 가치 흐름 및 프로세스로의 클라우드 운영 모델 진화 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png)
팀이 조직의 발전을 지원하는 방식을 평가할 때는 모델 간의 장단점, 모델의 전환 및 발전 중에 모델에서 개별 팀의 위치, 팀의 관계와 책임이 어떻게 바뀌는지 그리고 이점이 조직에 영향을 미치는지 여부를 조사합니다. 변화는 결코 선형적이지 않다는 점을 명심하세요. 일부 모델은 특정 사용 사례나 여정의 특정 시점에 더 적합하며, 이러한 모델 중 일부는 현재 환경의 모델보다 이점을 제공할 수 있습니다.