제12장 — 접근 제어와 신원

LLM Primer VII: AI 보안의 챕터별 워크스루 열두 번째 글입니다. 조합적 질문에 답하는 장 — 누가 LLM 통합 애플리케이션의 어떤 능력을 호출할 수 있으며, 그 강제가 시스템 컴포넌트 전반에 어떻게 구조화되는가.

이 장이 존재하는 이유

전통적 접근 제어 규율은 모두 LLM 시스템에 적용됩니다: 주체를 인증, 요청을 정책에 대해 인가, 테넌트 격리, 주체별 소비 제한, 엔터프라이즈 거버넌스 오버레이 노출. 메커니즘은 필드가 수십 년간 사용해 온 것들 — OAuth 2.0, mTLS, RBAC, ABAC, 토큰 버킷, SAML, SCIM — 입니다. 새로운 것은 모델 호출 자체가 주체가 될 수 있다는 것 — 사용자를 대행하는 에이전트는 자체 신원과 자체 권한을 지니며 — 그리고 테넌트별 모델 행동 구성이 멀티테넌트 LLM 플랫폼의 일급 제품 기능이라는 것입니다.

12.1 인증과 인가는 추가와 함께 이식된다

인증은 자격 증명을 확인합니다. API 키는 가장 단순한 메커니즘 — 프로비저닝 시 주체에게 넘겨지고, 자격 데이터베이스에 해싱되고, 모든 요청 헤더에 제시되는 고엔트로피 문자열 — 입니다. 구현과 사용이 쉬우며, 로그·CI 출력·커밋된 저장소를 통해 유출되기도 쉽습니다. OAuth 2.0 베어러 토큰은 수명이 짧은 토큰과 범위 제한으로 상황을 개선하며, OAuth 2.1 초안은 지난 십 년의 보안 모범 사례를 통합합니다. mTLS는 머신 간 호출에 상호 인증을 더하며, 내부 LLM 서비스에 특히 유용합니다. 인가는 인증된 주체가 무엇을 할 수 있는지를 묻습니다. RBAC — 역할, 권한, 할당 — 는 인구가 안정된 그룹으로 나뉠 때 작동합니다. ABAC — 속성 기반 접근 제어 — 는 주체·자원·맥락 속성에 대한 술어를 평가하며 RBAC가 다루지 않는 경우를 처리합니다: 자원의 소유자, 요청의 시간이나 위치, 시스템 내 관계에 의존하는 권한. 둘은 상호 배타적이지 않습니다. 프로덕션 시스템은 흔히 조합해 씁니다. 대략적 접근에는 RBAC, 구체적 조건에는 ABAC. 제10장의 정책 엔진 — OPA, Cedar — 이 ABAC를 스케일에서 유지 가능하게 만드는 방식입니다.

12.2 멀티테넌트 격리는 심층 방어 문제다

멀티테넌트 시스템은 단일 배포로 여러 고객을 서비스합니다. 격리 요구 사항은 어떤 실패 모드에서도 어떤 테넌트도 다른 테넌트의 데이터·요청·모델 상호작용을 볼 수 없다는 것입니다. 세 가지 아키텍처 접근이 스펙트럼 위에 있습니다. 데이터베이스 수준 격리 — 테넌트당 별개 데이터베이스 — 는 가장 강력하지만 운영 비용이 가장 큽니다. 스키마 수준 격리 — 공유 인프라 위 테넌트당 별개 PostgreSQL 스키마나 MySQL 데이터베이스 — 는 중간 지점입니다. 행 수준 격리 — 공유 스키마, 모든 행에 테넌트 ID, 데이터베이스 강제 행 수준 보안 — 는 가장 저렴하지만 규율 있는 애플리케이션 코드가 필요합니다. LLM 시스템에서 격리는 검색 코퍼스(테넌트별 벡터 데이터베이스 네임스페이스), 프롬프트 구성 로직(테넌트 간 이어 붙이기 금지), 로그 스토어(테넌트 간 읽기 금지), 그리고 테넌트별 데이터로 파인튜닝될 때 모델 자체로 확장됩니다. 속도 제한과 할당량은 자원 소비 축을 더합니다. 토큰 버킷은 정의된 용량까지의 짧은 버스트를 허용하고, 슬라이딩 윈도우는 더 높은 계산 비용으로 더 균일한 속도를 강제하며, 리키 버킷은 하류 속도를 부드럽게 합니다. LLM 시스템에서 속도 제한 차원은 확장됩니다: 초당 요청, 분당 토큰, 일당 비용, 시간당 도구 호출, 초당 임베딩. 각 차원은 고유의 경제적·보안적 정당성을 지니며, 엔터프라이즈 티어는 대개 여러 차원에 걸쳐 구분합니다.

