천객만래 [千客萬來] (It has an interminable succession of visitors)

당신의 조직은 개발자를 올바르게 관리하고 있는가?

류한석(IT 컬럼니스트)   2007/10/09

 

한국의 많은 소프트웨어 업체들이 개발자를 제대로 관리하지 못하고(또는 안하고) 있다. 소프트웨어 개발은 정신에 의한 작업이다. 누가 하는 가에 따라서, 어떤 동기부여를 하는 가에 따라서, 어떤 환경에서 하는 가에 따라서, 어떻게 관리하는 가에 따라서 엄청나게 다른 결과를 만들어낸다.

하지만 관리라는 이름 하에 개발자에게 모욕적인 대우를 하는 경우도 많다. 작업에 지장이 있을 정도의 저사양 개발장비를 제공하고, 좁아터진 공간에, 계속 울리는 전화벨과 시끄러운 대화 소리, 휴식공간이라고는 전혀 없는 조직도 많다. 직원들의 일거수일투족을 감시하고, 심지어는 복장 검사를 하는 경우도 있다.

또한 프로젝트 데드라인을 맞추기 위해 새벽에야 겨우 집에 들어갔음에도 불구하고, 출근시간에 몇 분 늦었다고 해서 지각을 체크하고 전체 직원이 모인 회의에서 실명을 거론하는 회사도 있다. 그런 회사일수록 야근수당이 없고 교통비도 지급하지 않으며 사소한 비용을 아낀다. 한마디로 작은 비용을 절약함으로써, 신뢰 상실이라는 큰 비용을 지불하는 것이다.

그런 회사에서 만들어지는 소프트웨어는 품질이 나쁘다. 불행한 개발자들은 품질이 나쁜 소프트웨어를 만들어 낸다. 어쩌면 잠을 못 자고 피로에 지친 개발자들이 내쉬는 서글픈 한숨이 소프트웨어의 영혼에 스며들어 가는 것은 아닐까? 저주받은 소프트웨어. 마치 호러영화의 한 장면처럼 느껴진다.

회사는 직원들을 사랑하지 않으면서, 직원들에게 애사심을 강요하는 회사를 보고 있자면 실소가 나온다. 물론 회사로서는 직원들에게 사랑을 보여줄 수 없는 가장 큰 이유가, 열악한 비즈니스 환경으로 인한 비용적 압박 때문이라고 얘기할 것이다. 백분 양보하여 그것을 인정한다고 할 지라도, 그렇다면 도대체 왜 부적절한 관리자에게 관리를 맡기고 있는 것일까?

나쁜 관리자가 프로젝트를 망치고 있다!
업계를 보면 관리자의 자격이 전혀 없는 사람이 관리를 맡고 있는 경우가 무척 많다. 나쁜 관리의 비용은 엄청나다. 단지 팀 구성원들의 작업에 지장을 주는 정도가 아니라, 조직의 목표 달성에 해악을 미치며 결국 상당한 대가를 치르게 만들고 프로젝트를 완전히 망치는 경우가 빈번하다.

필자는 단지 관리자를 잘못 배정했기 때문에 수백억 원의 손해를 본 어느 대기업의 프로젝트를 경험한 적이 있다. 팀원들은 모두 유능했고 각자의 마음 속에 일을 잘하고자 하는 열정이 있었지만, 관리자의 무능과 변덕과 학대로 인해 팀원들은 모두 좀비가 되어갔다. 일부는 떠났고 일부는 일을 하지 않았고 일부는 하는 척을 했다. 결국 수년간 프로젝트를 진행했으나 결과는 나오지 않았고 프로젝트는 취소됐다. 몇 가지 추가적인 원인이 없었던 것은 아니지만, 가장 주요한 요인은 ‘나쁜 관리자의 존재’ 그 자체였다.

나쁜 관리자는 팀원들이 무엇을 하고 있는지 알지 못하며(또는 관심이 없으며), 팀원들의 능력을 제대로 파악하지 못한 채로, 원칙 없이 업무를 지시하며, 부적절한 인력을 배치하고, 팀원들과 제대로 대화를 나누지 않으며, 펫프로젝트(pet project, 고위층 또는 자신의 개인적인 관심으로 만들어낸 프로젝트)로 인해 업무 우선순위를 마구 바꾸고, 결과가 나와도 잘했는지 못했는지 제대로 판단하지 못한 채 자신의 기호에 따라 결과를 재단한다. 한마디로 그들은 조직의 목표와 팀원의 성장에는 아무런 관심이 없으며 단지 자신의 안위만 생각하는 사람들이다.

그러한 나쁜 관리자의 존재가 지극히 예외적인 경우라고 생각하는가? 만일 그렇다면 당신은 조직 생활의 경험이 많지 않든가, 아니면 억세게 운이 좋은 경우일 것이다. 그런 나쁜 관리자로 인하여 젊은 시절의 소중한 경험을 빼앗기는 팀원들이 몹시 많다. 나쁜 관리자의 해악은 단지 프로젝트의 실패로 나타나는 것뿐만 아니라, 사람들의 인생에서 그 시기에 필히 겪어야 할 소중한 경험까지 앗아가 버리는 것에 있다. 좋은 관리를 받아보지 못한 사람은 좋은 관리를 할 수가 없다.

좋은 관리자가 되기 위한 지침
그렇다면 좋은 관리란 어떻게 관리하는 것인가? 하단과 같이 몇 가지 지침을 제시할 수 있을 것이다.

첫째, 바라는 결과를 명확히 알려주어야 한다. 어떤 관리자들은 자신이 무엇을 원하는지 자기 스스로도 정확히 모르는 채 작업을 지시하고, 팀원의 작업 결과를 그날그날의 기분에 따라 자신의 기호대로 판단하곤 한다. 그런 관리자는 관리자로서의 자격이 없다.

둘째, 위임을 적절하게 수행해야 한다. 어떤 사람의 그릇은 위임할 수 있는 양의 크기로 정해진다. 즉 어떤 사람이 이루어낼 수 있는 최대 성과치는 그가 팀원들에게 권한을 위임할 수 있는 능력에 의해서 결정된다는 뜻이다. 할 일이 너무나 많지만 일할 시간이 없고 혼자서 모든 일을 처리하려고 하는 관리자는 탈진증후군(burnout syndrome)에 빠지게 된다. 그리고 탈진증후군에 빠진 관리자는 결국 팀을 궤멸시킨다.

셋째, 방법보다는 결과에 초점을 맞추어야 한다. 이 말에 오해가 없기를 바란다. 오로지 결과만 중요시하라는 뜻이 아니라, 결과가 올바르다면 방법은 팀원에게 맡겨두라는 뜻이다. 개발자 출신의 관리자는 자신이 선호하지 않은 방법으로 구현을 했다는 이유로 팀원을 질책하거나 업무를 회수하는 잘못을 저지르는 경우가 많다. 그런 관리자는 좋은 결과도 팀원들의 신뢰도 얻지 못할 것이다. 결과가 옳다면 그 방법은 팀원에게 맡겨두는 포용력을 가져야 한다.

넷째, 피드백을 주고, 코칭을 하고, 경력 개발을 지원해야 한다. 피드백이란 해당 직원의 업무 결과에 대해 어떻게 생각하는지 그 내용을 전달하는 것이다. 코칭은 일종의 도움을 주는 것으로서 선택 가능한 사항들 속에서 실행 계획을 만들도록 도와주는 것이다. 그리고 팀원이 새로운 지식과 경험을 쌓음으로써 성장할 수 있도록 경력 개발을 지원해야 한다. 팀원의 경력 개발에 전혀 신경을 쓰지 않은 관리자들이 너무 많다. 그것은 팀원을 일회용품으로 취급하고 있음을 스스로 증명하는 것과 같다. 경력 개발에 도움을 받은 팀원은 관심을 갖고 도와준 관리자를 언제까지나 기억할 것이다.

다섯째, 좋은 관리자는 자기 자신을 관리하는 사람이다. 좋은 관리자는 감정의 폭발에 반응하기보다는 사건에 대응한다. 불필요한 감정을 발산하여 팀원에게 공포심을 조장해서는 안 된다. 만일 감정이 폭발했거나 또는 잘못된 지시를 했다고 판단될 시에는 즉각 솔직하게 인정하고 사과를 해야 한다. 실수를 인정하는 관리자는 인간적으로 보인다.

