코드형 자동화를 도입하는 방법: 코드형 인프라를 코드형 정책으로 확장하기

코드형 인프라(IaC)라는 전략적 기반을 바탕으로 조직은 운영 라이프사이클의 모든 단계에서 IT 프로세스를 자동화하기 위해 이러한 사례를 활용하기 시작했습니다. 코드형 인프라가 인프라의 구축, 프로비저닝 및 배포를 표준화하는 것처럼, IT 팀은 코드형 운영(OaC)을 도입하여 시스템 배포 후 해당 시스템의 유지 및 관리를 코드화할 수 있습니다. 그런 다음 이 접근 방식을 코드형 정책(PaC)으로 확장하여 애플리케이션과 솔루션을 위한 거버넌스, 위험 및 컴플라이언스 프로세스를 자동화할 수 있습니다.

자동화를 통해 제공을 가속화하고 효율성을 개선하는 것은 애플리케이션 및 인프라 팀의 일반적인 목표이지만, 대부분 Day 2 오퍼레이션과 거버넌스에 대한 수동 접근 방식에 계속 의존하고 있습니다. 자동화는 이러한 영역에서 많은 장점을 제공할 수 있지만, 자동화를 사용하여 Day 2 프로세스를 수행하려면 기존 팀도 새로운 툴과 방법을 배워야 합니다. OaC 및 PaC는 기존 IaC 전략을 확장하여 조직의 기존 지식과 툴을 다른 태스크에 적용할 수 있게 해주기 때문에 손쉽게 조직 문화를 변화시킬 수 있습니다.

코드형 인프라 방식을 따르는 기업은 OaC와 PaC를 도입하여 모범 사례를 코드화하고 모든 운영 프로세스에 대한 일상적인 태스크를 자동화함으로써 엔드 투 엔드 자동화를 실현할 수 있습니다. 이러한 코드형 자동화 접근 방식으로 일관되고 확장 가능한 방식으로 프로세스를 실행할 수 있으므로 팀은 수동 개입을 최소화하고 처음부터 끝까지 규정을 준수하는 애플리케이션, 인프라 및 워크로드를 구축하고 유지 관리할 수 있습니다.

이전에는 서버, 클라우드 인스턴스, 운영 체제, 스토리지, 로드 밸런서 및 기타 엔드포인트와 같은 IT 인프라를 구축하고 관리하는 일은 시간이 오래 걸리는 수동 프로세스였습니다. 그러나 인프라가 점점 컨테이너화되고 데이터센터부터 멀티클라우드, 엣지 위치에 이르는 다양한 플랫폼에 배포되면서 일부 인프라가 특히 클라우드에서 코드로 배포되고 있습니다.

코드로 배포된 인프라는 빠른 수요 증가와 확장성 요구에 대응하기 위해 더 빨리 가동될 수 있습니다. 이러한 장점 때문에 오히려 인프라 관리의 복잡성과 긴급성이 증가했으며, 조직이 매일 인프라를 프로비저닝, 배포, 해체해야 하는 경우가 많아졌습니다. 이에 대응하기 위해 IT 팀들은 이런 프로세스를 자동화할 IaC를 도입했습니다.

IaC에는 무엇이 포함되나요? 

IaC 접근 방식은 자동 실행되는 코드를 통해 인프라를 정의하고 프로비저닝하고 관리합니다. IaC를 사용하면 인프라 사양이 포함된 구성 파일이 생성되므로 올바로 구성된 인프라와 클라우드 인스턴스를 편집하고 배포하기가 더 쉬워집니다. 이러한 사양을 코드화하고 문서화하는 IaC는 팀이 문서화되지 않은 애드혹 변경을 방지하고 매번 동일한 환경을 프로비저닝할 수 있도록 지원합니다.

IaC로 인프라를 자동화하면 개발자가 애플리케이션을 개발하거나 배포를 푸시할 때마다 인프라 구성 요소를 수동으로 프로비저닝하고 관리할 필요가 없으므로 속도와 일관성을 대폭 개선하면서 인적 오류와 다운타임을 줄일 수 있습니다. 또한 이러한 접근 방식을 통해 조직은 모범 사례를 자동화 코드로 구축할 수 있으므로 팀이 공유한 전문성을 기반으로 모든 태스크가 실행됩니다.

인프라 워크플로우 자동화에 대한 가이드 읽기

IaC 전략 확장

대다수 조직에서 IaC로 트랜스포메이션하는 것은 쉽지 않은 일이었습니다. 새로운 툴을 개발하고 다양한 작업 방식을 구현하는 데 시간이 걸리기 때문입니다. 하지만 팀이 여유를 갖고 보다 유연하게 업무를 처리하면서 민첩하게 문제에 대응할 수 있게 되었다는 장점도 있었습니다. 이제 많은 자동화 툴이 IaC를 처리할 수 있게 되었고, IT 팀들은 이러한 문화 변화를 대부분 수용하여 많은 혜택을 누리고 있습니다.

