AI 에이전트 시대, AX가 기업 시스템을 재정의하다

에이전트형 AI의 핵심은 코드 작성, 스크립트 실행, 명령 수행, API 호출 등 실제 행동을 수행하는 데 있다. 이러한 작업은 해당 기능이 쉽게 탐색 가능하고, 충분히 문서화돼 있으며, 일관된 구조를 갖추고 있고, 처음부터 에이전트가 사용하기 쉽게 설계돼 있을 때 훨씬 효과적으로 이뤄진다.

에이전트는 사람과는 약간 다른 정보를 필요로 한다. 완전하고 정확하며 최신 상태의 문서나 올바른 명령어가 포함된 오류 메시지는 사람과 에이전트 모두에게 도움이 된다. 다만 예를 들어 데브옵스 에이전트는 전체 CI/CD 파이프라인에 대한 전반적인 맥락을 이해해야 하지만, 일반 개발자에게는 그 정도 수준의 전체 맥락이 항상 요구되지는 않는다.

전반적으로 비즈니스 로직, 코드, 데이터, 문서, API 설계, 정책, 모범 사례를 보다 체계적으로 관리하는 일은 사람 사용자에게도 직접적인 이점을 제공한다. 반대로 이러한 기반 작업을 소홀히 할 경우, 직원이 에이전트와 더 잘 작동하는 외부 서비스로 눈을 돌리면서 새로운 차원의 섀도우 IT가 발생할 위험이 있다.

시장조사업체 포레스터의 엔터프라이즈 아키텍처 담당 부사장 겸 수석 애널리스트 찰스 베츠는 “많은 조직이 에이전트형 AI의 가능성을 신뢰하고 도입을 검토하기 시작했지만, 이를 실제로 구현하려면 여전히 상당한 준비가 필요하다”라며 “에이전트에는 정밀하고 구조화돼 있으며 접근 가능한 정보가 요구된다”고 설명했다. 이어 “시스템에 대한 이해가 부족하면 AI 에이전트는 심각하게 혼란스러운 상태에 빠질 수 있다”고 분석했다.

에이전트 경험 최적화

넷리파이(Netlify)의 CEO 마티아스 빌만은 기존 엔터프라이즈 시스템을 에이전트에 맞게 준비하는 과정을 ‘에이전트 경험(AX)’이라고 정의한다. 이는 에이전트가 제품이나 플랫폼의 사용자로서 실제로 마주하는 경험 전반을 의미한다.

이미 모든 제품과 도구에는 각자의 에이전트 경험이 존재한다. AI 에이전트가 이미 이들 시스템을 사용하려 시도하고 있기 때문이다. 빌만은 “문제는 에이전트 경험이 좋은지, 나쁜지의 차이일 뿐”이라고 설명했다.

조직이 의존하는 제품이나 서비스에 에이전트가 함께 작동하길 기대한다면, 해당 시스템이 구조화되고 예측 가능한 인터페이스를 갖추고 있는지 점검해야 한다. 또한 포괄적인 오류 처리 기능, 여러 단계로 구성된 워크플로를 지원하는 세션 지속성, 실시간 피드백 제공 기능도 중요하다. 이런 요소가 갖춰져야 에이전트가 안정적으로 작업을 수행할 수 있다.

빌만은 “에이전트가 제품을 어떻게 발견하는가가 출발점”이라며 “사용자가 알려줘야 하는지, 아니면 에이전트가 스스로 적절한 해결책이라고 판단하는지 고민해야 한다”고 말했다. 이어 “에이전트가 제품으로 무엇을 할 수 있는지 이해하도록 어떻게 도울 것인지, 가능한 한 사용자에게 권한 요청을 최소화하면서 접근을 쉽게 제공할 수 있는지도 중요하다”고 설명했다. 또한 “에이전트 루프 안에서 충분한 맥락을 제공해, 사용자의 작업을 가장 효율적인 방식으로 해결하도록 해야 한다”고 덧붙였다.

AX라는 용어는 이미 AI 코딩 에이전트와 개발자 도구 공급업체 사이에서 확산되고 있다. 빌만은 “코딩 에이전트, 특히 클로드 코드에서 얻은 교훈이 기업과 소비자 지향 에이전트로 확장되기 시작하면, 에이전트와 원활히 작동하지 않는 도구와 서비스는 자연스럽게 우회 대상이 될 것”이라고 내다봤다. 아카마이의 최근 연구 결과 역시 이러한 변화가 이미 시작됐음을 보여준다.

