내가 에이전트와 지식베이스를 설계한 방법

2026-10-08 라이브 · 1시간 37분 · 다시보기

디스코드와 Claude Code를 잇기만 하는 에이전트 하나, 그리고 폴더와 마크다운만으로 된 지식베이스 하나로 혼자 사업을 굴리는 구조를 해설한 회차예요. 코딩은 없고, 실제로 쓰는 레포를 화면에 띄워 놓고 설명했어요.

이 노트를 읽고 나면 할 수 있는 것

1. 지침을 루트 AGENTS.md · principles · playbooks · skills로 나눠 담기
2. 레포에 둘 데이터(맥락형)와 DB에 둘 데이터(관계형)를 가르고, DB는 MCP 뒤에 숨기기
3. 피드백을 지침 문서로 영속화하는 루프를 돌리되, 지침의 내용은 직접 정하기

목차

• 편의와 통제 사이, 심플클로를 직접 만든 이유 ▶ 0:00:00
• "라이브 끝났어" 한 줄과 중고차 구매 ▶ 0:13:56
• 폴더 하나로 된 지식베이스, Context Hub ▶ 0:21:00
• principles · playbooks · skills를 나눈 기준 ▶ 0:24:50
• 폴더마다 AGENTS.md, 문서마다 프론트매터 ▶ 0:32:50
• 피드백을 지침으로 영속화하기 ▶ 0:39:45
• 맥락형 데이터는 레포에, 관계형 데이터는 MCP 뒤에 ▶ 0:42:12
• 어드민 화면과 지식 그래프는 만들지 않아요 ▶ 0:46:50
• 맡기는 일과 못 맡기는 일 ▶ 0:50:06
• Q&A ▶ 1:09:02
• 오늘 해볼 것 ▶ 0:37:15

편의와 통제 사이, 심플클로를 직접 만든 이유 ▶ 0:00:00

저는 심플클로(SimpleClaw)라는 에이전트를 직접 만들어서 써요. 하는 일은 하나예요. 디스코드와 Claude Code를 연결하는 것.

에이전트 서비스는 편의성과 통제가 트레이드오프예요 ▶ 0:00:36. 한쪽 끝에는 GrokBot, Dots, Muse처럼 아주 편하지만 통제 범위가 좁은 서비스가 있고, 중간에 OpenClaw나 Hermes가 있어요.

반대쪽 끝은 Claude Code나 Codex를 직접 쓰는 건데, 통제는 쉽지만 멀티 세션을 한눈에 보는 것 같은 편의 기능이 부족해요. 저는 적당히 불편하면서 통제하기 좋은 에이전트를 원했어요. ▶ 0:01:39 그 자리에 있는 서비스가 없어서 직접 만들었어요.

• 모르는 채 처리되는 일이 많아요. 잘못 처리된 게 생기면 되짚기가 번거롭고, 업무상 중요한 메일을 잘못 보내버릴 수도 있어요.
• 토큰을 많이 써요. OpenClaw에 Claude를 연동해 두면 사용량이 순식간에 없어져요.
• 동의하지 않은 내용이 지식으로 남아요 ▶ 0:03:08. Hermes는 사용 패턴을 보고 스킬을 알아서 만드는데, 잘못 추측해서 만든 스킬 때문에 작업이 은근슬쩍 엉망이 되더라고요.

디스코드에 메시지를 보내면 맥미니에서 24시간 도는 심플클로가 웹소켓으로 바로 받아요 ▶ 0:04:07. 빠른 분류는 1초도 안 걸리는 분기 도구 Jev로 하고, 필요할 때 Claude Code를 호출해 답을 돌려줘요. 결제·문의·새 메일 알림도 전부 디스코드로 와서, 업무는 디스코드 하나에서 해요.

다만 메일 중요도 분류는 Jev가 아니라 Claude Code의 Opus가 해요 ▶ 0:07:46. 중요도를 제대로 판단하려면 과거 작업 이력을 여러 방향으로 검색해 봐야 하는데, Jev는 주어진 프롬프트만 보고 판단하거든요. 메일 알림은 30초 늦어도 괜찮아요.

심플클로는 철저히 중계만 해요 ▶ 0:06:18. 프롬프트를 그대로 Claude Code에 넘기고 응답을 그대로 돌려줄 뿐, 중간에서 조작하거나 알아서 기억·학습하지 않아요.

업무 프로세스는 전부 파일로 관리해요. ▶ 0:06:39 이 노트의 나머지는 그 파일들 이야기예요.

