[인프라를 소프트웨어처럼 1/5] Infrastructure as Code, 그리고 그다음

flex의 인프라 연재 1편으로, terraform plan이 초록색이라는 것과 시스템이 살아 있다는 것이 같은 말이 아니라는 데서 출발한다. plan은 코드가 선언한 상태와 state 파일이 기억하는 상태라는 두 개의 의도를 비교할 뿐, 보안 그룹의 포트가 정말 트래픽을 흘려보내는지나 라우팅 한 줄이 살아 있는 서비스로 패킷을 데려가는지는 모른다. IaC가 인프라를 코드처럼 만들었지만 그다음이 비어 있었다는 문제 제기다.

핵심 포인트

plan은 "무엇이 바뀌는지"를 정확히 알려주지만 "그래서 되는지"에는 답하지 못한다.
한 줄을 고치고 결과를 확인하는 가장 빠른 길이 프로덕션에 apply해 보는 것인 세계는, 텍스트로 쓰여 있어도 소프트웨어라고 부르기 어렵다.
소프트웨어에서 당연하게 누리던 단위 테스트, 짧은 피드백 루프, 컴파일러가 미리 잡아 주는 실수, 리팩터링 안전망이 인프라에는 대부분 없었다.
실제로 plan이 깔끔하게 통과하고 리뷰도 승인됐는데 apply 이후 한 환경에서만 특정 트래픽이 조용히 끊긴 사고가 있었다.
그 사고에서 코드도 plan도 state도 모두 정상이었고, 문제는 코드 바깥에 있었다.

상세 정리

익숙한 장면: 한 줄을 고치고 plan을 돌려 수십 초를 기다린 뒤 초록색과 빨간색의 diff를 읽고 요약을 보며 잠깐 안심하는 흐름이다.
plan이 비교하는 것: 코드가 선언한 상태와 state 파일이 기억하는 상태, 그 둘의 차이를 계산할 뿐이다.
plan이 모르는 것: 새로 붙인 IAM 정책이 의도한 것만 허용하는지, 라우팅이 실제 서비스로 패킷을 데려가는지는 apply를 하고 클러스터에 붙어 실제 요청이 흘러 봐야 안다.
IaC가 준 것: 인프라를 텍스트로 옮겨 버전 관리가 되고 Pull Request로 리뷰가 되며 같은 선언으로 같은 환경을 다시 세울 수 있게 됐다. 클릭으로 만든 리소스가 누구의 기억 속에만 남던 시절과 비교하면 거대한 도약이라고 인정한다.
멈춘 지점: HCL이든 YAML이든 텍스트라는 사실만으로 소프트웨어의 미덕이 따라오지는 않는다. 설정 파일은 테스트되지 않고 의존성은 타입으로 강제되지 않으며, 한 환경에서 통과한 변경이 다른 환경에서 같게 동작한다는 보장도 그 자체로는 없다.
사고 사례의 성격: 추가 한 줄, 변경 두 줄의 작은 변경이었고 리뷰어도 무리 없이 승인했지만, 그 변경이 실제로 부딪치는 지점에서 문제가 생겼다. diff는 끝까지 초록색이었지만 시스템은 그와 무관하게 멈춰 있었다.
저자는 diff와 동작 사이의 그 거리를 이 연재가 메우려는 빈칸으로 규정한다.

왜 읽나terraform plan 통과를 안전의 근거로 삼아 온 인프라 엔지니어에게, 선언과 동작 사이에 남는 검증 공백이 무엇인지 사고 사례와 함께 짚어 준다.

flex 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

[인프라를 소프트웨어처럼 1/5] Infrastructure as Code, 그리고 그다음

이 글과 비슷한

엔터프라이즈 보안 요구사항을 충족하는 프라이빗 Amazon Bedrock AgentCore 구축하기

OpenTofu와 Argo CD로 구성하는 GitLab 기반 AWS 제어 플레인

Amazon Bedrock 기반 사내 LLM, 키 발급부터 비용 차단까지: F&F의 LiteLLM 게이트웨이 운영 사례