스쿠피는 온디바이스 AI일까? 문서는 로컬에, 답변은 클라우드에 두는 이유

AI 업무보조 에이전트, 스쿠피를 소개할 때 가장 자주 받는 질문 중 하나가 있어요.

“스쿠피는 온디바이스 AI인가요?”

짧게 답하면, 완전한 온디바이스 AI는 아니에요.

스쿠피는 문서의 저장과 검색은 사용자 PC에서 처리하고, 답변 생성은 클라우드의 고성능 AI에 맡기는 하이브리드 구조예요. 기술적으로는 Local RAG와 Cloud LLM을 결합한 방식이라고 부를 수 있어요.

조금 더 쉽게 표현하면 다음과 같아요.

문서를 보관하고 필요한 근거를 찾는 일은 내 컴퓨터가 하고, 찾아낸 근거를 바탕으로 이해하기 쉬운 답변을 작성하는 일은 클라우드 AI가 담당해요.

처음부터 이런 구조였던 것은 아니에요. 스쿠피의 초기 버전은 문서 검색부터 답변 생성까지 모두 PC에서 처리하는 100% 온디바이스 AI를 지향했어요.

그런데 실제 사용자에게 제품을 제공하면서 한 가지 현실적인 문제를 확인했어요. 보안은 훌륭했지만, 일반적인 사무용 PC에서 실행하는 로컬 언어모델의 답변 성능과 속도가 업무용 제품으로 사용하기에는 충분하지 않았던 것이죠.

결국 스쿠피는 ‘모든 것을 로컬에서 처리하는가’보다 더 중요한 질문을 던지게 됐어요.

“문서 원본을 보호하면서도, 실제 업무에 쓸 수 있는 수준의 답변을 제공하려면 어떤 부분을 로컬에 남겨야 할까?”

그 답이 지금의 Local RAG와 Cloud LLM을 결합한 구조예요.

온디바이스 AI란 무엇일까요?

온디바이스 AI는 AI 작업을 외부 서버가 아니라 사용자의 스마트폰이나 PC 안에서 처리하는 방식을 말해요.

완전한 온디바이스 AI에서는 다음 과정이 모두 기기 안에서 이뤄져요.

• 문서를 읽고 정리하는 작업

• 검색용 데이터를 만드는 작업

• 질문과 관련된 문장을 찾는 작업

• 답변을 생성하는 작업

• 문서와 대화기록을 저장하는 작업

문서와 질문이 기기 밖으로 나가지 않기 때문에 보안 측면에서는 가장 명확해요. 인터넷에 연결되지 않은 상태에서도 사용할 수 있다는 장점도 있고요.

하지만 답변을 만드는 언어모델까지 PC에서 실행하려면 충분한 연산 성능과 메모리가 필요해요.

구글은 Android Studio의 로컬 모델 안내에서 로컬 모델이 클라우드 기반 Gemini보다 정확도가 낮고, 응답이 느리며, 사용할 수 있는 기능도 제한될 수 있다고 설명해요. AMD 역시 온디바이스 LLM은 클라우드 환경보다 사용할 수 있는 연산 능력과 메모리 대역폭이 제한된다고 설명하고요.

정리하면 완전한 온디바이스 AI에는 다음과 같은 교환관계가 있어요.

보안만 놓고 보면 100% 온디바이스가 가장 단순한 답이에요. 하지만 사용자가 실제 업무에 활용하려면 답변의 정확도와 속도, 복잡한 질문을 이해하는 능력도 중요해요.

스쿠피도 처음에는 100% 온디바이스 AI였어요

스쿠피의 초기 방향은 명확했어요.

문서 원본과 검색 데이터, 대화기록뿐 아니라 답변을 만드는 언어모델까지 모두 사용자의 PC에서 실행하는 것이었어요. 계약서, 연구자료, 내부 보고서처럼 외부로 보내기 어려운 문서를 안전하게 분석하는 것이 가장 중요한 목표였기 때문이에요.

