태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

나쁜 프로그래머가 되는 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
    방랑자

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

‘한국의 저커버그’가 양성되기 위한 조건

2013.07.29 09:05 by 전규현


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






교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다.


이글은 제가 씨넷코리아에 게재한 칼럼입니다. 새로 시작하는 씨넷코리아에 많은 관심 바랍니다.


예전에는 한국의 빌 게이츠를 키워야 한다고 하더니 요즘은 스티브 잡스를 거쳐서 마크 저커버그를 키워야 한다는 목소리가 높다.  정부 주도의 한국판 저커버그 양성 프로젝트가 생기는가 하면 기업이 주도하는 시도들도 있다.  이런 시도들이 나쁜 것은 아니다.


프로그래머 인력을 키울 수는 있을 것이다. 하지만 빌게이츠나 저커버그 같은 사람이 탄생하는 데는 별 도움이 안될 것 같다. 과연 특수한 교육기관이나 양성 기관에서 그런 인물을 양성할 수 있을까?


그럼 한국의 빌게이츠, 저커버그를 양성하기 위해서 그들이 어떤 역량을 가지고 있는지 살펴보자. 물론 “인생 운칠기삼”이라는 말이 있듯 역량이 뛰어나기 때문에 빌 게이츠나 저커버그가 성공한 것은 아닐 것이다.


또한 그런 역량이 있는 사람이 무조건 성공하는 것은 아니다. 하지만 그런 역량을 가진 사람이 많이 배출될 수 있는 환경이 있다면 우리나라도 빌게이츠 같은 사람을 배출할 가능성이 높아질 것이다.


필자는 소프트웨어 개발자가 가져야 하는 역량 또는 소양을 8가지로 구분하여 비교를 해보았다. 비교 대상은 주변에서 흔히 볼 수 있는 일반적인 코더 또는 프로그래머, 경험이 많고 뛰어난 아키텍트 그리고 마지막으로 청년 시절의 빌 게이츠다.


비교 수치는 지극히 필자의 개인적인 의견이기 때문에 실제와는 차이가 있을 수 있으며 전체 맥락을 설명하기 위한 것이니 수치의 정확성을 가지고 논하지는 말자.


각 항목은 뛰어난 개발자 또는 아키텍트가 되기 위해서 필요한 역량과도 상당히 비슷하니 개발자라면 관심을 가져보자. 그럼 각 항목을 살펴보자


1. 창의력

남들이 생각하지 못하는 새로운 생각을 해내고, 문제에 봉착했을 때 참신하고 뛰어난 해결책을 찾아가는 능력이다. 단시간의 교육으로 배울 수 없으며 소프트웨어에 대한 지식뿐만 아니라 다양한 인문학도 창의력과 연관이 있다.


2. 논리력

소프트웨어 개발자에게 필수적으로 필요한 역량이다. 수학 교육과 다양한 논리 교육으로 향상 될 수 있으며 선천적인 지능에 크게 좌우된다. 이를 향상하기 위해서는 어렸을 때부터 오랫동안 꾸준한 교육이 필요하다.


3. 커뮤니케이션 능력

일반 코더에게는 그렇게 높은 수준이 커뮤니케이션 능력이 요구되지 않지만 뛰어난 아키텍트가 되려면 상당히 중요한 능력이다. 대화능력, 듣기능력, 토론기술, 대인기술, 설득능력, 인내력 등이 필요하다. 이런 능력은 암기식 교육환경에서는 키워지기 어렵다.  어렸을 때부터 토론식 교육 환경이 필요하며 능력을 키우기 위해서 시간이 매우 오래 걸린다.


4. 문서 작성 능력

가독성이 뛰어난 문서를 작성하는 기술이다. 일반적인 쓰기 능력, 정보 조직화 기술 등이 필요하며 일반 코더들이 가장 부족한 능력 중 하나이다. 십 수년의 학교 교육을 통해서 기초를 다져야 하며 실전 개발을 통해서도 오랫동안 단련해야 향상되는 능력이다.


5. 컴퓨터, 소프트웨어 지식

소프트웨어 동작원리, 자료구조, 알고리즘, 개발언어 등 개발의 기초 지식이다. 대학의 소프트웨어 관련학과에서 주로 가르치는 것이고 단시간에 기초를 닦을 수 있고 독학도 가능하며 실전 개발을 통해서 꾸준히 습득하는 지식이다. 단기적이고 집중적인 학습이 가능하다.


6. 코딩 능력

누구나 아는 코딩 파워다. 일반 코더의 능력을 구분하는 기준이며 그 능력차이는 코더마다 천지차이다. 다른 부분에 비해서 상대적으로 단기적인 교육의 효과가 있다.  우리나라 프로그래머들이 별로 떨어지지 않는 능력이다.


7. 소프트웨어 공학 경험

소프트웨어를 빠르게 개발하기 위한 공학적인 지식과 경험이다. 소프트웨어 분석, 설계, 소스코드관리, 이슈관리, 테스트, 프로세스, 툴, 개발문화 등 광범위한 영역의 경험이 필요하다. 학교에서는 배우기가 거의 불가능하며 제대로 된 개발환경에서 실전 개발을 통해 배워야 하며 매우 오랜 시간이 걸린다.


8. 도전정신

소프트웨어 개발자에게 꼭 필요한 역량은 아니지만 빌게이츠나 저커버그를 양성한다고 하면 필요한 정신이다. 타고난 유전자가 큰 영향을 미치며 주변 환경에 영향을 받을 수 있다. 단기적인 교육으로 향상하기는 어렵다.


이 중에서 교육기관이나 양성기관에서 단기적으로 키워서 효과를 볼 수 있는 분야는 소프트웨어 지식이나 코딩 정도이다. 나머지는 어렸을 때부터 꾸준히 키워야 하거나 실전 개발을 통해서 배워야 하는 것이다. 인위적이고 단기적인 교육으로 빌게이츠나 저커버그를 만들어낼 수 없다는 것은 자명하다. 인문학을 조금 더 가르치는 것도 새발의 피일 뿐이다.


교육기관이나 양성기관에서 배출할 수 있는 한계는 코더 또는 프로그래머이다. 굳이 정부 주도로 한국의 빌게이츠나 저커버그를 양성하지 않아도 한국의 소프트웨어 환경이 충분히 매력적이라면 머리 좋고 도전정신이 뛰어난 인재들이 뛰어들 것이고 그 중에서 빌게이츠나 저커버그 같은 사람도 탄생할 것이다.


직업훈련소 같은 학원을 세울 것이 아니고 불합리한 소프트웨어 업계를 바로잡는 제도와 법률을 손보고 도전하는 청년 창업자를 지원하는 것이 좋겠다. 그렇게 소프트웨어 생태계를 건강하고 매력적으로 만들어야 우수한 인재들이 모여들고 소프트웨어 환경은 더욱 좋아질 것이다.



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

전규현 사람과 기술

개발자, 회사의 과거인가 미래인가

2012.12.06 12:09 by 전규현


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







개발자는 소프트웨어 회사의 가장 중요한 자산이면서 서로 상반된 2가지 가치를 가지고 있다.


첫 번째는 ‘과거의 가치’이고

두 번째는 ‘미래의 가치’이다.


나는 과거의 개발자일까? 미래의 개발자일까? 스스로 판단하기는 어려울 것이다. 동료나 경영진에게 내가 퇴사를 하면 어떻게 될까?라는 질문을 해보면 짐작할 수 있다.


내가 퇴사를 하면 과거에 개발해 놓은 제품들을 어떻게 하지?라는 생각이 가장 먼저 들면 ‘과거의 개발자’에 가깝다.


반대로 내가 퇴사를 하면 과거에 개발해 놓은 제품들은 문제가 없는데 미래에 개발할 제품은 누가 개발하지?라는 생각이 들면 ‘미래의 개발자’라고 볼 수 있다.


회사나 개발자 입장에서 권장되는 개발자 타입은 미래 가치를 많이 지닌 “미래의 개발자”이다. 미래의 개발자가 지금은 가치가 적은데 미래에 가치가 높다는 의미가 아니다. 미래에 가치가 더 있고 시간이 흐를수록 점점 가치가 높아진다는 의미다.


과거의 가치를 더 많이 가지고 있는 ‘과거의 개발자’는 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식이 머리 속에 있기 때문에 동료나 신입개발자와 지식을 공유하기 어렵다. 본인이 의도해서 그렇게 한 것은 아니지만 결과적으로 자신이 과거에 만들어 놓은 소프트웨어를 인질삼아 회사와 인질극을 벌이고 있는 것과 같다.


물론 이런 개발자가 퇴사를 한다고 회사가 망하는 것은 아니지만 적게든 많게든 타격을 입게 되고 심한 경우 회사는 퇴락의 길을 걷기도 한다. 따라서 회사는 이런 개발자에게 질질 끌려 다니곤 한다. 이런 상태의 개발자는 스스로도 상황의 피해자일 뿐이다.


미래의 가치를 가진 ‘미래의 개발자’는 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수를 수월하게 할 수 있도록 개발 과정에서 적절히 문서화를 해 놓았고, 아키텍처를 깨끗하게 만들었으며 모든 이슈는 이슈관리시스템에 기록으로 남겨 놓았다. 그리고 Peer review를 통해서 이미 많은 지식을 동료들과 공유를 한 상태다.


