태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

부지런한 개발자가 되라

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

지난번에 "게으른 개발자가 되라"는 글을 올린 적이 있습니다.
이번에는 그 반대 제목인 "부지런한 개발자가 되라"는 글입니다.

소프트웨어 개발은 대단히 섬세하고 꼼꼼한 작업입니다.
이를 어설프게 대충 접근하다가는 프로젝트도 망칠 수 있을 뿐만 아니라 본인 스스로의 성장에도 지장을 줄 수 있습니다. 다음에 몇 가지 질문에 답변을 해보시죠.
  1. IDE에서 제공하는 편리한 Wizard를 이용하지 않으면 개발이 어렵다.
  2. 새로운 시도를 할 때 책은 안보고 일단 해본다.
  3. 새로운 알고리즘에 원리는 관심이 없고 사용만 한다.
  4. 내가 작성한 코드를 꼼꼼하게 Trace 해보지 않는다.
  5. 버그는 미뤘다가 나중에 고친다.
  6. 유닛 테스트는 잘 하지 않고 QA테스트에서 걸러줄 것으로 기대한다.
  7. 내가 참여하는 프로젝트만 관심이 있고 다른 부서의 프로젝트에 대해서는 전혀 모른다.
  8. 내가 주로 쓰는 프로그래밍 언어 외에는 배척한다.
  9. 항상 업무에 치여서 신기술에는 관심을 가질 시간이 없다.
  10. 동료들과의 지식공유에 많은 노력을 기울이지 않는다.
이 질문들에 Yes가 얼마나 많으신가요? 설마 10개는 아니겠죠.
질문들이 직접적인 관계는 없는 것 같지만 개발자가 단순히 Output만을 내기 위해서만 일을 해서는 안되다는 메시지를 담고 있습니다. 

너무 편리하게 일하려고 하고 원리에 소홀하면 개발자로서의 기술적인 깊이를 다질 수가 업습니다. 또 자신의 코드를 꼼꼼하게 검사하는 습관을 들이지 않으면 항상 버그만 많이 만들어 내는 개발자로 낙인 찍힐 수 있습니다. 또한 다른 부서의 프로젝트에 대해서도 관심을 많이 가져야만 지식과 경험의 범위가 넓어지고, 회사 내에서도 기술적인 영향력을 지속적으로 확대해 나갈 수 있습니다. 또한 다른 부서의 개발자들에게 도움도 줄 수 있습니다. 
따라서 10년 이상의 경력을 가진 개발자인데 아직도 자신의 팀의 프로젝트에서 게다가 코딩만 열심히 하고 있다면 정말 똑똑하게 부지런한 개발자는 아닙니다. 이런 개발자들이 주는 Value는 신입사원에 2,3배에 불과합니다. 당연히 연봉도 많이 받을 수가 없죠. 10년 경력 이상이라면 적어도 타 부서의 프로젝트의 다양한 Review session에 참여하여 기술적인 결정에도 참여를 하고 전사적인 기술 Roadmap이나 의사결정에 참여할 수 있어야 합니다. 물론 회사 규모에 따라서 그 정도는 약간씩 달라지지만 아직까지 자신의 팀에만 머물러 있어서는 안됩니다.

요지는 부지런해도 좀 Smart하게 부지런해야 한다는 것입니다. 코딩에만 몰두하지 말고 본인의 지식과 경험을 좀더 깊게 좀더 넓게 하기 위해서 꾸준히 부지런을 떨어야 합니다. 그래야 10여년 후에 연봉 1억을 받아도 아깝지 않은 개발자가 될 수 있습니다.

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

'사람과 기술' 카테고리의 다른 글

거짓말쟁이 개발자  (13) 2009/10/05
시한부 프로그래머  (13) 2009/09/22
부지런한 개발자가 되라  (9) 2009/09/11
게으른 개발자가 되라!  (6) 2009/08/28
과거의 개발자 vs. 미래의 개발자  (18) 2009/04/28
개발자는 억울하다.  (10) 2009/04/21

