[CIOBIZ+] Tech&Trend-필요한 프로세스만 골라 `맞춤 업무 애플리케이션` 구축

　넥스트 ERP : 비즈니스 프로세스 플랫폼(BPP)

#통신 서비스 업체 A사는 자회사 B를 통합해 새롭게 출범했다. 모기업인 A사는 오라클 ERP를, 통합된 자회사 B는 SAP ERP를 사용해 왔다. 그러면 이제 이 통합 통신 서비스 회사는 오라클 혹은 SAP 둘 중 하나를 선택해야 할까? 관례대로 모기업인 A사가 사용하던 오라클 ERP로 통합하자니 오래 전 구축한 것이라 버전이 낮고 활용도나 적용 범위도 B사만 못하다. 따라서 A사 ERP로 통합하면 ERP 업그레이드 비용과 통합 작업이 만만치 않을 것이고, B사에서는 구축한 지 얼마 되지 않은 ERP를 폐기한다고 불만이 많을 듯하다.

#제조 부문 중견 그룹사 C는 그룹IT통합 프로젝트를 추진하고 있다. 지금까지 각 계열사가 정보화 추진팀을 각각 두고 IT 프로젝트를 수행해 왔다. 그러다보니 각사는 저마다의 전략을 가지고 자사 업무와 프로세스에 특화된 애플리케이션들을 도입, 구축한 상태다. 제조업 계열사가 주를 이루는 만큼 대부분 ERP를 도입했지만 SAP, 오라클, 영림원 등 다양한 제품이 구축돼 있고 미들웨어도 각각 다르다. 유사하거나 중복되는 기능들이 많고 각사 단위 업무 시스템들간 인터페이스도 너무 많다. 그룹 IT통합을 무엇부터 시작해야 할지, 그리고 과연 시간과 비용이 얼마나 걸릴지 걱정스러운 상태다.

#에너지 서비스 업체 D는 최근 발전자회사 4군데와 통합 ERP를 구축하기로 했다. 1개사를 제외한 나머지 자회사와 모기업 D사는 이미 SAP 기반으로 ERP를 구축한 상태여서 통합ERP 또한 SAP 솔루션이 도입될 가능성이 높다. 그러나 몇백억원의 예산을 투입해 대대적으로 도입하는 만큼 미래 업무 효율성을 담보하고 법 규제 및 비즈니스 환경 변화에 신속히 대응할 수 있는 솔루션을 원하고 있다. IFRS 적용은 물론, 곧 다가올 탄소 배출량 제한에도 대비해야 한다. 미국의 경우 이미 온실가스 배출을 제한하기 위해 전력회사의 발전소에 규제를 가하고 있다. 새로 구축되는 통합 ERP는 아직 국내에 확정되지 않은 규제에 대해서도 추후 유연하게 반영할 수 있어야 한다.

　위 예는 조직 통합, IT 통합을 앞둔 기업들만의 고민은 아니다. ERP 업그레이드를 검토중인 기업, 현재 ERP를 사용하고 있지 않는 기업이라고 해도 동일한 문제와 고민에 당면하고 있다.

　기존 애플리케이션의 업그레이드 혹은 추가 애플리케이션 개발이 다른 애플리케이션 서비스에 미칠 영향, 연동과 상호 운영성 문제, 인터페이스 작업과 소요되는 리소스 고민은 그 어떤 애플리케이션도 마찬가지다. 진화하는 ERP가 그 고민을 해결해줄 수 있다.

　ERP는 대표적인 기업 애플리케이션이자 근간이 되는 업무 시스템이다. 그동안 확장형 ERP, ERP II로 계속 진화해 왔다. 이제 ERP는 기업 애플리케이션이면서 동시에 다른 애플리케이션의 플랫폼으로서 기능하는 모습을 보이고 있다. 최근 발표된 SAP 비즈니스 스위트 7, 그리고 2010년 공개 예정인 오라클 퓨전 애플리케이션에 앞서 발표된 오라클 퓨전 미들웨어 11g에서 그 면모를 찾아볼 수 있다.

　SAP 비즈니스 스위트 7과 오라클 퓨전 애플리케이션은 비즈니스 프로세스, 강력한 미들웨어, 조합 애플리케이션 개발 환경을 제공하면서 기업 자원 관리의 영역을 벗어나 비즈니스 프로세스 플랫폼(BPP)으로 자리매김하려 하고 있다.

