기술의 발전은 다양한 형태로 그 모습을 대중들에게 표현되고 전파된다. 그러한 과정에서 어떤 기술은 극도의 발전 형태를 띠는 것들이 있는가 하면, 다른 기술들은 오히려 전파되는 과정에서 그 효력이 못미치는 것들도 있다. 기술이 마케팅의 수단을 이용하는 경우에는 소비자나 이를 접하는 사람으로 하여금 해당 기술의 본질을 파악하는 것을 어렵게 만드는 경우도 있다. IT 기술 역시 마케팅의 수단으로 사용되는 경우들이 많으며, 이러한 대표적인 예가 '클라우드(cloud)'가 아닐까 한다.


TV 광고에까지 나타나는 '클라우드' 기술은 너무나도 광범위한 기술로 인식되기 때문에 이를 실제로 응용하려는 개발자에게는 어떻게 접근할지에 대해서부터 많은 고민을 가져다준다. 이러한 상황을 이전의 '컴포넌트(component)' 기술과 비교해본다면 상황에 대한 파악부터 다시 살펴볼 필요가 있다.



Sky symphony
Sky symphony by kevin dooley 저작자 표시



과거 '컴포넌트(component)' 기술이 2000년대 초반부터 IT 기술을 이끄는 대표적인 기술을 각광받던 시기에 수많은 벤더들이 '컴포넌트'라는 단어를 buzzword 내지 silver bullet으로 사용되었다. 컴포넌트라는 용어가 너무나도 강력하고 강렬한 나머지 시스템 자체에도 컴포넌트라는 용어를 붙여서 '컴포넌트 시스템'이라는 용어까지도 만들어냈다. 즉, 하나의 시스템을 컴포넌트로 바라보고 이러한 시스템들이 컴포넌트와 같이 결합을 하면 새로운 또 다른 시스템을 만들어내는 개념 정도로 볼 수 있을까. 거기에다가 수많은 CBD(component based development) 방법론들이 이를 더욱 부채질해서 거의 만능에 가까운 기술로 표현되기에 이른다.


하지만, 정작 '컴포넌트'라는 본질을 꽤뚫지 못한 기업들은 컴포넌트에 대한 다양한 회의적인 목소리를 내고, 심지어는 '자바는 느리다'라는 웃지 못할 상황까지도 연출하게 된다. 마치 컴포넌트 기술을 둘러싸고 자바와 .NET의 양진영에서 컴포넌트를 어떻게든 자기 진영의 유리한 형태로 해석하여 이를 관련 기술에서 한치의 오차도 없이 지원한다는 형태로 대량 마케팅 전술을 취하게 된다. (.NET과 EJB의 비교에 관련된 문서는 인터넷에 뒤지면 널려있다.)


수많은 개발자들이 이러한 마케팅적인 용어에 실제 컴포넌트에 대한 본질을 파악하지 못한 채 컴포넌트 기술은 점점 쇠퇴의 길을 걷게 된다. (마케팅적으로 쇠퇴를 의미하고, 실제로는 컴포넌트 개념은 설계에서 중요한 개념 중에 하나이고, 이는 SOA의 발전을 이끌게 된다.)


과거의 경험을 비추어볼때, 마케팅에서 말하는 용어는 그 본질을 파악할 때까지 곧이 곧대로 믿으면 안된다는 것이다. (물론, 이러한 방식에는 해당 기술에 대한 다양한 시도를 이끌고, 이를 통해 발전할 수 있는 계기를 만들어주는 것이 사실이지만, one size fits all 이라는 것은 어디에도 존재하지 않는다는 사실을 인식해야 한다.)


'클라우드' 역시 이러한 형태로 다양한 벤더나 통신회사들이 마케팅 정의를 만들어내고 있다. 이러한 형태는 세미나 후원이나 주최를 통해서 겉에 보이게 혹은 드러나지 않게 지원하고 있다. '클라우드(cloud)'는 기존 서비스(service)에 대한 개념을 한차원 높게 끌어올리는 기술을 제공하려는게 사실이며, 궁극적인 기술의 발전은 클라우드를 통해서 한단계 발전할 가능성이 높다.


다만, 이전의 컴포넌트 기술이 그랬듯이, 그 누구의 컴포넌트가 없듯이, 그 누구의 클라우드도 없기 때문에 그에 대한 본질적인 접근 방식을 고민해봐야 한다. 프레임워크나 솔루션, 라이브러리, 혹은 인프라를 통해서 구현되는 기술이 아니라, 본질적으로 클라우드가 가지는 속성이 전체 시스템 내에서 어떤 형태로 설계의 그림이 만들어져야 하는지에 대해서 심각한 고민을 할 필요가 있다. 혹은, 클라우드 형태가 아닌 기존 시스템을 클라우드 형태로 발전시키거나 확장하려고 할 때 서비스의 본질적인 모습과 이를 사용하려는 측과의 형태가 어떻게 진화해야 하는지에 대해서 고민해봐야 한다. 이는 단순히 AWS나 GAE를 사용한다고 해서 해결될 수 있는 문제는 아니다.