이 방식은 보안 측면에서 분명한 장점이 있었어요.

• 문서 원본이 외부 서버로 전송되지 않았어요.

• 문서에서 만든 검색 데이터도 PC에만 저장됐어요.

• 질문과 답변도 외부 계정에 기록되지 않았어요.

• 인터넷 연결 없이도 사용할 수 있었어요.

문제는 실제 사용자 경험이었어요.

로컬에서 실행할 수 있는 언어모델은 최신 클라우드 모델보다 작을 수밖에 없었어요. 문서에서 관련 문장을 찾더라도 이를 정확하게 해석하고, 여러 자료의 내용을 비교하고, 실무자가 바로 사용할 수 있는 답변으로 정리하는 능력에는 차이가 있었어요.

사용자의 PC 환경도 모두 달랐어요. 어떤 PC에서는 충분히 빠르게 동작했지만 오래된 PC에서는 답변 생성이 느리거나 다른 업무를 함께 하기 어려운 경우도 있었어요.

보안은 지켰지만 정작 사용자가 답변을 기다리거나, 결과를 다시 챗GPT와 같은 클라우드 AI에서 정리해야 한다면 업무용 제품으로서의 의미가 줄어들어요.

그래서 스쿠피는 문서 보안과 답변 성능을 서로 포기해야 하는 문제로 보지 않았어요. 대신 두 작업을 나눴어요.

Local RAG와 Cloud LLM은 각각 무슨 일을 할까요?

RAG는 AI가 사용자의 자료에서 질문과 관련된 근거를 먼저 찾은 다음, 그 근거를 바탕으로 답변하도록 만드는 방식이에요.

기술 용어가 어렵다면 다음과 같이 이해하면 돼요.

• Local RAG: 내 컴퓨터 안에서 자료를 보관하고 필요한 근거를 찾아주는 사서

• Cloud LLM: 사서가 찾아준 근거를 읽고 이해하기 쉬운 답변을 작성하는 실무자

스쿠피에서는 이 두 역할이 서로 다른 곳에서 실행돼요.

전체 흐름은 다음과 같아요.

파일 연동 → 로컬에서 문서 분석 → 로컬에서 관련 근거 검색 → 필요한 문맥만 암호화해 전송 → 클라우드 AI가 답변 생성 → 답변과 대화기록을 PC에 저장

이 구조에서 중요한 것은 파일 전체를 먼저 클라우드에 올려놓고 검색하는 것이 아니라는 점이에요.

예를 들어 200페이지짜리 계약서 30개를 연동하고 “자동 갱신 조건과 해지 통보 기한을 비교해 줘”라고 질문했다고 가정해 볼게요.

1. 사용자 PC에서 해당 질문과 관련된 조항을 찾아요.

2. 답변에 필요한 조항과 관련 문맥을 클라우드 AI에 전달해 비교 결과를 만들어요.

계약서 30개의 원본 전체가 클라우드에 저장되는 것이 아니라, 로컬 검색을 통해 선별된 관련 문맥이 답변 생성에 사용되는 방식이에요.

그렇다면 무엇이 PC에 남고, 무엇이 클라우드로 갈까요?

스쿠피의 보안 구조를 이해하려면 ‘로컬에 남는 데이터’와 ‘답변을 위해 전송되는 데이터’를 분리해 봐야 해요.

사용자 PC에 저장되는 데이터

다음 데이터는 사용자 PC에서 저장하고 관리해요.

• 연동한 문서 원본

• 문서를 검색하기 위해 만든 로컬 검색 데이터

• 파일명과 문서 위치 등의 정보

• 사용자의 대화기록

• 스쿠피가 생성한 답변과 출처 정보

문서 원본과 검색 데이터가 스쿠피의 클라우드 서버에 복제되는 구조는 아니에요. 문서 검색 역시 사용자 PC에서 이뤄져요.

