AI agent 보안, PR 검토 대신 MCP 서버로 회사 규칙을 먼저 건넨다

AI agent로 코드를 만드는 속도가 빨라지면서, 보안 검토를 pull request(코드 변경을 합치기 전에 검토를 요청하는 단계, 이하 PR) 단계에서 하던 방식이 한계에 부딪히고 있습니다. 아이디어에서 실제 배포까지 몇 달 걸리던 일이 1~2주, 때로는 며칠로 줄었고, 개발자가 아닌 직원도 직접 업무용 앱을 만들어 씁니다. SpaceX와 xAI에서 보안을 맡은 한 엔지니어는 그 해법으로 보안팀이 회사의 보안 규칙을 agent가 바로 꺼내 쓸 수 있는 형태로 건네는 방식을 제시합니다. 핵심 도구는 MCP(Model Context Protocol, AI agent가 외부 도구와 데이터에 접속하는 표준 규격) 서버와 코딩 도구의 hook(특정 시점에 자동으로 실행되는 사용자 설정 작업)입니다.

PR 단계 보안 검토가 따라가지 못하는 이유

예전의 개발 과정은 요구사항 문서와 설계 문서를 쓰고, 코드를 짠 뒤 PR을 올려 동료 승인을 받고, 자동 테스트와 staging 환경, 품질 검사를 거쳐 운영 환경에 배포하는 순서였습니다. 코딩에 특화된 대규모 언어 모델이 나온 최근 12~18개월 사이에 이 긴 일정이 무너졌습니다. 개발자는 대화형 화면이나 agent 안에서 코드를 만들고 고치며, 여러 모델 세션을 동시에 돌립니다. 기능을 거의 곧바로 수백만 사용자에게 내놓고, 오랜 사전 검사보다 운영 환경의 반응으로 결과를 확인하는 회사도 있습니다.

더 큰 변화는 개발 조직 밖에서 일어납니다. 채용팀 같은 비개발 부서 직원이 개발팀에 요청하는 대신 AI 모델에게 필요한 도구를 만들게 하고 직접 띄워 씁니다. 이런 도구는 개발팀을 거치지 않으므로 정적 분석, 보안 검토, 표준 테스트를 모두 건너뜁니다.

보안 인력의 비율로 보면 문제가 분명해집니다.

정적 분석(SAST)과 오픈소스 구성 분석(SCA)을 PR마다 기다리는 방식은 agent 여러 개가 동시에 코드를 낼 때 병목이 됩니다. 어떤 코딩 도구는 agent가 리뷰 댓글을 읽고 스스로 고쳐 다시 올리는 기능을 갖췄는데, 리뷰 봇이 문제를 지적하고 다른 agent가 고친 코드를 올리는 일이 PR 댓글에서 계속 오가기도 합니다. 그래서 보안 검증은 PR 단계가 아니라 코드를 만드는 그 자리에서 이뤄져야 한다는 주장입니다.

보안 규칙을 agent의 작업 맥락에 넣는 방법

AI agent 사용을 막는 것은 현실적인 해법이 아닙니다. 보안팀이 일하는 방식을 바꿔, 개발자와 비개발 직원이 이미 일하는 자리로 보안 규칙을 가져가야 합니다. 회사 정책, 안전한 코딩 방식, 미리 검증된 표준 경로(paved road, 보안 요건을 갖춰 둔 권장 개발 방식)를 agent가 바로 읽을 수 있는 형태로 묶는 것이 출발점입니다.

구체적인 방법은 두 가지입니다.

• 코딩 도구의 hook: Cursor 같은 agent형 코드 편집기가 지원하는 hook에 보안 점검을 걸어, agent가 작업하는 동안 회사 규칙을 자동으로 확인하게 합니다.
• 보안팀이 운영하는 MCP 서버: agent나 개발자가 작업에 맞는 보안 지침을 MCP 서버에 물어봅니다. 예를 들어 serverless 클라우드 인프라를 만들기 전에 관련 정책을 조회하면, 받아 온 정책이 모델의 context window(모델이 한 번에 참고하는 작업 맥락)에 들어가고 그 뒤에 만드는 코드가 회사 기준을 따르게 됩니다.

▲ agent가 조회하는 보안 정책

표준 경로의 개념 자체는 바뀌지 않지만 전달 방식은 바뀝니다. 지금까지는 문서나 코드 템플릿으로 나눠 줬다면, 이제는 agent가 function calling(모델이 정해진 형식으로 외부 기능을 호출하는 방식)으로 부를 수 있는 API와 도구 정의로 내놓아야 합니다. agent가 정적인 정책 문서를 찾아 읽지 않고도 필요한 규칙을 스스로 조회해 지킬 수 있기 때문입니다.