전규현 사람과 기술

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

    2번에 해당 되는 군요.. 책을 먼저 보면(읽는 것이 아니라) 좀더 빨리 새로운 것을 할 수 있습니다만.. 제것이 잘 안되더군요 .,. 직접 먼저 해보고 책을 보는 것이 좋더라구요..

  2. dkinght님 안녕하세요.
    업무에 치이다보면 시간이 없어서 어쩔 수 없는 경우도 많은 것 같습니다. 그래서 저는 개발자가 항상 시간적인 여유를 가질 수 있어야 한다고 생각합니다. 개발자는 기계적인 일을 하는 것이 아니기 떄문에 두뇌에 항상 여유분을 가지고 있어야 합니다.
    또 지식에 대한 열정도 필요하겠죠. ^^

  3. 우리나라의 일반적인 경우라면 "10년 이상의 경력을 가진 개발자인데 아직도 자신의 팀의 프로젝트에서 게다가 코딩만 열심히 하고 있다면 정말 똑똑하게 부지런한 개발자는 아닙니다."가 맞겠지만, 그렇지 않은 케이스도 많겠죠. 평생 코딩을 업으로 하고 싶다면, 이를 존중해주는 회사/사회가 보편화되길 바라마지 않습니다. 정확히 이야기해서 코딩을 잘하는 사람에게 사회성은 좋은 도구일 수는 있더라도 필수요건은 아니니까요.

  4. charlz님 안녕하세요.
    "평생 코딩을 업으로 삼다."와
    "평생 개발을 업으로 삼다."는 좀 다른 의미를 가지고 있습니다.
    저는 묵묵히 오랫동안 팀에서 코딩을 열심히 하는 개발자도 존중하지만, 높은 연봉을 주기 어려울 것 같습니다. ^^ 코딩도 하지만, 회사내에서 좀더 광범위하게 기술적인 영향을 끼치고, 후배들을 이끌 수 있은 개발자에게 좀더 연봉을 많이 줄 겁니다.
    두 경우 모두 전문적인 개발자 Track이 보장되어야만 가능하지만, 우리나라에서는 Technical Track이 보장되지 않는 회사가 많아서 많은 경우 대접 못받는 고참 개발자가 되거나 관리자로 전환 하는 경우가 많은 것이 안타깝습니다.
    저는 항상 강연이나 세미나에서 Technical Track의 필요성에 대해서 항상 역설합니다.
    조금씩 인식이 바뀌겠지요.

  5. 연봉이 모든걸 표현하지는 않겠지만, 확실히 노동자/개발자에게는 후하지 못한 경향이 크죠
    묵묵하게 자기 할일을 하는게 나쁜게 아님에도 불구하고
    소위 이빨까는 사람들보다는 / 사내정치 하는 사람보다는 합당한 돈을 받지 못하는 것 같고 말이죠

    그러한 점들만 아니라면, 여러가지 분야를 깊이있게 아는 사람에게 돈이 더 가야 하는건 맞겠지만
    그래도 한가지만 했다는건 그래도 좀더 많은 경험을 가졌기에 득도(?) 했다고 받아들여도 되지 않을까
    라는 생각을 해봅니다.

  6. 구차니님 안녕하세요.
    이빨까는 사람과 사내 정치하는 사람을 구분하려면 사내에 CTO가 있거나 기술적인 리더쉽이 있는 경영진이 있어야 하는데, 그렇지 못한 경우 많은 것이 현실입니다.

  7. 저 10개중에서는 3번항목에 대해서 부분적으로 해당사항이 있군요. 올해로 딱 10년차입니다. -_-;;;

    다만 10년차 or 그 이상이라면 프로그래밍 언어 뿐만 아니라 서버/네트워크/스토리지 구성 및 프로젝트별로 적절한 구성을 제시할 수 있는 훈련도 되어야 하지 않나 싶습니다.

    SI를 하는 업체라면 프로젝트에 대한 제안서 작성이나 견적 작업도 해봤어야 할 것 같구요, 그 외에도 개발자가 해야 할 문서작업들도 꽤 있죠(정상적이라면 10년차 정도면 과장급 이상이니... )

    그리고 2번은... '책' 이 아니라 '관련 기술문서' 라고 하는 편이 나을 것 같습니다. 최신의, 혹은 별로 알려지지 않은 몇몇 기술들은 그 '책' 이라는 것이 없는 경우도 있으니까요. :)

  8. 우울한딱따구리님 안녕하세요.
    나머지는 모두 문제가 없으신가보네요. :) 10점만점에 9점 ~~

  9. 다양한 관점에서 작성하신 글 동의합니다. 개발자들의 주어진 환경과 자신의 환경을 잘 극복하여 좋은 결과들이 많았으면 합니다. 물론 개발자 스스로의 열정과 노력도 필요하고요. 잘 읽었습니다.

문서를 작성하면 더 오래 걸린다는 고정관념

최근에 국내 유수 대학의 컴퓨터 공학 교수를 만난 적이 있다. 그 교수님도 문서를 작성하면서 Software를 개발하면 더 오래 걸린다고 굳게 믿고 있었다. 어느 정도 이해가 되는 상황이다. 원래 소프트웨어 공학은 실전에서..

이슈를 모으기도 정말 어렵다.

많은 회사들이 개발 프로세스 개선을 하겠다고 선진 개발 방법론을 흉내내거나 실패한 대기업의 프로세스를 가져다가 적용하곤 한다. 복잡한 프로세스와 많은 Template를 가져다가 적용해보려고 하는데 대부분은 실패를 한다. 기초..

변화에 실패하는 9가지 고정관념

회사는 끊임없이 변화하지 않으면 지속 성장하지 못한다. 하지만 변화는 피와 살을 깍는 고통을 동반하고 또 많은 회사가 변화에 실패해서 성장하지 못하거나 사라져간다. 보통의 사람들은 대부분 변화를 싫어하고 기존에 하던대로 계속..

좋은 프로그래머가 되는 24가지 방법

1. 프로그래밍에 열정이 있어야 한다. 열정이 없고 즐기지 못하면 평생하기 어려운 일이다. 2. 프로그래밍 기초 원리를 완전히 이해해야 한다. 원리를 모르면 근본적인 해결을 할 수 없다. 3. 문제 해결 능력을 키워야 한다...

요즘 실리콘밸리에서는...

얼마전 실리콘밸리의 한 Startup company에서 CTO로 일하고 있는 오랜 친구가 한국에 놀러와서 같이 여행을 갔다. Informix에서 소프트웨어 엔지니어로 시작해서 한 20년 정도 일한 중국인 친구다. 같이 일을..

전문가 vs. 책임자

우리나라 조직문화는 전문가보다 책임자를 선호한다. 조직의 장이 책임을 지고 모든 일을 알아서 하는 것이다. 상명하복 관계 위주다. 경영자가 SW개발에 대해서는 잘 모르는 경우 누구 한명이 책임지고 개발해줬으면 하는 생각을 하..

소프트웨어 회사의 자산은?

소프트웨어 회사의 자산은 무엇일까? 흔히 개발자가 소프트웨어 회사의 재산이라고 한다. 이런 회사일 수록 회사가 가지고 있는 것은 정말 개발자밖에 없다. 또한 파악하기 어려운 한 무더기의 소스코드가 있다. 개발자들이 나가면 이..

관리자가 이런 일까지?

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

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

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

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

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