어제 Apple은 Siri 생태계에 진정한 AI를 배포하기 위한 큰 진전을 발표했습니다. 여러 면에서 이는 긍정적이며 필연적인 일입니다. Siri는 세계에서 가장 널리 사용되는 음성 에이전트 중 하나이며, 성능이 형편없지 않다면 좋을 것이기 때문입니다. Apple이 프런티어 모델 (Frontier Models)을 통해 역량을 강화할 것이라는 생각은 '할 것인가'의 문제가 아니라, '언제' 그리고 '누구와'의 문제였습니다.

그 '누구'는 Google로 밝혀졌습니다. Apple은 Google Gemini 모델의 조합과 Google의 기밀 추론 (Confidential Inference), 그리고 프라이빗 호스팅을 위한 Apple 자체의 프라이빗 클라우드 컴퓨팅 (Private Cloud Compute)을 함께 사용할 것으로 보입니다. 이 시스템들은 사용자의 질의를 처리할 뿐만 아니라, 기기 내의 프라이빗 데이터 (Private Data)를 평가할 것입니다. Apple의 마케팅에서는 그 장점을 다음과 같이 홍보합니다:

• 첫째, 사용자의 휴대폰에는 이미 당신에 대한 '컨텍스트 (Context)' — 즉, 개인 정보, 일정, 이메일, 문자 메시지 등 — 가 있기 때문에, AI 기능이 탑재된 Siri는 외부 LLM (Large Language Models)보다 사용자의 실질적인 요청에 대해 잠재적으로 더 유용한 답변을 제공할 수 있습니다. 다음 주 생일 파티 예약을 잡고 싶으신가요? 이론적으로 미래의 Siri-AI는 누가 오는지, 그들이 어떤 종류의 케이크를 좋아하는지 이미 알고 있을 수도 있습니다. - 물론, Apple이 '컨텍스트 (Context)'라고 부르는 것은 당신의 삶에 대한 가공되지 않은 데이터이기도 합니다. 이것은 모든 앱에서 나오는 매우 프라이빗한 데이터이며, 이 데이터를 처리를 위해 무작위의 애드테크 (Adtech) 기업(또는 Sam Altman)으로 그냥 보낼 수는 없습니다. 당신의 컨텍스트는 보호되어야 하며, Apple은 스스로를 프라이버시 기업으로 홍보하고 있습니다.

이러한 목표들 사이에는 어느 정도 긴장 관계가 존재합니다. Apple은 이를 해결하기 위해 Private Cloud Compute, 즉 PCC라고 부르는 서비스를 마케팅하며 대응해 왔습니다. PCC는 2024년에 도입되었으며, Apple의 데이터 센터에서 실행되는 일련의 "신뢰할 수 있는" 하드웨어 보안 모듈(Hardware Security Modules)을 사용하여, 전적으로 Apple Silicon 위에서 구동되는 프라이빗 모델 추론 (Private Model Inference) 시스템입니다. 이 시스템의 목표는 사용자의 데이터가 Apple의 하드웨어를 절대 벗어나지 않도록 보장하는 것입니다. 데이터는 사용자의 휴대폰에서 전용 서버까지 암호화되어 전송되며, 응답이 휴대폰에 도달하면 데이터는 사라집니다. PCC의 상태 비저장 (Stateless) 설계는 (이론적으로) 데이터가 머물지 않도록 보장하며, 하드웨어 설계는 Apple조차 입력값을 볼 수 없도록 차단합니다.

Apple은 이후 PCC를 Google의 하드웨어까지 포함하도록 "확장"했습니다. 솔직히 고백하자면, 저는 이 새로운 "확장된" PCC의 세부 사항이 다소 모호하다고 느낍니다. 이는 Apple이 이 데이터를 처리하기 위해 주로 Google의 기존 기밀 컴퓨팅 (Confidential Compute, Google 데이터 센터에서 실행됨)에 의존하되, 실제로 어떤 모델이 실행되는지를 제어하기 위해 새로운 기술적 보안 계층을 덧붙이는 것처럼 들립니다. 어쨌든, 보안 전문가들은 이것이 Cozy Bear와 같은 공격자로부터 당신의 데이터를 지키기에 충분한지에 대해 논쟁할 수 있습니다. 제가 인정하는 점은, 이것이 아마도 Google과 Apple이 당신의 정보에 접근하는 것을 막기에는 충분할 것이라는 점이며, 이것이 애초에 대부분의 사람들이 걱정하는 부분입니다.

그렇다면 저는 왜 이렇게 불안해하는 걸까요?

프라이빗 에이전트와 관련된 짧은 시나리오

에이전트 (Agents)가 어떻게 작동하는지 설명하기 위해, 하나의 사용 사례를 고려해 보는 것이 도움이 됩니다. 당신이 6명을 위한 비즈니스 저녁 식사를 계획하고 있다고 가정해 봅시다. 여기에는 여러 가지 하위 작업 (Subtasks)이 포함됩니다:

