에이전트 컨트롤 플레인

여러 AI 에이전트를 한곳에서 보고 권한·정책·승인·감사 기록으로 통제하는 관리 계층으로, 에이전트가 하는 일을 밖에서 지켜보고 허용할지 말지 정한다. 코딩 에이전트를 여러 개 동시에 돌리거나 팀 전체가 쓰기 시작할 때 필요하다.

OpenHands가 정리한 소프트웨어 에이전트 스택 기준

이름은 네트워크 용어에서 왔다. 코딩 에이전트에서는 코드 수정·명령 실행처럼 실제 일을 하는 쪽이 데이터 플레인이고, 누가 무엇에 접근하고 어떤 행동에 승인이 필요한지 정하는 쪽이 컨트롤 플레인이다.

규칙을 프롬프트 밖으로 꺼낸다

컨트롤 플레인이 없으면 권한·예산·감사 규칙을 에이전트마다 프롬프트와 코드에 따로 넣어야 한다. 그러면 규칙을 검사하거나 버전 관리하거나 강제할 방법이 없다. 컨트롤 플레인은 '이 행동을 해도 되는가'라는 판단을 실행과 떼어 놓는다. 예를 들어 허용된 모델 목록을 정해 두면 에이전트가 더 비싼 모델이나 허가되지 않은 엔드포인트를 몰래 호출하지 못한다. 이 제한은 실행 중에 걸린다.

핵심 기능은 다섯 가지

상황에 따라 붙이는 방식이 다르다

터미널에서 여러 CLI 에이전트를 한 저장소에 돌리면 로그만으로는 누가 무엇을 하는지 알기 어렵다. 이때는 각 세션 상태를 한 화면에 모아 주는 '관제실' 형태가 필요하다. 팀에 이미 LLM·MCP 게이트웨이가 있다면 게이트웨이에 정책 층을 붙이는 방식이 있다. SDK를 넣거나 에이전트를 고칠 필요가 없고, PR당 비용까지 집계할 수 있다. 사람 없이 오래 도는 에이전트는 Kubernetes 위의 스케줄러로 돌리고, 중요한 작업 전에 사람에게 비동기로 피드백을 요청하게 만든다.

도입은 처음부터 막지 말고 감사 모드로 시작하는 편이 낫다. 기록만 남기면서 어떤 행동이 위험한지 먼저 보고, 그다음 차단 정책으로 넘어가면 개발 속도를 덜 해친다.

아직 정의가 업체마다 다르다

같은 이름이라도 게이트웨이에 붙는 정책 층, 에이전트 스케줄러, 신원 보안 플랫폼처럼 실제 모습이 제각각이다. 프롬프트 인젝션 방어, 운영 환경 삭제 같은 사고 예방, 비용 추적 가운데 무엇이 가장 급한지 먼저 정하고 도구를 고르는 게 좋다.

주로 위험한 행동을 막고 비용을 보는 데 쓴다

가장 흔한 건 여러 코딩 에이전트를 돌리는 팀이 위험한 행동에 승인 단계를 걸고 누가 무엇을 했는지 기록을 남기는 방식이다. 처음엔 감사 모드로 지켜보다가 문제가 되는 행동만 차단 정책으로 옮긴다.