많은 기업과 개발자들이 LLM(거대언어모델)의 놀라운 성능에 매료되어 빠르게 제품에 적용하고 있습니다. 하지만 ‘성능’에만 매몰된 나머지, 정작 이 모델이 실제 서비스 환경에서 어떤 공격 경로에 노출될 수 있는지에 대한 고민은 뒷전인 경우가 많습니다. 단순히 API를 연결하고 프롬프트를 튜닝하는 것만으로는 충분하지 않습니다. 공격자가 프롬프트 인젝션을 통해 내부 데이터를 탈취하거나, 모델의 가드레일을 무너뜨려 부적절한 답변을 생성하게 만든다면 그 피해는 고스란히 기업의 신뢰도 하락과 법적 리스크로 돌아옵니다.

우리는 흔히 보안을 ‘개발 완료 후 수행하는 검수 단계’로 생각합니다. 하지만 AI 시스템에서는 이러한 접근 방식이 매우 위험합니다. AI 모델의 동작 방식은 결정론적이지 않으며, 입력값에 따라 예측 불가능한 결과가 도출될 수 있기 때문입니다. 따라서 설계 단계부터 잠재적인 위협을 식별하고 이를 완화하는 ‘위협 모델링(Threat Modelling)’ 과정이 필수적입니다.

AI 위협 모델링이란 무엇인가?

위협 모델링은 시스템의 구조를 분석하여 잠재적인 보안 위협을 식별하고, 우선순위를 정해 대응 방안을 마련하는 체계적인 프로세스입니다. 일반적인 소프트웨어 보안과 달리 AI 위협 모델링은 데이터 파이프라인, 모델 학습 과정, 추론 인터페이스, 그리고 AI 에이전트의 권한 관리라는 특수한 영역을 모두 포괄해야 합니다.

특히 최근의 AI 인프라는 하드웨어 가속기부터 모델 서빙 프레임워크, 벡터 데이터베이스에 이르기까지 매우 복잡한 수직적 통합 구조를 가지고 있습니다. 이러한 복잡성은 공격자에게 더 많은 ‘공격 표면(Attack Surface)’을 제공하며, 이는 곧 보안 취약점으로 이어집니다.

AI 시스템의 주요 공격 벡터와 취약점

AI 모델을 분석할 때 우리가 가장 먼저 주목해야 할 지점은 데이터의 흐름입니다. 데이터가 입력되어 모델을 거쳐 출력되기까지의 과정에서 발생할 수 있는 위협은 다음과 같습니다.

• 프롬프트 인젝션(Prompt Injection): 사용자가 교묘하게 설계된 입력을 통해 모델의 시스템 프롬프트를 무시하게 만들고, 개발자가 설정한 제약 조건을 우회하는 공격입니다.
• 데이터 오염(Data Poisoning): 학습 데이터나 파인튜닝 데이터에 악의적인 데이터를 삽입하여 모델이 특정 상황에서 편향되거나 잘못된 동작을 하도록 유도하는 기법입니다.
• 모델 추출 및 도용(Model Extraction): API 응답 값을 분석하여 모델의 가중치나 구조를 역설계함으로써 지적 재산을 탈취하는 행위입니다.
• 간접적 프롬프트 인젝션: 모델이 외부 웹페이지나 문서를 읽어올 때, 그 문서 내에 숨겨진 악성 명령어를 실행하게 만드는 고도화된 공격 방식입니다.

기술적 구현: 위협 모델링의 단계별 접근법

실제로 TryHackMe와 같은 실습 플랫폼에서 강조하는 위협 모델링의 핵심은 ‘가시화’와 ‘시뮬레이션’입니다. 단순히 체크리스트를 채우는 것이 아니라, 공격자의 관점에서 시스템을 바라봐야 합니다.

