데모: https://loopgraph.vercel.app/brain

캠페인이 예산을 낭비하기 시작합니다. 고객이 제품 사용을 중단합니다. 계약이 뒤로 밀립니다. 계약 갱신 시점이 다가옵니다. 송장이 허용 범위를 벗어납니다. 운영 장애(production incident)가 발생합니다.

대부분의 기업은 이러한 순간들을 알림(notification)으로 경험합니다.

누군가가 알림을 확인하고, 그것이 무엇을 의미하는지 결정하며, 어느 부서의 소관인지 기억하고, 여러 시스템에서 맥락(context)을 수집하며, 프로세스를 선택하고, 승인을 요청하고, 후속 조치를 취하며, 결국 문제가 실제로 해결되었는지 확인합니다.

그러면 또 다른 신호가 도착하고 전체 프로세스가 다시 시작됩니다.

이것이 모든 기업 내부에서 일어나는 보이지 않는 업무입니다. 이것은 단순히 작업을 실행하는 것이 아닙니다. 이벤트를 문제로, 문제를 소유권(ownership)으로, 소유권을 조율된 행동(coordinated action)으로, 그리고 행동을 기업이 학습할 수 있는 결과(outcomes)로 전환하는 지속적인 행위입니다.

오늘날 사람들은 이러한 운영 그래프(operating graph)의 대부분을 머릿속에 담고 있습니다.

우리는 다른 모델을 구축하고 있습니다: Hermes Agent가 기업의 이벤트를 수신하고 해석합니다. 각 비즈니스 문제를 적절한 부서로 라우팅(route)합니다. 모든 부서는 여러 개의 특화된 루프(loop)를 소유합니다. Loopgraph는 어떤 루프가 실행될 수 있는지, 무엇을 할 수 있는지, 그리고 결과가 어떻게 기록되는지를 관리합니다.

우리는 이 모델 뒤에 있는 규율을 루프 그래프 엔지니어링 (Loop Graph Engineering)이라고 부릅니다.

이는 고립된 작업을 자동화하는 것에서 벗어나, 기업 전체가 어떻게 반응하고, 결정하고, 행동하고, 검증하고, 개선하는지를 엔지니어링하는 것으로의 전환입니다.

기업은 에이전트(agent)들의 목록이 아닙니다.
자율 기업을 상상하는 가장 쉬운 방법은 모든 도구에 연결된 하나의 거대한 에이전트라고 생각하는 것입니다.

그 그림은 단순해 보이기 때문에 흥미롭습니다: 모델에 충분한 맥락(context)과 충분한 권한, 그리고 충분히 야심 찬 프롬프트(prompt)를 제공한 다음, 그냥 실행하게 두는 것입니다.

하지만 실제 기업은 단순하지 않습니다.

마케팅 (Marketing), 영업 (Sales), 고객 성공 (Customer Success), 재무 (Finance), 운영 (Operations), 법무 (Legal), 그리고 엔지니어링 (Engineering)은 서로 다른 종류의 업무를 수행합니다. 이들은 서로 다른 증거 (evidence)를 사용하며, 서로 다른 책임자에게 보고합니다. 또한 서로 다른 리스크 한도 (risk limits) 하에서 운영되며, 각기 다른 완료 (done)의 정의를 가지고 있습니다.

심지어 하나의 부서 내부에서도 단일한 워크플로우 (workflow)는 존재하지 않습니다.

마케팅 부서는 광고 최적화 루프 (Ads Optimization loop), 콘텐츠 제작 루프 (Content Creation loop), 라이프사이클 루프 (Lifecycle loop), SEO 루프 (SEO loop), 그리고 출시 조율 루프 (Launch Coordination loop)를 담당할 수 있습니다. 영업 부서는 리드 자격 검증 (Lead Qualification), 거래 리스크 (Deal Risk), 후속 조치 (Follow-Up), 예측 품질 (Forecast Quality), 그리고 확장 (Expansion) 루프를 담당할 수 있습니다. 고객 성공 부서는 온보딩 (Onboarding), 채택 리스크 (Adoption Risk), 갱신 리스크 (Renewal Risk), 그리고 에스컬레이션 (Escalation) 루프를 담당할 수 있습니다.

부서는 운영 경계 (operating boundary)입니다. 루프는 그 경계 내부의 전문화된 업무 단위입니다.

이러한 구분은 매우 중요합니다. 만약 모든 부서가 하나의 일반적인 자동화 (automation)를 가리킨다면, 그 아키텍처 (architecture)는 단지 더 큰 상자 뒤로 복잡성을 숨길 뿐입니다. 진정한 운영 그래프 (operating graph)는 Hermes가 부서들로 라우팅 (route)되며, 각 부서가 서로 다른 작업, 증거, 권한, 그리고 결과를 가진 수많은 루프를 소유할 수 있음을 보여주어야 합니다.

