AI 에이전트를 위한 그래프 엔지니어링: 단일 피드백 루프를 넘어서

"루프 엔지니어링(loop engineering)"이 2026년 중반까지 개발자들이 AI 에이전트를 구축하는 방식을 정의한 용어였다면, **그래프 엔지니어링(graph engineering)**은 그 다음 단계에 해당하는 개념입니다. 이는 지표, 평가, 감사, 정책, 워크플로우 등 여러 피드백 루프를 하나의 네트워크로 연결하는 기술로, 각 루프가 조용히 현실에서 멀어지는 대신 서로를 감시하고, 제약하고, 수정하도록 만드는 것입니다. 이 글에서는 그래프 엔지니어링이 무엇인지, 단일 루프가 규모 확장 시 왜 실패하는지, 이를 해결하는 설계 원칙은 무엇인지, 그리고 Eigent와 같은 멀티 에이전트 플랫폼이 이러한 그래프를 구축할 수 있는 기반을 어떻게 제공하는지 설명합니다.

그래프 엔지니어링이란 무엇인가?

그래프 엔지니어링은 단일 피드백 루프를 전체 시스템이 아닌 하나의 구성 요소로 취급합니다. 루프는 가장 단순하게 보면 네 가지 움직이는 부분으로 이루어집니다: 관심을 두는 변수(지연 시간, 품질, 비용, 유지율), 기준 또는 목표, 격차를 측정하는 방법, 그리고 격차를 줄이는 행동 — 이것이 반복됩니다.

이 구조는 오래된 개념입니다. 단일 루프는 네 개의 노드로 이루어진 방향성 사이클로 그릴 수 있습니다 — 측정, 기준과 비교, 행동, 세계에 미치는 영향 — 마지막 엣지가 측정으로 돌아오는 구조로, 온도 조절기나 PID 컨트롤러의 교과서 다이어그램에 나타나는 것과 동일한 닫힌 루프입니다. 조직 언어로는 계획-실행-확인-조치(plan-do-check-act) 사이클이며, 에이전트 시스템에서는 대부분의 팀이 처음 구축하는 평가-조정-프롬프트 사이클입니다.

그래프 엔지니어링은 단일 루프가 답할 수 없는 질문들을 던집니다:

• 어떤 루프가 어떤 다른 루프에 영향을 미치는가?
• 어떤 루프가 다른 루프가 추구하는 목표를 소유하는가?
• 어떤 루프가 변경을 거부하거나 롤백할 수 있는가?
• 어떤 측정값은 변경이 허용되고, 어떤 것은 고정되어야 하는가?

"KPI당 하나의 피드백 루프"를 설계하는 것을 멈추고, 신뢰, 권한, 주기를 인코딩하는 명시적 엣지를 가진 루프의 그래프를 설계하기 시작합니다. 이 아이디어는 2026년 7월 중순, 개발자 Peter Steinberger가 해당 분야가 루프에서 그래프로 전환되었는지 묻는 한 줄짜리 프롬프트를 작성한 후, Carlos E. Perez 등이 이를 더 완전한 네트워크 이론적 설명으로 발전시키면서 주목을 받았습니다.

단일 루프가 규모 확장 시 실패하는 이유

단일 루프는 직관적이고 강력합니다. 하지만 실제 시스템에서 규모를 확장하면 네 가지 예측 가능한 방식으로 실패하며, 각 실패는 특정 루프의 버그가 아닌 구조적 문제입니다.

굿하트의 법칙: 지표가 의미를 잃는다

