안전한 Serving

첫 단계는 제품 이름이나 firewall 규칙을 고르는 일이 아니라 보호할 자원과 행위자를 적는 것입니다. 사용자 입력, system prompt, model weight, adapter, retrieval 문서, tool credential, 생성 결과, audit record 가운데 무엇이 기밀이고 누가 읽거나 바꿀 수 있는지 표로 만듭니다. 외부 사용자, 운영자, application gateway, model server, vector store, tool runner와 관측 저장소를 서로 다른 주체로 놓고 요청·응답·검색 문서·credential·telemetry가 이동하는 화살표를 그립니다. 그래야 “로컬이라 안전하다” 같은 막연한 표현을 실제 접근 정책으로 바꿀 수 있습니다.

NIST SP 800-207의 핵심은 LAN이나 자산 소유만으로 암묵적 신뢰를 주지 않고 자원에 session을 만들기 전에 주체와 device의 인증·인가를 따로 수행하는 것입니다. localhost에서 한 사람이 쓰는 실험은 공격 표면이 작지만, 0.0.0.0 bind나 port forwarding, reverse proxy를 통해 다른 host가 접근하는 순간 새로운 trust boundary가 생깁니다. 같은 사무실 Wi-Fi에 있다는 사실은 직무, tenant, 문서 권한이나 tool 실행 권한의 증명이 아닙니다. 접속 위치와 자원별 authorization을 구분해야 합니다.

Model server는 generation을 수행하는 component이지 사용자 계정, tenant 문서 권한, rate plan과 감사 정책을 모두 책임지는 security gateway가 아닙니다. vLLM·llama.cpp·Ollama가 HTTP API를 제공한다는 사실과 그 endpoint가 불특정 사용자에게 바로 공개해도 된다는 결론은 다릅니다. 외부 요청은 TLS를 끝내고 identity를 확인하며 요청 크기·schema·quota를 적용하는 gateway를 먼저 지나게 합니다. Model server는 별도 network segment나 host에서 gateway workload만 접근하도록 제한하고 관리 endpoint와 inference endpoint도 나눕니다.

Threat model에는 정상 흐름뿐 아니라 실패와 오용을 넣습니다. 도난 token 재사용, 다른 tenant 문서 검색, prompt injection이 tool call로 이어지는 경우, 거대한 context와 반복 요청으로 queue가 고갈되는 경우, debug log가 prompt 원문과 credential을 남기는 경우, 잘못된 model artifact가 승격되는 경우를 구체적인 misuse case로 씁니다. 각 항목마다 예방 control, 탐지 signal, 즉시 containment, 복구 artifact와 owner를 연결합니다. “보안 강화”가 아니라 어떤 attack을 어느 단계에서 막고 놓쳤을 때 어디서 알아채는지 답할 수 있어야 합니다.

예를 들어 인사 규정 Q&A는 employee와 HR reviewer를 구분하고 문서 ACL을 retrieval 전에 강제합니다. 사용자는 gateway session으로 들어오고 gateway가 tenant·role을 vector query filter와 tool policy에 전달합니다. Model server에는 사용자 credential 대신 짧은 수명의 workload credential만 보냅니다. 응답은 citation과 source authorization을 검사한 뒤 나가며 audit에는 원문 대신 request ID, 주체·resource decision, model·prompt digest와 정책 결과를 남깁니다. 이 구조와 자산 목록, data classification, owner가 첫 번째 capstone 산출물입니다.

Authentication은 요청자가 누구인지 확인하고 authorization은 그 주체가 지금 이 자원에서 이 action을 해도 되는지 결정합니다. 로그인에 성공했다는 이유로 모든 model, document collection과 tool을 허용하면 인증은 있어도 인가가 없는 서비스입니다. User, service workload와 operator identity를 나누고 subject·tenant·role·resource·action·context를 입력으로 policy decision을 만듭니다. Deny를 기본값으로 두고 관리자 endpoint, model 관리, document ingest, 일반 inference와 외부 side effect를 서로 다른 permission으로 분리합니다.

