ZDNET 3. 정보기술 아키텍처의 3가지 구결 -IT 삼정립의 법칙

[도미니크]

한 선배가 “어떤 사람이 특정분야에 대한 지식과 경험이 얼마나 심오한지 확인할 수 있는 방법은 내용을 얼마나 짧은 시간에 이해하기 쉽게 설명할 수 있는가에 있다”고 말한 것을 기억합니다.   간혹 전문가로 자처하는 사람들이 “나는 이 전문 분야를 몇 일씩이라도 강의 할 수 있다”고 자랑하는 것을 보았는데, 그들이 오랜 강의를 마친 후에 “지금까지 하신 이야기를 초보자라도 이해할 수 있도록 5분 메시지로 요약해 달라고 하면, 난감해 하는 것을 보았습니다.   많은 지식은 있으되 5분만에 핵심을 일반인도 이해할 수 있도록 설명하지 못하니, 정말 깨우치고 말씀하는 것인지 의문이 되기도 했습니다. 

때문에 누가 제게 수년 동안 학습한 컴퓨터 아키텍처의 키 메시지를 후학들에게 5분 안에 전달하라고 한다면, 저는 다음의 세가지를 전해야겠다는 생각을 오래 전부터 가지고 있었습니다. 저는 아래의 법칙을 업계 후배들이 제대로 익히고 응용한다면, IT 시스템을 도입하거나, 구축할 때 남다른 분별력과 식견을 가질 수 있다고 굳게 믿고 있습니다.

첫째는 삼정립의 법칙입니다.  최인호의 소설 ‘상도’에서는 솥”정”의 3다리를 재물, 권력, 명예의 개념으로 채용하였지만, 컴퓨터아키텍처에서 세다리는 하드웨어, 운영체제, DB를 포함한 어플리케이션으로 구성되어 있다 할 수 있겠습니다.  컴퓨터의 성능은 항시 이들 3가지 요소가 공히 같이 발전하여야 최적화될 수 있는데, 특정 벤더들은 이중 하나의 기능만을 높여놓고 이에 맞는 벤치마크를 만들어 놓고 총체적 성능이 좋아졌다고 사용자를 현혹시키는 일을 많이 보아왔습니다.  혹자는 이러한 접근을 벤치마케팅(Bench-Marketing)이라고 부릅니다.

일례로 64비트 CPU가 시장에 처음 나왔을 때가 이러했습니다.  최초에는 64비트 컴퓨터가무엇인지 정의도 분명치 않았었고, 나중에 메모리 어드레싱, 레지스터의 사이즈, 시스템 버스 등이 32비트에서 64비트로 확장된 것을 일반적으로 64비트 아키텍처라 정의하였습니다.   어떤 업체는 이중에 일부만을 64비트로 디자인 한 것을 전부인 양 소비자를 현혹하기도 한 적이 있었습니다.  나중에는 모두 64비트화된 컴퓨터가 나왔지만, 사용자의 어플리케이션 성능은 예전의 32비트와 마찬가지였습니다.  결국 64비트 컴퓨터는 운영체제, DB와 어플리케이션, 컴파일러 등이 64비트를 모두 지원할 때까지 성능을 혁신적으로 개선하지 못하였습니다.

식물학에 “최소양분률”의 법칙이 있습니다.   식물의 성장은 가장 적은 필수 영양소에 종속된다는 이론을 말합니다.   컴퓨터의 성능도 이와 같아서, 여러 컴퓨터 자원이 고도화 되었다고 하더라도, 어느 한 부분이 예전과 같다면 전체성능의 개선은 허구일 수 있습니다. 

둘째는 복잡성 불변의 법칙입니다.  물리학에서 에너지 불변의 법칙이 있듯이 IT의 경우도 “사용자가 편해지면, 기계가 고생한다”는 사실입니다.   UI도 좋아지고, 어플리케이션의 성능이 현격히 개선되었는데, 동일한 기계 사양으로도 가능하다는 벤더의 주장은 역시 거짓일 수 있습니다.  컴파일러가 최적화되어, 동일 사양의 기계가 갑자기 몇십%정도의 성능향상을 보여줄 수는 있으되, 어플리케이션의 기능이 개선된 버전up 된 소프트웨어를 예전의 하드웨어에서도 동일한 성능으로 사용할 수 있다고 말하는 영업사원의 말은 의심하여야 합니다.   사용자가 예전에 비해 월등한 기능과 효익을 도모한다면, 당연히 더 많은 컴퓨팅 자원을 투자해야 합니다.  

필자는 확장성도 선형, 수평, 수직, 가격대비, 단위, 범위, 한계확장성의 7가지가 구분하고 있는데, 기존의 하드웨어가 주변장치나 CPU에 있어서 Unbalanced 된 제품의 경우에는 주변장치의 추가(수평확장)나 CPU의 개수(수직확장)를 통하여 성능을 최적화 시킬 수 있고, 큰 부담 없이 업그레이된 어플리케이션을 운영할 수는 있을 것입니다.  비용지불(희생)없는 효익은 IT의 세계에서도 있을 수 없습니다.

셋째는 복잡성 증대의 법칙입니다.  컴퓨팅 자원이 많아지면 관리복잡도도 당연히 올라가는 것이 상식이지만, 이는 선형적 증가가 아니라 n(n-1)/2의 공식으로 복잡해 집니다.  IT업계에 종사하는 전문인들은 이 공식을 반드시 외울 것을 권고 드립니다.  자원이 2개일 경우의 연결점은 1이지만, 5개이면 10, 10개면 45개의 연결점이 필요합니다.  관리점이 얼마 안될 때는 사람의 힘으로 처리가 가능하지만, 관리포인트가 수백, 수천이 되게 되면 아키텍처가 바뀌지 않으면 관리할 수가 없게 됩니다.   그러므로, 한 기업의 어플리케이션의 복잡도가 증가하고 있음에도, 초기의 시스템 아키텍처로 모두 해결할 수 있다는 벤더의 주장은 순진한 일입니다.

이러한 복잡성 증대의 원칙은 IT에 국한되지 않으며, 일반적 사회현상을 설명할 수도 있습니다.  소기업이 번창하다가 이러한 복잡도를 잘 관리하지 못하여 쓰러져버리기도 합니다.  제가 알고 있는 많은 소프트웨어 패키지 기업도 초창기에 급격한 매출 증대로 즐거운 비명을 외치다가, 고객수가 많아 짐에 따라 발생하는 커뮤니케이션 비용, 인건비, 인프라 비용, 품질관리 비용 등.  즉, 복잡도비용을 관리하지 못하고 쓰러진 기업의 예를 다수 알고 있습니다.  이들 기업이 듣는 고객의 소리는 처음에는 “융통성 있게 고객의 요구를 잘 반영한다”라는 말에서 나중에는 “회사가 커지더니, 이제는 불러도 안 오는 구만!”으로 바뀌게 됩니다.  경영자에게 이는 조만간 커다란 Challenge로 작용하게 됩니다. 이를 극복하는 방법은 탁월한 관리역량, 효율적인 프로세스, 그리고 신기술로서 가능합니다.

ZDNET 칼럼 전체글 보기