여기에 의사소통을 하는 아주 혁신적인 도구가 있다고 하자. 이 도구는 언어나 텍스트로 표현하지 않아도 생각만으로 사용자의 의사를 표현할 수 있다고 하자. 정말 혁신적이지 않은가. 이제 우리는 더 빠르고 효과적으로 의사소통을 할 수 있게 되었다. 하지만, 과연 그럴까? 의사소통의 본질적인 내용을 보면 결국 쌍방의 의견이 합의해가는 과정이 된다. 아무리 빠르고 효과적으로 내 의견을 표현할 수 있다고 하더라도 이것이 의사소통을 효과적으로 할 수 있는 방법이 아닐 것이다. 의사소통에서는 '빠름'이 정답이 될 수 없음을 의미한다.


IMG_0567
IMG_0567 by illum 저작자 표시동일조건 변경허락



기존 소셜 서비스들이 의사소통에 영향을 미친 것은 빠른 의견의 개진과 더불어서 다수의 다양한 의견이 어느 방향성을 가지고 합의해가는 과정인 것이다. 즉, 이전에는 특정인이나 전문가 집단에 의해 한정된 의견으로 한정된 결정을 했다고 한다면 좀 더 다양하고 폭넓은 의견을 통해서 다수가 원하고 다수가 합의하는 결정으로 선택한다는 것이다. (다수가 선택한다고 꼭 정답이라는 것은 아니다.) 빠른 의사소통을 혁신적으로 할 수 있는 도구가 기존의 합의를 이루는 과정을 대체하기 힘들다는 것이다. 기존의 의사소통을 하는 방식은 수천년 동안 인류가 보편적으로 수행하던 방식이기에 이를 바꾸기는 힘들다. 결국 도구는 이러한 전통적인 의사소통이나 의사결정을 하는 방식을 더 효과적이고 효율적인 형태로 할 수 있게 도움을 주어야 한다.


도구를 도입하거나, 가지게 된다면 혁신적으로 문화를 바꿀 수 있다라는 생각은 SW를 도입하는 기업에서도 늘 발생하는 문제이기도 하다. 물론, 도구가 가지는 특성에 따라서 도구의 도입으로 기존 불편한 부분을 혁신적으로 바꿀 수 있는 영역은 분명 있다. 하지만, 이러한 영역이 문화나 프로세스와 같은 모든 구성원들과 수행 방법에 걸쳐서 스며든 내용까지는 바꾸기는 힘들다. SW를 개발하는 문화 역시 그 나름대로의 조직마다 독특한 문화가 존재하고, 그러한 개발 방식은 최종적으로 SW를 인도하는 시점에 고객의 만족으로 집중될 수 있다. SW 개발을 자동화하여 생산성을 아무리 높여도 고객 만족을 충족시키지 못한다면 이는 도구 도입으로 인해서 오히려 기존의 작업 방식을 저해하는 것이다. 도구가 담당하는 영역이 넓으면 넓을수록 오히려 도구에 한정되어서 기존 프로세스나 절차와의 충돌이 발생될 여지가 많아진다. 결국 이러한 기존 문화나 프로세스의 충돌을 해결하지 못하다면 도구가 가지는 장점보다도 단점의 모습이 더 많이 보이게 되고, 도구 도입의 실효성을 의심하게 된다.


구매나 제조 프로세스를 아우르는 ERP의 도입 역시 기존 프로세스와 상당한 충돌이 발생되면서 한정적 사용의 형태로 도구의 활용의 변형이 발생된다. 도구가 제공하는 기능에 사로잡혀서 모든 것을 도구 중심으로 맞추고 여기에 노력을 해보았지만 다시 원래의 프로세스로 되돌아가는 현상을 목격하는 것은 어렵지 않다. 인류가 발명한 위대한 도구들은 어느날 하루 아침에 번쩍하고 나타난 것들이 아니다. 그 이전에도 수많은 노력과 시도를 통해서, 그리고 여기에 인류가 적응해가면서 나름대로 최적의 방법과 같이 나타난 것들이다.


SW 도구 구매가 쉬워지면서 어느날 반짝하고 나타난 도구들과 같이 우리 삶은 마치 도구에 의존되거나 종속되도록 조정을 받는 경우도 많다. 도구 적응에 얼마나 쉽고 간편하게 접근할 수 있을 것이가, 그리고 도구가 이전에 우리가 수행했던 방식을 얼마나 존중하고 떠 받쳐줄 수 있을 것인가를 따지는 것이 도구를 도입하는 효과를 극대화시키는 방법이다.


