5장. 운영 보안과 사고 대응

학습 목표

• 사고 조사에 답할 수 있는 감사 로그를 설계하고, 로그 자체를 민감 데이터로 보호한다.
• 비용·자원 고갈 공격과 에이전트의 폭주를 탐지하고 예산과 차단 장치로 제한한다.
• 모델, 모델 파일, 플러그인, MCP 서버의 공급망 위험을 도입·변경 절차로 줄인다.
• LLM 사고 대응 절차를 단계별 담당자, 차단 수단, 증거, 복구 기준과 함께 수립한다.
• 개인정보 유출이 의심될 때 확인해야 할 법적 통지·신고 요건의 뼈대를 설명한다.

들어가며

금요일 밤, 어느 회사의 고객 지원 에이전트가 평소보다 열 배 많은 메일을 보내기 시작했습니다. 당직자는 경보를 받고 로그를 열었지만 로그에는 "도구 호출 성공"만 줄줄이 찍혀 있었습니다. 어떤 세션에서, 어떤 입력을 읽고, 누구에게 무엇을 보냈는지는 남아 있지 않았습니다. 발송 도구만 끄는 스위치가 없어서 서비스 전체를 내렸고, 월요일 아침까지 고객 문의가 쌓였습니다. 원인은 조사 끝에 밝혀졌지만, 몇 명의 고객 정보가 어디로 나갔는지는 끝내 확정하지 못했습니다. 당직자가 잘못한 것은 없었습니다. 사고 당일에 할 수 있는 일은 그 전에 만들어 둔 로그와 스위치가 정합니다. 그리고 운영 중의 사고는 공격자 없이도 일어납니다. 임시로 켠 설정 하나, 밤사이 반영된 업데이트 하나가 개인정보 사고와 비용 사고로 번집니다.

운영 보안은 사고가 나기 전에 준비해 둔 것만큼만 작동합니다. 이 장은 사고 조사에 답할 수 있는 감사 로그와 그 로그의 보호에서 시작해, 비용·자원 고갈과 에이전트 폭주를 제한하는 장치, 모델과 플러그인의 공급망 관리, 이상 신호의 설계를 다룹니다. 마지막으로 LLM 사고 대응 절차와 차단 스위치, 개인정보 유출이 의심될 때의 통지·신고 요건을 정리합니다.

핵심 개념

감사 로그는 무엇을 증명해야 하는가

사고가 나면 가장 먼저 묻는 질문은 "언제, 누구의 세션에서, 어떤 입력이 들어와, 모델이 무엇을 했나"입니다. OWASP Logging Cheat Sheet는 이벤트마다 언제, 어디서, 누가, 무엇을 남기라고 하고, 관련 이벤트를 잇는 상호작용 식별자를 함께 두라고 권합니다. LLM 애플리케이션에서는 하나의 요청이 검색, 여러 번의 모델 호출, 도구 호출, 승인으로 갈라지므로 이를 잇는 추적 식별자가 빠지면 조사가 끊깁니다.

로그는 "모델이 어떻게 생각했는가"보다 "시스템이 무엇을 허용했고 무엇을 실행했는가"를 증명해야 합니다. 하위 시스템 로그에 실제 요청자 대신 중계 서버만 남으면 조사가 막힌다는 점은 MCP 보안 모범 사례도 지적합니다.

로그 자체를 지키기

로그도 민감 데이터입니다. OWASP Logging Cheat Sheet는 세션 식별자, 접근 토큰, 비밀번호, 암호화 키와 기타 핵심 비밀값, 데이터베이스 접속 문자열, 결제 정보, 민감한 개인정보를 로그에서 제거하거나 가리거나 해시하거나 암호화하라고 합니다. 로그 보호도 함께 요구합니다. 위·변조 탐지, 가능한 한 빨리 읽기 전용 매체로 복사, 로그 접근의 기록과 감시, 열람 권한의 제한과 정기 검토입니다. 신뢰 경계 밖에서 온 데이터는 줄바꿈 문자 등을 정리해 로그 인젝션을 막습니다. 모델 출력과 외부 문서가 대표적입니다.

