🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

PAR는 다중 테넌트 식당 데이터 분석에서 LLM이 보안 경계를 직접 집행하게 두지 않고, 요청 인증·의도 검증·SQL 단계의 데이터 격리를 분리한 3계층 구조로 행 수준 보안을 설계했다.

📌 핵심 요약

• PAR는 300개 이상의 식당 비즈니스를 지원하는 환경에서, 비전문 사용자가 자연어로 질문하고 신뢰할 수 있는 데이터 기반 답을 받을 수 있는 text-to-SQL 분석 에이전트를 구축하려 했다.
• 핵심 문제는 같은 질문이라도 사용자 권한과 조직 구조에 따라 접근 가능한 행이 달라진다는 점이었다. 예를 들어 프랜차이즈 소유자와 본사 브랜드 매니저는 동일한 매출 질문에 대해 서로 다른 범위의 정답을 받아야 한다.
• 초기 접근처럼 LLM에게 사용자 비즈니스 ID 필터를 프롬프트로 지시하는 방식은 보안 경계로 충분하지 않다. LLM은 비결정적 생성 시스템이므로 필터 누락, 잘못된 값 생성, 범위 확대 해석이 발생할 수 있다.
• PAR는 테넌트, 비즈니스, 관리자 ID를 모든 요청의 식별 기반으로 삼고, 각 조합이 허용된 데이터만 반환되도록 아키텍처 수준에서 결정론적 통제를 설계했다.
• 운영 구조는 요청 서명, 의미 검증, Split-Plane SQL 기반 데이터 격리라는 세 계층으로 구성되며, 각 계층은 독립적으로 작동해 LLM이 조작되거나 우회되더라도 교차 테넌트 데이터 노출 위험을 줄이도록 설계되었다.

🧩 주요 포인트

1. PAR는 300개 이상의 식당 비즈니스를 지원하는 환경에서, 비전문 사용자가 자연어로 질문하고 신뢰할 수 있는 데이터 기반 답을 받을 수 있는 text-to-SQL 분석 에이전트를 구축하려 했다.
2. 핵심 문제는 같은 질문이라도 사용자 권한과 조직 구조에 따라 접근 가능한 행이 달라진다는 점이었다. 예를 들어 프랜차이즈 소유자와 본사 브랜드 매니저는 동일한 매출 질문에 대해 서로 다른 범위의 정답을 받아야 한다.
3. 초기 접근처럼 LLM에게 사용자 비즈니스 ID 필터를 프롬프트로 지시하는 방식은 보안 경계로 충분하지 않다. LLM은 비결정적 생성 시스템이므로 필터 누락, 잘못된 값 생성, 범위 확대 해석이 발생할 수 있다.
4. PAR는 테넌트, 비즈니스, 관리자 ID를 모든 요청의 식별 기반으로 삼고, 각 조합이 허용된 데이터만 반환되도록 아키텍처 수준에서 결정론적 통제를 설계했다.
5. 운영 구조는 요청 서명, 의미 검증, Split-Plane SQL 기반 데이터 격리라는 세 계층으로 구성되며, 각 계층은 독립적으로 작동해 LLM이 조작되거나 우회되더라도 교차 테넌트 데이터 노출 위험을 줄이도록 설계되었다.

🧠 상세 정리

1. PAR의 배경과 self-serve 분석 목표

PAR Technology Corporation은 독립 운영자부터 대규모 다중 브랜드 프랜차이즈 그룹까지 300개가 넘는 식당 비즈니스를 지원하는 기술 기업으로 소개된다. 이 고객층은 규모와 조직 구조가 다양하기 때문에, 같은 데이터 분석 기능이라도 사용자별 권한과 비즈니스 맥락이 크게 다르다. PAR가 만들고자 한 것은 기술 배경이 없는 비즈니스 사용자도 영어 자연어로 질문을 입력하면 몇 초 안에 데이터에 근거한 답을 받을 수 있는 self-serve 분석 에이전트였다. 겉으로는 자연어 질문을 SQL로 바꾸는 기능처럼 보이지만, 실제 과제는 정확한 SQL 생성만이 아니라 민감한 고객 데이터를 올바른 범위 안에서만 다루는 것이었다.

2. 다중 테넌트 환경에서의 핵심 난점

이 시스템의 본질적 문제는 데이터 접근, 정확성, 보안이 동시에 맞물린다는 데 있다. 수천 명의 사용자가 각기 다른 비즈니스, 데이터셋, 권한 경계에 연결되어 있고, 에이전트가 생성하는 모든 쿼리는 사용자가 볼 수 있는 데이터로만 제한되어야 한다. 즉 문제는 단순히 SQL을 생성하는 것이 아니라, 특정 사용자에게 맞는 SQL을 특정 데이터 조각에 대해 매번 정확하게 생성하고 실행하는 것이다. PAR는 이 요구사항을 행 수준 보안 문제로 규정하며, 전역 수치나 다른 테넌트의 수치가 섞이는 것을 허용할 수 없는 운영·컴플라이언스 요구로 설명한다.

