수평적 사고

여러분들이 모델링을 잘 하기 위해서 가장 먼저 개조해야 할 것이 있다면 수직적 사고를 수평적 사고로 바꾸는 것이다. 우리는 일반적으로 직관이 잘 발달되어 있고, 오랫동안 절차형으로 프로그램을 개발해 왔기 때문에 수직적으로 파고 드는 것에는 일가견을 가지고 있다.

그러나 모델링은 수평적으로 진행해 가지 않으면 절대로 하기 어려운 작업이다. 모델링 초기에는 아직 아무 것도 확정된 것이 없어 모든 것이 온통 불확실한 것 투성이다. 부모도 정의되지 않았는데 자신을 정의할 수 있겠는가? 내가 누군지도 정확히 정의되지 않았는데 내 자식을 어떻게 정의할 수 있겠는가?

모든 일에는 먼저 확정해야 할 것이 있고, 그것에 따라 나중에 확정할 것이 있는 법이다. 이 말은 위나 주변의 상황이 확정되지 않고서는 아래로 내려 갈 수가 없다는 것을 의미한다. 다시 말해서 수평적으로 밖에 진행할 수 없음을 말한다. 그럼에도 불구하고 무책임하게 자꾸 아래로 내려가는 것은 ‘명확하지 않은 정의’를 하고 있다는 것이 너무나 분명하다.

이런 방법은 당연히 헛점과 모순이 따를 것이며, 필연적으로 앞서 정의한 부분이 다시 수정을 일으키며 이로 인해 다시 아래 부분이 영향을 받는 악순환을 일으킬 것이 틀림없다. 우리는 정보시스템 분야에 발을 내딛으면서 지금까지 항상 접해 온 것은 한 건을 읽어 수 많은 경우의 수를 처리하는 복잡한 방식의 프로그램이다.

한 건에 대해 수직적인 처리가 끝나면 다음 건을 읽어 반복한다. 우리는 이러한 절차형 처리에서 발을 빼 본 적이 거의 없다. 이런 방식의 최대의 현안은 나타날 다양한 (예외)경우를 어떻게 풀어갈 것이냐에 있고 이것을 찾기에 혈안이 되어 왔다.

당연히 우리의 사고는 절차형으로 굳어 질 수 밖에 없었고, 흐름을 따라가면서, 스토리 중심으로 업무를 파악하고 설계를 해 왔다. 너무나 수직적이고 프로세스적인 길을 걸어 왔다는 것이다. 가령 엔터티 후보들을 찾아야 하는 단계에서 복잡한 예외처리에 빠져 고민하는 우매함을 곧 잘 저지른다.

수평적 사고를 하기 위해서는 먼저 현재 수준에서 우선적으로 정의해야 할 일정수준을 목표로 두고, 이것을 완벽하게 확정하는데 총력을 기울이는 것이다. 여기서 결정된 사항은 다음 단계에 해야 할 일들에 ‘정해진 상수값’의 역할을 함으로써 한꺼플씩 베일을 벗어 나가게 되는 것이다.

수평적 사고에 익숙해져 있지 않은 사람들의 공통적인 특징은 어떤 사안에 손을 댔다가 중간에 멈추면 매우 불안해 진다. 무엇인가 남겨주고 그냥 가버리는 것 같은 생각이 들어서 자꾸만 불안해 진다. 이것은 우리가 프로그램에서 어떤 프로세스를 처리할 때 한 번 손을 때면 끝을 봐야 하는 습관이 몸에 단단히 베었기 때문이다.

우리나라 사람들의 재미있는 특성을 살펴보자. 복잡한 수학문제가 하나 있다고 생각해 보자. 한 번에는 풀 수 없으니까 당연히 단계마다 ‘=’을 사용하면서 계속해서 풀어 나간다. 그리고는 예를 들어 마지막에 답이 ‘5’라고 잘도 만들어 낸다. 그런데 각 단계별로는 반드시 ‘=’이 되어야 틀린 답을 내지 않을 것일진대 참으로 신기한 것은 자세히 살펴보면 각 단계별은 정확히 ‘=’이 되지 않는 경우가 있는 데도 불구하고 답은 제대로 만들어 내고 있다는 것이다.

