Ch01 코드형 인프라란

한 줄 정의

코드형 인프라(IaC)는 변경을 막아서가 아니라 변경을 빠르고 안정적으로 반복함으로써 품질과 안정성을 얻는, 클라우드 시대의 시스템 관리 방식입니다.

쉽게 말하면

시스템의 안정성을 몸의 건강이라고 해 봅시다. 다칠까 봐 두려워 움직이지 않으면(변경을 막으면) 근육이 굳고 뼈가 약해져, 정작 넘어졌을 때 크게 다칩니다. 반대로 준비 없이 무리하게 움직이면(마구잡이 변경) 당장 다칩니다.

건강한 몸은 올바른 자세로 자주, 조금씩 운동하는 데서 옵니다. 코드형 인프라가 말하는 것이 정확히 이것입니다. 변경(운동)을 피하는 것이 아니라 작게 나눠 자주 수행하고 매번 확인(테스트)하는 루틴을 만들어, 변경 자체를 안전한 행위로 만드는 것입니다.

왜 중요한가?

클라우드와 자동화 도구를 도입했는데도 팀이 빨라지지 않는 이유를 설명합니다. 인프라 리소스의 규모·복잡성·다양성이 늘어나는 속도가 더 빠르기 때문입니다. 여기에 혼란이 두려워 변경 관리 프로세스를 강화하면 역설이 생깁니다.

• 변경을 제한하면 클라우드 기술을 쓰는 장점 자체가 사라집니다.

• 그래도 사용자는 클라우드의 장점을 원하므로 프로세스를 우회합니다. 최악의 경우 위험 관리를 통째로 무시하고 미래 결과에 대한 고려 없이 시스템을 구성하는 카우보이 IT 로 흘러갑니다.

즉 자동화 도구와 클라우드 플랫폼의 도입만으로는 아무것도 보장되지 않으며, 기술의 사용 방법이 성공 여부를 결정합니다.

데브옵스와 코드형 인프라

데브옵스는 소프트웨어의 계획·구축·실행에 관련된 개발, 운영, 관리 간 마찰을 줄이기 위한 움직임입니다. 기술이 먼저 눈에 띄지만 업무 흐름과 효율성에 가장 큰 영향을 미치는 것은 문화, 사람, 프로세스입니다. 코드형 인프라 같은 기술과 방법론은 조직 간 격차를 없애고 협업을 개선하는 데 사용되어야 합니다.

핵심 내용

구시대에서 클라우드 시대로

구분	구시대	클라우드 시대
리소스	물리 하드웨어	가상 리소스
프로비저닝	몇 주 소요	수 분 소요
변경 비용	높음	낮음
변경의 의미	장애 원인, ‘관리’·‘제어’ 대상	학습과 개선의 수단
목표	변경 실패 위험 감소	개선 속도 극대화
배포·테스트	배치로 배포, 마지막에 테스트	작은 단위로 배포, 지속적으로 테스트
릴리스 주기	긺	짧음
구조	모놀리식	마이크로서비스
구성 방법	GUI·수작업	코드

과도하게 철저한 사전 계획과 엄격한 변경 검토 같은 기존 거버넌스 모델은 틀린 것이 아니라, 변경이 느리고 비싸던 구시대 기술에 최적화된 것 입니다. “변경 후에 또 다른 변경이 없기를 바라며 미리 추가 작업을 해두는” 방식은 변경이 비쌀 때만 타당합니다. 클라우드에서는 빠르고 저렴하게 변경할 수 있으므로 이 전제가 깨졌고, 변경 속도를 활용해 지속적으로 배우고 개선하는 쪽이 합리적입니다.

안정성은 변경에서 비롯된다

변경은 프로덕션 시스템에 가장 큰 위험이지만, 동시에 시스템을 향상시키는 유일한 방법입니다. 계획되지 않은 운영 중단의 80%가 변경에서 발생하지만, Accelerate 연구는 수시로 수행하는 안정적인 변경이 조직의 성공과 연관됨을 보여줍니다.

