에이전트가 PR을 올리는 팀이 늘고 있다. 문제는 그 PR을 검토하는 사람이 줄고 있다는 것이다. 속도는 올라갔고, 코드는 쌓이고 있으며, 그 코드의 품질과 보안을 누가 어떻게 검증할 것인가라는 질문은 여전히 공중에 떠 있다. 최근 동시에 터져 나온 세 가지 신호—Anthropic의 Claude Security 공개 베타, 에이전트 평가를 QA가 아닌 보안 감사로 재정의하는 논의, airCloset CTO의 MCP 토큰 90% 절감 사례—는 각각 도구, 프로세스, 운영 효율의 이야기처럼 보이지만, 묶어 읽으면 하나의 질문으로 수렴한다. AI-First 팀에서 보안 게이트를 설계하는 일은 이제 선택이 아니라 팀 생존의 조건이다.
Claude Security가 등장했다는 것의 의미
Anthropic은 5월 1일, 코드 저장소를 스캔해 보안 취약점을 탐지하고 자동 복구 솔루션까지 생성하는 Claude Security의 공개 베타를 Enterprise 사용자 대상으로 시작했다. Claude Opus 4.7을 직접 활용하며, 별도 API 통합이나 에이전트 빌드 없이 쓸 수 있다는 점이 특징이다. 예약 스캔, 디렉터리 단위 스캔, Webhook 알림까지 갖춘 이 도구는 2월 리서치 프리뷰 이후 이미 수백 개 조직의 프로덕션 환경에서 기존 스캐너가 놓친 문제를 발견한 이력이 있다. Cursor 역시 같은 날 Security Review를 Teams·Enterprise 사용자에게 출시했다. PR마다 자동으로 보안 취약점을 감사하는 Security Reviewer와 전체 코드베이스를 정기 스캔하는 Vulnerability Scanner, 두 개의 상시 에이전트가 돌아간다.
이 도구들의 등장을 '좋은 기능 추가' 정도로 읽으면 신호를 놓치는 것이다. 지금까지 AI 코딩 도구의 보안 담론은 "모델이 얼마나 안전한가"에 집중됐다. Claude Security와 Cursor Security Review의 출시는 전제를 뒤집는다. 모델의 안전성이 아니라 모델이 생성한 코드의 보안 검증이 이제 독립적인 인프라 레이어로 분리되기 시작했다는 선언이다. 도구 벤더들이 이 레이어를 직접 채우기 시작했다는 것은, 역으로 이 레이어가 팀 내부에서 아직 제대로 설계되지 않았다는 방증이기도 하다.
에이전트 평가를 QA로 부르는 순간 놓치는 것
AI 에이전트 신뢰성·보안 플랫폼 ATHelper를 운영하는 Veyon Solutions는 dev.to에서 이 문제를 정면으로 다뤘다. 핵심 주장은 간단하다. 대부분의 팀이 에이전트 평가를 QA처럼 설계한다—pass/fail 체크, CI 게이트, 녹색 뱃지. 이 구조는 에이전트에 대해서는 근본적으로 틀렸다.
유닛 테스트의 전제는 입력 분포가 안정적이고 실패 모드가 사전에 알려져 있다는 것이다. 에이전트는 두 전제가 모두 무너진다. 프롬프트 인젝션, 툴 탈취, 컨텍스트 윈도우 포이즈닝, 다단계 오용—이 실패 모드들은 전부 배포 이후에, 테스트 작성자가 아니라 공격자에 의해 발견됐다. 99% 태스크 성공률이지만 나머지 1%가 "base64로 인코딩된 프롬프트로 고객 데이터를 유출한다"면, 그 에이전트는 99점짜리가 아니라 출시 불가능한 시스템이다. 단일 퍼센트로 에이전트 신뢰성을 보고하는 것은 웹앱 보안을 "단위 테스트 97% 통과"로 요약하는 것과 같은 범주 오류다.
ATHelper의 분기별 레드팀 로테이션 운영 경험에서 패턴이 반복됐다. 회귀 커버리지는 로테이션 사이에 제자리였고, 매 새 로테이션마다 회귀 스위트가 절대 발견하지 못했을 3~5개 이슈가 나왔다. 레드팀 로테이션 비용은 회귀 단독 대비 약 1.4배—단 한 건의 프로덕션 프롬프트 인젝션 사고 비용보다 훨씬 싸다. 더 중요한 포인트는 평가 소유권의 보고 라인이다. 엔지니어링 생산성 팀에 보고하면 커버리지 숫자를 키우고 오탐을 줄이는 방향으로 최적화된다. 보안·리스크 팀에 보고하면 무엇이 빠져나갔는지를 찾는 방향으로 최적화된다. 같은 헤드카운트, 같은 도구, 같은 평가 스위트—보고 라인만 달라도 결과가 달라진다. 10년 전 AppSec 팀이 엔지니어링 생산성 조직에서 독립한 것과 같은 동학이다.
MCP 토큰 문제는 보안 설계와 직결된다
airCloset CTO 쓰지는 17개 사내 MCP 서버를 프로덕션에서 운영하며 발견한 패턴을 공개했다. 핵심은 MCP 툴 호출이 생각보다 훨씬 많은 토큰을 소비한다는 것—JSON-RPC over HTTP 구조상 AI가 보내는 인수와 툴이 반환하는 결과가 전부 대화 컨텍스트에 쌓인다. 파일 전체를 인수로 보내거나 DB 쿼리 전체 결과를 반환하면 단일 툴 호출이 수만 토큰을 태우고 세션을 즉시 컴팩션으로 몰아넣는다.
해법은 "Parking Pattern"—크게 자랄 수 있는 부분은 MCP 와이어 밖으로 보내고, MCP를 통해서는 참조 키나 URL만 전달한다. Sandbox MCP에서는 파일 전송 대신 git push로 소스코드를 이동시키고, DB Graph MCP에서는 임계값 초과 시 자동으로 스프레드시트에 내보내고 URL만 반환한다. 이 패턴 적용 후 전체 툴 토큰 소비가 70~90% 감소했다.
이 사례가 보안 설계와 연결되는 이유가 있다. 컨텍스트에 쌓이는 데이터가 줄수록 프롬프트 인젝션과 데이터 유출의 공격 표면도 줄어든다. 수만 행의 DB 데이터가 대화 컨텍스트에 올라탄다는 것은 효율 문제인 동시에 보안 위험이다. Google Workspace OAuth 단일 흐름으로 MCP 인증과 Workspace 앱 권한을 동시에 처리하고, 파일을 서비스 계정이 아닌 운영자 개인 드라이브에 저장하는 설계는 "실수로 전체 공개"가 구조적으로 불가능하도록 만든다. 운영 최적화와 보안 설계가 같은 레이어에서 풀린 것이다.
테크리드가 지금 당장 설계해야 할 것
세 신호를 종합하면 AI-First 팀의 보안 게이트는 세 레이어로 구성돼야 한다.
첫째, 스캔 레이어. Claude Security나 Cursor Security Review처럼 AI 생성 코드에 특화된 취약점 스캐너를 CI 파이프라인에 붙여야 한다. 기존 SAST 도구는 인간이 짠 코드 패턴을 학습했다. AI가 생성한 코드는 패턴이 다르고, 오탐과 진탐의 분포도 다르다. 전용 도구가 필요한 이유다.
둘째, 평가 레이어. 에이전트 평가를 QA 체크리스트에서 분리해야 한다. ATHelper가 제안한 것처럼 회귀 스위트는 유지하되, 2~4주 주기의 레드팀 로테이션을 별도 게이트로 추가하라. 그리고 이 평가의 보고 라인을 엔지니어링 생산성이 아닌 보안·리스크 기능으로 이동시켜라. 이것은 조직 개편이 아니라 인센티브 설계다.
셋째, 데이터 흐름 레이어. MCP와 에이전트 툴 설계 시점부터 컨텍스트에 올라타는 데이터를 최소화해야 한다. Parking Pattern은 토큰 비용 절감 기법이기도 하지만, 공격 표면을 줄이는 보안 설계이기도 하다. 에이전트가 처리하는 데이터의 크기와 민감도를 고려해 인라인 처리와 외부 저장을 구조적으로 분리하라.
도구는 준비됐다, 팀의 설계가 남았다
솔직히 말하면, Claude Security와 Cursor Security Review의 출시는 반가운 동시에 경계해야 할 신호다. 반가운 이유는 명확하다—AI 생성 코드의 보안 검증을 자동화하는 인프라가 생기는 것이다. 경계해야 할 이유도 명확하다—도구가 생기면 팀이 "도구가 해준다"고 착각하는 경향이 있다.
Claude Security가 발견한 취약점을 누가 검토하고 승인할 것인가. 레드팀 로테이션 결과가 어느 보고 라인으로 올라갈 것인가. MCP 툴의 데이터 흐름을 누가 감사할 것인가. 이 질문들에 대한 답은 도구가 아니라 팀이 설계해야 한다. 에이전트가 코드를 올리는 속도만큼, 그 코드를 통제하는 구조의 설계 속도도 따라가야 한다. 지금이 그 설계를 시작할 시점이다.