통합에 대한 불편한 진실

SW에서 통합이라는 이슈가 불거진건 어제 오늘 일이 아니다. 그동안의 다양한 프로젝트들은 SI(System Integration)라는 이름 하에 진행되었으며, 그 내용 역시 서로 다른 다양한 시스템을 대상으로 통합을 위한 활동을 하는 것들이 포함된다. 하지만, 통합이라는 단어가 가지는 어감에 대해서는 시스템을 대하는 태도에 따라서 전혀 다른 아키텍처나 구조를 가지는 결과를 낳는다. 우선 통합과 반대가 되는 단어로는 분산을 들 수 있다. 통합과 유사하거나 같이 사용되는 단어로는 일관성 내지 표준화 정도로 볼 수 있다. 하지만, 이러한 단어들은 모두 통합을 위한 기본적인 토대가 되는 개념으로 서로 어느 정도는 상존될 수 밖에 없다. 아니, 반대와 유사한 개념들이 모두 공존하도록 아키텍처나 설계 구조를 만드는 노력이 오히려 필요하다.

통합은 겉에서 보기에는 서로 다른 종류의 시스템들이 유기적인 형태로 연결되어야 한다는 것을 의미하지만, 속내를 들여다 보면 데이터의 전송 방식과 표현 방식 등 상당히 많은 문제를 안고 있는 것이 사실이다. 또한, 동일한 의미의 단어라 하더라도 시스템 간에 서로 다른 의미로 사용되고, 그 안에 들어있는 데이터 역시 그 값이 동일하다고 하더라도 서로 다른 의미로 사용된다. 기존 시스템을 새로운 시스템으로 구성하려는 노력은 수많은 데이터들과의 싸움이기도 하다.

때로는 서로 다른 프로세스를 조정하는 역할을 필요로 하기도 하다. 프로세스에 대한 조정은 결국 필요한 컴포넌트를 어떻게 적절하게 조합할 것인가로 귀결되며, 결국 프로세스를 조정하게끔 어느 정도로 서비스의 크기(granularity)로 만들 것인가를 결정해야 한다.

통합은 특정 결합을 위한 도구만으로 해결되기는 어렵다. EAI(Enterprise Application Integration) 솔루션들이 아무리 막강한 기능을 제공한다고 하더라도 통합을 위한 인터페이스의 명세를 확정하지 않는 한 결국 시스템의 의존관계만 높아질 뿐이다.

통합은 순서가 중요하다.

모든 프로젝트가 그렇듯이 소프트웨어 개발에 있어서 선후 개발 순서는 상당히 중요한 이슈이다. 동시 다발적으로 개발이 진행되는 프로젝트라고 하더라도 사용하는 인터페이스들간의 관계는 분석/설계 단계에서 식별되어야 하며, 실제 구현 단계에서는 이러한 인터페이스는 더 많이 나타나게 된다. 이를 위해서는 비즈니스 분석의 Value Chain 과 프로세스 모델링이 식별되어야 하며, 이를 토대로 통합 및 구현을 위한 일정을 상세화시켜야 한다. 이를 각 개발 파트에게 맡겨놓는다면 전체적인 식별이 안된 상태에서 하위 모듈만을 식별해서 끼워맞추는 방식으로 진행되기 때문에 통합에 있어서 상당한 어려움이 발생될 수 밖에 없다.

Divide & Conquer라는 원칙으로 모듈을 식별하는 방식은 마치 기능적 세분화(functional decomposition)의 방식과도 유사하지만, 이러한 원칙을 어느 상세 레벨까지 분화를 할 것인가에 대한 것과 이를 어떠한 용도를 사용할 것인가를 고려해야 한다. 이 원칙은 커다란 하나의 덩어리를 서로 관련이 있는 것으로 뭉치는 방식으로 양측의 교집합을 최소화시켜야 한다. 예를 들어, 요즘과 같이 다양한 채널에 응대하는 서비스를 만들어야 하는 시스템의 경우 양쪽 채널에 동일한 서비스를 제공함에도 불구하고 서로 다른 채널이라는 기준으로 기능 세분화를 하다보니, 이러한 교집합을 무시한채 서로 다른 채널 덩어리를 식별하여 시스템을 개발하여 동일한 비즈니스 개념의 변경에 효과적으로 대처하기 어렵게 만드는 결과를 초래하기도 한다.

궁극적으로 이러한 모듈이나 서브시스템, 컴포넌트는 전체적인 관점에서 식별되어야 하며, 이에 대한 개발/통합 순서까지도 식별되어야 한다. 통합이 어려운 점은 개발할 시스템 대상이 불명확하거나, 이를 각 개발파트에 맡김으로써 전체적인 시스템 구성 원칙이 제각각이어서 결국 통합 지점에서는 상당히 어려운 형태로 만들어지기 때문이다.

명세는 시스템 인터페이스 이상의 내용이 포함되어 있어야 한다.