엔터프라이즈 환경에서 AX는 에이전트형 AI를 기존 시스템과 효과적으로 통합하기 위한 기초 작업을 의미한다. 과거 RPA처럼 레거시 애플리케이션에서 데이터를 긁어오는 방식으로 사후에 덧붙일 것인지, 아니면 MCP가 원활히 작동할 수 있도록 워크플로와 도구를 재설계해 에이전트 효율을 높일 것인지가 핵심 선택지다.

투자자들도 기업 가치 평가와 에이전트 주도 성장 가능성을 전망할 때 이러한 원칙을 고려하기 시작했다. 앤트로픽은 에이전트와 잘 작동하는 도구를 설계하기 위한 가이드라인을 제시하고 있으며, 마이크로소프트(Microsoft)는 에이전트가 안전하게 실행될 수 있도록 접근이 제한된 전용 계정을 윈도에 도입하고 있다.

한 AI 코드 도구 공급업체는 자사의 커서 코딩 에이전트가 CMS에 쉽게 접근하지 못하자, 막 비용을 들여 구축한 CMS를 철회하는 결정을 내렸다. 마케팅 팀은 기존 CMS 인터페이스를 사용하는 대신, 챗봇에 마크다운 형식으로 콘텐츠를 추가해 달라고 요청하는 방식이 더 간편하다고 판단했다.

물론 AI 코딩 도구를 개발하는 기업 특성상 커서의 비기술 직군 직원들도 비교적 높은 기술 이해도를 갖추고 있다. 이후 해당 CMS 벤더는 웹사이트 생성·업데이트·관리를 에이전트가 직접 수행할 수 있도록 지원하는 MCP 서버를 출시했다. 이는 AI 에이전트가 전통적인 소프트웨어 사용 방식에 상당한 영향을 미칠 수 있음을 보여주는 사례다.

MCP를 넘어

빌만은 우수한 AX를 구현하기 위한 네 가지 원칙을 제시했다. 첫째, 에이전트가 적절한 권한을 갖고 시스템에 접근할 수 있어야 한다. 둘째, LLM이 해당 시스템을 효과적으로 활용할 수 있도록 충분한 맥락을 제공받아야 한다. 셋째, API·SDK·CLI와 같은 도구가 에이전트가 이를 인터페이스처럼 활용할 수 있도록 설계돼야 한다. 넷째, 선호하는 에이전트를 쉽게 호출하고 조율할 수 있는 구조를 갖춰야 한다.

빌만은 “MCP, 역량, 컨텍스트 파일, 도구 응답 조정 등을 포함해 에이전트가 제품을 사용할 때 올바른 맥락을 확보하도록 설계하는 ‘컨텍스트 엔지니어링’이라는 분야가 새롭게 형성되고 있다”고 설명했다. 그는 넷리파이 CLI 명령어의 오류 메시지에 단 한 줄의 출력을 추가한 것만으로도, 도구를 활용하지 못하던 상태에서 한 번에 배포까지 가능하도록 AX가 근본적으로 개선됐다고 전했다.

다만 단순히 API를 감싸는 MCP를 만드는 것만으로는 충분하지 않다. 빌만은 “MCP를 에이전트를 위한 UI로 생각해야 한다”며 “단순한 API 호출을 넘어, API를 통해 작업을 효율적으로 완수할 수 있도록 적절한 맥락과 구조, 그리고 API 엔드포인트가 일반적으로 어떻게 함께 사용되는지에 대한 정보를 제공해야 한다”고 말했다.

AI 인프라 기업 젠틱(Jentic)의 CEO 숀 블랜치필드도 AI에는 추가적인 통합용 접착제가 아니라 맥락이 필요하다는 데 동의했다. 블랜치필드는 “잘 설계된 API에 대한 명확한 문서만 제공하면 LLM은 이미 이를 직접 연동할 수 있다”며 “결국 고품질 API 관리가 엔터프라이즈 AI 역량의 진정한 기반이 된다”고 설명했다. 이어 “OpenAPI, API 게이트웨이, 인증, 거버넌스에 대한 기존 투자는 AI 시대에 상당한 가치를 창출할 것”이라고 평가했다.

