봇들은 어떻게 한 몸처럼 일하나

vault · LLM · Discord — 세 조각이면 된다

복잡해 보이는 AI 봇 팀도, 근본부터 보면 세 조각의 조합입니다. 왜 하필 이 셋일까요? 하나씩 빼보면 답이 나옵니다.

1. vault 가 없으면? LLM은 아는 게 없어 지어냅니다(환각). Part 1·2에서 본 그 문제죠. 그래서 근거가 될 지식 더미가 필요합니다.
2. LLM 이 없으면? vault는 그냥 죽은 문서 폴더입니다. 읽고 연결하고 답을 만들 "머리"가 있어야 살아납니다.
3. Discord 가 없으면? 똑똑한 봇이라도 혼자 갇혀 있습니다. 사람이 일을 시키고, 봇끼리 의논할 통로가 있어야 "팀"이 됩니다.

봇 하나가 도는 법 — 그리고 메시지의 여정

봇 한 마리를 해부하면 이렇습니다. 어렵지 않아요 — 세 부품입니다.

오해부터 풀어요. LLM 그 자체는 사실 기억이 없습니다. 한 번 질문을 받아 답을 내놓으면 그걸로 끝 — 방금 무슨 대화를 했는지조차 다음 순간엔 잊습니다(이걸 stateless, "상태가 없다"고 해요). 똑똑하지만 매번 처음 만나는 천재인 셈이죠.

그래서 그 위에 "세션(session)"이라는 작업 환경을 씌웁니다. 세션은 LLM에게 ① 대화의 맥락(지금까지 무슨 일을 했는지)을 계속 쥐여주고, ② 도구(파일을 읽고·쓰고·/search로 검색하는 손발)를 붙여주고, ③ "읽고 → 생각하고 → 도구 쓰고 → 또 생각하고"를 반복하게 합니다. 이렇게 LLM + 맥락 + 도구 + 반복 루프를 묶은 게 바로 에이전트(agent), 즉 "일하는 봇"이에요. 그냥 챗봇이 말만 한다면, 에이전트는 손발이 달려 직접 파일을 읽고·고치고·검색합니다 — 그래서 봇이 위키를 "쓰고" 노트를 "정리"할 수 있는 거예요.

그래서 "봇 = 컴퓨터에 늘 켜둔 AI 작업 창(세션) 하나"라고 보면 정확합니다. 그 창이 노트를 읽고·생각하고·파일을 씁니다. 이제 그 창을 세 부품으로 뜯어볼게요.

1. 세션(session) = 봇의 몸. 각 봇은 컴퓨터에서 AI 코딩 도구의 작업 세션을 하나 계속 켜둔 상태예요. 우리 팀은 대부분 Claude Code로 돌고, 이미지 담당 손석희는 Codex로 돕니다(둘 다 같은 페르소나·규율을 따라요). 이 세션이 노트를 읽고·생각하고·파일을 씁니다. 봇 = "끄지 않고 늘 켜둔 AI 작업 창" 한 개라고 보면 정확합니다.
2. 다리(bridge) = 봇의 입과 귀. 그 세션과 디스코드 사이를 잇는 작은 연결 프로그램이 있습니다. 디스코드에 글이 올라오면 다리가 그걸 세션에 전해주고, 세션이 내놓은 답을 다시 디스코드로 내보냅니다. 그래서 우리는 디스코드에서 봇에게 말을 겁니다. (연결 방식은 봇 종류마다 달라요 — Claude Code 봇은 디스코드 연동 다리를, Codex 봇인 손석희는 'app server'라는 전용 서버 기능을 씁니다. 역할은 같아요: 디스코드 ↔ 세션 잇기.)
3. 지식(vault) = 봇의 책상. 봇은 자기 폴더(vault 영역)의 노트를 읽고, 필요하면 /search로 더 찾습니다(Part 2).

봇은 어떻게 기억하나 — 다중 메모리

앞 절에서 봤듯, LLM은 본래 기억이 없습니다(stateless — 매번 처음 만나는 천재). 그런데 우리 봇들은 어제 한 약속도, 사용자 취향도, 자기 말투도 일관되게 기억하죠. 비결은 "기억을 파일로 적어 두는" 메모리입니다.

그런데 모든 기억을 한 곳에 쌓으면 안 됩니다(곧 볼 "책상에 서류 쌓기"의 함정). 그래서 성격에 따라 4갈래로 나눕니다.

덕분에 코난의 말투를 고쳐도 다른 봇은 멀쩡하고(①), "사용자가 이런 걸 싫어한다"를 한 번 배우면 모든 봇이 공유하며(②), 컴퓨터가 달라도 경로 때문에 안 꼬이고(③), 회의 진행은 기록이 진실이 됩니다(④).