이런 합리적인 개발 과정을 통해서 본인은 분석, 설계 능력이 꾸준히 향상되어 왔으며, 회사도 성장에 걸맞게 프로세스와 개발문화가 발전되어 왔다. 유지보수에 허덕이지 않으므로 신기술에 대한 연구에 소홀하지 않아서 미래에는 과거 제품들보다 한 단계 수준 높은 제품을 만들어 낼 것이다.


언뜻 보기에는 과거의 엄청난 폭풍 코딩을 통해서 짧은 시간에 많은 제품을 만들어내는 성과를 낸 ‘과거의 개발자’가 영웅처럼 보이지만 미래의 가치를 지닌 ‘미래의 개발자’가 진정한 영웅이다.


필자는 대기업부터 작은 소기업까지 여러 소프트웨어 회사를 다니면서 개발자와 경영진을 대상으로 소프트웨어 개발에 대해서 강연이나 세미나를 많이 한다. 그럴 때 이런 질문을 하곤 한다.


“오늘 회사를 그만둬도 당장 큰 문제가 발생하지 않는 사람 손들어 보세요”.

“오늘 회사를 그만두면 회사가 당장 큰 일 나는 사람 손들어 보세요”.


이 두 가지 질문 중에서 두 번째 질문에 손을 드는 사람이 상당히 많다. 특히 주변에 특정인을 가리키며 손을 들라고 하는 경우가 많다. 이런 사람은 십중팔구 ‘과거의 개발자’이다.


과거에 엄청나게 많은 일을 해냈지만 대부분은 유지보수에 치여 본인도 발전 못하고 격무에 시달리고 있는 경우이다. 수많은 문제와 이슈는 본인만 알고 있어서 수시로 불려 다니고 정작 본인은 개발할 시간이 없고 발전도 어렵다.


물론 ‘과거의 개발자’양산이 개발자에게 책임이 있는 것은 아니다. 소프트웨어 개발 환경이 회사에서 제공하는 프로세스, 시스템이 열악한 상태에서 전적으로 개발자의 내공에 의존을 하기 때문에 개발자도 어쩔 수 없이 ‘과거의 개발자’가 되어 버리는 것이다.


‘과거의 개발자’가 주도하는 회사는 엄청난 개발자 Risk를 안고 있는 것이다. 뛰어난 개발자가 많지만 이들이 한두 명만 나가도 회사가 휘청대며, 유지보수에 발목을 잡혀서 앞으로 나가기 어려운 상태인 경우가 많다.


회사는 개발자가 개발에 전념할 수 있고 개발 과정에서 꾸준히 성장할 수 있도록 환경을 제공해야 한다. 개발자 경력을 보장하는 것은 물론이고 프로세스와 기반시스템을 제대로 갖추고 개발문화 구축에 제도적인 노력해야 한다. 그렇게 해서 개발자 내공에 의존하는 개발이 아닌 시스템에 의존한 개발이 되어야 한다. 그런 환경에서야 개발자가 최고의 활약을 할 수 있다.


그래야 개발자도 행복하게 개발을 할 수 있고 회사도 개발자 Risk가 줄어든다. 이런 환경에서 성장하는 개발자는 신참때는 주로 코딩을 하지만 고참이 되어 갈수록 설계, 분석에 집중하고 문서를 통한 협업에 능숙해진다. 이런 방법이 개발자와 회사 모두에게 좋은 방법이다.


여전히 개발자의 내공에 의존한 개발 환경을 가진 회사에서 유지보수에 허덕인다고 개발자를 탓하지는 말자. 지금이라도 ‘미래의 개발자’를 위한 환경에 대해서 고민해보자.


책에도 다 있고 이론은 많지만 현실에서 실천이 어려운 것이다. 이론으로는 배울 수 없고 경험에 의해서 밖에 배울 수 없기 때문이다. 책과 이론은 약간의 도움을 줄 뿐이다.



이 글은 Tech it에 기고한 글입니다.


image by CEThompson


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

전규현 사람과 기술

  1. 이 글이 뜻 하는 바는 알겠지만, 논리?예시가 적절치 못 한 것 같아서 한 글자 남깁니다. 예시로 들었던, 적절한 문서와 좋은 아키텍처는 보는 사람 입장에 따라서 천차만별입니다. 동일한 문서와 아키텍처도 충분하다고 하는 사람이 있는 반면, 부족하다는 사람도 분명 있습니다. 그렇다고 그 개발자가 과거의 개발자 인가요? 예시가 비약적인 면이 있습니다. 그리고, 유지보수에 허덕되는 사람은 과거 개발자가 아니라, 여러가지 에러케이스에 대응하지 못 한 수준 낮은 개발자 일 뿐 이라고 생각이 듭니다. 글쓰신 분이 컨설턴트라, 개인의 능력 보다는 회사 개발 프로세스의 중요성에 대해 강조 하는데 글의 주안점이 있는 것 같습니다.

  2. 안녕하세요. 저는 컨설턴트이기 전에 소프트웨어 개발자입니다. 따라서 개인의 역량을 매우 중요한 요소로 보고 있습니다. ^^ 각 글마다 주안점이 다르므로 여러 글을 읽어보시고 종합적으로 생각하시면 좋겠습니다.

  3. 물론 개발 프로세스도 중요 합니다. 하지만 적절하지 못한 개발 프로세스는 업무의 가중이라는 점도 충분히 컨설턴트 해 주실 수 있는 부분이라고 보여지네요. 많은 이들이 보고, 겪은 것과 같이, 수 많은 제도와 프로세스 때문에 소프트웨어가 하향평준화 될 수 있는 위험도가 분명히 있습니다.

  4. 제 글중에 http://allofsoftware.net/entry/소프트웨어-관료화 가 있습니다.
    이글을 보면 적절치못한 프로세스로 인해서 효율성이 오히려 낮아지는 위험에 대해서 경고하고 있습니다. 참고하세요.

  5. 와... 이렇게 좋은 블로그를 이제서야 발견하게 되다니 ㅠㅠ
    요즘 개발자와 함께 일하는것 때문에 많은 고민인데,
    주옥같은 글 감사합니다. ^-^

전지전능한 슈퍼 개발자의 역설

2012.11.22 10:02 by 전규현


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






필자는 여러 소프트웨어 회사에서 많은 개발자를 만난다. 그러면 보통 회사에 한두명씩 전지전능한 슈퍼 개발자가 있는 것을 보게 된다.


이들은 코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반관리, 전략 수립 등 엄청나게 많은 일을 한다. 직책은 대부분 팀장이다.


여러분의 회사에도 이런 개발자가 한두명씩은 있을 것이다. 이들이 여러분의 롤모델인가? “나도 그런 전지전능한 개발자가 되어야지”라는 다짐을 하는가? 아니면 혹시 여러분이 이런 전지전능한 개발자인가?


이렇게 많은 일을 하는 개발자가 One man company에만 있는 것이 아니다. 개발자가 수백명이 넘는 회사에서도 드물지 않게 만날 수 있다.


이런 회사에서는 모든 길이 로마로 통하듯이 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결이 된다. 이 전지전능한 개발자가 모든 기술과 정보를 꽤 뚫고 있어서 문제가 발생하면 즉시 해결해주고 회사는 그럭저럭 굴러간다. 이 개발자가 나가면 회사는 망할 것만 같다.


이런 현상이 좋아보이는 사람도 있을지 몰라도 회사는 인력적으로 큰 리스크를 안고 있는 것이고 뛰어난 개발자를 가장 가치 있는 일에 제대로 사용하지 못하는 손해를 입고 있는 것이다. 전지전능한 개발자는 본인이 선택을 해서 그런 위치가 된 것은 아니다.


회사가 성장과정에서 적당한 때 조직을 전문화하고 변화를 꾀했어야 하는데 그냥 달려만 오다보니 능력이 좋은 개발자가 이거 저거 다 떠 안게 되면서 이런 현상이 벌어지게 되었다. 좀더 잘할 수 있는 분야에 집중했다면 본인 역량 면으로도, 미래 가치면으로도 훨씬 좋은 결과를 가져왔겠지만, 지금은 회사의 맥가이버가 된 상황에 만족할 수 밖에 없다.


다른 회사로 가면 지금의 가치는 대부분 사라지고 만다. 개발자 본인에게도 안타까운 상황이다.


어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능하다. 아주 작은 회사에서나 그렇게 하는 것이다. 이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 한다. 모든 일을 잘한다는 것은 애초에 불가능하다. 특히 중요한 일은 주 업무인 개발을 할 시간이 확 줄어 든다는 것이다.


대부분의 이들은 예전에는 뛰어난 개발자였다. 하지만, 개발 이외 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됐다. 그리고 각 일의 Switching cost가 만만치가 않다. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거다.


심지어는 그런 개발자에게 테스트, 고객 응대, 기술 지원까지 하라는 것은 100원주고 20원짜리 일을 시키는 것과 같다. 비효율적일 뿐만 아니라 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못한다.


이런 슈퍼 개발자는 다른 소프트웨어 회사에 가면 가치가 확 떨어진다. 분야가 달라지면 Domain Knowledge 관련 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 된다. 관리자가 되어야 하나 고민이 많다. 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되는 경우도 있다.


회사는 이들에 대한 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 된다. 이들이 등돌리면 회사는 휘청거린다.


