8.2 코드형 인프라와 구성

개요와 동기

코드형 인프라(IaC)는 인프라(네트워크, 서버, 데이터베이스, 로드 밸런서, 권한)를 수동 콘솔 클릭이나 즉흥적 스크립트가 아니라 기계가 읽을 수 있는 정의 파일로 정의하고 프로비저닝한다는 뜻입니다. 구성 관리는 같은 생각을 시스템이 존재한 뒤의 설정과 상태로 확장합니다. 둘이 함께 인프라를 손으로 만든 취약한 산출물에서, 애플리케이션 코드에 쓰는 것과 같은 엔지니어링 규율의 버전 관리되고, 리뷰 가능하고, 재현 가능한 산출물로 바꿉니다.

큰 팀에게 IaC는 편의가 아니라 필수입니다. 수백 명의 엔지니어가 환경을 필요로 하고 수천 개의 자원이 리전과 계정에 걸쳐 일관되게 유지되어야 할 때, 수동 프로비저닝은 따라가지도, 올바르게 유지되지도 못합니다. 사람이 구성한 인프라는 조만간 아무도 완전히 이해하지 못하고 장애 후 믿을 만하게 다시 만들 수 없는 고유한 “스노플레이크” 서버로 표류합니다. 인프라를 코드화하면 일관되고, 감사 가능하고, 폐기 가능해집니다. 어떤 환경이든 정의로부터 다시 만들 수 있고, 모든 변경이 리뷰 가능한 diff입니다.

기업과 정부 조직은 하나 더 결정적인 이점을 얻습니다. 시행 가능한 거버넌스입니다. 저장 시 암호화, 네트워크 분할, 승인된 리전, 비용 배분을 위한 태깅 같은 보안 및 컴플라이언스 요건을 코드에 직접 내장하고 무언가 프로비저닝되기 전에 자동으로 검사할 수 있습니다. 사후에 인프라를 감사하며 위반을 쫓는 대신, 컴플라이언스를 지키지 않는 인프라가 아예 존재하지 못하게 합니다. 탐지에서 예방으로의 이 전환이 IaC가 현대 플랫폼 실천의 기초가 된 핵심 이유입니다.

핵심 원칙

단계를 기술하는 명령형 스크립트보다 원하는 상태를 기술하는 선언형 정의를 선호하십시오.
모든 인프라 정의를 버전 관리에 저장하고 다른 코드처럼 리뷰하십시오.
인프라를 불변으로 다루십시오. 제자리에서 수정하는 대신 교체합니다.
프로비저닝을 멱등하게 만들어 같은 정의를 반복 적용해도 같은 결과가 나오게 하십시오.
실제 환경이 선언된 정의에서 벌어지는 드리프트를 지속적으로 탐지하고 조정하십시오. 진실의 원천은 라이브 시스템이 아니라 코드입니다.
복사하여 붙이는 대신 재사용 가능하고 버전 관리되는 모듈로 인프라를 구성하십시오.
정책을 코드로 코드화하십시오. 조직의 규칙을 기계로 검사 가능한 코드로 표현해 가드레일이 권고가 아니라 자동이 되게 합니다.
비밀을 정의 밖에 두고 전용 비밀 관리자에서 참조하십시오.

권장 사항

선언형 도구를 고르고 모듈을 중심으로 구조화한다

Terraform, Pulumi, CloudFormation 같은 클라우드 네이티브 옵션 등 선언형 IaC 도구를 채택하고, 파편화된 도구 지형을 피하도록 조직 전체에서 표준화하십시오. 핵심 아키텍처 실천은 모듈성입니다. 흔한 패턴(컴플라이언스를 지키는 네트워크, 강화된 데이터베이스, 표준 서비스)을 담은 작고, 잘 문서화되고, 버전 관리되는 모듈을 만드십시오. 그러면 팀은 원시 자원을 작성하는 대신 이 모듈로 환경을 구성합니다. 이는 좋은 기본값과 보안 설정을 자동으로 퍼뜨리고 중복을 극적으로 줄입니다.

