MCP SAP RFC 연동 실무 가이드 SM59 권한 네트워크

SAP RFC 호출 구조: MCP SAP RFC 연동의 기본 원리

SAP 공식 AI(Joule)가 아니라 Claude 같은 외부 AI 도구를 전제로 말씀드리면, MCP는 SAP에 직접 붙는 구조가 아닙니다. Model Context Protocol은 AI가 외부 Tool을 표준 방식으로 호출하기 위한 약속이고, SAP 쪽 연결은 결국 별도의 Backend Layer가 담당해야 합니다. 쉽게 비유하면 MCP는 “비서”이고, 실제 SAP 문을 열고 들어가는 사람은 Python이나 Node로 만든 백엔드입니다. 이 백엔드가 PyRFC 또는 node-rfc를 통해 SAP NetWeaver RFC SDK를 호출하고, 그다음 SAP Gateway와 Application Server를 거쳐 ABAP Function Module 또는 BAPI가 실행됩니다.

SAP 외부 연동에서 보는 RFC, BAPI, Remote-enabled FM

실무에서는 이 셋을 섞어 부르지만 역할은 다릅니다.

구분	의미	실무 사용 포인트
RFC FM	Remote-enabled Function Module	외부에서 직접 호출 가능, 범용적
BAPI	표준 비즈니스 인터페이스	전표 생성, 마스터 변경 등 트랜잭션성 업무에 적합
ZRFC	고객 전용 Remote-enabled FM	보안, 입력 검증, 응답 구조 통제에 유리

 

S/4HANA로 오면서 OData와 CDS 기반 API가 많이 늘어난 건 맞습니다. 하지만 읽기 전용 조회는 OData가 편해도, 복잡한 검증이나 커밋이 필요한 업무는 여전히 RFC/BAPI가 핵심입니다. 특히 FI/TR에서는 전표 처리, 지급 상태 반영, 자금 데이터 조회처럼 한 번에 끝나지 않는 비즈니스 로직이 많아서 RFC를 완전히 빼기 어렵습니다. SAP Help Portal의 NetWeaver RFC 관련 문서도 이런 구조를 여전히 기본 인터페이스 축으로 설명하고 있습니다.

Claude MCP Tool 함수와 SAP RFC 호출 구조

구조를 단순화하면 아래 순서입니다.

 

1. Claude MCP Tool 함수 호출

2. Backend API(Python/Node)에서 인증·로깅·입력 검증

3. PyRFC 또는 node-rfc로 SAP RFC SDK 호출

4. SAP Gateway 통과

5. ABAP FM/BAPI 실행

6. 결과를 Backend가 가공 후 MCP 응답 반환

 

이 흐름에서 핵심은 “MCP는 직접 SAP 호출 X”입니다. Backend가 없으면 보안, 권한, 감사추적, 커넥션 관리가 다 무너집니다.

SAP가 아직도 RFC를 많이 쓰는 이유

이유	설명
트랜잭션 안정성	표준 BAPI와 Commit 흐름이 잘 정리되어 있음
감사 추적	ST22, SM21, SU53 등으로 원인 추적이 비교적 명확
권한 제어	S_RFC, S_RFCACL로 호출 범위를 세밀하게 통제 가능
기존 자산 활용	ECC 시절 인터페이스를 S/4HANA에서도 연속성 있게 사용 가능

 

SAP RFC는 “옛날 방식”처럼 보이지만, 실제로는 권한·감사·트랜잭션 제어가 강해서 SAP 외부 연동에서 아직도 매우 실용적인 선택지입니다.

 

SM59 RFC Destination 설정: 꼭 알아야 할 오해와 실제 구성

여기서 가장 중요한 오해 하나를 먼저 짚겠습니다. 외부 시스템이 SAP로 직접 접속하는 PyRFC SAP 연결이나 Node RFC SAP 호출에는 SM59가 필수가 아닙니다. 이 부분 때문에 현장에서 시간을 많이 잃습니다. 외부 애플리케이션은 보통 ASHOST, SYSNR, CLIENT, USER, PASS, LANG로 직접 SAP에 붙습니다. 반대로 SAP 내부에서 외부 시스템을 호출하거나, SAP에서 목적지 연결을 테스트해야 할 때 SM59 RFC Destination 설정이 필요합니다.

