ODataBridge2026년 7월 5일 / 8분 읽기

SAP OData 서비스를 AI가 쓰는 MCP 도구로 전환하는 법

LLM에게 "지난달 미결제 송장을 조회해줘"라고 말하면 실제 SAP 데이터를 가져오게 하려면 무엇이 필요할까요? 핵심은 SAP의 OData 서비스를 Model Context Protocol(MCP) 도구로 바꾸는 것입니다. 이 글에서는 그 원리와, 수작업 없이 자동화하는 방법을 정리합니다.

1. 왜 LLM은 SAP 데이터를 바로 다루지 못할까

Claude나 GPT 같은 LLM은 문서를 요약하고 코드를 짜는 데는 능숙하지만, 기본 상태로는 사내 SAP 시스템의 재고, 송장, 거래처 데이터를 직접 읽거나 쓸 수 없습니다. 모델은 학습된 지식 안에서만 답할 뿐, 실시간 업무 데이터에 손을 뻗을 통로가 없기 때문입니다.

모델이 “행동”하려면 외부 도구(tool)를 호출할 수 있어야 합니다. 문제는, 도구를 붙이는 방식이 AI 클라이언트마다 제각각이라는 점이었습니다. Claude에 맞춰 붙인 연동을 GPT에서 다시 짜야 했고, 에이전트 프레임워크가 바뀌면 또 처음부터였습니다.

이 혼란을 정리하는 것이 **MCP(Model Context Protocol)**입니다. AI 모델과 외부 시스템을 연결하는 표준 프로토콜로, 한 번 MCP 서버로 만들어 두면 Claude와 GPT를 비롯해 MCP를 지원하는 모든 클라이언트가 동일한 방식으로 그 도구를 인식합니다. “USB-C처럼, 한 번 꽂으면 어디서든 쓰인다”고 생각하면 쉽습니다.

2. SAP OData가 최적의 출발점인 이유

SAP를 AI에 연결한다고 하면 막막하게 느껴지지만, 사실 S/4HANA는 이미 훌륭한 재료를 갖고 있습니다. 바로 OData 서비스입니다. OData는 REST 기반 표준이라 다음 성질을 그대로 가집니다.

  • 조회, 생성, 수정, 삭제(CRUD)가 URL 규칙으로 정의되어 있음
  • 스키마가 $metadata XML로 노출되어 기계가 읽을 수 있음
  • 필드 타입, 필수 여부, 필터와 정렬 옵션이 명세에 담겨 있음

즉, “이 서비스가 어떤 데이터를 어떤 형태로 주고받는지”가 이미 구조화되어 있습니다. AI 도구로 변환하기에 이보다 좋은 출발점이 없습니다. 아래는 거래처(Business Partner) 서비스의 메타데이터를 단순화한 예입니다.

<EntityType Name="A_BusinessPartner">
  <Key><PropertyRef Name="BusinessPartner"/></Key>
  <Property Name="BusinessPartner"     Type="Edm.String" MaxLength="10"/>
  <Property Name="BusinessPartnerName" Type="Edm.String" MaxLength="80"/>
  <Property Name="CreationDate"        Type="Edm.DateTime"/>
</EntityType>

3. OData → MCP, 변환의 핵심 원리

변환의 본질은 메타데이터를 읽어 각 엔티티와 오퍼레이션을 MCP 도구 정의로 매핑하는 것입니다. OData의 필드 타입, 필수 파라미터, 필터 옵션이 그대로 MCP 도구의 입력 스키마가 됩니다. 위 거래처 조회는 이런 MCP 도구 하나로 바뀝니다.

{
  "name": "search_business_partner",
  "description": "거래처(Business Partner)를 이름과 생성일 등으로 조회합니다.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "name":  { "type": "string", "description": "거래처명 부분 일치" },
      "top":   { "type": "integer", "description": "가져올 최대 건수" }
    }
  }
}

전체 흐름을 단계로 정리하면 다음과 같습니다.

  1. 메타데이터 파싱 - $metadata에서 엔티티, 프로퍼티, 연관관계를 추출하고 OData v2/v4를 자동 판별
  2. 도구 정의 생성 - 각 오퍼레이션(조회/생성/수정/삭제)을 MCP tool 스펙으로 매핑
  3. SAP 특유 처리 래핑 - 인증(SSO)과 CSRF 토큰, 세션, 페이징을 도구 안에 감춤
  4. MCP 서버로 노출 - LLM이 도구 목록으로 인식하고 자연어로 호출