에이전트는 자신들의 사양에 부합하는 API를 필요로 하지만, 실제로는 이를 충족하지 못하는 경우가 많다. 젠틱이 제공하는 무료 ‘AI 준비도 스코어카드’ 도구는 이러한 부분을 점검할 수 있는 방법 중 하나다.

대표적인 문제로는 잘못된 참조, OpenAPI 사양 내 비정상적인 스키마, 서버 호스트 정보가 명시되지 않은 API, 또는 API를 통해 접근할 수 없는 상태로 사람 개발자용 인증 정보만 문서화한 사례 등이 있다. 사람 개발자는 이러한 한계를 우회할 수 있지만, 에이전트는 이에 크게 제약을 받는다.

SaaS 플랫폼 APIContext의 COO 데이비드 오닐은 “API 사양만으로는 운영 순서에 대한 개념을 담을 수 없다”고 지적했다. 이를 보완하기 위해 OpenAPI의 아라조 워크플로 표준을 활용해 운영 흐름을 인코딩해야 한다는 설명이다. 오닐은 “이제 OpenAPI 사양과 아라조 워크플로가 중요해졌다”며 “MCP와 에이전트형 시스템이 실제로 동작 가능한지를 검증할 때 이 표준을 활용하기 때문”이라고 말했다.

포레스터의 베츠는 이러한 작업을 ‘생성형 엔진 최적화’라고 표현했다. 이는 에이전트가 서비스에 대한 세부 정보를 정확히 파악하도록 돕는 활동을 의미한다.

베츠는 “API를 체계적으로 문서화하고, 데이터와 정보에 대해 명확한 비즈니스 정의를 마련하며, 해당 데이터가 어디에 존재하는지, 어떤 시스템이 최종 권위 시스템인지 분명히 이해하는 일은 매우 중요하다”고 설명했다. 이어 “지난 20년간 데이터 및 엔터프라이즈 아키텍트가 구축해 온 기반이야말로 AI가 제대로 작동하기 위해 반드시 필요한 요소”라고 분석했다.

AX 기본 원칙 점검

브로드컴의 스태프 테크놀로지스트 마이클 코테는 “대부분의 조직은 당장 폐기할 준비는 돼 있지 않지만, 그렇다고 그대로 복제하고 싶지도 않은 오래된 코드와 아키텍처를 사용하고 있다”고 진단했다. 코테는 “잘 설계된 데이터베이스와 데이터 아키텍처가 무엇인지, 단지 기능적으로만 동작하지만 바람직하지 않은 구조가 무엇인지 구분해 명확히 표시해 두는 작업이 필요하다”고 조언했다.

데이터 분석 플랫폼 KNIME의 IT 디렉터 마틴 하이더는 이러한 작업이 기본적인 IT 위생에 해당하지만 여전히 매우 중요하다고 설명했다. 특히 과거에는 최신 상태를 유지하거나 항상 접근 가능하도록 관리할 필요가 없었던 여러 데이터 소스를 직원이 수작업으로 취합해 처리해 온 업무를 자동화하려는 경우라면 더욱 그렇다는 지적이다. 하이더는 “재고 정보, 로그, 문서가 신뢰할 수 없다면 어떤 AI 시스템도 결국 잘못된 정보를 자동화하게 될 뿐”이라고 언급했다.

또한 에이전트는 조직 내 암묵지가 어디에 존재하는지를 초기 단계에서 드러내는 경우가 많다. 따라서 코드 전반에 걸쳐 표준을 수립하고, 코드 리뷰를 엄격히 시행하며, 시스템 정의와 문서를 단일 참조 체계로 유지하는 것이 중요하다. 이는 에이전트가 일관된 틀 안에서 작업할 수 있도록 돕는 기반이 된다.

마이크로소프트(MS)의 앱 및 에이전트 부문 CVP 아만다 실버는 이를 ‘에이전트 헌법’이라고 표현했다. 이는 조직이나 코드베이스 전반에 걸친 요구사항과 공통 기대치를 자연어로 명시하는 방식이다. 실버는 “에이전트가 항상 해당 내용을 맥락에 포함하도록 해야 한다”고 설명했다.

