병합 버튼 앞에서 멈춰야 하는 이유
AI 에이전트가 PR을 만들어주는 속도는 이제 팀의 리뷰 속도를 앞서기 시작했다. 문제는 속도가 아니다. diff가 깔끔해 보인다는 이유로 병합 버튼을 누르는 습관이다. dev.to에 공유된 한 엔지니어의 회고는 이 습관이 얼마나 조용히 팀을 망가뜨리는지를 정확히 짚는다. 에이전트 PR이 장기 기술 부채와 스코프 드리프트로 이어지는 가장 흔한 경로는 세 가지다: 빈 입력값에서 터지는 엣지 케이스, '리팩터'라는 이름 아래 숨어든 스코프 확장, 그리고 아무것도 검증하지 않으면서 통과된 테스트.
15분 체크패스가 잡아내는 것들
병합 전 15분 리뷰 루틴을 구조화하면 이 세 가지 패턴 대부분을 사전에 차단할 수 있다. 핵심은 diff를 '읽는' 게 아니라 '질문하는' 것이다. 에이전트가 생성한 코드는 표면적으로 논리가 맞아 보이도록 설계되어 있다. 그래서 리뷰어가 "이게 왜 이렇게 동작하지?"라고 묻지 않으면 취약점은 그냥 통과된다.
실질적으로 확인해야 할 항목은 이렇다. 첫째, 엣지 케이스 커버리지—빈 문자열, null, 경계값에서 코드가 어떻게 반응하는가. 둘째, 스코프 경계—PR 설명에 없는 파일이 수정되었는가. 셋째, 테스트 실질성—테스트가 실제로 동작하는 코드를 검증하는가, 아니면 그냥 실행만 되는가. 이 세 질문에 답하는 데 15분이면 충분하다. 그리고 이 15분이 나중에 수십 시간의 디버깅을 막는다.
MCP 생태계에서 드러난 보안의 민낯
에이전트 코드 리뷰의 중요성이 코드베이스 내부 문제라면, MCP 서버 생태계의 보안 상황은 그 외부 버전이다. 60일 만에 MCP 서버 대상 CVE 30건이 접수됐다는 최근 보고는 숫자보다 그 구조적 원인이 더 심각하다. 누구나 GitHub, npm, Smithery에 MCP 서버를 올릴 수 있고, 보안 감사도 없고, 샌드박싱도 없다. MCP 서버를 설치하는 순간, 팀은 그 저자에게 파일시스템, 네트워크, 환경변수 접근권을 통째로 위임하는 셈이다.
MarketNow의 Sentinel 파이프라인이 8,764개 서버를 감사한 결과는 이 구조적 문제를 숫자로 증명한다. 3개 서버는 환경변수를 그대로 노출했고(eval()에 인자를 그대로 넘기는 방식), 12개에는 API 키가 소스코드에 하드코딩되어 있었다. 전체의 47%가 네트워크 호출을 포함한다. 그 중 1개는 ptrace() 시도, 1개는 bpf() 시도가 gVisor 샌드박스에서 차단됐다.
OWASP MCP Top 10이 정의하는 전선
OWASP가 2026년을 겨냥해 발표한 MCP Top 10은 이 위협을 체계화한다. Tool Poisoning(MCP01)은 도구 설명에 악의적 지시를 심어 LLM을 조작하는 방식이고, Rug Pull(MCP02)은 초기 리뷰를 통과한 뒤 서버 동작을 바꾸는 방식이다. SSRF(MCP08), 데이터 유출(MCP05), 공급망 리스크(MCP09)까지 포함하면, MCP 서버를 팀 워크플로우에 붙이는 행위 자체가 새로운 공격 표면을 여는 것이다.
Sentinel의 6레이어 감사 파이프라인은 이 중 10개 중 7개를 현재 커버한다. 정적 분석, 패턴 기반 행동 분석, 실제 MCP 프로토콜 메시지를 이용한 60개 이상의 적대적 입력 테스트, gVisor 샌드박스 실행이 그 핵심이다. 인증(MCP07)과 세션 관리(MCP10)는 2027년으로 로드맵이 잡혀 있다. 솔직하게 갭을 공개하는 태도는 신뢰할 만하다.
팀 리드가 지금 당장 설계해야 할 것
두 흐름을 하나의 실무 원칙으로 묶으면 이렇다. AI가 생성한 코드와 외부 AI 도구(MCP 서버)는 모두 '신뢰하되 검증하라'는 원칙이 아니라 '검증한 뒤에 신뢰하라'는 원칙으로 다뤄야 한다.
내부 코드베이스에서는 병합 전 15분 체크리스트를 팀 표준으로 만들어야 한다. 에이전트 PR 전용 리뷰 체크리스트를 CI 파이프라인에 붙이고, 빈 입력/스코프 경계/테스트 실질성을 자동으로 플래그하는 룰을 추가하라. 외부 도구 사용에서는 MCP 서버의 출처와 감사 이력을 확인하는 절차를 온보딩 문서에 명시하고, 팀 내에서 허용된 MCP 서버 목록을 관리하는 것이 현실적인 첫 걸음이다.
전망: 보안은 속도의 적이 아니다
AI 에이전트가 코드를 짜는 속도는 계속 빨라진다. 하지만 보안 검증의 책임이 줄어드는 건 아니다. 오히려 반대다. 생성 속도가 빠를수록, 검증 루프를 자동화하고 구조화하지 않으면 취약점의 유입 속도도 함께 빨라진다.
15분짜리 병합 전 체크패스와 MCP 서버 감사 파이프라인이 공통으로 가리키는 방향은 하나다. AI-First 워크플로우에서 보안은 별도의 단계가 아니라 생성-검증-병합 루프 안에 처음부터 설계되어야 한다. 병합 버튼 앞에서의 15분은 팀이 AI를 동료로 쓸 수 있는지를 판가름하는 가장 현실적인 테스트다.