Claude Code, Cursor 같은 AI 코딩 에이전트를 도입한 회사라면 최근 두 달 사이 조용히 퍼진 뉴스 하나를 알아둘 필요가 있습니다. 바로 “에이전트재킹(Agentjacking)“이라 불리는 새로운 공격 기법입니다. AI 코딩 에이전트 해킹 대응이 왜 이제는 개발팀만의 문제가 아닌지, 어떤 원리로 뚫리는지, 개발자가 상주하지 않는 중소기업도 무엇을 점검해야 하는지 정리해보겠습니다.
에이전트재킹이 뭔가요, 왜 위험한가요
에이전트재킹은 피싱이나 악성코드 유포 없이, AI 코딩 에이전트가 신뢰하는 외부 도구를 통해 조작된 데이터를 흘려보내 개발자의 PC에서 공격자가 원하는 명령을 실행시키는 공격입니다. 사람을 속이는 게 아니라 에이전트를 속인다는 점이 기존 피싱·악성코드 공격과 다릅니다. 개발자는 평소처럼 오류를 고쳐달라고 요청했을 뿐인데, 그 오류 데이터 안에 숨겨진 지시문이 에이전트를 조종해 공격자의 명령을 실행시킵니다.
2026년 6월 보안 연구진이 이 공격을 처음 공개했습니다. 보안 기업 테넷시큐리티에 따르면 공격자는 웹사이트 소스코드 등에서 쉽게 노출되는 센트리 DSN(Data Source Name) 키를 확보한 뒤, 이를 이용해 센트리 인입 엔드포인트에 악성 오류 이벤트를 주입합니다. 센트리(Sentry)는 개발 현장에서 널리 쓰이는 오류 추적 도구로, 이 공격은 센트리의 이벤트 수집 방식(DSN을 아는 누구에게서든 임의의 데이터를 받아들이는 구조)과, 이 데이터를 신뢰할 수 있는 시스템 출력물처럼 AI 에이전트에 그대로 전달하는 센트리 MCP 서버의 구조적 허점의 교차점을 악용합니다.
공격 대상도 특정 도구에 국한되지 않습니다. 이 기법은 클로드 코드, 커서, OpenAI 코덱스 등 여러 AI 코딩 에이전트를 하이재킹해 개발자 PC에서 공격자가 지정한 명령을 실행시키며, 피싱이 전혀 필요하지 않습니다. 실제 테스트에서 클로드 코드, 커서, 코덱스를 포함한 AI 코딩 에이전트들이 MCP를 통해 주입된 이벤트를 그대로 가져왔고, 테넷시큐리티의 테스트 과정에서 정상적인 애플리케이션 오류와 구분하지 못한 채 개발자 본인의 시스템 권한으로 공격자가 지정한 명령을 실행했습니다.
이 사건이 보여주는 건 단순한 도구 하나의 취약점이 아닙니다. 업계 보안 전문가들은 단순한 프롬프트 인젝션에서 ‘에이전트 하이재킹’으로의 전환이 AI 위협 환경의 근본적인 변화를 의미한다고 진단합니다. AI 에이전트가 여러 외부 도구(모니터링, 이슈 트래커, 문서 저장소 등)를 MCP로 연결해 쓰는 구조 자체가, 그 도구 중 하나만 뚫려도 에이전트 전체가 오염될 수 있는 공급망 취약점을 만든다는 뜻입니다.
개발자가 없는 회사도 신경 써야 할까요
픽셀앤코드처럼 자체 개발 조직을 둔 회사는 물론이고, 외주 개발사나 유지보수 업체에 AI 코딩 에이전트 사용을 맡기는 발주처 입장에서도 이 이슈는 남의 일이 아닙니다. 공급망 공격은 계약서에 명시되지 않은 리스크로 조용히 스며들기 때문입니다. 자체 개발 인력이 없더라도 협력업체가 AI 코딩 에이전트로 우리 시스템을 유지보수하고 있다면, 그 에이전트가 어떤 외부 도구와 연결돼 있는지 물어볼 필요가 있습니다.
실무에서 바로 확인할 수 있는 항목은 다음과 같습니다.
- 사내 또는 협력업체 개발 환경에서 오류 모니터링 도구(센트리 등)의 DSN 키가 프런트엔드 코드나 공개 저장소에 노출돼 있지 않은지 확인합니다.
- AI 코딩 에이전트가 MCP로 연결된 외부 도구 목록을 파악하고, 굳이 필요하지 않은 연결은 끊습니다.
- 에이전트가 명령을 실행하기 전 사람이 확인하는 승인 단계(approval gate)를 두는지 점검합니다.
- 에이전트 실행 로그에서 MCP 도구 응답이 트리거한 명령 실행 이력을 주기적으로 감사합니다.
이런 대응 원칙은 이미 정리해둔 프롬프트 인젝션 실무 대응 글의 권한·승인 체크포인트와도 맞닿아 있습니다. 결국 핵심은 하나입니다. AI 에이전트에게 “무엇을 읽고, 무엇을 실행할 권한을 줄 것인가”를 명시적으로 설계해야 한다는 점입니다.
코드 예시로 보는 DSN 노출 점검
개발자가 없어도 IT 담당자가 간단히 돌려볼 수 있는 점검 스크립트 예시입니다. 프런트엔드 소스나 공개 저장소에 센트리 DSN이 그대로 노출돼 있는지 확인하는 용도입니다.
import re
import glob
# 소스 코드 폴더 내 파일에서 Sentry DSN 패턴 검색
dsn_pattern = re.compile(r"https://[a-f0-9]+@[a-z0-9.]+/[0-9]+")
target_files = glob.glob("./src/**/*.js", recursive=True)
found = []
for file_path in target_files:
with open(file_path, "r", encoding="utf-8", errors="ignore") as f:
content = f.read()
matches = dsn_pattern.findall(content)
if matches:
found.append((file_path, matches))
if found:
print("DSN이 노출된 파일 목록:")
for path, matches in found:
print(f"- {path}: {matches}")
else:
print("노출된 DSN이 발견되지 않았습니다.")DSN이 노출된 것을 발견했다면 즉시 재발급(rotate)하고, 가능하면 클라이언트가 아닌 서버 측에서 오류 데이터를 중계하는 프록시 구조로 바꾸는 것이 권장됩니다. 이런 구조 변경은 AI가 짠 코드 검수 방법에서 다룬 실행 전 확인 절차와 함께 적용하면 더 효과적입니다.
이 사건이 주는 실무 시사점
에이전트재킹은 특정 도구 하나의 버그가 아니라 하나의 공격 유형(class)입니다. 즉 센트리 문제가 해결되더라도 비슷한 구조를 가진 다른 모니터링·이슈 트래커·문서 도구에서 같은 방식의 공격이 반복될 수 있다는 뜻입니다. 그래서 지금 당장 센트리를 쓰지 않는 회사라도, “AI 에이전트가 외부 도구의 응답을 무조건 신뢰하고 실행까지 자동으로 넘어가는 구조”인지 여부는 반드시 점검해볼 만합니다.
바이브 코딩으로 사내 자동화 도구를 빠르게 만들어 쓰는 회사라면 이런 공급망 리스크가 더 크게 다가올 수 있습니다. 이미 바이브코딩 보안 취약점에서 다룬 배포 전 점검 체크리스트에, 이번 기회에 “이 자동화가 어떤 외부 서비스와 MCP로 연결돼 있는가”라는 항목을 추가해두는 것이 좋습니다. AI 코딩 에이전트의 생산성은 분명 매력적이지만, 그 생산성을 지탱하는 연결 구조 하나하나가 잠재적 진입점이 될 수 있다는 점은 계속 염두에 둬야 합니다.
픽셀앤코드는 맞춤형 소프트웨어 개발과 하드웨어 유지보수를 함께 다루는 회사로서, 고객사의 개발 환경에 AI 코딩 에이전트를 도입할 때도 이런 공급망 연결 지점을 함께 점검하는 절차를 두고 있습니다. AI 도구 도입 자체를 막기보다, 어떤 도구가 무엇에 접근할 수 있는지 파악하고 관리하는 것이 실무적으로 더 현실적인 접근이라고 보기 때문입니다.