300개 기업 데이터를 다루는 행 단위 보안(RLS)의 실체

PAR Technology는 독립 운영점부터 대형 프랜차이즈 그룹까지 300개 이상의 레스토랑 비즈니스를 지원하며, 이들이 보유한 데이터의 가치를 극대화하는 분석 도구를 제공한다. 이 시스템은 멀티테넌트(Multi-tenant, 하나의 소프트웨어 인스턴스가 여러 고객사를 동시에 지원하는 환경) 구조로 운영되기에, 사용자마다 접근 가능한 데이터 범위를 엄격히 제한하는 행 단위 보안(RLS, Row-Level Security)이 필수적이다. RLS는 사용자의 권한에 따라 데이터베이스의 특정 행에만 접근하도록 제한하는 보안 방식이다. 동일한 데이터베이스에 동일한 질문을 던져도 사용자 권한에 따라 결과값은 완전히 달라야 한다. 예를 들어 시카고에서 매장 2곳을 운영하는 가맹점주가 지난주 총 매출을 물으면 84,000달러라는 답을 얻어야 하지만, 전국 200개 매장을 관리하는 브랜드 매니저가 같은 질문을 하면 920만 달러라는 결과가 나와야 한다. 가맹점주에게 전국 매출 수치를 보여주는 것은 데이터 거버넌스 실패이며, 상업적으로 민감한 타 운영자의 정보를 노출하는 보안 사고가 된다. 따라서 모든 쿼리는 사용자별 권한 범위 내에서만 정확한 데이터를 반환하도록 설계되어야 한다.

결정론적 격리를 위한 3계층 보안 아키텍처

PAR Technology는 모델의 확률적 행동에 의존하지 않고 아키텍처 수준에서 데이터를 격리하는 3계층 보안 구조를 구축했다. 첫 번째 층은 AWS SigV4(AWS 서비스 요청 시 사용하는 암호화 서명 방식)를 통한 요청 서명 단계다. 모든 API 요청에는 Tenant ID, Business ID, Admin ID라는 세 가지 식별 값이 포함되며, 이를 통해 요청자의 신원을 암호학적으로 증명하고 위조를 방지한다. 두 번째 층은 Amazon Bedrock(AWS의 파운데이션 모델 관리 서비스)을 통한 시맨틱 검증 단계다. 모델이 생성한 쿼리의 의도가 요청자의 권한 범위 내에 있는지 의미론적으로 검토하여 비정상적인 데이터 접근 시도를 차단한다. 마지막 세 번째 층은 Split-Plane SQL(쿼리 생성과 권한 필터링을 분리하여 처리하는 방식)을 통한 프로그래밍적 데이터 격리다. LLM이 SQL 쿼리를 생성하더라도 실제 데이터베이스에 전달되기 전, 시스템이 식별 값을 기반으로 권한 필터를 강제로 결합해 데이터 경계를 확정한다. 이 구조는 모델이 SQL을 어떻게 생성했는지와 관계없이, 최종적으로 추출되는 데이터의 범위를 인프라 수준에서 결정론적으로 제어한다.

기존 방식과 달라진 지점

초기 버전인 V1 구조는 사용자 질문을 Amazon Bedrock으로 전달하고, 여기서 Claude Sonnet 4 모델인 `anthropic.claude-sonnet-4-20250514-v1:0`가 질문의 의도를 해석해 Databricks 데이터 웨어하우스용 SQL을 생성하는 방식이었다. 이 방식은 개념 증명 단계에서 대부분의 질문을 정확히 해석하고 적절한 테이블을 선택하며 분석 도구로서의 가능성을 입증했다. 하지만 프로덕션 환경으로 전환하며 PAR Technology는 모델의 생성 능력에 보안을 맡기는 대신 아키텍처 레벨에서 데이터 경계를 강제하는 제로 트러스트(Zero Trust, 아무도 믿지 않고 항상 검증하는 보안 모델)를 적용했다. V1이 분석적 성능은 확인했으나 기업용 멀티테넌트 환경의 컴플라이언스 요구사항을 충족하지 못한 점을 개선한 결과다. 모델이 SQL을 어떻게 생성하든 관계없이, 시스템 외부에서 결정론적으로 데이터 접근 권한을 제어하는 구조로 전환하여 모델의 확률적 특성으로 인한 보안 취약점을 제거했다.

확률적 생성 엔진을 보안 정책 엔진으로 쓸 수 없는 이유

LLM은 입력값이 같아도 출력이 달라질 수 있는 비결정적(Non-deterministic) 특성을 가진 확률적 생성기다. 이는 정해진 규칙에 따라 예외 없이 작동해야 하는 보안 정책 엔진과는 정반대의 성질이다. 실제 운영 환경에서 LLM에 비즈니스 ID 필터를 적용하라는 지침을 프롬프트로 전달했을 때의 위험성은 수치적 확률로 드러난다. 모델이 10,000번의 쿼리에서 비즈니스 ID 필터를 정확하게 적용했더라도, 10,001번째 쿼리에서 이를 누락할 가능성이 상존한다. 프롬프트의 모호함은 이러한 데이터 유출 위험을 가속한다. 사용자가 질문을 모호하게 던졌을 때, 모델은 이를 해석하는 과정에서 임의로 쿼리 범위를 확장하여 답을 찾으려는 경향이 있다. 이 과정에서 모델이 스스로 판단한 쿼리 범위가 실제 사용자의 데이터 접근 권한을 초과하게 되면, 설계자가 의도하지 않은 타 사업자의 데이터 영역까지 접근하는 결과가 초래된다. 결국 보안 경계는 모델의 추론 능력이나 행동에 의존해서는 안 되며, 모델 외부에서 권한을 검증하고 필터링하는 제로 트러스트 체계를 구축해야 한다.

한국 B2B SaaS 및 엔터프라이즈 LLM 에이전트 도입 시 시사점

엔터프라이즈 환경에서 텍스트-투-SQL(Text-to-SQL) 구현 시 모델이 생성한 쿼리를 그대로 실행하지 않고, 이후 단계에서 사용자 식별자를 강제로 결합하는 분리 구조를 설계해야 한다. 인프라 구축 시에는 AWS 공유 책임 모델(Shared Responsibility Model)을 명확히 적용하여, 기업은 애플리케이션 계층에서 데이터 격리 로직을 직접 구현하고 관리해야 한다. 최종적인 컴플라이언스 검증을 위해 인증된 사용자 ID, 요청 타임스탬프, 생성된 쿼리의 상세 내용을 기록하는 감사 로그(Audit Logging) 체계를 구축해야 한다. 단순한 결과 반환을 넘어 어떤 사용자가 어떤 권한으로 어떤 데이터에 접근했는지 기록하는 과정은 엔터프라이즈 LLM 에이전트 도입의 필수 조건이다. 이러한 결정론적 격리와 기록 체계를 통해 비로소 LLM 분석 도구를 실제 운영 환경에 배치하여 데이터 거버넌스를 유지할 수 있다. 기업용 에이전트를 설계할 때 모델의 지능에 의존하는 프롬프트 엔지니어링은 데이터 유출을 막는 근본적인 해결책이 되지 못한다. 지금 바로 구축 중인 아키텍처가 AWS SigV4 서명과 시맨틱 검증, 그리고 SQL 데이터 격리라는 3계층 방어선을 갖추고 있는지 확인하는 것부터가 데이터 거버넌스의 시작이다.