/8분

주제만 주면 기획/설계/개발까지 진행하는 OpenClaw 설정하기 (1): 내부 동작과 운영 원리

#openclaw#ops#automation#notion#telegram

시리즈: OpenClaw 며칠짜리 작업

먼저 읽으면 좋은 글(선택):

“주제만 주면 알아서 끝까지 해줘.”

OpenClaw 같은 에이전트를 쓰면 누구나 한 번쯤 이렇게 기대한다. 문제는 **현실의 작업이 ‘하루짜리 실행’이 아니라 ‘며칠짜리 진행’**이라는 점이다.

  • 중간에 방향이 갈린다
  • 사용자 확인이 필요하다
  • 막히면 기다려야 한다
  • 다음날 다시 깨어났을 때 “어디까지 했지?”를 복원해야 한다

이 글은 그걸 가능하게 만드는 **운영 원리(내부 동작)**를 정리한다.

이 글이 답하는 질문

  • OpenClaw는 “어디까지 했고 이제 뭘 해야 하는지”를 어떻게 기억/복원하는가?
  • 사용자는 언제 개입해야 하고, OpenClaw는 언제 스스로 진행해도 되는가?
  • Heartbeat / Cron / Notion / Telegram은 각각 어떤 역할을 맡아야 며칠짜리 작업이 굴러가는가?

0) 큰 그림: ‘대화’가 아니라 ‘운영 구조’를 세팅한다

“주제 던지기 → 기획/설계/개발 완료”는 마법 주문이 아니다.

실제로는 다음 4개가 고정되어야 한다.

  1. 기록(Record): 어디까지 했나 / 무엇이 결과물인가
  2. 재개(Resume): 다음에 뭘 해야 하나
  3. 승인(Approval/Brake): 사용자에게 물어봐야 하는 지점(멈춤)
  4. 정시 보고(Report): 이슈가 없을 때 공유하는 리듬

이 네 가지가 없으면, 에이전트는 둘 중 하나로 망한다.

  • 너무 자주 물어봐서 사용자가 피곤해짐(진행 멈춤)
  • 반대로 확인 없이 밀어붙여서 방향이 틀어짐(수정 비용 폭증)

1) 예시 작업: ‘가계부 만들기’가 왜 좋은가

“가계부 만들기”는 며칠짜리 작업의 전형이다.

  • 초기에 원하는 게 모호하다(요구 수집)
  • 구조를 정해야 한다(기획/설계)
  • 구현/검증/수정이 반복된다(개발)

즉, 사용자와의 공유/확인 루프가 없으면 진행이 멈추거나 엉뚱한 방향으로 달린다.

2) 1단계: 상세정보 수집은 ‘질문 20개’가 아니라 ‘결정 트리’다

초기 단계에서 OpenClaw가 해야 하는 건 “정보를 많이 모으기”가 아니다.

다음 단계(기획/설계/개발)를 가능하게 만드는 핵심 결정을 잠그는 것이다.

가계부 예시로 보면, 질문은 이런 축을 따라가면 된다.

  • 입력 방식: 수동? 자동 수집?
  • 목표: 월별 집계? 카테고리? 현금흐름? 세금?
  • 제약: 모바일/웹? 오프라인? 개인 정보? 보안?

여기서 중요한 출력은 장문의 질문지가 아니라:

  • “제가 이해한 목표 요약(3줄)”
  • “모호한 점 리스트(최대 5개)”
  • “다음에 딱 3개만 물어볼 질문”

OpenClaw가 사용자에게 Telegram으로 물어보는 시점(승인/확인)

질문은 아무 때나 하지 않는다.

아래 같은 지점에서만 “확인 후 진행”으로 멈추면 운영이 훨씬 안정적이다.

  • 방향이 크게 갈리는 선택(예: 자동수집 vs 수동)
  • 되돌리기 힘든 작업(예: 데이터 마이그레이션, 외부 공개)
  • 리스크가 큰 작업(결제/삭제/exec/외부 시스템 접근)

