태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

Search results for '이직'

망할 회사로 옮겨타는 방법

2011/01/20 14:57 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



많은 개발자들이 현재 회사에서 희망을 느끼지 못하고 회사를 옮깁니다. 그런데, 옮긴 회사도 별반 다를 바가 없는 경우가 많습니다. 그럼 어떤 회사로 주로 옮기게 될까요? (사실 좋은 회사 찾기 정말 힘듭니다.)

  • 망하지 않을 회사? (내가 다니는 동안에는 ...)
  • 정말 재미있는 일을 할 수 있는 회사 또는 좋은 사람과 같이 일할 수 있는 회사?
  • 이전 회사보다 연봉을 많이 주는 회사? (훨씬 많이)

이 모두 이직하는 회사의 조건들입니다. 하지만 아무리 재미있는 일을 할 수 있고 연봉이 많아도 회사가 망해버리면 소용이 없습니다.

망하지 않을 회사는 왠만해서는 망하지 않을 큰 회사이거나 작지만 알찬 회사일 것입니다. 큰 회사들이야 S사나 N사 등 다들 알고 계실 것입니다. 연봉도 작은 회사보다는 많죠. 이런 회사에서 일까지 재미 있다면 금상첨화지만 욕심 같네요. 주로 안정성 때문에 선택을 하게 되겠죠.

큰 회사도 좋지만 저라면 작지만 재미있게 일할 수 있고 성장 가능성이 높은 회사를 선택하겠습니다. 그럼, 작은 회사 중에서 망하지 않을 회사를 어떻게 고를 수 있을까요? 벤처투자가들이 이것을 알았다면 다들 떼돈을 벌었겠죠?

실제로 꽤 유명하고 규모도 큰 회사가 속은 썩어 있고 망하는 길로 가고 있는 회사는 의외로 많습니다.

제 블로그에 예전에 등록한 소프트웨어 회사의 개발 역량 평가표를 통해서 평가를 해보면 약간의 도움이 될 것입니다. 옮기려는 회사 내부에 이를 평가해줄 친구가 있다면 가능하겠지만 그렇지 않다면 알아낼 방법이 없겠죠. 물론 개발 역량이 회사의 성공을 위한 필요충분 조건은 아니지만 필요조건이기는 합니다.

회사의 내부 정보를 알아 낼 수 없다면 경영자를 살펴보는 것이 좋겠습니다. 대부분의 소프트웨어 회사가 특정 단계를 넘지 못하고 꺾이는 결정적인 이유는 경영자의 마인드에서 찾을 수 있습니다. 소프트웨어 회사에서 경영자가 소프트웨어를 이해하지 못한다면 특정 규모 이상으로 성장할 수 없습니다. CEO가 소프트웨어에 대한 이해가 부족하면 CTO가 이를 대신해주는데 우리나라 대부분의 소프트웨어 회사는 CTO가 없거나 CTO가 있어도 CTO역할을 하지 못하고 있습니다.

따라서 회사를 옮길 때 CEO 또는 CTO가 소프트웨어에 대해서 어떤 생각을 가지고 있는지 파악을 해보면 조금더 즐겁게 일할 회사, 그리고 앞으로 더 성장할 수 있는 회사로 옮길 가능성이 조금더 높아질 것입니다. 

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


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

전규현 사람과 기술 이직

Trackback Address: http://allofsoftware.net/trackback/208 관련글 쓰기
  1. Blog Icon
    쎄오

    S/W 회사의 경영자들도 S/W를 잘 이해하지 못하는 경우가 많은가 보군요... ㅡㅡ;;

    비 S/W 회사의 경영자가 S/W를 이해해 주길 바라는 것은 욕심이겠죠? ^^*

  2. 쎄오님 안녕하세요.
    비SW출신 경영자가 SW를 제대로 이해하기는 불가능하죠. 그래도 다른 사람의 얘기에 귀를 기울이는 경영자는 SW전문가의 도움을 받을 수 있습니다.

  3. CEO가 소프트웨어에 대한 이해는 있는데 경영에 대한 이해는 全無해서 망하는 경우도 있지 않나요? 물론 "소프트웨어에 대한 이해"의 범위를 어떻게 잡느냐에 따라 다를 수 있겠지만...

  4. 안녕하세요. Vincent님
    CEO는 경영자입니다. 경영에 대해서 전혀 모른다면 CEO로서의 자격이 없습니다. CEO가 모든 분야의 전문가가 될 수 없으므로 부족한 부분은 CTO, CFO, COO등의 도움을 받을 수 있겠지만, 경영, 비즈니스를 모른다면 아예 자격이 없다고 생각합니다.

  5. 저는
    지금까지 CEO, CTO, CFO등의 역할에 대해서 진지하게 고민을 해보지 않았던것 같습니다.
    위의 리플들을 쭈욱 읽어보니 각 CEO, CTO, CFO들의 역할이 다 있는것 같다는 생각이 들었습니다.
    제가 왜 이런 이야기를 하냐하면, 단지 CEO, CTO, CFO들은 높은사람, 높은자리에 있는사람이라고만
    생각했고, CEO만 있어도 문제없을거라 생각했거든요?

    좋은글 잘 읽고 갑니다.
    더 노력해야겠다는 생각을 하고 갑니다.

  6. 안녕하세요. 땅콩맨님
    감사합니다.

동종업계 취업금지 각서

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

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

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

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

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

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

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

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

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

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

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

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

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

Trackback Address: http://allofsoftware.net/trackback/163 관련글 쓰기
  1. 2009/12/29 18:15
    kiyong2의 생각 Tracked from case's me2DAY
  2. 2009/12/31 13:39
    각서나 문서 사인 요구시. Tracked from 천지여! 작렬태양이여! 솔솔부는 바람이시여!
  1. 각서보다는 예전 판례가 있기 때문에 문제가 되는게 아닐려나요?

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

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

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

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