“자동화할 만큼 변경이 잦지 않다”는 반대는 시스템을 빌드하고 나면 업무가 끝난다는 기대에서 나오지만, 현실의 시스템은 폐기 전까지 계속 변합니다. 새 기능을 위한 데이터베이스 추가, 애플리케이션 서버 업그레이드, 예상보다 빠른 사용량 증가에 따른 증설, 보안 취약점 패치, OS·패키지 지원 종료(EOL) 대응, 성능 튜닝 — 모두 일상적인 인프라 변경입니다.

패치되지 않은 시스템은 불안정하고 취약합니다. 오류 복구가 느리거나 변경마다 긴 다운타임이 생기거나 장애가 잦다면 안정성이 낮은 것입니다. 변경을 잘하는 능력이 곧 안정성입니다.

자동화는 나중이 아니라 설계의 일부다

“일단 구축하고 자동화는 나중에”라는 접근이 좋지 않은 이유는 다음과 같습니다.

• 자동화의 이점 대부분은 구축·배포 과정 자체에서 나옵니다. 작업이 끝난 뒤 자동화하면 그 이점을 놓칩니다.

• 자동화는 자동 테스트 환경 구성과 장애 시 빠른 리빌드를 가능하게 합니다. 빌드 프로세스의 일부일 때 더 나은 인프라가 만들어집니다.

• 이미 구축된 시스템에 자동화를 붙이는 것은 어렵습니다. 자동화는 시스템 설계와 구현의 일부라서, 고려 없이 만든 시스템에 추가하려면 설계·구현을 상당 부분 바꿔야 합니다.

자동화 없이 구축된 클라우드 인프라는 수작업 관리와 장애 대응 비용이 빠르게 늘어 예상보다 빨리 가치를 잃습니다. PoC도 예외가 아닙니다. 인프라를 자동화로 관리할 계획이라면 자동화 작동 방식도 검증 대상이므로 자동화 역시 PoC의 일부여야 합니다.

해결책은 시스템을 점진적으로 구축하면서 동시에 자동화를 진행하는 것입니다.

네 가지 주요 지표

Accelerate 연구(DORA)가 파악한, 조직의 목표 달성과 강한 상관관계를 갖는 소프트웨어 딜리버리·운영 성능 지표입니다.

지표	측정 대상
배포 수행 시간	변경을 구현·테스트·배포하는 데 걸리는 시간
배포 빈도	프로덕션에 변경을 배포하는 빈도
변경 실패율	장애·롤백·긴급 수정을 유발한 변경의 비율
평균 복구 시간(MTTR)	계획되지 않은 중단에서 서비스를 복구하는 시간

앞의 둘은 속도, 뒤의 둘은 안정성 지표입니다. 목표를 잘 달성하는 조직은 넷 모두에서 좋은 성과를 냅니다 — 속도와 품질이 트레이드오프가 아니라는 정량적 근거입니다.

세 가지 핵심 실행 방법

1. 모든 것을 코드로 정의한다

• 재사용성: 인스턴스 단위로 빠르게 수정·재빌드할 수 있고, 다른 사용자도 동일한 인스턴스를 만들 수 있습니다.

• 일관성: 코드로 빌드한 시스템은 매번 같은 방식으로 빌드되어 예측 가능하고, 안정적인 테스트와 지속적인 배포가 가능해집니다.

• 투명성: 코드를 보면 시스템이 어떻게 구축되었는지 알 수 있어 검토·개선 제안·규정 준수 감사가 가능합니다.

2. 코드를 지속적으로 테스트하고 딜리버리한다

품질은 테스트로 검사하는 것이 아니라 테스트를 통해 구축하는 것입니다. 작업이 모두 끝날 때까지 기다리지 않고 진행 중에 통합하고 테스트합니다. 브랜치에 쌓아두다 완료 시점에만 합치는 대신 최소 하루 단위로 모든 코드를 병합·테스트하고(CI), 병합된 코드를 항상 프로덕션에 배포 가능한(production-ready) 상태로 유지합니다(CD).

