몇 달 전, 저는 OpenClaw가 무엇을 할 수 있는지 확인해 보려고 일회성 사이드 프로젝트에서 이를 만져보고 있었습니다. 어느 시점에 저는 에이전트에게 평이한 영어로 저를 대신해 작은 반복 작업을 수행하라고 말했습니다. 에이전트는 작업을 수행하러 떠났고, cron job (크론 잡)을 작성하고, 커넥터 (connector)를 연결했으며, 그것으로 끝이었습니다.

저는 잠시 그 자리에 앉아 생각에 잠겼습니다. 제 이전 회사가 n8n에서 스케줄링, 통합 (integrations), 그리고 그 사이를 잇는 접착제 역할을 하는 기능들을 구축하기 위해 몇 주를 보냈던 작업이 그저 그곳에 있었습니다. 에이전트가 이미 커넥터를 가지고 있고 스케줄러 (scheduler)와 통신할 수 있었기 때문에, n8n과 같은 도구를 가치 있게 만들었던 전체 통합 계층 (integration layer)이 조용히 증발해 버린 것입니다. 원하는 것을 말하기만 하면 스스로 설정을 마쳤습니다.

그러자 두 번째 생각이 들었고, 그것이 가장 중요한 생각이었습니다. 저는 실제로 중요한 무언가를 이 방식대로 실행하게 내버려 두지 않을 것입니다. 관리자 없이 방치된 상태로는, 특히 비즈니스 환경에서는 절대 안 될 것입니다.

그 간극이 이 이야기의 핵심입니다. 설정 (setup) 문제는 대부분 해결되었습니다. 신뢰 (trust) 문제는 해결되지 않았습니다. 이 포스트는 제가 '감시자 (overseer)'라고 부르기 시작한, 아직 빠져 있는 조각에 관한 것입니다.

성공하지 못한 노코드 (no-code) 파이프라인

먼저, 인정할 것은 인정해야겠습니다. n8n은 실제 문제를 해결했으며, 여전히 많은 작업에 적합한 도구입니다. 반복적인 작업은 스케줄에 따라 실행되어야 하고, 재시작 시에도 살아남아야 하며, 당신이 지켜보고 있지 않을 때도 계속 진행되어야 합니다. 그것이 내구성 있는 실행 (durable execution)이며, 이는 진정으로 어려운 일입니다. n8n은 이를 접근 가능하게 만들었습니다.

문제는 작성 (authoring)과 실행 (execution) 양쪽 끝에서 나타났습니다.

제 이전 회사에서는 아웃리치 (outreach)를 자동화해야 했습니다. CRM에서 잠재 고객을 추출하고, 누가 인바운드 (inbound)인지 아웃바운드 (outbound)인지 결정하며, 각 고객을 위한 개인화된 메시지를 초안하고, 웹 데이터를 통해 내용을 보강한 뒤, 이메일을 보내는 작업이었습니다. 서류상으로는 이것이 엔지니어가 아닌 사람도 관리할 수 있는 깔끔하고 비기술적인 파이프라인이 될 것이었습니다.

상황은 그렇게 유지되지 않았습니다. 데이터 스트림 (data streams)을 분할하고 재구성하기 위해 코드가 필요했습니다. LLM (Large Language Model) 단계는 제약이 매우 심했고, 모델들은 우리가 직접 사용할 수 없는 출력을 계속 반환했습니다. 그래서 텍스트를 파이프라인이 처리할 수 있는 객체 (objects)로 다시 변환하기 위해 구조화된 도구 출력 (structured tool outputs)을 정의하고 파싱 (parsing) 단계를 추가해야만 했습니다. 게다가 시스템은 불안정했습니다. AI 단계에서 타임아웃 (time out)이 발생하거나, 아무것도 반환하지 않거나, 조용히 오작동하곤 했습니다. 노코드 (no-code) 워크플로우 (workflow)로 판매되었던 것이, 누군가가 계속해서 돌봐줘야 하는 매우 기술적이고 매우 취약한 프로세스로 변해버린 것입니다.

저작 (authoring) 과정이 고통스러운 이유는 바로 시각적 워크플로우 (visual-workflow) 모델이 존재하는 이유이기도 합니다. 런타임 (runtime)이 즉흥적으로 대처할 것이라고 믿을 수 없기 때문에, 모든 분기 (branch)를 사전에 지정해야 합니다. 그래프 (graph)는 유연할 것이라고 신뢰할 수 없는 동작을 고정시킵니다. 유능한 에이전트 (agent)는 그 비용을 제거합니다. 당신은 작업을 말로 한 번만 설명하면, 에이전트가 단계를 알아서 찾아냅니다.