　두 회사가 추구하는 공통점은 △기존 ERP 모듈보다 더 세분화된 단위로 비즈니스 프로세스를 나누고 △이 프로세스 서비스들이 저장된 서비스 리포지터리 혹은 서비스 레지스트리에서 기업은 자사에 필요한 것만 선택 구축하며 △ERP를 기업 고유의 애플리케이션이나 타사 애플리케이션을 조합 개발 및 연동, 통합할 수 있는 확고한 플랫폼으로 만든다는 것이다.

　이에 따라 새로 발표되거나 발표될 ERP는 기존 전통적 의미의 ERP 애플리케이션으로서의 역할과, 타 애플리케이션 통합 구축의 플랫폼으로서의 역할을 동시에 제공하게 된다. 차세대 ERP로의 변모를 가능케 하는 동인은 크게 세 가지다. △비즈니스 프로세스와 서비스의 매핑 △조합 애플리케이션 개발 △서비스지향아키텍처(SOA)의 기반으로서 강력한 미들웨어가 그것이다.

　◇ERP, BPP로 진화=포레스터 리서치 연구에 따르면 주요 애플리케이션의 업그레이드와 빈번한 패치 유지보수는 많은 기업들의 고민이 되고 있다. 애플리케이션 업그레이드 추가 비용과 작업, 예상치 못한 시스템 중단을 감수해야 하기 때문이다.

　오라클은 주요 포인트 솔루션의 업그레이드 비용이 애플리케이션 초기 구현 비용의 18∼20%에 이른다고 주장한다. 보통 2년을 주기로 주요 업그레이드 버전이 발표되고, 사용하는 포인트 소프트웨어가 많을수록 비용은 증가할 수밖에 없다.

　카네기멜론대학의 소프트웨어엔지니어링연구소(Software Engineering Institute)는 이 문제를 해결하기 위해 애플리케이션 구현 및 사용주기 방법론에 사용자 정의 코드, 타 시스템에 대한 링크·인터페이스와 비즈니스 프로세스를 포함시킬 필요가 있다고 지적했다. 이는 애플리케이션이 비즈니스 프로세스를 반영하고 SOA 기반으로 구축돼야 한다는 뜻이다. 오라클, SAP가 자사 ERP와 미들웨어를 단단히 결합해 BPP로 입지를 굳히려는 이유이기도 하다.

　SAP는 SAP ERP 6.0의 업그레이드 제품으로 ‘SAP ERP 7.0’이 아니라 ‘SAP 비즈니스 스위트 7’을 발표했다. SAP 미들웨어인 넷위버에 기반해 BPP를 제공한다는 것이 제품명 변경의 배경이다.

　SAP 비즈니스 스위트 7의 가장 큰 특징은 기존 모듈들을 더욱 세밀하게 구분해 2800여 비즈니스 프로세스로 나눈 것이다. 기존 SAP ERP, SAP CRM, SAP SRM, SAP SCM, SAP PLM 등 비즈니스 애플리케이션에 담겨 있는 기능을 일정한 프로세스 패턴으로 분석한 다음 상호 연동이 쉽도록 프로세스 단위로 쪼개고 이 프로세스 서비스들을 묶어 프로세스 컴포넌트를 구성했다. 비즈니스 프로세스들은 엔터프라이즈 서비스 리포지터리(ESR)에 저장돼 있으므로 기업은 필요한 프로세스 서비스만 골라 구축하면 된다.

　마크 깁스 SAP 북아시아 사장은 “사전 준비된 베스트 프랙티스의 프로세스를 선택적으로 추가하는 컨피규레이션만으로 기업이 원하는 업무 애플리케이션이 구축된다”며 이전처럼 코딩 작업(커스터마이징)을 할 필요가 없다고 설명한 바 있다.

　박범순 SAP코리아 부장은 “기존의 소프트웨어 애플리케이션을 비즈니스 서비스 단위로 잘게 나눈 이유는, 보다 편리하게 이들 서비스를 재배치하고 더 나은 서비스와 쉽게 결합할 수 있도록 하기 위해서”라고 설명한다. 누구나 이해하기 쉬운 비즈니스 서비스를 중심으로 비즈니스 프로세스를 정의하면 개선이 필요한 부분과 시점을 훨씬 더 쉽게 포착해 비즈니스 혁신을 유도할 수 있다.

