프로그래머는 어째서 방어적 입장을 취하는 것일까요?

종종 이런 이야기를 듣습니다. "프로그래머는 너무 방어적으로 일을 하는 것 같다." 라는 말이죠.

어떤 의미일까요? 예를 들어서 소프트웨어 개발 회사에서 어떤 프로젝트를 진행을 할때 그 프로젝트의 목표를 구현 하는 일을 소위 기획이라고 합니다. 기획자들은 충분한 시간을 가지고 이 프로젝트의 진행 목적 부터 진행 중간 단계의 표현, 기능 들에 대해서 진지하게 고민합니다. 그렇게 해서 (예제로써) 약 버스를 만들기로 했습니다.

그리고 이것에 대한 내용과 스케쥴을 기획서에 작성을 해서 그 기획서를 들고 프로그래밍 조직으로 찾아가서 이야기 합니다. "이것을 언제까지 만들어주세요." 그러면 프로그래머는 기획서를 쭉 살펴보고 기획서가 너무 부실하다고 생각합니다. 기획서에 써 있는 것들이 어떤 목적으로 구현이 되는 것인지, 그리고 또 어떠한 내용인지 확실히 알 수가 없습니다. (물론 아닌 경우도 있습니다.) 그리고 이것 저것 하나씩 묻기 시작하고, 실제 구현 방법에 대해서 하나씩 생각을 해보기 시작하고 나서 대부분은 이렇게 말합니다. "그때까지는 힘들겠는데요.."  라는 말과 함께 협상을 시작합니다.

그리고 프로그래머는 구현해야 하는 기능 중에서 구현이 애매 모호하거나 시간이 오래 걸릴 것 같은 기능들을 구현이 편한 방향으로 변경을 시도합니다. 때로는 이것은 기획자의 의도와는 좀 다른 방향으로의 결과물을 불러오기는 합니다만 이미 대부분의 상황에서 기획자와 프로그래머는 "협상" 단계에 들어가 있기 때문에 기획자도 그것을 받아 들입니다.
그렇게 해서 최초 목표였던 버스는 승합차가 되어 돌아오게 됩니다. 그리고 그것은 출시 됩니다.

지난 몇년간 게임 회사에서 일 하면서 경험하고, 봐왔던 현상입니다. 기존에 다른 회사에서 일 했던 경험을 바탕으로 한다면 다른 회사 역시 대부분은 저런 흐름을 비일비재하게 겪고 있을 것 같습니다.

프로그래머들은 어째서 저런 방어적 입장을 취하는 것일까요?

공식적인 이유로는 이러한 이유들이 있습니다.

1) 기획자가 정말 무리한 일정을 가지고 온 경우, 2) 일정을 아무리 길게 잡아도 아에 불가능한 것을 요구 하는 경우. (예를 들어 기존에 사용 하고 있던 코볼의 코드를 C#으로 완벽하게 포팅 해주는 프로그램을 만들어 주세요. 와 같은), 3) 나의 일을 줄이기 위해서.  4) 기타.. 어떤 것들이 있을까요?

... 어떤 이유일까요? 사실 이런 이유는 중요한게 아닙니다. 위에서 말한 어떤 이유라고 하더라도 그것은 사실상 개별적 해결이 불가능 하기 때문입니다.

저는.. 이런 일이 발생 하는 이유가 바로 '협상' 단계가 생길 수 밖에 없는 업무 흐름 때문일 거라는 생각이 듭니다. 완전한 갑을 관계에서는 '협상' 따위는 없겠죠. (경우에 따라서는 아주 조금 있을지도 모르지만-_-) 그렇다고 해서 갑을 관계를 형성 하라는 것은 아닙니다. 같은 회사안의 조직이기 때문에 그렇게 해봐야 조직간의 분열을 더 초례 할 뿐입니다.

그렇다면 이렇게 해보는건 어떨까요?

기획자는 처음에 기획을 구상 하는 단계에서 이것의 간단한 '목표' 만을 설정합니다. 그리고 기획 회의를 진행할때 실무자 또는 실무자에게 충분한 영향을 줄 수 있는 사람을 함께 하는 겁니다.

뭐야 이게? 라고 생각하는 분들도 있을 것 같습니다만, 실제 기획을 구체화 시킬때 실제 구현자인 프로그래머가 참석해서 함께 회의를 진행한다면 '협상' 단계 따위는 오지 않습니다. 네, 물론 그 '협상' 단계가 기획 회의에서 이루어지게 됩니다. 하지만, 그 수준이 명확하게 다릅니다. 왜냐하면, 기획 회의에서는 간단한 목표만 정해져 있을뿐, 이것의 정확한 기획 결정이 이루어지기 전이기 때문입니다.

기획 회의에 프로그래머가 참여를 한다면 프로그래머는 그 기획 회의에서 내가 어떻게 방어적 입장을 취할까를 고민하지 않습니다. 말 그대로 기술적인 지식을 바탕으로 그 기획에 함께 참여하게 됩니다. 또한 기획 회의에서는 해당 작업을 해야 하는 목적 등에 대한 고민이 이루어지므로 기획서에서는 그냥 지나치는 (또는 아에 나와 있지 않은) 작업의 목적(사실상 동기)를 프로그래머와 함께 공유 할 수 있게 됩니다. 이것은 프로그래머에게 기존의 방식 보다는 조금 더 주인의식(?)을 부여 할 수 있는 방법이 아닐까 싶습니다. 실제 프로그래머들을 참석 시킬 경우 기획자가 생각하지 못하는 기술적인 지식을 이용한 좋은 방향이나 아이디어가 나오기도 합니다. 손해 볼건 없다는거죠.

또한, 프로그래머가 참여 하므로 애시당초 불가능한 기능에 대해서는 기획 회의에서 충분히 걸러 질 수 있습니다. 그리고 결정 되어지는 것들에 대하여 그 자리에서 프로그래머와 함께 스케쥴 임시 계산이 가능하므로 스케쥴 문제 역시 크게 해결 할 수 있습니다. 어차피 스케쥴 협상을 할 거라면 회의 단계에서 미리 하는데 시간을 아끼는 방법이기도 하죠.

그냥 단지 프로그래머가 기획 회의에 참여 하는 것만으로 기존의 '협상' 단계를 없애거나 최소화가 가능해지지 않을까요?

네.

뭐 그냥 그렇다구요.