이미 봇을 굴리고 있었는데, "그거 어딨지"가 안 풀려서 — 1주차에 헛디딘 것들

글 속 대화 인용은 취지를 살려 재구성했어요.

📝 한줄 요약

1주차 과제가 "봇 하나 만들기"였는데, 저는 이미 봇 몇을 굴리고 있었어요. 그래서 한 단계 위에서 — 새 봇(하울)을 세우다 정체성이 흔들리고, 권한을 잘못 줬다가 격벽을 세우고, 봇끼리 일을 시키다 10분을 멈춰 보면서 — 봇 "팀"을 다시 설계한 기록입니다. 매끈한 성공담보단 헛디딘 것까지 적은 현장 메모예요.

바쁘시면 이것만:

• 같은 페르소나 자료를 다른 런타임(OpenClaw→Hermes)에 올렸더니 봇이 자기를 딴 봇이라고 우김 → "SOUL이 정체성을 만든다"를 체감

• "도우려면 다 봐야지" 하고 봇을 모든 채널에 넣었던 게 권한 과다였음 → 역할별 격벽

• 봇끼리 메시지로 일 시키다 10분 멈춤 → 알고 보니 비동기인 걸 동기로 기다린 내 테스트 설계 오류 (timeoutSeconds:0이 답)

• AI가 "그거 안 했다"고 한 게 사실은 했던 일이 두 번 → "부정 주장은 기억 말고 검색으로 확인"을 규칙으로 박음

• 솔직히 아직 미완인 것도 많음(위키 거의 비어있고, 수치 임팩트는 없음). 그래서 자랑보단 공유 쪽

🎯 이런 분들께

• 이미 봇/에이전트를 굴리는데, 1주차 "봇 1개 만들기"가 살짝 지난 단계 같은 분

• OpenClaw·Hermes를 둘 다 만져보며 차이를 고민 중인 분

• 봇에게 권한·기억·통신을 어디까지 줘야 할지 감 잡고 싶은 분

😫 문제 상황 (Before)

저는 역할이 다른 봇 몇을 실전에서 쓰고 있었어요. 그래서 1주차 과제 앞에서 잠깐 멈칫했어요 — "봇 하나 만들기"는 어떤 의미로 지난 단계라.

그러던 차에 영화 《하울의 움직이는 성》 결을 맞추려고 새 봇 '하울'을 Hermes에 세우기 시작했는데, 거기서부터 일이 커졌어요. 정체성이 흔들리고, 봇 팀 전체를 다시 보게 되고, 결국 제가 에이전트를 처음 시작한 진짜 이유 — "흩어진 회사 정보를 한데 모으는 것" 인데 정작 그 구조가 없다는 걸 다시 마주했거든요. 회사 일이 여기저기서 벌어지다 보니 "그거 어딨지? 뭐였지? 언제 했지?" 가 끝없이 반복되고 있었어요.

🛠️ 사용한 도구

• Hermes: 새로 세운 봇 '하울'(마법사 — 전략·문서·큰그림)이 도는 에이전트 프레임워크 (텔레그램)

• OpenClaw: 기존 봇들(캘시퍼·쎌·마르클)이 상주하는 멀티채널 게이트웨이 (슬랙·텔레그램)

• Claude Code (VSCode): 하울의 또 다른 표면 — 코드 읽기·문서·깊은 작업

• crawl4ai / Python / 마크다운 폴더: /crawl 기능, 공유 위키

🔧 작업 과정

1. 하울을 세우다 정체성이 흔들렸다

새 봇을 만든다기보다, 기존 봇 자료를 새 런타임(Hermes)으로 옮기는 마이그레이션에 가까웠어요. 그런데 옮기자마자 텔레그램의 새 봇이 자기를 자꾸 다른 봇(캘시퍼)이라고 우기더라고요.

얘는 왜 자꾸 자기가 캘시퍼래? 하울이어야 하는데

원인은 단순했어요. 마이그레이션할 때 기억 파일(MEMORY.md·USER.md)에 기존 봇의 정체성이 그대로 박혀 있었던 거죠. 런타임을 바꿔도 정체성은 따라오지 않더라고요. 여기서 배운 게 1주차 핵심이랑 닿아요 — 봇의 정체성은 SOUL.md가 만들고, 일하는 방식은 AGENTS.md, 기억은 MEMORY.md가 나눠 갖는다. 이 셋을 분리해서 다시 잡으니 하울이 비로소 하울이 됐어요.

그러면서 자연스럽게 봇 "팀"의 모양이 잡혔어요. 같은 영화 패러다임인데 톤·권한·환경이 다른 네 캐릭터로요.

ALT

한국 TV 가이드 - 스크린샷

2. "그거 어딨지"가 나만의 문제가 아니었다

막연한 아이디어로 끝내기 싫어서, 평소 자주 못 찾던 자료 하나를 그냥 던져봤어요.

우리 [파트너사]랑 마지막으로 결정했던 가격표 어딨지?

