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

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

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

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

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

아침에 신문을볼때마다 항상 두어번은 듣는 그 단어......ㅎㅎ 그런시각으로 볼수도 있겠네요 : )
좋은글 잘 읽고 있습니다.
전에 영어에 대한 쓰신 글을 본후, 꾸준히 공부하고있습니다.
실력 향상된것은 모르겠는데 습관이 되었다는것에 감사한 마음을 가집니다.
그때 조언 감사합니다

세계 최고나 세계 최장을 노려야 하려나요 ㅎ
세계적 수준의 안정성! 이런것도 좋을꺼 같은데 말이죠.


가끔은 무언가를 만들어내고 싶은 사람으로서
이미 내가 상상한 대부분은 어딘가에 만들어져있다 라는 사실에 우울해지더라구요.

이제는 어떤 분야에서 최초라는 말은 마루타라는 말로 밖에 안들립니다.
최초로 어떤 제품이 출시되고 몇달 후면 사용자들의 원성이 터져나오니 말이죠..
소프트웨어를 비롯한 모든 제품에서
최초보다는 안정화된 2번째, 3번째 제품들이 훨씬 괜찮다고 생각합니다. :-)

조금 다른 얘기를 하면, 너무 개발 계열에서만 바라보신 듯 합니다.
어차피 '세계 최초', '획기적인 기술'이라는 문구는 마케팅적 관점일 뿐입니다. 이걸 개발 계열의 관점으로 판단하는거 자체가 조금 어긋난거 아닌가 생각됩니다.

이런 문구는 (비록 완벽한 사실은 아닐지라도) 매우 중요합니다.

90의 기술을 만들고 가만히 있는 거보다, 80의 기술을 만들고 나머지 10을 가지고 열심히 마케팅하는게 중요할 수 있거든요. 실속있게 개발해야 된다고 하셨는데, 그 10의 마케팅자체가 실속있는 '개발+홍보+판매' 라고 볼 수 있거든요.

실속 있게 개발했다고 해서 모든 사람들이 그걸 알아준다면 어떻게 보면 세상은 공학도 위주로 돌아가겠죠. 하지만 그렇다면 마케팅 부서는 필요가 없는 것일꺼구요.

실속 있게 개발하는 것도 물론 중요하지만, 실속 있게 마케팅하는 것도 그에 못지 않게 중요하다고 봅니다.
(이렇게 말했지만, 그렇다고 전 마케팅과는 상관은 없는 사람입니다. 단지, 너무 개발 쪽에만 치우쳐진 시각인 것 같아서, 균형이 중요하다는 것을 말씀드리고 싶은 것입니다~)

안녕하세요.
언제나 좋은 글 잘 읽고 있습니다. 저도 개인적으로 많이 공감하지만 글 중에 조금 생각이 달라서
몇자 적어 봅니다.
자바 밖에 못한다가 꼭 나쁜건 아니라고 생각 합니다.
물론 님의 말씀도 꼭 그런 의미는 아니라고 생각합니다만 우리 나라 소프트웨어 산업을 보면
두루 두루 슈퍼맨을 인정하는 분위기가 많은거 같습니다.
특정 한 분야만 잘 하는 사람이 다수 존재하더라도 그들 사이의 커뮤니케이션 혹은 조율만 잘 할수 있다면
훨씬 더 좋은 결과를 낼수 있지 않을까요?
박사 과정의 전공만 놓고 보더라도... 왜 그 사람들이 한 분야만을 집중적으로 공부할까요?
분명 뭔가 그럴수 밖에 없는 이유가 있지 않을까요?
가장 중요한 것은 얼마나 깊이있는 지식을 습득하는 것이 아닐런지요.
대학 수업에서도 똑같은 과목을 전공 교수가 가르치는 것과 타학과 교수가 가르치는 것은
분명 차이가 있습니다.
수업을 잘하는 교수와 연구를 잘하는 교수 둘다가 대학에 필요하듯이
특정 언어를 가장 잘 이해하는 개발자만도 좋은 룰모델 혹은 평가를 받았으면 해서 몇자 적어 봅니다.

