프라이빗 RAG 시스템 구축하기: 로컬 우선 AI 저널을 통한 교훈

당신의 AI 저널이 당신의 일기를 읽고 있습니다. 제 것은 그렇지 않습니다. 대부분의 AI 앱은 당신의 데이터를 클라우드로 조용히 전송합니다. DiaryGPT는 그 반대로 동작하며, 이것이 전체 기술적 이야기입니다.

AI + 개인 데이터의 문제
일기를 쓸 때, 당신은 절대 입 밖으로 내뱉지 않을 내용들을 적습니다. 당신이 가장 원하지 않는 상황은 그 텍스트가 타인의 서버에 머물며 모델 학습에 사용되거나, 데이터 유출 사고로 노출되는 것입니다. 하지만 AI는 저널링(journaling)에 진정으로 유용합니다. 당신이 놓치는 패턴을 찾아내고, 내용을 되돌아보게 하며, 빈 페이지는 결코 할 수 없는 질문을 던질 수 있습니다. 긴장 상태는 실재합니다. 당신은 프라이버시를 희생하지 않으면서 AI의 통찰력을 얻고 싶어 합니다. 대부분의 앱은 개인정보 보호정책(privacy policy)을 신뢰함으로써 이 문제를 해결합니다. 저는 기술적인 보장을 원했습니다. 그래서 저는 DiaryGPT를 구축했습니다. 기본적으로 데이터가 당신의 기기를 전혀 떠나지 않는 AI 기반 개인 저널입니다. 정확히 어떻게 작동하는지 소개합니다.

DiaryGPT가 하는 일
아키텍처(architecture)를 살펴보기 전에, 이 앱이 제공하는 기능은 다음과 같습니다:

• 모든 항목에 대한 AI 기분 분석 — 기분, 주제, 성찰적 응답 및 후속 질문
• RAG 기반 채팅 — "내가 언제 가장 불안했지?"라고 물으면 실제 작성한 항목에 근거한 답변 제공
• 시맨틱 검색 (Semantic search) — 키워드가 아닌 의미로 항목 찾기 ("외로움을 느꼈던 때"라고 검색하면 "고립된", "단절된", "우울한" 등의 단어가 포함된 항목을 찾음)
• 주간 성찰 — 한 주 동안의 감정 변화에 대한 AI 요약
• 개인화된 저널링 프롬프트 — 최근 작성 패턴에서 생성됨
• 작성 기록 및 추억 — "작년 오늘 당신은 이렇게 썼습니다…"
• AI 컴패니언 모드 — 위기 감지 기능이 내장된 CBT/DBT 기반의 성찰 (면허를 가진 치료사를 대체하는 것이 아님)
• 기분 체크인 — 1~10 사이의 기록 및 히스토리 차트
• 음성 받아쓰기 및 음성 채팅 — 항목을 말하고 응답을 다시 듣기
• 저장 시 전체 AES-256-GCM 암호화 — 모든 일기 항목, 채팅 메시지 및 노트

프라이버시 아키텍처
DiaryGPT에는 두 가지 모드가 있습니다. 설정(Settings)에서 선택할 수 있습니다.

🟢 로컬 모드 (Local Mode, 기본값)
모든 것이 당신의 기기에서 실행됩니다. AI 모델, 검색, 분석 모두 Ollama를 통해 로컬에서 수행됩니다.

당신의 일기 항목 ↓ Ollama (nomic-embed-text) → 숫자로 변환 → SQLite에 저장 ↓ Ollama (llama3.2 / qwen2.5) → 기분 분석 → 암호화되어 저장. 데이터가 기기를 떠나지 않습니다.

🟡 클라우드 모드 (Cloud Mode, 선택 사항)
더 높은 추론 품질을 원하며 API 전송에 거부감이 없는 사용자를 위한 모드입니다. Groq, OpenAI, Anthropic 또는 Gemini와 같은 본인의 API 키를 직접 가져옵니다. 키는 로컬에 저장됩니다.
당신의 일기 항목 ↓ Ollama (embeddings) → 여전히 로컬에서 수행되며 아무것도 전송되지 않음 ↓ 상위 5개의 관련 발췌문 → 사용자의 API 제공업체로 전송 → 답변이 스트리밍되어 돌아옴. 일기의 아주 작은 부분만 전송됩니다. 전체 내용은 절대 전송되지 않습니다.