국내 기준도 같은 방향입니다. 개인정보의 안전성 확보조치 기준(개인정보보호위원회 고시)은 개인정보처리시스템에 접속한 자(정보주체 제외)의 접속기록을 1년 이상 보관·관리하고, 5만 명 이상의 정보주체 정보나 고유식별정보·민감정보를 처리하는 시스템 등은 2년 이상 보관하며, 접속기록이 위·변조되거나 도난·분실되지 않도록 안전하게 보관하라고 요구합니다. 에이전트가 개인정보처리시스템에 접근하는 구조라면, 그 접근 기록이 이 기준의 접속기록과 어떻게 대응하는지 개인정보 보호 책임자와 함께 정해 두세요.

원문 대화 전체를 남길지는 별도의 결정입니다. 기본 로그는 가림 처리한 구조화 필드로 남기고, 조사에 꼭 필요한 원문은 접근이 엄격히 제한된 별도 저장소에 짧게 보관하는 방식이 일반적인 절충입니다.

사용자 식별과 남용 추적

남용을 막으려면 누가 반복하는지 알아야 합니다. OpenAI는 요청에 safety_identifier 매개변수를 붙여 사용자를 고유하게 식별하되, 사용자 이름이나 이메일은 해시해서 식별 정보를 보내지 않게 하라고 권합니다. 로그인하지 않은 사용자에게는 세션 식별자를 대신 보낼 수 있습니다. 같은 문서는 가입과 로그인을 요구하는 등 사용자를 알아 두는 것(KYC)이 위험을 줄인다고도 합니다.

Anthropic은 같은 종류의 거절을 반복해서 유발하는 사용자에게 정책 위반을 알리고 속도 제한이나 차단으로 대응하라고 권합니다. 그러려면 가드레일 판정을 해시나 내부 가명으로 남긴 사용자 식별자와 함께 기록하고, 실제 신원과의 대응표는 따로 관리합니다.

무제한 소비의 모습

OWASP LLM10(Unbounded Consumption)은 사용자가 과도하고 통제되지 않은 추론을 실행할 수 있을 때 생기는 위험입니다. 하위 위험은 일곱 가지입니다.

에이전트에서는 공격자 없이도 같은 일이 일어납니다. 도구 오류에 대한 재시도, 하위 작업의 분기, 에이전트끼리 서로 일을 넘기는 고리가 비용을 기하급수적으로 키웁니다. OWASP Agentic Top 10의 ASI08(Cascading Failures)이 말하는 확산이 비용의 모습으로 나타나는 경우입니다. 지갑 고갈은 서비스가 정상으로 보이는 동안에도 피해가 쌓인다는 점에서 일반적인 서비스 거부와 다릅니다.

예산과 차단 장치

OWASP LLM10은 입력 검증, 로짓·로그 확률 노출 제한, 요청률 제한, 자원 배분 관리, 시간 제한과 조절, 로깅·모니터링·이상 탐지, 워터마킹, 단계적 성능 저하, 접근 통제, 중앙 집중식 모델 목록 등 열다섯 가지 완화책을 듭니다. OpenAI도 사용자 입력 길이와 출력 토큰 수를 제한하면 오남용을 줄일 수 있다고 안내합니다.

애플리케이션 운영자가 먼저 갖출 것은 다음 장치입니다.

경보와 차단을 구분하세요. 비용 경보는 사람에게 알릴 뿐이고, 금요일 밤에는 아무도 보지 않을 수 있습니다. 예산 상한은 코드가 실행을 멈춥니다. 모델 추출에 대응하려면 OWASP의 권고대로 API 응답의 logit_bias·logprobs 같은 세부 확률 정보 노출을 제한하거나 흐리고, 계정별 사용량 패턴을 감시합니다. OWASP AI Agent Security Cheat Sheet도 세션별 토큰 사용과 비용을 추적하고 연쇄 실패를 막는 회로 차단기를 두라고 권합니다.

공급망 1: 모델과 모델 파일

OWASP LLM03(Supply Chain)은 오래된 서드파티 패키지, 라이선스, 유지보수가 끝난 모델, 백도어가 숨은 사전학습 모델, 약한 출처 보증, 악성 LoRA 어댑터, 공동 개발 과정의 악용, 기기 탑재 모델의 변조, 불명확한 약관을 공급망 위험으로 듭니다. 모델은 들여다보기 어려운 바이너리 블랙박스라 정적 검사만으로는 보증에 한계가 있습니다.

