우리는 사람들이 소프트웨어를 단계별로 조작하는 세상에서, 사람들이 목표를 설정하면 에이전트(Agent)가 기존 시스템에 진입하여 이를 수행하는 세상으로 이동하고 있습니다. 이 에세이는 이러한 새로운 관계를 명명하기 위한 작업 개념으로 A2B, Agent-to-Business를 제안합니다.

한 팀이 "우리의 기존 비즈니스 시스템에 AI를 연결하고 싶다"라고 말할 때, 그 문장은 거의 무엇이든 의미할 수 있습니다.

제품 관리자(Product Manager)는 대화형 인터페이스(Conversational Interface)를 상상할 수 있습니다. AI 팀은 모델(Models), 검색(Retrieval), 그리고 컨텍스트(Context)를 생각할 수 있습니다. 개발자는 함수 호출(Function Calling), MCP 서버, 또는 내부 API(Internal APIs)를 생각할 수 있습니다. 보안 팀은 신원(Identity), 권한 부여(Authorization), 그리고 감사(Audit)를 생각할 수 있습니다. 비즈니스 소유자는 단순히 시스템이 주문을 읽고, 재고를 업데이트하며, 티켓을 생성하고, 환불을 처리하거나, 예약을 재조정하기를 기대할 수도 있습니다.

이러한 해석 중 틀린 것은 없습니다. 각각은 동일한 변화의 한 부분을 설명하고 있습니다.

한 문장으로 말하기 여전히 어려운 점은 바로 이것입니다:

에이전트가 사람이나 조직으로부터 목표를 전달받고, 이미 존재하는 비즈니스 시스템에 진입하여, 비즈니스 사실(Business Facts)을 읽고, 운영 경로(Operational Path)를 선택하며, 과거에는 사람이 인터페이스를 이해하고 이를 통해 행동해야 했던 작업을 완료하는 것.

만약 모든 진지한 대화에서 저 문단 전체를 반복해야 한다면, 문제는 단지 기술적 솔루션의 부재만이 아닐 수도 있습니다. 우리에게는 카테고리(Category)가 부족한 것일 수도 있습니다.

우리는 이미 복잡한 시장 관계를 압축하기 위해 B2B, B2C, B2B2C와 같은 짧은 용어들을 사용하고 있습니다. 에이전트 간의 협업을 논의하기 위해 A2A를 사용할 수도 있습니다. 하지만 에이전트가 기존 소프트웨어에 진입하여 실제 비즈니스 성과를 만들어내는 것을 설명하려고 할 때, 우리는 다음과 같은 느슨한 문구들로 되돌아갑니다: AI 통합(AI integration), 도구 사용(Tool use), LLM의 API 호출(LLM calling APIs), 기업 자동화(Enterprise automation), MCP 도입(MCP adoption), 운영을 위한 AI 어시스턴트(An AI assistant for operations).

각 문구는 해당 현상을 건드리고 있지만, 그 어느 것도 이를 완전히 식별하지는 못합니다.

이 에세이는 이를 A2B: Agent-to-Business라고 부릅니다.

A2B는 여기서 확립된 산업 표준(industry standard), 프로토콜(protocol), 또는 모두가 이미 사용하기로 합의한 제품 카테고리(product category)로 제시되는 것이 아닙니다. 이것은 하나의 **작업 개념(working concept)**입니다. 즉, 에이전트가 위임(delegation) 하에 행동하고, 기존 비즈니스 시스템으로 진입하며, 실제 운영 역량(operational capabilities)을 호출하고, 사람이나 조직이 책임을 져야 하는 결과물을 만들어내는 상황을 일컫는 명칭입니다.

이 관계에 이름을 붙이는 목적은 이미 포화 상태인 분야에 또 다른 약어(acronym)를 추가하려는 것이 아닙니다. 반복적이지만 파편화되어 있는 문제를 전체로서 검토할 수 있을 만큼 가시화하기 위함입니다.

