일본 애니메이션 공각기동대를 보다 보면 주인공인 “모토코”가 정보처리를 위해 다른 시스템을 연결해서 사용하는 것이 나옵니다. 대규모 연산을 위해서 자신의 컴퓨터에서 처리하는 것이 아니라 다른 컴퓨터에서 연산을 돌려서 그 결과를 받는 병렬/분산처리를 하는 것이죠. 실제로 이런 장면은 애니메이션에서만 나오는 것은 아니고 미드인 "24시"에서도 대규모 연산을 위해 다른 시스템의 사용허가를 받고 그 자원을 이용해서 연산을 처리하는 장면들이 나옵니다.

이것이 요즘 IT업계에서 회자되고 있는 SOA 개념과 상당히 유사한 점이 많은데, 실제로 SOA의 개념을 이용해서 시스템을 구현해 보시면 아시겠지만, 이를 실제 업무에 적용하기에는 상당한 어려움이 존재합니다. 드라마나 애니메이션에서 대규모 데이터가 병렬/분산으로 쉽게 처리되는 것과 다르게 특수한 환경이 아닌 경우를 제외하고는 이런 처리를 하기 위해서는 상당한 노력이 동반되기 때문입니다.

대규모 연산의 경우는 그래도 좀 분리하기가 쉬울 수 있겠지만, 다량의 데이터를 처리해야 하는 경우에는 상당한 량의 데이터를 각 서버에 보내야 하고, 이들 서버에서 처리되는 것을 받아서 통합 처리해야 하는 엄청난 일을 해야 합니다. 또한, 이런 일들을 자신의 모바일 장비에서 간단한 조작으로 가능하기 위해서는 대규모 데이터를 저장하고 있는 서버와 이를 처리를 위한 미들웨어 그리고 데이터들을 자연스럽게 흘릴 수 있는 데이터 통신 표준 및 코딩방식 등이 정해져 있어야 한다는 것입니다.

EDI vs. XML - 최신의 기술만이 항상 최고는 아니다

하지만, SOA 기반의 미들웨어는 XML 기반으로 데이터를 처리하는 관계로 기존의 Structure 형태를 띠고 있는 EDI에 비해 현저한 성능저하가 발생합니다. 따라서, 벤더들은 이러한 문제를 해결하기 위해 Parsing을 전문적으로 하는 서버의 설치를 권하기도 하는데, 이는 근본적인 문제를 해결하는 것이기보다는 문제를 악화시킬 가능성이 더 높습니다. (댓글에서 Tuna님이 말씀하신 것처럼 저도 대규모 데이터 처리 시에는 XML보다는 CSV 방식으로 저장된 데이터를 이용하여 처리하는 것이 바람직하다고 생각하고 있으며, 이러한 처리는 SOA 기반 미들웨어에서도 가능합니다.)

게다가 한국은 전문을 트랜잭션 단위로 처리하기보다는 배치성으로 처리하는 경우가 많기 때문에 SOA 기반 미들웨어들이 대규모 데이터를 처리해주어야 하지만, 이를 SOA 미들웨어에 보낼 경우 한번에 처리할 수 있는 데이터의 양이 보잘 것 없어서 처리하기 힘들 때가 많은 것 같습니다. 게다가 한번에 보내는 전체 전문의 양이 2MB를 넘는 경우 서버에서 처리를 못하고 문제가 생기는 경우도 많이 봐왔고, 이런 문제가 발생할 경우 “울며 겨자 먹기” 식으로 한번에 보내는 데이터의 양을 조절해야 하는 황당한 경우가 발생하는 경우도 있는 것 같습니다.

SOA 개념은 정말 좋지만 그걸 하기 위해서 얼마나 많은 인터페이스와 시스템을 바꾸어야 하는지 한번쯤 고민을 하시고, 그렇게 해도 문제가 없다는 생각이 드신다면 그 때 SOA 선택을 해서 도입을 하셔도 늦지 않을 것이라고 생각합니다.