[개발자와 커뮤니케이션] 피드백의 중요성

“개발자 나초보의 일화 첫번째”

 

개발자 나초보는 약점이 있었는데, 프로그래머의 피가 좀 부족하다는 것이다.

알고리즘이나 자료구조, 파일 처리론 등을 공부를 열심히 했고,  자바 랭귀지는 몇 년간 공부를 해 왔으나 희한하게 창의력 즉, 문제가 주어졌을 때 풀어나가는 능력이 자기 자신이 생각해도 한심할 정도로 떨어졌다. 그도 계속해서 공부를 하다 보니 이제야 감을 좀 잡나 싶었다.

그러나 웬걸?

첫 직장에서 개발자는 선임 개발자 한 명 이고 그 선임 개발자 마져도 남을 지도하는 데는 별 취미가 없었던 사람이다. 그러다 보니 모든 문제를 자신이 알아서 하는 형태여야 했고 웹 호스팅 회사에서 전임 개발자의 소스를 뜯어다가 붙여 넣는 C&P 신공에만 주력하게 되었다.

그에겐 DB Modeler 가 되는 꿈이 있었다. 그러나 모델링 관련해서 job search 를 해 봐도 눈에 띄지 않았고, 전공도 하지 않은 터에 지방 학교.. IMF 를 지난 지 몇 년 안된 시점.. 그를 써줄 회사는 눈 씻고 찾아봐도 쉽지 않았다.

그래서 나초보는 방향 선회를 결정했다.

“그래, 개발을 좀 해 보다가 Database 설계 쪽 일을 해 보는 거야!”

마침, 아는 사람을 통해서 웹호스팅 회사를 소개 받게 되었고, 서로간의 약속의 불이행으로 인해 6개월 후 퇴사하기까지 그 회사에서 자신의 의지와는 상관 없이 정말 배운 것 없이 지낸 시절 이었다.

그러나 정작! 문제는 그 다음 이었다.
6개월 일 하는 동안에 쌓지 못한 Skill 이 나초보의 발목을 잡게 된다.

 

개발자 사회에 대해서 잘 모르는 나초보는 잡코리아에 자신의 경력서를 올리게 되었고 전화를 한 통 받게 된다.
*** 은행에 들어가는 프로젝트란다…
경력관리에도 도움이 될거고 금액은 이정도를 준단다..
회사에서 제시하는 금액은 일반 신입사원의 반정도 밖에 못 받았던 그 전에 다니던 회사와
거의 동일한 금액으로 3개월 계약직을 얘기한다.
( 나중에 알게 된 사실이지만, 이 계약 형태가 프리랜서의 계약형태였다... 아마도 그 회사는 나초보에게 주기로 한 금액만큼 폭리를 취하려 했던 것 같다.. ) 
자신의 개발 경력이 6개월밖에 되지 않아서 나초보는 해당 계약에 동의를 하게 된다.
그리고 3개월동안 나초보의 하루 하루는 정말 지옥같았다.

투입된 지 한달 후부터 인원을 바꿔달라는 PL의  요청은 매일같이 전화기 소리 너머로 들렸고 프로그램 설계자의 태도는 가르치는 수준에서,,,, 아예 대놓고 무시하고, 차별하고, 설계서를 내 던지는 수준까지 가게 되었다. 그러나 "나초보" 인생 살아가는 데에는 열정이 있고, 오기가 있는지라...
여기서 물러나면 더 이상 갈 곳이 없다는 배수진을 치고 바늘방석에 기꺼이 앉아서 버텼다. 
매일 12시 넘어 퇴근에 주말에도 출근하고 밤샘도 기꺼이 했다. 

그러나 계약 만료전 나초보가 계약한 회사의 사장은 PL과 설계자가 

“나초보씨는 아는 것도 없으면서 잘 물어보지도 않는다. 하나 고치면 하나 에러난다. 같이 일 못할 정도로 불안하다.”라는 말을 했고 그래서 나초보에 대한 급여에 대한 잔금을 지불하지 못하겠다고 했다 한다.
그래서 월급을 못주겠다는 말을 하고 있다.

그러나 나초보의 입장은 달랐다.

개발경력 6개월로 솔직하게 넣었고, 금액도 거기에 맞춰서 정말 박봉으로 받았다.

그리고 같이 투입된 계약 회사의 4년차 개발자 "나중수" 그는 그 프로젝트에서 이미 베테랑 이었다.