카테고리는 집단적 사고를 위한 인프라입니다

기술 커뮤니티는 종종 언어를 실제 엔지니어링이 끝난 후에 적용되는 포장지로 취급하곤 합니다. 하지만 실제로 안정적인 카테고리는 엔지니어링 지식이 축적되는 인프라의 일부입니다.

공유된 명칭이 없다면, 문제는 개별 프로젝트 내부에만 존재할 수 있습니다. 커머스 팀은 이를 'AI 환불 어시스턴트'라고 부릅니다. CRM 팀은 '자율 영업 운영자'라고 부릅니다. HR 팀은 '직원 서비스 에이전트'라고 부릅니다. 운영 팀은 '자동화된 인시던트 처리(automated incident handling)'라고 부릅니다.

이 팀들은 자신들이 동일한 클래스의 시스템을 다루고 있다는 사실을 인지하지 못한 채, 동일한 아키텍처적 질문들에 직면해 있을 수 있습니다:

• 에이전트는 어떤 비즈니스 역량이 존재하는지 어떻게 학습하는가?
• 에이전트가 조언을 제공하는 것인가, 초안을 작성하는 것인가, 아니면 공식적인 조치를 취하는 것인가?
• 에이전트가 행동할 때 누구의 정체성(identity)이 대변되는가?
• 왜 자연어 목표(natural-language goal)가 이 특정한 일련의 운영 과정으로 변환되었는가?
• 어떤 결과가 자동으로 생성될 수 있으며, 어떤 결과가 사람에게 돌아가야 하는가?
• 결과가 잘못되었을 경우, 조직이 책임의 사슬(chain of responsibility)을 재구성할 수 있는가?

이러한 질문들이 단순한 '통합 세부 사항(integration details)'으로 남아 있다면, 모든 조직은 이를 매번 새로 발견해야만 합니다. 지식은 제품별 설정, 내부 프롬프트(internal prompts), 게이트웨이 규칙, 그리고 인시던트 보고서(incident reports) 안에 갇힌 채 머물게 됩니다.

유용한 카테고리는 이를 변화시킵니다. 이를 통해 제품 관리자(product managers), 개발자(developers), 아키텍트(architects), 보안 팀(security teams), 그리고 비즈니스 소유자(business owners)들은 자신들이 단순히 AI 기능을 추가하는 것이 아님을 깨닫게 됩니다. 그들은 의도(intention), 소프트웨어(software), 행동(action), 그리고 책임(responsibility) 사이의 새로운 관계를 설계하고 있는 것입니다.

지속 가능한 카테고리는 적어도 세 가지 속성을 가져야 합니다:

1. 압축 (Compression). 본질적인 구조를 버리지 않으면서, 수많은 반복되는 상황을 짧은 개념으로 축약할 수 있어야 합니다.
2. 구별 (Distinction). 무엇이 해당 카테고리에 속하고 무엇이 속하지 않는지, 그리고 인접한 개념들과 어떻게 다른지를 명확히 해야 합니다.
3. 생성성 (Generativity). 이전에는 공식화하기 어려웠던 질문을 던지도록 돕고, 실무에서 테스트할 수 있는 주장(claims)을 도출할 수 있어야 합니다.

따라서 A2B의 가치는 이 약어가 유행하느냐에 달려 있지 않습니다. 더 중요한 시험대는 A2B가 커머스(commerce), CRM, 헬스케어(healthcare), 공공 서비스(public services), AI 운영체제(AI operating systems), 로보틱스(robotics), 그리고 멀티 에이전트 시스템(multi-agent systems) 전반에 걸쳐 공통된 구조를 드러낼 수 있는지, 그 구조를 채팅(chat), 콘텐츠 생성(content generation), 고정된 자동화(fixed automation), 그리고 순수한 에이전트 간 협업(agent-to-agent coordination)과 구별할 수 있는지, 그리고 소프트웨어와 조직적 책임이 어떻게 변화할지 예측하는 데 도움을 줄 수 있는지 여부입니다.

