오랜만입니다. ;ㅅ; 대체 이넘의 오랜만이라는 소릴 좀 그만했으면 좋겠군요. (근데 뭐, 금방 그만 할 겁니다. 앞으로 될 수 있으면 계속 글을 쓸 껍니다. ;ㅅ;
오랜만의 글이 반면교사인 것에 대해서도 여러모로 좀 고민이 있던 것이지만… 이건 좀 제가 고민에 고민을 거쳐서 쓰는 글이군요. 근데 좀 글의 구성이 거칠거나 할 수 있으니 일단 양해 먼저 부탁드립니다.
개발을 하는 환경이 자기 혼자서 모든 것을 다 해야 하는 것이 아닌 이상, 개발자와 관리자(프로젝트 매니저)의 관계는 항상 존재하게 되어있습니다. 거기에 더 해도 같은 개발자가 더 있거나 디자이너, QA 등 여럿이 있지만 해당 프로젝트를 개발하는 개발자와 그 프로젝트를 책임지고 확인하고 관리하는 관리자는 항상 존재하게 되죠.
개발자와 관리자는… 서로 협력하거나 서로 싸우거나입니다만…. 여러모로 학 떼는 일들 많이 보는 관계가 됩니다. 그러면서 신뢰가 쌓이는 것도 있고 그렇습니다만….
관리자의 입장에서 개발자를 어떻게 대하느냐에 따라서도 여러모로 차이가 나는 일들이 생기기도 합니다. 관리자도 일단 기본적으로 프로그래밍을 어느 정도 해본 사람일 것이고(아예 안해본 경우도 있긴 합니다만… 그건 걍 답이 없습니다.), 그러다 보면 이 개발자가 어떤 수준의 개발자이고 어떤 성격의 개발자인지도 파악이 되는데, 여기서 이제 문제점이 생길 수 있는 길이 열립니다.
관리를 너무 빡빡하게 할 경우에는 개발자들이 숨쉬기 힘들어집니다. 관리자의 명령대로 움직여줘야 하는데 그러한 것에서 여러모로 문제가 생기게 되면 그땐 그냥 싸움의 연속이 될 수 있기 때문이죠. 팀 깨지는 거 쉽습니다. 게다가 개발 경험따윈 하나도 없는 녀석이 관리자일 경우…. 진짜 머리 아픕니다. 개발에 대해서 쥐뿔도 모르고 그냥 키보드 다닥거리면 그냥 완성되는 줄만 아니깐 그냥 일을 막 내리고 왜 안되었냐고 매일매일 갈구고 체크당하고 그러면 개발자들 스트레스 장난 아니게 받습니다. 진짜 회사 때려치고 싶어지게 되죠. 그러다가 도중에 문제 생기면 그냥 책임론으로 싸우기 쉽습니다.
그러다 보니 개발자 출신의 관리자들 사이에서는 개발자들을 믿고 그냥 맡기는 걸 최고라고 생각하는 관리자급이 많이 존재합니다. 특히 개발 좀 해봐서 안다는 그런 사람들 중에서(아마 한국에는 지금의 40 중반대~50 초반대의 팀장님들 중에 생길 가능성 높습니다.) 자기 팀의 개발자 또한 어느 정도 실력있어 보인다고 생각할 경우에 이런 경우가 상당히 생기는데… 이때 생각 잘못하면 진짜 피봅니다. 차라리 관리를 빡빡하게 해달라고 하는 게 더 좋을 정도입니다.
좋은 예를 들면 바로 저와 오씨의 경우입니다. 저도 좀 여러모로 많~~이 방치되어 있었고, 아마 오씨의 경우에도 엄청나게 방치되어 있었을 것입니다. (이 회사가 여러머로 사람 놀리는 일을 다방면으로 하다보니 회사에 개발자 혼자 덜렁 남는 경우가 좀 생기는 그런 회사입니다.) 개발자가 방치가 되어 있을 때, 좋은 점과 나쁜 점이 있습니다. 좋은 점은 자신이 해야 할 일이 명확하게 있을 경우에는 아무 방해 없이 자기 업무 스타일대로 개발을 할 수 있다는 점입니다. 이건 여러모로 좋은 점이죠. 개발하는 분들 잘 아실 겁니다. 나쁜 점은 해당하는 일이 다 끝났을 때입니다. 이때에 자기 권한 밖의 일을 끌어와서 일을 하느냐 마느냐의 기로에 설 수 있습니다. 아니 설껍니다.
이때, 저와 오씨의 일 처리 차이가 발생하였습니다. 전 무조건 제 위에 팀장을 불러서 일을 만들어냈습니다. 제 밑에 사람들을 이용해서 제가 만든 프로그램에 대한 테스트 또한 부탁을 하였죠. 이렇게 해서 제 권한과 제 위에 팀장의 권한을 잘 이용하여 여러모로 일을 진행할 수 있게 했습니다. 가끔 바빠서 이분들이 안계실 경우에는 좀 놀고 그랬습니다만 워낙 TODO 리스트를 미친듯 받아놓고 시작했기 때문에 여분의 공백이 있더라도 다음 일을 할 수 있도록 스스로에 대한 관리를 진행하였죠.
문제는 오씨의 경우였습니다. 이분은 팀장이 자리에 없거나 팀장이 있더라도 일을 진행할 생각이 별로 없었습니다. 초반에는 저처럼 했다고들 하더군요. 근데 도중부터는 그냥 사람들 없으면 일을 안했다고 하네요. 그러다보니 진행사항에 대한 것도 제대로 확인도 안되고, 일도 얼마나 했는지도 모르고, 그냥 개발자가 보고해야 하는대로만 알 수 있었다고… 회사가 좀 특이한 경우가 있어서 개발자 오씨를 제외하고는 전부 사람들이 나가있을 경우가 있으면 그냥 그분은 걍 회사에서 열심히 놀았다고 하는군요. 당연히 그분은 칼퇴란 칼퇴는 다 했습니다. 그러니 진행은 제대로 안되고… (근데 코드는 그따구로 짜고…)
근데 이건 팀을 관리하는 관리자의 입장에서는 정말 잘못한 실수입니다. 오씨가 방치되어있을 때에, 오씨와 해야 할 일에 대해서 체크를 하고 오씨를 놀리지 않도록 해야 할 일에 대해서 어느 정도의 관리를 한 다음에 오씨를 가만 두었어야 했습니다. 그럼 최소한 일이 진행되지 않는 그런 사태에 대해서는 미연에 방지할 수 있었습니다. 근데 오씨가 알아서 하겠지라고 그냥 믿고 있던 것이…. 엄청난 실수입니다. 그 사이에 일어났던 일들은….(이저 ㄴ시리즈들 참조)
근데 관리자들이 왜 이렇게 그냥 놔두는 선택을 하게 될까요..? 전 여러모로 그냥 추측만 해보고 있습니다만 가장 좋은 이유가 개발자한테 책임 물리기를 할 수 있기 때문이라고 봅니다. 관리자를 통해서 일을 처리하지 않고 있다가 지금까지 뭐했냐는 그런 식이죠. 그리고 관리자는 복잡한 것에 대해선 생각하지 않아도 되는 장점이 생깁니다. 복잡한 생각은 전부 프로그래머의 몫이 되고 관리자는 그냥 그런 기능이 사양서대로 구현되어 있는지만 체크하면 되는 간단한 수준으로 업무 내용이 줄어들게 됩니다.
개발자가 기획부터 설계, 개발, 테스트, 배포까지 모든 걸 해야 하는 경우가 아닌 이상 개발자는 어느 정도 선을 긋고 일을 해야 합니다. 안그러면 끝도 없는 일이 만들어지게 됩니다. 사양서에 없는 일까지 아주 완벽하게 가려고 하다보면 산으로 가는 코드 짜는 거 일도 아닙니다. 진짜로.. 그러다보면 커뮤니케이션 미스 나는 케이스도 금방 쉽게 발생하게 됩니다. 당연하죠. 개발자가 완벽한 사람도 아니고…. 맨날 컴퓨터랑 이야기해서 결과물 내는 데만 집중하는 사람들이 다른 일들까지 다 완벽하게 할 수 있을거라고 생각한다면 그것이야 말로 뭔가 잘못된 것이죠. 설계때부터 참여했다 해도 마찬가지입니다. 해당 설계가 완벽하다는 보장도 없는 이상 설계는 바뀔 수 있고, 바뀌는 것에 대해서 유연하게 대처하는 것 또한 필요한데 그런 것에 완벽함따위가 있겠습니까…
이런 상태에서 길도 모르는 채로 방치된다…?
프로젝트 진행 느리게 하는 가장 좋은 방법 중 하나라고 생각합니다.
그러다가 이제 사양서랑도 또 다른 고객의 의견을 들어보면 또 다른 멘붕하게 되고 그동안 방치되었을 때 뭐했냐 이런 소리 나오면서… 또 싸우게 되는 거죠.
개발자 믿고 방치하는 거 나쁘다는 거 아닙니다. 최소한의 컨트롤은 할 수 있는 선에서 방치해야지 그냥 개발자 믿고 맡기는 건 아닙니다. 그러다가 나중에 망하는 건 결국은 회사고….
그러면 그 와중에도 방치된 개발자가 방치된 상태를 꿀빠는 상태라고 오인하게 되는 겁니다. 개발자도 오인하고, 관리자도 오인하고, 사장도 오인하고, 그리고 그걸 지켜보는 다른 사업팀(개발 이외의 팀)들에서도 오인하는 거죠.
오씨 욕의 종착점 중 하나인 꿀빨았다는 것에 대해서 좀 써보려고 했는데… 돌아가던 상황 보면 오씨가 그러고 싶어서 그러던 것만이 아니라는 걸 생각외로 쉽게 깨달을 수 있었기에 일단 이런 글을 좀 써봅니다. 개발 진짜 나 혼자서만 해야 한다는 그런 상황 아니면 제발 유용하게 할 수 있는 건 다 유용하게 써먹어야 합니다. 특히 사람은 중요합니다.