private-ai-gateway 딥다이브
— 내 프롬프트를 서버 주인조차 못 보게 하는 TEE 기밀 추론 게이트웨이

Dstack-TEE/private-ai-gateway. AI에게 질문을 보낼 때 그 프롬프트와 답변을 서버를 운영하는 회사조차 들여다볼 수 없게 만드는 게이트웨이다. 핵심 아이디어는 추론을 TEE(신뢰 실행 환경)라는 하드웨어 금고 안에서 돌리고, "내 요청이 정말 진짜 금고 안에서 처리됐다"를 사용자가 수학적으로 검증할 수 있게 증명서(원격 증명)를 붙여 주는 것. OpenAI와 똑같은 API를 쓰면서도 프라이버시·검증가능성을 얹은, dstack(Phala Network) TEE 스택 위에 Rust로 짜인 신생 보안 인프라 프로젝트다. (저장소: Dstack-TEE/private-ai-gateway · 언어 Rust · ★14 · 라이선스 Apache-2.0 · 버전 0.1.0 개발자 프리뷰 · TrendShift 라이브 멘션 등재)

1프로젝트 한줄 요약

"AI 추론을 하드웨어 금고 안에서 돌리고, 그게 진짜 금고였다는 영수증까지 끊어 준다."

구체적으로 이 저장소는 ACI(Attested Confidential Inference, 증명된 기밀 추론)라는 개념의 개발자 프리뷰(0.1.0)다. 언어는 Rust이고, 약 1.9만 줄 규모다. 자체적으로 모델을 돌리는 게 아니라, 이미 TEE 안에서 도는 여러 추론 백엔드(Tinfoil·NEAR AI·Chutes·Phala 등) 앞에 서는 게이트웨이(중간 관문) 역할을 한다. 사용자의 요청을 받아, 뒤쪽 추론 제공자가 정말 검증된 TEE인지 먼저 확인하고, 검증에 실패하면 프롬프트를 아예 보내지 않는다(fail-closed).

이 문서가 주목하는 건 "또 하나의 AI 프록시"가 아니라 그 안의 보안 설계다. "신뢰를 어떻게 코드와 하드웨어로 증명하는가", "원격 증명이라는 게 실제로 어떤 바이트를 주고받는가", "키는 어디서 나오고 누가 보증하는가" — 기밀 컴퓨팅이라는, 앞으로 AI 프라이버시의 핵심이 될 분야를 실물 코드로 들여다보는 살아있는 교재다.

2왜 주목받는가

"AI 프라이버시 약속을, 신뢰가 아니라 검증으로 바꾼다 — 그것도 OpenAI API 그대로."

AI에게 민감한 걸 묻기가 점점 꺼려진다. 의료·법률·기업 기밀을 클라우드 LLM에 보내면 그 데이터가 어디로 가는지 알 수 없기 때문이다. 이 프로젝트가 회자되는 이유는, 그 불안을 기술로 정면 돌파하기 때문이다.

① 신뢰를 "검증 가능한 증거"로 바꾼다

대부분의 클라우드 AI는 "우리는 당신의 데이터를 학습에 쓰지 않습니다"라는 정책(약속)에 기댄다. 검증할 방법은 없다. 반면 이 게이트웨이는 GET /v1/attestation/report 한 번이면 "이 서버는 변조되지 않은 진짜 TEE이고, 응답에 서명한 키는 그 TEE가 보증한 것"임을 사용자가 직접 수학적으로 확인할 수 있다. 믿음의 자리에 증거가 들어선다.

② OpenAI 호환 — 갈아끼우기가 쉽다

완전히 새 SDK를 배울 필요가 없다. /v1/chat/completions·/v1/embeddings 등 OpenAI와 동일한 엔드포인트를 그대로 제공한다. 기존 앱은 주소(base URL)만 바꾸면 붙는다. 추가로 받는 건 응답 헤더의 x-receipt-id(영수증 번호) 하나뿐 — 검증을 원하는 사람만 그 영수증을 꺼내 보면 된다.

③ Fail-closed — 검증 안 되면 아예 안 보낸다

뒤쪽 추론 제공자가 검증되지 않거나 안전한 채널을 보장 못 하면, 게이트웨이는 프롬프트를 전송하지 않고 막아 버린다. "일단 보내고 보자"가 아니라 "확실하지 않으면 멈춘다"는 기본값이 안전(secure by default)인 설계다. 보안 시스템에서 가장 중요한 태도다.

④ 거물들의 생태계 — dstack / Phala

