Agent를 평가한다는 말은 너무 좁다

결국 TTL을 다 손보고 있다.

돌이켜보면 이 짓의 시작은 Universal AI Benchmark Platform 연구였다.

그러다 막힌 지점이 여기다.

우리는 Agent를 얼마나 신뢰할 수 있는가? 어떻게 측정할 수 있는가? 그리고 무엇을 측정하려는 것인가?

처음에는 단순하게 생각했다.

Agent에게 일을 시키고, 나온 결과물을 보면 된다고 생각했다. 결과가 좋으면 잘한 것이고, 나쁘면 못한 것이다. 벤치마크라는 것도 결국 입력을 주고 출력을 채점하는 구조라고 생각했다.

그런데 Agentic Workflow를 뜯어보면 이 방식은 금방 막힌다.

Agent는 혼자 결과를 만들지 않는다. 어떤 Prompt를 읽고, 어떤 Policy를 따르고, 어떤 Knowledge Base를 참조하고, 어떤 Ontology 위에서 판단하고, 어떤 Dataset을 소비한다. 때로는 모델이 직접 실행하고, 때로는 다른 시스템에 위임하고, 때로는 사람에게 판단을 넘긴다.

그러니까 "Agent를 평가한다"는 말은 사실 너무 좁다. Agent는 결과를 만든 단일 원인이 아니라, 실행 구조 안에 놓인 하나의 주체다.

우리가 평가해야 하는 것은 Agent 하나가 아니라, Agent가 실행된 전체 구조다.

이 글에서는 그 구조를 WorkflowGraph라고 부르겠다.

WorkflowGraph
=
Consumed Artifact
+
Execution Graph
+
Produced Artifact

이 말이 왜 필요한지 Agentic Workflow부터 보자.

Execution.Type = Task | Decision일 때, Workflow는 Execution들을 Rail로 연결한 그래프다.

(Execution) --Rail--> (Execution)

일반적인 실행 그래프로 보면 이것은 방향이 있는 그래프다. 실행들이 선으로 연결되어 있고, 그 흐름을 따라 일이 진행된다. 흔히 말하는 DAG(Directed Acyclic Graph)류의 실행 그래프와 닮아 있다.

하지만 Agentic AI System에서는 이것만으로 실행 구조를 충분히 설명할 수 없다.

각 Execution은 무엇을 실행하는가뿐 아니라 누가 실행하는가를 함께 가져야 하기 때문이다.

그래서 모든 Execution은 실행 주체를 가진다.

Execution.hasSubject
=
Self | Model | System | OtherWorkflow | Human

예를 들어 하나의 Workflow가 Claude Code나 Codex 같은 단일 실행 환경 안에서 수행된다면, 해당 Execution의 실행 주체는 자기 자신이다. 이 경우에는 외부 주체로 넘기지 않고 현재 실행 환경이 직접 처리한다.

Execution.hasSubject = Self

그러나 Agentic AI System에서는 실행 중간에 실행 주체가 바뀔 수 있다. 이 실행 주체 전환을 hand_off라고 부른다. hand_off는 하나의 Execution이 다른 실행 주체에게 실행 또는 판단을 넘기는 상위 개념이다.

hand_off
├── delegates_to
└── escalates_to

delegates_to는 모델, 시스템, 다른 워크플로처럼 실행 가능한 주체에게 작업이나 판단을 위임하는 관계다. 내가 직접 처리하지 않고, 다른 실행 주체에게 넘기는 것이다.

(Execution)
  --delegates_to-->
    (Execution.hasSubject = Model | System | OtherWorkflow)

반면 escalates_to는 더 높은 판단 권한이 필요하거나 사람이 개입해야 하는 경우, 실행을 Human 주체에게 승격하는 관계다. 대표적인 예가 HITL(Human-in-the-Loop)이다.

(Execution)
  --escalates_to-->
    (Execution.hasSubject = Human)

Execution
  --escalates_to-->
    Execution(hasSubject = Human, Type = Decision)

이 구조에서 중요한 점은 Workflow 자체가 바뀌는 것이 아니라는 점이다.

변경되는 것은 Workflow의 형태가 아니라 각 Execution의 실행 주체(ExecutionSubject)다.

따라서 Agentic Workflow의 핵심 복잡성은 그래프가 복잡하다는 데 있지 않다. 진짜 복잡성은 Execution Graph 위에서 실행 주체가 동적으로 전환되는 hand_off 구조에 있다.

누가 직접 실행하는가. 언제 다른 주체에게 위임하는가. 언제 사람에게 승격하는가.

이것을 표현해야 Agentic Workflow를 설명할 수 있다. 단순히 Task A 다음에 Task B가 온다는 정보만으로는 부족하다. Task A를 누가 했고, Task B는 누구에게 넘어갔으며, 어느 지점에서 사람이 판단했는지를 함께 봐야 한다.

즉 Agentic Workflow는 단순한 실행 순서 그래프가 아니다.

누가 언제 직접 실행하고, 언제 다른 주체에게 위임하며, 언제 사람에게 승격하는지를 표현하는 Control Graph다.

