OpenClaw Lobster Workflows: 승인 게이트(Approval Gates)를 통한 반복 가능한 에이전트 파이프라인 실행

에이전트를 신뢰할 수 없게 만드는 가장 쉬운 방법은 매일 동일한 운영 시퀀스를 즉흥적으로 수행하게 두는 것입니다.

수신함을 확인합니다. 메시지를 분류합니다. 답장 초안을 작성합니다. 미리보기를 보여줍니다. 승인된 항목만 전송합니다. 장부를 업데이트합니다. 이것은 하나의 창의적인 작업이 아닙니다. 판단이 중요한 몇몇 지점과 허가가 매우 중요한 한 지점이 포함된 반복 가능한 워크플로(Workflow)입니다.

OpenClaw의 lobster 도구는 바로 이러한 형태의 작업을 위해 존재합니다. 공식 문서에서는 Lobster를 명시적인 승인 체크포인트(Approval checkpoints)와 함께 다단계 도구 시퀀스를 하나의 결정론적(Deterministic) 연산으로 실행하기 위한 워크플로 셸(Workflow shell)로 설명합니다. LLM에게 모든 호출을 수동으로 오케스트레이션(Orchestration)하도록 요청하는 대신, 시퀀스를 구조화된 JSON 엔벨로프(Envelope)를 반환하는 타입 지정 파이프라인(Typed pipeline)으로 이동시킵니다.

이것은 완전 자율형 에이전트(Fully autonomous agent)보다 덜 화려하게 들릴 수 있지만, 운영자들에게는 대개 이것이 실제로 필요한 것입니다. 비즈니스 워크플로는 오늘 밤의 프롬프트가 네 번째 단계를 기억했는지 여부에 의존해서는 안 됩니다. 파이프라인, 제한된 런타임(Runtime), 구조화된 출력, 그리고 부작용(Side effects)이 발생하기 전의 명확한 일시 정지가 있어야 합니다.

Lobster가 변화시키는 것

워크플로 레이어(Workflow layer)가 없다면, 긴 연산은 하나의 대화가 됩니다. 에이전트는 도구 하나를 호출하고, 결과를 읽고, 다른 도구를 호출하고, 무슨 일이 일어났는지 설명하고, 사용자를 기다린 다음, 또 다른 도구를 호출합니다. 이는 탐색(Exploration)에는 적합합니다. 하지만 반복적인 연산에는 부적합한데, 매 실행마다 오케스트레이션에 토큰을 소비하며 매 단계마다 에이전트가 경로를 이탈할(Drift) 기회를 주기 때문입니다.

Lobster는 오케스트레이션을 런타임(Runtime)으로 이동시킵니다. 문서는 핵심 이점을 직접적으로 요약합니다: 하나의 Lobster 호출이 여러 단계를 나타낼 수 있고, 부작용(Side effects)은 승인될 때까지 중단될 수 있으며, 중단된 워크플로는 resumeToken을 반환할 수 있어 이미 발생한 모든 과정을 다시 실행하지 않고도 나중에 실행을 계속할 수 있습니다.

중요한 점은 단순히 "한 번의 호출에 많은 명령을 담는 것"이 아닙니다. 쉘 스크립트(Shell scripts)로도 이미 그것은 가능합니다. 진정으로 유용한 부분은 승인(approvals)과 재개(resume)가 일급 객체(first-class)로 취급된다는 점입니다. 일반적인 스크립트는 사람에게 질문을 던질 수 있지만, 지속 가능한 일시 중지(durable pause) 및 재개(resume) 동작은 런타임(runtime)의 관심사입니다. 만약 모든 스크립트 내부에서 이를 별도로 구현한다면, 승인 경계(approval boundary)는 빠르게 일관성을 잃게 될 것입니다.

도구를 의도적으로 활성화하기

Lobster는 선택적인 플러그인 도구이며, 기본 권한 표면(authority surface)이 아닙니다. 문서는 tools.alsoAllow를 사용한 추가적인 패턴을 보여줍니다:

{
  "tools": {
    "alsoAllow": ["lobster"]
...

또한 에이전트(agent)별로 허용할 수도 있습니다:

{
  "agents": {
    "list": [
...

이러한 구분은 매우 중요합니다. alsoAllow는 기존의 핵심 도구 세트(core tool set)를 유지하면서 선택적인 플러그인 도구를 활성화합니다. 문서는 제한적인 허용 목록(allowlist) 모드를 의도한 것이 아니라면 tools.allow를 사용하지 말라고 경고합니다. 즉, 워크플로 배포(rollout)를 실수로 더 광범위한 도구 정책 변경으로 이어지게 만들지 마십시오.

저는 이를 프로덕션 권한(production permission)으로 취급할 것입니다. 만약 에이전트가 게시, 이메일 발송, 레코드 업데이트 또는 명령 실행을 최종적으로 수행하는 워크플로를 실행할 수 있다면, 해당 워크플로는 다른 부수 효과(side-effecting)를 일으키는 자동화와 동일한 수준의 존중을 받아야 합니다.

파이프라인 패턴

깔끔한 Lobster 패턴은 JSON을 사용하는 작은 명령들이 파이프라인(pipeline)으로 연결되어 있으며, 워크플로가 변경 사항을 적용하기 전에 승인 게이트(approval gate)를 두는 방식입니다. 문서는 inbox list --json, inbox categorize --json, inbox apply --json과 같은 명령어를 통해 이러한 형태를 보여줍니다.

{
  "action": "run",
  "pipeline": "exec --json --shell 'inbox list --json' | exec --stdin json --shell 'inbox categorize --json' | approve --preview-from-stdin --limit 5 --prompt 'Apply changes?'",
...

이것이 핵심적인 아이디어입니다: 사실(facts)을 결정론적(deterministically)으로 수집하고, 가능한 경우 이를 결정론적으로 변환하며, 필요한 경우에만 모델의 판단을 요청하고, 부수 효과(side effect)를 미리 보기(preview)한 뒤, 실행 전에 일시 중지하는 것입니다.

승인 미리보기(approval preview)는 단순한 장식이 아닙니다. 별도의 커스텀 글루(glue) 코드를 작성하지 않고도 승인 요청에 JSON 미리보기를 첨부하고 싶다면 approve --preview-from-stdin --limit N을 사용하세요. 또한 문서에 따르면, 승인 재개(approval resumes)를 위해 컴팩트한 재개 토큰(resume tokens)이 사용되며, 워크플로우 재개 상태는 Lobster 상태 디렉토리 아래에 저장됩니다. 운영자(operator) 입장에서 이는 다음 작업이 "무슨 일이 일어났는지 재구성해 주세요"가 아니라, "미리보기를 검토하고, 승인 또는 거부한 뒤, 토큰으로부터 재개하세요"라는 의미입니다.

단순히 더 긴 프롬프트가 아닌, 더 안전한 프로덕션 에이전트를 원하시나요?

ClawKit은 승인, 도구(tools), 메모리(memory), 모델 라우팅(model routing) 및 복구(recovery)를 위한 실질적인 운영 규칙을 제공합니다. ClawKit을 $9.99에 이용하기.

순서가 중요할 때는 워크플로우 파일을 사용하세요

인라인 파이프라인(Inline pipelines)은 빠른 실행에 유용합니다. 하지만 순서가 운영 체제의 일부가 된다면, 이를 워크플로우 파일에 담으세요. 문서에 따르면 Lobster는 name, args, steps, env, condition, approval과 같은 필드를 가진 YAML 또는 JSON 워크플로우 파일을 실행할 수 있습니다. 또한 stdin: $step.stdout 및 stdin: $step.json을 통해 이전 단계의 출력을 전달할 수 있으며, condition 또는 when을 사용하여 승인 여부에 따라 단계를 제어(gate)할 수 있음을 보여줍니다.

name: support-triage
args:
  limit: 
...

이러한 파일은 긴 프롬프트보다 검토하기가 더 쉽습니다. 또한 차이점 비교(diff), 로그 기록, 테스트 및 팀원에게 설명하기에도 더 용이합니다. 워크플로우가 변경되면 승인 게이트(approval gate)가 이동했는지, 부수 효과(side-effecting)를 일으키는 단계가 변경되었는지, 또는 실행 단계로 들어오는 입력이 이제 다른 소스로부터 오는지 확인할 수 있습니다.

pipeline을 해당 파일의 경로로 설정하여 파일을 실행하세요. 파일이 인자를 받는 경우, argsJson을 통해 전달하면 됩니다:

{
  "action": "run",
  "pipeline": "/path/to/support-triage.lobster",
...

출력 엔벨로프(output envelope) 이해하기

Lobster는 JSON 엔벨로프(envelope)를 반환합니다. 문서에서는 세 가지 상태(status)를 정의합니다:

• ok: 워크플로(workflow)가 성공적으로 완료되었습니다.
• needs_approval: 워크플로가 일시 중지되었으며, 계속 진행하려면 requiresApproval.resumeToken이 필요합니다.
• cancelled: 워크플로가 명시적으로 거부되었거나 취소되었습니다.

OpenClaw 도구는 해당 엔벨로프(envelope)를 content에는 보기 좋은 JSON(pretty JSON) 형태로, details에는 가공되지 않은 원시 객체(raw object) 형태로 노출합니다. 이는 에이전트(agent)에게 유용한 경계가 됩니다. 자연어 답변은 실행 내용을 요약할 수 있지만, 실제 워크플로 상태는 구조화된 데이터(structured data)에 존재하기 때문입니다.

워크플로가 일시 중지되었을 때, 승인 결정과 함께 재개(resume)하려면 다음과 같이 합니다:

{
  "action": "resume",
  "token": "<resumeToken>",
...

또는 부작용(side effect)을 깔끔하게 거부하려면 다음과 같이 합니다:

{
  "action": "resume",
  "token": "<resumeToken>",
...

저는 동일한 재개(resume) 경로를 통해 거부하는 방식을 선호하는데, 그 이유는 워크플로가 중간 상태(half-state)에 갇히는 대신 최종적으로 완료된 상태로 남기 때문입니다. "아니오(No)" 역시 실질적인 결정이며, 자동화 시스템은 이를 하나의 결정으로 기록해야 합니다.

모델의 판단을 어디에 배치할 것인가

Lobster는 구조화된 모델 단계(structured model steps)와 잘 어울리지만, 러너(runner)의 세부 사항에는 주의해야 합니다. 현재 문서 사이트에 따르면, 번들로 포함된 Lobster 플러그인은 Gateway 내부의 프로세스 내(in-process)에서 워크플로를 실행하며, 임베디드 모드(embedded mode)에서는 중첩된 openclaw.invoke 호출이 Gateway URL이나 인증 컨텍스트(auth context)를 자동으로 상속받지 않는다고 경고합니다. 또한 동일한 문서에서는 지원되는 브리지(bridge)가 존재할 때까지 Lobster 외부에서 직접 llm-task를 호출하거나, 중첩된 OpenClaw CLI 호출에 의존하지 않는 Lobster 단계를 사용할 것을 권장합니다.

이것이 바로 워크플로가 제거해야 할 전형적인 실수(footgun)의 유형입니다. 모델 단계가 필요하다면 이를 명시적으로 만들고, 실제로 사용 중인 러너의 형태(runner shape)를 테스트하십시오. 독립형 CLI 예제가 임베디드된 Gateway 워크플로 내부에서도 동일하게 작동할 것이라고 가정해서는 안 됩니다.

더 안전한 운영 패턴은 다음과 같습니다:

1. 수집 및 정규화(normalization)에는 결정론적(deterministic) 명령을 사용합니다.
2. 좁은 범위의 판단 단계(judgment step)에만 구조화된 모델 출력을 사용합니다.
3. 출력을 다음 단계로 전달하기 전에 출력 형태(output shape)를 검증합니다.
4. 제안된 부작용(side effect)을 미리 봅니다(preview).
5. 전송, 게시, 삭제, 결제 또는 실행하기 전에 승인을 요구합니다.

워크플로 제한하기 (Bound the workflow)

도구 파라미터에는 cwd, timeoutMs, maxStdoutBytes, argsJson이 포함됩니다. 이것들은 사소한 세부 사항이 아닙니다. 유용한 워크플로가 제한 없이 실행되는 배경상의 실수(unbounded background mistake)로 변질되지 않도록 유지하는 방법입니다.

문서에 따르면 cwd는 반드시 Gateway 작업 디렉토리 내에 머물러야 합니다. 또한 timeoutMs와 maxStdoutBytes에 대한 기본 제한 사항도 명시되어 있으며, 설치된 플러그인 소스(plugin source)는 상대 작업 디렉토리를 해석하고, 긴 실행 시간을 타임아웃 처리하며, 과도한 출력을 거부함으로써 이러한 개념들을 강제합니다. 할당된 예산(budget) 내에서 완료할 수 없는 워크플로는 더 길게 실행되도록 묵인할 것이 아니라 분할해야 합니다.

안전 관련 참고 사항도 명확합니다. Lobster는 사용자를 대신해 OAuth 비밀 정보(secrets)를 관리하지 않으며, 이를 관리하는 도구를 호출할 뿐입니다. Lobster는 샌드박스(sandbox)를 인식합니다. 타임아웃과 출력 제한을 강제합니다. 현재 문서에 따르면, 번들로 포함된 플러그인 자체는 네트워크 호출을 수행하지 않습니다. 이를 마법이 아닌 경계(boundaries)로 취급하십시오. 워크플로 단계 중 하나가 이메일을 보내거나, 데이터베이스를 업데이트하거나, 채널에 게시하는 도구를 호출한다면, 해당 단계는 여전히 부작용(side effect)입니다.

Lobster가 적절하지 않은 경우

작업을 여전히 탐색 중인 단계에서는 Lobster를 사용하지 마십시오. 탐색을 위해서는 일반적인 에이전트 대화(agent conversation), 하위 에이전트(sub-agent), 브라우저 세션(browser session) 또는 코드 실행 경로를 사용하십시오. Lobster는 시퀀스(sequence)를 파악한 후 이를 반복 가능하게 실행하고 싶을 때 가장 효과적입니다.

또한, 단일 도구 호출 내에 위험한 동작을 숨기는 용도로 Lobster를 사용하는 것도 피해야 합니다. 미리 보기(preview) 없이 레코드를 삭제하는 압축된 워크플로는 가시적인 일련의 도구 호출보다 더 나쁩니다. 핵심은 작업을 덜 보이게 만드는 것이 아니라, 검토 가능하게(reviewable) 만드는 것입니다.

가장 좋은 Lobster 워크플로는 좋은 의미에서 지루합니다. 이들은 매번 동일한 증거를 수집하고, 동일한 미리 보기 형태를 생성하며, 동일한 승인 게이트(approval gate)에서 멈추고, 동일한 토큰 동작으로 재개됩니다. 그것이 바로 이들을 일상적인 사용에 충분할 만큼 신뢰할 수 있게 만드는 요소입니다.

운영자 체크리스트

Lobster 워크플로를 프로덕션(production)에 투입하기 전에, 저는 다음 다섯 가지 사항을 확인하겠습니다:

1. JSON 입출력 (JSON inputs and outputs): 각 명령은 다음 단계에서 소비할 수 있는 기계 판독 가능(machine-readable)한 출력을 생성해야 합니다.
2. 승인 위치 (Approval location): 승인 게이트(approval gate)는 부수 효과(side-effecting)를 일으키는 첫 번째 동작 바로 앞에 위치해야 합니다.
3. 재개 처리 (Resume handling): 런북(runbook)에는 resumeToken이 어디에 나타나는지, 그리고 누가 이를 재개할 수 있는지 명시되어야 합니다.
4. 런타임 경계 (Runtime bounds): timeoutMs, maxStdoutBytes, cwd는 워크플로의 영향 범위(blast radius)와 일치해야 합니다.
5. 버전 확인 (Version check): 독립형(standalone) 대 임베디드(embedded) 가정에 의존하기 전에, 설치된 OpenClaw 문서나 소스 코드를 통해 러너(runner) 동작을 확인하십시오.

이것이 에이전트가 길게 이어지는 채팅 기록이 아닌, 유용한 운영자(operator)가 되는 방법입니다. 반복 가능한 작업을 워크플로에 담으십시오. 판단(judgment)의 범위를 좁게 유지하십시오. 부수 효과(side effect)를 승인 뒤에 배치하십시오. 그런 다음 에이전트가 매일 밤 운영 절차를 새로 발명할 필요 없이 파이프라인을 실행하도록 하십시오.

전체 가이드를 원하시나요? ClawKit 받기 — $9.99

원문 게시 위치: https://www.openclawplaybook.ai/blog/openclaw-lobster-workflows-approval-gates/

OpenClaw Playbook 받기 → https://www.openclawplaybook.ai?utm_source=devto&utm_medium=article&utm_campaign=parasite-seo