다음 소프트웨어 사용자는 AI 에이전트입니다. 아키텍처는 준비되어 있나요?

AI 에이전트가 고객의 청구 분쟁을 처리한다고 상상해 보세요. 에이전트는 불만 내용을 읽고, 계정 내역을 확인한 뒤, 크레딧을 제공해야 한다고 판단합니다. 이 모든 일을 단 몇 초 만에 해냅니다.

인상적입니다. 이제 실제로 크레딧을 지급하라고 해보세요.

고객 계약서는 다른 시스템에 있습니다. 승인 규칙은 애플리케이션 코드 깊숙이 묻혀 있습니다. 청구 도구는 사람이 여러 화면을 클릭하며 진행하기를 요구합니다.

에이전트는 무엇을 해야 하는지 이해하지만, 아키텍처가 작업을 마무리하지 못하게 합니다.

에이전트형 AI가 실제 운영 환경에 도입되면 더 많은 기업이 이런 문제에 부딪히리라 예상합니다. 하지만 이상한 점은 작업을 끝내지 못하게 하는 장벽이 에이전트의 지능과는 거의 관련이 없다는 것입니다.

우리는 수년간 기업용 소프트웨어를 사용하는 사람들을 위해 현대화해 왔습니다. 이제는 점점 더 그 소프트웨어를 운영하게 될 에이전트를 위해 현대화해야 합니다.

사용자 인터페이스가 제품의 전부였던 적은 없습니다

오늘날 기업용 소프트웨어가 어떻게 작동하는지 생각해 보세요. 사람들은 애플리케이션을 열고, 대시보드를 탐색하고, 의사결정을 내리고, 한 시스템에서 다른 시스템으로 업무를 이어갑니다. 사용자 인터페이스는 사람들이 비즈니스와 상호작용하는 방식입니다.

에이전트에게 이런 화면이 반드시 필요한 것은 아닙니다. API, 모델 컨텍스트 프로토콜(MCP) 서버 및 기타 프로그래밍 방식의 인터페이스를 통해 정보를 가져오고 작업을 시작할 수 있습니다. 이는 헤드리스 아키텍처로 전환하는 과정의 일부입니다.

하지만 헤드리스라고 해서 애플리케이션이 사라지는 것은 아닙니다. 애플리케이션의 데이터, 비즈니스 규칙, 권한, 규정 준수 요건은 여전히 중요합니다. 오히려 더 중요하다고 생각합니다.

수년 동안 소프트웨어 공급업체는 세련된 사용자 인터페이스, 사용자 습관, 직원 재교육 비용을 바탕으로 경쟁 우위를 구축해 왔습니다. 에이전트가 애플리케이션 사용자 인터페이스를 열지 않고 더 많은 업무를 수행하면 이런 우위는 약해집니다. 그 대신 신뢰할 수 있는 데이터, 검증된 도메인 로직, 운영 거버넌스, 감사 가능한 거래 등 근간이 되는 기록 시스템의 가치가 커집니다.

상업적인 파장도 있습니다. 2030년까지 최대 2,340억 달러 규모의 기업용 애플리케이션 지출이 에이전트형 AI로 인한 변화에 노출될 수 있습니다. 이는 변화의 위험에 놓인 지출이지, 반드시 사라질 지출을 뜻하는 것은 아닙니다. 또한 에이전트가 대시보드에서 사람이 하던 업무를 맡게 되면 사용자별 과금은 점차 사용량·작업·성과 기반 모델로 대체될 수 있습니다.

소프트웨어 공급업체에는 비즈니스 모델의 과제입니다. 해당 애플리케이션에 의존하는 기업에는 아키텍처의 과제입니다.

구성 요소는 현대화했지만 업무 흐름은 그렇지 않았습니다

대부분의 기업은 수년 전부터 현대화를 진행해 왔습니다. 한 팀은 레거시 애플리케이션을 업데이트합니다. 다른 팀은 분산된 데이터를 최신 플랫폼으로 통합합니다. 세 번째 팀은 통합 기능을 구축하거나 단순히 사용자 인터페이스를 새로 단장합니다.

각 프로젝트는 개별적으로는 성공할 수 있습니다. 에이전트가 이 모든 요소를 아우르는 업무 흐름을 실행해야 할 때 문제가 시작됩니다.

에이전트에 정확한 고객 정보를 제공할 수는 있습니다. 하지만 그 정보를 바탕으로 작업을 수행하는 애플리케이션의 핵심 규칙이 레거시 코드에 묻혀 있다면, 그다음에는 어떻게 될까요? 또는 깔끔한 API를 제공해도 그 뒤에 있는 데이터가 서로 일치하지 않을 수 있습니다. 에이전트가 작업을 수행할 수는 있지만, 그 판단을 신뢰할 수 있을까요?

두 경우 모두 기술의 일부는 현대화했지만 업무 자체는 현대화하지 못했습니다.

에이전트형 AI는 어떤 현대화 프로젝트가 성공했는지에 관심이 없습니다. 전체 업무 흐름이 제대로 작동하는지가 중요합니다.