3. 같은 질문, 다른 정답: 데이터 경계의 예시

원문은 “지난주 총매출은 얼마였나?”라는 동일한 질문을 두 사용자가 던지는 상황으로 데이터 경계 문제를 설명한다. 시카고에서 두 개 매장을 운영하는 프랜차이즈 소유자에게 올바른 답은 두 매장의 합산 매출인 8만 4천 달러다. 반면 전국 200개 지점을 감독하는 본사 브랜드 매니저에게 올바른 답은 전체 체인의 920만 달러다. 같은 질문과 같은 데이터베이스를 사용하더라도 권한 범위가 다르기 때문에 두 답은 모두 올바르며, 서로 뒤바뀌면 한쪽은 민감한 상업 정보를 노출하고 다른 한쪽은 불완전한 정보로 전국 단위 의사결정을 하게 된다.

4. LLM을 보안 집행자로 신뢰할 수 없는 이유

PAR의 초기 직감은 많은 LLM 애플리케이션 팀과 비슷하게, 모델에게 적절한 필터를 적용하라고 지시하는 것이었다. 예를 들어 사용자 비즈니스 ID를 프롬프트에 넣고, 모델이 항상 그 범위로 쿼리를 제한하도록 요청하는 방식이다. 그러나 원문은 LLM이 강력한 추론 엔진이기는 하지만 결정론적 정책 엔진이 아니라 확률적 생성기라고 지적한다. 모델이 수만 번 필터를 올바르게 적용하더라도 다음 한 번에 조용히 누락할 수 있고, 필터 값을 환각하거나 모호한 질문을 넓게 해석해 접근해서는 안 되는 데이터까지 포함할 수 있다. 소비자 애플리케이션에서는 이런 비결정성이 불편함에 그칠 수 있지만, 민감한 비즈니스 데이터를 다루는 다중 테넌트 분석 시스템에서는 보안 경계로 충분하지 않다.

5. 목표: 모델 바깥의 결정론적 보안 경계

PAR가 설정한 목표는 비즈니스 사용자가 신뢰할 만큼 강력하면서도, 엔지니어링 및 컴플라이언스 팀이 받아들일 수 있는 보안 통제를 갖춘 분석 솔루션을 만드는 것이었다. 중요한 점은 데이터 경계가 모델의 선의나 지시 이행 여부에 의존하지 않고, 아키텍처 수준에서 결정론적으로 강제되어야 한다는 것이다. 즉 모델이 어떤 SQL을 생성하든, 또는 프롬프트 조작과 세션 침해 같은 상황이 발생하더라도 사용자가 허가받은 범위를 넘어설 수 없어야 한다. 이 관점에서 LLM은 보안 구조의 위에 있는 최종 권한자가 아니라, 통제된 경계 안에서 동작하는 구성 요소로 배치된다.

6. 초기 v1 구조와 프로덕션 전환의 한계

초기 분석 에이전트는 사용자가 자연어 질문을 입력하면 Amazon Bedrock의 Claude Sonnet 4 모델이 의도를 해석하고 Databricks 데이터 웨어하우스에 대한 SQL을 생성한 뒤, 쿼리 결과를 자연어 응답으로 돌려주는 단순한 흐름이었다. 개념 검증 단계에서는 모델이 대부분의 질문을 잘 해석하고 적절한 테이블을 고르며 정확한 SQL을 생성했기 때문에 유망해 보였다. 그러나 실제 고객 데이터와 수백 개 비즈니스, 수천 명 사용자를 대상으로 프로덕션을 준비하면서 질문이 달라졌다. 사용자가 모호하게 묻거나, 세션이 침해되거나, 권한 밖 데이터를 요구하도록 프롬프트를 조작하거나, 모델이 필터 적용을 잊는 상황을 고려하면 v1은 분석적으로는 가능성이 있지만 엔터프라이즈 다중 테넌트 환경에는 취약했다.

7. 고객 계층 구조와 요청 식별 값

원문은 PAR의 고객 구조를 테넌트, 비즈니스, 관리자라는 세 단계로 설명한다. 테넌트는 브랜드 그룹이나 프랜차이즈 본사 같은 최상위 조직이고, 비즈니스는 그 아래의 특정 식당 체인이나 콘셉트이며, 관리자는 실제로 분석 에이전트에 로그인해 사용하는 개인 사용자다. 한 브랜드 매니저는 비즈니스 전체 200개 지점에 접근할 수 있지만, 한 프랜차이즈 소유자는 자신이 운영하는 두 개 지점만 볼 수 있다. 따라서 모든 API 요청은 Tenant ID, Business ID, Admin ID라는 세 식별 값을 포함하며, 모든 쿼리 결과는 이 조합이 허용받은 데이터로만 정확히 제한되어야 한다. 이 구조 때문에 행 수준 보안은 부가 기능이 아니라 시스템의 기반 요구사항이 된다.

