구글 AX가 오픈소스라면, 구글은 무엇을 얻을까

핵심 요약

• ‘구글 AX’의 공식 공개 여부와 구체적인 기능은 확인이 필요한 주장입니다.
• 에이전트 실행기는 AI가 도구를 호출하고 작업을 이어가는 순서를 관리합니다.
• 실행기를 공개하면 클라우드 사업자는 유료 인프라 수요를 늘릴 기회를 얻을 수 있습니다.
• 도입할 때는 라이선스뿐 아니라 외부 서비스에 얼마나 의존하는지, 다른 환경으로 옮기는 데 비용이 얼마나 드는지도 살펴야 합니다.

AI가 회의록을 요약하는 것과 후속 업무까지 처리하는 것은 다른 문제입니다. 담당자를 찾아 업무를 등록하고 결과까지 확인하려면, 답변을 만드는 기능 외에 실행 과정을 관리할 장치가 필요합니다. 다만 ‘구글 AX’의 공식 공개 여부와 기능은 확인이 필요한 주장입니다. 여기서 설명하는 사업적 의미를 구글이 확정한 출시 목적으로 받아들여서는 안 됩니다.

에이전트 실행기는 어떤 일을 할까요?

오케스트레이터는 여러 작업이 정해진 흐름대로 진행되도록 조율하는 소프트웨어입니다. 에이전트 환경에서는 AI 모델을 외부 도구와 연결하고, 작업이 어디까지 진행됐는지 관리할 수 있습니다.

예를 들어 AI에게 “고객 문의를 확인하고 환불 가능 여부를 안내해 주세요”라고 맡겼다고 해보겠습니다. 주문 조회를 마쳐야 환불 조건을 판단할 수 있습니다. 조회에 실패하면 다시 시도하거나 사람에게 업무를 넘겨야 합니다.

이때 모델은 다음에 무엇을 할지 제안할 수 있습니다. 실행기는 도구를 호출한 뒤 그 결과를 다음 단계로 전달합니다. 실제 환불처럼 중요한 작업을 하려면 별도로 권한을 확인하거나 승인을 받는 절차도 필요합니다.

이 과정에서 실행 상태를 기록하는 일이 중요합니다. 어디까지 처리했는지 남겨두지 않으면 중단된 작업을 처음부터 반복할 수 있습니다. 결제나 메시지 발송이 포함된 업무라면 같은 작업을 두 번 실행하는 문제가 생길 수도 있습니다.

이는 에이전트 실행기에 일반적으로 요구할 수 있는 기능을 설명한 것입니다. AX가 이런 기능을 제공한다는 뜻은 아닙니다.

실행기를 공개하면 어디서 돈을 벌까요?

구글 같은 클라우드 사업자에게는 실행기 코드 외에도 수익을 낼 여지가 있습니다. 코드를 공개하더라도 그 위에서 업무를 돌리려면 서버와 저장 공간이 필요합니다. 모델을 호출하고 실행 기록을 보관하는 데도 비용이 들 수 있습니다.

개발자가 공개된 실행기를 쉽게 도입하고, 이를 운영하면서 해당 회사의 유료 서비스를 선택한다면 사업 기회가 생깁니다. 실행기를 쓰는 곳이 늘면서 인프라 수요도 커질 수 있는 셈입니다.

예를 들어 개발 단계에서는 노트북으로 충분했던 에이전트도 여러 직원이 함께 쓰기 시작하면 운영에 필요한 조건이 달라집니다. 접근 권한을 나누고 실패한 작업을 추적해야 합니다. 이때 이런 기능을 직접 만들지, 관리형 서비스를 구매할지 결정하게 됩니다.

실행기 공개에는 개발자의 시작점을 확보한다는 전략적 의미가 있을 수 있습니다. 다만 이렇게 사업적 의미를 해석할 수 있다는 것이지, 구글이 AX를 통해 이런 목적을 추구한다고 확인된 것은 아닙니다.

개발자가 익숙해진 방식에도 가치가 있습니다

인프라를 고를 때 제품의 기능표만 보는 것은 아닙니다. 팀이 이미 익힌 개발 방식과 그동안 쌓아온 운영 경험도 선택에 영향을 줍니다.

특정 실행기로 업무를 만들다 보면 도구 연결 코드와 배포 설정이 쌓이고, 장애에 대응하는 절차도 자리 잡습니다. 다른 실행기로 옮기려면 이 가운데 얼마나 다시 쓸 수 있는지 따져야 합니다. 코드를 바꾸는 것보다 팀의 운영 방식을 바꾸는 일이 더 클 수도 있습니다.

오픈소스로 공개하면 개발자가 도입을 검토하기 쉬워질 수 있습니다. 내부 동작을 살펴보고 직접 시험할 수 있기 때문입니다. 사용자가 문제를 보고하거나 개선 작업에 참여할 수도 있습니다.

하지만 코드를 공개한다고 생태계가 저절로 만들어지지는 않습니다. 문서를 쉽게 이해할 수 있고 변경 사항을 예측할 수 있어야 합니다. 외부 기여를 실제로 받아들이는지도 중요합니다. 저장소를 공개하는 일과 여러 조직이 믿고 쓸 수 있는 기반을 만드는 일은 그만큼 차이가 있습니다.

도입할 때는 의존성과 실패 처리를 살펴야 합니다

오픈소스라는 설명을 봤다면 먼저 라이선스를 살펴야 합니다. 코드를 볼 수 있다는 사실만으로는 어떤 조건에서 사용하거나 수정할 수 있는지, 재배포는 가능한지 알 수 없습니다.

그다음에는 외부 서비스에 얼마나 의존하는지 살펴야 합니다. 실행기 자체는 설치할 수 있어도 중요한 기능이 특정 회사의 서비스에 묶여 있을 수 있습니다. 다른 모델이나 저장소로 바꿀 때 어느 부분을 수정해야 하는지 확인해야 합니다.

간단히 점검하려면 작업 하나를 다른 환경에서 실행해보면 됩니다. 예를 들어 문서를 읽고 요약을 저장하는 작업에서 모델이나 저장 위치를 바꿔보는 식입니다. 이렇게 해보면 설정만 바꾸면 되는지, 업무 코드를 다시 작성해야 하는지 알 수 있습니다.

작업에 실패했을 때 어떻게 처리하는지도 살펴야 합니다. 도구 호출이 중간에 끊기면 어디서 다시 시작하는지, 재시도할 때 같은 작업을 중복 실행하지는 않는지 확인해야 합니다. 시연이 성공했을 때뿐 아니라 이런 상황에서도 실행기가 제 몫을 하는지 드러납니다.

실행기를 공개하는 사업자는 개발자가 업무를 만들 때 처음 선택하는 자리를 차지할 수 있습니다. 도입하는 팀에서는 그 도구가 운영 부담을 얼마나 줄여주고, 나중에 다른 선택을 할 여지를 얼마나 남기는지 따져야 합니다. 실행기를 고를 때는 첫 시연의 편리함과 일 년 뒤 다른 환경으로 옮기는 데 드는 비용을 함께 비교할 필요가 있습니다.