RAG 파이프라인 (The RAG Pipeline) — AI가 당신의 삶을 "기억"하는 방법
RAG는 검색 증강 생성 (Retrieval-Augmented Generation)의 약자입니다. 이는 모든 요청마다 당신이 쓴 모든 내용을 언어 모델 (Language Model)에 보내지 않고도, AI가 마치 당신을 실제로 알고 있는 것처럼 느끼게 만드는 기술입니다.

임베딩 (Embedding)이란 무엇인가?
모든 일기 항목은 의미를 위한 GPS 좌표와 같은 숫자 리스트로 변환됩니다.
"오늘 너무 불안했다" → [0.21, 0.83, 0.12, 0.74, ...]
"정말 스트레스를 받았다" → [0.22, 0.81, 0.14, 0.71, ...]
← 매우 유사함
"하이킹을 좋아한다" → [0.91, 0.12, 0.67, 0.23, ...]
← 매우 다름
유사한 의미 = 유사한 숫자. 이것이 의미론적 검색 (Semantic Search)을 가능하게 합니다. 즉, 정확한 단어가 아닌 개념으로 검색하게 됩니다.

1단계 — 항목 작성하기 (Phase 1 — Writing an Entry)
당신이 작성합니다: "오늘은 힘들었다. 마감 기한 때문에 불안했다."
↓ Ollama (nomic-embed-text)가 텍스트를 변환 → [0.21, 0.83, 0.12, 0.74, ...]
↓ SQLite / PostgreSQL에 저장:

• 항목 텍스트 → AES-256-GCM으로 암호화된 임베딩 (Embedding) → 원본 형태로 저장 (수학적 계산을 위해 필요)
• 기분/테마 → LLM에 의해 분석된 후 암호화되어 저장
  이 과정은 비동기식 (Asynchronously)으로 진행됩니다. 즉, 항목은 즉시 저장되고 분석은 백그라운드에서 실행됩니다.

2단계 — 질문하기
질문: "언제 업무에 대해 불안함을 느꼈지?"
↓ Ollama가 질문을 → 숫자로 변환
↓ 당신의 데이터베이스(sqlite-vec 또는 pgvector — 순수 수학, 외부 호출 없음)에서 코사인 유사도 (Cosine similarity) 검색 실행
항목 A: 0.91 일치 ✓
항목 B: 0.87 일치 ✓
항목 C: 0.79 일치 ✓
항목 D: 0.31 일치 ✗ (건너뜀)
↓ 상위 5개 항목이 메모리 내에서 복호화됨
↓ LLM이 다음을 수신: 시스템 프롬프트 (System prompt) + 일기 발췌본 + 당신의 질문
↓ 답변을 단어 단위로 스트리밍 (SSE)
핵심 통찰: 임베딩 (Embeddings)은 무엇을 읽을지 찾아냅니다. LLM은 그것에 대해 무엇을 말할지 결정합니다. LLM은 당신의 일기 전체를 절대 보지 않습니다 — 오직 가장 관련성이 높은 5개의 항목만 봅니다. 코사인 유사도는 전적으로 당신의 서버에서 실행됩니다. 클라우드 모드를 선택하지 않는 한, 아무것도 외부 서비스로 전송되지 않습니다.

