[지디넷코리아]현행 데이터 아키텍처는 현 시스템의 데이터 구조를 매우 구체적이고 체계적으로 보유하고 있으므로 이를 이용하여 시스템의 유지보수에 다양하게 활용할 수 있다는 것은 너무나 당연하다.

시스템이란 결국 ‘애플리케이션이 데이터를 조작하는 것’이라 할 수 있다. 이는 마치 '근육이 뼈대를 움직이는 것’과 유사하다고도 할 수 있다. 다른 말로 바꾸어 보면 본질이 되는 데이터의 형태가 변경이 되면 애플리케이션은 필연적으로 변경될 수 밖에 없지만 설사 애플리케이션이 변경되더라도 데이터 형태에는 변화가 발생하지 않는 경우가 많이 있을 수 있다는 것을 의미한다.

또 단위 애플리케이션의 변화는 상대적으로 주변에 미치는 영향이 덜 하지만 데이터 구조가 변경이 되면 영향을 받을 수 있는 것들이 매우 많을 수 밖에 없다는 의미도 내포하고 있다.

이런 이유 때문에 대부분의 사람들은 현실에서 발생할 수 밖에 없는 업무의 변경을 소화하기 위해서 데이터 구조를 최적화하는 것은 최대한 피하고, 어떻게 해서라도 애플리케이션을 변경하여 해결하려고 하는 경향이 강하게 나타나고 있다.

만약 현행 시스템의 데이터 구조가 효율적이지 못하고 더구나 그것이 투명하게 관리되고 있지 않다면 필연적으로 이러한 데이터를 기반으로 작성된 애플리케이션은 매우 복잡한 형태로 나타날 수 밖에 없다.

이러한 애플리케이션은 많은 문제를 안고 있기 때문에 개발이 완료된 후에도 오랜 시일을 거쳐 수없이 보완되고서야 겨우 안정화 단계에 도달할 수 있었을 것이다. 이처럼 천신만고 끝에 이룩한 안정화를 누가 감히 깨어버릴 엄두라도 낼 수 있겠는가.

물론 업무변경으로 인한 유지보수가 일부 애플리케이션을 보완하는 것만으로도 충분하다면 문제될 것이 없겠지만 데이터 구조의 변화가 필요한 정도라면 여러분은 중차대한 갈림길에 서 있다고 할 수 있다. 다시 말해서 시스템이 점차적으로 개선되는 쪽으로 가느냐, 아니면 갈수록 썩어 들어가느냐에 대한 기로에 서 있다는 것이다.

비록 지금의 데이터 구조에 심각한 문제가 있다손 치더라도 ‘떡본 김에 제사 지낸다’는 속담처럼 이왕 수정해야 할 상황이 되었으니 이제라도 잘못된 것을 확실하게 바로 잡겠다는 생각을 했다면 분명히 시스템은 날이 갈수록 개선되어 갈 것이다.

그러나 시스템의 데이터 구조를 건드렸을 때 이제서야 겨우 안정화되기 시작한 기존의 애플리케이션이 다시 잘못될 수도 있다는 공포감은 근본적인 문제를 개선하는 쪽으로 갈 수 없도록 한다. 사실 이러한 일이 발생하는 이유는 단지 수정할 내용이 너무 많아지기 때문이라기 보다는 데이터 구조가 투명하게 관리되고 있지 못하고 있기 때문에 함부로 건드렸다가는 어떤 일이 발생할지도 모른다는 불안 때문이라고 하는 것이 보다 정확한 표현일 것이다.

이런 이유로 인해 기존의 시스템에 오너쉽을 가지고 있는 쪽에서는 ‘데이터 구조 변경은 절대 불가하다’고 배수의 진을 치게 된다.

이처럼 기득권(?) 세력들의 워낙 완강한 저항에 가로막혀 개선을 하겠다는 개혁파들은 어쩔 수 없이 작전상 후퇴를 하지 않을 수 없다. 여기서 작전상 후퇴란 바로 기존의 테이블을 그대로 두고 이와 유사한 새로운 테이블을 생성하는 것을 말한다.

새로운 데이터가 생겨 난다는 것은 대개의 경우 새로운 애플리케이션이 필요해진다는 것을 의미한다. 이러한 현상으로 인해 데이터 모델이 추가되는 속도보다 훨씬 빠른 속도로 애플리케이션이 증가하는 심각한 문제를 불러오게 된다. 물론 이와 같은 방법으로 문제를 해결하는 것이 당장은 현재의 문제를 손쉽게 해결할 수 있을지 모르겠지만 이는 곧 시스템이 계속해서 썩어 들어가고 있다는 의미임을 명심해야 할 것이다.

데이터 모델이 계속 늘어나고 거기에 따라서 애플리케이션이 증가하게 되면 당연히 데이터의 일관성은 나빠진다. 이런 문제를 해결하기 위해 오차(gap)을 메우기 위한 애플리케이션이 다시 등장하게 된다. 이러한 악순환은 시스템에 지속적으로 악성종양을 증가시키며, 결코 저절로 어느 날부터는 감소 추세로 돌아 설 확률은 전혀 없다.

