클라우드 기반 멀티테넌트 LLM 분석 서비스는 여러 고객의 데이터를 하나의 환경에서 처리하기 때문에, 단일 테넌트 환경보다 훨씬 정교한 보안 설계가 요구된다. AWS ML Blog에 따르면 PAR사는 자사 분석 에이전트를 Amazon Bedrock과 AWS의 표준 인증 체계 위에 올려, 위변조 요청과 프롬프트 인젝션, 그리고 데이터 유출을 동시에 방어할 수 있는 3계층 분리 아키텍처를 구현했다. 본문에서는 이 사례를 토대로 각 계층의 실제 역할, 구현 시 주의할 지점, 그리고 한국 기업이 참고할 만한 시사점을 정리한다.
- 3계층 분리 구조로 요청 인증, 시맨틱 검증, 데이터 격리를 독립 수행하여 단일 계층 침해 시에도 데이터 노출을 차단한다.
- AWS SigV4 기반 1계층에서 테넌트 컨텍스트가 요청 단위까지 암호학적으로 묶여 위변조와 재전송 공격을 방어한다.
- Split-Plane SQL 기반 3계층은 LLM이 조작되더라도 테넌트별 행만 반환하도록 강제해 최종 데이터 경계를 보장한다.
결국 LLM 에이전트 보안은 모델 자체 신뢰보다 인증·검증·격리라는 3개 독립 계층을 어떻게 결합하느냐에 따라 결정된다.
들어가며 멀티테넌트 LLM 서비스의 보안 과제
하나의 LLM 에이전트를 여러 고객이 공유하는 멀티테넌트 구조에서는 전통적인 단일 사용자형 SaaS와 달리 프롬프트 인젝션이나 컨텍스트 오염 같은 모델 특유의 위협까지 고려해야 한다. AWS ML Blog에 따르면 PAR사는 자사 분석 서비스를 Amazon Bedrock 위에서 운영하며, LLM이 의도하지 않은 출력을 생성하더라도 다른 테넌트의 데이터가 노출되지 않도록 설계했다. 일반적인 API 인증만으로 이러한 위험을 충분히 줄이지 못한다는 점에서, 행 수준 보안과 LLM 호출 경로를 함께 다시 설계한 사례가 주목을 끈다.
왜 행 수준 보안이 핵심인가
여러 테넌트의 데이터를 동일 데이터 웨어하우스에 저장하는 경우, SQL 쿼리에서 WHERE tenant_id = ? 같은 조건을 빠뜨리면 한 번의 오류로 대규모 유출이 발생할 수 있다. LLM이 자연어를 SQL로 변환하는 환경에서는 프롬프트 조작만으로 이러한 조건을 제거할 가능성이 있어, 애플리케이션 코드 의존도가 낮은 행 수준 보안 정책이 사실상 필수로 부상했다. AWS ML Blog에 게시된 PAR사 사례도 이러한 배경에서 출발한 것으로 분석된다.
3계층 보안 아키텍처 개요
PAR사가 도입한 아키텍처는 같은 흐름 안에서 인증, 의미 검증, 데이터 접근 제어를 각각 다른 메커니즘으로 처리한다. 아래 표는 각 계층이 담당하는 책임과 실패 지점을 요약한 것이다.
| 계층 | 주요 메커니즘 | 방어 대상 | 실패 시 영향 |
|---|---|---|---|
| 계층 1 | AWS SigV4 기반 요청 서명 | 요청 위변조, 재전송 공격 | 인증된 호출자만 다음 계층 도달 |
| 계층 2 | Amazon Bedrock 시맨틱 검증 | 프롬프트 인젝션, 의도 왜곡 | 의미적으로 위험한 호출 차단 |
| 계층 3 | Split-Plane SQL 데이터 격리 | 테넌트 간 데이터 노출 | 결과적으로 단일 테넌트 행만 반환 |
계층 1 SigV4 기반 요청 인증
1계층은 AWS SigV4 사양(AWS SigV4 사양)에 따라 모든 호출에 테넌트 식별자와 만료 시각을 포함한 서명을 부여한다. 호출이 게이트웨이에 도달하면 서버는 동일 방식으로 서명을 재계산해 비교하며, AWS 공식 문서에 따르면 이 방식은 클라이언트 시크릿이 노출되지 않은 상태에서도 요청 무결성을 보장한다. 테넌트 식별자는 서명 파생 값에 묶여 있어, 별도 헤더 값을 조작하는 방식의 변조를 차단할 수 있다.
계층 2 Bedrock 시맨틱 검증
2계층은 Amazon Bedrock(AWS ML Blog 원문)에서 호출 의미를 평가한다. 여기에는 시스템 프롬프트와의 정합성, 사용자 의도가 데이터 유출 시도로 보이는지 여부, 그리고 응답에 허용 범위를 넘은 컬럼이 포함되는지 등이 포함된다. AWS ML Blog에 따르면 이 계층은 단독으로 완벽하지 않지만, 1계층과 결합될 때 LLM이 잘못된 도구를 호출하기 전에 차단해 후속 위험을 줄이는 역할을 한다.
계층 3 Split-Plane SQL 데이터 격리
3계층은 SQL 실행 영역을 모델 영역과 분리하는 Split-Plane SQL 방식으로 동작한다. LLM이 생성한 쿼리 후보는 별도 검증기를 거치며, 여기에 테넌트 필터가 자동 삽입되어 최종 결과가 단일 테넌트 범위로 제한된다. AWS ML Blog에 따르면 이 구조는 LLM이 완전히 손상되거나 의도적으로 조작된 출력을 내더라도 데이터 노출 위험을 줄이도록 설계된 것으로 해석된다.
실제 구현 포인트 및 주의사항
3계층 구조는 개념은 단순하지만, 실제 구현에서는 인증 컨텍스트가 LLM 호출까지 끊기지 않고 전달되어야 효과가 발휘된다. 운영 단계에서 자주 논의되는 두 가지 포인트를 정리한다.
테넌트 컨텍스트 전파 방법
1계층에서 만들어진 테넌트 식별자는 게이트웨이, 리트리버, SQL 실행기까지 동일한 메타데이터로 전달되어야 한다. AWS ML Blog에 따르면 PAR사는 컨텍스트를 토큰 형태로 일관되게 부착하고, 각 단계에서 토큰을 다시 검증하는 방식을 채택한 것으로 보인다. 컨텍스트 전파가 끊기면 3계층의 행 수준 정책이 제대로 적용되지 않을 수 있으므로, 로깅과 추적 단계에서도 동일 키를 유지하는 것이 권고된다.
LLM 손상 시나리오 대응
모든 계층이 동시에 실패할 가능성은 낮지만, LLM 가중치 유출이나 미세 조정 오류로 2계층이 무력화되는 시나리오는 사전에 검토할 필요가 있다. AWS ML Blog에 따르면 PAR사는 3계층이 LLM 출력과 무관하게 항상 테넌트 필터를 강제하기 때문에, 모델 손상 시에도 다른 테넌트의 행이 반환되지 않는다고 설명한다. 다만 분석에 따르면, 이는 SQL 실행기 자체가 침해되지 않는다는 전제에서만 유효하므로, 데이터 영역에 대한 별도 감사 로그가 함께 필요하다.
아키텍처의 한계와 운영 고려사항
3계층 구조는 비용과 복잡도를 동시에 끌어올린다. SigV4 서명 검증과 Bedrock 호출, 그리고 Split-Plane SQL 변환이 직렬로 일어나 응답 지연이 증가할 수 있으며, 인증 키 관리와 모델 가드레일 운영도 별도 역량을 요구한다. 또한 시맨틱 검증은 새로운 공격 패턴에 따라 규칙을 지속적으로 갱신해야 하므로, 보안 팀과 ML 팀의 협업 체계가 갖춰지지 않으면 오히려 거짓 양성으로 정상 호출이 차단될 위험이 커진다. AWS ML Blog에서 강조한 핵심은 계층의 수가 아니라 각 계층의 독립성과 책임 경계의 명확함으로 해석된다.
맺으며 한국 기업 도입 시 시사점
국내 금융, 공공, 그리고 B2B SaaS 영역에서도 멀티테넌트 LLM 분석 수요가 빠르게 늘고 있다. 이러한 환경에서 AWS의 3계층 구조는 참고할 수 있는 하나의 청사진을 제공하며, 핵심은 인증·검증·격리를 단일 모델 신뢰에 맡기지 않고 각각 독립된 메커니즘으로 결합하는 데 있다. 기업은 자사의 규제 요건과 데이터 민감도에 맞춰 각 계층의 책임을 재조정하고, 감사 로그와 키 회전 정책을 명시적으로 문서화한 뒤 단계적으로 도입해야 할 것으로 판단된다. 결과적으로 LLM 에이전트의 보안은 모델 성능을 높이는 작업과 별개로, 다층 방어의 설계 성숙도를 함께 끌어올리는 작업이라 할 수 있다.
핵심 정리
- PAR사의 멀티테넌트 LLM 분석은 AWS SigV4, Amazon Bedrock 시맨틱 검증, Split-Plane SQL의 3계층으로 구성된다.
- 각 계층은 인증, 의미 검증, 데이터 격리를 독립적으로 담당하며 단일 침해 시에도 데이터 노출 위험을 줄인다.
- 테넌트 컨텍스트 전파, 운영 복잡도, 모델 손상 시나리오 대응이 도입 시 핵심 검토 항목이다.
- 국내 기업은 규제 요건과 데이터 민감도에 맞춰 계층 책임을 재조정하고 감사 로그 체계를 병행 구축할 필요가 있다.