결국 사용자는 “지난달에 생성된 거래처 중 미결제가 있는 곳을 보여줘”라고 말하고, 모델은 뒤에서 search_business_partner를 호출해 SAP 실데이터로 답합니다.

4. 직접 구현하면 부딪히는 벽

엔티티 하나를 MCP 도구로 만드는 것은 어렵지 않습니다. 문제는 규모입니다. 실무에서는 거래처, 판매, 구매, 재고, 회계 등 서비스가 수십, 수백 개로 늘어나고, 각각에 대해 SAP 특유의 처리를 반복해야 합니다.

  • CSRF 토큰 - 쓰기 작업마다 토큰을 발급받고 만료되면 갱신하는 로직을 서비스마다 작성
  • 인증 - Basic Auth와 SAP SSO를 상황에 맞게 처리하고, 세션이 끊기면 자동 재인증
  • 타입 변환 - OData의 Edm.DateTime, Edm.Decimal 등을 JSON으로 안전하게 오가기
  • 필드 폭주 - 엔티티 하나가 필드 50~200개인 경우가 흔해, 매번 전부 주고받으면 토큰과 비용이 낭비됨

하나씩은 사소하지만, 수 백개 서비스에 곱하면 그 자체가 하나의 프로젝트가 됩니다. 그리고 이 배관 작업은 비즈니스 가치를 전혀 만들지 않습니다.

5. ODataBridge로 자동화하기

ODataBridge는 3장의 원리를 그대로 자동화합니다. $metadata XML만 넣으면 완전한 TypeScript MCP 서버 프로젝트가 생성되고, 위에서 나열한 CSRF, 인증, 세션, 타입 변환이 처음부터 내장됩니다.

3단계 자동 생성 파이프라인

  1. 메타데이터 파싱 - $metadata를 분석하고 v2/v4와 CRUD 가능 여부를 자동 판별
  2. AI 도구 정의 생성 - 핵심 엔티티를 선별하고 도구 설명까지 자동 작성, 필드셋을 short/long/all 모드로 최적화
  3. MCP 서버 생성 - OData 클라이언트(CSRF와 Auth 포함)와 테스트 코드까지 갖춘 프로젝트 출력

여기에 더해 SAP API Hub가 선정한 650개 이상의 카탈로그(OData v2 243개 + v4 407개)가 이미 준비되어 있어, 필요한 서비스를 즉시 추가할 수 있습니다. 고객이 직접 만든 CBO OData도 표준 API와 동일한 방식으로 전환됩니다.

Claude에 연결하기

생성된 서버는 MCP Gateway로 하나의 엔드포인트에 묶여, Claude Desktop 설정 한 줄로 650개 서비스에 동시에 접근할 수 있습니다.

{
  "mcpServers": {
    "sap": {
      "url": "https://your-gateway.liteway.cc/mcp"
    }
  }
}

이제 Claude에게 자연어로 요청하면, 뒤에서 알맞은 SAP OData 도구가 호출됩니다. 직접 붙였다면 며칠 걸렸을 배관이 메타데이터 입력 → 생성 두 단계로 끝납니다.

마무리

OData를 MCP로 바꾸는 순간, SAP는 “화면에서 클릭하는 시스템”에서 “AI가 대화로 다루는 시스템”이 됩니다. 원리는 의외로 단순합니다 - 메타데이터를 도구 정의로 매핑하고, SAP 특유의 인증과 세션을 감추는 것. 다만 그 반복을 650번 하고 싶지 않을 뿐입니다.

작게 시작해 원리를 이해했다면, 규모의 문제는 ODataBridge로 걷어내세요. 배관이 아니라 그 위에서 만드는 가치에 집중할 수 있습니다.

ODataBridge

SAP OData를 MCP로, 수작업 없이.

650+ 카탈로그 서비스 사전 구축, CRUD와 CSRF, SSO 자동 처리. 메타데이터만 있으면 AI가 바로 쓰는 MCP 서버가 생성됩니다.

ODataBridge 살펴보기
인사이트 목록으로