만들고 관리하는 영역
Workbench와 AWA가 Agent Artifact를 작성·검토·평가하고 Version을 관리한다. 아키텍처 용어로는 Control Plane이다.
Method X는 개인 Agent의 능력을 고객 조직이 공동으로 작성하고, 같은 실행 계약으로 시험하고 운영하며, 근거를 남겨 개선할 수 있게 만드는 고객 설치형 AI Enterprise Platform이다.
이 페이지의 권한: 저장소에 이미 남은 지식을 읽기 순서에 맞게 재구성한 문서다. 새로운 제품 의견이나 결정을 만들지 않는다. 확정 계약, POC 증거, 아이디어·가설, 미결, 과거 이력을 서로 다른 상태로 표시한다.
rules/의 현행 계약wiki/의 아이디어·가설rules/open/의 미결.aiignore/의 경위·대체 기록챗봇 하나가 아니라, Agent Capability를 고객 소유의 실행 가능한 계약으로 만들고 운영하는 플랫폼이다.
Agent는 목표를 받아 지시·맥락·도구를 활용해 여러 단계를 수행하는 AI 실행 주체다. Capability는 지시 이해, Tool 사용, Workflow 수행, 기록·위임 같은 수행 능력을 뜻한다.
Workbench와 AWA가 Agent Artifact를 작성·검토·평가하고 Version을 관리한다. 아키텍처 용어로는 Control Plane이다.
확정된 Agent Artifact Version을 실행기가 실제 Tool 및 데이터와 결합해 한 번의 업무 실행(Run)으로 처리한다. 이 영역을 Data Plane이라 한다.
단순히 SaaS가 아니라는 뜻을 넘어, 고객이 운영하는 Infrastructure 안에 설치되고 고객이 자산·데이터 계약을 소유한다는 책임 경계다.
현재 주 경로는 서버에서 독립적으로 실행되는 Method-X Runtime이다. Method-XE는 모바일 앱 안에 내장되는 별도 형태이며 후속 POC로 분리돼 있다.
Sources: method-x.md · method-xe.md · runtime boundary wiki
출발점은 AX SI 프로젝트의 구조적 마찰이다. 이 문제 정의와 사업 효과는 제품 가설이며, 확정된 성과로 읽으면 안 된다.
AX는 AI Transformation, 조직의 업무와 시스템을 AI 중심으로 전환하는 활동이다. SI는 System Integration, 고객 요구에 맞춰 시스템을 설계·연결·구축하는 프로젝트 방식이다. MM은 Man-Month 단위 인력 투입 계약 관행을 가리킨다.
업무 목표가 문서와 인력을 거치며 Prompt·Workflow·평가 기준과 분리되고 변경 이유가 구현물에 남지 않기 쉽다는 문제의식이다.
Instructions, Tool 계약, 흐름, 평가와 Trace가 플랫폼 내부 설정이나 개인 노하우로 흩어질 수 있다.
업무 API와 Agent 로직을 계약 없이 동시에 개발하면 한쪽 변경이 다른 쪽을 반복적으로 막는다.
Version·환경·Identity·실패가 연결되지 않으면 개선이 기억과 수작업에 의존한다.
Sources: project-background.md · problem-and-business-context.md · marketing foundation
Chat 작성, Graph, MCP 연결, Test Log, Evaluation 각각은 이미 경쟁 제품에도 있다. 차이는 이들을 고객 소유 계약과 같은 Runtime에 연결하는 조합이다.
업무 목적, Workflow, Tool 계약, 출력 Schema, Evaluation 참조와 Version을 구조화된 자산으로 남긴다.
Workbench Test와 Service Run이 같은 AA 해석 규칙, Compiler, Runtime Engine, Event·Trace 계약을 거친다.
Business Application과 Agent는 MCP·Tool Schema와 Digest를 경계로 개발하고 실제 Provider 계약으로 다시 검증한다.
투명한 자산과 실행 근거가 교체·개선 범위를 명확하게 만들 수 있다는 가설이다. 기간·비용 절감을 보장하지 않는다.
Version·Trace·Evaluation을 묶으면 반복 평가 자료를 만들 수 있다는 가설이다. 품질 향상을 직접 보장하지 않는다.
MCP(Model Context Protocol)는 Agent Host가 외부 Server의 Tool과 Resource를 표준 방식으로 발견하고 사용하는 프로토콜이다. Tool은 Agent가 호출하는 구조화 기능, Resource는 작성·판단에 읽는 맥락 자료다.
Sources: Copilot Studio 비교 · ownership-and-portability.md · 적대적 리뷰
사람이 보는 Diagram부터 Runtime Trace까지 같은 Action 식별자를 보존하는 것이 설계의 핵심 축이다.
AA는 Agent Artifact의 약자다. 특정 비즈니스 작업을 Agent가 수행하도록 목적·Workflow·Tool 계약·출력·평가·Version을 구조화한 고객 소유 JSON 문서다.
Draft는 revision 낙관적 잠금을 쓴다. 사용자 확인 뒤 불변 Snapshot과 Digest를 가진 Version이 생긴다.
Workflow가 Route와 Edge를, Action이 자신의 작업과 결과를 소유한다. Action은 다음 Action을 알지 않는다.
actionId는 정의, actionInstanceId는 반복 실행 개체, attempt는 재시도다.
Canonical JSON에 SHA-256을 적용한 내용 식별자다. AA, Tool 계약, Compile 결과 변경을 확인한다.
AWA Diagram Node
│ same actionId
▼
AA Action Definition ─── Edge ───▶ next Action
│ compile, identity preserved
▼
Execution Plan Action
│ run
▼
Trace: actionId + actionInstanceId + attempt| AA 최상위 필드 | 상태 | 역할 |
|---|---|---|
schemaVersion · artifactId · version | 확정 | 형식, 자산 식별, 불변 Version |
purpose · workflow · outputSchema | 확정 | 목적, 실행 Graph, 최종 결과 검증 |
toolDependencies · toolContractDigests | 확정 | 불투명 Tool 이름과 계약 고정 |
evaluationReferences · modelProfile · digest | 확정 | 평가, 논리 Model 요구, 내용 식별 |
metadata | 예비 | 내부 계약 미확정 |
Sources: agent-artifact.md · action-contract.md · aa-contract.md
Agent 업무는 여러 외부 시스템을 차례로 부르고 오래 기다릴 수 있다. 서버 프로세스 하나가 재시작됐다고 처음부터 다시 실행하면 중복 호출과 잘못된 결과가 생긴다. Method X는 실행 순서와 외부 호출을 분리해 이 문제를 다룬다.
Runtime은 확정된 Agent Artifact를 실제로 수행하는 실행 소프트웨어다. Compiler는 사람이 검토한 AA가 실행 가능한지 먼저 확인하고, 실행기가 순서대로 읽을 JSON 계획(Execution Plan)으로 바꾼다. 새로운 프로그램 코드를 만드는 것은 아니다.
Workbench Test (origin: awa) Business App (origin: service)
└──────────────┬──────────────┘
▼
Runtime Gateway
HTTP Run API · OIDC/JWT · SSE reconnect
▼
Durable workflow coordinator
Temporal Server + TypeScript SDK
실행 이력 · 작업 배정 · 대기 · 재시도 · 복구 재생
┌────────┴────────┐
▼ ▼
Workflow Worker · AA Interpreter Activity Worker
같은 입력=같은 순서 Agent Execution Adapter
Tool/MCP/Model/Storage I/O
└────────┬────────┘
▼
Run Data · Artifact Store이처럼 실행 상태를 기록해 두었다가 프로세스가 사라져도 이어가는 방식을 Durable Execution(내구성 있는 실행)이라 한다. Method X는 이를 직접 새로 만들지 않고 Temporal이라는 공개 플랫폼을 사용한다. Temporal의 Workflow는 “다음에 무엇을 할지”를 재현 가능하게 결정하고, Activity는 Network·Tool·Model처럼 결과가 매번 달라질 수 있는 외부 호출을 수행한다.
Runtime Gateway는 POST /v1/runs로 실행을 만들고 조회·취소·진행 Event 구독을 제공한다. 누가 어떤 용도로 시작했는지는 인증 정보로 결정한다.
SSE(Server-Sent Events)는 서버가 진행 상황을 순서대로 보내는 HTTP 방식이다. Client는 마지막 번호를 기억해 연결이 끊긴 다음 지점부터 다시 받는다.
같은 요청을 여러 번 보내도 실행이나 외부 부작용이 중복되지 않는 성질을 Idempotency(멱등성)라 한다.
Model·Tool·MCP·구조화 출력은 Vercel AI SDK를 Adapter 뒤에서 사용한다. 장애 복구와 실행 상태는 Temporal 한 곳만 책임진다.
| 정확한 기술·구성요소 이름 | 개발팀이 알아야 할 역할과 경계 |
|---|---|
| Node.js · TypeScript | 독립 Runtime Service의 구현 언어와 실행 환경이다. AA Contract, Compiler, Gateway와 Worker 코드를 같은 Type 체계로 연결한다. |
| Temporal Server · Temporal TypeScript SDK | Workflow Event History, Task Queue, Timer, Retry와 장애 후 Replay를 소유한다. 한 Run의 Durable Execution 소유자는 Temporal 하나뿐이다. |
| Temporal Workflow | AA Run의 결정적인 제어 흐름을 가진다. 시간·난수·Network·Database·Model·Tool 호출을 직접 수행하지 않는다. |
| Workflow Worker · AA Interpreter · Method-X Action Runner | Execution Plan에서 실행 가능한 Action을 선택하고 Action Type의 Executor를 호출한다. Diagram과 같은 actionId를 보존한다. |
| Activity Worker · Agent Execution Adapter | LLM, MCP Tool, Storage와 Network 같은 비결정적 외부 작업을 수행한다. 재시도 시 중복 부작용을 막도록 안정적인 Idempotency Key를 전달한다. |
Vercel AI SDK · @temporalio/ai-sdk | Model Provider, Tool Calling, MCP, Structured Output와 Streaming primitive를 제공한다. Preview 통합은 Method-X Adapter 뒤에 숨겨 교체 가능하게 둔다. |
| Runtime Gateway · HTTP · SSE | Run 시작·조회·취소와 Event 재연결을 공개한다. Token 단위 출력 Streaming은 현재 POC 공개 계약에 없다. |
| MCP Host · Streamable HTTP | 외부 설정의 MCP Server에 연결해 Tool·Resource Capability를 AWA와 Runtime에 함께 주입한다. POC는 Streamable HTTP만 지원한다. |
| Run Data Store · Artifact Store | 공개 Event·Trace·결과와 대용량 Payload를 고객 Stack에 보관한다. Temporal History에는 제어 상태와 안정적인 참조만 둔다. |
Deterministic(결정적) 실행은 같은 기록을 다시 읽으면 같은 제어 순서를 내는 성질이다. Replay는 저장된 Event History를 다시 적용해 장애 전 상태를 복원하는 과정이다. Adapter는 외부 SDK의 Preview API나 Provider별 차이가 Method X Core 계약으로 새지 않도록 감싸는 층이다.
Method-XE Core는 순수 TypeScript 기반 Embedded Runtime이고 첫 Host Adapter는 React Native다. @method-x/xe-core가 AA Load·공통 Contract 검증·Embedded Compile·Workflow 실행을, @method-x/xe-react-native가 Module API와 Host Lifecycle을, @method-x/xe-model-native가 iOS·Android On-device Model Adapter 경계를 맡는다. Temporal·Distributed Worker·Cluster·MCP Client는 포함하지 않는다. 현재 구현 경계와 실제 모바일 Service 통합 POC는 별개다.
Sources: runtime-engine.md · runtime-gateway.md · compiler.md · mcp-host.md
“어디서나 그대로 실행”을 보장하지 않는다. 무엇을 옮기고 다시 구현해야 하는지 식별할 수 있게 하는 방향이다.
AA Version, 실행·평가·감사 데이터, Business API·Data·MCP·Tool, 고객 인증·Infrastructure.
Workbench·AWA, Artifact Service·Compiler, Runtime Gateway와 Runtime Service의 범용 기능.
Provider, Endpoint, Credential, Server 설정 이름과 Routing. AA는 Tool 이름과 계약 Digest만 가진다.
고객 OIDC의 JWT를 검증한다. Secret 원문은 AA·설정 파일·Trace에 남기지 않는다.
OIDC(OpenID Connect)는 Identity 확인 표준, JWT는 서명된 인증 Claim 묶음이다. RBAC는 역할 기반 권한 관리이며 완전한 RBAC는 POC 범위 밖이다.
Sources: ownership-and-portability.md · security wiki · mcp-host.md
AWA는 업무 진실이나 보안 승인을 대신하지 않는다. 실제 MCP 맥락과 실행 증거를 읽어 검토 가능한 변경안을 만든다.
AWA(Artifact Writing Agent)는 PO와 SI 개발자가 AA를 작성·등록·수정·고도화·감사하도록 돕는 Workbench Agent다. PO는 업무 목적·Workflow·Evaluation을 검토하고 Version 생성을 확인하는 고객 측 역할이다.
업무 요구를 질문하고 MCP Resource를 읽어 Operation과 Field를 확인한다.
Workflow·Action·Schema·Binding·Evaluation을 제안하고 Diff로 보여 준다.
같은 Runtime의 awa Origin으로 실행해 Diagram에 Event와 Trace를 연결한다.
실패와 평가 결과를 Finding → Change Proposal → Regression Loop로 연결한다.
확인 없이 Version을 만들지 않는다. 업무 진실, 보안 승인, 배포 결정, 자산 소유권을 대신하지 않는다. 실시간 공동 편집·다단계 승인·범용 RBAC·여러 Project는 POC에 없다.
Sources: workbench.md · artifact-writing-agent.md · execution-grounded-authoring.md
Bank Marketing POC는 제품 전체가 아니라 AA 작성부터 Service Run과 개선까지의 최소 실행 척추를 확인했다.
Holdout은 최종 확인 전까지 보지 않는 데이터다. ROC-AUC는 순위 품질, PR-AUC는 희소 Positive 추천 품질, Brier Score는 확률 Calibration 오차, Top 10% Lift는 상위 10% 성공률의 전체 대비 배수다.
AA Contract·Compiler, 실제 MCP Resource 3개와 Tool 3개, Tool Digest, 같은 Runtime 경로.
Worker 재시작·Replay, SSE 재연결, 실패·취소, 동시성 10의 1,000 Candidate.
Draft → Version → Test → Service → Parity → Evaluation → 개선을 npm run poc:e2e로 검증.
Candidate가 정책 임계값 0.20을 넘지 않아 selectedCount=0이었고 계약에 맞는 성공 결과였다.
실제 은행 데이터와 캠페인 성과, 연락의 인과 효과, Production SLA·TCO, 외부 OIDC 배포, 완전한 RBAC·승인, HA·다중 Region, 부하·침투 Test, Model 교체성, Method-XE 모바일 통합은 증명하지 않았다.
Sources: poc-handoff.md · poc-development-tasks.md · bank-marketing-poc.md
문서가 스스로 기록한 공격 지점이다. 답이 정해지지 않은 항목을 낙관적 문구로 덮지 않는다.
고객 소유가 명목뿐일 수 있다. Method X만 AA를 해석한다면 파일 보유와 통제권은 다르다.
Lock-in을 바꿀 수 있다. 독자 Contract·Compiler·Runtime에 새 의존이 생긴다.
품질 인과가 없다. Trace와 Evaluation이 있어도 더 나은 Agent가 된다는 증거는 별도다.
범위가 너무 넓다. Workbench, Runtime, Compiler, Evaluation, 보안, On-prem 운영을 모두 감당할 수 있는가.
PO 참여는 복잡성 이전일 수 있다. 개발 복잡도를 업무 담당자에게 넘길 위험이 있다.
같은 Runtime은 같은 환경이 아니다. Identity, 권한, 데이터, Model, Network 차이가 남는다.
Mock과 계약은 병렬 개발을 보장하지 않는다. Provider의 성능·부작용·권한은 통합 때 드러난다.
고객 설치형 운영비가 더 클 수 있다. Upgrade, 장애 대응, Temporal 운영 비용이 생긴다.
Model 호환성과 비용 최적화는 미검증이다. 교체가 품질을 유지한다고 증명하지 않았다.
책임 경계가 책임 전가로 들릴 수 있다. 제품의 보호와 운영 책임을 구체적으로 보여야 한다.
Sources: marketing adversarial review · security review history
다음은 누락이 아니라 명시적으로 보류한 계약이다. 현재 구현의 전제로 사용하면 안 된다.
HITL(Human-in-the-Loop)은 실행 중 사람의 확인·승인·입력, HA(High Availability)는 일부 서버가 고장 나도 서비스를 지속하는 능력, TCO(Total Cost of Ownership)는 도입·운영·교체 총비용, SLA(Service Level Agreement)는 합의한 서비스 수준이다.
V8은 Chrome과 Node.js가 JavaScript를 실행할 때 사용하는 Engine이다. V8 Isolate는 서로 분리된 JavaScript 실행 공간을 만들어 코드와 Memory를 격리하는 방식이다. 초기 조사에서는 Agent 작업을 장기간 격리 실행하는 접근으로 검토했다. 현재 Method X는 고객 JavaScript 코드를 임의 실행하는 구조 대신, 정해진 Action 계약을 Temporal Workflow로 조정한다. 따라서 V8 Isolate는 현행 Runtime 구성요소가 아니라 변경 경위를 이해하기 위한 과거 기술안이다.
Sources: method-x open · agent-artifact open · runtime open · replaced execution history
핵심 용어는 처음 등장한 자리에서 설명했다. 이 목록은 다시 찾을 때 쓰는 압축 색인이다.
루트 지침·README, rules/ 전체, wiki/ 전체, docs/ 전체, .aiignore/의 모든 이력 Log, 앱의 사용자 문서형 HTML, 브랜드 시각 명세를 포함했다. 코드·Test·Fixture는 POC 증거 대조에 사용했고 지식의 위상은 문서 종류 규약을 따른다.