좋은 관리 방법을 배우기는 힘들다. 왜냐하면 그것은 눈에 잘 보이지 않기 때문이다. 하지만 우리는 그것을 배우고 실천해야 한다. 그것이야말로 업계에 만연된 악순환의 고리를 끊어버리는 유일한 방법이기 때문이다. 우리가 겪은 불행한 경험을 다시금 후배들에게 전달해서는 안 된다.

비록 기술 중심의 소프트웨어 업체라고 할 지라도, 기술 관리란 기술이 아니라 사람을 다루는 것임을 잊지 말아야 한다. 회사가 가능한 범위 내에서 최상의 업무 환경을 제공하고, 개발자 개개인을 세심히 배려하는 피드백, 코칭, 경력 개발을 지원하는 관리자가 있는 조직이라면 개발자는 결코 불행하지 않을 것이며 더 나아가 어려운 일도 기꺼이 극복해 낼 것이다.

하지만 지금 이 순간에도 많은 기업들이 사소한 비용 절감과 무의미한 규칙 준수를 위해 직원들의 신뢰를 잃고 있으며, 나쁜 관리자를 배정함으로써 프로젝트와 팀원의 인생을 망치고 있다. 나쁜 관리자는 개인, 회사, 사회 모두에 악영향을 미치는 존재이다.

반면에 좋은 관리자는 탁월한 결과를 만들어내고 팀원들을 성장시키고 사회 전반에 좋은 인재를 공급한다. 그런 훌륭한 관리자가 어디 흔하냐고 항변하는 기업의 목소리가 들린다. 하지만 기업들이여, 그런 변명보다는 좋은 관리자를 채용하려는 노력, 그리고 양성하려는 노력, 그리고 그가 ‘진짜 관리’를 제대로 수행하였는지 평가하려는 노력을 무엇보다 먼저 기울여야 하지 않을까? @

 

출처: http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39162121,00.htm

Posted by SB패밀리

순진한 개발자가 사내정치에서 살아남는 법




류한석 (IT 컬럼니스트) ( ZDNet Korea )   2008/03/17

 

개발자 K씨를 재회한 것은 8년만의 일이다. 그는 나와 함께 일했던 직장에서 이직한 이후에 4번이나 더 이직을 했는데, 현재는 실직 상태에서 직장을 구하고 있었다. 

 

솔루션을 개발하는 회사에서는 비전이 없어 그만 두었고, 대기업 계열 SI업체를 들어갔으나 개발이 아닌 관리를 시켜서 그만두었고, 포털에 들어갔는데 할 일이 별로 없고 회사 상황이 정치적이어서 그만두었다고 했다. 그리고 마지막 회사는 소위 벤처기업이었는데, 6개월이나 임금을 받지 못한 상태에서 사장이 사실상 야반도주를 해서 회사가 망했다고 했다. 

K씨는 자바를 정말 잘 다루던 개발자였는데, 일반적인 기준에서 볼 때 성격이 좋다고 얘기하기는 힘든 사람이었지만 그 정도면 무난하다고 할 수 있었다. 다만 여느 개발자와 마찬가지로, 타인의 욕구에 관심을 가지거나 커뮤니케이션 스킬이 뛰어난 사람은 아니었다. 다음은 그가 한 얘기이다.

“회사 경영은 나하고 상관이 없다고 생각했어요. 제가 경영이나 관리 같은 것은 잘 모르고요. 회사에서 벌어지는 정치 게임은 질색이에요. 저는 그저 개발만 하고 싶었어요. 그런데 개발에 집중할 수 있는 조직이 참 없더라고요. 이제 저는 어떻게 해야 할까요?”

필자는 그날 K씨와 새벽까지 술을 마실 수 밖에 없었다. 개발자가 개발자답게 일하고 성장할 수 없는 것이 바로 한국의 현실이다. 성장을 하는 것이 아니라 사라져 가고 있다.

개발자는 어떤 사람인가? 문제를 발견하고 문제를 해결하고, 스펙에 따라(또는 창조적으로) 무언가를 만들어 내고, 오랜 시간 동안 한 자리에 앉아서 화면만을 째려보며 몰입할 수 있기에 개발자다. 그것이 그들의 특징이며 그렇기 때문에 개발을 할 수 있는 것이다. 

개발자에 대해 IT업계의 다른 직종들은 어떻게 생각하고 있을까? 단편적이지만 그들의 생각을 살펴보자. 어떤 영업맨은 “저한테 저렇게 열 시간 동안 앉아 있으라고 하면 절대 그러지 못할 거 같네요. 어떻게 저럴 수 있나요?”라고 필자에게 반문하기도 했다.

어떤 마케터는 “그들은 쿠폰에 항상 도장을 찍더군요. 작은 것에 민감한 거 같아요. 시야가 좁고 자신들의 분야 외에는 거의 관심이 없는 거 같더군요. 게임이나 애니, 미드 같은 것을 좋아하고. 업계나 시장 돌아가는 상황에 대해서는 관심도 없고...”라고 얘기했다. 실제로 마케터들은 개발자와 함께 일하는 경우가 별로 없어서 그들을 잘 모른다. 원거리에서 그들을 바라볼 뿐이다.

반면에 개발자와 함께 협업하는 경우가 많은 요구분석가, 웹기획자들 중 상당수는 다음과 같은 얘기를 했다. “그들은 커뮤니케이션 스킬이 없어요. 중요한 대화에는 제대로 응하지 않다가 자신들과 상관이 있는 이슈가 나오면 발끈해요. 무조건 안 된다고만 하죠. 도무지 협상이라고는 할 줄 모르는 사람들이에요.”

혼자서 일하는 1인 개발자가 아닌 이상, 대부분의 개발자는 조직에서 협업을 해야 한다. 프로젝트 매니저와 대화해야 하고, 기획자/디자이너/동료 개발자와 협업을 해야 한다. 프로젝트에 따라서는 고객과 직접적인 커뮤니케이션을 해야 하는 경우도 있다. 그리고 사내정치를 피해갈 수 있는 개발자는 거의 없다. 직간접적으로 영향을 받을 수 밖에 없다.

그런데 한국에서 사내정치는 중소기업에서 대기업, 인터넷기업까지 만연되어 있다. 많은 개발자들이 정치를 싫어한다. 정확히 표현하면 정치가 미치는 부정적인 영향을 싫어한다고 할 수 있을 것이다. 하지만 조직이라는 것은 그 안에 있는 수많은 조직구성원들이 지위 고하에 따라 자신의 목표와 이익을 추구하는 곳이다. 그리고 그들간의 이해관계는 상충될 수 밖에 없다. 그래서 누군가는 희생자가 된다. 안타깝게도 그 대상은 대부분 개발자이다.

개발자는 현실적인 일정 하에서 보다 나은 기술을 이용하여 높은 품질의 소프트웨어를 만들고 싶어하지만, 어떤 사람들은 기술 자체나 품질은 전혀 상관없이 일자 또는 비용만이 그들의 관심사이다. 그렇다면 그것은 잘못된 것인가? 그럴 수도 있고 아닐 수도 있다. 상황에 따라 답이 다르다. 현실은 단순한 흑백논리로 설명되지는 않는다.



패배하지 않기 위해 이것만은 기억하자

사내정치에서 살아남기 위해서 개발자가 알고 있으면 유용할 세 가지 지침을 제시한다. 다음의 세가지 지침은 서로 연동된다.


1. 나의 목표와 주변의 이해관계를 파악하고 있어야 한다. 


자신이 원하는 것이 돈인지 명예인지 지위인지, 아니면 개발을 통한 자아실현인지, 개인생활의 추구인지 명확히 알고 있어야 한다. 또한 나의 목표를 실현하는데 있어 가장 큰 장애물이 무엇인지 알고서 그것을 관리해야 한다. 자신의 목표와 상충되는 목표를 가진 이해관계자의 욕구를 파악하고 그것과의 타협점을 찾아야 한다. 

