태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

나쁜 프로그래머가 되는 18가지 방법

2015.05.03 22:17 by 전규현


잠시 후 Google blogger로 이동됩니다.





소프트웨어 개발자는 끊임없이 변화하면서 성장한다. 스스로 길을 잘 찾아서 성장하는 경우도 있고, 좋은 환경에서 개발을 하다 보니 자연스럽게 실력이 향상되기도 한다. 하지만 열악한 환경에서 열심히 일만하다가 개발자로서의 실력은 점점 잃어가는 경우도 있다. 아무리 사회가 어떻고, 회사가 열악하다고 불평을 해봤자 남는 것은 자신의 개발자로서의 실력밖에 없다. 

 
이번 글에서 나쁜 프로그래머가되는 18가지 방법을소개한다. 물론 본의 아니게 주변의 환경이 나를 이렇게내모는 경우도 있지만 이를 반대로 해보는 노력을 해보자. 내가 대단한 사람이라서 이런 얘기를 하는 것은 결코 아니다. 나도 독자들과 똑같은 개발자로서 18가지 중에서 잘 안되는 항목도 있다. 단지 20년 넘게 개발을 하면서 느끼는 바를 공유하고자 함이다. 
 
1. 익숙한 기술만 고집한다
대부분의 사람들은 변화를 싫어한다. 익숙한 것을 사용할 때 업무의 효율도 높다. 하지만 지식노동자인 개발자는 익숙한 기술만 고집한다면 한계에 다다른다. 물론 환경이 그렇게 만들기도 하고, 다른 분야의 기술을 익힐 만한 시간과 여유가 없는 경우도 많다. 그러다 보면 새로운 기술이 필요한 상황에서도 익숙한 기술을 고집하는 고집쟁이가 되기도한다. 
 
2. 공유를위해 노력하지 않는다
현재 내가 하고 있는 일은 나만 안다. 내가 퇴사하면 당장 이 일은 마비된다. 지금은 내가 하는 일에 다들 관심들이 별로 없지만 내가 없는 빈자리는 매우 클 것이다. 내 업무에 관련된 지식의 90%는 내 머리속에 있다. 주변의 다른 개발자들도 비슷한 상황인데 굳이 내가 깃발들고 공유를 위해 나설 필요가 있을까?  
 
3. 후배에게 시키지 않고 직접 처리하는 것이 속편하다
후배들이 많이 있지만 실력도 부족하고 일을 시키면 답답하다. 내가 하면 한시간이면 할 수 있는 일을 신입사원을 시키면 하루종일해도 못끝낼 뿐만 아니라 신입사원이 해놓은 것을 검토하고 고치고 가르치는데 몇시간이 소모된다. 그러니 차라리 내가 빨리 끝내버리는 것이 낫다. 그래서 우리 회사는 신입 개발자보다 고참 개발자가 훨씬 바쁘다. 
 
4. 후배나 동료들이 작성한 소스코드를 봐주지 않는다
회사에서 코드리뷰를 하라고는 하는데, 내 할 일이 바빠서 다른 사람 코드를 봐줄 시간이 없다. 나 뿐만 아니라 다들 이런 상황이다 보니 코드리뷰는 유야무야되었다. 과거에도 코드리뷰를 몇번해 봤지만 바쁜 와중에 잠깐시간내서 봐주기는 했는데 제대로 봐주지도 못했다. 그냥 코딩 스타일을 가지고 트집을 잡는 정도다. 그러다보니 이제 코드리뷰는 모두들 꺼려 한다. 
 
5. 남이 내 코드를 보는 것을 꺼려 한다 
리뷰가 활성화된 조직에서는 지위고하를 막론하고 소스코드를 리뷰한다. 고참의 소스코드를 신입사원이 리뷰하고 지적할 수도 있다. 이런 거북함이 싫고, 귀찮고, 바쁘다. 내가 작성한 코드는 충분히 정상동작하는데굳이 다른 사람이 내 코드를 보고 지적을할 필요가 있을까? 개발할 시간도 부족하다. 
 
6. 문서화를 꺼려한다
문서작성은 무조건 싫다. 귀찮기도하고 잘 작성하지도 못한다. 하지만 회사에서 꼭 문서를 만들고 개발을 하라고는 한다. 그러면서 개발시간은 턱없이 부족하게 준다. 그래서 문서는 개발 다 끝나고 형식적으로 문서를 만든다. 한달동안 개발하고 나면 문서는 하룻밤 세워서 대충 문서를 만든다. 물론 이렇게 만든 문서를 나중에는 보지도 않는다. 
 
7. 커뮤니케이션 스킬 향상에 관심이 없다 
개발자는 프로그래밍을 잘하면 되지 커뮤니케이션 스킬은 별로 중요하지 않다고 생각한다. 개발자가 아닌 다른 사람들은 기술에 대해 잘 이해하지 못해서 기술에 대한 대화를 하기가 어렵다. 설명을 해도 잘 이해 하지 못한다. 난 컴퓨터와의 커뮤니케이션은 잘 되는 것 같다.
 
8. 책임지고 자신의 일을 마무리하지 않는다. 벌려만 놓는다
나는 개발을 엄청나게 빠르게 한다. 남들이 일주일 걸려서 하는 일도 나는 하루, 이틀이면 해치운다. 대신 완성도는 좀 떨어진다. 동작하도록 만드는 것은 나의 일이지만 귀찮은 버그를 잡는 일은 후배들을 시킨다.나는 새로운 일을 좋아하지 버그 잡는 것은 싫다. 
 
9. 소스코드가 주석 하나 없이 깨끗하다
항상 주석 같이 읽기 쉬운 소스코드를 주장하면 주석 하나 없이 깨끗하게 코딩을 한다. 하지만 후배들은 주석이 없으면 이해하기 어렵다고 불평이다. 하지만 프로젝트 일정이 항상 너무 촉박해서 소스코드에 주석을적을 시간이 없다. 
 
10. 소스코드가 읽기 난해하다
내 소스코드는 정상동작하지만 읽기는 어렵다. 워낙 바빠서 소스코드를 읽기 쉽게 정리할 수가 없다. 한 파일이 너무 크기도 하고 함수 이름도 난해하다. 내 소스코드는 최적화가 많이 되어서 짧은 코드로 어려운 로직을 기가 막히게 처리한다. 내 소스코드를 분석해 본 사람은 감탄을 할 것이다. 
 
11. 낮에는 집중해서 일하지 않고 주로 밤에만 일한다
회사가 낮에는 집중해서 개발할 수 없는 환경이다. 회의도 많고 시끄럽다. 그래서 밤에만 일을 하다 보니, 낮에는 여건이 되도 개발이 잘 안 된다. 밤에만 일하는 것이 완전히 습관이 되었다. 밤에 개발하는 것이 썩나쁘지는 않지만 나이를 먹어 갈수록 내 생활이 없어지는 것 같아서 걱정이다. 
 
12. 소프트웨어 공학에는 관심이 없다 
오로지 코딩, 코딩, 코딩만 잘하면 된다. 알고리즘, 알고리즘, 알고리즘은 관심이 많다. 소프트웨어공학이란말은 많이 들어 봤지만 이게 뭔지 설명하라고 하면 애매하다. 
 
13. 영어는 잘못하지만 공부할 시간은 없다 
원래 영어는 잘못했고 당장 영어공부를 따로 하지 않아도 개발을 하는데 큰 문제는 없다. 가끔 인터넷에서개발 관련 검색을 할 때는 주로 한글사이트만 검색한다. 스택오버플로우(Stack overflow)도 영어로 되어 있어서 잘 안 본다. 외국 소프트웨어 회사에 취업을 하고 싶어도 영어 때문에 포기했다. 
 
14. 기초, 원리는 잘 모르고 응용만 하려고 한다
시스템의 원리나 깊은 지식은 잘 모른다. 필요한 알고리즘이 있어도 원리는 잘 모르지만 인터넷에서 다운받아 그냥 사용하는 데는 큰 지장이 없다. 바빠서 따로 공부할 시간은 없다. 학교 다닐 때 전공수업 공부 열심히 할 걸 그랬다. 
 
15. 카피&패이스트(Copy & Paste)는 나의 무기 
소스코드 복사하는 것이 일상이다. 다른 프로젝트에 비슷한 기능이 있으면 복사해서 사용한다. 공통모듈을만들려면 여러 사람하고 얘기하고 조율을 해야 하는데 시간도 없고 내가 깃발들고 나서기는 싫다. 복사가 훨씬 빠르다. 소스코드를 복사해서 써도 지적하는 사람이 없다. 
 
16. 수학을 못한다. 관심도 별로 없다 
학교다닐 때부터 수학은 관심이 없었다. 잘 하지도 못한다. 소프트웨어를 개발하는데 수학이 왜 필요한가? 코딩만 잘하면 되지. 어려운 알고리즘은 인터넷을 조금만 뒤지면 라이브러리가 다 있다. 
 
17. 변변한 취미가 하나도 없다 
지난번 건강검진에서 의사가 술을 줄이고 운동을 하라고 했지만 매일 야근에 운동은 꿈도 못꾼다. 그나마 가끔 시간이 날 때 친구, 동료들과 술을 마시는 것이 유일한 낙이다. 숙취 때문에 다음날 일은 망친다. 
 
18. 개발밖에 모른다
회사가 어떻게 돌아가는지 잘모른다. 회사의 전략이나 경영 상황은 잘 모른다. 그런데 관심을 가질 시간이 별로 없다. 나는 회사일 신경 안 쓰고 내가 좋아하는 개발이나 평생하면 좋겠다. 
 
나는 소프트웨어 개발자는 참 좋은 직업이라고 생각한다. 물론 본인이 일 자체를 즐긴다면 정말 좋다. 말들도 많지만 대우도 그리 나쁘지 않고 성취도도 높다. 하지만 열악한 환경에서 일하는 수많은 개발자들은 그렇게 느끼지 못하고 있다. 물론 좋은 환경에서 일한다면 만족도도 높아지겠지만 개발자가 오랫동안 즐겁게일하는데 제일 중요한 것은 본인 스스로의 실력이다. 나쁜 개발자가 되는 방법을 한가지씩 지워가면서 좋은개발자가 되는 노력을 해보자.


이 글은 ZDNet Korea에 기고한 입니다.



저작자 표시 비영리 변경 금지
신고

전규현 사람과 기술 개발자, 캐리어

  1. Blog Icon
    김민혁

    항상 좋은 글 감사합니다.

  2. 좋은 글 감사합니다. 재밌게 읽었어요.

  3. Blog Icon
    나그네

    잘 읽었습니다. 좋은 글입니다..

  4. 6번 11번 빼고 공감되네요
    문서화는 최소화하는게 좋고 업무에 몰입할수 있는 환경에서 몰입하는게 좋습니다. 11번은 환경의 문제죠

  5. 정리가 안되서 가독성이 떨어지는 것과 최적화되어 떨어지는 것을 구분할 필요가 있지 않을까요? 다같이 하향평준화하는게 사독성을 높이는 길은 아니라고 봅니다.

  6. Blog Icon
    방랑자

    어이없는 인수인계를 당해보니 문서화의 중요성에 대해 느낍니다. 근데 문서를 작성할 여유를 주지 않는 일정관리도 문제라 생각합니다. 밤에만 작업 하는 경우는 회사탓이 더 크다 생각합니다. 매일 퇴근하기 싫어하는 사람이 어디 있을까요.

21C 韓 SW개발자는 16C 조선 陶工 처지

2014.12.18 22:00 by 전규현


잠시 후 Google blogger로 이동됩니다.





나의 취미 중 하나는 도예 즉, 도자기 만들기다. 우연한 기회에 시작해서 10년을 넘게 도자기를 만들었으며 도자기 역사나 도자기 기술에 대해서도 많은 공부를 하게 되었다. 그런데 요즘 우리나라의 소프트웨어 산업 환경이 조선 시대 임진왜란 때 일본으로 납치되어 간 도공들이 다시 조선으로 돌아오기를 거부하고 일본에서 뿌리를 내린 것과 비슷하다. 
 
임진왜란 당시 어떠한 일이 일어났는지 간단히 알아보자. 그리고 역사는 되풀이 된다는데 현재 우리는 무슨 문제를 가지고 있는지도 생각해보자. 
 
16세기까지 전세계에서 1천300도 이상에서 구워내야 하는 도자기를 만들어 낼 수 있는 나라는 중국, 한국, 베트남 정도였고 그 중에서 도자기의 최고봉인 백자는 중국과 조선만 만들어 낼 수 있었다. 지금은 도자기가 별 것 아니라고 생각할 수 있었지만  당시에는 최고로 돈이 되는 물건이었다. 유럽의 귀족들은 중국의 도자기에 열광해서 금, 은 그릇보다 비싼 가격에 도자기가 거래되고 있었고 세계 도자기 시장은 거의 중국이 석권하고 있었다. 
 
임진왜란이 왜 일어 났는지는 여러가지 의견이 있지만 도자기 때문에 일본이 일부러 일으켰다는 주장도 있다. 임진왜란의 근본 목적은 조선의 도자기 제작 기술을 비롯한 여러 가지 공예 기술을 훔쳐오기 위한 것이라는 주장이다. 일찌감치 네덜란드 등과 교역에 눈을 뜬 일본은 유럽에서의 도자기 인기를 알게 되었고 자신들의 도자기 제작 기술보다 월등히 높은 조선의 도자기 제조 기술을 가지고 싶어 했다. 그래서 임진왜란 전에 미리 첩자를 조선에 보내 조선의 도공들의 신상과 소재를 모두 파악한 후 임진왜란, 정유재란 중에 조선의 도공 거의 전부인 약 900명을 납치해 갔다는 것이다.물론 도공들만 납치해 간 것은 아니고 다른 수많은 분야의 장인들을 같이 납치해 갔지만 도자기 장인들이 핵심이었다. 
 
그렇게 납치해 간 도공들은 일본에서 도자기를 만들 수 있는 흙을 찾아냈고 20년만에 일본도 완벽한 도자기 제작 기술을 보유하게 되었다. 마침 중국의 내부 정세 혼란을 틈타 유럽의 도자기 시장을 석권하고 막대한 자금을 바탕으로 아시아 최대 강대국으로 발돋움 했다는 학설이다. 
 
그런데 임진왜란 후에는 조선은 도공들을 다시 돌려 받으려고 했지만 많은 도공들은 조선으로 돌아오기를 거부했다고 한다. 일본으로 끌려간 도공들은 조선에서보다 훨씬 나은 대접을 받았다고 한다. 조선에서는 기술은 천시하고 도공뿐만 아니라 대부분의 장인들은 하층민 대접을 받았지만 일본에서는 이들을 극진히 대우를 해줬다고 한다. 땅도 주고 집도 주고 결혼도 시켜주고 마음껏 도자기를 만들 수 있도록 지원을 아끼지 않았다고 한다. 옛날부터 일본은 장인을 존경하는 전통이 있었고 자신들이 가장 높게 사는 최고의 도자기 제작 기술을 가지고 있는 사람들을 존경하고 대우해주는 것은 어쩌면 당연했을지도 모른다. 
 
그러다보니 임진왜란 후 거의 도자기의 명맥이 끊기고 세계 예술사에서 거의 흔적을 남기지 못한 한국과는 대비되게 일본은 최고의 도자기 명문 국가가 되었고 선진국의 발판이 되었다. 역사에 만약은 없지만 도자기를 기반으로 우리나라가 18,19세기 강대국으로 발돋움 했다면 어떻게 되었을까? 
 
이 얘기를 하는 이유는 임진왜란 당시의 상황이 지금과 별반 다르지 않기 때문이다. 여전히 기술자는 존경과 대우를 못 받고 그나마 대우를 받으려면 관리자가 되어야 한다. 공부를 잘하는 학생들은 대부분 의사, 공무원이 되려고 한다. 소프트웨어 개발자들은 기회만 되면 외국으로 나가려고 한다. 개인 입장에서는 축하해줄 일이지만 그렇게 고급인력이 다 빠져나가면 우리나라는 어떻게 될까? 
 
