#DevOps

[인프라를 소프트웨어처럼 2/5] 코드가 모르는 그 '환경'은 누가 만드는가

Summary

"저 dev 환경 잠깐 점령할게요"라는 슬랙, 이제는 작별할 시간입니다

인프라를 단순 코딩(IaC)을 넘어 소프트웨어(IaS)로 관리하며 얻은 플랫폼팀의 선언적 환경 구축기

코드와 환경을 분리하려는 시도가 플랫폼팀에게는 오히려 거대한 수동 작업의 짐이 되곤 합니다. 본 아티클은 이러한 '환경의 공백'을 메우기 위해 flex 플랫폼팀이 Kafka 토픽 생성부터 시작해 인프라를 어떻게 선언적으로 소프트웨어화했는지 그 구체적인 여정을 다룹니다. Git 로그를 거버넌스의 원장으로 활용하고 테스트와 재현성을 확보하는 실전 전략을 공유합니다.

01환경을 계약(Port)과 실체(Substrate)의 관점으로 재정의
02단순 IaC를 넘어 테스트와 재현성을 보장하는 IaS로의 진화
03Kafka 토픽 설정을 JSON Schema로 사전 검증하여 배포 안정성 확보
04모든 인프라 변경을 Git PR로 통합하여 자동화된 거버넌스 구현
05수동 '요청' 문화를 코드 기반의 '선언' 문화로 전환한 조직적 변화

RECOMMENDATION

인프라 관리 효율을 높이고 싶은 플랫폼 엔지니어와 환경 격리 문제로 고민하는 데브옵스 담당자에게 추천합니다. 특히 리소스 생성이 티켓 기반으로 이루어져 병목이 발생하는 조직이라면 즉시 도입해볼 만한 가치가 있습니다.

The Problem

개발자가 정의하는 코드가 '무엇을(Logic)'에만 집중하면서, 이를 뒷받침하는 인프라 환경(Substrate)을 구축하고 관리하는 책임이 플랫폼팀의 수동 작업과 파편화된 기억에 의존하게 되는 공백이 발생했습니다. 특히 인프라 생성이 '요청' 기반으로 이루어짐에 따라 재현 불가능성이 쌓이고 변경 이력 추적이 어려워지는 문제가 있었습니다.

The Solution

인프라를 단순한 코드가 아닌 검증과 재현이 가능한 '소프트웨어(IaS)'로 취급하여, 모든 환경 생성을 '선언' 방식으로 전환했습니다. Kafka 토픽과 같은 작은 단위부터 JSON Schema 검증과 Git PR 기반의 워크플로우를 도입하여, 선언 파일이 곧 실제 인프라의 원장이 되도록 구조화했습니다.

The Result

인프라 생성 작업이 수동 콘솔 조작에서 Git PR 한 줄의 선언으로 간소화되었으며, JSON Schema를 통한 사전 검증으로 설정 오류를 배포 전에 차단할 수 있게 되었습니다. 또한 모든 변경 사항이 Git History에 기록됨으로써 별도의 문서화 없이도 완벽한 거버넌스와 감사(Audit) 기능을 확보했습니다.

Trade-off

개별 리소스 단위의 선언은 성공적이었으나, 수십 개의 리소스가 얽힌 환경 전체를 한꺼번에 찍어내는 데에는 여전히 높은 복잡도가 존재하며, 생성된 환경을 삭제하고 관리하는 생명주기 정책이 미비할 경우 공유 환경의 리소스 충돌이나 장애를 유발할 위험이 남아있습니다.