컴패니언 파이프라인 (The Companion Pipeline) — 안전 우선
컴패니언 모드는 하나의 규칙을 중심으로 구축되었습니다: 만약 누군가가 위기 상황에 처해 있다면, LLM은 절대 실행되지 않습니다.
메시지 입력
↓ 위기 감지 (Crisis detection) (키워드 매칭, 서버 측)
"자살", "나 자신을 해치고 싶다", "죽고 싶다" 등
↓ 위기 상황인가? 안전한가?
↓
하드코딩된 응답 (Hardcoded response) | LLM이 CBT/DBT 프롬프트와 함께 실행
988 + Crisis Text Line + findahelpline | 인지 행동 치료 (CBT) / 변증법적 행동 치료 (DBT) 기반
인정 → 반영 → 질문 하나 | LLM은 호출되지 않음
저장됨 | companion_messages에 암호화되어 저장됨
위기 대응은 하드코딩되어 있습니다. 이는 교묘한 프롬프트에 의해 환각 (Hallucination)을 일으키거나, 수정되거나, 우회될 수 없습니다. 컴패니언 배너 — "이것은 AI 컴패니언이며, 면허를 가진 치료사가 아닙니다" — 또한 UI에 하드코딩되어 있으며, AI에 의해 생성되지 않습니다.
컴패니언 시스템은 CBT 사고 재구성 (Thought-reframing), DBT 기술, 그리고 반영적 경청 (Reflective listening)을 중심으로 구축된 별도의 시스템 프롬프트를 사용합니다. 세션은 저장되며 다시 시작할 수 있습니다.
언급할 만한 실제 한계점: 키워드 감지는 "죽고 싶다"와 같은 명시적인 문구는 포착하지만, "그냥 다 멈췄으면 좋겠어" 또는 "내가 없는 게 모두에게 더 나을 거야"와 같은 우회적인 위기 언어는 놓칠 수 있습니다. 두 번째 계층으로서 작은 로컬 분류기 (Local classifier)를 도입하는 것이 로드맵에 있습니다 — 키워드 필터를 빠르고 감사 가능한 첫 번째 방어선으로 사용하고, 분류기를 암시적 신호를 위한 안전망으로 사용하는 방식입니다.

암호화 계층 (The Encryption Layer)
모든 사용자 콘텐츠는 데이터베이스에 저장되기 전에 AES-256-GCM 암호화를 거칩니다. // 모든 일기 항목, 채팅 메시지, 컴패니언 노트는 이 암호화 과정을 거칩니다 ( text ) // DB 삽입 전 decrypt ( text ) // DB 읽기 후, LLM 또는 브라우저로 전송하기 전. 암호화 키는 사용자의 소유입니다 — 사용자가 직접 생성하여 .env 파일에 저장하는 64자리의 16진수(hex) 문자열입니다. 이 키 없이는 데이터베이스를 읽을 수 없습니다. 서버는 절대로 키를 전송하지 않습니다. 단 하나의 예외는 임베딩 벡터 (embedding vectors)가 암호화되지 않은 상태로 저장된다는 점입니다. 코사인 유사도 (Cosine similarity)를 계산하려면 가공되지 않은 숫자가 필요하기 때문입니다. 임베딩을 생성한 청크 텍스트 (chunk text)는 별도로 암호화되어 저장됩니다. 보안 경계는 파생된 벡터가 아닌 원본 텍스트에 존재합니다.

기술 스택 (The Technical Stack)
런타임 (Runtime): Node.js + Express
프론트엔드 (Frontend): Vanilla JS SPA (빌드 단계 및 프레임워크 없음)
인증 (Auth): JWT + Argon2id 비밀번호 해싱 (password hashing)
암호화 (Encryption): AES-256-GCM (Node.js crypto 모듈)
저장소 (Storage): SQLite (로컬 기본값) 또는 PostgreSQL (멀티 디바이스)
벡터 검색 (Vector search): sqlite-vec (로컬) 또는 pgvector (Postgres)
임베딩 (Embeddings): Ollama nomic-embed-text (로컬 기본값)
LLM: Ollama (로컬 기본값) / Groq / OpenAI / Gemini / Anthropic
스트리밍 (Streaming): ReadableStream을 이용한 POST 방식의 SSE (Server-Sent Events)
음성 (Voice): 브라우저 SpeechRecognition API (무료) 또는 Whisper (유료)

프론트엔드는 의도적으로 프레임워크를 사용하지 않았습니다. React도, 빌드 파이프라인도, 브라우저 내의 node_modules도 없습니다. 즉각적으로 로드되며 (클라우드 LLM 호출을 제외하고) 오프라인에서도 작동합니다.

LLM 제공자 아키텍처 (LLM Provider Architecture)
LLM 계층은 활성화된 제공자에게 모든 호출을 라우팅하는 얇은 팩토리 (thin factory) 역할을 합니다:

// services/llm.js
const PROVIDERS = { ollama , anthropic , openai , gemini , groq };
export const streamChat = ( history , message , context , onDelta ) => PROVIDERS [ getConfig (). provider ]. streamChat ( history , message , context , onDelta );

제공자 전환은 런타임 (runtime) 중에 발생하며, 재시작이 필요하지 않습니다.