하지만 사실, 대부분의 경우 목표를 실현하는데 있어서 가장 큰 장애물은 자기자신의 성격이다. 그렇지만 성격을 수양하는 개발자가 과연 몇 %나 될까? 아는 것과 실천은 완전히 별개의 단계이다.

2. “너와 나의 진실은 다르다”는 사실을 이해하고 있어야 한다. 


자신이 믿는 것만이 정의이고 진실이라는 생각이 들 때, 숨을 세 번 크게 내쉬면서 상대편의 입장에서도 과연 그럴까 다시 한번 생각해 보기 바란다. 내가 알거나 느끼는 것을 쉽게 드러내서는 곤란하다. 대부분의 경우 그것은 설익은 판단이고 타이밍이 적절치 않은 경우가 많다. 하지만 자신의 감정을 주체하지 못하고 ‘욱’한 나머지, 준비도 안된 상태에서 회사를 그만 두어 버리고 경력을 망치는 개발자들이 많다. 퇴사 후 놀고 있는 당신을 사내정치인들은 비웃고 있다.


3. “군자에게는 실수를 해도 소인배에게는 실수를 하지 말라”는 격언을 기억하기 바란다. 


이 말은 필자가 회사 생활에서 곤란을 겪는 후배들에게 숱하게 해주었던 말이다. 이 말을 처음 들었을 때의 임팩트는 상당히 크다. 군자(君子)는 점잖고 덕이 있는 사람이다. 그래서 군자는 누가 실수를 해도 그 이유를 스스로 파악하여 너그럽게 이해해준다. 하지만 소인배는 조금만 불이익을 당하거나 무시를 당했다고 느끼면 바로 삐지며, 심할 경우 끝까지 따라다니며 괴롭힌다.

그런데 사람이란 군자에게는 존경심을 갖고서 공손히 대하고 소인배는 무시한 나머지 함부로 대한다. 그것이 인지상정이다. 하지만 만일 그 소인배가 당신의 직장상사라면?

사내정치는 어느 나라에나 존재한다. 한국뿐만 아니라 미국에도 일본에도 있다. 하지만 한국에서 더욱 사내정치가 심할 수 밖에 없는 이유가 있다. 한국은 아직까지 IT업계뿐만 아니라 사회의 여러 분야에서 전문가의 개념이 불분명한 나라이다. 제대로 된 전문가가 출현하고 그 가치를 인정받는 지식사회가 되기까지 앞으로도 꽤 많은 시간이 걸릴 것이다. 

한국은 아직은 선진 지식사회가 아니다. 그러므로 고급지식을 가진 사람들이 별로 없을 뿐만 아니라, 설사 있다고 하더라도 그것을 인정하지 못하며, 설사 인정한다고 할 지라도 필요로 하지 않는다. 실력을 인정하는 기준이 없으니, 사내정치가 판을 친다.


전문가를 필요로 하지 않는 사회, 자기계발이 살길 


궤변으로 들릴 지 모르지만, 우리 업계에 전문가가 없는 것은 전문가를 필요로 하지 않기 때문이다. 조직 내에 사내정치인이 승진하고 인정받는 것은 조직의 상층부가 몰라서 그런 것이 아니라 그런 사람을 선호하기 때문이다. 

성장은 커녕 생존을 이야기해야 하는 현실이 안타깝지만, 일단 생존해야 자기계발을 하고 경력관리를 하면서 기회를 노릴 것이 아닌가? 사내정치를 잘 할 필요는 없지만(그리고 개발자의 특성상 잘 하지도 못 할 것이다), 희생자가 되어서는 곤란하다. 이것이 바로 필자가 개발자 K씨에게 한 말이다.

개발자는 자신의 개발력과 장점을 해치지 않는 선에서, 이해관계자를 파악하고 그들의 욕구를 다루는 능력을 갖추어야 한다. 자신의 목표를 분명히 해야 하며, 감정에 치우쳐서 일을 그르치지 말아야 한다. 그러지 못한다면 결국 희생자가 될 뿐이다.

그러한 희생을 몇 번 당하다 보면, 개발업에 대한 애정이 식어버려 자기계발을 등한시하게 될 뿐만 아니라 성격까지 나빠져서 더욱 더 안 좋은 상태에 처하게 된다. 그렇게 사라져간 개발자들이 참 많다.

이런 조언을 하는 것에 대해 한편으로는 미안하게 생각한다. 언젠가 개발력만으로도 인정받을 수 있는 사회가 오면(너무 낭만적인 표현이다), 사내정치 대신 좀 더 아름다운 세상에 대해 이야기하겠지만 지금은 아니다. 정신을 똑바로 차리고 이 난세에서 생존하기 바란다. 환경을 바꿀 수 없으면 자신을 바꾸어야 하며, 자신을 진화시킨 개발자에게는 반드시 기회가 올 것이다. 세상은 장기적으로 볼 때 스스로 혁신하는 사람의 편이니까 말이다. @

 

출처 : http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39166851,00.htm

Posted by SB패밀리

[경영/리더십] 보스와 리더의 차이


※ 관리자의 유형에서 당신은 어느 위치에 있고 어느 유형을 지향하는지 살펴보세요




보스와 리더의 차이

 

모든 리더(Leader)는 보스(Boss)이다. 그러나 모든 보스는 리더가 아니다. 보스와 리더는 엄연한 차이가 있다. 보스와 리더의 가장 큰 차이가 있다. 보스는 상사이기 때문에 존경받고 복종받는다. 리더는 상사일 뿐만 아니라 인격과 능력에 품격 때문에 그 본보기로 로 존경받고 우러러 보게 된다. 이런 점에서 배경화면으로 보기도 한다.

리더가 되기위한 강한 열정을 가진 사람은 모범으로써 이끌어야 한다. 팀은 리더가 모든 위기에 노출되어 있다는 확실한 믿음을 가져야 한다. 리더는 비난을 하지 않고 문제를 바로 잡는다. 리더의 설득을 팀원들이 따르지 않는 것을 발견한다면 팀원은 더이상 리더를 존경하지 않는다. 팀원은 리더를 복종할지 모르지만 더 이상 존경은 없다. 리더는 행동으로써 이러한 존경을 얻는다. 그들은 진지하게 보고 행동한다. 말과 행동에 균형을 잃지 않는다. 접근과 인격에서 완전한 모습이다.

리더가 되기 위해서 모든 보스는 지식, 계획, 예측, 신중, 행동, 결과지향적 접근법, 균형과 같은 특성을 보여주고, 모든 팀원들을 존경, 존경을 얻고, 친구로서 멘토로서 행동해야한다. 이것는 리스트이지만 당신이 좋은 리더가 되기를 원한다면 이러한 자질을 지녀야 한다. 이는 국민의 리더뿐 아니라  조직의 리더로 있는 사람에게는 현실인 것이다. 팀원으로부터 존경을 얻고자 하는 사람이라면 단지 보스가 되기를 그만두고 리더가 되려고 변해야 한다.

==============================================================================

The Difference Between Boss and Leader

Every leader is a boss. But every boss is not the leader. This defines the difference between a boss and a leader. The biggest difference between a boss and a leader is one. The boss is respected and obeyed because of his/her seniority. A leader is respected and looked up to as a example not only because of seniority but mainly because of the qualities of character and ability. Please view these wallpapers in this reference.

Those who aspire to become leaders must lead by example. The team must always have a firm belief that the leader will be there during every crisis. Not to fix the blame, but fix the problem. If the team members find that the leader does not follow what he/she preaches, they will have no respect for him/her. They may obey him/her, but the respect will be missing. Leaders gain this respect by their actions. They look and act sincerely. There is no mismatch between their words and actions. They look integral in approach and character.

To be a leader, every boss must display characteristics such as knowledge, planning, anticipation, foresight, action, result oriented approach, perspective, respect every team member, earn their respect, act as a friend and act as a mentor. This is quite a list, but if you want to become a good leader you need these qualities. This is true not only for national leaders but for persons in every leadership position in any organization. Once a person earns the respect of his /her team members he/she ceases to be only a boss and transforms into a leader.

 

Read more: http://www.articlesbase.com/leadership-articles/the-difference-between-boss-and-leader-500785.html#ixzz1KQlnBkeh