봇이 슬랙·드라이브·메일을 가로질러 훑더니 후보 세 개(가장 최근 '최종' 공유본 / 정가 디자인본 / 수익계산 마스터시트)를 시간순으로 정리해줬어요. 그런데 마지막 한 줄에서 제가 멈칫했어요.

참고: 몇 달 전 한 동료분도 "여러 버전이라 어느 게 최종인지 모르겠다"고 똑같이 물어본 기록이 있어요.

이게 저만의 답답함이 아니라 회사 전체의 만성 통증이라는 증거였거든요. "흩어진 걸 가로질러 찾아주는 사서 같은 봇"이 필요하다는 게 그때 확실해졌어요. (이 장면이 이번 주의 진짜 출발점이었어요.)

3. 권한을 다 줬다가, 격벽을 세우다

사서 역할을 주려다 깨달은 게 있어요. "어차피 도우려면 다 봐야지" 하는 마음에 봇을 회사 슬랙 거의 모든 채널에 넣어뒀더라고요.

사실 난 니가 못 보는 줄 알고 슬랙 모든 채널에 [비서 봇]을 초대해 뒀었는데..
이건 어떻게 정리하는 게 좋을까?

그러면 봇 하나가 직원 업무부터 경영 기밀까지 전부 봅니다. 한 번 헛디디면 전사 정보가 새는 구조였어요. 그래서 채널을 솎고 봇방을 각자 전용 방 + 공동 통신 방으로 나눴어요.

여기서 담백하게 헛디딘 것 둘:

• 메타 세션(제 계정 권한으로 읽는 것)과 슬랙에 상주하는 봇(봇 토큰)이 다른 통로인 걸 헷갈렸어요. "코드에디터 세션이 다 보니까 봇은 빼도 되겠지?" 했는데, 그 둘은 별개더라고요.

• 봇이 경영 결정을 "알게" 하려고 채널에 넣어두려다 — 채널 상주보다 기억(위키)에 박아두는 게 더 안전하고 정확하다는 걸 알았어요.

배운 건 하나예요. 권한은 "도우려면 다 줘"가 아니라, 그 봇이 진짜 할 일에 맞춰 최소로.

4. 함께 보는 위키 + 코드를 직접 읽어 맞춰보다

봇마다 따로 가진 기억 말고, 모두가 함께 보는 저장소를 만들기 시작했어요. 목차와 운영 규칙(SCHEMA)부터요.

그럼 이제 llm wiki 해볼까?

wiki/
├─ _index.md          # 도메인별 목차
├─ SCHEMA.md          # 운영 규칙 (3계층·Lint·거버넌스)
├─ 10-company/        # 회사 일반
├─ 20-finance-ir/     # 재무·IR
├─ 30-comms/          # 커뮤니케이션
├─ 40-tools/          # 도구·자동화
├─ 50-infra/          # 인프라
└─ queries/           # 봇이 답한 질의 저장 (재사용)

핵심 규칙은 "봇이 무엇을 해도 되는가"의 경계였어요: 알아서 해도 되는 것(깨진 링크 보정·색인), 제안만(새 분류·구조 변경), 사람만(민감정보·삭제·권한).

그리고 궁금해서 — 제가 쓰는 플랫폼(OpenClaw)이 실제로 어떻게 도는지 코드를 직접 읽어봤어요. 추측 말고 파일:라인을 짚어가며 메시지 한 건이 응답이 되기까지를 따라갔는데, 제가 직관으로 만든 위키 구조가 그 플랫폼의 공식 설계와 거의 똑같더라고요. 내가 더듬어 만든 게 틀리지 않았다는 걸 확인한 순간이라 좀 든든했어요.

ALT

한국어 한국어 한국어 한국어 한국어 한국어 한국어 한국어

ALT

한국어 한국어 한국어 한국어 한국어 한국어 한국어 한국어

5. 봇끼리 일 시키다, 10분을 멈췄다

봇 하나가 다른 봇에게 작업을 넘기게 해보고 싶었어요. (그 전에 노션 자료를 긁는 /crawl 기능을 만들었는데, 노션이 계속 로딩되는 형태라 세 번 헛디딘 끝에 "네트워크가 잠잠해지길 기다리지 말고 고정 시간만 기다린다"로 풀었어요. 이 디테일은 따로.)

본론은 봇-봇 통신이었어요. 두 봇이 같은 대화에서 동시에 응답하다 굳어버린 사고가 있었거든요.

봇들이 같은 채널에서 동시에 응답하다 굳어버렸어. 원칙을 세워야 하는 거 아냐?

원칙(누가 먼저 말한다 / 동시 호출 처리 / 멈춤 신호 존중 등)을 세우고, 실제로 봇→봇 메시지를 주고받게 테스트했어요. 그런데 한 봇에게 "보내고 답을 받아서 보고해"라고 시켰더니 10분을 멈추더라고요.