이것이 개발자 탓일까? 아니면 회사 탓일까? 회사 탓이다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야한다. 그런데 개발자가 맨땅에서 북치고 장구치고 다 하고, 회사에서는 이를 방치하다보니 이렇게 되는 것이다. 하지만 많은 경영자들은 개발자가 잘 하니 그냥 그렇게 개발자가 다 해야 하는 것으로 아는 경우가 매우 많다.


그럼 어떻게 해야 할까?


개발자가 개발에 전념할 수 있도록 항상 여건을 조성해줘야 한다. 회사가 아주 작아서 어쩔 수 없이 개발자가 여러가지 일을 겸해서 하고 있다고 하더라도 회사가 조금만 커져도 개발자의 일에서 개발업무가 아닌 일을 떼어낼 수 있도록 준비를 해야 한다.


조직이 조금 커지면 테스터를 뽑고, 기술지원인력을 보강하는 것이 좋다.


개발자 10명이 이거 저거 모든 일을 다하는 것보다. 개발자 7명에 테스터2명, 기술지원 인력 1명인 조직이 더 낫다. 개발자가 개발에 더 집중할 수 있고 개발자 10명이서 하는 일보다 더 많은 일을 할 수 있다. 물론 조직과 더불어 프로세스, 기반시스템, 개발문화도 뒷받침이 되어야 하지만 이는 기본으로 생각하자.


이렇게 조직이 분리되고 개발자가 개발에 전념을 할 수 있어야 개발이 좀더 체계적으로 진행된다. 다른 조직의 인력과 협업을 하기 위해 필요한 최소한의 문서도 만들어야 하고 프로세스도 자연스럽게 필요하게 된다. 커뮤니케이션을 위한 기반시스템도 잘 활용하게 된다.


조직이 더 커지면 분리해야 하는 역할이 점점 많아진다. 즉 조직이 세분화 된다. 이는 회사 규모에 따라서 다르니 이 일이 개발자가 해야 하는 일인지 잘 생각해보고 결정하면 된다.


여기서 개발자의 업무를 모두 나열할 수는 없지만 회사에서 개발자가 개발에 집중할 수 있도록 노력하는 일은 대단히 중요하다. 개발자가 잘 해낸다고 그냥 방치하면 안된다. 개발자는 개발을 잘할 때 회사의 보물이 되는 것이다. 다른 일들은 여건이 되는 대로 다른 전문가에게 맡기도록 하자.


이 글은 Tech it에 기고한 글입니다.



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

전규현 사람과 기술

  1. "여건이 되는 대로"... 에 함정이 있는 것 같습니다. ㅎㅎㅎ

  2. 내 스스로를 평가하기는 그렇지만 왠지 저 일들 다하고 있는것 같다. 아직 대리인데..회사탓.... 이직해야하나..^^; 다른곳에 가면 저일들이 다 소용없어진다고...하~ 역쉬 우물안 개구리였나... 고민스럽네.. 후~~

한국에서 외국인 개발자가 일하기 어려운 이유

2012.10.23 20:00 by 전규현


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






소프트웨어 회사의 경영자는 항상 개발자 수급을 고민한다. 우수한 인재를 싸게 쓰고 싶지만 좋은 개발자를 찾기도 어렵고 인건비가 여간 비싼 것이 아니라고 생각한다. 물론 개발자 입장에서는 많지 않지만 경영자는 반대 입장이다.


그러다 보면 저렴하고 우수한 외국인 개발자를 쓰고 싶은 욕구가 생겨난다. 중국이나 인도 개발자들은 평균적으로 인건비가 국내 개발자보다 저렴하고 실력도 뛰어나다. 그래서 실제로 많은 회사들은 외국인 개발자 채용이나 현지 개발센터를 설립하는 일들을 그동안 많이 해왔다.


경우에 따라서는 인건비 이슈가 아닐 수도 있다. 외국인 개발자를 활용하는 것이 국내 개발자에게 들어가는 비용보다 더 많이 들어가기도 한다. 그럼에도 불구하고 개발 인력 수급 문제 해결과 조직의 Global 문화 흡수 등 여러가지 이유로 외국인 개발자 활용 전략을 추진해 왔다. 


나름 성과를 내고 있는 회사도 있으나 대부분은 실망이 큰 것이 사실이다. S사 같은 경우는 그룹차원에서 현지 개발자를 채용하여 각 계열사로 정책적으로 외국인 개발자를 배치하고 있으나 경영진의 바람과 외국인 개발자와 같이 일하는 국내 개발자와 평가는 차이가 꽤 크다. 뛰어난 개발자를 데려다가 단순 코더로 전락 시키기도 하고 문화적인 충돌로 인해서 거의 활용을 못하는 경우가 허다하다.


그럼 미국 실리콘밸리에서 일하는 인도, 중국 개발자들도 똑같은 상황일까? 전혀 그렇지 않다. 유독 우리나라에서 외국인 개발자들과 같이 제대로 일을 못하는 이유는 언어 장벽외에도 여러가지가 있다. 이것을 잘 생각해 보면 바로 우리들이 가지고 있는 문제를 고스란히 보여주기도 한다. 


우리는 왜 외국인 개발자와 제대로 같이 일을 하지 못할까?

 

1. 언어의 장벽


요즘은 영어를 잘하는 직원들이 많지만 소프트웨어 개발자들 중에는 영어를 잘하는 비율이 좀 낮은 것 같다. 생활영어 정도를 할 줄 안다고 해도 외국인 개발자와 회의나 리뷰를 제대로 하기 어렵다. 대화가 가능해도 훨씬 많은 노력을 들여야 하기 때문에 부담이 커진다. 특히 인도 영어는 더욱 알아 듣기 힘들다. 


2. 문서


외국인 개발자와 같이 일하려면 문서를 기반으로 일해야 한다. 대부분은 프로세스, 스펙 등에 익숙하기 때문에 우리나라와 같이 대충 말로 때우거나 지시하는 환경에 익숙하지 않다. 의사 소통도 쉽지 않은데 매번 말로 지시하고 확인하는 일이 쉽지 않다. 


3. 번역


외국인 개발자와 같이 일하려면 문서를 영어로 작성해야 한다. 모든 문서를 영어로 작성하면 우리나라 개발자가들이 힘들기 때문에 영어로만 작성하기도 어렵다. 한국어로 작성하고 영어로 번역을 해도 보통 어려운 일이 아니다. 최신 문서를 유지하기도 어렵고 싱크가 맞지 않는다. 보통 일이 아니다. 스펙을 제대로 작성했으면 한번만 번역을 하면 되는데 스펙을 제대로 작성하는 경우도 많지 않고 쉽게 바뀌는 일이 흔하기 때문에 매번 번역에 어려움이 있다.


4. 문화


외국인 개발자들이 한국에서 개발을 하면 문화적인 충격이 만만치 않다. 회사와 가정이 똑같이 소중한 외국인 개발자에게 무조건적인 헌신을 요구하는 경우가 많은데 상당히 어려움을 겪는다. 특히 야근 강요와 무리한 일정 요구는 많은 트러블을 일으킨다. 가끔은 후진국 사람이라고 무시하는 경향도 있다.


5. 전문가


우리나라 개발환경은 전문가가 제대로 일하기 어려운 환경이다. 보안 전문가를 데려다가 제대로 활용하지 못하기도 한다. 전문가들이 우리나라에 오면 그냥 똑같은 개발자가 되는 경우가 흔하다. 전문가가 제대로 역할을 하려면 스펙도 제대로 작성되어야 하고 합리적인 개발문화가 있어야 한다.


결론 


이러한 현상은 외국에 외주를 줄 때도 비슷하다. 외국에 외주를 주거나 개발센터 설립등이 쉽지 않은 이유이다.  스펙을 제대로 작성하고 수평적인 조직구조 등 제대로된 개발문화를 가지고만 있다면 이 또한 해결될 수 있다.


 image by niyam bhushan


 


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

전규현 사람과 기술

스타트업과 궁합이 맞는 개발자

2012.10.12 21:18 by 전규현


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









소프트웨어 스타트업의 두 가지 필수 요소를 꼽으라면 좋은 아이디어와 뛰어난 개발자이다.


개발자가 스스로 창업을 하기도 하지만 좋은 아이디어를 가지고 개발자 파트너를 물색하기도 하고 본인이 개발자라고 하더라도 추가로 개발자 파트너를 찾기도 한다. 좋은 개발자는 스타트업의 성공의 중요한 열쇠이지만 구하기 쉽지 않다. 또한, 어떠한 개발자가 스타트업에 꼭 필요한 개발자인지 판단하기 어렵다. 실력이 뛰어나 보이지만 막상 일을 그르치는 개발자도 있다.


만약 스타트업을 위해서 개발자 파트너를 찾고 있다면 어떤 조건이 필요한지 알아보자. 물론 일반적인 소프트웨어 회사에서 개발자를 선택하는 방법과 같은 조건도 있지만 사뭇 다른 요소도 있다.


1.특정 분야 유경험자?


개발자 채용이나 파트너 선택에서 흔히 하는 실수 중 하나가 특정 분야 유경험자의 가치를 너무 높게 보는 것이다.


물론 해당 분야의 경험이 풍부하다면 바로 실무에 투입되어서 일할 수 있는 장점이 있다. 스타트업이 아니고 이미 성숙된 회사라면 대부분 기존 제품 개발과정에서 변변한 기록도 없고 뒤죽박죽이라서 해당 분야에 경험이 풍부한 사람이 아니면 제대로 일할 수 없는 경우가 대부분이다. 그렇지 않은 경우도 있지만 드물다. 또한 개발자들이 많이 들어왔다 나갔다 하므로 무조건 당장 써먹을 수 있는 개발자를 선호한다.


