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

'개발자'에 해당되는 글 43건

  1. 2018.03.15 SW 개발자의 길, 아니다 싶으면 포기하라!
  2. 2016.05.31 [경영] 당신의 조직은 개발자를 올바르게 관리하고 있는가?
  3. 2016.05.31 [컬럼] 자신을 진화시키고 환경을 만들어내는 개발자
  4. 2016.01.28 이런 IT 회사 가지마라
  5. 2015.01.22 [자기경영] 내가 만든 음식을 먹으며 위로받는 사람들을 보면 나도 위로받고 행복해
  6. 2014.09.23 [자기경영/컬럼] 순진한 개발자가 사내정치에서 살아남는 법
  7. 2014.09.23 [개발/자기경영] "개발자에 필요한건 문제해결 능력"
  8. 2014.09.23 [경영] [컬럼] 대한민국 개발자의 우울, 자기책임론에서 구조개혁론으로
  9. 2014.08.05 [유머] 개발자가 보면 암걸리는 동영상 (The Expert)
  10. 2014.05.19 [개발/컬럼] 프로그래밍, 얼마나 배워야 하나요?
  11. 2014.05.19 [개발] 나는 과연 개발자로서 자질을 갖추고 있는가?
  12. 2014.04.10 [개발/자기경영] 자신을 진화시키고 환경을 만들어내는 개발자
  13. 2014.04.10 [개발] 프로그래머로 살아남는 법
  14. 2013.07.12 [유머] 개발자 이력서 10계명
  15. 2012.08.31 [IT/개발] 개발자와 영업직원의 소통의 시간
  16. 2012.06.19 [IT/개발] 개발자와 영업자
  17. 2012.05.17 [개발/컬럼] 얼마나 배워야 하나요?
  18. 2012.05.06 [개발/컬럼] 개발자가 야근을 하면 회사가 발전할까?
  19. 2012.05.02 [개발/컬럼] 소프트웨어는 누가 개발해야 하는가?
  20. 2012.05.01 [개인] 기획, 설계, 구현, 유지보수를 하는 개발부서 사람들

SW 개발자의 길, 아니다 싶으면 포기하라!




20일 오전에 MS가 주관하는 ‘2007 데브데이’ 행사에 참석했다. IT업계에 종사하는 사람이라면, 아마도 한번쯤은 MS의 독점성과 라이선스 정책 등에 대해 불만을 품어봤을 만하다. 그럼에도 불구하고 SW 개발자들의, MS에 대한, 관심은 어느 행사보다 뜨거움을 느낄 수 있었다.

기자는 오전 행사 중 한국MS의 최고기술임원인 김명호 박사(혹은 이사, 왠지 모르지만 박사라는 호칭이 더 어울린다)의 기조연설만 듣고 나서 김박사와의 짧은 인터뷰를 진행할 수 있었다. 그는 기조연설과 인터뷰를 통해 ‘한국에서 SW 개발자가 가야 할 길’에 대해 <희망차고도 암울한> 사회적 딜레마를 이야기해 주었다.

아래의 글은 김명호 박사를 통해 들을 이야기를 바탕으로 작성해 보았다.

[明, SW 개발자여 전문인으로 거듭나자!]
ZDNet Korea의 컬럼니스트 중 한명인 류한석 소장은 얼마 전 자신의 컬럼에 ‘한국에서 SW 개발자가 성공하지 못하는 세가지 이유’를 통해 어려운 사회적 현실을 이야기 했다. 그러한 이유가 아니더라도, SW 개발자로 성공한다는 것 자체는 다른 어떠한 직업과 견주어도 결코 쉬운 것만은 아닐 것이다.

한국 자바 개발자의 1세대라 할 수 있는 김명호 박사 역시 개발자 출신으로 성공의 길을 걷고 있다고 할 수 있지만 “이 길이 아니다 싶으면 차라리 다른 일을 하라”는 말을 서슴지 않고 내던지고 있다. 요즘 시대에 개발자는 한국이라는 좁은 시장에서가 아니라 전세계적으로 통할 수 있는 전문성을 가져야 하는데, 이를 달성하는 것은 결코 쉬운 일이 아니기 때문이다.

SW 개발자로 성공하려면, 단기간 학원 교육을 통해, 누구나 습득할 수 있는 주류 기술 몇 가지만 배워서는 안 된다. 코딩, 테스트, 디버깅, 이식, 성능, 설계, 스타일 등 다양한 소양을 갖춘 전문인이 진정한 개발자라고 할 수 있다. 단순히 코딩만을 할 줄 안다고 해서 전문인으로써의 ‘정신과 혼’을 담지 않고 있다면 ‘하급 노동자’에 지나지 않는다는 것이다.

개발자와 아키텍트는 다르다
한국의 개발자들은 마치 개발자가 아키텍트로 가는 중간 단계로, 한번쯤 거쳐야 할 과정쯤으로 여기는 경향이 있다. 그러나 아키텍트와 개발자는 엄연히 다른 직업이다. 아키텍트가 되기 위해 개발자 경험이 있는 것은 좋지만, 막연하게 개발자를 거쳐 아키텍트가 된다고 생각하는 것은 옳지 않다는 것이 김박사의 설명이다.

그는 “아키텍트가 될 자질을 갖추는 것은 개인의 소양에 따라 다르다. 이를 건설에 비유하자면, 개발자는 건설현장에서 일하는 인부고 아키텍트는 건축설계사라고 볼 수 있다. 미적, 공학적인 요소를 갖추었을 때 건축설계사가 되는 것처럼, 현장 인부가 자신의 경력을 통해서만 될 수는 없는 것이다”라며 “대신 그들은 미장이나 도색 전문가 혹은 작업반장이 될 수 있다. 즉, 해달 분야의 전문가로 훌륭히 성공할 수 있는 것이다”라고 말했다.

그렇다고 벽돌을 나르는 수준의 초급 개발자가 10년 후 작업반장 수준의 상급 개발자가 되는 것은 아니다. 먹고 살기 위해서 개발을 한다면 행복해 질 수 없을 테고, 당연히 훌륭한 개발자가 될 수도 없다. 때문에 개발자들이 당면한 과제는 어떻게 하면 훌륭한 개발자가 될 수 있냐는 올바른 방법론이 필요하다.

이에 대해 김명호 박사는 몇 가지 지침을 가르쳐 준다.

훌륭한 개발자가 되려면?
1) 기본에 충실해야 한다.
여기서 말하는 기본과 초급은 분명 다르다. 개발자라면 알고 있어야 할 프로그래밍의 기본 구조나 알고리즘 등의 기본에 충실하지 못하다면, 10년이 지나도 불행하기는 마찬가지일 것이다. 만약 개발자인 당신이 먹고 살기에 급급해서 수박 겉핥기로 몇몇 기술만 습득했다면 지금이라도 당장 시작하는 것이 중요하다. ‘언젠가는 적용해야 할 핵심기술’을 습득하는 것이 중요하다.

2) 지식의 포트폴리오를 유지하라.
재테크에서의 교훈에 따라 ‘달걀을 한 바구니에 담지 마라’는 것을 생각하자. 즉, 개발자는 어느 한 분야에 올인하지 말고 ‘남들도 다 아는’ 주류 기술과 ‘남들은 모르는’ 전문 기술로 분산 투자해야 한다는 것이다.

3) 분야 전문가나 해박한 지식을 갖춰라.
앞서 언급한 대로 건설현장에서 미장이나 도색 전문가, 작업반장이 될 수 있는 분야별 전문가가 된다면 어디서든 존중 받을 수 있다. 그러나 여기서 중요한 것은 과도한 욕심을 부려서는 안 된다는 것이다. 분야의 전문가인 동시에 해박한 지식을 갖추고 있다면 그야말로 ‘천재’라고 할 수 있지만, 이 둘 중 한가지만 갖춰도 충분하다는 것이다. 모든 분야에 대해 피상적인 지식만을 갖추고 있다거나, 사장된 기술에 매달린다거나, 자아도취에 빠져 자신만의 방법이 옳다고 여기는 오류를 범할 수 있기 때문이다.

4) 학습을 두려워 마라.
이것이 김박사가 가장 강조하는 부분으로, 충분한 기본지식을 갖추고 있다면 새로운 지식을 습득하는 것에 두려움이 없으며 새로운 기술을 습득하고 끊임없이 발전해 나가는 것이야 말로 행복한 개발자가 되는 최우선 요소다. 만약 새로운 기술을 습득하는데 더디다고 느낀다면 그것은 기본이 부족하기 때문이며, 지금이라도 기본을 습득해 나간다면 신기술 습득에 대한 두려움은 사라진다.

이러한 개발자를 위한 성공 방법론이 제시됐음에도 불구하고, 개발자가 선택할 수 있는 최악의 길은 ‘다른 길을 찾아가는 것’이다. 개발자가 뭐 그리 대단한 것인가? SW 개발자가 아니더라도 얼마든지 다른 분야에서 전문인이 될 수는 있는 것이다. 자신이 택했지만 SW 개발자로의 미래가 안 보인다고 생각된다면, 과감히 다른 길을 선택하라.

개발자야 말로 ‘파레토의 80대 20의 법칙’이 가장 확실하게 적용되는 분야다. 20%의 능력 있는 개발자만이 훌륭하게 80%의 개발을 수행할 수 있다.

