누군가 OpenClaw에 50시간을 허비하는 것을 지켜보았습니다. 해결책은 당혹스러울 정도로 간단했습니다.

r/openclaw에서 누군가가 OpenClaw 루프 하나로 프리랜서 탐색(scouting), 평가(evaluation), 그리고 아웃리치(outreach)를 자동화하려고 50시간을 썼다는 게시물을 본 순간, 저는 이것을 쓸 가치가 있다는 것을 알았습니다.

그 문장은 정확히 무슨 일이 일어났는지를 말해줍니다.

초보자의 혼란도 아닙니다. "AI는 쓸모없다"는 분노도 아닙니다.

그것은 훨씬 더 위험한 상태입니다: 전체 과정이 단 하나의 프롬프트(prompt)만 더 있으면 완성될 것이라고 믿을 만큼의 진전이 이루어진 상태 말입니다.

저는 다음과 같은 분야에서 이 패턴을 반복해서 보았습니다:

리드 자격 검증 자동화 (lead qualification automation)
리크루터 워크플로우 (recruiter workflows)
아웃바운드 영업 (outbound prospecting)
프리랜서 탐색 (freelancer scouting)
에이전트 기반 데이터 보강 파이프라인 (agent-based enrichment pipelines)

패턴은 항상 동일합니다:

사람 검색
평가
개인화된 아웃리치
메시지 전송
하나의 거대한 에이전트(agent)가 이 모든 것을 깔끔하게 처리할 수 있기를 희망

그러고 나면 워크플로우는 엉망진창(soup)이 되어버립니다.

해결책은 특별한 것이 아닙니다.

하나의 거대한 에이전트를 만드는 것을 멈추세요. 단계별 워크플로우(staged workflow)를 구축하세요.

판단(judgment)에는 OpenClaw를 사용하세요. 오케스트레이션(orchestration)에는 n8n이나 Make를 사용하세요. 결정론적 단계(deterministic steps)에는 스크립트와 API를 사용하세요. 그런 다음 LLM 호출 비용을 충분히 낮추어 실제로 제대로 테스트할 수 있는 여건을 만드세요.

핵심적인 실수: OpenClaw를 전체 운영 팀(ops team)처럼 취급하는 것

OpenClaw는 유용합니다. 하지만 사람들은 계속해서 잘못된 것을 요구하고 있습니다.

다음과 같은 어시스턴트 하네스(assistant harness)로서의 역할은 타당합니다:

상태 유지 세션 (stateful sessions)
메모리 (memory)
도구 사용 (tool use)
모델 라우팅 (model routing)
프로바이더 페일오버 (provider failover)

이것은 강력합니다.

하지만 이것이 하나의 거대한 비즈니스 프로세스를 통째로 넘겨주고 신뢰할 수 있는 엔드 투 엔드(end-to-end) 실행을 기대해도 된다는 뜻은 아닙니다.

만약 당신의 워크플로우가 다음과 같다면:

웹에서 프리랜서 검색
품질별 필터링
후보자 순위 지정
개인화된 DM 작성
DM 전송
결과 기록

...당신은 하나의 작업을 가진 것이 아닙니다.

당신은 서로 다른 실패 모드(failure modes)를 가진 여러 시스템이 하나의 작업인 척하고 있는 상황을 가진 것입니다.

이 차이는 매우 중요합니다.

OpenClaw 자체도 어느 정도 이 점을 알려주고 있습니다

CLI 형태를 보면 그 사고방식이 명확합니다:

openclaw status
openclaw status --all
openclaw status --deep
...

이것은 "마법을 믿으라"는 식의 UX가 아닙니다.

그것은 바로 검사(inspect), 디버그(debug), 반복(iterate) 하는 UX입니다.

그리고 이것이 바로 여러분이 에이전트 워크플로우(agent workflows)에 접근해야 하는 정확한 방식입니다.

왜 하나의 거대한 에이전트(one-big-agent) 설계는 실패하는가

