설계, 누구를 위한 활동인가

작업을 수행하는 사람들은 늘 흔적을 남기기 마련이며, 이를 SW에서는 산출물이라고 말한다. 즉, 어떠한 활동을 하든지 간에 그 흔적이 어떠한 형태로든 존재하기 마련인 것이다. SW 개발하는 입장에서 설계와 구현의 정확한 구분을 한다는 것은 사실 거의 불가능한 영역이기도 하다. 설계를 개발 단계 중에 정해진 기간으로 놓고 그 단계 내에서 산출물을 강요하는 식의 방식은 설계의 본연의 목적을 잃을 가능성이 너무나도 높다.

Anonymity; and the Internet. by Stian Eikeland

우리는 어떤 일을 하게 될때 머리속으로 먼저 무엇을 어떻게 수행할지를 가늠해본다. 좀더 깊이 생각하는 사람은 다양한 대안들을 생각해보고 각각의 장단점을 비교하여 사전 시뮬레이션까지도 고려하여 최적의 해결책이라고 여기는 방식을 선택하기도 한다. SW 개발에서 설계는 바로 이러한 활동들과 마찬가지이다. 설계는 비즈니스의 요구사항을 이해하고, 이를 시스템 관점에서 어떻게 구현할 것인지를 사전에 고민해보는 시간이다. 물론, 그러한 고민에는 다양한 제약사항들이 포함되어서 고려되는 것이 좋다. 하지만, 지금의 시스템이 단순하지도 않으며, 상당히 복잡한 비즈니스 로직이 이미 가지고 있는 상태이며, 서로 다른 시스템들의 관계까지 포함되어 있기 때문에 모든 사항을 고려해서 설계한다는 것은 거의 불가능한 일이다. 물론, 이는 경험으로 축적된 지식을 가진 사람이라면 다양한 조건들을 고려해서 설계를 할 수도 있다. 그렇다 하더라도, 설계 단계에서 고려는 그 이후 구현 시점에서 많은 부분이 바뀐다고 봐야 한다.

하지만, 아무리 경험을 많이 한 사람이라고 하더라도 설계때 만든 것을 가지고 SW를 이미 절반을 만들었다고 볼 수는 없다. SW에서도 재고라는 개념을 도입해보면, 만들어진 설계 산출물은 SW 구현을 위한 재고라고도 볼 수 있다. 현실세계에서의 재고와 SW에서의 재고의 차이는 눈에 보이는 물품의 재고는 바로 팔아서 현금화가 가능하다는 것이다. 실제 투입된 비용보다도 더 싸게 팔 수도 있겠지만, 어찌되었든 이는 명확하게 자산에 해당한다. 그렇지만, 구현되지 못한 SW의 설계는 아무리 많이 가지고 있다고 하더라도 현금화가 되지 못한다. 실제로 금융업계에서도 설계문서를 만들어서 파는 곳도 있지만, 이를 가지고 무엇을 할 수 있다는 것인가. 종이 인쇄비 만큼만 값어치가 있을 것이다. 만일 설계 문서만으로 가격을 책정한다면 많은 내용을 포함하는 설계와 단순한 몇가지 그림을 포함하는 설계, 이 두가지 중에서 어떤 것이 가격을 더 높게 쳐줄 것인가.

이를 다른 시각에서 보도록 하자. 금융 시스템은 상당히 복잡한 시스템들이 많이 있으며, 비즈니스 로직 또한 상당하다. 소스 코드 양도 천만 라인이 넘는 경우도 허다하며, 많은 인력과 오랜 경험의 축적으로 쌓여 있다. 금융 시스템의 설계의 양은 페이스북이나 트위터의 설계의 양보다도 훨씬 많을 것이다. 그럼 금융 시스템의 설계 문서와 페이스북의 설계 문서의 가치는 어떻게 책정할 것인가. (아직 해당 시스템이 구현되지 않았다고 가정한다) 결론적으로 그 가치는 아무도 모른다. 설계의 양이 많고 복잡하다고 해서 구현된 SW가 가치가 더 있다고 말할 수도 없으며, 아주 단순한 몇장의 그림만을 가진 설계로부터 구현된 SW가 가치가 훨씬 떨어진다고 말할 수 없다.

설계는 가치가 0인 산물을 만들어낸다. 그러한 가치를 매겨주는 것이 바로 우리나라의 SW 프로젝트의 특징이다. 설계가 가치를 가지는 것은 바로 사용자의 PC(디바이스) 앞에서 동작하는 SW가 있고, 그 사용자에게 가치를 줄 때 바로 의미가 있다.

그렇다면, (현물적인) 가치를 전혀 갖지 못하는 설계를 만드는 이유는 무엇일까. 우선은 커뮤니케이션과 가시화를 말한다. SW 시스템은 생명주기를 가진다. 즉, 개발 단계라는 탄생에서부터 운영을 거쳐 파기까지 길거나 짧은 시간을 거쳐서 사용자와 상호작용을 하게 된다. 그 기간 동안에 다양하고 많은 사람들이 관여를 할 수 밖에 없다. 소스 코드를 일일히 뒤져서 무슨 문제가 있고, 어떠한 상태인지를 파악하기란 지금의 시스템에서는 힘들기 때문에 이를 가시화시켜서 문서화해서 커뮤니케이션을 한다. 프로젝트의 산출물로의 가치는 바로 이러한 이유로 출발하게 된다. 그리고 그렇게 만들어진 문서는 점점 다양한 내용을 넣으려고 하고 종류나 내용이 많아지게 된다. 개발하는 입장에서는 바로 봐야할 문서가 많아지고 도통 서로간의 연관관계조차도 파악하기 힘든 경우도 많다. 이러한 설계문서는 운영이나 유지보수에 필요한 내용이 갱신되리라고 보장할 수도 없다.

