1-열풍의 물결

> 모두가 "AI를 하고 있지만", 아무도 그 이유를 묻지 않는다

오늘날 어떤 기술 조직에 들어가더라도 리더십으로부터 동일한 문구를 듣게 될 것입니다: "우리는 AI를 사용해야 합니다." "AI로 X를 해결해야 합니다"가 아니라, 그저 체크박스를 채우기 위한 "AI"일 뿐입니다.

Transformer 모델이 어떻게 작동하는지 설명하지 못하는 매니저들이 트렌드이고, 경쟁사들이 하고 있으며, 분기별 검토에서 "생산성 (Productivity)"라는 단어가 듣기 좋다는 이유로 팀 전체에 AI 도입을 명령하고 있습니다.
그 결과: AI의 도움을 받는 개발자들은 동료들보다 3~4배 빠른 속도로 커밋 (Commit)을 생성하며, 리더십은 이 속도 수치를 축하합니다.
하지만 속도가 전부가 아닙니다.

문제는 AI 도입이 아닙니다. 문제는 아무도 측정하지 않고 있는 것입니다.

2-사각지대: 안전 없는 속도_

처리량 (Throughput) 지표는 환상적으로 보이지만, 그 처리량에 따르는 보안 비용을 추적하는 사람은 거의 없습니다. 동일한 AI 보조 개발자들이 동료들보다 10배 빠른 속도로 보안 취약점 (Security findings)을 유발하며, 조직이 해결할 수 있는 속도보다 더 빠르게 쌓이는 보안 부채 (Security debt)를 생성하고 있습니다.

The Blind Spot

그리고 이는 더 새로운 모델이 나온다고 해서 개선되지 않고 있습니다. Veracode의 2026년 봄 연구에서 테스트된 모든 모델과 모든 작업에 걸쳐, 코드 생성 (Code generation) 작업 중 단 55%만이 보안이 확보된 코드를 생성했습니다. 즉, 45%의 경우 모델이 알려진 보안 결함을 도입했다는 의미입니다. AI 코딩 어시스턴트가 이제 95%를 초과하는 구문 정확도 (Syntax correctness)를 달성하고 있음에도 불구하고, 보안 통과율 (Security pass rates)은 약 55%에 머물러 있으며, 이는 2년 전과 비교해 거의 변하지 않은 수치입니다.

코드는 깨끗해 보이고, 컴파일되며, 테스트를 통과하지만, 수많은 취약점과 함께 배포됩니다.

3-언어별 취약점 데이터

The Vulnerability Data, Language by Language

CodeRabbit의 분석에 따르면, AI가 생성한 코드는 사람이 작성한 코드보다 취약점 발생률이 2.74배 더 높았습니다. 주요 언어 중 예외는 없었으나, 특히 Java에서 그 격차가 두드러졌습니다. Java 기반 시스템에 크게 의존하는 기업들에게 치명적인 노출인 SQL 인젝션 (SQL injection)과 같이 일반적으로 피하기 쉬운 취약점에 대해서도 모델의 성능이 현저히 떨어졌습니다.

모든 언어에 걸쳐 가장 흔하게 나타나는 결함 카테고리는 SQL 인젝션 (SQL injection), 교차 사이트 스크립팅 (Cross-site scripting), 로그 인젝션 (Log injection), 그리고 안전하지 않은 암호화 알고리즘 (Insecure cryptographic algorithms)입니다. 이는 생소한 예외 사례가 아니라 OWASP Top 10에 해당하는 항목들이며, AI는 이를 대규모로 생성해내고 있습니다.

4-슬롭스쿼팅 (Slopsquatting) 문제 (Node.js 및 그 이상)

이 지점은 특히 JavaScript 생태계에서 매우 위험해집니다. AI 모델은 단순히 보안에 취약한 코드를 작성하는 데 그치지 않고, 때때로 존재하지 않는 패키지를 추천하기도 합니다. 공격자들은 이러한 이름을 먼저 등록해 버립니다. 이를 슬롭스쿼팅 (Slopsquatting)이라고 부릅니다.

The Slopsquatting Problem (Node.js & Beyond)