하지만 지금 소프트웨어를 전공하는 대학생이 진로를 문의하면 나도 외국으로 나가라고 충고를 한다. 미래의 먹거리가 소프트웨어에만 있는 것은 아니지만 소프트웨어가 가장 중요한 기술 중 하나인데 개발자에 대한 인식이나 대우, 환경은 너무 열악하다. 드라마에서 잘나가는 사람들은 거의 의사, 경영자, 변호사, 검사다. 엔지니어나 소프트웨어 개발자가 주인공은 경우는 거의 없다. 사회적으로 인식이 매우 낮다는 반증이다. 
 
제2의 도자기 전쟁은 이미 시작되었고 핵심은 우수 두뇌 확보다. 구글이 3조원이 넘는 금액을 지불하고 네스트를 인수한 주 목적도 인재 확보다. 구글이 네스트에 지불한 금액은 1인당 100억원이 넘는다. 국가나 기업 모두 인재를 확보하기 위해서 혈안이 되어 있지만 우리나라 인재들은 외국으로 나가고 있다. 또는 기회만 되면 외국으로 가고 싶은 엔지니어도 상당 수다. 
 
외국의 인재도 모셔와야 하는 마당에 우리나라의 인재들이 일하기 힘든 환경을 그대로 놔두고 있는 것은 오랫동안 뿌리깊게 자리잡은 기술자 천시와 관료 우대 인식 때문이 아닐까 생각한다. 이런 기술자를 낮게 보는 인식을 없애지 않으면 구한말에 우리나라가 겪었던 고통을 또 겪어야 할지도 모른다. 나라를 좌지우지 하는 사람들은 국내 상황에 정신을 팔려서 세계의 흐름을 놓치고 있다. 나중에 애국심에 호소해서 외국에서 일하는 우리나라의 인재들에게 들어와서 나라를 다시 일으켜 달라고 해도 돌아오는 사람이 몇 명이나 될까? 
 
개발자들이 우리나라를 떠나고 싶어하는 가장 중요한 이유가 연봉의 차이는 아니라고 생각한다. 연봉이 높은 나라는 생활비 지출도 많고 세금도 많다. 더 중요한 것은 엔지니어에 대한 전문성의 인정과 사회적인 존경심이라고 생각한다. 창의적 지식 노동에 대한 이해와 좋은 개발환경도 필요하다. 개발자로 30년을 일해도 어린 관리자와 같이 일을 해도 전혀 어색하지 않고 어린 관리자도 늙은 개발자를 어려워하지 않는 문화가 필요하다. 생산성을 높이는 방법을 오직 야근밖에 모르는 회사가 워낙 많다. 이런 회사는 사채를 끌어 쓰는 것과 같아서 갈수록 어려워진다. 이런 환경이 계속 만연한다면 우수한 개발자 인력들은 외국으로 떠나던지 소프트웨어 업계를 떠날 것이다. 이런 환경을 수수방관하면 역사는 되풀이 될 것이다.


이 글은 ZDNet Korea에 기고한 칼럼입니다.

Image from 한량과사발

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발자, 대우, 도자기, 조선, 처우

할아버지 개발자를 만나고 싶다

2014.05.23 10:47 by 전규현


잠시 후 Google blogger로 이동됩니다.





외국 소프트웨어 회사에서는 할아버지 개발자들을 종종 볼 수 있다. 현재도 프로그래밍을 하고 있는 진짜 개발자들이다. 우리나라가 개발자들은 이런 할아버지 개발자를 만나보거나 이야기를 전해 들으면 많이 부러워한다. 

 

대부분의 개발자들은 경력이 쌓이면서 자연스럽게 관리 업무를 겸하거나 아예 관리자로 전환된다. 관리와 개발업무를 동시에 하는 개발자들도 관리하랴, 회의하랴 바빠서 본인이 가장 잘하며 좋아하는 개발 업무와는 점점 멀어지게 된다. 또 관리를 하지 않으면 회사에서 파워가 줄어들거나 대우도 안 좋기 때문에 자연스럽게 그리고 본의 아니게 관리 쪽 진로를 선택하지 않을 수 없게 된다. 종종 자신은 끝까지 개발만 하겠다고 고집하는 개발자들은 관리 능력, 커뮤니케이션 능력이 떨어지는 괴짜라고 생각하는 이상한 시각도 존재한다. 

 

S사의 예를 보자. 이 회사는 오래 전부터 개발자 경력을 보장해주고 있다. 제도적으로는 개발자 트랙을 선택한 사람들은 관리를 하지 않고 개발만 계속 할 수가 있다. 하지만 속을 보면 개발자 트랙을 선택하나 그렇지 않으나 큰 차이는 없다. 개발자 트랙을 선택한 경우에도 개발 일에만 집중할 수 없고 그렇지 않은 경우에도 개발과 관리를 겸하게 된다. 개발과 개발이 아닌 일을 명확하게 구분하지 않고 두루뭉술하게 일을 해서 대부분은 개발 경력이 쌓일수록 개발에 집중할 시간은 점점 줄어들게 된다. 

 

T사의 경우 10년차 이상이 되면 팀장이 되고 파트장을 맡는다. 대부분 회사에서 가장 뛰어난 개발자들이다. 하지만 관리를 조금이라도 맡은 이상 낮에는 개발에 집중할 시간이 거의 없다. 보고서 작성에 회의 참석, 다른 부서와 의견 조율, 이런 일로 하루를 보내다가 저녁이 되어서야 개발 일을 시작한다. 이런 생활을 몇 년 하다보니 자연스럽게 개발 일에서 손을 놓게 되었다. 

 

이런 회사에 경영자들에게 왜 회사의 가장 뛰어난 개발자들이 개발을 거의 못하는 관리 일을 시키냐고 물어보면 다음과 같은 얘기를 한다. 

 

“당연한 것 아닌가? 소프트웨어 개발은 워낙 특수해서 개발을 속속들이 잘 알아야 개발 조직을 관리할 수 있다. 그가 우리 회사에서 소프트웨어 개발을 가장 잘아는 사람이다. 그래서 그에게 개발 조직 관리를 맡기고 있고 본인도 그 자리를 원하고 있는 것으로 알고 있다.” 

 

주변에서 소프트웨어 업계의 유명했던 롤모델들을 보면 지금도 개발을 하고 있는 사람들은 그렇게 많지 않다. 왕년에 개발을 좀 했던 실력자이지만 현재도 개발을 하고 있는 엔지니어는 만나기 힘들다. 왠만한 뚝심으로는 개발자로 남아 있기가 어렵다. 당사자들이 환경에 순응해서 개발에서 손을 놓게 된 경향도 크다 

 

우리는 각 기업의 최고 개발자였지만 지금은 관리자인 사람들을 종종 만나게 된다. 이들은 대부분 본부장, 센터장, 부서장, 연구소장 등과 같은 직함을 가지고 있다. 이들 대부분은 과거에는 개발자였을지 모르지만, 그리고 지금도 코드를 잘 읽을 수 있을지 모르지만, 관리자로 몇년만 지나면 더 이상 개발자가 아니다.

 

개발도 잘하고 관리도 잘한다는 것은 착각이다. 관리자가 된 이상 개발에 대해 특히 아키텍처나 구체적인 기술에 대해서 이러쿵저러쿵 참견하는 것은 매우 위험하다. 관리를 잘하는 것이 본인의 업무이고 그것만도 매우 어렵다. 

 

나는 블로그를 통해서 자신의 회사에서 개발자 경력을 보장하고 있는지 설문 조사를 한적이 있다. 과거 4년동안의 통계를 보면 개발자 경력 보장 제도가 있는 회사는 14%이다. 물론 제도는 있어도 형식적이거나 현실적으로 개발자로 남기 불가능 회사가 많기 때문에 실제 개발자가 경력을 보장받을 수 있는 비율을 훨씬 떨어지게 된다. 한마디로 20년, 30년 개발자로 남아 있기는 낙타가 바늘 구멍 통과하기만큼 어렵다. 

 

우리나라는 장인정신보다는 관료주의적인 전통이 자리잡고 있어서 전문가보다는 관리자가 더 높은 자리로 인식된다. 그러다 보니 개발자도 분위기에 순응해서 자연스럽게 관리 쪽으로 슬금슬금 넘어가게 된다. 팀장, 부서장이 되어서도 개발에 집중하고 싶어도 주간보고, 월간보고, 업무 분배, 진척확인, 부서간 소통, 보고서 작성, 채용, 사업계획, 평가, 경영자에게 보고 등등 이런 일이 점점 늘어가고 그러다 보면 점점 관리자로 탈바꿈한다. 

 

개발자가 개발 일에서 떠나는 이유가 또 하나 있다. 개발 프로젝트가 대부분 합리적이지 못하고 무리한 경우가 많아서 몇 년 구르다 보면 야근과 각개전투가 난무하는 전투현장에서 벗어나고 싶게 된다. 개발이 진짜 즐겁고, 개발자로 충분히 대우도 받고 보장을 받을 수 있다면 관리자가 되려고 할까? 개발이 합리적이고 즐겁고 비전이 있어서 개발자들이 남아 있으려고 할 것이다. 

 

이렇게 고급 개발자들이 떠나게 되면 소프트웨어 생산성은 극도로 낮아진다. 이것은 회사적으로도 국가적으로도 큰 손해다. 뛰어난 개발자들이 관리를 잘 해준다고 해도 소프트웨어 생산성에는 별로 도움이 안된다. 그럼 소프트웨어 개발이 그렇게 관리가 많이 필요한가? 사실 개발팀은 관리할게 별로 없다. 

 

관리가 많이 필요한 개발팀은 비효율적 팀이라는 것을 단적으로 나타낸다. 단, 프로젝트 관리는 필요하고 전문 프로젝트 관리자가 있을 수 있다. 큰 조직이나 큰 프로젝트는 이보다 더 많은 전문 관리자가 있을 수 있다. 프로젝트 매니저(Project Manager), 리스크 매니저(Risk Manager), 프로덕트 매니저(Product manager), 프로그램 매니저(Program Manager) 등 다양한 전문 업무로 세분화 되기도 한다. 

 

외국 소프트웨어 회사와 같이 일해본 개발자들은 종종 할아버지 개발들을 만나게 된다. 이들은 50세가 넘어서도 가끔은 60세가 넘어서도 개발을 한다. 코딩도 직접 한다. 

 

왜 할아버지 개발자가 중요할까? 소프트웨어 개발자는 물론 예외도 일부 있지만 보통 경력이 쌓일수록 실력이 늘어간다. 그래서 회사의 개발자 층은 피라미드 구조를 이룬다. 그런데 가장 뛰어난 늙은 개발자가 관리를 하고 있으면 개발자 피라미드의 중간부터 꼭대기가 아예 없는 사다리꼴 피라미드가 된다. 이런 회사에서 개발 경쟁력을 기대하기는 어렵다.

 

개발자 본인은 어떨까? 나도 마찬가지지만 대부분의 개발자들은 관리를 극도로 싫어하고 잘하지도 못한다. 개발자들은 개발을 할 때 가장 행복하다. 행복한 일을 하면서 세상을 바꿀 수 있는 개발자라는 직업은 얼마나 멋진 직업인가? 하지만 40, 50세를 넘은 개발자를 찾아보기 어려운 현상은 개발자의 미래를 불투명하게 하고 직업 안정성을 해치고 있다. 

 

올림픽 금메달을 딴 선수가 20대 중반에 은퇴한 후 직장의 조직에서 불안해하는 것과 별반 다를게 없다. 이런 현상이 개발자 직업 선호도를 낮추는 원인이 되고 있다. 성공한 소프트웨어 회사에서 사장이나 연구소장이 나와서 브리핑하는 것이 아니고 백발의 진짜 개발자가 나와서 개발 이야기를 들려주는 일들이 뉴스에 자주 나와야 한다. 

 

소프트웨어 개발자의 경력을 보장하는 일은 개인, 회사, 사회적으로 매우 중요하다. 우리나라 소프트웨어 미래의 사활이 걸려있다고 봐도 과언이 아니다. 여기서 가장 중요한 역할은 회사가 해야 한다. 회사에서 개발자의 경력보장이 왜 중요한지 먼저 인식해야 한다.  왜? 거기에 회사의 소프트웨어 개발 경쟁력의 핵심이기 때문이다. 

 

먼저 개발자와 비 개발자의 트랙을 명확하게 나눠야 한다. 좋은게 좋은 거라고 두루뭉술해서는안된다. 개발자는 철저하게 관리 업무와 잡무에서 보호를 해야 한다. 

 

앞에서 언급한 보고서 작성, 사업 계획, 예산, 평가 등에 시간을 허비하지 않도록 해줘야 한다. 이런데 10%라도 시간을 빼앗기면 개발 생산성은 50% 이하로 떨어진다. 관리업무와 잡무는 다른 사람을 시키면 된다. 개발자가 10명 이하인 회사도 업무는 나눌 수 있다. 

 

회사에 롤모델과 멘토도 만들어야 한다. 내가 지금까지 개발자로 남아 있을 수 있던 이유는 롤모델이 있기 때문이다. 개발자는 어떻게 해야 하는지 보고 따라 할 수 있어야 한다. 눈에 보이지도 않는 요정과 같은 모습은 따라 할 수가 없다. 처음에는 어렵겠지만 개발자 롤모델을 키워내야 한다. 개발자에게 모든 것을 원하는 만능 개발자 위주 정책이 없어져야 한다. 한분야의 전문가라도 개발자로 일할 수 있게 해야 한다. 

 

회사가 준비가 되었다고 다는 아니다. 개발자 개인들도 생각을 바꿔야 한다. 본인의 성향을 보고 진로를 결정해야 한다. 인간의 두뇌 구조는 개발자와 관리자 모두를 잘할 수 있도록 되어 있지 않다. 물론 사회적 제도적 제한이 있어서 본의아닌 선택을 해야 하는 경우도 있지만 본인의 노력도 매우 중요하다. 개발자로 남고 싶으면 끊임없이 새로운 기술을 익혀야 한다. 시야도 넓혀야 한다. 비즈니스도 잘 알아야 한다. 개발자들이 서로 기술을 공유하고 경험을 나누며 같이 성장하려면 피어리뷰가 필수다. 

 

최고의 개발자들이 관리자나 다른 분야로 떠나고 신참들만 넘쳐나는 개발현장에서 경쟁력을 기대하기는 어렵다. 이런 관료적인 분위기를 소프트웨어 현장에서 없애지 않으면 우리나라 소프트웨어 미래는 없다. 나는 지금도 소프트웨어 경영자를 만나면 개발자 경력 보장이 얼마나 중요한지 역설 한다. 

 

물론 말 한마디로 30년차 개발자의 모습이 잘 그려지지 않고 실천하기는 어려울 것이다. 개발자 경력보장의 중요성에 대한 인식이 먼저 필요하다. 생각은 바뀌었는데 방법을 모르는 회사는 얼마든지 도와줄 의향이 있다. 그 중요성을 깨달은 것만으로도 이미 50%는 달성한 것이다. 

 

우리 주변에서도 할아버지, 할머니 개발자를 흔하게 보는 시기가 되면 소프트웨어 개발자들이 행복하게 일하는 세상이 이미 되어 있을 것이다.

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발자, 경력, 할아버지

  1. Blog Icon

    비밀댓글입니다

  2. 좋은 글 항상 잘 읽고 있습니다 ^^

똑똑한 개발자를 찾기 위한 인터뷰 전략

2014.04.24 23:15 by 전규현


잠시 후 Google blogger로 이동됩니다.






나는 오랫동안 많은 개발자 인터뷰에 참석했다. 여러 소프트웨어 회사에서 개발자 인터뷰를 어떻게 진행하는지 들을 수 있는 기회가 있었고 회사의 관계자 대신 면접관으로서 기술 인터뷰를 진행한 경험도 많다. 그래서 소프트웨어 업계에서 개발자 인터뷰를 어떻게 하고 있는지 알 수 있는 기회가 있었다. 

 

