Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
OpenAI는 Ironclad를 활용하여 법률, 상업 등 다양한 업무에 걸쳐 11가지 작업을 정의하고 평가 기준을 설정했습니다. 이 글은 에이전트 워크플로우에서 필수 승인 단계를 누락하는 문제를 지적하며, 진행 상황 측정 점수와 실제 사용 허용 조건을 분리할 것을 제안합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기에이전트는 워크플로우의 대부분을 올바르게 구성할 수 있지만, 여전히 필수 승인 단계를 누락시킬 수 있습니다. 만약 평가 보고서가 평균 점수만 제시한다면, 그러한 실패는 고무적인 숫자에 가려져 사라질 수 있습니다.
OpenAI가 10월 6일에 발표한 Ironclad를 활용한 컴퓨터 사용 발전은 이를 구체적인 공학적 문제로 만듭니다. 연구원들은 실무자들과 협력하여 법률, 상업 및 조달 업무 전반에 걸쳐 11가지 작업을 정의했으며, 각 작업당 8개에서 50개의 평가 기준을 두었습니다.
OpenAI는 GPT-6 Astra가 최대 추론(Max reasoning)에서 평균 55.0%의 루브릭 점수를, GPT-5.6 Sol이 높은 추론(High reasoning)에서 평균 41.6%를 기록했다고 보고합니다. 이 평균값들은 워크플로우가 완벽하게 완료된 비율이 아니라 충족된 기준들을 설명하는 것입니다. 보고된 시도당 19.2분 대 37.0분은 측정된 고객 절감액이 아닌 시뮬레이션 추정치입니다. 이 결과는 모든 Ironclad 워크플로우가 아닌, 그 11가지 연구 작업에 대한 것입니다.
제가 여기서 얻은 구현 교훈은 진행 상황을 측정하는 점수와 워크플로우 사용을 허용하는 조건들을 분리하는 것입니다. 아래의 설계는 제가 제안하는 패턴이며, Ironclad의 구현 방식에 대한 설명이 아닙니다.
가상의 구매 정책이 세금 제외하고 금액이 USD 10,000을 초과할 경우 재무(Finance) 부서의 승인을 필요로 한다고 가정해 봅시다. 실제 소유자는 이러한 세부 정보를 확인해야 하며, 에이전트가 임의로 만들어내서는 안 됩니다.
예시를 위해 금액을 센트 단위로 표현하여 경계값이 1,000,000이 되도록 합니다. 그런 다음 관찰 가능한 케이스들을 정의합니다:
마지막 두 가지 사례는 추가적으로 제안된 필수 요구 사항입니다. 이는 구현 전에 합의가 필요합니다. 이들의 목적은 가정을 정책으로 바꾸기보다는 모호성을 드러내는 것입니다.
수용된 사례들은 특정 설정 버전(configuration version)에 첨부되어야 합니다. 어제 설정에서 통과한 관찰 결과가 오늘 변경된 설정을 승인해서는 안 됩니다.
평가 기준표(rubric)는 유용한 레이블, 문서 품질 및 설정 세부 사항을 측정할 수 있습니다. 비교 및 디버깅을 위해 이 점수를 유지해야 합니다. 또한 프로세스 소유자(process owner)에 의해 선택된 명시적인 필수 검사 ID 집합도 별도로 보관해야 합니다.
다음은 신뢰할 수 있는 테스트 러너(trusted test runner)가 수집한 관찰 결과를 위한 간단한 Python 게이트 코드입니다. 이 코드는 요청된 버전에 대한 증거 참조(evidence reference)를 가진 명시적인 통과만 허용합니다. 누락되거나, 오래되었거나, 결론을 내릴 수 없는 관찰 결과는 검증되지 않은 상태로 남아 있습니다.
def acceptance(required, observations, version):
if not required:
raise ValueError("평가 전에 필수 검사를 정의해야 합니다")
...
이 결정에는 의도적으로 종합 점수(aggregate score)가 없습니다. 선택적 검사에 대한 높은 점수가 실패한 필수 검사를 취소할 수는 없습니다. 실패했거나 검증되지 않은 조건 모두 ready 상태가 참이 되는 것을 방지하며, 보고서 내에서 서로 구별되어 유지됩니다.
예를 들어, 다음은 게이트의 동작을 시연하는 합성(synthetic) 더미 데이터이며 실제 워크플로우의 증거는 아닙니다:
required = {"above_threshold", "missing_amount"}
observations = {
"above_threshold": {
...
빈 필수 집합은 오류를 발생시킵니다. 왜냐하면 실수로 비어 있는 체크리스트가 통과 결과를 생성해서는 안 되기 때문입니다. 예상치 못한 상태 역시 검증되지 않은 상태로 남아 있습니다. 이 함수는 입력 매핑이 표시된 스키마를 따른다고 가정하므로, 호출하기 전에 신뢰할 수 없는 입력을 경계(boundary)에서 검증해야 합니다.
위의 게이트는 참조(references)와 상태(statuses)를 확인합니다. 하지만 참조된 아티팩트가 실제로 존재하는지 또는 결과가 참인지 증명하지는 않습니다. 만약 동일한 에이전트가 관찰 기록을 꾸며내거나 필수 세트를 다시 작성할 수 있다면, 이 게이트는 거의 확신을 주지 못합니다.
별도의 테스트 컨트롤러를 사용하여 안전한 환경에서 알려진 요청(known requests)을 제출하고 그 결과로 나온 경로 또는 승인 상태를 읽어보세요. 요청 ID, 테스트된 구성 버전(configuration version), 입력(input), 예상 결과(expected outcome), 실제 결과(actual outcome), 그리고 증빙 자료(supporting evidence)를 저장하세요. 이 증거가 해당 정확한 사례와 버전에 대한 관찰 기록으로 해결되는지 확인한 후에 게이트로 넘기세요.
시각적 맥락이 중요한 경우 스크린샷을 사용하되, 실제 결과 상태도 반드시 캡처하세요. 에디터의 규칙에 대한 스크린샷은 구성이 어떻게 보이는지를 확립합니다. 경로가 지정된 테스트 요청(routed test request)은 다른 것을 확립합니다. 즉, 해당 구성이 특정 입력에 대해 어떻게 동작했는지를 보여줍니다.
실패 사례를 재현 가능한 케이스로 보존하세요. '에이전트가 몇 가지 단계를 놓쳤다'는 디버깅하기 어렵습니다. '저장된 요청을 900,000센트에서 1,100,000센트로 늘리는 것이 재무 검토를 유발하지 않았다'는 것은 입력 전환(input transition)과 관찰 가능한 결함(observable defect)을 설명합니다.
구성 변경 후에는 필수 사례에 대한 새로운 관찰 기록을 수집하세요. 보이는 양식(form)이 변하지 않았다는 이유만으로 이전의 통과 기록을 재사용하지 마세요. 승인 경로는 스크린샷이 보여주지 못하는 필드, 조건 또는 나중 편집에 의존할 수 있습니다.
첫 파일럿 단계에서는 광범위하고 모호한 확인 항목들의 대규모 집합보다 작고 필수적인 세트가 더 유용합니다. 소유자가 다른 요구 사항을 파악하거나 실패를 통해 누락된 경계(missing boundary)가 드러날 때 사례를 추가하세요. 전반적인 평가 기준(rubric)도 함께 추적하여, 아직 수용을 정당화하지는 못하지만 개선점을 볼 수 있도록 하세요.
또한 수용 가능한 결과에 도달하는 데 필요한 인간의 노력(human effort)도 기록하세요: 준비, 검토, 수정 및 반복 테스트. 이러한 측정값은 모델 실행 시간 및 연구에서의 시뮬레이션된 타이밍과 분리하여 유지해야 합니다.
OpenAI의 발표는 복잡한 계약 과정에서 인간의 감독 역할이 여전히 필요함을 명시적으로 유지하고 있습니다. 이 제안된 게이트(gate)가 그 책임을 제거하는 것은 아닙니다. 대신, 책임 있는 사람에게 무엇이 통과했는지, 무엇이 실패했는지, 그리고 아직 아무도 검증하지 않은 것이 무엇인지에 대한 더 명확한 시야를 제공합니다.
하나의 워크플로우, 즉 규칙에 대한 합의된 버전, 그리고 몇 가지 의미 있는 사례부터 시작하십시오. 신뢰할 수 있는 승인 결정은 완성된 시스템이 무엇을 해야 하는지에 대한 정확한 정의에서 시작됩니다.