크리에이티브 커먼즈 라이선스
Creative Commons License

SW를 개발하는 가장 보편적인 과정은 분석-설계-구현-테스트-인도의 형태를 나타난다. 수많은 SW를 만드는 프로젝트에서는 이러한 보편적인 과정을 중심으로 보편적인 계획을 만들고, 여기에 많은 노력을 기울인다. 초반 계획은 비즈니스에 대한 범위 뿐만 아니라, 전체 프로젝트에 대한 예산과 일정까지도 염두를 해두어야 하기 때문에 계획을 만드는 입장에서는 조심스럽고 여러가지 상황들을 고려하여 계획을 만든다. 통상 이러한 계획은 SW가 제공되어야 하는 기능을 중심으로 일정에 대한 틀을 잡고 전체적인 개발 계획이 마련된다.


이와 같은 방식이 얼핏 보면 가장 합리적이고, 무엇보다 전통적인 방식(기능을 큰 단위에서 적은 단위로 쪼개어서 개별 작업을 중심으로 일정을 세우는 방식)이기 때문에 선호하고 보편화되어 있다. 하지만, 이와 같은 계획은 SW가 제공하는 기능과 밀접하게 관련이 있기 때문에 SW를 만드는 과정에서 기능의 변경이나 수정이 발생하게 되면 전체적인 일정이나 예산이 달라질 수 있다라는 아주 큰 단점을 가지고 있다. 이러한 변경이 발생되면 일정과 범위가 바뀌어야 하기 때문에 되도록이면 기능의 변경이나 수정을 최소화시키려는 현상들이 발생되며, 이는 결국 프로젝트 처음부터 모든 기능을 도출하게 하는 (이후 다양한 이유로 식별된 기능이 바뀐다는 것을 인지함에도 불구하고) 작업들을 만들어낸다.


이와 같은 방식으로 분석/설계된 내용들은 구현 과정에서 그 내용이 바뀐다는 것을 모든 사람들이 알지만, 결국 감사와 감리라는 속박 속에서 어떠한 뚜렷한 방법을 시도할 생각도 없이 그냥 모두의 책임으로 남긴 채 어쩔 수 없는 상황으로 그 탓을 돌려버린다. 이러한 잘못들을 우리는 매번 프로젝트를 수행할 때마다 계속해서 저질러야 하는지는 한번쯤은 생각해 볼 만하다.



www.Army.mil
www.Army.mil by The U.S. Army 저작자 표시



군대에서는 비상시 전투에 임하는 개별 병사들에게 각자가 수행해야 하는 '개인임무카드'를 숙지하고 훈련시에도 이에 따라서 행동하게 만든다. 예를 들어, '최초 군장을 챙겨 OO 지점에 있는 탄약고로 이동하여 탄약 OOO발과 수류탄 OO발을 수령하여 OO지점으로 신속하여 이동하여 OO한다'와 같은 내용을 적혀있는 개인임무카드를 평상시 외우게 하고, 이에 따라 행동하게끔 수많은 반복 훈련을 한다. 이는 훈련시에 행동할 수 있는 지침으로 상당히 의미가 있고, 그 내용으로써도 손색이 없다. 하지만, 실전에서는 과연 이와 같이 행동할 수 있을 것인가에 대해서는 의문을 가질 수 있다. 만일 탄약고가 적의 포탄으로 손실되었다면, 위와 같은 개인임무카드에 익숙한 사람은 어떻게 행동해야 하는가? 만일 수령할 탄약과 수류탄의 수가 적어서 평상시 지급받던 것보다 덜 받았다면 남의 할당량까지 가지고 가야 하는가, 아님 지급받은 것만 받아야 하는가? 이동하려던 지점의 경로에 위험물이나 적에게 노출될 우려가 있어서 혹은 이동 경로에 문제가 생겨서 그동안 수없이 훈련받은 경로로 이동할 수 없다면 어떻게 이동해야 하는가?