기술이 마케팅 용어로 사용될 때에 가장 주의해야할 점은 기술의 본질이 무엇인지를 먼저 파악하는 것이다. 일반 대중에게 노출되는 마케팅으로 포장된 기술은 해당 기업에서 이윤의 목적으로 사용되는 용어이기 때문에 이를 곧이 곧대로 기술의 관점에서 접근하려 해서는 안된다. 설사 아무리 뛰어난 기술을 가진 회사라 하더라도 해당 기술의 본질을 왜곡하려는 시도는 다분히 들어갈 가능성이 많다.


지금의 기술을 이끌고, 앞으로 이끌 차세대 기술로써 '클라우드(cloud)'를 꼽는 것은 당연하다. 하지만, '컴포넌트' 기술과 마찬가지로 한낱 유행에 불과한 단어로 남는 역사를 되풀이하지 않으려면 이를 적용하려는 사람에게는 그 본질적인 면들을 파악해서 기존 기술과의 차이와 발전 방향에 대해서 논의될 필요는 있다.

저작자 표시 비영리 동일 조건 변경 허락
신고

경제학에는 수확 체감의 법칙과 한계효융의 체감 법칙이 있다.


수확 체감(diminishing returns)이란 일정한 면적에 노동력을 추가 투입했을때 수확량(혹은 생산성)의 증가가 노동력의 증가를 따라가지 못하는 현상을 말한다. 즉, 노동력의 투입이 결코 생산성과 연결될 수는 없으며, 과다 투입된 노동력에 대해서는 단위 면적을 넓히던가 아니면 더 생산적인 수단 방식을 사용해서 효율을 높여야 함을 의미한다.


한계효용(marginal utility)은 재화나 용역이 증가 혹은 감소함에 따라 주관적으로 매겨지는 가치의 관계에 대한 개념이다. 예를 들어, 갈증이 심할 때 먹는 50원의 물의 가치와 그러한 갈증이 해결된 후에 먹는 50원의 물의 가치는 절대적인 수치는 동일할지라도 이를 접하는 이의 주관적인 가치는 차이가 발생하게 된다.


Fields of Gold
Fields of Gold by Werner Kunz 저작자 표시비영리동일조건 변경허락


우리가 시스템을 개발할 때에도 이러한 법칙은 간혹 나타나기도 한다. 초반 시스템의 형상이 어떻게 만들어질지 모르는 상황에서 개발 인력이 투입되어 시스템을 만들 때와 많은 기능들이 구현되어서 서로 복잡하게 얽혀있는 상황에서 개발 인력이 투입되어서 시스템을 만들 때에는 그 생산성이란 큰 차이를 보인다. 초반의 시스템은 구현 마지막의 시스템보다도 훨씬 복잡도가 없으며, 하나의 기능을 구현하는 속도나 시간적인 측면에서 복잡한 시스템을 이해하고 구현하려는 속도나 시간보다도 상대적으로 훨씬 짧게 걸릴 것이다. 이는 시스템 개발 후반부에 생산성이 나지 않는 경우에서 흔히 목격할 수 있다.


또한, 초반의 시스템은 구성 요소가 단순한 것도 있고, 비즈니스 로직 자체도 상대적으로 복잡하지 않아서 여기에 나타나는 버그나 기능 확장 등의 작업을 하기가 수월할 뿐만 아니라, 그 효과 역시 이를 접하는 사람에게 크게 다가온다. 즉, 아무것도 없는 상태에서 만들어낸 시스템의 가치는 후반부의 복잡하게 얽혀있는 시스템의 버그를 수정하거나 기능을 확장하는 가치보다도 훨씬 크다. 즉, 한계효용에 따른 가치가 작용된 것이다.


프로젝트는 많은 사람들과의 관계를 통해서 문제를 해결하는 과정이라고 볼 수 있다. 그 대상이 컴퓨터라고 하더라도 그 안에는 다양한 문제와 위험들이 존재하게 되며, 이는 후반부로 갈수록 더 많이 나타나게 된다. 초반의 문제 해결 능력은 아직은 많지 않은 문제들을 접하고 해결하는데 아주 큰 가치를 주지만, 후반부의 문제 해결 능력은 산적한 문제와 해결될 수 없는 위험들로 인해서 그 능력을 의심받기 시작한다.