RFC 9700은 OAuth 보안 관행으로 token replay 완화, access token privilege 제한, 가능한 client authentication과 end-to-end TLS를 다룹니다. 실제 구현은 배포 환경에 맞춰야 하지만 장기 bearer token 하나를 모든 client와 service에 복사하는 패턴은 피해야 합니다. Token의 audience와 scope를 좁히고 만료를 짧게 두며 refresh credential을 더 엄격히 보호합니다. Authorization server metadata와 검증 library를 사용하고 issuer, audience, signature, expiry와 필요한 claim을 gateway에서 모두 검증합니다.

Browser에 넣은 secret, mobile package에 포함한 API key와 frontend JavaScript의 environment variable은 사용자가 추출할 수 있습니다. 공개 client에는 숨길 수 없는 값만 두고 privileged credential은 backend나 secret manager에서 service identity에 따라 주입합니다. Repository, image layer, prompt, query parameter와 exception message에 secret이 섞이지 않도록 pre-commit·build·runtime 검사를 둡니다. 회전은 새 credential 발급, 이중 허용 기간, consumer 전환, 기존 credential 폐기와 실패 확인까지 실행해야 완료됩니다.

TLS는 구간 도청과 변조를 줄이지만 잘못된 사용자의 정상 암호화 요청까지 막아주지는 않습니다. 반대로 인증 token이 있어도 평문 구간에 노출되면 탈취될 수 있습니다. Client→gateway와 gateway→resource 사이의 TLS, certificate 검증, proxy가 전달하는 identity header의 위조 방지, 내부 service identity를 함께 점검합니다. 외부에서 임의로 보낸 X-User 헤더를 신뢰하거나 TLS 종료 뒤 모든 내부 traffic을 신뢰하면 경계가 gateway에서 사라집니다.

Authorization 증거는 “로그인 화면이 보인다”가 아닙니다. 정상 사용자, 만료·변조 token, 다른 tenant, scope 부족, 퇴사자와 operator action을 자동 test로 실행하고 예상 HTTP status와 deny reason을 기록합니다. Direct model port와 관리 endpoint로 gateway를 우회할 수 없는지도 별도로 probe합니다. Audit에는 민감 token 자체가 아니라 hashed subject 또는 승인된 pseudonymous ID, resource, policy version, decision과 correlation ID를 남겨 누가 무엇을 허용·거부받았는지 재구성합니다.

Prompt injection은 공격자가 직접 입력하거나 검색 문서·웹 페이지·tool result에 숨긴 지시가 원래 정책과 충돌하도록 만드는 문제입니다. “이전 지시를 무시하지 마”라는 system prompt 한 줄은 모든 우회 표현을 막는 security boundary가 아닙니다. Trusted instruction과 untrusted data를 구조적으로 구분하고 retrieved text가 authorization, identity나 tool permission을 바꾸지 못하게 합니다. Input detector는 보조 signal로 쓰되 통과 결과를 안전 보증으로 간주하지 않습니다.

OWASP의 Excessive Agency 설명처럼 피해는 model 오류 자체보다 과도한 기능·권한·자율성에서 커집니다. Agent가 업무에 필요하지 않은 delete·send·payment tool을 보지 못하게 제거하고, 필요한 tool도 narrow typed function과 resource allowlist로 감쌉니다. 읽기와 쓰기, 초안과 외부 전송을 분리하며 되돌리기 어려운 action은 실행 직전 대상·변경 내용을 사용자에게 보여 주고 새 승인을 받습니다. Model이 만든 tool argument는 신뢰하지 않고 server가 schema·range·tenant ownership을 다시 검증합니다.