하지만 스타트업이라면 얘기가 좀 다르다. 우선, 개발자 파트너를 특정 분야 유경험자로 한정 지으면 범위가 너무 좁아진다. 소프트웨어에는 수천 가지의 Domain이 있는데 그렇게 범위를 좁히면 좋은 개발자를 구하기 힘들어진다.


오랜 기간 한 분야에만 종사하고 있는 개발자들 중에는 의외로 소프트웨어 개발 능력은 형편 없는 경우가 매우 많다. 대신 Domain 지식만 풍부해서 해당 분야에서 조금만 벗어나도 별 쓸모가 없어지곤 한다. 특히 스타트업은 아직 개발해야 할 분야가 고정 되지 않았기 때문에 특정 분야 유경험자만 찾다가는 골치덩어리 개발자를 떠안게 될지도 모른다.


특정 분야 유경험자보다는 무조건 뛰어난 개발자를 골라야 한다. 분석, 설계, 구현 능력이 뛰어난 개발자가 분야가 바뀌어도 빠른 시간 내에 실력을 발휘할 수 있다. 처음에는 유경험자보다 약간 느릴 수 있지만 역전되는 것은 순식간이다.


실리콘밸리를 보더라도 개발자들이 특정 분야에 국한하지 않고 어떠한 소프트웨어 회사라도 마음대로 옮겨 다닐 수 있는 이유이다.


실리콘밸리에서 개발자를 채용할 때 특정 분야 유경험자보다는 문제 해결 능력이 뛰어난 개발자를 뽑는 것이 그 이유이다. 심지어는 사용하고 있는 개발 언어의 경험을 보지 않는 경우도 있다.


물론, 특정 분야 유경험자가 꼭 필요한 분야도 있기는 하지만 이는 일반적인 케이스가 아니므로 여기서는 언급하지 않는다.


2. 경험이 많은 개발자?


흔히 경험이 많은 개발자가 실력이 뛰어날 것으로 생각하는데 우리나라에서는 통하지 않는다. 물론 경험 많은 개발자 중에서 뛰어난 개발자가 꽤 있는 것은 사실이지만 기대하고 있는 것만큼 많지가 않다.


그 이유는 우리나라 개발 환경이라는 것이 막노동판과 비슷해서 초급 때 벽돌 100장 쌓던 사람이 고참이 되면 200장 쌓을 수 있는 식이다. 공사판 10년 경험이면 멋진 빌딩을 설계할 수 있을 것으로 기대하는 것과는 거리가 멀다. 제대로 된 분석, 설계 경험이 부족하고 개발문화라는 것이 너무 척박해서 오랫동안 개발을 한다고 해서 실력이 많이 향상되지 않는다. 단지, 숙달되고 능숙해지며 해당 분야의 지식이 주로 쌓인다. 여전히 분석, 설계 역량은 미천하고 개발문화는 잘 모르는 경우가 허다하다.


스타트업에는 차리라 경험이 적더라도 두뇌가 뛰어난 개발자가 필요하다. 경험이 너무 많은 것보다 경험은 적당하지만 머리가 좋은 개발자가 다양한 도전에서 뛰어난 결과물을 만들어낸다.


또한 경험이 너무 많으면 수많은 잘못된 문화와 관행에 너무 젖어서 스타트업에서 필요한 혁신을 해내지 못한다. 정말 뛰어난 두뇌를 가지고 있다면 경력이 1,2년이라도 전혀 문제가 되지 않는다. 기존 조직의 개발 문화에서는 별로 배울 것이 없기 때문이다. 기존 환경에서 배운 것이 적은 개발자들이 새로운 스타트업에서 더 좋은 개발문화를 정착할 가능성이 더 높다. 기존에 잘못된 관행에 젖어 있는 수많은 개발자들은 이를 부정하고 화를 낼 수도 있지만 그것이 곧 반증이다.


3. 빨리 개발하는 개발자?


스타트업은 다양한 시도와 빠른 전략이 매우 필요하다. 그래서 빨리 개발을 하는 개발자를 선호하지만 빨리 개발하는 개발자보다는 확실하게 마무리를 잘 해내는 개발자가 더 필요하다. 이는 개발자의 성향과 관련이 있다.


어떤 개발자는 첫 번째 프로토타입은 매우 빨리 만들어내지만 마무리를 제대로 못하는 개발자가 있고 약간은 느려 보이지만 착실하게 개발을 해서 꼼꼼하게 마무리를 하여 제품을 제대로 만들어 내는 개발자가 있다. 이러한 성향은 쉽게 바뀌는 것이 아니므로 일당백을 해야 하는 스타트업에서는 확실하게 마무리를 잘하는 개발자가 더 필요하다. 그렇게 개발하는 것이 최종적으로는 더 빠르다.


같이 일을 해본 경험이 있다면 이러한 개발자를 가려낼 수 있을 것이다.


4. 개성이 강한 개발자?


스타트업에서는 개발자의 실력보다 더 필요한 것이 과연 얼마나 뜻을 하나로 모아서 나아갈 수 있는가 이다. 이 또한 개발자의 성향과 관련이 있다. 회사의 정책이나 비전에 적극적으로 따르는 개발자가 있는가 하면 부정적이고 따로 행동하는 개발자가 있다. 회사의 정책과 비전을 따르지 않는 개발자는 실력이 아무리 뛰어나도 스타트업의 파트너로는 적당하지 않다. 실력만 보고 동참을 시켰다가 두고두고 고생을 하게 될 것이다.


개발자 하나하나가 영향력이 매우 큰 스타트업에서는 특히 중요한 조건이다.


5. 개인 시간이 소중해?


스타트업에서 꼭 필요한 것 중 하나가 멤버들의 헌신이다. 일반 회사에서 항상 야근을 강요하는 그런 헌신이 아니다. 회사에 시간과 노력과 위험부담을 같이 투자한 파트너들로서 미래의 결실을 공유하고자 하는 것이므로 헌신은 매우 필요하다. 따라서 헌신할 수 없는 개발자는 고려하지 않는 것이 좋다.


나이, 가정, 주변 환경이 헌신을 가로막는 경우도 고려를 해야 한다. 가장 중요한 것은 정신적으로 얼마나 헌신을 할 자세가 되어 있는가 이다. 이는 하루 아침에 판단할 수는 없고 스타트업의 중요한 개발자 파트너 구하기 위한 것이라면 꾸준히 관찰을 해야 알 수 있는 요소이다.


아이디어가 스타트업의 중요 요소이듯이 좋은 개발자도 꼭 필요한데 겉모습만 보고 대충 채용을 했다가는 차라리 시작을 안 하느니만 못한 경우가 많다. 몇 년 후에 창업을 생각하고 있다면 주변의 개발자 중에서 위 다섯 가지 조건이 맞는 개발자를 꾸준히 물색해둬야 한다. 그리고 친하게 지내라. 그 중에 한 두명이 당신의 스타트업 파트너가 될 것이다.



이 글은  Tech it에 기고한 글입니다.

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

전규현 사람과 기술

Technical Career Path를 보장하는 방법

2012.09.03 06:00 by 전규현


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





그 동안 개발자 경력에 대한 글들을 여러 건 작성했다. 많은 독자들이 문제 인식에 공감을 했지만 여전히 해결책은 쉽지 않다. 그래서 여기 방법을 제시하고자 한다. 소프트웨어 회사들이 어떻게 하면 Technical Career Path를 보장할 수 있을까?


첫째, 경영자 의식의 변화이다.


경영자가 개발자의 경력을 보장하는 것이 회사에 얼마나 큰 이득이 되는지 깨닫지 못한다면 개발자가 꾸준히 개발만 할 수 있도록 노력할 리가 없다.


축구는 체력이 떨어지는 30대 중후반이면 더 이상 선수로 뛰기 어렵지만, 소프트웨어 개발자는 체력과 상관없이 평생 시간이 흐를수록 점점 더 뛰어난 개발자로 일할 수 있다. 이렇게 뛰어난 선수로 일할 수 있는 개발자들을 관리나 하라고 낭비하지 않고 계속 선수로 뛸 수 있도록 회사에서 지원을 해야 한다는 것을 경영자들이 절실히 깨달아야 한다.


아직은 경영자들이 이같은 인식이 부족하거나 막연히 개념만 인지하고 현실은 다르게 행동을 하는데 주위에서 설득하려는 노력이 필요하다. 이 칼럼들을 공유해도 좋고 외국의 사례를 보여주는 한 방법일 것이다. 이는 회사를 위하고 개발자도 위하는 길이다.


둘째, 개발 조직의 변화이다.


개발 조직은 워낙 회사마다 서로 달라서 하나의 형태를 지켜야 한다고 말할 수는 없다. 하지만 개발 조직이 전문 개발자들이 제대로 일할 수 있는 구조가 되어야 한다. 우선 개발팀장, 개발리더, 매니저 등 구분 없이 마구 섞여서 일하는 것은 지양해야 한다.


조직이 아주 작아서 혼자 다해야 하는 경우를 제외하고는 관리자와 개발자는 구분을 하자. 팀이 커져서 관리 일이 점점 많아지면 더 이상 개발자가 개발을 겸해서 하기는 어렵다. 전문 관리자를 두는 것이 좋고, 프로젝트에서도 프로젝트매니저를 따로 두는 것이 좋다. 개발자는 개발에 전념할 때 가장 높은 성과를 낸다. 개발 외의 일은 관리자나 프로젝트매니저가 맡아야 한다.


