에이전트가 알아서 일하게 만들고도 통제권은 쥐고 싶다 — OpenClaw Control UI의 예약 작업 화면

오픈소스 개인 AI 어시스턴트 OpenClaw를 집 서버에 올려 쓰다 보면 곧 이런 욕심이 생긴다 — "매일 아침 7시에 밤사이 변경사항을 요약해 줬으면", "15분마다 큐 길이를 한 번씩 체크해 줬으면". 사람이 매번 "이거 해 줘"라고 말하지 않아도 에이전트가 정해진 시각에 알아서 움직이게 하고 싶은 것이다. OpenClaw는 이를 위해 게이트웨이 안에 cron(예약 반복 실행기)을 내장했는데, 이 글은 그 cron을 명령줄이 아니라 브라우저 화면(Control UI)에서 보고 관리하는 경험에 집중한다 — 작업 목록, 다음 실행 시각, 켜고 끄는 토글, 실행 이력을 한 화면에서 다루는 방식이다.

배경 — 자율 에이전트의 역설: 알아서 일하되 감시는 가능해야 한다

AI 에이전트를 "자율적"으로 만든다는 건 사람이 매번 시키지 않아도 일하게 한다는 뜻이다. 그런데 사람 손을 떼는 순간 새로운 불안이 생긴다 — 지금 무슨 작업이 예약돼 있는지, 다음엔 언제 돌지, 어제 그 작업이 제대로 끝났는지 아무도 모른다는 점이다. cron은 그 자체로는 게이트웨이(메시지를 듣고 작업을 실행하는 OpenClaw의 상주 프로세스) 안에서 조용히 돌아가는 백그라운드 기능이다. 명령줄에서 openclaw cron list, openclaw cron runs 같은 명령을 쳐서 들여다볼 수는 있지만, 그건 매번 터미널을 열고 작업 ID를 외워야 한다는 뜻이다.

Control UI의 예약 작업 메뉴는 이 백그라운드 기능에 유리창을 달아 준다. Control UI는 게이트웨이가 같은 포트(:18789)로 함께 서빙하는 작은 단일 페이지 웹앱(SPA, 페이지 전환 없이 한 화면에서 동작하는 웹 애플리케이션)으로, 브라우저로 게이트웨이를 직접 조작하는 관리 콘솔이다. 그 안의 한 패널이 cron 작업 전용 화면이다.

다이어그램 설명. 이 그림은 운영자가 보는 화면부터 실제로 일하는 스케줄러까지의 한 줄 경로를 보여준다. 맨 위 운영자가 브라우저에서 예약 작업 패널을 열면, 그 패널은 게이트웨이에게 cron.list(작업 목록 요청)나 cron.runs(실행 이력 요청) 같은 메시지를 보내고, 게이트웨이 안의 cron 스케줄러가 SQLite(파일 하나로 동작하는 가벼운 관계형 데이터베이스) 상태 DB에서 답을 읽어 돌려준다. 점선은 사람이 보지 않을 때도 cron이 예약 시각마다 에이전트 턴이나 명령을 실제로 실행한다는 흐름이다. 핵심은 "일하는 주체(스케줄러)와 보는 창(UI)이 분리돼 있다"는 점이다 — UI를 닫아도 작업은 계속 돈다. 놓치기 쉬운 함정은 cron이 모델(LLM) 안이 아니라 게이트웨이 프로세스 안에서 돈다는 사실이다. 그래서 게이트웨이가 떠 있는 동안만 예약이 지켜지고, 모델을 바꿔도 스케줄은 그대로 유지된다. 그래서 사람에게 주는 가치는 분명하다 — "맡겨 놓되 언제든 들여다볼 수 있다"는 통제감이다.

핵심 문제 — 예약 작업을 "터미널로만" 다룰 때 생기는 마찰

예약 작업을 명령줄로만 관리할 때 실제로 불편한 지점이 몇 가지 있다. 구체적인 상황으로 풀어 보자.