모델 파일 형식도 위험이 됩니다. Hugging Face 문서는 PyTorch 가중치의 기본 형식인 pickle 파일을 불러올 때 임의 코드가 실행될 수 있다고 경고합니다. 믿을 수 있는 사용자와 조직의 모델만 불러오고, 서명된 커밋으로 출처를 확인하라고 권하면서도, 서명은 파일의 안전이 아니라 출처를 보장할 뿐이라고 덧붙입니다. Hub의 보안 스캔도 완전하지 않다고 밝히며, pickle과 달리 텐서를 안전하게 저장하도록 만든 safetensors 형식을 안내합니다.

도입 절차는 다음 순서로 짭니다.

1. 공급자, 데이터 출처, 약관, 개인정보 정책을 검토하고 정기적으로 다시 확인합니다.
2. 검증 가능한 출처의 모델만 쓰고 서명과 파일 해시로 무결성을 확인합니다.
3. 불러올 때 코드가 실행될 수 있는 파일은 격리된 환경에서만 엽니다.
4. 벤치마크 대신 내 용도의 레드팀과 평가로 확인합니다. 모델이 공개 벤치마크를 우회하도록 미세조정될 수 있기 때문입니다(OWASP).
5. 패치 정책을 두고 유지보수되는 API와 모델에 의존합니다.

공급망 2: 도구·플러그인·MCP 서버

에이전트는 실행 중에 도구와 다른 에이전트를 불러옵니다. OWASP Agentic Top 10의 ASI04(Agentic Supply Chain Vulnerabilities)는 LLM03이 정적 의존성에 초점을 둔 것과 달리, 실행 중에 조합되는 도구, MCP 서버, 에이전트 레지스트리, 업데이트 채널이 오염되는 위험을 다룹니다. 처음 설치할 때 검토한 도구라도 업데이트 뒤에는 다른 도구일 수 있습니다.

MCP 보안 모범 사례는 로컬 MCP 서버의 위험을 구체적으로 적습니다. 로컬 서버는 사용자 컴퓨터에서 클라이언트와 같은 권한으로 실행되므로, 악성 시작 명령이나 악성 서버는 임의 코드 실행과 데이터 유출로 이어집니다. 원클릭으로 로컬 서버를 설정하게 하는 클라이언트는 실행될 명령을 잘리지 않은 전체 형태로 보여 주고, 위험한 작업임을 밝히고, 사용자의 명시적 승인을 받아야 합니다. 서버 명령은 최소 권한의 샌드박스에서 실행하고, 파일과 네트워크 접근을 제한하라고 권합니다.

운영 원칙은 넷입니다. 도구와 서버의 버전을 고정하고, 업데이트 때 이름·설명·매개변수·요청 범위의 변화를 비교하고, 권한이 넓어지면 새로 도입하듯 승인하고, 침해가 의심되면 연결과 토큰을 한 번에 끊는 철회 절차를 마련합니다.

구성 명세와 AI BOM, 모델의 수명주기

사고 때 "문제가 된 구성 요소를 어디서, 어느 버전으로 쓰고 있는가"에 바로 답하려면 목록이 있어야 합니다. OWASP LLM03은 서명된 최신 SBOM(소프트웨어 구성 목록)을 유지하고, 모델과 데이터까지 담는 AI BOM(ML SBOM)을 검토하라고 하며, 출발점으로 OWASP CycloneDX를 듭니다. CycloneDX의 ML-BOM은 AI·머신러닝 시스템의 데이터셋, 모델, 구성을 표현하고 출처를 기록하는 형식입니다. LLM 애플리케이션에서는 여기에 프롬프트, 도구 정의, 커넥터와 권한 범위, 분류기, 검색 색인의 출처까지 목록에 올려 두면 좋습니다.

모델에도 수명주기가 있습니다. Anthropic 문서에 따르면 각 모델 ID는 고정된 버전을 가리키고 그 ID의 가중치는 바뀌지 않지만(이전 세대에 있던 별칭은 최신 스냅샷을 따라가므로 예외), 요청 라우터나 안전 분류기 같은 서빙 인프라가 바뀌어 관측되는 동작이 조금 달라질 수 있습니다. 모델은 지원 중단(deprecated)을 거쳐 은퇴(retired)하며, 은퇴한 모델로 보낸 요청은 실패합니다. Anthropic은 공개 모델의 은퇴 최소 60일 전에 통지하고, 은퇴 훨씬 전에 대체 모델로 애플리케이션을 시험하라고 권합니다. 보안 관점에서 모델 교체는 1장의 재검토 조건입니다. 새 모델에 회귀 평가 세트(4장)를 다시 돌린 뒤 교체합니다.

