OAC(Observability as Code)는 “도입할 것인가 말 것인가”의 문제가 아니라, 모니터링 구성 요소 중 어디까지를 코드로 관리하고 어디를 운영자의 영역으로 남길 것인가에 대한 선택의 문제로 정리되는 경우가 많습니다. 실제 현업에서는 전면적인 Code화보다는, 콘솔 기반 운영과 Code 기반 관리를 병행하는 형태가 상대적으로 안정적으로 받아들여지고 있습니다.
현업에서 OAC가 부담스럽게 느껴지는 가장 큰 이유는, 모니터링이라는 영역의 속성 자체 때문입니다.
인프라 자원은 한 번 선언하면 비교적 오래 유지되지만, 모니터링 설정은 그렇지 않습니다. 알람 임계치나 조건은 장애를 겪은 뒤에야 조정되는 경우가 많고, 서비스 특성에 따라 지속적인 미세 조정이 필요합니다. 이런 설정을 콘솔에서는 몇 초 만에 바꿀 수 있는데, 이를 코드 변경과 배포 절차로 전환하면 운영자 입장에서는 작업 부담이 급격히 커졌다고 느끼기 쉽습니다.
또 다른 이유는 작업 방식의 체감 생산성 차이입니다.
Grafana 대시보드나 Datadog 스크린보드처럼 시각적 구성이 중요한 요소를 JSON이나 HCL로 직접 작성하는 과정은, UI에서 마우스로 조정하는 방식에 비해 직관성이 크게 떨어집니다. 이 때문에 “체계는 좋아지지만 작업은 훨씬 피곤해진다”는 반응이 나오는 것도 자연스러운 흐름으로 보입니다.
이런 배경 때문에, 실제 운영 환경에서는 모든 것을 코드로 관리하겠다는 접근보다는 몇 가지 현실적인 타협안이 선택되는 경우가 많습니다.
첫 번째는 콘솔에서 먼저 만들고, 안정화된 뒤에 코드로 가져오는 방식입니다.
처음부터 코드로 대시보드나 알람을 작성하기보다는, 콘솔에서 충분히 조정하고 검증한 뒤 Terraform import나 terraformer 같은 도구를 사용해 코드로 추출해 관리합니다. Grafana의 경우에도 UI에서 대시보드를 수정한 뒤 JSON Export 기능을 통해 버전 관리 대상으로 전환하는 방식이 자주 사용됩니다. 이 접근은 코드 작성을 위한 부담을 줄이면서도, 재현성과 이력 관리는 확보할 수 있다는 장점이 있습니다.
두 번째는 코드로 관리할 대상과 콘솔이나 API로 관리할 대상을 명확히 구분하는 방식입니다.
알람 채널 설정, 공통 대시보드 템플릿, 로그 보존 정책처럼 구조적이고 재현이 중요한 요소는 코드로 관리하고, 특정 서비스의 세부 임계치나 일시적인 뮤트 설정처럼 자주 변하는 값은 콘솔이나 API를 통해 조정하는 식입니다. 경우에 따라서는 Terraform 코드 자체를 수정하지 않고도 값만 바꿀 수 있도록 변수 파일이나 외부 데이터 소스를 활용하는 구조를 택하기도 합니다.
세 번째는 표준 대시보드를 모듈화하는 접근입니다.
예를 들어 Kubernetes 환경에서 네임스페이스나 클러스터 수가 늘어날수록, 동일한 형태의 모니터링을 반복해서 구성해야 하는 상황이 발생합니다. 이때 공통적인 골든 시그널 대시보드나 알람 세트를 하나의 모듈로 정의해 여러 환경에 동일하게 배포하는 방식은, OAC의 효과가 비교적 직관적으로 드러나는 지점입니다. VCF나 대규모 Kubernetes 환경처럼 운영 대상이 빠르게 늘어나는 경우일수록 이러한 방식의 효용이 분명해집니다.
이런 사례들을 종합해 보면, OAC는 운영자의 즉각적인 판단과 개입을 없애기 위한 도구라기보다는, 반복 작업과 재현이 필요한 영역의 부담을 줄이기 위한 보조 수단에 가깝다고 볼 수 있습니다. 콘솔 작업에 익숙한 운영 방식과 코드 기반 관리가 충돌하는 것은 자연스러운 과정이며, 이를 전면적인 전환으로 해결하려 하기보다는 역할을 분리하는 방식이 현실적인 선택으로 보입니다.
정리하면, 주변에서 제기되는 우려 역시 충분히 이해 가능한 반응이고, 이를 무시할 필요는 없어 보입니다. 다만 자동화나 표준화를 중장기 목표로 두고 있다면, OAC를 전면 도입의 형태가 아니라 운영 부담을 줄이는 방향으로 제한적으로 적용해 보는 접근은 충분히 검토해 볼 만한 선택지라고 생각합니다.
감사합니다.