Workbench 설계 논의

문서 목적

사용자가 설명한 Workbench에 대한 생각을 배경, 기능, 구조와 논의 상태로 나누어 나중에 다시 읽고 판단할 수 있게 정리한다.

현재 확정된 POC 계약과 더 넓은 제품 구상은 서로 다른 범위다. 둘을 하나의 기능 목록으로 섞지 않고 출처와 상태를 함께 표시한다. 아직 사용자와 논의하지 않은 세부 설계는 확정된 내용처럼 추가하지 않는다.

배경

Workbench는 불특정 일반 사용자를 위한 제품이 아니라, 고객의 AI Agent 서비스를 구축하고 운영하는 SI 프로젝트 팀이 사용하는 제품이다.

프로젝트 참여자

사용자가 공유한 프로젝트 조직은 다음과 같다.

• 고객사 소속 PO
• 외주사 소속 SI 개발자
• 외주사 소속 운영자

외주사 인력이 Agent Artifact를 작성하거나 서비스를 운영하더라도 프로젝트에서 생성한 Agent Artifact와 Runtime 생산 데이터는 고객 소유다.

Runtime 데이터의 소비자

Workbench는 첫 번째와 두 번째 소비자를 위한 사람용 Interface다. 세 번째 소비자는 Workbench 화면이 아니라 고객 데이터 계약을 통해 Runtime 데이터를 사용한다.

현재 문서에서 파악한 Workbench의 범위

저장소의 현행 확정 문서와 과거 제품 구상 문서는 Workbench를 서로 다른 범위에서 설명한다.

Workbench의 전체 역할

현재까지 정리한 Workbench의 작업 범위는 Build, Release, Operate와 Improve로 나뉜다.

Build

• AA Draft 작성과 변경
• Workflow·Action·Binding 설계
• MCP Resource·Tool 계약 연결
• AWA 제안과 Diff 검토
• Test Run과 Trace 확인
• Evaluation과 Regression
• 불변 Version 생성

Release

• Version의 배포 준비 상태 확인
• 개발·검증·운영 환경별 Binding 비교
• 특정 Version을 환경에 배포·승격
• 배포 전 Evaluation과 계약 검증
• 현재 운영 Version 확인
• 이전 Version으로 Rollback
• 변경자·확인자·배포자와 변경 이유 기록

Operate

• 배포된 AA와 Run 상태 관찰
• 성공률·오류·지연 시간·처리량 확인
• Tool 호출·실패·Retry 분석
• 비용과 품질 변화 확인
• Run·Action·Tool Trace 탐색
• 실패 Run 재시도·취소 등 운영 조치
• Incident와 영향 Version 연결
• Policy 차단과 향후 Human Approval 처리
• 변경·배포·Rollback·Audit 이력 조회

Improve

운영 중 발견한 문제를 별도의 전달 문서로 끝내지 않고, 근거 Run과 Artifact 위치를 다음 Draft의 변경으로 연결한다. 구체적인 연결 구조는 다음 섹션에서 설명한다.

운영과 개선의 연결

AA 운영은 Monitoring 화면에서 끝나지 않는다. 이상, 품질 저하와 비용 증가를 발견한 뒤 변경 제안, Test와 새 Version까지 연결하는 흐름이 필요하다.

운영 Run
  ↓
이상 · 품질 저하 · 비용 증가 발견
  ↓
Finding
  ↓
AWA의 Change Proposal
  ↓
새 Draft
  ↓
Test · Regression
  ↓
새 Version
  ↓
승격 · 배포

운영 화면에서 발견한 문제는 artifactId, version, runId와 actionId 같은 식별자를 통해 근거 실행과 AA의 변경 위치에 연결되어야 한다.

상위 Information Architecture 초안

Workbench Component는 Diagram, Inspector와 AWA만으로 끝나지 않는다. 작성과 운영 범위를 모두 다루기 위한 상위 구조는 다음과 같이 정리할 수 있다.

Workbench
├─ Projects
├─ Agent Artifacts
│  ├─ Overview
│  ├─ Build
│  ├─ Test & Evaluate
│  ├─ Versions
│  ├─ Deployments
│  ├─ Runs
│  ├─ Quality & Cost
│  └─ Audit
├─ Operations
│  ├─ Fleet Overview
│  ├─ Incidents
│  ├─ Run Explorer
│  └─ Deployment Activity
└─ Settings
   ├─ MCP Capabilities
   ├─ Environments
   ├─ Access
   └─ Runtime Diagnostics

Workbench와 데이터 계약의 경계

Workbench는 Agent Artifact와 운영 데이터의 원본이 아니라, 이를 사람이 사용하는 대표 Client다.

같은 데이터는 Workbench뿐 아니라 API, Event와 Export를 통해 고객의 Monitoring, BI와 SIEM에서도 소비할 수 있어야 한다. Workbench를 유일한 데이터 소비 경로로 만들면 고객 데이터가 다시 제품 UI에 종속된다.

제품 구성 방향

현재 정리에서는 Workbench를 별도의 Builder 제품과 Ops 제품으로 나누기보다, 같은 AA 생명주기를 공유하는 하나의 작업 공간으로 보는 방향이 적절하다.

Design → Test → Version → Deploy → Observe → Improve

같은 제품을 사용하더라도 역할에 따라 처음 확인할 정보와 주로 수행하는 작업은 다를 수 있다.

현재 논의 상태