우리나라에서 개발자 인터뷰를 어떻게 진행하는지 보면 해당회사와 직접적으로 관련된 경력을 집중적으로물어본다. 구체적으로 무슨 프로젝트를 어떻게 진행했느냐? 무슨 기술을 다뤄 봤느냐? 이런걸 아느냐? 우연히 면접관이 아는 지식과 유사한 경험을 한 개발자는 재수좋게 시원하게 답변을 할 수있다. 또한 개발자는 경력에 대해서는 자신이 한 것이나 동료가 한 것이나 구분하지 않고 과장되게 설명하곤 한다. 

 

개발자의 역량보다 동일하거나 유사한 분야의 경험을 더 중시하여 개발자를 채용하는 것은 초단기적으로는회사에 급한 불을 끄는데는 도움이 되지만 중장기적으로는 좋은 전략이 아니다. 이는 마치 부품이 고장나서똑같거나 호환되는 부품을 갈아 끼우겠다는 전략과 별반 다를 바가 없다. 

 

이렇게 동일 경험 개발자를 선호하다보니 경쟁사 개발자를 데려오기도 하고 동종업계 이직금지 서약을 더욱 중요시 하게 되고 논란도 많다.이러다 보니 여러 분야에 손을 대고 있는 대기업은 어느 중소기업에서 개발자가 오더라도 동일 분야라고 주장을 하면 송사에 휘말릴 우려가 있고 개발자의 이직 자유권을 제한하기도 한다. 동일 분야 개발자를 특히 선호하는 이유는 회사의 개발 문화가 낙후되어 있기 때문이다. 

 

공유가 안되고 협업이 힘들어서 어느 개발자가 오더라도 능력을 발휘하는데 오래 걸린다. 이런 이유로 동일 경험 개발자 위주로 채용하는 현상은 개발자에게 이직의 범위를 축소시키고 기회를 박탈하게 된다. 소프트웨어 개발자는 자신이 일해왔던 분야 뿐만 아니라 거의 모든 분야에서 일할수 있다. 또 그렇게 일해야한다. 

 

물론 개발자 스스로가 다른 분야에 거부감이 있는 경우도 있지만 이 또한 환경이 그렇게 만든 측면이 크다. 문제는 회사가 문화적으로 프로세스적으로 준비가 되어 있는가이다. 여러 분야의 개발자가 섞이는 것은 개발자에게 기회의 확대외에도 다양한 경험이 창의적인 아이디어와 혁신에 도움이되어 소프트웨어 산업 전반적으로 꼭 필요하다. 

 

단기적인 부품교체를 하겠다는 생각이 아니라면 개발자를 채용할때 가장 중요한 것은 회사의 미래 개발에필요한 똑똑한 개발자를 뽑는 것이다. 고급 개발자에게 필요한 것은 3가지가있다. 첫째, 소프트웨어 이론 지식이다. 둘째, 공학적인 경험과 개발 문화적인 소양이다. 고참 개발자에게는 중요한 요소다. 셋째, 가장 중요한 논리적인 두뇌와 수학적인 능력, 그리고창의력이다. 

 

신입 개발자를 채용하는 경우라면 이중에서 세번째만 집중적으로 봐도 된다. 세번째를 확인할 수 있는 방법은 문제해결(Problem solving)능력을 확인할 수 있는 창의적인 질문과 코딩 테스트(Coding Test)다. 이 두가지로 개발자가 얼마나 논리적이고 수학적인 사고를 하는지, 또 창의적인지 확인할 수 있다. 

 

동일 분야 경험이 전혀 없더라도 회사가 문화적으로 프로세스적으로 준비가 되어 있다면 1, 2개월후에는 동일 경력만 있는 개발자보다 우수한 능력을 보여줄 수 있고 그 성과의 차이는 시간이 흐를수록 점점 벌어지게된다. 이중에서 코딩 테스트에 대해 좀 더 알아보자. 코딩테스트를 하는 회사가 과거보다 많이 늘었다. 하지만 코딩 테스트의 방향을 못잡고 엉뚱하게 진행하는 회사도 있고 코딩 테스트에 거부감을 가지고 있는 개발자들도 있다. 

 

사실 코딩 테스트를 한다는 것은 개발자에게 긍정적인 신호일 가능성이 더 높다. 개발자의 역량을 제대로 평가할 줄 알고 그 만큼의 대우가 있을 가능성이 더 높다. 가끔 소프트웨어 회사의 코딩 테스트를 보면 나도 통과하기 힘든 것 같은 문제들이 나오기도 한다. 동일분야의 상세한 경험이 없으면 풀 수 없는 문제가 대표적이다. 동일 분야 동일 경력 개발자를 채용하기 위한 방법으로 코딩 테스트를 사용할 뿐이다. 

 

이런 회사는 단기적으로 부품을 교체하겠다는 생각이라면 상관이 없지만 그렇지 않고 좋은 개발자를 뽑기 위한 목적이라면 잘못된 방법을 사용하고 있는 것이다. 역사를 배운다고 연도나 줄줄이 외워야 하는 것처럼 이런 것을 물어보는 쪽지 시험과 같은 코딩 테스트는 뛰어난 개발자를 놓치기 쉬운, 좋지 않은 방법이다. 

 

그런데 지금도 이런 문제들을 갖고 개발자를 채용하고 있는 회사들이 꽤 있다. 이런 현상이 벌어지는 이유는 회사에서 고참 개발자들에게 코딩테스트 준비를 하라고 하면 그 동안 암기식 교육에 익숙해서 이런 문제 밖에 못 내고 인사 담당자는 이를 평가할 능력이 없기 때문이다. 코딩 테스트시 집중적으로 봐야하는 것은 개발자의 논리적인 사고 능력과 문제해결 능력, 창의성이다. 

 

그러기 위해서 특정분야의 지식을 필요로 하는 문제는 삼가는 것이 좋다. 코딩 테스트에는 대략 5가지 방법이 있다. 아래 방법 중 한 두가지를 선택해서 코딩테스트를 진행한다. 

 

첫째, 온라인 사이트 코딩 테스트다. 지원자가 너무 많은 경우 정말 자격이 안되는 개발자를 거르기 위한 용도로 사용한다. 인터넷을 검색해 보면 이런 서비스를 제공하는 회사가 많이 있다. 지원한 회사에서 지정한사이트에 등록을 하고 자신이 선호하는 개발언어로 주어진 시간동안 코딩을 하면 된다. 

 

둘째, 24시간에서 며칠이 소요되는 프로젝트 테스트다. 좀더 가능성이 있는 개발자에게는 첫 번째 온라인 사이트를 이용한 코딩 테스트보다 몇 시간 또는 하루 이틀 걸릴 간단한 코딩 숙제를 주고 1~3일안에 온라인으로 제출을 하게 한다. 

 

이때는 개발자의 논리적인 사고와 창의력도 보고 코딩 스타일도 보게 된다. C사의 경우 이 코딩 테스트에서 95% 이상의 개발자가 탈락을 한다고 한다. 개발자들이 정말로 가고 싶어하는 유명한 회사가 아니고 이름이 잘 알려지지 않은 중소 소프트웨어 회사라 면이 방법을 사용하기 힘들다. 개발자들이 그냥 귀찮아서 포기할 가능성이 높다. 

 

셋째, 전화 코딩 테스트다. 전화를 이용해서 코딩 테스트를 하는 방법인데 위 방법보다 좀더 많은 것을 볼 수가 있다. 전화를 통해서 지원자와 대화를 하면서 화면을 공유할 수 있는 방법을 통해서 직접 코딩하는 것을 보면서 코딩 테스트를 진행한다. 

 

구글 드라이브 문서를 통해서 공유하기도 하고 이와 비슷한 공유가 가능한 온라인 편집기를 사용하기도 한다. 또는 스카이프 등 화면을 공유하는 소프트웨어를 이용하기도 한다. 이런 협업 도구를 통해서 코딩하는것을 직접보면서 면접관은 이런 저런 질문을 하고 개발자는 코딩하는 것을 설명하면서 진행한다. 토론식으로 진행도 가능함으로써 코딩 결과만 보는 것보다는 훨씬 많은 것을 파악할 수가 있다. 지역적으로먼거리에 있는 개발자를 검증하기 위해서 사용할 수 있다. 

 

넷째, 1~3시간 온사이트 테스트다. 지금까지의 방법은 다른 사람의 도움을 일부 받을 수가 있다. 하지만 온사이트 테스트는 확실히 본인만의 실력으로만 진행해야 한다. 이 방법은 인터뷰전에 혼자서 노트북에 직접코딩을 하는 것이다. 1~3시간안에 풀 수 있는 문제를 주고 컴파일 및 실행이 되도록 직접 코딩을 하는 것이다. 인터뷰시에는 코딩한 결과를 설명할 수 있어야 한다. 이런 테스트는 면접자에게 많은 시간과 부담을 주기 때문에 이에 합당하는 면접 비용을 지불하는 것이 좋다. 

 

다섯째, 면접관과 함께 하는 칠판 코딩 테스트다. 내가 가장 선호하는 방법은 짧은 시간에 진행하는 칠판 코딩 테스트다. 가장 많은 것을 볼 수 있다. 칠판이라는 특성 때문에 문법은 보지 않는다. Pseudo Code(실행되지 않고 로직만 표현한 소스코드)로 작성을 해도 된다. 코딩결과만 보는 것이 아니라 어떻게 진행하는지더 눈여겨 본다. 

 

개발자가 문제를 정확하게 이해했는지 면접관에게 물어보는 자세도 중요하게 본다. 일부러 질문을 유도하기 위해서 문제에 질문이 필요한 함정을 넣기도 한다. 이를 질문도 없이 일사천리로 코딩을 해나가면 의심을 해봐야 한다. 

 

코딩을 하면서 중간 중간에 적절하게 설명하는 자세도 아주 중요하다. 그런데 우리나라 개발자들은 설명없이 그냥 써내려가는 경우가 많다. 평상시에 개발하는 방식이 그대로 반영된다. 이때 면접관이 지적하는 것에 대해서 어떻게 대응하는지도 중요하다. 코딩을 다하고 나면 개선점을 가지고 간단한 토론을 하는 것이 좋다. 이렇게 면접관과 상호작용이 잘 되는 개발자는 나중에 개발시에도 공유 및 커뮤니케이션이 잘될 수 있다. 

 

이렇게 10~30분동안 진행하는 코딩 테스트는 평소 개발의 축소판이고 창의력, 문제 해결 능력, 커뮤니케이션 능력까지도 볼 수 있는 좋은 수단이다. 실제 인터뷰에서 경력은 화려한데 칠판 코딩 테스트에서 탈락하는 경우가 부지기수다. 기본적인 논리적 사고와 수학적인 능력도 없이 본인이 설명하는 수 많은 프로젝트를 수행했고 높은 연봉을 받은 고참 개발자들을 보면 안타깝기 그지 없다. 

 

누가 설계를 해야하고 누가 프로그래밍을 해야하는지 구체적인 구분도 없이 고참이고 경력이 많다는 이유로 프로젝트의 설계를 주도하고 망쳐와서 정작 경력이 적더라도 똑똑하고 뛰어난 개발자들이 성장의 기회를 놓치게 된다. 개발자에게 진짜로 필요한것이 무엇인지 생각해보자. 

 

회사에서 진짜 뛰어난 개발자를 구분할 수 있고 그에합당한 대우를 할 수 있을때 우리 주변에 연봉 수억의 개발자들이 바글바글하게 될 것이다. 그래야 뛰어난두뇌를 가진 사람에게 소프트웨어 개발자는 충분히 매력적인 직업이 될 수 있을 것이다. 그쯤되면 소프트웨어 생태계가 더욱 좋아지고 개발자에게는 롤모델도 생기고 개발자에 대한 전반적인 인식과 대우도 더 좋아질 것으로 확신한다.

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발자, 인터뷰, 채용, 코딩테스트

  1. Blog Icon

    비밀댓글입니다

여자 개발자가 희망이다

2014.03.16 23:21 by 전규현


잠시 후 Google blogger로 이동됩니다.





소프트웨어 회사를 포함해서 많은 기업들이 개발자가 부족하다고 아우성이다. 이렇게 개발자가 부족하게 된 이유는 열악한 개발 환경에 따른 뛰어난 개발자들의 이탈과 저급개발자 양산 등 여러 환경, 정책적인 문제가 있지만 여자 개발자에 대한 편견과 차별도 주요한 이유라고 본다. 

 

여자 개발자에 대하여 여러 가지 편견이 있다. 여자 개발자는 실력이 없다, 책임감이 부족하다, 감정적이다, 언제 그만둘지 모른다는 등이다. 하지만 이러한 편견은 남성 중심적인 사고에 기인한 것이 많고, 그 동안의 개발 환경이 야근강요, 코딩 중심, 무모한 프로젝트와 같은 성격을 띄는 경우가 대부분이어서 전투력 강한 개발자를 선호하다 보니 이런 편견이 생긴 것으로 생각한다. 

 

필자가 경험한 바로는 여자 개발자들이 공유, 협업 문화에 좀더 잘 적응하고 아키텍트로도 더 뛰어난 경우를 많이 보아왔다. 남자, 여자 누가 더 개발자로서 우수하다고 말하는 것이 아니라 서로 다른 특성이 있으므로 이를 이해할 필요가 있다는 것이다. 

 

뛰어난 소프트웨어는 다양한 특성을 가진 사람들이 모여서 협업을 하고 그 다양성을 기반으로 창의적인 아이디어가 많이 나와야 탄생할 수 있다.

 

현재 소프트웨어 업계에 여자 개발자가 절대적으로 부족한 이유는 여러 가지가 있겠지만 일단 누구라도 일하기 힘든 환경이 큰 요인이다. 이런 환경에서 상대적으로 남자들이 더 잘 버티기 때문에 더 많이 남아 있다고 생각한다. 

 

현재의 기형적인 개발자 성비를 개선하는 것이 소프트웨어 업계에는 꼭 필요한 과제이고 이를 위해서는 누구라도 일하기 좋은 환경을 만드는 것이 우선일 것이다. 그러기 위해서 먼저 여자 개발자에 대한 편견과 차별을 없애야 한다. 

 

많은 회사들에서 크든 작든 여자 개발자에 대한 차별이 존재한다. 비공식적이지만 급여의 차이도 존재하는 회사도 있다. 승진의 기회도 다르다. 이런 이유는 여자 개발자는 결혼하거나 출산을 하면 결국 그만둘 것이라는 선입관이 존재하기 때문이다. 

 

소프트웨어 업계에서 여자 임원이 절대적으로 부족한 것을 보면 이런 현상을 알 수 있다. 물론, 남자와 여자가 특성적으로 완전히 동일하다고 말할 수는 없다. 차이가 있고 그러하기 때문에 서로 보완이 된다. 필자의 경험과 교육학적인 여러 도서를 보면 선천적, 후천적인 남녀의 차이는 이런 것들이 있다. 물론 필자의 개인적인 생각도 있으므로 의견이 다를 수도 있다. 

 

우선 남자 개발자들은 도전정신이 강하고 무모한 자산감도 가진 경우가 많다. 치열한 경쟁에 거부감이 좀더 적고, 상대적으로 체력이 뛰어나서 야근에도 잘 버틴다. 남자 개발자가 좀더 코딩을 잘한다는 의견은 입사 이전에 또는 어렸을 때부터 코딩을 경험할 기회가 좀더 남자에 많기 때문이 아닌가 생각된다. 

 

이러한 남자들의 특성이 현재의 열악한 개발 환경에 좀더 통할 수 있는 측면이 있는건 사실이다. 무리한 일정에 잦은 야근,  협업은 없고 혼자서 달리는 코딩이 현재 흔하게 볼 수 있는 개발 환경이다. 그리고 요즘은 많이 바뀌고 있지만 부어라 마셔라 회식 문화도 상대적으로 남자들에게 더 적합하다. 

 

그런 반면 여자 개발자들은 커뮤니케이션과 협업에 더 유리한 특성을 가지고 있다. 서로 경쟁하기보다는 서로 도우려는 특성도 있다. 모두 그렇다는 것이 아니고 평균적으로 좀더 그렇다는 의미다. 

 