도구를 통해서 문화를 형성하고 구성하는 것은 정말 엄청난 노력이 든다. 이러한 노력을 최소화시키는 방법은 강제하는 것도 있다. 즉, 다양한 제약을 통해서 도구에 순응하게 만드는 것이다. 이러한 형태는 도구가 없으면 아무것도 못하게 만드는 결과를 낳기도 한다. 강제하지 못한다면, 도구를 익히고 적응하는데 많은 시간을 들여야 한다. 물론, 도구가 지원하는 범위가 협소하다면 그러한 시간이 아깝지는 않은 경우도 있다. 도구가 지원하는 범위가 넓다면, 가장 효과적으로 적용할 수 있는 영역을 찾아서 적용하는게 낫다. 도구 역시 인간이 만든 것이기에 여기에는 오류를 포함하고 있다. 그러한 오류까지도 문화에서 수용할 필요는 없다.


도구를 도입한다고 하면, 조직 구성원과 문화에 제일 적합한 도구를 선정해야 한다. 문화를 바꿀 목적으로 도구를 도입할 필요는 없다. 오히려 어색한 옷을 입은 모양과 같이 불편한 상황을 연출할 뿐이다. 이러한 상황은 기존의 최선의 원리나 원칙이 도구로 인해서 제약받는 경우에 식별된다. 즉, 도구로 인해서 최선이나 최적으로 생각했던 방식을 바꾸어야 한다면, 도구가 오히려 해당 문화나 절차를 해치는 결과를 초래한 것이다.

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

아주 근사한 가전제품을 만드는 회사가 있다고 하자. 이 회사에는 가전제품을 구성하는 요소들을 설계하는 설계팀과 이를 기반으로 조립 라인을 통해서 하나의 가전제품을 만드는 제조팀으로 구성되어 있다. 설계팀은 제품의 컨셉을 이해하여 명세(specification)를 정하고, 그에 맞게 각 구성 요소들을 설계 도면에 표시한다. 제품의 크기를 휴대성이 편하게 최소한으로 명세했기 때문에 가능한 한 각 구성요소가 최소한의 공간 안에 밀집하게 구성되어야 하며, 때로는 하나의 요소가 여러가지 역할을 수행하게끔 구성품을 만들어야 하는 경우도 있다. 설계팀은 촉박한 일정에서도 제조팀에서 해당 제품을 만들 수 있는 상태의 모든 요소가 설계되었음을 확인했고, 최종적으로 제조팀에게 제품 설계를 넘긴다.


제조팀에서는 설계를 토대로 생산과 조립 라인을 구성하고, 각 구성품들을 만드는 팀과 구성품들을 사용해서 조립하여 최종 기능 점검을 하도록 라인을 셋업한다. 처음에는 설계 도면을 이해하고 이러한 라인을 구성하는데 다소 시간이 걸릴 것이다. 또한, 기존 다른 제품의 라인을 재사용하기 위한 최적의 안을 만들어보고 시험 가동하여 최종 제품을 만들어낸다. 어느 정도의 조정을 통해서 제품을 생산하는 최적의 방법을 찾아낸 제조팀은 제품을 본격적으로 생산한다.



Killbot Assembly Line
Killbot Assembly Line by pasukaru76 저작자 표시



제조팀이 가능한 많은 테스트를 수행하려고 하지만, 현실적인 제약으로 인해서 고객에게 제품을 인도하고 나서 다양한 기능 결함들에 대한 의견이 접수되고 문제의 원인을 파악하기도 한다. 이 과정에서 생산과 조립 라인 내에서만 문제 해결이 안되는 경우도 많다. 즉, 제품을 설계한 설계팀과의 의견 조율이 필요하게 된다. 만일, 설계팀에서는 설계 문서를 보고 무엇이 문제인지를 이야기하고, 제조팀에서는 생산이나 조립 라인에서 문제를 찾아야 한다고 서로가 주장한다면 어떤 결과가 나타날지 예상을 할 수 있다. 설계 문서에는 당연히 제품을 구성하는 구성요소들의 만드는 과정이나 조립하는 과정이 나타나있지 않다. 설계팀에서는 설계 문서를 보고 제조팀에게 문제를 설명하지만, 제조팀은 라인 현장과의 매핑이 안되고 마치 뜬구름 같은 이야기처럼 들리게 된다. 이때에는 설계팀에서 생산이나 조립 라인의 현장을 둘러보고 설계문서와의 매핑을 통해서 문제 해결의 실마리를 찾아야 한다. 왜냐하면 라인 현장이 설계팀과 제조팀이 공통적으로 이해할 수 있고 의사소통할 수 있는 매개체이기 때문이다.


