코드형 정책(PaC)이란 무엇인가요?

사람이 규정 준수 여부를 확인하거나 보안 규칙을 기억하는 데 의존하는 대신, 이러한 규칙은 개발자나 시스템이 변경 사항 또는 요청을 제안할 때마다 실행되는 실행 가능한 로직으로 존재합니다. 누군가 변경 사항을 제출하면 정책 엔진이 코드로 정의된 규칙에 따라 이를 자동으로 평가하고 허용하거나 거부하거나 플래그를 지정합니다.

이 프로세스는 정책 관리 방식을 정적인 문서에서 소프트웨어 딜리버리 파이프라인에 내장되어 지속적으로 시행되는 동적인 제어 체계로 전환합니다.

코드 기반 규칙은 동일한 정책이 어디에서나 반복 가능하고 확장 가능한 방식으로 적용되도록 지원합니다. 정책 엔진은 빌드 또는 배포 과정에서 몇 초 만에 자동 검사를 실행하여 피드백 주기를 단축하고 DevOps 팀이 후반 단계에서 예기치 않은 보안 또는 규정 준수 관련 문제에 직면하지 않도록 지원합니다.

PaC를 사용하면 기업은 전반적인 사이버 보안 태세를 개선하고 업계 및 규제 표준을 계속 준수할 수 있습니다. 또한 정책을 코드처럼 다루는 방식은 인프라 요청과 같은 항목을 개발 팀이 검토하고 협업할 수 있는 코드 파일로 전환하는, 더 광범위한 ‘모든 것을 코드로(everything as code)’ 전환과도 부합합니다.

DevOps 용어로 정책이란 IT 인프라 및 애플리케이션을 구성하고 액세스하며 실행하는 방식을 규정하는 명확하고 시행 가능한 규칙입니다. 더 정확히 말하면 정책은 시스템이 이상적인 상태로 계속 운영되도록 어떤 작업이 허용, 필수, 금지되는지를 규정합니다. 

예를 들어 ‘모든 스토리지 버킷은 암호화되어야 합니다’ 또는 ‘어떠한 공개 서비스도 포트 22를 노출해서는 안 됩니다’는 시스템 동작에 대한 구체적인 제약 조건을 명시하므로 정책입니다.

PaC에서는 정책을 구조화된 프로그래밍 언어로 작성하므로, 정책 엔진과 자동화 툴이 이를 결정론적으로 구문 분석하고 평가할 수 있습니다. 따라서 정책은 사람마다 다르게 해석할 수 있는 지침이 아니라 시스템과 엔지니어가 충족해야 하는 실행 가능한 가드레일이 됩니다.

코드형 정책 툴을 사용하면 개발자는 런타임 환경과 지속적 통합/지속적 제공(CI/CD) 파이프라인에 적용할 실행 가능한 코드를 작성할 수 있으므로, 모든 변경 사항의 정책 준수 여부가 자동으로 확인됩니다.

기술적으로 대부분의 PaC 구성은 동일한 핵심 단계를 따릅니다.

• 개발자들은 코드 파일 형태로 정책을 작성합니다. 개발자는 코드 파일 형태로 정책을 작성합니다. Python, YAML, JavaScript Object Notation(JSON), Rego 등 다양한 고수준 명령형 및 선언형 언어를 사용할 수 있습니다. Rego는 일반적으로 오픈 소스 정책 엔진인 Open Policy Agent(OPA)와 함께 사용됩니다. 각 정책 파일은 관심 있는 입력값(예: resource.kind, metadata.labels)을 선언하고, '조건자'라고도 하는 조건과 결과(허용/거부, 심각도, 메시지)를 코드로 명시합니다.

• 코드는 Git이나 GitHub와 같은 버전 제어 시스템에 제출되며, 풀 리퀘스트, 코드 검토, 엄격한 구문 테스트를 비롯해 애플리케이션 코드와 동일한 워크플로를 거칩니다.

• 정책 엔진은 코드 파일을 읽고 구문 분석한 다음, 이를 내부에서 처리할 수 있는 데이터 구조와 명령어로 변환합니다. 이어서 이러한 데이터 구조와 명령어를 빠른 평가를 위한 간결한 저수준 명령 형식인 바이트코드로 변환합니다.