8. 운영 보안 기반과 서비스 구성 요소

PAR는 보안 책임을 클라우드 자체의 보안과 클라우드 안에서의 보안으로 구분해 설명한다. AWS가 Amazon Bedrock 등 서비스 인프라의 보안을 담당하는 반면, PAR는 3계층 보안 아키텍처, 식별과 접근 제어, 애플리케이션 및 데이터베이스 계층의 데이터 격리를 구현한다. 민감 데이터는 저장 중과 전송 중 암호화되도록 설계되고, Databricks 데이터 웨어하우스는 저장 데이터 암호화를 사용하며 API 통신은 TLS 1.3을 사용한다. AWS KMS의 자동 키 회전, 감사 로그, IAM 역할 기반 임시 자격 증명, 장기 액세스 키 미사용도 함께 언급된다. 시스템 구성 요소로는 의도 검증을 맡는 추론 엔진, 관련 스키마를 고르는 스키마 라우터, Databricks 호환 SQL을 만드는 SQL 생성기, 쿼리를 실행하는 Databricks 클러스터, 그리고 라우팅과 세션 관리를 담당하는 Flask API 계층이 제시된다.

9. 3계층 보안 아키텍처의 역할

프로덕션 구조의 핵심은 요청 파이프라인의 서로 다른 지점에서 독립적으로 작동하는 세 보안 계층이다. 첫 번째 계층은 API 진입점에서 모든 호출을 암호학적으로 서명해 누가 요청하는지 확인하는 무결성 보호 요청이다. 두 번째 계층은 인증 이후 데이터 접근 전 단계에서 질문이 지원 가능한 명확한 지표에 대응하는지 검증하고, 모호하거나 지원되지 않으면 SQL 생성으로 진행하지 않고 설명을 요청하는 의미 검증이다. 세 번째 계층은 SQL 생성 단계에서 Split-Plane SQL 구조를 통해 모델이 접근할 수 있는 데이터를 통제하고, 데이터베이스 계층에서 엄격한 행 수준 보안을 강제하는 프로그램적 데이터 격리다. 원문은 Layer 1이나 Layer 2가 우회되더라도 Layer 3이 여전히 행 수준 보안을 집행하도록 설계되었다는 점을 강조한다.

🧾 핵심 주장 / 시사점

• LLM 기반 분석 시스템에서 가장 중요한 보안 원칙은 모델에게 정책 준수를 부탁하는 것이 아니라, 모델이 생성한 결과가 통과해야 하는 결정론적 경계를 별도로 두는 것이다.
• 동일한 자연어 질문이라도 사용자 권한에 따라 정답의 범위가 달라질 수 있으므로, text-to-SQL의 정확성은 SQL 문법이나 집계 로직뿐 아니라 행 수준 접근 범위까지 포함해 평가되어야 한다.
• 다중 테넌트 환경에서는 인증, 의도 검증, 데이터 격리를 하나의 방어선으로 묶지 않고 독립 계층으로 나누는 설계가 교차 테넌트 노출 위험을 줄이는 핵심 접근이다.

✅ 액션 아이템

• 요청 서명, 의미 검증, Split-Plane SQL의 3계층을 분리해 LLM 조작 가능성에 강한 행 수준 보안 기본선을 결정론적으로 정한다.
• 텍스트-투-SQL 경로에서 테넌트·비즈니스·관리자 ID를 단일 식별 조합으로 묶어 동일 질문이라도 역할별 허용 행 범위를 명시적으로 고정한다.
• 초기 설계부터 SQL 실행 계층에서 권한 필터를 강제하고, 동일 쿼리라도 권한별 결과 차이가 재현되는지 자동 테스트 시나리오로 검증한다.

❓ 열린 질문

• 요청 서명·의미 검증·Split-Plane SQL 중 어떤 계층에서 위반을 가장 먼저 차단해야 교차 테넌트 노출 가능성을 최소화할 수 있을까?
• 가맹점 소유자와 본사 브랜드 매니저가 같은 매출 질의를 날렸을 때, 허용 행 집합이 예상대로 분리되는지 어떤 테스트 데이터셋으로 비교할 것인가?
• LLM이 필터 누락이나 범위 확대를 생성하더라도 SQL 계층이 항상 허용된 행만 반환한다는 보장을 어떻게 수학적으로/절차적으로 입증할 수 있을까?