셋째, 공정한 평가이다.


소프트웨어 개발자로 공정한 평가를 받기 매우 어렵다. 그래서 평가 대상보다는 평가자가 되려고 하는 경향이 있다. 공정한 평가가 대단히 어려운 일이지만 나름대로 객관적인 근거에 의한 평가를 위해서 노력해야 한다. 개발자가 어찌 해볼 수 없는 이유로 평가에서 불이익을 받는다면 개발을 계속 하기가 싫어질 것이다. 소스코드관리시스템과 이슈관리시스템의 기록을 활용하고 개발 일정 준수 등의 지표를 활용하는 것도 좋은 방법이다.


넷째, 적절한 대우이다.


많은 회사에서 팀장이 되고 관리자가 되어야 더 높은 연봉을 받을 수 있다. 그 주된 이유는 관리와 개발의 분리가 안되어 있어서 구분이 안되기 때문이다. 관리를 하지 않고 평생 개발을 한다고 해서 연봉이나 대우에서 불이익을 받아서는 안된다. 오히려 동일 경력에서 개발자가 관리자보다 더 높은 연봉을 받는 것이 맞을 수 있다. 관리자나 개발자나 자신의 전문분야에서 회사에 기여하는 만큼의 적절한 대우를 받아야 한다.


다섯째, Career Path 제공이다.


회사에서 다양한 Career Path를 제공해야 한다. 개발자는 이들 중에서 적절한 시점에 선택을 할 수 있어야 한다. 계속 개발자로 경력을 발전시켜 나갈 수도 있고 관리자나 프로젝트매니저가 될 수도 있다. 또는 다른 일을 맡을 수도 있다. 한번 개발자 경력에서 벗어나면 다시 돌아오기 어려우므로 신중하게 결정해야 한다.


여섯째, 개발문화, 개발 프로세스, 기반시스템이다.


너무 광범위한 내용이라서 다 설명하기는 어렵다. 개발자가 제대로 일하기 위해서는 공유를 기반으로 한 투명한 개발문화와 적절한 개발 프로세스가 필요하다. 또한 개발에 필요한 기반시스템을 제대로 갖추고 있어야 한다. 아무것도 갖추지 못한 회사에서는 개발자가 아무리 개발을 오래해도 가치를 높이기가 어렵다.


일곱째, 롤모델이 필요하다.


롤모델이 있다면 개발자들에게 확실한 길을 보여줄 수 있다. 하지만 무늬만 개발자가 아닌 진짜 개발자를 외부에서 영입하기는 쉽지 않다. 내부에서라도 개발자들의 롤모델을 만들도록 노력해 보자. 회사에서 가장 뛰어난 개발자들에게 관리 일은 덜어내고 개발에 전념할 수 있도록 해주고 회사의 제도가 이를 뒷받침하도록 하자. 회사의 개발 조직이 더욱 탄탄해 질 것이다.


개발자 경력 보장 문화는 개발자들의 인생이 달린 일이다. 아직은 척박하지만 우리가 하나씩 바꿔나가야 한다. 가장 어려운 일은 경영자를 설득하고 깨닫게 하는 일이다. 고양이 목에 방울달기 같은 일이지만 어렵다면 주변이나 전문가의 도움도 받아보자. 지금은 3D 취급하는 사람들도 있는 소프트웨어 개발이 좀더 좋은 대접을 받기 위해서는 개발자 경력 보장이 중요한 단초가 될 것이다.



image by o5com


이글은 Tech it에 기고한 글입니다.


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

전규현 사람과 기술 경력

무늬만 개발자

2012.07.09 06:00 by 전규현


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







우리나라에서 소프트웨어를 개발한지 10년이 넘은 개발자 중에서 진짜 개발자는 생각보다 적다. 15년쯤 지나면 자신은 스스로를 개발자라고 생각할지 몰라도 진짜 개발자인 경우는 급격히 줄어든다. 대부분은 개발과 관리의 경계에서 애매한 포지셔닝을 하다가 다시는 개발로 돌아오지 못하곤 한다.


그럼에도 자신은 개발자라고 착각을 하는 경우가 많다. 또는 자신을 Architect라고 우기기도 한다.


선임급 개발자를 채용하기 위해서 인터뷰를 하면 이런 "개발자가 아닌 무늬만 개발자"를 자주 볼 수 있다.


매일 수많은 회의에 쫓겨 다니고, 온갖 보고서를 만들고, 수시로 경영진에게 보고하고, 팀원들 관리하고 평가하느라고 시간을 다 보내면서, 스스로는 개발에 관해서 아는 것은 많다고 생각해서 개발할 때마다 간섭하고 스스로 뛰어난 Architect라고 생각한다.


이런 사람들은 개발을 좀 안다고 해도 절대로 개발자가 아니다. 개발과 관리의 차이에 대한 개념도 희미한 상태이다. 대부분은 개발자로 다시 돌아갈 수 없는 상태이다.


절대로 "개발"과 "관리" 둘 다 잘할 수는 없다.


우리나라 대부분의 기업에서 본부장, 부문장, 부서장쯤 되면 이러한 상태에 이르게 된다.  그래도 팀장급에서는 개발자의 모습을 아직도 간직하고 있는 경우가 종종 있다.


하지만 팀장급 이상으로 올라가게 되면 개발자이고 싶은 관리자가 되게 된다. 물론 외형적으로도 완전히 관리자를 선언한 사람도 있겠지만, 여전히 개발자이고 싶은 사람들도 매우 많다.


이렇게 되는 결정적인 이유는 경영자의 개발조직 관리에 대한 오해에서 비롯된다. 경영자는 개발조직을 관리하는 관리자는 개발을 매우 잘 알아야 하기 때문에 가장 뛰어난 개발자들이 관리를 하는 것이 옳다고 생각한다. 그래서 경험 많은 선임 개발자들에게 본부장, 부문장, 부서장을 맡기곤 한다.


개발조직을 관리하는 관리자는 개발에 대해서 개발자만큼 잘 알 필요가 없다. 개발자가 개발에 대해서 아는 정도와 관리자가 알아야 하는 정도는 엄청나게 다르다. 그런데 경영자는 이 둘을 같은 것으로 착각하곤 한다.


개발을 잘하는 개발자는 관리는 전혀 하지 않고 개발에 몰두할 때 가장 높은 가치를 창출한다. 경영자의 착각 속에 개발자는 점점 잘 하지도 못하는 관리 일에 치중하게 된다. 자연스럽게 회사는 개발 파워를 잃게 된다. 그럼 남는 것은 정치적인 경쟁밖에 없게 된다. 불쌍한 개발자들이다.


이렇게 관리자화 된 개발자들은 이직도 곤란하게 된다. 동일한 분야가 아니라면 이직을 해도 회사에 도움이 별로 안된다. 다른 분야로 이직을 한다면 관리 능력이 중요한데 사실 관리는 전문 관리자보다 훨씬 못하기 때문이다. 이미 전문 개발자는 아니기 때문에 다른 분야에서 개발자로서 활약하기도 어렵다. 정말 어중간한 위치기 된다.


결국 그 회사에서 관리자의 길을 걷거나 선택할 옵션이 별로 없게 된다.


물론 개발자 본인이 스스로 이런 선택을 하지 않았지만 결국 이런 결과에 이르는 것이 우리나라 개발자들의 안타까운 현실이다.


개발자가 원하고 실력이 된다면 은퇴할 때까지 개발자의 경력이 보장되는 외국의 상황은 부러울 따름이다.


2008/12/03 - [개발조직] - 우리나라 소프트웨어 회사에는 Technical career path가 없다.


주변의 환경을 무시하고 스스로 개발자로 계속 살아남는 다면 대단한 결심이 필요할 것이다.

하지만 결국 이런 개발자들이 언젠가는 대우를 받을 수 있을 것이다. (당장은 글쎄 …)

그런 환경을 만들고 싶다.


이글은 Tech it!에 기고한 글입니다.


image by  Michael Kappel


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

