우리는 LLM으로 코드를 짜고, VLM으로 문서를 처리합니다. AI가 개발의 중심이 된 만큼, AI 자체가 공격 경로가 됩니다. 이 글은 우리 팀이 마주한 위협을 정직하게 분석하고, "보안을 내재화한 AI 개발 가이드"를 어떻게 만들었는지 공유합니다.
01. 우리는 어떤 환경에서 일하는가
우리 제품의 핵심은 AI OCR입니다. 고객이 제출한 문서를 VLM이 읽고 LLM이 해석해 구조화된 데이터로 변환하며, 이 과정에서 신분증, 의료 차트 등 민감한 데이터가 대량으로 처리됩니다. 또한 개발자들은 GitHub Copilot, Claude 등을 일상적으로 사용하며 AI와 함께 협업하고 있습니다. 하지만 AI가 생산성의 중심이 된 바로 그 지점이 가장 넓은 공격 표면이 됩니다.
주목해야 할 수치가 있습니다. 간접 프롬프트 인젝션 공격의 성공률은 91%에 달하며, 프롬프트 인젝션은 OWASP LLM Top 10(2025)에서 1위를 차지했습니다. 그럼에도 전용 방어 솔루션을 도입한 기업은 35%에 불과합니다. OpenAI와 영국 NCSC는 이 위협이 완전히 차단될 수 없다고 공식 인정했습니다.
02. 우리가 마주하고 있는 위협들
우리 환경을 위협하는 것은 두 가지입니다. 하나는 AI OCR 파이프라인에 대한 외부 공격, 다른 하나는 AI 개발 도구를 통한 내부 취약점입니다. 두 가지 모두 "AI가 텍스트를 명령으로 실행한다"는 동일한 구조적 결함을 이용합니다.
간접 프롬프트 인젝션 [치명적]
고객 문서 안에 흰색 텍스트나 투명 레이어로 숨겨진 명령을 VLM이 정상 입력으로 인식해 실행합니다. OCR 파이프라인이 가장 직접적으로 노출되는 위협입니다. 문서 내 숨겨진 명령을 VLM이 실행하는 위협으로, 공격 성공률이 91%에 달합니다.
AI 에이전트 원격 제어 [치명적]
OpenClaw 유형의 PC 조작 에이전트는 링크 클릭만으로 인증 토큰이 탈취될 수 있는 CVE-2026-25253(CVSS 8.8) 위협이 존재합니다. 정상 사용자의 마우스·키보드 조작과 동일한 방식으로 작동하기 때문에 기존 보안 솔루션은 이를 정상 행동과 구분하지 못합니다.
RAG 파이프라인 오염 [치명적]
벡터 DB에 악성 문서가 삽입되어 지식 기반 전체가 공격 대상이 될 수 있습니다.
API 키 소스코드 노출 [높음]
AI 개발 과정에서 LLM API 키를 env나 코드에 하드코딩하여 유출되는 사고가 빈번합니다. 커뮤니티 서비스 한 곳에서 150만 개 키가 유출된 사례가 보고되었습니다.
AI 개발 도구 코드 탈취 [높음]
코드 주석의 인젝션이 개발자 PC에서 임의 코드를 실행하는 CVE-2025-53773 위협이 있습니다. 소스코드 자체가 공격 매개체가 됩니다.
외부 AI 서비스 데이터 유출 [높음]
직원이 고객 문서를 외부 ChatGPT·Claude 등에 업로드하면 개인정보가 서비스 학습 데이터로 사용될 위험이 있습니다. 가장 빈번하게 발생하는 실수입니다.
오픈소스 모델 공급망 공격 [중간]
Hugging Face 등에서 내려받은 오픈소스 모델 파일에 백도어가 삽입된 사례가 증가하고 있습니다. 체크섬 검증 없이 배포하면 안 됩니다.
섀도 AI (Shadow AI) [중간]
별도 승인 없이 설치된 AI 플러그인·에이전트 도구가 사내 데이터를 외부로 전송하는 경로가 됩니다. 관리되지 않는 AI 도구는 모두 잠재적 위협입니다.
핵심 구조적 문제
모든 위협의 공통 원인은 하나입니다. AI 모델이 데이터와 명령을 구분하지 못합니다. 문서 안의 텍스트든, 이메일 본문이든, 코드 주석이든 — LLM/VLM에게는 동일한 토큰 스트림입니다. 이것은 버그가 아니라 현재 AI 아키텍처의 구조적 한계입니다. 완전한 차단은 불가능하며, 탐지·격리·최소화가 현실적 전략입니다.
03. 보안 아키텍처 설계 원칙
우리가 내린 첫 번째 결론은 '외부 입력을 절대 신뢰하지 않는다'는 원칙입니다. 고객이 제출한 모든 문서는 Untrusted Zone에서 처리되며, 어떤 경우에도 내부 시스템의 명령 실행 권한을 가져서는 안 됩니다.
처리 흐름은 네 개 계층으로 구성됩니다.
첫 번째는 입력 계층(Untrusted)입니다. 모든 유입 문서에 악성 명령이 포함될 수 있다고 전제합니다. 두 번째는 검증 계층(Validate)입니다. 인젝션 패턴 탐지 및 파일 무결성을 검사합니다. 세 번째는 처리 계층(Process)입니다. 격리된 컨테이너(Sandboxing) 내에서 모델이 동작하며 외부 네트워크를 차단합니다. 네 번째는 신뢰 계층(Trusted)입니다. 사람의 최종 승인을 거친 결과만 내부 DB 및 ERP에 도달합니다.
이 아키텍처의 핵심은 컨텍스트 격리(Context Isolation)입니다.
시스템 프롬프트와 외부 입력은 물리적으로 분리된 처리 경로를 가집니다.
VLM이 문서를 읽는 컨텍스트 윈도우에는 내부 API 정보, DB 연결 정보, 실행 가능한 명령어가 절대 포함되지 않아야 합니다.
04. 개발자 보안 코딩 가이드
우리 팀은 '보안 체크리스트'가 아닌 기본값이 안전한 코드 패턴을 만들기로 했습니다.
보안은 검토 단계가 아니라 코드를 쓰는 순간부터 내재되어야 합니다.
원칙 1. 외부 입력과 시스템 프롬프트를 절대 혼합하지 않는다
OCR 처리 시 고객 문서 내용을 시스템 프롬프트에 포함시키지 않습니다. 외부 입력은 항상 user 역할로 전달하고, 내부 명령은 system 역할에만 위치합니다.
잘못된 예시는 이렇습니다. messages = [{"role": "system", "content": f"문서: {doc_text}를 처리해라"}]처럼 외부 입력이 시스템 프롬프트에 섞이는 구조는 금지합니다.
올바른 패턴은 system 프롬프트에 역할과 제약만 정의하고, 문서 이미지는 user 메시지로 분리해 전달합니다. 출력 결과는 예상 JSON 스키마와 대조 검증을 거친 뒤 내부 시스템에 전달합니다. 스키마를 벗어난 응답은 즉시 거부하고 보안담당자에게 알림을 발송합니다.
원칙 2. API 키는 코드에 존재해서는 안 된다
CI/CD 파이프라인에 git-secrets 훅을 필수 등록하고, PR 머지 전 자동 스캔을 통과해야 합니다. 스캔 대상에는 OpenAI(sk-), Anthropic(sk-ant-), Google(AIza) 패턴이 모두 포함됩니다.
원칙 3. LLM 출력을 직접 실행하지 않는다
LLM이 생성한 SQL, 셸 명령어, API 파라미터는 반드시 검증 레이어를 거칩니다. 화이트리스트 기반 출력 필터링을 적용하고, 예상 범위를 벗어난 출력은 즉시 거부합니다.
원칙 4. 자체적으로 개발해서 사용하는 AI 에이전트에 최소 권한 원칙을 적용한다
에이전트가 접근할 수 있는 파일·API·DB를 해당 작업에 꼭 필요한 범위로 제한합니다. 파일 전송, 외부 이메일 발송, 결제 등 비가역적 작업은 반드시 인간의 최종 승인을 요구합니다.
원칙 5. 모든 AI 행동을 감사 로그로 기록한다
어떤 프롬프트가 어떤 행동(파일 접근, API 호출, DB 쓰기)을 유발했는지 1:1로 매핑합니다. 로그는 변조 불가능한 외부 스토리지에 저장하고, 이상 패턴 발생 시 즉시 알림이 발송됩니다.
05. AI 개발 도구 안전 사용 가이드
AI 도구 사용을 금지하는 것은 답이 아닙니다. 우리는 안전하게 사용하는 방법을 표준화합니다. 코드 생성 AI는 강력하지만, 생성된 코드에 악성 패턴이 포함될 수 있습니다. AI가 생성한 코드도 반드시 사람이 검토해야만 합니다.
GitHub Copilot — 일반 코드 작성과 보일러 플레이트 생성에 사용하지만 고객 데이터가 포함된 코드를 컨텍스트로 제공하는 행위는 금지해야 합니다.
Claude — 설계 리뷰, 문서 작성, 코드 리뷰에 사용하고, 실제 고객 문서를 업로드하는 행위는 금지해야 합니다.
ChatGPT — 공개 정보 기반 질의에만 사용하며, 내부 코드, 고객 데이터, API 키 입력은 금지해야 합니다.
AI 에이전트 — 격리 VM 환경에서만 테스트 목적으로 사용하고, 사내망 연결이나 프로덕션 자격증명 연동은 금지해야 합니다.
미승인 AI 플러그인 — 절대 사용하면 안됩니다.
AI가 생성한 코드에는 다음 다섯 가지를 반드시 사람이 직접 검토해야 합니다.
하드코딩 된 크리덴셜(Credential), eval·exec 사용 여부, 검증 없는 외부 입력 처리, 과도한 권한 요청, 알 수 없는 외부 라이브러리의 사용입니다.
06. 배포 전 보안 체크리스트
새로운 LLM·VLM 기능을 배포하기 전, 다음 항목을 모두 통과해야 하는 것으로 규정을 마련중에 있습니다.
시스템 프롬프트와 외부 입력 경로가 분리되어 있는가?
API 키·시크릿이 소스코드에 포함되어 있지 않은가?
LLM 출력 결과에 대한 스키마 검증이 구현되어 있는가?
AI 에이전트 권한이 최소 필요 범위로 제한되어 있는가?
비가역적 작업에 인간 승인 단계가 포함되어 있는가?
프롬프트→행동 전 구간 감사 로그가 활성화되어 있는가?
Hugging Face 등에서 모델을 다운로드할 때, 보안상 취약한 Pickle 포맷 대신 Safetensors 포맷의 모델을 사용하는가?
프롬프트 인젝션 테스트 케이스가 CI에 포함되어 있는가?
이상 출력 탐지 모니터링 알림이 설정되어 있는가?
07. AI로 더 빠르게, 보안으로 더 안전하게
규정을 마련하면서 가장 중요하게 생각한 것은 보안이 개발 속도를 늦추지 않는다는 믿음을 개발팀과 쌓아 가는 것입니다. 안전한 기준을 표준화할 경우 매번 보안을 고민해야 하는 개발팀의 인지 부하가 줄어들 수 있습니다.
프롬프트 인젝션은 OpenAI와 영국 NCSC가 완전히 막을 수 없다고 공식적으로 인정했습니다. 하지만 탐지하고, 격리하고, 최소화할 수 있는 방안을 마련해야 합니다.
우리의 목표는 완벽한 차단이 아닌, 공격이 성공하더라도 피해 반경을 제한하고, 즉시 탐지할 수 있는 체계를 마련하는 것입니다.
새로운 취약점이 발견될 때마다 패턴도 업데이트해야 하며, 한 번의 설정이 아니라 지속적으로 보완하고 개선할 작업이라고 봅니다.
참고 자료: OWASP LLM Top 10 (2025) · Cisco State of AI Security 2026 · OpenAI Atlas Prompt Injection Report (2025.12) · Lakera AI Q4 2025 Threat Analysis · NIST AI Risk Management Framework · ISO/IEC 42001 AI Management System · CVE-2025-53773 (GitHub Copilot) · CVE-2026-25253 (OpenClaw Agent)
08. 고객에게 드리는 보안 약속
지금까지 어떤 위협을 직시하고, 어떻게 대응 체계를 구축하고 있는지를 정리했습니다.
이 모든 과정의 최종 목적지는 하나이며, 고객의 데이터를 안전하게 처리하는 것입니다.
고객은 계약서, 의료 기록, 도면처럼 민감하고 소중한 자산을 우리에게 위탁합니다.
상호 신뢰를 기반으로 하기에 철저히 관리해야만 합니다.
고객 문서는 처리 후 즉시 파기합니다. 업로드된 문서 이미지는 OCR 처리가 완료되는 즉시 서버에서 삭제합니다. 어떠한 원본 문서도 당사 스토리지에 보관하지 않습니다.
완전 격리된 환경에서 처리합니다. 문서는 외부 인터넷이 차단된 컨테이너 안에서만 처리합니다. 문서 처리 중 외부 네트워크 연결이 발생하지 않습니다.
고객 데이터로 모델을 학습하지 않습니다. 처리한 고객 데이터는 당사 AI 모델의 학습·파인튜닝에 사용하지 않습니다. 고객이 제공한 문서는 고객의 결과물을 만드는 것에만 사용됩니다.
프롬프트 인젝션 방어를 구축합니다. 악성 명령이 숨겨진 것으로 의심되는 문서는 자동 격리 후 보안팀에 전달할 계획입니다.
처리 전 과정이 감사 로그로 보존됩니다. 문서 접수부터 결과 반환까지 전 과정이 변조 불가능한 감사 로그로 기록되고, 고객이 요청 시 내역 전체를 투명하게 공개합니다.
보안 업데이트를 지속적으로 수행합니다. AI 보안 위협은 매일 진화합니다. 신규 취약점을 상시 모니터링하고 정기적으로 업데이트해야 합니다.
"당신의 문서가 처리되는 동안 단 한 줄의 데이터도 밖으로 나가지 않습니다."
"AI OCR의 편리함과 보안의 엄격함은 함께 존재할 수 있습니다. 우리는 그것을 기술로 증명하겠습니다."
준수 기준 및 인증: 개인정보보호법(PIPA) · ISO/IEC 27001 · ISO/IEC 42001 AI · NIST AI RMF · OWASP LLM Top 10 · 전자금융거래법
© 2026 Lomin AI OCR Tech Blog — Security Engineering Team