OpenClaw 프롬프트가 스킬, 스크립트 또는 n8n 작업이 되어야 하는 순간

에이전트(Agent) 구축 과정에서 저는 동일한 실패 패턴을 계속해서 목격하고 있습니다.

누군가가 OpenClaw를 이용해 한 번 똑똑한 작업을 수행하게 만듭니다.

정부 페이지를 확인하고, PDF를 분류하며, 보고서를 다시 작성하고, Discord에 요약본을 게시합니다.

잘 작동합니다.

모두가 흥분합니다.

그러고 나서 그들은 향후 3개월 동안 이 모든 과정을 하나의 거대한 프롬프트(Prompt) 안에 그대로 방치합니다.

그때부터 고통이 시작됩니다:

프롬프트가 계속해서 커집니다.
동작의 예측 가능성이 떨어집니다.
비용이 가변적으로 유지됩니다.
디버깅(Debugging)이 비참해집니다.
어느 부분이 실제로 안정적인지 아무도 모릅니다.

많은 에이전트 데모가 바로 그 지점에서 무너집니다.

어려운 점은 OpenClaw가 무언가를 한 번 수행하게 만드는 것이 아닙니다.

진짜 어려운 점은 영리한 프롬프트가 언제 프롬프트로서의 역할을 멈추고 스킬(Skill), 스크립트(Script), 또는 n8n 작업(Job)이 되어야 하는지를 알아차리는 것입니다.

이 문제를 조사하던 중, r/openclaw에서 성숙도 곡선(Maturity curve)을 매우 잘 포착한 스레드를 발견했습니다. 한 사용자는 워크플로(Workflow)를 다음과 같이 설명했습니다: 먼저 그것이 가능한지 증명하고, 시행착오를 거친 다음, 신뢰성이 필요하고 반복적으로 수행할 것으로 예상된다면 그 교훈을 스킬로 전환하십시오.

그것이 게임의 전부입니다.

나의 경험칙 (My rule of thumb)

다음 사다리를 사용하세요:

단계	사용 시점
채팅 내 프롬프트 / 시스템 지침 (System instructions) / TOOLS.md	워크플로를 여전히 탐색 중일 때
...

요약하자면:

탐색 중일 때는 프롬프트(Prompt)를 사용하세요.
반복할 때는 스킬(Skill)을 사용하세요.
동작이 확정되었을 때는 코드(Code)를 사용하세요.

당연한 소리처럼 들리겠지만, 사람들은 2단계를 건너뛰고 3단계를 너무 오랫동안 미룹니다.

프롬프트는 스케치이지, 아키텍처(Architecture)가 아니다

좋은 프롬프트는 스케치입니다.

나쁜 프로덕션 아키텍처 또한 아무도 임시적인 것이라고 인정하지 않은 스케치일 뿐입니다.

제가 본 더 나은 예시 중 하나는 권위 있는 웹사이트에서 화재 금지령과 공고를 확인하는 워크플로였습니다. 그것은 OpenClaw 채팅에서 프로토타입(Prototype)을 만들기에 완벽하게 합리적인 일입니다.

먼저 몇 가지 질문에 답해야 합니다:

어떤 사이트가 중요한가?
어떤 페이지에 공고가 포함되어 있는가?
무엇이 관련 업데이트로 간주되는가?
어떤 출력 형식(Output format)을 원하는가?

그것은 탐색 작업(Discovery work)입니다. 모델을 사용하세요.

하지만 사이트, 일정, 추출 규칙을 모두 파악했다면, 매 실행마다 전체 추론 체인(reasoning chain)을 끌고 가는 것은 대개 잘못된 선택입니다.

만약 매일 아침 동일한 사이트를 확인해야 한다면, 그것은 더 이상 대화가 아닙니다.

그것은 업무(job)입니다.

그리고 업무에는 지루한 기계 장치가 필요합니다.

첫 번째 신호: 동일한 지침을 두 번 붙여넣었을 때

제가 동일한 지침을 재사용하고 있다는 사실을 깨닫는 즉시, 저는 그것을 OpenClaw 스킬(skill)로 전환하는 것을 고려합니다.

아직 Python 단계는 아닙니다.
아직 n8n 단계도 아닙니다.
스킬 단계입니다.

왜일까요?

스킬은 대부분의 사람들이 과소평가하는 중간 계층(middle layer)이기 때문입니다.

스킬은 세 가지 유용한 역할을 수행합니다:

반복되는 동작을 패키지화(package)합니다.
다시 전송해야 하는 컨텍스트(context)의 양을 줄입니다.
특정 작업에 대해 재사용 가능한 인터페이스(interface)를 생성합니다.