상태를 의도적으로 관리한다

선언형 도구는 코드와 실제 자원 사이의 매핑을 상태 파일에서 추적합니다. 상태를 공유되고, 암호화되고, 접근이 통제되는 백엔드에 원격으로 저장하고, 동시 수정이 상태를 오염시키지 못하도록 잠금을 쓰십시오. 상태를 노트북에 두지 말고, 최후의 복구 조치가 아니면 손으로 편집하지 마십시오. 상태는 자원 메타데이터와 비밀을 담을 수 있어 민감하므로 그에 맞게 보호하십시오.

골든 이미지로 불변 인프라를 만든다

실행 중인 서버를 패치하는 대신, 버전 관리되는 “골든 이미지”(미리 구성되고 강화된 머신 또는 컨테이너 이미지)를 굽고 거기서 새 인스턴스를 배포하십시오. 변경이나 패치가 필요하면 새 이미지를 빌드해 롤아웃하고 옛 인스턴스를 퇴역시킵니다. 이는 구성 드리프트를 없애고, 롤백을 사소하게 만들고, 모든 인스턴스가 동일하고 알려진 좋은 빌드까지 추적 가능하게 유지합니다. 자동화된 이미지 파이프라인은 보안 강화와 스캔을 포함해, 컴플라이언스가 이미지 수준에 내장되게 해야 합니다.

구성 드리프트를 탐지하고 조정한다

드리프트는 실제 환경이 정의에서 벌어질 때 일어나며, 보통 누군가 긴급한 수동 변경을 했기 때문입니다. 실제 상태를 선언된 상태와 비교하고 차이를 표시하는 정기적 드리프트 탐지를 돌리십시오. 드리프트를 결함으로 다루십시오. 수동 변경을 그대로 두는 것이 아니라 코드를 갱신하고 다시 적용해 조정합니다. 지속적인 구성 강제가 필요한 시스템에는 호스트를 선언된 상태로 지속적으로 수렴시키는 구성 관리 도구를 쓰십시오.

GitOps와 풀 기반 배포를 채택한다

GitOps 모델에서는 Git 저장소가 시스템의 선언된 원하는 상태를 담고, 대상 환경 안에서 도는 자동화된 에이전트가 그 상태를 지속적으로 끌어와 실제 시스템을 그에 맞게 조정합니다. 이는 전통적인 푸시 모델을 뒤집습니다. 환경이 자기 구성을 스스로 끌어오므로 어떤 외부 시스템도 환경을 바꿀 상시 자격 증명이 필요 없습니다. GitOps는 완전한 감사 추적(모든 변경이 커밋), 쉬운 롤백(커밋을 되돌림), 강한 드리프트 교정(에이전트가 원하는 상태를 지속적으로 재주장)을 줍니다. 쿠버네티스와, 단일하고 리뷰 가능한 진실의 원천을 원하는 조직에 특히 강력합니다.

코드로서의 정책으로 가드레일을 시행한다

허용된 리전, 의무적 암호화, 필수 태그, 금지된 공개 노출 같은 조직의 규칙을 Open Policy Agent(OPA)나 Sentinel 같은 플랫폼 네이티브 정책 엔진 도구를 써서 기계로 검사 가능한 정책으로 표현하십시오. 프로비저닝 전에 파이프라인에서 이 검사를 돌려 위반이 자동으로 막히게 하십시오. 코드로서의 정책은 보안 팀의 의도를 실행 가능하고 균일하게 적용되는 통제로 바꾸며, 수동 리뷰가 결코 할 수 없던 방식으로 수천 개의 변경으로 확장됩니다.

장단점

