소개
저는 화장품·식품 이커머스 판매하는 1인기업을 운영하고 있습니다.
상품소싱부터 콘텐츠·마케팅·판매까지 혼자 돌리는데,
가장 큰 병목은 "내가 가진 정보를 매번 다시 찾고 정리해야 한다"는 것이었습니다.
같은 제품 영상을 5번 만들면 같은 자료 찾아 헤메는 일을 5번 반복했습니다.
그래서 이번 GPTer 인터페이스개발 스터디에 참여하게 되었습니다.
자료를 체계적으로 저장하고, 그 저장소가 곧바로 콘텐츠를 뽑아내는 플랫폼이 되 게 만들기.
부연하자면,
"프롬프트 한 줄로 — 내 데이터베이스가 맥락이 되어 — 콘텐츠를 빠르고 다양하게 찍어내는 시스템."
이게 가능하려면 "LLM이 검색할 수 있는 형태로 지식을 저장"하는 게 출발점입니다. 저는 이걸 형식과 구조 두 축으로 풀었습니다.
① 저장 형식 — 마크다운 + 프론트매터. 모든 노트를 평문 마크다운으로 쓰고 맨 위에 프론트매터(type·tags·updated 등)를 답니다. 프론트매터로 분류·검색 가능한 노트가, 그대로 콘텐츠 제작의 "맥락(context)"이 되기 때문입니다.
② 저장 구조 — LLM Wiki. 그런데 자료를 폴더에 쌓기만 하면 흩어진 메모일 뿐입니다. 그래서 카파시(Karpathy)의 LLM Wiki 패턴을 차용해 원본(raw) → AI 컴파일 위키(wiki) → 산출물(output)의 3계층으로 운영합니다. 사람이 모은 원본을 AI가 읽어 서로 [[링크]]로 연결된 위키 페이지로 합성·유지하고, 이 위키가 단일 진실 소스(single source of truth)가 됩니다. 프론트매터가 "한 노트를 검색 가능하게" 만든다면, LLM Wiki는 "지식 전체를 AI가 항해할 수 있는 지도로" 만드는 구조입니다.
이 저장 형식과 구조가 곧 생산 연료라는 게 이 과제의 핵심 깨달음이었습니다.
진행 방법
도구: 옵시디언(지식이 사는 곳) + Claude Code(볼트를 직접 읽고 쓰는 AI 에이전트)
옵시디언은 모든 노트가 평문 마크다운이라 LLM이 그대로 읽기 좋고, Claude Code가 볼트 안에서 파일을 직접 만들고 연결합니다. 이 둘을 한 볼트에 묶었습니다.
1) 볼트를 "세 영역"으로 설계 — 지식 / 제작 / 자동화
플랫폼이 되려면 저장소만으로는 부족합니다. 지식(자료) → 제작(작업장) → 자동화(부품)가 한 공간에 있어야 합니다.
SoGoodContents/ ← 옵시디언 볼트 (콘텐츠 제작 OS의 컨테이너)
├── [영역 A] LLM Wiki — 지식 데이터베이스
│ ├── 0. Inbox/ 외부 자료 진입점
│ ├── 1. raw/ 정리된 소스 자료 (5C+Reference DB)
│ ├── 2. wiki/ AI가 컴파일한 위키 ← LLM이 검색하는 핵심
│ └── 3. Output/ 텍스트 산출물
├── [영역 B] Studio — 콘텐츠 제작 작업장
│ └── _studio/<프로젝트>/{기획, 자료, 결과}
└── [영역 C] Claude — 툴 모음
└── .claude/skills/핵심은 "저장소(A)와 제작(B)을 같은 볼트에 두되, 절대 섞지 않는다" 입니다. 데이터와 도구가 다른 앱·다른 폴더로 떨어져 있으면 매번 0에서 시작하지만, 한 컨테이너에 두면 둘을 잇는 다리가 시스템의 일부로 굳어집니다.
2) LLM이 검색하게 만드는 핵심 — 프론트매터 + 위키링크
모든 위키 노트는 맨 위에 YAML 프론트매터를 답니다. type·tags로 AI가 분류·검색하고, 본문은 [[위키링크]]로 노트끼리 연결돼 AI가 맥락을 타고 탐색합니다.
원본(raw) 노트에는 수집 의도(intent:) 까지 박아둡니다. "이 자료를 왜 모았는지"를 AI가 나중에 복원해서, 흩어진 자료를 묶어 분석하거나 콘텐츠로 변환할 때 방향을 잡게 하려는 것입니다.
3) 플랫폼의 심장 — "Wiki → Studio 다리"
저장된 지식이 콘텐츠가 되는 실제 흐름입니다. 위키 원본은 손대지 않고, 프로젝트 폴더 안으로 "정리본 스냅샷"만 흘려보냅니다.
1) "○○ 제품 10초 릴스 만들어줘"│
▼
2) [Wiki 컨텍스트] 2. wiki/○○.md 읽기 → 차별점·메시지·키워드·톤 추출│
▼
3) 추출물을 studio/○○릴스/기획/제품정보.md 로 저장 (위키 원본은 그대로 보존)│
▼
4) [Studio 컨텍스트] 기획/제품정보.md 기반으로 Remotion 영상 코드 작성│
▼
5) npx remotion render → studio/○○릴스/결과/v1-YYYY-MM-DD.mp4
이 한 방향 다리 덕분에 위키 포맷이 바뀌어도 영상 코드가 안 깨지고, 여러 프로젝트가 같은 위키를 참조해도 충돌이 없습니다. 같은 위키 데이터로 영상·카드뉴스·블로그를 전부 뽑아낼 수 있는 이유입니다.
결과와 배운 점
콘텐츠 도구를 데이터 옆에 두라. 데이터와 도구가 다른 앱·폴더로 분리돼 있으면 매번 0에서 시작. 같은 컨테이너에 두면 다리가 시스템화된다.
단, 데이터 영역과 작업 영역은 명확히 분리하라. 같이 두되 섞지 않는다. 경계가 없으면 단일 진실 소스가 오염된다.
Skill(지식)과 Tool(실행)을 분리하라. "AI가 작업법을 아는 것"과 "도구가 실제로 도는 것"은 다른 차원. 분리하면 도구를 교체해도 지식이 살아남고, 같은 지식이 여러 도구에 재사용된다.
프로젝트는 결과물 단위로 폴더화하라. "한 폴더 = 한 결과물"이면 나중에 열었을 때 맥락 복원이 즉시 된다.
위키 → 프로젝트 발췌는 한 방향이다. 위키가 안정적으로 진화하려면 데이터는 위키에서 프로젝트로만 흘러야 한다.
시행착오 (1차 시도의 실패에서 배운 것):
범위를 너무 넓게 잡았다. 처음엔 "LLM Wiki로 뭐든 다 하기"였다가 → "콘텐츠 제작 OS"로 범위를 좁히고 나서야 진도가 나갔다.
저장소와 도구가 따로 놀았다. OS 부품과 위키가 분리돼 있어 연결이 안 됐다 → "스킬이 위키를 DB로 직접 활용"하는 구조로 전환.
한 볼트 안에서 영역이 섞였다. 지식·도구·산출물이 뒤엉켜 데이터가 오염 → 0~3 폴더 +
_studio+.claude3영역 분리, 경계를 절대 원칙으로 명문화.
앞으로 할일 (이번 GPTers 22기 인터페이스 개발에서 하고자 하는 일):
옵 시디언 LLM Wiki와 컨텐츠 영역 분리. 지금은 LLM Wiki와 컨텐츠 제작용 스킬이 한 폴더에 있어야만 한다고 생각했었는데, 구조면에서도, 활용도면에서도 두 영역은 분리되어야 좋다. LLM Wiki 밖에서 Wiki에 쿼리를 하는 인터페이스를 만들고, 각 영역을 분리해보려 한다.
슬랙-헤르메스-컨텐츠스킬-LLM Wiki 인터페이스 세팅. PC 밖에서도 수시로 아이디어가 떠오르거나 필요할 때마다 컨텐츠 제작을 진행할 수 있는 인터페이스를 세팅해보려고 한다.
옵시디언 볼트와 볼트의 인터페이스 세팅. LLM Wiki를 세팅해보니, 이질적 성격의 자료를 하나의 볼트에 담아두면 Wiki가 복잡해지고, 그럴수록 컨텍스트가 오염되서 Wiki의 효용이 떨어질 수 밖에 없을 것으로 추정된다. 더 단단한 하네스가 필요한 지점이다. 서로 다른 성격의 볼트들을 별도로 만들되, 볼트와 볼트간 인터페이스를 만들어 꼭 필요할 때는 여러개의 볼트에서 자료를 뽑아 하나의 맥락을 만들 수 있도록 해보려 한다.
도움 받은 글 (옵션)
참고한 지피터스 글이나 외부 사례를 알려주세요.
브레인 트리니티 — 카파시의 LLM Wiki로 나만의 AI 세컨드 브레인 만들기
일잘러 장피엠 — Claude Code 시작 가이드
빌더조쉬 — Claude Code로 영상 100% 자동 제작