당신은 참가자들의 스케줄을 조율하고, 그들이 언제 도시에 와서 만날 수 있는지 알아야 합니다.

• 메뉴와 위치를 기반으로 적절한 식당을 선택해야 합니다. 이는 참가자들의 선호도에 대한 당신의 지식에 따라 달라질 수 있습니다. 예를 들어, 마이크는 사천 후추에 심하게 알레르기가 있어 여러 옵션이 제외됩니다.
• 이러한 시간/요리/위치 제약 조건들이 마련되면, 실제로 여섯 명을 위한 테이블이 있는 식당을 검색해야 합니다.
• 마지막으로, 예약을 하고, 달력에 표시하며, 참석자들에게 알려야 합니다.

과거에는 이러한 종류의 스케줄링 작업에 상당한 양의 인간적인 노력이 필요했습니다. AI 에이전트의 장점은 이론적으로 이것이 자동화될 수 있는 바로 그 종류의 프로젝트라는 것입니다. 이 에이전트는 먼저 당신의 최근 대화를 스캔하여 단계 (1)과 (2)에 필요한 질문에 답할 수 있고, 그런 다음 단계 (3)에서 설명된 검색을 수행할 수 있습니다. 당신의 승낙만 있다면, 단계 (4)를 완료하는 데 필요한 캘린더 초대장과 문자 메시지까지 작성할 수 있습니다.

그렇다면 여기서 문제는 무엇일까요?

첫 번째이자 놀랍지 않은 관찰은 이러한 작업에서 유용하려면 에이전트가 *맥락(context)*을 가지고 있어야 한다는 것입니다. 이는 곧: 당신의 개인 데이터에 비교적 제한 없이 접근할 수 있음을 의미합니다. 당신은 초대 손님들의 참석 가능 여부를 그들이 문자 메시지로 보내주었기 때문에 알고 있습니다. 마이크의 알레르기에 대해서는 당신이 그와 이야기했거나 어딘가에 메모해 두었기 때문에 알고 있습니다. (이는 iMessage, 이메일, 연락처 또는 개인 메모를 의미할 수 있습니다.) 이 모든 데이터를 에이전트에게 다시 입력하는 것은 성가시고 시간이 많이 걸릴 것이며 에이전트의 전체 목적은 당신의 시간을 절약하는 것입니다. 승리하는 개인 비서는 단순히 똑똑해서 이기는 것이 아닙니다. 책상 옆에 앉아 있는 개인 비서처럼, 자신이 알아야 할 것을 “이미 알고” 있기 때문에 이기는 것입니다.

조금 더 깊이 있게 세부 사항을 파헤쳐 보겠습니다. 에이전트는 저녁 식사 일정을 잡는 데 필요한 매개변수 (parameters)를 학습하기 위해 사용자의 메시지 데이터베이스를 스캔할 수도 있습니다. 또는, 더 토큰 효율적인 (token-efficient) 시스템의 경우, 메시지를 지속적으로 읽고 나중에 필요할 수 있는 유용한 사실들을 추출하여 "메모리 (memory)"로 저장할 수도 있습니다. 두 방식 모두 기능적으로는 동일할 수 있지만, 한 가지는 매우 민감할 수 있는 결과물 (artifact)을 생성한다는 차이가 있습니다. 그리고 유용할 수도 있는 사실의 범위가 매우 넓다는 점을 명심해야 합니다. 예를 들어, 마이크의 알레르기는 그러한 사실 중 하나입니다. 하지만 다른 사실들도 아주 많습니다. 예를 들어, 마이크가 외도를 하고 있다는 사실을 알게 된 당신의 사적인 대화 또한 시스템에 의해 저장되거나 접근될 수 있는 잠재적인 또 다른 사실이 될 수 있습니다. 메모리 저장 여부와 상관없이, 이 데이터는 모두 에이전트의 가시 범위 내에 있게 되며, 당신은 에이전트가 어떤 데이터에 작용해야 할지를 제대로 알고 있기를 바라야만 할 것입니다.

이러한 데이터가 손끝에 닿는 곳에 있다면, 당신의 에이전트(실제로는 어딘가 데이터 센터의 서버에서 실행되는 LLM에 일련의 로컬 상태 (local state)와 프롬프팅 (prompting)이 결합된 형태)는 데이터를 요약하거나 질의 자체에 응답하기 위해 이 데이터에 대한 추론 (inference)을 수행해야 합니다. 바로 이 지점이 프라이빗 클라우드 컴퓨트 (Private Cloud Compute)와 기밀 추론 (Confidential Inference)이 당신을 보호하기 위해 설계된 부분입니다. 이러한 기술들의 목적은 이 데이터와 모든 추론 결과가 오직 당신에게만 제한되도록 보장하는 것입니다. 입력값과 출력값은 추론이 완료되는 즉시 삭제되어야 하며, 그 어떤 복사본도 오직 당신의 휴대폰에만 남아 있어야 합니다.

