개인임무카드와 지휘관의 의도 - SW 계획과 실행의 모순

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

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

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

www.Army.mil by The U.S. Army

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

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

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

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

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