민감정보 유출은 training memory만의 문제가 아닙니다. System prompt, RAG document, tool response, 이전 대화, trace와 error에 들어온 개인정보·비밀이 output이나 관측 저장소로 나갈 수 있습니다. Retrieval은 post-filter가 아니라 query 단계부터 ACL과 tenant filter를 적용하고 cache key에도 authorization context를 포함합니다. Output에는 허용된 source만 인용됐는지 검사하고 민감 pattern을 탐지하되 detector의 false negative를 고려해 애초에 model context에 불필요한 비밀을 넣지 않습니다.

LLM serving은 input 길이, output 길이와 동시 request가 KV cache·compute time·비용을 크게 바꾸므로 요청 수 하나만 제한해서는 부족합니다. User·tenant별 request rate와 token budget, context·output 상한, active sequence, queue length, deadline과 일일 비용을 함께 둡니다. Queue가 찼을 때 무한 대기보다 명시적 rejection과 retry-after를 돌려주고 client disconnect·timeout 뒤 generation이 실제 취소되는지 측정합니다. OWASP가 말하는 unbounded consumption에는 DoS뿐 아니라 비용 소진과 model behavior 추출도 포함됩니다.

예를 들어 128K context를 허용하는 model이라도 모든 사용자에게 128K를 기본 허용하지 않습니다. 실제 업무의 99번째 input 길이가 12K라면 16K 정책부터 시작하고 예외는 별도 role과 budget으로 승인합니다. Concurrency를 1, 2, 4, 8로 올리며 queue, p95 첫 token, inter-token latency, error와 VRAM을 기록해 SLO를 지키는 safe envelope를 찾습니다. 긴 요청 flood, streaming 중단, malformed JSON, prompt injection과 cross-tenant document ID를 attack set으로 보존해 release마다 반복합니다.

관측의 목적은 데이터를 많이 저장하는 것이 아니라 사용자 영향과 원인을 재구성하는 것입니다. Request count·error·rejection, TTFT·inter-token·end-to-end latency, input·output token, queue wait, active sequence, GPU memory·utilization과 model·prompt·policy digest를 release ID로 연결합니다. Gateway, retrieval, model과 tool span을 correlation ID로 잇고 error.type과 stage를 구조화하면 느림이 queue인지 검색인지 generation인지 구분할 수 있습니다. OpenTelemetry semantic convention은 span·metric·log·event에 공통 의미를 부여하는 출발점이며 환경에 맞춘 privacy 검토가 추가로 필요합니다.

평균 latency는 소수의 매우 느린 사용자를 숨깁니다. p50·p95·p99와 timeout·cancel을 length·tenant·model·status slice로 봅니다. 여러 replica의 latency를 합쳐야 한다면 bucket 설계와 aggregation을 고려합니다. Prometheus 문서가 설명하듯 client summary의 계산된 quantile은 일반적으로 replica 사이에서 그대로 평균 내어 전체 quantile로 만들 수 없지만 histogram observation은 server 쪽에서 window와 quantile을 계산하고 집계할 수 있습니다. Bucket은 실제 SLO 경계와 관측 분포에 맞춰 정하고 cardinality가 큰 raw user ID를 label로 쓰지 않습니다.

Prompt 원문을 모두 남기면 debugging은 쉬워 보이지만 개인정보, 계약 문서와 credential을 새 저장소로 복제합니다. 기본 telemetry는 길이, status, model·template digest, policy decision과 pseudonymous correlation으로 최소화합니다. 실제 content가 꼭 필요한 sampled debugging은 명시적 목적·권한·가림·암호화·보존 기간·삭제 검증을 둡니다. Trace export 실패나 dashboard 권한 오류도 incident가 될 수 있으므로 observability backend를 production data의 일부로 threat model에 포함합니다.