답변 생성을 위해 전달되는 데이터

답변을 만들 때는 다음 정보가 클라우드 LLM으로 전달돼요.

• 사용자가 입력한 질문

• 로컬 검색에서 찾은 관련 문맥

• 답변 생성에 필요한 지시사항

• 생성된 답변 결과

전송되는 문맥은 암호화된 상태로 전달돼요. 사용자 데이터는 AI 모델 학습이나 성능 개선에 사용되지 않아요.

하지만 여기서 “어떤 로그도 남지 않는다”고 설명하면 정확하지 않아요.

스쿠피 서버는 답변 처리를 위해 전달된 데이터를 별도로 보관하지 않지만, 스쿠피가 사용하는 API에는 별도의 안전성 정책이 적용돼요.

API에서는 데이터를 어떻게 처리할까요?

Google의 API 유료 서비스 약관에 따르면 프롬프트와 답변은 Google 제품 개선에 사용되지 않아요.

다만 Google은 API의 오남용 방지와 서비스 안전, 법률 및 규제상 필요한 공개를 위해 다음 데이터를 55일간 보관해요.

• API에 전달된 질문

• 질문과 함께 전달된 관련 문맥

• Gemini API가 생성한 답변

이 데이터는 일반적인 AI 모델 학습이나 미세조정에 사용되지 않아요. 금지된 사용 정책을 위반했는지 확인하고 서비스를 보호하기 위한 목적으로만 사용돼요.

대부분의 검사는 자동화된 시스템으로 진행돼요. 특정 프로젝트나 요청이 안전 필터에 의해 의심스러운 사용으로 표시되면 승인된 Google 담당자가 해당 내용을 검토할 수 있어요.

따라서 스쿠피의 데이터 처리 방식을 정확히 정리하면 다음과 같아요.

• 문서 원본은 사용자 PC에 남아요.

• 문서 검색 데이터와 대화기록도 사용자 PC에서 관리해요.

• 스쿠피 서버는 사용자의 문서와 대화기록을 저장하지 않아요.

• 답변에 필요한 질문과 관련 문맥은 Gemini API로 전달돼요.

• 전달된 데이터는 일반적인 모델 학습에 사용되지 않아요.

• Gemini API는 안전성 및 오남용 방지를 위해 해당 데이터를 55일간 보관해요.

• 안전 시스템에 표시된 콘텐츠는 승인된 Google 담당자가 검토할 수 있어요.

• 답변 생성에는 인터넷 연결이 필요해요.

스쿠피는 ‘어떤 데이터도 외부로 나가지 않는 완전한 오프라인 AI’가 아니에요. 문서 원본과 검색 기반은 로컬에 두고, 답변 생성에 필요한 최소한의 문맥만 클라우드 모델에 전달하는 하이브리드 AI예요.

왜 문서 검색은 로컬에 남기고, 답변만 클라우드에 맡겼을까요?

RAG를 구성하는 모든 작업이 같은 장소에서 실행될 필요는 없어요.

NVIDIA도 하이브리드 RAG의 대표적인 구조로 검색용 데이터 생성과 문서 검색은 로컬 PC에서 실행하고, 연산량이 큰 언어모델의 답변 생성은 원격 GPU에서 처리하는 방식을 설명해요.

스쿠피가 이 구조를 선택한 이유도 같아요.

1. 문서 원본 전체를 클라우드에 저장하지 않기 위해서예요

일반적인 클라우드 문서 AI에서는 분석할 파일을 서비스에 먼저 업로드해요. 이후 검색과 답변 생성이 모두 서비스 제공사의 서버에서 이뤄져요.

스쿠피는 파일을 업로드하는 대신 PC에 있는 파일을 연동해요. 원본과 검색 데이터가 로컬에 남기 때문에 계약서나 연구자료 전체를 외부 계정에 저장하지 않아도 돼요.