"라이브 끝났어" 한 줄과 중고차 구매 ▶ 0:13:56

라이브가 끝나면 저는 "라이브 끝났어"라고만 보내요 ▶ 0:14:13. 그러면 오른팔 등급용 자료 아카이빙, 이전 다시보기의 회원 전용 전환, 재생목록 설정, 고정 댓글, 숏츠 편집까지 이어서 처리해요. 홈페이지 레이아웃 문제를 모바일 브라우저로 디버깅하고 고치는 것도 해요.

폴더 하나로 된 지식베이스, Context Hub ▶ 0:21:00

저는 이 지식 체계를 Context Hub라고 불러요. 정체는 그냥 GitHub 레포지토리 하나예요. 폴더와 파일만으로 에이전트의 지식 체계를 관리해요.

그 아래로 핵심 원칙, OKR, principles 목록, 디렉터리 구조가 이어져요. 어떤 요청을 해도 읽히는 파일이라, 절대 모르면 안 되는 것만 담아요. ▶ 0:23:17

principles · playbooks · skills를 나눈 기준 ▶ 0:24:50

principles에는 B2B 컨설팅에서 반드시 지킬 것 같은 철칙을 담아요. 사업 방향을 바꾸지 않는 한 잘 안 바뀌어요. playbooks는 업무 매뉴얼이라 프로세스가 조금만 바뀌어도 같이 바뀌어요.

principles와 playbooks를 나눠 놓은 이유는 정보의 레이어를 나누기 위해서예요. ▶ 0:25:38 잘 안 바뀌는 층 위에 자주 바뀌는 문서를 얹어 문서마다 책임을 작게 만들고, 에이전트는 둘을 조합해 써요.

폴더마다 AGENTS.md, 문서마다 프론트매터 ▶ 0:32:50

그 밖의 폴더는 사업 형태마다 다를 거예요. 저는 문의 기록, 장기 프로젝트(유튜브 채널 운영도 프로젝트예요), 사업자 정보, 세금 자료, 일회성 프로젝트, 회의록 폴더를 두고 있어요.

이 폴더들에도 각자 AGENTS.md가 있어요. 하위 AGENTS.md는 상위 디렉터리의 내용을 상속하도록 만들었어요. ▶ 0:35:01 그 폴더 문서의 구조, 파일명 규칙, 쌓고 탐색하는 법만 덧붙여요.

피드백을 지침으로 영속화하기 ▶ 0:39:45

저는 작업 지침을 고도화하는 걸 영속화라고 불러요. 흐름은 이래요.

다만 지침의 내용까지 AI에게 맡기지는 않아요. playbooks나 principles는 AI에게 그냥 생성해 달라고 하면 잘 못 만들어요. ▶ 0:31:39

맥락형 데이터는 레포에, 관계형 데이터는 MCP 뒤에 ▶ 0:42:12

사실 저는 GitHub 레포만 관리하는 게 아니에요. 레포에는 맥락형 데이터만 두고, 관계형 데이터는 Supabase에 두고 MCP로 연결해 써요.

워드 파일로 관리할 만한 게 맥락형 데이터, 엑셀로 관리할 만한 게 관계형 데이터예요. ▶ 0:42:55 제품 구매자 목록, 사용자 데이터, 결제 내역 같은 것들이 관계형이에요. 이걸 마크다운으로 만들면 필터링도 안 되고 관리가 어려워져요.

어드민 화면과 지식 그래프는 만들지 않아요 ▶ 0:46:50

어드민 UI부터 얘기하면, 제가 만든 어드민을 쓰는 것보다 에이전트에게 말로 지시하는 게 더 편해요 ▶ 0:47:06. 그리고 어드민을 만드는 순간 어드민도 유지보수해야 돼요. ▶ 0:47:14

맡기는 일과 못 맡기는 일 ▶ 0:50:06

채널 운영 원칙은 "소모 최소화"예요. Threads는 요즘 지식을 공유하는 곳으로 접근하지 않아요 ▶ 0:50:29. AI 콘텐츠가 너무 많아서 일기처럼만 써요.

AI 잘 쓰는 도메인 전문가들의 오프라인 커뮤니티와 분기별 행사는 자동화가 거의 안 돼요. 제일 번거로운 걸 AI한테 못 맡겨요. ▶ 1:03:03

Q&A ▶ 1:09:02

오늘 해볼 것 ▶ 0:37:15

지식만 잘 남겨 두면 어떤 에이전트를 써도 잘 동작해요. ▶ 0:37:20 그래서 도구보다 지식을 먼저 정리하는 쪽을 권해요.