하지만 실행 (execution) 문제는 에이전트와 함께 사라지지 않습니다. 기존 도구들은 결정론적 (deterministic) 단계에 대해 내구성이 있는 실행 (durable execution)을 보장하지만, LLM 단계는 결정론적이지 않습니다. LLM 단계가 파이프라인 중간에 놓이는 순간, 당신이 의존해 왔던 보장 사항들은 더 이상 유지되지 않으며, 이것이 바로 우리의 시스템이 계속 타임아웃이 발생하거나 조용히 멈춰버렸던 이유입니다. 결과적으로 저작은 쉬워지지만 실행은 더 어려워지며, 처음부터 비결정론적 (non-deterministic) 작업을 위해 구축된 런타임이 필요하게 됩니다.

에이전트가 가져간 것과 남겨둔 것

에이전트 커넥터 (Agent connectors)는 통합자 (integrator)의 해자 (moat)를 가져갔습니다. 기존 도구들의 어렵고 방어 가능한 부분은 방대한 통합 목록과 그 사이의 배선 (wiring)이었습니다. 커넥터와 스케줄러 (scheduler)를 갖춘 에이전트는 문장 하나만으로 이를 무료로, 요청 시 즉시 수행합니다.

하지만 에이전트가 당신에게 주지 못한 것은, (시스템을 떠나) 완전히 손을 뗄 수 있는 능력입니다.

유능한 로컬 에이전트(local agent)는 당신을 위해 광범위한 작업을 기꺼이 수행할 것입니다. 하지만 이를 관리자 없이(unattended) 실행하려면 두 가지 선택지가 있는데, 둘 다 좋지 않습니다. 매 단계마다 에이전트가 권한을 요청하도록 두는 것인데, 이는 당신이 여전히 그 자리에 앉아 있어야 함을 의미하므로 실제로 업무가 위임된 것이 아닙니다. 또는 에이전트가 스스로 실행되도록 내버려 두고 운에 맡기는 것인데, 이는 장난감 용도로는 괜찮을지 몰라도 중요한 작업에서는 생각조차 할 수 없는 일입니다. 또한 이러한 에이전트들은 단일 작업에 정확히 필요한 액세스 권한으로 범위가 제한된(scoped), 실제 권한 모델(permissions model) 하에서 클라우드(cloud) 상에 실행되도록 설계된 적도 없습니다.

따라서 병목 현상(bottleneck)의 위치가 이동합니다. 그것은 더 이상 설정(setup)의 문제도 아니고, 능력(capability)의 문제도 아닙니다. 병목 현상은 바로 지켜보고 있는 당신입니다. 자동화 작업을 하나 실행한다면 계속 지켜볼 수 있습니다. 하지만 열 개나 스무 개를 실행한다면, 그중 하나가 고장 났는지 감시하는 것이 풀타임 업무가 되어버립니다. 당신이 포화 상태에 이르는 이유는 에이전트가 작업을 수행하지 못해서가 아니라, 그 모든 것을 검토할 수 없기 때문입니다.

그것이 바로 제가 해결하고 싶었던 부분입니다.

감시를 멈추기 위해 필요한 것

작업을 혼자 내버려 두기 전에 충족되어야 하는 조건들의 목록은 짧고 대부분 지루합니다. 작업은 예정된 시간에 실행되어야 하며, 실행할 수 없을 때는 명확하게 실패를 알려야(fail loudly) 합니다. 또한 작업에 정확히 필요한 액세스 권한으로 범위가 제한(scoped)되어야 하며, 샌드박스(sandboxed) 처리되어 잘못된 작업이 건드려서는 안 될 영역으로 침범할 수 없어야 합니다. 그리고 매 실행을 감시하며, 매번 당신에게 보고할지 아니면 조용히 넘어갈지를 결정할 무언가가 있어야 합니다. 결정론적 코드(deterministic code)의 경우, 성공은 테스트 통과 여부와 같이 확인할 수 있는 이진(binary) 값입니다. 하지만 에이전트의 경우 그러한 명확한 기준이 없으므로, 실행이 실제로 잘 되었는지 여부는 확인(check)이 아닌 판단(judgment)의 영역입니다. 앞의 두 가지는 기본 조건(table stakes)입니다. 마지막 하나가 게임의 핵심입니다. 그것이 검토(review)를 확장 가능하게(scale) 만드는 핵심이며, 안전하게 무시해도 되는 실행과 실제로 당신의 도움이 필요한 소수의 실행을 구분해 줍니다.

그리고 그 감시자(watcher)는 작업자(worker)와 분리되어야 합니다. 자신의 작업을 스스로 채점하는 에이전트는 긍정적인 방향으로 편향(skew positive)되기 마련입니다. 이것이 바로 Anthropic의 최근 harness work에서 하나의 에이전트에게 두 가지를 모두 맡기는 대신, 생성기(generator)와 별도의 평가기(evaluator)를 쌍으로 구성한 이유입니다. 작업자는 일을 끝내고 싶어 하지만, 검사자는 문제를 찾아내고 싶어 해야 합니다.

그래서 저는 그 감시자를 만들었습니다

그것의 이름은 Golemry입니다. 이는 로컬 에이전트에게 결코 없었던 계층, 즉 반복적인 작업을 위한 인프라(infrastructure)입니다.