또한, 아무리 일을 해도 계속 쏟아지는 일들로 인해서 점점 더 많은 스트레스와 함께 더 이상 생산성을 낸다는 것의 의미를 무력하게 만들기도 한다. 이러한 상황이 계속 지속되다보면 문제를 해결하는 능력에 대한 의심과 같이 부정적인 견해와 불평 불만의 이야기들이 쏟아져 나온다. 심지어 업무 간의 커뮤니케이션 역시 서로의 책임을 이야기하고 있으며, 한발짝 양보하려는 현상은 전혀 보이지를 않는다.


일을 떠나서 개인적으로 만나 이야기를 해보면 좋은 이야기를 하고, 긍정적인 말들을 하지만, 일을 접하는 순간부터 부정적인 견해와 비관적인 미래를 말하는 경우도 있다. 프로젝트는 원래의 특성상 성공이라는 단어를 함부로 꺼내가 힘든 일 중에 하나이다. 더군다나 수많은 사람들이 모여서 특정 목표를 향해 노력한다는게 얼마나 어려운지는 모두 알고 있을 것이다. 프로젝트 후반부에는 조그마한 실수 역시도 수많은 지탄의 대상이 되기도 한다. 혹은 남들보다 일찍 퇴근하는 것 역시 곱지 않은 눈으로도 보여질 수도 있다.


프로젝트를 수행하는데 있어서 중반부를 넘어가는 시점에서는 다시 한번 목표를 설정하고 공유할 필요는 있다. 그 목표가 애초에 생각했던 목표와 일치하는지 혹은 방향성 차원에서 다른 목표를 찾아야 하는지에 대해서 공유할 필요가 있다. 또한, 특정 업무가 시간만 잡아먹고 해결될 기미가 보이지 않는 내용에 대해서는 특단의 조치도 필요하다. 하지만, 무엇보다도 아무런 말과 견해를 보이지 않는 사람이라고 하더라도 분위기에 묻혀서 부정적인 생각을 가질 수 있기 때문에 지속적인 커뮤니케이션은 반드시 필요하다.


프로젝트를 성공으로 만드는 것은 이세상에 존재하지 않는다. 프로젝트에서 실패한 것들의 범위를 줄이는 것만이 있을 뿐이다.

저작자 표시 비영리 동일 조건 변경 허락
신고

철학의 한 분야인 인식론(epistemology)에서는 지식 습득에 대한 다양한 정의를 하고 있다. 즉, 인식론에서는 '앎(knowledge)이란 무엇인가?', '지식(knowledge)은 어떻게 얻는가?', '주어진 주제나 대상에 대해서 어느 정도까지 알 수 있는가?' 등의 질문에 대한 답을 구하는 과정을 이론화시킨다.


인식론은 앎의 성질을 분석하는데 초점을 두고, 진실(truth), 믿음(belief), 근거(justification)와 같은 개념과 어떤 관계가 있는지를 논한다. 이러한 인식론에 반해서 아무것도 알지 못한다고 하는 관점이 회의론(skepticism)이다. 인식론을 지식론(theory of knowledge)라고 한다.


인식론에 대한 내용은 소프트웨어 개발을 이해하는 방법에 마찬가지로 적용된다. 이는 개발 방법론 뿐만 아니라, 개념을 인식하는 과정에서도 동일하게 적용되기도 한다. 개발 방법론의 경우, 기존 전통적인 폭포수 개발 방법론에서 점증/반복 개발 방법론으로 전환이나 애자일과 같은 경량 프로세스를 이해하려는 인식의 전환에 있어서 이러한 인식의 활동들이 일어나게 된다. 또한, 프로그래밍 방식의 경우, 절차적인 개발 방식에서 객체지향 개발 방식, 그리고 컴포넌트/서비스 개발 방식으로의 전환이나, 관계형 데이터 모델에서 객체지향 관점의 데이터 모델로의 전환 역시 이러한 인식의 활동을 통해 개인의 지식(knowledge)이 발전되어 나아간다.



vastu/prativastu
vastu/prativastu by romana klee 저작자 표시동일조건 변경허락


IT 관점에서 인식의 전환을 필요로 하는 것들은 단순히 기술(technology)라고 부르기에는 한계가 있다. 왜냐하면 기술이라는 관점에서 이를 지식화시키는 과정은 매뉴얼이나 지침서를 만들어서 익히기만 하면 된다는 생각이 지배적이기 때문에 위에서 말한 지식들은 어찌보면 단순히 쓰여진 글이나 들어서 알아가는 과정 못지 않게 체득화시키는 과정이 강력히 필요하기 때문이다.