Posted by SB패밀리


아래의 글은 개발자가 되어 5년정도 개발하고 있게 되면... 자주 고뇌하게 되는 내용인 듯 싶다.

개발자의 미래는 무엇일까?

개발자로서 남을 수 있을까?

개발자는 관리자로 전향해야하나?

한 번 개발자는 영원한 개발자인가?

개발자는 치킨집을 목표로 삼아야 하나?


대부분의 칼럼에서 보면 우리나라에서는 개발자로 남는다는 것이 무척이나 어렵다고들 한다.

실제로... 10년차가 넘어서면 회사에서는 개발관련 업무 보다 개발 관리 업무를 원하기 시작하고

인력을 관리해주기를 바란다.

그러면서 많은 개발자들이 고민을 하게 되는데....







출처: http://techit.co.kr/7496


개발자의 미래, 당신의 선택은 무엇입니까?


Software개발이 좋아서 개발자가 된 사람들도 한 5~7년 개발을 하다 보면 미래에 대해 걱정을 하게 되고 불확실한 미래를 불안해하게 된다. 대부분의 회사에서 개발자의 Career Path를 보장해주지 않기 때문에 막연히 팀장이 되고 관리자가 되고, 또는 다른 직종으로 옮기기도 한다.

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

물론 한번 Software 개발자였다고 해서 평생 개발만 해야 하는 것은 아니다. 개발자가 선택할 수 있는 직종은 상당히 많다.
개발자가 Career Path 상에서 어떠한 직종을 선택할 수 있는지 알아보자. 자신의 역량과 성향에 따라서 Path를 정하면 좋을 것이다. 물론 회사에서 그리고 사회 전체적으로 개발자의 Career Path를 보장해 주는 방향으로 변하는 것이 우선이다.

Senior Engineer, Chief Scientist
한마디로 고참개발자이다. 개발을 계속하고 싶은 사람들이 선택하는 Path이다.
신참 때는 주로 코딩을 많이 하고 버그를 잡았으면 이제는 분석, 설계에 더 많은 시간을 소비하고 Peer Review에 많이 참석한다.
자신의 팀의 프로젝트만 관심을 가지는 것이 아니고 다른 팀의 프로젝트 리뷰에도 참석하여 기여를 한다.
흔히 Architect라고 불리기도 하고 여전히 코딩도 한다.
외국에서는 60세가 넘는 Software엔지니어를 볼 수 있기도 하다.
제대로 된 엔지니어라면 Domain과 상관없이 어느 분야로든지 이직이 가능하다.

CTO
회사의 최고 기술 책임자이며 많은 개발자들의 Role model이다.
회사의 경영에 관여를 하지만 관리는 하지 않는다.
장기기술전략, 실행전략, 아키텍처, 구현, 인프라구조 정립, 프로세스 등 개발에 관하여 기술적인 것이라면 모두 책임진다.
왕년에 코딩을 했다는 것으로는 CTO가 될 수 없다. CTO라면 현재도 코딩을 할 수 있어야 한다. 바쁘고 코딩의 Value가 낮기 때문에 안하는 것뿐이지 분석/설계/코딩을 현재도 모두 할 수 있어야 한다.
소프트웨어 회사의 최고봉이라고 할 수 있다.

SCM, Build and Release Engineer
소프트웨어 회사에는 몇가지 전문적인 분야가 있다. 형상관리, 빌드, 릴리즈, 팩키징 등이 그것이다. 처음에는 개발자들이 개발과 더불어 이런 업무도 같이 수행하지만 회사가 커지면 전문적인 업무로 떨어져 나온다. 몇 명이 전담을 해도 될 만큼 일의 양도 많고 취미로 해도 될 만큼 쉬운 일도 아니다. 또한 개발 능력도 상당히 필요해서 개발자 출신이 아니면 하기 어렵다. 대단히 전문적인 업무이고 이러한 개발 외의 환경이 잘 되어 있어야 개발자들이 개발에 집중할 수 있고 업무 효율이 오르게 된다.
개발자 중에는 프로젝트보다 이러한 전문적이고 SW공학적인 업무에 관심을 가지는 사람들이 있다. 이 영역에서 실력을 닦으면 이직 시에도 이 전문성을 활용할 수가 있다.

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

Technical Supporter
개발자 중에는 진득하게 않아서 개발하는 것을 좀쑤셔 하는 사람들이 있다. 여러 경쟁 제품을 써보기를 좋아하고 새로운 제품이 나오면 먼저 써보려고 하고 동료들의 시스템에 문제가 생기면 누구보다 빠르게 해결해 주는 능력을 가지고 있다.
이런 경우 개발 경력과 지식을 활용하여 기술지원업무를 수행할 수 있다. 회사의 제품에 대해서 기술적으로는 누구보다 속속들이 잘 알기 때문에 수준 높은 지원도 가능하다.
외향적인 사람들에게 어울리는 직종이다. 이직 시 비슷한 분야로 이직이 가능하며 선택의 폭도 상당히 넓다.

QA Engineer/Manager
개발자 출신으로 QA 엔지니어나 관리자가 될 수 있고 개발 능력을 활용하여 테스트 관련 툴을 개발할 수 있다. 개발 경험이 있는 것은 장점으로 작용하면 계획적인 삶을 살 수 있는 장점도 있다. 물론 우리나라에서는 똑같이 무지막지한 야근을 해야 하는 경우가 많다. Domain에 상관없이 이직이 가능하다.

Project Manager
기술자 트랙과 관리자 트랙의 중간쯤 되는 포지션이다. 프로젝트를 책임지고 맡아서 관리하는 역할로서 General Manager가 되는 중간 과정이 될 수도 있다. 개발자 출신으로 Project Manager가 되면 개발의 이해도가 높아서 문제 해결 능력이 뛰어나고 관리에 도움이 많이 된다. 프로젝트 관리 전문가 과정이 도움이 된다. 이직 시 선택의 폭이 매우 넓다.

General Manager
기술과는 관련이 없는 일반 관리자다. 기술에서는 손을 떼는 것이다. 우리나라의 개발팀장과는 다르다. 개발팀장이 된지 오래되어서 더 이상 개발을 하지 않고 관리만 하고 있다면 General Manager라고 볼 수 있다. 기술적인 결정은 하지 않는다. 하지만 과거에 개발 좀 해 봤다고 기술적인 결정을 자기가 해버리면 월권이라고 할 수 있다.
일단 일반 관리자로 넘어오면 다시 엔지니어로 돌아가는 것은 불가능 하다. VP Engineering으로 성장하는 트랙이다.

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

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

Restaurant Owner
소프트웨어 개발에 염증을 느끼거나 비전을 찾지 못하면 소프트웨어 업계를 완전히 떠나는 것도 한 방법이다. 흔히 통닭집 주인이라고 한다.

Posted by SB패밀리

※ 관리자의 유형에서 당신은 어느 위치에 있고 어느 유형을 지향하는지 살펴보세요

- 쌈꼬쪼려 소백촌닭 -

 

보스와 리더의 차이

 

모든 리더(Leader)는 보스(Boss)이다. 그러나 모든 보스는 리더가 아니다. 보스와 리더는 엄연한 차이가 있다. 보스와 리더의 가장 큰 차이가 있다. 보스는 상사이기 때문에 존경받고 복종받는다. 리더는 상사일 뿐만 아니라 인격과 능력에 품격 때문에 그 본보기로 로 존경받고 우러러 보게 된다. 이런 점에서 배경화면으로 보기도 한다.

리더가 되기위한 강한 열정을 가진 사람은 모범으로써 이끌어야 한다. 팀은 리더가 모든 위기에 노출되어 있다는 확실한 믿음을 가져야 한다. 리더는 비난을 하지 않고 문제를 바로 잡는다. 리더의 설득을 팀원들이 따르지 않는 것을 발견한다면 팀원은 더이상 리더를 존경하지 않는다. 팀원은 리더를 복종할지 모르지만 더 이상 존경은 없다. 리더는 행동으로써 이러한 존경을 얻는다. 그들은 진지하게 보고 행동한다. 말과 행동에 균형을 잃지 않는다. 접근과 인격에서 완전한 모습이다.

