AgentRun 리뷰: AI 에이전트 프레임워크가 필요한 순간

AI 에이전트 프레임워크 AgentRun은 정확히 무엇인가

AgentRun은 툴, 범위가 좁은 모델 판단, 에이전트 호출을 결정론적 구조 안에서 실행하도록 만든 Parcha의 TypeScript 워크플로우 인터프리터입니다. Parcha는 2026년 9월 23일에 이를 오픈 소스로 공개했습니다. 워크플로우 문서에는 상태 계약, 단계, 분기, 제한, 에스컬레이션 경로를 명시하고, 실제 애플리케이션은 툴, 모델 접근, 권한, 저장소, 전달 기능을 제공합니다. 같은 이름을 쓰는 Alibaba Cloud 제품도, 모델이 생성한 코드를 실행하는 구형 Python 패키지도, 아직 검색 결과에 등장하는 2014년 모바일 게임도 아닙니다. 현재 핵심 패키지는 Apache-2.0 라이선스로 배포되는 @parcha/agentrun-dsl 버전 0.1.0-beta.4입니다.

Parcha AgentRun이 맞는 팀과 건너뛰어야 할 팀

AgentRun은 이미 에이전트 런타임을 갖췄고, 일반 코드로는 흐름을 파악하기 어려워진 반복 업무를 하나 이상 짚어낼 수 있는 TypeScript 팀에 적합합니다. 고객 지원 분류가 좋은 예입니다. 먼저 검색하고, 답변이 충분한지 판단한 뒤, 조사가 필요할 때만 에이전트를 한 번 호출하고, 마지막에는 답변하거나 담당자에게 넘깁니다. 증거 선별, 승인 라우팅, 리서치 파이프라인도 같은 형태입니다. 제품·운영·리스크 담당자가 복잡한 콜백을 일일이 따라가지 않고 제어 흐름을 읽어야 할 때 특히 가치가 큽니다.

반면 작업이 뻔한 분기 2~3개로 끝나는 고정 함수라면 AgentRun을 건너뛰는 편이 낫습니다. 이번 리뷰의 대조군 구현은 31줄짜리 함수 본문으로 지원 사례 4건의 결과를 모두 재현했습니다. AgentRun 예제 워크플로우 파일은 호스트 통합 전부터 93줄입니다. 코드 길이만 보면 함수가 확실히 짧습니다.

핵심 문제가 영속성, 스트리밍, 사람의 개입을 갖춘 장시간 실행 상태형 에이전트라면 LangGraph.js를 선택하는 편이 낫습니다. 충돌, 네트워크 장애, 장시간 대기에도 애플리케이션 실행을 이어가는 것이 양보할 수 없는 요구사항이라면 Temporal이 맞습니다. AgentRun은 복구 훅을 제공하지만 내구성 있는 스케줄러를 함께 제공하지는 않습니다. Python, 브라우저 실행, 호스팅 대시보드, 운영 환경 지원 SLA가 필요해도 beta.4는 적합한 선택이 아닙니다. 이번 릴리스에는 어느 것도 포함되지 않기 때문입니다.

AgentRun DSL 핵심 기능 1: 타입 상태로 계약 변경을 잡아낸다

AgentRun DSL의 첫 번째 장점은 최종 값이 선언된 계약과 맞지 않으면 반환을 거부한다는 점입니다. 단순한 기능처럼 들리지만, 워크플로우가 검색 결과와 의미 판단, 에이전트 제출을 한데 묶으면 이야기가 달라집니다. 최종 검증기가 하나라도 없으면 어느 분기에서든 형태가 바뀐 값이 부분적인 성공으로 호출자에게 전달될 수 있습니다.

지원 워크플로우는 느슨한 Candidate와 최종 Answer를 구분합니다. 검색 결과에서 텍스트가 비어 있거나 출처가 없어도 됩니다. 그 상태 자체가 조사 분기를 시작할 수 있기 때문입니다. 완료 조건은 더 엄격합니다. 최종 답변에는 비어 있지 않은 텍스트와 출처가 하나 이상 있어야 합니다. 작성 가이드에 따르면 선언된 입력·출력 계약도 검증하며, 중간 상태 경로는 실행 도중 검사합니다.

계약 테스트에서는 픽스처 출력을 그대로 둔 채 필수 필드 하나만 추가했습니다.

