ARD가 발견을 해결한다. 하지만 AI가 도구를 찾은 후에는 어떻게 될까?

에이전트 기반 리소스 디스커버리(Agentic Resource Discovery)는 AI 에이전트가 직면한 가장 큰 확장성 문제 중 하나를 해결할 수 있습니다.

에이전트는 자신이 명시적으로 설치하지 않은 기능을 어떻게 찾을까요?

이는 생각보다 훨씬 더 큰 문제입니다.

오늘날 우리는 보통 다음과 같이 에이전트에게 능력을 부여합니다:

GitHub 통합(integration)
Slack 통합
데이터베이스 통합
...

에이전트가 10가지 기능을 가질 때는 작동합니다.

하지만 미래에 수백만 개의 기능이 존재한다면 설득력이 훨씬 떨어집니다.

ARD는 훨씬 더 나은 디스커버리 모델을 제안합니다.

모든 가능한 기능을 미리 설치하는 대신, 에이전트는 런타임(runtime)에서 적절한 에이전트 기반 리소스를 검색할 수 있습니다.

그 리소스는 다음과 같을 수 있습니다:

an MCP 서버
API
스킬(Skill)
...

이는 매우 중요한 문제라서 Google, Microsoft, GitHub, Hugging Face 등 여러 기업들이 이 새로운 사양(specification)을 중심으로 활발하게 기여하고 있습니다.

하지만 아키텍처의 어떤 부분이 제 주의를 끌었습니다.

공식 ARD 문서는 그 경계를 명확히 합니다:

ARD는 호출(invocation) 전에 위치합니다.

이는 리소스를 발견합니다.

그런 다음, 해당 리소스는 자체 메커니즘을 사용하여 호출됩니다.

그리고 이는 흥미로운 두 번째 문제를 남깁니다.

기능을 찾는 것과 능력을 안전하게 획득하는 것은 같지 않다

에이전트가 다음과 것을 검색한다고 상상해 봅시다:

"이 리포지토리에서 릴리스 브랜치를 생성하세요." 

디스커버리는 다음과 같이 알려줄 수 있습니다:

여기에 적합한 리소스가 있습니다.
여기에 그 계약(contract)이 있습니다.
여기의 엔드포인트(endpoint)가 있습니다.
...

훌륭합니다.

이제 무엇을 해야 할까요?

에이전트는 여전히 다른 일련의 질문에 대한 답이 필요합니다.

이 계약을 어떻게 이해해야 하나요?

어떻게 실행해야 하나요?
...

이것들은 주로 디스커버리 문제가 아닙니다.

이것들은 **런타임 문제(runtime problems)**입니다.

저는 정확히 그 경계에 대해 오픈 소스 실험을 구축해 왔습니다.

그 이름은 RIGHTCLICK입니다.

그리고 그 배경 가설은 다음과 같습니다:

디스커버리는 AI가 할 수 있는 것을 변경하되, AI가 그것을 수행하는 인터페이스를 변경하지 않아야 한다.

에이전트가 GitHub 도구를 받지 못한다면 어떨까?

GitHub를 고려해 봅시다.

일반적인 에이전트 통합 모델은 결국 다음과 같은 것을 노출할 수 있습니다:

github_create_issue
github_update_issue
github_create_branch
...

그리고 우리는 모든 제공업체(provider)에 대해 동일한 작업을 반복합니다.

RIGHTCLICK은 이 모델을 역전시키려고 합니다.

모델은 의도적으로 작고 일반적인 인터페이스를 갖게 됩니다.

context_runtime
context_inspect
context_actions
...

이후 기능(capabilities)들은 그 뒤에 있는 다양한 기질(substrates)로부터 도착할 수 있습니다:

OpenAPI
GraphQL
gRPC
...

이것들이 공통의 기능 모델로 반영됩니다.

프로토콜은 바뀔 수 있습니다.
제공업체는 바뀔 수 있습니다.
사용 가능한 소프트웨어는 바뀔 수 있습니다.

하지만 모델에 노출되는 인터페이스는 그럴 필요가 없습니다.

그래서 저는 RIGHTCLICK이 이 모델을 사용하도록 만들었습니다.

아키텍처 다이어그램은 그리기가 쉽습니다.
저는 훨씬 덜 편안한 테스트를 원했습니다.

