⚡ 3줄 요약
- AI 보안은 어떤 모델을 쓰느냐가 아니라 데이터·권한·실행이라는 세 경계를 어떻게 그었느냐에서 갈린다.
- “연결이 편하다”와 “연결이 안전하다”는 다른 말이다 — 편의는 대개 경계를 무너뜨리는 방향으로 작동한다.
- 도입 여부를 가르는 최종 질문은 하나 — 문제가 터졌을 때 되돌릴 수 있는가.
AI 도구를 검토할 때 사람들은 먼저 모델 이름을 묻는다. 어떤 LLM이 붙어 있고, 벤치마크 점수는 몇 점이며, 컨텍스트는 얼마나 긴지. 그런데 사고는 모델의 똑똑함에서 나지 않는다. 똑똑한 모델이 접근하면 안 되는 데이터에 접근하고, 실행하면 안 되는 명령을 실행할 때 난다. AI 보안은 결국 세 개의 경계를 어디에 긋느냐의 문제다 — 데이터가 어디까지 흐르는가(데이터 경계), 무슨 권한으로 움직이는가(권한 경계), 어디서 코드가 도는가(실행 경계). 이 글은 그 세 경계를 어떻게 확인하는지, 처음 이 분야를 보는 사람을 위한 지도다.

왜 ‘모델’이 아니라 ‘경계’인가
모델은 빠르게 바뀐다. 이번 달의 최신 모델은 다음 분기면 구형이 된다. 반면 데이터가 새는 방식, 권한이 과하게 부여되는 방식, 검증되지 않은 코드가 실행되는 방식은 20년째 거의 그대로다. 보안을 모델에 걸면 매번 갈아엎어야 하지만, 경계에 걸면 모델이 바뀌어도 안전장치는 유지된다.
그래서 이 분야의 첫 번째 사고 전환은 이것이다 — “이 AI가 얼마나 똑똑한가”가 아니라 “이 AI가 무엇에 손댈 수 있는가”를 먼저 묻는다. 똑똑함은 성능의 문제이고, 손댈 수 있는 범위는 보안의 문제다. 둘은 완전히 다른 축이다.
세 개의 경계: 지도 전체 보기
| 경계 | 핵심 질문 | 무너지면 생기는 일 |
|---|---|---|
| 데이터 경계 | 내 데이터가 어디까지 이동하나? | 민감 정보가 외부 API·학습 데이터로 유출 |
| 권한 경계 | 이 도구가 무슨 권한으로 실행되나? | 과잉 권한으로 파일 삭제·전송·결제까지 실행 |
| 실행 경계 | 코드가 어디서, 무엇을 건드리며 도나? | 검증 안 된 패키지가 네트워크·시스템에 침투 |
이 세 경계는 순서대로 좁혀 들어가는 관문이다. 데이터가 어디로 가는지 모르면 권한을 논할 수 없고, 권한이 불분명하면 실행을 통제할 수 없다. 아래에서 하나씩 본다.
데이터 경계 — ‘편리한 연결’을 의심하라
AI 도구의 셀링 포인트는 대개 “연결이 쉽다”다. 파일 하나 끌어다 놓으면 요약되고, 계정 하나 연동하면 메일·캘린더·문서를 다 읽는다. 여기서 놓치는 게 있다 — 편리한 연결은 정의상 넓은 접근 권한을 전제한다. 메일을 요약하려면 메일 전부를 읽어야 하고, 그 데이터는 어딘가로 이동한다.
확인할 것은 세 가지다. 첫째, 데이터가 로컬에 머무는가 외부로 나가는가. 둘째, 나간다면 어느 사업자의 서버로, 어떤 목적으로 가는가(추론용인지 학습용인지). 셋째, 로컬 파일·샌드박스·외부 API·모델 실행 환경이 분리되어 있는가 뒤섞여 있는가. 이 넷이 한 공간에서 뒤섞이면, 하나가 뚫릴 때 전부가 뚫린다.
⚠️ 가장 흔한 함정
“우리는 데이터를 학습에 쓰지 않는다”는 문장과 “데이터가 우리 서버를 거치지 않는다”는 문장은 전혀 다르다. 앞은 목적의 약속이고 뒤는 경로의 사실이다. 대부분의 논란은 이 둘을 같은 뜻으로 읽는 데서 시작된다.
권한 경계 — 에이전트는 ‘무엇을 할 수 있는가’로 판단한다
요즘 AI는 답만 하지 않는다. 도구를 호출하고, 파일을 쓰고, API를 때리고, 결제까지 한다. 이 ‘에이전트’형 도구에서 보안의 무게중심은 데이터에서 행동으로 옮겨간다. 질문이 바뀐다 — “무엇을 읽나”에서 “무엇을 실행할 수 있나”로.
여기서 원칙은 오래된 보안 상식 그대로다. 최소 권한. 이 에이전트가 실제로 필요한 딱 그만큼의 권한만 준다. 파일을 읽기만 하면 되는 도구에 쓰기·삭제 권한을 주지 않는다. 그리고 속도 제한을 건다. 사람이라면 하루에 세 번 할 작업을 에이전트가 초당 수백 번 반복하면, 정상 동작 하나가 사고로 증폭된다.
정책 자체도 경계 대상이다. 정책을 AI가 자동으로 바꾸게 두면 안 된다. 변경 이력을 남기고, 누가 승인했는지 기록하고, 승인 경계를 명확히 둔다. “왜 이 에이전트가 이 권한을 갖게 됐는지” 나중에 추적할 수 없는 시스템은, 사고 났을 때 원인도 못 찾는다.
실행 경계 — 설치와 공급망이 진짜 문턱이다
세 경계 중 가장 과소평가되는 게 실행 경계다. AI 패키지나 모델을 “설치 한 줄이면 끝”이라고 홍보하지만, 그 한 줄이 무엇을 내려받아 무엇을 실행하는지는 아무도 안 본다. 공급망 공격은 정확히 이 틈을 노린다 — 멀쩡해 보이는 패키지 안에 감춰진 의존성, 낯선 실행 파일, 조용한 네트워크 호출.
설치 전에 볼 것은 네 가지다. 의존성(무엇을 함께 끌고 오나), 실행 파일(어떤 바이너리가 도나), 네트워크 접근(설치·실행 중 어디로 통신하나), 업데이트 경로(누가, 어떻게 이걸 갱신하나). 그리고 하나 더 — 이 모든 게 통과됐다 해도, 롤백할 수 없으면 운영에 넣지 않는다. 되돌릴 수 없는 시스템은 검토가 끝난 게 아니라 시작도 안 한 것이다.
🎯 FEEDON의 선택 — 우리라면 이렇게 본다
우리는 새 AI 도구를 볼 때 벤치마크 표를 제일 나중에 본다. 먼저 보는 건 “이게 내 데이터로 무엇을 할 수 있고, 무엇을 실행할 수 있으며, 사고 나면 되돌릴 수 있는가” 세 줄이다. 이 세 줄이 흐릿하면 모델이 아무리 좋아도 도입하지 않는다.
순서도 정해져 있다 — 데이터 경계부터 긋고 → 권한을 최소로 조인 뒤 → 실행을 샌드박스에 가둔다. 거꾸로 가지 마라. 실행부터 열어놓고 나중에 권한을 조이려 들면, 이미 흐른 데이터는 회수되지 않는다. 보안은 사후 옵션이 아니라 도입 전에 그어야 하는 선이다.
도입 전 검증 체크리스트
- 데이터 — 내 데이터가 로컬에 머무는지, 외부로 나간다면 어느 서버·어떤 목적인지 확인했나?
- 분리 — 로컬 파일·샌드박스·외부 API·모델 실행 환경이 서로 격리돼 있나?
- 권한 — 에이전트에 최소 권한만 부여하고 속도 제한을 걸었나?
- 기록 — 도구 호출과 정책 변경, 승인자가 로그로 남나?
- 공급망 — 설치 전 의존성·실행 파일·네트워크·업데이트 경로를 점검했나?
- 복구 — 실패를 감지·격리하고 롤백하는 절차를 실제로 테스트했나?
지금 할 일
🔒 지금 할 일
- 지금 쓰는 AI 도구가 내 데이터를 외부 서버로 보내는지 확인하고, ‘학습에 안 쓴다’는 약속이 아니라 ‘어느 서버를 경유하는가’ 경로부터 짚어라.
- 에이전트에 준 권한을 최소 권한으로 줄여라 — 읽기만 필요한 도구에서 쓰기·삭제·전송 권한을 회수하고, 호출 속도 제한을 걸어라.
- 로컬 파일·샌드박스·외부 API·모델 실행 환경을 서로 격리하라. 한 공간에 뒤섞여 있으면 하나 뚫릴 때 전부 뚫린다.
- 새 패키지·모델은 설치 전에 의존성·실행 파일·네트워크 호출·업데이트 경로를 점검하고, 출처가 불분명하면 운영에 넣지 마라.
- 운영 투입 전에 롤백 절차를 실제로 한 번 돌려보라 — 되돌릴 수 없으면 도입 검토가 끝난 게 아니다.
AI 시스템의 데이터·권한·실행 경계와 검증 기준을 실무 관점에서 정리한 개괄 가이드다.
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.