선택	장점	단점	가장 적합한 곳
선언형 IaC (Terraform/Pulumi)	재현 가능, 리뷰 가능, 드리프트 탐지 가능	학습 곡선. 상태 관리의 복잡성	규모에서 거의 모든 팀
명령형 스크립트	익숙함. 일회성에 유연	멱등하지 않음. 감사와 반복이 어려움	좁은 과도기적 경우
불변 + 골든 이미지	드리프트 없음. 사소한 롤백	이미지 빌드 파이프라인 오버헤드	일관성이 필요한 단말 군단
가변 구성 관리	세밀한 지속적 통제	드리프트 위험. 느린 수렴	레거시 또는 오래 사는 호스트
GitOps (풀 기반)	강한 감사 추적. 자가 복구	클러스터 내 에이전트와 Git 규율 필요	쿠버네티스와 클라우드 네이티브
코드로서의 정책	자동적이고 균일한 가드레일	선행 정책 작성 노력	규제 환경

주된 긴장은 유연성 대 통제입니다. 수동과 명령형 접근은 단일 변경에는 더 빠르게 느껴지지만, 규모에서 치명적이 되는 숨은 비일관성을 쌓습니다. 선언형, 불변, 정책으로 다스려지는 인프라는 더 많은 선행 투자와 실제 문화적 전환을 요구하지만(엔지니어가 빠른 콘솔 변경을 멈춰야 하므로), 신뢰성, 감사 가능성, 무엇이든 필요할 때 다시 만들 수 있는 능력으로 그 투자를 몇 배로 갚습니다.

팀과 논의할 질문