2. 최신 클라우드 모델의 답변 성능을 활용하기 위해서예요

로컬 모델은 보안과 오프라인 사용 측면에서 유리하지만, 일반적인 사무용 PC에서 실행할 수 있는 모델의 크기에는 한계가 있어요.

복잡한 질문을 이해하거나 여러 문서의 내용을 비교하고, 표를 만들고, 조건을 구분해 설명하는 작업에서는 최신 클라우드 모델이 더 안정적인 결과를 제공할 수 있어요.

스쿠피는 문서 전체를 클라우드로 보내지 않으면서 클라우드 모델의 추론과 글쓰기 능력을 활용하기 위해 역할을 나눴어요.

3. 사용자의 PC 사양에 따른 차이를 줄이기 위해서예요

일반적인 사무용 PC에서도 스쿠피를 사용할 수 있어요. 다만 로컬에서 문서를 분석하고 검색 데이터를 만들기 때문에 오래된 PC에서 대량의 문서를 처음 연동할 때는 처리 속도가 다소 느릴 수 있어요.

답변 생성까지 로컬 PC에 맡겼다면 PC 사양에 따른 차이는 훨씬 커졌을 거예요. 답변 생성을 클라우드에서 처리하면서 사용자마다 크게 달라질 수 있는 성능 차이를 줄였어요.

4. 문서 근거와 답변 능력을 모두 확보하기 위해서예요

클라우드 모델에 질문만 전달하면 모델은 사용자의 사내 문서를 알 수 없어요. 반대로 로컬 검색만으로는 찾아낸 자료를 종합하고 설명하는 데 한계가 있어요.

스쿠피는 로컬 검색으로 근거를 찾고 클라우드 모델로 답변을 정리해요. 답변에는 근거가 된 파일과 문장을 함께 표시하고, 출처를 클릭하면 원문의 해당 내용을 확인할 수 있어요.

자료에서 답을 찾지 못하면 근거 없이 내용을 만들어내는 대신 찾을 수 없다고 답하도록 설계돼 있어요.

100% 온디바이스·클라우드 AI·스쿠피의 차이

세 가지 구조를 비교하면 스쿠피가 어느 위치에 있는지 더 쉽게 이해할 수 있어요.

100% 온디바이스 AI는 외부 전송이 전혀 허용되지 않는 환경에 적합해요. 일반 클라우드 AI는 공개 자료나 외부 저장이 허용된 문서를 빠르게 분석할 때 편리하고요.

스쿠피는 그 중간에 있어요.

문서 원본 전체를 클라우드에 올릴 수는 없지만, 답변에 필요한 일부 문맥을 기업용 API로 전달하는 것은 허용되는 환경에 적합해요.

실제 사용자는 왜 로컬 저장에 반응했을까요?

스쿠피 사용자 피드백에서 반복해서 등장한 직군은 연구자, 교수, 대학원생, 변호사, 법무팀, 회계사, 공무원, 컨설턴트 등이었어요.

이들이 다루는 자료에는 공통점이 있었어요.

한 사용자는 개인문서와 비공개 기업자료가 서비스 회사로 전달되지 않기를 원하면서, 어디까지 로컬에서 처리되고 어디부터 서버에서 처리되는지 더 친절하게 설명해 달라고 요청했어요.

법률 분야 사용자들은 사건기록과 비공개 자료, 계약서를 다룰 때 문서 원본을 클라우드에 올리는 것에 부담을 느꼈어요. 연구자들은 논문과 연구자료가 많을 뿐 아니라 저작권과 미공개 데이터에도 민감했고요.

사용자들이 Local RAG나 Cloud LLM이라는 기술 용어 자체에 반응한 것은 아니었어요. 실제로 중요하게 느낀 것은 다음과 같은 경험이었어요.

• 사용하던 폴더와 파일을 그대로 연동할 수 있어요.