IT 팀은 IaC를 위해 설계된 기존 방법과 툴을 사용하여 전체 운영 라이프사이클에서 프로비저닝, 구성, 애플리케이션 배포를 넘어 프로세스에 대한 코드형 자동화 접근 방식을 도입하기 시작했습니다. 운영 라이프사이클을 하나로 정의할 수는 없지만 일반적으로 다음과 같이 Day로 세분화됩니다.

• Day 0: 설계. 인프라 구문(construct)에 대한 빌드, 구성 및 프로비저닝을 지정합니다. 
• Day 1: 배포. 인프라를 설치, 설정 및 구성합니다.
• Day 2: 유지 관리. 배포된 인프라와 관련된 시스템을 관리, 유지 및 업데이트합니다.

IaC는 Day 0 및 Day 1에 인프라를 구축하고 프로비저닝하는 일관된 방식을 제공하지만, OaC는 애플리케이션 또는 서비스를 프로비저닝 해제해야 할 때까지 계속되는 시스템 유지 및 관리와 업데이트와 같은 Day 2 오퍼레이션에 이러한 접근 방식을 사용합니다.

시스템 작동 방식 모니터링, 업그레이드 설치, 문제 대응과 같은 Day 2 태스크는 전통적으로 수동 작업에 의존해 왔습니다. 즉, 서버나 애플리케이션이 다운되면 IT 팀은 티켓 알림을 받을 수도 있지만 이는 조사해야 할 증상일 뿐이며 문제 평가는 개별 직원이 직접 해야 하므로 물리 서버에 로그인하여 원인을 파악하고 IT 전문가를 끌어들여 문제를 해결해 왔습니다. 이러면 언젠가는 문제를 해결할 수 있지만, 기업의 운영 규모를 고려하면 시간이 오래 걸립니다.

또한 Day 2 오퍼레이션의 복잡성은 Day 0 및 Day 1 인프라 태스크만큼이나 커졌지만 Day 2 문제에는 자동화가 널리 사용되지 않았습니다. 많은 조직에서 Day 0 및 Day 1 프로세스를 자동화하기 위해 IaC를 도입했지만 이제 데이터센터부터 클라우드 환경 전반과 엣지 배포에 이르는 운영에도 동일한 접근 방식을 적용하여 무분별한 기술 확산을 막고 리소스를 확보할 수 있습니다.

코드형 운영(OaC)에는 무엇이 포함되나요?

OaC는 IaC가 자연스럽게 발전한 형태로, 인프라 및 운영 팀이 문제를 해결하면서 얻은 모든 경험과 축적된 지식을 자동화를 통해 코드화하는 것입니다. 따라서 운영 지식이 팀원 개개인에게만 있지 않고, 접근 가능한 리소스가 되는 것입니다.

OaC는 팀의 Day 2 운영 지식을 표준화, 코드화, 체계화하는 프로세스로, OaC를 도입하려는 조직은 다음을 수행해야 합니다.

• 표준화: 조직 전체에서 사용할 수 있도록 공통 코드베이스를 중심으로 표준화하여 운영 일관성을 개선합니다.
• 코드화: 운영 지식을 코드화하고 모범 사례를 자동화된 프로세스로 구축합니다. 
• 체계화: 이기종 툴과 프로세스를 통합된 엔드 투 엔드 접근 방식으로 체계화합니다.

Day 2 방법은 시스템이 점점 더 지능화되고 복잡해지며 상호 의존적이 되면서 자동으로 실행할 수 있는 코드로 변환됩니다.

모든 자동화 활용 사례와 마찬가지로, OaC의 목적은 사람을 대체하는 것이 아니라 팀이 지루한 수동 태스크를 최소화하여 미래 지향적인 프로젝트에 집중할 수 있게 하는 것입니다. Oac는 팀의 지식을 공유 접근 방식에 결합하여 여러 운영 모델과 팀 구조 전반의 협업도 지원합니다.

IaC와 OaC 방법을 거버넌스로 확장하면, 운영이 컴플라이언스 요건, 모범 사례, 기업 지침을 준수하도록 설계된 정책(규칙, 조건 또는 지침)을 시행할 때 IT 팀이 과도한 요청 기반 프로세스의 부담을 덜 수 있습니다. 

인프라와 운영이 코드로 정의되고 관리되면 보안 및 컴플라이언스 팀은 동일한 전략을 사용하여 해당 코드에 정책을 적용하고 거버넌스 관리 방식을 표준화할 수 있습니다. 이것이 코드형 정책(PaC) 접근 방식입니다.

