AI Copilot가 '설명만' 하고 끝나지 않기 위해: Tool Calling과 API 연동의 구현 설계

• AI 에이전트가 '설명만 하는 것'에서 '실제로 시스템을 조작하는 것'으로 나아가기 위해 필요한
  Tool Calling 구현 설계 - 읽기 전용 도구와 액션 도구의
  리스크 분류와 거버넌스 방침 - API를 안전한 실행 채널로 설계하기 위한
  4가지 제어 포인트 - 툴 카탈로그(Tool Registry)를 통한
  운영 관리의 스케일링 - 흔한 실패 패턴과 그 회피책

당신의 팀에 AI Copilot이 도입되었다고 가정해 보자. 청구서가 정체되어 있는 이유를 물으면, 발주서와 수령서, 그리고 벤더(Vendor)로부터 온 이메일 사이의 불일치를 친절하게 설명해 준다. 팀은 납득한다. 문제는 파악되었다. 그리고 당연하게도 다음 질문이 이어진다.

"그럼, AI가 직접 수정해 줄 수 있어?"

침묵.

답은 No다. Copilot은 문제를 설명할 수는 있지만, 시스템에는 전혀 손을 댈 수 없다. ERP에서 데이터를 가져오는 것도, 발주서의 상태를 확인하는 것도, 워크플로우에 케이스를 생성하는 것도, 벤더에게 확인 요청을 보내는 것도 할 수 없다. 모든 것이 수동인 상태 그대로다.

이것이 많은 엔터프라이즈 AI 파일럿 프로젝트가 좌초되는 순간이다. 모델은 우수하고 데모는 매력적이다. 하지만 비즈니스 가치는 미미하다. 왜냐하면 AI는 '권장'에서 멈추고, '실행'에 이르지 못하기 때문이다.

대화형 Copilot과 실제로 업무를 움직이는 에이전트의 차이는 단 하나의 능력으로 집약된다. 그것이 바로 Tool Calling, 즉 외부 함수를 선택하고 호출하는 능력이다.

Tool Calling이 없는 AI는 비평가에 불과하다. Tool Calling이 있어야 비로소 AI는 실행자가 된다.

"설명"에서 "실행"으로의 전환에는 도구, 제어, 관측 가능성(Observability)의 계층적 아키텍처가 필요하다

많은 조직이 처음에 범하는 실수는 모든 도구를 동일하게 취급하는 것이다.

데이터를 읽기만 하는 도구와 데이터를 변경하는 도구 사이에는 하늘과 땅 차이가 있다.

Read-Only 도구: 청구서 상태 확인, 고객 이력 참조, 구매 정책 취득. 리스크는 '잘못된 정보'로 한정된다. 액세스 제어와 로그는 필요하지만, 폭발 반경(Blast Radius)은 작다.

Action 도구: 벤더 신규 등록, 발주서 발행, 티켓 종료, 환불 처리. 이러한 조작은 비즈니스 상태를 변화시킨다. 리스크는 직접적이고 중대하다.

이 구분은 기술적인 각주가 아니다. 거버넌스의 기반이다. 많은 기업이 Read-Only로 충분한 유스케이스에 Action 권한을 안이하게 부여해 버린다. 결과적으로 리스크가 가치를 상회하게 된다.

원칙은 간단하다. 도구 호출의 비즈니스 영향이 클수록 검증, 정책 적용, 감사 가능성(Auditability)의 요구사항은 높아진다.

Tool Calling의 구현 수단으로서 가장 건전한 채널은 API다. API는 구조화되어 있고, 문서화되어 있으며, 제어 가능한 인터페이스를 제공한다. 에이전트는 그 목적을 위해 설계된 엔드포인트(Endpoint)를 호출한다. 인간처럼 화면 위에서 '조작'하는 것이 아니다.

UI 자동화(에이전트에게 화면을 조작하게 하는 수법)의 유혹은 강렬하다. 데모에서는 잘 작동한다. 빠르게 느껴진다. 하지만 취약하다. 화면이 바뀌면 작동하지 않는다. 필드가 이동하고 라벨이 바뀔 때마다 망가진다. 액세스 제어도 어렵고, 에이전트에게 특정 조작만 허용하려면 광범위한 시스템 권한을 부여할 수밖에 없게 된다. 감사 추적(Audit Trail)도 모호하다.