특히 요즘들어 도메인 지식보단 메타지식의 가치는 아무리 강조해도 지나치지 않는 시대 같습니다.

무엇보다 결론이 명쾌하시군요^^
그냥 뛰어난 개발자를 구하라!
너무 단순한지만 확실한 정답이 없는 것 같습니다^^

좋은 글 잘 읽고 갑니다. RSS 등록해놨습니다. ^^
"아이폰 개발 경험이 있는 개발자 급구" 또는 "안드로이드폰 개발 경험이 있는 개발자를 모십니다"는 개발자를 찾는게 아니라 경험을 찾는 게 아닐까요?

"개발자들의 개발 능력은 Domain지식과 경험에 크게 구애받지 않아야 한다는 겁니다."
본문의 이 부분에 크게 공감합니다.

저는 SI를 주로 하고 있습니다.
개발언어, 도메인을 전혀 가리지 않고 있습니다만,
접해본것은 몇가지 되지 않습니다.

프로젝트 면접을 보면 그쪽 언어, 혹은 도메인을 경험해보지 않았다고
탈락시키는 경우가 많더군요..

실제로 몸을 사리는 개발자들도 많지만
(말씀하신대로 난 java밖에 몰라, 또는 C밖에 몰라.. 나머진 다른 사람 시켜.. 하는 사람도 많더군요.)
경험이 없는 개발자는 절대 뽑지 않는 프로젝트도 많더군요..
3대 SI에서도요..

예전에(2003년도) 3대 SI업체중 한곳에서 스트러츠로 개발하는데 다른 사람만큼
퍼포먼스가 안 나온다고 일주일만에 쫓겨난 경험도 있고요.. (그때가 스트러츠 처음.. MVC도 처음)

개인의 노력도 중요하지만 업체들의 시각도 바뀌었으면 합니다...
물론 SI 기준입니다.. (패키지,솔루션등은 잘 몰라서요..)

첫번째 드는 생각은, 아직도 많은 사람들이 프로그래밍을 단순히 조금 더 '아는 것' (언어를 아는 것/SDK 를 아는것) 정도로 생각하는거 같다는 생각이고,

두번째 드는 생각은, 저렇게라도 뽑아야 할 정도로 훌륭한 프로그래머들을 찾는 것 역시 어렵겠구나... 생각이 듭니다. 아무리 지혜롭지 않은 사장이라 하더라도 그 밑에 훌륭한 프로그래머가 있다면, 그 프로그래머에게 시킬테니까 말이죠.

이직하려고 해도 도메인을 벗어나면 신입이 되니.. 그게 힘들게 하네요 후우..

어플리케이션의 생명은 이젠 아이디어가 아닌가 합니다.
업무 분할이 잘 되어서 아이디어를 살릴 수 있는 사람들은 아이디어를 잘 살리고,
코딩을 해야 하는 사람은 코딩을 잘 할 수 있는 환경이 마련되었으면 좋겠다는 바램인데,,
현실은 그렇지 않네요 ㅎ

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

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

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

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

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

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

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

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

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

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

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

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

안녕하세요. Ray님

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

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

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

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

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

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

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

잘 읽었습니다.

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

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

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

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

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

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

비밀댓글입니다

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

개인적으로 문과 성향이 짙긴 하지만 컴퓨터 하나만 보고 이과를 선택한 저로서는

수학과 개발능력간의 상관관계라.. 실제로 느끼는 바가 있어서 그런지 몰라도 좀 씁쓸하네요.

하지만 개발능력이 높다고 해서 뛰어난 개발자라는 논리에는 쉽게 수긍이 가질 않네요.

극단적인 예입니다만 개인적인 개발능력이 아무리 뛰어나다 해도

팀웍을 해치거나 자기만 이해할 수 있는 코드를 개발하시는 분을 뛰어난 개발자라고 할 수 있을까요? ^^

수학..... 전 중1인데 아직 수학을 잘하지 못하는데요. 지금부터라도 노력하면 '똑똑한 개발자'가 되는 것이 가능할까요?

