이번 프로젝트에서 IF(Interface)를 담당하게 되어 관련된 경험을 남겨본다.
외부 서비스를 이용할 때 보통은 공개된 API를 활용하거나, 마땅한 게 없으면 타업체와 협업해서 API 규약을 새로 만든다. 그러나 대기업의 경우는 이미 사용 중인 솔루션이 많기 때문에, 이를 각 솔루션과 일일이 직접 연동하다 보면 구조가 금세 복잡해진다. 게다가 API마다 보안도 따로 챙겨야 하니 유지보수도 만만치 않다.
그래서 나온 개념이 EAI(Enterprise Application Integration) 다. 대부분의 대기업은 외부와 통신할 때 가장 앞단에 EAI를 두고 데이터를 주고받는다.
EAI의 핵심 아이디어
EAI는 단순히 "시스템을 연결한다"는 의미가 아니다. 이질적인 시스템 간에 데이터와 비즈니스 프로세스를 일관되게 흐르게 만드는 것이 본질이다.
대표적인 통합 패턴은 다음과 같다.
- Point-to-Point: 시스템끼리 1:1로 직접 연결. 단순하지만 시스템이 N개면 연결선은 N(N-1)/2개로 폭발한다.
- Hub-and-Spoke: 중앙 허브를 두고 모든 시스템이 허브와 통신. 관리는 쉬워지지만 허브가 SPOF(Single Point of Failure)가 된다.
- ESB(Enterprise Service Bus): 메시지 버스 위에서 서비스가 느슨하게 결합. 라우팅, 변환, 오케스트레이션을 버스가 담당한다.
도구가 문제를 해결해주지는 않는다
국내에서는 webMethods, MuleSoft, IBM Integration Bus 같은 전통적 EAI/ESB 솔루션이 여전히 많이 쓰인다. 최근에는 iPaaS(Integration Platform as a Service) 형태로 Boomi, MuleSoft Anypoint 같은 클라우드 기반 도구도 자리잡고 있다.
다만 도구는 문제를 해결해주지 않는다. 인터페이스 정의서가 명확하지 않으면 어떤 솔루션을 깔아도 결국 진흙탕이 된다. 어떤 시점에 어떤 데이터가, 어떤 키로, 어떤 형식으로 흐르는지를 사람이 먼저 정리해야 한다.
실제 사례: Salesforce → webMethods → SAP
이번에 진행 중인 프로젝트의 구조다. 영업이 Salesforce에서 수주를 등록하면, 주문 정보가 webMethods를 거쳐 SAP로 전달되어 생산·물류 프로세스가 시작된다.
여기서 자주 나오는 오해 하나. "webMethods는 가운데에서 그냥 데이터 넘기는 통로 아닌가?"
아니다. 가운데에 있다는 이유로 단순한 프록시처럼 보이지만, EAI 미들웨어가 실제로 하는 일은 단순 중계와는 거리가 멀다.
- 데이터 변환(Transformation): Salesforce의 Order 객체 JSON을 SAP가 받을 수 있는 IDoc / BAPI / OData 페이로드로 매핑한다. 필드명, 자료형, 코드 체계가 모두 다르기 때문에 단순 복사는 불가능하다.
- 프로토콜 중계(Protocol Mediation): Salesforce 쪽은 REST/SOAP, SAP 쪽은 RFC, IDoc, OData V4 등 양쪽이 쓰는 통신 방식이 다르다. webMethods가 이 차이를 흡수한다.
- 라우팅(Routing): 하나의 Salesforce 이벤트가 SAP에서 여러 트랜잭션으로 분기되는 경우가 흔하다. 조건에 따라 어디로 보낼지 결정하는 것도 미들웨어 몫이다.
- 신뢰성(Reliability): SAP가 일시적으로 응답하지 않을 때, webMethods 큐에 메시지를 보관하고 재시도한다. Salesforce 호출은 이미 끝났는데 SAP가 다운되어 있어도 데이터가 유실되지 않는다.
- 모니터링과 추적(Monitoring & Audit): 어느 메시지가 어디서 막혔는지, 어떤 데이터로 어떤 변환을 거쳤는지 한 곳에서 본다. 장애가 났을 때 가장 먼저 보는 곳이 여기다.
- 보안 중앙화: Salesforce가 SAP 자격 증명을 알 필요가 없다. webMethods가 양쪽 시스템과의 인증을 분리해서 관리한다.
즉, webMethods는 "지나가는 길"이 아니라 변환·라우팅·완충 장치 역할을 하는 자율적인 시스템이다. 잘 설계된 미들웨어 계층이 있어야 양 끝단의 시스템이 서로의 변경에 영향받지 않고 독립적으로 진화할 수 있다.
SAP 측 인터페이스로는 전통적으로 IDoc과 BAPI(RFC)가 쓰였지만, 최근에는 OData V4 API(예:
CE_SALESORDER_0001Sales Order 표준 API)도 옵션으로 검토할 만하다. 양쪽 모두 webMethods 어댑터로 처리 가능하다.
마무리
IF를 진행하면서 새삼 느끼는 건, 결국 가장 중요한 건 비즈니스의 정의, 즉 인터페이스를 어떻게 정의할 것인가라는 점이다. 정의만 명확하다면 각 시스템 담당자들은 규칙대로 보내고 받기만 하면 되기 때문이다.
문제는, 언제나 그렇듯 인터페이스를 빠르게 정의하고 일을 시작하는 것이 쉽지 않다는 점이다. 도메인을 맡은 현업 부서와 IT 부서가 나뉘어 있다 보니 팀 내부 소통도, 외부 솔루션사와의 소통도 함께 풀어야 한다. 그래서 이번 일은 개발 난이도가 높다기보단, 사람과 사람 사이의 소통을 어떻게 풀어가는지가 핵심인 것 같다.
시간은 없고 오픈일은 다가오는데 IF 정의는 안 되는 — 그런 최악의 상황만큼은 피하고 싶다.