사람이 못 하던 shift-left를 agent가 해낸다

개발 초기 단계에서 보안 문제를 잡자는 shift-left는 오래된 목표였지만, 개발자의 피로와 시간 압박 때문에 잘 지켜지지 않았습니다. agent는 이런 한계가 없습니다. 많은 lint 규칙(코드의 오류와 규칙 위반을 찾는 자동 검사)을 받아들이고, 보안 검사를 뒤에서 돌리며, 지적된 문제를 바로 고칩니다. 예를 들어 Terraform 설정을 검사하는 편집기 lint가 공개로 열린 Amazon S3 버킷이나 지나치게 넓은 신뢰 정책을 찾으면 agent가 곧바로 고칩니다. agent에게 로컬 lint, 허용된 라이브러리 목록, 회사 정책을 함께 주면 PR을 올리기 전에 스스로 고칠 수 있습니다.

새 AI 보안 도구보다 기본 통제가 먼저

흔한 실수는 새로 나온 AI 보안 도구를 좇느라 기본적인 예방 통제를 소홀히 하는 것입니다. ’AI 보안’의 정의는 업계에서 아직 제각각이라, 열 명에게 물으면 열 가지 답이 나올 정도라는 지적도 있습니다. 반면 AWS의 Service Control Policies(SCP), GCP의 조직 정책, 리소스 통제 정책 같은 클라우드 기본 통제는 agent가 넘을 수 없는 확실한 울타리입니다. 실행 환경 격리, 네트워크 분리, 운영체제 수준 분리도 유용하지만, 신원·권한 관리와 클라우드 경계를 대신할 수는 없습니다.

권한 설계도 중요합니다. 지나친 권한을 가진 agent가 운영 데이터베이스를 통째로 지웠다는 사례가 알려져 있습니다. agent에게 사람의 검토 없이 운영 환경에 코드나 인프라 변경을 바로 밀어 넣을 쓰기 권한을 주는 것은 피해야 할 방식입니다. 수정이나 삭제처럼 상태를 바꾸는 작업에는 감사 기록과 사람의 명시적인 승인이 있어야 합니다.

책임 소재도 따져야 합니다. 사용자의 메일을 읽고 Slack 메시지를 보내는 개인 비서형 agent는 사용자를 대신해 움직이므로 책임은 그 사용자에게 있습니다. 반면 사람의 감독 없이 클라우드에서 혼자 도는 agent에게는 책임을 물을 수 없습니다. IBM의 오래된 원칙처럼 기계는 책임질 수 없으므로 관리 결정을 내려서는 안 됩니다. 그래서 자율 agent는 신원(identity) 측면과 네트워크 측면에서 접근 범위를 모두 좁히고, 할 수 있는 기능을 명시적으로 정해 두어야 합니다.

agent 유형과 작업 종류에 따라 통제를 달리한다

agent는 크게 두 가지로 나눌 수 있고, 사용자를 대신해 브라우저를 다루는 agent가 따로 있습니다.

분류에서 더 중요한 기준은 작업의 종류입니다. 공개된 S3 버킷을 찾는 것처럼 설정을 읽기만 하는 조회는 권한 경계만 지키면 대화형이든 코딩형이든 위험이 비슷합니다. 만들기, 수정, 삭제처럼 상태를 바꾸는 작업은 위험이 훨씬 커서 철저한 감시와 사람의 개입이 필요합니다. OpenTelemetry(시스템 동작 기록을 수집하는 오픈소스 표준)로 어떤 agent가 언제 어떤 도구와 데이터에 접근했는지 남겨 두면 나중에 추적할 수 있습니다.

MCP 서버는 결국 기존 API를 감싼 것이므로 네트워크나 API gateway 단계에서 통제할 수 있습니다. 회사 네트워크에서 어떤 서비스의 API를 막으면, 그 API에 기대는 MCP 서버도 안전하게 작동을 멈춥니다.

▲ agent 격리와 접근 통제

이 밖에 agent를 직원 컴퓨터가 아니라 클라우드의 격리된 sandbox(외부와 분리된 실행 공간)에서 돌리고, 나가는 네트워크 연결을 걸러 내며, 자격 증명은 프록시가 요청에 붙이게 해 비밀값이 모델에게 노출되지 않게 하는 방식이 권장됩니다. 다만 운영체제 격리와 나가는 연결 통제는 agent가 외부 호출을 워낙 많이 하는 탓에 아직 풀리지 않은 과제로 남아 있습니다. 데이터에도 개인정보처럼 민감한 자산을 구분하는 목록과 표시를 붙여, agent가 접근하면 안 되는 데이터를 프로그램으로 알아보게 해야 합니다.

보안팀이 직접 만드는 내부 도구

