OpenAI와 Ironclad: 계약 워크플로우를 에이전트 평가(Agent Evals)로 전환하기

OpenAI와 Ironclad는 실제 운영 중인 계약 워크플로우를 컴퓨터 사용 에이전트의 훈련 데이터이자 평가 기준(evaluation benchmarks)으로 활용하는 사례 연구를 발표했습니다. 이것은 시연이 아닙니다. SaaS 기업이 자체 워크플로우 엔진을 에이전트 훈련장으로 개방하는 파트너십입니다.

근본적인 질문은 간단합니다. 다단계 계약 승인 흐름(multi-step contract approval flow)을 고객 데이터가 유출되지 않는 재현 가능한 평가 환경으로 어떻게 전환할 것인가, 그리고 기반 제품이 변경될 때 이 평가 환경의 유효성을 어떻게 유지할 것인가입니다?

계약 워크플로우가 에이전트 평가에 중요한 이유

대부분의 컴퓨터 사용 벤치마크는 합성(synthetic)적입니다. 이는 통제된 환경에서 브라우저 작업이나 API 호출을 시뮬레이션합니다. Ironclad의 계약 수명 주기 관리 플랫폼은 다른 것을 제공합니다: 승인 체인, 수정 표시(redlining), 협상 루프, 조건부 분기 등 실제 다단계 워크플로우입니다.

이러한 워크플로우는 상태를 가집니다(stateful). 계약은 초안에서 법률 검토로 이동하고, 편집을 위해 영업팀으로 돌아가고, 승인을 위해 재무팀으로 갈 수 있습니다. 각 단계는 다른 권한, 다른 UI 표면(UI surfaces), 그리고 다른 실패 모드를 가지고 있습니다. 만약 에이전트가 이를 탐색할 수 있다면, 대부분의 SaaS 도구를 탐색할 수 있다는 의미입니다.

이번 파트너십을 통해 OpenAI는 다음 사항에 접근할 수 있게 되었습니다:

조건부 로직을 가진 실제 워크플로우 그래프
다중 역할 승인 체인(Multi-role approval chains)
문서 버전 관리 및 수정 표시
외부 시스템과의 통합 지점
실제 운영 사용에서 발생한 실패 사례들

평가 인프라의 도전 과제

운영 중인 워크플로우를 에이전트 평가로 전환하려면 세 가지 문제를 해결해야 합니다:

1. 데이터 정제(Data sanitization)

고객 계약으로 훈련할 수 없습니다. Ironclad는 실제 조건, 당사자 또는 협상 이력을 노출하지 않으면서 워크플로우 복잡성을 유지하는 합성 계약을 생성해야 합니다. 이는 다음을 의미합니다:

현실적인 조항이 포함된 템플릿 기반 계약 생성
실제 조직 구조를 반영하는 합성 승인 체인
익명화된 편집에서 추출된 수정 표시 패턴

2. 재현성 (Reproducibility)

계약 워크플로우는 결정론적(deterministic)이지 않습니다. 사용자마다 다른 경로를 따릅니다. 이를 평가(eval)로 만들기 위해서는 다음이 필요합니다:

고정된 UI 상태를 가진 스냅샷 환경
버전 관리되는 워크플로우 정의
결정론적 승인 로직 (평가 실행 중 인간 개입 없음)

3. 버전 드리프트 (Version drift)

Ironclad는 제품 업데이트를 배포합니다. UI가 변경되면 평가(eval)가 작동하지 않습니다. 인프라스트럭처는 다음을 수행해야 합니다:

평가 버전과 함께 제품 버전을 추적
하위 호환 가능한 평가 스냅샷 유지
UI 변경으로 인해 기존 테스트 케이스가 무효화될 때 플래그 지정

아키텍처: 워크플로우 캡처부터 에이전트 실행까지 (Workflow Capture to Agent Execution)

예상되는 흐름은 다음과 같습니다:

┌─────────────────┐
│ Ironclad Prod   │
│ Workflow Engine │
...

워크플로우 로거가 핵심적인 부분입니다. 다음을 캡처해야 합니다:

각 단계별 DOM 스냅샷
API 요청/응답 쌍
사용자 의도 신호 (인간이 무엇을 하려고 했는지)
성공 기준 (각 작업에 대해
Agent 추론 로그 (Agent reasoning log): 각 행동을 선택한 이유
단계별 DOM 차이 (DOM diff per step): UI에서 무엇이 변경되었는지
API 호출 로그 (API call log): 백엔드 상태 전환
스크린샷 타임라인 (Screenshot timeline): 에이전트가 본 것의 시각적 증거
지연 시간 분석 (Latency breakdown): 비전, 계획, 실행에 소요된 시간

관측 가능성 스택(observability stack)은 이러한 스트림들을 상관관계화해야 합니다. 만약 에이전트가 잘못된 버튼을 클릭했다면, 다음 사항들이 보여야 합니다:

DOM이 어떤 모습이었는지
비전 모델(vision model)이 무엇을 추출했는지
플래너(planner)가 무엇을 결정했는지
실행기(executor)가 브라우저에 무엇을 보냈는지

이러한 상관관계 없이는 실패 레이블링(failure labeling) 자체가 추측이 됩니다.

에이벌스 버전 관리 (Version Control for Evals)

Ironclad가 워크플로우를 변경할 때(새로운 승인 단계, 다른 UI 레이아웃 등), 에이벌 스위트(eval suite)도 적응해야 합니다. 두 가지 전략이 있습니다:

핀 스냅샷 (Pinned snapshots)

오래된 제품 버전을 격리된 환경에서 계속 실행합니다. 에이전트는 v1.2, v1.3, v1.4를 동시에 대상으로 훈련됩니다. 이는 회귀(regressions)를 포착하지만 여러 제품 버전을 실행하기 위한 인프라가 필요합니다.

적응형 에이벌스 (Adaptive evals)

제품이 변경될 때마다 에이벌 스냅샷을 업데이트합니다. 오래된 스냅샷은 사용 중단(deprecated)으로 표시됩니다. 이는 에이벌스를 최신 상태로 유지하지만, 역사적 비교를 잃게 됩니다.

대부분의 팀은 하이브리드 방식을 사용합니다: 중요한 워크플로우는 고정하고, 나머지는 적응시킵니다.

보안 경계 (Security Boundaries)

Ironclad가 OpenAI에 프로덕션 환경에 대한 직접적인 접근을 허용할 수 없습니다. 정제 파이프라인(sanitization pipeline)은 Ironclad의 VPC 내에서 실행되어야 합니다. 출력물(합성 계약 및 워크플로우 스냅샷)은 OpenAI의 훈련 환경으로 내보내집니다.

주요 경계는 다음과 같습니다:

데이터 유출 (Data exfiltration): 고객 데이터가 Ironclad을 벗어나지 않음
워크플로우 격리 (Workflow isolation): 에이벌 실행은 프로덕션 계약에 접근할 수 없음
접근 제어 (Access control): OpenAI 에이전트는 제한된 권한으로 실행되며, 권한 상승(escalate)을 할 수 없음

정제 파이프라인이 신뢰 경계입니다. 만약 여기서 PII가 유출된다면, 파트너십은 실패합니다.

트레이드오프: 프로덕션 워크플로우 대 합성 벤치마크 (Trade-Offs: Production Workflows vs. Synthetic Benchmarks)

차원	프로덕션 워크플로우	합성 벤치마크
현실성	높음 (실제 복잡성)	낮음 (단순화된 작업)
...
Production workflows는 실제 실패 모드를 노출합니다. Synthetic benchmarks는 제어하기가 더 쉽습니다. 가장 좋은 eval suite는 둘 다 사용합니다.

기술적 결론 (Technical Verdict)

다음과 같은 경우에 이 접근 방식을 사용하세요:

에이전트가 장난감 같은 작업이 아닌 실제 SaaS 복잡성을 처리해야 할 때
워크플로우 내부를 노출할 의향이 있는 SaaS 파트너가 있을 때
PII(개인 식별 정보)를 안정적으로 제거하는 sanitization 파이프라인을 구축할 수 있을 때
에이전트 실패를 분류할 라벨링 역량이 있을 때
제품 업데이트와 함께 진화하는 eval 데이터가 필요할 때

다음과 같은 경우에 이 접근 방식을 피하세요:

에이전트 개발 초기 단계여서 빠른 반복(iteration)이 필요할 때
sanitization 단계에서 데이터 프라이버시를 보장할 수 없을 때
SaaS 파트너가 매주 깨지는 변경 사항(breaking changes)을 배포할 때
제품 스냅샷을 버전 관리할 인프라가 부족할 때
Synthetic evals만으로 충분한 신호(signal)를 얻을 수 있을 때

OpenAI와 Ironclad의 파트너십은 프로덕션 워크플로우가 에이전트 훈련장소가 될 수 있음을 보여줍니다. 이 배관 공사(plumbing)는 간단하지 않습니다: sanitization, versioning, failure labeling, 그리고 observability 모두 맞춤형 인프라를 필요로 합니다. 하지만 그 보상은 단순한 데모가 아닌 실제 작업을 처리하는 에이전트입니다.

출처 링크 (Source Links)

OpenAI: Ironclad와 함께 컴퓨터 사용 발전시키기