에이전트형 산출물 생성의 구조와 평가 원칙

왜 중요한가

이미지나 텍스트 조각을 만드는 비용이 낮아져도 여러 요구사항을 동시에 만족하는 완성품을 만드는 문제는 남습니다. 이 survey는 2026년 8월 20일까지의 259개 기록을 바탕으로, 실패를 발견하는 시점과 수정 가능한 범위가 산출물 신뢰성의 핵심 조건임을 정리합니다. 특히 피드백이 원인 단위에 연결되지 않으면 자율성을 높여도 전체 재생성이나 책임 불명확성으로 이어집니다.

관련 Figure

Infographic

각 맥락은 screenplay·poster·video/audio, campaign brief·ad creatives, lesson plan, dashboard·summary report, paper draft·figures, CAD model·simulation report 같은 deliverable을 갖습니다. 아래 acceptance 기준은 creator/audience experience, audience fit, learning outcomes, grounding/actionability, evidence/peer review, tests/physical validity로 달라집니다. 이는 artifact family만으로는 구축 요구사항과 평가 기준을 모두 설명할 수 없다는 논문의 응용 축을 시각화합니다.

Creative Production, Brand Communication, Educational Support, Professional Work, Scientific Research, Engineering Design의 여섯 응용 맥락과 대표 산출물을 한 축에 배치합니다.

핵심 기여

상태 기반 Agentic Artifact Creation 정의

AI가 전달할 산출물을 실제로 구성하거나 수정하고, 구성 과정의 상태를 다음 결정까지 유지하며, 중간 관찰이 이후 작업을 바꾸는 episode를 Agentic Artifact Creation으로 규정합니다.

6개 산출물 family와 16개 profile 분류

Textual, 2D Visual, Audio, Video, Spatial, Behavioral의 여섯 family를 acceptance 기준과 수리 단위에 따라 정리하고, 응용 맥락과 산출물 family를 별도 축으로 구분합니다.

기능적 구축 루프 정식화

Operational Representation이 상태와 Edit Interface를 유지하고 Construction Policy가 다음 Action을 선택하며 Runtime Verification이 관찰을 Feedback으로 바꾸는 반복 구조를 제안합니다.

증거 중심 평가 관점

Delivered Artifact뿐 아니라 Construction Trajectory와 Agentic System에 관한 증거를 분리하고, Evaluation Target·Evidence Channel·Evaluator·Protocol·Metric을 연결하는 평가 틀을 구성합니다.

통제 가능한 구축을 위한 네 가지 원칙

Commitment를 외부화하고 Control Boundary를 정의하며 Feedback을 실행 가능한 수리로 바꾸고 변경된 상태를 다시 검증하는 원칙을 정리합니다.

핵심 아이디어 이해하기

일반적인 generative model은 자연어 입력에서 텍스트, 코드, 이미지, 비디오, 오디오 같은 결과를 만들지만, 한 번 생성한 결과의 내부 상태를 유지하거나 다음 수정 위치를 스스로 정하지는 않습니다. 요구사항이 여러 개이면 내용 변경이 레이아웃·동작·후속 제약을 함께 바꾸므로, 마지막 결과만 검사하는 One-Way Generation에서는 실패가 퍼지고 원인 위치를 찾기 어렵습니다.

Agentic Artifact Creation은 산출물을 단순한 출력값이 아니라 계속 검사하고 수정할 수 있는 state로 취급합니다. Operational Representation이 현재 상태와 수정 단위를 유지하고 Construction Policy가 요구사항·상태·이전 Feedback을 보고 Action을 고르며, Runtime Verification이 변경 결과를 관찰해 다음 결정에 되돌립니다. 따라서 입력은 Task Specification과 현재 상태이고, 처리는 Action을 통한 상태 갱신과 관찰이며, 출력은 승인된 Delivered Artifact 또는 추가 수정 결정입니다.

핵심은 에이전트 수가 아니라 관찰이 이후 artifact-level work를 실제로 바꾸는지입니다. 예를 들어 소프트웨어에서는 저장소를 편집한 뒤 테스트·실행 결과를 읽고 특정 파일이나 의존성을 다시 수정해야 하며, 포스터에서는 출처 내용·페이지 여백·가독성 검사를 통해 내용 단위와 레이아웃을 구분해 고쳐야 합니다. 관찰이 실패를 알려도 Edit Interface가 전체 재생성만 허용하면 국소 진단은 실행 가능한 수리로 이어지지 않습니다.