탐지 신호 설계

수상한 문구를 찾는 탐지보다 실제 권한 남용과 피해의 징후를 보는 탐지가 오래갑니다.

담당자가 없는 경보는 쌓이기만 하므로 경보마다 담당자와 첫 조치를 정합니다. 목표 상태와 도구 사용 패턴의 기준선을 만들어 두면 예상 밖의 목표 변화나 도구 호출 순서를 이탈로 잡을 수 있습니다(OWASP Agentic Top 10).

사고 대응 절차

LLM 사고도 일반 보안 사고와 같은 뼈대를 따르되, 도구 권한, 기억과 색인, 프롬프트·모델 버전이라는 고유 요소가 더해집니다. NIST는 2025년 4월에 SP 800-61 Rev. 3을 내고 사고 대응 권고를 사이버보안 프레임워크(CSF) 2.0과 위험 관리 활동에 맞춰 정리했습니다. NIST AI RMF의 Manage 기능도 사고에 대한 대응·복구·소통 계획을 포함하고, 사고와 오류를 관련 주체에게 알리라고 합니다.

차단이 범위 확정보다 먼저입니다. 유출이 진행 중일 수 있는데 로그 분석부터 하면 그동안 피해가 커집니다. 반대로 원인을 확인하지 않고 급히 재개하면 같은 경로가 다시 열립니다. OpenAI는 키가 노출되었거나 오용되었을 가능성이 있으면 즉시 폐기하고 새 키로 바꾸라고 권하고, OWASP Secrets Management Cheat Sheet는 애플리케이션을 재시작해도 도난당한 자격 증명은 폐기되지 않는다고 경고합니다. 평소 비밀값을 중앙 관리 도구에 두고 자동 교체를 걸어 두면 폐기와 재발급이 빨라진다는 것도 같은 문서의 권고입니다.

차단 스위치와 안전한 축소 운영

"서비스 전체 끄기" 하나만 있는 시스템은 작은 사고에도 큰 비용을 치릅니다. 차단 스위치는 단위별로 준비합니다.

1. 도구 단위: 특정 도구(발송, 결제, 외부 가져오기)만 끕니다.
2. 연결 단위: 특정 MCP 서버나 커넥터와의 연결을 끊고 토큰을 회수합니다.
3. 기능 단위: 메모리 쓰기, 외부 링크 렌더링, 파일 업로드를 끕니다.
4. 모드 전환: 읽기 전용 모드, 미리 준비한 정적 안내 모드로 바꿉니다.
5. 작업 단위: 대기 중인 작업을 취소하고 진행 중인 작업을 멈춥니다.

스위치마다 누가 켜고 끌 수 있는지, 끄면 무엇이 멈추는지, 진행 중인 작업은 어떻게 되는지를 런북에 적고, 정기적으로 실제로 눌러 봅니다. 사용자 화면의 "중지" 버튼이 서버의 작업을 실제로 멈추는지도 시험 대상입니다. 분기마다 실제 시스템을 건드리지 않는 탁상 훈련으로 런북을 말로 따라가 보면 "도구 하나만 끄는 스위치가 없다", "공급자 연락 경로를 모른다" 같은 빈틈이 드러납니다.

개인정보 유출 통지와 기록

LLM 사고가 개인정보 유출로 이어지면 법적 통지·신고 요건이 생깁니다. 이 절의 내용은 판단의 뼈대이며 법률 자문이 아닙니다. 실제 사고에서는 개인정보 보호 책임자와 법무 담당자가 판단합니다.

개인정보 보호법 제34조는 개인정보처리자가 유출등(분실·도난·유출·위조·변조·훼손)을 알게 되었을 때 지체 없이 정보주체에게 유출 항목, 시점과 경위, 피해를 줄이기 위해 정보주체가 할 수 있는 방법, 처리자의 대응 조치와 구제 절차, 담당 부서와 연락처, 손해배상 청구와 분쟁조정 같은 법적 권리와 행사 방법 등을 알리도록 합니다. 2026년 9월 11일 시행된 개정으로 유출등의 가능성이 있음을 알게 된 경우의 통지도 새로 들어갔습니다. 시행령은 이 통지를 서면등의 방법으로 72시간 이내에 하도록 기한을 정하고(긴급 조치가 필요하면 그 사유가 해소된 뒤 즉시), 구체 내용을 아직 확인하지 못했으면 확인된 내용부터 먼저 알린 뒤 추가로 알리게 합니다. 시행령 제40조는 1천 명 이상의 정보주체 정보, 민감정보나 고유식별정보, 외부의 불법 접근에 의한 유출 가운데 하나에 해당하면 알게 된 때부터 72시간 이내에 개인정보보호위원회 또는 한국인터넷진흥원에 신고하도록 합니다. 부득이한 사유의 기한 예외와, 회수·삭제로 권익 침해 가능성이 현저히 낮아진 경우 신고하지 않을 수 있다는 단서도 있습니다. 건강에 관한 정보는 같은 법 제23조의 민감정보에 해당합니다.