[暗, 과연 한국에서 SW 개발자가 성공할 수 있나?>
김명호 박사는 SW산업에서 이러한 파레토의 법칙이 중요하다고 말한다. 뛰어난 소수의 전문인력이 SW산업을 발전시킬 수 있고, 이러한 인재를 정책적인 지원 하에 키워내야 한다는 것이다.

그러나 현실은 그다지 밝지 않아 보인다. 정부의 정책이라는 것이 ‘노동정책’에 가깝기 때문이다. 즉, 대학과 같은 전문교육기관에 의한 전문가를 양성한다기 보다 실업자를 줄이기 위해 하급 개발자를 배출해 내는데 급급하고 있다는 지적이다.

막상 현재 대학의 교육 현실은 어떠한가? 학부제를 도입한 이후, 학생들은 어려운 과목은 제외하고 쉽거나 학점을 잘 받을 수 있는 과목을 수강할 수 있게 된 상태다. 숙명여대 전산관련 학과의 한 교수는 “요즘 학생들은 알고리즘과 같이 기본을 다질 수 있는 과목은 어렵다고 회피한다. 그저 취업을 위한 학점 챙기기나 가벼운 프로그래밍 기술에 몰린다”고 안타까워한다.

이럴 바에는, 오히려 비전공자가 낫다는 의견도 있다. 기본에 충실하지 않은 전공자들보다 학원에서 5~6개월 집중적으로 배우고, 취직해서 급여를 받는 이들이 더욱 충실도가 높고 급여도 적게 든다는 것에 SI업체들이 매력을 느낄 수도 있다는 것이다.

실패 거듭하는 ‘SW 정책’
실제 이렇게 부실한(기본에 충실하지 못하다는 의미로, 이들이 모두 부실하다는 것은 아니다) 개발자들을 고용한 SI업체를 통해 프로젝트가 실패한 경우, 그 책임소재의 표적은 SI가 아닌 HW로 돌리는 경향이 있기도 하다. 어떻게 보면 이것이 ‘SW 분리발주 정책’을 창출한 계기 중 하나이며, 개발자의 ‘표준공임단가’를 책정하게 된 이유가 될 것이다.

특히 개발자에 대해 표준공임단가를 두어 금전적 보상에 제한을 두어서는 안 된다. 이는 능력 있는 전문가가 되고자 하는 이들의 의지를 꺾을 수 있기 때문이다. 핀란드의 한 대학에서 내놓은 조사자료에 의하면 ‘SW 개발생산성에 있어 훌륭한 개발자 1명의 개발생산성이 하급 개발자에 비해 20배 가량 높다’는 결과가 있다. 이는 급여 측면에서 볼 때에도 그 이상의 가치가 있는 것이다.

현재 정부의 실업정책에 가까운 SW 정책은 이러한 측면에서 많이 부족하다는 지적이다. 즉, 표준공임단가에 묶여 있기 때문에 국내에서는 아무리 뛰어나다고 해도 인정받지 못하는 토양이 굳어져 가고 있으며, 이는 마찬가지로 기업 내부에서도 개발자에게 인색할 수 밖에 없다.

또한 전문인을 양성하기 위해 수년의 기간이 필요하지만, 단기간 성과를 내야만 하는 국내의 프로젝트 특성도 개발자를 힘들게 하는 악순환에 한 몫 거들고 있다.

소수의 전문인 중심 체계 필요
김명호 박사는 “정책적으로 획기적인 변화가 있어야 한다. 노동집약적 산업이 아닌 지식집약적 산업으로 바꾸기 위한 정책이 필요하다. 물론 교육도 마찬가지다. 전산 관련 대학 정원을 줄여서 의욕이 있는 전문가를 양성해 내고 이들을 대상으로 SW정책을 만들어 가야 할 것이다”라고 말했다.

그는 또 “16만 명에 달하는 국내 개발자들 모두에게는 미안한 말이지만, 누구나 다 성공할 수는 없다. 끊임없이 노력할 수 있고 자기를 발전시킬 수 있는 소수 개발자들만이 성공할 수 있으며, SW 정책도 이들에게 마음 놓고 일할 수 있는 환경을 만들어 주는 산업으로 만들어야 정부차원의 ‘미래의 먹거리’ 산업으로 성장할 수 있을 것이다”라고 주장했다.
Posted by SB패밀리

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

류한석(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 컬럼니스트)   2007/12/10

 

지난 컬럼에서 살펴본 개발자 관리의 문제점 및 좋은 관리 지침에 대해 독자들의 많은 피드백이 있었다. 그만큼 관리가 제대로 되고 있지 않다는 실증일 것이다. 올바른 관리의 밸런스를 갖추는 것은 쉽지 않다. 통제에 집착한 나머지 '관리를 위한 관리'를 하게 되거나, 리소스 부족 또는 자율에 집착한 나머지 방임을 하게 되는 경우가 많기 때문이다.

또한 이러한 잘못된 관리의 근원적인 문제는 곧 시스템의 문제라고 볼 수 있다. 단지 관리자 개인의 철학과 도덕성만으로는 어쩔 수 없는 조직문화, 그리고 조직의 프로세스로부터 엄청난 영향을 받기 때문이다. 사실, 조직문화와 시스템의 문제는 일개 개인이 어떻게 할 수가 없다. 시스템에 반발하면 퇴출당하거나 스스로 나가야 할 뿐이다.

이에 대해서는 필자 스스로 여러 기업들을 전전하면서 가슴 절절하게 느낀 부분이다. 그러므로 관리자들은 조직문화에 맞추어서 그리고 시스템을 위배하지 않는 가운데에서 자신의 관리 철학을 구현하려고 노력해야 할 것이다. 이것이 관리자를 위한 애정 어린 조언이다.

시스템을 바꿀 수 없다면 자신을 바꿔라
그렇다면 개발자 개개인은 어떻게 해야 할까? 많은 개발자들이 사회 환경과 조직 시스템에 대해 불만이 많다. 하지만 자신이 권한이 없다면, 사회와 조직은 바꿀 수 없다. 그것에 반발심을 가진 채로 자신에게 맞는 노력을 하지 않는다면, 마치 사춘기 소년이 트라우마를 안겨준 부모에게 반항한 나머지 자신의 인생을 망가뜨리는 것처럼 개발자 자신의 삶도 망가질 뿐이다.

조직은 개발자의 경력관리를 해주지 않는다. 이점은 불변의 진리이다. 정말 잘못된 일이지만, 현실을 보면 많은 회사들이 직원을 "달면 삼키고 쓰면 뱉는 일"이 빈번하다. 그러니 사람들이 생존의 욕구에 집착한 나머지 자아실현은 엄두도 내지 못하고 있는 것이 아닐까? 생존조차 쉽지 않은 것이 이 사회의 현실이다. 더군다나 개발자 직종에 몸담고 있다면 삭막한 현실은 몇 배 더 증가한다.

사회에서 성공한 선배 개발자(그 성공의 기준이 돈이든 명예든 자아실현이든)를 찾아보기가 참으로 힘들다. 물론 그것의 가장 큰 이유는 바로 업계 풍토 때문인데, 그것에 대해서는 이미 두 차례에 걸쳐서 컬럼을 쓴 바 있다. 업계 풍토는 서서히 변하거나 변하지 않는다. 개발자 개인이 바꿀 수 있는 것은 단기적으로는 단지 자기 자신뿐이다. 그렇다면 개발자 개인이 갖추어야 할 주요 역량에는 어떤 것들이 있는지 살펴보자.

개발자 개인이 갖추어야 할 주요 역량

첫째, 주변 상황과 인간의 역학관계를 이해하고 교류하는 커뮤니케이션 스킬이다. 많은 개발자들에게 있어 가장 부족한 역량이 바로 이것이다. 혹자는 이렇게 말한다. 개발자들은 그 특성상 커뮤니케이션 스킬이 부족할 수밖에 없고, 외국에서는 그것을 인정해주는데 한국에서는 왜 그렇지 않냐고. 실제로 소프트웨어 강국들을 보면, 개발자들에게 개발에만 집중할 수 있는 환경을 제공해주며 멀티플레이어 역할을 원하지 않는다. 하지만 한국은 소프트웨어 강국이 아니다! 또한 아무리 개발자를 대우하는 외국에서도 성공하는 개발자들은 커뮤니케이션 스킬이 뛰어난 사람들인 경우가 많다.

이 점을 간과해서는 안될 것이다. 커뮤니케이션 스킬은 개발자가 노력해서 갖추어야 하는 것이며 그것을 폄하해서는 안 된다. 개발자들과 함께 일해본 기획자들은 개발자들의 커뮤니케이션 문제점에 대해 지적하는 경우가 많다. 그들은 개발자들의 커뮤니케이션 태도가 닫혀있고, 어려운 용어를 남발하며, 대세에 영향을 미치지 않는 사소한 문제에 집착하고, 타인의 요구에 대해 관심을 가지지 않는다고 필자에게 하소연하곤 한다. 개발자 출신인 필자가 보기에도 그런 개발자들이 많다는 것을 인정하지 않을 수 없다.

물론 그러한 캐릭터가 바로 개발자이다. 그렇기 때문에 하루 종일 모니터를 바라보며 코딩의 세계에 빠져있을 수 있는 것이다. 하지만 만일 고도의 집중력를 발휘할 수 있는 캐릭터의 특성을 유지하면서 또한 타인과의 커뮤니케이션 스킬에 있어 조금의 향상이라도 가져온다면, 더욱 더 개발을 잘 할 수 있는 환경을 얻게 될 것이다. 즉 코딩을 더 잘하기 위해 커뮤니케이션 스킬이 필요한 것이다. 좋은 커뮤니케이션 스킬은 좋은 환경을 만들어 준다. 만일 데일 카네기의 책 한 권 읽어본 적이 없다면 지금 당장 인터넷 서점에서 구매하기 바란다.

둘째, 기술향상과 인간수양을 위한 자기계발이다. 자기계발이란 조직이 책임져주는 것이 아니다. 다시 한번 말하지만 조직은 경력관리를 해주지 않으며 자기계발을 시켜주지도 않는다. 회사가 시켜주는 교육은 단지 회사 업무를 위한 것일 뿐이다. 그것마저도 직원들이 함께 받는 경우가 대부분이라서 경쟁력 향상에 별로 도움이 되지 않는다.

자기계발은 여유 있을 때 행하는 것이 아니다. 실제로 인간이라는 존재는 한없이 여유로운 동물이라서, 시간이 많으면 더 게을러질 뿐이다. 그러므로 자기계발은 시간이 없을 때 짬을 내서 하는 것이라고 생각하는 것이 좋다. 그리고 자기계발에는 두 가지 측면이 있다. 하나는 개발자로서 기술적인 측면의 자기계발이고, 또 다른 하나는 인간으로서 인간수양 측면의 자기계발이다.

신기술 습득에 대해서는 다 아는 부분이니 따로 얘기하지 않겠다. 인간수양은 흔히 간과되지만 몹시 중요한 부분이다. 태어난 그 자체의 결함 가득한 성격 그대로 산다면 동일한 실수와 실패를 반복하게 될 뿐이다. 인간으로서의 멋진 점은 자신을 계속 가다듬으면서 조금이라도 완성된 인간을 지향하는데 있다. 다양한 책을 읽고, 가보지 않은 곳을 가고, 많은 사람들을 만나야 한다. 만일 이것을 해낸다면 인생의 도를 깨우친 멋진 개발자가 될 수 있을 것이다.

셋째, 작은 성공을 통해 큰 성공을 얻을 수 있도록 끊임없는 변화하고 실행해야 한다. 주변 상황과 인간을 입체적으로 이해하고 교류하면서, 기술과 인간적 소양의 자기계발을 하다 보면, 어느 순간 기회가 온다! 이것은 정말 준비된 사람에게만 주어지는 선물과도 같다. 하지만 준비되지 않은 사람에게는 기회 자체가 주어지지 않거나 또는 기회가 왔다고 하더라도 그 자신이 눈치챌 수 없다.

우리 스스로 저주를 받을 것인지 축복을 받을 것인지 선택할 수 있는 것이다. 그렇다. 어떤 측면에서 인생은 충분히 콘트롤 할 수 있다. 자신을 진화시키다 보면, 우리 자신이 이 사회에 변화를 줄 수 있는 주체라는 것을 깨닫게 되고 실제로 변화를 행할 수 있는 기회를 얻게 되는 것이다. 그러한 기회를 얻기 위해서는 끊임없이 변화하고 실행해야 한다. 자기 자신에게 다가오는 모든 기회를 수용하며 그 결과를 확인해야 한다. 불안감과 두려움 따위로 인해 좋은 기회를 포기해서는 안 된다.

자신에게 좀 벅차다고 생각하는 바로 그것을 떠맡아야 한다. 그 일을 하게 되면 그 일을 하기 전에 자신이 생각했던 그 모든 게 바보 같았다는 것을 깨닫게 된다. 그리고 이미 사람이 달라지고 있는 것을 발견하게 된다. 결국 그 일을 끝마쳤을 때는 모든 것이 변해있다. 작은 성공사례를 반복하고 반복하면서 더 큰 성공사례를 향해 다가가는 것이다. 그러니 신기술 구현이든, 새로운 프로젝트를 떠맡는 것이든, 자격증 도전이든, 커뮤니티 창설이든, 이직이든, 대학원 진학이든, 외국 취업이든 두려워하지 말고 실행하기를 바란다. 실행하면 모든 것이 달라진다.

환경, 조직, 사람간의 역학관계를 이해하고 미래를 준비하는 개발자

유능한 개발자는 기술력이 뛰어날 뿐만 아니라, 자신이 해야 할 일을 둘러싼 기술적/정치적 환경을 입체적으로 이해하고 교류하며, 자신
에게 요구될 역량을 미리 갖추고 있으며, 적절한 시점에 곧바로 행동에 옮길 수 있는 실행력을 갖춘 사람이다.

왜 개발자가 이렇듯 기술 외적인 부분에 대해 신경을 써야 할까? 이런 필자의 논리에 대해 불편한 감점을 느끼는 개발자도 있을 것이다. 충분히 이해하고 있다. 그러므로 좀 더 부연설명을 해보겠다.

만일 현재 자신이 처한 환경이 돈, 명예, 자아실현의 관점에서 자신의 원하는 만큼 만족스럽다면 필자가 제시한 이러한 역량들에 대해 신경 쓰지 않아도 좋다. 그런 분들한테는 여기까지 글을 읽게 해서 죄송할 따름이다. 하지만 자신이 처한 환경이 만족스럽지 않다면 그것이 커뮤니케이션 스킬과 자기계발, 실행력이 부족하기 때문은 아닌지 생각해 보기 바란다.

필자가 언급한 역량들은 사실 개발자뿐만 아니라 이 사회의 모든 개인이 갖추어야 할 역량이라고 볼 수 있다. 하지만 잘못된 업계 풍토로 인해 어려움에 처해있는 개발자들에게 있어 특히 부족하면서도 더욱 요구되고 있는 역량이라고 볼 수 있다. 이러한 역량들이 가져다 주는 놀라운 결과들을 간과하지 않았으면 좋겠다.

환경을 바꿀 수 없으면, 자기 자신을 진화시키고 결국 환경을 만들어 내야 한다. 그러지 못한다면 잘못된 업계 풍토로 인한 희생양이 될 뿐이다. 이 사회에 대한 올바른 이해와 방향 감각을 갖추고 있으면서, 부단히 노력하며 진화를 꿈꾸는 개발자의 앞날에 커다란 행운을 기원한다. @
 


Posted by SB패밀리

쌈꼬쪼려 소백촌닭
출처 : 인터넷




[IT/컬럼] 이런 IT 회사 가지마라

그냥 주관적인 글입니다.
이런 생각도 있으니 참고 하세요.

1. 직원들 얼굴이 어두운 회사

더이상 말이 필요없다.
직원들 얼굴이 현재진행상황을 알려준다.


2. 우수인재 확보 X

쓸만한 인재인데도 기존의 임금수준과 직급을 들먹이며 빈둥빈둥 시간을 끈다.
결국엔 갓 대학 졸업한 싸구려 인력만 뽑는 회사다.

좋은 인재를 찾으려는 노력자체를 하지않는 회사다.
이런 회사는 인재을 코딩하는 소모품으로 정도밖에 생각하지 않는다.
본인도 소모품으로 취급될 것이다. 빨리 나와라.


3. 테스트 기간 없는 회사

겁나게 큰 프로젝트인데도 테스트 기간을 전혀 잡지 않는 회사
이론상 제작 기간의 2배를 테스트 기간으로 잡아야 정상이다.

하지만 우리나라 특성상 -_-; 
대부분 열악한 기업들이 그리 길게 잡지 못한다.
3명이상 플젝이면 최소 최소 최소 아주 작게 잡아도 1주이상 잡아야 한다.
1주일이면 정말 미니멈이다. 
설계자가 1주일도 테스트 기간을 잡지 않는다면 
내일부터 출근하지 마라.
각종 버그에 고객 요구사항에 뒤처리만 하느라 두배로 기간이 늘어난 프로젝트에 빠져 허우적 댈것이다.


4. 월급이 안나오는 회사

IT기업은 지금도 수많은 회사들이 창업하고 망한다.
인권비는 IT계열에서 수익을 얻기위한 가장 기본적인 유지비용이다.
직원들 월급도 못줄 정도라면 정말 회사 사정이 어려워 진거다.
월급이 한달이라도 밀린다면 사정없이 그만둬라.
프로젝트 진행중이라도 상관 없다!!! 무조건 나와라!!

그리고 그만둘때는 다른일을 핑계대고 
그일만 아니라면 무보수로 몇개월씩 있을수 있다고 강조하며
회사가 어려우니 한달 보수 정도는 포기하면서
도의적 책임을 다하고
(플젝 진행중일테니 한달동안은 무보수로 반드시 도의적 책임을 다해라~! 꼭 명심해라!! 법정에서 유리하다. -_-;; )
사장과 기분좋게 끝내라.

직원들 월급도 못주는 IT기업이 회생할 가능성은 정말 낮다.
차라리 로또를 사라. 그게 확률이 높다.
괜히 인간관계 생각해서 몇개월 무보수로 더 일하면 좋은 꼴 절대 못본다.
사람은 돈이 관계되면 정말 치사해 진다.
특히 장사를 하는 사람은 정말 그렇다.
간이고 쓸개고 다 빼줄듯 하다가 회사 망해서 돈이 없으면 싹 돌아설 것이다.
밀린월급 받으려고 소송들이대고 합의보고 하다보면
잘 해봐야 몇개월 밀린 금액의 반정도로 합의 볼 것이다.
그동안 사장이랑 싸우고 맘고생하고..... 손해가 막심하다.


ps. 참고로 회사 이전은 왠만하면 재직중에 알아봐라
백수로 있으면 마음이 다급해져서 아무회사나 들어가는 경우가 많다.
또한, 보통 회사는 백수로 있는 인재보다는 재직중에 있는 인재를 좋아한다.

어디에선가 '쓸모'있는 인재라는 보장이 있기 때문이다.
(다른 회사에서 일 잘한 인재는 여기서도 일 잘할거야~~)


5. PM이 의사결정을 하지 않는 회사

의사결정을 다른이에게 맡기는 사람은 차라리 낫다.

그런 결정 조차도 하지 않는 PM이다.(지가 못하면 갑한테 물어보든가~ -_-; )

원인은 육안으로 잘 보이지 않지만 
증상으로 쉽게 진단할수 있다.

여러분이 똑같은 프로그램을 대여섯번 새로 만든다면 
확실이 이런 타입의 PM이다.
PM이 의사결정을 확실히 하지 않아 이렇게 짯다가 뒤엎고 저렇게 짯다가 뒤엎는다.
일하는건 문제가 아니다.
의사결정을 하지 않는 PM은 
나중에 플젝이 아작 났을때 책임이 없다.
심지어는 책임을 회피하려고 의사결정을 하지 않는 케이스도 있다.
IT쪽에서 일 존내 마니 하다 보면
플젝이 진흙탕에서 허우적 대다가 정말로 아작 나는 경우도 있다.


근데 이런 PM은 아작나도 책임이 별로 없다.

지가 책임질 부분이 적기 때문이다.

아작 났을때 PM을 제외한 하위 직원들이 아~주 난해하다.

조만간 직원들이 임무 %별로 PM보다 많이 프로젝트 보상금을 물고있는 자신을 보게 될것이다.
(돈 벌러 회사 들어가서 꼴아박고 나오는 케이스.)


6. 유지보수는 10분이면 된다는 회사

아마 만줄 코딩하고 허리한번 피게 될거다.

'고생'외에는 별 단점은 없지만
개인적으로 싫어한다.
나도 인간이다. 
어떻게 주7일동안 일만할수 있는가.

여자친구랑 놀시간도 필요하고 
주말에 인라인도 타야되고 사진도 찍어야 한다.
특별히 프로젝트 마무리단계도 아닌데 평상시에도 
주말보장 안해주는 회사는 개인적으로 '즐'이다.


지금도 수많은 열악한 IT회사들이 있습니다.
이상하게도 이바닥은 소프트웨어산업이 
'무'에서 '유'를 창조하는 줄 알고있는 무식한 사람들이 세운 
열악한 회사가 엄청 많습니다.
IT도 분명히 투자금액이 있습니다.
인권비며 사무실 비용이며 엄청나게 돈이 들어갑니다.
그래도 아직 사회적 인식은 소프트웨어는 공짠줄 알죠 -_-;


그래 그런 멍청한 자들이 지돈 존내 꼴아박고 남의 월급도 못주고
남의 경력 걸레로 만드는 겁니다.

물론 좋은 회사면 오래 있어야 합니다.
그래야 근무년수도 늘고 연봉에도 이익이 많쵸.

그래서 글을 끄적여서 올려봅니다.
이곳 저곳 옮기면서 6개월짜리 경력 5개 가지고 3년 채우면
여러분 IT 경력은 정말 걸레가 되는 겁니다.

그걸 막기 위해
어떤 회사가 좋은건지
어떤 회사가 나쁜건지
어떤 회사에 오래 있어야 되는지



여러분 판단에 조금이라도 도움이 될까 개인적인 생각을 끄적여 봤습니다.

위 글은 저자의 동의 없이 함부로 퍼가셔도 됩니다. -_-)v


2011년에 적은 글이넹.... 

Posted by SB패밀리

소프트웨어 개발자인 내가 하고 싶은 이야기가 있다.


소위 개발자들과 이야기를 해보면 그들은 왜 개발을 하고 있는지 모르고 있는 경우가 허다하다.


내가 수십만원을 들여서 자동차 수리를 맡기고 자동차를 돌려받았다.

그런데, 비용은 지급했는데 자동차 수리가 안되었다면 

이 결과를 당연하게 받아들일까?


개발자들이 마감일이 되었는데도 개발을 하는둥 마는둥 끝내버리고 일찍퇴근해 버리는 

그런 정신이라면 개발하지 마라고 하겠다. 아니, 고객에게 댓가를 받고 일하지 마라고 하고 싶다.


내가 무언가를 만들거나 서비스를 하고 있다면 그 목적이 무엇인지... 6하원칙으로 생각해보고 일하기를 권하고 싶다.






아메리칸 셰프 좋은대사


푸드트럭에서, 팬에 지진 쿠바샌드위치 빵이 탄걸 보고,


칼캐스퍼 : 뭐야? 이거 탔잖아~! NO~ 이건 버려야해!

퍼지(캐스퍼의 10살짜리 아들) ; 어차피 저 아저씨들한테 공짜로 주는건데 그냥 주면 뭐 어때서요?

(푸드트럭에서 나와서)

칼캐스퍼 : 넌 이 일이 재미있니?

퍼지 ; (고개 끄덕끄덕)


칼캐스퍼 ; 퍼지. 난 이 일을 사랑해.

잘 들어. 난 잘 하는게 별로없어. 모든게 서툴고... 네 얘기도 잘 못들어주고 말이야.

하지만, 난 음식을 잘 만들어.

내가 만든 음식을 먹으며 위로받는 사람들을 보면 나도 위로받고 행복해.


퍼지 : 네. 셰프.


칼캐스퍼 : 좋아.!  :)


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패밀리



'SW 마에스트로' 연수생 구글 본사 방문… 선배들과 간담회

2011년 01월 07일

"좋은 소프트웨어(SW) 개발자의 조건은 명문대 졸업여부가 아니라 창의력과 문제에 접근하고 해결하는 능력이다.", "초가집을 수 백 채 지어봤다고 63빌딩을 건설할 수 없다. SW 개발도 우선 역량을 크게 키워야 한다."

실리콘밸리를 방문한 한국의 SW 꿈나무들에게 미국 구글 본사에서 근무하고 있는 한국인 SW 엔지니어들은 창의력을 바탕으로 더 높은 곳으로 비상해야한다고 조언했다.

5일(현지시간) 지식경제부, 정보통신산업진흥원, 한국정보산업연합회 등이 주관하는 SW 마에스트로 미국 연수의 일환으로 구글을 방문한 학생들은 직원들의 언제든 즐길 수 있는 게임기와 카페테리아 등 자유로운 업무환경을 돌아봤다. 이어진 구글 본사에서 근무하고 있는 한국인 SW엔지니어들과의 간담회에서는 선배들의 조언이 쏟아졌다.

SW엔지니어인 전지운 씨는 "코딩과 프로그래밍 능력은 물론 창의력과 문제에 접근하고 해결하는 능력이 중요하기 때문에 미국에서는 SW 개발자를 뽑는데 창의력과 문제 해결 능력 등에 중점을 두고 평가한다"며 "알고리즘과 자료구조 등이 중요한데 책만 본다고 이런 능력이 생기는 것이 아니므로 프로젝트를 하면서 문제 해결 능력을 배양해야 한다"고 말했다.

김용성씨는 "초가집을 수 백 채 지어봤다고 63빌딩을 지을 수 있는 것이 아닌 것처럼 SW 도 SW를 잘 개발하는 역량이 있는 기업에서 배워야 한다"며 "SW 마에스트로 과정을 통해 큰 프로젝트들을 진행해 보는 것도 도움이 될 것"이라고 조언했다.

SW 마에스트로 연수단 학생들은 구글의 SW 개발 여건에 많은 관심을 나타냈다.