12.3 엔터프라이즈 거버넌스가 시스템을 사용 가능하게 하는 오버레이다

엔터프라이즈 고객은 인증과 속도 제한을 넘어서는 거버넌스 요구를 가집니다. 그들은 어느 직원이 시스템을 사용하며, 어느 데이터에, 어느 목적으로 사용하는지 알아야 합니다. 내부 컴플라이언스와 외부 감사에 충분한 감사 로그가 필요합니다. 어느 모델이 허용되고, 어느 도구가 사용 가능하고, 어느 콘텐츠 범주가 허용되는지에 대한 통제가 필요합니다. 데이터 처리 약속 — 학습 사용, 암호화, 거주지, 보존, 삭제 — 이 필요합니다. 표준이 된 기능은 이 요구를 반영합니다. SAML이나 OpenID Connect를 통한 싱글 사인온은 엔터프라이즈 신원 공급자를 누가 시스템을 사용할 수 있는지의 진리의 원천으로 만듭니다. SCIM 프로비저닝은 사용자 변경을 자동으로 전파합니다. 감사 로그 내보내기는 LLM 시스템의 텔레메트리를 엔터프라이즈 SIEM으로 보냅니다. 데이터 거주지 약속은 테넌트 데이터가 지정된 관할을 떠나지 않음을 보장합니다. 고객 관리 암호화 키는 엔터프라이즈가 제공자와 독립적으로 로테이션하거나 해지할 수 있게 합니다. 사설 배포 옵션은 LLM 서비스를 엔터프라이즈 자체 클라우드 계정으로 옮깁니다. 이 각 기능은 구현만이 아니라 운영되어야 할 거버넌스 표면입니다. 엔터프라이즈 거버넌스 오버레이가 멀티테넌트 LLM 플랫폼을 규제 산업이 도입할 수 있는 것으로 바꿉니다.

제12장이 준비하는 것

파트 IV는 LLM 보안의 시스템 수준 차원을 발전시켰습니다: 아키텍처 경계(제10장), 관측 가능성과 사건 대응(제11장), 신원과 접근 통제(제12장). 다루는 방식은 메커니즘 우선이었고, 방어 가능한 기술적 태세를 제공합니다. 제13장은 파트 V를 기술적 핵심에서 규제 경계로 나아가며 엽니다. EU AI 법은 대부분의 고위험 범주에 대해 2026년 8월부터 전면 시행되며, 가장 결과적으로 중요한 단일 도구지만, 미국 연방 태세(EO 14110에서 EO 14179로의 전환 이후 진화 중), 주 수준 법(콜로라도, 캘리포니아, 뉴욕시 등), AI 시스템에 적용되는 GDPR, 그리고 싱가포르·일본·한국·인도 등에서 등장 중인 프레임워크가 함께 컴플라이언스 표면을 단일이 아니라 복수로 만듭니다. 이 장은 이 규제들이 실용적 관점에서 요구하는 것과, 제3·10·11·12장의 통제가 그 요구에 어떻게 매핑되는지 살핍니다.

다음 → 제13장: 규제 지형. EU AI 법의 단계적 적용, AI 시스템에 대한 GDPR, 감사 가능성, 모델 카드, 그리고 규제 아키텍처를 구조화하는 위험 분류 프레임워크.