남자들은 모른다고 말하는 것을 꺼려하는 경향이 있다. 그래서 끝까지 도움을 받지 않고 혼자서 해결해 보려고 한다. 하지만 여자들은 초기에 도움을 받아야 할 것을 구분해서 적절한 도움을 받는데 익숙하다. 모른다고 말하는 것에 대해서 자존심의 상처를 덜 받는다. 

 

이것은 소프트웨어 개발 문화 중 협업의 문화에서 매우 중요한 요소다. 혼자서 엉뚱한 방향으로 내달리지 않고 적절할 때 서로 묻고 의논하고 도와야 제대로 된 방향으로 갈 수 있다. 그런 능력이 상대적으로 여자 개발자에게 더 많이 보인다는 것이 필자의 의견이다. 이런 특성에 기인해서 여자 개발자 중에서 아키텍트로서의 능력이 더 뛰어난 경우를 많이 보았다. 

 

설령 뛰어난 아키텍트 재능을 가진 개발자가 있다고 하더라도 우리나라와 같은 개발 환경에서는 눈에도 잘 안띄고 실력을 발휘하기도 어렵다. 

 

여자 개발자들에게는 출산과 육아의 장애물이 존재한다. 우리나라에서는 출산과 육아는 개발 경력의 큰 단절이고 2,3년만 단절되면 현업 복귀가 쉽지 않은 분야이기도 하다. 실력적으로는 현업복귀가 가능해도 기업에서 꺼리는 경우도 많다. 

 

재택근무로도 무리 없이 일할 수 있지만 재택근무를 그렇게 효과적으로 할 수 있는 회사가 그렇게 많지 않은 것이 안타까운 현실이다. 

 

현재와 같이 여자 개발자들이 꾸준히 일하기 어려운 환경은 여자들에게만 불리한 것이 아니라 모든 개발자에게 불리하며 이런 특성 때문에 개발이 3D 업무라고 불린다. 

 

경쟁보다는 협업을 하고 혼자 달리기 보다는 공유, 토론, 의논을 적절히 하는 환경, 무모한 일정에 따른 품질 저하와 그에 따른 야근의 악순환 보다는 합리적인 프로젝트, 재택근무를 해도 개발에 전혀 지장이 없는 프로세스, 시스템 그리고 문화, 이런 환경과 문화가 여자 개발자뿐만 아니라 모두에게 필요하다. 지금같이 여자 개발자들이 살아남기 힘든 환경이 계속된다면 소프트웨어 업계 전체가 살아남기 힘들 것이다. 


이글은 ZDNet Korea에 기고한 칼럼입니다. 



저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발자, 여자

  1. 근데 실제로는 프로그래밍 코딩은 남자가 훨씬 낫더이다 자부심 때문에 융통성 없는건 인정하지만

  2. 근데 여자 개발자가 희망이라는거 조차도 차별적인 발언 아닌가 툭하면 여자가 어쩌고 남자가 어쩌고 요즘은 사람들이 언론에서 지역분쟁도 모자라서 남녀 분쟁까지 부추키는거같네

개발자를 잘못 채용하는 방법

2010.04.19 15:23 by 전규현


잠시 후 Google blogger로 이동됩니다.






뛰어는 개발자를 보유하는 것은 소프트웨어 회사의 절대 필요 조건입니다.

뛰어난 개발자를 보유하는 방법은 내부 개발자들이 잘 성장할 수 있도록 좋은 환경과 기회를 제공하는 것도 중요하지만 기본적으로 뛰어난 개발자를 뽑아야 합니다.

적어도 능력은 B급 이상은 되야 입사 후 성장 가능성이 높습니다. 하지만 좋은 개발자들을 채용하는 것은 그렇게 쉽지 않습니다. 공채, 헤드헌터, 소개 등 갖가지 방법을 써도 쉽지는 않지만 흔히 잘못된 방법이 무엇인지는 쉽게 알 수 있습니다.

어떤 경영자들은 같이 일할 동료들을 개발자 채용 인터뷰에 참여시킵니다. 같이 일할 동료들이 보고 같이 일하기 좋은지 판단하라는 이유에서 입니다. 팀웍이 중요하다는 이유에서 입니다.

하지만 이 경우 잘되는 경우도 있지만 문제가 있는 경우도 많습니다. 기본적으로 같은 레벨에서 개발자를 평가하는 것은 쉽지 않습니다. 즉 인터뷰를 할 능력이 없는 사람에게 인터뷰를 맡기는 것과 비슷합니다. 그런 정도의 인성은 상급자들이 더 잘 볼 수 있습니다.

인터뷰에 참여한 개발자의 입장에서 보면 자신보다 뛰어난 개발자를 뽑는 것은 상대적으로 자신의 비중이 낮아지고 결국에는 자신에게 손해를 가져오기 때문에 본능적인 자기 방어차원에서 그런 개발자들의 채용에 반대하곤 합니다. 이유야 다른 곳에서 찾지요.

채용인터뷰는 특히 개발자 채용인터뷰는 CTO와 개발팀장 등 충분히 기술적인 면과 조직적인 면을 모두 볼 수 있는 사람이 해야합니다. 동료가 될 개발자들에게 인터뷰를 맡기는 것은 인터뷰의 책임이 있는 사람들이 기술적인 식견이 부족해서 기술적인 판단의 책임을 개발자들에게 전가하는 것일 수도 있습니다. 이런 경우 차라리 외부 전문가에게 부탁을 하는 것이 나을 수 있습니다.

개발자는 똑똑하며 긍정적인 사람을 뽑아야 합니다.

하지만, 현실에서는 경력직을 뽑을 때는 해당 분야에서 일해봤는지가 가장 채용의 조건이 되곤 합니다. 이런 개발자들이 똑같은 일을 하다가 똑같은 분야로 옮긴다는 것은 실력이 그리 뛰어나지 않고 그저 경험만 있을 가능성이 높습니다. 정말 일을 잘 했다면 이전 회사에서 더 좋은 대우를 받으며 더 오래 일 했을 겁니다. 뛰어난 개발자들이라면 이런 식으로 옮기지 않습니다. 자신의 미래에 도움이 되는 분야나 최신 기술을 배울 수 있는 곳으로 옮길 겁니다. 또한 퇴사 이전에 이미 누가 데려가지 이렇게 인력 시장에 잘 나오지를 않습니다. 

따라서 급하다고 동일 경력 개발자라는 이유만으로 뽑는 것은 며칠 전에 그만 두었거나 곧 그만둘 개발자의 대타는 될 수 있어도 장기적으로는 회사에 손해가 될 수 있습니다. 

결론은 항상 좋은 개발자를 뽑기 위해서는 당장 발등에 떨어진 불을 끄기 위해서가 아니고 평상시에 꾸준히 노력해야 한다는 겁니다. 그래서 당장 급해서 경력직을 뽑는 것보다 신입으로 미리 준비를 해서 꾸준히 키워 놓은 것이 더 좋은 결과를 가져올 때가 많습니다. 하지만 회사의 프로세스나 개발문화가 엉망이라면 위의 모든 것이 공염불이죠. 이런 경우는 어쩔 수 없이 발등의 불끄기 모드로 채용을 할 수 밖에 없습니다.

결국 악순환이 또다시 시작되는 거죠.

채용은 단발성으로 진행하지 말고 장기적인 안목을 가지고 꾸준히 노력해야 합니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.


저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발자, 인터뷰, 채용

  1. 잘 읽었습니다.
    글 내용에는 동의합니다만, 실천하기는 무척 어려운 사항이네요.

  2. 안녕하세요. 지킬박수님

    사실 평소에 채용을 위해 꾸준히 노력하는 것은 관리자의 의무입니다. 대부분 의무를 태반하는 것이지요. 또는 회사에서 개발자를 무슨 공장에서 부품 고장나면 교체하듯이 결원이 생길 때만 채용할 수 있도록 하는 회사도 있습니다.
    사실 그렇게 어려운 것이 아닌데, 회사 정책상 또는 게을러서 못하고 있는 경우도 의외로 많습니다.

  3. 댓글 고맙습니다.^^

    말씀하신 게 맞습니다. 어려움은 사장님을 어떻게 설득하느냐에 있습니다. 결원이 생기기 전에 좋은 사람을 미리 확보해 두는 식으로 허용되지 않는 경우 말이죠. 정말 참 어렵네요.

  4. 개발자를 미리 확보해두는 것은 어렵습니다. 평소에 채용을 위해 노력한다는 것은 개발자를 미리 뽑아 놓는 다는 의미는 아닙니다. 평소에 꾸준히 개발자들을 물색해 놓고 좋은 개발자들과 관계를 유지해 놓다가 기회가 되면 데려 올 수 있도록 하는 것도 한 방법입니다.

  5. 평소에 꾸준히 개발자를 물색해 놓는 거, 필요한 일이겠네요. 노력도 해 봐야겠고요. 이 부분은 미처 생각하지 못했습니다.

    다만, 이 또한 쉽지 않다는 생각도 함께 듭니다. 앞서 말씀 드린 대로 결원이 생기기 전에 미리 준비하지 않는 문화를 가진 조직에서는 평소에 꾸준히 개발자를 물색해 놓는 노력을 할 만 한 여유(?)를 만들기가 어렵거든요.

    이게 개인적으로 노력한다고 해서 가능한 것인지 좀 더 고민해 보겠습니다.

  6. 채용에 대한 노력은 관리자의 R&R에 명시적으로 포함이 되어 있어야 합니다. 이를 위한 시간 및 예산이 제공되어야 하며 평가에 반영이 되어야 합니다.
    흔히 관리자의 R&R에 개발자 retain만 포함되는 경우가 많지만, 채용을 위한 노력도 그에 못지 않게 중요합니다.
    개인이 회사의 지원 및 관심도 없이 혼자서 노력하는 것은 쉽지 않습니다.

  7. 예전 개발 환경에서는 기술/업무의 규모가
    크지 않았기 때문에 못하는 사람이나 잘하는 사람이나
    크게 차이가 없었지만 최근 동향을 보면 그 규모나 난이도가 예전과 비교 했을 경우 엄청난 차이가 납니다.

    못하는 사람과 잘하는 사람이 단순 본수로 판단했을 경우
    10본이상 차이가 난다고 합니다.

    즉 앞으로 회사 경쟁력은 테크니컬 인재를 많이
    가지고 있는 회사가 살아 남을 것 같습니다.

    최근 프로젝트를 하면 누가 고급이고 누가 중급인지
    판단이 애매 합니다.

  8. 개발자를 본수로만 따지는 프로젝트가 많죠. ^^

  9. 불러주는 사람도 없고..
    있어도 항상 망하는 회사에만 있는 저는 능력없는 나쁜 개발자인거군요 ㅠ.ㅠ
    이렇게 3년 일하니... 긍정적인 생각도 다 가출해버렸어요 OTL

  10. 구차니님 안녕하세요.
    운이 없으신 거겠죠. ^^ 제 글이 개발자 입장에서는 오해를 일으킬 수 있는 내용이네요. 죄송합니다.
    개발자도 한 회사에 평생 몸 담겠다는 마음가짐 보다는 적절한 때 회사를 잘 옮길 수 있도록 평소에 노력을 해 놓아야 한다고 생각합니다. 그래야 인연이 되는 좋은 회사도 만날 수 있고 그에 필요한 준비도 미리 할 수 있습니다.

  11. Blog Icon
    현실직시

    님께서 작성하신 글은 제가 보기엔 교과서적인 내용입니다.
    저도 여러개발과 수장 노릇도 해봤지만 님의 블로그 내용은 현실적 괴리가 있네요.
    특히, 결론부분은 인력시장을 잘 이해하지 못하신 것이 아닌지요?

    대기업같이 인력 풀이 잘되어 있는 곳이 적절한 예는 아닌 것같고
    그외의 회사를 예로 든다면 개발자를 잘 채용하는 비결은 적정한 보수입니다.
    신입을 키워 향후 활용하는 것은 그때뿐이며 다 자기능력에 대응하는 보수를 찾아 나갑니다.
    남게되는 경우는 대부분 인맥관계나 그외의 사정때문이지 그 회사가 키워줘서 남아 있는 것이 아니지요.
    이런 행태가 솔직히 비난받을 일은 아닙니다.

    경력의 경우 가장 필요한 덕목은 역량도 중요하지만, 책임감과 문제해결능력이 신입보다 높다는 것이지요.
    당장 발등에 불이 떨어져도 경력자가 위의 조건에 충족한다면 된 것입니다.
    제 경험상, 어차피 새로 온 조직에 적응과 업무이해를 위해 가르쳐주는 것은 대부분 경력자가 이해가 더 빠릅니다. 그래서 회사의 신입은 이직하기 전 열심히 배워야 하지요.
    그리고 퇴사 전 이미 누가 데려간다는 것은 대기업이 아닌 이상 대부분 다 인맥으로 가는 것입니다. 그런데 아는 사이이다 보니 연봉협상이 편하질 않죠. 누가 데려가지 않아서 실력이 낮을 것이다라는 편견은 아니시겠죠?
    대부분의 사람들이 적정한 보수와 하고싶은 분야의 일을 찾아 나온것입니다.

    그리고 동일개발자 부분은 저도 동의합니다.
    사실 개발자들은 한우물만 파서는 안됩니다. 일례로 Pro*C 부분만해도 그리 어려운 것이 아님에도 일부 금융권에서는 Pro*C 경력자만 뽑더군요. 전산프로젝트는 종합예술같아서 한가지 부분만 가지고 퍼포먼스 향상을 기대하지 못하는데..
    다양한 지식과 경험을 겸비한 개발자의 개발 능력은 한우물만 판 사람보다 생각의 틀이 넓습니다.

    컨설턴트 하실 때 저와같은 생각을 가지는 사람도 있다는 것을 염두해 두셨으면 합니다.

  12. 좋은 의견 감사합니다.
    경력직 개발자를 채용하는 첫번째 조건은 연봉 맞습니다. ^^ 그런데 발등에 불떨어진 듯 개발자를 뽑으면 높은 연봉을 주고도 좋은 개발자를 찾기가 어렵죠. 작은 회사들은 개발자를 미리 뽑아 놓는 것은 어렵죠. 그렇다고 하더라도 평소에 채용을 위해서 활동을 해야 할 것들이 많습니다. 그런데 대부분 평소에는 전혀 신경을 쓰지 않습니다. 평소에 준비를 잘 해놔야 필요할 때 좋은 개발자를 채용하기가 용이합니다. 연봉은 필요한 만큼 줘야하지요.

    그리고 누가 데러가지 않는 개발자는 실력이 낮다는 것은 아닌데, 제 글을 다시 읽어보니 그런 오해를 할 수 있는 문맥이군요. - -; 당연히 묵묵히 일하는 뛰어난 개발자들도 많이 있죠. 하지만 인력시장에서 좋은 개발자를 찾는 것이 쉽지 않은 것은 경험상 사실이죠. 여전히 여러 인맥을 통해서 뛰어난 개발자를 찾고 꾸준히 관계를 유지해 놓다가 서로 연결을 해서 데려가는 것은 좋은 개발자를 채용하는 효과적인 방법입니다.

    어쩔때는 제가 쓴 글을 다시 읽어보면 이번 글과 같이 의도하지 않은 의미로 이해가 될 수 있는 글들이 종종 있습니다. 이글도 관리자나 경영자의 시야에서 작성했었는데, 개발자 입장에서는 기분이 나쁠 수 도 있겠네요. 나중에 개발자 입장에서 이직에 대해서 글을 써봐야겠습니다.

    좋은 지적 감사합니다.

  13. 참으로 공감하는 내용입니다. 개발자 채용시 기술면접을 외부전문인에게 맡기는 것. 객관성을 유지할 수 있을 것 같습니다. 만약에 개발자 면접을 주관해야 하는 입장이라면 새로 면접하러 온 개발자의 능력을 자신의 능력과 경험에 견주어서 판단할 수도 있겠습니다. 말쓰하신대로 자신보다 뛰어난 개발자가 들어왔다거나, 정치적으로 자신이 위축될만한 인재라고 느낀다면 위축되고 경계하겠죠. 실제로 이런곳 여러군데 봤습니다.ㅎ
    장기적인 안목 그것이 중요할것 같네요 ( 참~ 전 이번 병고 이후 새로운 직장에 몸을 담을 예정입니다. 엔지니어링과 IT개발은 취미로 삼고 말이죠. 앞으로 규현님과 비슷한 일을 할 것 같은 예상이 듭니다. 많은 조언 부탁드리겠습니다.:)

  14. 안녕하세요. moova님
    몸은 많이 나아지셨나보네요. 다행입니다. 블로그에서 자주 뵙기를 희망합니다.

  15. 이글에 추천한표 던집니다. :)
    근데 이런 좋은 글은 저같은 개발자들이 공감하는거 보다도,
    각회사 인사담당자들이 좀 읽고 느껴야 하는데 말이죠.

  16. 안녕하세요. kevin님
    호주에 계시나봐요? 멋진 블로그도 가지고 계시고요. 반갑습니다.
    앞으로 종종 들려주세요.

  17. 이번에 "프로젝트가 서쪽으로 간 까닭은" 이라는 이름으로 번역되어 나온 책이나, 조엘의 책 등에서도 언급했고, 개인적으로도 그동안 인터뷰를 했던 경험으로 보자면 말씀하신 것과 같이 외부인력이나 CTO만으로는 부족합니다. 팀에서 일할 사람을 뽑는데 외부인력이 무슨 내용을 어떻게 알까요? 실제개발에 손놓은지 오래 된, 회사의 기술적 나갈 방향을 결정하는 CTO가 세세한 기술 인터뷰를 제대로 할 수 있을까요?
    함께 일할 사람을 뽑는데 있어 동료들만큼 기술인터뷰를 제대로 할 수 있는 사람들은 없다고 생각합니다.

    1차 기술 인터뷰를 동료들이 직접 하고, pass한 사람들에 대해서 CTO나 다른 사람들이 발전가능성/인성/조직 친화력? 등을 점검해야 합니다.
    최소한 전화인터뷰 - 팀 기술인터뷰 - 최종인터뷰 의 3가지 정도 과정을 거치는 것이 좋더군요.

    자신보다 일을 잘하는 사람을 일부러 떨어뜨린다? 글쎄요, 한명이라도 더 일 잘하는 사람이 들어왔으면 하는 바램으로 가득찬 게 개발자 집단이고, 만약 자신보다 일을 더 잘할 것 같아서 떨어뜨린다면 그 조직은 이미 정치가 난무하는 비효율의 하급 개발자들이 넘친다고 밖에 볼 수 없을 것 같습니다.

    A급 인재는 A급이나 S급 인재를 데려오지만, B급 인재는 자신보다 못한 사람들을 데려온다고 했던 조엘의 이야기가 생각나네요. 스타트업부터 시작해서 회사가 존재하는 한 '우수인력 유치'를 지속적인 프로젝트로 진행해야 하는 이유가 여기에 있을겁니다.

  18. 안녕하세요. 우울한 딱따구리님
    좋은 의견 감사합니다. 사실 CTO만 하더라도 우리나라에서는 상당히 왜곡된 이미지를 가지고 있습니다. 한마디로 우리나라 CTO는 기술을 잘 모르는 사람이 많죠. 그래서 말씀하신 내용이 일리가 있는 것 같습니다.

    거의 대부분의 소프트웨어 회사는 B급, C급 인재가 넘쳐나고 A급, S급 인재는 찾기 어렵습니다. 상황이 이러다보니 채용시에도 좋은 개발자를 가려내기 힘든 것 같습니다.

  19. Blog Icon
    jp

    B급, C급 인재에 대한 대책은 없나요?.^^..

  20. 안녕하세요. jp님
    어느 조직이나 다양한 인재가 필요합니다. 문제는 A급인제인줄 알고 뽑았는데, C급인재인 경우입니다.
    보통의 소프트웨어 회사는 A급인재 10~20% 정도, 그 외에는 B, C급 인재로 채워집니다. 물론 B,C급 인재를 키워서 역량을 갖추게 하는 것도 중요하지만, A급인재가 하나도 없는 회사는 또 곤란합니다.

    회사 입장에서는 그런 것이고, 개발자 개인 입장에서 자신은 B급, C급이 되겠다고 하는 사람들은 없을 겁니다. 그러므로 자신의 목표도 A급, S급에 맞춰야 겠죠.

  21. Blog Icon

    별로 공감이 안가네요.

    같은분야로 전직하는 사람은 위에서 얘기하고 있는 전제인 "실력이 있으면 더 좋은 대우를 받는다" 라는게 안들어맞기 때문입니다.

    오히려 실력이 있던 말던 대우는 똑같이 해주니까 그나마 실력이 있는 사람은 같은분야로 옮기고 실력이 없어서 옮길자신조차 없는사람이 그 회사에 눌러잇죠

  22. Lyn님 안녕하세요.

    핵심과는 좀 다른 글이군요. ^^
    제가 말하는 실력과는 좀 다른 기준을 가지고 있을 수 있는 것 같네요. 여기서 실력이란 오랜 공력에 따른 Domain지식 보다는 진정한 SW개발 실력, 즉, 분석/설계 등 공학적인 경험과 실력을 말합니다.

    실력이 있으면 좋은 대우를 받는다는 것은 음~ 회사마다 다르고 좋은 대우 받는 것은 상황에 따라서 완전히 다른 것 아닐까요?

    실력이 차이가나도 똑같은 대우을 해주는 회사는 호봉제 같은 회사인데 대부분의 회사는 실력에 따라서 차등 대우를 해주려고 노력하고 있고, 하지만 정확하게 실력에 따라 대우을 못해 주는 것이 현실이기는 합니다.

    여기서 핵심은 급하다고 동일 경험이 있는 개발자라고 마구 뽑다 보면 실력 있고 회사의 미래에 도움이 되는 개발자를 뽑기 어렵다는 것입니다.

    개발자는 동일 Domain 경험보다는 "문제 해결 능력" 등 근본적인 실력과 공학적인 경험 및 실력을 보고 뽑는 것이 회사의 미래에 더 좋다는 것입니다.

    ^^

