옵시디언 보관함을 프라이버시 중심 로컬 AI 엔지니어로 바꾸기

URL: https://www.youtube.com/watch?v=Ndp5VaqFrl0
날짜: 2026-10-11
채널: AI Engineer
발표: Filip Makraduli (Superlinked)
원문 제목: Turning My Obsidian Vault Into a Local AI Engineer
영상 길이: 47:25
태그: #AI #LLM #LocalAI #MCP #Obsidian #Privacy #OCR #Superlinked #Inference #SelfHosted

---

📌 핵심 질문 / 이 작업이 다루는 핵심 논점

==민감한 문서를 외부 API로 보내지 않으면서도 Obsidian과 Claude Code 같은 에이전트의 사용성을 유지하고, 비싼 토큰 사용을 줄이려면 문서 전처리와 모델 추론을 자신의 클라우드 안에서 MCP로 오프로딩해야 한다.==

• Obsidian은 파일과 지식 연결을 정리하기에는 좋지만, 에이전트에 원문 전체를 넘기는 순간 프라이버시와 토큰 비용 문제가 생긴다.
• 사설 VPC 또는 자체 클라우드에서 OCR, 엔터티 추출, 마스킹, 요약 등의 전처리를 실행하면 에이전트에는 필요한 결과만 돌아간다.
• Superlinked의 오픈소스 추론 엔진과 클러스터는 여러 오픈 모델, GPU 워커 풀, 배칭, 모델 핫스와핑을 운영 가능한 형태로 묶는다.
• 이 구조는 단순 문서 처리에 그치지 않고, 작업별 모델 라우팅·검색·리랭킹·가드레일·그래프 데이터 처리로 확장될 수 있다.

핵심은 Obsidian 자체의 그래프 기능보다 그 뒤에 놓인 추론 인프라다. 사용자는 평소처럼 에이전트와 대화하면서 민감하거나 토큰을 많이 쓰는 작업만 자신의 클라우드로 넘기고, 에이전트에는 비식별화·구조화된 작은 결과를 돌려받는다.

---

1. 문제 정의: 지식 보관함을 에이전트의 안전한 전처리 계층으로 만들기

Obsidian의 마크다운 파일, 링크, 그래프는 지식을 정리하기에 적합하지만, 파일을 단순히 모아두는 것만으로는 민감한 문서를 에이전트가 안전하게 처리할 수 없다.

1.1. 출발점과 기존 방식의 한계

1. Obsidian이 제공하는 기반

   1. 마크다운 파일을 사람이 직접 관리할 수 있다.
   2. 파일 사이의 연결과 그래프를 시각적으로 확인할 수 있다.
   3. 에이전트 메모리나 지식 그래프를 만드는 출발점으로 활용하기 쉽다.

2. 에이전트 사용에서 생기는 문제

   1. Claude Code, 클라우드 기반 에이전트, 코워크(co-work)에 파일을 그대로 노출하면 개인정보와 기관 내부 정보가 외부로 나갈 수 있다.
   2. 스캔 문서와 이미지가 섞인 PDF를 그대로 보내면 OCR에 많은 토큰이 필요하다.
   3. 원문 전체를 매번 컨텍스트에 넣으면 필요한 정보보다 잡음이 많아지고 컨텍스트 손실도 커진다.
   4. 외부 API만 사용하면 특정 오픈 모델, 작업 특화 모델, 자체 파인튜닝 모델을 유연하게 시험하기 어렵다.

1.2. 설계 목표 세 가지

1. 프라이버시와 자체 호스팅

   1. 민감한 문서를 자신의 VPC 또는 클라우드에서 먼저 처리한다.
   2. 외부 에이전트에는 비식별화된 결과나 필요한 사실만 돌려준다.
   3. 하드웨어를 직접 보유하거나 관리형 클러스터를 사용하더라도 데이터 처리 경계를 자신의 환경 안에 둔다.

2. 토큰 비용과 컨텍스트 절약

   1. 이미지·스캔이 포함된 10페이지 PDF처럼 OCR 비용이 큰 입력을 로컬 오픈 모델로 전처리한다.
   2. 더 작고 구조화된 산출물을 주 에이전트에 전달해 토큰 사용량을 낮춘다.
   3. 원문을 불필요하게 컨텍스트에 채우지 않아 후속 추론에 쓸 수 있는 컨텍스트를 보존한다.