자동화가 처음부터 컴플라이언스와 거버넌스를 보장하는 것은 아니며, 운영 라이프사이클의 모든 단계에서 IaC와 OaC가 제대로 적용될 수 있도록 정책을 일관되게 시행해야 합니다. 전통적으로 일반적인 거버넌스 방법에는 다음이 포함됩니다.

• 개인이 애드혹 솔루션을 제공하기 어려운 승인을 통해 워크플로우 구축
• 역할 기반 액세스 제어(RBAC) 또는 속성 기반 액세스 제어(ABAC)를 통해 제한된 보안 권한을 구현하여 특정 조건 또는 특성에 따라 특정 방식으로 어떤 기술을 누가 변경할 수 있는지 제어

이러한 수동 접근 방식은 오류가 발생하기 쉽고 시간이 많이 소요될 수 있습니다. PaC는 이러한 프로세스를 자동화합니다. 예를 들어, 자동화를 설정하여 IT 직원이 기업 표준을 준수하지 않는 클라우드 인스턴스를 만들지 못하게 하거나 컴플라이언스 의무를 구현하지 않는 코드 제공을 방지할 수 있습니다. RBAC와 ABAC는 여전히 필요하지만 PaC를 사용하면 수행 가능한 작업과 시기를 결정하는 훨씬 더 세분화되고 자동화된 프로세스를 만들 수 있습니다.

코드형 정책(PaC)에는 무엇이 포함되나요?

PaC를 통해 IaC 및 OaC와 유사한 전략에 따라 정책 및 보안 요구사항을 코드로 작성하여 컴플라이언스 프로세스를 자동화하면 모든 프로세스에 표준을 구축하고 팀 전체에 동일한 규칙을 일관되게 실행할 수 있습니다. PaC는 코드로 정책을 정의, 업데이트, 공유 및 실행하여 거버넌스를 중앙화하고 모든 IT 작업에 정책을 일관된 문서화 방식에 따라 효율적으로 적용할 수 있습니다.

정책을 코드로 정의하면 인프라가 가동 및 배포될 때는 인프라에, 자동화된 태스크가 실행될 때는 운영에, 정책을 더욱 원활히 적용할 수 있어 자동화 위치나 시기와 관계없이 표준 접근 방식을 적용할 수 있습니다. 예를 들어 직원이 특정 호스트에서 문제 해결을 위해 자동화를 실행하는 경우, 각 작업에 코딩된 정책으로 인해 해당 직원은 팀의 규칙을 위반하는 작업을 수행하지 못하게 됩니다.

또한 PaC는 기술 환경과 리소스를 합의된 표준에 맞게 조정합니다. 예를 들어, 팀은 PaC를 사용하여 민감한 컴퓨팅 리소스에 인터넷 직접 연결 경로(잠재적으로 보안 정책을 위반할 수 있음)를 없애거나 서비스 포트를 HTTPS와 SSH로만 제한할 수 있습니다.

AI가 다양한 시스템에서 확장성을 배가하는 역할을 하면서 IT는 인간만이 수행할 수 있는 작업, 인간만이 제어할 수 있는 작업의 한계를 넘어서고 있습니다. 자동화 개발을 가속화하기 위해 IBM watsonx Code Assistant가 통합된Red Hat® Ansible® Lightspeed와 같은 AI 서비스를 사용하는 팀이라면 처음부터 코드로 정책을 작성하고 학습 모델에 거버넌스를 제공하세요. 예를 들어, AI 툴이 학습 모델에 정책을 통합하면 콘텐츠 제작자는 의무화된 컴플라이언스 요건을 자동으로 유지 관리하는 코드를 작성할 수 있습니다.

PaC로 거버넌스를 자동화하면 AI 기반 관리를 통해 혁신적인 효율성을 제공하면서 예상되는 제어 기능을 유지 관리할 수 있으므로 IT 팀을 위해 수행된 작업에는이미 컴플라이언스가 내장되어 있습니다.

간단히 말해, 모든 유형의 코드형 자동화 트랜스포메이션은 주로 문화적 과제입니다. IT 팀은 IaC 자동화를 통해 얻은 경험을 바탕으로 동일한 방법과 툴을 사용하여 개발 라이프사이클 전반에서 더욱 효율적인 적응형 운영 방식을 활용할 수 있습니다.

DevOps 구현은 기업에 다양한 이점과 골칫거리를 가져다주었지만, 이런 광범위한 활동으로 엄청난 규모의 문화적 변화가 가능하다는 것이 입증되었습니다. 자동화는 항상 태스크 실행 방식에 변화를 가져오지만, 통합된 코드형 자동화 전략을 도입하려는 조직은 운영의 모든 단계에서 사례를 공유하여 팀의 협업 방식을 혁신해야 합니다. 이러한 활동의 핵심에는 IaC, OaC, PaC가 있습니다.