스마트폰 앱스토어가 진짜 대박이 아닌 이유

2010.02.09 13:58 by 전규현


잠시 후 Google blogger로 이동됩니다.





요즘 스마트폰이 IT 이슈의 정점에 있어서 스마트폰 관련 글을 계속 올리게 됩니다.
개발자의 한사람으로서 스마트폰의 급속한 확대는 좋은 징조임이 분명합니다. 하지만 종종 스마트폰 어플리케이션을 만들어서 앱스토어에 올리면 쉽게 대박을 맞을 수 있을 것 같은 기사들이 눈에 띕니다.


물론 거품을 경고하는 기사들이 많은 것은 사실이지만 좋은 것만 보인다고 대박 기사가 더 눈에 들어오는 것은 사실입니다. 개발자들은 "실패담은 내 이야기는 아닐거야"라고 자신에게는 관대한 판단을 내기는 것이 일반적입니다.

이런 종류의 기사들을 읽어보면 전문가들이 말을 인용하는 칼럼형식의 기사는 좀 나은데 기자들이 직접 작성하는 누구나 혼자서 쉽게 소프트웨어를 개발해서 성공할 수 있다는 식의 기사가 많습니다. 그래서 현 상황을 좀 냉정하게 바라보고자 합니다.

긍정적인 측면

확실히 앱스토어가 개발자들에게는 기회의 땅입니다. 어플리케이션을 만들기만 하면 바로 전세계 소비자와 바로 만날 수 있는 기회를 제공했습니다. 마케팅을 얼마나 잘하느냐는 다른 이슈이지만, 어마어마한 마케팅 비용을 들이지 않고도 일단 소비자와 접할 수 있다는 것은 엄청난 기회입니다. 정말 좋은 소프트웨어가 마케팅 비용이 없어서 사라지는 것을 막을 수 있습니다.

또한 스마트폰 앱 시장은 계속 커지고 있고 잠재 고객은 점점 늘어가고 있습니다. 
That's it.

부정적인 측명

기회는 균등합니다. 나에게 기회인 것은 전세계 모든 개발자들에게 동일한 기회입니다. 초창기를 제외하고는 소비자와 쉽게 자신의 어플리케이션을 보여줄 수 있는 것이 그리 매력적인 조건이 아닐 겁니다. 정말 좋은 소프트웨어가 아니면 이 장점이 큰 장점이 아닙니다. 또한 스마트폰 앱 시장이 점점 커지면서 메이저 소프트웨어 업체들이 뛰어들 준비를 하고 있습니다. 기존의 시장과 별반 다를바 없는 치열한 전투장이 될 겁니다.

시장은 그렇다 치고, 개발자 입장에서 바라보도록 하죠.

스마트폰이라고 해서 소프트웨어를 개발하기 더 쉬워진 것은 아닙니다. 잘 만들어진 Framework를 보면 개발이 더 쉬운 것처럼 착시현상을 일으키기도 하지만, 이것이 소프트웨어 개발 전체 프로세스에 미치는 영향은 5%도 되지 않습니다. OOP 컨셉이 없는 개발자들은 오히려 뒤죽박죽을 만들어 버리기 일쑤입니다. SDK를 이용한 코딩보다도 스펙을 제대로 정하고 설계를 하고 테스트를 하는게 비중이 더 높습니다. 이는 기존의 다른 소프트웨어를 개발하는 것과 별단 다르지 않습니다. 즉, 기존에 소프트웨어를 잘 개발하던 개발자나 회사가 이또한 잘 할겁니다.

스마트폰 앱이라고 해서 한번 만들고 끝나는 것이 아닙니다. 일반적으로 소프트웨어는 유지보수 비용이 개발비용의 2~5배 정도 들어간다고 합니다. 그래서 한번 만들어놓은 앱을 꾸준히 유지보수를 해야 하는데, 개인이 이를 감당하기에는 어려움이 있을 수 밖에 없습니다. 진짜 전업으로 매달려야 합니다. 또한 버그 관리, 소스관리, 스펙 관리가 그렇게 쉽지 않습니다. 기존의 소프트웨어 회사들도 크나 작으나 이들을 잘 해내지 못하는 것이 현실입니다. 그렇다고 혼자 개발을 한다고 이 이슈가 사라지지 않습니다. 진짜 혼자 다 해야 합니다.

또, 어쩌다 꽤 인기있는 앱을 만들어서 중박정도를 했다고 해도 꾸준히 매출을 유지하기 위해서 업그레이드와 새로운 제품을 계속 만들어내야 합니다. 앱 개발이 전업이 되었다는 얘기는 꾸준히 수익을 창출해야 한다는 얘기입니다. 회사라면 크나 작으나 나름 각 분야의 전문가들이 힘을 합쳐서 일하기 때문에 진짜 자신이 잘하는 분야에 집중할 수 있어서 꾸준히 발전해 나가는 것이 혼자 북치고 장구치고 하는 것보다는 유리합니다. 자칫하면 수주대토(守株待兎)가 될 수 있습니다.

소프트웨어 개발이라는 것의 대부분은 팀으로 일을 했을 때 더 잘 할 수 있는 것들인데, 혼자서 한다는 것은 한계에 부딪히게 됩니다.  아이디어의 한계, 기술의 한계가 그겁니다. 물론 혼자 일하는 것을 좋아하는 개발자들중에서는 팀웍을 이뤄서 제대로 일하는 방법을 모르기 때문인 경우도 있습니다. 어떠한 경우라도 혼자서 1인회사를 해나가는 것은 쉽지 않은 결정입니다.

이미 소프트웨어 개발에 상당한 공력을 가지고 있는 개발자 몇명을 제외하고는 아무리 좋은 아이디어로 좋은 앱을 개발했다고 하더라도 혼자 개발하는 것은 스스로의 성장에도 지장을 줄 수 있습니다. 물론 이런 시도는 도전의식과 비즈니스 경험을 쌓을 수 있어도 소프트웨어 개발자로서의 경험은 상대적으로 놓치게 됩니다. 자칫 평생 혼자 개발해야 편한 개발자가 될 수도 있습니다. 실패에서 얻는 것도 있지만 잃는 것도 크다는 것을 명심해야 합니다.

소프트웨어 개발자로서 사회에 첫발을 디뎠다면 아무리 대학때 소프트웨어를 좀 개발해 봤어도 조직에서 팀을 이뤄서 개발하는 방법과 그 문화를 어느정도 익히는 것이 필요합니다. 물론 좋은 환경의 소프트웨어 회사라야 하겠죠. 그리고 나서도 확신이 선다면 시도해볼 수 있는 도전이라고 생각은 합니다. 하지만 결코 기존의 소프트웨어 환경에 비하여 성공확률이 더 높아졌다고 생각해서는 안됩니다. 이또한 노력하는 사람에게 더 많은 기회를 제공할 겁니다. 자신의 성공확률에서 바뀐 것은 아무것도 없습니다.

