수구대토 -> 수주대토 로 수정해주세요

제 생각엔 스마트폰 초창기(아이폰으로 인해 시장이 커지는)라서
거품에 있고 사람들이 스마트폰에 대한 환상을 가지고 있는 것같습니다.
손바닥만한 화면으로는 분명 한계가 있는데요...
결국 단지 개인의 필요에 따라 몇몇 특정한 기능으로만 사용하게 될거고
꼭 이동시 사용해야하는 사람만 사용할텐데
꼭 만능기기인것처럼 여겨지는 분위기네요.
PMP있지만 돌아다니며 영화보는 사람 별로 없고요
네비있지만 네비들고 다니며 걸어가는 사람 없습니다.
전화기로 엠피스리 들을수있지만
따로 엠피스리를 가지고 다니는 사람들이 대부분이죠.
만능기기는 불편하고 이동기기도 또한 불편하죠.
이동하며 사무를 볼 수있다지만
이동하면서 까지 사무보고 싶은 사람이 몇이나 있겠어요.
오히려 전화기능과 카메라기능을 첨가하고
터치기능을 넣은 OS를 가진 스펙이 강화된
타블렛식으로 LCD를 뒤집을수있는
10인치내의 화면을 가진 노트북이 나오면
스마트폰 시장은 죽을 것같네요.ㅣ

저도 '현혹'의 성격이 짙은 글을 보면 비판적인 시각으로 바라보려 하고 있습니다.
이슈에 대해 여과 하지 않고 우르르 몰렸다, 우르르 파했다~ 하는 것만 봐도 매우 급변하는 IT정세와,불안정한 시국을 그대로 나타내주는 것이니까요. 이런 정세에 본질을 파악하기란 매우 어렵겠지만.. 지금 우리에게 필요한 것은 비판적인 시각이 아닐까 합니다. 예를들어.. 전규현님이 말씀하신 것처럼 요즘 모바일 쪽의 구인란을 보면 모바일 개발 경험이 有인 사람에 국한되어 있더군요. 참 안타까운 일입니다. 매우 좁게 시장이 형성되는 것도 문제이고, 장기적인 안목이 아닌 '언 발에 오줌누기 식'의 인력들만 채용하고 있으니까요. 본질을 따져서 설계와 구조에 중점을 둔다면 당연히 OO나 OOP관련 경험,또는 공학방법론을 사용해봤던 인재 위주로 형성이 되어야 하는 것이 맞다고 봅니다. 그 밑에 코딩할 인재들도 필요한 것이구요.
이 단면에서 돈만 되면 한다는 식의 불안정한 정세를 다시 한번 엿볼 수 있었습니다.
(요즘 스마트폰 애플을 취미삼아 해 보고 있습니다.--단지 취미입니다. 주업은 아니죠. 전에 GUI방식의 소프트웨어를 개발한 경험이 있다면, 예전 방식과 매우 닮아 있다는 것을 느끼고 맙니다.)

팀과 인력조화에 대해서도 한가지 문제점을 제시하자면.. 서로 잘 아는 팀을 만들 수 없는 문화가 한 몫하는 것 같습니다. 회사마다 계약 체제가 다르고 관리제도가 다르니 문화가 다를 수밖에 없고, 하청구조가 이미 뿌리박힌 데다가 같은 회사사람이 누군지도 모른 체 프로젝트가 진행되고 있는 곳도 상당히 많습니다. 어떤 회사는 갑 측에 같은 비용으로 50만 제공해주어도 되지만, 어떤 회사는 같은 비용에 200을 요구하는 곳이 있더군요.