공유 모듈 라이브러리는 누가 소유하며, 모듈의 개선은 그것을 쓰는 모든 팀에 어떻게 닿습니까? 모듈은 수정과 강화된 기본값이 전파될 때만 보답하며, 이는 모두가 복사해 가는 폴더가 아니라 분명한 소유권과 실제 버전 관리를 요구합니다. 컴플라이언스를 지키는 네트워크와 강화된 데이터베이스 모듈을 누가 유지하는지, 어떻게 버전을 관리하는지(변경 이력이 있는 시맨틱 버전 관리), 팀이 난리 없이 업그레이드를 어떻게 끌어오는지 정하십시오. 규모에서 이것은 잘못된 구성을 한 번 고치는 것과 천 개의 손으로 편집한 자원에 걸쳐 그것을 쫓아다니는 것의 차이입니다. 증거를 가져오십시오. 같은 패턴의 구별되는 사본이 오늘 몇 개 있는지, 보안 수정이 모든 환경에 닿는 데 얼마나 걸리는지, 팀이 모듈 버전을 고정하는지 떠다니게 두는지입니다. 핵심 패치가 영역 전체에 며칠 안에 닿지 못한다면, 모듈성은 겉치레입니다.
드리프트 탐지 주기는 얼마이며, 드리프트를 찾으면 실제로 무슨 일이 일어납니까? 드리프트는 실제 환경이 선언된 상태에서 조용히 벌어지는 것으로, 보통 긴급한 콘솔 변경에서 오며, 이를 용인하면 코드가 허구가 됩니다. 실제 상태를 선언된 상태와 얼마나 자주 비교할지(야간이 합리적인 기본값) 정하고, 더 중요하게는 대응을 정하십시오. 수동 변경을 그대로 두지 않고 코드를 갱신하고 다시 적용해 조정합니다. 규제 환경에서 이것은 통제 요건입니다. 감사자는 선언된 상태가 현실과 지속적으로 일치하기를 필요로 하기 때문입니다. 현재 숫자를 가져오십시오. 매주 몇 개의 자원이 드리프트하는지, 얼마나 오래 드리프트한 채 있는지, 아무도 이를 닫을 책임이 있는지입니다. 모든 드리프트를 소유자가 있는 결함으로 다루지 않으면, 아무도 코드를 신뢰하지 않을 때까지 진실 원천의 보장이 침식됩니다.
GitOps와 풀 기반 조정으로 옮겼습니까, 아니면 여전히 외부 시스템이 프로덕션을 바꿀 상시 자격 증명을 쥐고 있습니까? 풀 모델에서는 대상 환경 안의 에이전트가 실제 시스템을 Git에 맞게 지속적으로 조정하여, 어떤 외부 시스템도 쓰기 접근을 쥘 필요가 없어지고, 원하는 상태를 재주장해 드리프트가 스스로 교정됩니다. 모든 변경이 커밋이고 어떤 운영자도 상시 프로덕션 자격 증명이 필요 없으므로 이는 강한 보안 및 감사 태세입니다. 비용은 실제입니다. 운영할 클러스터 내 에이전트와 엄격한 Git 규율이므로, 현재의 푸시 기반 자동화에 견주어 저울질하십시오. 현재 프로덕션을 직접 바꿀 수 있는 사람과 무엇의 목록, 그 변경이 남기는 감사 추적을 가져오십시오. 쿠버네티스와 고보증 구역에서는 이 전환이 보통 값하고, 소수의 정적 자원에는 과할 수 있습니다.
인프라 상태는 어떻게 저장, 잠금, 접근 통제되며, 상태가 오염되거나 사라지는 날 무슨 일이 일어납니까? 상태는 코드와 실제 자원 사이의 지도이므로, 사라지거나 손상된 상태 파일은 도구가 자신이 만든 자원을 보지 못하게 하고 누군가를 파괴적인 재적용으로 유혹할 수 있습니다. 큰 팀에서는 위험이 곱해집니다. 공유 상태에 대해 적용하는 많은 엔지니어에게는 동시 실행이 서로를 덮어쓰지 못하도록 원격, 암호화, 잠금이 있는 백엔드가 필요하기 때문입니다. 하나의 큰 상태의 편의를 그것이 만드는 피해 범위에 견주어 저울질하고, 단 하나의 실수가 모든 것을 무너뜨리지 못하도록 환경별 또는 도메인별로 상태를 나누는 것을 고려하십시오. 사실을 가져오십시오. 오늘 상태가 어디에 사는지, 잠금이 시행되는지, 누가 읽을 수 있는지(비밀을 담을 수 있음), 복구를 예행연습해 본 적이 있는지입니다. 기업과 정부 환경에서는 상태 백엔드를 자체 백업, 감사 로그, 복구 런북이 있는 민감하고 접근이 통제되는 자산으로 다루십시오. 그것을 잃는 것은 무엇이 존재하는지에 대한 기록을 잃는 것이기 때문입니다.
진짜 긴급 상황이 수동 변경을 요구할 때, 허가된 비상 경로는 무엇이며, 그 변경은 어떻게 코드로 되돌려 접어 넣습니까? 모든 성숙한 IaC 실천은 결국 파이프라인을 기다리는 것이 받아들일 수 없는 새벽 3시 사고를 만나며, 정직한 질문은 수동 변경이 일어나는지가 아니라 그것을 어떻게 가두는지입니다. 누가 파이프라인을 우회할 수 있는지, 무엇을 건드릴 수 있는지, 행동이 어떻게 기록되는지, 변경이 코드로 조정되거나 되돌려져야 하는 기한을 미리 정하십시오. 그 합의가 없으면 긴급 예외가 조용히 일상의 습관이 되고 ClickOps가 뒷문으로 돌아옵니다. 증거를 가져오십시오. 지난 분기에 대역 외 변경이 몇 건 있었는지, 각각 얼마나 오래 조정되지 않은 채 있었는지, 드리프트 탐지가 실제로 그것을 잡았는지입니다. 규제된 조직과 공공 기관에서는 자동 로깅이 있는 문서화된 비상 절차가 통제 요건인 경우가 많습니다. 감사자는 긴급 상황이 가능하다는 것과 각각이 추적을 남기고 시스템을 선언된 상태로 되돌린다는 것을 모두 기대하기 때문입니다.
보안 및 컴플라이언스 기준의 얼마가 나쁜 변경을 자동으로 막는 정책으로 표현되어 있고, 얼마가 문서에 살면서 누군가의 기억에 의존합니까? 위키에 산문으로 쓰인 가드레일은 마감 압박 아래서 모든 엔지니어가 읽고 적용하는 데 의존하므로 으레 위반되는 반면, 같은 규칙을 코드로서의 정책으로 표현하면 컴플라이언스를 지키지 않는 변경이 프로비저닝되기 전에 거부됩니다. 큰 조직에서 이것은 보안 팀의 의도가 리뷰 병목이 되지 않고 수천 개의 변경으로 확장되는 유일한 방법입니다. 정책을 작성하고 유지하는 선행 비용을 수동 리뷰와 사후 시정의 반복 비용에 견주어 저울질하고, 어느 통제(암호화, 승인된 리전, 의무적 태그, 공개 노출 금지)가 하드 관문으로 시행할 만큼 협상 불가인지 정하십시오. 현재 기준 규칙의 목록을 가져와 어느 것이 자동화되고 어느 것이 권고인지, 각각이 실제로 얼마나 자주 위반되는지 표시하십시오. 기업과 정부 맥락에서 자동화된 정책은 감사를 몇 주의 수동 증거 수집에서 시행되는 통제에 대한 질의로 바꾸고, 컴플라이언스를 탐지에서 예방으로 바꿉니다.