• 정책 엔진에 결정을 요청하는 코드인 호출자는 데이터 입력을 정규화합니다.호출자는 IaC 툴의 HashiCorp Configuration Language(HCL) 파일 및 JSON 템플릿, Kubernetes 및 클라우드 플랫폼의 YAML 매니페스트, API 호출의 HTTP 요청, 런타임 및 프로덕션 환경의 애플리케이션 데이터와 텔레메트리 데이터를 비롯한 다양한 입력 형식을 처리합니다. 원시 입력을 정리하고 재구성해 하나의 표준 구조로 만들므로 정책은 입력을 일관된 방식으로 읽을 수 있습니다.

• 호출자가 정규화된 데이터를 정책 엔진으로 다시 전달하면, 정책 엔진은 데이터 입력을 기준으로 정책 코드를 실행하기 시작합니다.  

• 정책 엔진은 규칙을 순차적으로 검토하며 각 규칙의 조건자를 입력값과 대조해 어떤 조건자가 적용되는지 파악합니다. 정책 엔진이 “이 규칙은 이 입력값에 대해 무엇을 말하는가?”라고 묻는다고 생각할 수 있습니다.

• 정책 엔진은 모든 규칙의 결과를 취합하여 단일 정책 결정을 내립니다. 이 과정을 결정 집계라고 하며, 이를 통해 메시지 목록을 생성합니다. 메시지는 정책 검사를 통과하지 못한 코드에 대한 세부 정보(어떤 규칙을 위반했는지, 어떤 객체가 이를 위반했는지 등)를 제공하며, 때로는 수정 방법을 제안합니다.

• 정책 엔진은 관련 메시지, 태그 및 심각도 정보를 포함한 정책 결정 결과를 반환합니다. '거부'로 결정되면 정책 엔진은 모든 풀 리퀘스트와 코드 병합을 차단하고 개발자가 정책 위반을 시정할 때까지 배포를 중단합니다. '허용'으로 결정되면 엔진은 빌드 아티팩트(컴파일, 패키징 및 테스트된 코드 파일)를 생성하고 코드를 배포합니다. 경고가 있는 경우 코드의 진행은 허용되지만, 엔진은 로그 파일이나 코멘트에 경고를 포함합니다. 

정책 검사는 코드 통합부터 실제 프로덕션 환경 및 모니터링까지 소프트웨어 개발 라이프사이클(SDLC)의 어느 시점에서든 수행될 수 있습니다.

정책은 코드이기 때문에 다른 소프트웨어 아티팩트와 마찬가지로 취급될 수도 있습니다.

개발 팀은 정책에 샘플 입력값을 제공하고 반환되는 결정을 검증하는 자동화된 테스트를 작성하여, 정책이 변경될 때 피드백 주기를 단축할 수 있습니다.

정책을 코드로 명시하면 개발자는 공통 로직을 재사용 가능한 모듈이나 함수로 분리할 수 있습니다. 그러면 여러 상위 수준 정책은 조건을 곳곳에 중복하는 대신 공유 정책을 호출할 수 있습니다.

개발자는 대규모 애플리케이션 함수를 더 작은 함수로 리팩터링하는 것처럼, 동작을 변경하지 않고 대규모 정책의 이름을 바꾸거나 구조를 재편하거나 더 작은 정책으로 분할할 수 있습니다.

이러한 기능을 통해 팀은 거버넌스 로직에 기존 소프트웨어 엔지니어링 방식을 적용할 수 있으며, 이는 IT 아키텍처가 확장되고 발전하는 상황에서도 보안 및 규정 준수 요구 사항을 유지하는 데 도움이 됩니다.

예를 들어 X사는 모든 웹 서비스가 일반 HTTP가 아닌 HTTPS를 사용해야 하는 ‘HTTPS 전용’ 정책을 구현하려고 합니다.정책을 코드로 정의하기 위해 플랫폼 엔지니어는 다음과 같은 간단한 규칙을 작성합니다.

• 서비스의 프로토콜이 HTTP이면 변경을 거부해야 합니다.
• 서비스의 프로토콜이 HTTPS이면 변경이 허용됩니다.

엔지니어는 애플리케이션과 동일한 코드 리포지토리 내 'policies' 폴더에 이 정책 파일을 넣고, 정책을 추가하는 풀 리퀘스트를 엽니다. 이 풀 리퀘스트는 정책 파일의 자동 구문 검사와 다른 엔지니어의 코드 검토를 트리거합니다. 정책이 필요한 테스트를 통과한 후에만 메인 브랜치에 병합됩니다.