다이어그램 설명. 이 그림은 "예약 작업 하나를 점검한다"는 단순한 일이 명령줄에서 거치는 단계를 보여준다. 위에서 아래로, 터미널을 열고 → 목록 명령으로 긴 작업 식별자를 눈으로 골라내고 → 그 식별자를 복사해 이력 명령에 붙여 넣고 → 돌아온 다음 실행 시각이 사람이 읽기 어려운 형태(예: nextRunAtMs라는 밀리초 단위 숫자)로 나오고 → 잠깐 멈추려면 또 정확한 플래그를 외워 입력해야 한다. 이게 한 작업당 반복된다는 게 함정이다. 작업이 두세 개면 견딜 만하지만, 아침 브리핑·큐 점검·배포 다이제스트·주간 분석처럼 늘어나면 "전체를 한눈에 보는 시야"가 사라진다. 즉 진짜 문제는 개별 명령의 어려움이 아니라 여러 작업의 상태를 동시에 조망할 수 없다는 것이다 — 어느 게 켜져 있고, 다음엔 뭐가 먼저 돌고, 어제 무엇이 실패했는지를 한 장면에 모을 수 없다.

특히 실패는 조용히 쌓인다. 매일 7시 브리핑이 사흘째 토큰 만료로 실패하고 있어도, 터미널을 열어 이력을 조회하기 전까지는 알 길이 없다. 그래서 필요한 가치는 "상태의 가시성"이다 — 작동 중인지, 멈췄는지, 마지막에 성공했는지를 묻지 않아도 보이는 화면.

해결 방법 — 목록·다음 실행·토글·이력을 한 패널에 모은다

OpenClaw는 cron의 모든 조작을 게이트웨이의 cron.* 메시지군(예: cron.list, cron.runs, cron.update)으로 노출하고, Control UI의 예약 작업 패널이 이걸 그대로 화면 위젯에 연결한다. 문서가 정리한 패널의 능력은 목록(list)·추가(add)·편집(edit)·즉시 실행(run)·켜기(enable)·끄기(disable)·실행 이력(run history)이다. 명령줄에서 외워야 했던 동작들이 버튼과 토글로 바뀐 셈이다.

다이어그램 설명. 이 그림은 한 패널 안에 모인 다섯 갈래의 조작을 펼쳐 보여준다. 가운데 패널에서 갈라지는 마지막 갈래가 가장 중요한 작업 목록인데, 한 줄에 이름·켜짐 여부·다음 실행 시각·마지막 실행 결과가 함께 표시된다(목록 요약은 게이트웨이가 id, name, enabled, nextRunAtMs, scheduleKind, lastRunStatus를 묶어 돌려준다 — 즉 "다음 언제, 마지막은 성공이었나"가 한 줄에 있다). 나머지 갈래는 새 작업을 만들거나 고치는 추가·편집, 잠깐 멈추는 토글, 지금 당장 한 번 돌려 보는 즉시 실행, 그리고 한 작업을 클릭해 그 작업만의 실행 이력으로 들어가는 흐름(점선)이다. 이 구조의 핵심은 "조회와 조작이 같은 화면에 있다"는 점이다 — 터미널이라면 목록을 본 뒤 ID를 복사해 다른 명령으로 넘어가야 했던 동선이, 여기선 보는 그 자리에서 토글을 누르거나 이력으로 들어가는 한 번의 동작으로 끝난다. 함정은 이 편리함이 권한을 푸는 게 아니라는 점인데, 다음 절에서 다룬다.

다음 실행 시각 — 밀리초 숫자를 사람이 읽는 시각으로

cron이 내부에 들고 있는 "다음 실행 시각"은 nextRunAtMs, 즉 1970년 기준 경과 밀리초라는 기계용 숫자다. 사람에게 그대로 보여주면 의미가 없다. Control UI의 목록은 이 숫자를 사람이 읽는 시각으로 풀어 한 줄에 얹는다. 여기에 스케줄의 종류(scheduleKind)도 함께 보인다 — OpenClaw의 스케줄은 세 가지다.

