AI 안경은 왜 '클라우드'가 필요할까
AI 안경(AI glasses)은 요즘 가장 뜨거운 웨어러블 폼팩터예요. 그런데 여기엔 근본적인 딜레마가 있어요.
- 폼팩터의 한계: 안경 다리 안에 들어갈 수 있는 연산 자원은 한계가 명확해요. 실시간 번역, 대화 요약, 장기 기억(long-term recall) 같은 기능은 로컬 NPU로 감당이 안 됩니다.
- 상태 기반(Stateful) 요구사항: 진짜 쓸모 있는 AI 비서는 며칠~몇 주에 걸친 맥락을 기억해야 해요. 이건 결국 클라우드에 저장하고 불러와야 한다는 뜻이죠.
- 프라이버시 역설: 개인 맥락을 다 알고 있는 AI를 만들려면, 그 개인 맥락을 클라우드 사업자가 '못 보게' 만들어야 합니다.
전통적인 클라우드 아키텍처는 이 문제를 풀도록 설계된 적이 없어요. 데이터를 at rest(디스크) 와 in transit(네트워크) 에서는 암호화하지만, in use(메모리 상에서 연산 중) 상태에서는 어쩔 수 없이 복호화해야 하거든요. 이 순간 하이퍼바이저, 호스트 OS, 인프라 운영자가 다 볼 수 있게 됩니다.
Meta가 이 문제를 푼 방식이 바로 Private Processing입니다. 근거자료는 Meta Engineering 블로그에서 확인할 수 있어요.
개인적인 생각인데, 이 글은 단순 제품 홍보가 아니라 '기밀 컴퓨팅을 실제 프로덕션에 어떻게 얹는가'에 대한 아키텍처 레퍼런스로 읽는 게 훨씬 값어치가 있어요. 국내에서도 규제 산업(금융/의료) 쪽에서 이 패턴을 참고할 만합니다.
핵심 개념 3종 세트: Confidential Computing / TEE / Private Processing
먼저 용어 정리부터 갑니다. 이 세 개를 구분 못 하면 뒤에 나오는 아키텍처가 안 읽혀요.
1) Confidential Computing — 패러다임
데이터의 세 가지 상태 중 유일하게 남아 있던 구멍, in use 를 막자는 업계 전체의 움직임이에요.
| 상태 | 기존 보호 | 기밀 컴퓨팅 |
|---|---|---|
| At rest (디스크) | 암호화 O | 암호화 O |
| In transit (네트워크) | TLS O | TLS O |
| In use (메모리) | 평문 노출 | CVM으로 격리 |
2) TEE (Trusted Execution Environment) — 하드웨어 프리미티브
CPU/GPU 칩 안의 전용 보안 하드웨어가 CVM(Confidential VM)의 메모리를 자체 키로 암호화합니다. 이 키는 호스트 OS, 하이퍼바이저, 운영자 누구에게도 릴리스되지 않아요. CPU와 GPU 양쪽으로 확장되기 때문에, 두 연산 대상을 오가는 워크로드도 신뢰 경계 안에 머뭅니다.
CCC(Confidential Computing Consortium)가 정의한 TEE의 3대 보장:
- Data Confidentiality: CVM 밖에서는 메모리 내용을 못 읽음
- Data Integrity: CVM 밖에서는 데이터를 추가/삭제/변조 못 함
- Code Integrity: 로드된 코드는 아무도 못 바꿈
3) Private Processing — Meta의 구현체
TEE 위에 얹은 Meta의 인프라로, 하드웨어 보장 위에 non-targetability 와 encrypted storage 를 추가합니다.
# 원격 증명(Remote Attestation) 흐름을 의사코드로 표현
# 실제 구현은 C++/Rust 기반이지만 개념 이해용으로 파이썬으로 옮겨봤어요.
def establish_secure_session(device, gateway):
# 1. 게이트웨이가 CVM/TEE 노드를 선택 (사용자 식별 불가 휴리스틱 기반)
tee_node = gateway.select_tee_node(non_identifiable_heuristics=True)
# 2. RA-TLS 핸드셰이크 시작: 하드웨어 서명 인증서 요구
attestation_report = tee_node.request_hardware_signed_cert()
# 3. 서명 체인이 칩 벤더 루트 키까지 이어지는지 검증
if not verify_chain(attestation_report, root_key=VENDOR_ROOT_KEY):
raise ConnectionRefused("attestation chain broken")
# 4. CVM 이미지 해시가 공개 투명성 원장(append-only ledger)과 일치하는지 대조
if attestation_report.binary_hash != public_ledger.lookup(tee_node.image_id):
raise ConnectionRefused("binary hash mismatch")
# 5. 두 검증 모두 통과해야 TLS 세션 성립. 실패 시 fail-closed.
return tee_node.open_tls_session()
포인트는 fail-closed 예요. 검증이 하나라도 실패하면 데이터를 아예 안 보냅니다. "일단 보내고 나중에 확인" 같은 낙관적 처리는 여기서 통하지 않아요.
5가지 엔지니어링 요구사항과 실제 동작 흐름
Meta가 AI 글래스용 Private Processing을 설계할 때 세운 요구사항은 이렇습니다.
- Hardware Isolation: 전송/연산/저장 모든 상태에서 호스트 OS·하이퍼바이저·Meta조차 데이터를 못 읽음
- Fail-Closed Guarantees: 보장이 깨지면 시스템이 죽거나, 공개 원장을 통해 발각 가능해야 함
- Public Verifiability: 프로덕션의 모든 CVM 이미지는 append-only 공개 원장에 등록
- Non-Targetability: 특정 사용자 세션만 골라서 공격하는 게 불가능해야 함
- Encrypted Storage: 저장 데이터는 사용자 제공 키로만 접근 가능
실제 요청 흐름 (4단계)
① 신원 분리 (Non-targetable Routing) 글래스에서 요청이 나가기 전에 메타데이터 문제부터 해결합니다. 블라인드 서명 토큰(blind-signed token)을 무작위 주기로 발급받아, 인증 서비스가 요청을 계정에 연결하지 못하게 해요. 이어서 Fastly/Cloudflare 같은 서드파티 OHTTP 릴레이를 경유해 TEE 노드에 도달합니다.
② 원격 증명 (Remote Attestation) 글래스가 먼저 서버를 검증합니다. RA-TLS 세션을 열고 하드웨어 서명 인증서를 요구한 뒤, 바이너리 해시를 공개 원장과 대조해요. 실패하면 핸드셰이크 자체가 안 됩니다.
③ 처리 (Execution) TLS로 암호화된 블롭을 라우팅하지만 인프라는 내용을 못 읽어요. TEE 내부에서만 모델이 동작하고, 모델 간 통신도 RA-TLS로 상호 증명 후에만 데이터를 넘깁니다.
④ 상태 기억 (Encrypted Storage) 영속 메모리가 필요하면 TEE를 나가기 전에 사용자 키로 암호화됩니다. Meta 인프라는 암호문만 보관하고, 조회 시 사용자 키로 TEE가 복호화해서 처리합니다.
스토리지를 TEE 안으로 옮긴 이유
"그냥 클라우드 DB에 암호화해서 저장하면 안 되나?" 싶죠. 두 가지 이유로 안 됩니다.
- 접근 패턴이 행동을 누출: 내용이 암호화돼도 언제/얼마나/무엇을 함께 읽는지는 DB가 다 봐요. 이 메타데이터만으로 일상 루틴이 그려집니다.
- 원격 암호문 질의는 확장 불가: 시맨틱 벡터 검색 같은 연산을 하려면 대용량 암호문을 네트워크로 끌어와 TEE에서 복호화해야 해요. 컨텍스트가 커질수록 레이턴시가 폭발합니다.
그래서 실행과 상태를 프로세서 암호화 메모리 안에 co-locate 시켰습니다. 쿼리 엔진이 TEE 경계 안에서 돌기 때문에 읽기가 외부 네트워크를 넘지 않아요.
운영 관측성(Observability)이라는 역설
TEE는 운영자를 암호학적으로 배제합니다. 그런데 장애 대응은 어떻게 할까요?
- 실행 중 TEE에 디버거를 붙일 수 없음
- 크래시 시 메모리 스택 덤프, 모델 입출력 로깅 불가
- 특정 페이로드 검사 불가
그래서 관측 계층을 완전히 out-of-band 로 설계했습니다. CPU 사용률, 메모리 할당, 네트워크 레이턴시, 집계된 하드웨어 장애율 같은 신호만으로 서비스 헬스를 유지해요. 사용자 데이터 바이트 하나도 노출하지 않으면서요.
실무 팁: 이 패턴은 사내 규제 대응 시스템에도 그대로 이식 가능합니다. "로그를 못 남기는데 어떻게 디버깅하지?"라는 질문에 대한 정답지가 여기 있어요. 집계 지표 + 분산 트레이싱의 메타데이터만으로 SLO를 관리하는 방식입니다.
검증 가능한 투명성, 그리고 에이전트 시대의 토대
Binary Transparency
프로덕션에 배포된 모든 CVM 이미지는 append-only 공개 원장에 등록됩니다. 다른 바이너리를 몰래 배포하면 클라이언트와 외부 모니터가 불일치를 발견할 수 있어요. 이건 tamper-evidence(변조 증거)를 확보하는 장치입니다. 원장과 측정값은 공개되고, 대응 바이너리는 보안 프로그램 참여 연구자에게 제공됩니다.
서드파티 검증
이 설계는 자사 데이터센터 내부를 적대적 환경으로 가정합니다. 기존 클라우드 보안이 경계를 외곽에 두고 하이퍼바이저/호스트 OS/운영자를 신뢰했다면, Private Processing은 그 경계를 안쪽으로 밀어 넣고 셋 다 바깥에 둡니다. NCC Group 같은 독립 보안 업체와 협업해 설계 감사, 증명 로직 리뷰, 격리 모델 경계 테스트를 진행하고, 버그 바운티 프로그램도 Private Processing을 명시적으로 포함하도록 확장했습니다.
이 기술의 한계와 주의사항
솔직히 짚고 넘어갈 부분이 있어요.
- 성능 오버헤드: TEE 내부 연산은 네이티브 대비 오버헤드가 발생합니다. 대규모 배치 처리보다는 개인화된 저지연 추론에 최적화된 구조예요.
- 생태계 종속: 특정 벤더의 TEE 구현에 의존하면 멀티클라우드 이식성이 떨어집니다. 벤더 락인 리스크는 항상 따라다녀요.
- 원장의 신뢰 가정: "공개 원장"이 정말 독립적으로 운영되는지는 별개의 신뢰 문제입니다. 원장 운영 주체가 단일하면 투명성 주장이 약해져요.
- 부채널 공격: TEE 자체도 사이드채널 공격(Spectre류)에서 자유롭지 않습니다. 하드웨어 벤더의 마이크로코드 패치에 의존해야 해요.
한국 개발 생태계에서의 적용 맥락
국내에서는 개인정보보호법·신용정보법 때문에 금융/의료/공공 클라우드에서 "연산 중 데이터 노출"이 곧 컴플라이언스 이슈가 됩니다. 지금까지는 망분리나 물리적 격리로 퉁쳤는데, 기밀 컴퓨팅은 그 대안이 될 수 있어요. 다만 국내 CSP들의 TEE 지원 성숙도와 감사 체계는 아직 걸음마 단계라, 실제 도입 시 원격 증명 체인과 원장 검증 절차를 자체적으로 문서화해두는 게 안전합니다.
다음 단계 학습 방향
- CCC(Confidential Computing Consortium) 스펙 문서 정독 — TEE의 형식 정의부터
- RA-TLS 핸드셰이크 구현체 직접 뜯어보기 (Open Enclave, Intel SGX SDK 등)
- OHTTP / 익명 자격증명(Privacy Pass) 흐름 이해 — non-targetability의 핵심
- 에이전트 간 CVM 통신(inter-CVM attestation) — 앞으로 멀티 에이전트 시스템에서 필수 지식이 됩니다
AI 글래스는 앞으로 더 stateful해지고, 멀티모달해지고, 에이전트화됩니다. 신뢰 경계는 더 복잡해지겠지만, 이 글에서 다룬 프리미티브는 그대로 재사용될 거예요. 결국 "데이터를 누가 볼 수 있는가"를 하드웨어 수준에서 강제하는 게 답이라는 겁니다.
함께 보면 좋은 글
- 파이썬 3.15 미리보기: 새로운 프로파일러와 UTF-8 기본 인코딩 도입 — 언어 런타임 레벨의 변화가 어떻게 시스템 설계에 영향을 주는지
- NVIDIA TensorRT Edge-LLM: 자율주행과 휴머노이드 로봇을 위한 엣지 AI 런타임 완전 분석 — 엣지에서의 추론 최적화, 그리고 클라우드 오프로딩의 경계선