지속적 통합(CI) 파이프라인에서는 모든 정책 파일이 'policies' 폴더에서 정책 엔진으로 로드됩니다. 정책 엔진은 정책을 읽고 내부 표현으로 변환한 다음, 이를 간결한 저수준 형식으로 컴파일합니다. 이 간결한 형식을 통해 엔진은 파이프라인이 검사하는 모든 서비스에 대해 ‘허용’ 또는 ‘거부’ 여부를 빠르게 판단할 수 있습니다.

CI 작업은 파일 형식과 관계없이 기존 구성 파일에서 중요한 필드(이름, 프로토콜, 포트)를 추출하고, 각 서비스의 간단한 JSON 설명을 생성합니다.

호출자는 표준화된 서비스 설명을 입력값으로 전송하고 'HTTPS 전용' 정책 패키지를 적용하도록 지정하여 정책 엔진에 결정을 요청합니다.

그런 다음 정책 엔진은 입력값을 규칙에 따라 평가하고, 서비스의 프로토콜 필드를 확인합니다. 프로토콜이 HTTP이면 입력값이 정책의 '거부' 조건과 일치한다는 뜻입니다. 엔진은 변경을 거부해야 한다고 표시하고, 서비스가 HTTP 대신 HTTPS를 사용해야 한다는 메시지를 개발자에게 생성합니다. 서비스가 HTTPS를 사용하면 어느 거부 조건에도 해당하지 않으므로, 엔진은 변경이 허용된다고 표시합니다.

이어서 정책 엔진은 규칙 평가 결과를 해당 서비스의 단일 결정 객체로 요약합니다. 결정 객체에는 일반적으로 전체 결정이 '허용'인지 '거부'인지와 문제의 심각도(높음, 중간, 낮음)가 지정됩니다. 또한 입력값이 거부된 이유와 평가 과정에서 엔진이 발견한 경고를 설명하는 메시지 목록도 포함됩니다. 모든 항목이 규정을 준수하면 결정 객체에는 변경이 허용된다고 표시되며, 정보성 참고 사항만 포함되거나 메시지가 전혀 포함되지 않습니다.

마지막으로, CI 툴이 결정을 실행합니다. 결정이 '거부'이면 변경 사항은 메인 코드 브랜치에 병합되지 않습니다. 엔지니어에게는 서비스가 HTTPS를 사용해야 하며 특정 수정 사항을 적용해야 한다는 오류 메시지가 표시됩니다. 결정이 '허용'이면 아티팩트가 패키징 및 배포되고 CI 파이프라인은 정상적으로 계속 진행됩니다.

코드형 정책은 현대 DevOps와 클라우드 엔지니어링에서 등장한 더 광범위한 ‘모든 것을 코드로(everything as code)’ 움직임에서 비롯되었습니다.

처음에는 코드형 인프라(IaC)가 큰 변화를 이끌었습니다. 시스템 관리자가 사용자 인터페이스를 클릭하거나 런북을 따르는 대신, 팀은 서버·네트워크·기타 리소스를 선언형 코드 파일로 설명했습니다. 이러한 파일은 버전 제어 시스템에 저장되고 자동화된 파이프라인을 통해 적용됩니다.

기업들이 이점을 확인하면서 이 접근 방식은 IT 아키텍처의 다른 구성 요소로도 확산되었습니다. 애플리케이션 구성은 코드 기반 방식으로 전환되었고, CI/CD 파이프라인은 코드 리포지토리에 저장되는 스크립트가 되었습니다. 모니터링 및 경고 규칙도 코드로 관리되기 시작했습니다. 이러한 관행을 통틀어 ‘모든 것을 코드로’라고 부르게 되었습니다.

‘모든 것을 코드로’의 핵심 개념은 시스템의 어떤 부분이든 설명할 수 있다면 코드로 설명하고 소프트웨어 애플리케이션과 동일한 방식으로 관리해야 한다는 것입니다.

PaC는 본질적으로 이러한 철학을 규칙, 거버넌스 및 규정 준수에 적용한 것입니다. 전통적으로 정책은 PDF와 위키에 존재하거나 위원회에서 결정되었으며, 사람에 의해 시행되었습니다. 이러한 프로세스는 릴리스 주기가 느리고 인프라가 비교적 정적이던 때에는 효과적으로 작동했습니다.