씁쓸하지만 인정할 수 밖에 없는거 같아요-_-;

개발자도 개발자지만...
제발 기획자도 뛰어난 기획자로 쫌...

아.. 초 씁쓸입니다 ㅠ.ㅠ

그래도 뛰어난 개발자라고 해서 대단한 알고리즘이 툭~하고 튀어나오고 그러진 않을꺼 같아요.
그건 뛰어난 개발자라서가 아니라.. 그냥 천재인겁니다 ^^;

뛰어난 개발자는 이직을 잘 하지 않고 노출을 잘 하지 않다고 하는건.
어떻게 보면 이글과 좀 상반되는 이야기 인것 같습니다. - http://allofsoftware.net/117
정말로 인질범처럼 하나를 움켜잡고 프로젝트 끝까지 질질 끄는 사람들이 많습니다. 누군가는 계속되는 알고리즘을 제공해주는 반면. 이직을 잘 하지 않는 개발자중 상당수는 인질범심리가 꽤나 많더군요.

뭔가 동의 할 수 없는 이유는 뭘까요? (논리력이 떨어지기 때문일까요?) 초.중까지 수학경시대회 나갈 만큼 수학을 잘 했었고(상도 많이 받았지요), 학부 때는 교수가 잘 설명하다가 갑자기 그날 따라 못 풀더군요. 그래서 과감히 문제에 도전을 받고 풀었는데, 중간고사/기말고사를 보지도 않고 A+를 맞았고. 공업수학도 곧 잘 해서, A+, 알고리듬, 고급 알고리듬도 A+이고, 수치해석 A+를 맞았는데... (이 정도면 수학을 잘 한다고 봐도 될까요?) 나름 뜻이 있어 학부 3학년 때부터 산학협동을 시작으로 일을 하기 시작을 하긴 했는데...

그런데... 제가 개발을 잘 하는 사람인지는 모르겠습니다. 가끔은 후배녀석들이 수학을 잘해야 되냐고 묻는데, 나중에 필요할지 모르니까. 공부는 해둬라 정도였습니다. 제 업무가 수치 계산적인 부분이 필요한 콴트 개발자도 아니지만.... 글쎄요.

전체 그림은 무엇을 말씀하시는지 알겠지만, 국부적인 부분에 반감이 생깁니다.

"뛰어난 개발자의 필수 조건인 논리력은 태어날 때 이미 50%는 결정되고 교육과정을 거치면서 나머지 49%가 결정됩니다. 사회에 나와서 아무리 노력을 해도 이미 완성된 두뇌는 별로 바뀌지 않습니다. "

두뇌에 대해서 고정적인 듯 말씀하시는데, 뇌는 결정되지 않습니다. 또는 경험과 노련이 논리적인 것과 상관이 없다는 뉘앙스적 말씀하시는 것에 대해서는 상당히 반감이 생깁니다. 아... 전규현 컨설턴트도 틀린 말을 할 때도 있구나 라는 생각이 들었습니다. 뇌에 관련 된 책을 좀 읽으셨으면 합니다.(잘 모르면 제가 추천해드리겠습니다.) 러닝 스타일(learning style = 태아에서부터 만들어지는)이 존재하긴 하지만 이것은 계발을 통해서 바뀝니다.

그러니, 논리력 상태를 통해서 개발능력이 뛰어나다 아니다라고 말씀하시는 것에는 동의 할 수 없습니다. 내면의 어떤 동기부여에 따라서 그 사람의 스타일은 바뀝니다. 전체적으로 무슨 말씀인지는 잘 압니다. 저도 소위 말하는 문서면접이 아닌 구글만큼은 아니지만 시험을 보고 회사를 다닙니다.(수학문제도 있었고요.)

하지만, 논리, 뇌에 해당하는 문맥은 전체 글을 망가트리는 것 같습니다.

경영자의 한사람으로써 동의합니다. 이런 비밀을 공개하시다니... ㅎㅎㅎ