그렇다면 무엇을 측정하고 개선해야 하는가.

Data Supply Chain 관점에서 보면 이 Agentic Workflow는 Artifact Stream으로 다시 읽힌다.

Artifact
  --consumed_by-->
    Execution
      --produces_to-->
        Artifact

하나의 Execution은 Artifact를 소비하고, 다시 Artifact를 생산한다.

이때 소비된 Artifact와 생산된 Artifact 사이에는 근거 관계가 생긴다.

consumed_by o produces_to = evidence_of

다시 말해, 어떤 Artifact가 Execution에 의해 소비되고 그 Execution이 새로운 Artifact를 생산했다면, 앞의 Artifact는 뒤의 Artifact에 대한 evidence_of 관계를 갖는다.

여기까지 오면 측정 구조도 처음과 다르게 보인다. 처음에는 평가란 Workflow가 생산한 결과물만 측정하는 일이라고 생각했다.

예를 들면 이런 구조다.

(Workflow)
  --produces_to-->
    (Artifact)
      --measured_by-->
        (Execution.Type = Eval)

Workflow가 Artifact를 만들고, Eval Execution이 그 Artifact를 측정한다. 여기까지만 보면 평가 대상은 최종 산출물처럼 보인다.

문제는 이전에 정의한 Workflow가 다음과 같았다는 점이다.

Workflow = oneOf(Execution.Type = Task | Decision)

즉 Workflow는 Task와 Decision으로 구성된 실행 그래프라고 보았다. 하지만 이 정의에는 가장 중요한 것이 빠져 있었다.

바로 Workflow가 소비하는 Artifact다.

(Artifact)
  --consumed_by-->
    (Workflow)

여기서 소비되는 Artifact가 Low Trust Data라면 Workflow가 아무리 정교해도 결과는 흔들릴 수밖에 없다.

결국 익숙한 문장으로 돌아온다.

Garbage In, Garbage Out.

다만 Agentic Workflow에서의 Garbage는 단순한 입력 오류가 아니다.

신뢰할 수 없는 Prompt. 낡은 Ontology. 검증되지 않은 Knowledge Base. 불완전한 Policy. 품질이 낮은 Dataset.

이 모든 것이 Garbage가 될 수 있다.

결국 출력이 이상할 때, 원인은 Agent의 추론 능력만이 아닐 수 있다. Agent가 소비한 Artifact가 이미 낮은 신뢰도를 갖고 있었을 수 있다. 또는 Workflow 중간에서 잘못된 주체에게 위임했을 수도 있다. 또는 사람이 개입해야 할 판단을 모델에게 그대로 맡겼을 수도 있다.

따라서 Agent를 평가한다는 것은 Agent의 출력만 평가하는 일이 아니다.

Agentic Workflow가 무엇을 소비했고(Consumed Artifact), 누가 실행했으며(Execution), 무엇을 생산했고(Produced Artifact), 그 결과물이 무엇의 근거가 되는지(Evidence)까지를 하나의 단위로 평가하는 일이다.

즉 평가 대상은 개별 Output이 아니라 Workflow Graph 전체다.

WorkflowGraph
=
Consumed Artifact
+
Execution Graph
+
Produced Artifact

그리고 Evaluation은 이 WorkflowGraph 전체를 대상으로 다양한 목적 함수를 측정한다.

Evaluation
  --measures-->
    WorkflowGraph

Metrics
├── Trust
├── Quality
├── Cost
├── Speed
├── Safety
├── Robustness
└── Resource Usage

이렇게 보면 Evaluation의 의미가 바뀐다.

Evaluation은 단순히 "정답을 맞혔는가?"를 묻는 절차가 아니다. WorkflowGraph가 신뢰할 수 있는 입력을 소비했는가, 적절한 실행 주체가 실행했는가, 산출물이 충분한 품질을 갖는가, 비용과 속도는 합리적인가, 안전성과 강건성은 확보되는가를 함께 측정하는 일이다.

Agent를 평가하는 것이 아니다.

WorkflowGraph라는 실행 단위를 다목적으로 평가하고 개선하는 것.

이것이 Agentic Workflow에서 평가(Evaluation)의 실제 대상이다.

그래서 Repository를 다시 보게 된다.

Repository는 파일을 저장하는 곳이 아니다. 적어도 Agentic Workflow를 운영하는 Repository는 그렇게 보면 부족하다.

Repository는 실행과 산출물의 관계를 저장하는 그래프다. 어떤 Artifact가 소비됐고, 어떤 Execution이 그것을 읽었고, 누가 실행했고, 무엇을 생산했고, 그 산출물이 무엇의 근거가 되었는지를 남기는 그래프다.

이 관점에서 Repository는 단순한 폴더가 아니라, 신뢰와 품질을 계산하기 위한 실행 단위의 기억 장치가 된다.

첫 번째 결론은 이것이다.

Agent를 평가하려면 Agent만 보면 안 된다.

Agent가 놓여 있던 WorkflowGraph 전체를 봐야 한다.