전규현 사람과 기술

  1. Blog Icon
    정열

    글을 보고 있으니 현재, 제 자신의 상황과 너무 같아서 맘이 불편합니다.
    네! 제가 딱 무늬만 개발자 같습니다. 관리는 배운 적이 없어서 서툴고 그나마 알고 있던 개발지식은 이미 유통기한을 넘긴지 오래된 것들 뿐이고 수박 겉핡기 식으로 대충 본 최신 기술들을 가지고 있으면서 나는 개발자다! 나는 그래도 여전히 개발자다! 하고 자기 합리화를 하고 있었습니다.
    참... 두렵습니다. 앞으로 무엇을 보며 어떤 방향으로 살아가야 정답인지 모르겠습니다.
    이런 애매한 위치에 있는 사람들을 위한 대안(?)은 없는 걸까요?

  2. 안녕하세요. 정열님

    계속 개발자로 일하고 싶다면 경력이 쌓일수록 좀더 High level의 일을 할 수 있도록 역량을 계속 향상 시켜야 합니다. 중간에 관리직과 중간에서 왔다갔다 하다가는 그 기회를 놓쳐버릴 수 있습니다. 꾸준히 자신을 단련하고 향상하는 것이 필요합니다.

  3. Blog Icon
    김재현

    제가 요즘 딱 이 모양새 입니다... 한숨만
    나오네요 ㅜㅜ

  4. 김재현님 안녕하세요.

    어떻게 포지셔닝을 하셨든간에 최선을 다해보세요. ^^

  5. Blog Icon

    저도 한숨이 ...

  6. Blog Icon
    DrunkenJK

    저도 딱 상황이 비슷하네요.
    4년 남짓 첫직장 생활을 이제 정리하고 프리랜서 개발자부터
    차근차근 밟아가려고 용기한번 내봤습니다.
    나중에는 단순 코더가 아닌 개발자로서 대접받는 문화가 형성이 되었으면 좋겠습니다.

  7. 안녕하세요. DrunkenJK님

    개발자도 대접을 받으려면 경력에 걸맞는 실력을 보유해야 겠습니다. 개발자 혼자 역량을 향상할 수 있는 것은 아니고 회사가 개밞문화, 시스템, 프로세스, 제도등을 뒷받침해줘야 그 환경에서 개발자 역량이 향상됩니다.

  8. Blog Icon
    테디

    저도 똑같은 고민을 1년정도 하고 있는것 같군요.
    요즘은 거꾸로 그럼 관리자로 잘 하려면 어떻게 해야 하나 하고 생각해보고 있습니다.
    훌륭하고 유능한 관리자가 되려면 어떻게 해야 할까요?

  9. 안녕하세요. 테디님

    관리자는 제 전문이 아니라서요. ^^
    하지만 좋은 관리자가 되는 방법은 시중에 책도 넘쳐나고 지식을 얻기 쉬운 것 같습니다.

    좋은 개발자가 되는 방법을 알기가 더 어려운 것 같습니다. 그래서 제가 이렇게 용을 쓰고 있습니다. ^^

  10. Blog Icon
    NinJaZeroCool

    안녕하세요 테디님

    글 잘보고 있습니다.

    저도 개발자입니다. 그런데 나이가 40대 접어들면서 새로운것을 받아들이는것이 점점 어려워지네욤
    그리고 자연히 플젝관리 직원관리등하다보니 이도저도 안되는모양세입니다.

    저희는 작은회사라 팀장 이라도 개발에 투입이 됩니다.
    다양치 않아서 늘지 않은상태입니다.

    아직까지는 개발하지만 점점 힘들어지는데요 외국에 보면 머리 햐얀사람도 개발하는것 보면
    부럽기까지 합니다.

    그 노하우를 배우고 싶군요!!! ^^

    오늘도 무더운날씨입니다. 몸건강하세요 ^^~

  11. 안녕하세요. NinJaZeroCool님

    대한민국 모든 개발자들의 고민 같아요. ^^

  12. Blog Icon
    테디

    말씀 감사합니다.
    전 그래도 아직 40대는 아니네요..
    그래서 전 다시 개발에 발을 담그려고 합니다.
    거의 1년이상을 제대로 된 개발을 못했는데 다시 해보려 합니다.
    그래도 남는것은 개발인것 같고 전규현님 말씀처럼 좋은 관리자가 되는 방법은 조금 뒤로 미뤄도 될것 같다는 생각입니다.
    훌륭한 개발자 또는 엔지니어로서 커리어를 확실히 쌓아두는 것이 향후 개발자건, 관리자건 선택의 폭을 넓히고 기회를 만드는 지름길이라 판단했습니다.
    쉽지 않고 자신감도 많이 떨어졌지만 다시 해볼랍니다.
    저와 같은 고민을 하시는 분들 모두 모두 화이팅입니다!!!
    개발이건 관리건 인생의 목표는 '행복'이라 생각합니다.

한국의 경영자들은 가짜 영웅을 원한다.

2012.06.18 01:51 by 전규현


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






개발자들의 고충 중에는 다음과 같은 것이 이다.

"제대로 하고 싶은데 그러면 경영자의 눈에 들지 않는다"는 것이다.

스펙도 제대로 작성하고 리뷰도 하고 싶은데 경영자는 문서를 작성하고 있으면 노는 줄 알고 제대로 하는 것보다는 빨리하기를 원한다고 한다.


실제로 많은 경영자들이 Software 개발에 대한 이해 부족으로 회사에 진정으로 필요한 개발자가 어떠한 사람인지 잘 모른다. 그래서 진짜 영웅들이 가짜 영웅에 밀려서 대우를 못받는 경우가 많다.


그럼 회사에서 꼭 지켜야 하는 가짜 영웅과 회사를 좀먹는 가짜 영웅은 어떻게 다른지 알아보자.


가짜 영웅 

진짜 영웅 

말이 많고 잘 떠버린다. 

자신만 믿으라고 한다.

묵묵히 일한다.

잘하는 것이 눈에 잘 안띈다. 

첫번째 버전을 엄청나게 빨리 만들어 낸다.

합리적인 일정을 제시하고 차근차근 개발한다.

프로젝트 마무리를 잘 못한다. 
다른 사람들이 마무리를 해준다. 

잽싸게 다른 프로젝트로 넘어간다.

자신이 맡은 프로젝트는 책임감을 가지고 끝까지 마무리를 잘 한다. 

회사의 규정을 잘 안지킨다.

자신은 특별대우를 받아야 한다고 주장한다.

회사의 규정외로 높은 대우를 받기를 원한다. 

회사의 정책과 규칙을 잘 따른다. 

자신이 그만두면 회사가 망하는 줄 안다.
또 그렇게 주장한다.
 
실제로 회사를 그만두면 회사가 휘청한다. 

당장 퇴사를 해도 아무 문제가 없을 만큼 문서화도 잘하고 후배들도 잘 양성해 놓았다.

실제로 퇴사를 해도 회사가 문제 없이 돌아간다. 

자신의 지식이나 자신이 개발한 제품의 정보에 대해서 타인과 공유를 잘 안한다. 

공유를 잘 한다. 

스펙 등 문서를 잘 작성하고 다른 개발자와 업무를 잘 나눠서 일한다. 타인, 특히 후배들이 작성한 문서나 코드 리뷰를 잘 한다.

유지보수 비용이 점점 더 많이 들어가는데 이는 유지보수 인력이 개발을 잘 못해서 그런 것이라고 주장한다. 

유지보수에 비용과 시간이 별로 많이 안들어가도록 제품의 Architecture를 잘 만들어 놓았다. 

회사의 미래를 위해서 이런 사람은 최대한 빨리 짤라 버려야 한다. 

하지만 기존에 벌려 놓은 것이 많아서 당장 짜르기도 어렵다.

회사의 미래를 위해서 이런 사람은 높은 연봉을 주고라도 꼭 잡아야 한다. 


회사에서 어떤 사람을 지킬 것인지 잘 생각해야 한다.


image by Morinoko








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

