프로그래머가 매일 밤 야근하는 이유

working overtime

3.1. 전문가는 객관적인 근거를 가지고 판단한다

우리가 가장 쉽게 접하는 프로그램 개발은 제공되는 분명한 INPUT과 도출해야 할 OUTPUT이 확실히 나타난다. 작성과정에서 자신이 실수한 것은 여러 방법으로 시험되고 증명된다. 처리 프로세스 하나 하나가 모두 분명하고 자신이 무엇을 하고 있는지를 알고 있다. 논리적인 오류나 구문의 실수는 컴파일러가 검증해 주고 다양한 테스트를 통해 자신의 잘못은 명확하게 수정해 갈 수가 있다.

그에 반해 데이터 모델링은 그리 쉽게 자신의 실수를 인식할 수 없다.

온통 불확실한 것 투성이며, 무엇부터 결정해 가야 할지 막연하기 그지없다. 더구나 자신의 판단으로 결정한 것들이 얼마나 완벽한 지도 확인하기 어렵다. 도대체 무엇부터 찾아내어 어디에 초점을 맞추어 결정해 가는 것이 올바른 것인지, 많은 고민을 통해 결정한 것들이 과연 어디가 잘못되었는지, 혹은 몇점 짜리가 되는 지 도무지 알 수가 없다.

어디가 어떻게 잘못되었는지를 구체적으로 안다면 어떻게 해서라도 보완하겠는데 나중에 프로그램 개발 단계나 테스트 단계, 더 심하면 유지, 보수 단계에 가서야 문제점이 나타나니 참으로 답답하기 그지없다. 데이터 모델링을 하는 설계자들이 하나 같이 고민하는 소리가 바로 이렇게 자신의 판단을 확신할 수 없다는 것과 옳은 지, 그른 지를 확인할 수 없다는 것이다.

우리가 학교시절 화학시간에 배웠던 것처럼 리트머스 종이를 담갔을 때 적색이면 ”산성”, 청색이면 ”알카리성”이라는 식의 명확하고 객관적인 잣대가 있다면 얼마나 좋겠는가? 필자가 컨설팅을 수행하면서 어떤 결정을 보고 “어떤 근거로 판단했느냐?”고 물으면 구체적인 답을 하는 사람을 보지 못했다. 대부분의 사람들이 ”원래 그렇게 하는 거 아네요?”라고 막연한 반문을 하거나, 혹은 “이게 좋다고 하던데요?” “우리는 지금까지 항상 이렇게 해 왔는데요.”라는 말들이 나온다.

참으로 딱한 일이다.

분명한 판단의 근거를 가지고 복잡한 현실 요소들을 완벽하게 분석하여 전략적인 판단을 했더라도 전혀 예상하지 못한 변화로 문제를 일으킬 수 있는 것이 현실이다. 그럼에도 불구하고 무엇을 찔러보아야 할 지 조차 모르면서 겁(?)없는 결정을 계속해 갈 수 있다는 것은 참으로 대단한 용기(?)가 아닐 수 없다.

모델링 또한 프로그래밍 못지않게 객관화가 가능하다. 그렇지 않고 행해지는 수많은 결정들은 사상누각에 불과하다. 모델링에서 누구나 인정할 수 있는 객관화는 분명히 가능하다. 앞으로 우리는 모든 부분에 있어서 이러한 객관적인 판단을 할 수 있는 근거를 발견하게 될 것이다.

앞으로 모델링의 구체적인 과정이 진행되면서 필자는 상당히 많은 질문을 여러분에게 던지게 될 것이다.

강의를 하면서 이러한 문제를 던져보면 항상 모호한 답변밖에 안 나오며 언제나 대답이 여러 종류로 나누어진다.

가령 예를 들면, “저기 길거리를 지나고 있는 사람들과 우리와는 관계가 있느냐” 는 질문에 있다는 사람, 없다는 사람, 어떤 대답을 할 지 몰라 망설이는 사람, 이렇게 항상 세 종류의 사람이 있다.

또 한 가지 예를 더 들어 보자. “우리 할아버지와 나는 관계가 있느냐”라고 불어 보자. 독자 여러분들도 테스트를 해 보자. 할아버지하고 나하고 관계가 있다? 없다? 잘 모르겠다? 여러분은 어느 쪽이었는가? 어떻게 생각하면 매우 주관적일 수밖에 없는 이러한 상황을 누구도 아니라고 할 수 없는 객관적인 사실로 만들 수 있을 것인가? 다시 말해서 아니라고 말하는 순간, 그 사람은 바로 바보가 되어 버리도록 하는 객관화를 할 수 있는 방법은 무엇인가?

