AI 안경이 당신의 대화를 클라우드로 보내는 이유 — 그리고 아무도 못 읽게 만드는 법

왜 AI 안경은 클라우드로 도망갈 수밖에 없는가

AI 안경은 생각보다 좋은 폼팩터예요. 시야를 가리지 않고, 항상 몸에 붙어 있고, 사용자의 시선과 청각을 그대로 공유하니까요. 문제는 연산이에요. 통화 연결이나 문자 답장 정도는 온디바이스로 충분하지만, 실시간 번역이나 대화 요약, 며칠 전 맥락을 이어받는 개인화 응답은 안경 다리 안에 들어갈 수 있는 모델 크기로는 절대 안 됩니다.

그런데 컴퓨팅 파워만 문제가 아니에요. 진짜 유용한 비서가 되려면 상태(state)를 유지해야 하고, 며칠~몇 주에 걸친 맥락을 이어야 하고, 백그라운드에서 알아서 일을 처리해야 합니다. 이건 결국 클라우드에서 돌려야 한다는 뜻이에요.

여기서 근본적인 딜레마가 생깁니다.

"당신을 깊이 아는 초개인화 AI를, 프라이버시를 지키면서 어떻게 만들 것인가?"

전통적인 클라우드 아키텍처는 이 질문을 풀도록 설계된 게 아니에요. 데이터를 저장할 때(at rest)와 전송할 때(in transit)는 암호화하지만, 연산할 때(in use) 는 메모리에서 복호화된 상태로 존재해야 하니까요. 그 순간 하이퍼바이저, 호스트 OS, 인프라 운영자는 데이터를 볼 수 있습니다.

이 글은 Meta가 AI 안경을 위해 설계한 Private Processing — 기밀 컴퓨팅(Confidential Computing) 위에 세워진 인프라 — 의 엔지니어링 관점을 정리한 거예요. 근거자료는 Meta 엔지니어링 블로그에서 확인할 수 있어요.

핵심 개념 3종 세트: Confidential Computing, TEE, Private Processing

용어가 계속 나오니까 먼저 정리하고 갈게요.

1. Confidential Computing (패러다임)

데이터는 원래 세 가지 상태가 있어요.

기밀 컴퓨팅은 이 세 번째 상태를 닫는 산업 전반의 움직임이에요.

2. TEE (Trusted Execution Environment, 하드웨어 프리미티브)

TEE는 CPU/GPU에 내장된 하드웨어 기능이에요. 프로세서가 특수 VM(이걸 CVM, Confidential VM이라고 불러요)의 메모리를 칩 안의 전용 보안 하드웨어가 들고 있는 키로 암호화합니다. 그 키는 호스트 OS, 하이퍼바이저, 심지어 서버 관리자에게도 절대 안 넘어가요.

CCC(Confidential Computing Consortium)가 정의한 TEE의 3대 보장:

• Data Confidentiality — CVM 밖에서는 메모리 내용을 읽을 수 없음
• Data Integrity — CVM 밖에서는 데이터를 추가/삭제/변조할 수 없음
• Code Integrity — 로드된 코드는 아무도 수정할 수 없음

3. Private Processing (Meta의 구현체)

TEE 위에 얹힌 Meta의 인프라로, 하드웨어가 주는 기밀성 + 증명(attestation)에 다음을 추가합니다.

• Non-targetability — 특정 사용자 세션만 콕 집어 공격할 수 없게 만듦
• Encrypted Storage — 저장 데이터도 사용자 제공 키로만 접근 가능

클라이언트가 서버를 검증하는 흐름 (Remote Attestation)

여기가 진짜 핵심이에요. 클라이언트가 서버를 신뢰하지 않고 검증합니다.

1. 클라이언트 → 서버: 원격 증명 요청
2. 서버 TEE → 클라이언트: 칩 내부 키로 서명된 attestation report 반환
   (여기엔 CVM이 로드한 소프트웨어 이미지의 measurement가 포함됨)
3. 클라이언트 검증:
   a. 서명이 칩 벤더의 root key까지 체인되는가?
   b. measurement가 append-only 투명성 원장에 공개된 값과 일치하는가?