이에 대해 김용성 구글 SW엔지니어는 "미국과 한국의 SW 개발 환경의 차이는 관리 대상이 다르다는 것"이라고 설명하고 "한국에서는 SW를 개발할 때 사람을 대상으로 관리하는데 구글 등 미국에서는 일의 성과를 중심으로 관리한다는 점이 다르다"고 말했다. 또 "구글 등 미국 기업들의 자율적인 SW 개발 환경에 대해 동경하는 이야기가 많은데 실제 일의 강도와 업무는 한국보다 더 높다"며 "이는 업무를 믿고 맡겨서 밀어주는 환경이 업무 집중도를 높여주기 때문"이라고 설명했다.

한국인 구글 SW엔지니어들은 후배 개발자들에게 문제 해결 능력을 배양하는 것이 중요하다고 입을 모아 말하고 시야를 넓게 갖고 큰 꿈을 가지라고 충고했다

출처 : http://www.dt.co.kr/contents.html?article_no=2011010702010660739004




실제로 사회에서 개발자로 직장을 다닌다는건 .. 학생 때와는 다르게 프로다운 마음가짐이 필요합니다.
신입일 때는 내가 못하면 위에서 봐주면서 대신 처리해주지만 갈수록 책임감이 늘어갑니다.
즉, 문제가 주어졌을 때 해결해야한다는 것이죠. 차선책이라도 꼭 만들어야 한다는 겁니다.
가정의 가장일 경우도... 책임감은 날로 늘어가면서 가정을 지키기 위해서는 문제가 있을 때마다 해결해야한다는
압박감이 큽니다. 개발자이건 아니건 문제해결능력이라는건 그사람의 역량과도 직결되는 문제이니 간과해서는 안됩니다.


Posted by SB패밀리



대한민국 개발자의 우울, 자기책임론에서 구조개혁론으로




김국현(IT평론가)   2007/10/01

 

2007년 우리네 개발자의 자화상은 유난히 수척하고 우울하다. 연이어 터져 나오는 개발자 처우에 대한 보도와 칼럼들은 IT를 이공계 기피의 공식 상징으로 만들어 버렸다. 이런…… 별로 낭만적이지 않다. 

어느덧 개발자의 후생(厚生)은 나의 최우선 관심사가 되어 버렸다. 

우리는 누구나 자기가 좋아하는 일을 하는 삶을 꿈꾸고, 또 그 일이 사회에 가져다 주는 가치에 걸맞은 대가를 받기를 바란다. 낭만적 인생의 얼개란 의외로 단순하다. 그렇다면 개발자들은 적어도 자기가 좋아하는 일이 무언지 안다는 면에서는 행복한 이들이다. '알고리즘의 오르가즘', 즉 내 논리가 증명될 때의 기쁨에 끌려 이 바닥에 들어 왔기 때문이다. 허나 이 '손맛' 누구나 맛볼 수는 있지만, 그 대가는 천차만별이다. 스톡옵션과 인센티브 덕에 벤츠를 모는 프로그래머도 있지만, 그 동갑내기는 소위 말하는 SI 막장의 트러블 프로젝트 속에서 요구분석조차 제대로 되지 않은 시스템을 무한 반복적으로 수정하고 있기도 하다. 전자는 한 사람의 개발자가 세상을 흔들 가치의 원천임을 증명한 셈이지만, 동시에 후자는 정부가 정한 단가표로 조달 가능한 부품에 불과함을 증명하고 있다. 

이 차이의 원인은 어디에 있을까? 운이라고 말하면 성의 없는 대답이지만, 노력 탓이라고 말하는 것도 잔인한 기만이다. 지금 개발자들이 겪는 우울은 이 격차에 대한 울분이라기보다, 후자에서 전자로 이어지는 연속된 흐름이 발견되지 않는 구조적 모순에 있다. 닮고 싶은 롤모델도 없고, 괴로운 나날을 지킬 비전도 없다. 그도 그럴 만 하다. 안타깝게도 우리 주위에는 기술의 힘에 의해 기업의 지속 가능성(Sustainability)를 확보한 곳은 찾기 힘들다. 대신 기묘한 다단계의 착취 구조의 잉여 축적으로 지속 가능성을 근근이 유지하는 곳만 즐비하다. 가치를 발휘할 대상을 찾지 못하는 이들이 가치를 발휘할 리 없다. 악순환이다. 그렇기에 대부분의 경우 자기책임론은 무책임한 말이다.

어떻게 하면 좋을까? 가치를 둘러싼 사회의 문제란 결국 경제적 문제다. 그리고 경제적 부조리의 대부분은 수요와 공급의 구조 변화에서 온다. 우리는 이 구조를 간과해 왔다. 이를 알아차린 혹자는 의사나 변호사처럼 이익을 대변할 길드를 형성해야 한다고 말하고, 또 다른 이는 구조적 문제를 해소할 '당'을 만들어야 한다고 농담 같은 진담을 해 오기도 한다. 공급자의 입장에서 공급을 조절하는 구조를 꿈꾸는 기초적 반항심이다. 

그러나 이는 더 본질적 문제를 간과하고 있다. 그 것은 '업', 즉 프랙티스(practice)라는 개념이 완성되는 과정이다. 의사도 변호사도 모두 구조적 절차, 예컨대 선별 과정과 자성 절차를 통해 자신들의 업을 정의하게끔 하고 그 정의에 맞는 수행을 하도록 스스로를 단련하고 있다. 이 것이 구조의 힘이다. 

우리는 스스로를 개발자라고 말하지만, 이는 그냥 운동선수라고 말해 버리는 것과 마찬가지의 뭉툭한 묶음이다. IT라는 산업 역시 산업으로서의 스포츠 전체와 같아서, 어떠한 종목을 선택할지에 따라 이 산업에 참여한 신인의 미래는 크게 달라진다. 인기, 비인기 여부, 그리고 프로 리그의 존재 여부, 여기에 자신의 적성 및 특기, 비전이 더해져서 스포츠인으로서의 인생은 구조 안에서 만들어 지는 것이다. 

이 적응과 선택이 합리적이고 타당한 분기점과 분배구조를 통해 거쳐 가면서 누구는 맨유의 일원으로 또 누구는 마포구 조기축구회의 일원으로 각각 나름의 땀을 흘리게 된다. 이 것이 성숙된 구조를 지닌 산업의 일원에게 주어진 낭만성이다. 가장 인간적이며 원초적인 파이팅 정신을 스포츠에서 찾게 되는 이유는 어쩌면 이 절차적 투명성 덕일지 모른다. 스포츠는 이를 가능하게 하는 구조를 완성했다. 고대 그리스 시절부터. 

우리네 IT에게 결여된 것은 이러한 구조다. 우리는 왜 훌륭한 선수가 되지 못하냐는 질책은 있었지만, 어떠한 종목을 선택하는 것이 바람직한지 귀띔을 듣지 못했다. 그런 일을 태릉선수촌을 만든 정부에 기대해 보면 좋겠지만, IT에게 주어진 정책은 축구가 인기니까 6개월 과정으로 축구 선수를 배출하자는 근시안적인 방책뿐이었다. 그 덕에 98년에 엔터프라이즈 자바를 처음 하던 시절에 받던 '선생님' 대우가, 불과 10년도 안돼 단순 노무직의 신세가 되어 버린다. 더 아이러니한 것은 10년 동안 아무리 훌륭한 축구 스킬을 쌓았어도 이를 알아 주는 이는 없고, 넘치는 축구 선수 지망생 속에 스트라이커는 묻혀 버린다. 오늘 아침 조기축구회에 처음 나온 이도 박지성도 모두 똑같은 과기처 단가표를 받아 든다. 그나마 다행히 박지성은 특급일 것이다. 

더 큰 문제는 야구 선수마저 축구를 해야 하는 상황이다. 유난히 획일적인 사회 덕인지 모르지만, 어느 한 기술이 선택되면 업계 전체에 그 쏠림 현상은 무지막지하고, 여기에는 일종의 종교적 교조주의까지 가세한다. 눈치 보듯 동종 업계의 흐름을 뛰어 넘지 않는 RFP로 발주가 나고, 어느 누구도 새로운 것을 시도하지 않은 채 그저 그런 시스템이 계속 완성된다. 그리고 IT는 점점 새로운 것을 기피하며 혁신과 거리가 멀어진다. 

개발자의 생산성을 비약적으로 향상시킬 방안이 있어도, 그 기술을 쓰는 개발자의 단가가 비싸다는 이유로 기각되곤 한다. 이는 혁신의 상실일뿐더러 기회의 상실이다. ‘보이지 않는 손’의 위업이라 해버리면 그만이지만, 정책이란 이러한 상실을 지키기 위한 것 아니었던가. 

어쩌면 국가나 정부의 정책이 밸런스를 맞추는 일은 애초에 무리일지 모른다. IT에서 일어나는 대부분의 변화는 정책 수행이나 입안 주체가 지닌 능력이나 태도의 문제나 차원을 넘어 초국가적 IT 트렌드의 결과이기 때문이니까. 그러나 아무리 글로벌화로 평평한 세계가 되어도 여전히 국가의 경계가 주는 문화적 경제적 사회적 기회의 차이는 지대하기에, 지렛대가 되어야 할 정책의 몫은 여전하다. 한 국가의 스포츠 정책이 생활 체육보다 엘리트 체육에 치중하는 이유도 이 차이의 가시적 해소를 위함이다. 왜 오프쇼어가 존재하는지, 왜 전세계의 IT 시스템이 여전히 미국발 플랫폼에 의존하고 있는지를 기억해 보자. 아무리 세계가 평평해져도 물리적 IT강국과 그 가치의 흐름은 존재한다. 

한국 내에도 IT에 특화된 수많은 공공 단체들이 있지만 이에 대한 심도 깊은 고찰이 어디에서 이루어지고 있는 지 궁금하다. 예컨대 국가가 나서서 오픈소스를 이야기하지만, 오픈소스가 국내 개발자의 전체적 후생에 어떠한 영향을 미치는지 설명책임이 없다. 정책자 들은 오픈소스가 우리의 미래라고는 하지만, 우리에게는 아직 북구나 북미에서처럼 오픈소스 커미터로 활동하는 일에 대한 직업적 환경이 형성되지 못했다. 글로벌 벤더가 북구나 북미에서처럼 이들을 한국에서 고용하지도 않고, 또 그렇지 않더라도 돈을 받지 않고 연구에 몰두할 수 있는 사회적 안전망을 국가나 학계가 갖추어 주지 않는다. ‘스캔디나비안 객체 지향 학풍’, '핀란드의 기나긴 겨울'과 같은 은유적 여유조차 없는 우리에게 오픈소스는 '소프트웨어는 거저'라는 잘못된 인식의 획득뿐이고, 그 결과 세계에 기여는 안 하면서 가져다 쓰기만 하는 기형적 오픈소스 문화만 남게 되었다. 구조적 문제의 일례다. 

도대체 무엇이 우리의 미래인가? IT 강국이라고 공염불은 하지만 그 실체는 없고, 참여자는 좌절하고 있다. 좋아서 시작은 했지만, 어떻게 하면 가치를 발휘할 수 있는지 알려 주지 않는다. 축구 선수는 늘어났지만 클럽이 없다. 운이 좋아 프로 축구단에 소속되면 다행이지만, 일부 개인에게 돌아간 이 요행을 산업 전체에 바랄 수는 없다. 그렇다면 야구가 있음을 알려야 한다. 올림픽을 열어야 한다. 세계 선수권에 나가야 한다. 새로운 종목에 도전해야 한다. 여자 양궁을 찾아야 한다. 쇼트 트랙을 찾아내야만 한다. 

업계에 참여하는 개개인 모두가 IT의 미래를 날카롭게 읽어 내어 그 길을 내달리고 또 시장까지 열어 줄 수 있는 성과물을 만들어 주기를 바란다면 이는 욕심이다. 우리는 지금껏 그 욕심 속에서 자책해 왔다. 개인이 내달릴 수 있는 구조가 없는 곳에서, 개인이 움직여 주지 않는다 해봐야 아무 일도 일어나지 않는다. 

다행히 구조의 왜곡을 먼저 읽어 내는 이들은 분명 존재한다. 그들은 기업인일수도, 마케터일수도, 에반젤리스트일수도, 블로거일수도, 정책가일수도, 혹은 이 글을 읽는 여러분 일수도 있다. 이 업계의 이 사회의 구조를 바꾸는 일, 우리의 몫이다. 구조 개혁은 어쩌면 길을 먼저 읽어 낸 이들의 책임이다. 미래란 그들이 뜯어 고칠 이 구조의 결과인 것이다. 개인은 구조의 영향을 받지만, 그 구조를 만드는 것은 개인이라는 사실. 이 것이 우리가 지닌 가장 큰 희망이기도 하다. @
 


Posted by SB패밀리

얼마전 개발자가 보면 암 걸리는 동영상이라면서

SNS에 올라온 동영상이 있다.


모든 미팅이 이렇지는 않겠지만 프로젝트를 구성하는 여러 구성원이 모이면

개발자가 전지전능한 신처럼 여겨지는 경우가 있다.


물론, 강요에 의해서


여하튼 한 번이상은 이런 상황을 겪은 개발자(엔지니어)가 있다고 본다.


자, 아래 동영상을 감상하면서 공감해 보자.... 


다들 연기력이 좋지만, 엔지니어 역할 표정연기 너무 실감난다.
The Expert (Short Comedy Sketch)




The Expert (Short Comedy Sketch) - 엔지니어에게는 난감한 미팅!

(한국어 자막 지원됩니다 ^^)


Posted by SB패밀리

[개발/컬럼] 프로그래밍, 얼마나 배워야 하나요?

개발자에게 도움이 될만한 컬럼 같아서 올려봅니다.

Post-It Note Art Collage (PINAP)
Post-It Note Art Collage (PINAP) by Adrian Wallett 저작자 표시비영리변경 금지



 얼마나 배워야 하나요? | Codeway  2003.12.18  

류(ryujt)   http://cafe.naver.com/codeway/6 


얼마나 배워야 하나요?


가끔 프로그래밍을 시작하려고 하거나 입문과정에 있는 분들에게 받는 질문이다. 그리고, 때로는 자신의 위치가 어느 정도가 되는지 항상 의문을 가지는 사람들에게로부터 같은 질문을 받는다.

본인이 그러한 것에 대한 권위적인 기준을 남에게 이야기할 만한 자격은 없지만, 나름대로 생각한 기준을 말해보고자 한다. 지금부터 이야기하는 것들은 본인 자신의 개인적인 기준일 뿐, 그 어떠한 권위적인 해석이나 정보를 바탕으로 하고 있지 않음을 미리 알려둔다.

우선 본인은 개발자의 등급분류를 준비과정, 입문과정, 초급, 중급, 고급, 특급으로 나누고자 한다. 여기서 입문과정과 준비과정이 다소 애매하다. 프로그래밍을 시작하면 무조건 입문과정이라고 분류할 수 있을 것이다. 하지만, 그 입문과정을 준비과정과 입문과정 둘로 나누고 싶은 데에는 이유가 있다.

준비과정은 공부를 시작한 지 최소 1개월 정도를 생각한다. 이 과정 중에는 개발에 대한 전반적인 이해와 개념을 공부하는 과정이다. 이러한 공부는 상당히 지겨운 편이다. 공부하는 동안 그 결과가 겉으로 들어나지 않기 때문이다. 하지만, 본인은 조금은 여유를 가지고 살펴보기를 강력히 권장한다.

대부분의 사람들은 무엇을 배울 때, 상당히 조급한 경향이 있다. 그리고, 그 조급함으로 인해 무엇인가 빨리 터득했다고 믿는다. 또한, 항상 자신이 빠르게 배웠음을 자랑으로 여긴다. 하지만, 이러한 사람은 임계점에서 실력이 향상되지 않는 슬럼프를 꼭 겪게 된다.

준비과정에서는 프로그래밍 자체보다는 자신이 선택한 개발영역에 대한 포괄적인 이해에 대하여 집중해야 한다. 이것을 공부해 나가는 동안 여러분들은 개발에 관한 전체적인 안목을 얻을 수 있는 좋은 기회가 된다. 편협한 지식은 가끔 문제해결을 하고자 할 때, 상당한 방해가 된다. 마땅히 공부할 자료를 제시하기는 어렵지만, 전산학개론 정도가 될 것이다.

입문과정은 6개월 정도를 생각한다. 이 과정 중에는 선택한 프로그래밍 언어 자체에 대한 수련을 하는 과정이다. 우선은 문법체계와 프로그래밍에 대한 절차에 대해서 공부를 하고, 이후 다양한 문제해결에 대한 실전적인 연습이 필요하다. 굳이 책에 집착하지 말고 자신이 하고자 하는 새로운 프로젝트 또는 문제를 설정하여, 이를 선택한 언어를 통해 해결해 나가는 동안 그 언어에 대한 감각을 길러 가는 것이다.

프로그래밍은 지식보다는 감각적인 요소가 상당히 중요하다. 그것은 프로그래밍을 실무에 접했을 때, 그 문제의 해결을 위한 그 어떠한 정석도 존재하지 않기 때문이다. 비슷한 업무에 대한 개발을 계속적으로 진행하더라도, 결국 구현단계에서는 언제나 새로운 문제가 기다리고 있다. 이러한 것들을 단순히 암기된 지식의 결합 및 수정으로는 해결할 수가 없다. 특히 알고리즘에 관한 공부를 게을리하지 않기를 바란다.

이제, 위에서 거론된 두 과정을 지나면 여러분들은 초급 프로그래머라고 할 수 있을 것이다. 그리고 이 초급은 최소 1년에서 2년 이상 거쳐야 한다고 생각한다. 이후 중급은 4년 이상 그리고 고급과 특급은 기간자체가 중요한 요소라고 생각하지 않는다.