리더가 되기 위해서 모든 보스는 지식, 계획, 예측, 신중, 행동, 결과지향적 접근법, 균형과 같은 특성을 보여주고, 모든 팀원들을 존경, 존경을 얻고, 친구로서 멘토로서 행동해야한다. 이것는 리스트이지만 당신이 좋은 리더가 되기를 원한다면 이러한 자질을 지녀야 한다. 이는 국민의 리더뿐 아니라  조직의 리더로 있는 사람에게는 현실인 것이다. 팀원으로부터 존경을 얻고자 하는 사람이라면 단지 보스가 되기를 그만두고 리더가 되려고 변해야 한다.

==============================================================================

The Difference Between Boss and Leader

Every leader is a boss. But every boss is not the leader. This defines the difference between a boss and a leader. The biggest difference between a boss and a leader is one. The boss is respected and obeyed because of his/her seniority. A leader is respected and looked up to as a example not only because of seniority but mainly because of the qualities of character and ability. Please view these wallpapers in this reference.

Those who aspire to become leaders must lead by example. The team must always have a firm belief that the leader will be there during every crisis. Not to fix the blame, but fix the problem. If the team members find that the leader does not follow what he/she preaches, they will have no respect for him/her. They may obey him/her, but the respect will be missing. Leaders gain this respect by their actions. They look and act sincerely. There is no mismatch between their words and actions. They look integral in approach and character.

To be a leader, every boss must display characteristics such as knowledge, planning, anticipation, foresight, action, result oriented approach, perspective, respect every team member, earn their respect, act as a friend and act as a mentor. This is quite a list, but if you want to become a good leader you need these qualities. This is true not only for national leaders but for persons in every leadership position in any organization. Once a person earns the respect of his /her team members he/she ceases to be only a boss and transforms into a leader.

 

Read more: http://www.articlesbase.com/leadership-articles/the-difference-between-boss-and-leader-500785.html#ixzz1KQlnBkeh

Posted by SB패밀리

프로그래머를 위한 잠언(aphorism)
 
 
다음은 세상의 지혜, 발라사르 그라시안 지음, 이동진 옮김을 참고하여 프로그래머에 맞추어 재구성한 것입니다. 필자가 추가한 것도 있고 패러프래이즈 한 것도 있습니다. 세상의 지혜 책에는 300가지의 지혜가 있고 해설도 잘 되어 있으므로 프로그래머 여러분들께서 구입해서 한 번쯤 꼭 읽어보시기 바랍니다. 책 가격을 하는 좀처럼 드문 책임에 틀림없다고 생각합니다. 존칭은 편의상 생략합니다. 너그러운 양해를 구합니다.

1. 컴퓨터 프로그래머는 최고의 직업임을 알라.
2. 컴퓨터 프로그래머는 노가다 직업임을 인정하라.
3. 프로그래밍의 성공 열쇠는 자신감이다.
4. 산은 넘어봐야 안다.
5. 산을 넘지 않고 넘어봐야 안다는 말하는 사람들을 가까이 하지 마라.
6. 언제나 진실되게 행동하라.
7. 프로그래밍은 진실의 반영이다.
8. 프로그래밍은 고도의 논리적 사유를 요구한다.
9. 개발툴은 기술적이기보다는 기능적이다.
10. 완전한 프로그램을 만드는 것만큼 자신을 완전하게 만들어라.
11. 컴퓨터를 이해하고 프로그램 구조를 이해하는 것만큼 자신을 알고 이해하라.
12. 팀웍을 위해서 일하라.
13. 팀웍의 활성화를 위해서는 스터디 모임이 효과적이다.
14. 팀 내에서 나서는 사람이 되기보다는 없어서는 안될 사람이 되어라.
15. 프로그래밍 지식이 실체화되려면 용기가 있어야 한다.
16. 소프트웨어 기술과 소질을 잘 살려서 최대한 도로 자신의 능력을 완숙한 경지로 향상시켜라.
17. 팀원들이 당신을 존중하고 신뢰하도록 만들라.
18. 팀장에게 반항하거나 그를 능가하려고 하지 말라.
19. 팀 내에서의 불만을 자기 것으로만 생각하지도 말고 퍼뜨리지 말라.
20. 프로그램 개발 시 발생하는 고통은 누구에게나 있는 것이다.
21. 가능한 한 자신의 결점을 노출시키지 말라.
22. 항상 배우도록 하고 자신에게 멘토가 되어줄 사람을 찾아라.
23. 동료 팀원들을 스승으로 삼아라.
24. 재능은 누구에게나 주어지지만 그 재능이 숙련적인 기술로 발전하기 위해서는 노력이 필요하다.
25. 프로그램 완성을 위해서는 WHY 보다는 HOW가 더 중요하다.
26. 버그를 한 번에 잡으려고 하지마라. 긴장을 갖고 있으되 한편으로는 여유로움을 간직하라.
27. 프로그래밍이란 지성과 감성 그리고 용기와 박력의 결합이다.
28. 자신의 주변에 우수한 인재들이 모이도록 자신을 향상시켜라.
29. 프로그램 개발은 풍부한 기술지식과 풍요로운 마음가짐을 요구한다.
30. 팀 내에서 그리고 회사 내에서 그리고 어디에서든 적을 만들지 말라.
31. 적을 만들지 않기 위해서는 항상 자신을 새롭게 하라.
32. 근면은 프로그래머가 프로그래밍을 하는데 있어서 근간을 이룬다.
33. 자신이 작성한 프로그램에 자부심을 갖되 대단한 기대는 갖지 말라.
34. 직장에서 퇴출될 수 없는 자신만의 노하우를 가져라.
35. 운이 안 좋아도 배움을 늦추지 말라. 운이 안 좋을때 배우는 것이 더 많을 수 있다.
36. 장황한 지식이 아닌 실질적인 지식을 갖추어라.
37. 소프트웨어 기술 지식을 적시 적소에 사용하는 방법을 배워라.
38. 프로그래머는 소프트웨어 개발을 위한 마법사임을 깨달아라.
39. 자신의 결점을 숨기려고 하지 말고 결점을 고치려 하되 안 되면 무시하라. 가능한 한 떳떳하고 당당하게 살아가라.
40. 팀 내에서 다른 팀원의 결함을 찾아내려고 하지 마라.
41. 프로그램 개발에서부터 팀웍에 이르기까지 매사에 긍정적으로 생각하고 행동하라.
42. 사유와 상상은 다르다. 상상할 때와 사유할 때를 구별하라.
43. 팀 내의 전체적인 분위기를 읽을 줄 알아라. 회사가 돌아가는 분위기를 인식하라.
44. 경쟁 프로그래머가 있을 경우 그를 존중하고 그로부터 배우려고 노력하라.
45. 교만하고 자만해 있는 사람이 팀원으로 있다면 자신의 마음에 그러한 요인이나 인자가 없는지 잘 내면을 살펴라.
46. 소프트웨어 프로그래머의 실력은 소프트웨어가 얼마나 성능이 좋은가에 판가름난다.
47. 누구나 할 수 있는 프로그래밍 기술도 갖추되 자신만의 프로그래밍 기술도 갖추어라.
48. 프로그래밍에 대한 자신의 주관을 져버리지 말라. 자신의 철학을 지켜라.
49. 팀원으로부터 인기를 얻으려고 하지 말라.
50. 프로그램 상에 존재할 수 있는 미심쩍은 오류나 버그에 대해서는 즉각 조치를 취하라.
51. 운이 좋은 프로그래머와 실력이 좋은 프로그래머들을 주변에 많이 두어라.
52. 위기에 처했을 때는 마음으로 자신이 선망하는 고수들에게 기도하라.
53. 자신의 기술지식을 팀원에게 베풀거나 그들과 공유하라.
54. 자신의 능력을 20%~30%는 숨겨라.
55. 팀원이나 팀장의 요청을 무조건 받아들이려고 하지 말라. 거절할 줄도 알라.
56. 자신의 기술지식이나 기술소질에 있어서 가장 뛰어난 부분을 더욱 발전시켜라. 자신의 장점을 최대한 발전시켜라.
57. 프로그램의 구조와 설계 전반에 관하여 조용하고 맑은 정신으로 깊이 사유하는 시간을 가져라.
58. 구루나 마스터가 되기 전까지는 프로그래밍을 짜기 전에 3번 생각하고 한 줄의 코드를 작성하는 습관을 가져라.
59. 짠 코드를 다시 고치거나 지우는 것을 아깝게 생각하지 말라.
60. 프로그램이 완전히 완성되기에는 시간이 필요함을 알라. 모든 사사물물은 완성하는 데에는 시간이 요구된다.
61. 자신을 비난하는 자가 3번을 비난하면 두 번은 침묵으로 무시하나 한 번쯤은 진실한 말로 그렇지 않음을 이야기하라.
62. 운이 좋다고 느껴질 때 열심히 일하고 많은 것을 배워라.
63. 팀원들이 자신을 좋아하도록 해라. 팀원에게 친절하고 베풀어라.
64. 모자란 실력에 대해 자신이 실력 있다고 뻥 튀겨 부풀리지 말라.
65. 자신의 능력을 지나치게 믿지 말라.
66. 팀의 흐름을 따르라.
67. 행운이 자신에게 언제 찾아오는지 명리학자에게 자문을 구하라. 그러나 행운보다 노력과 배움이 더 중요함을 인지하라.
68. 원대한 포부와 야망 그리고 비전을 가진 사람이 어떻게 그것을 현실화시키는지를 알라.
69. 프로그래밍 기술지식이 풍부한 사람을 사귀라.
70. 교묘한 프로그래밍 기술 노하우(TIP)를 많이 습득하라.
71. 프로그램의 제어 흐름과 데이터 흐름을 잘 관찰하라.
72. 자신이 작성한 프로그램은 자신의 분신임을 깨달아라.
73. 프로그래밍을 통해서 일상생활에 대한 자신의 논리적 판단력을 증진시켜라.
74. 팀원을 미워하지 말고 자신을 사랑할 줄 알라. 애증을 버려라.
75. 팀 내에서 나서서 무엇을 하려고 하지 말라. 시키지 않은 일을 하지 말라.
76. 팀 내에서 알 수 없는 신비감과 심오함으로 자신을 포장하라.
77. 팀 내에서 자신과 타인의 자존심에 상처를 주지 않도록 주의하라.
78. 논쟁을 삼가되 논쟁을 하게 되면 서로를 존중하는 기반 하에서 논쟁을 하라.
79. 인생은 선택의 연속이다. 올바른 선택을 하라. 그러나 틀린 선택을 해도 후회하지는 마라.
80. 팀 내에서 누군가 자신을 비난해도 당황하거나 화를 내지 마라. 너그러운 마음으로 사태를 분석하고 진지하고 진솔하게 사실을 이야기 하라.
81. 프로그래밍은 빨리 한다고 능사가 아니다. 시간이 해결해 줄 수 있음도 인정할 줄 알라.
82. 진지함과 즐거움을 동시에 갖고 프로그래밍을 하라.
83. 팀 내에서 싸움은 가급적 피해 되 싸움에서 이기되 패배를 통해서 배우는 자세도 길러라.
84. 싸움은 배짱으로 하는 것이지 머리로 하는 것이 아니다. 머리를 텅비우고 배에 힘을 주어라.
85. 팀 내에서 자신을 나약하게 생각하거나 무시하는 사람에게는 자신이 힘이 있고 위엄이 있음을 보여주라.
86. 싸워서 질 경우 참고 견디는 인내의 마음을 길러라.
87. 프로그래밍할때는 항상 주의를 기울여서 실수와 오류가 프로그램 상에 들어가지 않도록 노력하라.
88. 항상 깨어있는 의식 상태로 프로그래밍을 하라.
89. 항상 버그가 언제 어디서든지 발생할 수 있음을 인식하고 있으라.
90. 팀웍을 원활하게 유지하려면 주변의 사람들의 수준과 자신의 수준을 일치시키도록 하라. 나서지도 말고 주눅들지도 말라.
91. 프로그램의 완성도는 바둑처럼 끝내기를 잘하는데 있다.
92. 프로그래밍을 통해서 지식과 지혜를 길러라.
93. 어려운 문제를 해결해 낼 수 있는 실력을 길러라. 소프트웨어 업계에서 장인이라고 호칭되려면 남들이 해결하지 못하는 프로그램 문제를 고칠 수 있어야 한다.
94. 어려운 문제가 발생할 경우 자신이 해결해야만 한다면 그 문제를 우회할 수 있는 길을 모색하라.
95. 자신의 능력을 100%활용해도 안 되면 휴먼 네트워크를 활용하라.
96. 팀 내의 팀원들에게 좋지 못한 소식은 전하지도 말고 들으려고 하지도 말라.
97. 프로그래밍은 판단력을 기르는데 매우 요긴한 도구이다.
98. 소프트웨어 개발은 결과로서 평가 받는다. 결과가 좋으면 과정도 좋은 것이다.
99. 자신만 잘하려고 하지 말고 팀 내의 팀원들이 판단을 잘하도록 도와주라.
100. 프로그램 개발 시에 모든 것을 혼자 다하려고 하지마라. 팀원들과 함께 일하라. 물론 부당한 요구는 거절할 줄 알아라.
Posted by SB패밀리
보편적 관리자? 프로젝트 매니저(관리자)? 업종 변경?