3. 모델 적응성과 실험성

   1. 오픈소스 모델을 여러 개 배치하고 작업별 품질을 비교한다.
   2. 특정 분야에 맞춘 LoRA와 파인튜닝 모델을 배포한다.
   3. 민감한 산업·법률 문서처럼 일반 모델보다 전문 적응이 중요한 영역을 지원한다.

1.3. 왜 단순 API나 노트북 플러그인이 아닌가

1. 노트북 안의 플러그인으로 끝내지 않는 이유

   1. 로컬 플러그인은 사용하기 쉽지만, 노트북의 CPU·GPU와 저장공간에 작업이 묶인다.
   2. 전용 클러스터를 두면 무거운 OCR·생성·임베딩을 별도 워커에 맡기고 평소의 Claude Code 작업은 중단하지 않을 수 있다.
   3. 어떤 GPU에 어떤 모델을 둘지, 워커 풀을 어떻게 나눌지, 사용하지 않을 때 어떻게 축소할지를 운영 계층에서 제어할 수 있다.

2. MCP를 경계면으로 삼는 이유

   1. Claude Code, 코워크, 클라우드 데스크톱 등 다양한 호스트가 같은 도구 인터페이스를 사용할 수 있다.
   2. MCP 서버가 도구를 노출하고, 실제 무거운 작업은 자신이 통제하는 클러스터가 수행한다.
   3. 새로운 문서 도구를 추가해도 주 에이전트의 사용 경험을 바꾸지 않고 확장할 수 있다.

---

2. MCP와 Superlinked Sci의 구조

MCP 클라이언트가 자연어 요청을 도구 호출로 바꾸고, Sci MCP 서버가 사설 추론 클러스터의 모델을 호출하는 세 계층 구조다.

2.1. 세 계층의 역할

1. 호스트·MCP 클라이언트 계층

   1. Claude Code, 코워크, 클라우드 데스크톱 또는 다른 에이전트 하네스가 호스트가 된다.
   2. 클라이언트는 서버와 핸드셰이크를 한 뒤 사용 가능한 도구를 발견한다.
   3. 사용자는 “NDA 문서의 개인정보를 마스킹해 달라”처럼 자연어로 요청하고, 에이전트가 적절한 도구를 선택한다.

2. Sci MCP 서버 계층

   1. 서버는 문서 변환, 엔터티 추출, 마스킹, 요약, 질의응답 등 작업별 도구를 노출한다.
   2. 서버는 실제 모델 실행을 직접 한 덩어리로 수행하기보다 뒤의 클러스터와 워커 풀에 일을 전달한다.
   3. 현재 프라이버시 중심 구성에서는 서버가 도구만 노출한다. 클라이언트의 샘플링(sampling)이나 엘리시테이션(elicitation)을 활용하는 양방향 복합 흐름은 사용하지 않는다.

3. 사설 추론 클러스터 계층

   1. GPU와 워커 풀이 실제 OCR, NER, 임베딩, 생성, 리랭킹 작업을 수행한다.
   2. 작업 종류에 따라 모델을 다른 워커 풀에 배치할 수 있다.
   3. 큐잉, 배칭, 자동 확장, 모델 핫스와핑이 주 에이전트와 분리된 운영 기반을 이룬다.

2.2. MCP 통신과 전송 방식

1. 핸드셰이크

   1. MCP 통신은 JSON-RPC를 사용한다.
   2. 초기화 과정에서 요청(request), 응답(response), 알림(notification)이 오가며 서버를 인증하고 도구 목록을 준비한다.
   3. 표준이 발전하면서 클라이언트가 샘플링·엘리시테이션을 제공하는 형태도 가능하지만, 데이터 경계를 단순하게 유지하기 위해 현재 구성에서는 도구 호출 중심으로 제한한다.

2. 로컬과 원격

   1. 로컬 개발에는 표준 입출력(stdio)을 사용할 수 있다.
   2. 원격 사설 클라우드 배포에는 스트리밍 HTTP 응답을 사용한다.
   3. 과거에는 스트리밍용 엔드포인트와 HTTP 핸드셰이크용 엔드포인트가 분리됐지만, 현재 표준은 이를 하나의 흐름으로 처리해 구성이 더 매끄럽다.

2.3. 배포 선택지