이러한 내용들은 개인임무카드에도 적혀있지도 않을 뿐더러 평상시 훈련에서도 고려되지 않았다. 따라서, 이러한 단점을 보완하기 위해서 군대에서는 작전 명령에 지휘관의 의도(Commander's Intent, CSI)를 포함해서 이를 예하부대에서 이해하고 있어야 함을 정하고 있다. 지휘관의 의도는 어떤 명령이 최종적으로 도달해야 하는 상태이며, 작전에 대한 궁극적인 목적이기도 하며, 수행해야 하는 주요 업무를 포함하고 있어야 한다. 개인임무카드에 적혀있는 행동 지침들은 지휘관의 의도에 맞게 얼마든지 수정될 수 있으며, 지휘관의 의도에 맞지 않는다면 개인이 판단해서 해당 행동을 바꿀 수도 있다.


SW 개발 프로젝트에서 최초의 계획은 마치 개인임무카드를 일일히 마련하는 것과 동일한 작업들을 한다. (최소한 그와 유사한 작업들을 한다) 하지만, 막상 SW 개발 단계에 들어가면서 이러한 개인임무카드에 적혀있는 내용들은 SW 개발시점에 전혀 다른 행동을 할 수 밖에 없는 상황에 부딪혀서 전혀 의미가 없는 내용들로 인식되며, 실제로도 아무런 도움이 되지 않는다. 즉, SW 개발 기간 동안에 전혀 사용할 수 없는 계획을 위해서는 사전에 어마한 노력을 들이고, 이에 대한 강력한 믿음을 강요하게 된다. '분석가는 OO 기능에 대한 프로세스와 관련 정보를 식별하고, 이를 특정 템플릿으로 그 내용을 채운다'와 같은 내용은 실전에서 OO 기능이 왜 필요한지, 혹은 OO 기능이 어떠한 기능들과 관련되어 있는지에 대한 내용을 파악하지 못한채 진행하고, 이를 구현단계에서도 변하지 않는 것으로 인식하게 되는 순간 해당 기능은 전혀 의미없는 구현으로 낳게 되는 결과를 맞이할 수도 있다. 즉, 해당 기능은 그 기능의 목적과 의도를 파악해야 하고, 이를 분석하는 것이 더 의미가 있으며, 이를 개발자에게 이해시키는 활동이 필요한 것이다.


계획 단계에서 이루어지는 활동의 결과로 만들어지는 내용들에서 지휘관의 의도와 같은 내용을 찾아보기란 쉽지 않다. 계획 단계에서부터 이러한 의도들은 수많은 다양한 산출물로 나뉘어지고 변환이 되어서 그 안에 들어있기 때문이며, 단계를 진행하는 사람들은 이러한 의도를 알아서 (제대로 개발을 할 줄 아는 사람이라면) 그 안에서 찾아서 실행해야 한다.


어찌보면 이미 알거나 이해하는 내용들이 잘못되거나 잘못될 것을 앎에도 불구하고, 어찌할 수 밖에 없는 환경에 스스로를 억지로 맞추는 우스꽝스런 작업들을 하는지도 모르겠다. 

저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

인터페이스 설계에서 오퍼레이션은 그 나름대로 책임을 가지게 된다. 즉, 해당 오퍼레이션을 호출하기 위해 입력받는 정보에 대해서는 호출하는 측(이하 클라이언트)에서 그 데이터가 올바로 들어갔는지를 점검할 책임이 있으며, 입력된 정보를 가지고 출력 정보를 형성하는 측(이하 서버)에서는 반환 정보에 대해서 올바른 값이 들어갔는지를 점검할 책임이 있다. 다시 말해서, 오퍼레이션은 사전 조건(precondition)과 사후 조건(postcondition)에 만족한 상태가 되어야 클라이언트와 서버가 원활하게 정보를 주고 받을 수 있다.


이와 같은 책임성에 기반해서 설계하는 방식을 '계약에 의한 설계(design by contract)'라고도 한다. 메시지를 주고 받는 양측은 서로 조건에 만족시킬 책임(responsibility)과 의무(obligation)를 양측에게 가지며, 이는 계약과 같은 형태로 존재하기 때문에 어느 한쪽이 이를 무시하거나 지키지 않는다면, 응당 그에 대항하는 책임이나 의무를 지을 필요가 없게 된다. 예를 들어, 숫자 1을 입력받고 한글 '하나'를 반환하는 오퍼레이션의 경우, 숫자 1이외의 값이 넘어오는 경우에 당연히 한글 숫자 '하나'를 반환할 의무가 없으며, 그외의 기타 예외나 null과 같은 형태로 계약이 파기되었음을 알릴 필요가 있다. 클라이언트에서는 오퍼레이션을 호출할 때 입력값을 올바르게 넣을 책임이 있으며, 이러한 책임은 서버에서 그에 합당한 올바른 값을 반환할 의무가 발생하는 것이다. 마찬가지로, 서버가 올바른 값을 반환할 것이라고 생각한 클라이언트가 올바른 값을 받지 못할 때에(서버가 올바른 값을 넘겨줄 책임을 다하지 못하는 경우), 클라이언트는 반환된 값에 대해 마찬가지로 계약 파기와 같은 행위(예외 처리와 같은)를 할 수 있다.



Apple Temptation
Apple Temptation by Lawrence OP 저작자 표시비영리



인터페이스 명세는 이러한 'Design by Contract (DbC)'라는 원칙을 준수할 수 있도록 기술(description)되어야 하며, 이는 문서를 만드는 경우에도 마찬가지로 포함되어야 한다. 하지만, 현실 세계에서는 이러한 원칙으로 인터페이스 명세를 작성하는 예를 찾아보기란 힘든게 사실이다.


여기에 한가지 현실적인 팁을 제공하자면, 이러한 DbC에 대한 명세를 제공하지 못한다면, (비)대칭적인 오퍼레이션을 제공하는 것도 방법이 될 수 있다. 즉, 대칭적인 오퍼레이션이란 정보를 저장하는 행위와 조회하는 행위를 일치시키는 방식으로 저장하는 구조 그대로 조회하는 오퍼레이션을 제공하는 것이다. 비대칭은 저장하는 정보의 구조와 조회하는 정보의 구조가 달라지는 형태라고 보면 된다.


이 경우, 정보를 검증하는 책임의 위치가 다소 달라질 수 있을 것이다. 예를 들어, 은행에 돈을 맡기는 경우, 고객이 1만원권 5장을 저금하고, 나중에 이 돈을 출금하는 경우, 은행 입장에서 1만원권 5장을 제공하는 경우와 5만원권 1장을 제공하는 경우로 나누어 볼 수 있다. 1만원권 5장의 경우에는 고객이 이미 1만원권을 알고 있고, 응당 저금시의 형태와 출금시의 형태가 같기 때문에 이는 자신이 받아야 하는 금액으로 인식을 할 것이다. 하지만, 은행이 5만원권을 내어주는 경우에는 고객이 만일 5만원권에 대한 인지를 하지 못한다면, 은행은 고객에게 5만원권 1장이 1만원권 5장과 같음을 증명해야 할 것이다.


결론적으로, 대칭적인 오퍼레이션을 제공하는 경우, 클라이언트 측에서는 저장에 상응하는 조회 오퍼레이션을 서버측이 제공함으로써 자신이 입력한 정보가 저장이 되었는지를 점검할 수 있으나, 비대칭적인 오퍼레이션을 제공하는 경우, 서버측에서 저장된 정보가 조회시 올바로 조회되는지에 대한 책임을 져야 한다.


이러한 (비)대칭 오퍼레이션[기능]에 대한 부분은 테스트를 통해서 충분히 검증이 가능하다. 예를 들어, 돈을 이체하는 기능의 경우, 이체를 요청하는 측(클라이언트)은 입금액을 파라미터로 넘기고, 잔액을 리턴으로 받아서 이체에 대한 검증을 이체를 수행하는 주체(서버)에서 이를 수행하게끔 할 수도 있다.(비대칭 signature) 혹은 이체를 수행하고 나서 그 결과값만을 보내고, 이체를 요청하는 측(클라이언트)에서 잔액을 다시 조회함으로써 이체에 대한 결과를 검증해볼 수 있다.(대칭 signature)


통상 설계나 구현을 할 때에 이러한 검증에 대한 고려를 하지 않는다면, 어느 한쪽에 치우친 기능만이 도출될 우려가 있다. 즉, 검증을 고려하여 기능의 책임을 양측(기능을 호출하는 측과 이를 제공하는 측)에 대한 균형을 유지하는게 좋은 설계라고 볼 수 있다.




기능이 비대칭적으로 혹은 대칭적으로 설계/구현이 되었든 간에 기능 검증의 책임은 서버와 클라이언트 측 어느 한곳에 반드시 있어야 하며, 이를 검증할 수 있는 메커니즘은 반드시 필요하다. 비대칭의 경우, 서버의 상태를 투명하게 보이게 하거나 혹은 외부에서 진입될 수 있는 지점을 열어놓음으로써 이러한 검증을 수행할 수 있고, 대칭의 경우, 클라이언트 측에서 서버가 제공하는 기능을 사용해서 검증할 수 있어야 한다. 전자는 식별된 기능을 중심으로 식별된 내용을 그대로 유지한 채 시스템을 설계하는 방식이 될 것이며, 후자의 경우에는 식별된 기능 이외에 안보이는 기능을 추가로 식별하는 과정으로 볼 수 있을 것이다. 후자는 최초 기능 식별에서 나타나지 않는 기능이라 하더라도 점차 기능 식별이 더 활발하게 진행되고 SW가 완성되어 가는 과정에서 이러한 기능은 재사용될 가능성이 더 높다.


계좌이체 예제에서 잔액을 확인하는 기능은 비대칭으로 구현시 계좌이체 프로세스 내에 섞여있는 형태로 나타나지만, 대칭 형태로 구현시에는 잔액 확인은 다른 기능에서 재사용될 가능성이 높아지고, 결국 현재 식별/구현되는 기능 이외에서 필요한 기능이 될 가능성이 높다.


대칭과 비대칭 signature는 시스템을 설계/구현하는 입장에서 어떤 것이 사용하기에 더 적합한지를 고려하여 선택하게 된다. 하지만, 이 두가지 형태는 모두 책임과 의무를 어느 측에 둘 것인가를 고려하면서 양측에게 이러한 책임과 의무가 균형을 이루도록 설계하는 DbC 원칙을 유지하게끔 하는 방식이라고 보면 된다.

저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

기술의 발전은 다양한 형태로 그 모습을 대중들에게 표현되고 전파된다. 그러한 과정에서 어떤 기술은 극도의 발전 형태를 띠는 것들이 있는가 하면, 다른 기술들은 오히려 전파되는 과정에서 그 효력이 못미치는 것들도 있다. 기술이 마케팅의 수단을 이용하는 경우에는 소비자나 이를 접하는 사람으로 하여금 해당 기술의 본질을 파악하는 것을 어렵게 만드는 경우도 있다. 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)'를 꼽는 것은 당연하다. 하지만, '컴포넌트' 기술과 마찬가지로 한낱 유행에 불과한 단어로 남는 역사를 되풀이하지 않으려면 이를 적용하려는 사람에게는 그 본질적인 면들을 파악해서 기존 기술과의 차이와 발전 방향에 대해서 논의될 필요는 있다.

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

+ Recent posts

티스토리 툴바