이 저장소는 혼자 떠 있는 게 아니라 dstack(TEE 위에서 도커 앱을 안전하게 돌리는 오케스트레이션 스택)과 Phala Network(기밀 컴퓨팅 클라우드) 생태계의 일부다. ACI라는 표준 초안(dstack#694)의 레퍼런스 구현 격이라, 단순 토이가 아니라 표준을 끌고 가는 성격이 있다.

경쟁 구도 한눈에

3기술 스택 전체 지도

"Rust 웹서버 한 채에, 암호학·하드웨어 증명·여러 추론 제공자 어댑터를 다 욱여넣었다."

이 게이트웨이는 순수 Rust 프로젝트다(약 1.9만 줄, 56개 소스 파일). 흔한 "프론트엔드/백엔드" 웹 구분과는 결이 다르다 — 한 Rust 바이너리 안에 HTTP 서버 · 암호학 · 하드웨어 증명 검증 · 제공자 어댑터가 레이어로 쌓여 있다. 아래는 그 레이어를 역할별로 정리한 지도다.

레이어별 기술 지도

주요 의존성(Cargo.toml에서 직접 확인)

4아키텍처 심화 분석 — 프롬프트가 금고를 거쳐 검증된 답이 되기까지

"내가 질문을 보내면, 그 한 줄이 TEE 금고 안을 거쳐 '증명서 붙은 답'으로 돌아오기까지 무슨 일이 벌어지나."

이 게이트웨이를 이해하는 가장 좋은 방법은 요청 한 건이 흐르는 길을 끝까지 따라가는 것이다. 먼저 전체 그림을 한 장으로 보자. (아래 구조도는 README의 다이어그램과 docs/frontend-middleware-backend.md를 코드 기준으로 재구성한 것이다.)

핵심은 게이트웨이 자체가 모델을 돌리지 않는다는 점이다. 게이트웨이는 TEE 안에 사는 검증 관문이고, 진짜 추론은 또 다른 TEE(상류)에서 일어난다. 게이트웨이의 일은 "양쪽 모두 진짜 금고인지 확인하고, 그 사실을 영수증으로 남기는 것"이다.

핵심 설계 1 — 원격 증명: "진짜 금고였다"를 증명하는 봉인 영수증

이 프로젝트의 심장은 원격 증명(remote attestation)이다. 사용자가 GET /v1/attestation/report를 부르면, 게이트웨이는 인텔 CPU가 하드웨어로 서명한 증거(TDX quote)를 돌려준다. 이 증거에는 "지금 도는 코드의 측정값(해시)", "워크로드 신원", "이 TEE가 보증한 공개키 묶음(keyset)"이 담겨 있다. 사용자는 이걸 로컬에서 검증해, 자기가 대화하는 상대가 변조되지 않은 바로 그 코드임을 확인한다.

핵심 설계 2 — 키는 dstack KMS에서, 신원에 묶인다

게이트웨이는 자기 키를 스스로 만들지 않는다. src/dstack.rs를 보면, dstack KMS에서 신원 키·영수증 서명 키·E2EE 키를 받아 온다. 중요한 건 KMS가 승인된 워크로드(검증된 코드)에만 키를 내준다는 것 — 즉 "이 키로 서명했다"는 곧 "승인된 TEE 안에서 서명했다"와 같은 뜻이 된다. 그래서 README가 "임시 키나 가짜 quote로 뜨는 모드는 아예 없다"고 강조한다. 모든 키와 증명서가 진짜 dstack 경로에서만 나온다.

핵심 설계 3 — Frontend / Middleware / Backend 삼분할

한 게이트웨이 프로세스 안이 세 역할로 나뉜다(docs/frontend-middleware-backend.md 기준).

왜 이렇게 갈랐나. 증명·검증 같은 신뢰의 핵심은 Frontend/Backend가 독점하고, 갈아끼우고 싶은 비즈니스 로직(과금·라우팅)은 Middleware로 빼서, 그 미들웨어가 검증을 위조하거나 우회할 수 없게 못 박은 것이다. Middleware는 평문을 보지만 "검증됐다"는 사실은 만들지 못한다 — 이 경계가 보안의 핵심이다.

흐름 한 줄기: 질문 한 발의 일생

위 부품들이 어떻게 맞물리는지, 미들웨어 없는 가장 단순한 경로('해피 패스')로 따라가 보자. (개념 단순화)

// "내 프롬프트가 검증된 TEE에서만 처리되게" 한 건의 내부 순서
① 사용자가 GET /v1/attestation/report?nonce=<난수> 호출
   → 게이트웨이가 TDX quote + keyset 반환 → 사용자가 로컬 검증
② 검증 통과 → POST /v1/chat/completions 전송 (TLS 또는 ACI E2EE)
③ Frontend: 외부 X-Private-AI-Gateway-* 헤더 제거, E2EE면 복호,
   요청 해시 기록, request_id 생성
④ Backend: 대상 라우트(model) 검증 → 상류 제공자 증명 확인/갱신
⑤ 채널 바인딩 강제(상류 TLS SPKI 또는 제공자 E2EE 키가 증명과 일치?)
⑥ 일치하면 상류로 전달 / 불일치·검증실패면 → 전송 차단(fail-closed)
⑦ 상류 TEE에서 추론 → 응답이 같은 길로 되돌아옴
⑧ Frontend: 응답 해시까지 본 뒤 receipt(영수증)에 서명, x-receipt-id 반환
⑨ 사용자가 GET /v1/aci/receipts/{id} 로 영수증을 꺼내
   "요청 해시·상류 검증·응답 해시·서명"을 최종 확인

여기서 배울 핵심은 "검증이 끝나야만 프롬프트가 흐른다"는 점이다. ⑥에서 보듯, 상류가 진짜 검증된 TEE라는 게 확인되지 않으면 프롬프트는 한 바이트도 나가지 않는다. 그리고 ⑧의 영수증은 요청·라우트·상류 검증·응답을 모두 해시로 묶어 서명하므로, 나중에 "내 요청이 정말 이 경로로 처리됐다"를 위조 불가능하게 증명한다.

5디렉토리 구조 해부

"폴더가 많아 보이지만, 사실 'src(엔진) + docs(설계·감사) + deploy(배포) + scripts(검증)'로 묶인다."

코드 대부분은 src/ 한 곳에 있고, 나머지는 문서·배포·테스트를 위한 보조 폴더다. README의 'Repository Map'을 코드 구조와 맞춰 풀면 이렇다.

주요 경로 한눈에

6학습 포인트 (기술별)

"이 한 채에 '기밀 컴퓨팅·원격 증명·E2EE·AI 게이트웨이 설계·dstack 배포'가 다 들어 있다."

AI에 관심 없어도, 보안·시스템 개발자라면 배울 게 가득하다. 분야별로 무엇을 배울지 + 작게 실습할 아이디어를 정리했다.

7하드웨어 / 시스템 요구사항

"진짜 보안 주장을 하려면 TEE 하드웨어가 꼭 필요하다 — 다만 코드 공부와 로컬 스모크는 평범한 PC로 충분하다."

이 프로젝트는 보안 주장의 뿌리가 하드웨어에 있어서, 요구사항이 일반 웹앱과 다르다. "진짜 운영 배포"와 "로컬 개발/공부"를 나눠서 봐야 한다.

진짜 운영 배포 (증명이 성립하는 환경)

로컬 개발 / 공부 (증명은 없지만 동작 확인 가능)

TEE 하드웨어가 없어도 코드를 읽고 빌드하고 모의 스모크를 돌릴 수 있다. 단, README가 강조하듯 이건 진짜 운영과 동등하지 않다 — 보안 주장은 못 하고, 동작과 흐름만 본다.

# 표준 로컬 점검 (Rust stable 툴체인 필요)
cargo test
cargo fmt --all -- --check
cargo clippy --all-targets -- -D warnings

# 신원만 띄우는 게이트웨이 (추론 라우트는 일부러 비움)
PRIVATE_AI_GATEWAY_CONFIG_PATH=/tmp/private-ai-gateway.config.json \
cargo run --release --bin private-ai-gateway

# 다른 터미널에서 신원 표면 확인
curl -sS 'http://127.0.0.1:8086/v1/attestation/report?nonce=test'

# 제공자 키 없이 추론 동작까지 보고 싶으면 — 모의 상류 2개로 스모크
scripts/local_multi_upstream_smoke.sh   # 라우팅·영수증·검증 이벤트·메트릭 자동 점검

복사해서 그대로 쳐도 된다(설정 JSON은 README의 Quick Start에 전문이 있다). 핵심은 하드웨어 없이도 흐름을 학습할 수 있되, dstack SDK 엔드포인트가 필요하다는 점 — 로컬에선 포워딩한 dstack 소켓을 dstack_endpoint에 지정한다. 스모크 스크립트엔 docker compose·curl·jq·cargo 등이 있어야 한다.

8직접 해볼 수 있는 실습 과제

"읽기만 하면 안 남는다 — 난이도별로 손을 움직여 보자. (대부분 TEE 하드웨어 없이 가능)"

9관련 기술 심화 학습 로드맵

"기밀 컴퓨팅은 처음엔 낯설다 — 개념 → 증명 → 암호 → 배포 순으로 4주 코스를 제안한다."

10핵심 키워드 사전

"이 분야의 영어·암호 용어를 한국어 뜻 + 일상 비유로 한 번에."

11참고 링크

"공식 저장소부터 TEE·dstack·Intel 문서까지 — 더 깊이 파고들 출발점."