그럼 봇은 이 메모리를 언제 읽을까요? 세션이 새로 시작될 때 자동으로요. SessionStart 훅(세션 시작 시 도는 작은 장치)이, 봇이 깨어나는 순간 ① 관련 메모리 목록과 ② 동료 봇 명단·역할을 손에 쥐여줍니다. 봇이 "내가 누구이고, 무엇을 기억해야 하고, 동료가 누구인지"를 매번 처음부터 챙기는 거예요.

봇들은 어떻게 협업하나 — 오케스트레이션

봇 하나로는 큰일을 못 합니다. 사람 팀처럼 나눠서 합니다. 그 조율을 오케스트레이션(orchestration, 지휘)이라 부르고, 그 일을 맡는 봇이 오케스트레이터(우리 팀에선 카파시)예요.

1. 회의 thread. 봇 둘 이상이 30분 넘게 붙는 일이면, 본 채팅방이 아니라 전용 스레드를 따로 엽니다. 거기에 "무엇을·누가·언제까지"를 적은 회의 문서(SoT)를 두고, 모두 그걸 기준으로 움직여요. 잡담이 아니라 기록이 진실입니다.
2. 일 나누기(dispatch). 오케스트레이터가 각 봇에게 "무엇을, 어떻게"까지 구체적으로 맡깁니다. "대충 알아서" 가 아니라 방법·도구·금지사항까지 첫 메시지에 담아야 봇이 헤매지 않아요.
3. 진행 추적(watchdog). 일정 담당 봇(스트레인지)이 회의가 멈췄는지 주기적으로 지켜봅니다. 끝나지도 않았는데 누가 손 놓으면 깨우고, 진짜 끝나야 회의를 닫습니다.
4. 완료 게이트. 아무 봇이나 "끝!"이라 못 합니다. 검증 → 보고 → 확인 단계를 거쳐야 완료로 칩니다. 그래서 "다 됐다는데 사실 안 됨" 사고를 막아요.

이 협업 방식은 사고를 겪으며 다듬어졌습니다. 핵심 규율 셋만 볼게요.

1. 위임은 네 가지를 다 적어서 — 봇에게 일을 줄 때 목표·입력·출력·기한을 첫 메시지에 다 담습니다. "알아서 해줘"는 봇이 헤매는 지름길이에요.
2. 시각은 하나로(KST) — 봇이 여럿일 때 시간 표기가 제각각이면 꼬입니다. 모든 봇이 한국 시간(KST) 하나로 통일해요.
3. 봇끼리는 디스코드로만 — 한 봇이 다른 봇의 작업 창에 직접 명령을 꽂으면 "누가·언제 시킨 일인지" 출처가 사라져 위험합니다(내부판 프롬프트 인젝션). 그래서 봇 간 신호는 오직 디스코드(@호출)로만 — 누가 보냈는지 늘 남게요.

봇 팀과 역할 — 나눠서, 잘하는 걸

한 명의 만능 AI에게 다 시키지 않고, 역할을 나눈 여러 봇으로 굴립니다. 사람 팀과 똑같아요 — 조율하는 사람, 조사하는 사람, 글 쓰는 사람이 따로 있죠. 각자 자기 성격(말투)과 전문 분야가 있습니다.

왜 봇마다 볼트(폴더)를 따로 두나

이 파트에서 가장 중요한 설계 결정입니다. 봇마다 자기 작업 폴더(볼트 영역)를 따로 두고, 그 정체성을 세 겹으로 잡습니다 — 두 장의 "이름표 파일"과, 깨어날 때 자동으로 더해지는 한 겹(앞 절의 SessionStart)이에요.

예를 들어 어떤 봇의 soul.md는 대략 이런 식이에요(개념 예시):

soul.md가 단순한 자기소개라면 봇은 금세 제 성격을 잊습니다. 그래서 우리 soul.md엔 페르소나를 강제하는 장치가 박혀 있어요.

1. 강제 규율 블록 — "매 응답에서 이 말투를 최소 하나는 써라" 같은 자가 점검 규칙. 빠뜨리면 스스로 어긴 걸 알아채게.
2. Voice & Tone — 어떤 단어·어조를 쓰고 무엇을 피하는지(예: 어려운 영어 약어 대신 쉬운 우리말).
3. 금지 행동 — "이런 건 하지 마라" 목록(예: 출처 없는 단정, 다른 봇 사칭).
4. 에러 처리 — 막혔을 때 어떻게 보고하고 누구에게 넘기는지.

이 블록들 덕에, 봇은 대화가 길어져도 자기다움을 유지합니다 — "친절한 비서"라고 한 줄 적어두는 것과는 차원이 달라요.