SM59는 모든 RFC 문제의 시작점처럼 보이지만, 외부→SAP 직접 연결에서는 필수 요소가 아닙니다. 이 오해만 풀려도 디버깅 방향이 훨씬 빨라집니다.

SM59 RFC Destination 설정의 역할과 유형

T-code는 SM59이고 메뉴 경로는 Tools > Administration > Network > RFC Destinations입니다.

Connection Type	의미	주 사용 시나리오
Type 3	ABAP Connection	SAP ↔ SAP 연결
Type T	TCP/IP Connection	SAP → 외부 프로그램 호출
Type G	HTTP Connection	SAP → HTTP 서비스 호출

 

운영중에 MPC 사용을 위해 고민을 했을 때 고민했던 부분이 “PyRFC 접속 안 되는데 SM59에서 뭘 만들어야 하나?”인데요, 외부 앱이 SAP에 붙는 구조라면 먼저 SM59가 아니라 계정, 포트, Gateway, SDK, 권한을 보셔야 합니다.

PyRFC SAP 연결과 Node RFC SAP에 필요한 실제 파라미터

외부 프로그램 기준 핵심 연결 값은 아래와 같습니다.

• ASHOST: SAP Application Server Host

• SYSNR: 시스템 번호, 예: 00

• CLIENT: 예: 100

• USER / PASS: RFC 서비스 계정

• LANG: 예: KO, EN

 

예를 들어 Python에서 연결은 이런 구조로 갑니다.

from pyrfc import Connection

conn = Connection(
    ashost='sap.example.com',
    sysnr='00',
    client='100',
    user='RFC_USER',
    passwd='********',
    lang='KO'
)
result = conn.call('STFC_CONNECTION', REQUTEXT='PING')
print(result)

 

이때 STFC_CONNECTION은 네트워크와 인증 검증용으로 많이 쓰는 기본 테스트 FM입니다. 운영계에 바로 FI 전표 BAPI를 때리기 전에 이 테스트부터 통과시키는 게 정석입니다.

RFC Function Module 준비와 FI/TR 실무 포인트

SE37에서 호출 대상 Function Module이 반드시 Remote-enabled로 되어 있어야 합니다. 일반 FM은 외부 호출이 안 됩니다. 조회라면 표준 BAPI나 RFC FM을 검토할 수 있지만, 실무에서는 ZRFC를 별도로 설계하는 경우가 많습니다. 이유는 간단합니다. AI나 외부 앱에서 SAP를 직접 건드릴 때는 입력값 검증, 회사코드 제한, 통화 체크, 응답 구조 정규화가 꼭 필요하기 때문입니다.

• BAPI_ACC_DOCUMENT_POST

• BAPI_TRANSACTION_COMMIT

 

전표 생성 BAPI를 호출하고 Commit을 빠뜨리면, 호출은 성공처럼 보여도 문서가 저장되지 않습니다. 이건 현장에서 정말 많이 나오는 사고입니다.

PFCG 권한과 S_RFC: 실패의 70%

권한은 거의 항상 핵심 원인입니다. 서비스 계정에 PFCG 역할이 잘 붙어 있어도 실제 필요한 권한 객체가 빠져 있으면 특정 FM만 실패합니다.

권한 객체	역할	체크 포인트
S_RFC	RFC 함수 호출 권한	허용 FM 그룹 또는 이름 범위 확인
S_RFCACL	신뢰/ACL 기반 RFC 제어	시나리오에 따라 누락 시 호출 실패
S_TCODE	관련 트랜잭션 접근	테스트용 트랜잭션 필요 시 확인

 

1. 사용자 생성

2. 역할(PFCG) 부여

3. 역할 안에 S_RFC 설정

4. 허용 가능한 Function Module 범위 제한

5. 필요 시 S_RFCACL 추가 제어

 

실제 프로젝트에서 S_RFCACL 누락 때문에 3일 동안 Python 로그만 붙잡고 디버깅한 적이 있었습니다. 연결도 되고 Ping도 되는데 특정 호출만 안 돼서 라이브러리 문제로 몰고 갔거든요. 결국 SAP 권한팀과 SU53, 보안 trace를 같이 보면서 해결했습니다.

 

Gateway, SAProuter, 방화벽: 네트워크의 현실

