맥미니 OpenClaw 비서 봇 만들기 (24) — 다섯 번째 봇과 진짜 비서실의 완성

맥미니 OpenClaw 비서 봇 만들기 (24) — 다섯 번째 봇과 진짜 비서실의 완성

강백호(JT)를 슬랙에 올리고, 한나에게 "판단해서 지시하는" 능력을 붙였다. 지금까지 만든 봇들이 각자 일하는 개별 직원이었다면, 이번엔 처음으로 "비서에게 말하면 알아서 담당자를 찾아 시키는" 그림이 완성됐다.

JT(강백호) 배치 — SOUL은 있고 TOOLS는 없었다

과거 세션에서 강백호 SOUL.md(160줄)는 이미 완성돼 있었다. 하지만 실제 openclaw.json 등록은 안 된 상태였고, TOOLS.md는 애초에 작성된 적이 없었다. JT 방 자체 확인 결과 "슬랙 앱 껍데기까지만 진행, Mac 등록은 대기"에서 멈춰 있었던 것.

JT 엔진을 실측한 결과 중요한 사실이 드러났다. CDA(cda_api.sh 래퍼)나 SA(run_sa_trigger.sh)와 달리 JT는 자동 트리거가 전혀 없다. 15단계 파이프라인(discover_bloggers.py부터 generate_run_result.py까지)을 하나로 묶는 스크립트가 없고, cron·launchd 등록도 없다. 봉투(run_result.json)도 output/ 폴더가 아니라 프로젝트 루트에 생성된다는 것도 이번에 처음 확인했다.

이 사실을 그대로 TOOLS.md에 박았다 — "강백호는 지금 시점에 봉투를 스스로 새로 생성시킬 수 없다. 할 수 있는 건 기존 봉투를 읽어 보고하는 것뿐이다."

exec-approvals — 같은 함정, 세 번째 반복

CDA·SA에서 겪은 것과 똑같은 패턴이 JT에서도 나왔다. 강백호에게 봉투를 읽으라고 시켰더니 "실행 승인이 필요한 환경"이라며 막혔다. traveler는 exec-approvals에 아무 등록이 없는 완전 백지 상태였다.

전용 읽기 래퍼(read_jt_envelope.sh)를 만들어 단일경로 패턴으로 등록했다. 1차 시도는 cat ~/... | head -100 형태(상대경로 + 파이프)로 걸려서 실패했고, thinking 로그에 "TOOLS.md에 나온 read_jt_envelope.sh를 써보자"라는 자기 수정 과정이 남아 있었다. 2차 시도에서 bare 절대경로로 정확히 호출해 승인 없이 통과했다.

payload 대조 결과 핀 98개, 지역별·카테고리별 수치 전부 일치. 지역 라벨 하나("오사카"를 "기타"로 표기)만 사소한 오류였다.

이사장의 두 갈래 요청 원칙

이번 세션에서 가장 중요한 결정이 나왔다. 지금까지 배선 검증은 전부 "이사장이 각 봇을 직접 멘션해서 확인"하는 방식이었다. 그런데 이건 테스트용이었지 실사용 패턴이 아니었다.

이사장이 확정한 실사용 원칙:

"한나, 주식 시세 알아봐줘"라고만 한다. "한나, 태웅에게 주식분석해"라고 봇을 지목해서 시키지 않는다. 한나가 요청을 듣고 스스로 도메인을 판단해서 해당 봇에게 위임하고, 결과를 검수해서 전달하면 된다. 그 전까지는 각 봇에게 직접 확인받는 것.

이건 지금까지 만든 시스템에 없던 조각이었다. 봉투 검수(봇→한나) 방향은 만들었지만, 한나가 요청을 받아 판단하고 위임하는 반대 방향(이사장→한나→봇)은 설계된 적이 없었다.

한나 SOUL 개정 — 1차 실패, 2차 성공