이는 들리는 것보다 훨씬 더 중요합니다.

만약 반복되는 지침을 채팅창이나 TOOLS.md에 그대로 남겨둔다면, 당신은 계속해서 컨텍스트 임대료(context rent)를 지불하게 됩니다. 매 실행마다 동일한 설명이 모델로 다시 끌려 들어가기 때문입니다.

스킬은 이를 압축합니다.

매번 다음과 같이 입력하는 대신:

게시판 페이지를 읽으세요. 탐색 텍스트는 무시하세요. 활성화된 화재 금지 명령만 추출하세요.
날짜를 ISO 형식으로 정규화(normalize)하세요. 활성화된 금지 명령이 없으면 NONE이라고 말하세요.
지역(region), 상태(status), 효력 발생일(effective_date), 출처 URL(source_url)을 포함한 JSON을 반환하세요.

…단 한 번 패키지화하여 스킬을 호출하면 됩니다.

이것이 워크플로(workflow)를 결정론적(deterministic)으로 만드는 것은 아니지만, 프롬프트가 쓰레기 매립지로 변하는 것은 막아줍니다.

스킬이 정답인 경우

예전에는 진짜 선택지가 프롬프트(prompt)냐 코드(code)냐의 문제라고 생각했습니다.

이제는 그렇게 생각하지 않습니다.

OpenClaw 스킬은 다음과 같은 상황에서 유용합니다:

작업이 반복될 때
출력 형태(output shape)가 대부분 알려져 있을 때
입력값이 여전히 지저분할 때
예외 케이스(edge cases)가 여전히 발견되는 중일 때
워크플로를 너무 일찍 고정하지 않으면서도 낮은 컨텍스트 오버헤드(context overhead)를 원할 때

이것이 많은 반구조화된(semi-structured) 자동화 작업의 최적 지점(sweet spot)입니다.

예시:

보기 흉한 PDF에서 필드 추출하기
유입되는 고객 지원 메시지 분류하기
일관성 없는 사고 보고서 요약하기
긴 텍스트를 구조화된 JSON으로 변환하기

당신은 여전히 모델의 유연성(flexibility)을 원하기 때문입니다.

단순히 작업을 매번 다시 설명하고 싶지 않기 때문입니다.

코드가 승리하는 순간

어떤 단계가 매번 동일한 방식으로 실행되어야 한다면, 저는 더 이상 타협하지 않습니다.

코드가 승리합니다.

LLM (Large Language Models)이 부족해서가 아닙니다.

규칙이 이미 알려져 있는 상황에서 반복적인 추론 (reasoning)을 수행하는 것은 낭비이기 때문입니다.

만약 당신의 로직이 기본적으로 다음과 같다면:

페이지 가져오기 (fetch page)
HTML 파싱 (parse HTML)
타임스탬프 비교 (compare timestamp)
항목 중복 제거 (dedupe items)
임계값 기반 라우팅 (route based on threshold)
Slack/Discord/이메일 알림 전송 (send Slack/Discord/email alert)

…그것은 프롬프팅 (prompting)이 아니라 소프트웨어입니다.

아주 간단한 예시를 들어보겠습니다.

프롬프트 형태의 솔루션

https://example.gov/fire-bans 를 확인하세요.
최신 활성 공고를 찾으세요.
제목, 날짜, 지역 및 제한 수준을 추출하세요.
...

스크립트 형태의 솔루션

import requests
from bs4 import BeautifulSoup
from datetime import datetime
...

페이지 구조가 안정적이라면, 신뢰성 측면에서 이 방식이 프롬프트를 매번 이길 것입니다.

매일 실행된다면, 스케줄을 예약하세요

이것은 사람들이 일을 필요 이상으로 어렵게 만드는 또 다른 지점입니다.

매시간 실행되어야 하는 워크플로 (workflow)를 만들어 놓고, 에이전트 (agent)를 영원히 살아있게 유지하려고 시도합니다.

그러면 이제 다음과 같은 문제들을 처리해야 합니다:

하트비트 (heartbeats)
세션 상태 (session state)
폴링 루프 (polling loops)
복구 동작 (recovery behavior)
기이한 타임아웃 버그 (weird timeout bugs)

단순히 스케줄링만 있으면 되었을 작업에 너무 많은 복잡성이 추가된 것입니다.

작업이 결정론적 (deterministic)이라면, 지속적인 추론보다 스케줄링이 더 낫습니다.

n8n은 이미 이 문제를 해결합니다

