가드폴, 오픈소스 코딩 에이전트 11개 중 10개가 뚫렸다

코딩 에이전트한테 "알아서 명령어까지 실행해줘"라고 맡겨두면 참 편합니다. 파일을 고치고 설치하고 실행하는 일을 대신 해주니까요. 그런데 그 편리함에 오래된 구멍이 있다면 어떨까요. 보안 업체 애드버사가 인기 오픈소스 코딩 에이전트 대부분에서 수십 년 전부터 알려진 방식으로 안전장치를 뚫을 수 있다는 사실을 공개했습니다. 이름은 가드폴(GuardFall)입니다. 무슨 문제인지, 그리고 코딩 에이전트를 쓰는 사람이 뭘 조심해야 하는지 정리했습니다.

무슨 일이 밝혀졌나요

2026년 6월 30일 애드버사 AI의 연구자가 공개한 내용에 따르면, 가장 많이 쓰이는 오픈소스 코딩 에이전트 11개 중 10개가 셸 명령 눈속임에 뚫렸습니다. 이 11개를 합치면 깃허브 별이 약 54만 8천 개에 달할 만큼 널리 쓰이는 도구들입니다. 에이더, 클라인, 구스, 오픈핸즈, 플랜덱스 같은 이름이 포함됐고, 컨티뉴 하나만 구조적으로 상당 부분을 막고 있었습니다.

어떤 원리로 뚫리나요

문제의 뿌리는 안전장치가 명령을 검사하는 방식에 있습니다. 많은 에이전트가 실행 전 명령어를 글자 그대로 훑어보며 위험한지 판단하는데, 정작 그 명령을 실제로 처리하는 셸(bash)은 글자를 다시 해석하고 조합해 실행합니다. 이 틈을 노려 명령을 살짝 비틀면, 검사에는 안전해 보이지만 실행 단계에서는 위험한 명령으로 되살아납니다. 특수문자로 명령을 쪼개거나 인코딩해 숨기는 식인데, 사실 보안 분야에서 수십 년간 알려져 온 낡은 수법입니다.

왜 '패치' 한 번으로 못 막나요

가드폴에는 하나의 취약점 번호(CVE)가 붙지 않았습니다. 그게 오히려 핵심이에요. 특정 프로그램의 버그가 아니라 "에이전트가 셸에 명령을 넘기되 문자열 검사로만 거른다"는 설계 관행 자체가 구조적으로 뚫리기 때문입니다. 부품 하나를 고쳐서 끝낼 문제가 아니라 안전장치를 설계하는 방식 자체를 바꿔야 합니다. 앞서 저장소 하나로 개발자 PC까지 뚫렸던 클로드 코드 보안 취약점 사례처럼, 코딩 에이전트의 편리함 뒤에는 이런 위험이 함께 붙어 있습니다.

그럼 나는 어떻게 해야 하나요

당장 실천할 수 있는 방어가 있습니다. 우선 에이전트가 명령을 스스로 실행하기 전에 사람이 승인하도록 설정하는 게 기본입니다. 자동 실행을 무조건 켜두지 마세요. 가급적 격리된 환경(별도 컨테이너나 가상 환경)에서 돌리면 문제가 생겨도 실제 시스템까지 번지지 않습니다. 출처가 불분명한 저장소나 코드를 에이전트에게 통째로 맡기는 것도 피하는 게 좋습니다. 실제로 AI가 사람 없이 해킹부터 협박까지 수행한 랜섬웨어 사례까지 나온 만큼, 편리함과 통제 사이의 균형을 잡는 습관이 중요합니다.

유료 상용 도구는 안전한가요

이번 조사는 오픈소스 에이전트만 살펴본 것이라 상용 도구가 같은 문제에서 완전히 자유롭다고 단정하기는 어렵습니다. 다만 상용 제품은 별도의 안전장치와 격리 구조를 갖춘 경우가 많습니다. 어느 도구를 쓰든 "자동 실행 권한을 얼마나 넓게 열어뒀는가"를 스스로 점검하는 게 핵심입니다. 개인적으로는 이번 일이 코딩 에이전트를 안 쓸 이유라기보다, 권한 설정을 한 번 더 돌아볼 계기라고 봅니다.

자주 묻는 질문

제가 쓰는 도구가 목록에 있으면 지금 위험한가요? 자동 실행 권한을 넓게 열어두고 출처가 불분명한 코드를 다루는 상황이라면 위험이 커집니다. 승인 절차를 켜고 격리 환경에서 쓰면 위험을 크게 줄일 수 있습니다.

컨티뉴만 안전하다는 뜻인가요? 컨티뉴가 구조적으로 상당 부분을 막고 있었다는 것이지, 다른 도구가 무조건 위험하다는 뜻은 아닙니다. 설정과 사용 방식에 따라 위험 수준이 달라집니다.

초보자는 코딩 에이전트를 쓰면 안 되나요? 그렇지 않습니다. 기본 안전 설정(사람 승인, 격리 환경, 신뢰할 수 있는 코드만)만 지키면 충분히 안전하게 쓸 수 있습니다. 편리함을 포기하기보다 안전 습관을 함께 들이는 쪽이 맞습니다.