대부분의 자동화는 여전히 선형적인 구조로 설계되어 있습니다:

트리거 (trigger) -> 에이전트 (agent) -> 액션 (action)

이것은 하나의 작업을 더 빠르게 만들 수는 있지만, 회사를 더 지능적으로 만들지는 못합니다.

기업 형태의 아키텍처는 다르게 보입니다:

이벤트 (events) -> Hermes Agent -> 부서 (departments) -> 다수의 거버넌스 루프 (multiple governed loops) -> 결과 (outcomes) -> 증거 (evidence)

Hermes는 또 다른 부서가 아닙니다. Hermes는 들어오는 신호를 해석하고 비즈니스 문제가 어디에 속하는지를 결정하는 지능 (intelligence)입니다.

부서는 실행 가능한 워크플로우 (executable workflows)가 아닙니다. 부서는 소유권과 정책의 경계입니다.

루프 (Loops)는 실제 운영 단위입니다. 각 루프는 제한된 범위의 증거 (evidence)를 관찰하고, 정의된 목표를 추구하며, 허용된 동작을 준비하거나 수행하고, 결과를 검증하며, 인간의 판단이 필요할 때 에스컬레이션 (escalation)하고, 발생한 일을 기록합니다.

루프 내부의 모델은 변경될 수 있습니다. 도구 (tools)도 변경될 수 있습니다. 제공자 (provider)도 변경될 수 있습니다. 하지만 루프는 여전히 안정적인 비즈니스 계약 (business contract)을 유지합니다:

이 루프는 왜 존재하는가?
어떤 종류의 문제가 루프를 깨우는가?
어떤 증거가 반드시 가용해야 하는가?
무엇을 읽거나 변경할 수 있는가?
무엇이 승인을 필요로 하는가?
문제가 해결되었음을 무엇으로 증명하는가?
결과로부터 무엇을 학습해야 하는가?

에이전트 (agent)는 추론 (reasoning)할 수 있기 때문에 강력하며, 루프는 그 권한이 제한되어 있기 때문에 신뢰할 수 있습니다.

이벤트 (event)는 명령 (instruction)이 아니라 증거 (evidence)입니다.
전통적인 자동화는 종종 이벤트를 동작 (action)에 직접 하드와이어링 (hardwire)합니다:

'X가 발생하면, Y를 실행하라'

이 방식은 세상이 깨끗하고 모든 이벤트가 정확히 하나의 의미만을 가질 때 작동합니다. 기업은 그런 세상에서 운영되지 않습니다.

열 개의 웹훅 (webhook) 전달이 하나의 지속적인 문제를 설명할 수도 있습니다. 하나의 페이로드 (payload)가 두 개의 독립적인 문제를 포함할 수도 있습니다. 유효한 이벤트가 적절한 루프가 비활성화되어 있거나, 이미 실행 중이거나, 데이터가 누락되었거나, 쿨다운 (cooldown) 기간 내에 있거나, 승인된 자율성 수준 (autonomy level)을 벗어난 상태에서 도착할 수도 있습니다.

때로는 올바른 대응이 기다리는 것일 수 있습니다. 때로는 컨텍스트 (context)를 요청하는 것일 수 있습니다. 때로는 아무것도 실행하지 않고 문제를 기록하는 것일 수 있습니다.

따라서 루프 그래프 (Loopgraph)는 대부분의 자동화 시스템이 하나로 뭉뚱그려 처리하는 세 가지 객체를 분리합니다.

이벤트 (event)는 불변의 증거 (immutable evidence)입니다. 그것은 무언가가 발생했다는 사실, 그것이 어디에서 왔는지, 언제 발생했는지, 어떤 대상과 관련되는지, 어떻게 인증되었는지, 그리고 어떤 정규화된 데이터 (normalized data)가 수신되었는지를 기록합니다.

비즈니스 문제 (business problem)는 상태 유지 (stateful)됩니다. 그것은 회사가 해결해야 하는 이슈를 나타냅니다. 이는 시간이 지남에 따라 여러 이벤트로부터 증거를 수집할 수 있습니다.

루프 실행 (loop run)은 하나의 시도입니다. 이는 문제를 해결하기 위해 통제된 하나의 노력입니다. 실행은 성공하거나, 실패하거나, 승인을 기다리거나, 혹은 이전의 이력을 삭제하지 않고 새로운 증거를 생성할 수 있습니다.

유료 캠페인이 한 시간 동안 10개의 이상 징후 알림 (anomaly alerts)을 생성한다고 가정해 봅시다.

