부지런한 개발자가 되자

 
By 2012년 8월 16일 
TAGGED :

얼마 전에 “게으른 개발자가 되자”라는 글을 올린 적이 있다. 이번에는 그 반대 제목인 “부지런한 개발자가 되자”는 글이다.

두 글의 주제는 모두 같다. 평소에 어떠한 자세로 일해야 개발자의 경력이 좀더 좋은 방향으로 발전될까에 대한 고민이다. 신입사원일 때부터 꾸준히 좋은 습관을 유지하는 것이 좋을 것이다.

아래 10가지의 질문이 있다. 각자 점수를 한번 매겨보자.

1. 개발툴(IDE)에서 제공하는 편리한 마법사(Wizard) 기능을 이용하지 않으면 개발이 어렵다.
2. 새로운 기술을 시도할 때 책은 안보고 일단 무조건 시도 해보면서 시행착오를 거쳐 익힌다.
3. 알고리즘의 원리에는 관심이 없고 사용법만 익혀서 사용만 한다.
4. 내가 작성한 코드를 꼼꼼하게 Trace 해보지 않는다. 결과만 제대로 나오면 OK이다.
5. 버그는 미뤘다가 나중에 고친다.
6. 바쁘기 때문에 유닛 테스트는 잘 하지 않고 버그는 QA테스트에서 걸러줄 것으로 기대한다.
7. 내가 참여하는 프로젝트만 관심이 있고 다른 부서의 프로젝트에 대해서는 전혀 모른다.
8. 내가 주로 쓰는 프로그래밍 언어 외에는 배척한다.
9. 항상 현재 개발업무에 바빠서 신기술에는 관심을 가질 시간이 없다.
10. 동료들과의 지식공유에 별로 노력을 기울이지 않는다.

0점이면 가장 좋겠지만 몇점이나 나오는가? 3점 이상이면 개발습관에 대해서 고민을 해야 하거나 현재 너무 바빠서 미래를 갉아먹고 있을 가능성이 높다.

너무 편하게만 개발을 하려 하고 원리에 소홀하면 기술적인 깊이가 얕아져서 문제 해결 능력이 떨어지고 좋은 Architecture를 만들어 낼 수가 없다. 빠른 것도 좋지만 약간은 느리더라도 원리를 파악하는데도 시간을 투자해야 한다. 옛날에는 이런 편한 개발툴들이 없어서 다들 밑바닥에서부터 원리를 파악하고 개발했었는데 좋은 개발툴들이 많이 나오면서 오히려 기술의 깊이가 얕아지는 일들이 벌어지고 있다. 더욱 원리에 관심을 가져야 한다.

자신이 작성한 소스코드를 꼼꼼하게 검사하는 습관을 가지지 않으면 항상 버그만 많이 만들어 내는 개발자로 낙인 찍힐 수 있다. 자신이 작성한 소스코드는 100% 완벽하다는 확신을 가지고 소스코드관리시스템에 등록하는 습관을 들여야 한다. 바쁘다는 핑계로 QA팀에 의지하는 습관을 가지게 되면 결국 본인의 가치만 떨어진다.

다른 부서의 프로젝트에 대해서도 관심을 많이 가져야만 지식과 경험의 범위가 넓어지고, 회사 내에서도 기술적인 영향력을 지속적으로 확대해 나갈 수 있다. 또한 다른 부서의 개발자들에게 도움도 줄 수 있다.

10년 이상의 경력을 가진 개발자인데 아직도 자신의 팀의 프로젝트에서 게다가 코딩만 열심히 하고 있다면 정말 똑똑하게 부지런한 개발자는 아니다. 이런 개발자들이 주는 가치는 신입사원에 2배에 불과하다. 당연히 연봉도 많이 받을 수가 없다. 10년 경력 이상이라면 적어도 타 부서의 프로젝트의 다양한 Review 에 참여하여 기술적인 결정에도 기여하고 전사적인 기술 Roadmap이나 의사결정에 참여할 수 있어야 한다. 물론 회사 규모에 따라서 그 정도는 약간씩 달라지지만 아직까지 자신의 팀에만 머물러 있어서는 안된다.

핵심은 부지런하더라도 좀 Smart하게 부지런해야 한다는 것이다. 코딩에만 몰두하지 말고 본인의 지식과 경험을 좀더 깊고 넓게 위해서 꾸준히 부지런을 떨어야 한다. 그래야 연봉 1억을 줘도 아깝지 않은 개발자가 될 수 있다.