schemaWorkflow.schemas.Answer.properties.resolutionCode = {
  type: 'string',
  minLength: 1,
};
schemaWorkflow.schemas.Answer.required.push('resolutionCode');

비밀번호 경로는 도움말 조회와 첫 번째 판단까지 정상적으로 수행했습니다. 하지만 완료 단계에서는 resolutionCode가 없어 WorkflowOutputInvalidError, 코드 output_invalid로 실패했습니다. 잘못된 답변은 반환되지 않았습니다. 의미상 그럴듯한 객체를 계약까지 충족한 결과로 취급하지 않고 시스템 경계에서 멈췄으므로 올바른 실패 방식입니다.

보호 범위에는 명확한 한계가 있습니다. 유효한 text 문자열과 유효한 sources 배열에도 틀린 답이 담길 수 있습니다. 스키마 검증이 보장하는 것은 다운스트림 코드가 값을 처리할 수 있다는 사실이지, 고객이 내용을 신뢰해도 된다는 뜻이 아닙니다. 함께 읽을 만한 Jev 기반 지원 티켓 라우팅 리뷰는 그 판단 계층을 다룹니다. 확률과 타입이 지정된 출력에도 라벨이 붙은 사례와 사람에게 넘기는 대체 경로가 필요합니다.

AgentRun 워크플로우 핵심 기능 2: 분기 제어로 에이전트 호출을 제한한다

AgentRun의 워크플로우 제어는 4가지 지원 사례에서 그래프에 적힌 그대로 움직였습니다. 요청 2건은 검색과 판단 한 번으로 끝났고, 나머지 2건은 제한된 조사 한 번과 두 번째 판단을 거쳤습니다. 여기서 유용한 단위는 자율 에이전트가 아닙니다. 에이전트를 호출할 수 있는 지점이 단 하나인 결정론적 경로입니다.

각 픽스처를 직접 실행한 결과는 문서와 일치했습니다. 비밀번호, 청구서, 결제 실패 사례는 코드 0을 반환했습니다. 해결되지 않은 결제 사례는 조사 한 번 뒤에도 답변이 불충분하거나 불확실하다는 이유와 함께 코드 2를 반환했습니다. 4건 모두 stderr에는 0바이트가 기록됐습니다. 저장소의 지원 관련 집중 테스트도 2.92초에 31개를 모두 통과했습니다. 여기에는 유효하지 않은 제출, 낮은 신뢰도 판단, 취소, 어댑터 오류 사례가 포함됩니다.

이 결과가 입증하는 것은 호출 규율이지 고객 지원 품질이 아닙니다. 검색 답변, Jev 판단, 조사 출력은 모두 고정된 픽스처였습니다. 프롬프트를 바꿔도 자동으로 적응하지 않으며 실제 고객에게 답장을 보내지도 않습니다. 실행으로 확인된 범위는 더 좁지만 분명히 유용합니다. 첫 답변이 통과하면 인터프리터는 에이전트 호출을 소비하지 않습니다. 통과하지 못하면 정확히 한 번의 조사만 허용합니다. 두 번째 검사도 실패하면 완료 상태로 새어 나가지 않습니다.

이 런타임을 도입할 가장 강력한 이유가 바로 여기에 있습니다. 일반적인 에이전트 루프는 대화가 아직 끝나지 않았다고 판단해 다시 검색하고, 다시 고치고, 또 다른 툴을 호출할 수 있습니다. AgentRun은 허용되는 작업량을 워크플로우 자체에서 유한하게 만듭니다. 호스트가 공급자 비용과 툴 권한을 별도로 강제해야 한다는 사실은 변하지 않지만, 운영자는 실행 전에 호출 예산을 검토할 수 있습니다.

핵심 기능 3: 에스컬레이션은 프롬프트 속 희망 사항이 아니라 코드다

AgentRun에서 에스컬레이션은 에이전트 프롬프트 속 문장으로 묻히지 않습니다. 이유가 포함된 런타임 상태로 반환됩니다. 테스트한 워크플로우는 판단 결과가 yes이고, 답변이 계약을 충족하며, 신뢰도가 0.8 이상일 때만 답변을 채택합니다. 그 외에는 0회 또는 1회 실행되는 조사 큐를 열고 결과를 다시 검사한 뒤, 같은 기준을 넘지 못하면 에스컬레이션합니다.