• 문서 원본 전체를 별도의 클라우드 저장 공간에 올리지 않아도 돼요.

• 한 번 연동한 여러 자료에 반복해서 질문할 수 있어요.

• 답변의 근거가 된 원문을 직접 확인할 수 있어요.

• 개인용 AI 계정에 민감한 파일을 계속 업로드하지 않아도 돼요.

기술 구조보다 “내 자료가 어디에 남는지 설명할 수 있다”는 점이 더 중요했던 것이죠.

하이브리드 구조에도 단점은 있어요

스쿠피의 구조를 설명하면서 장점만 이야기해서는 안 돼요. Local RAG와 Cloud LLM을 결합했기 때문에 생기는 한계도 분명히 있어요.

1. 일부 문맥은 외부 API로 전달돼요

문서 원본 전체는 외부 서버에 저장되지 않지만, 답변을 만드는 데 필요한 관련 문맥은 Gemini API로 전달돼요.

회사 정책이 “원본 파일 전체의 클라우드 저장 금지”라면 검토할 수 있지만, “문서 내용은 한 문장도 외부로 전송하면 안 됨”이라면 적합하지 않을 수 있어요.

2. 로컬 문서 분석에 PC 자원을 사용해요

파일 연동과 문서 분석, 검색 데이터 생성은 사용자 PC에서 실행돼요. 일반적인 사무용 PC에서 사용할 수 있지만 오래된 PC에서 매우 많은 자료를 처음 연동하면 속도가 느려질 수 있어요.

3. 일반 AI보다 앱 용량이 커요

문서 처리 도구와 로컬 검색 기능, 검색 데이터를 관리하는 구성요소가 앱에 포함돼 있어 일반적인 웹 채팅 서비스보다 설치 용량이 클 수 있어요.

이러한 부담은 문서 검색을 외부 서버가 아니라 사용자 PC에서 처리하기 위해 필요한 부분이에요.

스쿠피는 어떤 조직에 적합할까요?

다음 조건에 해당한다면 스쿠피의 하이브리드 구조를 검토해 볼 수 있어요.

• 계약서와 연구자료 등 원본 전체를 클라우드에 올리기 어려워요.

• PC나 사내 파일서버에 이미 많은 업무 문서가 쌓여 있어요.

• 문서를 별도의 AI 서비스에 매번 업로드하고 관리하고 싶지 않아요.

• 최신 클라우드 AI 수준의 답변 성능은 필요해요.

• 답변만 받는 것이 아니라 근거가 된 원문까지 확인해야 해요.

• 회사 정책상 기업용 API를 통한 최소 문맥 전송은 허용돼요.

반대로 다음 환경에서는 일반 스쿠피보다 별도의 구축 방식을 검토해야 해요.

• 인터넷이 차단된 폐쇄망에서 사용해야 해요.

• 문서 내용 일부도 외부 API로 전달할 수 없어요.

• 모든 추론 과정을 조직 내부 서버에서 처리해야 해요.

• 데이터의 물리적 처리 위치에 관한 강한 규제 요건이 있어요.

이러한 조직에는 언어모델과 검색 시스템을 모두 내부 환경에서 실행하는 온프레미스 구성이 더 적합할 수 있어요.

자주 묻는 질문

스쿠피는 완전한 온디바이스 AI인가요?

아니요. 문서 원본과 검색 데이터, 대화기록은 사용자 PC에서 관리하지만 답변 생성은 Cloud LLM이 담당해요. 따라서 Local RAG와 Cloud LLM을 결합한 하이브리드 AI라고 설명하는 것이 정확해요.

연동한 문서 전체가 클라우드로 전송되나요?

아니요. 문서 원본은 사용자 PC에 남아요. 스쿠피가 로컬에서 질문과 관련된 근거를 찾은 다음, 답변 생성에 필요한 문맥만 암호화해 클라우드 LLM으로 전송해요.