이 개념은 보다 폭넓게 적용될 수 있으며, 메타 프롬프트 형태로 활용할 수도 있다. 예를 들어 에이전트가 ID를 관리해야 할 때의 구체적인 처리 방식, 휴먼 인 더 루프 인터페이스를 생성하는 방법, 또는 에이전트의 운영 과정을 관찰할 수 있는 기능을 구축하는 절차 등을 명시할 수 있다.

맥락과 연결성

기존 인프라에 대한 ID 관리, 접근 통제, 권한 설정은 기본 전제다. 대부분의 조직은 우선 인벤토리 정비부터 시작해야 할 가능성이 크다. 에이전트가 상호작용할 모든 시스템을 파악하고, 필요 시 이를 업데이트할 수 있는지 확인해야 한다.

이는 새로운 API를 추가하거나, 핵심 로직과 사용자 인터페이스가 강하게 결합돼 에이전트 활용이 어려운 레거시 애플리케이션을 교체하는 작업으로 이어질 수 있다. API가 기본 내장된 SaaS나 조합형·헤드리스 아키텍처로 전환하는 방안도 포함된다. 실제로 IDC와 논의 중인 조직 가운데 약 30%는 AI와 에이전트를 보다 효과적으로 활용하기 위해 전체 소프트웨어 포트폴리오를 현대화하는 방안을 검토하고 있다.

실버는 “에이전트가 제공할 수 있는 가장 높은 ROI 작업은 백엔드 워크플로 처리”라고 평가했다. 이어 “MCP와 같은 프로토콜을 활용해 데이터를 노출할 수는 있지만, 그것만으로 에이전트가 행동을 수행할 수 있는 것은 아니다”라며 “어떤 작업을 자동화할지 정의하고, 이를 에이전트가 호출할 수 있는 도구로 노출해 의도에서 계획을 거쳐 실제 실행과 행동까지 이어지도록 설계해야 한다”고 설명했다.

예를 들어 장애 대응에 에이전트를 활용하려면, 사고 관련 정보를 취합하는 대시보드에 데이터를 추가할 수 있는 API 접근 권한이 필요하다. 또한 주문 배송 여부나 송장 분쟁 여부와 같은 이벤트를 구독할 수 있도록 워크플로에 에이전트를 포함해야 하며, 이에 맞춰 적절한 조치를 자동으로 트리거할 수 있어야 한다.

정책 역시 문서 형태가 아니라 코드에 포함돼 있는 경우가 많다. 이를 에이전트가 접근할 수 있는 자연어 정책 문서로 추출하는 작업도 필요하다. 조직이 더 많은 에이전트를 활용하게 되면, 전체 워크플로를 순차적으로 조율하는 오케스트레이션을 넘어, 여러 정책을 동시에 충족해야 하는 ‘적대적 평가’ 방식까지 고려해야 한다는 것이 실버의 설명이다.

실버는 “이를 위해 정책 기반의 멀티 에이전트 오케스트레이션을 구현하고, 여러 전문 에이전트의 판단을 종합해 자연어로 규정된 다수의 정책을 동시에 충족하는 결정을 내리도록 설계할 수 있다”고 말했다.

에이전트를 위한 핀옵스

초기 도입 조직은 이미 에이전트가 집요하게 반복 요청을 보내는 특성을 경험하고 있다. 빌만은 “에이전트는 계속 시도하며 가능한 모든 방법을 동원한다”며 “스스로 멈추지 않기 때문에 서비스에 과부하를 일으킬 수 있다”고 설명했다. API를 직접 설계하지 않아 힌트를 반환하도록 수정할 수 없다면, 쿼터를 설정하거나 요청 우선순위를 조정하는 방식이 필요할 수 있다.

APIContext의 COO 데이비드 오닐은 “에이전트형 시스템은 스스로를 통제하는 데 취약하기 때문에 다양한 상황별로 수동 가드레일을 설정해야 할 가능성이 크다”며 “이 시스템은 해법을 도출하도록 설계됐지, 실패했을 때 스스로 중단하도록 설계된 것은 아니다”라고 말했다.