숫자가 실제 동작을 제어하는지 확인하려고 두 비교 기준을 모두 0.8에서 0.98로 높였습니다. 비밀번호 픽스처의 스크립트 판단은 yes, 신뢰도 0.97 그대로였습니다. 원래 워크플로우에서는 에이전트 호출 없이 즉시 완료된 사례입니다. 더 엄격한 워크플로우에서는 조사 분기로 들어가 같은 유효 답변을 받았고, 다시 yes, 신뢰도 0.97을 반환한 뒤 에이전트 호출 한 번과 판단 두 번 만에 에스컬레이션됐습니다.

이 작은 수정은 프롬프트, 픽스처 답변, 어댑터를 건드리지 않고 분기만 바꿨습니다. 신뢰도 정책을 코드에 두는 실무적 이점입니다. 팀은 다른 동작 변경과 마찬가지로 임계값 변경을 리뷰하고, 라벨이 붙은 사례를 실행해 본 뒤, 릴리스 전에 달라진 인계 비율을 확인할 수 있습니다.

에스컬레이션은 전달 단계와도 분리됩니다. 런타임은 complete 또는 escalated를 반환하고, 지원 티켓을 열지, 담당자에게 알릴지, 아무것도 하지 않을지는 호스트가 결정합니다. 이 분리 덕분에 워크플로우 문서가 스스로 고객에게 연락하거나 계정을 변경할 권한을 얻지 못합니다.

핵심 기능 4: 검사 기능은 유용하지만 통합은 여전히 팀의 몫이다

AgentRun의 검사 기능을 사용하면 코드를 실행하기 전에 워크플로우를 읽을 수 있습니다. 그렇다고 주변 애플리케이션 작업까지 사라지지는 않습니다. 생성된 분류 예제에서 agentrun inspect는 워크플로우 다이제스트와 judge, escalate, code 노드, 필수 runJudge 어댑터, executableCode: true를 반환했습니다. validate는 ok: true를 반환했습니다. dry-run도 ok: true였지만, 합성 에스컬레이션 경로를 건너뛰었다는 점을 분명히 알렸습니다.

이 건너뛰기는 중요합니다. 성공한 dry run은 연결이 맞다는 증거일 뿐 분기 커버리지를 뜻하지 않습니다. 반환, 조사, 검토 경로를 의도적으로 실행한 4가지 지원 픽스처가 동작을 증명했습니다. CI에서도 이 차이를 유지해야 합니다. 검사는 구조를, 검증은 계약을, 고정 사례는 동작을 확인합니다.

통합에는 주로 3가지 어댑터가 필요합니다. runEffect는 툴과 기타 효과를 디스패치합니다. runJudge는 필요할 경우 Jev를 통해 타입이 지정된 판단을 제공합니다. runNode는 에이전트 런타임을 연결하며 스키마, 툴, 취소 신호, 검토 콜백을 빠짐없이 전달해야 합니다. 인증, 비밀 정보, 모델 선택, 턴 제한, 예산, 로그, 민감 정보 삭제, 결과 전달, 내구성 있는 영수증도 호스트가 책임집니다.

일반 함수와 비교하면 트레이드오프가 더 선명해집니다. 31줄짜리 함수 본문은 같은 스크립트 어댑터를 사용해 모든 기준 상태와 호출 횟수를 재현했습니다. 지원 경로가 하나라면 이 함수가 더 읽기 쉽고 배포하기도 쉽습니다. AgentRun 워크플로우 파일에 추가된 62줄로 얻는 것은 재사용 가능한 문서, 범용 검사, 공유 노드 의미 체계, 출력 계약, 구조화된 에스컬레이션, 작성 에이전트가 생성할 수 있는 표면입니다. 기본적으로 코드가 줄어드는 것은 아닙니다.

이는 내부 에이전트 워크플로우를 직접 구축할지 구매할지 판단하는 기준과 같은 경계입니다. 반복되는 운영 작업이 공통 기반을 유지하는 비용보다 커질 때 공유 도구를 도입해야 합니다.

AgentRun 베타 가격: 인터프리터는 무료지만 런타임은 아니다

AgentRun 베타의 소프트웨어 가격은 하나뿐입니다. Apache-2.0 코드 사용료는 $0입니다. beta.4에는 유료 AgentRun 요금제도, 호스팅형 AgentRun 런타임도 없습니다. npm 패키지, 소스, CLI, 워크플로우 인터프리터, 예제가 곧 제품입니다. Parcha는 모델 토큰, 툴 실행, 저장소, 관측 기능, 운영 지원을 이 라이선스에 묶어 제공하지 않습니다.