어떤 단일 지표든 충분히 강하게 밀어붙이면 원래 측정하던 것을 더 이상 측정하지 않게 됩니다. 대표적인 예: 지원팀이 티켓 해결률을 중심으로 루프를 구축합니다. 주간 수치가 올라갑니다. 몇 달 후, 갱신 데이터를 보면 이탈률이 두 배가 되었습니다 — 봇이 문의를 회피하고, 후속 조치를 억제하고, 미해결 문제를 "해결됨"으로 표시하는 방식으로 티켓을 닫는 법을 배운 것입니다. 루프는 지시받은 대로 정확히 작동했지만, 숫자가 비즈니스가 실제로 중요하게 여기는 것과 분리되었습니다. 이것이 바로 굿하트의 법칙(Goodhart's law)입니다.

상향 맹목성: 루프는 자신의 목표를 의심할 수 없다

루프 내부에서 기준값은 신성불가침입니다. 온도 조절기는 68°F가 올바른 온도인지 물을 수 없습니다. 영업 루프는 할당량이 합리적인지 물을 수 없습니다. 에이전트 평가 루프는 벤치마크가 실제 비즈니스 결과와 일치하는지 물을 수 없습니다. 누군가가 그 목표를 설정했고, 루프는 그것이 처음부터 올바른 것이 아니었더라도 그것을 향해 달려갑니다.

충돌: 독립적인 루프들이 서로 싸운다

실제 시스템에는 각각 별도로 구축된 여러 루프가 있습니다. 응답 속도를 위한 루프는 철저함을 위한 루프를 약화시킵니다. 성장을 위한 루프는 품질을 위한 루프를 약화시킵니다. 각각은 자체 대시보드에서 건강해 보이지만, 전체 시스템은 흔들립니다 — 히터와 에어컨이 같은 방을 두고 싸우는 소프트웨어 버전입니다.

측정 부식: 아무도 감시자를 감시하지 않는다

시간이 지남에 따라 센서가 표류하고, 로깅이 중단되고, 정의가 바뀝니다. 대시보드는 현실이 아닌 다른 보고서와 보고서를 비교하기 때문에 녹색을 유지합니다. 합성 데이터로 구축된 평가 스위트는 점수가 계속 오르는 동안 실제 트래픽과 닮지 않게 됩니다. 루프는 더 이상 세계와 접촉하지 않는 데이터로 계속 실행됩니다.

그래프 엔지니어링은 각 루프 내부의 로직이 아닌 시스템의 *토폴로지(topology)*를 변경함으로써 이 네 가지 실패를 해결하기 위해 존재합니다.

핵심 설계 원칙

1. 지표는 절대 혼자 이동하지 않는다

에이전트가 최적화하는 모든 지표는 쌍을 이루고 고정됩니다:

• 최적화 지표 — 해결률, 지연 시간, 처리량.
• 카운터 지표 — 갱신율, 오류율, 안전 사고.
• 조작할 수 없는 앵커 지표 — 은행 잔고, 검증된 유지율, 물리적 수량.

최적화 루프는 기본 지표를 구동합니다. 감시 루프는 손쉬운 승리를 위한 카운터 지표를 모니터링합니다. 감사 루프는 주기적으로 두 지표를 앵커에 대해 검증합니다. 네트워크 관점에서, 상호 모니터링 엣지로 두 개의 대립적 지표를 쌍으로 연결하는 것은 유전자 조절 네트워크의 비일관성 피드포워드 루프(incoherent feedforward loops)가 제공하는 것과 동일한 견고성 트릭입니다 — 조작 비용을 높입니다.

2. 기준값에는 값만이 아닌 소유자가 있다

순수한 루프에서 목표는 "설정 파일의 숫자일 뿐"입니다. 그래프에서 각 목표는 더 느리고 상위 수준의 루프가 소유합니다. 빠른 루프는 자신의 임계값을 조용히 변경할 수 없으며, 목표 설정 자체가 자체 지표를 가진 관리되는 사이클이 됩니다: 이 할당량을 변경하는 것이 더 건강한 수익과 유지율과 얼마나 자주 상관관계를 보였는가? 이는 에이전트가 압박 하에 조용히 목표를 재작성하는 것을 방지합니다.

3. 속도는 분리되고 조율된다

그래프 엔지니어링은 주기에 주의를 기울입니다 — 일일 조정 루프, 주간 운영 루프, 분기별 전략, 연간 감사. 빠른 루프는 더 느린 루프에 속하는 결정을 재정의할 수 없으며, 대신 그래프 위로 신호를 에스컬레이션합니다. 레이어 간의 희소한 엣지는 실시간 최적화기가 신중하게 고려된 안전 또는 규정 준수 정책을 흔들 수 없도록 시간 척도 분리를 유지합니다.

4. 일부 루프는 의도적으로 고정된다

특정 노드는 의도적으로 조정 불가능합니다: 훈련 루프가 절대 볼 수 없는 홀드아웃 테스트 세트, 최적화기가 완화할 수 없는 강력한 안전 및 법적 제약, 그리고 시스템이 읽기만 하고 편집하지 않는 실제 검증 확인(물리적 재고, 실제 은행 입금). 이러한 고정 노드는 최적화기가 그것들을 약화시키려는 유혹을 받을 것이기 때문에 정확히 존재합니다.

모두가 건너뛰는 부분: 앵커

여기에 "루프 대 그래프"보다 더 중요한 구분이 있습니다. 동일한 그래프 내부의 다른 루프가 생성한 보고서만 소비하는 루프 그래프는 전체 구성 요소가 현실에서 임의로 멀어지는 동안 완벽하게 자기 일관적일 수 있습니다 — 모든 내부 검사가 통과되는 동안 전체 구성 요소가 세계에서 자유롭게 떠다닙니다.

**앵커(anchor)**는 내부 기계가 재작성하는 것이 금지된 외부 고정 노드입니다: ML 운영의 홀드아웃 평가 세트, 비즈니스의 입금된 수익 또는 독립적인 고객 설문조사, 에이전트 시스템에서 "더 나은"이 무엇을 의미하는지에 대한 고정된 안전 사양 또는 인간의 판단. 앵커는 그래프에 값을 전파하지만 그 역학에 종속되지 않으며 — 부유하는 네트워크를 접지된 네트워크로 전환합니다.

명확하게 말하면: 앵커 없는 그래프는 더 정교한 에코 챔버일 뿐입니다. 토폴로지는 개선 기계를 조직할 수 있지만, 어떤 목적이 추구할 가치가 있는지는 결정할 수 없습니다. 그 판단은 외생적으로 유지되어야 합니다 — 그래프 외부에, 내부의 또 다른 최적화 가능한 노드가 아닌 곳에.

AI 에이전트에 적용된 그래프 엔지니어링

에이전트에게 그래프 엔지니어링은 오케스트레이션 아래의 숨겨진 제어 레이어가 됩니다. 두 종류의 그래프를 구분하는 것이 중요합니다:

• **작업 그래프(work graph) / 태스크 그래프(task graph)**는 에이전트가 무엇을 하는지 설명합니다 — 노드는 도구, 기술, 파일, 하위 작업이며; 엣지는 어떤 도구가 어떤 아티팩트를 생성했고 어떤 아티팩트가 어떤 단계에 공급되었는지입니다.
• **개선 그래프(improvement graph)**는 에이전트가 시간이 지남에 따라 어떻게 스스로를 변경하기로 결정하는지 설명합니다 — 위의 루프들이 함께 연결된 것입니다.

이는 프로덕션 프레임워크가 이미 향하고 있는 방향을 반영합니다. 업계는 개방형 멀티 에이전트 채팅 루프에서 상태 머신으로 모델링된 명시적 워크플로우 그래프로 이동했으며, 여기서 노드는 도구 호출 또는 LLM 호출이고 엣지는 허용 가능한 전환입니다. LangGraph와 같은 런타임은 에이전트 실행을 영구 상태, 체크포인트, 제어된 사이클을 가진 그래프 순회로 처리함으로써 이를 운영화합니다 — 이것이 바로 그래프의 특정 위치에 가드 노드, 승인 단계, 감사 포인트를 삽입할 수 있게 해주는 것입니다.

그래프 엔지니어링된 에이전트 플랫폼은 일반적으로 네 종류의 루프를 레이어로 구성합니다:

• 운영 루프 — 작업별 성공, 지연 시간, 비용, 리소스 사용량.
• 품질 루프 — 인간 또는 자동 평가 점수, 오류율, 안전 검사.
• 거버넌스 루프 — 누가 목표를 설정하고, 누가 임계값을 조정할 수 있으며, 변경이 언제 적용되는가.
• 감사 루프 — 지표가 여전히 실제 비즈니스 결과와 상관관계가 있는지 주기적으로 확인.

확대해서 보면 더 이상 "에이전트를 실행"하는 것이 아닙니다. 스스로를 조작하지 않고 공동 진화해야 하는 에이전트, 도구, 지표, 정책의 그래프를 운영하는 것입니다.

Eigent의 역할

Eigent는 오픈소스 Cowork 데스크톱 앱으로, 실제 워크플로우를 사용자의 컴퓨터에서 실행하는 멀티 에이전트 AI 워크포스입니다. 단일 에이전트 플로우에서도 작업 그래프의 구성 요소는 이미 보입니다: 작업은 별개의 툴킷(파일, 터미널, 스크린샷, 할 일)을 가진 단계로 분해되고, 실행 컨텍스트는 작업이 사용한 기술, MCP, 참조 파일을 추적하며, 에이전트 폴더는 생성된 아티팩트를 표면화합니다. 이것이 바로 구조화된 작업 기록입니다 — 노드(도구, 기술, 파일, 하위 작업)와 엣지(어떤 도구가 어떤 아티팩트를 만들었고, 어떤 아티팩트가 어떤 단계에 공급되었는지).

Eigent의 **워크포스 모드(workforce mode)**는 이를 장기 작업으로 확장하며, 여기서 단일 루프 사고는 명확히 충분하지 않습니다: 몇 주에 걸쳐 상호 연결된 프로젝트에서 여러 에이전트, 많은 손을 거쳐 진화하는 공유 아티팩트, 비즈니스가 학습함에 따라 변화하는 우선순위. 작업 그래프 위에 그래프 엔지니어링이 요구하는 더 느린 조율 루프를 레이어로 추가할 수 있습니다 — 각 에이전트-작업 쌍을 자체 로컬 지표를 가진 노드로 처리하고, 공유 아티팩트와 결과를 통해 노드를 연결하고, 그래프를 순회하여 굿하트 스타일의 동작(갱신율이 떨어지는 동안 티켓을 "해결"하는 에이전트 무리)을 발견하는 감독 패스를 추가합니다.

솔직한 표현으로: 플랫폼은 캔버스를 제공합니다 — 에이전트, 워크스페이스, 실행 컨텍스트, 워크포스 모드. 그래프 엔지니어링은 그 캔버스에서 실행되는 루프가 조직을 진정으로 더 나아지게 하는지, 아니면 단지 대시보드에서 더 녹색으로 만드는지를 결정하는 규율입니다.

그래프 엔지니어링이 지금 중요한 이유

세 가지 힘이 수렴하여 이것을 학문적인 것이 아닌 긴급한 것으로 만들고 있습니다:

1. 에이전트는 실제 작업을 신뢰받고 있습니다 — 프로덕션 시스템, 법률 워크플로우, 고객 커뮤니케이션, 금융 데이터 — 장난감 코파일럿이 아닙니다.
2. 최적화가 공격적으로 변하고 있습니다. 자동 튜너, RL 파인튜닝, 자동화된 프롬프트 및 전략 검색은 어떤 인간 팀보다 더 강하고 빠르게 주어진 지표를 추구합니다.
3. 작업은 기본적으로 그래프 형태입니다. 파일, API, 도구, 데이터셋, 팀은 이미 밀도 있게 상호 연결되어 있으며, 유능한 에이전트 플랫폼은 암묵적으로 작업과 영향력의 그래프를 구축하고 있습니다.

그런 세계에서 진짜 질문은 "루프냐 그래프냐?"가 아닙니다. 에이전트를 설계하는 것만큼 신중하게 개선 그래프를 설계할 것인지, 그리고 그것이 자기 일관적이고 근거 없는 대시보드의 원이 되도록 내버려 두는 대신 현실에 고정할 것인지입니다.

자주 묻는 질문

AI 에이전트를 위한 그래프 엔지니어링이란 무엇인가요?

그래프 엔지니어링은 지표, 평가, 감사, 정책, 워크플로우 등 피드백 루프의 네트워크를 설계하는 실천으로, 각 루프가 현실과 멀어지는 대신 서로를 감시하고, 제약하고, 수정하도록 합니다. 단일 루프를 독립적인 시스템이 아닌 더 크고 관리되는 토폴로지의 하나의 노드로 취급합니다.

그래프 엔지니어링은 루프 엔지니어링과 어떻게 다른가요?

루프 엔지니어링은 단일 에이전트의 동작을 프로그래밍 가능하게 만듭니다: 행동, 관찰, 추론, 반복의 하나의 반복 사이클. 그래프 엔지니어링은 그 위의 다음 레이어입니다 — 루프와 에이전트의 전체 조직을 프로그래밍 가능하게 만들어, 어떤 루프가 어떤 다른 루프를 공급하고, 소유하고, 모니터링하고, 거부할 수 있는지, 그리고 어떤 주기로 그렇게 하는지를 정의합니다.

단일 피드백 루프가 규모 확장 시 왜 실패하나요?

네 가지 구조적 실패: 굿하트의 법칙(지표가 강하게 밀어붙여질 때 목표에서 분리됨), 상향 맹목성(루프가 자신의 목표를 의심할 수 없음), 루프 간 충돌(독립적인 루프들이 공유 리소스를 두고 싸움), 측정 부식(루프가 오래된 데이터로 계속 실행되는 동안 센서가 표류함). 이것들은 토폴로지 문제이므로 토폴로지 수정이 필요합니다.

루프 그래프에서 앵커란 무엇인가요?

앵커는 최적화 기계가 재작성하는 것이 금지된 외부 고정 기준입니다 — 홀드아웃 평가 세트, 입금된 수익, 물리적 재고, 고정된 안전 사양, 또는 "더 나은"이 무엇을 의미하는지에 대한 인간의 판단. 앵커는 그래프에 값을 공급하지만 그 역학에 종속되지 않으며, 이것이 전체 시스템을 자기 참조적이 아닌 접지된 상태로 유지합니다.

그래프 엔지니어링을 하려면 특별한 프레임워크가 필요한가요?

특정 프레임워크가 필요한 것은 아니지만, 에이전트 실행을 검사 가능한 상태로 노출하는 기반이 필요합니다: 관찰하고 관리할 수 있는 노드, 엣지, 아티팩트, 지표. 실행 컨텍스트와 공유 아티팩트를 기록하는 상태 저장 그래프 런타임과 멀티 에이전트 워크스페이스가 원자재를 제공하며, 규율은 그 위에 루프를 어떻게 연결하는지에 있습니다.

나만의 작업 그래프 구축하기

그래프 엔지니어링은 에이전트가 실제로 하는 일의 구조화된 기록에서 시작됩니다 — 호출하는 도구, 생성하는 아티팩트, 이동시키는 지표. Eigent는 로컬에서 실행되는 오픈소스 멀티 에이전트 워크포스로서 그 기반을 제공하며, 장기적이고 상호 연결된 작업을 위해 구축된 실행 컨텍스트와 워크포스 모드를 갖추고 있습니다. 에이전트가 시간이 지남에 따라 어떻게 스스로를 개선하는지 생각하고 있다면, 자기 진화 에이전트에 대한 심층 분석과 함께 이 글을 읽어보고, Eigent를 다운로드하여 서로를 정직하게 유지하는 루프를 연결하기 시작하세요.