Field Log · Entry
OpenClaw는 정말 '딸깍'을 해주는가 — 20봇 실험을 1프로젝트로 좁힌 기록
Slack에 봇 20개를 풀고 “iCME 백엔드 만들어줘, 360me QA 돌려줘, 코인 백테스트 해줘”를 동시에 시킬 수 있을 줄 알았습니다. 결과는 정반대였습니다. 한 달 안에 openclaw.json이 24번 깨졌고, 봇 사이의 작업은 누가 어디서 시작했는지조차 추적이 안 됐습니다.
결론부터 말하면, OpenClaw는 모든 걸 ‘딸깍’ 해주는 도구가 아니라, 하네스가 잘 깔린 반복업무를 슬랙에서 호출하는 인터페이스입니다. 저는 그걸 모르고 모든 개발/QA/반복업무를 다 맡겨보다, 한 달 만에 한 프로젝트로 좁히고 반복업무만 스킬로 정리한 뒤에야 진짜 ‘딸깍’을 봤습니다. 이 글은 그 과정의 1인칭 기록입니다.
이 글이 답하는 질문
- OpenClaw로 “모든 걸 자동화”가 왜 안 되는가?
- 봇 20개를 1개로 줄였더니 무엇이 바뀌었나?
- OpenClaw를 ‘딸깍 도구’처럼 쓰려면 어떤 사전 정리가 필요한가?
사전 안내 — 이 글은 하네스 엔지니어링 시리즈의 사례편입니다. 시리즈를 처음 본다면 1편 — 7축 로드맵부터 보면 본문의 “하네스가 비어 있었다”는 표현이 훨씬 또렷해집니다.
OpenClaw가 약속하는 ‘딸깍’은 무엇인가
OpenClaw는 한 줄로 말하면 Slack을 인터페이스로 여러 Claude Code 에이전트를 호출하는 오케스트레이션 도구입니다. 채널마다 봇을 두고, 봇마다 워크스페이스(SOUL.md, AGENTS.md, MEMORY.md)를 두고, openclaw.json에 라우팅을 적어두면 슬랙에서 @commander ~해줘 한 줄로 작업이 떠오릅니다.
처음 만나면 머릿속에 두 장면이 자동으로 그려집니다.
- “팀 슬랙에 채널만 만들면 풀스택 1팀이 생기는구나.”
- “개발/QA/반복업무를 다 슬랙으로 모으면 콘솔에서 일할 일이 없겠다.”
이게 제가 가진 ‘딸깍 환상’이었습니다. 그리고 이 환상은 OpenClaw가 잘못한 게 아니라 제가 하네스를 비워둔 채 시작한 게 잘못이었습니다.
1차 시도 — 20봇으로 모든 걸 돌려보다
처음 한 일은 단순했습니다.
- iCME(영어학습)·360me(MBTI 인식차)·calculate_math(커리큘럼 뷰어)·coin(트레이딩 백테스트) 네 프로젝트에 각각 commander/be/fe/qa/design/research 봇을 풀었습니다.
- 사일로별 6개 × 4프로젝트 ≈ 20+ 봇. 슬랙 사이드바가 빽빽했고, 멀티프로젝트가 진짜 돌아가는 줄 알았습니다.
- 매일 슬랙에 들어가 “오늘 할 일 정리해줘 → 분배해줘 → 결과 합쳐줘”를 4번 반복했습니다.
처음 며칠은 멋있었습니다. 슬랙 스레드 5개가 동시에 움직이는 장면은 시각적으로 강력합니다. 그러나 한 주가 지나면서 “무엇이 끝났는지”를 확인할 수 없다는 사실이 점점 무거워졌습니다.
부딪힌 벽 — 무엇이 무너졌나
구체적으로 무너진 자리는 다음 세 곳이었습니다.
1) 설정 파일이 일주일에 5번 깨진다. ~/.openclaw/openclaw.json은 한 달에 19번 .clobbered.*로 백업이 떨어졌고, 그중 5번은 하루(2026-05-13) 에 몰렸습니다. 봇이 늘어날수록 라우팅·바인딩·권한 충돌이 생기고, 한 봇의 변경이 다른 봇 설정을 덮어쓰는 일이 잦아졌습니다.
2) 봇이 만든 코드를 봇이 모른다. 개발과 QA를 각각 다른 봇에 맡기면, QA 봇은 개발 봇의 코드 의도를 모릅니다. 코드 컨벤션·결정 사항·이전 PR 맥락이 봇 사이로 흘러가지 않습니다. 사람이 풀스택으로 일할 때 머릿속에 자동으로 들고 있는 것을 봇은 들고 있지 않습니다.
3) 같은 명령에 다른 결과가 나온다. 반복업무도 “주식 뉴스 정리해줘”라고만 시키면 어떤 날은 표가 나오고, 어떤 날은 줄글이 나옵니다. 결정적 절차가 없으면 ‘딸깍’이 아니라 매번 새 작업입니다.
이 세 가지가 동시에 터지면 OpenClaw 잘못처럼 보입니다. 그러나 한 발 떨어져 보면 원인은 같았습니다 — 하네스의 7축이 비어 있었습니다. 시리즈 1편에서 정리한 규칙·도구·기억·권한·역할·검증 중 어느 하나도 봇 단위로 정착돼 있지 않았습니다.
깨달음 — OpenClaw가 못한 게 아니라 하네스가 비어 있었다
여기서 가장 중요한 자각을 적어둡니다.
OpenClaw는 잘 깔린 하네스를 Slack으로 펼치는 도구지, 하네스를 대신 만들어주는 도구가 아니다.
봇 SOUL.md는 한 줄 정체성만 있었고, AGENTS.md는 협업 규칙이 비어 있었고, MEMORY.md는 첫 줄도 안 쓰여 있었습니다. 그 상태로 봇을 20개 풀었으니 결과는 시리즈 2편(과업 분해), 4편(도구 설계), 7편(역할 분리), 8편(검증 루프)가 한꺼번에 결핍된 상태였습니다.
깨닫고 나서 한 일은 단순했습니다 — 좁히고, 결정적으로 만든다.
전환 — 1프로젝트 + 반복업무만
세 가지 결정을 한 번에 내렸습니다.
1) 프로젝트 1개로 축소. iCME·360me·math는 슬랙에서 잠시 내렸습니다. 남긴 건 coin(주식·트레이딩 리포트) 한 줄기. 여러 프로젝트를 동시에 굴리기 전에, 한 프로젝트로 감을 잡아야 한다는 게 가장 큰 교훈이었습니다.
2) 개발·QA는 다시 사람 손으로. OpenClaw에서 코드 작성과 QA를 빼고, Claude Code 콘솔에서 직접 작업하는 흐름으로 되돌렸습니다. 개발은 맥락 캐치가 필요하고, QA는 시각적 검증이 필요해서 슬랙 비동기 호출에 잘 맞지 않습니다.
3) 반복업무만 OpenClaw에 위임. 남긴 일은 셋입니다.
- 주식 뉴스 수집 (정해진 출처, 정해진 시간)
- 종목 리포트 작성 (정해진 섹션, 정해진 길이)
- 일/주 단위 요약 발송 (정해진 포맷)
이 세 가지는 모두 입력과 출력이 정해진 절차입니다. 즉 스킬로 정형화할 수 있는 작업입니다. 그래서 다음 단계가 자연스럽게 따라왔습니다.
스킬 + OpenClaw 조합이 작동하는 이유
반복업무를 Claude Code의 스킬로 만들고, OpenClaw는 그 스킬을 슬랙에서 호출하는 입구로 두기 시작하자 결과가 안정됐습니다. 이유를 정리하면 한 표로 들어옵니다.
| 역할 | 누가 책임 | 무엇이 보장되나 |
|---|---|---|
| 결정적 절차 (입력→출력 동일) | 스킬 (SKILL.md) | 매번 같은 결과 — 진짜 ‘딸깍’ |
| 인터페이스 (호출·알림·기록) | OpenClaw + Slack | 어디서든 한 줄로 시작, 결과가 스레드에 남음 |
| 판단 (어떤 스킬을 부를지) | 봇 SOUL.md/AGENTS.md | 사람이 매번 결정하지 않아도 라우팅됨 |
| 컨텍스트 (왜·언제·누구) | 봇 MEMORY.md + 프로젝트 KB | 다음 호출에서 잊지 않음 |
세 번째 칸이 비어 있으면 봇은 ‘판단을 흉내내는 무작위 호출자’가 됩니다. 두 번째 칸만 있고 첫 번째가 없으면 매번 다른 결과가 나옵니다. ‘딸깍’은 첫 번째 칸이 결정적일 때만 가능합니다.
결국 OpenClaw가 잘 작동하는 조건은 4편 — 도구 설계에서 정리한 “스킬은 결정적 절차, 에이전트는 판단 주체”라는 분리를 봇 레벨까지 끌고 내려오는 일과 같습니다.
OpenClaw를 잘 쓰는 5가지 가이드
지난 한 달의 시행착오를 다섯 줄로 압축하면 이렇습니다.
1) 프로젝트 1개로 시작해 감을 잡는다. 여러 프로젝트의 봇을 동시에 풀고 싶은 충동을 누르세요. 한 프로젝트에서 봇 1~2개가 안정적으로 돌기 전엔 두 번째 프로젝트를 붙이지 않습니다.
2) 개발·QA는 일단 OpenClaw에서 뺀다. 코드 작성과 시각적 검증은 Claude Code 콘솔이 더 잘합니다. OpenClaw는 반복 가능한 정해진 일에 강합니다.
3) 반복업무를 먼저 스킬로 만든다. SKILL.md에 입력·절차·산출물 형식을 못박은 다음, OpenClaw 봇이 그 스킬을 호출하게 합니다. 봇이 자유 작문하지 않도록 만드는 게 핵심입니다. 자세한 분리 방식은 4편을 참고하세요.
4) 봇을 만들기 전에 하네스 7축을 먼저 채운다. SOUL.md(정체성)·AGENTS.md(협업 규칙)·MEMORY.md(누적 컨텍스트)·TOOLS.md(도구)·knowledge/(도메인) 다섯 파일이 비어 있으면 봇은 헛돕니다. 시리즈 3편 — CLAUDE.md 구조화와 같은 골격을 봇 워크스페이스에도 적용하세요.
5) openclaw.json은 한 사람이 한 번에 한 곳에서만 편집한다. 여러 봇·여러 세션이 동시에 라우팅을 건드리면 24번 깨지는 게 어렵지 않습니다. 변경은 단일 진입점(예: commander 봇 또는 사람 직접)에서만 일어나도록 강제하세요.
FAQ
Q. OpenClaw로 개발 자동화는 영영 안 되나요?
가능합니다. 단, 하네스 7축이 모두 깔리고 검증 루프가 도는 이후입니다. 그 전엔 사람이 콘솔에서 직접 작업하는 편이 빠르고 안정적입니다. 처음부터 “다 자동”을 노리지 마세요.
Q. 봇은 몇 개가 적당한가요?
1개로 시작합니다. 사일로별 1개도 충분합니다. 봇을 늘리고 싶어질 때마다 “지금 봇 1개가 이 일을 결정적으로 끝내고 있는가?”를 먼저 물으세요. 답이 ‘아니오’면 봇 추가가 아니라 스킬·하네스 보강이 먼저입니다.
Q. 스킬과 에이전트(봇)는 어떻게 다르나요?
스킬은 결정적 절차(같은 입력 → 같은 출력)이고, 에이전트는 판단 주체(상황에 따라 다른 스킬을 부름)입니다. 자세히는 시리즈 4편에 정리해두었습니다. 둘을 섞어 쓰면 ‘딸깍’이 사라집니다.
Q. OpenClaw 대신 Claude Code만 써도 되지 않나요?
대부분의 1인 작업은 그렇습니다. OpenClaw가 의미를 갖는 순간은 여러 사일로/여러 사람이 같은 작업창(Slack)에서 비동기로 호출해야 할 때입니다. 그 전엔 Claude Code 콘솔이 더 빠릅니다.
마무리
‘딸깍’은 도구가 주는 게 아니라 결정적으로 만들어둔 절차가 줍니다. OpenClaw는 그 절차를 슬랙으로 펼치는 데 강하고, 그 절차가 비어 있으면 봇을 아무리 늘려도 같은 결과를 두 번 못 봅니다.
저는 다음 한 달은 한 프로젝트(coin)에서 주식 뉴스·리포트·요약 세 스킬을 안정시키는 데 쓰려 합니다. 이 세 스킬이 1주일 연속으로 같은 결과를 뽑아내면, 그때 두 번째 사일로를 다시 붙여볼 생각입니다. 후속 글에서는 스킬 한 개를 결정적으로 만드는 절차(SKILL.md 템플릿·실패 로그·재시도 정책)를 정리합니다.
시리즈를 함께 읽으면 본문의 흐름이 더 또렷해집니다 — 1편 7축 · 2편 과업 분해 · 4편 도구 설계 · 7편 역할 분리 · 8편 검증 루프.