복잡도가 덜할 때에도 근본적인 문제를 해결하지 못했는데 이미 곳곳이 곪아 있는 상태에서라면 더더욱 근본적인 해결은 꿈도 꿀 수 없다. 이제 시스템은 중병이 들어 많은 유지보수 인력의 각고의 보살핌에 의해 근근이 버티다가 생명주기를 제대로 채우지도 못하고 재개발의 전철을 밟게 될 것이다. 엄연한 현실의 모습이다.

결국 모든 문제의 갈림길은 데이터 구조를 투명하게 관리하고 있느냐에 대한 문제와 데이터 구조의 문제를 애플리케이션으로 막지 않도록 하기 위해 더 늦기 전에 올바른 노력을 기울여 왔느냐에 있다고 할 수 있겠다.

이 말은 데이터 구조가 투명하고 구체적으로 관리되고 있어야 한다는 것과, 프로그래머가 함부로 애플리케이션만 수정하고자 하는 미봉책을 쓰지 않도록 적극적인 통제 조직의 역할이 필요하다는 것을 분명히 하고 있다.

이것은 곧 시스템을 썩지 않고 오래도록 유지하기 위해서는 반드시 데이터 아키텍처가 수립되어 있어야 한다는 당위성과 데이터를 관리하는 전문 조직이 반드시 필요하다는 것을 뜻하고 있다.

이 두 가지의 요건은 필연적인 관계를 가지고 있다. 비록 아무리 완벽한 데이터 아키텍처가 수립되어 있다 하더라도 이를 이용해 제대로 된 통제를 할 수 있는 조직이 없다면 유명무실해 질 수 밖에 없으며, 아무리 우수한 조직이 준비되어 있더라도 그들에게 정확한 현황정보를 제공할 수 없다면 아무 것도 할 수 없다는 것은 지극히 자명하다.

데이터 아키텍처가 시스템 유지보수 수단이라는 것을 확실히 하기 위해서 필자가 경험한 어느 프로젝트의 예를 들어 보겠다. 이 프로젝트는 수백억의 비용이 소요된 대형 프로젝트였지만, 시작 초기부터 여러가지 잡음이 끊이질 않았다.

2년이 넘게 프로젝트가 진행되면서 ‘갑’과 ‘을’이 모두 다른 회사로 합병되는 우여곡절도 겪었다. 그 와중에서 천신만고 끝에 개발한 시스템을 몇 번에 걸쳐 오픈을 시도해 보았지만 번번히 실패로 끝나고 말았다. 급기야 대부분의 개발자들이 극도로 지치고 의욕도 잃은 상태에서 컨설팅 업체의 도움을 받아 겨우 성공적인 오픈을 할 수 있었다.

당시 이 프로젝트는 일단 정상적인 오픈을 하는 것이 최대 과제였기 때문에 눈앞에 보이는 문제를 해결하기 위해 급격하게 이루어진 많은 변경사항들을 제대로 관리할 수가 없었다.

결국 천신만고 끝에 오픈은 했지만 이제부터 그들에게 남겨진 과제는 정상적인 유지수 활동을 수행해야 한다는 것이었다. 불행히도 개발에 참여한 모든 사람이 그대로 유지보수를 담당할 수는 없었다. 개발자들은 SI업체 요원이었기 때문에 유지보수는 응당 시스템을 인수받은 ‘갑’의 몫이 될 수 밖에 없었다.

지금까지 ‘갑’들은 단지 프로젝트 결과만 체크했을뿐 내용에 대해서는 깊게 관여하지 않았기 때문에 ‘을’이 제공한 산출물의 품질을 정확하게 검증할 수 없음은 당연한 일이었다.

애플리케이션이야 물론 어느 정도의 수준에 도달한 프로그래머라면 얼마 동안 운영해 보면 파악이 가능할 것이다. 그러나 데이터 모델은 구체적인 자료가 없다면 웬만해서는 깊이 있는 파악이 불가능하므로 시스템의 본질인 데이터 구조를 정확히 인식하지 못한 채 유지보수가 실시될 수 밖에 없다.

데이터 모델은 다수의 애플리케이션에서 사용되기 때문에 데이터 구조를 정확히 알지 못한 채 실시되는 유지보수는 필연적으로 크고 작은 많은 시스템 사고를 겪을 수 밖에 없다.

결국 이런 문제를 해결하기 위해 '갑'은 데이터 아키텍처를 수립하게 됐고, 애플리케이션 아키텍처와 연결해 어떤 데이터가 어떠한 애플리케이션에 어떤 목적으로 사용되었는지 까지도 관리할 수 있게 됨으로써 과거에 비해 소수의 인력으로 보다 양질의 유지보수를 할 수 있게 됐다. @