1. 관리형 클러스터

   1. Superlinked 사이트에서 inference grant를 신청하면 API 키와 테스트용 컴퓨트를 받을 수 있다.
   2. 데모와 해커톤에서는 관리형 하드웨어를 사용해 빠르게 시작할 수 있다.
   3. 관리형 클러스터를 사용해도 MCP와 에이전트 사이의 데이터 흐름은 마스킹·전처리 설계에 따라 제한할 수 있다.

2. 자체 호스팅

   1. Sci 저장소와 MCP 패키지는 오픈소스로 공개돼 있다.
   2. Docker 컨테이너로 로컬에서 시작할 수 있고, 장기 운영에서는 자신의 GPU와 클러스터를 사용할 수 있다.
   3. Helm chart와 Kubernetes 클러스터가 제공되며, Terraform apply로 인프라를 배포할 수 있다.
   4. 저장소의 README, 빠른 시작 문서, 모델 버전 설명, 트러블슈팅 가이드를 따라 OpenAI API 기반 워크플로를 옮길 수 있다.

---

3. 현재 제공되는 도구와 문서 처리 흐름

도구의 가치는 원문을 그대로 에이전트에게 전달하는 것이 아니라, 사설 모델이 민감한 입력을 먼저 작고 유용한 산출물로 바꾼다는 데 있다.

3.1. MCP 도구 묶음

1. 문서 변환과 OCR

   1. docs-to-markdown은 스캔과 이미지가 포함된 문서를 마크다운으로 변환한다.
   2. 공개 오픈소스 OCR 모델을 사용하며, OCR은 오픈 모델로 오프로딩해도 품질을 크게 희생하지 않는 대표적인 작업으로 제시된다.
   3. 문서 전체를 멀티모달 입력으로 외부 모델에 보내는 대신 텍스트·구조 중심의 작은 결과를 만든다.

2. 정보 추출

   1. 엔터티 추출 도구는 NER 모델을 사용해 사람, 이메일, 전화번호, 주민등록번호와 같은 문서 속 엔터티를 찾는다.
   2. 캡셔닝과 태깅 도구는 이미지와 데이터에 설명·레이블을 붙인다.
   3. 구조화 생성, 요약, 질의응답 도구는 후속 에이전트 작업이 쓰기 쉬운 형태로 결과를 만든다.

3. 확장 가능한 오픈소스 표면

   1. 새로운 도구는 저장소에 PR로 추가할 수 있다.
   2. 콘텐츠 가드(content guarding), 정책 확인(policy checking), 구조화 출력, 코드 작성용 생성 모델도 같은 추론 계층을 활용할 수 있다.
   3. 문서 처리에 한정하지 않고 임베딩, 이미지 캡션, 가드레일, 검색과 리랭킹으로 확장할 수 있다.

3.2. 시연에 사용한 합성 문서

1. Inbox 폴더의 입력

   1. 실제 데이터 대신 이메일과 문서를 흉내 낸 합성 데이터를 사용했다.
   2. 인보이스 관련 이메일, 민감한 정보가 포함된 문서, 전화번호와 사회보장번호가 들어 있는 NDA가 배치됐다.
   3. 계약서는 텍스트가 아니라 이미지로 스캔돼 있어 OCR 없이는 바로 읽을 수 없는 형태였다.

2. 자연어 기반 NDA 마스킹

   1. “NDA 문서의 데이터를 마스킹해 달라”는 요청으로 문서 처리 도구를 호출했다.
   2. 결과에는 관련 엔터티가 추출되고, 이메일과 사람 등의 값이 마스킹된 문서가 생성됐다.
   3. 처리 결과에는 10개 스팬(span)을 마스킹했다는 정보와 레이블별 개수가 표시됐다.
   4. Claude Code나 주 에이전트는 전체 NDA가 아니라 마스킹된 결과만 보게 된다.

3. 스캔 문서의 OCR과 마스킹 결합

   1. “스캔을 전처리하고 마스킹해 달라”는 자연어 요청을 보낸다.
   2. OCR 모델이 이미지 계약서의 텍스트를 추출해 마크다운 파일을 만들고, 이어서 개인정보를 마스킹한다.
   3. 결과 파일은 원래의 이미지 스캔보다 에이전트가 검색·요약·질의응답하기 쉬운 형태가 된다.
   4. OCR 전처리와 비식별화를 한 번에 사설 환경에서 수행하므로 토큰 절약, 컨텍스트 관리, 데이터 보호를 동시에 얻는다.

3.3. 프라이버시 경계와 주의점