실무 함의는 두 가지입니다. 72시간 안에 "어떤 항목이, 몇 명분, 어떤 경로로"를 답하려면 범위 확정에 쓸 로그가 미리 있어야 하고, 유출이 확정되기 전에도 통지 판단이 필요할 수 있으므로 사고 초기부터 개인정보 보호 책임자를 대응 체계에 넣어 둡니다. NIST AI 600-1도 로그, 변경 관리 기록, 버전 이력이 사고 정보 공유를 돕는다고 설명합니다.

깊이 읽기

증거 보존과 개인정보의 균형

조사에는 원문이 필요하고 개인정보 보호는 원문을 줄이라고 하므로, 저장소를 나눕니다. 기본 감사 로그는 가림 처리한 구조화 필드로 길게 보관하고, 원문은 별도의 증거 저장소에 짧게, 접근 승인을 거쳐서만 열람하게 둡니다. 사고가 선언되면 해당 기간의 원문을 증거 저장소에 동결하고, 수집·열람·인계 기록을 남깁니다. 분석은 원본이 아니라 사본으로 하고, 사본에도 무결성 확인값을 붙입니다.

시스템마다 시계가 다르면 사건 순서를 재구성할 수 없으므로 시각을 한 기준으로 맞추고 추적 식별자로 이벤트를 잇습니다. 조사 중에 원문을 메신저나 티켓에 붙여 넣어 2차 노출을 만들지 않도록 조사 채널의 규칙도 정해 둡니다.

메모리·색인·캐시 오염의 복구

에이전트 사고에서 원인을 제거해도 오염은 남을 수 있습니다. 오염된 문서는 색인에, 숨은 지시에서 비롯된 "선호"는 장기 메모리에, 오염된 답은 응답 캐시에 남습니다. 복구는 다음 순서로 생각합니다. 먼저 오염원의 쓰기를 멈춥니다. 다음으로 오염 기간과 경로를 기준으로 영향받은 메모리 항목, 색인 조각, 캐시 항목을 찾습니다. 출처 정보가 저장되어 있으면 이 단계가 쉬워집니다. 찾은 항목은 먼저 검색 대상에서 빼 격리한 뒤 지우고, 색인은 신뢰할 수 있는 원본에서 필요한 범위만큼 다시 만듭니다. 오염 기간에 발급되거나 노출된 자격 증명은 교체합니다. 마지막으로 같은 오염을 재현하는 시나리오로 회귀 평가를 돌린 뒤 쓰기를 다시 엽니다.

1장의 질문, "오염되었을 때 어떻게 지우는가"에 답이 없는 저장소는 이 단계에서 통째로 버려야 할 수도 있습니다. 메모리와 색인에 출처와 작성 시각을 남기는 설계가 복구 비용을 크게 줄입니다.

실무 장면

한마음치과네트워크: 디버그 로그가 유출 통로였다

치과 병원 네트워크 '한마음치과네트워크'의 예약·상담 챗봇을 정기 점검하던 담당자는 석 달 전 품질 조사용으로 켠 디버그 로깅이 그대로 켜져 있고, 대화 원문 전체가 외부 로그 분석 서비스로 전송되고 있음을 발견했다. 대화에는 환자의 이름, 연락처, 통증 부위와 치료 이력이 들어 있었다. 그 로그 서비스의 프로젝트에는 외주 개발사 직원을 포함해 스무 명 가까운 계정이 접근할 수 있었다.

담당자는 먼저 차단했다. 디버그 로깅을 끄고, 외부 전송을 멈추고, 프로젝트 접근 권한을 최소 인원으로 줄였다. 이어서 전송 기간, 전송된 대화 수와 고유 환자 수를 세고, 로그 서비스의 접근 기록으로 그 기간에 누가 로그를 열람했는지 확인했다. 외부의 불법 접근 흔적은 없었지만, 업무상 필요 없는 사람들이 민감한 진료 정보에 닿을 수 있는 상태였다.

