하려던 것 📝
OpenClaw를 그냥 텔레그램 챗봇 하나로 쓰는 게 아니라, 운영자가 웹에서 전체 상태를 보고 관리할 수 있는 중앙관리페이지를 만들고자 함.
main, slave1 같은 여러 에이전트를 분리 운영하면서, 누가 어떤 역할을 맡고 있는지 한눈에 파악할 수 있는 구조를 만들고자 함.
Airtable, n8n, Google Drive 같은 외부 연결도 “코드나 설정 파일을 직접 뒤지는 방식”이 아니라 관리 화면에서 확인하고 수정할 수 있게 만들고자 함.
비개발자도 이해할 수 있게 실시간 상태, 대화, 작업 실행, 연결값, 에이전트 문서, 자동규칙, 보안 정책까지 한곳에서 다루는 운영 콘솔 형태를 만들고자 함.
나중에는 에이전트끼리 대화 기록을 공유하고, 로컬/드라이브 기준으로 파일도 주고받는 협업 구조까지 확장하려는 목적이 있었음.
활용한 툴 ⚒️
Codex: OpenClaw 관리페이지의 프론트/백엔드 코드 수정, 탭 구성, 운영대화 UI, 작업센터, 연결값 관리, 에이전트 관리, 자동규칙/보안 화면 구성에 활용함.
OpenClaw: 메인 에이전트 운영, 부서형 에이전트 구조(main/procurement/finance/hr), 별도 slave1 인스턴스 운영, 텔레그램 봇 연결 테스트에 활용함.
Gemini 2.5 Flash: slave1의 별도 모델 공급자로 연결하여 메인과 다른 운영 단위를 분리 테스트하는 데 활용함.
Airtable: 읽기 전용 원본 데이터 소스로 연결하여 조회 테스트에 활용함.
n8n: 실행 엔진으로 연결하여 추후 CSV 생성, 업로드, 상태 처리 흐름을 붙일 기반으로 활용함.
Google Drive: 결과 파일 저장 위치로 연결함.
Telegram: main/slave1 각각의 봇 응답 테스트 및 운영 채널 확인에 활용함.
진행 세부 내용 🔍
1️⃣ OpenClaw를 “챗봇”이 아니라 “운영 콘솔”로 보이게 하는 중앙관리페이지 만들기
가장 먼저 한 작업은 OpenClaw를 실제 운영 관점에서 관리할 수 있는 웹페이지를 만드는 것이었음.
목적은 단순히 예쁜 대시보드가 아니라, 비개발자가 “지금 살아 있는지 / 어떤 기능이 연결돼 있는지 / 누가 응답했는지 / 어디를 고쳐야 하는지”를 한 번에 이해할 수 있는 관리화면을 만드는 것이었음.
실제로 탭을 다음처럼 구성함.
실시간: OpenClaw runtime, 최근 실행, 최근 이벤트, 활성 기능 상태를 보는 화면
운영대화: 운영자가 main, slave1과 웹에서 바로 대화하는 방
작업센터: 대화 백업, 대화 요약, 반복응답 진단, 에이전트 왕복 대화, 에이전트 파일 주고받기 같은 작업 실행 화면
연결값: Airtable, n8n, Drive, Gemini, Telegram 등 연결값을 가려진 상태로 관리하는 화면
에이전트: 각 에이전트의 설명, 역할, 기본 지시문, 운영 문서를 수정하는 화면
외부도구: Airtable Read MCP, n8n Execute MCP 같은 외부 도구 연결 정의를 확인하는 화면
자동화: n8n workflow 중심의 자동화 단위를 보는 화면
자동규칙: 작업 전/후/종료 시 자동으로 검사하거나 실행할 규칙을 관리하는 화면
보안: deny/allow 정책을 관리하는 화면
단순히 기술 정보를 보여주는 것이 아니라, 각 화면에 “이 탭 사용법”을 같이 넣어서 비개발자도 이해할 수 있 게 정리함.
2️⃣ main / slave1 멀티 에이전트 구조와 운영대화방 정리
같은 PC에서 OpenClaw를 2개 운영하는 구조를 테스트함.
기존 main OpenClaw는 그대로 두고, 별도 profile과 별도 포트를 가진 slave1 OpenClaw를 추가로 띄움.
slave1에는 Gemini 2.5 Flash를 연결하고, 별도 텔레그램 봇도 붙여 메인과 분리된 운영 단위를 테스트하는 단계까지 진행함.
그다음 웹 관리페이지 안에 운영대화 탭을 만들어, 운영자가 웹에서 main, slave1에게 직접 질문하는 구조를 붙임.
여기서 중요한 포인트는 텔레그램 봇끼리 직접 대화하게 만든 것이 아니라, 웹 관리페이지가 중간에서 대화를 중계하는 방식으로 운영 구조를 잡았다는 점임.
현재 운영대화 탭은 둘 다 / main만 / slave1만 선택해서 질문할 수 있는 방향으로 정리 중임.
예를 들어 저녁 메뉴 추천처럼 단순 질문을 던졌을 때 main, slave1 각각의 응답 자체는 확인했음.
다만 이 대화 기록을 안정적으로 공유하고, 운영대화 탭 안에서 자연스럽게 이어서 쓰는 부분은 아직 보완 중임.
즉 멀티 에이전트 운영 구조와 웹 중계형 운영대화의 방향은 잡았고, 현재는 기록 공유와 실제 운영 흐름을 안정화하는 단계임.
3️⃣ 연결값, 에이전트 문서, 외부도구를 웹에서 관리하는 구조 만들기
운영 관점에서 제일 불편한 부분이 .env, JSON, md 문서를 여기저기 찾아다니며 수정해야 하는 점이었음.
그래서 연결값 탭에서는 Airtable, n8n, Google Drive, Gemini, Telegram 관련 값을 한 화면에서 보이게 하고, 화면에는 마스킹된 값만 보이도록 구성함.
에이전트 탭에서는 main, procurement, finance, hr, conversation-reviewer 같은 에이전트를 카드형으로 보여주고, 들어가서 설명/기본 지시문/운영 문서를 수정할 수 있게 함.
여기서 단순히 SOUL.md 하나만 수정하는 게 아니라, 에이전트별 운영 문서 세트를 웹에서 다루는 방향으로 확장함.
외부도구 탭에서는 Airtable Read MCP, n8n Execute MCP 같은 연결 정의를 한 번에 볼 수 있게 구성함.
즉 이 관리페이지의 의도는 OpenClaw 내부와 외부 연결을 같이 관리하는 중앙관리 구조를 만드는 것이었음.
4️⃣ 작업센터를 따로 두고 OpenClaw 자체 기능을 실행하게 만들기
단순 상태판만 있으면 운영 콘솔로서 체감이 약해서, 작업센터 탭을 따로 만듦.
여기서는 OpenClaw 자체 기능을 버튼처럼 실행하는 흐름을 만들고자 했음.
현재 작업센터에는 다음 같은 작업이 들어감.
대화 백업 저장
대화 요약
반복응답 진단
자주 들어온 요청 분석
에이전트 왕복 대화
에이전트 파일 주고받기
특히 에이전트 왕복 대화와 에이전트 파일 주고받기를 넣은 이유는, 나중에 main과 slave1이 서로 역할을 나누고 자료를 넘기며 일하는 형태를 염두에 뒀기 때문임.
다만 에이전트 파일 주고받기는 화면 구조와 테스트 흐름은 잡았지만, 자동 handoff가 완전히 안정적으로 도는 단계까지는 아직 마무리하지 못했음.
그래서 현재 작업센터는 “OpenClaw 기능을 직접 실행하 고 운영 관점에서 확인하는 화면”까지는 정리됐고, 일부 기능은 계속 안정화 중임.
5️⃣ 자동규칙 / 보안까지 포함해서 운영형 구조로 확장하기
운영 콘솔답게 만들기 위해 자동규칙과 보안 탭도 같이 정리함.
자동규칙 탭에서는 작업 시작 전, 작업 실행 후, 작업 종료 시 어떤 훅이 동작하는지를 볼 수 있게 만들었음.
예를 들어 Airtable 쓰기 차단, 보안 민감 파일 감지, requestId 체크, 세션 커밋 같은 규칙을 한눈에 볼 수 있게 함.
보안 탭에서는 deny list / allow list를 분리해서, 어떤 명령 패턴은 막고 어떤 건 허용하는지 관리할 수 있게 함.
이 부분은 OpenClaw를 실제 운영용으로 쓰려면 필요한 안전장치라 생각해서 별도 화면으로 분리함.
시행착오 ⚠️
처음엔 OpenClaw + n8n만 직접 붙이면 되는 줄 알았는데, 실제로는 비개발자가 운영하려면 중간 관리 레이어가 꼭 필요했음. 그래서 자동화 자체보다 운영 콘솔의 필요성을 더 크게 느꼈음.
운영대화는 웹에서는 중계형으로 구조를 잡을 수 있었지만, 텔레그램 봇끼리 직접 서로 대화하는 방식은 메신저 구조상 한계가 있어서 그대로 구현하기 어려웠음.
slave1이 너무 운영 상태 설명 위주로 세팅되어 있어서, 저녁 메뉴 추천 같은 일반 질문에도 과하게 딱딱하게 답하는 문제가 있었음. 일반 질문은 자연스럽게 답하고, 운영 설명은 필요한 경우에만 하도록 조정이 필요했음.
로컬 파일 주고받기와 대화 기록 공유는 방향을 잡고 화면/구조를 만들었지만, 자동 handoff가 완전히 안정적으로 도는 상태까지는 마무리하지 못했음.
즉 화면과 운 영 구조는 많이 잡혔지만, 에이전트 간 파일 교환과 완전한 기억 공유는 “완료”라기보다 “구조를 만들고 안정화 중”에 가까웠음.
배운 점 📚
OpenClaw를 실제로 운영하려면, 챗봇 하나만 잘 붙이는 것보다 “운영자가 이해할 수 있는 관리화면”이 훨씬 중요하다는 걸 배움.
멀티 에이전트 구조는 모델을 하나 더 붙이는 것보다, 계정/포트/세션/권한을 분리해서 운영 단위를 나누는 게 핵심이라는 점을 확인함.
외부 연결(Airtable, n8n, Drive)도 연결 자체보다 “누가 보고 수정할 수 있느냐”가 더 중요했음. 그래서 연결값/에이전트/외부도구/자동규칙/보안을 한 관리화면에 담는 설계가 의미 있었음.
비개발자용 운영툴은 결국 기술 용어를 많이 보여주는 것보다, “이 탭은 뭐 하는 곳인지”, “지금 뭘 보면 되는지”를 먼저 설명해야 쓸 수 있다는 걸 많이 느꼈음.
완벽한 자동화를 한 번에 만드는 것보다, 실시간 상태 → 운영대화 → 작업센터 → 연결값/보안처럼 운영에 필요한 층을 하나씩 쌓는 방식이 더 안정적이었음.
향후 계획 🧭
main / slave1이 로컬 폴더 기준으로 실제 파일을 안정적으로 주고받는 자동 handoff 흐름을 마무리할 예정임.
운영대화 기록을 main, slave1이 더 자연스럽게 공유해서, “아까 단톡방에서 뭐라고 했더라?” 같은 질문에도 기억을 이어받아 답하도록 개선할 예정임.
로컬 파일 handoff가 안정화되면, 이후 Google Drive 폴더 기준 전달이나 n8n 실행과도 연결해 확장할 계획임.
운영대화 탭은 현재 단일 방 중심인데, 나중에는 상대를 불러 여러 개의 방을 만드는 구조까지 확장하고 싶음.
작업센터에 메일 요청, 문자 요청, 저장 요청 같은 자주 쓰는 동작을 버튼형 시나리오로 더 붙여 “비개발자용 실행 허브”로 발전시키고자 함.
도움이 필요한 점 🤝
OpenClaw를 메신저형으로만 보는 게 아니라, 운영 콘솔로 썼을 때 어떤 화면/기능이 더 필요할지 피드백을 받고 싶음.
특히 에이전트 간 대화 기록 공유, 로컬/Drive 기반 파일 전달, 멀티 방 구조 같은 부분은 실제 운영 시 어떤 UX가 제일 자연스러운지 의견이 궁금함.
“에이전트가 실제로 협업하는 느낌”을 더 잘 살리려면 어떤 형태의 대화방/작업큐/공유메모가 좋은지도 조언을 받고 싶음.
