📝 한 줄 요약
작품 설정을 GPT와 Claude에 매번 따로 업로드하지 않기 위해, 옵시디언 볼트를 AWS 서버와 동기화하고 Tailscale로 기기를 연결한 뒤 GPT API 기반 웹앱을 만들었습니다. 연결 자체는 성공했지만, 단어 일치 중심의 검색 방식으로는 질문의 맥락을 제대로 이해하지 못했습니다. 이번 실험을 통해 LLM을 연결하는 것과 내 자료를 정확히 찾아 활용하게 만드는 것은 별개의 문제라는 점을 확인했습니 다.
🎯 이런 분들께 도움이 됩니다
GPT, Claude 등 여러 AI를 번갈아 사용하면서 같은 자료를 매번 다시 업로드하는 분
옵시디언을 AI의 외부 기억 공간으로 활용하고 싶은 분
집과 회사처럼 서로 다른 기기에서 동일한 프로젝트 자료에 접근하고 싶은 분
코딩을 잘 모르지만 직접 AI 웹앱이나 자동화 구조를 만들어보고 싶은 분
성공 사례뿐 아니라, 실제 구축 과정에서 무엇이 막히는지 궁금한 분
😫 문제 상황: AI를 바꿀 때마다 기억도 끊겼다
저는 집필 중인 작품 자료를 옵시디언에 정리하고 있습니다. 기존에는 아이클라우드를 기반으로 동기화해 핸드폰과 맥북에서는 문제없이 확인하고 수정할 수 있었습니다.
문제는 아이클라우드를 사용하기 어려운 회사 PC였습니다. 장소와 기기가 바뀌면 자료 접근이 불편했고, AI를 활용할 때도 비슷한 문제가 생겼습니다.
작품은 GPT와 Claude의 프로젝트 기능으로 각각 관리하고 있었는데, LLM을 바꿀 때마다 같은 설정 자료를 다시 업로드해야 했습니다. 어느 한쪽에만 최신 파일이 들어가면 두 AI가 가진 정보량이 달라졌고, 그 결과 같은 질문에도 서로 다른 답이나 오류가 발생했습니다.
저는 세계관과 설정 관리는 Claude와, 문장 윤문은 GPT와 진행하고 싶었습니다. AI 모델은 버전이 바뀔 때마다 잘하는 일이 달라지기도 하니, 필요에 따라 자연스럽게 바꿔 쓰고 싶었습니다.
그래서 목표를 이렇게 정했습니다.
AI의 프로젝트 파일을 따로 관리하지 않아도, 어떤 AI든 하나의 옵시디언 자료를 읽고 작업을 이어가게 만들자.
💡 아이디어를 얻은 계기
2주차 스터디원 사례 발표에서 Tailscale로 서로 다른 기기를 연결한 사례를 들었습니다. 그 발표를 보며, 옵시디언을 항상 켜져 있는 서버에 동기화하고 여러 기기와 AI가 그 서버에 접근하게 만들면 되지 않을까 생각했습니다.
이 아이디어를 바탕으로 다음 구조를 직접 만들어보기로 했습니다.
옵시디언 → AWS 서버에 상시 동기화 → Tailscale로 기기 연결 → GPT API 웹앱에서 자료 검색
🛠️ 사용한 도구
Obsidian Sync: 기존 옵시디언 볼트를 서버와 동기화
AWS Lightsail: 24시간 작동하는 서버 구축
Tailscale: 회사 PC와 서버를 안전한 사설 네트워크로 연결
OpenAI API: 옵시디언 자료를 참고해 답변하는 모델 연결
간단한 웹앱: 질문 입력, 답변 확인, 참고 문서 표시
🔧 작업 과정
1. 옵시디언 자료가 항상 열려 있는 서버 만들기
먼저 기존 옵시디언 볼트를 Google Drive에 백업했습니다. 이후 AWS Lightsail 서버를 만들고 고정 IP를 연결했습니다.
서버에 옵시디언 싱크를 로그인한 뒤, 서버가 재시작돼도 자동으로 동기화가 실행되도록 설정했습니다. 이 과정은 대부분 터미널에서 진행했습니다.
처음에는 낯설었지만, 여러 번 명령어를 입력하다 보니 터미널 화면 자체는 조금씩 익숙해졌습니다. 여전히 아는 것은 많지 않았지만요.
한국어 텍스트가 있는 페이지의 스크린샷
2. Tailscale로 회사 PC와 서버 연결하기
다음으로 서버와 회사 PC에 Tailscale을 설치했습니다. 서버에서 로그인과 인증을 진행하고, Windows용 앱을 설치해 두 기기가 같은 네트워크에 들어오도록 했습니다.
이 단계까지 진행한 뒤 회사 PC에서 서버 접속에 성공했습니다. 기존에는 아이클라우드 환경이 아니면 접근하기 어려웠던 옵시디언 자료를, 다른 기기에서도 사용할 수 있는 기반이 생긴 셈입니다.
앱 다운로드 페이지 스크린샷
3. GPT API를 서버에 연결하기
OpenAI API에서 이 작업을 위한 별도 프로젝트를 만들고 키를 발급했습니다. 키는 화면이나 코드에 직접 적지 않고 서버의 환경변수로 저장했습니다.
간단한 테스트를 통해 GPT API가 정상적으로 응답하는 것을 확인한 뒤, 옵시디언 문서를 먼저 검색하고 관련 내용을 GPT에 전달하는 웹앱을 만들기 시작했습니다.
4. 긴 코드는 파일로 만들어 서버에 업로드하기
앱 제작 과정에서 긴 스크립트를 터미널에 그대로 붙여넣자 오류가 반복됐습니다. 그래서 Windows에서 완성된 파일을 만든 뒤 서버로 업로드하는 방식으로 우회했습니다.
모든 일을 정석대로 해결하지 않아도, 현재 가능한 방법으로 흐름을 이어가는 것이 중요했습니다. 이 방식으로 웹앱을 실행했고, URL을 통해 접속할 수 있었습니다.
한국어 텍스트가 있는 검은 화면
5. 보조작가답게 세부 설정 추가하기
단순히 질문에 답하는 웹앱에서 끝내지 않고, 실제로 사용하던 AI의 느낌과 작업 방식을 반영했습니다.
기존에 사용하던 AI 페르소나 적용
기기별 최근 대화 내용 최대 6개 기억
사용할 GPT 모델 변경 기능
답변에 참고한 옵시디언 문서 경로 표시
이제 겉으로 보기에는 제가 원하던 ‘옵시디언을 읽는 보조작가’에 가까운 형태가 만들어졌습니다.
두 번째 뇌 GPT
🧪 검증: 연결됐지만, 이해한 것은 아니었다
웹앱이 실제 작품 설정을 제대로 이해하는지 검증했습니다.
첫 번째로 특정 캐릭터와 관련된 설정을 질문했습니다. 앱은 정확한 정보가 들어 있는 문서를 찾기는 했지만, 이름이 언급된 다른 문서까지 함께 가져왔습니다. 문서에 명시된 사실과 주변 문장에서 추론한 내용을 섞어 답하기도 했습니다.
두 번째로 여러 문서의 상태를 종합해야 하는 질문을 던졌습니다. 관련 내용이 옵시디언 안에 있었지만, 앱은 응답할 내용이 없다고 답했습니다.
흰색 배경에 한국어와 중국어 텍스트
❌ 실패한 이유
검증 결과, GPT API 자체는 분명 LLM의 두뇌를 사용하고 있었습니다. 하지만 그 두뇌에 어떤 자료를 전달할지는 제가 만든 검색 코드가 결정하고 있었습니다.
초기 웹앱은 질문 속 단어를 기준으로 옵시디언 문서를 찾고, 일치율이 높은 문서를 GPT에 넘기는 비교적 단순한 방식이었습니다. 이 방식은 정확한 고유명사를 묻는 질문에는 어느 정도 대응했지만, 다음과 같은 질문에는 약했습니다.
여러 문서를 함께 읽어야 하는 질문
질문에 사용된 단어와 문서 표현이 다른 경우
작품명, 인물명처럼 여러 파일에 반복해서 등장하는 단어
문서에 적힌 사실과 문맥상 추론을 구분해야 하는 경우
결국 GPT를 연결했다고 해서 ChatGPT 프로젝트와 같은 수준의 맥락 이해가 자동으로 생기는 것은 아니었습니다. 모델의 성능과 별개로, 필요한 자료를 찾아 전달하는 검색 구조가 중요했습니다.
✅ 결과: 완성된 보조작가는 아니지만, 병목은 찾았다
이번 실험으로 원래 원했던 결과를 완전히 만들지는 못했습니다. 하지만 어디가 문제인지 명확하게 확인했습니다.
| 항목 | 실험 전 | 실험 후 |
|---|---|---|
| 작품 자료 관리 | GPT와 Claude에 각각 파일 업로드 | 하나의 옵시디언 볼트를 공통 원본으로 사용하는 구조 구현 |
| 기기 접근 | 아이클라우드 환경 중심 | 회사 PC에서도 서버 접근 성공 |
| AI 연결 | 각 서비스의 프로젝트 기능에 의존 | GPT API가 옵시디언 문서 를 참고하는 웹앱 제작 |
| 답변 품질 | AI별 정보량 차이로 오류 발생 | 단순 질문은 검색 가능했지만 맥락형 질문의 한계 확인 |
| 다음 과제 | 막연히 ‘AI를 연결하고 싶다’ | 검색·문맥 이해 구조가 핵심 병목이라는 점 확인 |
작동하는 화면을 만드는 것과 실제로 신뢰할 수 있는 보조작가를 만드는 것은 다른 일이었습니다. 그래도 이번 실패 덕분에 다음 단계에서 무엇을 검증해야 하는지는 훨씬 분명해졌습니다.
💬 이 과정에서 배운 AI 활용 팁
1. 실패한 프로토타입도 가치가 있다
이번 결과물은 실사용 가능한 보조작가가 되지는 못했습니다. 대신 AWS, Tailscale, API, 웹앱 제작을 직접 경험했고, 막연했던 문제가 ‘검색과 맥락 전달’이라는 구체적인 과제로 바뀌었습니다.
🌱 얻은 것
AWS와 Tailscale처럼 어렵게 느껴졌던 서비스를 직접 사용해봤습니다.
간단한 웹앱을 만드는 과정에 대한 두려움이 크게 줄었습니다.
AI의 성능뿐 아니라, AI에게 어떤 자료를 어떻게 전달하는지가 중요하다는 사실을 체감했습니다.
실패 원인을 막연한 ‘모델 성능’이 아니라 검색 구조의 문제로 좁힐 수 있었습니다.
🚀 앞으로 검증할 내용
다음 단계에서는 두 가지를 확인하려고 합니다.
질문의 단어만 찾는 것이 아니라, 질문의 맥락을 읽고 관련 문서를 고르는 방법
직접 서버와 검색 앱을 만드는 대신 Google Drive MCP를 이용해 프로젝트 자료를 연결하는 방법