이 상황을 너무 부풀려서도 너무 축소해서도 안됩니다. 확실히 기회가 생긴 것은 맞습니다. 하지만 냉철한 가슴으로 생각하고 도전해야 합니다. 또, 이를 이용해서 부추기는 선정적인 기사는 좀 줄어야 하겠습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by Mykl Roventine
저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발자, 대박, 문화, 버그관리, 소스관리, 스마트폰, 스펙, , 앱스토어, 유지보수, 중박

  1. Blog Icon
    지니랜드

    수구대토 -> 수주대토 로 수정해주세요

  2. 감사합니다. 블로그 글은 종종 오타가 생기더군요. 좀더 꼼꼼히 적어야 하는데요...

  3. Blog Icon
    ㅎㅎㅎ

    제 생각엔 스마트폰 초창기(아이폰으로 인해 시장이 커지는)라서
    거품에 있고 사람들이 스마트폰에 대한 환상을 가지고 있는 것같습니다.
    손바닥만한 화면으로는 분명 한계가 있는데요...
    결국 단지 개인의 필요에 따라 몇몇 특정한 기능으로만 사용하게 될거고
    꼭 이동시 사용해야하는 사람만 사용할텐데
    꼭 만능기기인것처럼 여겨지는 분위기네요.
    PMP있지만 돌아다니며 영화보는 사람 별로 없고요
    네비있지만 네비들고 다니며 걸어가는 사람 없습니다.
    전화기로 엠피스리 들을수있지만
    따로 엠피스리를 가지고 다니는 사람들이 대부분이죠.
    만능기기는 불편하고 이동기기도 또한 불편하죠.
    이동하며 사무를 볼 수있다지만
    이동하면서 까지 사무보고 싶은 사람이 몇이나 있겠어요.
    오히려 전화기능과 카메라기능을 첨가하고
    터치기능을 넣은 OS를 가진 스펙이 강화된
    타블렛식으로 LCD를 뒤집을수있는
    10인치내의 화면을 가진 노트북이 나오면
    스마트폰 시장은 죽을 것같네요.ㅣ

  4. 제 생각은 좀 다릅니다.

    스마트폰의 파급효과는 생각보다 클 것 같습니다. 지금은 거품이라고 얘기하지만 거품이 꺼지면 실체가 보일겁니다.
    지금은 인터넷 없는 세상 생각하기 힘들죠? 스마트폰은 인터넷을 들고다니게 되는 세상입니다. 한단계 업그레이드 되는 겁니다. 기존에도 이동중에 인터넷을 사용할 수 있었지만, 편리함이 다르죠.
    스마트폰이 화면이 작기는 하지만 새로운 UX가 불편함을 감소시킬 것이고, 자연스럽게 생활속으로 파고들 것으로 예상하고 있습니다.
    인터넷(웹)이 나오고나서 일상 생활속을 들어오는데까지는 6,7년이 걸렸습니다. 스마트폰이 나온지는 꽤 됐지만, 전 아이폰과 안드로이드 폰이 나오고 완전히 생활속으로 들어오는데, 3,4년이면 충분하리라고 봅니다. 그사이에 사람들을 편리하게 해주는 앱들이 쏟아져 나오겠죠.

    누가 옳든 간에 이쪽 밥 먹고 사는 사람들은 남들보다 빨리 알아채야 겠죠. 버스 떠난 다음에 손흔들면 안되니까요... 일반 사용자라면 자신이 좋은 것 그냥 선택하면 될거구요. ^^

  5. 저도 '현혹'의 성격이 짙은 글을 보면 비판적인 시각으로 바라보려 하고 있습니다.
    이슈에 대해 여과 하지 않고 우르르 몰렸다, 우르르 파했다~ 하는 것만 봐도 매우 급변하는 IT정세와,불안정한 시국을 그대로 나타내주는 것이니까요. 이런 정세에 본질을 파악하기란 매우 어렵겠지만.. 지금 우리에게 필요한 것은 비판적인 시각이 아닐까 합니다. 예를들어.. 전규현님이 말씀하신 것처럼 요즘 모바일 쪽의 구인란을 보면 모바일 개발 경험이 有인 사람에 국한되어 있더군요. 참 안타까운 일입니다. 매우 좁게 시장이 형성되는 것도 문제이고, 장기적인 안목이 아닌 '언 발에 오줌누기 식'의 인력들만 채용하고 있으니까요. 본질을 따져서 설계와 구조에 중점을 둔다면 당연히 OO나 OOP관련 경험,또는 공학방법론을 사용해봤던 인재 위주로 형성이 되어야 하는 것이 맞다고 봅니다. 그 밑에 코딩할 인재들도 필요한 것이구요.
    이 단면에서 돈만 되면 한다는 식의 불안정한 정세를 다시 한번 엿볼 수 있었습니다.
    (요즘 스마트폰 애플을 취미삼아 해 보고 있습니다.--단지 취미입니다. 주업은 아니죠. 전에 GUI방식의 소프트웨어를 개발한 경험이 있다면, 예전 방식과 매우 닮아 있다는 것을 느끼고 맙니다.)

    팀과 인력조화에 대해서도 한가지 문제점을 제시하자면.. 서로 잘 아는 팀을 만들 수 없는 문화가 한 몫하는 것 같습니다. 회사마다 계약 체제가 다르고 관리제도가 다르니 문화가 다를 수밖에 없고, 하청구조가 이미 뿌리박힌 데다가 같은 회사사람이 누군지도 모른 체 프로젝트가 진행되고 있는 곳도 상당히 많습니다. 어떤 회사는 갑 측에 같은 비용으로 50만 제공해주어도 되지만, 어떤 회사는 같은 비용에 200을 요구하는 곳이 있더군요.

    얼마 전에 선임연구원으로 혼자 들어갔었던 프로젝트가 바로 이것과 비슷했습니다. 돈을 더 많이 주니 더 많은 아웃풋을 내야 한다는 묵시적, 강제적 계약조건이더군요. 설계,구조.. 전혀 신경을 안 쓰고 제품의 품질과는 전혀 상관없이 높은 비용(그렇게 높지도 않지만)을 주니 설계 제외하고 더 많은 아웃풋을 내라..라는 SI특유의 병폐를 또 다시 한번 경험했습니다.(아웃풋에 계약조건으로 차등을 주니 사실상 팀웍이란 잠점을 발휘할 수도 없을뿐더러 활용할 수도 없는 문화가 되어버립니다.)

    사실 노하우있는 기술자를 쓰는 이유는
    소프트웨어가 필요한 곳에 경험과 노하우,설계,구조론,방법론을 오히려 배우기 위한 것으로 생각합니다. 그것이 경험 있는 기술자들을 쓰는 이유가 아닐까 합니다.
    5년 차가 10장찍어내고 10년 차가 같은 시간에 20장을 찍어내라는 식이니..원..(이런 곳 정말 많습니다.) 상식적으로 매우 미달인것이죠.

    전 지금 병원에 입원해 있는데도.. 규현님의 글은 읽어 봅니다.:)

  6. moova님 안녕하세요.

    병원에 입원해계시고 수술이 필요하신 것 같은데 쾌차하시기 바랍니다.
    우리나라의 대부분의 회사에서는 고급개발자를 키울지도 모르고 구분할줄도 모르고 고급개발자가 무슨 일을 하는지도 모릅니다. 그만큼 낙후되어 있습니다.

    소프트웨어 개발에 있어서 무슨일이 싼일이고 어떤게 비싼 일인지 구분도 못합니다. 그래서 비용과 시간이 더 많이 들며서도 날밤까면서 일해도 좋은 제품이 안나오죠.

    또 무엇이 필요한 문서인지 어떤 것은 형식적이고 필요가 없는 것인지도 구분하지 못합니다. 이는 프로젝트마다 달라서 선임급(고급)개발자가 이런 것들을 프로젝트 성격에 맞게 합리적으로 결정해야 하는데 그렇게 하지도 못하게 하는 것이 현실입니다.

    moova님도 고생이 많겠습니다. moova님 글들을 보면 어떤 생각과 경험을 가지고 있는지 알 수 있거든요. 저는 언제나 미래에 기회가 되어서 제 블로그를 찾아주시는 분들 중에서 뛰어난 분들과 일해보는 것을 꿈꿔 보곤 합니다.

    감사합니다. 다시 한번 쾌차를 기원합니다.

  7. 스마트 폰이 상당부분 생활을 바꾸긴 하겠지만, 그렇다고 해서 삶을 스마트하게 바꾸어 줄꺼라고 생각하지는 않습니다. 상당 부분 거품도 있고 허세도 있기 때문이죠.

    문득 지하철에서 보이는 아이폰 유저들을 보면
    "게임", "동영상" 정도 밖에 안보이더군요.
    일부 헤비유저일 것으로 예측되는 증권이나 금융 개발쪽 분들이 눈에 띄지 않는 걸지는 모르겠지만
    결국에는 PMP + PSP + NDS 를 통합한 그 이상도 그 이하도 아닌 딱 게임기+휴대폰 이라는 느낌이 강합니다.
    단지 인터넷이 될뿐이고, 외부에서도 편하게 할수 있을 가능성이 있기 때문에 사용자들이 끌리는거겠죠

    솔찍히 말해서 저도 쓸모는 없지만 가지고는 싶습니다.
    '필요'하지도 않고 '용도'도 정해지지 않았지만 가지고는 싶습니다.
    아마도 이러한 경우에 단지 새로 나온 스마트 폰이고 다들 아이폰 아이폰 하니까 얼리어탑터 기분으로
    대세(?)를 따라 나도 스마트하게 스마트폰! 하는게 아닐까 생각이 됩니다.

    결론만 말하자면, 지금보다 상당부분 거품이 심하게 끼어있고, 비록 어느정도 삶을 변화 시킬지라도 생각보다 큰 변화를 일으키지는 못할것이라는 겁니다. 원더키디가 나올때까지 10년도 채 안남았고, SF영화에서 그리던 2000년은 차들 대신에 무빙워크 에 서서 다니는 그런 환상적인 세상이었는데 실질적으로 변한 삶의 패턴은 극히 드물듯이 말이죠.

  8. 구차니님 안녕하세요.

    현재 거품이 꺼지고 좀 차분해져야 실체가 나올 것 같습니다.
    "알고 봤더니 별거 아니더라"라는 말도 많이 나오겠죠. 그러면서 서서히 생활속으로 들어와서 조금씩 생활패턴을 바꾸겠죠. 이게 뭐 엄청난 변화냐? 라고 할 수도 있어도 지금도 인터넷(특히 웹) 없이도 사는 사람이 엄청나게 많지만 많은 사람은 인터넷 없는 세상은 상상하기 힘듭니다.
    처음에 웹이 나왔을 때 되는게 없었습니다. 이걸로 뭐를 할 수 있을지 제대로 상상한 사람도 별로 없었습니다. 그때는 기껏해야 회사 소개하는 홈페이지와 인터넷 신문정도 였습니다. (여담이지만 95년에 제가 세계 최초 상용 Webmail 시스템을 만든 사람이지만 이를 기억하는 사람은 아무도 없습니다. 세계최초 별거 아닙니다. - -; 저는 별로 크게 성공하지도 못했구요. 제가 만든 Webmail을 컨셉과 원형을 따라서 만든 D사는 크게 성공했죠)

    94년에 웹이 처음 나왔을 때는 이것이 생활을 바꿀 것이라고 생각한 사람은 극소수였습니다. 그런데 스마트폰은 얼마 되지도 않았는데 난리네요. 그래서 거품이 꺼져야 한다는 얘기입니다. 반대급부로 이쪽 개발에 종사하는 개발자들은 거품이 더 좋은 기회가 되기도 합니다만...

    스마트폰이 바꾸는 생활의 변화를 가져오는 것의 주역은 하드웨어가 아닌 소프트웨어라고 생각합니다. 얼마나 좋은 소프트웨어가 더 많이 나오냐에 따라서 결론이 달라질 것 같습니다. 이는 소프트웨어 개발자들이 몫이겠죠. 구차니님 같은 분들이 바꾸는 것이라고 생각합니다.

    설령 기대에 못미칠 수는 있어도 소프트웨어 개발자라면 과소평가보다는 창조자의 마인드로 동참하는 것이 필요하다고 생가가합니다.

  9. 스마트폰에 대해서 갖는 부정적인 시각은, 사용자가 아닌 개발자의 시선에서 바라봐서가 아닌가 싶습니다.
    제가 느끼는 스마트폰은 저에게 있어서는 혁명이었습니다.
    96년부터 PC통신 하이텔을 통해서 커뮤니티에 입문했는데요, 그 이후로 제 삶속에는 항상 인터넷이 있었습니다.
    어딜가도 컴퓨터가 있으면, PC통신에 접속하고, 그 이후에는 인터넷에 접속해서 현재 저의 동호회, 카페, 홈페이지, 블로그 등을 보며 실시간으로 글을 게시하고, 댓글놀이를 즐겨왔는데요, 스마트폰은 이런 소셜 네트워크에 한층 가깝게 다가갈 수 있도록 해주는 중요한 역할을 해주고 있거든요.
    인터넷이 연결되어 있지 않았을 때의 불안감이나 답답함을 한번에 해결해주고 있습니다.

    집전화가 있고, 공중전화가 있지만, 누구나 휴대폰을 가지고 다니듯이, 요즘 우리 생활에 있어서 인터넷이 그렇게 변하고 있습니다. 스마트폰은 걸어다니는 인터넷 기능때문에 중요한 것이죠.
    다만 인터넷 기능이 필요하지 않으신 분들께서, 스마트폰을 필요해서 자발적으로가 아닌 뜬다고 하니까 공부하시려는 분들께서 부정적인 시각으로 말씀해주시는 것 같은데요, 크게... 변화를 줄 것 같아요.

    자다가 일어나서 갑자기 말이 많았습니다. 또 놀러올겠습니다. ^^

  10. Blog Icon
    샘성맨

    회사를 그만두고 앱 개발 창업을 준비하고 있는 사람으로서 research 도중 오랜만에 좋은 글을 발견한것 같아 기쁩니다.
    진입장벽이 낮은 앱 개발은 정말 개발자의 한사람으로서 전업으로 뛰어들기전에 가장 생각이 많아지는 부분입니다. 그리고 유지보수얘기를 쓰셨던데, 시장조사도중 많은 대다수 앱개발자들이 개발은 해놓고 테스트 및 유지보수같은건 신경쓰지 않는걸 볼 수 있더군요. 정말 공감가는 부분입니다. 이런 부분을 고려한 비즈니스 모델도 생각중입니다. 그리고 혼자개발하는것에 대한 한계성 또한 매우 공감갑니다. 몇몇의 인재와 함께하면 좋겠는데, 우리나라같이 대기업만 밝히는 분위기에서 벤처에 누가 쉽게 열정을 쏟으려고 할까요 솔직히 아직 회사를 그만둔건 아닌데(저도 분위기상 대기업을 왔습니다만..), 이 부분에 대해서 상당히 두렵네요. 하지만, 돈만을 위한 개발이 아닌 첫사랑을 다시 만나 연애하는 기분으로서 다시 개발을 시작한다면 어느정도의 생활은 가능할꺼라 점점 확신이 듭니다. 그 첫사랑을 지금 시대흐름이 아니면 다신 볼 수 없을것도 잘 알고 있습니다. 또한 스마트 TV 라는 블루오션시장도 보이고요. 아직 절망보다는 희망이 많아보입니다. 첫걸음부터 큰걸음을 내딪지말고 3번의 시련을 각오하고 희망을 향해 몸을 던지렵니다.

  11. 안녕하세요. 샘성맨님
    도전은 항상 아름답니다. ^^ 도전이 소프트웨어 발전의 힘입니다.
    혼자 소프트웨어를 개발하는데는 많은 어려움이 따릅니다.
    앱센터를 이용하면 도움이 좀 될 수 있을 것 같습니다.
    앞으로 도전하시는데 도움이 필요하면 부담없이 연락주세요.
    도움을 드릴 수 있으면 기쁘겠습니다.

동종업계 취업금지 각서

2009.12.29 12:17 by 전규현


잠시 후 Google blogger로 이동됩니다.




개발자에게는 동종업계 취업금지라는 이상한 족쇄가 있습니다.
보통 2년 어쩔 때는 더 길기도 합니다.
입사 시에 이러한 동종업계 취업금지 각서에 사인을 하라고 하는 회사가 종종 있습니다.
물론 특정 업종에 따라서는 이러한 금지조항이 꼭 필요한 경우가 있습니다. 하지만 그렇지 않은 회사에서도 너무 광범위하게 "동종업계 취업금지"를 활용하고 있습니다. 

실제로 이러한 조항 때문에 이직 시에 문제가 되는 경우를 종종 봐왔습니다. 이 와중에 개발자만 괜히 낙동강 오리알이 되고 오갈데 없는 신세가 되곤 하더군요. 이전 회사에 다시 돌아가지도 못하고 참 곤란한 경우를 겪더 군요. 

이 작은 땅덩어리에서 개발자들이 경쟁 업체에 취직을 못하게 하면 개발자는 갈 곳이 별로 없습니다.
이전 회사에서는 상당히 그럴싸한 이유를 댈 수 있습니다. 
개발자가 회사의 소스코드를 몽땅 들고 가서 경쟁회사에서 이를 그대로 사용할 수 있다는 겁니다. 이것은 범죄인데 직원이 퇴사 시 범죄를 저지를까봐 미리 방지하는 셈입니다. 실제로 이러한 걱정을 하는 회사가 꽤 많고 일부 이해도 됩니다. 

마치 지하철에서 신문을 보면 이 신문을 깔고 "대ㅂㄴ"을 볼 수 있으므로 신문을 못 보게 하는 것처럼 생각되기도 합니다.
영업직은 자신의 모든 영업라인을 끌고 이직을 해도 입사할 때 이런 서약을 하라고 하지 않습니다.
물론 개발자가 이직을 해서 기존의 소스코드를 얼마나 활용하고 참조하는지는 알 수 없습니다. 또한 자신이 개발한 일부 함수를 재활용한다고 해도 범죄라고 얘기하기가 어렵습니다. 회사에서는 나중에 문제가 되고 귀찮아지니까 이를 원천 봉쇄하겠다는 뜻이죠.

이는 마치 소수의 개발자와 소스코드에 회사의 경쟁력이 전적으로 의존되고 있다는 뜻이기도 한데, 이런 회사는 보기에도 좀 불안해 보입니다. 개발자들이 퇴사하는 것은 언제든지 일어날 수 있는 일인데, 이것이 그렇게 심각하다면 좀 문제가 있습니다. 분명 개발자는 소프트웨어 회사에서 가장 큰 자산이지만, 이는 소수의 한두명이 아니고 전체를 말하며 팀을 이뤄서 일했을 때 가치를 말할 수 있어야 합니다.

개발자들도 이직을 할 때 두뇌를 완전히 비우고 이직을 할 수는 없겠지만, 또 이전 회사에서 자신이 작성한 소스코드를 참조하고 볼 수는 있겠지만, 소스코드를 완전히 배껴서 동일 제품을 만든 것은 안됩니다. 자신이 만든 소스코드의 지적 재산권은 회사에 있는 것이죠. 다만 이를 만들면서 쌓인 지식과 경험은 개발자 것이지요. 새로 이직한 회사에서도 그 지식과 경험을 사는 것이지 소스코드를 들고 오라고 하면 안되겠죠. 또, 이런 지식과 경험을 이용해서 새로운 제품을 만드는데 힘쓰는 것이 좋겠죠.