1. 노출되는 데이터의 최소화

   1. VPC 안에서 원문을 읽고 처리한 뒤, 외부 에이전트에는 마스킹된 문서를 반환한다.
   2. 에이전트가 원문을 보지 않아도 문서 작업에 필요한 구조와 사실을 사용할 수 있다.
   3. 같은 설계는 Claude Code가 아닌 다른 하네스에도 적용된다.

2. 추가 가드레일의 필요성

   1. MCP 서버를 VPC에 두는 것만으로 모든 우회·오작동 가능성이 자동으로 제거되지는 않는다.
   2. 실제 환경에서는 에이전트가 마스킹 이전 원문을 요구하거나 잘못된 도구를 호출하는 상황을 평가해야 한다.
   3. 더 강한 통제가 필요하면 오픈소스 하네스와 자체 도구 호출 계층을 사용해 데이터 경계를 직접 강제할 수 있다.

3. 토큰 절감 측정

   1. 화면에 절약된 토큰 수를 보여주는 상태 표시줄이 있다.
   2. 데모 시점의 카운터는 아직 정확히 업데이트하도록 손볼 부분이 남아 있다.
   3. 측정치를 제품 품질 지표로 사용하려면 원문 토큰, 전처리 후 토큰, 동일 작업의 정확도와 지연시간을 함께 기록해야 한다.

---

4. 숨은 핵심: 추론 인프라가 성능과 비용을 결정한다

MCP 도구 표면은 단순해 보여도 실제 차이는 여러 모델을 GPU에서 효율적으로 실행하는 추론 계층에서 발생한다.

4.1. 게이트웨이와 워커 풀

1. 작업 분리

   1. 게이트웨이가 요청을 서로 다른 워커 풀로 연결한다.
   2. 각 워커에는 자체 배처(batcher)가 있어 해당 모델·워커에 맞게 배칭한다.
   3. OCR, NER, 임베딩, 생성처럼 성격이 다른 작업을 같은 큐에 억지로 섞지 않는다.

2. 공유 큐와 워커별 배칭의 비교

   1. 모든 요청을 하나의 공유 큐에 넣고 워커가 가져가게 하면 대기와 처리 방식이 서로 다른 모델에 맞지 않을 수 있다.
   2. 테스트에서는 워커별 배칭이 공유 큐 중심 배칭보다 지연시간과 종단 간 성능이 좋았다.
   3. 인프라 구조를 바꾸는 것만으로도 개별 모델의 순수 추론 최적화와 별개의 개선을 얻을 수 있다.

4.2. GPU 선택, 자동 확장, 모델 핫스와핑

1. 서로 다른 비용 계층

   1. 무거운 모델에는 더 큰 GPU를 배정할 수 있다.
   2. 가벼운 작업은 L4 스팟 인스턴스에서 충분히 실행해 비싼 하드웨어 낭비를 줄일 수 있다.
   3. 사용량이 줄면 자동 확장으로 워커와 비용을 함께 줄인다.

2. 한 GPU에서 여러 모델 운영

   1. NER, 작은 생성, 임베딩처럼 한 GPU에 들어가는 모델은 여러 개를 올려두고 필요할 때 전환할 수 있다.
   2. 다섯 개의 서로 다른 영역 특화 LoRA를 배치한 뒤 작업별 품질을 시험하는 시나리오가 가능하다.
   3. 모델을 매번 처음부터 로드하지 않고 핫스와핑해 실험과 운영 사이의 간격을 줄인다.

3. 작업 번들

   1. 문서 파싱, 콘텐츠 임베딩, 코드 작성, 이미지 캡션, 가드레일과 정책 확인을 각각 모델 번들로 구성할 수 있다.
   2. 하나의 MCP 엣지가 모든 문서 작업을 처리하면서도 작업별 모델과 워커를 선택한다.
   3. 같은 기반 위에 질문응답, 사실 추출, 문서 읽기와 검색을 더할 수 있다.

4.3. 임베딩 벤치마크와 경제성

1. 측정 결과

   1. 현재 확보된 벤치마크는 임베딩 모델 중심이다.
   2. 일부 최적 모델은 프론티어 모델과 비교해 약 10분의 1 가격으로 비슷한 품질을 냈다.
   3. MTEB 작업으로 평가했을 때 가장 좋은 모델은 비교 대상 프론티어 모델 품질의 99.8%에 도달했다.