외부 연동은 결국 포트가 열려 있어야 합니다. SMGW에서 Gateway 상태를 확인하고, sapgw00 같은 Gateway 포트가 방화벽에서 열려 있는지 봐야 합니다. SAProuter를 경유하는 구조라면 라우팅 문자열까지 정확해야 합니다. 운영에서는 보안상 직접 접속이 막혀 있는 경우가 흔하니, 네트워크팀과 인프라팀을 초반부터 같이 끌고 가는 게 좋습니다.

S/4HANA에서는 OData/REST 기반 표준 API 활용 범위는 커졌지만, 기존 RFC/BAPI 기반 외부 연동은 여전히 많이 사용됩니다. 다만 신규 개발은 Clean Core 관점에서 표준 API 우선 검토가 권장됩니다.

SAP 버전에 따라 동작이 다를 수 있으니 SAP Help Portal 확인을 권장합니다.

 

MCP SAP RFC Tool 구현: 실무 체크리스트와 활용 팁

MCP SAP RFC Tool 구현은 생각보다 “AI”보다 “기본 연결”이 중요합니다. 현장에서 보면 성공 비율은 대략 SAP 설정 70%, 백엔드 구조 20%, 프롬프트 10% 정도 느낌입니다. Claude가 똑똑해도 SAP 자격증명을 직접 들고 가게 만들면 운영에서 바로 막힙니다. 반드시 Backend에서 인증, 로깅, 마스킹, 재시도 정책을 잡아야 합니다.

결국 AI 연동이라고 해서 특별한 비밀이 있는 건 아닙니다. SAP 외부 연동의 기본기를 제대로 세운 팀이 결국 MCP Tool도 가장 안정적으로 운영합니다.

PyRFC, node-rfc 실무 팁 비교

항목	PyRFC SAP 연결	Node RFC SAP
필수 라이브러리	SAP NW RFC SDK 필요	SAP NW RFC SDK 필요
OS 변수	Windows PATH, Linux LD_LIBRARY_PATH	동일
주의점	Python 버전 호환성	Node 버전·빌드 의존성
추천 테스트	Connection.ping(), STFC_CONNECTION	동일

• sapnwrfc.dll 또는 libsapnwrfc.so가 실제 경로에 있어야 합니다.

• SDK 버전과 런타임 버전 불일치는 생각보다 흔한 원인입니다.

• 대량 데이터는 한 번에 다 받지 말고 Pagination이나 배치 조회로 나누세요.

• 쓰기성 BAPI는 Commit 처리까지 한 트랜잭션 단위로 설계하세요.

• DEV/QAS/PRD는 계정과 연결 정보를 반드시 분리하세요.

 

보안은 특히 신경을 써야 합니다. 회사에서 사용한다면 더 조심해야겠죠. Claude MCP Tool이나 외부 AI 도구에 SAP 계정 정보를 직접 전달하지 마세요. 자격증명은 Backend의 비밀관리 체계에서 보관하고, AI로 나가는 응답에서는 개인·금융 민감정보를 마스킹해야 합니다.

SAP 공식 기능과 외부 AI 도구 적용 범위 비교

구분	SAP 공식 AI(Joule)	외부 AI 도구 + MCP
통합 편의성	SAP 생태계 내 강점	유연성 높음, 구현 부담 큼
SAP 데이터 접근	표준 서비스 중심	RFC Tool, BAPI, Backend 설계 자유도 높음
보안/거버넌스	SAP 표준 정책 연계 용이	별도 설계 필수
커스터마이징	제한적일 수 있음	업무 맞춤형 구현 유리

 

PyRFC는 연결되는데 특정 FM만 실패했던 케이스도 있었습니다. 알고 보니 전체 접속 권한은 있었지만, S_RFC에서 필요한 함수 그룹이 빠져 있었습니다. 이런 경우 개발자는 “왜 어떤 함수는 되고 어떤 함수는 안 되지?”에서 오래 고민할 수 있습니다.

 

SAP RFC 호출 구조 기준 에러 및 연동 오류 해결

에러는 메시지만 보면 비슷해 보여도 원인이 다릅니다. 그래서 저는 항상 “인증 → 네트워크 → 권한 → ABAP 덤프” 순서로 봅니다. 이 순서를 지키면 불필요한 디버깅을 크게 줄일 수 있습니다.