n8n을 사용하고 있다면, Schedule Trigger를 사용하세요.

워크플로 구성 예시:

Schedule Trigger -> HTTP Request -> HTML Extract -> Code -> IF -> Discord

또는 모호한 단계 하나를 위해 여전히 모델의 도움이 필요하다면:

Schedule Trigger -> HTTP Request -> LLM extraction -> Code -> Database -> Notification

실용적인 cron 예시:

*/30 * * * *

이것은 30분마다 실행됩니다.

n8n에서는 내장된 트리거 UI나 사용자 정의 cron 표현식을 사용하여 동일한 작업을 수행할 수 있습니다.

이것이 아무 이유 없이 항상 켜져 있는 에이전트 런타임 (agent runtime)을 만들어내는 것보다 보통 더 낫습니다.

실제로 작동하는 실용적인 분할 방식

이것이 제가 OpenClaw + n8n 빌드를 위해 권장하는 분할 방식입니다.

모델은 다음 용도로 사용하세요:

지저분한 텍스트 분류 (classifying messy text)
일관되지 않은 문서에서 데이터 추출 (extracting data from inconsistent docs)
비정형 콘텐츠 요약 (summarizing unstructured content)
아직 완전히 매핑되지 않은 예외 케이스 처리 (handling edge cases you haven’t fully mapped yet)

코드 또는 네이티브 노드 (native nodes)는 다음 용도로 사용하세요:

날짜 형식 지정 (date formatting)
유효성 검사 (validation)
중복 제거 (deduplication)
임계값 확인 (threshold checks)
라우팅 로직 (routing logic)
예약된 폴링 (scheduled polling)
재시도 (retries)
이미 파악하고 있는 정리 작업 (cleanup you already understand)

이를 잘 수행한다면, 모델은 모호함 (ambiguity)을 처리하고 워크플로 (workflow)는 그 외의 모든 것을 처리하게 됩니다.

이는 이미 알고 있는 로직을 바탕으로 GPT-5.4나 Claude Opus 4.6이 계속해서 즉흥적으로 대처하도록 요구하는 것보다 훨씬 더 건강한 아키텍처 (architecture)입니다.

구조화된 출력 (Structured output)은 좋은 가교 역할을 합니다

완전히 코드로 전환할 준비가 되지 않았다면, 최소한 구조를 강제하세요.

예를 들어, 스키마 제약이 있는 출력 (schema-constrained output)은 "LLM이 유용한 무언가를 수행함"과 "자동화가 이를 충분히 신뢰하여 계속 진행할 수 있음" 사이를 잇는 좋은 가교 역할을 합니다.

예시 패턴:

from pydantic import BaseModel
from openai import OpenAI

...

이것이 결정론적 로직 (deterministic logic)을 대체할 수는 없습니다.

하지만 다운스트림 (downstream)의 추측을 줄여주며, 나중에 안정적인 구성 요소들을 코드로 옮기는 것을 더 쉽게 만들어 줍니다.

비용도 중요하지만, 아키텍처가 더 중요합니다

반복되는 작업을 거대한 프롬프트 (prompts)에서 분리해야 하는 명백한 이유는 비용입니다.

네, 그것은 중요합니다.

토큰 (token)당 비용을 지불하고 있다면, 프롬프트 비중이 높은 반복적인 워크플로는 끊임없이 추정하고 모니터링해야 하는 대상이 됩니다.

프로토타입 단계에서도 이는 충분히 번거로운 일입니다.

워크플로가 n8n, Make, Zapier, OpenClaw 또는 커스텀 에이전트 스택 (custom agent stack)에서 하루 종일 실행될 때는 상황이 더 악화됩니다.

그 시점에는 캐싱 (caching)과 배치 (batching)가 도움이 되더라도 여전히 두 가지 문제에 직면하게 됩니다:

반복되는 컨텍스트 (context)에 대해 비용을 지불하고 있음
더 이상 모호하지 않은 단계들을 추측하기 위해 모델을 사용하고 있음

이것이 바로 Standard Compute와 같은 OpenAI 호환 정액제 서비스가 자동화 팀에게 흥미로운 이유입니다.

동일한 SDK와 HTTP 클라이언트 (HTTP clients)를 유지하면서도, 모든 예약된 실행을 마치 작은 예산 이벤트처럼 취급하는 것을 멈출 수 있습니다.

그것이 모든 것에 "LLM을 사용하라"는 뜻은 아닙니다.

그것은 모델 호출이 필요한 경우, 토큰 소모 (token burn)를 계속해서 감시하는 것보다 예측 가능한 가격 책정 (predictable pricing)이 상시 가동되는 자동화 (automations) 및 에이전트 워크플로 (agent workflows)에 훨씬 더 적합하다는 의미입니다.