개발자들의 마인드도 좀 바뀌어야 무분별한 동종업계 취업금지 관행에서 개발자들이 벗어날 수 있을 것으로 생각됩니다.

개발자들이 모든 소프트웨어 회사로 자유롭게 이동을 할 수 있어야 소프트웨어 업계 전체적으로 발전할 수 있습니다. 그래야 개발자들도 많은 지식과 경험을 접하게 되고, 개발자 및 회사 모두에게 더 많은 기회를 제공합니다.

입사시에 이런 각서에 사인을 해야 한다고 하면 사인을 해도 되는지 잘 한번 생각해보세요. 

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by michele cat

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 각서, 개발자, 동종업계취업금지, 이직, 입사

  1. 각서보다는 예전 판례가 있기 때문에 문제가 되는게 아닐려나요?

    아무튼 영업직은 그 사람과 연관된 거래선이 따라가는건데 아무말 하지 않는다 라는 관점이 신선합니다.
    개발자에게 적절한 방어막이 될 좋은 문구인거 같아요 +_+!

  2. 구차니님 새해 복 많이 받으세요.
    이직을 하면서 기업의 비밀과 재산을 얼마나 침해하느냐가 문제인데, 물건 만드는 공장에서는 설계 도면이 매우 중요하지만, 소프트웨어는 참 애매합니다. 그래서 제가 항상 강조하는 것이 소스코드에 너무 큰 비중을 두지 말자는 것입니다. 개발자들의 자유로운 왕래가 없이는 소프트웨어 전체적인 성장은 어렵습니다.

  3. 컴공학부 4학년 학생으로... 개발자로 일하기 원하는 학생인데 언제나 좋은 글 읽고 갑니다.^^;
    하지만, 졸업 후에 처음 어떠한 회사에 입사 시에 어떠어떠한 서류에 사인하라고 하면... 제 코가 석자라서 이런 것을 알아도 하게 될 것 같습니다.(슬픈현실..ㅠㅠ?코가 석자라..)
    하여튼 맨날 그냥 좋은 글 읽고만 가다가 감사의 마음으로 댓글이라도 달고 갑니다.
    내년에도 계속 꾸준하게 좋은 글 부탁드리겠습니다.

  4. 안녕하세요. simplism님
    사인은 해야겠죠. 하지만 사인을 하는 의미는 알아야 합니다. 아니면 퇴사후 창업을 하셔야 할 겁니다. ^^
    학부생이 피부로 느끼기에는 좀 어려운 내용들도 있는데, 열심히 보고 있다니 고맙습니다. 이제 내년에 졸업이시군요. 훌륭한 개발자가 되시기 바랍니다.

당신은 개발자도 아니고 관리자도 아냐!

2009.12.23 19:05 by 전규현


잠시 후 Google blogger로 이동됩니다.





컨설팅을 하다 보면 많은 개발자와 관리자를 만납니다.

그런데, 특히 고참 개발자나 개발자 출신 관리자 중에는 자신의 정체성을 못 찾는 사람들이 많습니다.
이런 사람들에는 다음과 같은 말을 해주고 싶습니다.

"당신은 개발자도 아니고 관리자도 아냐!"

개발자와 관리자 두 가지 일은 병행하여 둘 다 잘할 수 있을 만큼 쉽지 않습니다.

개발자로 5년~10년 일을 하면 팀장을 하라고 합니다. 하지만 팀장으로서 정확하게 무슨 일을 하라고 하는지는 알려주지 않는 경우가 많습니다. 그래서 기존에 팀장들이 어떤 일을 하는지 보고 따라 해보곤 합니다. 하지만 팀장이라는 역할이 개발자로서 개발의 리더 역할인지 관리자의 역할인지 애매한 경우가 많아서 개발도 하면서 관리도 하면서 어쩔 때는 팀장 일을 하느라고 개발은 소홀히 하거나 팀장이라고는 하지만 여전히 개발에 매달리면서 팀장 일은 나몰라 하는 경우가 많습니다. 어떤 경우는 둘다 못하기도 합니다.

또 개발자 출신으로 관리자가 된 경우에는 관리자로서 해야 할 일들이 얼마나 많고 어려운데 개발 관련된 이슈들만 눈에 들어와서 사사건건 개발에 대한 기술적인 이슈 해결에 직접 참견을 하고 해결하려고 하고 정작 본연의 관리 업무는 소홀히 합니다. 개발자 출신으로 관리자가 된 경우는 물론 개발에 대해서 잘 알고 이런 기술적인 이슈에 대해서 조언을 해줄 수 있는 것은 확실하나 사소한 기술적인 이슈까지 너무 참견을 한다면 후배들이긴 하지만 정작 개발자들을 무시하는 처사입니다.
관리자로서는 HR이슈, 프로젝트, 인력, 비용 관리, 부서간 이슈 조정, 경영자에게 보고 등 많은 일들을 더 잘 처리하는 것이 중요합니다.

이런 현상이 벌어지는 근본적인 이유는 개발자와 관리자의 트랙이 명확하게 구분이 되어 있지 않아서입니다. 개발자라면 언젠가는 둘 중에 하나를 선택해야 합니다. 
관리자를 선택한 사람들은 일정 기간이 지나면 다시는 개발자 트랙으로 돌아오지 못합니다.
하지만 개발자 트랙에 있던 사람은 시기에 구애 받지 않고 관리자가 될 수 있습니다. 물론 관리를 잘하느냐 못하느냐는 다른 이슈입니다. 가능하다는 거죠.

이렇게 정해지면, 자신의 업무에 집중해야 합니다. 개발자 트랙을 선택한 사람이 관리에서 오는 행정적인 Power를 추구해서는 안됩니다. 개발자의 Power는 기술에 대한 지식과 경험에서 오는 카리스마입니다. 관리자 트랙을 선택했다면 관리에 힘을 써야지 개발자의 영역을 넘보면 안됩니다. 개발에 대한 해박한 지식과 이해는 관리에 분명히 도움을 많이 줍니다. 그렇다고 하더라도, 개발자가 해야 할 일을 자신이 해는 안되죠. 이미 관리로 넘어 왔다면 기술과는 점점 Gap이 벌어지게 되어 있고 어느덧 자신이 아는 지식은 옛날 지식이 되어 있을 수도 있습니다. 

물론 누구나 좋은 개발자, 좋은 관리자가 될 수는 없습니다. 하지만 둘다 하겠다고 해서는 둘다 못하는 결과를 초래합니다. 선택을 해야 할 시점에 선택을 해야 하고 회사에서도 제도적으로 이를 뒷받침 해줘야 합니다.

둘다 잘할 자신이 있다고 한다면 저는 "개발자"를 선택하겠습니다. ^^


* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by obo-bobolina
저작자 표시 비영리 변경 금지
신고

전규현 사람과 기술 개발자, 개발자트랙, 관리자, 관리자트랙, 캐리어패스

  1. 해외 롤이 생각나는군요.
    개발자 - 대표개발자 - 쥬니어 컨설턴트 - 임플리먼트 컨설턴트 - 프로젝트 메니저 -프로그램 메니저
    - 비지니스 컨설턴트
    - 일반 관리

    말씀하신 내용은 개발자와 관리자 두가지 롤에서만 국한 된것 같습니다.

    예를들어 컨설턴트라면 개발자와 관리자 또는 조직영역에서 전문적으로 컨설팅하는 영역이 있다는 것을 알고 계실 것 같군요. 개발자에서 컨설턴트로 크셨던 분들은 다시한번 테크니컬쪽으로 가던지 아니면 관리적인쪽으로 가던지.. 하는것이죠. 제품 기술 컨설팅도 어차피 개발자에 국한된 롤이기는 하나 일반적인 개발자와는 차등을 둔다고 알고 있습니다. 특히 기술 컨설팅 영역에서는 누군가에게 미래를 제시해주거나
    더 낳은 기술적 비전을 제시하면서 업무를 수행했던 사례도 몇번 있었죠.

    다른 한편으로는 아키텍트 영역으로 발전하는 사례도 있고 말이죠. 아니면 정말 개발자답게 개발영역에서 크는 분들도 있고요.

    제가 생각했을 때는 관리자영역이나 개발자영역이나 주어진 업무가 있기 때문에 대부분 역할을 수행하기 위해서 힘든 노력을 하고 있는 것을 알고 있습니다. 말씀하신대로 짱뽕 업무를 하면 두마리 토끼를 다 놓치는 셈이죠. 이런경우 조직적인 차원에서 안정화가 안되어 있기때문에 부랴부랴 하는 것이 아닐까요?

    한 사무실에서 관리업무나 개발업무가 짱뽕된 상태, 이거 개선해 나가야 할 문제긴 하죠.
    규현님께서는 소프트웨어공학 컨설턴트라고 하셨는데 구체적으로 어떤일을 하고 계신가요?

  2. 안녕하세요. moova님
    제 글의 의도야 잘 아시겠지만, 크게 기술과 계속 접해있는냐? 아니냐의 차이를 말하는 거죠. 컨설턴트가 관리자는 아니죠. 저는 주로 국내 현실을 많이 조명해봅니다.

    제가 하는 일이 무어냐구요? 소프트웨어공학이 뭔지는 아실 거고.. 소프트웨어 컴퍼니가 소프트웨어를 잘 개발할 수 있도록 조직, 프로세스 등을 개선해주고, 가르쳐주기도 합니다. 말씀하신 컨설턴트와는 좀 다르죠. 저는 아직 엔지니어 Path에 있는 사람입니다. ^^

  3. 두가지중에서 한가지를 선택하라면..저같은 경우 없겠네요.
    단 다른 분류를 더 수용한다하면 기술,제품 컨설턴트를 택하겠습니다.^^

  4. 저도 개발자를 선택할겁니다.^^ 굿잡~

  5. 청하님 안녕하세요.
    개발자 의지 주욱 유지하세요. ^^

  6. Blog Icon
    bawoo

    포스팅 잘 구독하고 있습니다.
    오늘따라 제목이 가슴에 파악 와 닿아서 글을 남겨 봅니다.

    저의 경우에는 두 트랙 사이에서 왔다갔다 하다가 이번 조직 개편 이후 확실하게 매니저 트랙으로 전담하게 된 상황입니다. 역시나 코딩은 개인적으로나 접근으로 해야 할 것이고 업무적으로는 조직 및 프로젝트의 효율적인 관리에 집중해야 할 상황입니다.

    역시 두가지 다 잘하기는 힘든것 같습니다. 개발에도 많은 공을 들이고 공부도 하고 시행착오도 겪어야 하지만 메니지먼트도 그에 못지 않은 가시밭길이더라구요. 3년차까지 정말 힘들었습니다. 좌절도 많이 했구요.
    그래도 이제는 익숙해지니 좀 할만하고 나름 비전도 만들어 갈 수 있을것 같네요.

    좋은 글 감사하고 개발자와 메니저 두 트랙 사이에서 갈등하고 고뇌하시는 모든 분들이 힘내시길 바랍니다.

  7. bawoo님 안녕하세요.
    좋은 관리자가 되세요. 감사합니다.

  8. Blog Icon
    Barry Seok

    안녕하세요. Ray님

    개발자 , 관리자 두가지 일은 회사내의 Position , Power 이런 것을 떠나서 서로 "목표"가 다른 일이라 두가지 역할을 병행하여 잘 한다는 것은 이론적으로도 성립하지 않을 것 같습니다. 예를들어 관리자가 시간이 나서 개발자들 일을 도와 줄 수 도 있겠지만 , 도와 주는 것 자체도 추후 개발자 인사 평가에 문제가 되지 않겠습니까.
    개발자도 아니고 관리자도 아닌 상태가 지속이 되면 회사로서는 매우 큰 손실이 될 것 같습니다.

  9. 석부장님 새해 복 많이 받으세요.

  10. 전 그냥 뼛속까지 개발자를 하렵니다 ㅋ
    개인적으로는 개발자와 후진양성쪽을 해보고 싶어요 ㅎ

  11. 구차니님.. 개발자 화이팅

  12. 개발자 출신이라고 사소한 기술적인 이슈를 모두 가이드 한다는 것에 대한 느낌이
    지금 어떤것인지 정말 확실히 느끼고 있는 상황이기에.. 허탈한 웃음만 나오네요 ^^

  13. zeous님 안녕하세요.
    그런 관리자와 같이 일한다면... 사실 트러블을 피하기 어렵습니다. 정말 Communication 기술이 필요한 시점입니다. 아니면 부서를 옮기는 것도 한 방법...

  14. 개발자 와 관리자... 글쎄...
    2000년 초반 같은 경우야 PL이라 함은 개발 리딩 + 관리 리딩
    이였지만 최근에는 업무 와 기술이 옛날과 비교도
    할수 없을 정도로 복잡하고 규모가 커졌습니다.
    막말로 기술 하나만 리딩하는 것 자체도 상당히
    버거운 현실인데 두 개를 잘한다...
    물리적으로 힘든 경우 입니다. 실제로 사이트에 나가보면
    관리자 롤이면서 본인이 관리자 하기전에 개발 리딩했다면서
    일장 Lip Service를 합니다. 정착 이슈가 났을때는
    발뺌을 하더군요. 오히려 방향성만 흐리게 합니다.
    보다 전문적인 롤 구분이 필요 하다고 생각 하는데
    아직도 회사에서는 옛날 사고 방식에 젖어 있다는게 문제 입니다.

  15. 안녕하세요. Beyond J2EE님
    둘다 잘하는 것은 거의 불가능하다는 얘기입니다.
    하나만 잘하기도 어렵죠. 자신이 잘할 수 있는 것 하나만 집중해야죠.

뛰어난 개발자는 길러지는 것

2009.11.29 16:18 by 전규현


잠시 후 Google blogger로 이동됩니다.




이전 글("뛰어난 개발자는 타고나는 것")에서 논리적인 두뇌가 개발자의 Performance에 미치는 영향을 알아보았습니다. 이 글은 원래 상반된 의견을 가진 두 글로 계획된 것인데, 이전 글에 대해서 많이들 관심을 가지고 의견을 주셔서 두번째 글을 바로 올립니다. 
이전 글을 본 독자분들은 자신의 경험에 비추어서 위화감을 느끼시는 것 같습니다. 인정하기 싫은 현실일 수도 있습니다. 사실 이전 글은 사실 경영자가 봐야할 글입니다. 자신을 똑똑한 개발자와 반대편에 두고 무조건 거부감을 둘 필요는 없습니다.

이런 형태의 글은 옛날에도 올렸었죠. ^^


이번 글은 개발자를 위한 글입니다.

Microsoft등의 유수의 소프트웨어 회사들은 상위 0.01% 또는 0.001% 두뇌를 확보하기 위해서 학과를 가지 않고 천문학과, 물리학과 등에서 천재들을 확보하고 있습니다. 그리고 학생 중에서도 소프트웨어 개발에 특별한 재능을 보이는 개발자 후보를  싹쓸이 하기 위해서 엄청난 노력을 기울입니다.
이러한 활동은 국내 대부분의 소프트웨어 회사들은 먼나라 얘기일 뿐입니다. 또한, 이러한 사람들이 개발자가 된다고 해도 우리나라 보통의 소프트웨어 회사에서 진짜 훌륭한 개발자로 성장하기는 어려울 것 같습니다.

똑똑하고 뛰어난 논리 회로를 지닌 사람이 뛰어난 개발자가 될 가능성이 확실히 높기는 하지만, 개발자가 몸담은 환경에 따라서 훌륭한 개발자가 될 수도 있고, 천덕꾸리기가 될 수도 있습니다.
또한 그런 특별한 논리 회로를 지닌 사람만이 할 수 있는 일은 어렵기는 하지만 그리 많지는 않습니다.  대부분의 개발업무는 보통의 두뇌를 가진 사람들이 수행합니다. 물론 이들도 일반인과 비교하면 비교도 안될 정도로 논리적인 두뇌를 가지고 있습니다.
하지만 훌륭한 개발자가 되는 것은 두뇌의 성능에 의해서 결정되지 않습니다. 상위 0.1%의 두뇌를 가지고 있다고 하더라도 훌륭한 개발자가 되는데 크게 유리하지도 않습니다. 훌륭한 개발자는 어떻게 경험과 경력을 쌓아가느냐에 달렸습니다. 