당신이 개발자라면 어떤 것을 택하시겠습니까?



프로그래머 경력 3년차, 이제 어디로 갈까?

35세 정년 과감하게 뛰어 넘는 경력 관리 해법 찾기

지금 다니는 직장에 몇 개월째 근무하고 있는가? IT 종사자들의 근무 주기가 점점 짧아지고 개발자들도 한 분야만 알아서는 경력 관리를 하기가 힘들어졌다. 평생 직장 개념은 이미 사라진지 오래. 프로그래머라는 직업을 갖고 언제까지 일할 수 있을지 자문해 보자. 프로그래머 정년이 35세라는 말이 공공연히 나돌면서 이제는 자신의 경력을 꼼꼼하게 관리해야 할 때가 왔다. 목표를 확실히 세우고 50세가 되어 있을 자신을 그려 보자.


글·김영미 기자 kelly@pserang.co.kr 사진·권현진 기자 guswls 337@pserang.co.kr

중소 IT 업체에 근무하는 A씨는 요즘 아침에 출근해 컴퓨터를 켜면 암호로 잠궈 둔 이력서를 연다. 자신의 경력기술서를 주욱 보다가 한숨짓는 K씨. 프로그래밍이 좋아 IT 업계로 뛰어든지 어언 3년째, 회사에선 주임으로 승진도 했고 자리도 잡았다. 그동안 갖가지 프로젝트에 밀려 일주일에 서너 번은 밤을 새고 까다로운 클라이언트사의 비위도 맞춰 가면서 프로그래머 경력을 쌓아 왔지만 요즘은 왠지 모르게 자괴감이 밀려 온다.
프로그래머 정년 35세라는 주변의 이야기들을 차치하고서라도 지금하고 있는 업무를 언제까지 할 수 있을지 의문이기 때문이다. 실력이 뛰어난 후배들은 계속 밀려들어 오고 학교다닐 때처럼 계속 공부를 한다는 것도 심적으로 부담이다. K씨는 회사를 계속 다니고는 있지만 앞으로 어떻게 경력을 관리해야 할지 심각하게 고민 중이다.

프로그래머는 왜 이직율이 높을까?

취업 사이트인 인쿠르트의 통계에 따르면 IT 종사자의 이직 주기는 상당히 짧은 것으로 나타났다. 인크루트( www.incruit.com)가 1,982명의 IT 재직자를 대상으로 이직 동향에 대해 설문 조사를 실시한 결과 1~2년마다 회사를 옮기는 종사자가 38.4퍼센트(761명)에 달했다. 5년 이상 주기로 회사를 옮기는 종사자는 4.7퍼센트(94명)에 불과한 것으로 나타났다. 이직시 10~20퍼센트의 연봉을 올려 받는 것으로 드러났다.
‘2~3년마다 이직한다’는 대답은 31.4퍼센트, 3~5년 단위로 이직하는 경우는 13.6퍼센트, 1년 이하 주기로 이직하는 경우는 11.9퍼센트 등이었다. 전체 이직 주기로 보면, 1~3년마다 이직하는 비율이 전체의 69.8퍼센트에 달해 대다수 IT 종사자들이 1~3년 내에 다른 직장으로 옮기는 것으로 조사됐다. 이직 사유로는, ‘회사의 비전이 없기 때문’이라고 답한 응답자가 33.5퍼센트(664명)로 가장 많았고, 그 뒤를 이어 ‘자기 계발을 위해 이직한다’가 33.1퍼센트(655명)에 달해 직장 생활에서 회사 비전과 개인의 발전 가능성을 가장 중시하는 것으로 드러났다.