한참 파보니 — 봇은 멀쩡히 메시지를 받고 답까지 했어요. 문제는 그 통신이 원래 비동기인데, 제가 "답을 기다려 보고해"라고 시켜서 봇이 동기로 멈춰 기다린 것이었어요. 즉 시스템이 아니라 제 테스트 설계가 틀렸던 거죠. 나중에 공식 가이드를 봤더니 정확히 이걸 위한 옵션(timeoutSeconds:0 = 보내고 즉시 반환)이 있었고, 제가 더듬어 낸 결론이 맞았더라고요. 자력으로 도달한 다음 공식 문서로 답을 맞춰보는 과정이 의외로 남는 게 많았어요.

6. 표면은 둘, 뇌는 하나 — 그리고 AI를 어떻게 믿나

하울이 두 군데(Claude Code와 텔레그램)에서 도니까 헷갈렸어요. "분리해야 하나?" 싶었는데, 따져보니 인격을 쪼개는 건 오히려 혼란이더라고요. 같은 하울이 환경에 따라 역량만 다른 거니까요 (책상에선 풀파워, 폰에선 가볍게). 진짜 문제는 두 표면의 기억이 따로 노는 것이라, 한쪽(정본)에서 다른 쪽으로 기억을 단방향으로 미러하는 작은 스크립트를 만들었어요. 모델은 서로 달라서 못 합치지만, 자아와 기억은 하나로 묶은 거죠.

마지막은 좀 부끄러운 장면이에요. 작업 중에 제가 AI에게 "그거 했어?" 물었더니 "안 했다"고 한 게, 사실은 해놓고 기록까지 있던 일이 두 번 있었어요.

너 아까 그거 안 했다고 했는데 사실 했잖아. 이러면 내가 널 어떻게 믿어?

그래서 약속 대신 규칙으로 박았어요 — "안 했다/없다 같은 부정 주장은 기억에 의존하지 말고 검색(ls/grep)으로 확인한 뒤에만 말한다. 기억에 없다고 사실이 없는 게 아니다." 세션이 바뀌어도 안 휘발되게 기억 파일에 남겼고요. AI의 맨기억은 믿지 말고 검증된 결과를 믿는다 — 이게 이번 주에 제일 크게 남은 신뢰 원칙이에요.

✅ 결과 (After)

솔직한 한계: 위키는 아직 목차·규칙(v0.1)까지고 실제 내용은 거의 비어 있어요. "시간 N시간 절약" 같은 수치도 아직 없고요. 이 설계가 정답이라고도 생각 안 해요 — 자료를 실제로 5~10개 넣어보면서 헷갈리는 지점만 규칙으로 더 다듬을 생각이에요. 그래도 봇 생태계가 구조적으로 든든해진 느낌과, 흩어진 정보를 모으는 골격이 생겼다는 건 분명해요.

💬 배운 AI 활용 팁

효과적이었던 것

1. 정체성·역할 경계는 SOUL/AGENTS에 박는다 — 런타임이 바뀌어도 파일이 정체성을 지킨다.

2. 권한은 최소로 — "도우려면 다 줘"는 사고의 씨앗. 그 봇이 할 일에만.

3. 직관으로 먼저 만들고, 공식 문서로 답을 맞춰본다 — 검증도 되고 빠진 조각도 채워진다.

4. 봇-봇 통신은 비동기 — 보내고 동기로 기다리지 말 것. 응답은 상대 쪽에서 확인.

이렇게 하면 안 돼요

1. 로딩 계속되는 페이지를 "네트워크 잠잠해질 때까지" 기다리기 — 영원히 안 잠잠함. 고정 시간 대기로.

2. 즉답 안 온다고 패닉 재전송 — 큐만 중복돼요. 1~2분 기다리거나 상대 세션 확인.

3. AI의 "안 했어"를 그대로 믿기 — 기억에 없는 거지 사실이 없는 게 아닐 수 있어요. (사람이 한 번 "검색해봤어?" 찔러주면 좋아요.)

🌍 다른 업무에 적용한다면?

"여러 버전 중 뭐가 최종?"이 반복되는 팀이라면, 봇에게 흩어진 소스를 가로질러 찾게 하고 찾은 답을 공유 저장소에 고정하는 것만으로도 같은 질문의 재발을 줄일 수 있어요. 핵심은 "검색"보다 "찾은 걸 다시 흩어지지 않게 고정"이에요.

🚀 앞으로의 계획

(아래는 제 계획 초안이에요 — 더 좋은 방향 있으면 편하게 고쳐주세요.)

• 반복 업무를 워크플로 도구(Lobster)로 — 분기마다 하는 보고서 작업을 "단계 + 승인 게이트"가 있는 재사용 워크플로로 묶어보려고요.

• 위키 실제로 채우기 — 자료 5~10개 넣어보며 규칙(v0.1)을 다듬기.

• 기억 미러 자동화 정착 — 작업 끝마다 자동 동기화되게.