이 공격의 수치는 놀라울 정도입니다. 576,000개의 샘플을 대상으로 16개의 대규모 언어 모델 (LLM)을 테스트한 USENIX Security 2025 연구에 따르면, AI가 생성한 패키지 추천의 약 19.7%가 레지스트리에 존재하지 않는 패키지를 참조하는 것으로 나타났습니다. 더 심각한 점은, 연구진이 동일한 프롬프트를 각각 10번씩 다시 실행했을 때, 환각 (Hallucination) 현상으로 나타난 패키지 이름의 43%가 매 실행마다 다시 나타났다는 것입니다. 이는 환각이 예측 가능하고 반복 가능하다는 것을 의미하며, 바로 이 점이 공격에 악용될 수 있는 핵심 요소입니다.

실제 사례들이 이미 기록되어 있습니다. 합법적인 eslint-plugin-unused-imports를 모방하여 환각(hallucination)을 일으킨 npm 패키지는 npm에 의해 보안 조치(security-held)가 취해졌음에도 불구하고, 2026년 초 기준으로 여전히 활성화되어 매주 약 233회의 다운로드를 기록하고 있었습니다. 별도의 연구자가 huggingface-cli라는 이름을 무해한 테스트용으로 등록했는데, 불과 3개월 만에 이 이름이 한 주요 기술 기업의 공개 저장소(public repository) README에 등장하며 30,000회 이상의 다운로드를 기록했습니다. 그것은 테스트였습니다. 실제 페이로드(payload)를 실은 동일한 수법은 이제 반복 가능한 공격 모델이 되었습니다.

5-공격자의 도구로서의 AI

여러분의 팀이 코드를 더 빠르게 작성하기 위해 AI를 사용하는 동안, 공격자들은 코드를 더 빠르게 파괴하기 위해 AI를 사용하고 있습니다. 이것은 "AI 생산성"에 관한 대화에서 누구도 다루고 싶어 하지 않는 이야기의 이면입니다.

AI as the Attacker's Tool

IBM X-Force의 연구에 따르면, 공격자들은 이제 단 5개의 프롬프트(prompt)를 사용하여 단 5분 만에 효과적인 피싱(phishing) 캠페인을 생성할 수 있으며, 이는 이전에는 16시간의 인적 노력이 필요했던 과정입니다. AI가 생성한 피싱 캠페인은 2025년 12월에 14배 급증하여 보고된 모든 공격의 56%를 차지했으며, 해커의 82%가 현재 워크플로(workflow)에 AI를 사용하고 있습니다(2023년 64%에서 증가).

6-새로운 공격 표면: 프롬프트 인젝션 (Prompt Injection)

전통적인 취약점을 넘어, AI는 대부분의 보안 아키텍처(security architecture)가 모델링해 본 적 없는 완전히 새로운 공격 카테고리를 도입합니다.

New Attack Surface: Prompt Injection

2026년 보안 감사에서 평가된 AI 시스템의 73%가 프롬프트 인젝션 (Prompt Injection)에 노출된 것으로 나타났으며, 신뢰할 수 있는 소스에 악성 명령을 숨기는 간접 공격 (Indirect Attacks)이 전체 사고의 55% 이상을 차지하며 20~30% 더 높은 성공률을 기록했습니다. 만약 여러분이 코드베이스, 리포지토리 (Repos), 또는 CI 파이프라인 (CI Pipeline)에 접근 권한이 있는 AI 에이전트 (AI Agents)를 사용하고 있다면, 이제 풀 리퀘스트 (Pull Request) 설명, 이슈 (Issue) 댓글, 그리고 README 파일은 모두 공격 표면 (Attack Surfaces)이 됩니다. 실제 사례는 다음과 같습니다:

CVE-2025-53773
풀 리퀘스트 설명에 임베디드된 숨겨진 프롬프트 인젝션이 GitHub Copilot을 통해 원격 코드 실행 (Remote Code Execution)을 가능하게 할 수 있음을 보여주었으며, CVSS 척도에서 9.6점을 기록했습니다.

7-아키텍처적 해답: 해결 방법은 이것입니다

이 기사의 데이터는 여러분이 AI를 멀리하게 만들려는 것이 아니라, 격차(Gaps)가 정확히 어디에 있는지 보여줌으로써 이를 메울 수 있도록 하기 위함입니다. 위에서 설명한 모든 취약점 카테고리, 모든 공격 벡터 (Attack Vector), 모든 사각지대에는 알려진 아키텍처적 대응책 (Architectural Countermeasure)이 존재합니다. 이것이 바로 해답입니다.