설계 활동에 대한 가치를 떨어뜨리는 행위들은 매번 SW 개발 프로젝트를 수행할 때마다 반복해서 발생되며, 여기에 설계가 가지는 단어에 대한 반감을 가지게 만든다. 실제로 하나의 개념에 대해서 10가지가 넘는 문서들을 만들고 이를 보고 개발자에게 개발하라고 말하지만, 개발자는 어떠한 문서도 보지 않고 바로 해당 설계를 만든 사람에게 입과 귀로 그 내용을 듣는 경우가 허다하다. 이러한 식의 설계 활동은 전혀 개발에 도움을 주지 않으며, 오히려 개발자에게 부담만을 안겨준다.

현실적으로 제대로 된 설계를 만나보기가 힘들다. 개발자들에게 설계를 보고 만들라고 입버릇처럼 말하지만, 이를 곧이 곧대로 듣고 개발하는 사람들은 큰 낭패를 보거나 실력없는 개발자로 낙인찍히기 딱 알맞다. 설계와 구현은 사실 그 경계가 모호하고 거의 없다고 봐야 한다. 실행력이 없는 기획이나 설계는 가치가 전혀 없는 것과 마찬가지로 생각하고 사고한 것을 소스 코드로 구현할 수 있는 능력이야 말로 SW를 구현하는데 있어서 필요한 능력이라고 볼 수 있다. 정말 설계한대로 소스코드를 만들어낸다면 대단한 SW를 만들 수 있다고 생각한다면, 이는 아주 큰 오해 중에 하나이다. 설계는 세밀한 구현체와는 달리 동작하는 SW의 윤곽을 보여준다. 그 윤곽은 다양한 관점에서 바라볼 수 있는 시각을 제시하며 SW가 가지는 여러가지 제약들을 고려할 수 있는 단초를 제공한다. UML이 그러한 부분을 제시해줄 수도 있겠지만, 클래스 다이어그램 한가지만으로도 한가지 기능의 다양한 측면들을 그려낼 수 있다. 이를 그려낼 수 있는 능력이 설계자가 가지는 능력이지만, 이는 결국 구현체를 미리 머리 속에서 그려낼 수 있는 능력이기도 하다. 역으로 설계의 능력을 가진 자가 설계 문서를 만들지 않고 코드를 바로 작성하면서 머리 속에서 설계를 생각하는 것 역시 설계의 능력을 가졌다고 볼 수 있다. 즉, 설계를 통해 구현체의 투상을 볼 수 있어야 하며, 구현체를 통해서 설계를 가늠해볼 수 있어야 한다.

설계의 가치를 인정하지 않는 것은 아니다. 설계는 분명 그 자체로 가치가 충분하며 설계자의 의도가 명확할 때에만 그리고 남을 이해시킬 수 있는 관점을 정확하게 제시할 때 그 가치가 제대로 발휘된다. 물론 구현체로써도 설계 문서를 가지고 설명이 된다면 더할 나위 없을 것이다. 설계는 그 누구를 위한 것보다도 개발자 자신을 위한 산출물을 만들어낼 때에 그 가치가 있다. 아무리 단순한 기능이라고 하더라도 하나 둘 제약사항이 들어가기 시작하면 처음에 단순한 모델이 복잡한 구현체로 변모했음을 알 수 있을 것이다. 시스템을 단순히 CRUD를 가지는 기능 덩어리로 바라보는 관점은 이제는 바뀌어야 한다. 과거의 시스템은 하나의 기능을 수행하기 위해서 사용하는 시스템의 자원을 지금의 시스템에서 제공하는 기능이 사용하는 시스템의 자원과 비교를 한다면 엄청나고 복잡할 것이다. 때로는 이러한 기능을 한 사람이 아닌 여러 사람이 공동으로 개발하는 경우도 많다. 이를 소스 코드만으로 분석하려고 한다면 그리고 이를 말로만 설명하려 한다면 엄청난 오해와 곡해로 인해서 전혀 예상했던 기능과는 다른 기능이 만들어질 것이다. 이미 그 때에는 되돌리기에는 너무나 많은 노력을 투여했기 때문에 그 복잡성에 더해 새로운 복잡성을 만들어내기도 한다.

구현시 수없시 많은 재반복 작업을 경험해본 적이 있는가. 그렇다면 우선은 설계를 만들어서 전체적인 윤곽을 그려보라. 거기에서 장단점을 볼 수 있는가. 단점을 극복할 수 있는 방법을 추가해보라. 설계를 먼저 그러한 용도를 사용해본다면 반복되는 구현 작업을 최소화시킬 수 있을 것이다. 설계는 구현을 하는 방법을 최적으로 하기 위한 전략을 구상하고 예측할 수 있게 만드는 장치로 활용한다는 사고를 가진다면 설계 작업이 더 없이 필요함을 느낄 것이다. 코딩은 단순한 작업이 아니다. 결코 단순해질 수 없는 작업이며, 앞으로도 더 복잡해졌으면 복잡해졌지 단순해질 수 없는 작업이다.