Composability는 독립적으로 교체할 수 있는 작업 단위를 만들고, Traceability는 요구사항·출처·수정·관찰의 연결을 보존하며, Revisability는 영향을 받은 부분과 의존성만 다시 확인하게 합니다. 이 세 성질은 표현 구조, Action, 기록, 검증이 같은 수정 단위를 가리킬 때 함께 작동합니다.

관련 Figure

Diagram
첫 번째 패널에서는 중간 관찰이 이후 Action을 바꾸지 않아 Failure Propagation, Weak Localization, Broad Regeneration이 발생합니다. 두 번째 패널에서는 Action이 상태를 바꾸고 Observation이 Runtime Verification을 거쳐 Feedback으로 돌아가며, acceptance 뒤 Delivered Artifact가 방출됩니다. 이 비교는 논문의 핵심 경계인 일회성 생성과 상태 기반 agentic construction의 차이를 직접 연결합니다.
왼쪽은 Input Instruction이 고정된 One-Way Generation을 거쳐 Produced Artifact가 되는 흐름이고, 오른쪽은 Task Specification이 Construction Policy·Operational Representation·Runtime Verification을 순환하는 구조입니다.

방법론

저자들은 arXiv, Google Scholar, Semantic Scholar, ACM DL, IEEE Xplore에서 2023년 1월부터 2026년 8월 20일까지 검색했습니다. 검색어는 agentic creation, iterative artifact generation, tool-augmented generation 같은 agentic-process 용어와 여섯 artifact family 용어의 조합이었고, 인용 추적과 특정 venue 점검을 보완적으로 사용했습니다. 제목·식별자 중복 제거 후 상태 기반 구축 정의에 따라 후보를 선별했습니다.

최종 corpus는 정의를 만족하는 230개 system과 29개 construction benchmark로 구성됐습니다. 직접 생성기, 중간 관찰이 이후 작업을 바꾸지 않는 workflow, 산출물을 소비하거나 평가만 하는 system은 제외했습니다. 각 기록을 corpus role, primary family, subtype, cross-cutting facet, provenance로 코딩했고, 모호한 사례는 반복적으로 조정했습니다.

기능 분석에서는 Operational Representation, Construction Policy, Runtime Verification을 공통 축으로 사용했습니다. 표현은 Artifact Instance·Structured Model·Executable Program으로, Edit Interface는 Unit Edit·Relation Edit·Whole-Artifact Edit로, 정책은 Workflow·Autonomous와 Single-Agent·Centralized Multi-Agent·Decentralized Multi-Agent로 구분했습니다.

응용과 평가는 artifact family에 종속시키지 않고 별도 축으로 취급했습니다. 평가 절차는 Task Set, Evaluation Metrics, Run Configuration, Analysis Plan을 바탕으로 Evaluation Target과 Evidence Channel을 정하고, Rule-based Checks·Specialist Models·LLM Judges·Human Reviewers가 만든 신호를 점수와 집계 결과로 변환하는 흐름으로 정리했습니다.

관련 Figure

Diagram
Operational Representation 안에는 Artifact Instance·Structured Model·Executable Program과 Unit Edit·Relation Edit·Artifact Edit가 배치됩니다. Runtime Verification은 Artifact State·Runtime Behavior·Evaluation Signal·External Response를 관찰하고, 승인 시 Delivered Artifact를 내보냅니다. 이 도식은 세 기능 역할과 각 역할 사이의 입력·처리·출력 관계를 구체화합니다.
Task Specification에서 출발해 Construction Policy가 작업을 배분하고 Operational Representation을 수정하며, Runtime Verification의 Criterion Status·Failure Diagnosis·Revision Guidance가 다시 정책으로 돌아가는 기능 구조입니다.

주요 결과

검토된 기록은 230개 system과 29개 benchmark였으며, 2026년 자료는 8월 20일까지의 부분 집계입니다. 251개 family-assigned record는 Textual, 2D Visual, Audio, Video, Spatial, Behavioral로 분류됐고, 13개 Video record는 주 profile을 정하지 못한 Cross-profile로 남았습니다. Spoken Audio에는 strict record가 없었습니다.