분야별 관점

스타트업. 속도가 이기므로 전체 스택을 하나의 선언형 저장소에 두고(Terraform이 흔한 기본값), 상태를 관리형 암호화 백엔드에 두고, 팀이 세 명이어도 모든 변경을 풀 리퀘스트로 보내십시오. 무거운 플랫폼 장치는 건너뛰십시오. 중앙 모듈 팀도 아직 정책 엔진도 없이, 버전 관리와 콘솔에서 절대 클릭하지 않는 규율만 있으면 됩니다. 그것만으로 돈을 아끼려고 철거하고 다음 시연을 위해 다시 만들 수 있는 재현 가능한 환경을 얻습니다.

소기업. 전담 플랫폼 전문가가 없으니 유지할 수 없는 맞춤 도구를 세우기보다 관리형 서비스와 클라우드 제공자나 벤더가 이미 지원하는 IaC에 기대십시오. 운영할 사람이 없는 골든 이미지 파이프라인을 만드는 것보다, 합리적인 기본값(암호화, 백업, 패치)이 대신 처리되는 호스팅 플랫폼을 사는 쪽을 선호하십시오. 목표를 좁게 구성하십시오. 장애나 떠나는 계약자 후에 다시 만들 수 있도록 소수의 핵심 자원을 코드에 넣는 것입니다.

대기업. 핵심 문제는 많은 팀, 계정, 리전에 걸친 일관성이므로, 버전 관리되는 공유 모듈 라이브러리, 원격 잠긴 상태, 파이프라인에서 시행되는 코드로서의 정책에 투자하십시오. 중앙 플랫폼 팀이 강화된 모듈과 가드레일을 공표하고 제품 팀은 그 안에서 셀프서비스하며, 드리프트 탐지가 지속적으로 돌아 수천 개의 자원이 알려진 상태에 머뭅니다. 모듈과 정책을 유지하는 지속적 비용에 예산을 잡으십시오. 그 가치는 수정이나 강화된 기본값이 모든 곳에 한꺼번에 전파되는 데서 오기 때문입니다.

정부. 조달 규칙, 인증, 공적 책임이 불변 인프라, 서명된 커밋, 인증된 구역 안의 GitOps 조정 쪽으로 이끌어, 어떤 운영자도 프로덕션을 바꿀 상시 자격 증명을 쥐지 않게 합니다. 필수 보안 기준을 골든 이미지와 코드로서의 정책에 코드화하고, 커밋 이력이 변조 흔적이 드러나고 지속적으로 이용 가능한 감사 증거 역할을 하게 하십시오. 여러분을 가두는 독점 형식보다 개방적이고 이식 가능한 도구를 선호하고, 긴급 변경도 구성 통제 요건을 충족하도록 비상 절차와 그 로깅을 명시적으로 만드십시오.

사례