만약 이러한 일을 해내지 못한다면, 그것은 단지 라벨(label)에 불과합니다. 하지만 이를 해낼 수 있다면, 그것은 인지적 도구(cognitive tool)가 됩니다.

중요한 변화는 AI가 API를 호출할 수 있다는 것이 아니다

언뜻 보기에 A2B는 "LLM이 API를 호출하는 것"을 일컫는 새로운 용어처럼 들릴 수 있습니다. 하지만 그것은 너무 피상적입니다.

소프트웨어가 소프트웨어를 호출해 온 지는 수십 년이 되었습니다. 워크플로 엔진(workflow engines), 스크립트(scripts), RPA 시스템, 스케줄러(schedulers), 그리고 통합 플랫폼(integration platforms)은 이미 주문을 업데이트하고, 재고를 동기화하며, 알림을 보내고, 승인을 트리거(trigger)합니다.

또한 현대적인 에이전트(agents)와 함께 기계가 중대한 결정을 내리기 시작한 것도 아닙니다. 알고리즘 트레이딩(algorithmic trading), 부정 결제 탐지(fraud detection), 산업 제어(industrial control), 추천 시스템(recommendation systems), 그리고 자율 주행 차량(autonomous vehicles)은 오래전부터 데이터로부터 행동을 선택해 왔습니다.

에이전트가 변화시키는 것은 기계적 행동(machine action)의 존재 여부가 아닙니다. 그들은 행동의 **범용성(generality), 개방성(openness), 그리고 접근성(accessibility)**을 변화시킵니다.

이전의 자동화된 의사결정 시스템(automated decision systems)은 대개 입력값, 목표, 상태 공간(state spaces), 그리고 사용 가능한 행동들이 사전에 정교하게 모델링된 도메인 내부에서 작동했습니다. 전문 팀이 시스템이 실행되기 전에 경로를 정의했습니다.

반면, 범용 에이전트(general-purpose agent)는 완전한 절차로 인코딩되지 않은 목표를 전달받을 수 있으며, 이질적인 도구(heterogeneous tools)를 발견하거나 선택하고, 논거를 구축하며, 중간 결과물을 검토하고, 다음 단계를 수정할 수 있습니다.

전통적인 자동화는 종종 다음과 같은 실행 경로(execution path)로 시작됩니다:

개발자가 조건을 사전 정의함
  -> 워크플로 설계자가 단계를 구성함
  -> 파라미터가 결정론적 매핑(deterministic mappings)으로부터 도출됨
...

에이전트는 오직 의도된 결과(intended outcome)만을 가지고 시작할 수 있습니다:

사람이 목표를 진술함
  -> 에이전트가 목표를 해석함
  -> 에이전트가 역량(capabilities)을 선택함
...

두 체인 모두 동일한 API를 사용할 수 있습니다. 하지만 이들은 동일한 행동 구조(action structure)를 가지고 있지 않습니다.

첫 번째는 주로 실행을 위임(delegates execution)합니다. 두 번째는 의도(intention)를 운영 경로(operational path)로 변환하는 과정의 일부를 위임합니다.

이것이 에이전트가 인간의 의지(human will), 도덕적 주체성(moral agency), 또는 법적 인격(legal personhood)을 소유한다는 의미는 아닙니다. 에이전트는 여전히 사람과 조직에 의해 배포되는 소프트웨어로 남습니다. 모델이 추론(reasoning)에 참여했다는 이유만으로 책임(responsibility)을 모델로 이전할 수는 없습니다.

하지만 중요한 공학적 사실이 변했습니다. 이제 비인간 구성 요소(non-human component)가 목표가 어떻게 운영으로 전환될지를 결정하는 과정에 참여한다는 점입니다.

