AI 에이전트 이야기를 하면 개발자들은 보통 LangGraph나 MCP, 오픈소스 프레임워크 이야기부터 꺼낸다. 그런데 정작 기업 현장에서 구매, 재무, 재고, 인사 같은 핵심 데이터가 들어 있는 시스템을 떠올려 보면 상당수가 SAP다. 에이전트가 진짜 일을 하려면 결국 그 데이터와 프로세스 안으로 들어가야 한다는 얘기다. 그래서 요즘 SAP가 Joule이라는 이름으로 내놓는 에이전트 전략을 유심히 볼 필요가 있다.
이 글은 SAP를 매일 쓰는 ERP 담당자보다는, 에이전트 개발에 관심이 있는데 SAP BTP 쪽은 낯선 분들을 위해 썼다. Joule 에이전트가 정확히 무엇인지, BTP 위에서 어떻게 만들고 연결하는지, 그리고 도입 전에 어디를 조심해야 하는지를 차근차근 정리해 본다.
Joule과 Joule 에이전트는 무엇이 다른가
먼저 이름부터 헷갈리기 쉬운 부분을 정리하고 가자. Joule은 SAP가 자사 제품군 전반에 넣고 있는 AI 어시스턴트의 이름이다. S/4HANA, SuccessFactors, Ariba 같은 화면 안에서 자연어로 물어보면 답을 주고 몇 가지 작업을 도와주는 역할을 해왔다. 초기에는 이 정도가 전부에 가까웠다. 질문에 답하고 화면 이동을 도와주는 부조종사 성격이 강했다.
Joule 에이전트는 여기서 한 걸음 더 나간 개념이다. 하나의 질문에 하나의 답을 내놓는 게 아니라, 목표를 받으면 여러 단계를 계획하고 필요한 API와 문서를 호출하면서 업무를 끝까지 밀고 가는 쪽에 가깝다. 결제 분쟁을 처리하는 상황을 예로 들면, 수금 담당 에이전트와 송장 담당 에이전트, 고객 응대 에이전트가 각자 맡은 부분을 처리하면서 협업하는 그림이 나온다. 이때 여러 에이전트를 묶어서 조율하는 상위 개념이 Joule 어시스턴트다. 사용자의 역할에 맞춰 알맞은 에이전트들을 자동으로 불러오는 식으로 설계돼 있다.
여기서 한 가지 짚어둘 점이 있다. SAP가 에이전트라는 이름을 붙이는 기능의 범위는 제각각이다. 경비 보고서 검증처럼 범위가 좁고 이미 정식 출시된 것도 있고, 여러 단계를 스스로 계획하는 본격적인 오케스트레이션형은 아직 다듬어지는 중이다. 이름만 보고 판단하지 말고 어떤 범위의 작업을 하는지, 지금 어떤 출시 상태인지를 따로 확인하는 습관이 필요하다.
왜 하필 BTP 위에서 돌아가는가
Joule 에이전트를 이해하려면 BTP, 즉 Business Technology Platform을 같이 봐야 한다. BTP는 SAP가 제공하는 클라우드 플랫폼으로, 통합, 보안, API 노출, 사용자 정의 로직, 운영 통제 같은 기능이 모여 있다. 쉽게 말해 SAP 시스템과 바깥세상을 안전하게 이어주는 중간 계층이다.
에이전트가 기업 시스템에서 일을 하려면 로그인 권한, 접근 범위, 호출 횟수 제한, 감사 기록 같은 것이 반드시 따라와야 한다. 개발자 입장에서 흔히 하는 실수가 에이전트의 똑똑함에만 신경 쓰고 이 통제 계층을 나중으로 미루는 것인데, 기업 환경에서는 이 부분이 없으면 시범 운영조차 넘어가기 어렵다. BTP가 이 역할을 맡아주기 때문에 에이전트는 통제된 도구를 통해서만 SAP 비즈니스 시스템에 닿게 된다. SAP가 조달 플랫폼인 Ariba를 BTP 기반으로 처음부터 다시 만들었다는 소식도 같은 맥락이다. 에이전트가 조달 워크플로를 호출하고 공급업체 데이터를 조회하고 승인을 실행하는 일을 플랫폼의 기본 동작으로 만들려면, 기존 구조에 덧붙이는 방식으로는 한계가 있었다는 판단으로 읽힌다.
Joule Studio 에이전트 빌더로 만드는 방법
직접 만들어 보고 싶은 사람에게 가장 중요한 도구가 Joule Studio의 에이전트 빌더다. 올해 초 정식 출시됐고, 비즈니스 담당자와 IT 담당자 모두 사용자 정의 에이전트를 만들 수 있게 해준다. 접근 방식은 크게 두 갈래다.
첫 번째는 브라우저 기반의 시각적 빌더를 쓰는 저코드 방식이다. 로컬 환경을 따로 세팅할 필요 없이 트리거, 데이터 소스, 실행할 동작, 사람에게 넘길 조건을 화면에서 설계한다. 두 번째는 자신의 IDE에서 Joule Studio CLI와 VS Code 확장을 쓰는 프로코드 방식이다. 코딩 에이전트를 MCP로 연결해서 개발하는 흐름도 지원한다. 개발자라면 두 번째 방식이 손에 익겠지만, 업무를 잘 아는 현업 담당자가 첫 번째 방식으로 초안을 만들고 개발자가 다듬는 협업도 충분히 현실적이다.
기능을 하나씩 뜯어보면 꽤 실용적이다. 이미 만들어진 스킬 라이브러리를 재사용해서 에이전트의 부품으로 쓸 수 있고, 문서를 기반으로 에이전트의 판단 근거를 잡아줄 수 있다. 하위 에이전트를 도구처럼 추가해서 복잡한 작업을 나눠 맡기는 구성도 가능하다. SAP가 미리 만들어 둔 에이전트에 도구나 전후 처리 로직을 얹는 확장도 업그레이드에 영향을 주지 않는 방식으로 할 수 있어서, 표준 기능을 건드려서 나중에 발목이 잡히는 일을 피할 수 있다. 그리고 중요한 결정과 승인 단계에는 사람이 개입하도록 설계할 수 있다. 에이전트가 알아서 다 해버리는 것보다 결재선을 그대로 유지하는 쪽이 기업 입장에서 훨씬 받아들이기 쉽기 때문이다.
MCP로 바깥 도구와 연결하기
Joule Studio에서 개발자에게 가장 반가운 부분은 MCP 지원이다. MCP는 에이전트가 외부 도구와 시스템에 접근하는 방식을 표준화한 프로토콜인데, SAP도 이를 받아들였다. 외부 MCP 서버는 BTP 코크핏에서 설정하는 destination을 통해 연결한다. 예를 들어 Joule Studio에서 만든 지원 에이전트가 MCP로 기능을 노출하는 외부 구매 요청 도구에서 요청서를 만들거나 수정하는 시나리오가 가능하다.
기업 환경에서는 MCP 서버를 아무 데나 열어둘 수 없기 때문에 관리 계층이 따로 있다. 통합 스위트 쪽의 MCP 게이트웨이는 SAP와 비SAP API를 통제된 방식으로 도구로 노출해 주고, 보안, 호출 제한, 관측, 수명주기 관리를 함께 제공한다. 별도의 MCP 서버를 직접 개발하지 않아도 된다는 점이 장점이다. 만들어 본 사람은 알겠지만, 도구 하나를 MCP로 감싸는 일은 금방 끝나도 그걸 운영 환경에서 권한과 함께 굴리는 일이 훨씬 오래 걸린다. 그 부분을 플랫폼이 덜어준다는 게 핵심이다.
A2A로 에이전트끼리 협업시키기
MCP가 에이전트와 도구 사이의 약속이라면, A2A는 에이전트끼리 대화하는 약속이다. 독립적으로 만들어진 에이전트들이 서로 작업을 넘기고 맥락을 주고받도록 하는 표준이다. 인사 정보를 다루는 에이전트와 자체 개발한 재무 에이전트를 Joule이 오케스트레이터로 묶어서 사용자의 한 번의 요청을 나눠 처리하는 그림이 대표적이다.
여기서 반드시 알아둘 현재 상태가 있다. 지금 시점에서 Joule이 외부 에이전트를 A2A로 호출하는 방향은 사용할 수 있지만, 반대로 외부 오케스트레이터가 Joule 에이전트를 동등한 상대로 호출하는 방향은 올해 4분기 목표로 잡혀 있고 아직 일반 출시 전이다. 이걸 놓치고 아키텍처를 설계하면 나중에 방향이 틀어질 수 있다. 자체 개발한 에이전트를 붙이고 싶다면 SAP Cloud SDK for AI로 파이썬이나 타입스크립트 에이전트를 만들어 자신의 BTP 서브계정에 배포하고, A2A로 Joule과 연결하는 방식이 공식적으로 제시되는 경로다. 에이전트 신뢰와 인증, 거버넌스는 SAP 클라우드 아이덴티티와 LeanIX의 AI 에이전트 허브 쪽에서 맡는 구조다.
도입 전에 꼭 확인할 것들
기술이 좋아 보여도 현실적으로 따져볼 항목이 몇 가지 있다. 첫째는 비용이다. Joule Studio의 에이전트 빌더는 현재 올해 말까지 무상 프로모션으로 제공되고, 그 이후에는 추가 비용이 붙는 프리미엄 AI 기능으로 전환될 예정이다. 시범 사업을 무료로 할 수 있다고 해서 본 운영 예산까지 무료라고 가정하면 안 된다. 계약과 요금 체계는 시점마다 바뀔 수 있으니 실제 도입 전에 SAP 측 안내를 직접 확인하는 게 안전하다.
둘째는 범위를 좁게 잡는 것이다. 이미 SAP 커뮤니티에서 에이전트를 만들어 본 사례들이 공통으로 말하는 교훈이 있다. 성공한 기업용 에이전트는 대체로 목적이 좁고, 근거 데이터가 분명하고, 통제가 되어 있었다는 것이다. 모든 걸 다 해주는 만능 에이전트를 만들려는 순간 테스트가 어려워지고 안전성을 설명하기 힘들어진다.
셋째는 테스트 체계다. 에이전트는 코드처럼 한 번 통과했다고 끝나지 않는다. 입력이 조금만 달라져도 다른 경로로 움직일 수 있기 때문에 지속적으로 검증하는 흐름이 필요하다. 넷째는 클린 코어 원칙이다. S/4HANA 표준을 건드리지 않고 바깥에서 확장하는 방향을 유지해야 나중에 업그레이드가 수월하다. 마지막으로 SAP가 AI 에이전트의 API 사용에 관한 정책을 따로 두고 있어서, 무엇이 허용되고 무엇이 제한되는지를 구축 전에 읽어 둘 필요가 있다.
LangGraph 같은 오픈소스와는 어떻게 다른가
LangGraph 같은 프레임워크로 에이전트를 만들어 본 입장에서 Joule Studio를 보면 첫인상은 이렇다. 자유도는 오픈소스가 높고, 기업 시스템에 붙였을 때의 안정성과 통제는 Joule 쪽이 낫다. 오픈소스로 만들면 상태 관리, 흐름 제어, 모델 선택을 원하는 대로 짤 수 있는 대신 인증, 권한, 감사, 운영 관측은 직접 붙여야 한다. Joule Studio는 그 반대다. SAP 데이터와 프로세스를 이해하는 기반 위에서 권한 체계와 거버넌스를 이미 갖춘 채로 시작하지만, 내부 동작을 세밀하게 손대는 데는 한계가 있다.
그래서 둘 중 하나를 고르기보다 역할을 나누는 접근이 현실적이다. SAP 안쪽의 표준 업무와 권한이 얽힌 부분은 Joule 에이전트에 맡기고, 바깥에서 복잡한 추론이나 자체 모델, 특수한 검색이 필요한 부분은 직접 만든 에이전트로 처리한 뒤 A2A와 MCP로 잇는다. SAP도 이 방향, 즉 자체 개발 에이전트를 가져와서 연결하는 구조를 공식 아키텍처로 밀고 있다는 점이 눈여겨볼 대목이다.
마무리하며
정리하면 이렇다. Joule 에이전트는 SAP의 어시스턴트가 질문에 답하는 단계를 넘어 업무를 직접 처리하는 단계로 옮겨가는 흐름이고, 그 뼈대는 BTP가 잡아준다. Joule Studio 에이전트 빌더로 저코드와 프로코드 양쪽에서 만들 수 있고, MCP로 외부 도구를, A2A로 다른 에이전트를 연결한다. 다만 외부 오케스트레이터가 Joule 에이전트를 호출하는 방향은 아직 출시 전이고, 현재의 무상 제공은 연말까지라는 점은 반드시 감안해야 한다.
결국 성패는 기술 자체보다 어떤 업무를 어느 범위까지 맡기고, 어디에서 사람이 승인하게 할지 설계하는 데서 갈릴 가능성이 크다. 기업 시스템 안으로 들어가는 에이전트는 똑똑함보다 통제 가능한지가 먼저 평가받는다. SAP 환경에서 에이전트를 고민하고 있다면, 가장 반복적이고 규칙이 뚜렷한 업무 하나를 골라 작게 시작해 보는 것을 권한다.