스타트업. 다섯 명의 스타트업이 VPC, 데이터베이스, 컨테이너 서비스인 전체 AWS 구성을 단일 Terraform 저장소에 정의하고, 상태는 암호화된 S3 백엔드에 두고 DynamoDB로 잠급니다. 모든 변경이 풀 리퀘스트를 거치므로 혼자 온콜인 엔지니어도 apply를 실행하기 전에 무엇이 바뀔지 정확히 볼 수 있습니다. 큰 시연을 위해 새 스테이징 환경이 필요하면 작은 모듈을 복사해 몇 분 안에 세우고, 클라우드 청구서를 낮게 유지하려고 똑같이 빨리 철거합니다.

기업. 한 다국적 소매업체가 여러 클라우드 계정과 리전에 걸쳐 인프라를 관리합니다. 중앙 플랫폼 팀이 컴플라이언스를 지키는 네트워크, 데이터베이스, 서비스 뼈대를 위한 버전 관리되는 Terraform 모듈을 공표하고, 암호화나 비용 배분 태그가 없는 자원을 거부하는 OPA 정책을 시행합니다. 제품 팀은 자기 환경을 셀프서비스로 프로비저닝하지만 모든 변경은 정책이 자동으로 검사되는 파이프라인을 거칩니다. 드리프트 탐지가 매일 밤 돌아 모든 수동 변경에 티켓을 열어, 수천 개의 자원을 알려지고 컴플라이언스를 지키는 상태로 지속적으로 유지합니다.

정부. 고보증 환경에서 운영하는 한 국방 기관이 필수 보안 기준을 내장한 강화된 골든 이미지를 만들고, 그 이미지에서 불변 인스턴스만 배포합니다. 모든 인프라는 Git에 선언되고 인증된 구역 안의 GitOps 에이전트가 조정하므로, 어떤 운영자도 프로덕션을 직접 바꿀 상시 자격 증명을 쥐지 않습니다. 모든 변경은 서명된 커밋입니다. 이는 감사자에게 완전하고 변조 흔적이 드러나는 이력을 주고, 수동 증거 수집 없이 지속적 모니터링과 구성 통제 요건을 충족합니다.

비즈니스 사례: 동기, ROI, TCO

IaC의 ROI는 속도, 신뢰성, 위험 감소에서 나옵니다. 티켓 기반 수동 프로비저닝에 몇 주 걸리던 환경을 몇 분에 만들 수 있어 엔지니어를 풀어 주고 프로젝트를 가속합니다. 재현성은 어떤 환경이든 코드로 다시 만들 수 있으므로 장애 후 복구 시간을 대폭 줄입니다. 자동화된 정책 시행은 보안 사고와 감사 지적의 빈도와 비용을 줄이며, 규제 조직에서는 상당할 수 있습니다.

TCO 장부에서 도입 비용에는 도구, 교육, 모듈과 정책 라이브러리의 구축, 수동 변경을 멈추는 규율이 포함됩니다. 도입하지 않는 비용은 더 가파르고 시간이 지나며 복리로 쌓입니다. 아무도 다시 만들 수 없는 스노플레이크 인프라, 느리고 오류 나기 쉬운 프로비저닝, 침해로 이어지는 보안 구성 오류, 몇 주의 수동 노력을 먹는 감사입니다. 리더십에는 IaC를 인프라를 관리되지 않는 부채에서 거버넌스가 적용되고 재현 가능한 자산으로 바꾸는 것으로, 보안과 컴플라이언스를 열망이 아니라 자동으로 만드는 메커니즘으로 구성하십시오.

안티패턴과 함정

프로덕션의 ClickOps. 콘솔에서 손으로 변경하면 드리프트가 보장되고 재현성이 파괴됩니다.
코드 속 비밀. 정의 파일에 자격 증명을 하드코딩하면 버전 이력과 상태로 유출됩니다.
모놀리식이고 모듈화되지 않은 정의. 아무도 감히 바꾸지 못하는 하나의 거대한 구성은 그것이 대체한 수동 구성만큼 취약해집니다.
관리되지 않는 상태. 로컬이거나 잠기지 않은 상태 파일은 오염과 인프라 손실로 이어집니다.
용인된 드리프트. 수동 변경을 그대로 두면 코드가 허구가 될 때까지 진실 원천의 보장이 침식됩니다.
문서로서의 정책. 자동 검사가 아니라 위키에 사는 규칙은 으레 위반됩니다.
복사하여 붙이기의 확산. 팀 간에 구성을 복제하면 수정과 개선이 결코 퍼지지 않습니다.