보다 정확하게 표현을 하자면 이것은 ‘=’이 아니라 ‘→(화살표)’가 맞는 표현일 것이다. 즉, 이 단계가 다음 단계로 진행되었다는 표시일 뿐이지 앞과 뒤가 정확히 일치(=)하지는 않는다. 그럼에도 불구하고 답을 만들어 내는 것이 우리나라 사람들이다. 이런 현상은 설계단계, 특히 기능 설계단계에서 DFD(Data Flow Diagram)를 그릴 때 확연하게 나타난다. 원칙적으로 보면 하위계층을 크게 둘러 싼 모양은 상위 계층의 버블(bubble)과 정확히 일치해야 하지만 어느 프로젝트에서도 이 원칙을 정확히 준수한 DFD는 볼 수가 없다. 그럼에도 불구하고 신기하게도 프로그램은 개발되고 시스템은 가동이 된다.

문제는 정상적인 가동을 하기 까지는 많은 시행착오가 틀림없이 있었을 것이며, 앞으로 수 많은 업무 변화가 발생했을 때 많은 비용이 소요될 것이 걱정일 뿐이다. 불이 나 봐야 불이 안 났을 때 보다 비용이 증가했는 지를 알게 되고 이를 아까워 하게 된다. 프로그램은 시행착오를 겪더라도 상대적으로 충격이 적다. 그러나 설계 상의 문제는 그 시행착오가 미치는 영향은 굳이 정보공학론을 들먹이지 않더라도 수십배의 충격을 받는다는 것은 자명한 일이다.

설계를 해 가는 과정에서도 마찬가지라고 할 수 있다. 건물을 지을 때 아직 문짝을 어디에 달지도 결정하지 않았는데 도어록을 가져다가 어디에 붙일 지를 걱정하는 바보가 되어서는 안된다. 만약, 풍경화를 그릴 때 주변은 아직 데생도 끝나지 않았는데 어떤 가지의 잎사귀를 자세하게 그렸다면, 다른 것들과 위치가 맞지 않거나 크기가 맞지 않다면 애써 그려 놓은 것을 모두 지워버려야 할 것이다.

이런 무지한 짓을 하지 않기 위해서 사고를 수평적으로 접근할 수 있는 기가막힌 원리를 소개하겠다. 이름하여 ‘삼각형의 원리’라고 표현을 하는 것인데 여러분들은 다음에 설명할 내용의 의미를 가슴깊이 새겨 두기 바란다.

[그림1]

위의 그림에 있는 ‘전체 삼각형’은 우리가 하고자 하는 업무의 크기를 의미한다. 우리가 해야 할 업무의 크기에 따라 우리가 만나는 삼각형은 적을 수도, 혹은 매우 클 수도 있다. 그러나 일이 크든 작든 간에 난이도는 항상 동일해지지 않으면 우리가 인간이기 때문에 너무 큰 업무들은 도저히 풀어 낼 수가 없을 것이다.

동일한 난이도를 만드는 원리는 매우 간단하다. 자신의 능력과 수준에 맞는 ‘단위 삼각형’을 먼저 결정하고, 그 높이 만큼 ‘수평선’을 그어 보라. 그리고는 좌.우로 대각선을 그으면 여러 개의 단위 삼각형이 나타난다. 그림에서 알 수 있듯이 이제 우리에게는 전체 삼각형은 없어지고 동일한 크기의 단위 삼각형이 여러 개 생겨났다.

우리는 전체 삼각형의 크기와 상관없이 항상 동일한 단위 삼각형을 만들 수 있으며, 큰 삼각형이라면 단지 단위 삼각형의 개수가 늘어 날 뿐이라는 것을 알 수 있다. 이 단위 삼각형은 우리가 앞으로 풀어 가야 할 ‘독립적인 결정 단위’로써 난이도와 직결된다. 업무의 크기가 커진다고 난이도가 같이 늘어 난다면 경우의 수가 몇가지 되지 않을 때는 시행착오로 풀어낼 수도 있다. 그러나 복잡한 업무에서는 천문학적으로 경우의 수가 늘어 나기 때문에 도저히 불가능한 일이다.