클라우드 네이티브 및 마이크로서비스 아키텍처가 보편화되고 팀이 하루에 여러 번 코드를 배포하기 시작하면서 수동 프로세스는 이를 따라갈 수 없게 되었습니다. PaC는 정책을 기계가 읽을 수 있는 형식으로 표현하여 이러한 과제를 해결했습니다. 이에 따라 정책을 Git에서 버전 관리하고, 코드 파일처럼 검토하고, CI에서 테스트하고, 파이프라인 또는 런타임에서 자동으로 시행할 수 있습니다.

코드형 정책은 IT 정책을 소프트웨어 코드처럼 관리하는 방식입니다. 코드형 인프라(IaC)도 이와 유사하지만 초점이 다릅니다. IaC는 엔지니어링 팀이 애플리케이션 코드를 사용하여 IT 인프라를 정의하고 관리할 수 있도록 지원합니다.

IaC를 사용하면 개발자는 가상 머신(VM), 로드 밸런서와 같은 네트워크 자산을 수동으로 생성하고 구성하는 대신, 이러한 리소스의 원하는 상태를 설명하는 코드를 작성할 수 있습니다. 그런 다음 IaC 툴이 해당 코드를 가져와 지정된 리소스를 생성하거나 수정합니다.

IaC는 인프라 확장과 자동화를 훨씬 쉽게 만듭니다. 팀에 더 많은 서버가 필요하면 코드에서 숫자만 변경하면 됩니다. 예를 들어 인스턴스 수를 6개에서 9개로 변경할 수 있습니다. 자동화 툴은 추가 리소스 프로비저닝에 필요한 세부 작업을 처리합니다.

큰 틀에서 IaC는 어떤 인프라가 존재해야 하고 어떻게 구성되어야 하는지를 규정하는 반면, PaC는 인프라가 준수해야 하는 규칙과 제약 조건에 중점을 둡니다. IaC 코드는 리소스를 생성하고 구성하며, PaC 코드는 이러한 리소스와 그 사용 방식이 정의된 보안 요구 사항, 규정 준수 표준 및 운영 가드레일을 따르도록 지원합니다.

많은 현대 IT 아키텍처와 CI/CD 구성에서 IaC와 PaC는 상호 보완적인 이점을 제공합니다. IaC는 프로비저닝을 자동화하고, PaC는 그 위에 자동화된 거버넌스를 추가합니다.

개발자가 IaC 파일을 변경하면 PaC 엔진은 새 계획 또는 구성을 검사할 수 있습니다. 모든 항목이 수립된 정책을 준수하면 변경 사항의 진행이 허용되고 인프라가 업데이트됩니다. 규칙을 위반한 항목이 있으면 파이프라인이 실패하고 문제가 해결될 때까지 아무것도 배포되지 않습니다.

DevSecOps는 보안과 규정 준수를 마지막에 덧붙이는 대신 DevOps 라이프사이클에 내장하는 방식입니다. 이는 소프트웨어 개발 라이프사이클의 각 단계에서 보안 프로세스를 우선시하고 실행하는 개발 접근 방식입니다.

PaC는 다음과 같은 방법으로 DevSecOps 사례를 지원합니다.

PaC는 문제가 사용자에게 영향을 미칠 수 있는 배포 후 검사를 수행하는 대신, 실행할 때까지 기다리지 않고 개발 프로세스의 초기 단계로 보안 검사를 이동하여 보안을 유지하도록 지원합니다. 개발자가 위험한 구성 또는 안전하지 않은 패턴을 도입하면 자동화된 정책이 문제를 탐지하고 빌드를 실패 처리할 수 있습니다.

PaC 툴은 보안 규칙을 CI/CD 파이프라인과 런타임 시스템에 직접 내장하여 시행을 자동화합니다. 따라서 코드나 인프라가 변경될 때마다 검사가 자동으로 수행됩니다. 사람이 모든 보안 표준을 기억하고 모든 변경 사항을 수동으로 검토하는 데 의존하는 대신, 시스템이 변경 사항을 일관되게 평가하여 어떤 단계도 실수로 누락되지 않도록 합니다.