운영 환경에서 에이전트를 운용한다면, API를 제1의 경로로 삼아라. UI 자동화는 통합 레이어를 현대화하기 전까지의 일시적인 가교에 불과하다. 사용한다면 명확한 보완적 제어를 동반해야 한다.

인간이 조작하는 애플리케이션에서는 안전한 API라도, 에이전트가 호출하면 이야기가 달라진다. 에이전트는 더 빠르고, 더 높은 빈도로, 때로는 자율적으로 동작한다. 에이전트가 호출할 수 있는 모든 엔드포인트를 **제어점(Control Point)**으로 취급해야 한다.

다음의 4가지 규율은 타협할 수 없는 사항이다.

에이전트에게는 필요 최소한의 액세스 권한만 부여한다. 범용적인 서비스 계정의 재사용은 금지한다. 에이전트마다 전용 자격 증명(Credential)을 갖게 한다.

에이전트는 루프나 재시도(Retry)를 통해 고빈도 호출을 생성할 수 있다. API 게이트웨이에서 적절한 스로틀링(Throttling)을 설정한다.

입력은 엄격한 스키마(Schema)를 따르게 한다. customer_id, refund_reason, amount를 기대하는 엔드포인트에 자유 형식의 텍스트를 보내게 해서는 안 된다.

모든 호출을 기록한다. 보안 사고 조사, 장애 원인 식별, 그리고 지속적인 개선을 위해서다.

구현 측면에서는 **API 게이트웨이 (API Gateway)**와 **정책 엔진 (Policy Engine)**이 필수적인 인프라가 된다. 게이트웨이는 인증, 스로틀링 (Throttling), 라우팅 (Routing)을 담당한다. 정책 엔진은 에이전트가 '실행하고 싶어' 하더라도, 비즈니스 규칙과 리스크 제어를 통과하도록 만든다.

예를 들어, 고객 서비스 환불 에이전트를 생각해보자. 건전한 설계에서는 에이전트에게 직접적인 환불 함수를 넘겨주지 않는다. 대신, **환불 가능 여부 확인 엔드포인트 (Endpoint)**를 호출하게 한다. 정책 엔진이 환불 금액의 임계값과 고객 이력을 체크한다. 기준 내에 있다면 에이전트가 자율적으로 실행한다. 임계값을 초과하면 시스템이 자동으로 상위 승인을 요청한다. 모든 단계는 로그에 남는다.

API는 단순한 기술적 커넥터가 아니다. 운영 규율을 강제하는 안전한 채널이다.

도구(Tool)의 수가 늘어남에 따라 통합 문서만으로는 불충분해진다. 필요한 것은 **Tool Registry (툴 레지스트리)**다. 이는 어떤 도구가 존재하고, 어떤 비즈니스 기능을 가지며, 누가 사용할 수 있고, 입출력 스키마 (Schema)는 무엇인지, 리스크 레벨과 가드레일 (Guardrail)은 무엇인지를 일원 관리하는 카탈로그다.

레지스트리가 없다면 각 오케스트레이터 (Orchestrator)가 개별적으로 통합을 하드코딩하게 된다. 유스케이스가 1~2개라면 몰라도, 규모가 커지면 관리가 불가능해진다.

좋은 레지스트리에는 다음 사항이 포함되어야 한다:

• 도구 이름 및 설명
• 비즈니스 오너 및 테크니컬 오너
• 대상 시스템
• 리스크 카테고리 (Read-Only / Action)
• 읽기/쓰기 모드
• 권한 모델
• 승인 요구사항 (자율 실행 / 승인 필요)
• 속도 제한 (Rate Limit)
• SLA (Service Level Agreement)
• 버전
• 운영 상태 (가동 중 / 유지보수 중 / 폐지 예정)
• 감사 훅 (Audit Hook)

조직적인 영향은 크다. 레지스트리가 존재하면 프로세스 오너는 실제로 이용 가능한 능력을 파악할 수 있다. 리스크 오너는 도구마다 자율성의 경계를 설정할 수 있다. 플랫폼 팀은 라이프사이클을 관리한다. 현장에서는 에이전트와 협업하는 방법을 훈련한다.