그렇다면 프로그래머들은 왜 이직을 자주 하는 것일까? 물론 고용 불안에서 오는 구직자들의 자발적 이직도 있지만 거꾸로 이야기하면 그만큼 기회가 많기 때문이라고 해석할 수도 있다.
잡서치코리아의 이기대 사장은 국내 2~3년차 프로그래머들의 문제점을 IT 산업 계층 구조에서 기인한다고 설명한다. 그는 “국내 IT 업체들은 산업 자체가 영세한데다 SI 업체가 많아야 프로그래머가 대접을 받는데 SM(시스템 운영) 업체들이 대부분이다. IT업체들이 2차, 3차로 하청을 주는데 이 하청 업체에 2~3년차 프로그래머들이 몰려 있다. 따라서 업무 환경도 열악하고 자기 개발할 여유도 없이 경력을 쌓게 된다. 노가다성 코딩 작업만 하다보니 자신의 능력을 업그레이드할 기회가 없어 슬럼프에 빠진다”고 말한다.


프로그래머 10년, 관리자 10년
국내 IT 환경에서 개발자들이 전산 업무를 10년 정도 하면 관리자로 승진하고 더 이상 개발자로 일하지 않는다. 이는 본인의 선택적인 측면이 많지만 장유유서(長幼有序)로 대변되는 사회분위기와 무관하지 않다. 또 30대 중반이 되면 아이들이 커가고 밤새고 일하는 것이 즐겁지 않다. 관리하고 싶은 마음이 생기는 것이다. 여기에서 프로그래머 ‘35세 정년’이라는 말이 나오기 시작한다.


개발자로서 수명이 다한 인력들은 다른 분야로 전직하거나 개발자들을 관리하는 매니저로 승진하는 것이 통상적인 국내 프로그래머들의 경력 지도이다. 일부 IT 컨설턴트라고 하는 개발자와 관리자의 중간 단계의 직종으로 자리를 옮기는 경우도 있지만 문과 출신이면서 IT 기업 근무 경력이 있고 경영학 석사 등 각종 학위로 무장한 이들에 밀려 빛을 보지 못하는 경우가 많다. 사정이 이렇다보니 서른만 넘겨도 의욕을 상실하는 프로그래머들도 생겨난다. 그렇다면 경력 관리는 언제, 어떻게 시작해야하는 것일까. 헤드헌팅 포털 HP존에 따르면 헤드헌터들은 이직 희망자들의 가장 큰 문제점을 경력 관리 미흡과 조직 생활 부적응을 꼽았다.


전문가들은 초보 개발자 시절부터 자신의 목표를 명확히 해야한다고 말한다. 삼성멀티캠퍼스 교육사업팀 오형석 과장은 “자신이 제너럴리스트로 성장할 것인지 스페셜리스트로 성장할 것인지에 대해서는 확실한 주관이 있어야 한다”고 말한다. 경력 관리에 기술적인 접근이 필요하다는 것.


계속 프로그래밍을 할 것인지, 개발 지식을 토대로 기술 영업을 할 것인지, 프로젝트 매니저가 될 것인지 2~3년차에 결정해야 한다는 인크루트 김현정 IT 담당 부장은 “취업 시장에서는 프로그래머의 수명은 약 20년이다. 이 중 순수하게 프로그래밍(코딩) 업무만으로 파악하면 약 10년 정도이다. 이는 다른 산업군에 비하면 상당히 길다. 프로그래밍 분야 즉, 코딩 작업을 할 수 있는 기간이 10년이라는 이유는 IT 트렌드가 끊임없이 바뀌고 있고 개발 언어 또한 계속 교체되기 때문”이라고 쐐기를 박는다. 그러나 이 기간 동안 프로그래머 업무에 충실하고 경력 관리를 제대로 하면 길을 얼마든지 있다.

변화에 알맞는 경력 지도 그려야
올해 31세인 5년차 프로그래머 장윤기씨의 경우 현재 네 번째 직장에 다니고 있다. 이 중 1년씩 일한 직장이 2곳, 3년 동안 일한 업체를 거처 포스데이타라는 SI 업체에 안착했다. 그는 중소 IT 업체에서 경력을 쌓고 대기업으로 경력을 업그레이드 했다. 올해 30세인 권영민 시큐어소프트 과장의 경우 병역특례 경력을 합하면 프로그래머 경력만 7년째다. 비주얼 C에서 자바로 업그레이드하고 프로그래머로써 경력을 쌓다가 경력이 10년쯤되면 독자적인 프로젝트 매니저로 승부를 낼 생각이다.


프로그래머의 일반적인 경력 지도는 약 10여 년의 프로그래머 생활을 거친 후 기술 영업을 하거나 전산실 매니저가 되거나 프로젝트 매니저로 성장하는 방안을 들 수 있다. 기술적인 백그라운드가 있고 전문성이 있기 때문에 가능하다.


이 중 프로그래머 실력을 기반으로 성장하고 싶은 개발자들은 프로젝트 매니저에 관심을 가져보자. 급변하는 IT 트렌드를 봤을 때 개발자가 2~3가지 프로그래밍 언어까지는 학습이 가능하지만 그 이상은 어려운 것이 현실이다. 메인프레임을 사용하던 개발자가 C/S 환경에서 웹으로 전환하기가 사실상 힘들기 때문이다.


프로젝트 매니저는 프로젝트 일정을 관리하고 전산 자원을 배분하여 프로젝트를 효율적으로 이끄는 역할을 하는 핵심 인력이다. 자신이 수행한 프로젝트로 경력을 인정받는 프로그래머는 금융이나 통신과 같은 산업 분야 별로 경력을 쌓거나 원가, 회계, 재무와 같은 직무별 커리어를 쌓는 것이 경력 관리에 도움이 된다.


분야별 전문 지식을 토대로 관리 능력을 쌓아가는 것이 프로그래머 경력을 극대화시키는 방법 중 하나이다. 국내의 경우 ‘관리자=People Management’로 인식되는 경향이 있으나 점차 바뀌어가고 있다. 이는 우리나라 전산인들이 프로젝트 관리를 제대로 하지 않는다는 반성에서 비롯된다. 잡서치코리아 이기대 사장은 “프로그래머로 경력을 쌓고 관리자가 되면 피플 관리가 아닌 프로젝트 관리로 포지셔닝을 해야 한다. 건별 계약이든 기업의 전산 관리자로 있든 경력이 어느 정도 쌓이면 PM(Project Manager)역할을 할 수 있어야 하는데 국내에는 이러한 인력이 턱없이 부족하다. SI 인력도 적을 뿐더러 프로젝트 관리 능력이 떨어져 결과적으로 IT 결과물의 퍼포먼스가 떨어진다”고 말한다.


실제로 30대 중반의 프로젝트 매니저를 헤드헌팅업체에서 많이 찾는데 국내에서 찾기 힘들다는 것이 전문가들의 견해이다. 전반적인 기술이나 프로젝트에 대한 관리 능력을 갖춘 전문가가 시급하다는 것. 프로그래머는 많아도 관리자는 드문 것이 국내 전산 환경의 현 주소이다.


경력을 쌓아 교육 분야로 진출하는 것도 바람직하다. IT 교육 전문가가 턱없이 부족하기 때문이다. 대학이나 기업에서도 IT 분야를 가르칠 사람이 없어 애를 먹고 있다.