Secure Architecture

보안 아키텍처 (Security Architecture)는 모든 AI 지원 개발 워크플로우 (AI-assisted Development Workflow)에서 '있으면 좋은 것'이 아니라 '타협할 수 없는 관문'으로 진화해야 합니다. 실질적으로 이는 다음 일곱 가지를 의미합니다:

AI 출력을 신뢰할 수 없는 제3자 코드처럼 취급하십시오. 모든 AI 생성 함수는 출처를 알 수 없는 게시자의 종속성 (Dependency)과 동일한 정밀 조사를 거쳐야 합니다. 기능적으로 볼 때, 그것이 바로 AI 생성 코드의 본질이기 때문입니다.

SAST/DAST를 필수적인 CI/CD 관문으로 설정하십시오. 플래그십 모델조차 보안 통과율이 55% 수준에 머물러 있다는 점을 고려할 때, AI가 지원하는 모든 PR에 대한 자동 스캐닝 (Automated Scanning)은 선택적인 오버헤드가 아니라 도구 사용에 따르는 비용입니다.

설치 전 종속성 검증을 수행하십시오. 슬롭스쿼팅 (Slopsquatting) 데이터를 고려할 때, AI가 제안하는 모든 패키지 이름은 npm install 또는 pip install이 실행되기 전에 실제 레지스트리 (Registry)와 자동으로 대조 확인되어야 합니다.

작성 주체와 상관없는 위협 모델 (Threat model). 인증 흐름 (auth flow)을 사람이 작성했든 LLM이 작성했든, 위협 모델은 변하지 않습니다. 아키텍처 리뷰 (Architecture reviews) 시에는 다음과 같은 질문을 명시적으로 던져야 합니다: "만약 이것이 AI로부터 생성된 것이라면, 무엇을 틀렸을 가능성이 높은가?" 주입 (Injection) 처리, 암호화 (Crypto) 선택, 그리고 SSRF는 통계적으로 발생 가능성이 높은 원인들입니다.

프롬프트에 보안을 내재화하세요. 팀은 보안 요구 사항을 프롬프트 템플릿 (Prompt templates)과 코드 생성 스캐폴딩 (Code generation scaffolding)에 직접 포함시켜야 합니다. 모델이 요청하지 않아도 스스로 더 잘 알 것이라고 기대하지 마십시오. 데이터에 따르면 모델은 그렇지 않습니다.

위협 모델에 AI 에이전트 (AI agents)를 포함하세요. 코드베이스 (Codebase)나 리포지토리 (Repo) 접근 권한을 가진 AI 에이전트를 사용하고 있다면, 풀 리퀘스트 (Pull request) 설명, 이슈 (Issue) 댓글, 그리고 README 파일은 이제 공격 표면 (Attack surfaces)이 됩니다.

보안 부채 (Security debt)를 일급 지표 (First-class metric)로 추적하세요. 대시보드에 커밋 속도 (Commit velocity)가 있다면, AI 보조 PR (AI-assisted PR)당 취약점 밀도 (Vulnerability density)도 바로 옆에 있어야 합니다.

맺음말

요약 (Summary) :

double agent summary

결론 (Conclusion) :

AI가 우연히 소프트웨어 개발의 보안성을 낮춘 것이 아닙니다. AI는 개발 속도를 높였고, 보안은 속도가 최적화하려는 병목 지점(Bottleneck)이었던 적이 없었습니다. "모든 곳에 AI를(AI everywhere)" 도입하려는 관리자들이 도구가 강력하다는 점을 주장하는 것은 틀리지 않았습니다. 하지만 강력함이 곧 기본적으로 안전함을 의미한다고 가정하는 것은 틀렸습니다.

지난 1년 동안 조직의 81%가 최소 한 번 이상의 성공적인 사이버 공격을 경험했습니다. AI는 개발자가 코드를 더 빨리 작성하도록 도울 뿐만 아니라, 공격자가 취약점을 더 빨리 찾는 데도 도움을 줍니다.

2026년에 승리하는 팀은 AI를 가장 빠르게 도입한 팀이 아닐 것입니다. 그들은 동일한 AI를 사용하는 공격자가 먼저 찾아내기 전에, AI가 틀린 부분을 잡아낼 수 있는 보안 아키텍처 (Security architecture)를 구축한 팀이 될 것입니다.

참고 문헌 (References) :