SAP MES 인터페이스, 홀과 주방을 잇는 웨이터의 기술

안녕하세요, Rabbit입니다! 🐰

홀 매니저가 주문을 받았습니다. 그런데 주방에 전달할 방법이 없습니다. 직접 주방까지 달려가자니 다음 손님이 기다리고, 소리를 지르자니 홀 분위기가 어수선해집니다. 결국 레스토랑이 제대로 돌아가려면 홀과 주방 사이에 웨이터가 있어야 합니다. 주문을 받아 주방에 전달하고, 완성된 요리를 다시 홀로 가져오는 역할이죠.

SAP와 MES 사이에서 이 웨이터 역할을 하는 것이 인터페이스입니다. 프로젝트 현장에서 “RFC로 할지 PI/PO로 할지”, “동기로 갈지 비동기로 갈지” 같은 논의가 나올 때, 그게 바로 웨이터를 어떻게 운영할지 정하는 대화입니다.

인터페이스가 왜 필요한가

SAP와 MES는 서로 다른 회사가 만든 별개의 시스템입니다. 데이터 형식도, 통신 방식도, 사용하는 언어도 다릅니다. 인터페이스 없이 직접 연결하려면 둘이 서로의 언어를 이해해야 하는데, 현실에서 그렇게 구축된 경우는 거의 없습니다.

레스토랑으로 보면 이렇습니다. 홀 매니저(SAP)가 쓰는 주문서 양식과 주방(MES)이 쓰는 조리 지시서 양식이 다릅니다. 웨이터(인터페이스)가 없으면 홀 매니저가 직접 주방 언어로 주문서를 다시 써야 합니다. 비효율적이고 오류도 잦습니다.

인터페이스는 이 변환과 전달을 자동으로 처리하면서, 데이터가 제대로 흘렀는지까지 확인합니다. 인터페이스가 끊기면 재고 데이터가 맞지 않고, 생산 실적이 SAP에 반영되지 않아 원가 계산이 틀어집니다.

RFC: 직통 전화 방식

RFC(Remote Function Call)는 SAP가 MES에 직접 함수를 호출하는 방식입니다. 중간에 아무것도 없이 직통으로 연결합니다. ‘직통 전화’라고 생각하면 정확합니다.

SAP가 MES에 전화를 걸어 “지금 A 제품 재고 100개 있어?”라고 물으면, MES가 창고를 확인해서 “맞아, 100개 있어”라고 즉시 답합니다. SAP는 그 답을 받은 뒤에야 다음 업무를 시작합니다.

💡 핵심: RFC는 빠르고 단순합니다. 직접 연결이라 통신 지연이 없고, 실시간으로 결과를 확인할 수 있습니다.

반면 단점도 명확합니다. MES가 시스템 점검 중이거나 응답이 늦어지면, SAP도 그 자리에서 기다려야 합니다. 한쪽의 장애가 다른 쪽으로 전파되는 구조입니다. 시스템이 복잡해질수록 이 취약점이 부각됩니다.

RFC는 단순하고 빠르지만, 연결하는 시스템이 2개를 넘거나 운영 환경의 안정성을 중시해야 할 때는 PI/PO 방식을 검토하게 됩니다.

PI/PO: 중앙 관제 방식

PI/PO(Process Integration / Process Orchestration)는 SAP와 MES 사이에 중간 관제 시스템을 두는 방식입니다. 모든 통신이 이 중간 시스템을 거칩니다. ‘만능 통역사’가 중앙에서 모든 대화를 관리한다고 보면 됩니다.

SAP가 메시지를 보내면 PI/PO가 받아서 MES가 이해하는 형식으로 변환해 전달합니다. 반대 방향도 마찬가지입니다. 홀 매니저(SAP)가 웨이터(PI/PO)에게 주문서를 건네면, 웨이터가 주방 언어로 바꿔서 주방(MES)에 전달하는 구조입니다.

RFC보다 구조가 한 단계 복잡하지만, 현장에서 PI/PO를 선호하는 이유는 세 가지입니다.

• 안정성: MES가 잠깐 다운돼도 PI/PO가 메시지를 보관하고 있다가 정상화되면 재전송합니다. 데이터가 유실되지 않습니다.
• 유연성: MES 외에 WMS(창고관리시스템), QMS(품질관리시스템) 등 여러 시스템과 동시에 연결할 수 있습니다. 여러 나라 말을 하는 통역사처럼, 연결 대상이 늘어나도 유연하게 대응합니다.
• 모니터링: 모든 통신 이력이 PI/PO에 남습니다. 데이터가 언제, 어디서, 어떤 오류로 막혔는지 추적하기 쉽습니다.

대형 제조 프로젝트에서 PI/PO 방식이 더 선호되는 건 이 세 가지 장점 때문입니다.

그림 1. RFC와 PI/PO의 구조 비교

동기와 비동기: 대화 스타일의 선택

연결 방식(RFC, PI/PO)을 정했다면, 다음엔 소통 스타일을 정해야 합니다.

동기(Synchronous): 카카오톡에서 ‘1’ 읽음 표시가 사라질 때까지 기다리는 방식입니다. SAP가 요청을 보내고 MES의 응답이 올 때까지 다음 업무를 멈춥니다. 실시간으로 결과를 확인해야 할 때, 예를 들어 반제품 재고가 실제로 있는지 확인한 뒤 생산오더를 생성해야 하는 상황에서 씁니다.

비동기(Asynchronous): “시간 될 때 답장 줘”처럼 쿨한 방식입니다. SAP가 오늘 생산할 계획 수백 건을 한꺼번에 MES에 던져두고, 응답을 기다리지 않고 다음 업무로 넘어갑니다. 대량의 생산 계획을 안정적으로 전달하는 데 적합합니다.

그림 2. 동기·비동기 소통 방식 비교

⚠️ 주의: 비동기 방식은 SAP 입장에서 전달 직후 MES가 제대로 받았는지 즉시 확인하기 어렵습니다. 별도 모니터링이나 오류 알림 체계가 함께 설계돼야 합니다.

RFC와 PI/PO, 동기와 비동기 중 어느 쪽이 더 좋다고 단정할 수 없습니다. 실시간 확인이 필요하면 동기, 대량 전달이 중요하면 비동기를 조합해 쓰는 것이 인터페이스 설계의 핵심입니다.

Rabbit의 한 끗

인터페이스를 개발자가 알아서 설계하면 된다고 생각하면 절반만 맞습니다. 어떤 데이터를 언제, 어느 방향으로, 얼마나 자주 주고받아야 하는지는 현업 실무자가 가장 잘 압니다.

“이 업무는 실시간 확인이 필요한가, 아니면 안정적인 대량 전달이 더 중요한가”라는 기준을 갖고 있으면, 개발자와의 논의가 훨씬 구체적이 됩니다. SAP PP 실무자가 인터페이스 회의에서 제대로 된 요건을 전달할 수 있을 때, 프로젝트 품질이 달라집니다. 😎

---

더 읽어보기

• SAP MES, 총괄 셰프와 주방 팀의 완벽한 분업
• SAP Activity와 CNF, 주방일지를 주방장에게 보고하는 순간