입문과정이 전반적이 이해와 감각을 키우는 과정이라면, 초급과정에서는 스킬을 중점으로 공부하는 과정이라고 생각한다. 입문과정은 다소 포괄적인 공부를 하는 단계라고 한다면, 자신의 개발영역을 조금씩 넓혀가면서 심도 깊게 연구하는 단계이다.

초급, 중급, 고급, 특급 개발자들의 기준은 다음과 같이 정리해봤다.


초급 
     - 제한된 범위의 단위 모듈에 대한 코딩 능력
     - 작성된 모듈에 대한 수정 및 변경 능력
     - 프로그래밍에 대하여 상급 개발자의 조언에 의존하는 단계

중급 
     - 설계서를 토대로 스스로 프로그래밍의 문제를 해결할 수 있는 능력
     - 개발절차와 흐름에 대한 완벽한 이해

고급 
     - 프로젝트의 위험요소를 미리 판별하고 대응하는 능력
     - 설계능력
     - 리더십
     - 풍부한 개발 경험

특급 
     - 기술적인 사회적 흐름을 예측하는 능력
     - 대인관계와 대응에 대한 능력
     - 풍부한 사회 경험
     - 회사내의 개발전략을 작성하고 영업과 경영에 대한 조언 및 보조 능력

Posted by SB패밀리

[개발] 나는 과연 개발자로서 자질을 갖추고 있는가?


◈ 나는 과연 개발자로서 자질을 갖추고 있는가?

--------------------------------------------------------------

1. 다른 사람과 경쟁하길 좋아한다.

2. 성공을 위하여 보상에 관계없이 격렬하게 경쟁한다.

3. 조심하면서 경쟁하지만 가끔 허세를 부린다.

4. 장래 이득을 얻기 위해선 주저하지 않고 위험을 무릅쓴다.

5. 업무를 잘 처리하여 확실한 성취감을 얻는다.

6. 전통에 얽매이길 싫어한다.

8. 먼저 일을 시작하고 나중에 의논하는 경향이 있다.

9. 칭찬이나 보상보다는 업무수행 자체를 중시한다.

10. 타인의 의견에 구애받지 않고 내 방식대로 한다.

11. 과오나 패배를 잘 인정하지 않는다.

12. 자발적이며 남의 말을 듣지 않는다.

13. 좀처럼 좌절하지 않는다.

14. 문제가 있으면 스스로 해결책을 찾는다.

15. 호기심이 강하다.

16. 남이 방해하는 것을 참지 못한다.

17. 타인의 명령을 듣기 싫어한다.

18. 비판을 받고도 참을 수 있다.

19. 일 완성되는 것을 보겠다고 고집한다.

20. 동료나 부하들이 나처럼 열심히 일하기를 바란다.

21. 개발에 관한 지식을 넓히기 위해 독서를 한다.


------------------------------------------------------------



My Desk @ SimpleGeo SF
My Desk @ SimpleGeo SF by Jon Rohan 저작자 표시




측정 방법 : 서술내용과 나의 행동이 일치하면 3 점, 
항상 일치하지는 않으나 상황에 따라 일치하면 2점, 
일치하지 않으면 1점

평가 방법 : 총점이 63점이면 완벽, 52 ~ 62 점이면 우수, 
42 ~ 51 점이면 보통, 41 점 이하면 열등






Posted by SB패밀리


어느 분야를 막론하고 경력이 쌓여갈 동안 매년 같은 일만 반복하는 해위를 하지 않으려고 노력해야 

보다 더 나은 경력과 연봉, 지식, 명예가 따르기 마련이다.





PAR-TIC-I-PA-TION, or 37 pieces of library flair (also a 365days shot)
PAR-TIC-I-PA-TION, or 37 pieces of library flair (also a 365days shot) by cindiann 저작자 표시비영리동일조건 변경허락





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

자신을 진화시키고 환경을 만들어내는 개발자

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

 

지난 컬럼에서 살펴본 개발자 관리의 문제점 및 좋은 관리 지침에 대해 독자들의 많은 피드백이 있었다. 그만큼 관리가 제대로 되고 있지 않다는 실증일 것이다. 올바른 관리의 밸런스를 갖추는 것은 쉽지 않다. 통제에 집착한 나머지 '관리를 위한 관리'를 하게 되거나, 리소스 부족 또는 자율에 집착한 나머지 방임을 하게 되는 경우가 많기 때문이다.

또한 이러한 잘못된 관리의 근원적인 문제는 곧 시스템의 문제라고 볼 수 있다. 단지 관리자 개인의 철학과 도덕성만으로는 어쩔 수 없는 조직문화, 그리고 조직의 프로세스로부터 엄청난 영향을 받기 때문이다. 사실, 조직문화와 시스템의 문제는 일개 개인이 어떻게 할 수가 없다. 시스템에 반발하면 퇴출당하거나 스스로 나가야 할 뿐이다.

이에 대해서는 필자 스스로 여러 기업들을 전전하면서 가슴 절절하게 느낀 부분이다. 그러므로 관리자들은 조직문화에 맞추어서 그리고 시스템을 위배하지 않는 가운데에서 자신의 관리 철학을 구현하려고 노력해야 할 것이다. 이것이 관리자를 위한 애정 어린 조언이다.

시스템을 바꿀 수 없다면 자신을 바꿔라
그렇다면 개발자 개개인은 어떻게 해야 할까? 많은 개발자들이 사회 환경과 조직 시스템에 대해 불만이 많다. 하지만 자신이 권한이 없다면, 사회와 조직은 바꿀 수 없다. 그것에 반발심을 가진 채로 자신에게 맞는 노력을 하지 않는다면, 마치 사춘기 소년이 트라우마를 안겨준 부모에게 반항한 나머지 자신의 인생을 망가뜨리는 것처럼 개발자 자신의 삶도 망가질 뿐이다.

조직은 개발자의 경력관리를 해주지 않는다. 이점은 불변의 진리이다. 정말 잘못된 일이지만, 현실을 보면 많은 회사들이 직원을 "달면 삼키고 쓰면 뱉는 일"이 빈번하다. 그러니 사람들이 생존의 욕구에 집착한 나머지 자아실현은 엄두도 내지 못하고 있는 것이 아닐까? 생존조차 쉽지 않은 것이 이 사회의 현실이다. 더군다나 개발자 직종에 몸담고 있다면 삭막한 현실은 몇 배 더 증가한다.

사회에서 성공한 선배 개발자(그 성공의 기준이 돈이든 명예든 자아실현이든)를 찾아보기가 참으로 힘들다. 물론 그것의 가장 큰 이유는 바로 업계 풍토 때문인데, 그것에 대해서는 이미 두 차례에 걸쳐서 컬럼을 쓴 바 있다. 업계 풍토는 서서히 변하거나 변하지 않는다. 개발자 개인이 바꿀 수 있는 것은 단기적으로는 단지 자기 자신뿐이다. 그렇다면 개발자 개인이 갖추어야 할 주요 역량에는 어떤 것들이 있는지 살펴보자.

개발자 개인이 갖추어야 할 주요 역량
첫째, 주변 상황과 인간의 역학관계를 이해하고 교류하는 커뮤니케이션 스킬이다. 많은 개발자들에게 있어 가장 부족한 역량이 바로 이것이다. 혹자는 이렇게 말한다. 개발자들은 그 특성상 커뮤니케이션 스킬이 부족할 수밖에 없고, 외국에서는 그것을 인정해주는데 한국에서는 왜 그렇지 않냐고. 실제로 소프트웨어 강국들을 보면, 개발자들에게 개발에만 집중할 수 있는 환경을 제공해주며 멀티플레이어 역할을 원하지 않는다. 하지만 한국은 소프트웨어 강국이 아니다! 또한 아무리 개발자를 대우하는 외국에서도 성공하는 개발자들은 커뮤니케이션 스킬이 뛰어난 사람들인 경우가 많다.

이 점을 간과해서는 안될 것이다. 커뮤니케이션 스킬은 개발자가 노력해서 갖추어야 하는 것이며 그것을 폄하해서는 안 된다. 개발자들과 함께 일해본 기획자들은 개발자들의 커뮤니케이션 문제점에 대해 지적하는 경우가 많다. 그들은 개발자들의 커뮤니케이션 태도가 닫혀있고, 어려운 용어를 남발하며, 대세에 영향을 미치지 않는 사소한 문제에 집착하고, 타인의 요구에 대해 관심을 가지지 않는다고 필자에게 하소연하곤 한다. 개발자 출신인 필자가 보기에도 그런 개발자들이 많다는 것을 인정하지 않을 수 없다.

물론 그러한 캐릭터가 바로 개발자이다. 그렇기 때문에 하루 종일 모니터를 바라보며 코딩의 세계에 빠져있을 수 있는 것이다. 하지만 만일 고도의 집중력를 발휘할 수 있는 캐릭터의 특성을 유지하면서 또한 타인과의 커뮤니케이션 스킬에 있어 조금의 향상이라도 가져온다면, 더욱 더 개발을 잘 할 수 있는 환경을 얻게 될 것이다. 즉 코딩을 더 잘하기 위해 커뮤니케이션 스킬이 필요한 것이다. 좋은 커뮤니케이션 스킬은 좋은 환경을 만들어 준다. 만일 데일 카네기의 책 한 권 읽어본 적이 없다면 지금 당장 인터넷 서점에서 구매하기 바란다.

둘째, 기술향상과 인간수양을 위한 자기계발이다. 자기계발이란 조직이 책임져주는 것이 아니다. 다시 한번 말하지만 조직은 경력관리를 해주지 않으며 자기계발을 시켜주지도 않는다. 회사가 시켜주는 교육은 단지 회사 업무를 위한 것일 뿐이다. 그것마저도 직원들이 함께 받는 경우가 대부분이라서 경쟁력 향상에 별로 도움이 되지 않는다.

자기계발은 여유 있을 때 행하는 것이 아니다. 실제로 인간이라는 존재는 한없이 여유로운 동물이라서, 시간이 많으면 더 게을러질 뿐이다. 그러므로 자기계발은 시간이 없을 때 짬을 내서 하는 것이라고 생각하는 것이 좋다. 그리고 자기계발에는 두 가지 측면이 있다. 하나는 개발자로서 기술적인 측면의 자기계발이고, 또 다른 하나는 인간으로서 인간수양 측면의 자기계발이다.

신기술 습득에 대해서는 다 아는 부분이니 따로 얘기하지 않겠다. 인간수양은 흔히 간과되지만 몹시 중요한 부분이다. 태어난 그 자체의 결함 가득한 성격 그대로 산다면 동일한 실수와 실패를 반복하게 될 뿐이다. 인간으로서의 멋진 점은 자신을 계속 가다듬으면서 조금이라도 완성된 인간을 지향하는데 있다. 다양한 책을 읽고, 가보지 않은 곳을 가고, 많은 사람들을 만나야 한다. 만일 이것을 해낸다면 인생의 도를 깨우친 멋진 개발자가 될 수 있을 것이다.

셋째, 작은 성공을 통해 큰 성공을 얻을 수 있도록 끊임없는 변화하고 실행해야 한다. 주변 상황과 인간을 입체적으로 이해하고 교류하면서, 기술과 인간적 소양의 자기계발을 하다 보면, 어느 순간 기회가 온다! 이것은 정말 준비된 사람에게만 주어지는 선물과도 같다. 하지만 준비되지 않은 사람에게는 기회 자체가 주어지지 않거나 또는 기회가 왔다고 하더라도 그 자신이 눈치챌 수 없다.

우리 스스로 저주를 받을 것인지 축복을 받을 것인지 선택할 수 있는 것이다. 그렇다. 어떤 측면에서 인생은 충분히 콘트롤 할 수 있다. 자신을 진화시키다 보면, 우리 자신이 이 사회에 변화를 줄 수 있는 주체라는 것을 깨닫게 되고 실제로 변화를 행할 수 있는 기회를 얻게 되는 것이다. 그러한 기회를 얻기 위해서는 끊임없이 변화하고 실행해야 한다. 자기 자신에게 다가오는 모든 기회를 수용하며 그 결과를 확인해야 한다. 불안감과 두려움 따위로 인해 좋은 기회를 포기해서는 안 된다.

자신에게 좀 벅차다고 생각하는 바로 그것을 떠맡아야 한다. 그 일을 하게 되면 그 일을 하기 전에 자신이 생각했던 그 모든 게 바보 같았다는 것을 깨닫게 된다. 그리고 이미 사람이 달라지고 있는 것을 발견하게 된다. 결국 그 일을 끝마쳤을 때는 모든 것이 변해있다. 작은 성공사례를 반복하고 반복하면서 더 큰 성공사례를 향해 다가가는 것이다. 그러니 신기술 구현이든, 새로운 프로젝트를 떠맡는 것이든, 자격증 도전이든, 커뮤니티 창설이든, 이직이든, 대학원 진학이든, 외국 취업이든 두려워하지 말고 실행하기를 바란다. 실행하면 모든 것이 달라진다.

환경, 조직, 사람간의 역학관계를 이해하고 미래를 준비하는 개발자
유능한 개발자는 기술력이 뛰어날 뿐만 아니라, 자신이 해야 할 일을 둘러싼 기술적/정치적 환경을 입체적으로 이해하고 교류하며, 자신에게 요구될 역량을 미리 갖추고 있으며, 적절한 시점에 곧바로 행동에 옮길 수 있는 실행력을 갖춘 사람이다.

왜 개발자가 이렇듯 기술 외적인 부분에 대해 신경을 써야 할까? 이런 필자의 논리에 대해 불편한 감점을 느끼는 개발자도 있을 것이다. 충분히 이해하고 있다. 그러므로 좀 더 부연설명을 해보겠다.

만일 현재 자신이 처한 환경이 돈, 명예, 자아실현의 관점에서 자신의 원하는 만큼 만족스럽다면 필자가 제시한 이러한 역량들에 대해 신경 쓰지 않아도 좋다. 그런 분들한테는 여기까지 글을 읽게 해서 죄송할 따름이다. 하지만 자신이 처한 환경이 만족스럽지 않다면 그것이 커뮤니케이션 스킬과 자기계발, 실행력이 부족하기 때문은 아닌지 생각해 보기 바란다.

필자가 언급한 역량들은 사실 개발자뿐만 아니라 이 사회의 모든 개인이 갖추어야 할 역량이라고 볼 수 있다. 하지만 잘못된 업계 풍토로 인해 어려움에 처해있는 개발자들에게 있어 특히 부족하면서도 더욱 요구되고 있는 역량이라고 볼 수 있다. 이러한 역량들이 가져다 주는 놀라운 결과들을 간과하지 않았으면 좋겠다.

환경을 바꿀 수 없으면, 자기 자신을 진화시키고 결국 환경을 만들어 내야 한다. 그러지 못한다면 잘못된 업계 풍토로 인한 희생양이 될 뿐이다. 이 사회에 대한 올바른 이해와 방향 감각을 갖추고 있으면서, 부단히 노력하며 진화를 꿈꾸는 개발자의 앞날에 커다란 행운을 기원한다. @


Posted by SB패밀리

프로그래머로 살아남는 법 / 이만용

출처 : http://maso.zdnet.co.kr/20010407/specplan/article.html?id=128&page=1%C2%A0%C2%A0


이 글은 컴퓨터 프로그래밍을 이미 자기 삶의 중요한 일부분으로 받아들였지만 잠시 주춤하고 있는 사람들과 프로그래머의 길 앞에서그렇게 될 것인가 말 것인가 고민하고 있는 사람들에게 '삶의 과정으로서의 프로그래밍'이라는 관점을 갖고 작성했다. 이를 통해프로그래밍하는 인간의 모습을 돌아보고 프로그래머로서의 인간 에너지를 충전시키는 시간을 제공하고 싶다.  


이만용 (리눅스코리아 CTO ) 2001/04/13  


필자는 이 글을 통해 지난 3-4 년간 프로그래머가 되고 싶어했던 사람들, 이미 직업으로서 프로그래밍을 하고 있다. 현재보다 더나은 프로그래머가 되길 원했던 사람들이 필자에게 보낸 메일에 대한 답장 속에서 했던 이야기. 그리고 하고는 싶었지만 답장 메일로적기에는 너무 길어 적지 못했던 마음속의 말들을 꺼내어 정리하는 시간을 갖게 되었다. 종종 일상의 지겨운 반복 속에서 좌표를잃지 않기 위해 컴퓨터 앞을 떠나 편안하게 사색에 잠길 수 있기를 바라며 이야기를 시작한다.  

원래 창조적인 지적 유희이며 그러해야 한다  
필자에게 왜 프로그래밍을 하고 있냐고 묻는다면, 주저없이 '재미(fun)'라고 답할 것이다. 한 가지 덧붙이자면, 만약프로그래밍보다 더 재미있는 일이 있다고 생각한다면, 역시 주저함 없이 프로그래밍 대신 그 일에 몰두할 것이다. 재미없는 일을억지로 하면서 보내기에는 인생은 너무 짧지 않은가. 여러분이 이미 생계의 족쇄 속에 또는 사회적 위치 속에 결박당해 탈출할 수없는 경우가 아니라면, 그리고 충분히 새로운 선택을 하여 재시도할 수 있는 사람이라면, 다시 한 번 진정으로 자신이 프로그래밍을즐기고 있는지 생각해 보는 시간을 갖기 바란다. 꼭 프로그래밍을 해야 하는 절대절명의 이유란 없다. 앞으로 전개될 글을 읽기전에 마음의 고리를 풀고 편안한 마음으로 자신의 사고가 흐르는 대로 방치하기 바란다.  