　SAP코리아는 SAP 비즈니스 스위트 7로 이기종 애플리케이션의 벽을 뛰어넘는 유연한 프로세스 통합이 가능해진다고 주장한다. 또 ESR에 저장된 서비스와 프로세스 컴포넌트를 활용해 기업은 자사 고유의 업무 프로세스를 개발, 정립하고 그에 따라 프로세스 서비스들을 재배치 및 추가함으로써 맞춤 프로세스를 구성할 수 있다.

　SAP 비즈니스 스위트 7에 대응할 오라클의 퓨전 애플리케이션 스위트는 아직 발표 전이다. 2010년, 이르면 2009년말 일부 고객들에게 제공될 예정이지만 그마저도 명확치 않다.

　오라클 퓨전 애플리케이션은 오라클 E-비즈니스 스위트, JD에드워드, 피플소프트와 시벨 제품군 등에서 최고의 기능과 특장점을 취하게 된다. 찰스 필립스 오라클 사장이 지난해 오라클 오픈월드에서 언급한 퓨전 애플리케이션의 비전은 ‘차세대 엔터프라이즈 애플리케이션의 완벽한 표준이 되는 것’이다.

　당초 발표 예정보다 지연되는 것에 분석가들은 오라클의 퓨전 애플리케이션에서 다뤄야 할 기술들이 너무 많기 때문이라고 지적한다. 오범에 따르면 오라클 퓨전 애플리케이션은 단순한 SOA가 아니다. “퓨전 애플리케이션 전반에 걸쳐 비즈니스 인텔리전스와 웹 2.0을 통합해야 하며, 사일로(silo) 수준의 애플리케이션들이 모듈들을 따라 흐르는 엔드-투-엔드(종단간) 비즈니스 프로세스로 변화되는 것”이라고 오범은 설명했다.

　최근 발표된 퓨전미들웨어 11g의 SOA 스위트 11g는 서비스를 비즈니스 프로세스 기반으로 조합, 관리, 운영하기 위한 BPEL 프로세스 매니저, BAM(Business Activity Monitoring), BRE(Business Rule Engine)가 제공된다.

　◇신규 애플리케이션도 ERP에서 간단히 개발=애플리케이션 플랫폼으로서 차세대 ERP가 주는 또다른 혜택은 기업이 자사에 필요한 애플리케이션을 보다 간편하고 신속하게 개발할 수 있다는 것이다. 조합 애플리케이션 환경(Composite Application Environment)이 제공되기 때문이다.

　SAP는 조합 애플리케이션 프레임워크(Composite Application Framework. CAF)를 제공한다. CAF와 서비스 리포지터리(ESR)을 활용해 기업은 자사 고유의 비즈니스 프로세스를 ERP라는 단일 플랫폼 위에서 신속히 개발 또는 맞춤 구성할 수 있다. 특히 SAP는 기존 개발 언어인 ABAP 외에 자바 지원도 강화함으로써 타 애플리케이션에 대한 개방성과 통합성을 확보하게 됐다.

　퓨전 애플리케이션 발표 전인 한국오라클에서는 오라클 서비스 버스(OSB)로 기업이 원하는 맞춤 어댑터(Custom Adpator)를 제작할 수 있는 SDK(소프트웨어 개발 키트)를 제공하고 있음을 강조한다. OSB는 웹서비스뿐 아니라 JMS, EJB, HTTP 등 다양한 프로토콜을 지원하는 어댑터를 제공하며 이 어댑터로 연결할 수 있는 모든 애플리케이션은 별도의 프로그래밍 없이 서비스화 된다.

　서비스화된 애플리케이션은 ‘플로(Flow)’라고 부르는 사용자 요청 처리 로직에서 자유롭게 조합할 수 있다. 한국오라클은 연결하는 레거시 애플리케이션의 프로토콜에 무관하게 동일한 방식으로 유연하게 조합할 수 있다고 설명했다.