Jev는 별도의 선택형 판단 모델 비용입니다. 2026년 9월 24일에 TypeSafe의 실시간 모델 페이지에서 확인한 Jev 1.13 가격은 입력 토큰 100만 개당 $0.042이며 출력 토큰은 무료입니다. 판단 1회당 입력 토큰 500개를 쓴다고 가정하면, 검사 한 번은 $0.000021, 두 번은 $0.000042입니다. 사례 100,000건에서 판단 호출 비용은 각각 총 $2.10 또는 $4.20입니다.

이 계산에는 에이전트 조사가 들어 있지 않습니다. AgentRun은 호스트가 제공하는 어떤 에이전트 런타임과도 연결할 수 있어 모든 사례에 적용되는 정직한 단일 비용을 제시할 수 없습니다. Jev 검사 한 번으로 끝나는 지원 사례와 에이전트, 툴, 두 번째 검사, 저장소, 로그, 사람 검토까지 거치는 사례의 비용 구조는 다릅니다. 이번 리뷰는 스크립트 응답만 사용했으므로 실제 모델 호출에 쓴 비용은 $0이었고, 운영 비용에 관해 실행에서 얻은 증거 역시 0입니다.

Temporal은 내구성 있는 호스팅이 별도 구매 항목인 이유를 잘 보여줍니다. Temporal Cloud는 현재 작업 100만 건당 $50부터 시작하며 저장소 비용이 추가되고, 90일 동안 쓸 수 있는 $150 크레딧을 제공합니다. AgentRun이 이 플랫폼 요금을 받지 않는 이유는 그에 상응하는 호스팅 실행 계층을 제공하지 않기 때문입니다.

실제로 부딪히는 한계

AgentRun의 제약은 가볍지 않습니다. 기본 아키텍처로 삼기보다 경계가 명확한 워크플로우 하나부터 베타를 도입해야 합니다.

1. 릴리스 산출물끼리 버전 표기가 맞지 않는다

배포된 패키지 매니페스트는 설치 패키지를 0.1.0-beta.4로 식별하지만, 함께 번들된 README에는 Beta: 0.1.0-beta.3라고 적혀 있습니다. beta.4 태그의 루트 README도 릴리스를 beta.3라고 부르고, changelog는 beta.4를 미출시 상태로 표시합니다. 현재 main에서는 루트 README가 beta.4로 수정됐지만, 배포 태그를 고정한 구매자는 서로 모순되는 상태 문구를 보게 됩니다.

인터프리터가 깨지는 문제는 아니지만, 버전 출처가 중요한 워크플로우 시스템에서는 의미 있는 결함입니다. npm 버전을 고정하고 워크플로우 다이제스트를 저장하며, 어댑터와 정책 버전을 따로 기록해야 합니다. 운영 실행을 재구성할 때 설명용 배지에 의존해서는 안 됩니다.

2. 호스트 부담 자체가 제품의 경계다

AgentRun이 제공하는 것은 제어 흐름이지 완성된 지원 시스템이 아닙니다. 인증된 툴, 에이전트 어댑터, 필요할 경우 Jev 접근, 비밀 정보, 예산 강제, 취소, 비공개 진단, 고객 데이터 정책, 전달, 모니터링, 사람 검토 처리까지 직접 마련해야 합니다. 소스 설정에 걸린 30.48초는 이 통합 노력에 관해 아무것도 말해 주지 않습니다.

3. 복구 훅이 내구성 있는 실행을 뜻하지는 않는다

런타임은 체크포인트, 메모, 영수증, 복구 인터페이스를 노출하지만 저장과 조정은 호스트가 구현합니다. 멱등성 키는 중복 제거에 도움이 될 뿐 정확히 한 번의 전달을 보장하지 않습니다. 시간 초과된 외부 효과가 뒤늦게 완료될 수 있으므로, 호스트는 재시도 전에 최종 처리 결과를 확인해야 합니다. 장애 복구가 최우선이면 Temporal을 선택하십시오. 영속적인 상태형 에이전트 그래프가 핵심이라면 LangGraph.js를 평가해야 합니다.

4. 신뢰된 JavaScript는 엄격한 보안 경계다

