상세 컨텐츠

본문 제목

Agents Companion (6): 에이전트의 제품화? 에이전트에서 계약자로, From agents to contractors

IT/Agentic AI

by HarimKang 2025. 5. 8. 20:10

본문

이전 글에서는 기업의 에이전트 사용에 대해 알아보았습니다. 이제 우리는 AI 에이전트의 중요한 발전 방향 중 하나인 '계약(Contract)' 개념을 도입한 '계약 이행 에이전트(Contract adhering agents)'에 대해 살펴보겠습니다.

이 블로그 글 시리즈의 첫 글에 작성한 것처럼, 현재 다양한 도구 및 플랫폼에서 AI 에이전트를 정의하는 일반적인 인터페이스는 목표, 텍스트 지침, 사용할 수 있는 도구, 예제 등으로 매우 단순합니다. 이러한 단순한 정의는 시제품(prototype) 데모에는 충분할 수 있지만, 정의가 불충분하여 AI 에이전트가 시제품 단계에서 실제 운영(production) 단계로 나아가는 데 어려움을 겪는 주요 원인 중 하나가 될 수 있습니다.

이런 제품화 과정을 위해서 해당 문서에서는 복잡하고 중요한 작업(high-stakes)을 AI 에이전트를 사용하여 해결하는 맥락에서, 에이전트 인터페이스를 "계약 이행 에이전트"로 발전시킬 것을 제안하고 있습니다.

계약(Contracts)이란 무엇인가? 🤝

'계약자(Contractors)'의 핵심 아이디어는 요청자와 에이전트 간의 '계약'을 명시하고 표준화하는 것입니다. 이는 다음과 같은 가능성을 제공합니다:

  • 결과물 명확화: 실제 세계에서 어떤 서비스를 제공하는 회사와 계약할 때와 유사하게, 기대하는 결과물을 가능한 한 정확하게 정의합니다. 이를 통해 에이전트(계약자)는 원하는 결과물을 기준으로 검증하고, 목표가 달성될 때까지 반복하여 작업을 수행할 수 있습니다. (-> 결과물의 정의? 기존에 사용하던 시스템 프롬프트와는 뭐가 다른가..? 똑같나..?)
  • 작업 협상 및 구체화: 작업 정의의 모호함을 피하고 목표에 대한 공통 이해의 간극을 메우기 위해, 작업을 협상하고 명확하게 구체화할 수 있도록 합니다.
  • 하위 계약 생성 규칙 정의: 복잡한 문제를 해결하기 위해 필요한 새로운 하위 계약을 표준화된 방식으로 생성하는 규칙을 정의합니다.

이것만 봐서는 기존의 프롬프트를 자세히 쓰는거랑 뭐가 다르지 싶다. 프롬프트 엔지니어링..? 예제 코드가 없어서 꽤나 헷갈린다..

계약 라이프사이클 (Contract Lifecycle) ✨

계약 정의(Defining), 협상(Negotiating), 실행(Executing)의 라이프사이클은 다음과 같습니다:

계약 정의 (Contract Define)

계약의 초기 정의에는 다음과 같은 필드가 포함될 수 있습니다:

  • Task/Project description (필수): 계약자가 달성하기를 기대하는 작업에 대한 상세 설명. 가능한 한 구체적이고 명확해야 합니다.
  • Deliverables & Specifications (필수): 계약 작업의 예상 결과물 및 명세에 대한 정확한 설명. 결과물이 허용 가능한 기준과 검증 방법에 대한 세부 정보를 포함합니다.
  • Scope (선택): 계약자가 책임지는 작업의 범위 명확화. 작업의 모든 측면에 대한 세부 정보를 포함하며, 범위 외의 사항도 명시합니다.
  • Expected Cost (필수): 작업 완료에 대한 예상 비용. 작업 복잡성과 사용될 도구에 따라 결정됩니다. (-> 이게 정의가 될 수 있는가..? min/max를 세탕하는게 아닌가..?)
  • Expected Duration (필수): 작업 완료 예상 기간. (-> 이것도 마찬가지..)
  • Input Sources (선택): 작업 완료에 유용하게 사용될 수 있는 입력 소스를 지정합니다.
  • Reporting and Feedback (필수): 피드백 루프의 형태를 명시합니다. 진행 상황 업데이트 빈도와 피드백 메커니즘(이메일, API 등)을 정의합니다.

계약 수정 및 반복: 피드백 및 협상 (Contract Revision & Iteration: Feedback & Negotiation)

계약이 진행되는 동안 피드백 및 협상을 위한 필드는 다음과 같습니다:

  • Underspecification (선택): 작업 시작자가 불충분하게 정의했거나 명확화가 필요한 부분을 강조합니다.
  • Cost negotiation (선택): 작업 완료 비용이 너무 높다고 판단될 경우 협상합니다.
  • Risk (선택): 계약 이행의 잠재적 위험을 강조합니다.
  • Additional input needed (선택): 계약 이행에 유용할 추가 데이터나 정보의 종류를 요청합니다.