다이어그램 설명. 이 그림은 작업 목록의 "다음 실행" 칸 뒤에 숨은 세 가지 스케줄 종류를 보여준다. 한 번만 도는 일회성, 고정 간격으로 반복하는 방식, 그리고 다섯(또는 여섯) 칸짜리 cron 표현식(분·시·일·월·요일 자리로 시각을 적는 표준 표기. 0 7 * * *는 매일 7시)으로 정밀하게 거는 방식이다. 화면 관점에서 중요한 건, 운영자가 종류와 다음 시각을 나란히 보기 때문에 "이건 매일 도는 거고 다음은 내일 아침", "이건 한 번 쓰고 사라질 알림"을 구분할 수 있다는 점이다. 놓치기 쉬운 함정 하나 — cron 표현식에서 "일자"와 "요일"을 둘 다 채우면 둘 다 만족할 때가 아니라 둘 중 하나만 맞아도 실행된다(표준 Vixie cron 동작). 화면에서 다음 실행 시각을 보면 이 함정에 빠진 작업이 "생각보다 자주 도는" 게 눈에 띄어 바로 잡을 수 있다. 그래서 가치는 "의도한 주기와 실제 주기가 맞는지 눈으로 검증"된다는 데 있다.

켜기 / 끄기 토글 — 삭제하지 않고 잠시 멈추기

예약 작업을 다룰 때 자주 필요한 건 "지웠다 다시 만들기"가 아니라 "잠깐 꺼 두기"다. 휴가 동안 아침 브리핑을 멈추고 싶을 때 작업을 삭제하면 스케줄·전달 설정을 나중에 다시 입력해야 한다. 토글은 정의를 보존한 채 실행만 멈춘다.

다이어그램 설명. 이 그림은 켜짐과 꺼짐을 오가는 토글의 상태 전이를 보여준다. 켜진 작업을 끄면 작업 정의(스케줄·프롬프트·전달 대상)는 그대로 남고 예약 시각이 와도 실행만 건너뛰며, 다시 켜면 같은 설정으로 곧장 가동된다. 이게 삭제와 다른 점이 핵심이다 — 삭제는 정의 자체를 지워 복원이 불가능하지만, 토글은 되돌릴 수 있는 일시 정지다. 화면에서 이건 목록의 "켜짐 여부" 표시와 한 번의 클릭으로 끝난다. 함정은 "꺼 둔 걸 잊는" 것인데, 목록이 꺼진 작업도 회색 상태로 계속 보여 주므로 "왜 브리핑이 안 오지?" 할 때 한눈에 원인을 찾는다. 그래서 가치는 "임시 중단이 비용 없는 동작이 된다"는 점이다.

실행 이력 — 어제 그 작업이 정말 성공했나

자율 에이전트에서 가장 불안한 질문은 "내가 안 볼 때 일이 제대로 됐나"이다. cron은 모든 실행을 SQLite 상태 DB에 기록으로 남기고, 패널은 한 작업을 클릭하면 그 작업만의 실행 이력을 펼친다 — 언제 돌았고, 성공(ok)이었는지 실패(error)였는지, 아니면 건너뜀(skipped)이었는지.

다이어그램 설명. 이 그림은 한 작업의 실행 이력이 화면에 쌓이는 모습을 시간순으로 보여준다. 같은 "매일 7시 브리핑" 작업이 하루는 정상, 다음 날은 모델 호출 실패, 그다음 날은 로컬 모델 서버가 꺼져 있어 아예 시작 전 건너뜀으로 기록된다. 세 가지 종료 상태를 구분하는 게 중요하다 — 성공은 결과를 전달했고, 실패는 실제로 돌다가 깨졌으며, 건너뜀은 시작 조건이 안 맞아 모델 호출조차 안 했다(예: 로컬 Ollama·vLLM 같은 자체 모델 서버가 꺼져 있으면 OpenClaw가 미리 점검해 실행을 건너뛴다). 점선은 실패가 누적되면 별도 경로로 실패 알림이 나간다는 흐름이다. 이력 화면이 주는 가치는 단순하다 — "조용한 실패"가 더 이상 조용하지 않다. 사람이 묻지 않아도, 어제 무엇이 깨졌는지 화면에 남아 있고, 즉시 실행 버튼으로 그 자리에서 다시 돌려 확인할 수 있다.

