수명이 짧은 개발자라는 직업
프로그래밍을 하다 막히면 근처 치킨집 사장에게 상의하라는 농담이 있다. 실제로 그런 경우도 있긴 있겠지만, 정확한 의미는 '개발자는 대부분 일찍 퇴임하고 자영업 등 다른 업종으로 뛰어들거나 개발직종이 아닌 직종으로 옮겨간다' 라는 말이다. 즉 개발자라는 직종의 수명은 짧다.
그리고 주변에서도 이런 생각을 가지고 있는 사람이 많다. 어쩔 수 없는 한국의 현실이라고 하기 전에, 왜 이런 생각이 잘못되었다고 고치자는 인식이 없는지가 답답하다.
대우의 문제
한국에서는 개발자를 낮게 보는 시선이 있지 않을까 생각된다. 일종의 하도급 인력 혹은 시간만 주면 모든 것을 다 해내는 잡부 정도의 시각일지도 모른다.
이렇게 낮게 보는 시각은 개발이라는 것 자체를 쉽게 보는 시선에서 발생한다고 본다.
개발자는 굉장히 많이 양산(?)된다. 하나의 프로그래밍 언어만 학교나 학원에서 배워도 일단은 프로그래머다. 그래서 저렴한 신입인력을 많이 채용하는 것도 가능하다. 흡사 공사현장에서 공사를 빨리 마무리 짓기 위해 인력을 많이 투입하는 것과 비슷하다. (일용직 근로자 분들을 나쁘게 표현한 것 같아서 미안하다. 그저 비교 예시로만 받아들여 주었으면 좋겠다)
이렇게되면 개발자는 대체로 아랫선에 가깝게 취급된다. 개발팀은 기획팀 등의 윗선과 가까운 조직과 대비되는 그런 조직이다.
시키는 대로만 하는 개발팀... 그래서 제대로 된 결과물이 나오겠나?
개발자의 노하우(장인정신)
경영진의 착각 중 하나가 '많은 인력을 투입하여 프로젝트를 단축시키는 것' 이다. 이미 많은 이들에 의해 어느 정도 검증된 이야기인데, 개발에 있어서 인력을 적정선을 넘게 투입하게 되면 오히려 프로젝트가 느려지거나 산으로 가거나 망하거나 등등 더 안좋은 결과를 초래하는 경우가 많다.
경연진은 개발자가 일을 하는 것을 보기 보단 개발자가 만들어 낸 것을 보게 된다. 따라서 그 안이 어떻게 구성되어 있는지 전혀 알지 못 한다. 결국 이 안에 모인 개발자의 노하우를 전혀 볼 수가 없다. 즉, 개발이라는 것을 쉽게 보게 된다.
'경력이 많고 연봉도 많은 개발자가 업무 처리 속도가 무조건 빠른게 아니다' 라는 말이 있다. 이도 오해의 일종이다. 무조건 빠르게 개발하는게 좋은게 아니라는 점을 전혀 이해하지 못 하기 때문이다. 테스트나 디버깅이라는 절차를 아예 모르고 있다고 봐도 된다. '문제를 미연에 방지하고 효율적인 코드를 작성하려 노력한다' 라는 것을 경영진이 알 턱이 없다. 단지 눈에 보이는 속도에만 관심이 갈 뿐, 그 이후에 발생될지도 모를 추가 작업 시간을 줄였다는 것을 알 턱이 없다.
능력자가 오랜 시간을 들여 개발한 것과 아마추어가 단시간에 개발한 것. 이 둘의 차이는 무엇일까. 경험자는 알겠지만, 디버깅이나 유지보수 그리고 재사용성에서 그 결과가 확연해진다.
크게 바뀌어야 할 때 마다 소스코드가 대량으로 엎어지고, 테스트 마다 시간이 지체되고... 과연 좋은 것인가?
한국에서 개발자가 걷는 길
개발 자체를 쉽게 보니 개발자는 어릴 때 혹은 경력이 짧을 때 하는 일이다 라는 말을 해대는 사람이 있다. 심지어 개발자 출신이 이런 이야기를 하기도 한다.
이런 시각을 가진 개발자들도 많은 건지, 여전히 개발자들은 40대 쯤에 개발자를 포기하고 PM(Project Manager)이나 기획쪽으로 빠지거나 아니면 자영업 등 다른 업종에 뛰어들기도 한다.
애초에 경영진이 PM이란 것도 그냥 팀원 관리만 하는 팀장으로 인식하지 PM이 해야 할 일을 제대로 알고 있는 건지도 의문이다. 이렇게 순수 개발자를 PM으로 격상시켜서 기획영업팀과의 분쟁도 자주 초래한다.
뭐가 문제인지 아직도 모르고 있을 것이다.
의문의 피로(?)
한국에서 제법 규모가 있는 소프트웨어 계열 회사는 대체로 SI, 즉 자체 솔루션 개발이 아니라 수주를 받아서 대신 만들어 주는 일을 하는 곳이 많다. 그리고 이런 SI업체는 장기간 파견을 나가는 경우가 많다.
일단 파견 자체가 편할리는 없다. 분명 무리가 갈 것이다.
그런데 또 다른 문제가 있다. 이런 파견의 경우 갑을관계가 발생하게 된다는 점이다. 당연히 파견간 개발자는 을이다.
갑을관계의 가장 큰 문제는 시키면 해야 한다는 것. 유명한 사례로, 개발자가 일 마무리 하고 퇴근하려는데 발주처에서 "이거이거 내일 아침까지 해놔요" 라는 말을 하는 것이 있다. 개발자는 밤을 세서 그 일을 다 처리해야 한다.
당연히 피로와 갑을관계의 스트레스가 쌓이고 이것이 과로가 되고 결국 개발자를 빨리 관두게 만든다.
뛰어난 개발자?
한국에서 뛰어난 개발자가 나오려면 우선 개발자가 하는 일을 제대로 아는 사람이 있어야 한다.
앞서 이야기 한 대로, 개발자가 하는 일을 표면적으로만 보는 이들이 있다면 그들을 절대로 윗사람으로 둬서는 안된다. 이것이 뛰어난 개발자가 되기 위한 첫 관문이다.
결국 개인이 아무리 노력해 봤자 한국의 회사 내에서 뛰어난 개발자가 되리란 불가능하다. 참 어이없다. (물론 약간 과장해서 적긴 했다)
개발자를 평가하는 방법?
개발자를 평가하는 방법이라고 적긴 했는데 글로 적으니 정말 쉽다. 문제는 이게 쉽게 되지 않는다는 점이긴 하지만... 어쨌든 적어보자.
당연히 개발자의 기본 기술이 최우선으로 평가되어야 할 것이다. 언어 사용 경력, 툴 사용 경력 등등 다양한 표면적인 평가 방법이 있다.
그리고 또 중요한 것이 있다면 바로 문제 해결 능력이다. 문제가 발생했을 때 얼마나 정확하게 그리고 얼마나 부작용(Side Effect) 없이 문제를 해결하느냐이다. 여기서 '얼마나 빠르게' 라는걸 집어넣어 버리면 개발자가 사라지니 조심.
효율 증대라는 말도 있다. 이건 뛰어난 개발자라면 가지고 있을 수 있다. 그들은 긴 경력을 증명하듯이 자신만의 도구나 라이브러리 등의 효율성을 증대시킬 기술을 가지고 있다.
마지막으로 프로젝트 관리. 이건 PM이 할 일이다. 중요한 건 그게 아니라, PM이 관리를 편하게 할 수 있도록 어느 정도는 도움을 주어야 한다. 최소한 코드 리비전 관리 라던가 이슈 트래커 등을 다룰 줄 알고 적극적으로 다뤄야 한다.
이 정도가 되면서 충분히 능력이 있는 PM이 있다면 일정이나 디버깅으로 프로젝트에 문제가 발생 할 리가 없다.
신입 개발자에게 평가가 가능한 항목은 매우 드물다. 충분한 경력이 없는 이에겐 언어 사용 경력 하나 만으로도 벅찰지도 모른다.
결론
사실 결론이라고 말 할 만한건 없다. 그저 내가 하고 싶은 주장을 적어보려 한다.
물론 사람마다 느끼거나 생각하는건 다르다. 개발자 마다도 다르다. 그렇다고 그들에게 선택권을 빼앗는 행위는 사라져야 한다.
개발 직종이 제대로 대우 받기 위해선 경영 및 기획 전담 부서의 시각 개선도 필요하지만 결국은 개발자 자신의 생각도 달라야 한다. 어설픈 한국의 소프트웨어 개발 문화가 완전히 정착하기 전에 말이다.
그리고 주변에서도 이런 생각을 가지고 있는 사람이 많다. 어쩔 수 없는 한국의 현실이라고 하기 전에, 왜 이런 생각이 잘못되었다고 고치자는 인식이 없는지가 답답하다.
대우의 문제
한국에서는 개발자를 낮게 보는 시선이 있지 않을까 생각된다. 일종의 하도급 인력 혹은 시간만 주면 모든 것을 다 해내는 잡부 정도의 시각일지도 모른다.
이렇게 낮게 보는 시각은 개발이라는 것 자체를 쉽게 보는 시선에서 발생한다고 본다.
개발자는 굉장히 많이 양산(?)된다. 하나의 프로그래밍 언어만 학교나 학원에서 배워도 일단은 프로그래머다. 그래서 저렴한 신입인력을 많이 채용하는 것도 가능하다. 흡사 공사현장에서 공사를 빨리 마무리 짓기 위해 인력을 많이 투입하는 것과 비슷하다. (일용직 근로자 분들을 나쁘게 표현한 것 같아서 미안하다. 그저 비교 예시로만 받아들여 주었으면 좋겠다)
이렇게되면 개발자는 대체로 아랫선에 가깝게 취급된다. 개발팀은 기획팀 등의 윗선과 가까운 조직과 대비되는 그런 조직이다.
시키는 대로만 하는 개발팀... 그래서 제대로 된 결과물이 나오겠나?
개발자의 노하우(장인정신)
경영진의 착각 중 하나가 '많은 인력을 투입하여 프로젝트를 단축시키는 것' 이다. 이미 많은 이들에 의해 어느 정도 검증된 이야기인데, 개발에 있어서 인력을 적정선을 넘게 투입하게 되면 오히려 프로젝트가 느려지거나 산으로 가거나 망하거나 등등 더 안좋은 결과를 초래하는 경우가 많다.
경연진은 개발자가 일을 하는 것을 보기 보단 개발자가 만들어 낸 것을 보게 된다. 따라서 그 안이 어떻게 구성되어 있는지 전혀 알지 못 한다. 결국 이 안에 모인 개발자의 노하우를 전혀 볼 수가 없다. 즉, 개발이라는 것을 쉽게 보게 된다.
'경력이 많고 연봉도 많은 개발자가 업무 처리 속도가 무조건 빠른게 아니다' 라는 말이 있다. 이도 오해의 일종이다. 무조건 빠르게 개발하는게 좋은게 아니라는 점을 전혀 이해하지 못 하기 때문이다. 테스트나 디버깅이라는 절차를 아예 모르고 있다고 봐도 된다. '문제를 미연에 방지하고 효율적인 코드를 작성하려 노력한다' 라는 것을 경영진이 알 턱이 없다. 단지 눈에 보이는 속도에만 관심이 갈 뿐, 그 이후에 발생될지도 모를 추가 작업 시간을 줄였다는 것을 알 턱이 없다.
능력자가 오랜 시간을 들여 개발한 것과 아마추어가 단시간에 개발한 것. 이 둘의 차이는 무엇일까. 경험자는 알겠지만, 디버깅이나 유지보수 그리고 재사용성에서 그 결과가 확연해진다.
크게 바뀌어야 할 때 마다 소스코드가 대량으로 엎어지고, 테스트 마다 시간이 지체되고... 과연 좋은 것인가?
한국에서 개발자가 걷는 길
개발 자체를 쉽게 보니 개발자는 어릴 때 혹은 경력이 짧을 때 하는 일이다 라는 말을 해대는 사람이 있다. 심지어 개발자 출신이 이런 이야기를 하기도 한다.
이런 시각을 가진 개발자들도 많은 건지, 여전히 개발자들은 40대 쯤에 개발자를 포기하고 PM(Project Manager)이나 기획쪽으로 빠지거나 아니면 자영업 등 다른 업종에 뛰어들기도 한다.
애초에 경영진이 PM이란 것도 그냥 팀원 관리만 하는 팀장으로 인식하지 PM이 해야 할 일을 제대로 알고 있는 건지도 의문이다. 이렇게 순수 개발자를 PM으로 격상시켜서 기획영업팀과의 분쟁도 자주 초래한다.
뭐가 문제인지 아직도 모르고 있을 것이다.
의문의 피로(?)
한국에서 제법 규모가 있는 소프트웨어 계열 회사는 대체로 SI, 즉 자체 솔루션 개발이 아니라 수주를 받아서 대신 만들어 주는 일을 하는 곳이 많다. 그리고 이런 SI업체는 장기간 파견을 나가는 경우가 많다.
일단 파견 자체가 편할리는 없다. 분명 무리가 갈 것이다.
그런데 또 다른 문제가 있다. 이런 파견의 경우 갑을관계가 발생하게 된다는 점이다. 당연히 파견간 개발자는 을이다.
갑을관계의 가장 큰 문제는 시키면 해야 한다는 것. 유명한 사례로, 개발자가 일 마무리 하고 퇴근하려는데 발주처에서 "이거이거 내일 아침까지 해놔요" 라는 말을 하는 것이 있다. 개발자는 밤을 세서 그 일을 다 처리해야 한다.
당연히 피로와 갑을관계의 스트레스가 쌓이고 이것이 과로가 되고 결국 개발자를 빨리 관두게 만든다.
뛰어난 개발자?
한국에서 뛰어난 개발자가 나오려면 우선 개발자가 하는 일을 제대로 아는 사람이 있어야 한다.
앞서 이야기 한 대로, 개발자가 하는 일을 표면적으로만 보는 이들이 있다면 그들을 절대로 윗사람으로 둬서는 안된다. 이것이 뛰어난 개발자가 되기 위한 첫 관문이다.
결국 개인이 아무리 노력해 봤자 한국의 회사 내에서 뛰어난 개발자가 되리란 불가능하다. 참 어이없다. (물론 약간 과장해서 적긴 했다)
한국 개발자가 걸어야 할 길
시작은 순수한 개발자이다. 하지만 그 결말까지의 진행은 과연 어떨까?
대우와 오해 그리고 피로로 인한 개발자의 수명의 짧아짐은 결국 개발자를 PM(Project Manager)으로 내몰게 한다. 그것도 오해가 뭉쳐있는 PM이다.
A. PM이 할 일은 프로젝트를 관리하는 것이다. 기획/영업팀에게서 일을 얻어오고 이를 개발자에게 지시하고 결과를 보고하는 등의 일이다.
B. A와 함께 더불어, 하지만 정말 PM이 해야 할 일은 바로 기획/영업팀과의 업무 조율이다. 필요한 일, 필요없는 일, 힘든 일, 나중에 할 일 등등 일의 순서나 효율성을 결정하고 이를 개발자들을 통해 구현하게 하는 것이다. 그리고 만약의 사태(예를 들어 알 수 없는 문제로 인해 일정에 늦어지는 등)에 대처하는 것 등이 있다.
문제는 위에서 B라는 건 한국에선 대게 생략되는 분위기이다. 왜냐하면 A만 해도 시간이 흘러가기 때문이다. 문서 작업과 쓸 데 없이 긴 회의가 다른 일을 방해한다. 결과적으로 업무 조율을 제대로 할 수가 없다.
사측 경영진에선 B의 역활 보단 A에 집중하길 원한다. 그러니 프로젝트가 제대로 될 리가 없고 결국 PM은 경영진의 까임을 당하게 된다.
그리고 PM휘하의 개발자들은 결국 빠른 개발에만 집중 할 수 밖에 없으니 개인 개발이라던가가 제대로 진행 될 리도 없다. 피로만 쌓이고 오랜 디버깅으로 까이다 결국 개발자를 그만둘 가능성만 높아진다.
그래서 치이고 치이는 PM조차도 그만두고 결국 개발 외의 직종으로 옮겨간다. 또 하나의 치킨집 사장의 탄생(?)이다.
개발자를 평가하는 방법?
개발자를 평가하는 방법이라고 적긴 했는데 글로 적으니 정말 쉽다. 문제는 이게 쉽게 되지 않는다는 점이긴 하지만... 어쨌든 적어보자.
당연히 개발자의 기본 기술이 최우선으로 평가되어야 할 것이다. 언어 사용 경력, 툴 사용 경력 등등 다양한 표면적인 평가 방법이 있다.
그리고 또 중요한 것이 있다면 바로 문제 해결 능력이다. 문제가 발생했을 때 얼마나 정확하게 그리고 얼마나 부작용(Side Effect) 없이 문제를 해결하느냐이다. 여기서 '얼마나 빠르게' 라는걸 집어넣어 버리면 개발자가 사라지니 조심.
효율 증대라는 말도 있다. 이건 뛰어난 개발자라면 가지고 있을 수 있다. 그들은 긴 경력을 증명하듯이 자신만의 도구나 라이브러리 등의 효율성을 증대시킬 기술을 가지고 있다.
마지막으로 프로젝트 관리. 이건 PM이 할 일이다. 중요한 건 그게 아니라, PM이 관리를 편하게 할 수 있도록 어느 정도는 도움을 주어야 한다. 최소한 코드 리비전 관리 라던가 이슈 트래커 등을 다룰 줄 알고 적극적으로 다뤄야 한다.
이 정도가 되면서 충분히 능력이 있는 PM이 있다면 일정이나 디버깅으로 프로젝트에 문제가 발생 할 리가 없다.
신입 개발자에게 평가가 가능한 항목은 매우 드물다. 충분한 경력이 없는 이에겐 언어 사용 경력 하나 만으로도 벅찰지도 모른다.
결론
사실 결론이라고 말 할 만한건 없다. 그저 내가 하고 싶은 주장을 적어보려 한다.
아무리 개발자라도 나중에는 기획이나 PM 같은거 해야된다???위 말은 '정의'가 아니다. 나는 이 말을 '사기' 로 정의한다.
물론 사람마다 느끼거나 생각하는건 다르다. 개발자 마다도 다르다. 그렇다고 그들에게 선택권을 빼앗는 행위는 사라져야 한다.
개발 직종이 제대로 대우 받기 위해선 경영 및 기획 전담 부서의 시각 개선도 필요하지만 결국은 개발자 자신의 생각도 달라야 한다. 어설픈 한국의 소프트웨어 개발 문화가 완전히 정착하기 전에 말이다.
댓글
혹시 트위터 사용하시나요? 사용하시면 팔로우 하고 싶습니다.