트리거 기반 (trigger-based) 시스템은 10개의 최적화 작업을 시작할 수 있습니다. 반면 문제 기반 (problem-based) 시스템은 10개의 증거 조각이 하나의 미결 캠페인 효율성 문제를 설명하고 있음을 인식합니다. 시스템은 새로운 증거를 추가하고, 심각도 (severity)를 업데이트하며, 이미 활성화된 루프가 있는지 확인하여 중복 작업을 방지합니다.

첫 번째 시도가 검증에 실패하더라도, 이벤트는 소실되지 않으며 문제도 사라지지 않습니다. 다른 실행을 다시 시도할 수 있습니다. 사람이 직접 관리권을 가질 수도 있습니다. 보조 루프 (supporting loop)를 도입할 수도 있습니다. 시스템은 발생한 일, 회사가 그것이 의미한다고 믿었던 것, 그리고 수행하려고 시도했던 것 사이의 차이를 기억합니다.

이것이 조직적 기억 (organizational memory)의 시작입니다.

Hermes는 해석하고 Loopgraph는 관리합니다
언어적 판단 (Language judgment)과 운영 권한 (operational authority)은 서로 다른 작업입니다. 이 아키텍처는 이 둘을 의도적으로 분리합니다.

Hermes Agent는 회사 그래프의 중심에 있는 가시적인 지능이자 유일한 외부 이벤트 유입 (ingress) 지점입니다. 비즈니스 시스템은 Hermes로 이벤트를 보냅니다. Hermes는 경로를 인증 및 필터링하고, 제공자 페이로드 (provider payloads)를 경계가 지정된 이벤트 봉투 (bounded event envelopes)로 정규화하며, 발생 가능한 비즈니스 문제를 해석하고, 적절한 루프를 비교하여 구조화된 경로를 제안합니다.

Loopgraph는 관리되는 레지스트리 (registry)이자 실행 커널 (execution kernel)입니다. Loopgraph는 승인된 루프 사양 (LoopSpecs), 부서 구조, 라우팅 계약 (routing contracts), 커넥터 준비 상태 (connector readiness), 내구성이 있는 이벤트 영수증 (durable event receipts), 비즈니스 문제 기록, 쿨다운 (cooldowns), 동시성 규칙 (concurrency rules), 정책 확인 (policy checks), 큐 (queues), 트레이스 (traces), 검토 (reviews), 승인 (approvals) 및 결과 (outcomes)를 소유합니다.

가장 깔끔하게 표현하자면 다음과 같습니다:

Hermes는 제안하고, Loopgraph는 확정합니다 (commits).

Hermes는 캠페인에 고객 획득 효율성 (acquisition-efficiency) 문제가 있다는 것을 추론할 수 있습니다. 하지만 존재하지 않는 루프를 만들어내거나, 쿨다운 (cooldown)을 무시하거나, 승인 절차를 우회하거나, 사용할 수 없는 커넥터 (connector)를 사용하거나, 초안 (draft)을 자율적인 고객 대면 액션으로 전환할 수는 없습니다.

이것들은 언어적인 질문이 아닙니다. 이것들은 시스템적 사실 (system facts)이자 정책 결정 (policy decisions)입니다. 이들은 결정론적 코드 (deterministic code)에 속해야 합니다.

이러한 분리는 우리에게 두 계층의 최상의 특성을 모두 제공합니다:

• Hermes는 복잡한 비즈니스 컨텍스트 (business context)에 대해 유연하게 추론할 수 있습니다.
• Loopgraph는 안정적인 운영 경계 (operational boundaries)를 강제할 수 있습니다.
• 모든 결정은 사후에 검사될 수 있습니다.
• 모델과 도구는 권한 (authority)을 조용히 변경하지 않고도 진화할 수 있습니다.
• 잘못된 추론은 잘못된 액션이 되기 전에 거부될 수 있습니다.

목표는 추론 계층 (reasoning layer)의 지능을 낮추는 것이 아닙니다. 지능을 실제 운영에서 사용할 수 있을 만큼 충분히 안전하게 만드는 것입니다.

라우팅 (Routing)은 통제된 결정입니다.
이벤트가 도착했을 때, Hermes가 회사의 모든 루프 중에서 선택해서는 안 됩니다.

라우팅은 두 단계로 이루어집니다.

첫 번째 단계는 결정론적 적격성 (deterministic eligibility)입니다. Loopgraph는 레지스트리 (registry)를 필터링하여 다음 조건을 만족하는 루프를 찾습니다: 활성화 상태인지, 해당 이벤트 패밀리 (event family)를 수용하는지, 관련 워크스페이스 (workspace) 및 부서에 속해 있는지, 필수 필드를 매핑할 수 있는지, 필요한 커넥터 또는 수동 폴백 (manual fallback)을 갖추고 있는지, 쿨다운 및 동시성 (concurrency) 제한 내에 있는지, 그리고 이미 동일한 이벤트를 커밋 (commit)하지 않았는지 확인합니다.