3. 시스템을 작고 간단하게 빌드한다

크고 긴밀하게 결합된(tightly-coupled) 시스템은 변경하기 어렵고 망가지기 쉽습니다. 높은 성과를 내는 팀의 코드베이스는 작고 간단한 컴포넌트와 깔끔한 인터페이스로 구성되며, 각 컴포넌트를 서로 영향을 주지 않는 분리된 상태로 테스트·배포합니다.

비교 / 트레이드오프

“품질을 원하면 천천히, 속도를 원하면 품질을 희생”이라는 연속체(continuum) 관점은 잘못된 이분법입니다. 속도와 품질은 한 축이 아니라 두 축입니다.

	느린 속도	빠른 속도
높은 품질	속도보다 품질 우선	속도와 품질 모두 우선 ← 린·애자일·데브옵스의 목표
낮은 품질	지저분하고 부실한 시스템	품질보다 속도 우선

핵심 통찰은 한쪽만 선택한 두 사분면이 모두 왼쪽 아래(부실한 시스템)로 미끄러진다 는 것입니다.

• 품질보다 속도 (‘move fast and break things’): 품질을 희생해 깨지기 쉬운 시스템을 만들고, 부실한 시스템이 속도를 잡아먹습니다. 예전엔 빨리 처리하던 변경이 며칠에서 몇 주로 늘어납니다.

• 속도보다 품질 (“중요한 업무니까 반드시 제대로”): 무거운 프로세스가 개선을 가로막는 벽이 되고 기술 부채가 ‘알려진 이슈’ 목록과 함께 쌓입니다. 실패할수록 프로세스를 더 만들어 개선을 더 어렵게 하는 악순환에 빠집니다. 위험에 민감한 산업일수록 이 방식을 ‘정상’으로 여깁니다(비정상의 정상화, normalization of deviance).

『Accelerate』의 저자 니콜 포스그렌

이러한 결과는 성능 향상과 더 높은 수준의 안정성 및 품질이 상충관계가 아니라는 것을 보여 준다. 오히려 높은 성과를 내는 조직이 이러한 조치를 더 잘 수행한다.

조직은 ‘변경을 잘 한다’와 ‘안정성 강화를 잘 한다’ 중 하나를 고를 수 없으며, 둘 다 잘하거나 둘 다 못하는 경향이 있습니다.

내 생각

• 애플리케이션 개발에서 검증된 원칙의 이식입니다. TDD·CI·CD·작은 모듈은 백엔드 코드에서는 이미 상식인데, 이를 인프라에 그대로 적용하자는 것입니다. Terraform 코드나 K8s 매니페스트도 애플리케이션 코드와 같은 수준의 리뷰·테스트 파이프라인을 거쳐야 한다는 뜻입니다.

• “프로세스 강화 → 우회 → 카우보이 IT” 역설은 실무에서 흔합니다. 변경 승인 절차가 길어질수록 콘솔에서 몰래 고치는 수동 변경이 늘고, 그 드리프트가 코드와 실제 인프라의 불일치를 만들어 자동화에 대한 신뢰를 더 떨어뜨리는 악순환이 됩니다.

• 사분면의 아픈 지점은 “품질 우선도 결국 부실로 떨어진다”입니다. move fast의 실패는 다들 예상하지만, 신중하게 프로세스를 쌓아 온 조직이 같은 자리(부실 시스템)에 도착한다는 지적이 금융·엔터프라이즈 환경에서는 훨씬 뼈아픕니다.

관련 개념

• Ch23 지속적 통합 — 핵심 실행 방법 2의 기반인 CI의 상세 원리
• Ch24 지속적 배포 — 항상 배포 가능한 상태를 유지하는 CD 실천법