개인정보 보호 책임자와 법무팀이 같은 날 합류했다. 치료 이력은 민감정보에 해당할 수 있고, 시행령상 민감정보 유출은 인원과 관계없이 신고 대상이 될 수 있었다. 법무팀은 통지와 신고가 필요한지를 검토해 72시간 안에 결론을 냈고, 그 판단에는 담당자가 정리한 기간, 항목, 인원, 열람 기록이 그대로 쓰였다.

원인 제거로 기본 로그는 가림 처리한 구조화 필드(추적 식별자, 도구 이름, 판정, 토큰 수)만 남기고, 원문이 필요하면 승인을 받아 제한된 내부 저장소에 최대 2주만 보관하게 했다. 디버그 설정에는 만료일을 두었고, 외부로 나가는 데이터는 분기마다 검토한다. 회고에는 "로그도 민감 데이터이며, 임시 설정은 반드시 만료일을 가진다"를 남겼다.

파도미디어: 공격자 없이 일어난 지갑 고갈

콘텐츠 회사 '파도미디어'는 기사 초안을 만들 때 자료 조사 에이전트를 쓴다. 에이전트는 외부 자료 검색 커넥터로 자료를 모으고, 하위 에이전트에게 요약을 나누어 맡긴다. 어느 화요일 새벽, 월 예산의 40%가 여섯 시간 만에 쓰였다는 경보가 떴다. 경보는 메일로만 갔고, 아침 출근 전까지 아무도 보지 못했다.

당직자가 로그를 보니 공격의 흔적은 없었다. 전날 밤 검색 커넥터가 업데이트되며 응답 형식이 바뀌었고, 에이전트는 응답을 해석하지 못하자 "검색 실패"로 판단해 재시도했다. 재시도마다 하위 에이전트를 새로 띄워 요약을 다시 맡겼고, 하위 에이전트도 같은 커넥터를 불러 실패하고 재시도했다. 작업 하나가 수백 번의 모델 호출로 불어났다.

차단은 두 단계였다. 커넥터 연결을 끄고, 진행 중인 조사 작업을 모두 취소했다. 취소 버튼이 실제로 하위 에이전트까지 멈추는지 확인하는 데 시간이 걸렸는데, 일부 하위 작업은 부모 작업이 취소된 뒤에도 계속 돌았다. 팀은 이것을 별도 결함으로 기록했다.

재발 방지책은 경보를 차단으로 바꾸는 데 집중했다. 작업 하나에 모델 호출 수, 하위 에이전트 수, 재시도 횟수, 비용의 상한을 두었고, 재시도 간격은 점점 늘리고, 같은 도구 오류가 연속 다섯 번 나오면 그 호출을 막는 회로 차단기를 넣었다. 부모 작업을 취소하면 하위 작업도 함께 멈추게 고쳤다. 커넥터는 버전을 고정하고 응답 형식 비교와 회귀 시험을 통과한 업데이트만 반영한다. 조직 일일 예산에 닿으면 조사 기능을 읽기 전용 요약 모드로 낮춘다. 회고에는 "악의가 없어도 무제한 소비는 일어난다", "아무도 보지 않는 시간에는 경보가 아니라 상한이 일한다"를 적었다.

자주 틀리는 지점

1. "싼 모델로 바꾸면 비용 공격이 해결된다." 단가가 내려가도 요청이 무제한이면 비용은 계속 늘어납니다. 원인은 상한 없는 소비입니다.
2. "비용 경보를 설정했으니 지갑 고갈은 막힌다." 경보는 사람에게 알릴 뿐입니다. 아무도 보지 않는 시간에는 코드가 멈추는 상한이 필요합니다.
3. "인기 많은 모델이니 검증된 것이다." 다운로드 수나 벤치마크 점수는 무결성의 증거가 아닙니다. 출처, 서명, 해시, 내 용도의 평가로 확인합니다.
4. "모델 ID를 고정했으니 동작은 절대 바뀌지 않는다." 가중치가 고정되어도 서빙 인프라 변경으로 동작이 조금 달라질 수 있고, 모델은 결국 은퇴합니다. 회귀 평가를 주기적으로 돌립니다.
5. "로그는 많이 남길수록 좋다." 로그도 민감 데이터입니다. 무엇을 남기고, 무엇을 가리고, 얼마나 보관하고, 누가 열람하는지 정해야 합니다.
6. "원인을 다 밝힌 뒤 차단하자." 진행 중인 피해가 있으면 차단이 먼저입니다. 원인 확인은 재개 전에 끝냅니다.
7. "키를 바꾸려면 서비스를 재시작하면 된다." 재시작은 도난당한 자격 증명을 폐기하지 않습니다. 폐기와 재발급이 따로 필요합니다.