이 단계는 다음 질문에 답합니다:

무엇이 실행될 수 있는가?

그다음에야 Hermes는 적격한 라우팅 카드 (Routing Cards)를 비교합니다. Hermes는 실제 비즈니스 문제, 각 루프의 구체성, 가용 증거, 예상 결과, 위험 수준, 그리고 하나 이상의 독립적인 문제가 존재하는지 여부를 평가합니다.

이 단계는 다음 질문에 답합니다:

무엇이 실행되어야 하는가?

Loopgraph는 제안된 경로를 커밋하기 전에 다시 한번 검증합니다.

이 아키텍처는 자율 시스템(autonomous systems)이 보통 숨기는 사례들에 대해 명시적인 답변을 제공합니다.

만약 적절한 루프(loop)가 없다면, 해당 문제는 처리되지 않은 것(unhandled)으로 기록됩니다. Hermes는 새로운 워크플로우(workflow)를 즉흥적으로 만들어내지 않습니다.

만약 두 개의 루프가 비슷하게 타당하다면, 시스템은 사람에게 묻거나 선언된 트리아지 루프(triage loop)를 사용합니다. 추측하지 않습니다.

만약 활성화된 문제에 대해 동일한 이벤트가 다시 도착하면, 이는 추가적인 증거가 됩니다. 중복된 작업을 생성하지 않습니다.

만약 하나의 이벤트에 진정으로 독립적인 여러 문제가 포함되어 있다면, 경로는 팬아웃(fan out)될 수 있습니다. 하지만 이는 선택된 모든 루프가 이를 허용하고 전체 경로의 수가 제한된 범위 내에 있을 때만 가능합니다.

광범위한 루프와 전문적인 루프가 모두 관련 있어 보인다면, 구체성(specificity)이 우선합니다. 관리 루프(management loop)는 단순히 모든 것을 관찰할 수 있다는 이유만으로 작업을 가져가지 않습니다.

이것이 라우팅(routing)을 단순한 프롬프트(prompt)에서 책임 있는 기업의 의사결정으로 전환하는 핵심입니다. 시스템은 무엇이 적절했는지, 무엇이 거부되었는지, 어떤 증거가 중요했는지, 어떤 정책이 적용되었는지, 어떤 경로가 커밋되었는지, 그리고 다음에 어떤 일이 일어났는지 설명할 수 있습니다.

하나의 부서가 여러 루프를 소유할 수 있습니다
부서 레이어(department layer)는 기업의 소유권이 가시화되는 지점입니다.

이는 모든 작업을 하나의 거대한 부서 에이전트(departmental agent)를 통해 강제로 통과시키지 않으면서도, 그래프에 안정적인 조직적 형태를 부여합니다. Hermes는 문제를 마케팅(Marketing) 부서로 라우팅할 수 있지만, 결과물을 어떤 전문 루프가 담당할지는 여전히 마케팅 부서에서 결정해야 합니다.

우리의 첫 번째 참조 디자인(reference design)은 두 개의 구체적인 마케팅 루프를 사용합니다.

Ads 루프는 지출(spend), 캠페인 성과(campaign performance), 분석 전환(analytics conversion), CRM 자격 결과(CRM-qualified outcomes), 그리고 이전 실험(prior experiments)을 모니터링합니다. 이 루프의 목표는 더 많은 클릭을 유도하는 것이 아닙니다. 목표는 개선된 자격 획득 효율성(qualified acquisition efficiency)과 더 빠른 학습입니다. 이 루프는 증거를 수집하고, 낭비나 기회를 식별하며, 실험 브리프(experiment brief)를 준비할 수 있습니다. 하지만 예산, 타겟팅, 주장(claims), 또는 캠페인 상태를 몰래 변경할 수는 없습니다.

Content 루프는 승인된 포지셔닝(positioning), 고객 및 제품 증거(customer and product evidence), 콘텐츠 백로그(content backlog), 과거 성과, 그리고 검토자 피드백(reviewer feedback)을 모니터링합니다. 이 루프는 주제의 순위를 매기고, 브리프를 준비하며, 콘텐츠 초안을 작성하고, 주장과 톤(voice)을 검증하며, 결과를 검토 단계로 보낼 수 있습니다. 하지만 근거 없는 주장을 게시하거나 필요한 승인 없이 자료를 보낼 수는 없습니다.