꼭 프로그래밍만이 재미있다고 말할 수는 없지 않겠는가. 당연히 재미라고 하는 것이 인간의 다른 모든 행위로부터 프로그래밍을구별해 주는 유일한 요소일 수는 없다. 이 세상에는 프로그래밍 이외에도 이미 사람이 재미를 느낄 수 있도록 해 주는 일이 헤아릴수 없을 정도로 많듯이 말이다. 예전에도 그리고 지금도 수억의 인구가 회화, 악기 연주, 운동 등에서 즐거움을 느끼고 있다. 이활동들은 새로울 것도 없지만, 여전히 재미있는 활동이다. 프로그래밍도 시간이 지남에 따라 훨씬 더 대중화하고 똑 같은 취급을받을 것이다. 하지만 프로그래밍이 똑같이 재미있는 수많은 일 중 그냥 하나라고 말하기에는 너무 극단적이다. 어떤 점에서프로그래밍이 주는 재미가 다른 재미와 같고 또한 다른 것일까.  

프로그래밍은 이미 오랜 시간 동안 인간의 역사 속에서 사람들에게 재미를 제공했던 기존 활동과는 도구적 관점에서 다르다. 여기서컴퓨터라고 하는 20 세기의 놀라운 발명품을 이야기하지 않을 수 없을 것이다. 책, 기관차, 전화와 같은 출판 기술, 증기기관, 통신 기술이 인간 세상을 변화시킨 것처럼 컴퓨터가 현재의 인간 생활을 변화시켰다는 점을 부인할 사람은 없다.  

인간은 그 동안 자신이 발견하거나 발명한 것을 즐기며, 도구를 통해 자신을 다시 변화시켜 왔다. 프로그래밍은 컴퓨터라고 하는도구를 통해 그 안에서 인간의 상상력과 논리적 사고력을 실현해 내는 고급 유희다. 그러나 바로 이전 문장에서 표현했듯이, 인간이지적 노력을 쏟아 지적인 재미를 만들어 내려고 하는 지적 유희라는 점에서는 그 이전의 모든 창조적 지적 유희와 하나도 다르지않다. 여기서 필자는 다르다는 점보다 같다는 점을 강조하고 싶다.  

채 다 배우기도 전에 쏟아져 나오는 프로그래밍 언어, 선택해 보지 못한 메뉴가 아직도 많은데 버전업돼 나오는 통합 개발 환경에치여 살다 보니, 프로그래머인 우리 자신이 인간이 최근 만든 가장 놀라운 발명품을 사용해 가장 재미있는 창조적 지적 활동을 하고있다는 사실을 너무도 쉽게 잊어버리는 모습을 목격할 수 있다. 그리고 현실 속에서는 이러저러한 언어, 도구에 지배받으며 지쳐있는 불쌍한 자신을 쉽게 발견한다.  

하지만 그 어떤 컴퓨터를 사용하든, 그 어떤 프로그래밍 언어나 도구를 사용하든 우리 프로그래머들이 본질적으로는 참 재미있는 일을 하고 있다는 사실을 망각하지 말아야 한다고 말하고 싶다. 그것도 매우 지적인 재미 말이다.  

그러한 자기 만족감이 없이 버틸 수 있는 프로그래머가 있을까. 프로그래밍 언어책을 보다 며칠씩 이해되지 않던 부분이 갑자기 슬슬풀려 나갈 때, 작지만 자기가 예상한 대로 모든 일이 척척 진행돼 나갈 때, 하루 종일 찾지 못했던 버그를 커피 마시다 갑자기찾아냈을 때 느끼는 자신에 대한 대견스러움, 만족감을 느껴보지 않고 어떻게 프로그래머라고 말할 수 있을까. 이런 즐거움은 이성친구, 애인, 가장 가까운 친구에게도 어떤 말로도 전달할 수 없는 매우 개인적인 차원인 것이다. 때로는 자신의 소스 코드와프로그램을 이해하는 지구 반대편의 프로그래머와 더 진한 동질감을 느끼기도 하는 것 또한 프로그래머다.  

자신에 대해 대견스러워하는 마음, 무엇보다 자신이 설계한 대로 컴퓨터가 작동하는 것을 보는 즐거움, 컴퓨터를 통해 자기만의세계가 창조되는 즐거움을 느끼지 못한다면 앞으로 하는 모든 이야기는 별 의미가 없다. 취미로든 직업으로든 왜 프로그래밍을선택했는지 그리고 왜 수많은 책과 읽을거리와 투쟁하고 있는지 자기 확신을 갖자. 아무리 생각해 봐도 프로그래밍은(유일하지는않아도) 꽤 매력적인 고급 활동이다. 재미있는 일을 재미있게 하지 못한다면 그것은 큰 문제가 아닐 수 없다.  


프로그래밍의 본래 의미를 찾는다  
대학생 친구들을 위한 언어 교재를 만들면서 자주 등장하는 외래어 표현을 정리하고 있었다. 그런데 바로프로그램(program)이라는 말 그 자체가 우리에게 시사하는 바가 많다는 사실을 발견했을 때 마치 보물을 발견한 양 즐거워 한적이 있다.  

'program'이라는 단어는 'pro'와 'gram'의 합성어다. 여기서 'pro' 는 '어떤 일을 하기 전에...' 라는'before' 의 의미를 갖고 있으며 'gram'은 '무엇인가를 쓰다' 즉 'write'의 의미를 갖고 있다. 따라서program은 쓰거나 만드는 행위라기보다 '쓰기 전에 하는 일' 즉 계획적인 사고 행위를 가리킨다.  

현실적으로 우리가 우리 자신을 설계자나 기획자라고 생각할 수 있는 여유는 거의 없는 것 같다. 우리가 매일 확인할 수 있는자신의 모습은 특정 언어나 특정 제품, 특정 프로젝트의 노예로 전락해 있는 초라한 모습이지 않은가. 프로그래밍은 어느 새 밤을세며 코딩하는 중노동과 동일시돼 버렸다. 그래서인지 요즘 미국이나 한국 젊은이를 대상으로 한 설문조사를 보면 그래픽 디자이너가되고 싶다는 답변이 프로그래머가 되고 싶다는 답변보다 월등히 많다고 한다. 이미 프로그래머란 컴퓨터 분야 중 가장 선호하는직업이 아닌 것이다.  

프로그래밍 작업의 특성이 무엇을 이뤄내기 전에 먼저 머리 속에서 설계하는 정신적 유희라는 본질적인 의미를 자꾸만 잊게 하는 그무엇을 갖고 있다고도 볼 수 있다. 프로그래머를 계속해서 괴롭힐 동전의 양면적 특성이 존재하는 것이다. 계획과 함께 실천이있어야만 완성되는 것이 프로그래밍의 중요한 특성이다.  

설계한다는 점에서 프로그래머는 건축가와 유사한 점이 많다. 아무리 작은 프로그램을 만들지라도 프로그래머의 머리 속에는 이미 어느정도의 프로그램 진행 과정에 대한 설계가 먼저 이뤄진다. 그러나 건축가가 실제 건물을 만들지는 않는다. 건물을 직접 만드는 일은건축 노동자들의 몫이다. 이렇게 건축이라는 영역에서 건물을 설계하는 일과 짓는 일은 완벽히 분리돼 있다. 그러나 프로그래머는결국 자기 손으로 건물까지 지어야 한다는 점에서 크게 다르다. 상상만 하고 코드를 입력해 실행 프로그램을 만들어내지 않으면 아무것도 하지 않은 것과 같다. 그런 점에서 프로그래머는 어떻게 보면 화가나 조각가에 더 가깝다. 자기 내면에 비춰진 이미지에서그치는 것이 아니라 캔버스나 대리석에 실체를 구현해야 하며, 생각하는 주체와 그것을 실현해 내는 주체가 같다.  

프로그래머인 우리가 결국 C, C++, 자바 등 특정 언어를 배워 우리의 아이디어를 실행 가능한 소프트웨어로 만들어내야 한다는사실은 분명하다. 그러나 그렇다고 해서 프로그래밍이 언어를 잘 구사하는 것만으로 끝날 일은 아니다. 그림만 잘 그린다고 해서화가라고 말하지 않는 것과 같다.  

시작은 언어 대신 사고력 부터  
그렇다 해도 여전히 훌륭한 프로그래머가 되기 위한 시작은 언어가 아니라 사고 능력이라는 점을 지겹도록 강조하고 싶다. 프로그래밍언어책을 붙들고 공부한다고 해서 자연스럽게 프로그래밍을 잘 하게 되는 경우는 없다. 만약 그랬다면 이 글을 쓰고 있어야 할이유조차 없었을 것이다. 언어 공부가 자연스럽게 자신을 프로그래머로 만들어 주지는 않는다. 이 사실은 독자 여러분이나 필자나말하지 않아도 알고 있다.  

또한 그렇다고 해서 무조건 명상에 잠긴다거나 순서도 그리는 일을 다 마치고 나서 언어를 배우고 프로그래밍하는 것도 아니다. 원래생각하는 과정과 도구를 사용해 실현하는 과정이 떨어져 있는 것도 아니다. 인간은 자유로운 상태에서 생각하며 도구를 사용하고,도구를 사용하며 생각한다.  

인간의 놀라운 점 중 하나는 도구를 사용함으로써 자신의 사고 능력을 발전시키고 그 발전된 사고 능력으로 도구를 개선하거나 새로운도구를 만들어 가는 무한 사이클을 이어간다는 것이다. 여러 가지 관점에서 설명할 수 있겠지만 필자가 강조하고자 하는 면은 다음과같다. 생각하지 않으면서 언어를 사용하고 코딩하는 것은 계속 제자리를 맴도는 것과 같다. 생각없는 코딩은 생각하는 사람의 사고능력에 아무런 영향도 미치지 않는다. 아니, 오히려 악영향을 미치기도 한다. 생각없는 반복적 행동은 오히려 생각을 굳게 만들어반복적 행동을 또 다시 만들어 낼 가능성이 높다. 극단적으로 말해서 생각없이 코딩하느니 너무 지겨워서 다시 생각을 하고 싶을정도로 빈둥대거나 잠을 푹 자두는 것이 현명한 일이다(필자는 실제로 그렇게 하고 있다).  

인간의 다른 지적 노동과 마찬가지로 현명한 반복만이 현명함을 낳는다. 학문이라는 것이 마치 강을 거슬러 올라가는 것과 같다는옛말이 있는데, 사실 이보다 더 끔찍하다고 생각한다. 아무 생각없는 반복은 또 다른 생각없는 반복만을 낳을 뿐이며, 현명하게반복할 수 있다는 사실을 잊게 만든다. 자연스럽게 어떻게 프로그래밍을 배워나가야 하는지 얘기를 이어나가고자 한다.  


프로그래밍, 어떻게 배워나가야 하나  
'닭이 먼저냐 달걀이 먼저냐' 하는 전통적인 질문이 여기서도 그대로 적용된다. 똑똑해지려면 똑똑하게 배워야 한다. 현명해지려면 현명하게 배워야 한다.  

어떻게 똑똑하게 배울 수 있는가  
반대로 설명하는 것이 좋겠다. 프로그래밍은 매우 지적인 유희라고 앞서 몇 번이고 반복한 바 있다. 현재 대부분의 프로그래머지망생이 학습하는 방법은 크게 다르지 않다. 학습이 매우 단순 반복적이다. 단순 반복에 의해 지적인 성장이 이뤄진다고생각하는가. 게다가 학습 과정이 지겹기 때문에 유희적인 측면도 이미 상실한 지 오래다. 무엇보다도 몇 번의 반복 속에 자기자신을 지치게 만들면 이미 게임은 끝난 것이다(물론 꾹 참고 꾸준히 하면 언젠가 길이 보일 것이라고 얘기할 수도 있다. 그러나이렇게 말해 버리면 역시 이 글의 의미가 완전히 사라진다).  

똑같은 책, 똑같은 도구를 갖고 배우는데 서로 다른 결과물이 나온다면, 조금만 논리적으로 생각해 봐도 차이를 결정짓는 것은 책이나 도구가 아니라 다른 곳에 있다는 결론을 내리게 된다.  

여기서 프로그래밍 학습에 있어 가장 중요한 부분이라고 말할 수 있는 언어 선택 및 학습 과정에 대하여 짚고 넘어가겠다. 먼저거의 대부분 첫 번째 언어를 잘못 선택함으로써 프로그래밍의 본격적인 재미를 느끼기도 전에 탈락한다. C/C++/자바는 원래부터만만한 언어가 아니다. 현실적으로 많이 사용하고 있는 이 언어를 많은 사람들이 배우기 어렵다고 말하는데 그 대답은 당연하다. 이전문언어는 매우 다양한 일을 해낼 수 있는 다목적 언어이며 전문 프로그래머의 경험 속에서 진화해 온 언어이기 때문에 어렵다.그냥 열렬한 컴퓨터 사용자였다가 갑자기 자기 손으로 프로그램을 만들고 싶다고 해서 제일 먼저 덤빈 언어가 C, C++, 자바와같은 전문 언어라면 여러분은 열 명 중 여덞, 아홉은 탈락할 것이다.  

필자 나이의 다른 프로그래머와 마찬가지로 필자의 첫 번째 언어는 베이직이었다. 필자는 아직도 이 언어에 대한 향수를 갖고 있을정도로 좋아한다. 이제 생각해 보니 행 번호 개념과 GOTO 문이 유치하게 느껴질 정도로 까마득하지만, 사용자에서 프로그래머가되기 위한 첫 번째 단계에서는 매우 유용한 중간 단계라고 생각한다. 베이직은 필자에게 인간의 논리가 아니라 컴퓨터의 논리입장(물론 이것도 창조한 사람이 만들어낸 것이지만)에 서서 자연스럽게 프로그래밍하는 것을 가르쳐 주었다. 지금은 전혀 사용하지않지만 매우 중요한 언어임에 틀림없다.  


단순 조급증에서 벗어나야 한다  
프로그래머가 되고 싶어하는 수많은 사람을 처음부터 확실하게 걸러내 준 악습 중 하나는 프로그래머가 되려면 마치 C, C++,자바 중 하나로 꼭 시작해야 한다는 강박 관념이다. 사람들의 책꽂이에는 최소 2~3 권의 C/C++/자바 책이 꽂혀 있다. 모두1/3도 보지 않은 채 방치되고 있을 것이다. 바이블에 해당하는 몇 개의 책을 구입했다가 포기하고 결국에는 '며칠 내에완성하기', '그냥 따라하기'라는 유혹적인 제목의 책을 마지막에 구입한다. 하지만 '21 일 완성하기'를 21일 안에 끝내는사람은 거의 보지 못했다. 원래 어려운 것을 쉽게 설명하는 일은 더 어렵다.  

현실에서 가장 널리 사용하고 있는 매우 현실적인 언어가 C, C++, 자바이기 때문에 처음에 언어를 배울 때부터 이 언어로시작하면 뭔가 큰 이득이 될 것이라고 생각하는 것이 바로 앞서 표현한 단순 조급증이다. 물론 뭔가에 빨리 도달하고 싶겠지만생각처럼 되지 않는다. 오히려 꽃도 피워보지 못하고 초반전에서 프로그래머의 세계로부터 탈락하는 지름길을 선택하게 된다.  

꿋꿋하게 버텨 살아남은 한두 명도 결국에는 잘못된 믿음의 피해자가 된다. 그들은 어렵게 어렵게 배운 C, C++, 자바로부터벗어나려고 하지 않는다. 마치 이 세상에 그 세 가지 언어만 있는 것처럼 살아가는데, 사실 살아남기는 했어도 어처구니없게도언어라는 도구의 노예가 되어 버리고 만다. 이들의 프로그래머적 성장은 이미 끝나버렸다.  

상처받은 사람들을 위한 언어, 파이썬  
물론 사회적으로 준비가 잘 되어 있는 것은 아니다. 서점에 가봐도 C와 C 유사 언어 외에 다른 언어에 대한 훌륭한 책이 많지도않다. 여러 가지 언어를 잘 구사하는 훌륭한 프로그래머도 많지 않고 강사는 거의 없다고 봐도 무방하다. 현재 훌륭한 정보의대부분은 인터넷에 뿔뿔이 흩어져 있고 대부분 영어로 작성돼 있는 것이 현실이다.  

이런 상황 속에서도 지금 막 프로그래머가 되고 싶어하는 사람들을 위한 첫 번째 언어로서, 그리고 기존 언어를 모두 맛보고,패배감을 가진 사람들이 자신을 재정비하고 다시 프로그래밍의 즐거움 속으로 빠져들기 위한 재충전용 언어로 '파이썬'이라는 언어를권하고 있다.  

아직 첫 번째 교육 언어로 채택하기에는 훌륭한 서적과 과정이 나와 있지 않은 상황이어서 필자가 처음 시작했던 베이직보다는 어려울것이다. 그러나 다른 언어에 의해 상처받은 사람들을 치유하는 치료용 언어로서는 상당한 효과를 볼 수 있다. 이 언어를 통해언어가 중요한 것이 아니라 인간의 사고력을 풍부하게 발휘하는 것이 중요하다는 사실을 배울 수 있다.  

여러분이 오히려 컴퓨터 언어를 단계적으로 여러 가지 배워감에 따라 자신이 진정 원했던 결과를 더 빠르게 그리고 더 견고하게 세워나갈 수 있다는 사실을 느끼길 바란다. 언어는 결국 교체 가능한 도구라는 사실을 알게 되고, 여러분의 필요에 따라 새롭게 배우고구사할 수 있다는 자세를 갖추는 것이 중요하다. 또한 2~3 가지 언어를 구사할 수 있어야 한 가지 언어만 알았을 때보다 훨씬더 심도깊게 언어를 사용할 수 있다는 사실도 깨닫게 될 것이다.  


