로컬독스에서 스쿠피로: 온디바이스 AI가 하이브리드 업무 에이전트가 되기까지
로컬독스가 스쿠피(Scoopie)로 바뀌었습니다.
이름만 바꾼 것은 아닙니다. 그렇다고 온디바이스 구조에서 하이브리드 구조로 전환하면서 곧바로 스쿠피가 된 것도 아닙니다.
실제 변화는 세 단계에 걸쳐 일어났습니다.
단계 | 제품명 | 작동 구조 | 제품의 역할 |
|---|---|---|---|
1단계 | 로컬독스 | 100% 온디바이스 | 내 PC에서 문서를 검색하고 질문하는 AI |
2단계 | 로컬독스 | Local RAG + Cloud LLM | 문서는 로컬에서 찾고, 최신 AI로 더 좋은 답변 생성 |
3단계 | 스쿠피 | Local RAG + Cloud LLM | 문서 검색을 넘어 검토·비교·정리·초안까지 맡기는 업무 에이전트 |
먼저 기술 구조가 바뀌었습니다. 로컬독스라는 이름으로 하이브리드 구조를 약 3~4개월간 운영한 뒤, 제품이 단순한 문서 검색 AI를 넘어 업무를 맡길 수 있는 에이전트로 확장되면서 이름도 스쿠피로 변경했습니다.
따라서 이번 변화의 핵심은 “클라우드 AI를 사용하기 시작해서 이름을 바꿨다”가 아닙니다.
더 좋은 답변을 위해 기술 구조를 먼저 바꿨고, 그 구조에서 제품의 역할이 달라졌기 때문에 이름도 스쿠피로 바뀌었습니다.
처음에는 100% 온디바이스 AI였습니다
로컬독스는 내 컴퓨터 안에서 문서를 읽고 답하는 온디바이스 AI로 출발했습니다.
문서 저장과 검색은 물론, 답변 생성까지 사용자의 PC에서 처리하는 구조였어요. 회사 문서를 외부 서비스에 올리지 않고 사용할 수 있다는 것이 가장 중요한 가치였습니다.
계약서, 사내 규정, 감사 조서, 기술 매뉴얼처럼 민감한 자료를 챗GPT나 다른 클라우드 서비스에 통째로 업로드하기 어려운 조직에는 분명한 장점이 있었습니다.
문서 원본이 사용자의 PC에 남습니다.
외부 서버에 자료를 저장하지 않습니다.
인터넷 연결 없이도 사용할 수 있습니다.
별도의 클라우드 AI 계정 없이 문서와 대화할 수 있습니다.
우리는 처음에 이 구조가 보안과 편의성을 모두 해결할 수 있다고 생각했습니다.
하지만 사용자들이 실제 업무 자료를 연결하고 더 복잡한 요청을 하기 시작하면서, 100% 온디바이스 방식의 한계도 명확해졌습니다.
문서는 잘 찾았지만, 복잡한 업무까지 잘하기는 어려웠습니다
작은 로컬 AI 모델도 문서 요약이나 단순한 질의응답은 수행할 수 있습니다.
하지만 기업의 실제 업무는 단순히 문장 하나를 찾는 것으로 끝나지 않았습니다.
“작년 계약서와 올해 계약서에서 변경된 조항을 표로 비교해 주세요.”
“세 개의 펀드 문서에서 납입 금액과 기한, 계좌 정보를 각각 찾아 정리해 주세요.”
“개정 전후 인사 규정을 비교하고 직원 공지문 초안까지 작성해 주세요.”
“감사 조서의 수치가 다른 보고서와 일치하는지 검토해 주세요.”
이런 요청을 처리하려면 여러 문서를 오가며 정보를 찾고, 서로 다른 내용을 비교하고, 빠진 근거를 다시 확인한 뒤, 사용자가 바로 활용할 수 있는 결과물로 정리해야 합니다.
일반적인 업무용 PC에서 실행할 수 있는 로컬 모델은 복잡한 추론과 긴 문맥 처리에서 최신 클라우드 AI 모델과 차이가 날 수밖에 없었습니다. 사용자의 PC 사양에 따라 속도와 결과 품질이 달라지는 문제도 있었어요.
AMD의 온디바이스 RAG 설명에서도 로컬 LLM의 성능이 기기의 연산 능력과 메모리 대역폭에 크게 영향을 받는다고 설명합니다. 충분한 성능을 내려면 모델을 압축하거나, 고성능 GPU·NPU에 맞춰 별도로 최적화해야 합니다.
결국 우리는 선택해야 했습니다.
보안을 이유로 답변 품질의 한계를 감수할 것인지, 좋은 답변을 위해 문서 전체를 클라우드에 올릴 것인지 말이에요.
하지만 두 가지 중 하나를 반드시 포기할 필요는 없었습니다.
로컬 RAG와 Cloud LLM으로 역할을 나눴습니다
우리가 내린 결론은 모든 작업을 한곳에서 처리하지 않는 것이었습니다.
문서를 보관하고 필요한 근거를 찾는 일은 사용자의 PC가 맡습니다. 찾은 근거를 이해하고 비교해 결과물을 만드는 일은 최신 Cloud LLM이 맡습니다.
쉽게 말하면 이렇습니다.
회사 서류 전체를 외부 전문가에게 넘기는 대신, 내 사무실에서 질문과 관련된 페이지만 찾아 필요한 부분을 전달합니다. 전문가는 전달받은 내용으로 답변을 작성하고, 사용자는 결과의 근거를 다시 원문에서 확인합니다.
이 과정에서 사용하는 기술이 로컬 RAG입니다.
RAG는 AI에게 모든 문서를 한꺼번에 읽히는 대신, 질문과 관련 있는 부분을 먼저 찾아 답변의 근거로 제공하는 방식입니다. Red Hat의 RAG 설명에 따르면 RAG는 전체 문서가 아니라 관련성이 높은 부분을 AI에 전달해 답변의 정확성과 효율을 높일 수 있습니다.
로컬독스는 이 검색 과정을 사용자의 PC에서 수행하도록 구조를 변경했습니다.
문서 원본을 사용자의 PC에 연결합니다.
문서를 검색하기 위한 정보도 PC에서 관리합니다.
질문이 들어오면 관련 있는 문장과 표를 PC에서 먼저 찾습니다.
답변에 필요한 암호화된 컨텍스트만 Cloud LLM에 전달합니다.
Cloud LLM이 해당 근거를 바탕으로 답변이나 결과물을 만듭니다.
답변에 출처를 표시하고, 클릭하면 원문의 근거 문장을 보여줍니다.
데이터와 작업 | 처리 위치 |
|---|---|
연결한 문서 원본 | 사용자 PC |
문서 검색을 위한 정보 | 사용자 PC |
질문과 관련된 근거 검색 | 사용자 PC |
답변에 필요한 컨텍스트 | 암호화해 Cloud LLM에 전송 |
답변 작성과 복잡한 추론 | Cloud LLM |
출처와 원문 확인 | 사용자 PC의 원본 문서 |
이 구조로 바뀐 뒤에도 제품명은 한동안 로컬독스였습니다.
우리는 약 3~4개월 동안 하이브리드 구조로 제품을 운영하며, 실제 사용자들이 어떤 업무를 맡기고 어디에서 가치를 느끼는지 확인했습니다.
하이브리드 구조로 바꾸자 질문의 수준이 달라졌습니다
사용자들은 더 이상 “이 문서에 이런 내용이 있나요?”라고만 묻지 않았습니다.
여러 자료를 비교하고, 누락된 내용을 검토하고, 표를 만들고, 보고서나 이메일 초안을 작성해 달라고 요청하기 시작했습니다.
문서를 검색하는 도구에서, 자료를 바탕으로 일을 수행하는 도구로 사용 방식이 달라진 것입니다.
로컬 RAG는 필요한 근거를 PC 안에서 찾았습니다. Cloud LLM은 그 근거를 바탕으로 비교·분류·검토·정리 같은 복잡한 작업을 수행했습니다.
하이브리드 구조는 단순히 답변을 조금 더 자연스럽게 만드는 변화가 아니었습니다. 제품이 처리할 수 있는 업무의 범위 자체를 넓혔습니다.
여러 문서를 함께 검토할 수 있게 됐습니다
하나의 문서에서 문장을 찾는 것을 넘어, 여러 계약서와 보고서에 흩어진 내용을 비교하고 공통점과 차이점을 정리할 수 있게 됐습니다.
질문이 모호해도 의도를 좁힐 수 있게 됐습니다
정확한 키워드를 입력해야만 결과를 보여주는 검색기가 아니라, 질문의 맥락을 해석하고 필요한 정보를 추가로 찾는 방향으로 발전했습니다.
답을 넘어 결과물을 만들 수 있게 됐습니다
찾은 내용을 표로 정리하거나, 검토 결과를 요약하거나, 보고서와 공지문 초안을 만드는 등 다음 업무까지 이어갈 수 있게 됐습니다.
최신 AI 모델의 성능을 활용할 수 있게 됐습니다
사용자마다 고성능 GPU를 준비하지 않아도 복잡한 추론과 문서 이해에 강한 최신 모델을 활용할 수 있게 됐습니다. 모델이 개선될 때마다 직원들의 PC를 교체할 필요도 없습니다.
이 시점부터 ‘로컬 문서 검색’이라는 이름만으로는 제품의 역할을 충분히 설명하기 어려워졌습니다.
3~4개월 뒤, 로컬독스가 스쿠피가 됐습니다
스쿠피라는 이름은 하이브리드 구조로 전환한 순간에 만들어지지 않았습니다.
기술 구조가 먼저 바뀌었고, 그 구조로 제품을 운영하면서 사용자들이 스쿠피에게 더 넓은 업무를 맡기기 시작했습니다. 이후 제품의 역할을 다시 정의하면서 이름도 바꿨습니다.
로컬독스라는 이름은 제품의 출발점을 잘 표현했습니다.
로컬에서 작동합니다.
내 문서를 읽습니다.
문서에서 필요한 내용을 찾아줍니다.
하지만 스쿠피가 지향하는 역할은 그보다 넓습니다.
여러 자료를 검토합니다.
문서 간 차이를 비교합니다.
필요한 정보를 추출하고 분류합니다.
표와 보고서 형태로 정리합니다.
답변과 결과물에 출처를 표시합니다.
반복되는 문서 업무를 하나의 흐름으로 처리합니다.
스쿠피는 단순한 사내 문서 검색기가 아니라, 업무 자료를 바탕으로 실제 작업을 수행하는 사내용 AI 업무보조 에이전트입니다.
제품명이 달라진 이유도 여기에 있습니다.
로컬독스가 ‘자료를 어디에서 찾는가’를 보여주는 이름이었다면, 스쿠피는 ‘자료를 바탕으로 어떤 일을 맡길 수 있는가’를 보여주는 이름입니다.
스쿠피는 100% 오프라인 AI가 아닙니다
하이브리드 구조를 설명할 때 가장 중요하게 구분해야 하는 부분입니다.
스쿠피는 최신 Cloud LLM으로 답변을 생성하기 때문에 기본적으로 인터넷 연결이 필요합니다. 답변을 만드는 데 필요한 컨텍스트도 클라우드 AI에 전송됩니다.
다만 연결한 문서 원본 전체를 외부 서버에 업로드하거나 저장하지는 않습니다.
스쿠피 공식 안내에 따르면 문서 원본과 연결한 자료는 사용자의 PC에서 관리됩니다. PC에서 질문과 관련된 내용을 먼저 검색하고, 답변에 필요한 암호화된 컨텍스트만 전송합니다.
전송된 데이터는 모델 학습에는 사용되지 않습니다. 감사 모니터링을 위해 구글 데이터센터에 일정 기간 보관된 뒤 자동 삭제됩니다.
따라서 스쿠피의 보안을 설명할 때 “어떤 데이터도 외부로 나가지 않는다”거나 “완전한 오프라인 AI”라고 표현해서는 안 됩니다.
정확한 설명은 다음과 같습니다.
문서 원본과 검색 과정은 사용자의 PC에 남기고, 답변에 필요한 암호화된 컨텍스트만 Cloud LLM에 전달합니다.
인터넷이 차단된 폐쇄망에서 모든 처리 과정을 내부에 두어야 하는 조직이라면 완전한 온프레미스 구성이 필요합니다. 스쿠피는 사내에 구축된 온프레미스 LLM을 활용하는 구성도 지원할 수 있지만, 기본 제품의 하이브리드 구조와는 구분해서 검토해야 합니다.
구조는 달라졌지만, 지키려는 원칙은 같습니다
100% 온디바이스에서 하이브리드 구조로 바뀌었다고 해서 로컬독스가 중요하게 생각했던 가치까지 사라진 것은 아닙니다.
1. 문서 원본은 사용자의 PC에서 관리합니다
스쿠피는 연결한 원본 문서를 클라우드 저장소에 통째로 올려놓고 검색하지 않습니다. 필요한 근거를 찾는 과정은 사용자 PC에서 수행합니다.
2. 답변의 출처를 직접 확인할 수 있습니다
업무용 AI는 자연스럽게 말하는 것만으로는 충분하지 않습니다. 실무자가 답변의 근거를 눈으로 확인할 수 있어야 합니다.
스쿠피는 답변에 출처를 표시하고, 출처를 클릭하면 원문의 해당 부분을 하이라이트해 보여줍니다.
3. 문서에 없는 내용은 구분하도록 설계했습니다
RAG는 AI가 조직 내부 문서의 근거를 활용하도록 해 부정확한 답변의 가능성을 낮춥니다. 스쿠피 역시 근거가 충분하지 않을 때 억지로 답을 만들기보다, 연결된 자료에서 확인되지 않는다는 사실을 구분하도록 설계했습니다.
4. 한국 기업이 사용하는 문서를 읽습니다
PDF뿐 아니라 HWP·HWPX와 Word 문서, 텍스트 파일 등을 지원합니다. PDF 안의 표와 수식, 이미지도 분석할 수 있으며 지원 형식은 계속 확대하고 있습니다.
기술을 바꾼 것이 아니라, 역할을 적절히 나눴습니다
온디바이스 AI와 클라우드 AI 중 하나가 항상 더 좋은 것은 아닙니다.
온디바이스 방식은 데이터 통제와 오프라인 사용에 강합니다. Cloud LLM은 복잡한 이해와 추론, 결과물 작성에서 강점을 가집니다.
중요한 것은 모든 작업을 한쪽에 몰아주는 것이 아니라, 각 작업을 가장 적합한 위치에 배치하는 것입니다.
스쿠피는 문서 저장과 검색은 로컬에서 처리하고, 복잡한 답변 생성은 Cloud LLM에 맡깁니다. 이를 통해 문서 원본을 외부에 저장하지 않으면서도, 일반적인 업무용 PC에서 최신 AI 모델의 성능을 활용할 수 있도록 했습니다.
이 선택을 한 뒤에도 한동안 제품 이름은 로컬독스였습니다.
그리고 약 3~4개월 동안 사용자들이 실제로 제품을 사용하는 모습을 지켜본 결과, 우리가 만들고 있는 제품은 더 이상 문서를 검색하는 도구에 머물러 있지 않았습니다.
자료를 읽고, 비교하고, 검토하고, 정리하고, 결과물을 만드는 에이전트에 가까워졌습니다.
그 변화에 맞춰 이름도 스쿠피로 바꿨습니다.
로컬독스의 원칙 위에서, 스쿠피의 역할로
로컬독스는 내 컴퓨터에서 문서를 안전하게 읽는 AI로 시작했습니다.
답변 품질과 업무 활용도를 높이기 위해 Local RAG와 Cloud LLM을 결합했고, 그 구조로 3~4개월 동안 제품을 운영했습니다.
그 과정에서 사용자가 원하는 것은 단순한 문서 검색이 아니라는 사실을 확인했습니다.
필요한 자료를 찾고, 여러 문서를 비교하고, 결과를 검증하고, 실제 업무에 사용할 수 있는 형태로 완성해 주는 AI가 필요했습니다.
그래서 로컬독스는 스쿠피가 됐습니다.
기존의 기술을 버리고 완전히 다른 제품이 된 것이 아닙니다. 문서 원본을 로컬에서 관리하고 출처를 검증한다는 원칙은 유지하면서, 최신 AI의 지능을 결합해 맡길 수 있는 업무의 범위를 넓힌 것입니다.
문서는 사용자의 PC에 두고, 필요한 근거만 찾아 최신 AI의 지능을 활용하는 것. 그리고 모든 결과를 다시 원문에서 검증할 수 있게 하는 것.
이것이 로컬독스에서 시작해 스쿠피로 이어진 변화의 핵심입니다.
우리 회사 문서에서는 스쿠피가 어떤 결과물을 만드는지 궁금하다면 직접 확인해 보세요.