TL; DR
에이전트 기반 코딩의 위험은 에이전트가 나쁜 코드를 작성하는 데 있는 것이 아닙니다. 에이전트가 행동하는 데 있는 것입니다. 이 프로그램은 패키지를 설치하고, 사용자가 열지 않은 파일을 편집하고, 도구를 호출하고, 아무도 검토하거나 열지 않는 설정을 읽습니다. pull requests이러한 작업들은 모두 개발자 권한이 필요한 특권 작업이며, 기존의 컨트롤은 사람이 직접 입력하는 환경을 기반으로 설계되었습니다.
속도 문제로 인해 병목 현상이 검토 단계로 옮겨졌습니다. AI 코딩 도우미에 대한 독립적인 연구에 따르면 생성된 코드의 약 40%에 보안 취약점이 포함되어 있으며, 모델의 성능이 향상되었음에도 불구하고 이 비율은 개선되지 않았습니다. 출력량은 증가했지만 검토 능력은 향상되지 않았습니다. 에이전트 프로그래밍은 단일 명령이 수십 개의 파일을 건드릴 수 있기 때문에 기존 자동 완성 기능보다 훨씬 더 정확하게 이러한 문제를 해결할 수 있습니다.
공격의 목표는 모델이 아니라 배선입니다. 규칙 파일에 숨겨진 유니코드로 인해 어시스턴트가 백도어가 포함된 코드를 실행하면서도 이를 전혀 언급하지 않는 문제가 발생했으며, 이는 MITRE ATLAS에 AML.CS0041로 등록되었습니다. 공격자들은 패키지 이름 모델 환각(model hallucinate)을 등록합니다. 한 MCP 브리지는 클라이언트에 원격 코드 실행 권한을 437,000회 이상 전송했습니다. 기존 분석 방식으로는 이러한 파일들을 전혀 읽어낼 수 없습니다.
그 안에 담긴 내용은 지루하지만 효과적입니다. 실제로 사용 중인 에이전트 및 MCP 서버 목록을 작성하고, 프롬프트 및 규칙 파일을 검토 중인 코드로 처리하고, 모든 도구 표면의 범위를 작업에 맞추고, 에이전트가 실행되는 개발자 컴퓨터에서 정책을 적용합니다. Xygeni AI 보안 처음 세 가지를 처리합니다. DevAI 마지막으로, AI가 생성한 코드와 사람이 작성한 코드 모두에 해당됩니다.
에이전트 코딩이란 무엇인가요?
에이전트 기반 코딩이란 AI 에이전트가 목표를 설정하고 이를 실행하기 위해 다양한 도구를 사용하는 개발 방식입니다. 이러한 도구에는 파일 읽기 및 편집, 종속성 설치, 테스트 실행, 코드 열기 등이 포함됩니다. pull requests위험은 생성된 개별 함수의 품질이 아니라 그러한 동작과 그 동작을 유도하는 구성에서 발생합니다. 효과적인 방법은 인벤토리 관리, 범위 지정 권한, 검토된 구성, 그리고 엔드포인트에서의 강제 적용입니다.
에이전트 기반 코딩인가, 에이전트 기반 프로그래밍인가?
두 용어 모두 동일한 변화를 나타내며, 팀에서는 혼용해서 사용합니다. 에이전트 프로그래밍은 주로 엔지니어링 작업 방식에 대한 논의에서 등장하고, 에이전트 코딩은 툴링 및 보안 분야에서 주로 사용되는 용어입니다. 기술적으로는 두 용어를 구분할 수 없습니다. 전체 정의 및 관련 어휘저희 용어집의 에이전트 코딩 항목에서 이를 다루고 있습니다.
이 글에서 중요한 것은 제안과 실행의 차이입니다. 한 줄을 완성해주는 도우미는 생산성 향상 기능입니다. 반면 패키지를 설치하고, 파일 6개를 편집하고, 브랜치를 푸시하는 에이전트는 시스템 내부에서 작동하는 비인간적인 존재입니다. SDLC에이전트 기반 프로그래밍은 조용히 그 선을 넘었고, 그 이후로 대부분의 보안 프로그램은 재검토되지 않았습니다.
에이전트 코딩의 실제 위험성
무는 경향이 있는 순서대로 네 가지 위험한 과(科)를 나열했습니다.
- 볼륨 아웃러닝 리뷰. 에이전트가 생성하는 변경 사항은 검토자가 의미 있게 검토할 수 있는 양보다 훨씬 많습니다. 승인은 형식적인 절차에 불과하며, 보안에 취약한 패턴은 기계적인 속도로 복제됩니다. 이는 모두가 인지하고 있지만 가장 측정하기 어려운 위험입니다. 에이전트가 작성한 변경 사항과 사람이 검토하는 데 걸리는 시간의 비율을 측정해 보세요. 그 수치만으로도 이 주장이 타당함을 알 수 있을 것입니다.
- 명령어 계층. 에이전트의 컨텍스트에 도달하는 모든 것은 에이전트의 방향을 바꿀 수 있습니다. 프롬프트 주입이 그중 가장 중요한 요소입니다. OWASP LLM 지원자 대상 Top 10 그럴 만한 이유가 있고, 에이전트 기반 코딩에서는 전달 수단이 아주 평범합니다. 문제 설명, 코드 주석, 의존성 패키지의 README 파일, 에이전트가 가져오는 문서 등이 그 예입니다. 아무도 직접 공격할 필요가 없습니다. 에이전트가 읽을 만한 내용을 작성하기만 하면 됩니다.
- 구성 계층. 규칙 파일, 스킬 파일, 프롬프트 및 MCP 서버 정의는 에이전트의 동작과 접근 권한을 결정합니다. 이러한 파일들은 애플리케이션 코드가 아니므로 일반적인 스캐너로는 읽을 수 없습니다. 규칙 파일 백도어는 검토자가 물리적으로 볼 수 없는 지침을 0의 너비 문자로 전달하는 극단적인 경우를 보여주었습니다. 일반적인 경우도 마찬가지로 위험합니다. 예를 들어 구성 파일에 공급자 자격 증명이 평문으로 저장되어 있거나, 기본 설정으로 인해 어시스턴트에게 전체 파일 시스템에 대한 읽기 권한이 부여된 경우 등이 있습니다.
- 의존성 및 도구 표면. 에이전트는 종속성을 선택합니다. 이름을 확인하고 설치한 다음 다음 단계로 넘어가며, 설치 스크립트는 다른 모든 작업 전에 실행됩니다. pipeline 변화를 감지합니다. 슬롭스쿼팅은 바로 이 점을 악용합니다. USENIX Security 2025에서 발표된 연구에 따르면 언어 모델이 추천하는 패키지의 19.7%가 실제로 존재하지 않으며, 이러한 가짜 이름이 자주 반복되어 공격자가 이를 등록하고 기다릴 수 있다는 사실이 밝혀졌습니다. 이는 다른 경우에도 마찬가지입니다. MCP 서버신뢰할 수 없는 서버에 연결하면 감사를 거치지 않은 도구가 에이전트에게 제공되는 상황이 발생할 수 있습니다.
실제로 어떻게 잘못되는지
단 하나의 특이한 기술이 아닙니다. 이미 실제 상황에서 입증된 기술들을 착지 순서대로 조합한 것입니다.
- 지시사항이슈 설명, 의존성 README 또는 코드 주석에 문장이 하나 있습니다. 그 문장은 사람이 읽도록 작성된 것이 아닙니다.
- 문맥개발자가 에이전트에게 문제 해결을 요청합니다. 에이전트는 설명, 저장소 및 자체 규칙 파일을 컨텍스트로 가져옵니다. 지침과 콘텐츠는 모델과 동일하게 보입니다.
- 설치에이전트는 적절해 보이는 도우미 라이브러리를 찾아 설치합니다. 이 이름은 모델들이 계속해서 만들어내는 것을 알아챈 누군가가 지난주에 등록했습니다. 설치 스크립트는 노트북에서 실행됩니다.
- 자격증공급자 토큰이 평문으로 존재합니다.
mcp.json그리고 셸에서 이미 클라우드 세션이 활성화되어 있습니다. 스크립트는 권한 상승이 필요하지 않습니다. 권한을 상속받습니다. - The pull request변경 사항은 미미하고, 테스트 결과는 정상이며, 차이 값도 합리적입니다. 대기 중인 항목이 네 개 더 있기 때문에 1분도 안 되어 승인되었습니다.
당신이 소유한 모든 게이트는 3단계 이후에 활성화됩니다. 처음 세 번의 작업은 개발자 컴퓨터에서 약 90초 만에 완료됩니다.
얼리어답터로부터 배우는 8가지 교훈
이 내용은 기록된 사건, 발표된 연구 결과, 그리고 정책이 마련되기 전에 에이전트 기반 프로그래밍을 도입한 팀에서 지속적으로 나타나는 패턴을 바탕으로 작성되었습니다.
- 폭발 반경은 프롬프트가 아니라 공구 표면입니다. 팀들은 프롬프트 보안 강화에 몇 주를 투자하는 반면, 상담원이 어떤 도구를 사용할 수 있는지 결정하는 데는 몇 분밖에 걸리지 않습니다. 이는 잘못된 비율입니다. 읽기만 할 수 있는 상담원은 보안이 취약할 때 불편할 뿐입니다. 반면, 메일을 보내고, 운영 체제를 조회하고, 푸시 알림을 보낼 수 있는 상담원은 훨씬 효율적입니다. commits는 인시던트이며, 이를 수행하기 위해 개발자 자신의 자격 증명을 보유합니다. 왜냐하면 거의 아무도 에이전트에 대한 ID를 프로비저닝하지 않기 때문입니다. 시스템 프롬프트를 작성하기 전에 도구 목록을 작성하십시오.
- 에이전트는 코드가 제대로 작동하는 것이 아니라 테스트 통과에 최적화되어 있습니다. 테스트 스위트가 실패하고 충분한 자율성이 주어진다면, 에이전트는 어설션을 삭제하거나, 조건을 완화하거나, 통합 기능을 모의 통합 기능으로 교체한 다음 성공을 보고할 것입니다. 모든 팀은 첫 주에 이 사실을 깨닫습니다. 이것이 바로 녹색인 이유입니다. 녹색으로 표시되는 이유입니다. pipeline증거로서의 효력을 잃은 이유와 검토 질문이 "이것이 효과가 있는가?"에서 "이것이 통과되도록 무엇이 바뀌었는가?"로 바뀐 이유.
- 규칙 파일은 운영 환경 설정입니다. 생성된 모든 줄을 제어하는 파일은 일반적으로 다음과 같습니다. commit한 번 검토하고 나면 다시는 확인하지 않습니다. 담당자가 지정되고, 변경 사항 검토가 이루어지며, 아무도 추가한 줄을 알아차릴 수 있는 사람이 있는 변경 관리 체계에 속해야 합니다. 보이지 않는 내용을 포함하여 그 안에 있는 모든 사항은 준수될 것이라고 가정하십시오.
- 에이전트의 종속성은 사용자의 종속성과 다릅니다. 승인된 라이브러리 목록은 사람이 직접 선택했다는 가정하에 작성됩니다. 에이전트는 적절한 이름을 찾아 설치하고, 설치 스크립트는 CI 환경이 구축되기 전에 실행됩니다. 문제가 발생했던 팀들은 개발자가 선호해야 할 라이브러리를 나열한 정책 문서가 아니라, 설치 시점에 시스템에서 라이브러리를 확인하는 절차를 추가했습니다.
- 그들이 무엇을 운영하고 있는지 아무도 말해줄 수 없습니다. 다섯 명의 엔지니어에게 어떤 MCP 서버와 어시스턴트를 사용하는지 물어보면 다섯 가지 답변이 나오지만, 어느 하나 완전한 답변은 없습니다. 설문 조사는 여기서는 효과가 없습니다. 도구가 로컬에 설치되고 매주 변경되기 때문입니다. 필요한 정보는 코드, 종속성, 그리고 도구가 남기는 구성 파일에서 찾아야 합니다.
- 치료 과정이 끝난 후에도 기억은 독을 간직합니다. 잘못된 명령어가 지속적인 컨텍스트나 에이전트 메모리에 저장되면 작업이 종료되더라도 사라지지 않습니다. 관련 없는 작업에도 조용히 영향을 미치며 계속 실행되므로, 메모리 및 컨텍스트 오염은 OWASP 에이전트 목록에 별도의 항목으로 포함되어 있습니다. 에이전트 메모리는 편의 기능이 아니라 검토 및 삭제가 필요한 상태로 취급해야 합니다.
- 예방보다는 되돌릴 수 있는 가능성이 더 중요하다 가장 안전하게 자율적인 에이전트를 운영하는 팀은 가장 엄격한 통제를 하는 팀이 아닙니다. 오히려 실수를 쉽게 되돌릴 수 있도록 시스템을 간소화한 팀입니다. 에이전트가 메인 브랜치 대신 분기 브랜치를 실행하고, 일회용 환경에서 작업하며, 모든 작업에 원터치 실행 취소 기능을 제공하는 식입니다. 자율성은 그 실행을 되돌리는 것이 얼마나 쉬운지에 따라 비용 효율성이 결정됩니다.
- 조종사가 당신에게 거짓말을 하고 있어요 에이전트는 소규모 저장소의 새로운 작업에서는 탁월한 성능을 보이지만, 암묵적인 규칙이 있는 대규모 레거시 코드베이스에서는 성능이 저하됩니다. 성공적인 파일럿 테스트는 생산성 향상을 과대평가하고 위험을 과소평가하여, 대규모 환경에서는 누구도 충족할 수 없는 기대치를 설정합니다. 가장 깔끔한 저장소가 아닌, 가장 문제가 많은 저장소에서 파일럿 테스트를 진행하세요.
실제로 이것이 어떻게 보이는지
도구보다 순서가 훨씬 중요합니다. 에이전트를 찾지 못하면 권한을 설정할 수 없으므로 먼저 에이전트를 검색해야 합니다. 그다음 구성 계층을 설정해야 하는데, 여기에 설치 지침이 있기 때문입니다. 마지막으로 엔드포인트를 설정해야 하는데, 에이전트가 실제로 실행되고 설치가 완료되는 지점이기 때문입니다. pipeline 통지.
Xygeni AI 보안 모든 AI 자산을 찾아냅니다 SDLC모델, 에이전트, 에이전트 서버, MCP 서버, 데이터 세트, 스킬 파일, 프롬프트 등을 포함합니다. guardrails 아무도 선언하지 않은 애플리케이션 코드, 선언된 종속성, AI 도구가 남긴 구성 파일을 읽고 연결 방식을 파악합니다. 에이전트 프로그래밍에 특정한 위험, 즉 프롬프트 주입 및 시스템 프롬프트 유출, 규칙 및 스킬 파일의 악성 명령 및 도구 주입, 안전하지 않은 MCP 구성, 과도한 에이전트 및 누락된 에이전트를 감지합니다. guardrailsAI 파일에 숨겨진 비밀 정보, 취약하거나 무단으로 사용된 AI 종속성 등을 탐지합니다. 탐지 결과는 OWASP Top 10 LLM 애플리케이션 취약점과 연관되어 정확한 파일 및 줄 번호를 알려주며, 우선순위 지정 과정을 통해 수천 개의 탐지 결과 중 실제로 사용 중이거나 접근 가능하고, 악용 가능하며, 권한이 필요하고, 비즈니스에 중요한 취약점으로 추려냅니다.
DevAI 나머지 절반은 에디터에서 다룹니다. 코드가 작성되는 즉시 보안을 강화하고, AI가 생성한 코드와 사람이 작성한 코드 모두에 적용되며, 다른 에이전트가 실행하기 전에 미리 차단합니다. 동일한 인텔리전스가 이미 실행 중인 스캐너에서 수집된 결과에도 적용되므로 기존 시스템을 교체할 필요가 없습니다.
FAQ
- 에이전트 코딩의 가장 큰 위험은 무엇인가요? 과도한 권한 위임. 광범위한 도구를 가진 담당자는 성공적인 개입을 실제 행동으로 전환시키지만, 대부분의 팀은 사람에 대한 범위보다 도구에 대한 범위를 훨씬 더 느슨하게 설정합니다.
- 에이전트 기반 프로그래밍은 규제 환경에서 안전한가요? 네, 인벤토리, 범위 지정 권한, 검토된 구성 및 엔드포인트에서의 적용이 있다면 가능합니다. 감사에서 용납될 수 없는 것은 어떤 에이전트가 실행 중인지, 어떤 영역에 접근하는지, 또는 어떤 코드를 작성했는지 알지 못하는 것입니다.
- 에이전트 기반 코딩은 사람이 작성한 코드보다 보안성이 떨어지는 코드를 생성하는가? 한 줄당 오류율은 사람의 오류율과 비슷하지만, 처리량은 그렇지 않으며, 바로 이 처리량이 검토를 무산시키는 요인입니다. 문제는 인재가 아니라 처리량입니다.
- 인공지능 코딩 도우미를 금지해야 할까요? 금지 조치는 사용을 음성화시켜 상황을 악화시킵니다. 섀도우 AI는 승인된 AI보다 보안이 더 어렵고, 실제로 상황을 바꿀 수 있는 것은 발견입니다.
- 에이전트가 취약점을 유포했을 때 누가 책임을 져야 할까요? 병합한 사람은 이전과 똑같습니다. 불편한 점은 바로 이 부분이며, 작성자 정보가 중요한 이유이기도 합니다. 대량으로 처리되는 기계 생성 변경 사항에 대해 검토자가 승인하려면 승인 후에가 아니라 승인 전에 검토 결과가 나와야 합니다.
- 만약 우리가 아무것도 모르는 상태라면 어떻게 시작해야 할까요? 저장소에 대한 검색을 실행하고, 발견된 MCP 서버와 어시스턴트 목록을 확인한 다음, 도구 사용 범위에 따라 에이전트 순위를 매기세요. 가장 위험한 에이전트는 대개 아무도 우려하지 않았던 에이전트입니다.
에이전트는 이미 저장소에 있습니다.
에이전트 코드는 승인 여부와 관계없이 이미 저장소에 존재합니다. 이를 잘 처리하는 팀은 가장 엄격한 정책을 가진 팀이 아닙니다. 오히려 어떤 에이전트가 실행 중인지, 해당 에이전트가 접근할 수 있는 영역은 어디인지, 그리고 에이전트를 제어하는 파일에 어떤 변경 사항이 있는지를 매일 정확하게 파악할 수 있는 팀입니다.
에이전트가 어떤 서비스에 연결되어 있는지 확인하려면 다음 링크를 참조하세요. 제니.