산출물 family가 달라지면 실패가 관찰되는 방식도 달라졌습니다. Textual·2D Visual은 읽기와 렌더링을 통한 정적 검사, Audio·Video는 재생과 시간적 연속성, Spatial·Behavioral은 탐색·실행·상호작용에 의존합니다. 정적 렌더가 유효해도 데이터 변환, 장면 관계, 충돌 가능성, 실행 동작이 보존됐다는 뜻은 아니므로 family별 관찰 신호와 수리 단위가 필요합니다.

분해는 각 단위의 복잡도를 낮추지만 조정과 재조립 비용을 늘릴 수 있습니다. 또한 Learned Judge가 generator와 같은 선호나 blind spot을 공유하면 독립적인 증거가 거의 늘지 않을 수 있으며, 늦게 도착한 피드백이나 넓은 편집 연산은 이미 승인된 상태까지 무효화할 수 있습니다.

평가 주장은 하나의 점수만으로 산출물의 준비 상태를 확정하지 않습니다. Reference Inputs, Structured State, Rendered Output, Runtime Behavior, Construction History, Use Outcomes를 목표 및 evaluator와 연결하고, artifact 자체뿐 아니라 trajectory와 system에 대한 증거를 함께 수집해야 합니다.

관련 Figure

Diagram
Evidence Channel에는 Reference Inputs, Structured State, Rendered Output, Runtime Behavior, Construction History, Use Outcomes가 있고, Evaluator에는 Rule-based Checks·Specialist Models·LLM Judges·Human Reviewers가 포함됩니다. Evaluation Protocol은 Task Set, Evaluation Metrics, Run Configuration, Analysis Plan으로 구성됩니다. 따라서 최종 점수 하나가 아니라 어떤 대상에 어떤 증거와 평가자를 적용했는지가 Evaluation Claim의 근거가 됩니다.
Delivered Artifact·Construction Trajectory·Agentic System에서 Evaluation Targets를 정한 뒤 Evidence Channel과 Evaluator를 거쳐 Evaluation Signals, Scores, Metrics, Evaluation Claim으로 이어지는 평가 절차입니다.

기술 상세

세 기능은 다음 상태 전이를 반복합니다. Operational Representation은 시점 t의 상태 Rₜ와 Edit Interface를 유지하고, 선택된 Action aₜ를 적용해 Rₜ₊₁ = U(Rₜ, aₜ)를 만듭니다. 여기서 R은 현재 산출물 상태, a는 수정·생성·분기·중단 같은 작업, U는 인터페이스가 수행하는 상태 갱신입니다. 입력 상태와 Action을 연산에 넣으면 다음 수정 가능한 상태가 출력되며, Action이 바뀌면 보존되는 의존성과 이후 검사 범위도 달라집니다.

Construction Policy는 Task Specification T, 현재 상태 Rₜ, Feedback fₜ를 입력으로 받아 aₜ = π(T, Rₜ, fₜ)를 선택합니다. T는 목표와 acceptance criteria, Rₜ는 현재 artifact-side 상태, fₜ는 이전 관찰에서 추출한 제어 정보이며, π는 다음 수정 대상·연산·작업 배분·분기·중단을 결정하는 정책입니다. 같은 요구사항이라도 상태와 Feedback이 다르면 다른 Action이 선택되어야 하므로 고정된 일괄 생성과 구별됩니다.

Runtime Verification은 수정된 상태와 관찰 oₜ₊₁를 받아 fₜ₊₁ = V(T, Rₜ₊₁, oₜ₊₁)를 계산합니다. o는 렌더링 결과, 실행 동작, 테스트 판정, metric, 사용자 응답 같은 evidence이고, V는 이를 acceptance criteria와 비교해 Criterion Status·Failure Diagnosis·Revision Guidance로 변환하는 함수입니다. 예를 들어 테스트 실패가 특정 파일과 의존성에 연결되면 whole-repository 재생성 대신 해당 단위와 영향을 받은 의존성만 다시 확인할 수 있습니다.