실제로는 다음과 같습니다. 한 고객사는 복잡한 엔진 수리 견적을 더 빠르게 산출해야 했습니다. 계약에 따라 수리·교체·재정비가 가능한 부품이 정해져 있었습니다. 계약서와 정비 매뉴얼을 일일이 조사하느라 견적 하나를 내는 데 며칠, 때로는 몇 주가 걸렸습니다. 고객사는 이미 데이터 플랫폼을 현대화했지만, 병목은 데이터가 아니었기 때문에 견적 처리 속도는 전혀 빨라지지 않았습니다. 문제는 조사 작업이었습니다. 우리는 여러 조사 에이전트를 중심으로 해당 업무 흐름을 재구축해 조사 시간을 80% 단축했고, 견적 처리 속도도 완전히 달라졌습니다.

이 때문에 애플리케이션 현대화와 데이터 현대화를 서로 독립된 두 개의 작업 흐름으로 계획해서는 안 됩니다. 아키텍처는 비즈니스 성과 전체를 지원해야 합니다.

API를 제공한다고 시스템이 에이전트 대응형이 되는 것은 아닙니다

해결책은 간단하다고 생각하기 쉽습니다. 엔드포인트를 열고, 에이전트를 연결하면 끝이라는 식입니다.

그렇게 간단하다면 얼마나 좋을까요.

정보를 가져오는 일은 한 가지입니다. 크레딧을 지급하거나, 재무 기록을 업데이트하거나, 교체 부품을 주문하는 일은 전혀 다릅니다. 이제는 단순한 접근이 아니라 실행을 이야기하는 것입니다.

여기서 제가 사용하는 용어가 에이전트 제어 인터페이스입니다. 이는 에이전트가 기록 시스템에서 정보를 읽고 쓸 수 있도록 범위와 거버넌스를 정한 인터페이스입니다.

API와 MCP 서버는 에이전트에 도구와 데이터를 제공할 수 있습니다. 하지만 MCP가 비즈니스 규칙을 자동으로 적용하거나 누가 작업을 수행할 권한이 있는지 판단해 주는 것은 아닙니다. 이러한 통제는 여전히 기반 시스템과 워크플로에 구현해야 합니다.

에이전트가 신뢰할 수 있는 출처의 데이터를 가져올 수 있습니까? 비즈니스 규칙이 명확하게 정의되어 일관되게 적용됩니까? 에이전트가 조치를 권고하되 수행 권한이 있는 조치만 실행할 수 있습니까? 문제가 발생했을 때 해당 조치를 추적하고 예외 상황을 처리하며, 가능하다면 되돌릴 수 있습니까?

이런 문제는 더 나은 모델만으로 해결할 수 없습니다. 워크플로, 애플리케이션 설계, 데이터 아키텍처, 통합, 거버넌스에 관한 문제입니다. 그리고 이 문제들은 함께 답을 찾아야 합니다.

기술이 아니라 업무에서 시작하세요

그렇다면 어디서부터 시작해야 할까요?

모든 애플리케이션을 헤드리스로 만들거나 사용 가능한 모든 API를 개방하는 것부터 시작하지는 않겠습니다. 먼저 비즈니스에 의미 있는 워크플로 하나를 살펴보겠습니다.

처음부터 끝까지 추적해 보세요. 기록은 어떤 시스템에 저장되어 있습니까? 비즈니스 로직은 어디에 있습니까? 에이전트는 어떤 데이터를 신뢰할 수 있습니까? 어떤 결정에 사람의 승인이 필요합니까? 시스템이 작업 도중에 멈추면 어떻게 됩니까? 거버넌스는 어떻게 유지됩니까?

그러면 중요한 격차가 드러날 것입니다. 이것이 바로 현대화 로드맵입니다. 서로 동떨어진 기술 프로젝트가 아니라 비즈니스 성과를 목표로 애플리케이션, 데이터, 통합, 통제 과제를 조율해 추진하는 계획입니다.

그리고 그에 맞는 지표로 성과를 측정하세요. 개방한 API의 수나 이전한 데이터의 양이 아니라 워크플로가 안정적으로 완료되는지, 예외 상황이 어떻게 해결되는지, 비즈니스 성과가 개선되는지를 기준으로 삼아야 합니다.

목표는 모든 업무를 자율적으로 처리하는 것이 아닙니다. 필요한 곳에 사람의 판단을 더하면서 안정적이고 신뢰할 수 있게 업무를 실행하는 것입니다.

진정한 변화는 헤드리스 그 이상입니다

제가 기대하는 것은 대시보드를 없애는 일이 아닙니다. 사람들이 업무를 마치기 위해 서로 단절된 시스템 사이에서 수작업으로 일을 옮길 필요가 없어지면 어떤 일이 벌어질지 기대됩니다.

하지만 에이전트를 애초에 에이전트를 고려해 설계되지 않은 아키텍처 위에 올려놓는다고 해서 그 목표를 이룰 수는 없습니다.

차세대 엔터프라이즈 소프트웨어는 사람에게 무엇을 보여줄 수 있는지만으로 정의되지 않을 것입니다. 에이전트가 무엇을 안정적이고 책임감 있게 수행할 수 있는지에 따라서도 정의될 것입니다.