전규현 사람과 기술

  1. Blog Icon
    초보

    본문에 오타가 있어요.
    '꼭 지켜야 하는 "가짜 영웅"과 회사를 좀먹는 "가짝 영웅"은'

  2. 고쳤습니다. 감사합니다.

  3. Blog Icon
    이창환

    꼭 지켜야 하는 "진짜 영웅" 으로 바뀌어야 하는 것 같아 보여요.

  4. Blog Icon
    지나가다가

    일단 영웅이라는 잣대로 구분할 수 밖에 없었는가 하는 아쉬움이 들구요.
    어떤 쪽이든 자신들만의 향기가 묻어있는 개발자라고 생각을 합니다.
    10년간 일해오면서 저렇게 극과 극을 달리는 사람들을 본적이 없는 제 경험에 의해서는
    안좋은점으로 꽉찬 개발자 좋은점만 꽉찬 개발자로 나뉘는 것에 대해서는 공감이 힘드네요.

    양쪽의 스타일이 적당히 섞여 있는 개발자들이 정말 잘 성장하는 케이스를 많이 봐왔는데요.

    물론 우리나라 문화가 좋다는건 아니지만 문화적인 특성을 간과하지 않고 제 느낌을 이야기 해보자면
    좋은 개발자로 분류해놓은 스타일은 너무 많은 고민들을 합니다. 나쁜게 아니라 경우에 따라서는
    안좋은 개발자가 될 수 도 있는거죠.

    스타트업을 하는데 있어서는 초반 프로토타입이나 실제 피드백을 받을 수 있는 빠른 개발력이 우선시 되는 경우도 많습니다.
    이런 경우에는 전자의 몇가지 능력을 가진 사람이 능력자가 되는 경우도 생기겠죠.


  5. 안녕하세요.

    실제 개발에 있어서 진짜 영웅처럼 개발을 해야 더 빨리 개발합니다. "가짜 영웅"은 빨리 개발하는 것 처럼 보이는 것 뿐입니다.

    스타트업이라고 하더라도 진짜 영웅이 필요합니다. 대부분의 성공한 스타트업들은 진짜 영웅이 있게 마련입니다.

    진짜영웅 스타일로 개발할 경우 가장 빨리 개발하는 방법도 압니다.

    여러 보통의 소프트웨어 회사를 경험해보면 대부분 가짜 영웅들이 존재합니다. 그 1/10 정도의 비율로 "진짜 영웅"을 볼 수 있을까요? 실제 가짜 영웅에 발목 잡혀서 쓰러져 가는 회사들도 매우 많습니다.

  6. Blog Icon
    지나가다가

    말씀하시는 진짜영웅이 되어야 더 빠른 개발을 할 수 있다는 어느정도 동의합니다.
    하지만 반대의 경우에 과연 빨리 개발하는 것 처럼 보이는 것 뿐이다라고 단정지을 수 있을까요?
    케이스 바이 케이스가 적절치 않다고 생각이 듭니다.

    그리고 대부분 성공한 스타트업들이 진짜 영웅때문에 성공하게 된다는 점에는 전혀 수긍을 할 수가 없습니다.
    개인적으로는 스타트업들이 성공을 했기에 그에 포함되는 개발자가 영웅이 된 것이라고 생각을 하거든요.
    규현님이 말하시는 진짜 영웅이 스타트업에서 실패하게 되면 영웅이라고 불릴 수 있을까요?
    스타트업의 성공여부는 진짜영웅 가짜영웅의 논조에서 바라볼 것이 아니라,
    사업성과 빠른 추진력에서 바라봐야 한다고 생각합니다.

    스타트업의 특성상 빠른 피드백과 빠른 프로토타입등의 개발에 있어서
    규현님께서 말하는 진짜영웅들은 어느정도 시간이 보장되어야 하는 경우가 많습니다.
    물론 좋지만, 유두리가 있어야 한다는거죠. (진짜영웅의 케이스가 유두리가 없다는 말은 아닙니다)
    하지만 전자의 경우는 규현님께서 정의해놓은 막장의 케이스가 아니라 4~5가지의 성향과 진짜영웅의 1~2가지의 성향만 합쳐져도 엄청난 시너지를 내는 경우가 많습니다.

    특정 부분 공감은 하지만 서술하신 위의 분류대로 딱 나뉘게 되는 개발자들이 얼마나 될까요?
    물론 개개인의 경험에 따라 많이 봤을수도 적게 봤을수도 보지 못했을 수도 있습니다.

    제 개인적으로는 저 나뉨이 좀 현실성이 없는 나뉨으로 보여져서 글을 적었던 겁니다 ^^;;

  7. 지나가다님 안녕하세요.

    스타트업이 성공하는 케이스는 별의별 경우가 다 있죠. 좋은 개발자들이 있으면 좀더 성공할 확률이 높겠지만, 그렇지 않은 경우인데도 아이디어가 좋아서 초기에 큰 성공을 거둘 수 있고, 반대로 뛰어난 개발자들이 모여서 나쁜 아이디어로 실패할 수도 있습니다. 개발 역량과 비즈니스 성공 여부는 당연히 일치하지는 않습니다.

    모든 개발자를 흑/백처럼 가짜영웅/진짜영웅으로 나누지 마십시오. 그렇게 나누라고 하지도 않았습니다. 모든 개발자를 이 둘로 나뉘어야 하는 것으로 오해를 하신 것 같군요.

    소프트웨어 회사에서 개발자가 수십명 또는 수백명이되면 그중에서 한두명 또는 몇명의 영웅 개발자들이 눈에 띄게 됩니다. 그런 영웅 개발자들은 회사를 좌지우지하고 많은 사람들에게 영향을 끼칩니다.

    그런데 많은 회사들이 가짜영웅 개발자들에 휘둘리는 것을 많이 볼 수 있습니다. 그래서 가짜영웅 구별법을 적은 겁니다.

    가짜영웅을 자주 접하시게 되면 이 글이 도움이 되실 겁니다. ^^

  8. Blog Icon
    한유신

    후배가 여기 글을 퍼와서 찾아왔네요...
    현직에서 일하는 개발자로서...
    조금 불쾌한 감이 없잖아 있습니다...

    태생적인 글 같지만...
    여전히 대부분의 많은 사람들이 하는 소리와 별반 다르지 않아요..
    책임의 소재는 항상 끄트머리의 개발자에게 전가하는 것이 같은 귀결이군요...
    즉... 서비스나 프로젝트의 성공적인 마무리는... 개발자가 좋아야 한다...


    실력있는 영웅도 처음에는 여러 시행착오를 거쳤을 것이고...
    그러한 경험이 영웅에 오르게 하지 않았을까요...?
    다행이 그 영웅은 그런 시기를 견딜수 있는 여유 있는 주군(?)을 재수 좋게 만난 것일테구요...
    저도 그런 좋은 주군 만나고 싶네요...



  9. 한유신님 안녕하세요.

    제가 쓰는 글들 중에서 아주 가끔 독자들의 반발을 사는 글들이 있습니다. 이번에도 그 중에 하나 같습니다. ^^ 가끔 들르시는 분들이 그러긴 하지만 제 글을 여러개 읽어보면 그런 맥락이 아니라는 것을 아실 겁니다.

    우리나라 개발자들 중 상당 수는 피해의식을 가지고 있습니다. 회사가 당연히 해줘야 할 것을 제공 받지 못하고 착취를 당하고 환경도 좋지 않았는데, 덤터기로 책임을 지기도 하기 때문입니다. 그래서 조금만 민감한 내용이 나와도 자신을 비난 하는 것처럼 들리는가 봅니다. 이번 글도 그런 뉘앙스를 보였나본데, 그런 맥락은 아닙니다.

    이글을 읽으시는 독자의 9할 이상은 여기서 말하는 양쪽 끝의 영웅은 아닙니다. 대부분 묵묵히 자기일 하는 개발자들입니다.

    그리고 가짜영웅이 스스로 그렇게 되고 싶어서 그렇게 된 것은 아니고 회사가 환경을 제공하지 못해서 본의 아니게 그렇게 된 경우가 더 많습니다. 제 블로그에 그런 내용의 글도 꽤 있습니다. ^^

    개발자들이 어떤 내용에 대해서 민감한지 또 배우는 기회가 되었습니다. ^^

    글에서 말하는 가짜영웅 개발자를 진짜로 접해 봤다면 그들이 동료 개발자들에게는 얼마나 피해를 주는데 회사에서는 대접을 받고 있을 수 있다는 것을 아실 겁니다. 제 글이 이런 문제점을 제대로 표한하지 못했다면 제 글쓰는 능력이 좀 부족한 것이겠지요. ^^

    제 글솜씨도 점점 나아지겠죠? :)

  10. Blog Icon
    손님

    어떻게 보면 돈 적게 받아도 회사 정책 잘 따르면서 불만 얘기 안하고, 언제든지 짤라도 회사가 돌아갈 수 있는 사람이군요..

    급여나 고용에 대한 회사의 정책은 어디까지나 회사를 위한 것이지 근로자를 위한 것은 아니니까요.

    저러면 경영자 입장에선 좋겠네요.

    한국에선 자기가 정말 0.5% 에 속하는 특급 개발자가 아닌 한, 가짜 영웅이 살기 좋습니다.

  11. 그런 개발자가 회사에 더 필요하기 때문에 더 높은 연봉을 받아야 하는데 그렇지 않은 회사라면 문제가 있는 회사지요.

    이글을 쓴 이유도 많은 경영자들이 이들을 구분하는 능력이 없기 때문에 경각심을 불러 일으키려고 한 겁니다 ^^

  12. 프로그래머랑은 거리가 먼 역사전공자지만 글 잘 읽고 있습니다.
    (물론 어려운 용어는 걍 넘기지요)
    오늘 글은 매우 유익했습니다.
    뭐랄까 이것저것 생각할 기회를 주네요.
    지금도 회사를 다니고 있어서 난 어느쪽인가도,
    사료에서 볼 수있는 조직의 인간이 가지는 의미를 생각해볼 수 있었네요.

    영웅이란 단어를 바꾸기만 하면 어디나 통용될 수 있는 것이라 생각합니다.

  13. 안녕하세요. RGM-79님

    반갑습니다.

  14. Blog Icon

    실제 빠른게 아니라 빠르게 보이는 것에 공감합니다.
    현실은 정말 답답합니다. 당장 뭔가 빨리 나오면 빨리 한 것 처럼 생각하는데 빨리 나온만큼 뒤에 발생하는 유지보수 비용은 전혀 계산하지 않죠.
    반대로 탄탄한 기초를 다져서 유지보수 비용을 아껴도 초반에 뭔가 눈에 보이는 결과물이 없으면 일을 잘 안한 것 처럼 생각하죠.
    공부할때 소프트웨어는 유지보수 비용이 가장 크다고 배웠을텐데 실무에서 유지보수는 별개로 개발자가 알아서 책임지길 바라는 것 같습니다.

  15. 안녕하세요. A2님

    그렇습니다. 그런데 현실은 좀 답답하죠. ^^

  16. Blog Icon
    KALA555

    매번 좋은글 잘 읽고 있습니다. 근데 RSS리더에서는 본문 내용이 전부 안보이고 일부만 나와서
    전문을 보려면 블로그로 방문해서 봐야 하는데 원래 그런건가요? 아님 제가 무슨 설정을 해줘야 하는 건가요?

  17. 안녕하세요. KALA555님

    제 블로그 RSS 설정이 그렇게 되어 있어서 그렇습니다. 정상입니다.

SW개발자의 미래

2012.05.21 06:23 by 전규현


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






개발이 좋아서 SW개발자가 된 사람들이 한 5~7년 개발을 하다보면 흔히 미래에 대해서 생각하게 되고 불확실한 미래를 불안해하곤 한다.


특히 대부분의 회사에서 개발자의 Career를 보장해주지 않기 때문에 막연히 팀장이 되기도 하고 다른 직종으로 옮기기도 한다.


그러다보니 전문성있고 가치가 높은 개발자의 경험과 지식이 묻혀버리기 일쑤이고 회사는 기술력이 축적되지 못하게 된다.