방금 필자가 던진 질문에 대한 해답은 나중에 설명하기로 하겠다. 여기서 미리 답을 주지 않는 것은 여러분들을 궁금하게 하기 위해서 그렇게 하는 것이다. 모델링은 모든 과정을 객관화 시킬 수 있는 수단을 찾지 않으면, 자신이 애써 결정한 것들이 물거품이 되고 만다. 그렇게 되지 않으려면 모든 부분에 있어서 누구도 꼼짝 못하게 하는 객관화를 시킬 수 있는 근거를 세우고 여기서 나오는 힘을 자신의 것으로 만드는 방법이 가장 중요하다.

4.2. 정확한 이유와 근거를 가지고 판단하는 힘을 길러라

시중에는 수많은 모델링 관련 서적과 강좌가 나와 있다. 이들의 대부분은 ERD를 작도하는 방법을 가르치고 있다. 다시 말해서 그림을 그리는 방법을 교육시킨다는 것이며 이것은 분명히 잘못된 것이다.

모델링이라는 것은 인간의 사고를 통한 판단력으로 해 나가는 것이다. 그렇다면 판단하는 근거와 사고의 원리를 배우는 것이 무엇보다 중요하며, 그림을 그리는 방법만 익혀서는 아무 것도 제대로 할 수가 없는 것이다.

우리가 속성 하나를 결정하는 데도 분명한 판단의 기준이 있다. 예를 들어 누구나 알 수 있는 ”성명”을 ”성”과 ”명”이 각각 속성인지 결합한 것이 속성인 지를 물어보면 각자 대답이 다르다. 설계 시에 언제나 고민의 대상이 되는 ”일자”를 년, 월, 일로 구분한 것이 속성인지, 결합한 것이 속성인지 판단해 보라. 결정했다면 그 판단의 근거가 무엇인가?

정확한 이유와 근거를 가지고 판단할 수 있는 힘이 있다면 자신의 판단한 결정이 윤동주님의 시처럼 하늘을 우러러 한 점 부끄럼이 없도록 할 수 있을 것이다.

이와 같이 완벽하게 처리하였다고 하더라도 언제라도 변할 수 있는 것이 바로 정보시스템 의 세계이므로 우리가 해야 할 판단이 얼마나 어렵고 힘든 것이며, 얼마나 중요한 것인지를 명심해야 할 것이다.

업무는 살아 있는 생명체와 같아서 수많은 변화를 필연적으로 수반한다. 그 변화에 적절한 대응을 하지 못하면 매일 저녁 밤을 새워서 고생을 하지만 앞으로 못 나가고, 뒤에 남아서 지난 일의 구멍 난 곳을 때우는데 아까운 시간을 다 써버리는 이런 불행한 일이 자꾸만 일어나게 된다.

앞으로 여러분에게는 수많은 객관화 방법이 구체적으로 소개될 것이다. 이러한 객관화 방법을 완벽히 이해하여 여러분의 귀중한 판단에 활용한다면, 이제 더 이상 자신의 결정에 불안해하지 않게 될 것이며, 발생할 수많은 시행착오가 줄어들게 될 것이라 확신한다.

4.3. 프로그래머가 매일 야근하는 이유

거의 대부분의 정보시스템 프로젝트는 한결같이 밤늦게까지 고생을 하고 있다. 겉으로는 주로 프로그램의 문제처럼 보이지만 자세히 살펴보면 그 근본적인 원인으로 설계상의 문제가 가장 크다는데 문제가 있다. 단지 프로그램의 오류였다면 설사 문제가 있더라도 그렇게 오래 동안 고생하지 않아도 충분히 해결 가능하다.

그러나 데이터 모델에 문제가 발생했다면, 문제의 차원은 달라진다. 만약 건물은 이미 거의 다 세워졌는데 설계도를 바꿔 버린다면, 건물의 상당 부분을 무너뜨리고 새로 엄청난 보수공사를 해야 한다고 생각해 보라. 이와 마찬가지로 개발이 상당히 진척된 상황에서 데이터 모델에 변경이 일어난다면 그 심각성은 이에 못지않을 것이다.

프로그램은 얼마든지 바꿔 버릴 수 있지만, 설계를 바꾼다는 것은 매우 심각하고 중차대한 일이다.

프로젝트가 일정에 맞추어 순조롭게 진행되는 듯하다가 어느 순간에서부터 계속해서 엉켜버리는 현상이 많은 프로젝트에서 나타나고 있다. 프로젝트 막바지에 이르면 이러한 현상은 더욱 심해져 밥 먹듯이 밤을 지새우는 경우가 많이 있다.

필자는 지금까지 컨설팅을 수행해 오면서 거의 150개 정도의 프로젝트를 경험했다. 정말 각양각색의 업무와 다양한 문제들이 있었다. 사실 우리를 요청할 정도가 되면 보통 심한 정도가 아니다, 데이터가 매우 많거나, 아니면 매우 복잡하거나, 아니면 매우 많은 문제가 섞여 있거나 하는 심각한 경우가 많았다. 병원으로 말하면 외과 수술에 해당하는 상황이 대부분이었고, 거기에는 항상 심각한 설계상의 문제가 있었다.