얼마 전에 선임연구원으로 혼자 들어갔었던 프로젝트가 바로 이것과 비슷했습니다. 돈을 더 많이 주니 더 많은 아웃풋을 내야 한다는 묵시적, 강제적 계약조건이더군요. 설계,구조.. 전혀 신경을 안 쓰고 제품의 품질과는 전혀 상관없이 높은 비용(그렇게 높지도 않지만)을 주니 설계 제외하고 더 많은 아웃풋을 내라..라는 SI특유의 병폐를 또 다시 한번 경험했습니다.(아웃풋에 계약조건으로 차등을 주니 사실상 팀웍이란 잠점을 발휘할 수도 없을뿐더러 활용할 수도 없는 문화가 되어버립니다.)

사실 노하우있는 기술자를 쓰는 이유는
소프트웨어가 필요한 곳에 경험과 노하우,설계,구조론,방법론을 오히려 배우기 위한 것으로 생각합니다. 그것이 경험 있는 기술자들을 쓰는 이유가 아닐까 합니다.
5년 차가 10장찍어내고 10년 차가 같은 시간에 20장을 찍어내라는 식이니..원..(이런 곳 정말 많습니다.) 상식적으로 매우 미달인것이죠.

전 지금 병원에 입원해 있는데도.. 규현님의 글은 읽어 봅니다.

스마트 폰이 상당부분 생활을 바꾸긴 하겠지만, 그렇다고 해서 삶을 스마트하게 바꾸어 줄꺼라고 생각하지는 않습니다. 상당 부분 거품도 있고 허세도 있기 때문이죠.

문득 지하철에서 보이는 아이폰 유저들을 보면
"게임", "동영상" 정도 밖에 안보이더군요.
일부 헤비유저일 것으로 예측되는 증권이나 금융 개발쪽 분들이 눈에 띄지 않는 걸지는 모르겠지만
결국에는 PMP + PSP + NDS 를 통합한 그 이상도 그 이하도 아닌 딱 게임기+휴대폰 이라는 느낌이 강합니다.
단지 인터넷이 될뿐이고, 외부에서도 편하게 할수 있을 가능성이 있기 때문에 사용자들이 끌리는거겠죠

솔찍히 말해서 저도 쓸모는 없지만 가지고는 싶습니다.
'필요'하지도 않고 '용도'도 정해지지 않았지만 가지고는 싶습니다.
아마도 이러한 경우에 단지 새로 나온 스마트 폰이고 다들 아이폰 아이폰 하니까 얼리어탑터 기분으로
대세(?)를 따라 나도 스마트하게 스마트폰! 하는게 아닐까 생각이 됩니다.

결론만 말하자면, 지금보다 상당부분 거품이 심하게 끼어있고, 비록 어느정도 삶을 변화 시킬지라도 생각보다 큰 변화를 일으키지는 못할것이라는 겁니다. 원더키디가 나올때까지 10년도 채 안남았고, SF영화에서 그리던 2000년은 차들 대신에 무빙워크 에 서서 다니는 그런 환상적인 세상이었는데 실질적으로 변한 삶의 패턴은 극히 드물듯이 말이죠.

스마트폰에 대해서 갖는 부정적인 시각은, 사용자가 아닌 개발자의 시선에서 바라봐서가 아닌가 싶습니다.
제가 느끼는 스마트폰은 저에게 있어서는 혁명이었습니다.
96년부터 PC통신 하이텔을 통해서 커뮤니티에 입문했는데요, 그 이후로 제 삶속에는 항상 인터넷이 있었습니다.
어딜가도 컴퓨터가 있으면, PC통신에 접속하고, 그 이후에는 인터넷에 접속해서 현재 저의 동호회, 카페, 홈페이지, 블로그 등을 보며 실시간으로 글을 게시하고, 댓글놀이를 즐겨왔는데요, 스마트폰은 이런 소셜 네트워크에 한층 가깝게 다가갈 수 있도록 해주는 중요한 역할을 해주고 있거든요.
인터넷이 연결되어 있지 않았을 때의 불안감이나 답답함을 한번에 해결해주고 있습니다.