모든 제공자(provider)는 동일한 세 가지 함수 계약(contract)을 구현합니다:

analyzeEntry ( text ) // → { mood, themes, reflection, followUpQuestion }
generateText ( systemPrompt , userMessage ) // → string
streamChat ( history , message , context , onDelta ) // → full string, streams via onDelta

Groq는 https://api.groq.com/openai/v1 을 가리키는 OpenAI SDK를 사용합니다. Ollama는 http://localhost:11434/v1 을 가리키는 동일한 SDK를 사용합니다. 인터페이스는 동일하지만, 개인정보 보호 특성은 완전히 다릅니다.

내가 배운 점들

1. 임베딩 (Embeddings)과 LLM은 완전히 별개의 관심사입니다. 텍스트를 숫자로 변환하는 모델은 답변을 생성하는 모델과 아무런 관련이 없습니다. 임베딩을 위해 Ollama를 실행하고 채팅을 위해 Groq를 동시에 실행할 수 있습니다. 대부분의 사람들은 이 둘을 혼동합니다.

2. 7B–8B 모델은 구조화된 일기 작업에 충분히 좋습니다. 기분 감지, 주제 추출, 저널링 프롬프트 — 프롬프트가 잘 작성된 qwen2.5:7b는 이 모든 것을 안정적으로 처리합니다. 70B 모델과의 품질 차이는 긴 형식의 주간 요약에서만 나타납니다. 구조화된 출력을 위해 Ollama에서 format: json mode를 사용하세요. 이것이 없으면 작은 모델들은 결국 잘못된 형식의 JSON을 반환하여 파이프라인을 조용히 망가뜨릴 것입니다.

3. 코사인 유사도 (Cosine similarity)는 벡터 데이터베이스가 아닌 여러분의 데이터베이스에 속해야 합니다. 수백만 개가 아닌 수천 개의 항목을 가진 개인용 앱의 경우, sqlite-vec와 pgvector만으로도 충분합니다. Pinecone, Weaviate, 추가 인프라가 필요 없습니다. 수학적 계산은 단순하고 빠릅니다.

4. 스트리밍 (streaming)을 위해서는 POST 방식의 SSE (Server-Sent Events)가 올바른 선택입니다. 표준적인 권장 사항은 EventSource를 사용하는 것이지만, EventSource는 GET 방식만 지원합니다. 채팅은 (메시지 본문을 보내기 위해) POST가 필요합니다. 해결책은 클라이언트 측에서 fetch + ReadableStream을 사용하는 것입니다. 이를 통해 스트림 생명주기를 완전히 제어할 수 있으며, 어색한 쿼리 스트링 (query-string) 페이로드를 피할 수 있습니다.

5. 위기 감지 (Crisis detection)는 LLM 내부가 아니라 LLM 이전에 실행되어야 합니다. 위기 언어를 일관되게 감지하고 안전하게 대응하는 것을 LLM에만 의존할 수는 없습니다. LLM 호출 전의 키워드 매칭 (Keyword matching)은 우아하지는 않지만, 신뢰할 수 있고 감사 가능 (auditable)합니다.

위기에 처한 사람에게 LLM (Large Language Model)은 결코 첫 번째 방어선이 되어서는 안 됩니다. 심지어 그 메시지를 전달받아서도 안 됩니다. 6. 프라이버시 우선 (privacy-first) 앱에서 가장 어려운 엔지니어링 결정은 무엇을 하지 않을 것인가에 관한 것입니다. 분석 (Analytics) 금지. 원격 측정 (Telemetry) 금지. "익명화된" 사용 데이터 금지. 이 모든 것들은 포기해야 하는 유용한 제품 기능들이지만, 그것들을 포기하는 것이 바로 핵심입니다. 직접 시도해 보세요. DiaryGPT는 오픈 소스 (open source)입니다. 직접 호스팅하고, 모든 코드를 읽고, 프라이버시 주장을 검증하십시오. 🔗 GitHub: https://github.com/rahul70-code/diarygpt 당신의 일기는 당신의 것입니다. AI는 당신을 위해 작동해야 하며, 당신으로부터 정보를 수확해서는 안 됩니다. Stack: Node.js · Ollama · SQLite · AES-256-GCM · Vanilla JS Tags: #LLM #RAG #Privacy #LocalFirst #OpenSource