Data Eng Wiki

Agent Harness vs Loop vs Graph Engineering

17 min read

Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering

Author: @beamnxw | Source: X (Twitter) thread | Published: 2026-07-25

한 줄 요약

세 용어가 같은 모델 주위에 있고 모두 “loop”를 포함할 수 있어 혼동되지만, 환경 → 피드백 → 흐름이라는 서로 다른 엔지니어링 결정을 기술하며 실패 증상으로 어느 레이어를 손볼지 진단할 수 있다.

핵심 주장/내용

  • 30초 답:
    • Harness engineering — 모델 주위의 기계장치를 만든다
    • Loop engineering — 반복되는 작업-피드백 사이클을 설계한다
    • Graph engineering — 워크플로 토폴로지를 명시적으로 만든다: 노드, 분기, join, 상태 전이, 통제된 사이클
    • 깔끔한 멘탈 모델은 environment → feedback → flow
  • 왜 지금 중요한가: 원시 언어 모델은 프로젝트 상태를 유지하거나, 테스트 스위트를 돌리거나, 브라우저를 보거나, 승인 규칙을 강제하거나, 실패한 잡을 재시작할 수 없다. 그 능력은 모델이 있는 환경에서 온다. 에이전틱 소프트웨어가 성숙하며 표준 스택이 모이고 있다 — 기저에 모델을 실제로 돌리는 코드인 agent harness, 그 다음 반복 실행과 품질 체크를 다루는 loop, 마지막으로 전체 과정을 안내하는 구조화된 경로를 그리는 graph
  • Agent Harness Engineering: LangChain 정의로 agent = 모델 + harness이고 harness는 모델 밖의 코드·설정·실행 로직이다. 시스템 프롬프트, 툴 정의, 메모리, 파일시스템, 샌드박스, 모델 라우팅, handoff, 미들웨어 hook, compaction, 권한, 로깅, 검증 인터페이스
    • “harness”라는 단어가 유용한 이유는 모델 숭배에서 주의를 돌리기 때문이다. 두 팀이 같은 foundation 모델을 쓰고도 아주 다른 결과를 얻는 이유는 한쪽이 깨끗한 툴, 안정적 워크스페이스, 제약된 권한, 관측 가능한 상태를 주고 다른 쪽은 모호한 프롬프트와 불안정한 API 래퍼를 주기 때문이다. 지능은 비슷할지 몰라도 작업 조건은 아니다
    • 진지한 harness가 담는 것: context injection(지시, 검색된 사실, 대화 상태, skill, 태스크별 정책), action surface(API, 브라우저, 셸, 코드 인터프리터, DB, MCP 호환 툴), persistence(파일, 체크포인트, 세션, 진행 로그, git 히스토리, 장기 메모리), execution control(타임아웃, 재시도, 예산, 모델 라우팅, 서브에이전트 스폰, 승인 게이트), safety·governance(권한, 격리, allow list, secret 처리, 사람 인가), observability(trace, 툴 입출력, 상태 전이, 비용, 레이턴시, 평가 결과)
    • 아키텍처 다이어그램에서 모델을 지워보라. 남은 것이 대부분 harness다
    • 언제 harness 작업이 값어치를 하나: 장기 실행 태스크. 멀티세션 코딩에서 Anthropic은 단순히 context compaction을 쓰는 것으로는 불충분함을 발견했고, 더 나은 프롬프트가 아니라 initializer·progress 파일·git 히스토리·점진적 작업의 규율을 만들어 새 컨텍스트마다 무슨 일이 있었고 무엇이 남았는지 이해할 수 있게 했다. 에이전트에 능력이 없거나, 깨끗하게 돌아올 수 없거나, 상태를 잃거나, 너무 많이 접근하거나, 감사가 안 되거나, 환경마다 다르게 행동할 때 harness 엔지니어링을 적용하라
  • Loop Engineering: 툴을 쓰는 모든 에이전트에 이미 작은 루프가 내장되어 있다(모델 호출 → 결과 확인 → 툴 실행 → 관측을 모델에 입력 → 최종 답까지 반복). 빌더가 그 행동 주위에 의도적으로 새 사이클을 짓거나 쌓기 시작하면 loop engineering이다. 검증 루프는 에이전트가 아티팩트를 만들고 결정론적 체크나 grader를 실행하고 명시적 피드백을 받아 증거상 에러가 있을 때만 반복하게 한다. event-driven 루프는 스케줄·webhook·새 문서로 에이전트를 깨운다. improvement 루프는 trace와 실패를 분석해 지시·툴을 수정하고 새 버전이 더 나은지 테스트한다. “하나의 마법 while문”이 아니라 루프의 스택
    • 잘 설계된 루프의 해부: Trigger(다음 사이클을 무엇이 시작하나 — 사용자 요청, 스케줄, 실패한 테스트, 새 데이터, evaluator 피드백), Goal(도달할 구체적 상태이지 “계속 개선하라”는 모호한 지시가 아님), State/memory(모든 걸 replay하지 않고 다음 사이클이 알아야 할 것), Action policy(에이전트가 무엇을 바꾸고 호출하고 위임하고 지출할 수 있나), Evidence(테스트, 스키마 검증, 인용, diff, 지표, 사람 리뷰), Feedback(증거가 왜 실패했는지에 대한 compact하고 실행 가능한 기술), Stopping rule(성공, 예산 한도, 타임아웃, 복구 불가 에러, 사람 escalation)
    • 확신에 대해 루프를 돌리지 말고 증거에 대해 루프를 돌려라. “에이전트가 끝났다고 말한다”는 정지 조건이 아니고 “테스트가 통과하고, 링크가 해소되고, 스키마가 검증되고, 리뷰어가 승인했다” 가 정지 조건이다
    • 왜 프롬프트 엔지니어링이 아닌가: 프롬프트는 호출 중에 모델이 무엇을 할지 말하고, 루프는 호출 후에 시스템이 무엇을 할지 — 결과를 어떻게 관측하고, 피드백을 어떻게 고르고, 계속할지 결정하고, 진행을 영속화하고, 종료하는지 — 를 명시한다. 루프가 일회성 지시를 관리되는 프로세스로 바꾼다. 주 트레이드오프는 비용과 레이턴시로, 모든 grader·리뷰어·재시도가 모델 호출이나 툴 실행을 더한다. 실패 비용이 검증 비용보다 큰 곳에 루프를 추가하라
  • Graph Engineering: 다른 질문을 한다 — 에이전트가 무엇을 하는가가 아니라 어떤 컴포넌트가 다음에 실행되도록 허용되는가. 노드가 단계를, 엣지가 허용된 단계를 나타내고 순서·조건 분기·병렬 fan-out·join·루프·사람 interrupt를 표현할 수 있다. 상태가 그래프를 순회하고 토폴로지가 원하는 제어 흐름을 검사 가능하게 만든다
    • graph 엔지니어가 실제로 결정하는 것: 노드 경계(어떤 작업이 결정론적 함수, LLM 호출, 전문 에이전트, 사람 리뷰 단계에 속하나), state 스키마(각 노드가 무엇을 읽고 갱신할 수 있고 병렬 갱신을 어떻게 병합하나), 라우팅 조건(어떤 증거가 작업을 앞·뒤·옆으로 보내거나 escalate하나), 동시성(무엇이 병렬 실행 가능하고 무엇이 join되어야 하고 어떤 공유 리소스에 조율이 필요한가), 사이클과 exit(재시도가 어디서 legal하고 몇 번 허용되고 무엇이 사이클을 안전하게 하나), durability(체크포인트가 어디서 일어나고 중단 후 실행이 어떻게 재개되나)
    • 워크플로 그래프는 지식 그래프 엔지니어링과 다르다 — 지식 그래프는 데이터의 엔티티·관계를 나타내고 워크플로 그래프는 제어와 상태 전이를 나타낸다
    • 언제 그래프가 ceremony 값을 하나: 프로세스에 의미 있는 분기, 병렬 작업, 승인, 복구 경로, 여러 전문 에이전트가 있을 때. “에이전트 하나에 툴 셋 주고 일하게 두면 되는” 작업에는 덜 유용하다. 그래프는 디버깅을 개선할 수 있지만 가정을 너무 일찍 얼려버릴 수도 있다 — 모델이 계획을 동적으로 발명해야 한다면 가능한 모든 경로를 다이어그램에 강제하는 것이 시스템을 덜이 아니라 더 취약하게 만든다
  • 세 레이어의 중첩: 그래프가 harness 안에서 돌고, 하나 이상의 루프가 그래프 안에 살고, harness가 그 루프들이 필요로 하는 상태·툴·evaluator를 공급한다. 소프트웨어 레이어가 겹치므로 범주도 겹치지만 각각이 시스템이 실패할 때 당길 다른 레버를 준다
  • 실패 증상으로 레이어 진단하기:
증상시작할 곳유력한 수정
에이전트가 올바른 데이터·툴에 안전하게 접근할 수 없다Harness툴 계약, 권한, 샌드박스, context injection
세션 간 진행을 잊는다Harnessdurable 상태, 체크포인팅, 진행 아티팩트, compaction
첫 시도가 종종 근접하지만 신뢰할 수 없다Loop외부 grader, 결정론적 테스트, 피드백, bounded 재시도
성공 후에도 계속 일하거나 증명 전에 멈춘다Loop증거 기반 terminal state, 예산 인지 정지 규칙
여러 전문가가 통제된 순서로 실행되어야 한다Graph명시적 노드·엣지·라우팅 조건·join
다단계 프로세스에서 실패 위치를 찾기 어렵다Graph + harness그래프 노드·전이와 정렬된 stateful trace
워크플로가 고정 다이어그램에 비해 너무 자주 바뀐다더 단순한 harness제어를 모델 주도로 유지하고 그래프 형식화를 미뤄라
  • 약한 에이전트 아키텍처 뒤의 비싼 실수들:
    • 작업을 이해하기 전에 그래프를 만드는 것 — 유능한 에이전트가 실제로 그것을 어떻게 푸는지 관찰하기도 전에 비즈니스 프로세스를 수십 개 노드로 번역한다. 더 단순한 harness의 trace에서 시작해 안정적인 경로를 형식화하라
    • 같은 모델이 안전장치 없이 쓰고 채점하게 두는 것 — 자기 리뷰가 도움이 될 수 있지만 공유된 맹점에 취약하다. 가능한 곳에 결정론적 체크를 선호하고, 리뷰어 컨텍스트를 분리하고, 고임팩트 행동에는 사람 승인을 요구하라
    • “계속 시도하라”를 루프 명세로 쓰는 것 — bounded되지 않은 재시도 루프는 비용 누수다. 모든 루프에 측정 가능한 목표, 새로운 증거, 최대 시도 횟수, 이름 붙은 escalation 경로가 필요하다
    • harness를 잡동사니 창고로 취급하는 것 — 툴과 메모리가 많다고 자동으로 낫지 않다. 붐비는 툴셋은 선택 에러를, 노이즈 많은 컨텍스트는 혼동을, 넓은 권한은 리스크를 올린다
    • 오케스트레이션 실패를 모델 탓으로 돌리는 것 — 모델은 stale 상태, 모호한 툴 스키마, 깨진 API, 빠진 exit 조건을 신뢰성 있게 보상할 수 없다. 실패를 소유한 레이어를 개선하라
  • 프로덕션 준비 설계 체크리스트: Harness — 툴이 좁고 문서화되고 관측 가능한가? 상태가 durable한가? 권한이 least-privilege인가? 운영자가 실행을 일시정지·검사·재개할 수 있나? / Loop — 무슨 증거가 성공을 증명하나? 실패 시 무슨 피드백이 반환되나? 몇 번의 재시도가 허용되나? 예산이 고갈되면 무슨 일이 일어나나? / Graph — 어떤 경로가 결정론적이어야 하나? 무엇이 병렬로 돌 수 있나? 어떤 상태가 공유되나? 사람 게이트와 복구 경로가 어디 있나? / Evaluation — 팀이 실제 trace를 replay하고 버전을 비교하고 직관이 아니라 특정 변경에 개선을 귀속시킬 수 있나? / Operations — 비용·레이턴시·실패율·개입률·태스크 레벨 성공이 프로덕션에서 모니터링되나?
  • 셋 중 어느 것도 다른 것을 대체하지 않는다. harness가 상태를 잃었다면 아름답게 그려진 그래프도 충분하지 않고, 최고의 harness가 있어도 증거나 정지 규칙이 없으면 돈 낭비이며, 세심하게 만든 루프도 분기·병렬·승인이 임시 코드에 박혀 있으면 운영하기 어렵다. 세 레이어를 함께 설계하고 각 레이어가 무엇을 풀어야 하는지 팀이 알 때 신뢰할 만한 에이전트 시스템이 나온다

관련 위키

Source: 원문 보기

그래프 뷰

백링크