회계 관리 예시가 결정적인 증거입니다

좋은 경계 테스트는 회계 관리 (bookkeeping)입니다.

회계 관리는 대부분 규칙 기반 (rule-based)입니다.

영수증의 OCR (광학 문자 인식)이 실패한다면, 물론 모델을 사용하여 가맹점을 분류하거나 카테고리를 추론하도록 할 수 있습니다.

하지만 검증 규칙, 계정 매핑 (account mappings), 그리고 전기 로직 (posting logic)이 파악되고 나면, 그 로직을 프롬프트 (prompts) 안에 숨기는 것은 그저 값비싼 산문일 뿐입니다.

그것은 에이전트 아키텍처 (agent architecture)가 아닙니다.

그것은 챗봇의 탈을 쓴 비즈니스 로직 (business logic)입니다.

저의 결정 테스트

OpenClaw 워크플로를 살펴볼 때, 저는 네 가지 질문을 던집니다:

여전히 프로세스를 탐색하는 중인가?
동일한 지침을 반복하고 있는가?
이 단계가 매번 동일한 방식으로 실행되어야 하는가?
정해진 일정에 따라 실행되는가?

그다음에는:

1번에 '예'라면, 채팅 상태를 유지합니다.
2번에 '예'라면, 스킬 (skill)로 만듭니다.
3번에 '예'라면, 코드 (code) 쪽으로 옮깁니다.
4번에 '예'라면, cron 또는 n8n Schedule Trigger를 사용합니다.

이것이 프레임워크입니다.

엉망인 상태로 시작하세요.
반복되는 것을 패키지화하세요.
안정화되는 것을 코드로 만드세요.

예시 마이그레이션 경로

실제 사례는 다음과 같습니다.

단계 1: OpenClaw에서 탐색

목표: 규제 기관 페이지를 모니터링하고 새로운 집행 회보 (enforcement bulletins)를 요약함.

OpenClaw 채팅을 사용하여 다음 사항을 파악합니다:

페이지가 어디에 있는지
무엇이 회보로 간주되는지
어떤 필드가 중요한지
좋은 요약이란 어떤 모습인지

단계 2: 반복되는 추출을 스킬로 전환

스킬: extract_enforcement_bulletin
입력: 원본 페이지 콘텐츠 (raw page content)
출력: 구조화된 회보 JSON (structured bulletin JSON)

이제 프롬프트 확산 (prompt sprawl)을 줄였고 추출 과정을 재사용 가능하게 만들었습니다.

단계 3: 안정적인 오케스트레이션 (orchestration)을 n8n으로 이동

Schedule Trigger
-> HTTP Request
-> OpenClaw skill / LLM extraction
...

단계 4: 가능한 경우 안정적인 모델 단계를 코드로 교체

페이지 형식이 충분히 예측 가능하다면, LLM 추출을 결정론적 파싱 (deterministic parsing)으로 교체하십시오.

그것이 바로 졸업 단계입니다.

단 한 가지만 기억해야 한다면

에이전트 엔지니어링 (agent engineering)의 진정한 기술은 OpenClaw가 단 한 번 인상적인 결과물을 내놓게 만드는 것이 아닙니다.

인상적인 부분이 끝나는 시점을 알아차리는 것입니다.

그때가 바로 프롬프트의 영리함 (prompt cleverness)을 의도적으로 지루한 시스템 (boring systems)으로 교체해야 할 순간입니다.

대부분의 OpenClaw + n8n 워크플로우 (workflows)를 위한 경로는 다음과 같습니다:

채팅을 사용하여 프로세스를 발견합니다.
반복되는 작업을 OpenClaw 스킬 (skill)로 전환합니다.
안정적이고 빈도가 높은 단계를 Python 또는 n8n 코드 노드 (Code node)로 이동합니다.
에이전트를 인위적으로 깨워두는 대신 작업을 스케줄링 (schedule)합니다.

일단 작업이 매일 동일한 방식으로 실행된다면, 매번 다시 설명하기 위해 비용을 지불하는 것은 대개 잘못된 아키텍처 (architecture)입니다.

그리고 해당 워크플로우가 지속적으로 실행되고 있다면, 한 달 내내 토큰당 비용 (per-token costs)을 일일이 관리하는 것보다 예측 가능한 정액제 컴퓨팅 (flat-rate compute)이 훨씬 더 적합합니다.

이것이 더 많은 팀이 최적화해야 할 부분입니다.