저는 개발자는 수학뿐만이 아니라 국어도 잘해야한다고 생각합니다.
결국, 코드라는 것은 자기의 생각을 표현해내는 것이기 때문에, 표현력이 요구된다고 생각하구요. 또 훌륭한 표현력은 다른 사람들과 공유할 수 있는 산출물 작성에도 꼭 필요하기 때문이죠.
현장에 있다 보면 많은 분들이 이런 점은 간과하시는 거 같더라구요.

게임개발자들에게 미움 받으실지도 모릅니다. 저처럼요. 저도 늘 그런 소리 하고 다녀서 많은 오해(?)를 받고 살거든요. ^^ 뭐 비단, 게임개발자만이 아니라 이 세상 어딜가나 "기본이 된 개성"과 "기본도 모르는 괴성"이 있는게 아닐까 싶습니다.

즐거운 한 주 만드세요~~

아마도 자신에 대한 '의존도'에 대한 착각이 단순한 '업무부하'로 이어진다는 단순한 사실은 못보기 쉽상이죠. 정작 지켜야할 것은 밥그릇이 아니라 곡간을 채워놓는 일인데 말이죠. 밥그릇보단 곡간을 채울 수 있는 안목을 길러주는 것이 더 중요한 일인지도, 바로 그게 리더의 역할이겠죠.
오히려 개발자보단 리더의 역할이 더 중요한게 아닐런지도 모르겠습니다.

늘 좋은 글로 마음을 채워주시듯...
곡간을 가득 채워갈 수 있는 풍성한 한주 되시길..^^

그래도 개발자는 항상 고달프고 힘듭니다 ㅠ.ㅠ
무슨.. 개발자는 모든 OS를 잘 다루고, 뜬금없이 납땜도 할줄알고
형광등도 잘 갈아야 하고(응?) 슈퍼맨이기를 요구하자면
실질적인 처우는 노예/노비나 다름이 없죠


이런 이유로 갈수록 개발자들의 각박하게 구는게 아닐까 생각이 됩니다.

개발자의 눈으로 이야기 하자면, 이용당하지 않을려고 적당하게 거리를 두고 방어막을 치는 거죠.
어짜피 해주면 잘해야 본전 못하면 쪽박, 그 이후에 처신도 문제고 말이죠. 해주지 않으면 이상한 소리 듣고
한번해주면 그 사람의 업무가 되어버리는 현실이니 말이죠.

물론 개발방법론은 서로에게 좋자고 하는 것이지만, 인원이 부족한 상황이라던가
개발자에게만 강요하는 상황에서는 개발자 역시 스스로를 위해 방어막을 펼칠수 밖에 없는 현실입니다.


그런데.. 정말 왜 기술자/개발자에게는 슈퍼맨이기를 요구하는걸까요..
여기저기서 올라오는 개발자의 덕목을 보면, 득도하거나 신이 되길 바라는 것 같기 까지 합니다 ㅠ.ㅠ

확실히 게임개발자들이 좋아할 글은 아니네요. ^^ 어느 정도 공감은 합니다만.ㅎㅎ

결론만 말하자면, 개발자에게 요구되는 항목들은
갈수록 많아지고, 성인 군자에 슈퍼맨이 되기를 요구하는 것 같아요

말만 거창한 화이트 칼라 계층이지
실은 21세기 IT 노예 그 이상도 이하도 아닌거 같다는 생각이 종종들게 되더라구요.

축구 이야기가 있어서 적어놓고 가고 싶네요.멀티 플레이어를 생각해보면 그가 수비 포지션을 하고 있으면 대신 공격 포지션으로 다른 사람이 움직이 것이고, 그가 공격 포지션으로 가면 다른 이가 수비 포지션으로 갑니다. 즉 동시에 두 포지션을 뛰는것이 아닙니다. 근데 회사는 착각을 하죠. 멀티 플레이어는 두가지 이상을 동시할 수 있다고..