"나중수"는 같은 회사 소속이었으므로 리드를 해 줬어야 하는데 기존에 있었던 멤버들과의 친분이 이미 있었고, 프로젝트가 2차였으므로 혼자 작업하기 바빴다..

“나초보”는 무언가 모르는 게 생길 때에도 프로젝트 경험이 없기 때문에 무엇을 어떻게 수정해야 하고 어디서부터 접근해야 할지 접근법 조차도 모르는 신입이다.

또한 질문조차도 어떻게 질문해야 하는 지도 모르는 초짜 신입 개발자 이다.

그에게 일을 시킬 때 일반 프리랜서 개발자 ( 나초보는 자신이 프리랜서라는 것도 모른다.) 에게 일을 시키듯이 시키고 나서 아무런 의사소통도 없이 나초보씨를 투입시킨 회사의 책임으로 돌린 것이다.

 

나초보씨가 실수한 것은 자신의 입장을 충분하게 표현하지 못한 것이다.

즉, 자신은 신입이고 이런 일처리에 대한 감각이 없다는 것을 주위에 적극적으로 알리고 도움을 받았어야 했다. 프리랜서의 입장은 가만히 있어도 누군가 이끌어주고 하는 선/후배가 거의 없다고 봐야 한다. 자신의 앞가림을 자신이 모두 해야 하고 자신의 역할을 다 해야 하는 것이다.

아무리 무엇을 물어볼지 모른다지만, 계속해서 물어보고 발전 시켜나가야 한다.

흔히 개발자에겐 자신에게 문제가 주어지면 다 완성되면 보여줘야 한다는 생각에 모든 문제를 끙끙대며 안고 간다.

그러다가 한,두달 정도 지나고 스케쥴 확인과 완성된 프로그램을 확인할 때 사태는 걷잡을 수 없는 상황으로 달려간다.

자신에게 지시를 내리는 사람이나 설계를 한 사람, 현업에의 끊임없는 피드백과 커뮤니케이션은 아무리 강조해도 지나치지 않다.

 

그 프로젝트의 PL의 소통 능력도 매우 의심 스럽다.

자신이 이끌고 있는 팀원의 자질에 문제가 있다면, 그가 무슨 문제가 있는가를 적극적으로 알아보고 리드 했어야 했다.

리드를 해야 할 사람이 자신의 역할은 하지 않고 상대방에게 책임만을 요구한다면, 그것은 그 팀이 깨질 수 밖에 없는 요인이 된다.

 

설계자 역시 자신의 일만 하는 것이 아니라 개발자의 문제를 보았다면 win-win 할 수 있는 방안을 만들었어야 했다.

 

서로간의 커뮤니케이션의 부재에서 문제가 발생했다.

“나초보” 만의 문제가 아니라 개발자의 일반적인 성향으로 인해서 발생한 문제라고 해도 과언이 아닌 사례이다.

 

우리 개발자들은  일반적으로 피드백에 약하다.

모두 완성되면 한방에 보여주려 한다.

중간 중간에 보여주면

“혹시나 내가 한 작업을 별볼일 없다고 무시 받으면 어떻게 하지?”

“내가 짠 코드를 감히 누가 뭐라고 해?”

등의 생각을 하고 접근하게 된다.

 

모든 사람간의 관계가 그렇듯이 피드백은 정말로 중요하다.

그것이 긍정적 피드백이든, 무언가 고쳐줘야 하는 피드백이든….

피드백은 서로의 상황을 공유하는 첫번째 단계이다.

 

위의 사례에서는 또 하나의 촛점이 있다.

바로 적극적인 자신의 의사표현이다.

자신의 의사표현을 적극적으로 하지 않은 탓에 “나초보”는 자신이 받아야 할 정당한 대우조차도 받지 못하고 자신이 일하고 있는 상황 역시 최악으로 치닫게 되었다.

우리는 흔히 결과물로 얘기해야 한다고 말한다.

그리고 한방에 보여주려 한다.

그러나, 사람간의 관계는 자신을 적극적으로 표현하지 않으면 항상 손해보게 마련이다.

 

--- 이전 글---
2008/12/04 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 말 잘하는 사람이 성공한다.
2008/12/04 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 굳이 말하려고 하는 이유
2008/12/03 - [글쓰기/개발자와 커뮤니케이션] - [개발자와 커뮤니케이션] 개발자와 커뮤니케이션 글쓰기의 시작

패턴 그리고 객체지향적 코딩의 법칙 지은이 문우식

상세보기

자바 성능을 결정짓는 코딩 습관과 튜닝 이야기 지은이 이상민

상세보기