2. 해석

   1. 비용 절감은 모델 단가만이 아니라 배칭, 워커 배치, GPU 선택, 캐시와 자동 확장을 포함한 종단 간 구조에서 발생한다.
   2. 모델별 추론이 완벽하게 최적화되지 않아도 전체 아키텍처를 올바르게 구성하면 지연시간과 처리량이 개선될 수 있다.
   3. 임베딩 외 생성 모델의 추가 벤치마크와 세부 수치는 이후 공개될 예정이다.

4.4. LoRA와 좁은 도메인 적응

1. 빠른 특화

   1. LoRA를 비교적 빠르고 저렴하게 파인튜닝해 특정 업무 영역에 맞출 수 있다.
   2. 독일어 법률 언어처럼 매우 좁은 영역에서는 범용 모델보다 특화 LoRA가 더 유용할 수 있다.
   3. 여러 LoRA를 실서비스에 배포하고 비교할 수 있으면 어떤 특화가 실제 성능을 높이는지 빠르게 확인할 수 있다.

2. 운영상의 의미

   1. 자체 추론 인프라가 모델 교체와 실험을 지원해야 파인튜닝의 이점이 운영까지 이어진다.
   2. 모델 하나를 고정하는 API보다 작업별 모델을 교환할 수 있는 구조가 민감한 산업 문서에 잘 맞는다.

---

5. 다음 단계: 작업별 모델 라우팅과 멀티모델 추론

현재 구현은 도구 호출 중심이지만, 도구 안에서 어떤 모델을 선택할지까지 판단하는 라우팅이 핵심 확장 방향이다.

5.1. 작업에 맞는 모델 선택

1. 도구와 모델의 분리

   1. 현재는 OCR 도구가 특정 OCR 모델과 연결되는 식으로 생각하기 쉽다.
   2. 향후에는 같은 OCR 도구 호출이라도 저가 모델, 고정확도 모델, 도메인 특화 모델 중 작업에 맞는 모델을 고른다.
   3. 선택 기준은 평가 점수, 비용, 지연시간, 입력 난이도와 데이터 유형이 될 수 있다.

2. 모델의 ‘온도’까지 고려

   1. GPU에 이미 올라가 있는 warm 모델은 더 비싼 모델이어도 즉시 응답할 수 있다.
   2. 저렴하지만 현재 GPU에서 축출된 모델을 다시 로드하는 비용이 더 클 수 있다.
   3. 마지막으로 축출된 모델, 현재 warm 상태, 로딩 시간과 요청 비용을 함께 보고 라우팅하면 인프라 관점의 최적화가 가능하다.

5.2. 추론과 평가의 위험

1. 추론 토큰 설정 문제

   1. 요약 도구에서 thinking token을 사용하는 모델을 연결했을 때, 모델이 실제 요약보다 내부 사고에 토큰을 소진해 결과가 지나치게 짧거나 아예 나오지 않는 문제가 있었다.
   2. 모델의 reasoning 기능을 켤지 끌지는 작업과 출력 예산에 맞춰 설정해야 한다.
   3. 어려운 작업에는 추론이 도움이 되지만, 모든 요청에 무제한 추론을 허용하면 GPU 비용만 늘고 산출물은 없어질 수 있다.

2. 모델 라우터·모델 평의회

   1. 작업 난이도에 따라 여러 모델을 호출하거나 모델 간 판단을 결합하는 ‘모델 평의회(council of models)’ 구상이 가능하다.
   2. 라우터와 판정 모델은 반드시 사전 평가(evals)를 거쳐야 한다.
   3. 편향된 판정 모델, 지나치게 긴 추론, 평가 지표를 해킹하는 모델 최적화는 실제 품질과 다른 결론을 만들 수 있다.
   4. 최적화 대상 지표만 높이고 실제 목표를 달성하지 않는 현상을 막으려면 평가 설계와 운영 검증을 함께 해야 한다.

5.3. 텍스트를 넘어서는 추론 상자

1. 확장 가능한 입력

   1. 음성·영상 트랜스크립트, 이미지, 그래프 기반 데이터도 같은 추론 상자에 넣을 수 있다.
   2. 여러 도구 호출을 연결해 온톨로지를 생성하고 구조화된 데이터를 만들 수 있다.
   3. 검색(retrieval)과 리랭킹(scoring)을 결합해 자체 지식 보관함의 검색 품질을 높일 수 있다.