NIST SP 800-61 Rev.3은 incident response를 별도 비상 문서가 아니라 조직의 risk management 전반에 통합해 준비, incident 감소와 탐지·대응·복구 효율을 높이는 방향을 제시합니다. Serving runbook에는 alert trigger, severity, on-call과 의사결정자, containment 명령, credential revoke, evidence 보존, 사용자 통지 판단, restore와 종료 기준을 둡니다. OOM, data exposure, unauthorized tool action, poisoned artifact와 availability attack은 containment와 복구가 다르므로 scenario별 절차가 필요합니다.

Tabletop만으로 끝내지 않고 staging이나 제한 환경에서 failure를 주입합니다. Expired token flood, 다른 tenant document 접근, 긴 request burst, model process crash와 잘못된 candidate를 실행해 alert가 목표 시간 안에 울리고 담당자가 올바른 dashboard와 runbook을 찾는지 봅니다. Traffic 차단·key revoke·queue drain·previous bundle restore 뒤 normal·attack·performance set이 회복되는지 확인합니다. 실제 시간, 누락된 telemetry, 사람이 헷갈린 단계와 개선 owner를 incident evidence로 남깁니다.

Capstone의 시작은 “LLM chatbot 만들기”가 아니라 제한된 업무 계약입니다. 사용자와 owner, 정상 입력과 거부해야 할 입력, 허용 model·document·tool, latency·availability 목표, data classification과 보존 기간을 한 페이지에 씁니다. 예상 사용량과 실패 비용에 따라 gate를 정하며 모든 과목에 같은 고정 글자 수나 request 수를 복사하지 않습니다. 낮은 분산의 단순 분류와 여러 언어·긴 문서·rare security case가 섞인 서비스는 필요한 sample과 attack 범위가 다릅니다.

Release manifest에는 source commit, container·model·adapter·tokenizer·template·prompt·runtime·driver digest, gateway·policy·retrieval index·tool schema, secret reference version과 infrastructure config를 포함합니다. SLSA provenance와 SSDF의 원칙을 참고해 누가 어떤 source와 build process에서 artifact를 만들었는지 추적하고 signature·hash를 확인합니다. Latest tag나 이름만 남기면 incident 때 동일 binary와 policy를 다시 만들 수 없습니다. Secret 값 자체는 manifest가 아니라 관리 시스템의 version reference로 연결합니다.

시험은 네 묶음으로 나눕니다. 기능·품질 set은 실제 업무와 critical slice를 확인하고, authorization·injection·sensitive disclosure·resource abuse attack set은 deny와 containment를 확인합니다. Load set은 대표 length·arrival·burst에서 tail과 safe capacity를 측정하고, recovery set은 process·dependency·candidate failure에서 previous complete bundle의 회복을 봅니다. 각 case에는 stable ID, source, precondition, expected policy·output·final state, actual identity·timestamp와 raw evidence 위치를 둡니다.

Offline gate를 통과하면 shadow에서 candidate output과 action을 사용자에게 노출하지 않은 채 actual identity·latency·policy decision을 확인하고, 대표 slice의 제한 canary로 넘어갑니다. Canary에는 owner, 최대 traffic, 관측 창, stop condition과 자동 또는 수동 rollback 권한을 명시합니다. Security critical, cross-tenant, secret exposure, tool final state, p95·error·queue와 비용 가운데 하나라도 독립 기준을 실패하면 평균 품질이 좋아도 확대하지 않습니다. Previous bundle restore는 문서가 아니라 실제 실행 결과가 필요합니다.

최종 제출물은 architecture·data-flow diagram, threat register, policy와 secret lifecycle, reproducible manifest, test raw result, dashboard·alert, incident runbook·exercise, backup/restore와 승인 record입니다. Known limitation, risk acceptance의 범위·만료, 재평가 trigger와 운영 owner를 적습니다. 교육 화면의 gate 통과는 입력값의 논리 확인일 뿐 실제 보안이나 배포 승인을 증명하지 않습니다. 독립 reviewer와 초보 학습자가 문서만 보고 같은 test와 rollback을 재현할 수 있을 때 capstone이 완성됩니다.