전달 방식 — 결과를 어디로 보낼지도 화면에서 고른다

예약 작업의 결과는 어딘가로 가야 의미가 있다. 패널은 작업을 만들거나 고칠 때 전달 방식(delivery)도 화면에서 고르게 한다. 문서가 정리한 동작은 작업 종류에 따라 다음과 같다.

다이어그램 설명. 이 그림은 작업 결과의 세 가지 행선지를 보여준다. 채팅 채널로 알리는 방식은 운영자가 채널과 대상(예: 텔레그램 방 ID)을 화면 필드에 적어야 하고, 외부 시스템으로 넘기는 방식은 받는 쪽 HTTP 주소를 적으며, 아무 데도 안 보내는 내부 전용 방식은 결과를 밖으로 내보내지 않는다. 화면 관점에서 영리한 부분은 "알림 방식을 고르면 그때만 채널·대상 입력칸이 나타난다"는 점이다 — 필요 없는 필드로 화면을 어지럽히지 않는다. 또 격리 실행(독립된 임시 세션으로 도는 작업)은 기본값이 요약 알림이라, 별도 설정 없이도 결과가 오게 돼 있다. 함정은 외부 주소로 보내는 방식과 채팅 알림 방식을 동시에 켤 수 없다는 점인데, 화면 검증이 잘못된 값일 때 저장 버튼을 비활성화해 막아 준다. 그래서 가치는 "잘못 설정할 길 자체를 화면이 좁혀 준다"는 데 있다.

결과 — 무엇이 좋아졌나

예약 작업 메뉴가 들어오면서, 앞에서 본 "터미널 마찰"과 "조용한 실패"가 이렇게 정리된다.

이전 (명령줄만)	이후 (Control UI 예약 작업 패널)
여러 작업의 상태를 한눈에 못 봄	이름·켜짐·다음 실행·마지막 결과가 한 줄 목록에
다음 실행 시각이 밀리초 숫자(nextRunAtMs)	사람이 읽는 시각 + 스케줄 종류 표시
잠깐 멈추려면 명령·플래그를 외워 입력	토글 한 번으로 정의 보존한 채 일시 정지
실패가 조용히 쌓임 (이력 명령 쳐야 확인)	작업별 실행 이력(ok/error/skipped)이 화면에
전달 설정 실수를 실행 후에야 발견	인라인 검증이 잘못된 값일 때 저장 차단

정리하면, OpenClaw의 예약 작업 화면은 자율 에이전트의 역설 — "알아서 일하게 하되 통제권은 쥔다" — 을 화면 한 장으로 푼 사례다. 작업은 사람이 보지 않아도 게이트웨이 안에서 계속 돌지만, 운영자는 언제든 브라우저를 열어 무엇이 켜져 있고 다음엔 뭐가 돌며 어제 무엇이 깨졌는지를 묻지 않고 본다. 화려한 모델 기능보다, 이런 "맡겨 두고도 들여다볼 수 있는 창"이 사실 자율 에이전트를 안심하고 오래 굴리는 진짜 조건이다 — 점검 비용이 너무 비싸면 사람은 결국 자동화를 끄게 되기 때문이다. (덧붙이면, 에이전트가 cron을 스스로 도구로 써서 자기 일정을 거는 측면은 또 다른 이야기로, 여기서는 사람이 화면으로 관리하는 경험에만 집중했다.)

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.