페이스북으로 댓글을 남기실 수 있습니다.
THE AUTHOR
전규현 (gracegyu@gmail.com, allofsoftware.net) | 소프트웨어 컨설팅 회사인 ABC Tech(www.abcswcon.com)의 수석 컨설턴트이다. 연세공대를 졸업하고 18년 간 한글과컴퓨터를 시작으로 안철수연구소에까지 이르면서 수많은 소프트웨어를 개발하였고 Programming Engineer, Project Leader, Project Manager, CTO 등 소프트웨어 개발 분야의 다양한 역할을 두루 경험했다. 현재는 소프트웨어 개발 컨설턴트로서 소프트웨어 회사가 갖고 있는 소프트웨어 개발에 관련된 문제들을 해결해 주는 일을 하고 있다. Tech it 독자들의 구체적인 문의는 언제든지 환영합니다.
 
  • m. kim말하길

    새로운 기술을 시도할 때 책 부터 보는게 일단 무작정 해보기보다 낫다는 것은 일반화 하기 힘듭니다. 신기술은 좋은 책이 별로 없는 경우가 많고 이미 나와있는 책들도 웹으로 볼 수 있는 내용을 반복하는 경우가 많습니다. 책 부터 보고 해보겠다는 자세는 아무것도 시작하지 못하거나 그냥 책만보고 마는 상황이 될 수 있다고 봅니다. 요새 기술 대세도 일단 “시작하기”를 보고 따라하는 것에서 시작하니까요. 물론 책이나 심화 기술 문서를 보지 않는다는 것은 아닙니다만 일단 따라해보고 책을 보면 아! 하면서 더욱 이해가 잘 됩니다.

    또한 다른 부서의 프로젝트에 관심을 가질지 말지는 개인의 선택이라고 봅니다. 그냥 회사는 밥을 위해서 다니고 개발 열정은 오픈소스나 개인 프로젝트를 위해 쓰는 사람도 많습니다.

    연봉 1억 받기를 목표로 하는 개발자가 좋은 개발자 일까요. 이런식으로 일반화하기 힘든 내용을 목록으로 만들고 “점수를 매겨” 좋은 개발자인지 나쁜 개발자인지 구분하는 것이 인사팀에서 엉뚱한 이력을 기준으로 사람 분류를 하는 것과 무엇이 다를까요.

  • ickhyun말하길

    10가지 질문 중에 반은 공감이 가는데 반은 공감이 안가네요.
    마법사 기능은 사용해야지요. 왜 처음부터 에러로그 보면서 만들고 있어야 합니까? 시간낭비입니다.

    새로운 기술을 익힐 때 책을 꼭 봐야하는건 아닙니다. 윗분 생각에 동의합니다.

    알고리즘의 원리를 알면 좋겠지만 비즈니스가 중요한 곳에서는 비즈니스에 집중해야 합니다. 물론 업무에 따라서 알고리즘에 대한 이해가 필수인 경우는 있겠지요.

    4,5,6 번은 개인의 문제이기도 하지만 팀의 문제이기도 합니다. 짝프로그래밍을 하면 좋겠지만 여건이 안되면 커밋하기전에 코드리뷰과정이라도 있어야 합니다. 즉, 개인의 책임보다는 프로세스의 문제입니다.

    이 포스팅을 읽고 괜히 자책하는 개발자가 없었으면 합니다.

  • angelkum말하길

    마법사 기능 사용에 대해 한마디 드리자면
    한글은 끝까지 잘 읽어야 한다고 봅니다.

    1. 개발툴(IDE)에서 제공하는 편리한 마법사(Wizard) 기능을 이용하지 않으면 개발이 어렵다.

    말하고자 하는 논점은 마법사를 사용하지 않으면 개발이 “어렵다” 즉 마법사를 쓰지 말자는 얘기가 아니라, 마법사 없으면 어떻게 할지 모르는 사람들을 지칭하는 것 같은데요.

    ———————————
    원글의 내용이 공감가는 부분도 있고, 약간 일반화하기에 무리가 있는 내용도 있는 것 같습니다. 다만 이런 글에서 100% 적용되는 것을 논하기 보다는 취할 것은 취하여 자기반성내지는 더 발전하는 계기가 되면 그것으로 충분하지 않을까 생각해봅니다.

  • [...] 개발자 경력 보장 소프트웨어 개발자의 나아갈 길 게으른 개발자가 되자 부지런한 개발자가 되자 좋은 프로그래머가 되는 24가지 방법 Technical Career Path를 보장하는 방법 [...]