승인 시점 τ의 상태 Rτ에 Delivery operation D를 적용해 A = D(Rτ)를 산출합니다. A는 전달 artifact이고, D는 중간 표현을 최종 형식으로 내보내는 renderer·executor·toolchain입니다. 승인되지 않으면 Feedback이 Construction Policy로 돌아가며, 이 반복은 acceptance 또는 termination까지 계속됩니다.

Intermediate Form은 직접 유지하는 초안·이미지·오디오 같은 Artifact Instance, 단위·관계·제약을 담는 Structured Model, 실행 가능한 절차나 저장소인 Executable Program으로 구분됩니다. Edit Interface는 passage·vector element·timeline segment·source file 같은 Unit Edit, 순서·레이아웃·타이밍·의존성을 바꾸는 Relation Edit, 전체 재작성 또는 재생성인 Whole-Artifact Edit로 나뉩니다. 표현이 객체 구조를 갖춰도 인터페이스가 전체 재생성만 제공하면 실질적인 국소 제어는 제한됩니다.

Runtime Verification의 관찰원은 Artifact State, Runtime Behavior, Evaluation Signal, External Response로 나뉩니다. 관찰이 실패를 발견하는 것만으로는 충분하지 않고, Feedback이 책임 단위와 실행 가능한 수정 방향을 지정해야 합니다. 따라서 자율성의 상한은 모델 능력뿐 아니라 verifier coverage, reversibility, 전문성, decision authority와 표현·인터페이스의 정렬에 의해 결정됩니다.

관련 Figure

Diagram
Textual과 2D Visual은 reading/rendering, Audio와 Video는 playback/continuity, Spatial과 Behavioral은 traversal·execution·interaction에 가까운 관찰 지점을 갖습니다. 각 family에서 State를 Edit한 뒤 Observe하는 공통 흐름은 acceptance 기준이 관찰 시점과 수리 단위를 결정한다는 내용을 뒷받침합니다.
Textual, 2D Visual, Audio, Video, Spatial, Behavioral artifact family를 정적 검사, 시간 재생, 런타임 결과라는 관찰 방식에 배치한 비교 도식입니다.

한계점

저자들은 검색별 query export, source별 수집량, 조정 전 label을 보존하지 않았으며 공개 파일에는 최종 coding과 한계만 기록했습니다. 2026년 corpus는 8월 20일까지의 부분 집계이고, 일부 사례는 cited system paper에 세부 구현이 보고되지 않아 NR로 남았습니다. 또한 Learned Judge의 독립성, 여러 정답이 가능한 창작물의 평가, 변화하는 산출물·창작 의도·구축 system에 대한 장기적 책임성은 남은 과제로 제시됩니다.

실무 활용

실무에서는 문서, 차트, 포스터, 프레젠테이션, 오디오, 비디오, 3D 장면, 소프트웨어처럼 여러 제약이 상호작용하는 산출물에 적용할 수 있습니다. 먼저 수정 가능한 상태와 단위를 보존하고, 각 Action 뒤에 해당 기준을 검사하며, 실패 진단이 가리키는 영향 범위만 수정한 뒤 관련 의존성을 재검증하는 순서가 필요합니다.

출처·내용·레이아웃·렌더링 상태를 연결한 연구 포스터와 프레젠테이션 제작
데이터 변환 경로와 시각적 mark를 연결한 차트 생성 및 국소 수정
스크립트·장면·샷·오디오·자막을 유지한 설명형 또는 서사형 비디오 제작
Scene Graph·CAD·BIM·실행 코드에 기반한 3D 자산과 공간 모델 구축
저장소 상태, 테스트 결과, 실행 로그를 연결한 소프트웨어 수정

코드 공개 여부: 공개

코드 저장소 보기

관련 Figure

Diagram
Addressable Artifact State는 Requirements·Design·Algorithm·Evaluation 계층과 U1~U5 의존성을 유지하고, 팀별 책임과 Human Review를 연결합니다. 변경 후에는 evidence→diagnosis→repair와 change→invalidation→revalidation 흐름을 따라 선택적 검사를 수행합니다. 하단의 commitments remain satisfied와 control cost remains proportionate는 명시적 책임과 검증 비용의 균형을 최종 목표로 둡니다.
Externalize Commitments, Define Control Boundaries, Make Feedback Actionable, Revalidate Affected State의 네 원칙을 Addressable Artifact State와 Controlled Goal Realization으로 연결한 원칙 도식입니다.