저도 위 글에 동의하면서도 동의하기 힘든 부분이 있습니다. 물론 각각의 영역에 대한 전문화가 필요한 것은 사실입니다. 하지만 전문화의 정도가 어느 정도 선까지 적합한지에 대한 가이드는 없는 것이 사실입니다. 물론 가이드를 만든다는 것이 힘들다는 것은 사실이지만 전문화를 너무 강조할 경우 숲을 보지 못하고 나무를 보는 경우를 종종 봅니다.
점점 더 많은 개발자가 전문화되고 있어서 자신이 현재 하고 있는 일은 파악할 수 있지만 전체를 볼 수 있는 능력을 가진 개발자가 점점 더 사라지고 있다는 것입니다. 물론 멀티 플레이어를 한다고 해서 해결되는 것은 아니지만 전문화가 너무 강조되다보니 개발자가 한 분야에만 너무 국한된 생각을 한다는 것이 문제점으로 부각되고 있습니다.
전문화는 하지만 적절한(?) 전문화를 이야기해야 될 때이지 않나 싶습니다. 이 같은 글이 전문화를 반드시 해야 되는 것으로 비쳐질까 생각되어 덧글 남겨봅니다.

개발자가 모든 개발과 관련된 업무를 다 잘한다면 좋겠죠~
정말 천재적인 사람이 아닌 이상 그건 힘들다고 봅니다. 제가 생각 할때는 기본적으로 개발관련된 부분에 대한 포괄적인 관심이 있어야 한다고 봅니다. 옛날처럼 DOS 에서 C 로 개발할때와 지금은 상황이 많이 다르죠
또한 새로운 기술이 많이 나오는 분야인데 꼭 자기가 하고 있는 부분만 관심을 둔다면 다른 분야 개발을
하는 개발자나 다른분야 사람들(시스템엔지니어 , 네크워크관리자, DB관리자)와 대화할 때 문제가 생기죠. 저는 같이 일하는 경력이 얼마 안되는 개발자들에게 항상 이런 얘기를 해줍니다.~ 개발과 관련된 많은 기술들을 포괄적으로 습득하라고 얘기합니다 또한 자기가 관심있는 전문적인 부분의 스킬을 중점적으로 up시키라고요~ 하지만 다른 사람과 차별되는 자신만의 무기(전문분야)이 필요하다고 강조 합니다. 그래야 나이 50에 개발 할 수 있지 않을까요? ^^

종종 대화하다 인용하고 싶은 딱 그런 정리와 분류입니다. (감탄)

내가 나를 모르는데 난들 너를 알겠느냐~ 인가요 ㅎ
정말 자신의 능력을 확실히 모르니 애매하긴 합니다.

그래도 일단 해본것과 아는것중에는 해본것을 저는 높게 쳐주는 편이랍니다

제가 거짓말쟁이 개발자는 아닌지 한 번 생각해 봤습니다.

말 할 때 항상 주의해야 겠다는 생각이 드는군요

좋은 글 감사합니다 ^^

좋은글 잘 읽었습니다.

"안다"라는 기준이 모든 사람들마다 틀리기 때문에
많이 겪어본 동료라면 그 동료를 거짓말쟁이로 몰기 보다는
자신의 기준으로 적정하게 생각하는것도 한가지 방법이 될 수 있겠다는 생각을 해 봅니다.

사실과 의견, 정보가 섞여있다. 그리고,
잘 모르는 것을 안다고 하는 부분..

주위에서 많이 보기도 하고,
또 혹시 제가 그러지 않았나 반성합니다.^^
좋은 글 감사합니다.

프로그래밍 언어를 학습하고, 개발자의 길을 걷고 있는 사람들의 작은 까페를 운영하고 있는 중에 이 글을 보고 나서 저희도 운영 방침에 약간의 수정사항을 반영하게 되었습니다. 사실과 개인 의견, 중론, 정의는 분명히 다르지만 인터넷 상에 떠도는 수 많은 정보들은 마치 자신이 "정의" 또는 "중론"인 양 내세우는 경우가 많더군요.
전문성을 확보하신 분들에게는 이 같은 정보들의 참/거짓의 판별 능력이 있으시겠지만 아직 그러한 능력이 부족한 초보자에게는 엄청난 덫이 될 수도 있다는 것이 정말 위험하다고 판단이 들더군요.

