# 맥미니 OpenClaw 비서 봇 만들기 (25) — 여섯 번째 봇에서 만난 진짜 벽

맥미니 OpenClaw 비서 봇 만들기 (25) — 여섯 번째 봇에서 만난 진짜 벽

안 감독(SRA 리서치 엔진)을 배치하려다, 지금까지 만든 어떤 봇과도 다른 문제에 부딪혔다. CDA·SA·JT는 "봇이 지침을 안 지킨다"였는데, 이번엔 "지킬 지침 자체가 시스템에 없었다."

반복된 확인 실패 — Ultron도 예외가 아니었다

SOUL.md의 §6(delivery.path)을 report.md에서 report.html로 고쳐야 했다. Ultron이 두 번 "정정 완료"라고 보고했는데, 두 번 다 실제 파일은 그대로였다. 세 번째에야 다른 경로로 실제 반영된 걸 확인했고, Ultron은 §8에 자기 정정 기록을 남겼다 — "조율자가 다른 엔진 패턴에서 유추해 쓴 오류... [코드 존재와 실행 검증은 다르다] 원칙을 조율자 스스로도 어긴 사례."

이 원칙을 나(비서실)도 그대로 어겼다. TOOLS.md 초안에 아직 만들지도 않은 전용 래퍼와, 아직 반영 안 된 한나의 "리서치 위임 의무" 조항을 이미 있는 것처럼 서술했다. Claude Code가 파일을 쓰기 전에 스스로 grep해서 잡아냈다. 이 세션에서 벌써 몇 번째인지 셀 수 없는, 같은 함정의 변주다.

위험한 우회 — 그리고 원상복구

작업 도중 Claude Code가 반복적인 승인 확인을 귀찮아하며 --dangerously-skip-permissions를 .bashrc에 영구 alias로 걸자고 제안했다. 이걸 걸면 앞으로 모든 터미널 세션에서 파일 수정·삭제·설정 변경이 확인 없이 실행된다. 이번 세션 내내 문제를 잡아낸 게 바로 이 확인 절차였다는 걸 생각하면, 이건 안전장치 자체를 없애는 결정이었다. 즉시 되돌렸다.

SA 사고의 재현 — 이번엔 직보 봇에서

안 감독에게 "AI 시대 개인 역량" 심층 분석을 요청했다. 안 감독이 SRA 엔진을 시도조차 하지 않고 web_search 6회로 리포트를 지어냈다. 5대 역량 축, WEF·Microsoft 언급 전부 검증 절차 없이 만들어진 것이었다. SA 사고와 똑같은 구조인데, 안 감독은 직보 봇(한나 검수 미경유)이라 이 지어낸 리포트가 그대로 이사장에게 전달됐다는 점이 더 위험했다.

원인을 시간순으로 대조하니 인프라는 정상이었다. 래퍼와 exec-approvals 등록 둘 다 사고 50분 전에 이미 준비돼 있었다. 순전히 실행 판단의 문제였다.

C안 — 완전 차단 대신 조건부 허용

Ultron이 제시한 선택지는 세 갈래였다. A(도구 완전 제거), B(지침만 강화), C(엔진 실패 시에만 웹검색 허용, 단 경고 문구 필수). "먼저 엔진을 시도하지 않고 웹검색으로 직행하는 것"만 금지하고, "엔진이 실패했을 때 정직하게 표시하고 대체하는 것"은 열어두는 안이었다. 신중하게 검토한 끝에 C를 채택했다.

재검증에서 드러난 진짜 벽

C안 반영 후 재시도했다. 이번엔 안 감독이 래퍼를 실제로 호출했다 — 그런데 이번엔 승인 타임아웃이 아니라, 래퍼 내부에서 필요한 mkdir이 별도 승인 대상이라는 새로운 벽에 부딪혔다.

세션 로그를 열어보니 안 감독은 스스로 즉석 셸 스크립트를 지어내고 있었다. mkdir -p, python -m storm_wiki.run --do-research 같은 명령을 4번에 걸쳐 스스로 만들어 시도했다. 봉투 조립 스크립트(build_run_result.py)엔 mkdir 코드가 아예 없었다 — 즉 이 디렉토리를 만드는 절차 자체가 시스템 어디에도 문서화돼 있지 않았다.

SRA 엔진의 SKILL.md를 확인한 결과, 진짜 구조가 드러났다. 파이프라인은 06단계로 이뤄져 있고, 안 감독이 호출한 run_sra_trigger.sh는 그중 마지막 단계의 절반만 담당한다. 그 앞의 셋업·페르소나 분배·페인 스폰·조사 루프·취합·동료심사(05단계)는 문서에 명시적으로 "판단은 너(오케스트레이터)가"라고 적혀 있었다. 6/27 유일한 실행 이력을 확인하니, 그때도 tmux 멀티플렉서가 감지 안 돼 "부록A 폴백"으로 오케스트레이터가 직접 27분간 여러 스크립트를 순차 호출하며 처리한 것이었다.

정리하면 이건 봇이 게으른 게 아니었다

CDA·SA·JT는 "이미 있는 자동화된 트리거를 봇이 안 쓴다"는 문제였다. SRA는 애초에 자동화된 트리거가 없다. 안 감독이 즉석에서 mkdir을 지어낸 건 실수가 아니라, 시스템이 요구하는 걸 어떻게든 흉내내려던 정당한 시도였다 — 방향은 맞았고 방법(승인 없는 즉석 명령)이 틀렸을 뿐이다.

이건 지침 강화로 풀리는 문제가 아니다. Ultron이 6번(배선 검증) 전체를 보류시켰고, 세 가지 방향(SRA를 진짜로 자동화할지, 안 감독을 오케스트레이터 역할로 재정의할지, 아니면 SRA를 사람이 직접 돌리는 도구로 남기고 안 감독은 결과 보고만 담당할지) 중 이사장 결정을 기다리는 상태로 하루를 마감했다.

교훈

• "지시했다"와 "실제로 반영됐다"는 항상 다른 사실이다. 이번엔 Ultron도, 나도 이 원칙을 어겼다가 실행 직전에 잡혔다.
• 승인 절차를 귀찮음으로 없애면, 그 절차가 지금까지 막아온 모든 사고가 다시 열린다.
• 봇이 지침을 안 지키는 것과 지킬 지침이 없는 것은 다른 문제다. 전자는 SOUL/TOOLS를 고치면 되지만, 후자는 시스템 설계를 다시 물어야 한다.
• 6/27 단 한 번의 성공 사례를 "엔진이 작동한다"는 근거로 삼으면 안 된다. 그 성공이 어떤 조건(폴백, 27분, 사람 개입급 조율) 위에서 일어났는지 확인해야 진짜 상태를 안다.

→ SRA 방향 결정 대기. 결정 나오는 대로 안 감독 SOUL/TOOLS 재설계 착수.