실전에서 설계를 하는 사람은 대부분 경력이 많은 고참이고, 프로그램을 작성하는 사람은 경력이 상대적으로 적은 신참이다 보니 문제가 있어도 쉽게 불만을 가질 수 없다.

차라리 자신이 프로그램에 한번 더 복잡한 처리를 하는 것이 속이 편하다고 생각한다. 고참인 설계자들이 정말 제대로 알고 하는 것이 아니라 자신들이 과거에 해 왔던 막연한 생각, 예를 들면 ”이렇게 하는 것이 좋더라”, ”저렇게 해 보니까 좋더라”하는 식의 경험적인 기준으로 판단을 하는데 앞으로 모델링에 대해서 자세히 알아보면서 충분히 느끼겠지만 그렇게 대충 결정해서 제대로 될 리가 없다.

이렇게 해서 나타나는 문제점은 대부분 프로그램을 통해 무마된다. 다시 말해서 데이터가 투명하지 않기 때문에, 프로그램이라는 요리과정을 통해 거기서 씻어 내고, 양념치고, 조미료를 첨부해야 겨우 먹을 수 있다는 말이다. 이런 형태로의 진행은 프로그램을 작성하는 사람들이 많은 고생을 하게 되고, 헛된 시간을 소비하게 되어 보다 나은 시스템을 구축하고, 보다 나은 요소기술을 습득해야 할 시간을 뒷처리하는데 다 써 버린다.

항상 발등에 불이 떨어져 있으니 언제나 바쁘게 일하지만 노력에 비해 자신의 실력 향상은 아주 미미하다. 이렇게 세월이 흐르면서 어느덧 자꾸만 지쳐가고, 잔재주만 늘어가면서 설계자 역할을 담당하게 되니 또 다시 이러한 빈곤의 악순환은 계속되어 진다. 이것이 우리의 적나라한 현실이 아닌가?

4.4. 단순하고 유연한 데이터 모델

데이터 모델은 곧 프로그램이라는 시각에서 데이터를 투명하게 해야 한다. 그리고 단순, 명료하게 해야 한다. 과거에는 대부분을 처리를 자신이 직접 로직을 만들어야 했지만 이제는 그렇게 해서는 안 된다. 관계형 데이터베이스나 많은 개발 툴들이 상당한 부분에 대해 인간의 역할을 대신해 주고 있다. 우리가 보다 쉽게 많은 일을 하려면 모든 것을 자신이 직접 다 하겠다는 생각부터 버려야 한다. 기계가 대신해 줄 수 있는 일을 하는 사람은 그만큼 고달프고 하위 계층을 벗어나기 힘들다.

그러나 DBMS나 개발 툴은 인간만큼 다양하고 복잡한 일을 하지 못한다. 그것들은 단순하고 규칙이 분명한 것들을 반복해서 하는 것에 장점을 가지고 있을 뿐이다. 다시 말해서 복잡하면 원래의 기능을 제대로 발휘할 수가 없게 된다는 것이다. 예를 들어 여러분들이 SQL을 쓰면서 OR를 함부로 사용하면 옵티마이저가 전체 데이터를 모두 스캔해 버린다.

시스템이 복잡해진다고 해서 “사장님! 좀 회사 일을 단순하게 합시다”라고 할 수도 없는 노릇이다.

복잡한 것을 어떻게 단순하게 풀어내는 것 바로 이것이 기술이다. 설계가 복잡하면 이미 단순화란 있을 수 없다. 예를 들어 아주 값비싼 고급차의 엔진실을 열어 보면 실제 기능은 훨씬 많이 가지고 있지만 외형적으로는 아주 단순하게 되어 있다. 그러나 값싼 차의 엔진실은 기능이 적으면서도 엄청나게 복잡하게 되어 있음을 알 수 있다.

이와 같이 훨씬 더 복잡하더라도 오히려 단순하게 만들 수 있는 것이 기술이고 그래야 값비싼 고급이 될 수 있으며, 바로 이것은 설계기술에서 비롯되는 것이다. 이러한 단순화로 우리가 얻을 수 있는 것은 아주 많이 있다. 이렇게 되어야만 DBMS나 툴의 지원을 많이 받을 수 있고, 쉽게 변경할 수 있으며, 수행속도 또한 현격히 빨라진다는 것이다. 필자는 ”대용량 데이터베이스 솔루션 I,II”를 통해서 이와 같은 부분에 대해 많은 증거들을 보여 주었다.

설계를 단순화 시키라는 말은 참으로 광범위한 말이다. 그러나 앞으로 진행될 모델링의 세부적인 각 단계에서는 이에 대한 상세한 예를 들어 가면서 많은 설명이 구체적으로 언급될 것이다.