2. 구성 가능한 검색 계층

   1. 모델 카탈로그는 인코딩과 스코어링 모델을 구분해 태깅한다.
   2. 스코어링 모델은 검색 결과를 재정렬하는 리랭커로 활용할 수 있다.
   3. MCP를 통해 자체 검색·리랭킹 버전을 구축하면 외부 검색 API에 종속되지 않고 보관함에 맞춘 검색을 실험할 수 있다.

---

6. 모델 카탈로그와 생태계

추론을 운영하려면 모델을 단순 파일 목록이 아니라 모델 가족별 실행 방식과 역할까지 포함한 카탈로그로 다뤄야 한다.

6.1. 모델 실행 방식

1. 모델 가족별 런타임

   1. 모델마다 어텐션 구현과 forward pass 방식이 다를 수 있다.
   2. 모든 모델을 동일한 실행 경로로 처리할 수 없으므로 모델 가족에 맞는 런타임 번들이 필요하다.
   3. 출력 유형, 아키텍처, 인코딩·스코어링 역할에 따라 모델을 분류해야 추론을 최적화할 수 있다.

2. 개발자 진입점

   1. 공개 저장소의 패키지, README, 자격 증명 설정 예시를 통해 MCP 도구를 구성할 수 있다.
   2. 기존 OpenAI API 워크플로를 빠르게 옮길 수 있는 마이그레이션 경로가 제공된다.
   3. 재현 가능한 예시와 새로운 도구 PR이 생태계 확장에 중요하다.

6.2. 크레딧과 공동 개발

1. 실험 지원

   1. 무료 클러스터 인프라 크레딧을 신청해 도구와 모델을 테스트할 수 있다.
   2. 관리형 클러스터를 빠르게 써본 뒤 필요하면 자체 GPU 클러스터로 옮길 수 있다.
   3. 해커톤에서 이 크레딧이 많이 활용됐으며, 새로운 도구를 만드는 참여자에게 추가 크레딧을 제공하는 방향도 언급됐다.

2. 해커톤과 기여

   1. 런던에서 Tech Europe, DeepMind와 함께 해커톤을 진행했다.
   2. 참가자들은 검색, 리랭킹, 생성 양쪽을 시험했다.
   3. 콘텐츠 가드, 정책 확인, 검색·리랭킹과 같은 도구 기여가 실용적인 다음 단계가 된다.

---

7. 질의응답에서 확인된 운영 원칙

7.1. Claude Code가 보는 범위

1. 마스킹 결과만 전달

   1. 프라이버시 질문의 핵심 답은 Claude가 입력 문서 전체가 아니라 마스킹된 버전만 받는다는 것이다.
   2. OCR과 마스킹을 VPC에서 끝내면 원문 개인정보가 주 에이전트 컨텍스트에 들어가지 않는다.
   3. 이 원칙은 Claude Code뿐 아니라 도구 호출을 제대로 구현한 다른 에이전트 하네스에도 적용된다.

2. 추가 검증

   1. 에이전트가 이 경계를 우회하는지, 잘못된 파일을 요청하는지 계속 평가할 필요가 있다.
   2. 더 엄격한 환경에서는 오픈소스 하네스를 직접 구성해 도구 호출과 데이터 흐름을 강제할 수 있다.
   3. 프라이버시를 기능 설명이 아니라 실제 로그·권한·네트워크 정책으로 검증해야 한다.

7.2. 관리형과 자체 클러스터

1. 자체 클러스터 가능성

   1. 데모는 제공되는 관리형 클러스터를 사용했지만 필수 조건은 아니다.
   2. 저장소의 Terraform 배포와 Kubernetes·Helm 구성을 이용해 자신의 GPU와 VPC에 클러스터를 만들 수 있다.
   3. 하드웨어를 직접 소유하면 데이터 처리 위치, 모델 버전, 네트워크 정책을 모두 직접 통제할 수 있다.

2. 파일 처리 위치

   1. MCP가 파일을 주 작업자에게 전달하면 해당 워커가 파일을 처리한다.
   2. 워커 풀과 클러스터 설정은 배포 환경에 맞게 바꿀 수 있다.
   3. 무료 관리형 컴퓨트는 시작을 빠르게 할 뿐, 자체 호스팅 선택을 제한하지 않는다.

---

주요 발언 모음

“목표는 데이터를 비공개로 유지하고 자체 호스팅하면서도, 사람들이 실제로 쓸 수 있을 만큼 사용하기 쉽고 친숙하게 만드는 것이었다.”