레지스트리는 아키텍처를 운영 모델로 변화시킨다. 에이전트에 관한 대화를 구체화한다. "어떤 도구를, 누가, 어떤 조건에서 사용할 수 있는가"를 명확히 하는 것이다.

많은 에이전트 프로그램이 실패하는 이유는 모델의 성능이 약해서가 아니다. 통합 패턴이 처음부터 잘못되었기 때문이다.

데모에서는 동작한다. 하지만 운영 환경에서는 취약하고, 과도한 권한을 가지며, 감사가 어렵다. 회피책: API를 제1 경로로 삼고, UI 자동화는 일시적인 가교 역할로 정의한다.

Read-Only 도구는 신속하게 자율 실행을 허용할 수 있다. Action 도구에는 리스크 분류, 승인 로직, 엄격한 가관측성 (Observability)이 필요하다. 회피책: 도구를 Read-Only와 Action으로 이분하여 거버넌스 레벨을 다르게 적용한다.

스키마 불일치, 중복, 유지보수 비용 증가를 초래한다. 회피책: Tool Registry를 중앙 관리하고, 에이전트는 레지스트리로부터 도구 정의를 동적으로 가져온다.

정책은 문서에 적혀 있지만, 실행 경로에는 포함되어 있지 않다. 에이전트는 기술적으로 금지된 행위를 실행할 수 있다. 회피책: 정책 엔진을 API 게이트웨이 후단에 배치하여 모든 Tool Calling을 통과시킨다.

도구는 실패한다. API는 타임아웃 (Timeout)된다. 스키마는 변한다. 폴백 (Fallback)이 없으면 에이전트는 무한 재시도에 빠지거나 중단된다. 회피책: 각 도구 호출에 타임아웃, 재시도 상한, 폴백 동작 (인간에게 에스컬레이션 등)을 정의한다.

이 글에서 단 하나만 가져간다면, 이것이다.

에이전트는 감사 가능한 인터페이스를 통해서만 행동해야 한다.

무제한적인 UI 접근을 통해서가 아니다. 과도한 권한을 가진 서비스 계정을 통해서도 아니다. 스키마가 없는 도구를 통해서도 아니다. 흔적을 남기지 않는 통합을 통해서도 아니다.

감사 가능한 인터페이스란, **식별자, 권한, 입출력 계약, 정책 적용, 로그, 가관측성, 킬 스위치 (Kill Switch)**를 갖춘 것을 의미한다.

이 원칙이 중요한 이유는, 에이전트 AI가 '지능'의 문제가 아니라 '신뢰'의 문제이기 때문이다. 이 AI에게 회사의 운영을 맡길 수 있는가?

CIO에게 있어 API 현대화 (API Modernization)는 그 어느 때보다 전략적인 과제가 된다. COO에게는 어떤 액션 포인트 (Action Point)를 에이전트에게 개방해도 안전할지를 판단하기 위한 프로세스 재설계가 필요하다. CHRO에게 인간의 역할 변화는 어떤 도구가 사용 가능한지, 에이전트가 얼마나 안전하게 행동하는지, 그리고 어디에 인간의 제어점 (Control Point)이 남아있는지에 따라 결정된다.

자사에 다음과 같은 질문을 던져보길 바란다.

• 통합 레이어 (Integration Layer)는 기존 애플리케이션뿐만 아니라 디지털 실행 채널 (Digital Execution Channel)로서도 기능할 준비가 되어 있는가?
• 어떤 업무 액션이 진정으로 에이전트에게 위임해도 안전하며, 어떤 것을 인간의 제어 하에 두어야 하는가?
• 에이전트가 도구와 API를 통해 일상 업무를 대행하기 시작할 때, 현장 실무자와 관리직의 역할은 어디로 향하게 되는가?
• 당신은 엔터프라이즈 전체로 확장 가능한 에이전트를 구축하고 있는가? 아니면 제어가 여전히 수동이라서 그저 돌아가기만 하는 데모를 구축하고 있는가?