SW를 만들때에 설계팀을 아키텍처팀으로, 제조팀을 개발팀으로 비교해보자. 아키텍처팀은 자신이 만든 설계들을 개발팀에게 전해주며 이를 기반으로 SW를 만들라고 말한다. 개발팀은 이를 토대로 개인의 개발환경(작업장)과 통합/배포, 검증에 관련된 환경들을 만들고 본격적으로 SW를 만든다. 응당 개발팀에게는 문제가 발생되기 마련이고, 이를 해결하고자 하는 욕구를 어딘가에 이야기하길 원한다. 아키텍처팀에서는 개발팀의 이러한 문제를 접수하기도 하지만, 대답은 설계 문서에서 그 답을 찾으려고만 한다. 개발팀은 아키텍처팀에서 이야기한 것이 무엇인지를 이해하고 자신의 문제로 매핑해야 하지만, 도저히 그러한 매핑이 어떻게 이루어져야 하는지를 잘 모른다. 결국 개발팀은 문제를 불거지게 하지 않고(문제를 쌓아두거나 그냥 묻어두는 형태) 최소한의 검증에만 통과할 수 있도록 둔다.


이러한 문제는 결국 시스템을 오픈하는 시점에서야 뒤늦게 발견되고, 아키텍처팀과 개발팀이 서로 얼굴을 대고 으르렁거리는 사태까지도 연결되기도 한다. 아키텍처는 SW가 만들어질 수 있는 최종적인 상태만을 이야기하기 때문에 그러한 과정에서 발생될 수 있는 문제들에 대해서는 모두 포함할 수가 없다. 이는 제조 과정에서 일어나는 것과 비슷하다. 아키텍처팀이 개발의 모든 과정에 참여하기가 현실적으로 힘들지만, 문제 발생시 현장을 개발팀과 같이 살펴야 한다. 물론, SW는 현장이 개발 소스 코드라는 것은 당연하다. 즉, 문제는 소스 코드에서 해결 실마리를 찾아야 한다는 의미이다. 아키텍처가 가지는 많은 장점들이 있지만, 가장 크게 빠질 수 있는 맹점은 현장 적용에 있어서 SW 제품을 만드는 과정의 문제를 모두 포괄할 수 없다는 것이다.


개발자의 환경의 탓으로 인해서 아키텍처에서 만든 프레임워크가 잘 동작되지 않는 경우도 있다. 혹은, 너무 과도하게 생성된 객체들로 인해서 설계에서 만들어놓은 객체 수용 공간의 한계를 넘어서는 경우도 있다. 복잡하게 얽힌 컴포넌트들 간의 관계로 인해서 원활하게 통합이나 배포가 어려운 경우도 있다. 비즈니스 로직이 UI에 너무 많이 몰려있는 관계로 사용자 환경이 해당 SW로 인해서 문제가 발생되는 경우도 있다. 요구사항으로 인해서 너무나 많은 데이터를 필요로 하는 통신으로 인해서 다른 기능의 네트워크 부하에도 영향을 미치는 경우도 있다. 이러한 문제들은 개발 과정에서 비일비재하며 독특한 형태로 나타난다. 이를 설계 문서만을 가지고 해결한다고 하면, 개발자들은 이해하지 못하는 언어로 의사소통하는 경험을 느끼게 되며, 심지어 책임 회피 현상까지도 나타나게 된다.


아키텍처팀과 개발팀의 공통 언어는 소스 코드이어야 한다. 물론, 개발팀에서도 설계를 이해하고 설계할 수 있는 능력을 필요로 한다. 하지만, 설계상의 문제보다 개발 과정의 문제가 훨씬 더 많은 비중을 차지하며, 실제 고객에게 인도되는 SW는 설계문서가 아니라 동작하는 SW가 아닌가. 개발팀이 고민하는 문제를 해결해줄 때에 더 품질이 높은 SW가 만들어질 수 있다. 개발팀에게 더 친숙한 형태로 다가가는게 더 생산성이 날 수 있다. 개발팀이 아키텍처팀에서 일방적으로 정한 것을 따라오는 대상이 아니라, 아키텍처팀에게는 또 다른 이해관계자라는 개념으로 바라보아야 한다. 이해관계자가 가지는 관심사(concern)를 해결해주는게 아키텍트의 임무(role)이지 않은가.

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

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 기능이 어떠한 기능들과 관련되어 있는지에 대한 내용을 파악하지 못한채 진행하고, 이를 구현단계에서도 변하지 않는 것으로 인식하게 되는 순간 해당 기능은 전혀 의미없는 구현으로 낳게 되는 결과를 맞이할 수도 있다. 즉, 해당 기능은 그 기능의 목적과 의도를 파악해야 하고, 이를 분석하는 것이 더 의미가 있으며, 이를 개발자에게 이해시키는 활동이 필요한 것이다.


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


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

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

+ Recent posts