다양한 오픈소스의 세계  
컴퓨터 언어를 배우는 플랫폼도 중요하다. 필자로 하여금 C, C++, 자바 이외에도 이 세상에는 수많은 언어가 있으며 수많은새로운 아이디어가 있다는 사실을 일깨워 준 것이 바로 리눅스와 오픈소스 세계다. 오픈소스는 필자에게 프로그래머로서의 새로운의지를 수혈해 준 주역이다. 여기서 파이썬을 포함해 LISP, 펄, Ada 등등 많은 언어를 접할 수 있었으며, 여러 번의외도(?)를 통해 오히려 이미 알고 있던 C 언어를 훨씬 더 잘 이해하고 어디에 어떻게 적절하게 사용해야 할 지 알게 되었다.무엇보다 각 언어마다 나름의 이유가 있으며 그 창조자의 생각을 어느 정도 이해할 수 있다는 즐거움도 만끽할 수 있었다. 다양한욕구를 가지고 있는 독자라면 리눅스에서 다양한 오픈 소스 언어를 만나 보기 바란다. 그리고 여러분이 눈길을 주기를 기다리는어마어마한 분량의 소스 코드가 널려 있다. 또한 멋진 것은 매우 초보적인 소스 코드부터 매우 전문적인 소스 코드까지 선택의 폭이넓다는 것이다.  

한편, 윈도우 플랫폼에서는 좋으나 싫으나 마이크로소프트의 제품 정책에 따를 수밖에 없으며(그나마 예외는 자바 정도) 따라서제품의 노예가 되어버리기 쉽다. 예를 들어 현재 프로그래머 사이에 논란이 되고 있는 C# 이라는 언어는 새롭게 출현해야 할정당한 논리적 이유없이 자바와의 전쟁 속에서 나온 사생아라는 지적이 나오고 있다. 직업적 프로그래머라면 새로운 언어와 규칙을배워야 하는 수고를 마다해서는 안되겠지만, 프로그래머가 되어 볼까 생각하는 사람들에게는 짜증나는 현실이다.  

조금이나마 다행스러운 것은 오픈소스 진영이 매우 성숙해 훌륭한 소프트웨어의 대부분이 윈도우와 매킨토시 등 리눅스/유닉스가 아닌플랫폼에서도 동작한다는 사실이다. 여러 플랫폼에서 동작하는 멀티 플랫폼 언어나 도구를 사용하는 것도 현명한 선택 중 하나다.  

웹 프로그래밍 언어에만 집착하지 말자  
마지막으로 언어 선택에 있어 웹 프로그래밍과 관련한 PHP, ASP, JSP에 대한 의견을 개진하고자 한다. 결과를 즉시 확인할수 있으며, 현재 유행하는 개발 영역의 언어이기 때문에 많은 사람들이 쉽게 시작하고 있지만, 이 언어들은 모두 실용 언어로서인간에게 프로그래밍하는 더 좋은 방법을 알려주지는 못한다. 따라서 전문 프로그래머가 되려면 이 언어에만 집착해선 안된다. 또한프로그래밍 본연의 지적 유희를 즐기려는 취미 프로그래머도 역시 이 언어에만 집착해선 안된다. 실전의 전문 프로그래머는 이들의한계를 분명히 인식하면서 사용한다. 실용 언어와 함께 일반 언어도 동시에 익혀 나감으로써 프로그래밍 사고력과 실용성을 모두성취할 수 있기를 바란다.  


직업적 프로그래머가 되고 나면  
프로그래밍이란 생계와 결부되는 매우 실용적인 영역임에도 불구하고 의도적으로 이 이야기를 지금까지 피해 왔다. 직업으로프로그래밍을 하고 있는 사람은 이 글을 읽으며 무슨 지적 유희냐고 화를 내고 있을 지 모른다. 실전에 들어가면 프로그래머의생활이란 다음과 크게 다르지 않다.  

* 자바 프로그래머로 입사했는데(사실 이 말 자체가 우습다. 프로그래밍 언어 중 자바도 구사할 수 있는 프로그래머라고 표현해야한다) 실제 프로젝트는 별로 사용해 본 적 없는 C++로 해야 한다고 팀장이 전달한다. 자기가 잘 모르는 언어로 프로그래밍을해야 한다는 부담감 때문에 매일 짜증내면서 어쩔 수 없이 새롭게 책을 구입해 쫓기듯 학습한다.  

* 쉬엄쉬엄 컴퓨터 앞에 앉아 이런 생각 저런 생각을 하면서 코드만 작성하고 만들어내기만 하면 되는 줄 알았는데, 거의 대부분의시간을 보고서와 설명서를 쓰는 데 허비하고 있다. 과연 내가 프로그래밍을 하고 있는지 문서 작성을 하고 있는지 한탄스러울 때가많다.  

* 열심히 만들었더니 주문한 고객의 마음이 또 바뀌어 모든 부분을 일일이 다 고쳐야 하는 일이 다반사다. 창조적이라기 보다는 코딩 막노동(?)이라는 느낌이 들면서 자신이 한심하게 느껴지기 시작한다.  

* 거의 대부분의 시간을 버그 잡느라고 머리털 빠지고 있다. 재미없는 디버거와 함께 하는 시간이 코드 짜는 시간보다 월등히 많다.  

이런 현실적인 문제들을 하나씩 짚어 가기 전에 필자는 독자 여러분에게 이 세상에 재미를 느끼게 해 주는 수많은 일들이 있는데프로그래밍을 자기 직업으로 삼은 이유가 무엇이냐고 우선 반문하고 싶다. 마음속으로 자기만의 답을 생각해 보고 앞서 나열한 네가지 문제를 하나씩 다뤄보자.  


새로운 언어를 적극 받아들이자  
번 문제를 살펴보자. 회사나 팀장의 요구가 부당하다고 생각할 지 모르지만, 자신이 모르는 다른 언어로 프로그래밍해야 한다는요구가 무조건적으로 틀린 것은 아니다. 사실 여러분이 직업적 프로그래머로서 직장 상사나 팀장에게 '나는 이 언어밖에못합니다'라고 말하는 것은 프로그래머로서의 자신의 진짜 가치를 고백하는 것이나 다름없다. 굳이 사회적으로 통용되는 표현을쓰자면, 한 가지 언어만을 전문으로 구사할 수 있다고 말하는 사람은 그 언어만 다룰 수 있는 기능사일 뿐이다. 기술자라면, 아니진짜로 프로그래머라면 새로운 언어를 배워야 한다는 것이 짜증나는 일이라고 단언해서는 안된다. 새로운 언어를 배워 나가는 것은전문 프로그래머의 일상 업무이다.  

물론 지금 당장은 답답할 지 모른다. 그러나 필자의 논지에 수긍한다면 어떤 언어든 자기가 구사할 줄 아는 언어의 전부가 아니라그 중 하나일 뿐이어야 한다. 팀장의 요구가 없다 하더라도 사실 유행에 따라 어쩔 수 없이 또 다시 끌려가야 하는 경우도 있지않은가. 원래부터 피할 수 없는 일이므로 적극적으로 받아들이자.  

문서화는 결코 어려운 일이 아니다  
번 문제를 살펴보겠다. 필자도 보고서를 쓰거나 설명서를 쓰는 작업은 태생적으로 싫어한다. 그러나 보고서나 설명서를 쓰는 작업자체가 프로그래머의 몫이 아니거나 또는 무가치한 일로 보는 입장에는 동의할 수 없다. 물론 형식화한 보고서, 설명서를 쓰는 것은매우 지겹고 화나는 일이다.  

보고서와 설명서를 쓰는데 많은 시간이 걸리는 이유는 두 가지를 들 수 있다. 원래 문서화 작업이라고 하는 것이 생각보다 시간이많이 걸리는 작업이다. 우리의 머리 속에 있는 것을 글로 표현한다는 것이 쉽지 않다는 사실은 어렸을 때부터 독후감 쓰는 일이쉽지 않다는 경험으로부터 잘 알고 있을 것이다. 글로 표현한다는 것은 자유롭게 흘러가는 생각을 그대로 반영하는 것이 아니라 한번 더 숙고해 체계화하는 과정이기 때문이다(필자 또한 지금 이 원고 쓰는 일을 흔쾌히 승낙해 놓고서는 얼마나 후회하는지모른다).  

그러나 무엇보다도 자신이 글을 쓰는 일에 익숙하지 않다고 스스로를 묶어 버림으로써 문서 작업을 싫어하고 집중할 수 없게 되는수도 있다. 자기 최면을 통해 집중하지 않음으로써 여러분은 자기가 싫어하는 일에 더 많은 시간을 할애할 수밖에 없고 그 만큼여러분이 원하는 작업에 필요한 시간을 허비하고 있다.  
리눅스나 오픈소스라고 해서 마냥 코딩만 하고 문서화는 전혀 안한다고 생각하면 오산이다. 최소한의 README, 잘 만들어진문서가 없는 오픈소스 소프트웨어는 초보 프로그래머의 작품일 뿐이다. 이미 수준 높은 품질의 아파치, 삼바, 리눅스 커널을 보면상당히 친절한, 하지만 작성한 사람 입장에서는 많은 노력을 들인 문서들이 포함돼 있다는 사실을 알게 될 것이다.  

문서화 또한 현명한 대처가 필요하다. 막무가내로 불필요한 분량의 문서를 요구하는 팀조직이 있다면 매우 고루한 조직임에 분명할것이다. 이러한 조직에 대해 말할 수 있는 해결책은 없다. 그 조직은 여러분이 선택한 것이다. 너무 불합리한 경우가 아니라면,문서화 작업을 소프트웨어 디자인의 일부로 여기는 능동적인 자세가 필요하다.  
코딩을 할 때 소스 코드에 주석(comment)을 넣지 않는 것은 전문 프로그래머로서의 자질이 없음을 단적으로 보여 주는것이므로 주의하자. 직업적 프로그래머라면 어떤 일이 있어도 소스 코드는 주석으로 시작해서 주석으로 끝나야 한다.  

문서화란 어떻게 보면 그렇게 어려운 것도 아니며 프로그래밍의 필수 과정이기도 하다. 기본적으로 소스 코드의 주석, README,INSTALL, 그리고 TODO(앞으로 할 일), 각 버전간의 변경 사항을 적는 Changes 문서는 모든 문서화의 기초가된다. 아직 직업 프로그래머로 취업하지 않는 예비 프로그래머는 지금부터라도 이를 습관화하기 바란다.  
많은 사람들이 오해하고 있는 것을 하나 지적하고자 한다. 대부분 프로그래밍을 코딩에 쏟은 시간만 갖고 평가하려는 경향이 있다.그러나 앞서 'program'의 어원을 알아보면서 확인한 것처럼, 프로그래밍에서 가장 중요한 것은 계획이다. 계획하고 기획한것을 좀 더 구체적인 방법으로 설계하고 언어를 통해 구현하고 중간 과정을 기술하는 모든 행위가 프로그래밍이다.  


'간략한' 프로그램을 위해 노력하자  
번 문제로 넘어가겠다. 일단 계획이 서면 거침없이 코드를 작성하고 고치지 않을 것 같지만 몇 명의 천재적인 프로그래머를제외하고(실제로 그런 사람이 있는지 궁금하다. 자기가 수없이 반복하면서 얻은 경험에 의지해 거침없이 하는 것은 아닐까?) 거의모든 프로그래머는 그런 식으로 프로그래밍하지 않으며 할 수도 없다. 열심히 프로그래밍했다고 생각했는데 일 년이 지나 소스 코드개수와 줄 수를 세 보고나면 자괴감에 빠질지도 모른다.. 실제로 우리는 끝없이 고치고 고치고 또 고친다. 그러면서 소프트웨어가견고해 지는 것이다.  

그리고 현실 세계에서 고객의 요구는 첫 번째로 중요하다. 그들의 요구가 변화하는 것은 당연하다. 훌륭한 프로그래머는 고객이처음부터 정확한 요구 사항을 제시하도록 유도하고 변화의 폭이 제어할 수 있는 범위 안에 들 수 있도록 잘 안내한다.  
소프트웨어의 기능을 잘 구분하고 반복적인 패턴을 함수/라이브러리/모듈화하지 못하는 초보 프로그래머는 똑같은 소스 코드를 여기 저기 복사해서 쓰게 되는데, 이 때는 소프트웨어를 고치는 일이 곤역스러울 수밖에 없다.  

전문 프로그래머라면 반복적인 패턴을 훨씬 더 많이 찾아내고 압축하는 기술을 가꿔 나가야 한다. 다시 한 번 말하지만 반복적인경험에서는 얻을 것이 별로 없다. 그 수많은 경험 중에서 문제 해결을 위해 고민한 시간만이 소중한 경험이다.  
고객의 변덕에 따라 짜증이 날 정도로 많이 고쳐야 한다면, 그것은 오히려 여러분에게 더 많은 경험과 사고가 필요하다는 증거이다. 같은 일을 하더라도 지난번보다는 더욱 더 간략하게 프로그램을 작성할 수 있도록 노력하라.  

디버깅은 불필요한 일이 아니다  
번 문제를 생각해 보자. 우리의 예상과 달리 프로그래밍 중에서, 특히 프로그래밍의 일부분인 코딩 중에 새로운 코드를 만들어 내는시간보다는 기존의 코드를 개선하거나 잘못된 코드를 찾아내는 일에 절대적으로 많은 시간을 쏟는다고 한다.  

필자의 경우도 예외는 아니었다. 그러나 경험을 토대로 스타일을 바꿔나가기 시작했다. 필자가 제일 많은 시간을 쏟는 부분은 자료수집과 연습 코드 부분이다. 필자의 경우에는 무조건 책이나 웹을 통해 관련 자료를 수집하고 재빨리 훑어 내려간다. 다 이해하지못해도 상관없다는 듯이 읽어 내려간다. 특히 요즘은 노하우보다 노웨어가더 중요하다고 말하지 않는가. 이미 많은 문제의 일부분을다른 사람이 해결했을 가능성이 높다. 이를 반복할 필요는 없다. 현 시대에서 요구하고 있는 프로그래머의 자질 중 하나는 처음부터다시 만드는 것이 아니라, 기존의 것을 취사 선택해 창의적으로 결합시키는 능력이다.  

그 다음에는 짧은 연습 코드를 많이 작성한다. 핵심적인 부분에 대한 연습 코드를 몇 번 작성하다 보면 프로그램의 절반이 끝났다고해도 과언이 아니다. 개인적으로 자료 수집과 연습 코드, 특히 연습 코드에 신경을 많이 쓰는데 이렇게 함으로써 프로그래밍과정에서 절대 빠질 수 없는 디버깅(debugging)을 최대한 피할 수 있다고 생각하기 때문이다.  

하지만 어떤 식으로든 디버깅 과정을 피할 수 있다고 생각하지 말라. 사실 버그를 얼마나 빨리 잡는가, 그 짜증나는 시간을 어떻게빨리 마칠 수 있는가는 그가 얼마나 유능한 프로그래머인지 판단할 수 있도록 해 주는 잣대이다. 디버깅이 마치 불필요한 과정이라고생각하지 말았으면 한다. 여러분이 만든 버그야 어떻게 잘 피할 수 있을 지 몰라도 실전에서는 남이 만들어낸 버그를 찾아야 할때가 많다. 그런데 남이 만들어낸 버그를 잘 찾는 사람이란 결국 알고 보면 자기 자신도 똑같은 버그를 만들어 보았고 고통스러운시간을 통해 버그를 찾아낸 경험이 많은 사람이다.  

디버깅에서 중요한 자세는 절대 짜증내지 말고, 적군을 무찌르겠다는 식의 투지를 갖고 단시간 안에 돌파하는 것이다. 만약 한 가지방법이 실패했다면, 잠시 먼 발치에서 새로운 구상을 한 뒤, 다시 전투적으로 임한다. 지루하게 디버깅을 하면 시간도 많이 걸리고정신도 피폐해진다.  

결론적으로 정도의 차이가 있을 뿐, 여러분이 현실 세계에서 당면하고 있는 모든 문제는 피해야 할 어떤 일이 아니라 사실프로그래밍이라고 하는 전체 과정에 원래부터 속해 있던 일부라는 사실을 인식하고 이에 대해 짜증을 내는 수동적인 방식이 아니라 좀더 현명하게 그리고 적극적으로 자기만의 해결책을 찾아나가길 기대하겠다.  


몇 가지 실천안  
다음 실천안은 여러분이 좀 더 프로그래밍을 즐길 수 있고 직업적으로도 유능함을 발휘할 수 있게 되길 바라며 마음속에 떠도는 생각을 아주 간략하게 정리해 본 것이다.  