“민감한 문서를 사설 클라우드에서 전처리한 뒤 무언가를 돌려받을 수 있다면 어떨까?”

“추론이 병목이었다. 데이터를 어디에 저장할지는 쉬웠지만, 오픈소스 추론을 규모 있게 실행하고 여러 모델을 시험하며 운영에 배포하는 일이 어려웠다.”

“원문 문서를 외부 에이전트에 보내는 대신, 마스킹된 버전만 에이전트가 보게 된다.”

“인프라와 아키텍처가 잘 구성되면 모델별 추론이 완전히 최적화되지 않아도 종단 간 성능과 지연시간이 좋아진다.”

“추론 인프라는 API 친화적이고 사용하기 쉬운 설계에서도 훨씬 더 중요하다.”

핵심 데이터 & 수치

• 47분 25초: 전체 발표 길이.
• 3계층: 호스트·MCP 클라이언트, Sci MCP 서버, GPU·워커 풀을 포함한 Sci 추론 클러스터.
• 10개 스팬: NDA 데모에서 마스킹된 엔터티 범위의 예시 결과.
• 약 10분의 1 가격: 일부 임베딩 모델이 비슷한 품질로 기록한 대략적인 비용 수준.
• 99.8%: MTEB 작업에서 가장 좋은 임베딩 모델이 비교 대상 프론티어 모델에 도달한 품질.
• 5개 LoRA 예시: 서로 다른 업무 영역에 파인튜닝한 LoRA를 한 GPU에서 핫스와핑하며 비교하는 운영 시나리오.
• L4 스팟 인스턴스: 가벼운 모델을 저렴하게 실행할 수 있는 GPU 계층의 예시.
• 10페이지 PDF 예시: 이미지와 세부 정보가 포함된 문서를 사전 OCR하면 토큰 비용과 컨텍스트 부담을 줄일 수 있는 사례.

결론 및 실행 시사점

1. Obsidian 파일을 에이전트에게 그대로 연결하기 전에 원문, 전처리 결과, 외부 에이전트가 볼 결과를 분리한다.
2. 스캔·이미지 문서는 VPC 안에서 OCR해 마크다운과 구조화된 데이터로 바꾼 뒤, 개인정보를 마스킹하고 필요한 결과만 반환한다.
3. Claude Code나 다른 하네스에는 문서 원문이 아니라 MCP 도구의 제한된 결과만 전달한다.
4. 초기에는 docs-to-markdown, 엔터티 추출, 마스킹 세 도구만으로 시작하고, 실제 토큰 절감·정확도·지연시간을 측정한다.
5. OCR·NER·임베딩·생성 모델을 하나의 공유 큐에 넣지 말고, 작업 특성에 맞는 워커 풀과 배칭 전략을 설계한다.
6. 가벼운 모델은 L4 스팟 인스턴스에, 무거운 모델은 별도 GPU 풀에 배치하고 자동 확장으로 유휴 비용을 줄인다.
7. 여러 LoRA와 모델을 핫스와핑할 수 있게 해 도메인별 성능을 운영 데이터로 비교한다.
8. 모델 단가뿐 아니라 로딩 시간, warm 상태, 배칭, 네트워크, GPU 사용률을 함께 고려해 라우팅한다.
9. thinking token을 켠 모델은 요약 결과가 비거나 지나치게 짧아질 수 있으므로 작업별 추론 예산을 검증한다.
10. 모델 라우터나 모델 평의회를 도입하기 전에 독립적인 평가 세트와 실제 업무 지표를 만들고, 지표 해킹과 편향을 점검한다.
11. 모델 카탈로그에 모델 가족, 실행 런타임, 인코딩·스코어링 역할, 비용과 품질 태그를 기록한다.
12. 자체 호스팅이 필요하면 Docker, Helm, Kubernetes, Terraform 구성을 이용해 사설 VPC에 클러스터를 배포한다.
13. 문서에서 시작해 임베딩, 검색·리랭킹, 트랜스크립트, 그래프 기반 온톨로지 생성으로 확장한다.
14. 개인정보 처리 경계는 주장으로 끝내지 말고 네트워크 정책, 권한, 로그, 우회 테스트로 검증한다.
15. 최종적인 경쟁력은 자연어 도구 인터페이스가 아니라, 그 뒤에서 요청을 빠르고 저렴하고 안전하게 처리하는 추론 인프라에서 나온다.