키워드

Agentic Artifact Creation(에이전트형 산출물 생성)Operational Representation(운영 표현)Runtime Verification(런타임 검증)Construction Policy(구축 정책)Traceability(추적 가능성)Revisability(재수정 가능성)Evaluation Protocol(평가 프로토콜)

용어 해설

운영 표현(Operational Representation): — 생성 중인 산출물의 현재 상태와 수정 가능한 구조를 유지하는 표현 방식입니다. Artifact Instance, Structured Model, Executable Program 같은 중간 형식과 Edit Interface를 통해 어떤 부분을 보존하고 어느 단위에 Action을 적용할지 결정합니다. 상태가 충분히 구조화되어야 이후 관찰 결과를 특정 부분의 수정으로 연결할 수 있습니다.
구축 정책(Construction Policy): — Task Specification, 현재 산출물 상태, 누적 Feedback을 입력으로 받아 다음 Action을 선택하는 제어 요소입니다. 수정 대상, 작업 방식, 담당 에이전트, 분기, 중단 여부를 결정하며 Workflow 또는 Autonomous 방식으로 구현됩니다. 정책의 범위가 넓어도 수정 인터페이스와 검증 결과가 구체적이지 않으면 국소 수리가 어렵습니다.
런타임 검증(Runtime Verification): — 수정된 산출물에서 발생한 관찰 결과를 Acceptance Criteria와 대조하고 제어에 필요한 Feedback으로 바꾸는 과정입니다. Artifact State, Runtime Behavior, Evaluation Signal, External Response를 입력으로 받아 Criterion Status, Failure Diagnosis, Revision Guidance를 산출합니다. 실패 위치와 원인을 수정 가능한 단위에 연결할 때 다음 Action을 좁힐 수 있습니다.
중간 형식(Intermediate Form): — 승인 전 산출물이 구성되고 수정되는 동안 유지되는 artifact-side 표현입니다. 초안이나 이미지 같은 Artifact Instance, 단위·관계·제약을 담는 Structured Model, 실행 가능한 절차를 담는 Executable Program으로 구분됩니다. 어떤 형식을 선택하느냐에 따라 객체·관계·파일·전체 산출물 중 수정 가능한 범위가 달라집니다.
혼합 주도 방식(Mixed-Initiative): — 사람과 AI가 반복적인 산출물 구축 과정에서 함께 의사결정을 내리는 방식입니다. 사람의 승인이나 중간 입력이 이후 시스템 작업을 바꾸며, 초기 프롬프트나 최종 점수만 전달하는 구조와 구별됩니다. 사람의 판단을 유지하면서도 상태, Action, 관찰 기록을 연결해야 책임 범위와 재수정 지점을 추적할 수 있습니다.
추적 가능성(Traceability): — 요구사항, 출처, Action, 산출물 영역, 관찰 결과, 의사결정 사이의 연결을 기록하는 성질입니다. 예를 들어 포스터의 텍스트가 넘칠 때 내용 길이, 레이아웃, 서체, 렌더링 상태를 연결해 원인 후보를 좁힐 수 있습니다. 이 기록이 있어야 승인된 부분을 유지하면서 영향을 받은 부분만 수정할 수 있습니다.

에이전트형 산출물 생성의 구조와 평가 원칙

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

용어 해설

관련 토론

댓글

관련 기사

에이전트 데이터 생성을 위한 ACE 프레임워크와 방법론

쉽게 익히는 Agentic AI 핵심 개념 10가지

AI 에이전트 아키텍처의 5단계 진화와 평가 전략의 변화.

실제 업무를 끝내는 Agent의 조건

2026 최소 AI 엔지니어 툴킷

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

관련 토론

댓글

관련 기사

에이전트 데이터 생성을 위한 ACE 프레임워크와 방법론

쉽게 익히는 Agentic AI 핵심 개념 10가지

AI 에이전트 아키텍처의 5단계 진화와 평가 전략의 변화.

실제 업무를 끝내는 Agent의 조건

2026 최소 AI 엔지니어 툴킷