◆ 프로그래밍이란 절대 코딩이 아니다. 먼저 생각하고 만든 것을 정리하고 문제점을 해결해 나가는 모든 과정이 프로그래밍이다. 이 점을 자기 자신에게 충분히 납득시켜야 한다. 코딩은 프로그래밍의 일부이다.  
◆ 각 언어는 모두 나름의 탄생 이유가 있으며 그 언어를 만든 사람의 아이디어가 담겨 있다. 언어를 먼저 선택하려 하지 말라. 유능한 프로그래머는 절대 한 가지 언어에 집착하지 않는다.  
◆ 언어를 처음 배울 때에는 그에 걸맞게 쉬운 언어부터 시작하라. 실전에서 사용하는 언어를 먼저 배워두면 더 이득이 될 것이라고생각하지 말라. 전문 프로그래머가 되려면 최소한 세 개 이상의 언어를 익혀야 한다. 물론 세 가지 언어를 똑같이 잘 할 필요는없다. 자기 주 종목 언어를 갖지 말라는 말이 아니다.  
◆ 책을 다 읽고 나서야 프로그래밍할 수 있다고 생각하지 말고 배운 만큼만 갖고도 연습 코드를 작성할 수 있어야 한다.  
◆ 언어 그 자체는 여러분의 상상력을 키워주지 않는다. 상상력은 여러분 스스로 인생의 모든 영역에서 듣고 배우면서 채워야 한다.언어는 상상력을 실현할 도구만 제공할 뿐이다. 과학과 수학에 관심을 가져 보라(그렇다고 해서 A 등급을 맞을 만큼 잘 할 필요는없다).  
◆ 주석 및 문서화 버릇을 들이자. 프로그래밍의 귀찮은 일부가 아니라 매우 중요한 핵심 부분이다.  
◆ 언어책이 줄 수 있는 지식의 양은 딱 그 만큼이다. 여러분의 상상력과 프로그래밍 능력을 살찌워주는 것은 다른 사람, 다른프로그래머다. 적극적으로 프로그래밍 사용자 모임 또는 뉴스그룹에 참여해 남을 돕고 남으로부터 도움을 받는 것이 자기 계발의원천이다.  
◆ 자기가 습득한 지식은 자신만이 볼 수 있는 형태든 아니면 홈페이지를 통해 누구나 볼 수 있는 형태든 상관없이 정리하는 습관을갖자. 무엇이든 막상 글로 적으면 자신이 얼마나 피상적으로 알고 있는지 각성하게 되고 지식을 좀 더 견고하게 만들게 된다.  
◆ 현실은 현실이다. 영어를 잘 못하고 두려워하는 사람이 최고의 프로그래머가 되기는 거의 불가능하다. 여러분이 한국어만 하면한국 프로그래머의 지식만 습득할 수 있을 뿐이다. 영어를 두려워하지 않는다면, 그 대가는 전세계 프로그래머의 지식 습득이된다(영어를 잘 하는 방법은 영어를 잘 하는 사람에게 물어보라).  

아무튼 여러분이 프로그래밍의 본질을 재확인하고 프로그래밍하는 그 과정을 즐길 수 있는 사람이 될 수 있기를 바라며 글을 마친다. 

출처 : Tong - I제로I님의 알아두면 좋은 자료통

Posted by SB패밀리

개발자 이력서 10계명




#1: 보유 기능 목록을 제일 앞에 올리라
고용 담당자는 회사가 찾고 있는 기능을 보유하고 있는지 알고 싶어 한다. 물론 "경력" 란에 구직자의 보유 경력이 잘 나오겠지만, 이력서 상단에 "보유 기능" 란을 넣으면 자연스럽게 그 부분을 제일 먼저 보게 된다. 

당연히 그런 이력서를 고르기가 더 쉽다. 동시에 그렇게 하지 않았다면 고용 담당자들이 놓쳐버렸을 수 있는 기능에 관심을 가지게 한다는 장점도 있다. 최소한 고용 담당자는 그 보유 기능 목록을 보게는 된다.

#2: 눈길을 끄는 방식으로 경력을 소개하라
일자리를 구하는 대부분의 개발자들은 데이터 중심형 웹 사이트나 데스크톱 애플리케이션을 만든 적이 있다. 따라서 이력서에 그런 일반적인 예를 잔뜩 써 넣는 것은 별로 눈길을 끌지 못한다. 장래의 고용주가 관심을 가지는 것은 독특한 무언가가 있는 경력, 즉 단순히 기본적인 수준의 프로그래밍 작업을 한 것이 아님을 보여주는 경력이다. 

독특한 제약 조건이 적용되는 작업을 했거나 트랜잭션이 많이 발생하거나 무장애 실행을 요구하는 환경에서 일한 경력은 이력서를 보는 사람에게 아주 좋은 인상을 준다. 즉, 자신의 경력이 남과 다르다는 것을 보여주어야 다른 사람이 그를 남다른 사람으로 보게 된다.

#3: 문법, 철자 및 기타 일반적인 실수를 샅샅이 찾아내어 고치라
고용 업무를 담당하는 동안 필자는 이력서에서 온갖 종류의 문법 오류나 철자 오류를 보았다. 가장 황당했던 경우 중 하나는 자기가 졸업한 대학교의 철자를 잘못 쓴 경우였다.

이력서에는 몇 가지 독특한 문법적인 규칙이 관련되며, 특히 소프트웨어 개발 작업에는 약어나 철자가 특이한 단어들이 관련되는 경우가 많다. 하지만 어떤 경우에도 변명의 여지가 없다. 철자나 문법상으로 실수가 없는지 확인해야 한다. 이 점은 필자가 읽어 본 모든 이력서 관련 지침에 빠지지 않고 나오며, 분명히 강조할 가치가 있다.

#4: 학력은 고려 대상이지만 중요하지는 않다
프로그래밍 구직 시장에 이제 막 발을 들여 놓은 사람이나 아주 전문적인 자리를 얻기 위해 이력서를 쓰는 것이 아닌 한 학력은 별로 중요하지 않다. 물론, 이력서에 학력이 빠질 수는 없지만 제일 마지막에 넣는 것이 좋다. 

학력에 대해 알아야 하거나 알 필요가 있는 고용 담당자라면 학력 부분까지 읽을 것이고, 그 외의 사람들은 학력을 보느라 시간을 허비할 필요가 없다. 프로그래밍 계통은 변화가 너무 심하기 때문에 7년쯤 뒤에는 (수학이나 "순수" 컴퓨터 공학과 같은 "원론적인" 과목 이외에는) 대부분의 학과목과 자격증은 현재의 실제 업무와 거의 관계가 없다.

#5: 빨리 본론으로 들어가라
전통적인 이력서 형식에는 개발 담당자가 볼 때 필요하지 않은 정보가 많이 포함되어 있다. 예를 들면 요약 부분이 그런 정보이며 아마도 목표 부분도 그렇게 볼 수 있을 것이다. 

사실 이력서보다 더 간단한 내용으로 프로그래밍 경력을 표현하는 요약을 쓸 수 있는 방법은 없다. 대부분의 요약 항목이 아무 쓸모없는 정보로 보이는 이유가 바로 그것이다. 예를 들어 주요 기능을 기록한 부분 앞에 붙어 있는 "10년 개발 경력의 노련한 프로그래머"라는 표현이 무슨 의미가 있겠는가? 고맙지만, 없으면 더 고맙겠다.

목표는 (항상은 아니지만) 쓸모 없는 경우가 많다. 전직하려는 경우라면 목표는 고용 담당자가 당신의 보유 기능과 경력을 기준으로 당신을 분류하지 못하게 하는 좋은 방법이 될 수 있다. 

하지만 선임 개발자 자리로 옮기려고 하는 중급 프로그래머는 목표를 생략해도 무방하다. 소프트웨어 아키텍트나 DBA가 되려고 하는 선임 프로그래머는 목표를 밝혀야 한다. 따라서 요약 부분은 어떻게든 빼고 쓸모 있는 목표만 포함시켜 이력서를 보는 사람이 당신의 보유 기능을 가능한 한 빨리 볼 수 있게 하라.

#6: 서식을 주의 깊게 고려하라
이력서 서식은 중요하다. 고급 용지에 이력서를 인쇄하여 발송하던 시절은 오래 전에 지나갔지만 컴퓨터 화면으로 보든 종이로 된 문서이든 간에 이력서는 서식이 있어야 한다. 어쨌든 이력서를 쓰려면 상당한 균형 감각을 가져야 한다. 지금은 자신의 피카소 같은 감각을 과시하는 시대가 아니다. 

원하는 자리가 시각적인 예술 감각과 관련이 있는 것이 아닌 한 그렇다. 지금은 가독성을 높여야 하는 시대이다. 가독성을 높이려면 더 큰 글꼴(10~12포인트)를 사용해야 하며 (문서 포맷에 글꼴이 내장되지 않는 한) 모든 컴퓨터에서 사용하는 글꼴이어야 함을 의미한다. 한 마디로 화면으로 보든 인쇄해서 보든 간에 보기 좋아야 한다. 

추천할 만한 영문 글꼴은 Verdana, Arial, Tahoma, Calibri, Helvetica 등이다.

문서가 너무 빽빽해 보이지 않도록 여백을 충분히 두어야 한다. 그래야 보는 사람이 질리지 않는다. 반대로, 겨우 200단어를 여덟 페이지로 만들 정도로 공간을 낭비하지 말라. 

물론, 파일 자체의 포맷은 중요하다. 필자의 경험으로는 사원 모집 담당자들의 99.9%는 접수된 이력서가 다른 포맷으로 되어 있으면 MS 워드 포맷의 이력서를 요구한다. 따라서 표준 .doc 포맷으로 문서를 만들어야 한다.

이력서가 자신을 상품으로 소개하는 주요 도구라는 사실을 항상 염두에 두어야 한다. 이력서를 보는 사람이 이력서에 담긴 정보를 이해하는 데 어려움이 있다면 그것이 기술적인 문제이든 가독성 문제이든 간에 그들은 즉시 다음 이력서로 넘어간다.

#7: 길이에 주의하라
문서 포맷에 관계 없이 아주 특별한 상황이 아닌 한 분량을 2~4페이지 정도로 제한하라. 단기 계약직으로 일하는 데 많은 시간을 보내는 사람들이라면 이력서가 비교적 길 것이며 막 구직 시장에 뛰어든 사람이라면 이력서가 짧을 것이다.

전반적으로 기존의 1페이지 분량의 이력서 서식 안에 자신의 기술적인 보유 기능과 하나 이상의 직장 경력을 적절하게 부각시키기는 어렵다. 2페이지는 중급 개발자나 선임 개발자를 기준으로 한 것이다. 

하지만 4페이지 이상이면 이력서를 보는 사람의 눈이 침침해진다. 학력과 마찬가지로 7~8년 전에 가졌던 경력은 별 관계가 없지만, 고용 담당자는 담당한 책임이나 프로젝트 수준이 점점 높아지는 과정을 보고 싶어한다.

#8: 경력을 적절하게 정리하라
프로그래밍은 취업 경력 면에서 대부분의 분야와 차이가 있다. 우선, 많은 프로그래머들은 계약직이기 때문에 취업 경력은 줄줄이 이어지는 형태가 되기 마련이다. 뿐만 아니라 닷컴 불황이 지난 지 그렇게 오래 되지 않았으며, IT는 항상 파산, 인수, 합병이 많이 이루어지는 산업계였다.

문제는 고용 담당자는 단기직 경력이 길게 나열된 이력서를 좋아하지 않는다는 점이다. 이력서에 직책이 점점 높아지는 취업 경력이 쭉 이어지고 있다면 충성심이 없는 사람으로 보일 수 있다. 반면에 직무가 기본적으로 동일(하거나 점점 낮아)지는 것처럼 보인다면 실직자라는 느낌을 준다. 

계속 단기직으로 일한 정당한 이유가 있다면 반드시 그 이유를 명확하게 밝히라. 예를 들어 계약직/컨설팅 직은 명확하게 표시하라.

#9: 이력서를 보는 사람에게 법적인 부담을 주지 마라
어떤 고용 담당자도 고용 과정에서 편파적이거나 차별 대우를 했다고 고발 당하는 것을 좋아하지 않는다. 그런 행동은 비윤리적일 뿐만 아니라 불법이다. 따라서 직무를 올바르게 수행하려고 애쓰고 있는 고용 담당자는 신청인에게 해서는 안되는 질문을 잘 알고 있다. 

바꿔 말하면, 이력서를 내는 사람은 그런 내용을 이력서에 포함시켜서는 안된다. 고용 담당자가 알 필요가 없는 그 외의 개인적인 정보도 많다. 관련이 없는 내용을 이력서에 자세히 밝히면 고용 담당자는 겁을 먹고 수동적이 된다. 그런 구체적인 내용은 밝히지 말기 바란다.

#10: "튀는 사람이군!"
고등학교에서 튀는 행동으로 왕따를 당하는 것을 좋아하는 사람은 없다. 하지만 지금은 프로그래머로 일자리를 찾고 있는 중이다. 고용 담당자들은 "튀는 사람"을 "돈덩어리"로 본다. 따라서 그들에게 자신이 총명하며 프로그래밍을 사랑하고 끊임없이 성장하면서 새로운 아이디어를 배우고 탐구하는 사람임을 보여줄 수 있는 방법을 찾으라. 

오픈소스 프로젝트에 참여하고 있거나 동네 아이들에게 프로그램을 가르치는 자원 봉사 활동을 하고 있다면 그런 취미 활동에 대해 이야기하라. 그런 정보를 통해 고용 담당자들은 당신이 퇴근 후에도 프로그래밍이나 컴퓨터를 다룰 만큼 그런 것을 좋아한다는 것을 알게 된다.

고용 담당자들이 이 문제를 보는 논리는 정말 단순하다. 현재 두 명의 후보자들이 거의 비슷한 수준이라면 내일은 열정이 있는 후보자가 업무를 "단순한 직업"으로 취급하는 후보자보다 훨씬 더 발전해 있기 마련이라는 것이다.

출처 : 인터넷

Posted by SB패밀리

개발자와 영업직원간의 의사소통을 위해서...


뭐, 업무시간이나 그 외시간이나 의사소통의 여유가 있고 방법에서도 서로의 환경을 존중해주면 

문제가 없지만 그렇지 않고 한 쪽이라도 업무가 바빠서 또는 서로의 의사소통 방식을 존중해 주지 않는다면....

의사소통이 되지 않을 것이다.



골프처럼 야구장도... 친근해지고 이야기하기 좋은 곳이 될 수 있겠다.



한 쪽 업무가 바쁠때를 생각해보자... 거의 힘들다.


그렇다면.. .여유가 되는 시간은 언제 일까?

식사시간, 담배 피우는 시간, 커피 한잔으로 머리를 환기시키는 시간, 술 마시는 시간.... 등이 있을 것이다.


나의 경우는 야간에 머리도 식힐겸 야근을 할 때 영업직원도 야근을 하고 있다면

서로간에 이야기를 하기가 좋지 않을까 생각을 해보곤 했었다.


어떤 경우... 술자리를 갖는 것에 대해서 편애하는 경우도 보았다.

술자리가 아니면... 친해지기어렵고 말을 섞기가 어렵다는...


술자리는 한 사례지만 개발자나 영업직원 모두 한가지 방법을 고집하기 보다

상대를 배려한 또는 서로가 부담없이 이야기를 할 수 있는 자리가 필요한게 아닐까 싶다.


개발자가 자신이 사용하는 한가지 툴이 아니면 개발을 할 수 없다는 말을 하는 경우가 있는데

영업직원이 술자리 아니면 말하기가 어렵다고 하는 것도 별반 다를 바 없다.


위에서 말 한 사례만이 아니라 분야가 다르더라도 우선 서로를 신뢰하고 배려하면서

이야기를 풀어간다면 부서간의 화합도 될 수 있고 다른 업종에 대한 긍정적인 선입견을 가질 수 있을 것이라는 생각이다.





Posted by SB패밀리

이런 말들이 예전부터 있다.


영업직원이 개발직원에게 질문을 했을 때

답답해하면서 "검색 한 번만 해보면 알 걸 가지고 불편하게 질문을 한다"고

반대로 개발직원이 영업직원에게 질문을 했을 때

답답해하면서 "신문에 다 나와 있는데 신문한 번 보면 될 것을 질문 한다"고 한다는

내용의 영업직원과 개발직원간의 불편한 진실...


흔히 영업직원이 개발직원에게 어떤 기능이 되냐고 물었을 때


"안되는데요"


라고 개발직원이 이야기 하는 경우가 많다고 한다.

개발직원은 (현재 조건으로는) 안되는데요라는 말을 단순히 안되는데요

라고 하는 경우가 많다.


개발직원이 영업직원에게 이 물건을 팔 수 있냐고 물었을 때


"안되는데요"


라고 대답하는 경우가 있다.


둘다의 경우 "안되는데요", "모르겠는데요"라고 대답이 끝나버리면 초급이거나 무능하다고 해야할 것이다.


반면


"알아봐야겠는데요", "해봐야겠는데요", "가능할 것 같습니다"


라는 대답이 나오면 정답일 것이다.



Posted by SB패밀리




얼마나 배워야 하나요?
2003.12.18 17:35  

류(ryujt)   http://cafe.naver.com/codeway/6 


얼마나 배워야 하나요?


가끔 프로그래밍을 시작하려고 하거나 입문과정에 있는 분들에게 받는 질문이다. 그리고, 때로는 자신의 위치가 어느 정도가 되는지 항상 의문을 가지는 사람들에게로부터 같은 질문을 받는다.

본인이 그러한 것에 대한 권위적인 기준을 남에게 이야기할 만한 자격은 없지만, 나름대로 생각한 기준을 말해보고자 한다. 지금부터 이야기하는 것들은 본인 자신의 개인적인 기준일 뿐, 그 어떠한 권위적인 해석이나 정보를 바탕으로 하고 있지 않음을 미리 알려둔다.

우선 본인은 개발자의 등급분류를 준비과정, 입문과정, 초급, 중급, 고급, 특급으로 나누고자 한다. 여기서 입문과정과 준비과정이 다소 애매하다. 프로그래밍을 시작하면 무조건 입문과정이라고 분류할 수 있을 것이다. 하지만, 그 입문과정을 준비과정과 입문과정 둘로 나누고 싶은 데에는 이유가 있다.

준비과정은 공부를 시작한 지 최소 1개월 정도를 생각한다. 이 과정 중에는 개발에 대한 전반적인 이해와 개념을 공부하는 과정이다. 이러한 공부는 상당히 지겨운 편이다. 공부하는 동안 그 결과가 겉으로 들어나지 않기 때문이다. 하지만, 본인은 조금은 여유를 가지고 살펴보기를 강력히 권장한다.

대부분의 사람들은 무엇을 배울 때, 상당히 조급한 경향이 있다. 그리고, 그 조급함으로 인해 무엇인가 빨리 터득했다고 믿는다. 또한, 항상 자신이 빠르게 배웠음을 자랑으로 여긴다. 하지만, 이러한 사람은 임계점에서 실력이 향상되지 않는 슬럼프를 꼭 겪게 된다.