집전화가 있고, 공중전화가 있지만, 누구나 휴대폰을 가지고 다니듯이, 요즘 우리 생활에 있어서 인터넷이 그렇게 변하고 있습니다. 스마트폰은 걸어다니는 인터넷 기능때문에 중요한 것이죠.
다만 인터넷 기능이 필요하지 않으신 분들께서, 스마트폰을 필요해서 자발적으로가 아닌 뜬다고 하니까 공부하시려는 분들께서 부정적인 시각으로 말씀해주시는 것 같은데요, 크게... 변화를 줄 것 같아요.

자다가 일어나서 갑자기 말이 많았습니다. 또 놀러올겠습니다. ^^

각서보다는 예전 판례가 있기 때문에 문제가 되는게 아닐려나요?

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

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

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

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

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

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

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

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

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

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

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

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

역시 두가지 다 잘하기는 힘든것 같습니다. 개발에도 많은 공을 들이고 공부도 하고 시행착오도 겪어야 하지만 메니지먼트도 그에 못지 않은 가시밭길이더라구요. 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 = 태아에서부터 만들어지는)이 존재하긴 하지만 이것은 계발을 통해서 바뀝니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

좋은 글 감사합니다 ^^

좋은글 잘 읽었습니다.

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

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

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

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

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

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

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

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

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

조언을 얻고 싶습니다.

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

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

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

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

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

글 잘 읽고 갑니다.

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

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

제가 생각하는 copy&paste의 문제는 이해부족에서 온다고 생각합니다.

체계적으로, 기존에 다른 사람이 작성한 코드를 분석하지 못했기때문에,
(이유는 여러가지가 있겠죠? 실력부족, 문서화안됨, 스파게티코드, 시간부족 등)
기존에 잘 돌던코드는 그대로 두고 플러스 알파만 내가 했다... 뭐 이런거 아닐까요?

또 비슷한 측면에서,
자신이 작업하던 코드의 경우에도, 설계가 세밀하게 진행되지 않은 상태에서,
일단 만들어보면서 얼기설기 작업해나가다 보면,
적절한 타이밍에 리팩토링 시기를 놓쳐버린 상태가 되는 경우가 있습니다.

시간비용 + 귀차니즘 때문에, Copy&Paste로 떡칠이 되기 시작하는 거죠.


마지막으로는 코딩스타일에서 올 수 있겠네요.
현재 제가 주로 작업하는 분야가 C언어를 사용한 임베디드 분야 (wipi등)쪽 인데,
판단문과 분기문이 수도 없이 떡칠되기 시작하면서, 소스가 주렁주렁 ㅎㅎㅎ

state머신이나 적절한(펑션포인터등 사용) 분기체계가 아닌,
switch-case, if-else 등으로 관성이 붙어버리는 거죠.

이상태에서 상용으로 소스는 릴리즈나가고 -_-;;;;;
대형 리팩토링 했다가는(이것도 안습) 되던 소스도 망가지고,
고객사에서는 최대한 손대지 말고 요거 하나만 고쳐달라고 하죠.

저희는 견디다 못해서....
고객사에서 version 2 만들자고 할때, 그쪽 목적은 기능개선, UI개편이었는데,
저희내부에서 아키텍처 부터 다시 잡아서 첨부터 다시 만들었습니다.

후우... 그나마 이제는 좀 살만해졌네요.

며칠전부터, 이 블로그를 처음부터 정주행하고 있는데,
오늘 정주행 완료하고 나니까, 현실적으로 와 닿는 얘기들이 왜이리 많은지요 ㅠㅠ

계속 분발해야겠습니다.

현실적 고민이 뭍어나오는 좋은 글들 감사합니다.

p.s. 3일에 걸쳐 블로그글을 다 읽고 났더니.. 진작에 신경쓸걸 하는 울컥한 마음에, 댓글이 횡설수설 합니다. 양해부탁드립니다.