AI가 주로 답변을 생성할 때, 평가는 인식론적 품질(epistemic quality)에 집중됩니다: 출력값이 정확한가, 관련이 있는가, 근거가 확실한가(grounded), 혹은 편향되었는가?

에이전트가 비즈니스 시스템에 진입하면 또 다른 차원이 나타납니다: 그 행동이 정당한가(legitimate)? 권한이 부여되었는가(authorized)? 원래의 위임 사항을 충실히 따랐는가? 중단되거나 되돌려질 수 있었는가? 결과에 대해 누가 책임을 지는가?

답변이 사실적으로는 정확할지라도, 결코 일어나서는 안 될 행동으로 이어질 수 있습니다. 매개변수(parameter)가 모든 스키마(schema) 규칙을 충족하더라도, 행위 주체(acting subject), 현재의 비즈니스 상태, 또는 권한(authority)이 잘못되었다면 그것은 부적절한 것이 될 수 있습니다.

A2B는 AI의 출력이 제도적 행동(institutional action)이 되는 경계선을 나타냅니다.

인간이 운영하는 소프트웨어에서 에이전트가 운영하는 소프트웨어로

소프트웨어 인터페이스의 역사는 대부분 사람들이 기계를 운영하는 방식을 개선하는 것에 관한 것이었습니다.

명령줄(Command lines)은 사람들이 기계 지향적 언어를 배우도록 요구했습니다. 그래픽 인터페이스(Graphical interfaces)는 작업을 창, 양식, 메뉴, 버튼으로 구성했습니다. 모바일 컴퓨팅은 이러한 인터페이스를 지속적으로 사용할 수 있게 만들었습니다. 자연어(Natural language)는 의도를 표현하는 데 필요한 노력을 줄여주었습니다.

이러한 인터페이스들은 오랫동안 공존할 것입니다. 하지만 에이전트는 방향의 변화를 가져옵니다:

소프트웨어의 직접적인 운영자가 인간에서 에이전트로 확장되고 있습니다.

익숙한 비즈니스 경로는 다음과 같습니다:

사람이 비즈니스 목표를 이해함
  -> 시스템에 로그인함
  -> 올바른 기능을 찾음
...

새롭게 등장하는 경로는 다음과 같을 수 있습니다:

사람이 비즈니스 목표를 표현함
  -> 에이전트가 이를 해석함
  -> 에이전트가 비즈니스 역량(business capability)을 선택함
...

이는 단순히 클릭을 도구 호출(tool calls)로 대체하는 것 이상의 의미를 갖습니다.

역사적으로 비즈니스 시스템은 페이지, 메뉴, 버튼을 통해 사람들에게 기능을 노출해 왔습니다. 앞으로는 구조화된 역량(structured capabilities), 기계가 읽을 수 있는 의미론(machine-readable semantics), 그리고 신뢰할 수 있는 실행 피드백(execution feedback)을 통해 에이전트에게도 기능을 노출해야 할 필요성이 점점 커질 것입니다.

대화는 인간을 위한 진입점일 뿐입니다. 결정적인 변화는 대화 이후에 일어납니다. 즉, 목표가 어떻게 비즈니스 프로세스에 진입하는지, 어떻게 행동이 되는지, 그리고 그 결과가 어떻게 인간의 책임 영역으로 돌아오는지에 관한 것입니다.

A2B가 설명하는 것

A2B는 세 가지 수준에서 이해될 수 있습니다.

일상적인 언어로 정의하자면 다음과 같습니다:

과거에는 사람들이 직접 소프트웨어를 열고 단계별 절차를 수행했습니다. A2B는 사람이 목표를 제시하면 에이전트가 기존 비즈니스 시스템에 진입하여 업무를 완수하는 과정을 설명합니다.

공학적 정의는 다음과 같습니다:

A2B는 인간 또는 조직의 위임 (delegation) 하에 동작하는 에이전트가, 기존 비즈니스 시스템이 제공하는 기능을 사용하여 비즈니스 사실을 읽고, 운영을 조직하며, 추적 가능한 비즈니스 결과물을 생성하는 상황을 설명합니다.

구조적 정의는 다음과 같습니다:

A2B는 에이전트가 소프트웨어, 조직 또는 신뢰 경계 (trust boundary)를 가로질러 실제 비즈니스 프로세스에 참여하는 관계를 의미합니다.

이 공통 구조는 세 가지 요소로 압축될 수 있습니다:

A2B = 의미론적 위임 (semantic delegation) + 경계 교차 (boundary crossing) + 제도적 결과 (institutional consequence)

의미론적 위임 (Semantic delegation)

사람이나 조직은 완전한 단계별 시퀀스 대신 목표를 제공합니다. 에이전트는 그 목표를 기능 (capabilities), 인자 (arguments), 그리고 실행 순서로 변환하는 과정에 참여합니다.

경계 교차 (Boundary crossing)

행위가 에이전트의 환경에서 벗어나 고유한 신원 (identities), 데이터, 정책 및 책임을 가진 다른 시스템으로 이동합니다. 이 경계는 애플리케이션, 기업, 공공 기관 또는 외부 신뢰 도메인 (trust domain)을 둘러싸고 있을 수 있습니다.

제도적 결과 (Institutional consequence)

결과는 단순한 모델 출력 (model output)이 아닙니다. 그것은 조직에 의해 인정되는 하나의 사실이 됩니다. 즉, 환불이 생성되었거나, 직원 기록이 변경되었거나, 예약이 취소되었거나, 신청서가 제출되었거나, 재고가 차감되었거나, 작업 지시서가 종료되는 등의 결과입니다.

제도적 결과는 쓰기 (writes) 작업에만 국한되지 않습니다. 개인적인 주문, 의료 기록, 계정 또는 직원 파일을 읽는 행위는 보호된 정보를 소유하는 주체를 변화시키며, 기밀 유지, 사용 및 추적 가능성에 대한 의무를 생성합니다. A2B의 결과에는 비즈니스 상태의 변경과 제약된 비즈니스 사실에 대한 접근이 모두 포함됩니다.

이러한 요소들은 규정적(prescriptive)인 것이 아니라 기술적(descriptive)인 것입니다. A2B라고 명명한다고 해서 모든 배포 사례가 동일한 프로토콜, 신원 형식(identity format), 승인 워크플로우(approval workflow) 또는 거버넌스 모델(governance model)을 채택해야 하는 것은 아닙니다. 이는 우선 어떤 종류의 관계가 형성되고 있는지를 우리에게 알려줍니다. 그런 다음 각 조직은 그 관계가 어떻게 관리되어야 하는지를 결정할 수 있습니다.

"비즈니스"는 상업만을 의미하지 않습니다

A2B에서 _비즈니스(Business)_라는 단어는 영리 목적의 상업뿐만 아니라, **비즈니스 시스템(business systems) 및 제도적 프로세스(institutional processes)**라는 넓은 의미로 읽어야 합니다.

관련 시스템에는 ERP, CRM, HR, 재무, 지원, 생산, 의료, 교육, 정부 및 공공 서비스 시스템이 포함됩니다. 이들의 공통된 특징은 조직에 의해 인정되는 실제 상태(real states)를 유지한다는 점입니다. 예를 들어 주문이 환불되었는지, 직원이 재직 중인지, 재고가 할당되었는지, 의료 요청이 업데이트되었는지, 허가가 승인되었는지, 또는 케이스가 종료되었는지와 같은 상태들입니다.

현대적인 비즈니스 시스템은 단순히 수동적인 정보를 저장하는 데이터베이스가 아닙니다. 그것은 제도적 규칙을 실행하는 매개체(executable carrier)입니다.