여러분은 이미 사용 중인 에이전트에 이를 MCP 서버(MCP server)로 추가하기만 하면 됩니다. 일상적인 언어로 반복적인 작업을 설명하면, 에이전트가 작업을 설정합니다. 그 이후부터 작업은 Golemry에서 정해진 일정에 따라 실행되며, 도구(tools)의 범위 내에서 샌드박스(sandboxed) 처리됩니다. 동시에 감시자(overseer)가 모든 실행을 검토하며, 무언가 잘못된 것으로 보일 때만 여러분을 호출합니다. 여러분의 에이전트는 인터페이스(interface) 역할을 유지합니다. 에이전트는 작업을 설정하고, 무엇이 실행되었는지 확인하며, 여러분의 도움이 필요한 단 한 가지 사항만을 전달합니다.

이것이 잡아내는 사례 중 하나입니다. 저에게는 매주 연구 작업을 수행하며 정상적으로 보이는 개요를 이메일로 보내주는 작업이 있었는데, 그 이면의 실제 작업은 조용히 부실해지고 있었습니다. 결과물만 봐서는 전혀 눈치챌 수 없었지만, 감시자는 결과뿐만 아니라 실행 과정(run) 자체를 읽기 때문에 추론(reasoning)이 빈약해지는 것을 포착하고 해당 작업이 구식(outdated)이라고 표시했습니다. 이메일의 내용만으로는 절대 알 수 없었을 일입니다.

돌봄이 필요 없는 여러분의 에이전트

커넥터(connectors)를 포함하여 현재 매일의 상호작용을 처리하고 있는 에이전트를 상상해 보세요. 이제 여기에 새로운 능력이 하나 추가됩니다. 주간 연구 개요, 포스트 아이디어 및 초안을 위한 크롤링(crawl), 혹은 매일 아침 확인해야 하는 보고서와 같이 반복되는 모든 것을, 혼자 두어도 괜찮고 필요할 때만 여러분을 다시 부를 수 있도록 설계된 무언가에 맡길 수 있게 됩니다.

그것이 바로 복리로 쌓이는 자동화와 당신의 숨통을 조이는 자동화의 차이입니다. 당신은 한 번에 얼마나 많은 자동화가 실행될 수 있는지를 결정하는 한계점(ceiling)이 되지 않게 됩니다. 그리고 실행과 권한이 당신의 기기가 아닌 인프라(infrastructure)에 존재하기 때문에, 이전에는 결코 시도하지 않았을 곳에 마침내 에이전트(agent)를 배치할 수 있습니다.

공개 개발 (Building this in public)

저는 인상적인 것보다 정확한 것을 선호하므로, 현재의 솔직한 상태를 말씀드리겠습니다.

현재 V1 단계에서는 다음과 같은 기능이 제공됩니다: 에이전트의 MCP 서버를 통해 설정된 예약된 작업(scheduled jobs), 샌드박스 실행(sandboxed runs), 각 작업이 필요한 도구에만 제한된 범위(scoped)를 갖는 구조, 방대한 커넥터(connectors) 라이브러리, 그리고 사후에 각 실행을 검토하고 이메일과 알림을 통해 판결(verdict)을 전달하며 에스컬레이션(escalating)하는 감독자(overseer) 기능입니다.

다음 단계: 제안된 작업이 실행되기 전에 감독자가 의견을 제시하는 인간 참여형(human-in-the-loop) 도구와, 단순히 시계(clock)에 의해서만이 아니라 특정 사건이 발생했을 때 작업이 실행될 수 있도록 하는 이벤트 기반 트리거(event-based triggers)를 준비 중입니다.

아직 해결해야 할 과제: 피드백 루프(feedback loop)와 학습 부분입니다. 여기서 감독자의 판결과 사용자의 응답은 작업이 시간이 지남에 따라 조정할 수 있는 임계값(threshold)이 됩니다. 작업이 신뢰를 쌓으면 에스컬레이션을 조금씩 줄이고, 실수가 발생하면 조금 더 늘리는 방식입니다. 여기서 핵심은 이를 어떻게 직관적인 방식으로 노출하고 범위를 지정(scope)할 것인가 하는 점입니다.

목표는 어떤 단계에서도 변하지 않습니다. 모든 것을 감시하는 단계에서 거의 아무것도 감시하지 않는 단계로 점진적으로 이동하는 것이며, 이는 막연한 기대감이 아니라 지표로 가리킬 수 있는 보장(guarantees)을 바탕으로 이루어집니다.

V1은 현재 라이브 상태입니다. golemry.com에서 직접 체험해 보실 수 있으며, 로드맵은 인간 참여형(human-in-the-loop) 및 학습 기능이 나아갈 방향을 보여줍니다. 직접 사용해 보시고 어디서 문제가 발생하는지 알려주세요. 그것이 제가 이 시스템을 구축하는 데 바탕이 되는 피드백입니다.