이 바닥을 못 벗어난다.

2009/05/18 23:12 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed
우리나라 소프트웨어 개발자들은 자신이 처음부터 일해온 바닥을 못 벗어나는 경향이 있습니다.

처음에 게임회사에서 일을 시작한 개발자는 계속 게임회사에서 일하고, 금융회사, 보안회사, 장비회사, SI회사 등 쉽게 그 바닥을 못 벗어나곤 합니다. 

이러다 보니 개발자가 이직 시 선택의 폭이 좁아지고, 분야가 조금만 바뀌어도 자신의 Value가 확 줄어드는 현상이 일어나곤 합니다.이런 일이 비일비재하게 일어나는 것을 보면 개발자의 전문성이란 어디에 있는 것인지 궁금하지 않을 수 없습니다.

금융에 대한 전문지식을 많이 가지고 있고, 게임에 대한 많은 지식을 가지고 있는 것을 개발자의 전문성이라고 볼 수도 있습니다. 또 그러한 Domain 지식이 없으면 개발을 할 수 없다고 단정적으로 얘기를 하는 개발자도 많습니다.

소프트웨어 엔지니어가 소프트웨어를 개발하기 위해서는 크게 2가지의 지식이 필요합니다.
그 중 하나는 이미 앞에서 언급한 Domain 지식입니다.
그리고 또 하나는 Software Engineering 지식입니다.

Domain 지식은 개발 분야가 바뀌면 거의 쓸모가 없는 산업 지식이고, Software Engineering 지식은 개발 분야가 바뀌어도 항상 사용되는 지식들입니다.

Domain 지식은 너무 광범위해서 나열을 할 수는 없습니다.
하지만 Software Engineering 지식은 무엇인지 설명할 수 있습니다.

요구분석, 설계, 구현, 테스트, 소스코드 관리, 버그 관리, 프로세스 등 소프트웨어를 개발하기 위한 일련의 지식들입니다.

물론 소프트웨어를 개발하기 위해서는 Domain 지식과 Software Engineering 지식 모두가 필요합니다. 하지만 흔히 접하는 현상을 보면 개발자들이 점점 Domain 지식이 치중하는 경향이 있습니다. Software Engineering에 대한 전문성을 떨어진 상태에서 Domain 지식만 점점 늘어가니 당장 일은 잘하고 있는 것 같아도, 동료나 후배들과 협업이 잘 안되고, 프로젝트 규모가 조금만 커져도 문제가 있고, 이직 시에는 심각한 가치 하락이 발생합니다.

그럼 어떻게 해야 할까요? 소프트웨어를 개발하면서 자연스럽게 얻게 되는 Domain 지식에만 의존해서는 안됩니다. Software Engineering 지식을 꾸준히 발전시켜서 소프트웨어 전문가가 될 수 있도록 해야 합니다. Software Engineering에 능통한 소프트웨어 전문가가 된다면, 어느 소프트웨어 회사를 가더라도, 여전히 전문가로서 높은 가치를 가지고 개발을 할 수 있습니다. 새로운 분야로 이직을 하더라도 Domain 지식은 일을 하는 과정에서 차츰 배워 나갈 수 있습니다. 

그리고 Domain 지식에 능통한 개발자에게만 의존해서 개발이 진행되는 소프트웨어 회사는 매우 큰 리스크를 안고 있는 겁니다. 그런 개발자가 한 명만 퇴사를 해도 회사는 큰 위험에 봉착합니다.  

결국, 회사를 위해서도, 개발자들을 위해서도 개발 개발자들의 머리 속에 들어 있는 Domain지식에 의존하기보다는 적절한 개발 프로세스 및 시스템을 기반으로 개발을 해야 합니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 
저작자 표시 비영리 변경 금지

'소프트웨어이야기' 카테고리의 다른 글

도대체 얼마나 자세히 적어 달라고?!  (4) 2009/06/29
악순환 vs. 선순환  (2) 2009/05/22
이 바닥을 못 벗어난다.  (5) 2009/05/18
나는 혼자가 아니다.  (5) 2009/05/15
이거 팔면 돈 되겠는데!  (20) 2009/04/17
외주를 주면 된다고요?  (6) 2009/03/30

전규현 소프트웨어이야기 Domain지식, 소프트웨어전문가, 이직

Trackback Address: http://allofsoftware.net/trackback/122 관련글 쓰기
  1. Blog Icon

    비밀댓글입니다

  2. Blog Icon
    한세희

    절대 공감합니다. 저희회사에서 오래 다니신분들만봐도 이글에 속하는 개발자들이 수두룩한듯합니다.ㅠㅠ

  3. 한세희님 안녕하세요.
    그럴 수밖에 없는 환경도 많이 있는 것 같습니다.

  4. Blog Icon
    grayger

    회사 경영진은 도메인 지식이 쌓인 인력은 대체하기 어려운 인력, Software engineering 에 능통한 인력은 대체하기 쉬운 인력이라고 판단합니다. 도메인 지식이 풍부한 자가 설계를 하고, 개발은 외주를 주는 경향이 있죠. 특정 도메인에 전문화된 기술을 가진 회사일수록 도메인 지식이 부족하나 개발은 잘하는 사람을 핵심 인재라고 생각하지 않습니다.

  5. grayger님 안녕하세요.
    그래서 악순환의 고리가 계속되고 원인은 총체적인 문제입니다. 관련된 글을 더 올릴 계획입니다.

관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..