지금까지의 내용은 당신이 추론 이외의 다른 어떤 것도 할 계획이 없다면 매우 설득력 있는 이야기로 들립니다.

프라이빗 추론 (Private inference)은 좋지만, 에이전트가 유용해지려면 무언가와 소통해야 합니다

추론 (Inference)만 수행하는 AI는 당신의 개인 파일을 읽을 수는 있지만, 인터넷 접속도 안 되고 외부로 전화를 걸 수도 없는 창문 없는 방에 갇혀 있는 인간 비서와 같습니다. 당신의 데이터는 완벽하게 안전하지만, 그 비서는 가장 단순한 작업들, 예를 들어 당신이 읽을 수 있도록 수신된 메시지를 요약하거나 문자 메시지 초안 작성을 돕는 일 외에는 아무런 쓸모가 없습니다. (요컨대, 현재의 Apple Intelligence가 하는 일입니다.)

이제 실제로 일을 처리할 수 있는 개인 비서를 상상해 보십시오. 이 비서는 인터넷 접속이 필요할 것입니다. 최소한 검색 엔진을 쿼리(Query)할 수 있는 능력, 혹은 미래에는 Gemini나 ChatGPT와 같은 검색용 LLM (Large Language Model)을 검색할 수 있는 능력이 필요합니다. 우리 작업의 후반 단계들을 완수하려면, 이 비서가 공개 캘린더 초대를 예약하고 연락처에 있는 사람들과 공유할 메시지 초안을 작성할 수 있어야 합니다. 이제 이 비서는 유용해졌지만, "어떠한 개인 데이터도 타인에게 접근할 수 없다"는 멋진 PCC (Privacy-Preserving Computing) 보장은 더 이상 그대로 적용되기 어렵습니다. 당신의 데이터 프라이버시는 더 이상 특정 실리콘(Silicon)의 설계에 달려 있는 것이 아니라, 비서의 신중함과 판단력에 달려 있게 됩니다.

다시 우리의 가상 비즈니스 저녁 식사 상황으로 돌아가 봅시다. 단계 (3)을 완수하기 위해 당신의 에이전트(Agent)는 검색 엔진이나 비공개(Non-private) LLM을 방문해야 하며, 아마도 여러 번의 쿼리를 던질 것입니다. 이때 각 쿼리는 당신의 구체적인 요구 사항에 대한 정보를 일부 유출하게 됩니다. 데이터 유출의 성격은 "프라이빗" 에이전트가 쿼리를 작성할 때 얼마나 주의를 기울이느냐에 따라 크게 달라집니다. 매우 합리적인 사례로, 모델이 단순히 일련의 유용한 사실들을 수집한 뒤, 다음과 같이 Gemini, ChatGPT 또는 Claude와 같은 더 강력한 "오픈(Open)" 검색용 LLM에 그 모든 정보를 업로드하는 경우가 있을 수 있습니다:

"

헤이, LLM 검색 엔진, 여기 내 참석자들과 이번 회의 목적에 관한 30가지의 상세한 사실 목록이 있어. 모두에게 적합한 레스토랑을 찾아줘."

이것은 믿을 수 없을 정도로 효율적인(그리고 어느 정도 자연스러운) 설계가 될 것입니다. 왜냐하면 비공개(non-private) LLM이 프라이빗(private) LLM보다 훨씬 더 강력하고 유능할 가능성이 높기 때문입니다. 불행히도, 이는 작업을 완수하는 데 엄격하게 필요하지 않을 수도 있는 정보를 포함하여, 당신의 프라이빗 데이터에 대한 터무니없이 많은 양의 정보를 드러내게 될 것입니다. (마이크의 불륜 사실이 좌석 배치도와 관련이 있을까요?) 달리 말하면, 프라이빗 추론 (Private Inference)은 완벽하게 작동할 수 있음에도 불구하고, 에이전트가 업무를 수행하도록 프로그래밍된 방식이 약간 프라이버시를 보존하지 않는 방식으로 설계되었다는 이유만으로 가치 있는 (수익화 가능한) 데이터가 공용 검색 엔진이나 LLM으로 흘러 나갈 수 있다는 것입니다.

좋습니다, 검색 엔진이 일부 프라이빗 데이터를 학습할 수도 있습니다. 그래서 어쩌라는 건가요?

당신은 아마 검색 엔진이 마이크가 사천 요리에 알레르기가 있다는 사실을 알아내는 것에 대해 크게 신경 쓰지 않을 것입니다. 하지만 당신이 정말로 신경 써야 할 것들이 있습니다. 보안 용어로 말하자면, 이 두 가지는 서로 다른 *적대자 (Adversaries)*와 관련이 있습니다.