비슷한 예로 여러분들이 슈퍼맨이나 새가 아닌 이상 15층 빌딩을 한 번에 올라 갈 수는 없다. 그렇지만 수평으로 동일한 크기의 계단이 놓여 있으면 얼마든지 올라갈 수 있으며 건물이 높을수록 단지 올라갈 계단이 많아질 뿐인 것이다. 자신의 능력에 따라 20cm, 혹은 50cm로 된 계단을 만들면 된다. 이 말은 능력이 부족하더라도 계단의 높이만 조절한다면 얼마든지 원하는 목표에 도달할 수 있다는 것이다.

문제의 초점은 계단이 이미 놓여 있는 것이 아니라 자신이 놓아가야 한다는 것과 이미 올라 갔던 계단을 다시 내려와서는 안된다는 것이다. 이것이 바로 빌딩을 오를 수 있는 키 포인트이다. 사실 이 원리는 지극히 상식적인 것처럼 보이지만 결코 간단하지만은 않다. 좀더 자세히 살펴보기로 하자.

먼저 자신이 올라갈 수 있는 적절한 크기의 어떤 계단을 놓아야 할 것이냐에 대해 살펴 보기로 하자. 이를 위해서는 가장 먼저 모델링의 구체적인 방법론을 알아야 한다. 그림을 그리는 방법이 아니라 앞으로 여기서 제시할 수사를 하는 방법을 알아야 한다는 뜻이다.

가령, 모델링을 하기 위해서 가장 먼저 해야 할 일이 ‘엔터티 선정’ 단계이다. 그러나 이 목표를 달성하기 위해서는 보다 세부적인 계단이 필요하다. 예를 들어 ‘엔터티 후보 도출’의 단계를 거쳐야 하고, 이어서 ‘후보 엔터티의 분류’, ‘엔터티 의미의 명확화’, ‘엔터티 확정’ 등의 단계를 거쳐야 한다.

‘엔터티 후보 도출’ 단계에서도 ‘엔터티 후보의 개념정립’, ‘관리대상 여부 확인’, ‘집합여부 확인’ 등의 단계가 필요하다. 물론 여기에 대한 자세한 내용 뒤에서 별도로 설명될 것이며, 지금 설명하고자 하는 것은 이러한 방법으로 보다 세부적인 수평선을 그어서 더 작고 구체적인 단계를 만들어야 한다는 것을 예를 들어 설명하는 것이다.

이렇게 해서 생겨난 각 계단(단위 삼각형)을 어떤 객관적인 잣대로 평가해 내어야 확실한 결론으로 도출할 수 있는 지는 매우 중요하다. 앞 장에서 이를 위한 객관적인 ‘판단의 근거’에 대한 중요성을 언급한 적이 있었다. 이러한 판단의 근거는 앞으로 모든 단계의 모델링 과정에서 구체적으로 제시되어 진다.

두번째 문제는 이미 올라갔던 계단을 다시 내려오는 일을 어떻게 방지하느냐가 관건이라는 것이다. 앞의 [그림 1]로 표현한다면, ‘커진 삼각형’으로 표시된 부분을 어떻게 예방할 것인지가 포인트라는 것이다. 결론부터 말하자면 삼각형을 커지지 않게 하는 유일한 방법은 먼저 결론을 내린 단위 삼각형을 반드시 ‘100% 확실’하도록 하는 것이다. 100% 확실하다는 것은 이 결과가 확정값(방정식이라면 상수값)이 되어, 다음 삼각형의 결정 사항에 판단의 기준으로 활용(미지수에 대입)될 수 있으며, 이 결정이 다시 수정될 필요가 없음을 의미한다.

만약 지금 실시하고 있는 단위 삼각형의 판단을 대충하고 내려오는 순간 어떤 일이 벌어지겠는가? [그림 1]의 ‘커진 삼각형’처럼 크게 늘어나 버린다. 왜냐하면, 해당 삼각형에서 정의한 결정이 상위 삼각형의 결정을 변경시키고, 이것이 다시 하위 삼각형들에게 영향을 주게 되므로 우리가 신경을 써야 할 삼각형의 크기는 늘어나 버리는 것이다.

