개발자가 아닌 사람이 어떻게 개발자를 판단할까요?
그들은 아마도 냉소적인 성격일 수도 있습니다. 가치 없이 막 던진다는 소리일 수 있습니다. 아무튼 여러 가지 그들의 함구를 정리해 보았습니다. 이 내용은 그저 종교 논쟁이나 같을지 모릅니다. 그래도 이와 같은 한 모퉁이의 항변이 수많은 그들 중 한 사람만이라도 깨우친다면 성공했다 하겠습니다.
(여기서 냉소적이든 아니든 개발자가 아닌 사람이 개발자를 판단하는 어리석은 사람을 그들이라고 표현하겠습니다.)
그들이 이렇게 말합니다.
- 개발자는 이것 저것 해봐야 한다.
- 업무를 알기 위해 테스트를 해야 한다.
- 개발자들은 못 믿겠다.
- 빨리빨리 미리미리
- 개발자는 대체물?
솔직히 이 말들은 다녔던 회사의 관리자가 한 말들 또는 개발자에 바라는 마음들 입니다. 그는 개발자가 아닌데도 개발자의 전망이나 로드맵을 말하며 이거 저거를 해야 한다고 말하곤 합니다. 하지만 IT의 넓은 시야를 보려고 노력하는 본인이 듣기에는 전혀 말 같지도 않는 소리 뿐이었습니다. 자바가 빠르다며 웹이든 뭐든 자바로 구현하라고 주장하는데 어디가 어떻게 빠른지 좀 묻고 싶습니다.
자 그럼 말 한마디 한마디 따져보겠습니다.
1. 개발자는 이것 저것 해봐야 한다.
자 우린 한 빌딩을 지으려고 합니다. 음악을 전문으로 하는 곳으로 녹음실도 있고 음반 포장실도 있고 회의실도 있고 당연 화장실이 있습니다.
그들은 이 모든걸 다 설계 하길 바랍니다. 설계는 가능합니다. 하지만 그 목적에 충실하지 못할 수도 있습니다. 녹음실을 전문으로 설계한 사람은 화장실에다가도 꼭 스피커를 심으려 할 것 입니다. 그것도 고음질의 콘솔과 앰프가 달린 것으로 말이죠. 화장실을 전문으로 설계하는 사람은 녹음실을 설계할 때 어떻게 설계 될까요? 생각만 해도 끔찍하기만 합니다.
그래도 전문성을 지닌 개발자들은 몸담지 못한 사람들이 모르는 그들만의 철학이 있을 것입니다. 화장실을 설계 하는 사람은 화장실에 대해 깊고도 깊은 무언가의 철학이 있을 것입니다. 하지만 그들은 그것을 무시합니다. 그래도 이런 건축은 눈에 보여지므로 개발자보다는 덜합니다. 개발자는 눈에 보이지도 않기 때문에 그들의 막말에 대응할 증거들이 부족하죠.
여러 나라의 언어를 배워 보십시오. 그 배운 언어들 중에 장편소설에 쓸 수 있는 언어가 있을까요? 쓰라고 하면 쓰겠죠. 고생은 엄청 하고 결과물은 엉터리로 말입니다. 이렇게 가치 없게 기술을 습득 시켜 주시는데 죄책감은 절대 있을 리 없겠죠? 그렇죠?
2. 업무를 알기 위해 테스트를 해야 한다.
이건 정말 안될 일입니다. 라고 조엘은 강조하더군요.
개발자는 테스트를 하지 말아야 한다고 저는 생각을 합니다. 그래도 어느 기본적인 테스트는 거쳐야 할 테지요. 제가 말하는 테스트는 QA부서들이 하는 일입니다. 아무튼 개발자는 그 테스트를 당연히 해야 한다고들 그들은 말하고 있습니다. 그리고 불만을 갖지 말라고 하죠.
참고로 전 회사는 개발자로 뽑은 신입사원들에게 3개월 동안 QA를 시켰습니다. 그러면서 당연히 신입은 해야 한다고 말하죠. 개발 신입이 오자마자 개발자임을 치가 떨게 될까 두렵습니다.
저는 개발자가 테스트를 하는 것과 관리자급들이 테스트를 하는 것은 같다고 생각을 하는데 한마디로 누구든 테스트를 할 수 있지만 직무와는 관계가 없다는 것입니다. 즉 개발자라서 테스트하는 것은 그저 시키기 위한 핑계 일뿐입니다. 또한 업무의 형태를 알기 위해 테스트를 해야 한다고 당연한 것처럼 말하는 것도 핑계입니다. 장담컨대 개발자가 테스트를 한다는 것은 일의 능률을 밑바닥까지 끌어내리기만 할뿐입니다. 기능을 추가하거나 자신의 아이디어를 적용하면 뭐합니까? 명세서 쓸 것이나 테스트 할 것들이 그 만큼 쌓이는데 말이지요. 만들고자 하는 제품의 날로 발전하기를 바란다면 테스터를 고용하여야 합니다. 하고 싶고 열심히 하려는 대학생들 넘쳐 납니다.
3. 개발자들은 못 믿겠다.
개발자들이 무슨 거짓말쟁이로 만들어 버리곤 하는 그들은 결국 개발자를 한통속으로 몰아 넣곤 합니다. 특히 일정부분에 많은 충돌이 일어나는데 개발자가 무슨 예언자도 아니고 정확한 일정을 어떻게 산출을 해내고 어떻게 산출한 일정대로 움직일 수 가 있습니까? 아직 100년도 안된 공학입니다. 일정계획 수립은 아직도 개발자의 경험 하에 나오게 되고 대부분 실패하거나 맞추기는 하더라도 일부 기능을 축소로 겨우 겨우 맞출 뿐이죠.
그래서 일정을 예측할 때 자신이 생각한 일정에 곱하기 3을 해야 어느 정도 맞다 라는 법칙이 나온 것 입니다. 참고로 일정 곱하기3은 그들이 아주 싫어 하는 것 같아 보입니다. 즉 놀 시간을 더 늘리는 것처럼 보일 테니깐요.
4. 빨리빨리 미리미리.
일정압박을 통해 잃어가는 건강과 가족 따위도 생각 안 하냐고 EA 직원이 EA CEO에게 쓰는 블로그가 생각이 나며 눈물도 나는군요. 또 주 40시간 근무를 해야만 돈이 들어온다고 하는 조엘도 생각 나는군요.
분명 프로젝트의 종료일정이 있지만 그들은 조급하고 불안하고 개발자를 못 믿는 나머지 계속적인 압박과 미리 개발완료라는 카드를 꺼내 들고 개발자의 숨통을 죄고 있습니다. 마지 못해 압박된 일정에 출시한다면 그건 50%가 불만 섞인 코드 일 것입니다. 50%이면 그래도 다행입니다. 그래도 일단 종료를 하고 출시를 하면 불만 섞인 코드의 동작은 불량을 토해내고 사용자들은 불편함에 함구를 합니다. 그럼 개발자는 해명을 해대지만 이미 핑계처럼 보이기만 합니다.
뒷짐지며 뒤에서 바라보는 그들은 원초적인 문제를 알란가 모르겠습니다.
5. 개발자는 대체물?
개발자 전문가입니다. 전문성을 지니고 고결한 기술을 능숙 능란하게 휘날리는 개발자란 말입니다. 그들은 이런 지식근로자를 마음대로 배치를 합니다. 자신마다의 장단점을 무시하고 그저 아무데나 놓고 자리에 앉혀 놓으면 뭔가 뚝딱하고 나올 듯 한가 봅니다. 네 나오긴 합니다. 하지만 개발자는 고생할 뿐 어느 하나 도움이 안되고 불만과 스트레스만 쌓이게 될 것입니다. 이런 대체물에 대한 언급은 피플웨어의 저자인 톰 디마르코가 한 말입니다. 아주 자세하게 지식근로자는 대체물이 아님을 설명하였으니 한번 읽어보았으면 좋겠습니다.
아무튼 그들은 우리를 한낱 기술을 가벼운 망치질로 여기기 때문에 이쪽 저쪽 배치하면 잘 될지 압니다. 이렇게 개발자를 값어치 떨어지게 생각한다는 것이 정말 치욕스럽기까지 합니다.
마무리
개발자는 집중하지 않으면 엄청난 재앙이 다가오는 정밀작업을 하는 사람들입니다. 당신들이 무엇을 알고 개발자는 어떻고 대세는 어떻고 어떤걸 배우면 성공한다고 말을 하십니까? 지금 당장 자리에 앉아 무엇을 개발한다고 해보십시오. 분명 당신은 “내가 그걸 왜 해?” 하겠지만 그래도 한번 시작해 보십시오. 시작을 하고 끝을 했다면 비로서 개발자를 10% 판단 할 수 있을 것입니다.
평생 안 할거지요? 그럼 평생 개발자를 정의 하지 마십시오.