　또한 오라클 퓨전 미들웨어 11g 제품군에서 보다 강력해진 서비스 개발 능력을 강조하고 있다. 퓨전 미들웨어 11g 제품군 중 하나인 SOA 스위트 11g에서 주목할 기능은 네이티브 서비스 컴포넌트 아키텍처(SCA:Native Service Component Architecture) 기반 SOA 플랫폼 및 디자이너다. 한국오라클은 네이티브 SCA 디자이너에 대해 드래그&드롭으로 복합 애플리케이션을 개발, 구축, 실행, 관리할 수 있어 개발자의 생산성을 향상시킬 수 있다고 설명했다.

　◇미들웨어와 프로세스 서비스의 결합=애플리케이션 플랫폼으로서 ERP는 강력한 미들웨어 지원 없이는 불가능하다. 이 점에서 보면, 오라클과 SAP의 전략은 차이가 난다. 미들웨어와 다양한 애플리케이션 포트폴리오가 오라클의 강점이라면, 확장 ERP 기능에 충실한 풍부한 비즈니스 프로세스 서비스와 이를 담은 서비스 리포지터리가 SAP의 강점이다.

　퓨전 애플리케이션 발표 전인 오라클은 BEA시스템즈 인수 후 미들웨어 시장에서 영향력을 확장해 나가고 있으며, 미들웨어의 중요성에 목소리를 높인다. 현 상태에선 맞춤 서비스 개발과 비즈니스 프로세스 통합 관리를 미들웨어가 담당하고 있기 때문이다.

　한국오라클은 오라클 미들웨어 상에서는 SAP 프로세스의 맞춤별 구성이 가능하다고 주장한다. 이종영 한국오라클 상무는 “프로세스 연동 부분이 비록 SAP라도 오라클 SOA 기반에서는 쉽게 통합 연동할 수 있으며, 표준 프로세스가 SAP 고유의 것이라도 설계 단계에서 운영단계로 쉽게 전환시킬 수 있다”고 말했다. 오라클 패키지라면 오라클 AIA(Application Integration Architecture)를 통해 더욱 손쉽게 개발할 수 있다.

　오라클에 비해 상대적으로 미들웨어가 약세인 SAP는 미들웨어의 역할보다 비즈니스 프로세스의 역할을 더 강조한다. 이벤트가 발생하면 그 메시지를 해당 프로세스, 시스템 등에 전달하는 미들웨어가 중요하긴 해도 애플리케이션 플랫폼의 완성도는 결국 비즈니스 프로세스의 베스트 프랙티스에 달려 있다는 주장이다.

　◇이기종 애플리케이션 운영 플랫폼으로서 ERP=지금까지는 여러 벤더의 플랫폼을 사용하는 기업에서 통합 애플리케이션 환경을 구현하고자 할 때, 하나를 취하면 다른 하나는 버려야 하는 제로섬 게임이 존재했다. 연결재무제표와 같이 제3의 시스템을 통해 데이터 중심으로 연동하던 것이 최선이었다. 그러나 애플리케이션 플랫폼, 비즈니스 프로세스 플랫폼으로서 ERP가 온전히 제 역할을 하게 되면 보다 수월하게 이기종 ERP 시스템을 통합 운영할 수 있게 된다.

　한 컨설팅 업체 관계자는 “이론상으로는 이전에도 SAP, 오라클, 그 외 다른 벤더의 플랫폼이 웹서비스 표준을 따르는 한, 타 ERP 시스템에 있는 기능을 서비스화하고 리포지터리에서 호출해 통합 관리할 수 있다”고 말한다. 그러나 하드 코딩에 의한 서비스 개발, 비즈니스 프로세스와의 연동 등 작업에 소요되는 리소스를 감안하면 차라리 한 애플리케이션으로 단일화하는 것이 더 효율적인 방법이었다는 것이다.

　ERP가 비즈니스 프로세스 플랫폼으로 진화를 거듭할수록 사용자 선택의 폭이 넓어진다. 서비스나 상품의 중복이 거의 없을 경우, 중복이 심할 경우, 혹은 기업이 오랜 정보화 경험을 바탕으로 고유의 시스템 템플릿을 갖고 있거나 그렇지 못할 경우 등 기업이 처한 입장과 상황에 따라 선택할 수 있는 통합 방법이 다양해지는 것이다.

　박현선기자 hspark@etnews.co.kr