먼저 데이터 흐름도(DFD, Data Flow Diagram)를 작성하십시오. 사용자의 입력이 어디로 흐르는지, 어떤 외부 API와 통신하는지, 데이터베이스의 어떤 영역에 접근하는지를 명확히 그려야 합니다. 그 다음, 각 흐름의 경계(Trust Boundary)를 설정하십시오. 예를 들어, 사용자 입력창과 내부 프롬프트 처리 엔진 사이는 신뢰할 수 없는 경계로 설정하고, 이곳에 강력한 필터링 계층을 배치해야 합니다.

이후 STRIDE 모델을 적용하여 위협을 분류합니다. Spoofing(신분 도용), Tampering(변조), Repudiation(부인), Information Disclosure(정보 유출), Denial of Service(서비스 거부), Elevation of Privilege(권한 상승)의 관점에서 AI 모델의 각 구성 요소를 분석하는 것입니다. 예를 들어, AI 에이전트가 이메일 전송 권한을 가지고 있다면, 프롬프트 인젝션을 통해 권한을 상승시켜 무단으로 메일을 보내는 시나리오를 상정할 수 있습니다.

AI 모델 분석의 트레이드오프: 성능 vs 보안

보안을 강화하면 필연적으로 성능이나 사용자 경험(UX)에 영향을 미칩니다. 너무 엄격한 가드레일은 모델의 창의성을 저해하고, ‘거절 답변’만 반복하는 무능한 AI를 만들 수 있습니다. 반대로 보안을 느슨하게 하면 심각한 사고로 이어질 수 있습니다.

결국 핵심은 ‘적정 수준의 균형’을 찾는 것입니다. 모든 요청을 검사하기보다, 위험도가 높은 API 호출(예: 데이터 삭제, 외부 전송) 직전에만 추가적인 검증 단계를 두는 ‘계층적 방어(Defense in Depth)’ 전략이 효율적입니다.

실무자를 위한 액션 아이템: 지금 당장 시작해야 할 것들

AI 제품을 운영 중인 개발자와 PM이라면 다음의 단계를 즉시 실행에 옮기십시오.

• 공격 표면 매핑: 우리 서비스에서 AI 모델이 외부 데이터와 상호작용하는 모든 접점을 리스트업 하십시오. 특히 RAG(검색 증강 생성)를 사용한다면 외부 문서 저장소가 공격 경로가 될 수 있음을 인지해야 합니다.
• 레드팀 테스트(Red Teaming) 도입: 정기적으로 의도적인 공격 시나리오를 작성하여 모델의 취약점을 테스트하십시오. 내부 인력이 어렵다면 외부 보안 전문가나 오픈소스 벤치마크 툴을 활용해 ‘탈옥(Jailbreak)’ 가능성을 점검하십시오.
• 입출력 가드레일 구축: NeMo Guardrails와 같은 프레임워크를 도입하여 입력 단계에서 유해한 쿼리를 차단하고, 출력 단계에서 민감 정보(PII)가 유출되지 않도록 필터링 시스템을 구축하십시오.
• 최소 권한 원칙 적용: AI 에이전트에게 부여하는 API 권한을 최소화하십시오. 모델이 직접 DB에 쿼리를 날리게 하지 말고, 사전에 정의된 함수(Function Calling)만을 통해 제한된 데이터에만 접근하게 설계하십시오.

결론: 보안은 기능이 아니라 문화다

AI 위협 모델링은 한 번의 작업으로 끝나는 프로젝트가 아닙니다. 모델이 업데이트되고, 새로운 공격 기법이 등장하며, 제품의 기능이 확장될 때마다 지속적으로 갱신되어야 하는 프로세스입니다. 보안을 개발의 방해 요소가 아니라, 제품의 완성도를 높이는 핵심 경쟁력으로 인식해야 합니다.

결국 가장 강력한 보안은 최신 툴을 사용하는 것이 아니라, ‘어디서 문제가 생길 수 있는가’를 끊임없이 질문하는 개발자의 비판적 사고에서 시작됩니다. 지금 바로 여러분의 AI 서비스 흐름도를 그려보고, 공격자의 시선으로 그 빈틈을 찾아보시기 바랍니다.