Privacy-Preserving Intelligence — Steve Korshakov, Bee (acq. Amazon)
📺 원본 영상: Privacy-Preserving Intelligence — Steve Korshakov, Bee (acq. Amazon)
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-21
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Steve Korshakov는 Bee가 만든 AI 웨어러블이 단순한 음성 녹음 장치가 아니라, 사용자의 일상 대화를 지속적으로 수집해 개인 AI 에이전트를 구성하는 시스템이라고 설명한다. 이 장치는 한 사람으로부터 연간 약 1,000만 토큰 수준의 데이터를 포착할 수 있고, 사용자가 착용한 지 일주일만 지나도 가족, 친구와 나눈 극도로 민감한 정보가 포함될 수 있기 때문에 일반적인 클라우드 애플리케이션보다 훨씬 높은 수준의 프라이버시 설계가 필요하다.
강연의 핵심은 “민감한 데이터를 활용하면서도 운영자조차 그 데이터에 접근하지 못하게 하려면 무엇을 설계해야 하는가”라는 질문이다. Bee는 이를 위해 고객 기기 중심의 키 관리, 강제 암호화, Confidential Computing(기밀 컴퓨팅), 원격 증명(Remote Attestation), 투명성 로그(Transparency Log), 제한된 배포 파이프라인을 결합했다. 특히 Amazon에 인수된 이후에는 외부 클라우드 고객으로서의 보안 모델을 넘어, Amazon 내부자 위협까지 고려해야 했다는 점이 설계의 난도를 높인다.
가장 민감한 캡처 장치가 만든 설계 압력
Korshakov는 Bee의 제품을 손목에 착용한 AI 웨어러블로 소개하면서, 본질적으로 “모든 것을 기록하는 마이크”라고 설명한다. 이 표현은 다소 직설적이지만, 제품의 프라이버시 위험을 정확히 드러낸다. 사용자는 단순히 명령을 내리는 것이 아니라 일상적인 대화를 계속 남기게 되고, 시스템은 그 축적된 데이터를 바탕으로 개인 AI와 외부 에이전트가 사용할 수 있는 구조화된 정보를 만들어낸다.
문제는 이 데이터가 일반적인 앱 로그나 검색 기록보다 훨씬 사적인 성격을 가진다는 데 있다. 강연자는 한 사람이 보통 1년에 약 1,000만 토큰을 캡처한다고 말하며, 첫 일주일 안에도 사용자가 가족이나 친구에게 매우 민감한 내용을 말하는 경우가 많다고 강조한다. 이는 사용자의 일정, 관계, 건강, 재정, 고민, 감정 상태 같은 정보가 자연스럽게 포함될 수 있음을 뜻한다.
01:06 - Bee 웨어러블이 수집하는 개인 데이터의 민감도와 일주일 내 노출될 수 있는 사적 정보의 범위
따라서 Bee의 보안 목표는 “데이터를 안전하게 보관한다”보다 더 강한 형태를 취한다. Korshakov는 회사와 Amazon 내부의 누구도 이 데이터에 접근할 수 없어야 한다고 설명한다. 즉, 신뢰의 중심을 서버 운영자에게 두는 것이 아니라, 운영자가 시스템을 운영하더라도 평문 데이터에는 도달하지 못하게 만드는 구조가 필요했다.
요청-응답 AI에서 지속 실행 에이전트로
강연자는 현재 많은 AI 시스템이 요청-응답(Request-Response) 방식으로 설계되어 있다고 지적한다. 사용자가 iPhone 같은 기기에서 LLM에 요청을 보내면, 모델이 계산하고 결과를 반환하는 구조다. 이 방식은 챗봇이나 단발성 작업에는 자연스럽지만, 개인 에이전트가 사용자를 위해 계속 일해야 하는 환경에서는 충분하지 않다.
Bee가 상정하는 개인 AI는 사용자가 매번 호출하지 않아도 백그라운드에서 작동해야 한다. 강연자는 Claude Code로 보이는 사례를 언급하며, 불과 몇 달 전에는 “이것을 바꿔라, 저것을 바꿔라” 식의 요청-응답에 가까웠던 개발 에이전트가 이제는 몇 시간 동안 작업할 수 있는 방향으로 이동하고 있다고 설명한다. 그는 같은 변화가 결국 모든 개인 에이전트에도 일어날 것이라고 본다.
이 관점에서 Bee는 Stateful Runtime(상태를 가진 런타임)과 Persistent Memory(영속 메모리)를 갖춘 시스템을 설계했다. 에이전트는 여러 도구와 서드파티 서비스에 연결될 수 있고, 사용자의 기기가 항상 온라인일 필요도 없다. 다만 이 자율성은 회사가 사용자의 데이터를 볼 수 있다는 뜻이 아니라, 사용자가 통제권을 유지한 상태에서 시스템이 독립적으로 일할 수 있어야 한다는 방향으로 구현된다.
03:25 - 요청-응답 방식의 한계를 넘어 상태를 가진 런타임과 영속 메모리를 갖춘 개인 에이전트 구조
네 가지 원칙: 키, 암호화, 감사, 신뢰 최소화
Bee의 시스템은 네 가지 핵심 아이디어 위에 세워져 있다. 첫째, 암호화 키는 고객의 기기, 즉 사용자의 iPhone이나 Android 기기에서만 생성되고 관리된다. 회사는 키를 보유하지 않으며, 서버 쪽에 영구 저장하지도 않는다. 이는 서버가 침해되거나 내부자가 접근하더라도 고객 데이터 복호화에 필요한 핵심 권한을 갖지 못하게 하기 위한 출발점이다.
둘째, 모든 데이터는 암호화되며 이를 끄거나 우회할 수 있는 옵션이 없다. 이 대목은 제품 철학상 중요하다. 많은 시스템은 보안 기능을 설정값으로 제공하지만, Bee는 데이터의 민감도를 고려해 암호화를 선택 사항이 아니라 시스템의 기본 조건으로 만든다. 사용자의 편의나 운영상의 이유로 보안 경로를 우회할 수 있다면 전체 모델이 약해지기 때문이다.
셋째, 내부자 위협을 막기 위해 워크로드에 대한 투명한 감사를 수행한다. 넷째, 신뢰해야 하는 의존성을 가능한 한 줄인다. 이 두 원칙은 “우리가 좋은 의도를 갖고 있다”는 선언으로는 충분하지 않다는 인식에서 출발한다. 실제 보안 아키텍처에서는 어떤 코드가 실행되었고, 누가 무엇을 배포했으며, 그 실행 환경이 검증 가능한지를 외부 감사와 내부 통제 구조로 증명할 수 있어야 한다.
04:37 - 고객 기기 기반 키 관리, 강제 암호화, 투명 감사, 신뢰 최소화라는 네 가지 보안 원칙
키 관리와 원격 증명: 사용자의 휴대폰에서 시작되는 신뢰
Korshakov는 어떤 형태의 End-to-End Encryption(종단 간 암호화)이든 가장 어려운 문제는 Key Management(키 관리)라고 설명한다. Bee의 키는 사용자 휴대폰에서 시작되고, 적어도 영구 저장 위치도 휴대폰이다. 이후 휴대폰은 백엔드와 연결되며, 이 과정에서 무결성과 특정 워크로드가 공개 투명성 로그 안에 존재하는지를 검증하는 복잡한 Attestation Pipeline(원격 증명 파이프라인)을 수행한다.
강연자는 Bee가 투명성 로그로 Sigstore를 사용한다고 말한다. Sigstore는 소프트웨어 아티팩트의 서명과 투명성 검증을 위한 생태계로 알려져 있으며, 여기서는 특정 워크로드가 정당한 배포물인지 확인하는 데 쓰인다. 다만 강연자는 이 검증 방법이 너무 복잡해 발표 안에 모두 담기는 어렵고, 자세한 내용은 나중에 공개할 예정이라고 덧붙인다.
05:31 - 휴대폰에서 시작되는 키 관리와 Sigstore 기반 투명성 로그 및 원격 증명 파이프라인
원격 증명이 끝나면 클라이언트는 백엔드와 키를 공유하고, 백엔드는 Confidential Computing 환경에서 실행되는 추론 노드들에 이 키를 복제한다. 여기서 중요한 점은 복제된 키가 일반 서버 코드가 마음대로 접근할 수 있는 형태로 남는 것이 아니라는 점이다. Bee는 평문 데이터가 자신들의 보안 경계 밖으로 나갈 수 없기 때문에 자체 추론 인프라도 운영해야 했고, 이는 일반적인 AI 회사보다 더 복잡한 운영 부담으로 이어졌다.
자체 추론 인프라와 7일 만료 정책
Bee는 다양한 모델과 추론 소프트웨어를 실행하지만, 모든 코드를 추론 노드에 무차별적으로 복제하지 않는다. 강연자는 특정 워크로드만 복제해 실행 범위를 제한한다고 설명한다. 이는 공격 표면을 줄이고, 어떤 코드가 민감 데이터 근처에서 실행될 수 있는지를 통제하기 위한 선택으로 볼 수 있다.
또 하나 눈에 띄는 설계는 메모리 안에 키가 존재하는 모든 위치에 7일 강제 만료 정책을 도입했다는 점이다. Korshakov는 7일을 선택한 이유를 사용자를 위해 현실적으로 유용한 작업을 수행할 수 있는 시간 지평으로 설명한다. 24시간은 너무 짧아서 사용자가 하루 동안 휴대폰을 열지 않아도 작업이 끊길 수 있기 때문에, 실용성과 보안 사이에서 약 일주일이 균형점이 되었다는 것이다.
06:43 - Confidential Computing 환경의 추론 노드와 메모리 내 키의 7일 강제 만료 정책
이 정책은 영속적으로 일하는 개인 에이전트의 어려운 트레이드오프를 보여준다. 에이전트가 장기간 유용하게 작동하려면 상태와 권한이 필요하지만, 권한이 오래 남을수록 침해 시 피해도 커진다. Bee의 접근은 “언제까지나 접근 가능하게 만들지 않는다”는 시간 기반 제한을 통해 자율성과 피해 범위를 동시에 관리하려는 시도다.
배포 파이프라인: 아무도 몰래 위험한 코드를 넣을 수 없게 하기
민감 데이터 보호에서 암호화만큼 중요한 것은 어떤 코드가 실제 프로덕션에 배포되는지다. Korshakov는 Amazon 내부의 누구도 눈에 띄지 않게 데이터를 침해할 수 있는 코드를 배포하지 못하게 하는 것이 목표였다고 설명한다. 소프트웨어에는 버그가 있을 수 있지만, 의도적이든 실수든 감시되지 않은 변경이 민감 데이터 경로에 들어가는 상황은 막아야 한다는 문제의식이다.
이를 위해 Bee는 두 계층의 시스템을 만들었다. Amazon 조직 내부에는 프라이버시와 투명성 로그를 관리하는 전담 팀이 있고, Bee 팀은 소프트웨어를 배포하더라도 이 팀의 승인 및 서명 체계를 우회할 수 없다. 해당 팀의 Signing Key(서명 키)는 클라이언트 앱과 백엔드에 하드코딩되어 있어, 배포물의 정당성 검증이 런타임 신뢰 체계와 직접 연결된다.
다만 큰 조직에서 모든 변경을 매우 높은 수준의 직원 승인으로 처리하면 프로세스가 느려진다. 그래서 Bee는 Base Image(기반 이미지)와 실제 워크로드 배포를 나누는 방식을 선택했다. 기반 이미지에는 부팅 측정, 매니페스트 측정, 워크로드와 데이터 측정에 필요한 도구를 넣고, 이후 배포 단계에서는 특정 매니페스트를 투명성 로그에 올려 검증 가능한 배포 이력을 남긴다.
08:59 - 기반 이미지와 워크로드 매니페스트를 분리하고 투명성 로그에 배포 증거를 남기는 배포 파이프라인
감사 가능성: 과거의 모든 배포물을 추적한다는 의미
강연자는 Bee가 고위급 외부 감사 회사들과 지속적으로 협력한다고 말한다. 이 시스템의 장점은 과거에 배포된 어떤 이미지나 매니페스트도 제공하고 추적할 수 있다는 점이다. 만약 잘못된 배포가 있었다면, 어떤 이미지가 언제 어떤 경로로 들어갔는지 되짚어 약점을 찾을 수 있다.
이 접근은 보안을 “현재 안전한 상태”로만 보지 않는다. 실제 운영 환경에서는 나중에야 취약점이나 실수가 발견되는 경우가 많고, 그때 중요한 것은 과거 상태를 재구성할 수 있는 증거다. 투명성 로그와 매니페스트, 서명 키, 원격 증명 문서가 결합되면, 시스템은 단순히 믿어 달라고 말하는 대신 검증 가능한 흔적을 남긴다.
강연 후반부에서 Korshakov는 VM이 자체 검증을 마친 뒤 인증서를 발급하며, 이 인증서 안에 암호화 정보, 투명성 증명, Attestation Document(증명 문서)를 포함한다고 설명한다. 공용 인증서에는 이런 정보를 넣기 어렵기 때문에 사설 인증서를 사용한다고 말한다. 향후에는 일반 TLS와 더 가벼운 형태의 증명을 처리하는 추가 프록시를 도입할 수 있지만, 발표 시점에는 아직 구현되지 않았다고 밝혔다.
09:44 - VM 자체 검증 이후 인증서에 암호화 정보, 투명성 증명, 원격 증명 문서를 포함하는 방식
Amazon 내부로 들어간 뒤 달라진 보안 모델
질의응답에서 한 참석자는 Bee가 작은 스타트업에서 Amazon 내부 조직이 된 뒤 프로세스 관점에서 무엇이 달라졌는지 묻는다. Korshakov는 이전에는 Amazon을 사용하는 고객 입장이었기 때문에 Amazon이 고객에게 제공하는 보안 보장을 활용하면 되었지만, 인수 이후에는 자신들이 Amazon 내부의 일부가 되었다는 점이 달라졌다고 답한다. 즉, 더 이상 “클라우드 제공자가 데이터를 볼 수 없다”는 외부 고객 모델만으로는 충분하지 않게 된 것이다.
이 변화는 내부자 위협을 별도의 설계 대상으로 끌어올렸다. Amazon 내부에 있다고 해서 모든 내부 주체를 신뢰할 수 있는 것으로 두면, 민감한 개인 데이터 보호 목표와 충돌한다. 그래서 Bee는 Confidential Computing, 투명성 로그, 서명 분리, 감사 가능성을 통해 내부 운영자와 개발팀의 권한도 제한하는 방향으로 시스템을 재구성했다.
Korshakov는 자세한 내부 사정을 많이 말할 수는 없다고 선을 긋지만, 핵심 메시지는 분명하다. 외부 클라우드 고객일 때의 보안 모델과 클라우드 기업 내부 서비스가 되었을 때의 보안 모델은 다르다. 후자의 경우에는 같은 회사 안의 배포 권한, 운영 권한, 감사 권한을 서로 분리하지 않으면 “누가 데이터를 볼 수 없는가”라는 주장을 강하게 유지하기 어렵다.
코드 범위를 줄이는 보안 전략
질의응답에서 Bee가 얼마나 많은 것을 직접 만들었는지에 대한 질문이 나오자, Korshakov는 대부분을 처음부터 만들려고 한 것은 아니라고 답한다. 그는 가능한 한 기존의 널리 쓰이는 소프트웨어를 사용하고, 직접 작성한 코드의 양을 줄이려 했다고 설명한다. 발표 전 계산한 기준으로 직접 작성한 코드는 약 2만 줄 수준이며, Memory-Safe Language(메모리 안전 언어)로 작성되었다고 한다.
이 답변은 보안 엔지니어링에서 중요한 원칙을 보여준다. 민감 시스템이라고 해서 모든 것을 자체 구현하면 오히려 위험해질 수 있다. 특히 암호화나 원격 증명처럼 작은 결함이 치명적 결과로 이어질 수 있는 영역에서는 검증된 구성 요소를 재사용하고, 직접 작성한 부분을 작게 유지해 감사 가능성을 높이는 편이 더 합리적이다.
Korshakov는 Telegram이 자체 암호화를 구현한 사례를 언급하며, 그런 방식은 논쟁적이었다고 말한다. 그는 Amazon에서 같은 실수를 반복하지 않으려 했다고 설명한다. 이 발언은 Bee의 전략이 “새로운 암호 기술을 발명하는 것”이 아니라, 검증 가능한 배포와 실행 환경을 만들고 그 위에서 기존의 신뢰 가능한 구성 요소를 조합하는 데 있다는 점을 잘 보여준다.
에이전트 안전성: 똑똑하게 만들기보다 해칠 수 없게 만들기
마지막 질의응답에서는 에이전트가 위험한 행동을 하지 못하게 하는 방법에 대한 논의가 나온다. 질문의 일부는 STT상 불명확하지만, Korshakov의 답변은 비교적 분명하다. 그는 모델을 개인 컴퓨터에 그대로 연결하는 것을 선호하지 않으며, 에이전트를 “길들이는” 여러 실험을 했지만 실제로 작동하는 것은 Sandboxing(샌드박싱)과 해를 끼칠 수 있는 권한을 주지 않는 것뿐이라고 말한다.
그는 인간의 뇌가 의지만으로 심장을 멈출 수 없다는 비유를 든다. 이는 지능이 높아지는 것과 실행 권한을 갖는 것은 별개의 문제라는 뜻으로 읽힌다. 에이전트가 아무리 유능하더라도, 중요한 시스템을 직접 변경하거나 손상을 일으킬 수 있는 경로가 열려 있다면 프롬프트나 정책만으로는 충분하지 않다는 것이다.
Korshakov는 Claude로 보이는 도구가 보안을 강화하려다 유용성이 떨어졌다고 언급하며, Bee의 목표는 “wild agent”에 가깝지만 특정 에이전트별 샌드박스를 배포해 실제로 할 수 있는 일을 제한하는 것이라고 설명한다. 즉, 에이전트를 약하게 만드는 것이 아니라, 강한 에이전트가 안전한 경계 안에서만 움직이게 하는 방향이다. 이 관점은 개인 AI 시대의 보안이 단순한 데이터 암호화를 넘어 권한 설계와 실행 환경 격리로 확장되어야 함을 시사한다.
마무리 / 핵심 정리
이 강연은 개인 AI가 진짜로 유용해질수록 프라이버시 문제가 더 어려워진다는 사실을 보여준다. 사용자의 모든 대화와 맥락을 기억하는 에이전트는 강력한 생산성 도구가 될 수 있지만, 동시에 가장 민감한 개인 데이터 저장소가 된다. Bee의 접근은 이 모순을 피하지 않고, 키를 사용자 기기에 두고, 서버 실행 환경을 원격 증명하며, 배포물을 투명성 로그로 검증하고, 내부자조차 몰래 위험한 코드를 넣을 수 없도록 만드는 쪽으로 나아간다.
특히 중요한 메시지는 보안이 단일 기능이 아니라 운영 체계라는 점이다. 암호화, Confidential Computing, Sigstore 기반 투명성 로그, 사설 인증서, 코드 범위 축소, 감사 가능한 배포 이력, 에이전트 샌드박싱이 함께 작동해야 “운영자도 볼 수 없는 개인 AI”라는 주장이 현실성을 가진다. Bee의 사례는 앞으로 웨어러블, 개인 에이전트, 장기 실행 AI 런타임을 만드는 팀들이 피할 수 없는 질문을 던진다. AI가 사용자를 위해 계속 일하게 만들려면, 먼저 그 AI와 인프라가 사용자를 배신할 수 없는 구조를 만들어야 한다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Privacy-Preserving Intelligence — Steve Korshakov, Bee (acq. Amazon) |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-21 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.