프로젝트 개발/운영팀 구성과 시스템 구성

Conway의 법칙은 특정 시스템을 만드는 조직이 궁극적으로 해당 시스템의 내부 모듈(서브시스템)을 결정한다는 것입니다. 특히, 대형 시스템의 경우 특정 한 회사가 모든 시스템을 만드는 것보다는 여러 회사가 모여서 시스템을 만들기도 하며, 혹은 한 회사 내에서도 서로 다른 팀을 구성하여 시스템을 구축하게 됩니다. 이러한 시스템의 개발에 관련된 조직 구성의 형태는 그대로 시스템의 형태에 영향을 미쳐서 나누어진 개발조직/팀 별로 그 모듈이나 시스템이 구성되는 결과를 초래합니다.

이는 비단 대형 시스템의 경우 뿐만 아니라, 자그마한 소규모 프로젝트 역시 개인별로 그 영역을 나누었을 때에도 마찬가지입니다. 특히나, 기존의 다른 사람이 만든 클래스나 컴포넌트를 최대한 재사용하려는 노력보다 그와 유사한 클래스나 컴포넌트를 만드려는 경향이 더 강하다는 것입니다. 이유는 다양하겠지만, 이러한 현상이 나타나는 가장 강력한 이유는 기존의 기능을 최대한 훼손시키거나 변형시켜서 문제를 유발시키지 않기 위함입니다. 이와 같이 개발팀의 구성이 시스템의 구조에 영향을 미치기 때문에 인터페이스에 대한 영역 역시 개발팀간의 의사소통 경로 만큼이나 만들어질 가능성도 있습니다. (물론, 시스템의 구조에 따라서 전혀 인터페이싱을 하지 않는 팀이 생기기도 합니다.)

Come Together by h.koppdelaney

문제는 이러한 조직 구성의 결과로 만들어진 시스템의 구성의 결과는 몇가지 문제를 유발시킬 수 있다는 것입니다. 우선 시스템을 개발할 당시의 팀과 이를 넘겨받아서 운여하는 팀의 조직 구성이 달라짐에 따라서 시스템의 구조도 바뀌어질 가능성이 높아집니다. 즉, 최초에 시스템을 설계하고자 했던 의도와는 다른 형태로 새로운 모듈이나 서브시스템이 생기거나 기존 모듈이나 서브시스템에 전혀 다른 용도의 기능이 추가되기도 합니다. 이러한 현상은 조직 구성을 유연한 형태로 바꾸지 않는 한, 혹은 개발팀과 운영팀을 동일하게 구성하지 않는 한 사라지기 어려운 부분입니다. 특히, 개발 당시와는 달리 실제 고객에게 서비스를 제공하여 운영하는 시스템에 기존의 것을 재사용하거나 수정하려는 노력보다도 별도의 유사 기능이나 확장 기능을 만들어서 유지하는 것이 더 쉬워보인다는 유혹을 뿌리치지 못합니다. 또한, 장애에 대한 두려움(과 압박)으로 인해 기존 코드의 수정은 어느 누구도 시도해볼 만한 일이라고 생각할 수도 없습니다. 이러한 과정을 거쳐서 점차 시스템은 운영조직이 다루기 편한 구조(최초의 설계 의도와는 전혀 다른 형태로)로 진화를 하게 됩니다. 이렇게 진화한 시스템은 기존의 오류와 문제들을 그대로 가지고 가면서 새로운 문제들이 덧대여져서 더 큰 문제 덩어리로 변모하기 쉽습니다.

두번째로 개발시점의 개발팀의 구성이 시스템 내부에 영향을 미쳐서 유사/중복 기능의 산재화의 결과를 미칠 수 있습니다. 예를 들어, 특정 기능을 제공하는 시스템과의 인터페이스를 요청하는 다른 모듈이나 서브시스템들이 많아질수록 유사하지만 조금씩 서로 다른 인터페이스를 요청하는 경우들이 많이 있습니다. 해당 기능을 요청하는 조직의 파워에 따라서 이러한 인터페이스들은 그 유사성이 각기 다르게 됩니다. 파워가 강력한 조직의 경우 (아마도 대부분 인터페이스를 제공함으로써 해당 요청자로부터 이익을 얻는 조직일 가능성이 높습니다.) 대부분의 개발팀에서는 해당 요청 조직에 요구에 맞게 인터페이스를 제공할 수 밖에 없습니다. 기존의 유사한 인터페이스가 있지만, 뭔가 통신 방식이 다르거나 내용에 있어서 약간의 차이만 있어도 이를 최대한 맞추어서 제공할 수 밖에 없을 겁니다. 이런 경우에는 별도의 팀을 구성하여 인터페이스를 제공하는 형태가 됩니다. 즉, 동일한 비즈니스 로직임에도 불구하고 내부적으로 서로 다른 구현 결과를 갖는 모듈/서브시스템이 존재하게 됩니다. 이러한 구현 결과는 추후 변경이 발생하게 되면 양쪽의 비즈니스 로직을 동기화시키는 노력을 필요로 하며, 그러한 로직을 어느 한군데에도 빠뜨릴 경우, 동기화되지 못한 비즈니스로 인해서 큰 문제들을 유발시킬 수도 있습니다.

세번째로 유연성이 없는 인프라의 고정으로 인해서 발생하는 불필요한 중복 현상들이 유발될 수 있습니다. 특히, EAI와 같은 외부 솔루션들의 도입으로 인해서 기존의 인터페이스를 재사용하지 못해 변경이 발생됨으로써 이를 새로운 모듈/시스템 구성으로 확장하려는 설계를 생각하게 됩니다. 이 역시 기존 인터페이스를 수정하려는 노력보다 새로운 것을 만들어서 제공하려는 노력이 더 비용이 싸기 때문에 발생하는 현상입니다.

이외에도 개발 조직을 구성하는 방식에 따라서 시스템의 구성이 결정되는 예들은 많이 있습니다. 다만, 이러한 구성으로 인해서 비즈니스의 중복과 동기화 문제들이 발생이 되며, 수정할 수 없는 더 많은 오류와 문제들을 유발시킨다는게 큰 숙제인 것 같습니다.

이와 같은 문제를 방지하려는 노력은 개발시점부터 필요한 것 같습니다. 예를 들어, 전체 개발팀을 가로지르는 별도의 팀(QA나 PMO 조직이 최적이나 이들이 실제 개발에 대한 내용에 대해서 도움이 되는 사람으로 구성되어야 함)을 통해서 조율하거나 조정하도록 하거나, 해당 개발팀 내에서도 핵심 비즈니스 로직과 이를 사용한 변형부분(가변성 영역)을 효과적으로 구성하기 위해 유연한 개발 조직의 구성을 해볼 수도 있습니다. 이에 대한 잣대(기존)들을 만들고 해당 잣대에서 벗어나는 모듈/서비시스템에 대해서는 책임의 분산과 통합을 하여 시스템 구조를 효율적으로 구성하도록 해야 합니다.