← 전체 목차 · 이전: Agent 아키텍처: 실행 Agent에게는 거부권이 있어야 한다 · 다음: Agent 월권 경계 — 안전 샌드박스는 무엇을 가두는가
흔한 오답은 이것이다: "완료된 단계를 새 목표와 하나씩 의미 유사도로 채점하고, 임계값 미만이면 폐기 표시한다."
이 방식은 파라미터 변경 시나리오에서 완전히 무너진다. 사용자가 일별 매출 리포트를 주별로 바꿨다고 하자. 일 단위로 집계된 12장의 중간 테이블은 의미상으로는 새 목표와 완전히 똑같아서 전부 만점 통과하지만, 수치 층위에서는 이미 전부 틀렸다.
핵심은 Agent의 상태 관리 안에서 "단계의 의미 관련도"와 "데이터 산출물의 유효성"을 완전히 다른 두 차원으로 취급했는가이다.
정답은 이렇다. Agent는 **단계 의존의 유향 비순환 그래프(DAG)**를 유지하고, 각 단계는 계획 단계에서 "입력 파라미터"와 "산출 데이터 입도" 두 개의 구조화 태그를 선언한다. 목표가 바뀌면 재채점이 아니라 변경을 DAG 위의 파라미터 변경 이벤트로 매핑해 루트 노드부터 너비 우선 순회하며, 산출 입도가 새 파라미터와 불일치하는 노드와 그 모든 하류를 정확히 폐기 표시한다.
| 차원 | 묻는 질문 | 판단 근거 |
|---|---|---|
| 단계의 의미 관련도 | 이 단계가 새 목표와 관련 있는가? | 자연어 의미 매칭 |
| 데이터 산출물의 유효성 | 이 단계가 산출한 데이터가 수치상 아직 쓸 수 있는가? | 산출 데이터 입도가 새 파라미터와 일치하는가 |
의미 관련도가 높다고 데이터가 유효한 것은 아니다.
사용자가 "일별 매출 리포트를 주별로 바꿔줘"라고 한다. Agent는 이미 12단계를 완료했다 — 일별 주문 금액 집계, 일별 객단가 계산, 일별 카테고리 반품률, 일별 재구매율 등.
Agent가 각 중간 테이블에 의미 매칭만 한다면 스스로에게 이렇게 묻는다: "이 테이블은 매출액에 관한 것인가? 집계 데이터인가? 사용자의 새 목표와 관련 있는가?" 결과는 12장 전부 만점 통과다. 의미적으로 "일별 주문 금액 집계" 테이블과 "주별 주문 금액 집계" 테이블은 거의 똑같기 때문이다.
그러나 입도가 일에서 주로 바뀌면 수치 층위에서 전부 틀린다.
Agent가 12장을 "보존 가능"으로 판정하면 주별 리포트의 모든 숫자가 틀린다.
사용자가 최초로 목표를 제시할 때 Agent는 계획 단계에서 각 단계마다 두 개의 구조화 태그를 선언한다.
| 태그 | 예시 내용 |
|---|---|
| 입력 파라미터 | 시간 차원=일 / 통계 지표=주문 금액 / 날짜 범위=2026년 7월 |
| 데이터 산출 입도 | 중간 테이블=일별 매출 집계 / 시간 필드 입도=일 |
이 두 태그는 사람이 읽는 주석이 아니라 기계가 읽는 메타데이터이며 DAG 각 노드의 속성이 된다.
DAG의 간선은 데이터 의존을 나타낸다. 단계 B의 입력이 단계 A의 출력에서 온다면 A가 폐기되면 B도 폐기된다.
사용자가 "주별로 바꿔줘"라고 하면 Agent는 의미 채점을 다시 하지 않고 변경을 DAG 위의 파라미터 변경 이벤트 시간 차원: 일 → 주로 매핑한다.
이 사례에서 폐기 집합 = 일별 중간 테이블 12개 노드 + 이 중간 테이블에 의존하는 집계 단계 3개 노드. 그리고 시간 차원과 무관한 보조 단계 3개(데이터 소스 연결성 검증, 필드 타입 매핑)는 재사용 가능으로 표시된다.
의미 채점으로는 이런 노드 단위 정밀도에 도달할 수 없다.
"전부 폐기하고 처음부터 다시 돌린다"는 논리적으로는 틀리지 않지만 연산 자원을 낭비한다. 폐기 표시와 동시에 한 번 더 지능적 판단을 해야 한다 — 어떤 폐기 노드의 원본 입력 데이터가 아직 남아 있어 재집계로 복구 가능한가.
12장의 일별 집계 테이블은 입도가 틀렸지만, Agent가 두 가지 핵심 자산 — 각 테이블을 생성한 원본 SQL과 하위 상세 데이터 — 를 보존해 두었다면 주문 원본 테이블부터 전 사슬을 다시 돌릴 필요가 없다.
| 경로 | 방법 | 대가 |
|---|---|---|
| 전 사슬 재실행 | 주문 원본 테이블부터 다시 시작 | 1시간 |
| 증분 재구축 | GROUP BY의 시간 입도만 바꿔 재집계 | 5분 |
일에서 주로 바꾸는 것은 본질적으로 GROUP BY의 시간 입도를 바꾸는 일이다. 이 판단을 할 수 있는지가 초급 Agent와 프로덕션급 Agent를 가르는 지점이다.
파라미터 변경을 구조화 표현한다. DAG 각 노드의 파라미터 벡터와 새 목표의 파라미터 벡터를 차원별 Diff한다.
| 적중 상황 | 처리 |
|---|---|
| 시간 차원, 집계 함수, 데이터 소스 세 차원 모두 적중 | 고우선순위 폐기 |
| 한 차원만 적중 | 저우선순위 폐기 |
폐기 우선순위가 다르므로 Agent가 배치를 나눠 재구축할 수 있고, 한꺼번에 전부 폐기하지 않아도 된다.
"사용자가 목표를 바꿀 때마다 Agent가 처음부터 다시 계획한다"는 나쁜 경로다. 재계획은 완료된 모든 중간 결과를 버리는 것이고, 앞의 작업이 전부 헛수고가 된다.
올바른 방법은 차등 재계획이다. 재사용 불가능한 부분만 폐기하고 기존 중간 결과의 재사용 가치를 최대화한다.
시간 차원: 일→주라는 파라미터 변경 이벤트로 번역해야 차원별 Diff가 가능하고, 우선순위를 매길 수 있고, 배치 재구축이 가능하다. 모델에게 "자유재량으로 재채점"을 맡기는 것은 통제 가능성을 포기하는 것이다.입력 파라미터와 데이터 산출 입도는 노드 속성이어야지 사후에 SQL에서 역추론하는 것이면 안 된다. 역추론은 늦기도 하고 신뢰할 수도 없다.GROUP BY 한 번 수정이고, 없으면 주문 원본 테이블부터 전 사슬 재실행이다.