AI agent는 보안팀에게도 기회입니다. 예전에는 내부 보안 플랫폼을 만들려면 소프트웨어 개발 역량을 갖춘 인력이 따로 필요했지만, 이제는 분명한 아이디어만 있으면 보안 담당자가 직접 만들 수 있습니다. 상용 보안 업체가 수익이 나지 않아 만들지 않는, 회사마다 다른 작업 흐름에 맞춘 도구가 특히 그렇습니다. 사서 쓸지 만들어 쓸지의 계산이 달라진 셈입니다.

대표적인 사례가 정책 차단 설명 봇입니다. 개발자가 Kubernetes admission controller(클러스터에 들어오는 요청을 정책에 따라 허용하거나 막는 장치)나 AWS SCP에 막혀 HTTP 403 오류를 받으면, 예전에는 화면을 캡처해 Slack 채널에 올리고 보안팀에 이유를 물었습니다. 보안팀이 만든 Slack 봇은 이 오류를 읽고 어떤 정책에 걸렸는지, 어느 설정이 문제인지, 어떤 값으로 바꾸면 되는지 설명합니다. 예외가 꼭 필요하면 신청 절차를 안내하고 사람의 승인이 필요할 때만 보안 엔지니어를 부릅니다. 이 봇 하나로 반복되는 보안 문의와 업무 중단이 25~30% 줄어들 수 있다고 합니다. 같은 방식을 HIPAA나 PCI DSS 같은 규제 준수 영역으로 넓힐 수도 있습니다.

agent를 만들어 본 적 없는 보안 담당자라면 다음 순서로 시작할 수 있습니다.

1. 1~2주 동안 AI를 일상 업무의 보조 도구로 씁니다.
2. 모델이 잘하는 일, 사람이 바로잡아야 하는 일, 사람이 해야만 하는 일을 나눠 봅니다.
3. 같은 단계를 되풀이하는 업무를 찾아 자동화 흐름이나 agent 도구로 바꿉니다.

예를 들어 대량으로 들어오는 버그 바운티 제보의 1차 분류는 코드베이스 맥락을 준 agent에게 맡길 수 있습니다.

다만 보안팀이 만드는 agent일수록 더 조심해야 합니다. 보안팀은 관리자급 자격 증명을 가진 경우가 많아, 보안 agent가 탈취되거나 사칭되면 피해가 매우 큽니다. 보안팀은 개발팀에 요구하는 정책과 격리 기준을 자기 agent에도 똑같이 적용해야 합니다. 그리고 자격 증명을 모델에 노출하지 않고 agent에 넘기는 방법처럼 직접 풀어 낸 문제는 회사 전체가 쓸 표준 경로로 만들어 나누는 것이 좋습니다.

agent가 늘어날수록 플랫폼이 필요하다

대부분의 기업에서 AI를 제대로 활용하는 팀은 아직 한두 곳뿐입니다. 이를 회사 전체로 넓히면 예전 microservice가 무분별하게 늘어났던 것처럼 agent도 관리되지 않은 채 늘어날 수 있습니다. 그때 Kubernetes와 클라우드 네이티브 플랫폼이 microservice를 표준화했듯, 이제는 승인된 템플릿과 기록 수집 기능을 갖춘 사내 AI 플랫폼이 필요하다는 주장입니다. 직원이 1만 명이 넘는 대기업도 플랫폼을 통해 어떤 agent가 돌고 있는지 파악하고, 기준에 맞지 않는 배포를 격리하고, 사고에 빨리 대응할 수 있습니다.

정리: 보안팀이 지금 점검할 일

agent 시대의 보안은 마지막 관문에서 막는 방식이 아니라, agent가 일하는 자리에 회사 규칙을 미리 놓아두는 방식으로 옮겨 가는 것으로 보입니다. 다음 항목부터 점검해 볼 수 있습니다.

• 보안 지침을 API로 제공: 보안 정책과 표준 경로를 MCP 서버나 function calling 도구로 만들어 agent가 작업 전에 조회하게 합니다.
• 검사를 생성 단계로 이동: lint와 정책 검사를 PR이 아니라 agent의 로컬 작업 흐름에서 돌립니다.
• 기본 통제 확인: SCP, 조직 정책, 최소 권한, 데이터 분류가 제대로 걸려 있는지 먼저 봅니다.
• 쓰기 작업 승인: 운영 환경을 바꾸는 작업에는 사람의 승인과 감사 기록을 남깁니다.
• 실행 환경 격리: agent를 격리된 sandbox에서 돌리고 나가는 연결과 자격 증명을 통제합니다.
• 보안팀 agent도 같은 기준 적용: 높은 권한을 가진 보안팀 자동화일수록 더 엄격하게 관리합니다.