한눈에 정리

시험 전날 다음 문장을 하나씩 소리 내어 확인하세요.

• 감사 로그는 언제·어디서·누가·무엇을, 그리고 입력 출처, 도구 호출, 승인, 판정, 버전을 추적 식별자로 잇는다.
• 로그에서 토큰·비밀번호·키·접속 문자열·민감 개인정보를 빼거나 가리고, 위·변조와 열람을 통제한다.
• 남용 추적은 해시한 사용자 식별자와 가드레일 판정 기록으로 한다.
• 무제한 소비에는 공격자가 없을 수도 있다. 재시도·분기·위임 고리가 비용을 키운다.
• 경보는 알리고, 상한은 멈춘다. 작업 단위 예산과 회로 차단기를 둔다.
• 모델 파일은 출처·서명·해시를 확인하고, 실행 코드가 들어갈 수 있는 형식은 격리해서 다룬다.
• 도구·MCP 서버는 버전을 고정하고, 업데이트 때 설명·매개변수·범위의 변화를 검토한다.
• 사고 대응의 뼈대는 여섯 단계이고, 피해가 진행 중이면 범위를 다 밝히기 전에 먼저 끊는다. 재개는 원인을 고치고 회귀 시험을 통과한 뒤다.
• 차단 스위치는 도구·연결·기능·모드·작업 단위로 준비하고 실제로 눌러 본다.
• 개인정보 유출이 의심되면 72시간 기준의 통지·신고 판단을 위해 개인정보 보호 책임자를 초기에 부른다.

공식 문서로 확인하기

• OWASP LLM10:2025 Unbounded Consumption: 하위 위험과 완화 전략.
• OWASP LLM03:2025 Supply Chain: 공급망 위험과 AI BOM.
• OWASP Logging Cheat Sheet: 기록할 것, 뺄 것, 로그 보호.
• OpenAI — Safety best practices: safety_identifier, 키 폐기, 신고 경로.
• Hugging Face — Pickle Scanning: pickle 파일의 코드 실행 위험.
• Anthropic — Model deprecations: 모델 수명주기와 은퇴 통지.
• NIST SP 800-61 Rev. 3: CSF 2.0에 맞춘 사고 대응 권고.
• 개인정보 보호법: 제34조 유출등의 통지·신고(시행령 제39조·제40조와 함께).

셀프 체크

5-1. OWASP Logging Cheat Sheet 기준으로 로그에서 제거하거나 가려야 할 데이터 네 가지를 쓰고, 그 대신 조사를 위해 남길 수 있는 정보를 하나 들라.

5-2. 비용 경보와 예산 상한의 차이를 설명하고, 에이전트 작업 하나에 걸 수 있는 상한 두 가지를 쓰라.

5-3. OWASP LLM10의 하위 위험 가운데 "지속적 입력 넘침"과 "자원 집약적 질의"를 구분해 설명하고, 각각에 맞는 통제를 하나씩 들라.

5-4. 모델 ID를 고정해 두어도 같은 프롬프트에 대한 동작이 달라질 수 있는 이유를 Anthropic 문서의 설명에 근거해 쓰고, 운영팀이 할 일을 하나 들라.

5-5. 로컬 MCP 서버를 원클릭으로 추가하게 하는 클라이언트가 MCP 보안 모범 사례에 따라 반드시 해야 할 일 두 가지와 권장되는 실행 환경을 쓰라.

5-6. 개인정보 보호법 시행령 제40조가 정한 신고 대상 세 가지와 신고 기한을 쓰라.

5-7. 설계 과제: 장기 메모리 기능이 있는 상담 에이전트의 사고 대응 런북에 넣을 차단 스위치 네 가지를 설계하라. 스위치마다 무엇을 끄는지, 누가 끌 수 있는지, 끄면 무엇이 멈추는지를 적어라.

실습 과제