제가 두 글에서 서로 다른 시각을 두는 것은 두뇌에서 나오는 개발자의 Performance실제 개발의 전반적인 Performance의 차이를 보여주기 위함입니다. 어차피 두뇌는 거의 정해진 것입니다. 하지만 개발자가 어떠한 환경에서 어떤 방향으로 성장하느냐에 따라서 10년 후의 Performance와 회사에서의 기여도는 엄청난 차이를 가져옵니다. 이것은 개발자 혼자만의 노력으로 가능한 것은 아니고 회사에서 환경을 제공해 줘야 합니다.

그럼, 뛰어난 개발자로 길러지는 방법에 대해서 알아보겠습니다.

첫째, 먼저 자신을 잘 알아야 합니다.
모든 사람은 장점과 단점이 있습니다. 두뇌는 뛰어나나 표현을 못하고 글을 잘 못쓰는 사람이 있는가 하면 두뇌는 보통이지만 인화력이 뛰어나고 남을 잘 이해해주는 사람도 있습니다. 누구는 발표를 잘하고 누구는 설득을 잘합니다. 누구는 끈기는 없지만 아이디어는 끝내줍니다. 또 누구는 신제품 가지고 놀기를 좋아합니다. 자신의 능력과 취향을 잘 알아야 합니다. 그래야 개발의 수많은 분야에서 어느 분야로 성장할지 결정할 수 있습니다. 소프트웨어 개발자 외에도 가능한 다른 분야는 Project Manager, Product Marketing, QA Engineer, Build and Release, Technical Support 등 다양한 분야가 있습니다.

둘째, 자신의 전문 분야에서는 최고가 되어야 합니다.
자신의 분야에서 최고가 된다는 마인드로 주변의 누구보다도 자신의 분야에서는 많은 지식과 경험이 있어야 합니다. 그렇지 않고 일반지식만 가지고 있다면 소프트웨어 개발자로는 부족하죠. 남들보다 특출난 한 분야가 꼭 있어야 합니다. 모든 분야에서 모두 최고가 된다는 것은 불가능하기 때문에 자신만의 분야를 찾는 것도 중요합니다.

셋째, 넓은 지식과 경험을 가져야 합니다.
항상 코딩에만 집중하는 개발자는 넓은 지식을 가지기 어렵습니다. 개발자는 자신만의 분야 뿐만 아니라 다양한 분야의 지식을 섬렵해야 합니다. 그러기 위해서 가장 좋은 방법은 Peer review입니다. 개발자는 자신의 프로젝트만 할 것이 아니라 다른 팀의 여러 프로젝트의 Review에 꾸준히 참석해서 도움을 주는 것 뿐만 아니라 자신의 경험과 지식도 넓혀야 합니다. Review가 아니면 그렇게 많은 지식을 넓힐 기회가 별로 없습니다. 또한 다양한 Conference에도 꾸준히 참석해서 Technology Trend도 따라가야 하며 인맥도 유지해야 합니다. 많은 경력을 가진 개발자들은 자신의 개발업무에만 치중하는 것이 아니라 회사의 중용한 기술적을 결정에 참여를 해야 하기 때문에 넓은 지식을 자지고 있지 않으면 안됩니다. 
또한 소프트웨어공한의 다양한 분야에 대한 전반적인 경험과 지식도 같이 가지고 있습니다. 그렇지 않고 매일 코딩만 하는 개발자에게 어떻게 높은 연봉을 줄 수 있을까요?

넷째, 긍정적인 마인드입니다. 
회사에 긍정적이고, 팀에 긍정적이고, 자신에게 긍정적이어야 합니다. 그렇지 않은 개발자는 분위기가 음산하고 같이 일하기 거북합니다.
회사의 정책에 호응하고 긍정적이지 못한 개발자는 항상 불만이고 반대합니다. 이러한 패턴은 바뀌지 않고 언젠가는 회사의 발등을 찍을지 모릅니다. 실력이 뛰어나도 이런 개발자는 빨리 내보내는 것이 좋습니다.
팀에 긍정적이지 못한 개발자는 팀웍을 무시하고 자신만을 위해서 일합니다. 이러한 개발자는 다른 개발자들에게 피해를 끼치며 마이너스 생산성을 가집니다.
자신에게 긍정적이지 못한 개발자는 자신감이 없으며 훌륭한 개발자로 성장하기 어렵습니다. 
또한 이런 개인의 기본 자세는 쉽게 바뀌지 않습니다. 따라서 항상 긍정적인 마인드를 유지하기 위해서 꾸준히 노력하고 자신을 설득해야 합니다. 천성이 긍정적인 사람은 저절로 되는 일이지만 그렇지 않은 사람은 노력을 많이 해야 합니다. 부정적인 마인드는 면접시 탈락의 큰 요소도 되기도 합니다.

이 중에서 대부분은 개발자 스스로 노력해서 가능한 것들입니다. 하지만 셋째는 개발자 혼자의 노력만으로는 어렵습니다. 회사에서 그렇게 할 수 있도록 환경을 조성하고 지원을 해줘야 합니다. 그래서 좋은 환경에서 일하는 것이 중요하죠. 지금의 회사가 연봉은 괜찮지만, 개발자로서 성장할 수 있는 좋은 환경이 아니라면 오래 몸담는 것이 오히려 미래에 내 몸값을 떨어뜨리는 일일 수도 있습니다. 불행히 우리나라에는 좋은 환경의 소프트웨어 회사가 적은 편이기는 하지만, 그 중에서도 상대적으로 좋은 환경을 찾는 노력은 필요합니다. 저의 Mission 중의 하나가 그런 환경을 가진 소프트웨어 회사를 많이 만드는 겁니다.

머리는 똑똑하지만, 같이 일하기 어려운 천덕꾸리기 개발자보다는 경험과 지식 및 인성이 두루 균형 잡힌 개발자가 더 가치 있고 회사에 더 필요합니다. 미래의 나는 내가 만들어 가는 겁니다.
 
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 사람과 기술 개발자, 경험, 지식, 팀웍

  1. 매번 비슷한 생각의 글 올려주셔서 또 들어와 버렸네요. 같은 개발자라도 만나보면 항상 코딩관점에서 생각하는 분들이 많습니다. api와 코드를 하루종일 봐도 항상 코드적으로 해결하려고만 하죠.
    저같은 경우는 주로 외국계쪽이나 대기업쪽을 다녔는데 요즘 하고 있는 작은 프로젝트에서는 불만들이 항상 쏟아져 나오고 있습니다. 나중에 긍정적으로 몰입하려해도 분위기들이 불만 투성이라 혼자 긍정이 될 순 없었죠. 오히려 역으로 SRS나 문서들을 쪼고 이만큼 진행한것도 어찌보면 큰 프로젝트에서의 경험이 뒷받침 될 수 있었던 것 같습니다. 큰문화와 체계가 잡혀있던 곳에서 활동한 기술자들이 체계가 잡혀있지 않고 언발에 오줌누기식인 프로젝트를 만나면 어떻게 해야할까요? 역으로 배워야 하지 않을까 생각합니다.
    가끔씩은 불만을 토로하고는 있는데 그 불만이 어떻게보면 조직적인 차원에서의 발전성을 이야기하는 것이지 한 조직을 망하라고 하는 것은 아니거든요^^

  2. 안녕하세요. moova님
    이런 경우는 참 곤란한 경우죠.
    조직을 바꾸려면 힘이 있어야 합니다. 그렇지 않으면 미움만 사기도 합니다. 아니면, 아주 서서히 조금씩 무리없게 바꿔가야 합니다. 지금 꽤 열심히 하고 계신데, 미움사지 않을 정도로 적절히 조절하시면서 하시면 되지 않을까요?

    제일 좋은 방법은 좋은 환경의 회사에서 일하는 것이겠죠?

  3. 아악 사수의 존재가 ㅠ.ㅠ
    그래도 가장 좋은건 누군가가 이끌어주는 사람이 있다는거겠죠.
    (3년째 사수없이 살아가는 3년차 개발자 ㅠ.ㅠ)

  4. Blog Icon
    Richpapa

    지나가면서 글 남깁니다.

    사수가 없다면, 스스로 사수가 되어보려고 해 보세요. 분명 달라집니다. 제대로 된 사수 만나기도 하늘에 별 따기입니다.

  5. 구차니님 안녕하세요.
    전 사수 system을 별로 긍정적으로 생각하지 않습니다. 사수가 있는 것 자체는 좋은 일이지만, 사수를 둬야 하는 원인을 생각하면 부정적입니다. 사수가 아니면 새로 입사한 개발자를 끌어줄 방법이 별로 없기 때문에 사수에게 알아서 하라고 맡기는 경우가 대부분입니다. 제대로 된 환경의 SW회사라면 사수가 없어도 입사 첫날부터 버그도 잡고 제대로 일할 수 있습니다.
    이 글에서도 이러한 제대로 된 환경의 중요성을 강조하고 있습니다. 개발자는 사수가 키워주는 것이 아니고, 제대로 된 환경이 필요합니다.

  6. Blog Icon
    Richpapa

    위의 내용은 뛰어난 개발자가 되기 위한 것이 아니더라도, 어떤 분야건 필요충분조건이라고 보여집니다.

  7. Richpapa님 안녕하세요.
    형이상학적으로 가면 모두 일맥상통하죠.

  8. 잘 읽었습니다.

  9. 열산성님 안녕하세요.
    블로그에 들려 주시고 댓글 남겨주셔서 감사합니다.

  10. 개발자의 한사람으로써 동의합니다. 구구절절 옳은 말씀입니다.

  11. 안녕하세요. 전경헌 사장님
    회사는 여전히 잘 되시죠? 이렇게 블로그에도 들러주시고 댓글도 자주 남겨주시니 정말 고맙습니다.

  12. 좋은 환경의 회사...혹시 아시면 소개좀...^^;;;
    일단 주어진 환경에서라도 뛰어난 개발자가 되기 위해 노력해야 할것 같습니다.^-^
    추천해주신 책~ 잘 보고 있습니다.~ 감사합니다.

  13. sozu님 안녕하세요.
    좋은 환경의 회사는 여러가지 조건이 있지만, 이를 갖추기 위해서는 경영자의 마인드가 가장 중요합니다. 일단 SW를 잘 이해하는 좋은 경영자가 있는 회사라면 크기와 상관 없이 좋은 회사고 그런 회사에서는 배울 것도 많죠. 구체적인 이름을 나열하는 것은 문제가 있어서 말씀드리지 못하겠네요. 나중에 개인적으로 만나면 알려드리죠.

    일단 국내에는 상대적으로 그런 회사가 적은 편입니다. 하지만 미국에는 정말 많죠. 영어를 잘하시고 기회가 되시면.. 또 아직 국내 경력이 그렇게 많지 않으면 미국 SW회사에 지원해보는 것도 괜찮을 겁니다. 하지만 국내에서 이미 경력이 많다면 미국 SW회사에 입사해서도 적응을 못하는 경우가 많아서 권해드리기 힘들겠네요.

    일단 현재 환경에서 노력해보시기 바랍니다.

  14. 조언 감사드립니다..^^ 미국진출은 항상 준비하고 있습니다~
    어제 팀장님과 토론하느라 늦게 퇴근하고 집에 가면서 생각해봤는데요..
    꼭 좋은 환경에서만 좋은 개발자가 나올것 같지는 않습니다. 나쁜 환경이라도 좋게 받아드리고 개선하려고 노력했던 경험을 쌓는 것도 좋은것 같아요..물론 정말 어렵겠지만..
    동료들, 윗분들을 설득하려다 보니 제 스스로가 강해지기 위해 더 많이 연구하게 되더라구요~ 그래도 들어주는 사람이 있다는게 너무 감사한것 같습니다.ㅋㅋㅋ
    그리고 그 회사들은 나중에 꼭 알려주세요~~^^ 감사합니다~

  15. 오랜만에 들어오니 또 좋을 글들이 올라와있네요.
    앞으로는 자주 와봐야 겠습니다.^^

    위의 댓글에서 보면 사수 시스템에 대해서 부정적이신데..
    멘토링이라는 제도와 사수 시스템을 같은 개념으로 보시는것이지요?
    요즘 멘토링노하우 라는 책을 보고 있어서 언급해봅니다.
    규모가 작은 회사에서 체계적인 개발자 교육 시스템을 갖추기란 쉽지가 않을겁니다.
    요즘 개발자 실력 향상 및 교육 방법으로 멘토링 방법을 생각해보고 있는데..
    스스로 공부하려고 하지 않는다면 어떤 방법도 소용이 없겠지요
    항상 가장 부족하고 중요한건 열정인것 같습니다.

  16. 안녕하세요. 크레브님

    용어의 차이를 두어서 설명할 생각은 없습니다. 다만, 사수든 멘토링이든 이를 시행하는 이유와 환경이 중요한 것 같습니다. 회사일이라는 것이 시스템, 프로세스, Role 이런 것들만 잘 정의 되었다고 잘 돌아가는 것은 아니죠. 이런 건 기본 중에 기본이죠. 그외에 멘토링을 통해서 얻을 수 있는 것은 매우 많습니다. 하지만, 흔히 사수제도 도는 멘토링 제도를 하는 이유가 아무런 기초도 되어 있지 않아서 경험있는 사수가 머리속에 있는 것을 하나씩 1:1로 가르치라는 것인데, 시간도 많이 걸리고 효율적이지도 못합니다.

    아직 체계가 없는 회사라면 우선 사수제도라도 시행하는 좋겠습니다. 그리고 빨리 체계를 갖춰야죠. 그래야 비로소 소프트웨어를 제대로 개발할 수 있는 기초중에 기초를 만든 겁니다. 이제 시작이죠.

  17. 안녕하세요. 오랜만에 들어왔습니다.
    저희 회사가 전규현 님의 지원으로 저희 개발부 경쟁력은 물론 연관 부서 경쟁력도 많이 올라갔습니다.
    구성원 대부분이 인정하는 사안입니다.
    더욱 의미있는 것은 서로 Communication 을 더 잘 할 수 있는 기반을 닦았다는데 있습니다.
    뛰어난 개발자가 될 수 있는 환경을 제공하는 회사가 되어야 하는데, 모자란 것이 많다는 것만 아는 경영자이어서 문제가 있습니다.

    개발 출신 경영자로서 단점을 보완하고, 장점을 활용하며 스킬을 높여 나가야겠다는 영감을 주는 글 감사합니다.
    뛰어난 개발자가 나올 수 있는 환경을 조성하고 지원하는 회사가 되도록 노력하겠습니다.
    수고하세요.

  18. 황규환 사장님 오랫만입니다.
    사장님을 비롯해서 개발자들은 아주 인상에 많이 남아 있습니다. 특히 SW 개발을 이해하고 있는 사장님이 회사의 큰 힘으로 생각됩니다.
    글로벌 경쟁력을 갖추기 위해서 앞으로도 해야 할 일이 많지만, 이미 변화의 기초를 갖췄고 나아지는 길을 가고 있기 때문에 앞으로 방향만 제대로 잡아서 성장해나가면 제가 항상 바라는 개발자, 경영자 모두 행복한 SW회사가 될 것으로 확신합니다.
    요즘 계속 너무 바빠서 시간을 못내고 있는데, 조만간에 한번 뵙죠. 건승하십시오.

  19. Blog Icon

    비밀댓글입니다

  20. 안녕하세요. 오랫만입니다.
    재미있는 거 하고 계시네요. ^^ 저도 바빠서 계속 못나가고 있는데, 나중에 꼭 뵈요.

  21. 안녕하세요, 네오플 공식 블로그 <네오플로그> 운영자입니다. 네오플로그에 본 포스트를 스크랩하고 싶은데요, 가능할까요? ^^ 단, 본문이 조금 길어서 일부 내용은 삭제해야할 것 같은데요. 답변 부탁 드립니다. :) 좋은 글이 많네요.

  22. 안녕하세요. 네피님
    이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
    본문의 일부만 게재하는 것도 얼마든지 가능합니다.
    감사합니다.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..