Private LLM 옵션: 로컬, 클라우드, 또는 기밀(Confidential)?
요약
개인 LLM 구축 시 로컬, 클라우드, 기밀 추론 세 가지 옵션을 비교 분석합니다. 각 방식의 비용과 장단점을 다루며, 특히 데이터 보호 측면에서 물리적, 계약적, 기술적 개인 정보 보호 개념을 설명합니다.
핵심 포인트
- 로컬 LLM은 가장 높은 수준의 개인정보 보호를 제공합니다.
- 클라우드 옵션은 AWS Bedrock 등 서비스별 데이터 보존 정책을 확인해야 합니다.
- 기밀 추론(Confidential Inference)은 TEE 기반으로 하드웨어 레벨에서 데이터를 암호화하여 보안성을 높입니다.
개인적인 LLM을 원한다면 가장 당연한 방법은 장비를 구매하여 직접 실행하는 것입니다. 그렇게 하기 전에, 해당 하드웨어가 실제로 얼마나 비용이 드는지, 2년 후에 구식이 되었는데도 여전히 할부금을 내고 있는 상황은 어떤지, 그리고 다른 옵션들은 무엇인지 이해할 가치가 있습니다. 세 가지 경로가 있습니다: 자체 하드웨어, 계약을 맺은 클라우드 제공업체, 또는 애초에 프롬프트를 읽을 수 없는 하드웨어에서의 기밀 추론(confidential inference)입니다.
본 게시물에서는 Private LLM의 옵션들, 각 옵션의 비용, 그리고 팀원들과 에이전트(agent)를 공유할 때 AI 개인 정보 보호에 대한 심층적인 내용을 다룹니다.
- LLM에게 '개인적(private)'이라는 것은 무엇을 의미하는가?
- 옵션 1: 자체 하드웨어에서의 로컬 LLM
- 옵션 2: 계약이 있는 클라우드 제공업체
- 옵션 3: SayGM을 사용한 기밀 추론
- 세 가지는 어떻게 비교되는가?
- 다른 측면: 공유 에이전트에서의 개인 메모리
- Private LLM에 대한 일반적인 질문들
- 어떤 것을 선택해야 하는가?
LLM에게 '개인적(private)'이라는 것은 무엇을 의미하는가?
'Private LLM / AI'라는 용어는 다양한 맥락에서 사용됩니다.
**물리적 개인 정보 보호(Physical privacy)**란 프롬프트가 통제하는 기계를 절대 벗어나지 않는 것을 의미합니다.
**계약적 개인 정보 보호(Contractual privacy)**란 프롬프트가 외부로 나가지만, 제공업체가 서면으로 이를 학습에 사용하지 않고, 공유하지 않으며, 정해진 기간이 지나면 보관하지 않기로 동의한 경우를 말합니다.
**기술적 개인 정보 보호(Technical privacy)**란 프롬프트가 외부로 나가더라도, 운영자가 들여다볼 수 없는 하드웨어 내부에서 처리되며, 사용자가 직접 이를 확인할 수 있는 것을 의미합니다.
프롬프트를 읽을 수 있는 주체는 누구이며, 그들을 막는 것이 벽인지, 약속인지, 아니면 칩인지를 알아야 합니다.
옵션 1: 자체 하드웨어에서의 로컬 LLM
로컬 LLM은 개인 정보 보호 문제에 대한 가장 깔끔한 해답입니다. 아무것도 건물 외부로 나가지 않으며, 신뢰할 제공업체도 없고, 변경될 때마다 다시 읽어야 할 서비스 약관도 없습니다.
최신 하드웨어 정보를 종합해보면 RTX 5090이 MSRP(미국 달러) 기준 1,999달러에 32GB VRAM을 탑재하고 있으며, 70B 모델에서 초당 약 25~30 토큰을 처리할 수 있고, 유사한 속도를 내는 128GB Mac Studio는 3,500달러에서 4,000달러에 구매 가능합니다(fungies.io hardware guide). 이는 한 사람이 사용하기에 충분히 좋은 구성입니다.
단점은 다음과 같습니다:
- 동시성(Concurrency). 초당 25토큰을 처리하는 하나의 카드는 하나의 대화 세션만을 의미합니다. 열 개의 병렬 호출로 확장되는 에이전트의 경우, 같은 카드에서 순서가 지연됩니다.
- 배우자(아내 또는 남편). 그들이 당신에게
AWS Bedrock은 모델 제공업체가 고객의 프롬프트와 완성본에 접근할 수 없다고 명시합니다. 데이터 보존 문서에는
세 번째 옵션은 더 새롭고 앞의 두 가지 사이의 위치에 있습니다. Private LLM 게이트웨이는 다른 모든 클라우드 엔드포인트처럼 호출하는 API이지만, 이 게이트웨이는 신뢰 실행 환경(TEE) 내부에서 작동합니다. TEE의 간단한 설명은 칩이 그 안에 실행되는 모든 메모리를 암호화한다는 것입니다. 따라서 호스트 머신과 이를 운영하는 사람들은 그 안에 무엇이 있는지 읽을 수 없습니다. 클라우드처럼 하드웨어를 임대하지만, 프라이버시는 칩에 의해 강제되며 로컬 방식에 더 가깝습니다.
예를 들어, SayGM은 게이트웨이를 Intel TDX 기밀 VM에서 실행하며, 메커니즘을 알고 싶다면 AI 팀을 위한 신뢰 실행 환경 작동 방식에 대해 매우 잘 설명합니다.
이러한 게이트웨이는 두 가지 다른 보증(guarantee)이 있으며, 이들을 혼동해서는 안 됩니다:
- 기밀 모델(Confidential models). 오픈 웨이트(Open-weight) 모델은 엔클레이브 자체 내부에서 실행됩니다. 프롬프트는 모델을 실행하는 하드웨어 내부에서만 복호화되므로, 게이트웨이도 읽을 수 없고 호스트도 읽을 수 없습니다.
- 프론티어 모델(Frontier models). 게이트웨이를 통과하는 경로는 봉인되지만, Anthropic이나 OpenAI가 모델을 제공하는 경우 여전히 프롬프트를 볼 것입니다. 다만 개인 정보를 마스킹할 수 있는 옵션이 종종 있습니다.
Private LLM 게이트웨이의 장점은 다음과 같습니다:
- 선행 비용 또는 비싼 계약 없음
- 사용량 기반 지불(Pay per use)
- 데이터가 로깅되지 않음을 보장하는 하드웨어 수준 검증
하지만, Amazon Bedrock처럼 프론티어 모델에 대한 진정으로 사적인 엔터프라이즈 액세스를 제공할 수는 없습니다.
다른 측면: 공유 에이전트 내의 사적 메모리
위의 모든 내용은 모델로 전달되는 프롬프트를 보호하는 것에 관한 것입니다. 일단 에이전트에 메모리를 부여하고 여러 사람이 이를 사용하게 하면, 이제는 사용자들 내부에서 발생하는 유출을 통제해야 합니다.
메모리를 가진 공유 에이전트란 접근 권한만 있는 누구나 그 에이전트로부터 다른 사람들이 공유했던 정보를 캐내려고 시도할 수 있다는 것을 의미합니다. 예를 들어, 회사만을 위한 완전히 사적인 AI 에이전트를 설정했다고 하더라도, 그 에이전트가 인사팀의 사적인 대화를 관련 직원들에게 공유하기 시작할 수 있습니다.
이에 대한 연구는 안심할 만하지 않습니다. ServiceNow AI Research와 Mila에서 진행한 2026년 벤치마크 PiSAs에서는 다중 사용자 에이전트 시스템을 테스트했으며, 테스트 실행의 75% 이상에서 적어도 하나의 개인 정보 유출 위반 사례를 발견했고, 공유 메모리는 상황을 현저히 악화시켰습니다. 별도로 MEXTRA 논문에서는 에이전트 메모리에 저장된 사적인 상호작용이 블랙박스 프롬프트만으로도 추출될 수 있음을 보여주었습니다.
세상에서 가장 사적인 LLM을 실행하고 있어도, 그 에이전트가 인턴에게 지난주 창업자가 요청했던 내용을 말해줄 수 있습니다. 도움이 되는 몇 가지 사항들이 있습니다:
- 기본적으로 사용자별로 메모리 범위를 제한하고, 공유 메모리는 개인이 특정 노트에 동의할 때만 사용하도록 합니다.
- 저장 계층에서 접근을 강제합니다. 시스템 프롬프트에
물량이 적을 때는 토큰당 비용을 지불하는 기밀(Confidential) 등급이 좋습니다. 구매할 하드웨어가 없기 때문입니다. 단일 모델에 대해 높고 꾸준한 물량이라면, (자신들의 시간은 제외한다면) 상환된 소유 하드웨어(owned hardware)가 이길 수 있습니다.
어떤 것을 선택해야 할까요?
작업량이 일정하고 사용자 본인만 사용하는 경우라면, 로컬 LLM을 논하기 어렵습니다. SLA와 법무팀이 이미 이해하는 계약서가 필요한 최고 수준의 모델이 필요하다면, 클라우드를 사용하고 보존(retention) 페이지를 제대로 읽어보세요. 만약 아무도 읽지 않았으면 하는 데이터 위에서 에이전트(agents)를 실행하는 소규모 팀이라면, 신뢰하기보다는 직접 검증하고 싶은 경우에 적합한 옵션이 바로 프라이빗 LLM 게이트웨이(private LLM gateway)입니다.
어떤 방식으로든 프라이빗 LLM을 선택하더라도, 에이전트가 다중 사용자(multi-user)로 전환되기 전에 메모리 문제를 해결하세요. 그것이 사람들이 두 번째로 발견하는 누수 지점입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기