준비과정에서는 프로그래밍 자체보다는 자신이 선택한 개발영역에 대한 포괄적인 이해에 대하여 집중해야 한다. 이것을 공부해 나가는 동안 여러분들은 개발에 관한 전체적인 안목을 얻을 수 있는 좋은 기회가 된다. 편협한 지식은 가끔 문제해결을 하고자 할 때, 상당한 방해가 된다. 마땅히 공부할 자료를 제시하기는 어렵지만, 전산학개론 정도가 될 것이다.

입문과정은 6개월 정도를 생각한다. 이 과정 중에는 선택한 프로그래밍 언어 자체에 대한 수련을 하는 과정이다. 우선은 문법체계와 프로그래밍에 대한 절차에 대해서 공부를 하고, 이후 다양한 문제해결에 대한 실전적인 연습이 필요하다. 굳이 책에 집착하지 말고 자신이 하고자 하는 새로운 프로젝트 또는 문제를 설정하여, 이를 선택한 언어를 통해 해결해 나가는 동안 그 언어에 대한 감각을 길러 가는 것이다.

프로그래밍은 지식보다는 감각적인 요소가 상당히 중요하다. 그것은 프로그래밍을 실무에 접했을 때, 그 문제의 해결을 위한 그 어떠한 정석도 존재하지 않기 때문이다. 비슷한 업무에 대한 개발을 계속적으로 진행하더라도, 결국 구현단계에서는 언제나 새로운 문제가 기다리고 있다. 이러한 것들을 단순히 암기된 지식의 결합 및 수정으로는 해결할 수가 없다. 특히 알고리즘에 관한 공부를 게을리하지 않기를 바란다.

이제, 위에서 거론된 두 과정을 지나면 여러분들은 초급 프로그래머라고 할 수 있을 것이다. 그리고 이 초급은 최소 1년에서 2년 이상 거쳐야 한다고 생각한다. 이후 중급은 4년 이상 그리고 고급과 특급은 기간자체가 중요한 요소라고 생각하지 않는다.

입문과정이 전반적이 이해와 감각을 키우는 과정이라면, 초급과정에서는 스킬을 중점으로 공부하는 과정이라고 생각한다. 입문과정은 다소 포괄적인 공부를 하는 단계라고 한다면, 자신의 개발영역을 조금씩 넓혀가면서 심도 깊게 연구하는 단계이다.

초급, 중급, 고급, 특급 개발자들의 기준은 다음과 같이 정리해봤다.


초급 
     - 제한된 범위의 단위 모듈에 대한 코딩 능력
     - 작성된 모듈에 대한 수정 및 변경 능력
     - 프로그래밍에 대하여 상급 개발자의 조언에 의존하는 단계

중급 
     - 설계서를 토대로 스스로 프로그래밍의 문제를 해결할 수 있는 능력
     - 개발절차와 흐름에 대한 완벽한 이해

고급 
     - 프로젝트의 위험요소를 미리 판별하고 대응하는 능력
     - 설계능력
     - 리더십
     - 풍부한 개발 경험

특급 
     - 기술적인 사회적 흐름을 예측하는 능력
     - 대인관계와 대응에 대한 능력
     - 풍부한 사회 경험
     - 회사내의 개발전략을 작성하고 영업과 경영에 대한 조언 및 보조 능력

Posted by SB패밀리

[개발/컬럼] 개발자가 야근을 하면 회사가 발전할까? 


개발자가 야근을 하면 과연 회사가 발전할까요?

 

"개발자가 정한 일정을 회사가 받아들여주지 않는다"


경영자 중에는 정말로 꽉 막힌 사람이 있어서 논리적으로 설득하려고 하면 
화를 내고 고성을 질러 잠재우는 사람도 물론 있지만 
설득하기에 따라서 개발자의 말을 들어주는 사람도 분명히 있습니다.
저의 경우에는 아래와 같은 논리로 합리적인 일정의 필요성을 호소합니다.
회사에서 촉박하게 일정을 잡고 개발자를 야근 시키는 이유는 역시 돈을 많이 벌기 위해서인데 
장기적으로 볼 때 촉박한 일정과 개발자의 야근은 회사의 수익을 줄어들게 만든다고 생각합니다.

 

<경영진/영업팀에서 기대하는 프로젝트 진행 과정>
 1 경영진/영업팀에서 갑과 상의하여 프로젝트 완료 일정을 결정
 2 개발자가 최선을 다해서 정해진 일정에 프로젝트 완료
 3 짧은 기간에 프로젝트를 완료해서 회사의 이익이 높아짐

 

<실제 프로젝트 진행 과정>
 1 경영진/영업팀에서 갑과 상의하여 프로젝트 완료 일정을 결정
 2 시간 부족으로 인해 [요구사항 분석] -> [기획] -> [설계] 모두 부실해짐
 3 개발기간이 부족한데다 잘못된 [기획], [설계] 로 인해 개발 중 요구사항이 계속 추가, 수정되어 부실한 결과물 또는 완료일 지연
 4 수준 낮은 결과물로 인해 고객의 신뢰 하락, 개발비 받지 못하거나 줄어듬, 영업 안됨

 

 

회사에서는 촉박하게 일정을 잡으면 돈을 많이 벌 수 있을거라고 생각하지만 
이렇게 하다 골로 가는 회사 여럿 봤습니다.


<경영진/영업부에서 기대하는 개발자의 직장생활>
 1 많을 일을 하기 위해 개발자는 매일 야근
 2 개발자 능력 향상 및 회사의 수익증가

 

<실제 개발자의 직장 생활>
 1 많은 일을 하기 위해 개발자는 매일 야근
 2 실력있는 개발자의 경우 야근이 힘들어서 개발환경이 더 좋은 회사로 이직
 3 회사의 개발 노하우도 다른 회사로 이동
 4 신입 및 다른 회사로 이직할 능력이 없는 개발자만 남음
 5 기존 개발, 운영중인 프로젝트에서 사고 발생 증가. 경영 상황 악화


우리나라에서 개발자를 고용해줄 회사가 하나밖에 없다면 그렇게 개발자를 혹사 시켜도 상관 없겠지만 
우리나라에는 개발자가 필요한 회사가 생각보다 많고 개발자의 경우 이직이 쉽고 
노예 취급하는 회사를 위해 충성을 다할 개발자는 없습니다.
실력 있는 개발자일 수록 더 좋은 환경의 회사를 찾아간다는 것을 대부분의 경영자는 생각하지 못하는듯 합니다.
회사가 발전하려면 좋은 개발자를 확보하여야만 하고 좋은 개발자를 모으기 위해서는 
좋은 대우를 해주는 수 밖에 없다고 생각합니다.

 

출처 : 인터넷

--------------------------------------------

 

위 이야기는 모든 회사가 그런 것은 아니지만 다수의 회사들이 위와 같은 증상을 갖고 있는 것으로 생각이 됩니다.


사실, 인재를 함부로 부리다가 나가면 다시 뽑으면 되겠지 하는 회사는 결국, 더 좋은 인재를 구할 수 없고
좋은 인재도 퇴사하게 됩니다.
결국, 새로운 인재를 교체하면되지라는 생각보다는 현재 회사의 인재의 역량을 더욱 강화시켜서 
회사의 수익을 창출하는 방법이 더욱 효율적이라는 생각입니다.

Posted by SB패밀리

[개발/컬럼] 소프트웨어는 누가 개발해야 하는가?


소프트웨어는 누가 개발해야 하는가?

김국현(IT평론가)   2006/07/27  
     



소프트웨어는 누가 개발해야 하는가? 세상에 이런 우문이 어디 있느냐 생각할지도 모르겠다. 그리고 '개발자'라 짧게 대답할 것이다. 개발자라는 세 글자에는 외부에서 고용된, 그마저도 몇 단계의 하청을 거쳐, SI 업의 하류 공정을 묵묵히 맡고 있는 젊은이의 초상이 투영된다. 

정말 소프트웨어는 그들만의 몫일까? 일견 당연해 보이는 이 상식을 이제는 벗어 버려야 할 때다. 소프트웨어란 '갑'이, 그 중에서도 '현업'이 개발해야 하는 것이다. '을'이 개발하고 ‘갑’은 검수를 하는 현재의 안이한 세태로는 기업이 지녀야 할 속도와 유연성은 참 갖추기 힘든 일이다.

요즈음, 기업의 IT 시스템을 짓는 일을 기업의 사옥을 짓는 일에 섣불리 비유하는 일이 위험해지고 있다 생각하게 되었다. 오늘날의 세태를 생각해 보면 사옥을 지으라 시켜 놓고, 팔짱 끼고 있는 발주자의 모습만이 떠오르기 때문이다. 무언가를 만드는 일의 설렘을 총체적으로 잊어 가는 사회 속에서 주인님이 함께 손에 흙을 묻힐 리가 없는 일이다. 

건축이란 적어도 100년, 길게는 세기를 넘긴 미래를 만드는 일이다. 그렇기에 장인의 정성, 즉 고용된 프로페셔널 만으로도 가능한 일이다. 한번 타오른 열정, 100년은 갈 수 있으니 아깝지 않다. 그렇지만 기업의 IT는 오늘을 만드는 일이다. 내일의 비즈니스를 위한 오늘을 매일 매일 만들어야 하는 일인 것이다. 이 사실을 잊을 때 시스템에 우환이 찾아 든다. 기업이 맞닥뜨리게 될 변화의 힘과 속도는 팔짱 낀 방관자적 IT를 두고 볼 정도의 여유가 없다. 

시스템을 1년에 걸쳐 치밀히 구축해 봤자, 남는 것은 그 시간 동안 변해 버린 환경과 이를 고려하지 않은 시스템뿐이다. 우리는 이러한 풍경을 수도 없이 목격한다. 새 집을 지어 줬다고 생각했지만, 정작 사용자는 낡고 쓸모 없다 구박한다. 현장의 사용자, 즉 현업이 원하는 그들 마음에 쏙 드는 시스템은 영원히 만들어지지 않는다. 이를 회피하기라도 하듯 현업의 요구는 억제되고, 비즈니스의 혁신은 프로젝트 일정에 의해 묵살된다. 누구를 위한 것인지 알 수 없는 개발 프로젝트는 종료를 향해 앞으로만 내달려 간다. 

SI에서 일어나는 관습적 악순환이다. 파견직 개발자들은 자신이 쓸 프로그램이 아니므로, 자신이 유지 보수할 프로그램이 아니므로 정성껏 만들지 않는다. '남'을 위해 짜주는 코드와 '나'를 위해 짠 코드의 질이 같을 리가 없다. 개인이나 집단의 태도나 자질의 문제가 아니다. 인간 본성이다. 훌륭한 프로그램은 남의 집에서 만들어지지 않는 것이다. 

미래를 살아 남을 기업은 지금과 같은 태평한 시스템 구축을 견디지 못할 것이다. 그들은 혁신을 위해 더 많은 요구를 할 것이고 그 요구가 받아들이지 못하면 다른 길을 찾을 것이다. 

미래 기업은 ① 이상계, 즉 인터넷 서비스 기업이 정성껏 만들어 준 온라인 소프트웨어를 사용하거나, ② 현실계에서 현업 사용자 스스로 직접 소프트웨어를 개발할 것이다. 

①은 현재 진행형이다. 온라인 너머로 기업 시스템을 옮기는 SaaS(Software as a Service)라는 행위가 벌어지고 있다. 세일즈포스닷컴(salesforce.com)은 대표적 사례다. 어설프게 개발한 시스템, 어설프게 운영되는 전산실보다 아예 경험 많은 이상계 기업에게 자신의 정보를 업로드해도 괜찮을 것 같다는 정서가 본격적으로 도래할지 모른다. 마치 개인들이 자신의 이메일을 포털에 맡기는 것처럼. 

②는 허황된 소리로 들릴지 모르겠다. 비즈니스 수행에 바쁜 기업의 직원들이 언제 프로그래밍 공부하겠냐 할 것이다. 그러나 미래 기업에게는 많은 옵션이 생길 것이다. BPMN(Business Process Modeling Notation)이라는 비전문가도 알 수 있는 단순 조작으로 모듈화된 서비스를 재조합하여 늘 새로운 시스템을 만들자는 SOA의 철학은 엔드 유저 컴퓨팅(EUC)이라는 이루지 못한 꿈을 다시 꾼다. 마치 위키를 쓰듯, 기업 시스템을 현업이 스스로 '매시업(mash-up)'해 주무르는 IBM의 QEDWiki는 ‘사용자가 직접 개발’하는 웹 2.0적 '참여의 아키텍처'를 꿈꾼다. 마이크로소프트 오피스 차기 버전에 새롭게 등장한 Excel Services는 엑셀로 서버 프로그래밍을 가능하게 한다. 회계사 겸 서버 프로그래머, 서버 프로그래밍을 할 줄 아는 보험 업무 담당자가 대거 등장할 것이다.

일을 하다가 필요한 부분은 현업이 직접 만들어 쓰는, 그 정도까지는 아니라도 혁신을 위한 변경은 스스로 수행하는 회사에 어떤 기업이 당할 수 있을까? 전산실에 의뢰하고, 전산실은 외부 발주하여 6개월 뒤에나 오픈할 수 있는 기업과, 오늘 판단하여 내일 바뀔 수 있는 기업 중 누가 승리에 가까이 있을까?

처음에만 외주 개발을 하고 유지 보수를 포함한 2차 개발을 스스로 해결하려는 기업이 생겨나고 있다. 이미 실력 있는 개발자를 '전문 위원'이라고 계약 고용을 하고 있는 기업들이 생기고 있다. 그들은 적극적으로 양질의 개발 인력을 직접 확보하려고 애쓰고 있다. 그들은 그들의 변화 속도, 그들의 혁신을 스스로 제어하고 싶은 것이다. 

IT를 관리 대상이나 설비로 본다면 이러한 행태는 착오라 해야 할 것이다. 핵심 역량이 아닌 것은 아웃소싱해야 하니까. 그러나 IT를 비즈니스의 거울, 비즈니스 수행의 주체라 생각한다면 ②의 용기를 내는 기업은 내일의 서바이벌이 두렵지 않다. 

IT 시스템을 MVC, 즉 모델, 뷰, 컨트롤의 큰 덩어리로 나뉠 때 적어도 모델 정도는 충분히 현업이 만들어 낼 수 있음을 이제는 인지해야 한다. 그러나 현실계의 기업들이 이 가능성을 인지하지 못하고 하도급 공정에 안주한 채 변화에 둔감해 있다면, 그나마 있던 현실의 기회와 가치들은 모두 현실계를 떠나 이상계로 넘어 가 버릴지 모르는 일이다. 적어도 이상계나 환상계는 남을 시키지 않고 자기 스스로 직접 개발하고 있다. 남을 위한 노동은 나를 위한 작품을 보통은 이길 수 없는 법이다. 

1970년대에 알란 케이는 그의 꿈 다이나북을 위해, 프로그래밍 언어이자 동시에 사용자 인터페이스인 스몰토크를 구상했다. 짜는 것과 쓰는 것을 떼어 생각하지 않았던 것이다. 그가 꿈꿨던 하드웨어의 미래는 오늘 우리 무릎 위에 있지만, 그가 꿈꿨던 소프트웨어의 미래는, 그리고 그가 꿈꿨던 '소프트웨어를 만드는 사용자'들은 아직 우리 곁에 보이지 않는다. "사용자는 공동 개발자로 여겨져야 한다"는 웹 2.0적 참여의 이상이 익어 갈 무렵에는 '소프트웨어를 만드는 사용자'들을 우리 곁에서 찾아 볼 수 있을까?@

 

출처 : 인터넷

Posted by SB패밀리

[개인] 기획, 설계, 구현, 유지보수를 하는 개발부서 사람들


프로젝트를 시작할 때 고객 또는 사업부서와 요구사항 분석을 위해서 기획을 하거나 기획에 참여하는 개발부서가 있다.

설계를 진행하고 구현에 들어가는 개발부서.

유지보수를 위한 매뉴얼, 가이드를 만드는 개발부서.


이런 개발부서가 있는 회사라면 개발자들에게 있어서는 대체로 배울 것이 많은 개발부서나 회사라는 생각이 든다.

그러나 프로젝트 기획이나 설계를 하거나 참여를 하지 않는 개발부서가 있다.


개발 PM에 따라 사정이 달라질 수 있지만 이런 경우 회사에서도 항상 개발부서에 대한 말이 많을 수 밖에 없다.

단순히 진행과정상의 문제와 요구했던 결과와 다른 결과물에 따라 평가하기 때문이다.

기획, 설계가 함께 진행되지 않으니 당연히 요구했던 결과물이 안나올 수 밖에 없을 것이고

요구사항 분석과 기획과정에서 고객의 Needs를 파악하고 문제를 좁혀나가야 원하는 결과물과 가장 가까워지지 않을까 생각한다.


결과적으로 회사 개발부서는 단순히 개발자가 기획에 참여하거나 설계를 하지 않는게 아니라

사업부서에서 그 과정을 배제시키는 경우가 대부분이라는 생각이다.

결국, 사업부서에서 요구하는 결과물, 개발부가 만들어 내는 결과물에는 이질감이 늘어가고 상호간의 불신이 짙어갈 수 밖에 없다는 생각이다.


문제는 기획부서, 사업부서에서 만들고 "뒷일은 자네들(개발부서)이 수습하게" 라는 꼴이다.

이런 회사에서 개발자는 발전 가능성이 있을까?


개발하는 환경에 대해 각자의 의겨견이 다를 수 있지만 지금 내가 생각하는 어느 환경에 대한 시각이다.

개발자는 그냥 거들 뿐.



Posted by SB패밀리