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

요즘 인터넷이나 다른 소프트웨어 벤더들이 이야기를 하는 것을 보면 데이터 전송은 마치 XML이 대세인 것처럼 이야기하는데, 제가 생각하기엔 세상이 모든 것들이 다 마찬가지겠지만, 항상 Trade-Off가 존재하기 때문에 어떤 방식이든 장점과 단점이 다 존재한다고 생각합니다.

일반적으로 XML의 장점은 다 아시다시피 전문내의 각 항목들의 포맷 및 데이터 길이를 상당히 자유롭게 구성할 수 있습니다. 또한, DTD를 재구성하거나 Well-Defined 형태만을 취해서도 데이터 교환을 위해서 쉽게 프로토콜을 바꿀 수 있는 장점도 있습니다.  

하지만, 그러한 장점만큼이나 상당한 단점도 존재하는데, 일단 각 항목별로 이를 나타내는 태그가 들어가기 때문에 전문의 길이가 훨씬 늘어나게 됩니다. 태그의 양이 얼마 안 된다고 생각하실 수도 있지만, 상황에 따라서는 보내고자 하는 전문의 양이 2-3배 정도가 늘어날 수 있습니다. 예를 들어 3K전문을 100만 건 처리한다고 했을 때, EDI의 경우 3G가 되지만, 태그를 가지고 있는 XML로 처리할 때는 전체 데이터의 양이 3G에서 6G내지는 9G로 늘어난다는 것입니다.

또한, EDI방식은 전문을 처리할 때, 일반적으로 각 자리의 위치와 크기가 정해져 있는 Structure방식으로 처리되기 때문에 Parsing이 상대적으로 쉬우면서 주로 메모리의 Heap만을 사용해서 처리할 수 있는 반면, XML은 전문을 구조적으로 해석해야 되는 단계가 있으므로 상대적으로 많은 CPU와 메모리에서 Heap과 Stack를 모두 사용해야 합니다. 즉, 다시 말해서 편리함만큼이나 상당한 대가를 치러야 한다는 말입니다.

따라서, 이러한 대규모 데이터를 처리하기 위해서는 기존의 EDI 전문처리 방식을 고려해야 볼 필요가 있습니다. EDI방식은 XML 방식과 비교해서 태그 등을 사용하지 않은 관계로 일단 대규모 데이터 처리 시 상당한 효율성을 보장합니다.

또한, 대규모 데이터를 처리하는 경우 데이터 통신 양을 줄이기 위해서 압축을 사용하는 경우가 많은데, 이는 시스템 튜닝적인 성격이 강합니다. 일반적으로 튜닝을 하는 경우 전산자원 중 가장 느린 자원의 속도를 높임으로서 전체의 효율을 증대하려는 목적이 있는데, 전산자원의 일반적인 요소들 – 네트워크, 보조기억장치, 주기억장치, 연산장치 – 을 고려할 때 네트워크 -> 보조기억장치(일반적으로 하드디스크) -> 메모리 -> CPU 등의 순서로 튜닝을 진행하는 것이 가장 바람직하기 때문입니다.

따라서, XML나 EDI의 경우에도 그냥 전문을 보내기보다는 압축 알고리즘을 이용해서 데이터를 압축해서 사용하는 경우가 많습니다. 이런 경우 패키지가 있으면 훨씬 편리하게 작업을 할 수 있겠지만, 굳이 패키지가 없더라도 처리할 수 있는 방법이 있으므로 굳이 필요하지 않다면 패키지를 구매하지 않더라고 간단한 방법을 통해 패키지 구입비용을 아낄 수 있습니다.

다만, 이런 경우 데이터를 압축하기 위해서는 별도의 작업이 필요로 한데, 일단 EDI 전문을 GZIP 등을 이용해서 압축하고 압축된 전문과 해당 전문들의 리스트를 첨부해서 받는 쪽 시스템에 FTP등과 같은 프로토콜을 이용해서 파일을 보냅니다. 그런 다음, 리스트 파일을 추출해서 데이터베이스의 Table에 저장하고, 이 테이블에 별도의 처리필드를 두어서 전문의 처리여부 및 에러코드를 남기게 하면, 나중에 문제가 발생한 경우 에러가 난 부분만을 살펴보고, 해당 부분만을 수작업으로 처리해 줄 수 있습니다.

패키지를 사용하는 경우에도 이런 방식을 취해서 데이터를 압축할 수 있는데, 현재 출시되고 있는 EAI 패키지들을 보면 다양한 전문처리(XML, FILE 등)이외에도 별도의 OS의 외부 명령어를 사용해서 전처리와 후처리를 할 수 있는 것으로 알고 있습니다. 따라서, EDI 전문 전송을 위해 패키지를 사용하는 경우라도 자체적인 압축방식을 사용할 수도 있겠지만, OS 유틸리티를 이용해서 압축 및 리스트를 추출하고 이를 해당 서버에 보낸 뒤, 다시 압축을 풀고, 처리하는 방식으로 하면 번거롭기는 하지만, 상당한 효율로 데이터를 처리할 수 있습니다. 다만, 이러한 방식을 취할 경우 OS 버전이 올라가거나 해당 유틸리티의 버전이 올라갈 경우 파라미터값이 변화되거나 해당 프로그램의 이름의 변경으로 유지보수 하는데 어려움이 있을 수는 있습니다.

하지만, 데이터를 압축해서 네트워크로 전송하는 경우에도 고려할 점이 있는데, 데이터를 압축해서 보내는 경우 데이터를 빠른 시간 내에 전송할 수 있는 장점이 있는 반면 압축을 실행하기 위해서 압축알고리즘에 의해서 데이터를 압축을 해야 함으로 앞서 언급한 바와 같이 이를 지원하는 전용 프로세서가 없는 경우 대부분의 작업이 CPU에서 일어나게 됩니다.

따라서, 압축작업에 CPU의 사용량이 증가하게 됨으로 다중 CPU를 가지고 있지 않은 경우 네트워크 전송속도를 늘이기 위해 CPU 자원을 소모해야 함으로 전체적인 데이터 처리속도가 떨어질 수도 있는 문제가 발생할 수 있기 때문에 데이터 압축을 사용해서 데이터를 전송하고자 할 때는 반드시 이러한 부분을 고려해서 어느 방식이 더 빠를 지를 결정해야 합니다.

EDI와 XML로 데이터를 전송하는 것은 그 나름대로의 장단점이 존재하기 때문에 데이터 교환을 하는데 있어서 여러 가지 상황을 고려해서 정해야 됩니다. 개인적인 경험으로 생각해 볼 때, 피크타임이 존재하지 않는 온라인 트랜잭션의 경우는 XML이 유지보수나 활용도 측면 등에서 장점이 있으므로 좋은 솔루션이라고 생각되고, 피크타임이 존재하는 대규모 온라인 트랜잭션의 경우는 EDI방식을 고려해 볼 수 있다고 생각합니다. 또한, 배치작업 등을 위한 대규모 데이터 전송 및 전문처리는 EDI 방식이 XML에 비해 좋은 선택이라고 할 수 있습니다.

추신: XML도 EDI의 한 방식으로 볼 경우 경계가 애매한 부분이 있지만, 편의를 위해서 이 글에서는 XML과 기존의 EDI 처리방식을 구별해서 사용했습니다… ^^