RFC 장애는 한쪽 로그만 보면 놓치는 게 많습니다. SAP 로그와 백엔드 로그를 같이 봐야 원인이 정확히 드러납니다.

에러/증상	주요 원인	확인 위치	해결 방법
CALL_FUNCTION_REMOTE_ERROR	FM 내부 ABAP Dump	ST22, SE37	Dump 원인 분석, 입력값 검증, 예외 처리 보강
LOGON_FAILURE	계정 오류, Client 불일치, 계정 잠김	SU01, 보안 로그	비밀번호 초기화, Client 재확인, 서비스 계정 점검
RFC_COMMUNICATION_FAILURE	네트워크, Gateway, 방화벽	SMGW, OS 포트 테스트	포트 오픈, SAProuter/Host 정보 수정
NO_AUTHORITY	S_RFC 부족	SU53, PFCG	권한 역할 수정, 허용 FM 범위 재설정

 

1. STFC_CONNECTION으로 기본 연결 테스트

2. 안 되면 계정과 CLIENT 확인

3. 그래도 안 되면 포트와 Gateway 확인

4. 연결되는데 특정 FM만 실패하면 SU53와 S_RFC 확인

5. 권한도 맞는데 실패하면 ST22 Dump 확인

6. 쓰기성 BAPI는 Commit 누락 여부까지 점검

 

도구 버전 및 SAP 환경에 따라 동작이 다를 수 있으니 공식 문서 확인을 권장합니다.

 

MCP SAP RFC 연동 현업 인사이트: 결국 성공은 SAP 설정에서 결정된다

오랜기간 프로젝트를 수행하거나 운영업무를 보면서 느낀 건, 새로운 기술이 등장할 때마다 사람들은 늘 “이제 기존 방식은 끝났다”고 말한다는 점입니다. RFC도 마찬가지였습니다. OData가 나오고 API Hub가 커지면서 다들 RFC는 곧 사라질 것처럼 이야기했죠. 그런데 실제로는 어땠냐면, 전표 처리나 자금관리처럼 검증이 복잡한 업무는 여전히 RFC/BAPI가 핵심이었습니다. 당시에도 이런 말이 있었지만 실제로는 기존 인터페이스를 이해한 사람이 새로운 구조도 더 잘 만들었습니다.

제 관점은 분명합니다. MCP SAP RFC 연동은 충분히 실무적이고, 당장 써먹을 수 있습니다. 다만 AI Tool에만 시선을 빼앗기면 실패합니다. 먼저 SAP RFC 호출 구조를 이해하고, 서비스 계정·권한·Gateway·커밋·감사로그를 탄탄히 잡으세요. 그 위에 Claude MCP Tool 함수를 올려야 운영에서 버팁니다. 독자분들이 지금 시작한다면 순서는 이렇습니다. 첫째, STFC_CONNECTION으로 기본 연결 성공. 둘째, ZRFC 또는 안전한 BAPI 범위 정의. 셋째, Backend에서 마스킹과 로깅 설계. 이 순서면 됩니다.

 

마무리: SAP 외부 연동은 기술보다 구조가 먼저입니다

• MCP SAP RFC 연동의 핵심은 AI가 아니라 SAP 설정, 권한, 네트워크입니다.

• PyRFC SAP 연결과 Node RFC SAP 모두 기본 구조는 같고, Backend Layer는 필수입니다.

• FI/TR 업무에서는 BAPI 호출 후 Commit, 권한 범위, 민감정보 통제가 특히 중요합니다.

 

여러분도 비슷한 이슈를 겪으셨다면 댓글로 공유해주세요. PyRFC 실전 코드가 필요하시면 OS와 Python 버전, 또는 Node 버전을 남겨주시면 다음 글에서 환경별 예제로 이어가보겠습니다. 다음에 읽으면 좋은 글로는 “PyRFC SAP 연결 실전 코드”와 “Node RFC SAP + MCP Tool 구현 가이드”를 추천드립니다.

 

참고 출처

• SAP Help Portal, NetWeaver RFC 관련 문서: https://help.sap.com/docs/SAP_NETWEAVER

• SAP NetWeaver RFC SDK: https://support.sap.com/en/product/connectors/nwrfcsdk.html

• SAP Note 460089: RFC Authorization 관련 참고