성숙도 모델

1단계: 시작. 인프라가 콘솔과 즉흥적 스크립트로 수동 프로비저닝됩니다. 환경은 일관되지 않고, 문서화되지 않았으며, 믿을 만하게 재현할 수 없고, 장애로부터의 복구는 느리고 불확실합니다.

2단계: 발전. 일부 인프라가 코드화되지만 실천은 팀마다 다릅니다. 상태 관리가 일관되지 않고, 드리프트가 흔하며, 비밀이 때로 정의로 새고, 정책은 시행된다 해도 수동 리뷰로 이루어집니다.

3단계: 표준화. 선언형 IaC가 조직 전체의 문서화된 표준으로, 관리되는 원격 잠긴 상태를 가진 공유 버전 관리 모듈로 구축됩니다. 코드로서의 정책이 파이프라인에서 가드레일을 시행하고, 비밀은 전용 관리자에서 참조되며, 드리프트 탐지가 정기적 주기로 돕니다.

4단계: 관리. 실천이 기준선에 대해 측정됩니다. 드리프트율과 평균 조정 시간, 팀 전반의 모듈 버전 채택, 막힌 정책 위반 대 빠져나간 위반, 프로비저닝 리드 타임, 실제로 코드 아래 있는 자원의 비율을 추적합니다. 이 지표가 변경을 관문 통제하고 투자할 곳을 이끌어, 결정이 일화가 아니라 증거에 근거합니다.

5단계: 오케스트레이션. 인프라가 불변이고 GitOps로 구동되며, 드리프트에 대해 자가 복구하고, 컴플라이언스 증거가 자동으로 생산됩니다. 모듈과 정책 라이브러리는 실제 사용과 사고로 지속적으로 개선되고, 인프라 실천은 보안, 비용, 전달 계획과 통합되어 요건이 이동함에 따라 영역 전체가 적응합니다.

논의를 위한 아이디어

중앙에서 다스려지는 모듈과 맞춤 인프라를 정의하는 팀 자율 사이의 선은 어디에 두어야 합니까?
ClickOps를 정상화하지 않고 파이프라인을 우회해야 하는 진짜 긴급 변경을 어떻게 다룹니까?
많은 계정과 팀에 걸쳐 상태를 관리하고 보호하는 올바른 전략은 무엇입니까?
가변 구성 관리는 언제 완전한 불변 인프라 대비 여전히 정당화됩니까?
코드로서의 정책 라이브러리를 진화하는 보안 및 규제 요건과 어떻게 정렬되게 유지합니까?
IaC 이전부터 있던 레거시 인프라의 현실적인 이전 경로는 어떤 모습입니까?

핵심 요점

인프라를 선언적으로 정의하고, 버전을 관리하고, 리뷰 가능하고 재현 가능한 코드로 다루십시오.
좋은 기본값을 퍼뜨리고 중복을 없애도록 작고 버전 관리되는 모듈로 구축하십시오.
드리프트를 없애고 롤백을 단순하게 하도록 불변 인프라와 골든 이미지를 선호하십시오.
상태를 의도적으로 관리하고 비밀을 정의 밖에 두십시오.
강한 감사 추적과 자가 복구 조정을 위해 GitOps를 채택하십시오.
컴플라이언스가 사후에 감사되는 것이 아니라 예방으로 존재하게 되도록 코드로서의 정책으로 가드레일을 시행하십시오.

참고 문헌과 더 읽을거리

Kief Morris, Infrastructure as Code: Dynamic Systems for the Cloud Age.
Yevgeniy Brikman, Terraform: Up & Running.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
Weaveworks, “GitOps” foundational writings (Alexis Richardson et al.).
Open Policy Agent documentation and the Rego policy language.
NIST Special Publication 800-53, security and privacy controls (configuration management family).