그래서 요즘 팀들이 보는 방향은 “대화를 더 오래 저장하자”보다 에이전트 실행을 그래프로 추적하자에 가깝습니다. 저는 이 흐름을 Action Lineage Graph라고 보는 게 가장 정확하다고 생각합니다. 핵심은 채팅 로그를 더 쌓는 것이 아니라, 입력, 승인, 도구 호출, 파일 변경, 검증, 배포 후보까지를 원인과 결과 체인으로 연결하는 것입니다.

이 흐름은 이미 AI 에이전트 관측/통제, Harness Engineering, Test Evidence Pipeline, Stateful Sandbox Snapshot의 다음 단계처럼 보입니다. 이제 질문은 “무슨 말을 했는가”보다 어떤 실행 경로를 거쳐 어떤 결과가 나왔는가로 옮겨가고 있습니다.

이 글에서 얻는 것

• 왜 채팅 로그 중심 운영만으로는 에이전트 품질과 책임 경계를 설명하기 어려운지 이해할 수 있습니다.
• action lineage graph에 어떤 노드와 엣지가 있어야 실무 가치가 생기는지 기준을 잡을 수 있습니다.
• span coverage, root-cause time, handoff 성공률 같은 숫자를 어떻게 운영 기준으로 둘지 정리할 수 있습니다.

핵심 개념/이슈

1) 채팅 로그는 풍부하지만, 운영 질문에 답하기엔 너무 납작하다

운영에서 진짜 궁금한 건 대개 이런 것들입니다.

• 이 변경은 어떤 승인 단계를 거쳤는가?
• 어떤 파일 변경이 어떤 도구 호출에서 나왔는가?
• 실패 원인이 모델 판단인지, 도구 오류인지, 환경 드리프트인지?
• 이 테스트 결과는 현재 작업공간 상태와 정확히 연결되는가?
• 같은 문제가 다시 나면 어디서 되감아야 하는가?

순수 대화 로그는 맥락 서술에는 좋지만, 이런 질문에 빠르게 답하기 어렵습니다. 사람이 길게 읽어 해석해야 하고, 도구 실행과 산출물의 인과관계가 중간에 끊기기 쉽습니다. 그래서 최근에는 Schema-Constrained Output + Runtime Validator처럼 자유 서술을 계약 구조로 바꾸려는 흐름이 커졌고, 그 다음 자연스러운 단계가 실행 그래프화입니다.

2) action lineage는 프롬프트 추적이 아니라 ‘실행 DAG’에 가깝다

좋은 lineage graph는 최소 아래 노드가 연결돼야 합니다.

1. intent node: 사용자 요청, 티켓, 시스템 이벤트
2. decision node: 승격, 승인, 정책 차단, 재시도 판단
3. action node: 도구 호출, 셸 명령, API 호출, 브라우저 액션
4. artifact node: 생성 파일, diff, 문서, 테스트 로그, 스냅샷
5. evidence node: 검증 결과, 평가 점수, 리뷰 코멘트, 배포 신호

중요한 건 “무엇을 했다”보다 무엇 때문에 그 행동을 했고, 어떤 결과가 뒤따랐는지를 엣지로 남기는 것입니다. 예를 들어 approve -> tool_call -> file_diff -> test_pass -> handoff 같은 체인이 보여야 사람이 5분 안에 상태를 이해할 수 있습니다. 이 구조는 Test Evidence Pipeline과 거의 붙어 다닙니다.

3) 팀은 긴 대화보다 짧은 원인 추적 시간을 원한다

실무에서 에이전트 운영의 진짜 비용은 토큰보다도 사람이 다시 이해하는 시간입니다. 이전 실행을 읽고 재구성하는 데 25분 걸리면, 모델이 3초 빨라진 이득은 거의 사라집니다. 반대로 lineage graph가 잘 잡혀 있으면 온콜, 리뷰어, 다음 실행자 모두가 빠르게 현재 위치를 파악할 수 있습니다.

그래서 좋은 팀은 로그 보존량보다 아래를 먼저 봅니다.

• 사람이 실패 원인을 찾는 평균 시간
• handoff 이후 추가 질문이 몇 번 나오는지
• 어떤 변경이 어떤 증거에 의해 검증됐는지 바로 열리는지
• 동일 이슈 재현 시 어느 노드부터 replay 가능한지

즉 action lineage는 관측성 기능이면서 동시에 협업 압축 도구입니다.

4) lineage graph는 observability, sandbox, validator가 같이 있어야 완성된다

Action lineage만 따로 붙인다고 해결되지는 않습니다. 그래프가 실무에서 힘을 가지려면 세 가지가 같이 붙어야 합니다.

• 관측성: 어떤 실행이 있었는지 span 단위로 남아야 한다.
• 검증성: 그 산출물이 통과한 체크가 구조화돼 있어야 한다.
• 재현성: 같은 상태를 다시 열 수 있는 snapshot이나 replay 힌트가 있어야 한다.

그래서 최근 흐름들이 서로 이어집니다. AI 에이전트 관측/통제가 기반 계측을 깔고, Harness Engineering이 실행 프레임을 고정하고, Stateful Sandbox Snapshot이 작업공간 복원을 담당하고, lineage graph가 이들을 하나의 인과 지도로 묶는 구조입니다.

5) 그래프가 강해질수록 프라이버시와 책임 경계 설계가 더 중요해진다

모든 것을 연결하면 좋아 보이지만, 무차별 수집은 금방 독이 됩니다. 프롬프트 원문, 민감 파일 경로, 개인 데이터, 승인 메모까지 전부 장기 보존하면 운영성보다 위험이 커집니다.

