문제점: Infrastructure-as-Code에서 뒤처지는 생태계

인프라 및 플랫폼 엔지니어로서, 우리는 유용할 만큼의 기능은 갖추었지만 여전히 다듬어지지 않은 라이브러리들을 다루는 데 많은 시간을 소비합니다.

최근 저는 Kubernetes 인프라를 검증하기 위해 InSpec을 사용하여 컴플라이언스 테스트(compliance tests)를 작성하고 있었습니다. InSpec은 견고한 컴플라이언스 코드화 (compliance-as-code) 기능을 제공하지만, InSpec의 Kubernetes 리소스 팩은 최근 몇 년 동안 크게 발전하지 못했습니다. 만약 여러분이 최신 Gateway API 표준을 테스트하는 것과 같은 현대적인 **클라우드 네이티브 아키텍처 (cloud-native architectures)**를 다루고 있다면, 기초적인 빌딩 블록이 누락되어 있다는 사실을 빠르게 깨닫게 될 것입니다.

저의 경우, **사용자 정의 리소스 정의 (Custom Resource Definitions, CRDs)**를 검증해야 했습니다.

신기루: 자신감 넘치는 환각 (Hallucination)

처음에 컴플라이언스 테스트를 생성하기 위해 AI 모델과 협업했을 때, 모델은 제가 보고 싶었던 것을 정확히 내뱉었습니다. 루프는 깔끔하고 직관적이며 자연스러워 보였습니다:

expected_standard_crds.each do |crd_name|
  describe k8s_custom_resource_definition(name: crd_name) do
    it { should exist }
...

단 한 가지 문제가 있었습니다. InSpec Kubernetes 리소스 팩에는 k8s_custom_resource_definition이라는 리소스가 존재하지 않습니다. 모델이 API 래퍼(wrapper)를 완전히 환각(hallucinated)해낸 것입니다.

보통 이 지점은 한숨을 쉬며 지저분한 임시방편(workaround)을 작성할 준비를 하는 단계입니다. InSpec에서 이는 대개 가공되지 않은 Ruby 코드를 직접 작성하거나, 명령 리소스를 통해 kubectl을 셸(shell)로 호출하거나, 가공되지 않은 JSON 문자열을 파싱하는 것을 의미하며, 이는 컴플라이언스 코드화 (compliance-as-code)의 깔끔하고 표현력 있는 특성을 완전히 망가뜨립니다.

반전: Claude를 이용한 추상화 설계

이 문제를 Claude에게 가져갔을 때, Claude는 단순히 사과하며 지저분한 임시방편으로 테스트를 다시 작성하지 않았습니다. 대신, 프레임워크의 공백을 포착하고 엔지니어링 사고방식으로 전환했습니다.

Claude는 그 이상적인 테스트 코드가 작동하게 하려면, 단지 누락된 추상화(abstraction)를 구축하기만 하면 된다는 사실을 깨달았습니다.

Claude는 InSpec의 기반이 되는 K8s 클라이언트 백엔드(client backend)로 직접 들어가, 커스텀 리소스 구현(custom resource implementation)을 생성하고 이를 프로파일의 libraries/ 디렉토리에 바로 배치했습니다:

# libraries/k8s_custom_resource_definition.rb

class K8sCustomResourceDefinition < Inspec.resource(1)
...

Claude가 apiextensions.k8s.io/v1 리소스 엔드포인트(endpoint)를 정확하게 매핑했기 때문에, 기존의 우아한 테스트 루프(test loop)가 이제 완벽하게 작동했습니다.

플랫폼 엔지니어링(Platform Engineering)에서 AI의 진정한 레버리지

우리는 흔히 보일러플레이트(boilerplate) 애플리케이션 코드를 작성하거나 빠른 유틸리티 스크립트를 구성하는 맥락에서 AI를 이야기합니다. 하지만 파편화되거나 뒤처지는 오픈 소스 생태계와 씨름하는 인프라 엔지니어들에게, 진정한 레버리지(leverage)는 생태계의 확장일 수 있습니다.

오픈 소스 도구가 80% 정도 완성되었을 때, 우리는 보통 나머지 20%를 메우는 기술 부채(technical debt)를 직접 떠안게 됩니다. 만약 LLM(대규모 언어 모델)이 "도구의 엄격한 제약 조건 내에서 코드를 작성하는 것"에서 "도구 자체를 동적으로 다시 작성하고 확장하는 것"으로 전환될 수 있다면, 우리가 플랫폼 툴링 스택(platform tooling stack)을 유지 관리하는 방식은 완전히 바뀔 것입니다.

한 모델의 환각(hallucination)이 다른 모델이 프레임워크를 확장하기 위한 청사진(blueprint)이 되었던 유사한 워크플로우를 경험해 보신 적이 있나요?

댓글에서 함께 논의해 봅시다!

추가 읽을거리 및 리소스

유사한 컴플라이언스 코드화(compliance-as-code) 패턴을 구현하고자 하거나 이 포스트에서 언급된 도구들을 탐색하고 싶다면, 다음 프로젝트들을 확인해 보세요:

• CINC Auditor – 커뮤니티에서 구축한, 완전히 자유로운 형태(free-as-in-freedom)의 무료 Chef InSpec 배포판입니다. Apache 2.0 라이선스 하에 100% 프로파일 호환성을 제공하여, 기업용 CI/CD 파이프라인에서 인기 있는 교체용 도구(drop-in replacement)로 사용됩니다.
• Chef InSpec – 보안, 컴플라이언스(compliance), 인프라 정책 요구사항을 사람이 읽을 수 있는 코드(human-readable code)로 변환하는 업계 표준 오픈 소스 테스트 프레임워크입니다.
• InSpec Custom Resources Documentation – 자체적인 리소스 DSL 매핑을 작성하여 프레임워크를 확장하는 방법에 대한 공식 가이드입니다.