확실히 와닿네요!! 고객사별로 소스가 따로 노는데 그 소스 통채로 복사해와서 붙여넣고 다른 고객사 나갈 때 커스터마이징한 소스도 그대로 붙어서 나가지요~ 보고 있으면 숨이 꽉꽉 막힙니다~

몇개 부분에서 리팩터링을 해야할 필요성을 느낌에도 불구하고
계속 일에 치여서 다른 부분을 작성하다 보니 주렁주렁 늘어나는 코드를 보면서 눈물만 머금게 되는군요 ㅠ.ㅠ

음.. copy&paste문제는 아마도 설계상의 문제가 가장 크지 않을까 생각이 듭니다.
비슷한 기능이지만 약간의 다른 처리를 요구하는 함수가 발생할 때,
전용 함수로 만들면 간단하게 해결되는데
copy&paste하지 않기 위해서 두가지 기능을 하나로 합치다 보면 범용 함수가 되고
그렇게 되면 상당히 귀찮아 지니 말이죠. 물론 범용 함수가 좋고
여러개의 함수를 합쳐서 하나로 쓰는 것도 좋지만 대부분의 외각체크 루틴들은 거의 copy&paste 식으로
비슷비슷하게 쓰여지는데, 이 부분을 명확하게 처리할 방법이 없는거 같더라구요.

머.. 저의 프로그래밍 실력의 부족이 가장 큰 원인이겠죠 ㅠ.ㅠ

C&P 를 하고 향후에도 계속 C&P 를 하는 것이 과연 '개발자의 잘못' 으로 '해고되어야 마땅한' 일인지는.. 모르겠군요. 개발자 중 C&P 를 좋아서 하는 사람이 있을까요?

C&P 에 대해 이리저리 생각하면..
* 어찌 되었건 회사 입장에선 가장 빨리 답을 냈고 (해당 기능에 대해선 가장 빨리 답을 낼 가능성이 높습니다.)

* C&P 를 한 다음에 부정적 피드백이 바로 날라오는 것도 아닙니다. (CPD 나 simian 같은 것을 회사차원에서 daily test 로 돌리지도 않고) 매일 매일 다음 할 작업으로 로드가 걸린 개발자 입장에선 일종의 시간 벌기가 됩니다. 밑의 돌 빼서 위에 꽂기 같은.

* C&P 를 하는 당시에는 '이건 잠깐이고 언젠가 다시 리팩토링 할꺼야' 라 생각한 뒤, 실제로 리팩토링을 하지 않거나 하지 못하게 될 상황이 바로 닥치게 될 경우가 많습니다. 예전에 어떤 분 말씀처럼 '지금 당장 정리 하지 않으면 지는거다' 라고 강하게 생각하지 않고선 쉽지 않습니다.

* 코드리뷰의 경우 리뷰를 1주일 이내 단위로 자주 하는 것이 아닌 이상 C&P 가 고쳐질 것이라고는 생각치 않습니다. 리뷰의 주기가 길 경우, 이미 리뷰 받고 난 뒤엔 돌이킬 수 없게 되는 경우가 많습니다. 리뷰 중 자주 나오는 말 중 하나가 '이번엔 어쩔 수 없으니.. 다음번엔..' 일겁니다. 소 잃고는 외양간 고치려고 해봤자 고칠 맘은 안생깁니다.

포스팅 잘 읽었습니다. CMMI에서도 요구사항에 대해서 요구사항을 먼저 "개발" 하고 그 다음 레벨이 요구사항 "관리"입니다. 지속적으로 요구사항이 바뀌기 때문이지요. 본문의 내용과 비슷한 맥락이라 허접 답변 남기고 갑니다. ^^

어쩌면 가장 중요한 차이점은,
요구사항이 변경되고 나서 재계산되는 시간, 비용의 차이가 아닐까 생각이 됩니다.
한국에서는 변경되도 마감일이나 비용이 변하지 않으니 말이죠..