4. 둘 중 하나라도 실패 → 연결 거부, 데이터 전송 안 함 (fail-closed)

즉 "우리 믿어주세요"가 아니라 "이 바이너리가 맞는지 직접 확인하세요"라는 구조예요.

AI 안경용 Private Processing: 5가지 엔지니어링 요구사항

실시간 전사(transcription), 컨텍스트 검색, 장기 리콜 같은 무거운 워크로드를 안전하게 오프로드하려면 다음 5개가 필요해요.

1. Hardware Isolation — 전송/연산/저장 모든 상태에서 호스트 OS·하이퍼바이저·Meta가 데이터를 암호학적으로 못 읽어야 함
2. Fail-Closed Guarantees — 보장을 깨려는 시도는 시스템을 닫히게 하거나, 공개적으로 발견 가능해야 함
3. Public Verifiability — 프로덕션의 모든 CVM 이미지는 append-only 공개 원장에 등록
4. Non-Targetability — 특정 개인 세션을 노리는 공격이 전체 시스템을 깨지 않고는 불가능해야 함
5. Encrypted Storage — 저장 데이터는 사용자 제공 키로만 접근

세션 수립 흐름 (4단계)

[1] Decoupling Identity (Non-targetable Routing)
    - 익명 자격증명(blind-signed token)을 무작위 스케줄로 fetch
    - 인증 서비스가 요청을 계정에 연결하지 못함
    - 서드파티 OHTTP 릴레이(Fastly/Cloudflare) 경유 → TEE 노드 선택

[2] Remote Attestation (Verification)
    - RA-TLS 세션 개시, 서버 TEE의 하드웨어 서명 인증서 요구
    - 바이너리 해시를 공개 투명성 원장과 대조
    - 실패 시 핸드셰이크 종료

[3] Processing (Execution)
    - TLS로 암호화된 blob 전송, 인프라는 라우팅만 하고 못 읽음
    - TEE 내부에서 모델 실행, Meta도 접근 불가
    - TEE 간 통신도 동일한 RA-TLS 프로토콜로 상호 증명

[4] Stateful Memory (Encrypted Storage)
    - 영속 메모리 필요 시 사용자 키로 암호화 후 TEE 밖으로 출력
    - 조회 시 디바이스가 키 제공 → TEE 내부에서 복호화 및 처리

왜 그냥 "디바이스에서 암호화 → 클라우드 DB 저장"은 안 되는가

당연해 보이는 이 접근은 두 가지 이유로 무너져요.

• 접근 패턴이 행동을 유출함 — 내용이 암호화돼 있어도 외부 DB는 언제 읽고 쓰는지, 얼마나 자주 쿼리하는지, 어떤 레코드가 같이 접근되는지를 관찰할 수 있어요. 이 메타데이터만으로 일상 루틴이 지도처럼 그려집니다. 암호화는 페이로드는 지켜도 실행 패턴은 못 숨겨요.
• 원격 암호화 쿼리는 확장이 안 됨 — 시맨틱 벡터 검색이나 멀티 세션 조인을 하려면 거대한 ciphertext를 네트워크로 끌어와 TEE에서 복호화해야 해요. 컨텍스트가 커질수록 레이턴시가 폭발합니다.

그래서 Meta는 스토리지 엔진 자체를 TEE 안에 넣었어요. 신뢰 경계를 확장해서 데이터를 기밀하게 저장하고, 쿼리 엔진이 TEE 경계 안에서 직접 돌아갑니다. 읽기가 외부 네트워크를 넘지 않으니 빠르고요.

디버깅 in the Dark: 운영 관측성

여기서 재미있는 문제가 생겨요. 운영자를 암호학적으로 배제한 시스템을 어떻게 고가용성으로 유지하는가?

TEE 안에서는 표준 진단이 전부 무용지물이에요.

• 실행 중인 TEE에 디버거를 붙일 수 없음
• 크래시 시 메모리 스택 덤프, 모델 입출력 로그 불가
• 장애를 유발한 페이로드를 들여다볼 수 없음