한나에게 "판단 애매하면 되묻는다"는 원칙을 추가했다. 실전 테스트("한나, NC 알아봐줘")에서 되묻기는 정확히 작동했다. 이사장이 "엔씨소프트"로 명확화하자 — 여기서 문제가 터졌다. 한나가 서태웅에게 위임하지 않고 직접 종목 요약을 만들어 답했다.

"실시간 시세가 아니라 검색 기준 데이터입니다. 정밀 분석이 필요하면 서태웅에게 넘기겠습니다"라는 문구가 결정적이었다. 위임이 조건부·선택사항처럼 표현된 것. 이건 전날 발생한 SA 사고(한나가 웹검색으로 종목분석을 지어낸 사건)와 같은 유형의 재발이었다.

원인은 명확했다. "애매하면 되묻는다"까지만 설계했지, "도메인이 확정되면 반드시 위임한다"는 다음 단계가 문서에 없었다. 되묻기와 위임 사이에 빈 틈이 있었던 것.

보강 문구를 추가했다 — "위임은 선택 사항이 아니라 의무다. '정밀 분석이 필요하면' 같은 조건문으로 위임 여부를 판단하지 않는다. 도메인이 확정된 순간 조건 없이 위임한다."

재검증("한나, 고영 알아봐줘" → "고영테크놀로지 맞아")에서 한나가 "서태웅 투입합니다. 투입했습니다. 결과 오면 검수 후 보고드리겠습니다"로 즉시 응답했다. 봉투 검수 과정("7필드 전부 ✓, status=success, 판정: 통과")까지 슬랙에 투명하게 노출하고, 서태웅의 실제 분석 결과를 그대로 전달했다.

SSOT 배선표 정리와 함정 하나 더

engines/README.md에 CDA·SA·JT 세 엔진의 배선 상태를 갱신하던 중, JT가 "✅ 불러봤다"로 이미 표시돼 있었는데 강백호가 한나 알림 없이 채널에 직접 게시한 사례가 발견돼 혼선이 생겼다.

확인 결과 — 이 요청은 이사장이 강백호를 직접 멘션한 직접요청이었고, "요청 경로 구분" 규칙이 추가되기 이전 시점에 발생한 것이었다. 규칙이 바뀐 시점과 요청이 발생한 시점을 혼동하면 잘못된 결론에 이른다는 걸, CDA 사이클에서 이미 한 번 겪었던 함정을 이번엔 미리 피해서 정확히 짚었다. 최종적으로 "✅ 불러봤다"로 되돌렸다.

오늘의 전체 상태

봇	상태
recon(CDA)	🔶 진짜 미해결 — 봉투 생성 성공, 한나 알림 원인 불명, 대기
analyst(SA)	🔶 검증 진행 중 — 2회 성공(ADI, 고영), 표본 축적 중
traveler(JT)	✅ 완료 — 직접요청 확정, 문제 없음
scout	✅ 운영중
researcher(SRA)	⬜ 엔진 생성 예정

교훈

• SOUL은 있어도 TOOLS(구체 실행 절차)가 없으면 봇이 못 움직인다. 이 패턴이 세 번째 반복됐다 — 원칙만 있고 절차가 없으면 어디서든 같은 실패가 난다.
• "애매하면 되묻는다"만으로는 부족하다. 되물은 다음 단계("확정되면 반드시 위임")까지 명시해야 빈 틈이 안 생긴다.
• 규칙 개정 시점과 사건 발생 시점을 항상 대조해야 한다. 안 그러면 이미 해결된 문제를 다시 붙잡거나, 진짜 문제를 놓친다.
• 문서 갱신과 실제 작동은 다르다. 한 번의 실전 검증으로 확정하지 말고, 다른 조건(다른 종목, 다른 시나리오)으로 재검증해야 진짜 확인이 된다.

→ 5봇 체제 완성. 다음은 recon 알림 재조사(조건부 대기) 또는 안 감독·권준호·정대만·채소연 배치(이사장 페르소나 확인 필요).