일반적으로 명세는 크게 문법적인(syntactic) 개념과 문맥적인(semantic) 개념으로 나뉜다. 전자를 외관에 비유하면 후자는 내관에 비유할 수 있다. 즉, 외형적인 측면과 내면적인 측면으로 나뉘어 볼 수 있는데, 통합에 있어서 표준적인 명세를 마련하는 게 상당히 중요하지만, 외형적인 측면만으로 고려하고 이를 명세의 완성으로 생각하여 구현하다가 그 내포적인 의미로 인해서 상당한 지연이나 추가 개발 노력이 들어가는 경우가 허다하다. 외형적인 부분은 기술적인 영역에 포함되어 있지만, 내면적인 부분은 크게 업무 프로세스와 그 프로세스에서 처리하는 데이터로 나뉠 수 있다. 이러한 내용들은 문서화가 되기 어려우며, 문서화가 되어 있다고 하더라도 여기저기 산재해 있어서 이를 모두 고려해서 통합을 만들어낸다는게 사실상 불가능한 것처럼 보인다. 데이터만 하더라도 요청을 보내는 측과 그 요청을 처리하는 측에서 다르게 해석할 수도 있으며, 각각의 영역에서 번역이나 해석을 달리 할 수 있다.

이러한 내용들은 어디에도 문서화되어 있지 않는 경우도 있으며, 오로지 이를 운영하는 사람의 머리 속에 남아 있거나 그 사람마저 조직에서 떠나면 어느 누구도 알지 못하는 경우가 많다. 이러한 상태에서 문서화/명세화된 수는 크게 의미가 없을 수 있으며, 결국 인터페이스만 바라보고 개발하기 어렵게 되며, 양측의 코드를 상세하게 분석하는 추가적인 시간이나 노력을 들이는 경우가 대부분이다. 또한, 이러한 데이터들 자체가 코드화가 되어 있어서 사실상 분석한다고 하더라도 시간이 걸릴 수 밖에 없는 영역이 되어버린다. 차라리 명확하게 풀어서 사용하는게 더 나을 수도 있다. 지금의 시스템은 이전 시스템과 달리 용량의 엄청난 증가를 수용할 수 있는 단계이기 때문에 ABC와 같은 코드보다 NOT_FOUND라는 형태의 보고 이해기 쉬운 형태로 사용하여 부수적인 문서를 보지 않더라도 이해할 수 있게 만드는게 더 나을 수 있다.

시스템 통합은 궁극적으로 사람의 통합을 의미한다.

시스템을 통합하는 것은 결국 이를 사용하는 사람들이 각기 다른 시스템을 편하게 사용하기 위함도 있으며, 중복이나 모자란 부분을 가감하여 더 나은 서비스를 제공하여 보다 가치있고 더 나은 업무를 하기 위함이다. 통합은 궁극적으로 비즈니스의 변화를 가져올 수 밖에 없으며, 이는 수년 동안 익혔던 시스템에 대한 기능을 사용했던 업무를 다른 형태로 변화시켜서 새로운 업무 형태로 만들어야 됨을 의미한다.

이는 두개의 시스템은 단순히 연결되는 것만이 전부다가 아니라는 것이다. 두개의 시스템이 연결됨으로써 최종사용자의 업무는 더 복잡해지거나 더 많은 정보를 다루게 될 수도 있는 결과를 초래할 수도 있음을 의미한다. 제대로 만들어진 통합은 오히려 이러한 불편함을 줄이도록 혹은 개선하도록 만들어지게끔 하는 것이 목표겠지만, 기존 기능을 과감하게 없애지 못하는 문화나 기존 멤버들의 이기주의는 오히려 더 복잡한 기능만을 제공하는 통합을 낳게 된다.

통합된 시스템을 만들기 이전에 이러한 내용에 대해서 먼저 사람과의 통합을 시도해야 할 것이며, 이는 SW를 만드는 영역이 아니라고 볼 수도 있다. 하지만, SW 개발이 무조건적으로 요구사항을 수용하여 시스템의 모습을 원칙에서 벗어나게끔 만드는 것은 가급적 회피해야 한다. 또한, 요구사항을 만들어내는 사람들이 전체 사용자를 대변할 수 있다고도 볼 수 없다. 그들이 이해하는 것은 그들만의 언어이기 때문에 그 저변에 있는 컨텍스트를 이해할 필요가 있으며, 그러한 시도를 할 때 결국 사용자들에게 적합한 시스템 통합을 만들 수 있기 때문이다.


N-스크린, 클라우드, 빅데이터, 융합 등의 키워드로 상당한 IT 기술의 새로운 국면인 것처럼 말들을 하지만, 정작 이를 만드는 실행자들의 입장에서는 별반 차이를 느끼기는 어렵다. 오히려 그동안의 SW 원칙이라고 불리웠던 내용들이 더 강조되고 더 충실히 지켜야 하는 것이 되어가는 상태인 것 같다.