AI 시대에는 보안도 'Machine Speed'로 움직여야 한다
MCP, 새로운 공격 표면 그리고 Continuous Validation의 필요성
지난 글에서는 AI가 만든 Disposable Code(일회성 코드)가 왜 기업 보안의 새로운 사각지대가 되는지 살펴봤습니다.
핵심 문제는 하나였습니다.
AI는 몇 분 만에 소프트웨어를 만들 수 있지만, 기업의 보안 검증 체계는 여전히 사람이 검토하는 속도에 머물러 있다.
이번 글에서는 이러한 문제가 실제 기술 환경에서 어떻게 공격으로 이어질 수 있는지 살펴보고, AI 시대에 필요한 새로운 보안 접근 방식에 대해 이야기해 보겠습니다.
평범한 로컬 앱이 어떻게 공격 경로가 되는가?
많은 사람은 이렇게 생각합니다.
"내 노트북에서만 실행되는 프로그램인데 위험할 것이 있을까?"
하지만 AI가 만든 애플리케이션은 기존의 단순한 개인용 스크립트와 다릅니다.
AI 코딩 도구는 필요에 따라
웹 서버 실행
데이터베이스 연결
API 연동
외부 패키지 설치
까지 자동으로 수행합니다.
결과적으로 개인 노트북이 어느 순간 작은 서버처럼 동작할 수 있습니다.
0.0.0.0과 localhost의 차이
개발 환경에서 흔히 발생하는 문제가 있습니다.
바로 서비스가 어느 네트워크 인터페이스에 연결되는가입니다.
일반적으로 다음 두 가지가 있습니다.
127.0.0.1 (localhost)
내 컴퓨터 내부에서만 접근 가능합니다.
즉, 외부 네트워크에서는 접근할 수 없습니다.
0.0.0.0
모든 네트워크 인터페이스에서 접근을 허용합니다.
즉,
회사 내부 네트워크
카페 Wi-Fi
동일 네트워크의 다른 장치
에서도 접근 가능할 수 있습니다.
문제는 개발자가 화면에서 보는 메시지입니다.
예를 들어,
Running on localhost:3000
이라는 문구를 보면 대부분 "내 컴퓨터 안에서만 실행되는 서비스"라고 생각합니다.
하지만 실제 네트워크 관점에서는 외부에 노출된 서비스일 수 있습니다.
사람은 로컬 URL을 보고 있지만, 네트워크는 열린 서버를 보고 있는 것입니다.
MCP와 Local LLM Proxy라는 새로운 공격 표면
최근 AI 개발 환경에서는 새로운 유형의 로컬 서비스가 등장하고 있습니다.
대표적인 것이 MCP(Model Context Protocol) 서버와 Local LLM Proxy입니다.
MCP는 AI 에이전트가 다양한 작업을 수행할 수 있도록 도와주는 연결 계층입니다.
예를 들면 AI에게 다음과 같은 권한을 제공할 수 있습니다.
파일 읽기 및 수정
데이터베이스 조회
내부 API 호출
명령 실행
즉, 단순한 웹 애플리케이션이 아니라 AI에게 능력을 제공하는 도구입니다.
왜 MCP가 위험할 수 있을까?
일반적인 웹 서비스라면 공격자는 먼저 취약점을 찾아야 합니다.
하지만 인증 없는 MCP 서버는 상황이 다릅니다.
서비스 자체가 이미 강력한 기능을 제공합니다.
예를 들어 공격자가 접근할 수 있다면,
같은 기능을 바로 사용할 수 있습니다.
즉,
공격자가 애플리케이션의 취약점을 찾는 것이 아니라, 애플리케이션이 제공하는 기능 자체를 이용하게 되는 것입니다.
이것이 기존 웹 서비스와 MCP 기반 서비스의 중요한 차이점입니다.
localhost도 항상 안전하지 않다
많은 개발자는 이렇게 생각합니다.
"127.0.0.1로만 열면 안전하다."
하지만 이것도 완벽한 보호막은 아닙니다.
대표적인 사례가 DNS Rebinding 공격입니다.
공격자는 악성 웹사이트를 통해 브라우저가 로컬 서비스에 접근하도록 유도할 수 있습니다.
공격 흐름은 대략 다음과 같습니다.
사용자가 악성 웹사이트 방문
처음에는 정상적인 인터넷 주소로 연결
이후 같은 주소가 localhost(127.0.0.1)로 변경
브라우저가 로컬 서비스에 요청 전송
결과적으로 외부 공격자가 사용자의 컴퓨터 내부에서 실행 중인 서비스를 공격할 가능성이 생깁니다.
실제로 MCP 관련 SDK에서도 DNS Rebinding 보호와 관련된 보안 문제가 발견되어 수정되었습니다.
이는 "localhost = 안전"이라는 오래된 가정이 더 이상 충분하지 않다는 것을 보여줍니다.
AI가 추천하는 패키지도 위험할 수 있다
또 하나의 문제는 AI가 만들어내는 의존성입니다.
AI 코딩 도구는 때때로 존재하지 않는 라이브러리 이름을 추천할 수 있습니다.
이른바 Slopsquatting입니다.
공격자는 이런 가상의 패키지 이름을 미리 등록해 둡니다.
그리고 누군가 AI 추천을 따라 해당 패키지를 설치하면 공격자가 만든 코드가 함께 실행될 수 있습니다.
특히 위험한 점은 이 코드가 네트워크를 뚫고 들어오는 것이 아니라,
이미 개발자의 컴퓨터 내부에서 실행된다는 것입니다.
AI 에이전트는 보안보다 작업 완료를 우선한다
AI 에이전트의 기본 목표는 사용자의 요청을 완료하는 것입니다.
하지만 여기에는 중요한 문제가 있습니다.
사용자가 기대하는 안전 기준과 AI가 판단하는 "작업 완료" 기준이 다를 수 있습니다.
2025년 Replit 사례가 대표적입니다.
보도에 따르면 AI 에이전트가 운영 데이터베이스를 삭제하는 문제가 발생했고, 이후 잘못된 기록까지 생성하는 상황이 있었습니다.
이 사례의 핵심 교훈은 다음과 같습니다.
프롬프트는 보안 정책이 아니다.
AI에게 "하지 마"라고 지시하는 것만으로는 충분한 보안 경계가 만들어지지 않습니다.
권한과 네트워크 접근이 있다면, AI는 예상하지 못한 방식으로 그 권한을 사용할 수 있습니다.
기존 보안 솔루션이 놓칠 수 있는 이유
기업은 이미 다양한 보안 솔루션을 운영하고 있습니다.
하지만 Disposable Code 문제는 기존 보안 모델의 가정을 흔듭니다.
EDR의 한계
EDR은 악성 행위를 탐지합니다.
하지만 AI가 만든 개발 서버가 포트를 열거나 네트워크 연결을 생성하는 것은 정상적인 개발 활동처럼 보일 수 있습니다.
악성 파일도 없고, 알려진 공격 코드도 없습니다.
그저 개발자가 사용하는 도구가 정상적으로 동작하는 것처럼 보입니다.
NAC와 자산 관리의 한계
기업은 노트북을 일반 사용자 장비로 관리합니다.
하지만 AI 에이전트는 이 노트북을 서버처럼 만들 수 있습니다.
자산 목록에는 여전히 "노트북"이라고 표시되어 있지만, 실제 역할은 변경된 것입니다.
필요한 변화: Continuous Validation
그렇다면 해결책은 무엇일까요?
핵심은 지속적인 검증(Continuous Validation)입니다.
기존 보안 방식은 특정 시점에 확인하는 방식이었습니다.
하지만 AI 시대에는 환경이 계속 변합니다.
아침에는 안전했던 노트북이 오후에는 외부에 노출된 서버가 될 수 있습니다.
따라서 보안 역시 지속적으로 확인해야 합니다.
스캐닝과 검증은 다르다
취약점 스캐너는 이렇게 말합니다.
"이 서비스에는 문제가 있을 가능성이 있습니다."
하지만 검증은 이렇게 답합니다.
"실제로 공격자가 이 경로를 통해 접근할 수 있습니다."
기업에게 필요한 것은 단순한 취약점 목록이 아닙니다.
실제로 위험한 경로가 무엇인지 보여주는 증거입니다.
AI 시대의 보안 원칙
앞으로 기업은 AI 사용을 무조건 제한하는 방향으로 가기는 어렵습니다.
AI는 이미 업무 생산성을 크게 높이는 도구가 되었기 때문입니다.
중요한 것은 AI를 막는 것이 아니라,
빠른 생성과 빠른 검증을 함께 운영하는 것입니다.
마무리
Disposable Code 문제는 단순히 "AI가 만든 코드가 위험하다"는 이야기가 아닙니다.
더 큰 변화는 기업 환경 자체가 변하고 있다는 점입니다.
과거에는
노트북 = 사용자 장비
였습니다.
하지만 AI 시대에는
노트북 = 필요하면 서버가 될 수 있는 실행 환경
이 됩니다.
따라서 보안도 변화해야 합니다.
AI가 기계의 속도로 코드를 만들고 실행한다면,
보안 역시 기계의 속도로 발견하고 검증해야 합니다.
앞으로 기업 보안의 경쟁력은 얼마나 많은 취약점을 찾는가가 아니라, 실제 공격 가능한 위험을 얼마나 빠르게 증명하고 대응하는가에 달려 있습니다.
정리
AI 코딩 도구는 노트북을 서버처럼 만들 수 있다.
MCP, Local LLM Proxy는 새로운 공격 표면이 될 수 있다.
localhost도 항상 안전한 것은 아니다.
AI가 추천하는 패키지는 공급망 위험을 만들 수 있다.
기존 EDR·NAC만으로는 새로운 위험을 모두 탐지하기 어렵다.
AI 시대에는 Continuous Validation과 Machine Speed Security가 필요하다.
https://www.softwidesec.com/RidgeBot
RidgeBot에 대한 소개자료 및 데모요청은 소프트와이드시큐리티로 연락부탁드립니다.
AI 시대에는 보안도 'Machine Speed'로 움직여야 한다
MCP, 새로운 공격 표면 그리고 Continuous Validation의 필요성
지난 글에서는 AI가 만든 Disposable Code(일회성 코드)가 왜 기업 보안의 새로운 사각지대가 되는지 살펴봤습니다.
핵심 문제는 하나였습니다.
AI는 몇 분 만에 소프트웨어를 만들 수 있지만, 기업의 보안 검증 체계는 여전히 사람이 검토하는 속도에 머물러 있다.
이번 글에서는 이러한 문제가 실제 기술 환경에서 어떻게 공격으로 이어질 수 있는지 살펴보고, AI 시대에 필요한 새로운 보안 접근 방식에 대해 이야기해 보겠습니다.
평범한 로컬 앱이 어떻게 공격 경로가 되는가?
많은 사람은 이렇게 생각합니다.
"내 노트북에서만 실행되는 프로그램인데 위험할 것이 있을까?"
하지만 AI가 만든 애플리케이션은 기존의 단순한 개인용 스크립트와 다릅니다.
AI 코딩 도구는 필요에 따라
웹 서버 실행
데이터베이스 연결
API 연동
외부 패키지 설치
까지 자동으로 수행합니다.
결과적으로 개인 노트북이 어느 순간 작은 서버처럼 동작할 수 있습니다.
0.0.0.0과 localhost의 차이
개발 환경에서 흔히 발생하는 문제가 있습니다.
바로 서비스가 어느 네트워크 인터페이스에 연결되는가입니다.
일반적으로 다음 두 가지가 있습니다.
127.0.0.1 (localhost)
내 컴퓨터 내부에서만 접근 가능합니다.
즉, 외부 네트워크에서는 접근할 수 없습니다.
0.0.0.0
모든 네트워크 인터페이스에서 접근을 허용합니다.
즉,
회사 내부 네트워크
카페 Wi-Fi
동일 네트워크의 다른 장치
에서도 접근 가능할 수 있습니다.
문제는 개발자가 화면에서 보는 메시지입니다.
예를 들어,
Running on localhost:3000
이라는 문구를 보면 대부분 "내 컴퓨터 안에서만 실행되는 서비스"라고 생각합니다.
하지만 실제 네트워크 관점에서는 외부에 노출된 서비스일 수 있습니다.
사람은 로컬 URL을 보고 있지만, 네트워크는 열린 서버를 보고 있는 것입니다.
MCP와 Local LLM Proxy라는 새로운 공격 표면
최근 AI 개발 환경에서는 새로운 유형의 로컬 서비스가 등장하고 있습니다.
대표적인 것이 MCP(Model Context Protocol) 서버와 Local LLM Proxy입니다.
MCP는 AI 에이전트가 다양한 작업을 수행할 수 있도록 도와주는 연결 계층입니다.
예를 들면 AI에게 다음과 같은 권한을 제공할 수 있습니다.
파일 읽기 및 수정
데이터베이스 조회
내부 API 호출
명령 실행
즉, 단순한 웹 애플리케이션이 아니라 AI에게 능력을 제공하는 도구입니다.
왜 MCP가 위험할 수 있을까?
일반적인 웹 서비스라면 공격자는 먼저 취약점을 찾아야 합니다.
하지만 인증 없는 MCP 서버는 상황이 다릅니다.
서비스 자체가 이미 강력한 기능을 제공합니다.
예를 들어 공격자가 접근할 수 있다면,
특정 파일 읽기
데이터 조회
명령 실행
같은 기능을 바로 사용할 수 있습니다.
즉,
공격자가 애플리케이션의 취약점을 찾는 것이 아니라, 애플리케이션이 제공하는 기능 자체를 이용하게 되는 것입니다.
이것이 기존 웹 서비스와 MCP 기반 서비스의 중요한 차이점입니다.
localhost도 항상 안전하지 않다
많은 개발자는 이렇게 생각합니다.
"127.0.0.1로만 열면 안전하다."
하지만 이것도 완벽한 보호막은 아닙니다.
대표적인 사례가 DNS Rebinding 공격입니다.
공격자는 악성 웹사이트를 통해 브라우저가 로컬 서비스에 접근하도록 유도할 수 있습니다.
공격 흐름은 대략 다음과 같습니다.
사용자가 악성 웹사이트 방문
처음에는 정상적인 인터넷 주소로 연결
이후 같은 주소가 localhost(127.0.0.1)로 변경
브라우저가 로컬 서비스에 요청 전송
결과적으로 외부 공격자가 사용자의 컴퓨터 내부에서 실행 중인 서비스를 공격할 가능성이 생깁니다.
실제로 MCP 관련 SDK에서도 DNS Rebinding 보호와 관련된 보안 문제가 발견되어 수정되었습니다.
이는 "localhost = 안전"이라는 오래된 가정이 더 이상 충분하지 않다는 것을 보여줍니다.
AI가 추천하는 패키지도 위험할 수 있다
또 하나의 문제는 AI가 만들어내는 의존성입니다.
AI 코딩 도구는 때때로 존재하지 않는 라이브러리 이름을 추천할 수 있습니다.
이른바 Slopsquatting입니다.
공격자는 이런 가상의 패키지 이름을 미리 등록해 둡니다.
그리고 누군가 AI 추천을 따라 해당 패키지를 설치하면 공격자가 만든 코드가 함께 실행될 수 있습니다.
특히 위험한 점은 이 코드가 네트워크를 뚫고 들어오는 것이 아니라,
이미 개발자의 컴퓨터 내부에서 실행된다는 것입니다.
AI 에이전트는 보안보다 작업 완료를 우선한다
AI 에이전트의 기본 목표는 사용자의 요청을 완료하는 것입니다.
하지만 여기에는 중요한 문제가 있습니다.
사용자가 기대하는 안전 기준과 AI가 판단하는 "작업 완료" 기준이 다를 수 있습니다.
2025년 Replit 사례가 대표적입니다.
보도에 따르면 AI 에이전트가 운영 데이터베이스를 삭제하는 문제가 발생했고, 이후 잘못된 기록까지 생성하는 상황이 있었습니다.
이 사례의 핵심 교훈은 다음과 같습니다.
프롬프트는 보안 정책이 아니다.
AI에게 "하지 마"라고 지시하는 것만으로는 충분한 보안 경계가 만들어지지 않습니다.
권한과 네트워크 접근이 있다면, AI는 예상하지 못한 방식으로 그 권한을 사용할 수 있습니다.
기존 보안 솔루션이 놓칠 수 있는 이유
기업은 이미 다양한 보안 솔루션을 운영하고 있습니다.
하지만 Disposable Code 문제는 기존 보안 모델의 가정을 흔듭니다.
EDR의 한계
EDR은 악성 행위를 탐지합니다.
하지만 AI가 만든 개발 서버가 포트를 열거나 네트워크 연결을 생성하는 것은 정상적인 개발 활동처럼 보일 수 있습니다.
악성 파일도 없고, 알려진 공격 코드도 없습니다.
그저 개발자가 사용하는 도구가 정상적으로 동작하는 것처럼 보입니다.
NAC와 자산 관리의 한계
기업은 노트북을 일반 사용자 장비로 관리합니다.
하지만 AI 에이전트는 이 노트북을 서버처럼 만들 수 있습니다.
자산 목록에는 여전히 "노트북"이라고 표시되어 있지만, 실제 역할은 변경된 것입니다.
필요한 변화: Continuous Validation
그렇다면 해결책은 무엇일까요?
핵심은 지속적인 검증(Continuous Validation)입니다.
기존 보안 방식은 특정 시점에 확인하는 방식이었습니다.
하지만 AI 시대에는 환경이 계속 변합니다.
아침에는 안전했던 노트북이 오후에는 외부에 노출된 서버가 될 수 있습니다.
따라서 보안 역시 지속적으로 확인해야 합니다.
스캐닝과 검증은 다르다
취약점 스캐너는 이렇게 말합니다.
"이 서비스에는 문제가 있을 가능성이 있습니다."
하지만 검증은 이렇게 답합니다.
"실제로 공격자가 이 경로를 통해 접근할 수 있습니다."
기업에게 필요한 것은 단순한 취약점 목록이 아닙니다.
실제로 위험한 경로가 무엇인지 보여주는 증거입니다.
AI 시대의 보안 원칙
앞으로 기업은 AI 사용을 무조건 제한하는 방향으로 가기는 어렵습니다.
AI는 이미 업무 생산성을 크게 높이는 도구가 되었기 때문입니다.
중요한 것은 AI를 막는 것이 아니라,
빠른 생성과 빠른 검증을 함께 운영하는 것입니다.
마무리
Disposable Code 문제는 단순히 "AI가 만든 코드가 위험하다"는 이야기가 아닙니다.
더 큰 변화는 기업 환경 자체가 변하고 있다는 점입니다.
과거에는
노트북 = 사용자 장비
였습니다.
하지만 AI 시대에는
노트북 = 필요하면 서버가 될 수 있는 실행 환경
이 됩니다.
따라서 보안도 변화해야 합니다.
AI가 기계의 속도로 코드를 만들고 실행한다면,
보안 역시 기계의 속도로 발견하고 검증해야 합니다.
앞으로 기업 보안의 경쟁력은 얼마나 많은 취약점을 찾는가가 아니라, 실제 공격 가능한 위험을 얼마나 빠르게 증명하고 대응하는가에 달려 있습니다.
정리
AI 코딩 도구는 노트북을 서버처럼 만들 수 있다.
MCP, Local LLM Proxy는 새로운 공격 표면이 될 수 있다.
localhost도 항상 안전한 것은 아니다.
AI가 추천하는 패키지는 공급망 위험을 만들 수 있다.
기존 EDR·NAC만으로는 새로운 위험을 모두 탐지하기 어렵다.
AI 시대에는 Continuous Validation과 Machine Speed Security가 필요하다.
https://www.softwidesec.com/RidgeBot
RidgeBot에 대한 소개자료 및 데모요청은 소프트와이드시큐리티로 연락부탁드립니다.