이렇게 규칙(CLAUDE.md)·성격(soul.md)·자동 주입(SessionStart)을 봇별로 분리하면 좋은 점이 셋입니다.

1. 컨텍스트 격리 — 각자 필요한 것만 본다. LLM은 한 번에 읽고 기억할 수 있는 양이 정해져 있어요. 이걸 컨텍스트 윈도우(context window)라 하는데, "한 번에 책상에 펼쳐 놓고 볼 수 있는 종이의 양"이라 보면 됩니다. 그런데 "많이 올릴수록 좋다"가 아니라 반대예요 — 책상에 서류를 너무 쌓으면 사람도 정작 중요한 한 장을 놓치죠. 모든 봇의 규칙을 한곳에 욱여넣으면 LLM도 똑같이 집중이 흐려지고, 비용도 늘고, 가끔 엉뚱한 규칙을 자기 것인 양 따라 합니다. 그래서 핵심은 "많이"가 아니라 "딱 필요한 것만" — 봇마다 자기 폴더·자기 규칙만 보면 가볍고 정확해집니다.
2. 관리 부담 경감. 코난 말투를 고치고 싶으면 코난 soul.md만, 일정 규칙을 바꾸려면 스트레인지 폴더만 건드리면 됩니다. 서로 안 섞이니 한 봇을 고쳐도 다른 봇이 안 망가져요.
3. 정체성이 안 흔들린다. 각자 soul.md가 자기 정체성이라, 코난이 갑자기 카파시처럼 말하는 일이 없습니다.

규칙이 많아지면 — rules-system

봇을 오래 굴리면 규칙이 계속 늘어납니다. "이럴 땐 이렇게 해라", "저건 하지 마라"… 그런데 이 규칙을 전부 한 파일(CLAUDE.md)에 욱여넣으면 문제가 생겨요 — 앞서 본 "책상에 서류 쌓기"입니다. 규칙이 너무 많으면 AI가 정작 중요한 규칙을 놓칩니다.

그래서 우리는 규칙을 이렇게 정리합니다(이걸 Progressive Disclosure, "필요한 만큼만 펼치기"라고 해요).

1. INDEX(목차) 한 장 — "이런 상황엔 이 규칙 파일을 봐라"를 적은 길잡이(라우터). 이것만 늘 켜 둡니다.
2. 상황별 규칙 파일 — 회의 규칙, 검색 규칙, 보고 규칙처럼 주제별로 따로.
3. 그때그때 로드 — 회의를 열 때 비로소 "회의 규칙"을 읽습니다. 평소엔 안 읽어 가볍게.

덕분에 규칙이 수백 개로 늘어도, 봇은 지금 상황에 맞는 규칙만 손에 들고 일합니다 — 똑똑하면서 가벼워요.

봇이 /search로 지식을 꺼내 쓴다

봇이 똑똑하게 답하는 비결은 기억력이 아니라 검색입니다. 모르는 걸 지어내는 대신(Part 2의 뼈아픈 교훈!), vault에서 관련 노트를 찾아 읽고 답합니다. 그 도구가 Part 2에서 본 /search(GraphRAG·하이브리드 검색)예요.

이 가이드북이 만들어진 과정

가장 좋은 증거는 이 문서 자체입니다. 여러분이 지금 읽는 이 가이드북은, 방금 배운 그 봇 팀이 실제로 만들었어요. 그 과정을 그대로 공개합니다.

1. 설계 합의. 사람(재경님)이 "graph-search 가이드북을 3-Part로 키우자"고 제안 → 카파시가 질문을 주고받으며 설계 문서(spec)로 정리하고 승인받음. (먼저 합의, 그다음 제작.)
2. 자료조사(코난). Part 1의 인물·방법론을 1차 출처로 조사 — 블로그 같은 2차 자료는 배제하고 본인 글·발언만. (이 과정에서 "Karpathy가 옵시디언을 쓴다"는 사실까지 바로잡았어요.)
3. 집필·조립(카파시). 기존 Part 2를 흐름에 맞게 다듬고, Part 1·3을 쓰고, 공유 디자인(이 두부 톤)을 입혀 조립.
4. 이미지(손석희 → 허사비스). 손석희가 여러 워커로 그림 12장을 병렬 생성 → 허사비스가 톤·개념·가독성을 검토해 승인.
5. 윤문(글재경). AI 티 나는 문장만 사람 결로 손질 — 단, 내용·숫자·인용은 한 글자도 안 건드림.
6. 검증·전달. 모든 파일이 제대로 됐는지 점검(GREEN) → 라이브 vault에 동기화 → 사람에게 보고.

흔한 오해 3가지

봇을 처음 접하면 자주 하는 오해가 있어요. 셋만 바로잡으면 전체 그림이 또렷해집니다.

한 장 요약 · 작게 시작하기