정찰(scouting), 평가(evaluation), 그리고 연락(outreach)은 하나의 문제가 아니기 때문입니다.

이것들은 마치 트렌치코트를 입고 있는 세 개의 서로 다른 버그와 같습니다.

1) 모델이 생각을 시작하기도 전에 검색이 실패한다

많은 잘못된 에이전트 워크플로우는 단순히 불필요한 단계가 추가된 잘못된 입력값일 뿐입니다.

만약 소싱(sourcing) 레이어가 취약하다면, 모델은 쓰레기를 분류하는 데 모든 지능을 소모하게 됩니다.

이것이 바로 제가 검색 중심의 에이전트 루프(agent loops)를 위해 Exa를 추천하는 사람들의 의견에 동의하는 이유입니다. 더 나은 검색 품질(retrieval quality)은 사람들이 생각하는 것보다 훨씬 더 중요합니다.

이러한 유형의 워크플로우에서 검색은 보조 도구가 아닙니다. 검색은 토대(foundation)입니다.

실질적인 소싱 단계는 다음과 같은 모습에 가깝습니다:

// 의사 파이프라인 (pseudo-pipeline)
const candidates = await exa.search({
  query: "freelance product designer SaaS portfolio",
...

이것은 하나의 거대한 프롬프트(giant prompt)에게 후보자를 발견하는 것과 심사하는 것을 동시에 수행하라고 요구하는 것보다 이미 더 나은 방식입니다.

2) 평가는 느낌(vibes)이 아니라 반복이 필요하다

이 지점이 대부분의 에이전트 데모가 실제 운영(production) 환경에서 무너지는 구간입니다.

단 한 번 성공하는 것을 보는 것만으로는 점수 산정 프롬프트(scoring prompt)를 검증할 수 없습니다.

여러분은 다음과 같은 대상으로 실행해야 합니다:

20명의 후보자
그다음 50명
그다음 엣지 케이스 (edge cases)
그다음 명백한 탈락자
그다음 모호한 프로필

그런 다음 출력을 비교하십시오.

그다음 루브릭(rubric, 평가 기준)을 미세 조정하십시오.

그다음 다시 실행하십시오.

이것이 바로 여기서 n8n이 유용한 이유입니다. n8n의 평가 워크플로우 패턴은 엔지니어들이 LLM 로직을 테스트해야 하는 방식에 훨씬 더 가깝습니다.

간단한 점수 산정 루프 (scoring loop)

Google Sheets나 테이블에 25개의 행을 넣으십시오:

후보자 (Candidate)	포트폴리오 (Portfolio)	메모 (Notes)
A	https://example.com/a	강력한 UI, 약한 케이스 스터디
B	https://example.com/b	훌륭한 B2B 작업
C	https://example.com/c	대부분 학생 프로젝트

그런 다음 작고 명시적인 프롬프트로 각 행의 점수를 매기십시오.

{
  "task": "score_freelancer",
  "criteria": {
...

그리고 모델을 좁은 범위 내에서 호출하십시오.

const prompt = `
아웃바운드 아웃리치 (outbound outreach)를 위해 이 프리랜서를 평가하십시오.

...

이것이 실제 작업입니다.

화려한 DM 생성(DM generation)이 아닙니다. 스코어링 루프 (scoring loop)입니다.

3) 아웃리치 (Outreach)는 모든 짜증 나는 지점에서 결정론적 (deterministic)입니다

이 부분은 개발자들이 보통 이미 알고 있는 내용이지만, 자율 에이전트 (autonomous-agent)라는 환상이 즐겁기 때문에 무시하곤 합니다.

이메일 전송, Airtable에 쓰기, HubSpot 연락처 생성, Notion 업데이트, Slack에 게시, Postgres에 쓰기 — 이것들은 LLM 문제가 아닙니다.

이것들은 API 문제입니다.

그러므로 다음을 통해 해결하십시오:

n8n
Make
직접 작성한 스크립트 (direct scripts)
네이티브 API (native APIs)
Composio
CRM 커넥터 (CRM connectors)

모델은 **무엇 (what)**을 말할지 결정하게 하십시오.

이상한 부작용 (side effects)을 디버깅하는 것을 즐기지 않는 한, 메시지가 어떻게 (how) 전송되는지에 대한 메커니즘을 모델이 소유하게 두지 마십시오.

분리 예시:

if (candidate.decision !== "approve") {
  return
}
...

그러한 아키텍처 (architecture)는 덜 마법적입니다.

또한 새벽 2시에 디버깅하기가 훨씬 더 쉽습니다.

현실과 접촉했을 때 실제로 살아남는 워크플로우 (workflow)

만약 제가 오늘 프리랜서 탐색이나 리드 자격 검증 (lead qualification) 자동화를 구축한다면, 다음과 같이 구조를 잡을 것입니다:

Exa 또는 결정론적 스크래퍼/API (deterministic scraper/API)를 사용하여 후보자 소싱 (Source candidates)
코드로 레코드 정규화 (Normalize records)
좁은 범위의 LLM 프롬프트 (narrow LLM prompt)로 후보자 점수 산정 (Score candidates)
라벨링된 데이터셋 (labeled dataset)에 대해 평가 (Run evals) 실행
예외 케이스나 가치가 높은 아웃리치에 대해 승인 요구 (Require approval)
승인된 후보자에 대해서만 개인화 생성 (Generate personalization)
Gmail, LinkedIn 헬퍼, 또는 CRM 통합을 통해 메시지 전송 (Send messages)
나중에 프롬프트 반복 (prompt iteration)을 위해 결과 기록 (Log outcomes)

이것은 하나의 거대한 에이전트 (giant agent)보다 느리게 들릴 것입니다.

실제로는 더 빠릅니다.

모든 고장 난 부분에 이름이 있기 때문입니다.

하나의 거대한 에이전트 vs 단계별 워크플로우 (staged workflow)

접근 방식	실제로 일어나는 일
하나의 거대한 에이전트 워크플로우	하나의 프롬프트가 탐색, 평가, 개인화, 전송을 모두 시도합니다. 데모하기에는 빠르지만, 디버깅하기에는 비참하며, 모든 실패가 복합적으로 작용합니다.
...

워크플로우를 몇 번 이상 실행할 계획이라면, 단계별 버전이 승리합니다.

그것이 우아하기 때문이 아닙니다.

생존 가능하기 때문입니다.

아무도 인정하고 싶어 하지 않는 비용 문제

아키텍처 결정을 조용히 망가뜨리는 부분은 바로 이것입니다:

재시도(retries)에는 비용이 듭니다.

당신이 다음을 수행할 때마다:

배치(batch) 재점수화
추출(extraction) 재시도
폴백 프롬프트(fallback prompts) 실행
모델 비교
50개의 예시 평가
아웃리치(outreach) 재생성

...비용 계량기가 돌아갑니다.

그리고 이는 잘못된 행동을 유발합니다.

토큰당 과금 방식(per-token pricing) 때문에 반복 작업(iteration)이 비싸게 느껴지기 때문에, 팀들은 스스로 잘못된 것을 알면서도 다음과 같은 행동을 하기 시작합니다:

평가(evals) 회피
프롬프트 테스트 부족
단계를 나누는 대신 거대한 프롬프트 유지
재시도 생략
실험의 배치(batch) 처리 거부

이것이 토큰 불안(token anxiety)이 설계 제약 조건이 되는 방식입니다.

에이전트 워크플로우(agent workflows)의 경우, 이는 매우 가혹합니다.

왜냐하면 올바른 아키텍처는 보통 더 많은 호출, 더 작은 단계, 더 많은 테스트를 포함하기 때문입니다.

그것이 바로 자동화 중심의 스택에서 정액제 컴퓨팅(flat-rate compute)이 매우 매력적인 이유입니다.

만약 당신이 n8n, Make, Zapier, OpenClaw 또는 커스텀 워크플로우에서 하루 종일 에이전트를 실행하고 있다면, 예측 가능한 가격 책정은 긍정적인 방향으로 행동을 변화시킵니다. 모든 반복 작업을 재정적 결정처럼 취급하는 것을 멈추게 됩니다.

그것이 **표준 컴퓨팅(Standard Compute)**의 진정한 매력입니다.

이는 OpenAI와 호환되는 API를 제공하면서도, 토큰당 과금 대신 월정액으로 무제한 AI 컴퓨팅을 제공합니다. 따라서 비용이 끊임없이 당신을 괴롭히지 않는다면 구축했을 아키텍처 — 단계별 워크플로우, 반복적인 평가, 수많은 좁은 범위의 모델 호출 — 가 실용적으로 변합니다.

워크플로우가 반복적인 랭킹(ranking), 점수 매기기(scoring), 다시 쓰기(rewriting), 그리고 폴백 로직(fallback logic)을 수행할 때 이는 매우 중요합니다.

지루한 아키텍처가 대개는 더 진보된 것입니다

사람들은 정교한 설정이 최대의 자율성(autonomy)을 갖춘 것이라고 생각합니다.

대개 그렇지 않습니다.

대개 정교한 설정은 다음과 같습니다:

판단 및 도구 사용을 위한 OpenClaw
오케스트레이션(orchestration)을 위한 n8n
검색을 위한 Exa
전달을 위한 Gmail 또는 HubSpot 커넥터
반복적인 점수 매기기를 위한 더 작은 모델
필요할 때만 사용하는 더 큰 모델

이것은 덜 진보된 것이 아닙니다.

그것이 더 진보된 방식입니다. 왜냐하면 실패 경계 (failure boundaries)를 존중하기 때문입니다.

내가 가장 먼저 구축할 것

아웃리치 (outreach)가 아닙니다.

그것은 미끼일 뿐입니다.

점수 매기기 루프 (scoring loop)를 먼저 구축하세요.

여기서 시작하세요

25개의 후보자 프로필을 수집합니다.
이를 Google Sheets나 데이터베이스 테이블에 넣습니다.
점수 산정 루브릭 (scoring rubric)을 정의합니다.
모든 행에 대해 동일한 프롬프트 (prompt)를 실행합니다.
출력값을 비교합니다.
루브릭을 수정합니다.
반복합니다.

최소한의 프롬프트만으로도 충분합니다:

당신은 아웃리치 (outreach)를 위한 프리랜서 후보자들의 점수를 매기고 있습니다.

다음 항목을 기준으로 이 후보자를 평가하세요:
...

그다음, 만약 OpenClaw를 사용 중이라면, 시스템이 실행되는 동안 실제로 검사하십시오:

openclaw status --deep
openclaw logs --follow
openclaw doctor

만약 특정 후보자가 왜 선택되었는지 설명할 수 없다면, 당신은 아웃리치를 자동화할 준비가 되지 않은 것입니다.

가혹하게 들릴 수도 있습니다.

하지만 다이어그램 상으로는 똑똑해 보였던 워크플로 (workflow)에 또 다른 50시간을 허비하는 것보다는 여전히 저렴합니다.

진짜 교훈

교훈은 OpenClaw가 약하다는 것이 아닙니다.

교훈은 사람들이 지저분한 인간의 워크플로 (workflows)를 하나의 영웅적인 프롬프트 (prompt)로 압축하려고 계속 시도한다는 것입니다.

그것은 거의 항상 실패합니다.

이를 분해하십시오.

LLM (대규모 언어 모델)이 판단하게 하십시오.

스크립트 (scripts)가 실행하게 하십시오.

n8n이나 Make가 오케스트레이션 (orchestrate)하게 하십시오.

그리고 토큰 가격 (token pricing) 때문에 설계가 왜곡될 정도로 반복적인 LLM 작업을 수행하고 있다면, 반복 (iteration)에 대해 벌칙을 주지 않는 인프라를 사용하십시오.

그것이 이러한 워크플로 (workflows)가 단순한 데모를 넘어 시스템 (systems)이 되는 방법입니다.