소프트웨어를 개발하다보면 개발자 입장에서, 또는 설계자 입장에서 의사 결정이 필요한 문제들이 매순간 찾아온다. 그 결정의 순간은 사실 개발 초기부터 시작된다. '이거, 할까?'
문제의 종류는 다양하다. 문제의 결정은 프로젝트에 심각한 영향을 초래할 수도 있고 그렇지 않을 수도 있다. 보통 프로젝트에 심각한 영향을 초래하는 문제는 개발자가 직접 다루는 일이 드물다. 예를 들어 프로젝트의 진행 여부를 결정하는 것은 개발자가 아닌 프로젝트 관리자 쯤에서 결정하는 것이 보통이다. 물론 개인적인 프로젝트의 경우라면 개발자가 결정하겠지만 보통 이런 경우는 답이 정해져 있다.
오늘은 개발 과정에서 개발자에게 일어나는 의사 결정에 대해 이야기하고자 한다. 개발자라고해서 그렇게 대단한 사람을 지칭하는 것은 아니다. 논란의 여지가 분분하겠지만 그건 내 알바 아니니 이 글에서 개발자는 나름대로 설계도 하고 코딩도 하는 나같은 찌질이를 말한다.
무엇이 문제인가?
의사 결정의 순간 가장 중요한 것은 결정하려는 문제가 무엇인지 분명히 파악하는 것이 중요하다. 무엇을 하려고 하는 것인지, 그것을 왜 해야 하는 것인지, 그것을 함에 있어 제약 조건은 어떤 것들이 있는지 파악해야 한다. 따라서 결정의 순간 가장 처음 할 일은 문제를 정확히 파악하는 것이다.
* 무엇이 문제인가?
* 왜 문제가 되는가?
* 시급한 일인가?
* 중요한 일인가?
* 이 문제로 인해 영향을 받는 다른 영역이 존재하는가?
* 존재한다면 어떤 영향을 미치는가?
* 이 문제에 제약 조건이 있는가?
문제를 파악함에 가장 소홀한 부분은 그것이 정말 중요한 문제인지 판단하는 것이다. 개발자는 일단 문제에 봉착하면 그것을 무조건 중요한 문제로 받아들인다. 담배 한 대 피우고 동료들과 노가리를 까라. 단, 지금 발생한 문제를 머릿속에서 완전히 지워라. 그리고 나서 그 문제를 다시 보라. 자, 이것이 정말 중요한 문제였던가? (내 경우 대부분은 정말 대수롭지 않은 문제였었다!)
중요한 문제인가를 판단하기 어렵다면 그 문제가 다른 영역에 어떠한 영향을 끼지는지 분석해보면 좀 더 명확해 진다. 만약 그 문제가 그 부분에서만 영향을 끼친다면 대부분은 중요하지 않은 문제이다. 개발자의 똘끼가 발동했을 뿐 프로젝트 자체에 커다란 영향을 끼치지 않는 문제라는 것이다. 이런 문제에 많은 시간을 들여서 고민할 필요가 없다. 작은 문제에 시간을 쏟아 붓다간 정작 심각한 문제에 봉착했을 때 '하루만 더 있었으면!' 하고 외치는 바보를 발견할 수 있을 것이다.
중요하지 않은 문제는 일단 어딘가 적어놓고 제쳐라. 저는 이 문제를 당장 어떻게 하지 않으면 일이 손에 잡히지 않아요! 당신의 이런 점이 스스로는 매력이라고 말하겠지만, 그런 당신을 바라보는 동료들은 한숨을 내쉰다. 변명은 필요 없다. 제쳐라! 왜냐하면 중요하지 않은 문제에 많은 노력을 기울여 완벽하게 해결하더라도 그것보다 더 큰 문제가 답이라고 여겼던 이전의 결정을 송두리째 날려버릴 수 있기 때문이다.
그러므로 중요한 문제를 먼저 해결하라. 중요한 문제는 해결 과정에서 정책과도 같은 결정을 내리기 마련이다. 이 정책은 자잘한 문제들의 제약 조건이 된다. 제약 조건은 보기가 다섯개짜리인 문제를 세개짜리로 줄여준다. 당신의 고민거리를 줄여주는 셈이다! (보기 다섯개짜리와 세개짜리인 문제에서 각각 생각할 수 있는 경우의 수를 굳이 비교하지 않아도 그 차이가 얼마나 큰지 이해하리라 믿는다) 만약 중요한 문제를 결정하기도 전에 중요하지 않은 문제에 대해 이미 4번을 선택했다면 괜한 고집으로 4번을 고집하지 말고 과감히 다시 결정하라. 괜한 고집은 4번을 포함하도록 중요한 문제의 결정을 수정하려 들 것이다. 너무나 당연한 이야기처럼 들리겠지만 사실 개발자 대부분은 엄청난 고집쟁이이므로 이런 실수를 아무렇지도 않게 범하고 있다.
어떻게 해야 하는가?
답은 다 말했다. 문제를 정확히 분석하고 중요한 문제부터 풀어라. 괜한 뻘짓으로 나중에 고생하는 일이 없도록 노력하라. 그러기 위해서는 문제를 정확히! 분석할 수 있어야 한다. 지금부터라도 노력하라. 사소한 문제라도 문제 노트같은 것을 만들어서 필요한 항목을 모두 서술하라. 이러한 과정이 몸에 베어있지 않는 상황에서 당신이 선택한 답안지는 글쎄... 이미 경험해서 알고있지 않은가?
문제의 종류는 다양하다. 문제의 결정은 프로젝트에 심각한 영향을 초래할 수도 있고 그렇지 않을 수도 있다. 보통 프로젝트에 심각한 영향을 초래하는 문제는 개발자가 직접 다루는 일이 드물다. 예를 들어 프로젝트의 진행 여부를 결정하는 것은 개발자가 아닌 프로젝트 관리자 쯤에서 결정하는 것이 보통이다. 물론 개인적인 프로젝트의 경우라면 개발자가 결정하겠지만 보통 이런 경우는 답이 정해져 있다.
오늘은 개발 과정에서 개발자에게 일어나는 의사 결정에 대해 이야기하고자 한다. 개발자라고해서 그렇게 대단한 사람을 지칭하는 것은 아니다. 논란의 여지가 분분하겠지만 그건 내 알바 아니니 이 글에서 개발자는 나름대로 설계도 하고 코딩도 하는 나같은 찌질이를 말한다.
나는 굉장히 쫌생이다. 코드마다 알맞은 탭으로 줄이 잘 맞아있지 않으면 짜증부터 낸다. 심지어는 멤버 변수를 선언할 때 타입과 변수 이름 사이에 탭을 두어서 그 사이에서도 줄을 맞추고 있다. 날마다 신경이 날카로운 것은 다 이유가 있는 거다.
이러한 쫌생이 기질은 의사 결정 순간에 늘 방해가 된다. 의사 결정이 신중해야 한다는 것은 부정할 수 없다. 그러나 신중이라는 단어를 어떻게 이해하고 있는가가 문제가 된다. 어떤 기능을 하는 단위 조각을 설계한다고 생각해보자. 나는 그 기능을 정의하고 그 기능을 수행하기위해 필요한 객체들을 모은다. 이미 존재하는 객체는 설계하려는 객체에 연관을 짓고, 새로 만들어야하는 객체는 객체의 멤버와 기능을 설계한다. 그런데 항상 이 순간 고민의 늪, 그것도 아주 깊은 고민의 늪에 빠진다.
그날의 결정은 기능 F를 객체 B에 구현하는 것으로 마무리 지었다. 그리고 구현을 시작한다. 구현을 하는 도중에 계속 뒤가 캥긴다.
결국 구현 중간에 설계를 고친다. 이제 기능 F는 객체 A에 있다. 그러나 얼마 못가서 문제가 발생한다. 객체 B가 기능 F를 수행할 수가 없다. 이런...
후... 끝도 없다. 재미있는 사실은 이러한 의사 결정이 쳇바퀴 돌 듯 되풀이된다는 것이다. 기능 F는 어느날 객체 A에 있다가 어느날 객체 B로 이사를 갔다가 쥐도 새도 모르게 다시 객체 A로 돌아오기를 반복한다. 하나가 신경 쓰이면 다른 부분에 신경 쓸 여력이 없다. 이게 해결이 되어야 다른 부분이 제대로 구현될거야라고 나는 생각한다.
이러한 쫌생이 기질은 의사 결정 순간에 늘 방해가 된다. 의사 결정이 신중해야 한다는 것은 부정할 수 없다. 그러나 신중이라는 단어를 어떻게 이해하고 있는가가 문제가 된다. 어떤 기능을 하는 단위 조각을 설계한다고 생각해보자. 나는 그 기능을 정의하고 그 기능을 수행하기위해 필요한 객체들을 모은다. 이미 존재하는 객체는 설계하려는 객체에 연관을 짓고, 새로 만들어야하는 객체는 객체의 멤버와 기능을 설계한다. 그런데 항상 이 순간 고민의 늪, 그것도 아주 깊은 고민의 늪에 빠진다.
"기능 F는 의미상 객체 A에 있어야할 것 같은데 구현을 생각해보면 객체 B에 있어야 할 것 같아."
그날의 결정은 기능 F를 객체 B에 구현하는 것으로 마무리 지었다. 그리고 구현을 시작한다. 구현을 하는 도중에 계속 뒤가 캥긴다.
"아무리 봐도 의미상으로는 객체 A에 있어야 할 것 같아."
결국 구현 중간에 설계를 고친다. 이제 기능 F는 객체 A에 있다. 그러나 얼마 못가서 문제가 발생한다. 객체 B가 기능 F를 수행할 수가 없다. 이런...
"인터페이스로 기능 F만 쓸 수 있게 빼 내어서 객체 B에게 전달할까?"
후... 끝도 없다. 재미있는 사실은 이러한 의사 결정이 쳇바퀴 돌 듯 되풀이된다는 것이다. 기능 F는 어느날 객체 A에 있다가 어느날 객체 B로 이사를 갔다가 쥐도 새도 모르게 다시 객체 A로 돌아오기를 반복한다. 하나가 신경 쓰이면 다른 부분에 신경 쓸 여력이 없다. 이게 해결이 되어야 다른 부분이 제대로 구현될거야라고 나는 생각한다.
무엇이 문제인가?
의사 결정의 순간 가장 중요한 것은 결정하려는 문제가 무엇인지 분명히 파악하는 것이 중요하다. 무엇을 하려고 하는 것인지, 그것을 왜 해야 하는 것인지, 그것을 함에 있어 제약 조건은 어떤 것들이 있는지 파악해야 한다. 따라서 결정의 순간 가장 처음 할 일은 문제를 정확히 파악하는 것이다.
* 무엇이 문제인가?
* 왜 문제가 되는가?
* 시급한 일인가?
* 중요한 일인가?
* 이 문제로 인해 영향을 받는 다른 영역이 존재하는가?
* 존재한다면 어떤 영향을 미치는가?
* 이 문제에 제약 조건이 있는가?
문제를 파악함에 가장 소홀한 부분은 그것이 정말 중요한 문제인지 판단하는 것이다. 개발자는 일단 문제에 봉착하면 그것을 무조건 중요한 문제로 받아들인다. 담배 한 대 피우고 동료들과 노가리를 까라. 단, 지금 발생한 문제를 머릿속에서 완전히 지워라. 그리고 나서 그 문제를 다시 보라. 자, 이것이 정말 중요한 문제였던가? (내 경우 대부분은 정말 대수롭지 않은 문제였었다!)
중요한 문제인가를 판단하기 어렵다면 그 문제가 다른 영역에 어떠한 영향을 끼지는지 분석해보면 좀 더 명확해 진다. 만약 그 문제가 그 부분에서만 영향을 끼친다면 대부분은 중요하지 않은 문제이다. 개발자의 똘끼가 발동했을 뿐 프로젝트 자체에 커다란 영향을 끼치지 않는 문제라는 것이다. 이런 문제에 많은 시간을 들여서 고민할 필요가 없다. 작은 문제에 시간을 쏟아 붓다간 정작 심각한 문제에 봉착했을 때 '하루만 더 있었으면!' 하고 외치는 바보를 발견할 수 있을 것이다.
중요하지 않은 문제는 일단 어딘가 적어놓고 제쳐라. 저는 이 문제를 당장 어떻게 하지 않으면 일이 손에 잡히지 않아요! 당신의 이런 점이 스스로는 매력이라고 말하겠지만, 그런 당신을 바라보는 동료들은 한숨을 내쉰다. 변명은 필요 없다. 제쳐라! 왜냐하면 중요하지 않은 문제에 많은 노력을 기울여 완벽하게 해결하더라도 그것보다 더 큰 문제가 답이라고 여겼던 이전의 결정을 송두리째 날려버릴 수 있기 때문이다.
그러므로 중요한 문제를 먼저 해결하라. 중요한 문제는 해결 과정에서 정책과도 같은 결정을 내리기 마련이다. 이 정책은 자잘한 문제들의 제약 조건이 된다. 제약 조건은 보기가 다섯개짜리인 문제를 세개짜리로 줄여준다. 당신의 고민거리를 줄여주는 셈이다! (보기 다섯개짜리와 세개짜리인 문제에서 각각 생각할 수 있는 경우의 수를 굳이 비교하지 않아도 그 차이가 얼마나 큰지 이해하리라 믿는다) 만약 중요한 문제를 결정하기도 전에 중요하지 않은 문제에 대해 이미 4번을 선택했다면 괜한 고집으로 4번을 고집하지 말고 과감히 다시 결정하라. 괜한 고집은 4번을 포함하도록 중요한 문제의 결정을 수정하려 들 것이다. 너무나 당연한 이야기처럼 들리겠지만 사실 개발자 대부분은 엄청난 고집쟁이이므로 이런 실수를 아무렇지도 않게 범하고 있다.
어떻게 해야 하는가?
답은 다 말했다. 문제를 정확히 분석하고 중요한 문제부터 풀어라. 괜한 뻘짓으로 나중에 고생하는 일이 없도록 노력하라. 그러기 위해서는 문제를 정확히! 분석할 수 있어야 한다. 지금부터라도 노력하라. 사소한 문제라도 문제 노트같은 것을 만들어서 필요한 항목을 모두 서술하라. 이러한 과정이 몸에 베어있지 않는 상황에서 당신이 선택한 답안지는 글쎄... 이미 경험해서 알고있지 않은가?
이 글의 트랙백 주소는 http://semix2.tistory.com/trackback/241 입니다
