AI 에이전트가 대두되면서, 많은 조직과 개발자들이 작업 효율성이 미친듯이 올라갔다고 증언하고 있다.
인간은 목표만 설정해두면 에이전트들이 자율적으로 작업을 이뤄나가며, 인간의 개입이 거의 없어도 제품을 만들어낸다는 시대가 되었다.
하지만, 그와 동시에 AI 에이전트에게 너무 많은 권한을 위임하는 것은 보안상 위험할 수 있다는 전문가들의 지적도 꾸준히 나오고 있다.
그래서 AI 에이전트의 자율성은 ‘작업 효율 향상’과 ‘보안 취약’이라는 양날의 검을 가지고 있다고 표현하는 것이다.
물론 보안 취약성 때문에 AI 에이전트를 쓰지 말라는 이야기를 하려는 것이 아니다.
이미 세상에는 너무나 다양한 제품이 AI 에이전트로 빠르고 효율적으로 개발되고 있다.
그렇기 때문에 시대를 거스르지 않으면서도 안전을 확보하는 방법이 필요하다는 이야기를 하려는 것이다.
이렇게 생각해볼 수도 있겠다.
AI가 자유롭게 뛰놀 수 있는 자율성은 주되, 보안에 민감한 영역으로 넘어가지 못하도록 활동 영역을 제한하면 어떨까?
이러한 방식을 직관적인 단어로 표현하면 가드레일(Guard rail) 접근법이라 한다.
가드레일이란, 주행 중인 자동차가 사고로 이어질 위험이 있는 탈선을 막기 위해 도로를 따라 설치해두는 철제 구조물을 의미한다.
이를 AI 주도 개발에 대입해보자. 에이전트에게 어느 방향으로 어떻게 작업을 하든 충분한 자율성을 주되, 넘어가면 안 되는 울타리를 설정하는 것이다.
이것을 다르게 말하면 ‘조직이 제어하길 원하는 AI 활용 범위’인데, 조금 더 정제해서 표현하면 ‘조직의 AI 활용 정책’이라고 할 수 있다.
즉, 에이전트가 접근할 수 있는 데이터, 수행할 수 있는 작업, 사람의 승인이 필요한 시점 등을 정책(Policy)으로 정의하는 것이다.
특히 클라우드 기반으로 서비스하는 조직에서의 예를 들면 아래와 같다.
- 민감한 데이터가 저장된 특정 DB의 외부 접근 허용 금지
- 서비스 배포 시 검증된 레지스트리의 이미지만 사용
- 에이전트가 생성한 Kubernetes 리소스는 관리자가 검토 후 태그를 변경하기 전까지 트래픽 차단
이런 정책들은 잘 지켜지면 조직과 서비스를 안전하게 지켜줄 수 있다. 하지만 이런 정책들이 문서로만 이루어져있다면 어떻게 될까?
AI 에이전트마다 일일이 정책이 공유되어야 하고, 관리자는 매번 정책 문서를 들여다보며 일을 처리해야 한다. 그러다보면 자연스레 현실 상황과 문서와의 괴리가 생긴다.
정책이라고 하면 그 누구도 업데이트할 엄두를 못 낸 탓에 현실과의 갭이 엄청나게 벌어져버린 따분한 문서라는 인식이 생긴 것도 이 때문이다.
그래서 정책을 문서로만 남기지 않고, 실제 운영 환경(클라우드)에 적용하기 위해 등장한 개념이 있다. 바로 PaC(Policy as Code)이다.
혹시 IaC(Infrastructure as Code)라고 들어봤는가?
AWS, GCP, Kubernetes 등의 클라우드 클러스터를 구성하는 요소(컴포넌트)를 일일이 직접 배포하고 설치하는 과정을 자동화하기 위해, 필요한 리소스와 작업들(Infrastructure)을 스크립트(Code) 안에 모두 정의해서 스크립트 실행만으로 쉽게 클러스터 구축을 할 수 있는 기술이다. Terraform이 대표적인 IaC 툴이다.
Iac는 클러스터 구축을 자동화할 수도 있지만, 해당 스크립트를 Git과 같은 버전 컨트롤 시스템에서 관리할 수 있다는 점에 우리는 주목해야 한다. 왜냐하면…
- 클러스터 구축 스크립트 수정 시 각 변경 사항이 저장되어 추적이 가능하고,
- 스크립트를 공유하기도 용이하기 때문이다.
IaC에 대해 잠시 알아본 이유는, PaC의 특징이 이와 유사하기 때문이다.
PaC는 조직의 개발, 보안, 운영과 관련된 정책(Policy)을 스크립트(Code)로 정의하는 것이다.
사람이 정책 문서를 보며 직접 준수 여부를 확인하는 기존 방식이 아닌, 특정 툴이 스크립트로 정의된 정책들을 자동으로 확인하고 준수하도록 조치하는 개념이다.
그리고 스크립트로 정의된 정책은 Git에서 관리할 수 있다. (그러므로 IaC와 동일한 특징을 공유하게 된다.)
이렇게 보안과 운영 부분에서 민감한 데이터가 있는 영역은 접근을 제한하는 등의 정책을 자동화할 수 있으므로, AI 에이전트로 개발 시 PaC가 가드레일 역할을 할 수 있다는 것이다.
갑작스러운 PaC의 등장에 당황했을 수도 있다.
걱정하지 않아도 된다. 아래에서 PaC의 히스토리와 흐름을 같이 따라가다보면 PaC에 대해 자연스레 이해할 수 있을 것이다.
PaC를 이해하려면 그 히스토리를 알아야 한다
위에서 살펴본 것처럼, PaC가 등장하기 전의 정책이라 함은 문서로 정의해서 관리하는 것이었다.
‘소스코드에 암호를 포함시키지 않는다’, ‘컨테이너는 root 유저로 실행하지 않는다’와 같은 정책이 문서화되면, 개발자가 정책을 직접 참고해야 했기 때문에 정책 구현(문서화)에 시간이 많이 소요되고 정책 준수에도 오류가 발생하기 쉬웠다.
또한 정책 관리를 수동으로 했던 기존 방식에서는 조직이 확장되고 자산과 인원이 증가할수록 정책 준수를 강제하기 위한 노력 역시 더 들 수밖에 없었다.
그렇다보니 자연스레 정책 정의나 준수 과정에서 휴먼 에러가 생기는 경우가 많았다.
이렇게 정책 적용 자동화의 필요성이 증가하면서 PaC가 등장했고, 다양한 PaC 툴이 개발되었다.
대표적인 PaC 툴로는 Kyverno와 Cloud Custodian이 있다.
Kyverno는 k8s 환경에서 정책을 관리하고 시행하기 위해 설계된 오픈소스 정책 엔진이다.
Kubernetes 클러스터의 ‘문지기’ 역할을 하며, 클러스터에 들어오는 모든 리소스 생성 및 변경 요청을 감지하고, 정의된 정책에 따라 허용, 차단 또는 수정 작업을 수행하는 것이다.
Cloud Custodian은 클라우드 리소스를 필터링, 태그 등으로 관리할 수 있는 오픈소스 툴이다.
Kubernetes뿐만 아니라 퍼블릭 클라우드 AWS와 Azure, GCP도 지원하므로, 다양한 클라우드를 사용하는 조직이 정책을 통일해서 관리하기 좋다.
‘우아한형제들’은 재작년 주최한 기술 컨퍼런스 ‘우아콘’의 발표에서 Cloud Custodian을 도입하여 대규모 AWS 클라우드 리소스를 관리하는 정책을 체계적으로 표준화했다고 밝혔다.
이런 PaC는 DevOps 문화에 보안(Sec)이 결합된 DevSecOps가 대두되면서 많은 관심을 얻게 되었다.
기존의 정책 관리 방식을 개선할 수 있는 대안책으로 인식되기 시작한 것이다.
에이전트에 PaC를 도입하면 어떤 효과가 있을까?
DORA 메트릭으로 유명한 Google의 DORA 팀은 2025년 공개한 ‘State of AI-assisted Software Development’ 보고서에서 AI 역량 모델(AI Capabilities Model)을 새로 선보였다. AI를 잘 사용하는 조직의 사례를 모은 다음, 공통적으로 관찰되는 특징을 모아 분류한 체크리스트라고 할 수 있겠다.
조직의 기술과 문화를 모두 아우르는 7개 항목으로 구성된 DORA AI 역량 모델은 조직이 앞으로 어느 분야에 투자해야 AI 도구를 더 잘 쓸 수 있을지 가늠하게 해준다.
갑자기 DORA 팀의 AI 역량 모델을 이야기하는 이유는, 해당 모델의 항목 중 ‘명확하고 공유된 AI 활용 원칙(Clear and communicated AI stance)‘이 우리가 지금까지 살펴본 AI 에이전트의 가드레일과 연관되기 때문이다.
DORA AI 역량 모델의 해당 원칙은 개발자가 어떤 AI 도구를 어떻게 사용할 수 있는지에 대해서 조직의 공식적인 원칙이 있어야 AI를 잘 도입할 수 있음을 시사한다.
즉,
- 조직의 AI 활용에 대한 정책이 명확할수록,
- 조직의 AI 정책이 개발자들에게 직접적으로 체감될수록
AI 도입으로 개발자 개인의 효율성과 조직의 성과는 증가했고, 불필요한 마찰은 감소했다는 응답이 많았다고 한다.
그리고 아마 감을 잡았을 수 있는데, 명확하고 직접적인 정책은 PaC의 대표적인 특징이다.
정리하면 이렇다. PaC를 통해 AI 에이전트의 가드레일을 명확하고 투명하게 설정하면, 조직 내 불필요한 마찰을 줄이면서 조직의 성과가 증가할 수 있다는 것이다.
마무리: 게이트키퍼에서 가드레일로
AI 에이전트 시대에 오면서 우리는 인간이 명령하는 것만 수행하는 AI에서 자율적으로 움직이는 AI를 만나게 되었다.
AI가 수행하는 작업의 각 스텝마다 인간이 ‘게이트키퍼(문지기)‘로서 개입하는 시대는 지나갔다는 이야기다.
그래서 더욱이 AI 에이전트의 자율성으로 인한 보안 취약 위험은 우리가 예기치 못한 때에 돌이킬 수 없는 사고로 이어질 수 있다. 에이전트가 작업하는 것을 하나하나 두 눈 크게 뜨고 낱낱이 살펴본다면 모를까. (과연 그렇게 하고 싶은 사람이 얼마나 있을지 모르겠다.)
에이전트가 작업을 수행하는 과정에서 어떤 행동을 할지 예상하기 어렵다면, 에이전트가 뛰놀 수 있는 범위를 가드레일로 정해주면 된다. 그리고 클라우드 네이티브 환경에서 이런 가드레일 역할을 효과적으로 수행해줄 수 있는 기술이 바로 PaC라고 할 수 있다.
만약 AI 에이전트를 사용하면서 예상치 못한 보안 사고가 걱정된다면, 우리가 함께 알아본 PaC를 도입하는 것을 고려보면 어떨까?
꼭 바로 도입하지 않더라도, AI 에이전트가 울타리를 넘어가면 안 되는 영역을 정의하는 것이 에이전트 운영에 큰 도움이 될 것이다.