태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

무늬만 개발자

2012/07/09 06:00 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

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

그런 환경을 만들고 싶다.


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


image by  Michael Kappel


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

전규현 사람과 기술

Trackback Address: http://allofsoftware.net/trackback/262 관련글 쓰기
  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년이상을 제대로 된 개발을 못했는데 다시 해보려 합니다.
    그래도 남는것은 개발인것 같고 전규현님 말씀처럼 좋은 관리자가 되는 방법은 조금 뒤로 미뤄도 될것 같다는 생각입니다.
    훌륭한 개발자 또는 엔지니어로서 커리어를 확실히 쌓아두는 것이 향후 개발자건, 관리자건 선택의 폭을 넓히고 기회를 만드는 지름길이라 판단했습니다.
    쉽지 않고 자신감도 많이 떨어졌지만 다시 해볼랍니다.
    저와 같은 고민을 하시는 분들 모두 모두 화이팅입니다!!!
    개발이건 관리건 인생의 목표는 '행복'이라 생각합니다.

넣는 것 보다 빼는 것이 더 어렵다.

초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다. 성공하는 회사들의 초기 제품은 간략하고 핵..

[공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다.

소프트웨어를 개발하는데 있어서 가장 어려운 것을 하나 꼽으라면 "요구사항분석"입니다. 소프트웨어를 개발하는데 있어서 가장 중요한 것을 하나 꼽으라도 "요구사항분석"을 선택합니다 하지만 우리나라에서 "요구사항분석" 역량을 제대..

투명한 개발 문화의 효과

흔히 투명한 개발이 효율적이고 좋다고 한다. 그 진정한 의미를 알아보자. 투명한 개발이란 개발에 관련된 거의 모든 정보와 지식이 공유되는 것을 말하지만 추가로 내가 강조하고 싶은 것이 따로 있다. 거의 모든 결정의 과정 및..

소프트웨어공학은 실전이다.

이 전글에 댓글을 달려다가 좀더 정리를 해야 할 것 같아서 본글로 올린다. 2013/02/27 - [프로젝트/품질관리] - 거의 다 만들었어요. 알파, 베타의 정의를 가지고 이렇게 강하게 주장하는 경우는 처음봐서 약간 당황스..

거의 다 만들었어요.

"거의 다 만들어서 2주후에 개발이 끝나요" 이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다. 개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다. 하지만 이런 대화는 여..

고쳤으니 테스트 해주세요.

여기 두가지 테스트 방법이 있다. 우리 회사는 어떤 방법을 사용하고 있나 생각해보자. 첫째, 테스트 도중에 버그를 고쳐서 좀더 안정된 버전을 테스트팀에 계속 전달하는 방식이다. 테스트 한사이클을 도는데 2주일이 걸린다고 생각..

인해전술이 오히려 프로젝트를 망친다.

일정이 촉박하다고 프로젝트를 빨리 끝내고 싶은 마음에 프로젝트 초기부터 대거 인력을 투입하면 오히려 프로젝트를 망칠 가능성이 더 높아진다. 프로젝트 초기에 분석/설계 단계에는 그렇게 많은 인력이 필요하지 않다. 많은 인력을..

1:10:100 rule
1:10:100 rule 2013/02/05

소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 "1:10:100 rule"이다. 성숙한 개발문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고..

티끌모아 태산 (개발 시간 절약하기)

성숙된 개발문화를 가지고 있는 회사는 개발 절차가 아주 효율적으로 진행된다. 하지만 그렇지 않은 회사들은 불필요하게 낭비하는 시간이 아주 많다. 10초에서 몇십분까지 자잘한 시간을 낭비해서 이것들을 합치면 어마어마한 시간이..

재택근무가 가능한가?

우리 주변에는 비효율적인 개발 환경을 가지고 있는 회사들이 매우 많다. 상상외로 많다. 스스로의 회사는 어떤가 생각해 보자. 나름대로 효율적인 개발문화를 가지려고 많은 노력을 해왔을 것이다. 그래서 과연 우리회사가 제대로 효..