최근 NoSQL의 등장으로 인해서 대용량 데이터에 대한 분산 기술에 초점을 맞춘 내용들이 봇물을 이루듯이 나오고 있다. 하지만, 이러한 NoSQL의 관점을 기존 엔티티 간의 관계로만 데이터를 기술하려는 RDB의 관점을 개념과 개념의 집합(aggregate) 관계로 인식을 전환해야 함을 강조하는 글들이 찾아보기 힘들다. 분명 NoSQL이라고 부르는 DB들은 분산 관점의 처리에 대해 기존 RDB보다는 상당히 강점이 있다. 하지만, 분산에 대한 데이터 덩어리를 어떻게 구성하고 어떤 설계 형태가 될지에 대해서는 기존 RDB 관점의 접근 방식과는 다른 면이 있다.


데이터를 여러 테이블에 산재한 row들의 집합으로 표현하는 RDB의 관점은 NoSQL로 전환되면, 그러한 데이터 덩어리들이 하나의 집합된 형태로 표현된다. (XML이나 JSON과 같은 형태) 즉, 데이터의 구성이 관련있는, 그리고 애플리케이션 관점에서 필요한 형태의 구조를 갖게 된다.


이 두가지 인식의 차이는 얼핏 그냥 보기에 유사한 것처럼 보이지만, 아주 큰 차이를 보여준다. 데이터를 구성하는 구조에 대한 사실이 DB 자체에 저장되느냐 그렇지 못하냐는 애플리케이션 코드를 작성하는 개발자에게 그대로 영향을 미치게 되며, 데이터 저장에 있어서 마찬가지로 큰 인식 전환을 필요로 하게 된다.


예를 들어, 어느 사용자가 작성한 블로그(혹은 게시글) 정보를 기존 RDB에 저장하여 조회하는 경우, 관련 테이블의 join을 통해서 나온 결과를 다시 화면이나 애플리케이션 코드에 적합 형태로의 변환을 수행하는 로직을 생각해 볼 수 있다. 이러한 지식은 RDB에서 어느 비즈니스에 관련된 데이터의 집합이라는 관점을 시스템 상에 저장할 수 없기 때문에 이를 다루는 사람은 테이블간의 관계를 통해 매핑에 대한 사고를 한번 더 수행해야 함을 의미한다.


만일, 이를 NoSQL을 사용해서 저장한다면, 사용자에 관련된 블로그나 게시글에 대한 정보는 모두 한덩어리의 형태로 XML이나 JSON의 형태로 저장이 가능하다. 특정 사용자가 작성한 블로그나 게시글을 조회하려면 그 사용자의 ID를 조건으로 모든 데이터를 조회할 수 있다. 즉, 데이터 저장소에 저장된 데이터 구조와 화면이나 애플리케이션 코드에서 사용하려는 데이터 구조로의 매핑이 전혀 필요없게 된다.


하지만, 여기에도 단점은 존재한다. 데이터 덩어리를 어떠한 관점에서 볼 것인가에 따라서 저장된 데이터 구조가 달리 설계될 수 있다. 위의 예에서 NoSQL이 들어간 블로그를 검색하려면 사용자 기준으로 저장된 블로그나 게시글들을 모두 탐색하여 조회를 해야 한다. 즉, 데이터 덩어리를 사용자 중심으로 구조를 형성할 것인가, 혹은 블로그나 게시슬을 중심으로 형성할 것인가가 설계의 이슈로 나타나게 된다.


결국 이러한 다양한 관점의 데이터 구조를 NoSQL이 해결해주기는 아직까지 힘들기 때문에 기존 RDB의 강점과 NoSQL의 강점을 같이 혼합한 hybrid 방식의 데이터 관리를 생각해볼 수 있다. NoSQL의 등장은 기존 RDB의 반대 급부의 현상이라기 보다는 기존 데이터를 저장하는 방식에 대한 인식을 좀 더 다양한 형태로 저장할 수 있는 선택의 폭을 넓혔다고 볼 수 있다.


결론적으로, NoSQL의 등장이 단순히 기술적인 관점에서의 접근 방식이 아닌, 인식의 전환으로 바라봐야 하는 이유가 데이터를 저장하는 구조에 대한 변환을 가져오기 때문에 이러한 인식의 전환은 지식의 습득 과정과 체화의 과정을 거쳐야 하며, 이는 진실과 믿음이라는 개념을 필요로 하기도 한다. 즉, 기존에 알고 있던 정보공학 방식의 데이터 구조의 설계 방식에 대한 진실이나 믿음과는 반하는 진실이나 믿음이 존재할 수 있다는 것을 인식하는 과정이 필요한 것이다. 이러한 인식의 전환은 외부에 의한 자극보다는 내부의 자각으로 인해서 바뀌는 경향이 강하기 때문에 선택의 폭을 아무리 넓힌다고 하더라도 이를 받아들이는 입장의 인식이 변하지 않는 한 단지 새로운 또 다른 기술로 인식할 수 있을 것이다.

저작자 표시 비영리 동일 조건 변경 허락
신고

+ Recent posts