클라우드로 전달된 내용이 AI 학습에 사용되나요?

스쿠피가 사용하는 Gemini API 유료 서비스에서는 질문과 관련 문맥, 답변을 Google 제품 개선에 사용하지 않아요. 다만 오남용 방지와 서비스 안전, 법률 및 규제상 필요한 처리를 위해 55일간 보관해요.

스쿠피 담당자가 제 대화기록을 볼 수 있나요?

대화기록은 사용자 PC에서 관리되며 스쿠피 서버에 계정별 대화 목록으로 저장되지 않아요. 따라서 스쿠피가 사용자의 전체 대화기록을 볼 수 있는 구조가 아니에요.

다만 Gemini API로 전달된 개별 요청이 안전 시스템에 의해 의심스러운 사용으로 표시되면 승인된 Google 담당자가 검토할 수 있어요.

일반 사무용 PC에서도 사용할 수 있나요?

네. 일반적인 사무용 PC에서 사용할 수 있어요. 다만 파일 분석과 검색 데이터 생성이 로컬에서 실행되므로 오래된 PC에서 대량의 문서를 처음 연동하면 처리 속도가 느려질 수 있어요.

왜 완전한 온디바이스 방식을 유지하지 않았나요?

사용자 PC에서 실행할 수 있는 로컬 언어모델만으로는 답변의 속도와 복잡한 추론 능력, 여러 문서를 종합하는 성능을 업무용 수준으로 일관되게 제공하기 어려웠기 때문이에요.

문서 원본과 검색은 로컬에 남기면서 답변 생성에 최신 클라우드 모델을 활용하는 것이 보안과 사용성 사이에서 더 현실적인 선택이라고 판단했어요.

결론: 스쿠피는 ‘로컬에 중요한 것을 남기는’ 하이브리드 AI예요

스쿠피는 엄밀한 의미의 완전한 온디바이스 AI는 아니에요.

문서 원본과 검색 데이터, 대화기록은 사용자 PC에 저장하고, 문서 검색도 로컬에서 처리해요. 대신 검색된 근거를 해석하고 답변으로 정리하는 과정에는 클라우드 LLM을 사용해요.

처음에는 모든 과정을 PC에서 처리하는 방식을 선택했지만, 실제 사용자 환경에서는 답변 성능과 속도, PC 사양에 따른 차이가 업무용 제품의 큰 장벽이 됐어요.

그래서 스쿠피는 보안을 포기하고 모든 자료를 클라우드로 옮기는 대신, 역할을 나눴어요.

중요한 자료를 보관하고 찾는 일은 로컬에서, 높은 지능이 필요한 답변 생성은 클라우드에서 처리해요.

이 구조가 모든 조직의 정답은 아니에요. 문서 내용 일부도 외부로 전송할 수 없는 조직에는 완전한 온프레미스 환경이 필요해요.

하지만 문서 원본 전체의 클라우드 업로드는 피하면서 최신 AI의 답변 성능과 원문 출처 검증 기능을 활용하고 싶다면, Local RAG와 Cloud LLM을 결합한 스쿠피가 현실적인 선택지가 될 수 있어요.

우리 회사 문서로 스쿠피 사용해 보기

참고자료

1. Private AI Cowork Agent for Sensitive Files | Scoopie

2. Abuse monitoring | Gemini API | Google AI for Developers

3. Gemini API Additional Terms of Service | Google AI for Developers

4. Optimize AI Model Performance and Maintain Data Privacy with Hybrid RAG | NVIDIA Technical Blog

5. Use a local model | Android Studio | Android Developers

6. RAG with Hybrid LLM on AMD Ryzen AI Processors | AMD

7. Implement RAG while meeting data residency requirements using AWS hybrid and edge services | AWS

8. What is on-device processing? A Google engineer explains | Google

9. Harnessing Large Language Models Locally: Empirical Results and Implications for AI PC