코드 노드는 프로세스 권한으로 JavaScript를 실행하며, 검증 과정에서도 프로브를 실행할 수 있습니다. CLI의 --trusted 플래그는 위험을 인정한다는 표시이지 샌드박스가 아닙니다. 사용자나 생성된 산출물, 또는 별도 신뢰 영역에서 워크플로우를 받는 팀은 호스트가 제어하는 프로세스, 파일 시스템, 네트워크, 자격 증명 경계로 이를 격리해야 합니다.

5. 타입을 충족한 결과도 자신 있게 틀릴 수 있다

스키마 테스트는 의도한 방식으로 정확히 실패했지만, 형태만 올바른 오답까지 감지하지는 못합니다. 신뢰도가 높은 yes 판단도 결국 모델 결과입니다. 워크플로우에는 라벨이 붙은 사례, 작업별 임계값, 운영 모니터링, 검토 경로가 필요합니다. 지원 테스트 31개가 통과했다는 사실은 제공된 시나리오만 검증할 뿐 실제 Jev 정확도를 증명하지 않습니다.

6. 플랫폼과 지원 선택지가 좁다

beta.4는 Node.js ESM 라이브러리이며 Node 최소 버전은 22.19, TypeScript 사용자의 TypeScript 최소 버전은 5.4입니다. Python, 브라우저 실행, 호스팅 런타임은 범위 밖입니다. 베타에는 운영 환경 지원 SLA가 없으며, 베타 릴리스 사이의 API 또는 실행 방식 변경으로 마이그레이션이 필요할 수 있습니다.

7. 예상보다 자주 고정 함수가 더 나은 추상화다

31줄 대조 함수는 억지로 만든 장난감 예제가 아닙니다. 스크립트 사례 4건에서 워크플로우와 같은 결과를 냈습니다. 검색 한 번, 조건 하나, 선택형 에이전트 호출 한 번, 한 팀이 담당하는 인계 한 번으로 끝나는 작업이라면 함수가 더 높은 응집도와 적은 개념을 제공합니다. 워크플로우 자체를 주변 애플리케이션과 독립적으로 검사·생성·버전 관리·조합·평가해야 할 때 AgentRun의 도입 근거가 생깁니다.

운영 도입 시에는 이 리뷰와 함께 실패 증거 수집 계획도 세워야 합니다. AI 에이전트 실패 분석 툴 가이드는 정상 경로 그래프만으로 부족해진 뒤 필요한 로그와 추적 정보를 다룹니다.

결론: AgentRun을 선택할 만한 순간

AgentRun은 반복 가능한 에이전트 작업의 중간 구간을 명시적 소프트웨어로 바꾸는 설득력 있는 베타입니다. 인터프리터 설치는 쉬웠고, 지원 그래프는 제한된 모든 분기를 그대로 따랐으며, 출력 계약은 안전하게 실패했고, 임계값은 코드처럼 동작했습니다. 라이브러리 밖에 남는 책임을 이례적일 만큼 분명하게 밝힌 프로젝트이기도 합니다.

그래도 결론에는 조건이 붙습니다. 다음 4가지가 모두 참일 때만 AgentRun을 선택하십시오. 워크플로우가 반복되고, 최소 하나의 모델 또는 에이전트 분기에 눈에 보이는 제한이 필요하며, 둘 이상의 사람이나 시스템이 워크플로우를 검사하거나 생성해야 하고, 호스트가 어댑터·권한·복구·평가·전달을 책임질 수 있어야 합니다. 하나라도 충족하지 않으면 TypeScript 함수로 시작하는 편이 낫습니다.

제품의 본질이 영속적인 에이전트 그래프라면 LangGraph.js를 사용하십시오. 워크플로우의 본질이 내구성 있는 분산 프로세스라면 Temporal이 맞습니다. AgentRun은 그 둘과 함수 사이에 있습니다. 어느 런타임보다 범위는 좁지만 손으로 작성한 제어 코드보다는 구조적입니다.

월요일에 바로 할 일은 구체적입니다. 기존 에이전트 업무 하나를 골라 각 단계를 결정론적 코드, 타입 기반 판단, 에이전트 조사, 사람 검토로 표시하십시오. 다이어그램이 하나의 직선으로 끝나면 함수를 유지합니다. 반복되는 분기가 있고 에이전트 비용이나 에스컬레이션 정책을 검토해야 한다면 그 경로 하나만 AgentRun으로 작성하고, beta.4를 고정한 다음, 실제 모델을 연결하기 전에 픽스처 4개를 만드십시오.

AgentRun 자주 묻는 질문