AWS Agent Registry 런타임 검색, 빌드 단계의 도구 연결 설정을 대체하다
AWS는 10월 20일 AWS Agent Registry 런타임 검색을 상세히 소개하며, 모든 기능을 에이전트에 하드코딩하는 방식의 대안을 제시했다. 이 접근 방식은 도구 선택을 실행 중인 애플리케이션으로 옮긴다. 여기서 요청을 조정하는 에이전트인 오케스트레이터는 연결을 선택하기 전에 카탈로그를 검색한다. 이 변화는 많은 팀이 도구 카탈로그가 부서 전반으로 확장되기 전까지는 무리 없이 유지할 수 있는 아키텍처에 도전한다.
핵심 경쟁 구도는 빌드 시점 연결 설정과 런타임 선택 사이에 있다. 빌드 시점 연결 설정은 개발자에게 사용할 수 있는 기능의 명시적인 목록을 제공한다. 런타임 선택은 그 목록을 독립적으로 변경할 수 있게 하지만, 검색 결과를 애플리케이션 동작의 일부로 만든다. 문제는 기능이 오케스트레이터의 릴리스 주기 밖에서 변화하도록 허용하면서도 팀이 예측 가능한 실행을 유지할 수 있는지다.
Anthropic 역시 필요할 때 도구를 불러오는 방식을 홍보해 왔으며, 이 AWS 사례는 업계에서 익숙한 기준점을 제공한다. AWS는 모델 컨텍스트뿐 아니라 승인, 소유권, 연결 세부 정보, 접근 규칙이 중요한 엔터프라이즈 카탈로그 관리로 논의를 확장한다. 개발자와 엔터프라이즈 구매자에게 중요한 변화는 조직적 측면이다. 도구의 사용 가능 여부는 또 다른 애플리케이션 배포가 아니라 카탈로그 거버넌스에 따라 결정될 수 있다.
AWS Agent Registry 런타임 검색은 연결 선택 시점을 바꾼다
runtime discovery walkthrough는 Discover, Instantiate, Execute 루프를 제시한다. 샘플은 주문 관리 서버를 가격 책정 및 고객 지원 에이전트와 연결한다. 이는 독립적으로 평가된 엔터프라이즈 배포의 증거가 아니라 시연 시나리오다.
이 예시는 애플리케이션이 AI 시스템에 도구와 컨텍스트를 제공하는 방식을 표준화하는 Model Context Protocol인 MCP를 사용한다. 또한 에이전트 간 통신을 위한 에이전트 간 프로토콜인 A2A도 사용한다. 두 가지를 동일한 검색 루프에 포함하면, 이 사례는 개별 기능 카탈로그를 넘어선 의미를 갖게 된다.
아키텍처상의 변화는 오케스트레이터가 모든 연결을 빌드 과정에 포함하는 대신, 요청을 받은 뒤 연결을 선택한다는 점이다.
이 차이는 단순히 “검색”이라는 단어가 암시하는 것보다 더 주목할 가치가 있다. 개발자가 참조하는 카탈로그는 구현 중에 사람이 통합을 선택하도록 돕는다. 실행 중에 참조하는 카탈로그는 특정 요청에 대해 애플리케이션이 사용할 수 있는 통합을 결정하는 데 도움을 준다.
이는 기능을 추가한다는 의미도 바꾼다. 명시적 연결 설정에서는 개발자가 일반적으로 오케스트레이터를 배포하기 전에 통합이 어디에 속하는지 결정한다. 런타임 선택에서는 호환 가능한 기능이 카탈로그를 통해 후보에 포함될 수 있다. 애플리케이션은 여전히 발견한 기능을 해석하고 사용하는 규칙을 갖춰야 한다.
이 차이는 검토자가 살펴봐야 할 대상도 바꾼다. 오케스트레이터의 소스 코드를 검토하더라도 미래의 전체 기능 집합이 반드시 드러나는 것은 아니다. 유의미한 검토는 카탈로그, 게시 권한, 승인 관행, 호환성 기대치도 함께 고려해야 한다.
이미 주문 문의를 처리하는 가상의 엔터프라이즈 어시스턴트를 생각해 보자. 지원팀이 보증 청구 전문 기능을 도입한다. 아키텍처상의 이점은 조정 애플리케이션에 또 다른 이름 지정 통합을 추가하지 않고도 그 전문 기능을 검색 가능하게 만드는 데 있다.
이 이점은 호환성에 달려 있다. 익숙하지 않은 연결 방식을 쓰는 새로 게시된 서비스는 여전히 통합 작업을 만든다. 런타임 검색은 일부 결정을 뒤로 미룰 뿐, 가능한 모든 서비스를 즉시 사용할 수 있게 하지는 않는다.
따라서 중요한 경계는 애플리케이션이 지원하는 연결 계약이다. 개발자는 프로토콜, 접근 방식, 실행 정책에 대한 통제권을 유지하면서 해당 계약 범위 안에서 새 기능을 허용할 수 있다. 이는 범용 플러그 앤 플레이 통합보다 더 좁지만 유용한 약속이다.
AWS Agent Registry 런타임 검색을 평가하는 독자라면, 첫 질문은 이 아키텍처가 실제로 어떤 변화를 분리하는지에 관한 것이어야 한다. 호환 가능한 기능을 추가하는 일과 기능이 실행되는 규칙을 변경하는 일은 다르다.
플랫폼 팀은 카탈로그 게시 문제를 떠안는다
AWS는 governed capability catalog를 게시 및 승인 워크플로를 갖춘 관리형 검색 서비스로 설명한다. 문서는 게시자, 큐레이터, 소비자를 구분한다. 이 역할들은 중요한 조직적 결과를 보여준다. 기능 검색에는 지속적인 소유권이 필요하다.
런타임 선택은 조정 작업을 개별 통합 릴리스에서 카탈로그 게시, 검토, 유지 관리로 옮긴다.
플랫폼 엔지니어는 가장 직접적인 압박을 받는다. 빌드 시점 연결 설정에서는 애플리케이션 저장소가 명확한 조정 지점을 제공한다. 변화하는 카탈로그에서는 어떤 기능이 함께 속하는지, 어떤 변경에 더 폭넓은 검토가 필요한지를 정의할 다른 방법이 필요하다.
기능 소유자에게는 다른 의무가 생긴다. 소비자가 언제 이를 선택해야 하는지 이해할 수 없다면, 작동하는 엔드포인트만으로는 충분하지 않다. 소유자는 다른 팀이 연결을 평가할 수 있을 정도로 의도된 작업, 중요한 제외 사항, 예상 입력값, 운영상 제약을 명확하게 설명해야 한다.
이는 팀 간 공유 인터페이스를 유지하는 일과 닮았다. 설명은 의미를 전달하고, 연결 계약은 소프트웨어가 실제로 할 수 있는 일을 결정한다. 어느 한쪽이 취약해도 조정 에이전트가 안정적으로 해결할 수 없는 혼란이 생길 수 있다.
승인에도 구체적인 목적이 필요하다. 조직은 기능을 받아들이기 전에 보안 상태, 소유권, 지원 약속, 호환성을 검토할 수 있다. 이러한 점검은 서로 다른 질문에 답하므로, 승인 라벨이 가능한 모든 보증을 뜻하는 약어가 되어서는 안 된다.
승인된 서비스라도 특정 사용자 요청에는 적합하지 않을 수 있다. 프로덕션 보고 도구는 주제와 관련이 있어도 요청한 직원이 사용할 수 없을 수 있다. 지원 기능은 정책을 설명할 수 있지만 주문을 변경할 권한은 없을 수 있다.
엔터프라이즈 구매자에게 이는 더 구체적인 조달 논의를 시사한다. 카탈로그 레코드를 누가 유지하는지, 변경을 누가 승인하는지, 게시된 기능을 사용할 수 없게 되었을 때 누가 대응하는지 물어야 한다. 관리형 검색 서비스만으로는 이러한 내부 책임을 배정할 수 없다.
같은 차이는 조직 지식에도 적용된다. 팀에는 기계가 읽을 수 있는 레코드와 함께 결정 사항, 예외, 운영 절차를 위한 공유 공간이 필요하다. searchable knowledge base는 그러한 문서화 요구를 다루며, 레지스트리는 런타임 검색을 담당한다.
압박의 핵심은 단순히 모든 것을 중앙화하는 데 있지 않다. 지나치게 광범위한 카탈로그는 거버넌스가 까다로워질 수 있고, 지나치게 분리된 카탈로그는 검색이 줄여야 할 조정 문제를 유지할 수 있다. 팀은 실제 소유권과 소비 패턴을 기준으로 경계를 선택해야 한다.
유용한 진전 지표는 릴리스 간 의존성의 감소일 것이다. 새 기능마다 여전히 오케스트레이터 편집, 공동 승인, 수동 소비자 업데이트가 필요하다면, 조직은 아키텍처적 독립성을 크게 얻지 못한 채 디렉터리만 갖게 된 것이다.
반대로 독립적인 게시가 보이지 않는 동작 변화를 뜻해서는 안 된다. 소비자는 어떤 기능이 애플리케이션의 범위 안으로 들어왔는지 이해할 방법이 필요하다. 운영상의 독립성은 소유권과 변경 커뮤니케이션이 명시적으로 유지될 때 가장 잘 작동한다.
이 루프는 검색, 연결, 실행을 분리한다
AWS Agent Registry 런타임 검색의 작동 방식은 각 단계를 별도의 결정으로 다룰 때 더 명확해진다. 관련 기능을 찾고, 연결을 설정하고, 어떤 작업을 수행할지 결정하는 일은 서로 연관되어 있다. 하지만 각각 다른 근거와 통제가 필요하다.
AWS는 의미 기반 매칭과 키워드 매칭을 결합하는 hybrid registry search를 문서화한다. 이름, 설명, 프로토콜 디스크립터는 관련성에 영향을 준다. 디스크립터는 기능과 연결 세부 정보를 설명하는 구조화된 메타데이터다.
검색 문서는 검색 가능한 결과가 승인된 레코드로 제한된다고도 명시한다. 검색 인덱싱은 최종 일관성을 가지므로, 승인된 변경 사항이 즉시 모든 곳에 표시되지는 않는다. 이러한 속성은 검색을 거버넌스 메커니즘이자 변화하는 런타임 의존성으로 만든다.
검색은 후보 집합을 좁힐 뿐이며, 애플리케이션은 여전히 유효한 연결을 설정하고 적절한 작업을 선택해야 한다.
AWS 샘플에서는 검색이 기능 호출에 필요한 인증 정보인 호출 자격 증명 없이 연결 메타데이터를 반환한다. 애플리케이션은 자격 증명을 별도로 가져온다. 이후 발견된 기능으로 임시 내부 에이전트를 구성하고 요청이 끝나면 클라이언트를 해제한다.
이 분리는 관련성이 권한을 보장하지 않기 때문에 중요하다. 서비스는 요청과 매우 잘 맞을 수 있지만 애플리케이션은 접근할 수 없을 수 있다. 반대로 애플리케이션은 현재 작업을 처리해서는 안 되는 서비스에 유효한 자격 증명을 가지고 있을 수 있다.
따라서 애플리케이션이 관련 클라이언트를 구성하는 인스턴스화 단계는 통합 경계로 이해해야 한다. 소프트웨어는 디스크립터를 해석하고, 연결 유형을 인식하며, 확립된 인증 경로를 적용해야 한다. 검색 결과가 이러한 점검을 대체할 수는 없다.
실행 단계는 또 다른 경계를 만든다. 지원 기능을 선택했다고 해서 애플리케이션이 정보를 조회해야 하는지, 변경을 제안해야 하는지, 실제로 변경을 수행해야 하는지가 결정되는 것은 아니다. 조직은 검색 관련성이 이를 표현할 것으로 기대하기보다 실행 정책에서 이러한 차이를 정의해야 한다.
가상의 환불 요청은 그 차이를 보여준다. 검색은 정책 전문 기능과 주문 정보 서비스를 식별할 수 있다. 애플리케이션은 여전히 고객 신원을 확인하고, 올바른 거래를 조회하며, 자격 요건 안내와 환불 실행 권한을 구분해야 한다.
이 아키텍처가 매력적인 이유는 요청에 대해 모델이 보는 범위를 좁힐 수 있기 때문이다. 동시에 상류 의존성도 만든다. 모델이 기능을 선택하려면 먼저 올바른 기능이 후보 집합에 들어와야 한다. 아무리 뛰어난 모델이라도 제공되지 않은 통합을 선택할 수는 없다.
이는 단계를 분리해 평가해야 함을 시사한다. 후보 누락은 검색 문제다. 거부된 연결은 인증 또는 호환성 문제다. 연결 성공 후 부적절한 작업은 실행 문제다. 이를 하나의 실패 범주로 묶으면 개선 대상을 정하기가 더 어려워진다.
이 루프는 이전 결과를 재사용하는 캐싱이 정책 선택이 되는 지점도 명확히 한다. 검색 결과를 재사용하면 반복 작업을 줄일 수 있지만, 팀은 최신성 및 기능 철회가 그 선택에 어떤 영향을 미치는지 결정해야 한다. 적절한 균형은 애플리케이션의 결과에 따라 달라진다.
Anthropic의 도구 검색은 더 광범위한 아키텍처 전환을 보여준다
AWS는 클라우드 카탈로그 관리에 그치지 않는 문제를 다루고 있습니다. Anthropic의 온디맨드 도구 검색은 도구 정의가 관련성을 갖게 될 때까지 지연하는 방식을 설명합니다. 핵심 개념은 생성 과정에서 모델이 이용할 수 있는 정보인 컨텍스트에 전체 기능 라이브러리를 모두 넣지 않는 것입니다.
Anthropic이 공개한 접근 방식은 선택한 정의에 지연 로딩을 표시합니다. 그러면 Claude는 관련 도구를 검색하고 필요할 때 해당 정의를 받을 수 있습니다. 이는 두 접근 방식을 상호 대체 가능한 제품으로 취급하지 않으면서 AWS의 방향을 이해하는 데 유용한 맥락입니다.
공통된 설계 원칙은 선택적 노출이지만, 통합 책임은 각 시스템에 맞게 구체적으로 남아 있습니다.
이 비교는 근본적인 아키텍처 선택과 벤더 포지셔닝을 구분하는 데 도움이 됩니다. 팀은 모든 도구를 처음부터 로드하는 것이 낭비라는 데 동의하면서도, 가장 중요한 워크플로에는 명시적 연결을 선호할 수 있습니다. 선택적 노출이 모든 애플리케이션 결정을 동적으로 만들어야 한다는 의미는 아닙니다.
이 비교는 과장된 새로움 주장도 막아 줍니다. 런타임 검색은 늘어나는 기능 라이브러리를 관리하려는 더 넓은 노력의 일부입니다. AWS 사례는 업계가 이제야 이 문제를 발견했다는 주장을 뒷받침하기보다, 구체적인 엔터프라이즈 패턴을 제시합니다.
플랫폼 팀에 중요한 질문은 카탈로그 결정이 어디에 속하느냐입니다. 일부 애플리케이션에는 별도로 관리되는 기능 전반을 아우르는 중앙 거버넌스 디렉터리가 필요합니다. 다른 애플리케이션은 기존 도구 라이브러리가 모델의 가용 컨텍스트를 압도하지 않도록 유지하는 것이 주된 필요일 수 있습니다.
이러한 요구 사항은 겹치지만 동일하지는 않습니다. 더 작은 프롬프트가 자동으로 승인 워크플로를 제공하는 것은 아닙니다. 거버넌스가 적용된 카탈로그가 특정 모델이나 작업에 가장 적합한 선택 전략을 자동으로 결정하는 것도 아닙니다.
명시적 연결을 지지하는 가장 강력한 주장 역시 공정하게 검토할 가치가 있습니다. 워크플로에 안정적인 순서와 제한된 기능 집합이 있다면 개발자는 의도한 연결을 직접 검토할 수 있습니다. 런타임 검색은 또 하나의 결정 지점을 정당화할 만큼 분명한 이점을 제공해야 합니다.
가상의 예약 조정 프로세스는 그 사례를 보여 줍니다. 애플리케이션이 항상 레코드를 가져오고, 비교한 뒤, 승인된 보고서를 작성한다면 매번 같은 기능을 검색하는 일은 별다른 가치를 더하지 못할 수 있습니다. 순서 자체가 이미 비즈니스 요구 사항을 표현하고 있기 때문입니다.
범용 어시스턴트는 다른 상황에 놓입니다. 요청은 서로 관련 없는 작업에 걸칠 수 있고, 가용 기능은 독립적으로 변화하는 팀에 속할 수 있습니다. 완전하고 명시적인 인벤토리를 유지하는 일이 반복적인 조정 작업을 만든다면 런타임 선택은 더 설득력을 얻습니다.
이는 실용적인 평가 원칙을 시사합니다. 동일한 작업과 변경 시나리오를 기준으로 아키텍처를 비교해야 합니다. 일상적 실행, 기능 추가, 장애, 복구를 포함해야 합니다. 설득력 있는 시연은 유연성이 본질적으로 가치 있다고 가정하기보다 동적 선택이 어디에서 도움이 되는지 보여 줘야 합니다.
구매자는 카탈로그 규모만으로 아키텍처를 판단하는 것도 피해야 합니다. 더 중요한 질문은 카탈로그가 변해도 유용한 기능이 계속 발견 가능하고 올바르게 적용되는지입니다. 일반적인 요청에도 여전히 수동 라우팅이 필요하다면 인상적인 인벤토리의 가치는 제한적입니다.
검색 품질에는 별도의 프로덕션 증거가 필요하다
가장 중요한 불확실성은 시연을 넘어선 동작과 관련됩니다. AWS의 워크스루는 이 루프를 보여 주지만, 특정 엔터프라이즈 카탈로그가 어떻게 작동할지는 입증하지 않습니다. 프로덕션 주장은 아키텍처 다이어그램이 아니라 대표성 있는 평가에 기반해야 합니다.
검색 API는 관련성 순으로 정렬된 일치 메타데이터를 반환하며 구조화된 필터링을 지원합니다. 따라서 후보 집합은 관찰 가능한 애플리케이션 출력이 됩니다. 팀은 모델이 다음에 무엇을 했는지 조사하기 전에 검색이 무엇을 반환했는지 검토할 수 있습니다.
프로덕션 평가는 어떤 기능도 사용해서는 안 되는 요청을 포함해, 검색이 필요한 기능을 제공하는지 측정해야 합니다.
그럴듯한 결과와 충분한 결과의 차이부터 구분해야 합니다. 청구 전문가는 주문 관련 질문에 적절해 보일 수 있지만, 답변에 필요한 배송 정보가 없을 수 있습니다. 평가자는 관련 설명이 있는 결과를 받아들이는 대신 완료에 필요한 기능을 식별해야 합니다.
모호한 요청은 특히 주의가 필요합니다. 사용자가 “내 주문을 수정해 주세요”라고 요청할 때 이는 주소 변경, 청구 정정 또는 파손 상품 신고를 의미할 수 있습니다. 안전한 애플리케이션은 강력한 검색 일치를 확정된 의도로 해석하는 대신, 언제 명확화가 필요한지 인식해야 합니다.
부정 사례도 마찬가지로 중요합니다. 카탈로그에 적절한 기능이 없으면 일부 요청은 연결을 생성하지 않아야 합니다. 사용자의 권한이 없거나 요청한 작업이 애플리케이션 범위를 벗어나기 때문에 중단해야 하는 요청도 있습니다.
카탈로그 성장은 명시적인 테스트 조건이 되어야 합니다. 팀은 중복되는 기능을 추가하거나 설명을 수정하거나 서비스를 종료한 후 같은 평가를 반복할 수 있습니다. 이는 오케스트레이터의 소스가 변하지 않았더라도 일반적인 유지보수 변경이 요청을 다르게 라우팅하는지 드러낼 것입니다.
홍보성 표현을 부추기지 않고 설명 품질도 평가해야 합니다. 게시자는 자신의 기능이 검색되도록 만들 유인이 있습니다. 검토자는 서비스가 인접한 모든 작업을 처리한다고 주장하는 설명보다 정확한 범위와 제외 사항을 우선해야 합니다.
검색과 인증의 분리는 테스트할 유용한 장애 사례를 만듭니다. 관련 기능에 만료된 자격 증명이 있거나, 엔드포인트를 사용할 수 없거나, 응답이 호환되지 않을 수 있습니다. 애플리케이션은 덜 적합한 작업으로 조용히 대체하지 않고 이러한 제한을 설명해야 합니다.
복구 역시 동등한 수준의 검토가 필요합니다. 정보 조회 재시도는 비즈니스 레코드를 변경하는 요청 재시도와 다릅니다. 팀은 자동 복구가 동일 작업을 다시 실행하도록 허용하기 전에 해당 작업을 반복해도 안전한지 판단해야 합니다.
운영 증거는 요청을 선택된 기능 및 최종 결과와 연결해야 합니다. 그렇지 않으면 유창한 답변이 실패한 조회, 의도하지 않은 대체 처리 또는 완료되지 않은 작업을 가릴 수 있습니다. 검토자에게는 응답 품질뿐 아니라 실행에 관한 증거도 필요합니다.
평가가 실패할 때 책임 소재 문제도 있습니다. 책임 주체는 기능 게시자, 카탈로그 큐레이터 또는 애플리케이션 팀일 수 있습니다. 이러한 책임을 일찍 정의하면 부서 간 런타임 선택을 더 쉽게 운영할 수 있습니다.
AWS Agent Registry 런타임 검색에 대해 방어 가능한 약속은 정의된 경계 내에서의 아키텍처 유연성입니다. 더 높은 정확도, 더 낮은 운영 부담, 더 쉬운 유지보수는 각 배포 환경에서 입증해야 할 결과로 남아 있습니다.
마이그레이션, 카탈로그 성장, 독립적 게시를 주시하라
즉각적인 관찰 지점은 구체적입니다. AWS의 레지스트리 마이그레이션 가이드에 따르면 전용 agent-registry 네임스페이스는 2026년 8월 6일에 출시되었습니다. 네임스페이스는 인터페이스와 구성 전반에서 사용하는 서비스 식별자입니다. 프리뷰 bedrock-agentcore 레지스트리 네임스페이스 지원은 10월 30일에 종료됩니다.
이 가이드는 서비스 엔드포인트, 권한, 클라이언트, 리소스 식별자 및 관련 구성에 영향을 미치는 변경 사항을 설명합니다. 그 밖의 AgentCore 기능은 이 레지스트리 네임스페이스 변경의 영향을 받지 않는다고 명시합니다. 따라서 기존 프리뷰 사용자에게 마이그레이션은 단기적인 운영 과제입니다.
다음 증거는 마이그레이션 완료, 카탈로그 성장 중 안정적인 검색, 불필요한 오케스트레이터 변경을 피하는 기능 추가를 보여 줘야 합니다.
먼저, 프리뷰 사용자가 마이그레이션을 완료하고 검색 경로를 검증하는지 지켜봐야 합니다. 성공적인 구성 업데이트 뒤에는 의도한 애플리케이션이 승인된 기능을 계속 찾아 호출할 수 있다는 증거가 뒤따라야 합니다. 이는 운영 연속성에 대한 신뢰를 높일 것입니다.
마이그레이션 실패가 그 자체로 런타임 선택을 무효화하는 것은 아닙니다. 하지만 변화하는 관리형 인터페이스에 의존할 때의 유지보수 요구를 드러낼 수는 있습니다. 팀은 서비스 마이그레이션 문제와 검색 또는 실행 설계의 취약점을 구분해야 합니다.
둘째, 요청 집합을 고정한 채 카탈로그를 확장하는 평가를 주시해야 합니다. 더 많은 중복과 모호성에도 필요한 기능이 계속 발견되는지가 유용한 신호입니다. 성공 사례만 보고하면 핵심 확장성 문제는 해결되지 않은 채 남습니다.
선택 품질 악화의 증거는 추가 통제 없이 광범위하게 배포해야 한다는 주장을 약화시킬 것입니다. 이는 설명 표준, 카탈로그 경계, 필터링 또는 평가 관행을 수정해야 함을 시사합니다. 카탈로그 확장은 테스트할 가치가 있는 동작 변경으로 다뤄야 합니다.
셋째, 독립적인 팀이 일상적인 오케스트레이터 편집 없이 호환 가능한 기능을 게시할 수 있는지 지켜봐야 합니다. 이는 연결을 빌드에서 분리함으로써 암시되는 조직적 효과입니다. 가장 강력한 증거는 단순한 게시가 아니라 온보딩, 인증 설정, 소유권 및 철회를 포함할 것입니다.
추가 과정에서 조정 애플리케이션의 특별 처리가 반복적으로 필요하다면, 이 아키텍처는 다이어그램이 시사하는 것보다 독립성이 낮을 것입니다. 팀이 예측 가능한 동작을 유지하면서 기능을 추가할 수 있다면 런타임 검색은 릴리스 조정에 측정 가능한 변화를 가져온 셈입니다.
이러한 신호는 자율 에이전트에 관한 광범위한 예측보다 더 중요합니다. 이는 설계를 관찰 가능한 엔지니어링 결과, 즉 마이그레이션 중 연속성, 성장 중 신뢰할 수 있는 선택, 기능 변경 시 줄어드는 조정과 연결합니다.
초기 평가에서는 기능 소유권이 이미 여러 팀에 걸쳐 있는 범위가 제한된 워크플로를 선택하십시오. AWS Agent Registry 런타임 검색을 도입하기 전에 현재 릴리스 종속성과 장애 동작을 설정하십시오. 대표 요청, 예상 기능, 허용할 수 없는 작업을 명확히 유지하십시오. 일반 요청을 모호한 질문, 누락된 서비스 및 거부된 접근과 비교하십시오. 그런 다음 호환 가능한 기능을 도입하고 게시, 승인, 인증, 검색 및 실행 전반에서 실제로 무엇이 바뀌는지 살펴보십시오. 향후 유지관리자가 경계를 이해할 수 있도록 기술적 결정과 함께 결과를 보존하십시오. 카탈로그를 확장하기 전에 애플리케이션이 그 동작에 책임진 사람들이 여전히 이해할 수 있는 상태를 유지하면서 확장하기 쉬워졌는지 물어보십시오.