개발자의 Career Path 상에는 어떠한 직종들이 있는지 알아보자. 자신의 역량과 성향에 따라서 Path를 정하면 좋을 것이다. 물론 회사에서 그리고 사회 전체적으로 개발자의 Career Path를 보장해 주는 방향으로 변하면 좋겠다.



Senior Engineer, Chief Scientist


한마디로 고참개발자이다. 신참때는 주로 코딩을 많이 하고 버그를 잡았으면 이제는 분석, 설계에 더 많은 시간을 소비하고 Peer Review에 많이 참석한다. 

자신의 팀의 프로젝트만 관심을 가지는 것이 아니고 다른 팀의 프로젝트 리뷰에도 참석하여 기여를 한다.

흔히 Architect라고 불리기도 하고 여전히 코딩도 한다. 

외국에서는 60세가 넘는 Software엔지니어를 볼 수 있기도 하다. 

제대로 된 엔지니어라면 Domain과 상관없이 어느 분야로든지 이직이 가능하다.

CTO


회사의 최고 기술 책임자이며 많은 개발자들의 Role model이다.

회사의 경영에 관여를 하지만 관리는 하지 않는다.

장기기술전략, 실행전략, 아키텍처, 구현, 인프라구조 정립, 프로세스 등 개발에 관하여 기술적인 것이라면 모두 책임진다.

왕년에 코딩을 했다는 것으로는 CTO가 될 수 없다. CTO라면 현재도 코딩을 할 수 있어야 한다. 바쁘고 코딩의 Value가 낮기 때문에 안하는 것 뿐이지 분석/설계/코딩을 현재도 모두 할 수 있어야 한다.

소프트웨어 회사의 최고봉이라고 할 수 있다.

SCM, Build and Release Engineer


소프트웨어 회사에는 몇가지 전문적인 분야가 있다. 형상관리, 빌드, 릴리즈, 팩키징 등이 그것이다. 처음에는 개발자들이 개발과 더불어 이런 업무도 같이 수행하지만 회사가 커지면 전문적인 업무로 떨어져 나온다. 몇명이 전담을 해도 될만큼 충분히 일이 많고 취미로 해도 될만큼 일이 쉬운 것이 안다. 또한 개발 능력도 필요하다.

대단히 전문적인 업무이고 이러한 개발외의 환경이 잘 되어 있어야 개발자들이 개발에 집중할 수 있고 업무 효율이 오르게 된다.

개발자 중에는 프로젝트보다 이러한 전문적이고 SW공학적인 업무에 관심을 가지는 사람들이 있다. 이 영역에서 실력을 닦으면 이직시에도 이 전문성을 활용할 수가 있다.


Technical Marketer


제품을 기획할때는 비즈니스적인 요소, 기술적인 요소가 모두 고려된다. 그중에서 기술적인 부분은 일반 기획자들이 속속들이 알기가 어렵다. 따라서 기술을 아주 잘아는 테크니컬 마케터가 기술적인 부분을 담당하게 된다. 경쟁사의 제품을 분석할 때도 단순히 기능이 되는지 O, X만 체크 하는 것이 아니고 기술적인 부분까지 검토를 해서 적용된 기술도 파악할 수 있다. 

새로 기획하는 제품의 기술적인 비전을 수립하고 마케팅과 개발자의 연결고리 역할도 수행한다.

Technical Supporter


개발자 중에는 진득히 않아서 개발하는 것을 좀 쑤셔하고 싫어하는 사람들이 있다. 여러 경쟁 제품을 써보기를 좋아하고 새로운 제품이 나오면 먼저 써보려고 하고 동료들의 시스템에 문제가 생기면 누구보다 빠르게 해결해 주는 능력을 가지고 있다.

이런 경우 개발 경력과 지식을 활용하여 기술지원업무를 수행할 수 있다. 회사의 제품에 대해서 기술적으로는 누구보다 속속들이 잘 알기 때문에 수준 높은 지원도 가능하다.

외향적인 사람들에게 어울리는 직종이다.

QA Engineer/Manager


개발자 출신으로 QA 엔지니어나 관리자가 될 수 있고 개발 능력을 활용하여 테스트 관련 툴을 개발할 수 있다. 

개발 경험이 있는 것은 장점으로 작용하면 계획적인 삶을 살 수 있는 장점도 있다. 물론 우리나라에서는 똑같이 무지막지한 야근을 해야 하는 경우가 많다.

Project Manager


기술자 트랙과 관리자 트랙의 중간쯤 되는 포지션이다. 프로젝트를 책임지고 맡아서 관리하는 역할로서 General Manager가 되는 중간 과정이 될 수도 있다. 


General Manager


기술과는 관련이 없는 일반 관리자다. 기술에서는 손을 떼는 것이다. 우리나라의 개발팀장과는 또 다르다. 개발팀장이 오래되서 더이상 개발을 하지 않고 관리를 하면 General Manager라고 볼 수 있다.

기술적인 결정은 하지 않는다. 하지만 과거에 개발 좀 해 봤다고 기술적인 결정을 자기가 해버리면 월권이라고 할 수 있다.

일단 일반 관리자로 넘어오면 다시 엔지니어로 돌아가는 것은 불가능 하다. VP Engineering으로 성장하는 Track이다.

VP Engineering


우리말로는 "기술부사장", "연구소장" 정도가 되겠다. CTO와는 완전히 다르다. CTO는 관리를 하지 않지만 VP Engineering은 관리자다. 개발관리 총책임자 쯤 된다. 개발자나 CTO가 하는 기술적인 얘기의 용어들을 거의 알고 있고 개발프로세스가 어떻게 돌아가는지도 잘 안다.

하지만 기술적인 결정을 하지는 않고 관리만 한다.

우리나라에서는 흔히 VP Engineering을 CTO라고 불러서 오해를 하는 경우가 많다.

Domain Expert


소프트웨어 개발 역량보다는 업무 지식에 치중하는 사람들이다. 증권사, 은행, 회계, 토목, 건설, 기계, 예술 분야의 소프트웨어를 개발하려면 해당 영역의 지식과 경험이 많이 필요하고 소프트웨어 기술도 어느 정도 알아야 한다. 개발 경험을 가지고 해당 산업 지식을 쌓으면 도메인 전문가가 될 수 있고, 이 경우 해당 분야로만 이직이 가능하다.

Restaurant Owner


소프트웨어 개발에 염증을 느끼거나 비전을 찾지 못하면 소프트웨어 업계를 완전히 떠나는 것도 한 방법이다. 



image by  j.o.h.n. walker



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

전규현 사람과 기술

  1. Blog Icon

    컨설턴트는 없나요~?

  2. Blog Icon
    mins

    Domain Expert가 컨설턴트로 보이네요..주로 컨설팅회사에서 ??선생이라고 불리는..

  3. 제가 지금은 컨설턴트니까 컨설턴트가 될 수도 있겠네요. ^^
    저는 Software Engineering 컨설턴트이지만, 컨설턴트는 그 분야가 매우 넓어서 한마디로 얘기할 수 없습니다.
    저같은 공학 컨설턴트는 정말 드물고요. ERP 컨설턴트, IT컨설턴트 또는 경영컨설턴트가 되기도 합니다.
    그리고 Domain 전문가로서 해당 영역의 컨설턴트가 되기도합니다. Domain 전문가는 Specialist라고 불리기도 합니다.
    각 분야마다 특징이 달라서 한마디로 말하기는 어렵네요. ^^

  4. Blog Icon
    sb

    아~그렇군요~~

  5. Blog Icon
    nejinn@naver.com

    대단합니다. 소개글로 cafe.naver.com/itscholar 로 가져가겠습니다~

  6. 마지막 restaurant owner 에서 빵 터졌습니다. 그리고 잠시 생각하게 되는군요. ^^
    매번 좋은 글 감사히 잘 읽고 있습니다!

  7. 좋은 글 감사합니다.. 위에 남긴 제 블로그로 담아가겠습니다..:) 출처 밝힐테니 걱정 하지 마세요..;)

  8. 좋은글 잘보고갑니다. ㅋㅋ 저도 마지막 restaurant owner 에서 빵 터졌습니다 ㅋㅋㅋ

  9. Arone님 안녕하세요.

    다들 식당 주인의 꿈이 있는 듯합니다. ^^

  10. 대한민국 현실과 안맞는군요
    경력 5~8년이상이면
    보통 을에선 특급으로 플젝에 넣어서 갑에서 1000~1500만원받아내죠
    병정무수리 쪽은 고급개발자명목으로 을회사가 갑회사서 700~1000만원을 받아내
    업체들에게 40%이상을때먹고 줘서 보통 개발자들은 400~600받으면 많이 받는 대한민국현실에선 안맞는 글같습니다.

  11. 네, 대한민국 현실과 안맞는 것이 내용입니다.
    개발자들 경력이 보장되지 않으니 경력을 보장해야 한다는 의미에서 캐리어패스를 알아본 글입니다. 대부분은 캐리어에 대한 고민없이 적당히 흘러가는대로 관리자가 되기도 하고 앵벌이가 되기도 하죠. ^^

  12. Restaurant Owner 가 맨마지막에 있는 걸 보니, 미국도 우리나라랑 비슷한 부분이 있나 보네요. 나머지는 우리시장이 좁으니까...

  13. 순서는 의미가 없습니다. ^^

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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