얼마 전 한 중견 IT 업체는 최근 호주 소프트웨어 회사의 수석 엔지니어를 초빙해 3일간 프로그램 교육을 실시했다. 강사료는 1,000만 원. 국내에서는 이같은 인력을 찾을 수 없었다는 업체 측의 전언이다. 노동연구원 조사 결과에서도 고급 인력이 절대적으로 부족한 직종 1위는 IT 교육 전문가이다. 지난해 보고서에 따르면 대학과 학원, 직업 훈련 기관의 부족한 IT 교원은 1,374명이었다. 1년차 개발자 100명 중 5년이 지나고 남는 개발자가 15명밖에 안된다는 말이 이를 반증해 준다.



조직 내 커뮤니케이션·리포팅 능력 중요
일반적으로 프로그래머의 특성을 살펴 보면 외곬수에 커뮤니케이션 능력이 약하다는 평가를 내리는 사람들이 많다. 한 대기업의 마케팅 부서 이사는 “자신의 의사를 적절히 표현하지 못하는 프로그래머들이 많다. 회의 시간에 한 마디도 못하거나 요점없는 이야기로 시간을 낭비하고 대답을 못하거나 의견을 제시하면 무조건 할 수 없다고 말하는 개발자들이 많아 현업에서 불만”이라고 이야기한다. 어려운 프로그래밍 서적만 보다보니 커뮤니케이션 능력이 상대적으로 떨어진다는 것.


인크루트 김현정 부장은 “프로그래머들은 업무 성향이 오기와 비슷한 독특한 특성이 있다. 커뮤니케이션 활동이 폐쇄적인 데다 오픈마인드를 갖고 있지 않다”고 평가한다. “IT 조직은 서비스 조직이라는 생각을 갖고 있어야 한다. 지원 조직이고 현업을 서비스하는 조직이라는 마인드를 갖고 있어야 한다. 프로그래머가 현업과의 커뮤니케이션에서 융통성을 발휘하고 서포팅을 잘하면 인정받기도 쉽다”고 조언한다. 그러나 프로그래머들이 현업을 이해가기가 만만치 않은 것이 현실이라고 말한다.


실제로 프로그래머들 중 상당수는 상사와의 갈등이나 동료와의 불협화음으로 이직을 하려는 개발자도 많다. 소규모 IT 기업에서 근무하던 개발자 B씨는 회사가 급성장 하면서 조직이 확대되어 개발 인력이 수십 명으로 불어났으나 이에 적응하지 못하고 실직한 경우다. 이전의 가족같은 분위기가 사라진 데다 새로 영입된 팀장의 업무 스타일에 적응하지 못한 것. 조직 내 커뮤니케이션이 프로그래머에게 큰 문제로 나타난다는 것이 전문가들의 의견이다. 이기대 사장은 “커뮤니케이션을 잘하는 가장 손쉬운 방법은 상대방이 하는 말을 주의 깊게 듣고 있다가 그 방식으로 그대로 설명하는 것”이라고 조언한다.


프로그래머들에게 또 하나의 벽은 글쓰기와 프리젠테이션 능력이다. 자신의 생각을 표현해 내는 과정에서 타 부서인들의 이해를 구하려는 노력이 필요하다는 것. 권영민 시큐어소프트 과장은 “개발자들이 스케줄 관리와 다큐멘테이션에 약하다. 프리젠테이션 능력과 글쓰기 노력을 병행해야 한다. 자신이 가진 기술만큼 중요한 것이 생각을 표현해 내는 능력”이라고 말한다.



장기계획 세우고 목표 확실히 설정
초보 개발자 시절부터 장래에 대한 계획을 확실히 세우고 꾸준히 계단을 올라 가면 더할 나위 없겠지만 안타깝게도 경력 관리에 대해 여유를 갖게 되는 것은 시간이 한참 흐른 후이다. 이번 기회에 다시금 자신을 되돌아보는 계기를 만들어 보자.


여러 가지 이유 때문에 실직했다면 공백을 최우선으로 줄이는 것이 경력 관리에 흠을 없애는 방법이다. 무엇보다 공백 기간이 6개월 이상 장기화되지 않도록 노력해야 한다. 프로그래머에게 있어 반년 이상의 공백은 일을 안한다는 의미가 아니라 직무 능력이 떨어짐을 의미하기 때문이다. 따라서 실업이 장기화될 가능성이 있을 때는 차라리 직장 눈높이를 낮춰서라도 재직 상태를 유지하는 것이 좋다. 불가피하게 공백기를 가졌다면 업무의 연속성을 가져야 한다. 아르바이트를 하거나 커뮤니티 활동, 연구, 단기 프로젝트 활동을 할 수 있도록 노력해야 한다.


특히 유의할 점은 일을 놓고 싶더라도 목표없이 그만 둬서는 안된다. 업무를 진행하면서 주기적으로 휴식을 취할 수 있는 공간을 만들어야 한다. 또, 취업 정보를 꾸준히 받을 수 있는 상황인지 살펴 봐야 한다. 퇴직 준비를 하면서 정보 검색을 하지 않았다면 반성해야 한다. 프로젝트 매니저로서 대우를 받을 수 있는 경력은 5년차 이상일 때 옮기는 것이 좋다. 프로젝트 경험 많은 7년차가 가장 좋다.


슬럼프에 빠졌다면 보직이나 근무지를 바꿔 같은 일이라도 새로운 환경에서 일하도록 하는 것이 좋다. 업무와 관련된 교육 기회를 찾아 그간의 관점을 바꿀 수 있는 신선한 주제를 제공하여 분위기를 전환하는 것도 좋은 방법이다.
Posted by SB패밀리


XP 이상 O/S는 사용자 계정 컨트롤(UAC) 라는게 기본설정으로 존제한다.
강화된 보안정책으로 어떠한 행동을 할때 권한을 얻고 해라 라는 형식이다.
일반적으로 어느정도 O/S를 다룰줄 아는 사람은 이부분을 권한 설정을 끈다.
하지만 그렇게 못하는 사람도 있기 때문에 프로그램을 만들때
관리자 권한을 획득한 상태로 프로그램을 실행 시켜야한다.

- ShellExecute 를 사용 하는 방법

if(IsUserAnAdmin() == FALSE) //프로그램이 관리자 권한인지 알 수 있는 함수
{
 //관리자 권한으로 실행 시킨다.
 SHELLEXEGUTEINFO si
 ZeroMemory(&si, sizeof(SHELLEXECUTEINFO));

 si.cbSize = sizeof(SHELLEXECUTEINFO);
 si.hwnd = NULL;
 si.fMask = SEE_MASK_FLAG_DDEWAIT | SEE_MASK_FLAG_NO_UI;
 si.lpVerb = _T("runas");
 si.lpFile = _T("프로그램명");
 si.lpParameters = _T("파라미터");
 si.nShow = SW_SHOWNORMAL;
 si.lpDirectory  = NULL;

 ShellExecuteEx(&si);
}

 

- Visual C++ 2008 일 경우 설정

 

 Project > Properties 메뉴를  선택
 Linker > Manifest File 항목에서
 Enable User Account Control (UAC)를 Yes로 설정하고
 UAC Execution Level을 requireAdministrator로 설정한다.

 

- 매니페스트 파일 생성


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

  <assemblyIdentity version="1.00.0"

     processorArchitecture="X86"

     name="IsUserAdmin"                       

     type="win32"/>

  <description>Description of your application</description>

  <!—어플리케이션 보안 요구 사항을 식별합니다. -->

  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

    <security>

      <requestedPrivileges>

        <requestedExecutionLevel

          level="requireAdministrator"

          uiAccess="false"/>

        </requestedPrivileges>

       </security>

  </trustInfo>

</assembly>

 

위의 내용으로 manifest 라는 XML 파일을 생성한다.

name="IsUserAdmin" 여기에 실행파일 명을 명시!!!
level="requireAdministrator" 인 경우 관리자 권한으로 프로그램 실행됨.
level="asInvoker" 인 경우 부모 프로세스와 동일한 토큰으로 실행됨(경험적 결과이나 일반사용자 권한으로 실행됨)

 


위의 파일을 응용프로그램 안으로 통합하는 방법은 여기  http://blogs.msdn.com/shawnfa/archive/2006/04/06/568563.aspx  를 참고하십시오

Posted by SB패밀리