사람, 사람 그리고 사람
내가 공대를 간 이유
내가공대를 지망한 것은 어린 마음에 막연히 컴퓨터가 좋아서였다(근데왜 전산을 전공하지 않았을까???)
당시 내 성적이면 그래도 맘만 먹는다면 일류대는 아니더라도 의대는 갈 수준이었지만 “피”를 무서워하고 사람 대하는 데 도통 자신이 없는 터라 사람이 아닌 “기계”를 대하는 공대가 적성에 맞다고 생각했다.
10년.
입사한 지도 10년이 지났다. 주변머리가 없어 다른 길을 보지도 않고 그냥 한 길로만 왔다.
철없던 어린 시절에는 나에게 주어진 일, 내가 맡은 블럭만 신경써서 (당연히 타 블럭과의 연동 포함) 문제 없이 동작하는 게 전부 인 줄 알았다.
그리고 이제서야 깨달은 것은
결국 S/W 개발도 사람을 관리하는 게 핵심이구나.
얼마전에 만난 친구 녀석. 이젠 현역(?)이 아니라 8명의 부하직원을 둔 매니저가 되었단다. 첫 마디가
“말도 어지간히 안 듣는다”
후배들
함께 일하는 후배나 동료를 본다.
그들 중에 얼마나 많은 이가
S/W quality, 문서화, 자발적인 코드 리뷰, 타인에 대한 배려, 방어적인 프로그래밍, 정보 공유, productivity, unit test, block test, test automation…
이런 것들에 대해 고민하는 가 생각해 봤다. 몇 명의 얼굴이 떠올랐지만 그들은 손가락으로 꼽을 만한 수였다.그것도 왼손만.
Process
자꾸만 process를 복잡하게 한다. 패치하나를 내려고 하면 이런 저런 문서를 몇 가지를 함께 제출해야 한다. 당연히(?) 개발자들은 힘들어 한다.
그런데 어찌 보면 당연한 작업이다. 그동안 하지 않았을 뿐. 코드를 수정해서 패치를 내면 당연히 뭘 고쳤는지, 왜 고쳤는지등을 설명해야 할 것이고, 수정된 코드로 인해 기존에 잘(?) 동작하던 것들에 영향을 미칠 수 있으므로 regress test결과를 제출해야 할 것이다. 그래야 잘못된 패치로 인해 발생할 수 있는 부작용을 줄일 수 있는 것이다.
블럭 독점주의
블럭 담당자가 자기가 맡은 블럭이 뭘 해야 하는 지 모르는 경우도 많다. 누구말대로 “블럭 담당자”가 쉽게 딸 수 없는 타이틀이라는 것이라고 알게 해야 할 정도다. 이런 저런 잡일을 하다가 나름 실력을 인정받은 경우에만 “블럭”을 할당해서 자부심을 갖게해야 할 지도 모르겠다. 하지만 지금은 자신이 맡은 블럭은 남들은 전혀 신경도 안 쓰고, 신경도 못쓰게 자신만의 블럭으로 생각한다.
All I have to know is the programming language
코딩을 위해 당연히 언어는 기본이고(모르면 필요하면 책을 보거나 reference code를 보면 된다) 코드 관리나 unit test, block test, documentation 등 다양한 내용을 알아야 한다. 하지만 오직 설계 문서도 없고(문서가 아니더라도 어떤 형태던지 설계에 대한 내용을 알 수 있는 기록) 코드에는 코멘트도 없고, test case도 정리하지 않고, 타 블럭과의 연동은 항상 직접 붙어야 한다고 생각하는 자세.
결국 사람이 문제다.
개발자의 능력이 문제고, 그 보다는 개발자의 자세/자질의 문제다. 동시에 입사한 신입사원을 보더라도 정말 흔한 말로 “열정”을 가지고 노력하는 모습이 보이는 사람과 그렇지 않은 사람은 확연하게 구분이 된다. 비록 지금은 별 차이가 없을 지라도 불과 1-2년만 지나면 그 두 사람에 대한 대우가 달라진다. 금전적인 것이 아니라 동료 혹은 선배들이 바라보는 시선이 달라진다.
잔소리
매일 아침마다 하라고 하는 이야기가 있다. 하지만 한 명도 안한다. 왜 안하는 걸까?
하기 싫어서? 하기 귀찮아서? 힘들어서?
이유가 뭘까? 정말 이유가 뭘까?
큰소리
왜 회의때마다 그 사람이 그렇게 언성을 높이는 지 가끔은 이해가 된다. “왜 내가 시킨 걸 안했어” 도 있겠지만 “왜 너희들은 나만큼 관심을 갖지 않는 거야”라고 이해가 될 때도 있다. 나도 나이가 들어서 그런 것일까?
Management
사람이 싫어 공학을 했지만 가끔은 사람을 관리하고 싶다는 생각을 한다. 나라면 조금 다르게 해 보지 않을까? 나라면 좀 더 인간적으로 대할텐데. 지금 내 위의 관리자들은 “사람”을 “사람”으로 대하지 않고그저 “블럭 담당자”로 보는 듯해서 무척 아쉽다. 그렇게 해서는 품질 개선을 위한 지시 사항은 모두 “숙제”로 느껴질 뿐일 것같다. 사람들의 “공감”을 얻는 노력이 필요한데 그게 없다.
이러한 문제는 Ego가 강한 한 개인의 문제라기보다는, 팀 문화의 문제라고 생각한다. 어떤 잘못이 있을 때 원인과 해결 방법에 집중해서 논의가 일어나기 보다는 그 사람의 성격 탓으로 돌리는 행위나 감정을 자극하는 언행들이 팀원 하나하나로부터 조금씩 보이면서 팀의 문화로 형성되는 경향이 있는 듯하다. egoless programming
그래서 뭐~
그냥 그렇다고. 나중을 대비해서 열심히 효과적인 S/W project management나 심리학등을 공부해야 겠다.