계약 실행 (Contract execution) 📝

이 단계는 계약자 런타임이 정의된 명세에 따라 계약을 이행하고 작업을 해결하는 능력을 요구합니다. 낮은 지연 시간(latency)보다 품질과 완전성(quality and completeness)을 우선시하여 LLM의 기능을 최대한 활용할 수 있습니다. 예를 들어, 다양한 솔루션을 생성하고 이를 검토, 평가 및 발전시키는 방식입니다. 엔진은 제공된 기대를 기반으로 결과물에 대해 반복하고 자체적으로 검증하며, 검증 조건이 충족될 때까지 개선하고 자체 수정할 수 있습니다. 객관적인 기준에 대해 솔루션을 구체적으로 검증하는 능력은 AI 맥락에서 매우 효과적임이 입증되어있다고 합니다. (-> 흠..)

계약 협상 (Contract Negotiation) 🤝

자동화 에이전트 맥락에서 계약의 핵심 가설 중 하나는 엔터프라이즈 세계의 많은 작업이 지연 시간 및 비용 제약이 덜한 방식으로 LLM의 힘을 활용할 때 상당한 이점을 얻을 수 있다는 것입니다. 점점 더 복잡한 작업을 해결하고 고객이 계약자의 결과를 신뢰할 수 있도록 하는 것은 기업에 진정한 가치를 제공할 것입니다. 그렇더라도 작업이 적절하게 우선순위가 지정되고 리소스가 공정하게 할당되도록 하기 위해 상대적 우선순위에 대한 개념이 필요합니다. 따라서 계약 개시자와 계약자 간에 논의 및 협상될 수 있는 비용(일반적으로 고객 또는 계약 개시자별 상대적) 개념을 도입하여, 계약이 계약 개시자가 시작한 다른 계약에 비해 적절한 리소스를 받을 수 있도록 합니다. 계약자는 명세 및 결과물과 같은 계약의 다른 측면도 협상할 수 있습니다.

계약 피드백 (Contract Feedback) 📢

계약은 피드백을 제공하고 특히 모호성을 해결하기 위한 수단을 제공합니다. 작업이 점점 더 복잡해짐에 따라, 작업 명세와 관련된 모호성이나 기타 문제를 가능한 한 조기에 제기하는 것이 중요합니다. 계약자는 계약을 받은 직후(초기 계약 평가) 및 계약에 미리 정의된 빈도로 피드백을 제공할 수 있습니다. 이 피드백에는 명확화 요청 또는 작업의 불충분한 정의 또는 잘못된 정의(불일치, 충돌하는 명세, 명확화 등)에 대한 다른 유형의 피드백이 포함됩니다.

하위 계약 (Subcontracts) 🌳

계약 정의 및 명세의 직접적인 부분은 아니지만, 작업을 하위 작업으로 분해하여 하위 계약을 생성하는 능력은 계약자 엔진을 구동하는 핵심 개념이 될 것입니다. 직접 다루기에는 너무 복잡하다고 간주되는 작업이 있을 때, 계약자는 해당 작업을 더 작고 쉬운 작업으로 분해하기로 결정할 수 있으며, 이 작업은 해결을 위한 실행 대기열에 추가됩니다. 이는 위에 설명된 계약 공식화를 통해서만 가능하며, 이를 통해 계약자는 다른 계약을 균일하고 표준화된 방식으로 생성, 처리 및 조작할 수 있습니다.

(-> 결국 복잡하고 중요한 작업을 에이전트에게 맡기려면, 단순히 명령하는 것을 넘어 더 구조화되고 협상 가능한 '계약' 형태의 인터페이스가 필요하다는 이야기인 것 같다. 현실에서 외주를 맡기면서 계약서를 작성하는 것과 유사한 것 같다. 하지만 예제 인터페이스는..?)


이번 편에서는 에이전트의 신뢰성과 유용성을 한 단계 높이기 위한 계약 이행 에이전트의 개념과 그 구성 요소, 라이프사이클에 대해 알아보았습니다. 다음편에서는 자동차 AI 예제를 바탕으로 Multi Agent 구성에 대해 알아보는 Automotive AI 파트에 대해서 살펴보겠습니다.

https://davinci-ai.tistory.com/68

 

Agents Companion (7): Automotive AI, 멀티 에이전트 아키텍처 적용 사례

이전 글에서는 에이전트에 '계약' 개념을 도입한 '계약 이행 에이전트'에 대해 살펴보았습니다. 이번 글에서는 이러한 AI 에이전트 기술이 실제 기업 환경에서 어떻게 활용될 수 있는지, 특히 자

davinci-ai.tistory.com

(해당 글은 구글의 Agents Companion White Paper 내용을 정리한 문서이며, 일부 필요에 따라 내용을 재배치하였습니다.)

반응형

관련글 더보기