이렇게 모호한 결정이 여러군데 암세포처럼 퍼져 있는 상태로 자꾸만 아래로 내려오면 나중에는 엄청난 크기의 삼각형이 생기게 되므로 난이도는 크게 증가하고 시행착오는 반복된다. 필연적으로 이것은 시간과 노력을 크게 증가시켰음에도 불구하고 언제나 문제의 불씨를 끌어안고 있는 것 같은 불안정한 상태를 만들게 된다.

실전에서는 항상 이런 일이 실제 벌어지고 있다. 프로그램 개발 단계에서 수 많은 컬럼(column)이 추가되고, 새로운 테이블이 생성된다. 얼마 전 필자가 어떤 프로젝트의 개발단계에 컨설팅을 했었는데 강제로 테이블 변경(alter) 커맨드를 막으라고 한 적이 있었다. 한 반나절도 지나지 않아 개발을 진행할 수 없다고 아우성을 치고 있었다. 도대체 설계가 모두 끝나고 개발을 시작한 지가 언제인데 잠시 테이블 변경을 막았다고 해서 개발이 진행되지 않는 것일까?

설계가 끝나고 프로그램 개발하고 있는 과정에 왜 ‘alter table’ 커맨드가 필요한 이유는 설계단계가 대충 진행되다 보니 프로그램에서 구체적인 처리를 할려고 하니 그제서야 문제점과 누락이 발견되기 때문이다. 이것이 우리의 현실이며 과연 자신의 프로젝트는 절대로 그렇지 않다고 항변할 수 있는 곳이 얼마나 될 것인가?

이런 식으로 항상 변해 가기 때문에 위에 있던 것이 아래에 영향을 주고, 밑에 있던 것이 위쪽에 영향을 주기 때문에 업무가 크면 클수록 막바지에 와서 프로젝트는 복잡하게 실타레처럼 엉키게 된다. 불행하게도 이렇게 엉키는 현상을 감지하는 시점이 프로젝트가 70~80% 가야 이제 보이기 시작한다 것에 문제의 심각성이 있다.

처음에는 업무별로 사람별로 분할하여 독자적으로 열심히 앞만 쳐다보고 실적을 채워 나아간다. 이것을 결합을 해 보려면 프로젝트가 약70% 정도 진행되어야 가능하다. 결합 테스트를 해 보면 맞을 리가 있는가? 당연히 문제가 발생되고 이것을 고쳤다, 저것을 고쳤다 할 수 밖에 없다. 문제는 해당되는 것만 고쳐서 되는 것이 아니라 이것을 고치니까 저것이 연쇄 반응을 일으키고, 저것을 고치니까 또 다른 것이 연쇄 반응을 일으키게 된다는 점이다.

사실 문제가 있는 줄 알면서 게을러서? 아니면 인간성이 나쁘기 때문에 그냥 흘러 갔겠는가? 절대로 그것은 아니라고 확신한다. 그렇다면 왜 이러한 문제는 자꾸만 반복되는가? 엄밀히 말하면 그 이유는 다른 곳에 있다.

가장 큰 이유는 바로 자신이 해 놓은 일의 어디가 잘못되었는 지를 모르기 때문이다. 무엇이 잘못인 지를 모르는데 무엇을 보완할 수 있겠는가? 가장 답답한 것은 자신이 모르는 것이 무엇인지 모른다는 것이다.

정보시스템을 하는 사람들은 거의 대부분은 순수하고 꼼꼼하며, 문제해결을 위해 수 많은 밤을 세우는 것쯤은 겁내하지 않는 사람들이다. 단지 어떤 절차와 방법으로 어떻게 해야 제대로 할 수 있는 지를 잘 모르기 때문에 하지 않아도 할 고생을 하고 있다는 편이 맞는 말일 것이라 믿는다. 어디를 어떻게 찔러봐서 어떤 현상이 나오면 어떻게 해야 한다는 것을 정확히 알고 있으면서 문제를 양산할 사람은 없다.

이런 의미에서 문제를 근본적으로 해결해 줄 실전적인 절차와 방법을 매우 구체적으로 제시해 줄 것이다. 여러분들이 지금까지 독자적으로 해 오던 방법을 바꾸기 위해서는 처음에는 얼마간의 고통이 따르겠지만 크게 각오를 다져 탈태환골할 수 있는 기회로 삼을 수 있기를 바라마지 않는다.