그래서 실무 원칙은 대체로 이렇습니다.

• 민감 원문은 전부 보존하지 않고 참조/해시/요약으로 분리한다.
• 사람 메모와 시스템 증적의 보존 기간을 다르게 둔다.
• lineage 열람 권한은 실행 권한보다 좁게 가져간다.
• 정책 차단, 승인, 배포 같은 고위험 노드만 장기 보존 강도를 높인다.
• 파일 diff 전체보다 핵심 산출물 메타데이터를 우선 연결한다.

즉 좋은 lineage는 “다 저장”이 아니라 책임 추적에 필요한 최소 연결을 정교하게 남기는 일에 가깝습니다.

실무 적용

1) 최소 action lineage 스키마

처음부터 거대한 그래프 DB가 필요하지는 않습니다. 아래 8개만 있어도 운영 가치가 생깁니다.

• run_id
• parent_intent_id
• decision_type (승격, 승인, 차단, 재시도)
• action_type (tool, shell, browser, api)
• artifact_ref (파일, diff, 로그, snapshot)
• validation_ref (test, lint, eval, review)
• status (started, passed, failed, canceled)
• timestamp + actor

핵심은 각 노드가 따로 존재하는 게 아니라, 바로 이전 이유와 다음 결과를 잇는 링크가 보이는 것입니다.

2) 의사결정 기준(숫자·조건·우선순위)

운영 기준은 아래 정도로 시작하면 현실적입니다.

• span_coverage: 핵심 작업의 95% 이상이 lineage에 연결될 것
• artifact_link_rate: 파일 변경의 90% 이상이 생성 원인 노드와 연결될 것
• human_root_cause_time_p50: 15분 이하
• handoff_question_rate: handoff 1건당 추가 질문 1회 이하
• replay_start_identification_time: 실패 후 되감기 시작점 찾는 시간 5분 이하
• sensitive_raw_retention: 0 또는 최소화

우선순위는 원인 추적 가능성 > 민감정보 최소화 > 검증 연결성 > 시각화 화려함 순으로 두는 편이 좋습니다. 예쁜 그래프보다 빠른 사고 분석이 먼저입니다.

3) 어떤 팀부터 효과가 큰가

특히 아래 환경에서 효과가 큽니다.

여러 에이전트/여러 도구를 섞는 팀
하나의 결과가 여러 실행 단계를 거쳐 나오는 경우

코드 리뷰 전 증거 묶음이 필요한 팀
누가 왜 이 변경을 신뢰해야 하는지 빠르게 보여줘야 하는 경우

장시간 handoff가 잦은 팀
주간/야간, 사람/에이전트 사이에 자주 이어받는 경우

운영 승인 단계가 있는 팀
자동 실행과 인간 승인 경계가 중요한 경우

반대로 개인 취미 프로젝트, 짧은 read-only 조사, 임시 요약 작업에는 과할 수 있습니다.

4) 4주 도입 플랜

1주차: 이벤트 분해
현재 실행 로그를 intent, decision, action, artifact, evidence 다섯 종류로 나눕니다.

2주차: 핵심 경로 1개 연결
예를 들어 “요청 수신 → 코드 수정 → 테스트 → handoff” 한 경로만 lineage로 묶습니다.

3주차: root-cause 측정
문제 5건을 골라, 기존 방식과 lineage 방식의 원인 파악 시간을 비교합니다.

4주차: 민감정보/권한 정책 고정
어떤 노드를 원문 저장하고 어떤 노드는 참조만 남길지 룰을 문서화합니다.

이 순서가 좋은 이유는 시각화 툴부터 고르지 않고, 실제 질문에 답할 수 있는 연결 구조를 먼저 만들기 때문입니다.

트레이드오프/주의점

1. 다 연결한다고 다 좋은 건 아니다.
   노이즈 노드가 너무 많으면 사람은 다시 로그 사막으로 돌아갑니다.

2. 원인과 상관만 구분해야 한다.
   같은 시점에 일어났다고 모두 인과관계는 아닙니다. 승인, 실행, 산출물 링크를 엄격히 정의해야 합니다.

3. 민감정보가 섞이기 쉽다.
   lineage는 운영 증적이기 때문에 오히려 더 오래 남을 수 있습니다. 보존 정책이 필수입니다.

4. 그래프만 있고 replay가 없으면 반쪽이다.
   어디서 실패했는지 알아도 그 상태를 다시 못 열면 운영 가치가 크게 줄어듭니다.

체크리스트 또는 연습

체크리스트

• intent, decision, action, artifact, evidence 노드가 구분돼 있다.
• 파일 변경과 테스트 결과가 같은 lineage 체인으로 연결된다.
• 민감 원문과 참조 메타데이터의 보존 정책이 다르다.
• root-cause time과 handoff 질문률을 측정한다.
• replay 시작점이 그래프에서 5분 안에 식별된다.

연습 과제

1. 최근 에이전트 작업 1건을 골라, 실제로 남아 있는 로그를 intent, decision, action, artifact, evidence로 다시 분류해 보세요.
2. 그 작업에서 사람이 다음 실행자에게 설명하느라 쓴 시간을 적고, lineage graph가 있다면 어떤 링크 3개가 가장 시간을 줄였을지 써 보세요.
3. 민감한 작업 하나를 골라 원문 저장이 필요한 노드와 해시/요약만 남겨도 되는 노드를 분리해 보세요.

관련 글

• AI 에이전트 관측/통제 트렌드
• Harness Engineering
• Test Evidence Pipeline
• Stateful Sandbox Snapshot
• Schema-Constrained Output + Runtime Validator