가장 명백한 "적대자"부터 시작해 봅시다. 당신이 마크 저커버그(Mark Zuckerberg)나 순다르 피차이(Sundar Pichai), 혹은 애플의 광고 사업을 운영하는 사람이라고 상상해 보십시오. 당신에게는 휴대폰에 매우 유용한 데이터 더미를 저장하고 있는 수십억 명의 사용자가 있습니다. 이 데이터는 타겟 광고 (Targeted Advertising)에 매우 가치 있는 것이며, 생성형 AI (Generative AI) 덕분에 앞으로 엄청나게 더 수익성이 높아질 분야입니다. 동시에, 이 데이터의 큰 부분은 접근이 불가능합니다. 단순히 사용자들이 당신이 그들의 개인적인 대화를 스캔한다는 아이디어를 좋아하지 않기 때문입니다. 따라서 당신이 일부 공개 데이터(웹 브라우징 등)에는 접근할 수 있을지 몰라도, 많은 사용자가 자신의 기기에 저장해 둔 수년간의 친밀한 프라이빗 대화 내용을 읽을 수는 없습니다.

이제 에이전트(Agent)를 사용자의 휴대폰에 배포하는 상황을 상상해 보십시오. 그 에이전트는 그 모든 데이터에 접근할 수 있을 것입니다. 사용자가 하는 모든 것에 접근할 수 있게 됩니다. 자신의 임무를 수행하기 위해, 에이전트는 말 그대로 각 사용자의 선호도를 파악하고, 이를 귀하의 검색 엔진이나 "검색 LLM (Search LLM)"에 반복적으로 요청을 보내는 쿼리(Query)로 실행에 옮겨야 합니다. 이 검색 엔진을 운영하는 사람은 사용자의 욕구에 관한 방대한 양의 유용한 정보를 학습하게 될 것이며, 그중 일부는 가장 친밀한 사적인 대화 — 심지어 몇 년 전에 일어났고 당신은 이미 잊어버린 대화 — 에서 비롯될 것입니다. 만약 검색 엔진을 운영하는 사람이 모델과 프롬프팅(Prompting)을 설계하는 사람이기도 하다면, 이는 데이터 수익화 (Data Monetization)를 위한 최상의 시나리오가 됩니다. 주요 기술 기업의 CEO들이 이 사실을 모르고 있을 것이라고는 믿기 어렵습니다.

에이전트가 사람들과 대화할 수 있다면, 낯선 이들도 에이전트와 대화할 수 있습니다

따라서 Google, Meta 또는 Apple이 우리의 프라이빗 데이터로부터 우리에 대해 훨씬 더 많은 것을 배울 수도 있다는 생각에는 반대하지만, 적어도 우리의 가장 친밀한 비밀이 전 세계에 공개되지 않을 가능성은 있습니다. 하지만 이것이 당신의 프라이빗 데이터가 공개되지 않을 것이라는 의미는 아닙니다. 이것이 바로 우리가 두 번째 적대자 (Adversary)에 대해 이야기해야 하는 이유입니다. 이 적대자는 당신의 에이전트가 대화하는 검색 엔진이 아니라, 당신의 에이전트와 대화하게 될 다른 모든 사람들입니다.

Simon Willison은 그가 *치명적인 삼중주 (the lethal trifecta)*라고 부르는 상황을 설명합니다. 이는 (a) 개인 데이터에 대한 접근 권한, (b) LLM이 파싱해야 하는 신뢰할 수 없는 콘텐츠, 그리고 (c) 외부 통신을 보낼 수 있는 능력이 결합될 때 발생합니다. 이 요소들이 함께 작용하면 데이터 유출 (data-exfiltration) 공격을 위한 완벽한 폭풍을 만들어내며, 원격 공격자는 기밀 데이터를 외부로 전송하라는 지침을 보냄으로써 LLM을 단순히 "속이는" 것만으로 공격을 수행할 수 있습니다. LLM 기술이 발전하고 있음에도 불구하고, 최첨단 (frontier) LLM조차 악의적인 사용자가 (웹사이트의 일부나 데이터의 일부로서) LLM이 공개해서는 안 될 정보를 드러내도록 유도하는 텍스트를 포함하는 단순한 프롬프트 인젝션 (prompt injection) 공격에 속아 넘어가는 일이 여전히 매우 흔합니다. 이 문제는 여전히 매우 실재하는 위협입니다. 바로 오늘, OpenAI는 ChatGPT가 민감한 문서를 업로드할 위험 때문에 웹 검색을 수행하지 못하도록 제한하는 "잠금 모드 (lockdown mode)" 기능을 최근 공개했습니다.