PaC는 개발자가 일관성과 안전성을 희생하지 않으면서 배포 속도를 유지하도록 지원합니다. 개발·테스트·스테이징·프로덕션 등 모든 환경과 모든 단계에서 동일한 정책 정의를 실행합니다. 이를 통해 팀은 동일한 규칙 세트가 어디에나 적용된다는 확신을 바탕으로 자주 릴리스할 수 있습니다. 또한 환경 간에 구성이 달라지거나 규칙을 약간 다르게 해석하는 상황을 방지하는 데 도움이 됩니다.

PaC는 애플리케이션 보안 정책을 버전 제어 시스템에 있는 다른 코드 아티팩트와 동일하게 취급합니다. 개발, 운영 및 보안 팀은 익숙한 워크플로(코드 검토, 브랜치 전략 등)를 통해 정책을 검토, 논의, 업데이트할 수 있으므로, 정책 논의가 더욱 투명해지고 일상적인 개발 업무에 더 잘 통합됩니다.

코드형 정책은 엔터프라이즈 IT 아키텍처에서 광범위하게 활용됩니다.

개발자와 보안 전문가는 AI 또는 에이전틱 워크플로의 전체 라이프사이클에 적용되는 계층화된 가드레일 모델을 구축하는 방법으로 코드형 정책을 검토하고 있습니다. 이 사례는 아직 초기 단계이지만, 초기 조사에서 AI 워크플로에 PaC를 적용할 수 있는 다양한 가능성이 확인되었습니다.

PaC는 AI의 추론과 실제로 실행이 허용되는 작업을 결정하는 시스템을 명확히 분리하는 데 도움이 될 수 있습니다. AI 툴은 작업이나 계획을 제안할 수 있지만, 기본 시스템에 영향을 주기 전에 정책 엔진이 코드로 정의된 규칙에 따라 이러한 제안을 평가합니다.

입력 단계에서 PaC는 사용자 프롬프트를 필터링하거나 변환하고, 민감한 데이터를 마스킹하며, 테넌트 격리를 시행하고, 알려진 공격 패턴을 차단하는 데 도움이 될 수 있습니다. 계획 단계에서는 실행이 허용되기 전에 AI 에이전트가 구조화된 계획을 생성하도록 요구하고, 각 단계를 허용된 툴, 작업 및 위험 조건에 따라 검증할 수 있습니다.

실행 시에는 모든 툴 호출이나 API 호출을 정책 시행 계층에서 검사할 수 있습니다. 이 계층은 작업을 허용, 거부 또는 수정할지, 또는 사람에게 에스컬레이션할지를 결정합니다. 실행 후에는 정책이 로깅, 감사 추적, 보존 규칙 및 모델 아웃풋에 대한 사후 필터를 제어하여 응답이 필요한 요구 사항을 준수하도록 지원할 수 있습니다.

• 일관성. PaC를 사용하면 동일한 코드가 모든 곳에서 실행되므로 모든 환경에 정책이 동일한 방식으로 적용됩니다. 이러한 일관성은 일회성 ‘스노플레이크’ 구성을 줄이고, 팀이 환경별로 조금씩 다른 수동 프로세스를 기억해야 하는 상황을 방지합니다.

• 효율성. 정책을 코드로 정의하면 CI/CD 파이프라인 또는 배포 시점에 자동으로 시행할 수 있으므로 수동 검사와 승인이 필요하지 않습니다.

• 자동화. PaC를 사용하면 자동화된 유효성 검증과 정책 테스트가 가능하므로, 팀은 인적 오류의 영향을 최소화하고 잘못된 구성을 포착하며 보안 취약점이 프로덕션에 도달하기 전에 해결할 수 있습니다.

• 가시성. 정책을 코드로 작성하여 중앙에서 관리하면 이해관계자는 분산된 문서와 개인의 기억에 의존하지 않고 적용 중인 규칙을 정확히 확인할 수 있습니다.

• 확장성. 정책 평가가 자동화되므로 조직은 인력 규모를 그에 비례하여 늘리지 않고도 여러 서비스, 클러스터 또는 계정 전반에 걸쳐 대규모로 정책을 시행할 수 있습니다.

• 협업. PaC는 정책 코드를 중심으로 한 협업을 간소화합니다. 이러한 공유 워크플로는 사일로를 해소하고, 보안 및 거버넌스를 DevOps 사례에 맞추며, 정책 논의를 더욱 구체적이고 테스트 가능하게 만듭니다.