포레스터의 찰스 베츠는 무한 반복이나 과도한 API 호출을 방지하기 위해 멱등성 보장, 재시도 정책, 쿼터와 사용 한도 설정을 강제해야 한다고 조언했다. 베츠는 “에이전트는 무제한 자원이 아니며, 원하는 답을 얻지 못할 경우 언제 시도를 중단해야 하는지 알아야 한다”고 설명했다.

마이크로소프트(Microsoft)의 앱 및 에이전트 부문 CVP 아만다 실버는 거버넌스의 핵심 중 하나로 에이전트에 노출된 MCP 범위를 파악하는 일을 꼽았다. 실버는 “특정 MCP에 대한 접근을 철회할 수 있어야 하고, 토큰 사용량을 관리하며, 조직에 적합한 거버넌스 정책을 적용할 수 있어야 한다”고 전했다.

결국 AX는 UX와 마찬가지로 반복적 개선이 필요한 분야다. 빌만은 “사용자나 에이전트가 무엇을 달성하려 하는지 이해하는 것이 출발점”이라며 “문제와 기회를 분석할 전담 팀을 두어야 한다”고 말했다. 이를 위해 세션 리플레이를 분석하고, 실패하는 에이전트 행동을 식별하며, 이를 성공으로 이끌 수 있는 응답과 인터페이스를 설계해야 한다는 설명이다.

에이전트 모델이 고도화되면서 넷리파이는 최신 API로 유도하기 위한 컨텍스트 파일에 덜 의존하게 됐다. 그러나 이는 곧 목표 지점이 계속 변화한다는 의미이기도 하다. 빌만은 “지속적으로 협업하고 반복 개선해야 할 새로운 에이전트라는 이용자층이 등장했다”고 평가했다.

오닐에 따르면 MCP를 이미 활용 중인 APIContext 고객은 트랜잭션 수, 호출되는 API, 사용되는 서비스 자체가 예기치 않게 변하는 사례를 경험하고 있다. 오닐은 “MCP가 반환하는 서비스 목록이 달라지거나, 기록을 생성하는 방식이 변경돼 더 이상 작동하지 않는 경우가 있다”며 “게이트웨이처럼 모든 것을 정의하는 구조가 아니라, 사용할 수 있는 도구 목록을 제공하는 블랙박스에 가깝다”고 설명했다.

새롭게 등장한 MCP 서버 성능 모니터링 도구는 성능 임계값, 사양, 네트워크 기능, 데이터 주권을 위한 전송 규칙 등을 기준으로 알림을 설정하고 거버넌스 규칙을 수립할 수 있도록 지원한다. 에이전트 시대에는 API 관리에 대해 그 어느 때보다 세심한 주의가 필요하다는 지적이다. 오닐은 “이로 인해 기업이 API 거버넌스를 더욱 진지하게 받아들이게 될 것”이라고 내다봤다.

베츠는 거버넌스 도구와 모니터링, 관측 체계뿐 아니라 API 게이트웨이도 적극 활용해야 한다고 조언했다. 그는 “에이전트는 LLM과 추론 과정, 의도 관리, 목표 추구 행위를 포함한 하나의 서비스일 뿐”이라며 “결국 여전히 소프트웨어”라고 설명했다.

이는 로그 인프라에 상당한 부하가 가해질 수 있음을 의미한다. 베츠는 “에이전트형 접근을 전면 도입하고 모든 에이전트를 추적한다면, 트래픽은 다소 비결정적인 방식으로 오가게 될 것”이라고 말했다.

실버는 에이전트의 성공 여부를 평가할 때 결과와 관측 가능성을 함께 고려해야 한다고 강조했다. 실버는 “시간이 지남에 따라 에이전트가 실제로 의도한 작업을 수행하고 있는지, 경로를 이탈하지는 않는지 평가해야 한다”고 설명했다.

MS는 이미 사이트 신뢰성 엔지니어링(SRE)에 에이전트를 활용해 라이브 사이트 장애 대응 비용을 낮추고 복구 시간을 단축하고 있다. 실버는 “이를 위해서는 레이블과 타임스탬프가 포함돼 추적 가능한 데이터를 확보해야 한다”며 “풍부하고 구조화된 신호와 함께, 어떤 결과가 바람직한지에 대한 명확한 기준도 필요하다”고 밝혔다.
dl-ciokorea@foundryco.com