RIGHTCLICK이 동적으로 반영된 기능(capability)을 통해 자체 GitHub 저장소에 수정할 수 있을까요? — 이 작업을 위해 GitHub 전용 도구를 추가하지 않으면서 말입니다?

런타임은 GitHub의 API를 반영했습니다.
그것은 다음과 같은 것과 동등한 기능을 발견했습니다:

브랜치 병합하기 (Merge a branch)

이 구조화된 계약(structured contract)은 다음과 같은 값들을 요구했습니다:

owner
repo
base
...

에이전트는 다음을 받지 않았습니다:

github_merge_branch

그것은 여전히 다음을 사용했습니다:

context_run

RIGHTCLICK은 실행 경계(execution boundary)에서 필요한 권한을 해결하고 GitHub를 호출했습니다.
GitHub는 응답했습니다:

HTTP 201

그리고 RIGHTCLICK은 의도적으로 이 작업이 성공했다고 호출하지 않았습니다.
그것은 '수락됨(accepted)'이라고 호출했습니다.
왜냐하면 이것:

HTTP 201

이 다음을 논리적으로 증명하지 않기 때문입니다:

사용자가 요청한 저장소 상태가 이제 존재함

그래서 별도의 저장소 관찰(repository observation)이 결과 브랜치 상태를 확인했습니다.
상태가 독립적으로 관찰된 후에야 그 결과는 검증된 것으로 처리될 수 있었습니다.
결과적인 실행 모델은 다음과 같았습니다:

ARD / 발견 소스 (discovery source)
        ↓
발견된 기능 (capability found)
...

흥미로운 결과는 이것이 아니었습니다:

AI가 GitHub에서 브랜치를 병합했다.
에이전트들은 이미 그것을 할 수 있습니다.

흥미로운 결과는 다음과 같았습니다:

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

AI는 RIGHTCLICK이 영구적인 github_merge_branch AI 도구를 얻지 않고도 그 능력을 획득했습니다.

GitHub는 역량(capability) 실행 환경 뒤에 또 다른 제공자(provider)가 되었습니다.

ARD와 RIGHTCLICK은 따라서 문제의 서로 다른 절반을 해결합니다

제가 현재 스택에 대해 생각하는 방식은 이렇습니다.

                     사용자 의도 (USER INTENT)
                          │
                          ▼
... 

ARD는 묻습니다:

이 작업을 수행하는 데 도움이 될 수 있는 리소스가 무엇이 있습니까?

RIGHTCLICK은 묻습니다:

그 리소스가 다른 제공자별 인터페이스를 추가하지 않고도 이 에이전트가 안전하게 실행하고 추론할 수 있는 역량(capability)이 되려면 어떻게 해야 합니까?

이들은 경쟁하는 추상화 개념이 아닙니다.

이들은 놀라울 정도로 자연스럽게 결합됩니다.

발견은 권한일 수 없습니다 (Discovery cannot be permission)

d이나믹 디스커버리(dynamic discovery)에는 불편한 함의가 있습니다.

만약 에이전트들이 런타임에 새로운 역량들을 발견할 수 있다면, 그들이 무엇을 할 수 있는지 하는 집합은 작동하는 동안 바뀔 수 있다는 것입니다.

이는 하나의 분리가 절대적으로 중요하게 만듭니다:

발견됨 (DISCOVERED)
    ≠
인가됨 (AUTHORIZED)

찾는 것:

운영 데이터베이스 삭제 (Delete production database)

이것이 그것을 호출할 권한을 부여하지 않습니다.

마찬가지로:

역량이 존재함 (capability exists)
역량에 적용됨 (capability applies)
권한이 있음 (authority available)
...

은 여섯 가지 다른 사실입니다.

신뢰할 수 있는 런타임은 이들을 success = true라는 하나의 부울(Boolean)로 통합하는 것을 저항해야 합니다.

HTTP 200은 놀라울 정도로 위험한 추상화 개념입니다 (HTTP 200 is a surprisingly dangerous abstraction)

이것은 에이전트 시스템에서 제가 가장 좋아하는 문제 중 하나가 되었습니다.

에이전트가 요청한다고 가정해 봅시다:

고객 계정을 생성하세요. (Create the customer account.)

API는 응답합니다:

200 OK

우리는 실제로 무엇을 증명한 것일까요?

어쩌면:

요청이 제공자에게 도달했다 (the request reached the provider)

가능할지도 모릅니다:

제공자가 그것을 수락했다 (the provider accepted it)

하지만 반드시는 아닙니다:

고객 계정이 올바르게 존재한다 (the customer account now exists correctly)

이 구별은 에이전트가 질문에 답하는 것에서 영구적인 상태를 변경하는 것으로 이동함에 따라 점점 더 중요해집니다.

결과가 중요한 작업(consequential operations)의 경우, 저는 스택이 다음을 점점 더 필요로 한다고 생각합니다:

행동 (ACTION)
   ↓
확인 (ACKNOWLEDGEMENT)
...

라기보다는:

ACTION
↓
200
...

런타임은 학습할 수 있어야 한다 — 권한을 학습하지 않고도

저는 또한 절차적 경험(procedural experience)으로 실험하기 시작했습니다.

만약 어떤 역량(capability)이 이전에 접수되었다면, 런타임은 무슨 일이 일어났는지에 대한 제한된 관찰 기록을 유지할 수 있습니다.

예를 들어:

accepted but unverified
verification predicates passed
failed
...

하지만 RIGHTCLICK은 의도적으로 그 이력이 권위가 되는 것을 방지합니다.

이전 경험으로는 다음을 할 수 없습니다:

create a missing capability
resurrect a stale capability
...

저는 이 구분이 엄청나게 중요할 것이라고 생각합니다.

에이전트는 기억이 필요합니다.

에이전트는 절차적 지식(procedural knowledge)이 필요합니다.

하지만:

“나는 이것을 전에 본 적이 있다”가 결코 “내가 이것을 해도 좋다”로 조용히 변해서는 안 된다.

이것은 통합 프레임워크라기보다는 다른 모습으로 보이기 시작한다

제가 이것을 구축할수록, '통합(integration)'이라는 단어의 유용성이 떨어진다고 느꼈습니다.

장기적인 모델은 운영체제 추상화(operating-system abstraction)에 더 가깝게 보입니다:

environment changes
        ↓
capabilities appear/disappear
...

호환 가능한 애플리케이션이 나타나면:

에이전트는 능력을 얻습니다.

API가 온라인 상태가 되면:

에이전트는 능력을 얻습니다.

ARD가 이전에 알려지지 않은 리소스를 발견하면:

역량 그래프(capability graph)가 커집니다.

모델에게 다른 공급자별 언어(provider-specific language)를 가르치지 않고도 말입니다.

제가 현재 관심을 갖는 질문

MCP는 외부 역량과 통신하기 위한 표준 인터페이스를 제공했습니다.

ARD는 에코시스템 규모에서 에이전트가 어떻게 그 역량들을 발견하는지에 대해 다루고 있습니다.

다음 질문은 아마 이것일 것입니다:

발견(discovery)과 행동(action) 사이에 있는 운영체제는 무엇인가?

어떤 주체가 이 모든 외부 계약(foreign contracts)을 표준화할까요?

누가 정책(policy)을 소유할까요?

누가 권위(authority)를 가질까요?

누가 승인(approval)을 실행(execution)에 묶어줄까요?

누가 그 행동이 실제로 요청된 것을 달성했는지 결정할까요?

그리고 우리가 이 문제들을 각각의 공급자마다 독립적으로 재구축하는 대신, 한 번에 해결할 수 있을까요?

그것이 바로 RIGHTCLICK 뒤에 있는 실험입니다.

이것은 오픈 소스입니다:

https://github.com/rossbuckley1990-hash/rightclick

저는 특별히 더 많은 프로바이더 통합(provider integrations)을 원하지 않습니다.

오히려 런타임이 아직 이해할 수 없는 기능 클래스(capability classes)를 찾고 싶습니다.

만약 여러분이 ARD, MCP, A2A, 권한 부여(authorization), 에이전트 런타임(agent runtimes), 기능 보안(capability security), OpenAPI, GraphQL 또는 gRPC에 대해 작업하고 있다면, 아키텍처를 깨뜨려 보세요.

왜냐하면 저는 에이전트 생태계가 다음과 같은 스택으로 향하고 있다고 생각하기 때문입니다:

Discovery
    ↓
Capability Runtime
...

그리고 만약 이게 맞다면, 최종 목표는 다음과 같지 않습니다:

모든 것을 위한 통합을 구축하는 것.

그것은 다음과 같습니다:

통합 자체를 사라지게 만드는 것.