그래서 관측성은 전부 out-of-band로 설계해야 합니다. CPU 사용률, 메모리 할당, 네트워크 레이턴시, 집계된 하드웨어 장애율 같은 집계 신호(aggregate signal) 에만 의존해서 서비스 헬스를 유지해요. 사용자 데이터 1바이트도 노출하지 않으면서요.

검증 가능한 투명성 (Verifiable Transparency)

"우리 안전해요"는 아무 의미 없어요. 그래서 두 가지 장치를 둡니다.

• Binary Transparency via Public Ledgers — 프로덕션의 모든 CVM 이미지를 append-only 공개 원장에 등록. 다른 바이너리를 배포하려 하면 클라이언트와 외부 모니터가 불일치를 발견할 수 있음. 이건 tamper-evidence(변조 증거)를 만드는 거예요. tamper-proof가 아니라요.
• Third Party Validation — NCC Group 같은 독립 보안 업체와 연구자에게 아키텍처, 증명 로직, 격리 모델 경계를 감사받음. 게다가 AI 안경용 Private Processing을 Bug Bounty 범위에 명시적으로 포함시켜서 외부 연구자에게 CVM 바이너리와 문서를 제공합니다.

이 기술의 한계와 주의사항

• TEE는 만능이 아님 — 사이드채널 공격(Spectre 계열, 캐시 타이밍)은 여전히 연구 주제예요. 하드웨어 벤더의 마이크로코드 패치에 의존하는 부분이 큽니다.
• 공개 원장은 tamper-evidence이지 tamper-proof가 아님 — 변조를 '탐지'할 뿐 '차단'하지는 않아요. 탐지 후 대응 로직이 별도로 필요합니다.
• 성능 오버헤드 — CVM 내부 연산, 메모리 암호화, 원격 증명 핸드셰이크는 공짜가 아니에요. 레이턴시 민감한 기능은 프로파일링 필수입니다.
• 운영 복잡도 — 디버거를 못 붙이는 시스템을 운영한다는 건, 관측성 파이프라인을 처음부터 다시 설계해야 한다는 뜻이에요.

다음 단계 학습 방향

1. CCC(Confidential Computing Consortium) 의 백서와 threat model 문서 읽기
2. Intel TDX / AMD SEV-SNP / NVIDIA H100 Confidential Computing 스펙 비교
3. RA-TLS 프로토콜과 OHTTP 릴레이 구조 실습
4. 직접 CVM 위에 간단한 워크로드 올려보고 증명 흐름 관찰하기
5. 에이전트 시대의 inter-CVM 통신 설계 패턴 공부 (이게 다음 난제입니다)

정리: "믿어달라"에서 "검증하라"로

AI 안경용 Private Processing의 핵심은 화려한 모델이 아니라 신뢰 경계의 재설계예요.

• 데이터를 저장·전송·연산 모든 상태에서 보호
• 클라이언트가 하드웨어 증명으로 서버를 직접 검증
• 특정 사용자만 노리는 공격을 구조적으로 차단 (non-targetability)
• 스토리지까지 TEE 안으로 끌어와 접근 패턴 유출 차단
• 운영자를 암호학적으로 배제하고도 집계 신호로 가용성 유지

앞으로 AI는 점점 더 stateful, multimodal, agentic해질 거예요. 에이전트가 민감한 상태를 들고 여러 세션에 걸쳐 행동하려면, 격리와 데이터 출처 증명, CVM 간 통신이 필수가 됩니다. 지금 이 인프라가 그 미래의 토대예요.

기능은 계속 커져도, 보안과 프라이버시 경계는 그대로 유지된다 — 이게 이 아키텍처가 던지는 진짜 메시지입니다.

함께 보면 좋은 글

• AI 시대, 데이터 제너럴리스트의 가치는 더 커졌다 (feat. 5년 전 글을 다시 읽으며)
• 백그라운드 코딩 에이전트를 위한 콘텐츠 엔지니어링 — 안정적인 PR 생산의 비결