결국 저희도 정보를 전달하고자 할 경우엔 그것이 "개인의 의견"인지, "사전적 정의"인지, "해당 기술의 개발자가 직접 정의내린 사용법"인지 등등에 관한 분류를 글 틀로 반영하게 되었습니다.

.덧붙임. 항상 좋은 글 올려주시는 것에 진심으로 감사드립니다.

제가 일등인가요? ㅎㅎㅎ
좋은 글 감사합니다.
우리나라에도 Career Path에 신경써주는 회사도 있겠죠??

아직 이 세계에 발을 들인지 얼마 안 됐지만
규현님께서 지적하신대로 개발, 팀장, 관리자
모두 계급화(?) 되어있다는 걸 바로 느끼게 되었습니다.
언제 이런 계급 타파(말이 심했나요?)가 이뤄질지...
글 잘 보고 갑니다. ^^
(물론 갑을병정 간의 관계는 말 할 것도 없겠죠.)

모두들 Career Path가 보장되는 회사가 있다고만 하지,
명확히 제시를 하지는 못 했던 것 같습니다.
뭐 하나씩 나열하는 것도 웃긴 일이지만 혹시나 개인적으로 알고 계신 회사가 있나요?

조언을 얻고 싶습니다.

안타깝긴 하지만 고참개발자에게 관리를 시키는 것이 가장 현실적인 대안이 아닐까 합니다.
고참개발자 본인을 위해서나 "그 관리 전문가"로 뽑혀서 고생할 신참 관리자를 위해서나

프로젝트 진행 중간에 발생할지 모르는 그 수많은 기술적 위험들을 신참 관리자에게 맡기는건 정말 위험한 일이고, 언젠가는 그 관리자가 쓸만한 관리자가 되겠지만 그때까지 얼마나 많은 프로젝트와 개발자의 야근이 인질로 잡혀야 할지 좀 걱정이 되는군요. (훌륭한 외과의사 하나 만들자고 멀쩡한 사람들 여럿잡는 일과 비슷하다고 해야 할지...)

그리고 제가 알기로는 국내의 많은 중소 회사에서 '나이많은 개발자' 뽑기를 선호하지 않습니다. 이유는 그 개발자 면접이나 1차 서류심사를 하는 사람들 중에 그 팀의 '팀장' 이 포함되어 있을 가능성이 높은데, 자기보다 나이많은 사람이 밑으로 들어오면 일 시키기가 껄끄럽다고 생각하기 때문이죠.

전에도 한번 댓글을 달면서 적었던 것 같기도 한데 '고참개발자' 가 될 생각이라면 당연히 자기보다 나이적은 팀장에게 지시받고 일하는 것에 대해 충분히 감당할 준비도 되어있어야 할 테구요...

오히려 고참개발자 or 관리자 로 분류하기 보다는 개발자 or 기술영업 의 형태가 국내사정에 맞지 않을까라는 생각도 해봅니다.

글 잘 읽고 갑니다.

이런 글만 보면 제 꿈이 프로그래머라는 것이 불안하기도... ㅎㅅㅎ

프로그래머의 역할이 기획이나 테스트 등과 명확히 구분이 되지 않은 상태에서 제품 개발에 부족한 모든 부분은 개발자의 몫으로 남아있는 것이 큰 문제입니다. 완전하지 않고 거의 기본 개념이나 현재의 동향 정보에 불과한 상품기획서를 가지고 제품개발을 시작하면서 구멍이 숭숭 뚫린 부분들을 모두 개발을 해 가면서 만듭니다. 개발이 80% ~ 90%이상 완성되면 베타테스트 준비다 필드테스트 준비다, 테스트시나리오 작성, 매뉴얼 작성 등의 몫도 대부분 개발자 몫입니다.
심지어는 만든 제품에 대한 사전 영업을 위한 프레젠테이션 준비나 시연 준비도 대부분 개발자의 몫입니다. 이런 식으로 몇년 돌다 보면 우리나라는 개발자가 개발자가 아닙니다. 자연스럽게 다른 길을 찾아가게 되어 있습니다.