질문 메시지는 이렇게 구성하면 된다. (복붙)

[확인 필요] 가계부 범위 결정
- 지금 막힌 이유: 요구사항이 갈림
- 선택지 A: 수동 입력 중심(V0 빠름)
- 선택지 B: 카드/은행 자동 수집(난이도↑/인증 리스크↑)
- 내 추천: A로 V0 만들고, B는 V1로
- 확인해주면 다음 24~48h에 할 일: 1) 데이터 모델 초안 2) 화면 플로우 3) 저장 포맷 결정

3) 2단계: 기획은 ‘문서’가 아니라 ‘다음 개발이 가능한 형태’로

기획 단계의 산출물은 “잘 쓴 문서”가 아니라 “개발이 이어질 수 있는 스펙”이다.

최소 구성:

  • 화면/흐름(유저가 무엇을 누르면 무엇이 바뀌나)
  • 데이터(어떤 항목을 저장하나)
  • 성공 기준(DoD: 끝났다고 말할 수 있는 증거)
  • 우선순위(V0/V1)
  • 리스크(승인 필요한 지점)

가계부 V0 DoD 예시:

  • “한 달 수입/지출 입력 → 카테고리별 합계 → CSV 내보내기”까지 동작
  • 테스트 데이터 1세트

4) 3단계: 설계/개발은 ‘연속 대화’가 아니라 ‘작업 단위’로 굴린다

며칠짜리 작업이 끊기지 않으려면, OpenClaw가 다시 깨어날 때(heartbeat) 이렇게 말할 수 있어야 한다.

  • “현재 상태는 뭐고(Status)"
  • “지금 당장 할 다음 행동은 뭐다(Next action)"

그래서 작업은 항상 24~48시간 단위로 쪼개서 남긴다.

예시:

  • 데이터 모델 확정
  • 입력 폼 구현
  • 집계 로직 구현
  • CSV 내보내기
  • 테스트/버그 수정

5) 왜 Notion이 필요한가: ‘어디까지 했나’ 복원 문제

대화는 휘발된다.

며칠짜리 작업에서 중요한 건 “그때 무슨 말을 했나”가 아니라:

  • 현재 상태
  • 결과물(증거 링크)
  • 다음 행동
  • 막힌 이유 + 누구 응답이 필요한지

다음날 OpenClaw가 깨어났을 때 이 정보가 없으면, **재개(resume)**가 아니라 **재시작(restart)**가 된다.

그래서 Notion 같은 운영판을 **단일 진실(Source of Truth)**로 두는 게 강력하다.

Notion에 반드시 남겨야 하는 최소 정보

  • Status: Researching / Deciding / Building / Testing / Waiting approval / Blocked / Done
  • Next action: 1줄(24~48h 단위)
  • Evidence: 결과물 링크/파일/로그
  • Blocked reason: 왜 멈췄는지(그리고 누구 답이 필요한지)

6) Telegram 공유는 두 종류다: (1) 질문(승인) (2) 정시 보고

공유를 “자주” 하려고 하면 망한다. 공유는 “의미 있는 타이밍”에 해야 한다.

  • 질문(승인): Waiting approval일 때만. 선택지/추천/결정 후 다음 행동이 포함.
  • 정시 보고: 이슈가 없으면 고정 시간에 중간 결과 + 다음 계획.

정시 보고는 2편에서 **Cron(격리 세션 + announce)**로 구현한다.

7) 다음 글(2편)에서 다룰 것

2편에서는 “실제로 따라 하면 돌아가는 세부 설정”을 다룬다.

  • Notion 운영판(Projects/Task Queue/Decision Log) 필드 설계
  • Waiting approval/Blocked를 ‘기다림’으로 강제하는 규칙
  • Heartbeat에서 “복원→재개”를 수행하는 순서
  • Cron(격리+announce)로 Telegram 정시 리포트 발송
  • CLI가 아니라 ‘복붙 프롬프트’로 Cron 등록을 OpenClaw에게 맡기는 방식