코드형 자동화 전략으로의 문화적 변화를 이끌어내려면 팀에는 다음이 필요합니다.

• 소프트웨어 개발자처럼 생각하기. 비즈니스의 모든 영역에서 현대적인 개발 및 배포 사고방식을 장려하고 Git 또는 기타 리포지토리를 사용합니다.
• 자동화 우선 사고방식을 개발하기. 새로운 프로젝트나 구축하고 싶은 것이 있을 때 구축뿐 아니라 자동화하는 방법을 먼저 생각합니다. 간단한 자동화 프로젝트에서 점차 확장해 갑니다. 
• 개인의 기술과 경험으로 시작하기. 모든 조직 구성원이 축적한 지식을 자동화에 통합하고 팀 간 콘텐츠와 전문성을 공유하여 인재 격차를 해소합니다.

코드형 자동화는 시스템 설계자와 관리자를 비롯한 모든 팀이 이러한 철학을 수용할 때 성공할 수 있습니다. 이러한 접근 방식은 일부 팀에서 가끔 자동화하는 태스크의 호환성을 기대하는 수준을 넘어, 조직 전반의 팀이 함께 만들 수 있는 공유 전략과 규칙을 제공합니다.

이러한 전략을 실행에 옮기려면 일부 활용 사례와 일부 팀에서만 작동하는 애드혹 솔루션 수준을 넘어서야 합니다. 조직이 여러 툴을 사용하여 프로세스를 실행하면 IaC와 DevOps가 지나치게 복잡해지고 기술 부채가 발생할 수 있습니다. 통합 자동화 플랫폼을 사용하면 구성, 네트워크, 인프라 또는 클라우드 태스크에 사용되는 동일한 자동화 언어를 도메인 전반의 운영 태스크로 확장하여 IT 팀이 전체 엔드 투 엔드 라이프사이클을 관리할 수 있습니다.

Red Hat Ansible Automation Platform에는 Event-Driven Ansible, 분석, 강화된 보안, 새로운 자동화 이니셔티브를 시작하는 데 필요한 인증 및 검증된 콘텐츠의 광범위한 에코시스템 등 전사적 자동화를 구현하는 데 필요한 모든 툴이 포함되어 있습니다. 사람이 읽을 수 있는 YAML을 사용하므로 다양한 기술 수준의 사용자가 조직 전반에서 자동화 콘텐츠를 공유, 검사 및 관리할 수 있습니다. 

Ansible Automation Platform을 사용하는 조직은 운영, 인프라 및 애플리케이션 팀의 경험을 YAML 기반 Ansible Playbook 및 Ansible Rulebook으로 코드화할 수 있습니다. 플레이북과 룰북을 사용하여 알려진 솔루션 패턴을 코드형 자동화 접근 방식으로 구축할 수 있으며, 특정 이벤트가 발생하면 Event-Driven Ansible이 해당 자동화를 트리거할 수 있습니다.

플레이북과 룰북에 전문 지식을 통합함으로써 팀은 IT 대응을 자동화하여 구성 드리프트를 제한하고, 장기 유지 관리 문제를 최소화하며, 평균 문제 해결 시간(MTTR)을 개선할 수 있습니다. Event-Driven Ansible의 모듈식 설계는 운영 라이프사이클의 모든 단계 활용 사례에서 위치와 시간에 상관없이 여러 도메인에 걸쳐 IT 작업을 자동화하도록 지원합니다.

Event-Driven Ansible에 대해 자세히 알아보기

코드형 자동화를 더욱 손쉽게 이용할 수 있게 해주는 IBM watsonx Code Assistant 통합 Red Hat Ansible Lightspeed는 분야별 전문성을 팀과 도메인 전반에서 확장되는 신뢰할 수 있는 YAML 코드로 변환할 수 있게 해줍니다. 사용자는 태스크 요청을 자연어로 입력할 수 있으며, Ansible Lightspeed는 IBM watsonx Foundation 모델과 상호 작용하여 Ansible Playbook을 만들기 위한 코드 권장 사항을 생성합니다. 이 서비스는 다양한 경험 수준을 가진 팀원들이 생산성, 효율성, 정확성을 높여 조직 전반에서 더욱 일관된 자동화를 추진할 수 있게 도와줍니다.

Red Hat은 사전 구성된 Ansible Automation Platform 환경에서 인터랙티브 랩을 제공합니다. 이 인터랙티브 랩을 사용하여 IT 사례를 효율적으로 생성, 관리, 확장하는 방법을 실험, 연습 및 학습할 수 있습니다. 또한 신속한 개발 및 배포, 간소화된 운영 및 분석, 일관된 엔드 투 엔드 사용자 환경 등을 포함하여 다양하고 효율적으로 실습할 수 있는 방법을 알려드립니다.