[ 펌 ] 프로그래머의 경력을 말아먹는 12가지 방법

프로페셔널한 프로그래머라면 본인의 경력을 스스로 관리할 수 있어야 합니다. 누구나 초보 프로그래머로 시작하여 수많은 시행착오를 겪으며 성장합니다. 많은 사람들이 같은 실수를 반복하며, 같은 후회를 되풀이합니다.

이 글에서는 좋은 프로그래머로서의 경력을 쌓기 위해 반드시 피해야 하는 몇 가지 사례들을 살펴봅니다. 글을 작성하기에 앞서, 여기에서 다루는 내용은 저의 주관적인 견해가 많이 들어있지만, 목차 또는 일부 구절 등에서 샘 라이트스톤의 『프로그래머로 사는 법』의 내용을 자주 인용했음을 밝혀 둡니다.

 

1. 다른 사람을 화나게 하기

일을 하다 보면 다른 사람과 의견이 다르거나 다른 사람에게 불만을 품게 되는 경우가 종종 있습니다. 특히 전쟁터와 같이 매우 급하게 진행되는 프로젝트에서는 일을 성사시키기 위해 다른 사람과 언성을 높이는 경우가 종종 있습니다. 물론, 이견을 조율하는 과정에서 약간의 논쟁은 생산적일 수 있지만, 이 과정에서 다른 사람을 화나게 하는 말투나 행동은 상대방과의 관계에 심각한 악영향을 초래합니다.

‘기억은 생각보다 오래가고, 무시당한 기억은 특히 오래간다’라는 말을 기억해야 합니다. 상대방의 기억 속에는 분명히 ‘같이 일하기 싫은 사람’이라고 내가 기억되어있을 것이고 이 기억은 언제가 나의 경력의 발목을 잡을 수 있다는 점을 명심해야 합니다.

 

2. 남을 헐뜯기

여러 사람과 함께 일하다 보면 마음에 들게 일을 처리하는 동료도 있고, 주어진 일을 제대로 처리하지 못하여 불만을 품게 만드는 동료도 있습니다. 또한, 일은 아주 잘하지만 성격이 괴팍하여 함께 일하기가 매우 불편한 사람도 있을 수 있습니다.

이런 경우 대부분의 사람은 같은 불만을 가진 사람들끼리 모여 그 사람을 헐뜯게 됩니다. 같은 생각을 하는 사람들끼리 뒷이야기를 하는 것은 그나마 양호하지만, 전혀 무관한 사람에게도 다른 동료의 결점을 헐뜯는 경우 큰 문제점들이 있습니다. 다른 사람에 대한 험담은 영원히 비밀보장이 되지 않는다는 점입니다. 만약, 내가 누군가를 헐뜯었다는 사실을 당사자가 알게 되는 경우 둘의 관계는 돌이킬 수 없는 강을 건너게 되는 것입니다. 상대방을 헐뜯는 사람은 듣는 이로 하여금 ‘다른 곳에서는 또 나를 헐뜯지 않을까?’라는 의심을 품게 합니다. 즉, 내 이야기를 들어준 사람과의 관계도 망칠 수 있다는 이야기입니다.

만약, 상대방에게 불만이 있다면 가장 좋은 해법은 직접 단둘이 이야기하는 것입니다. 그러나 만약 이것이 현실적으로 어렵다면 동료보다는 상사에게 객관적인 의견을 전달하는 것이 좋습니다. 왜냐하면, 동료보다는 상사가 민감한 정보에 대해 더욱 객관적으로 판단할 수 있으며 이야기의 민감성을 더욱 잘 판단하여 비밀을 더 잘 지키는 편이기 때문입니다.

 

3. 대책 없이 불평만 하기

대부분의 상사는 무조건 ‘예스’만을 외치는 예스맨들을 싫어합니다. 하지만 실제로는 끊임없이 불평만을 이야기하는 투덜이 유형을 더욱 싫어하게 되는 것이 사람의 마음입니다. 회사의 방향이나 일의 진행에 있어서 잘못되었다고 느끼는 점을 솔직하게 상사에게 이야기하는 것은 서로에게 도움이 되지만, 뚜렷한 대안도 없이 모든 사안에 대해서 불평하는 사람은 투덜이로 낙인찍혀 더는 그 어떤 의견도 제대로 전달될 수 없습니다.

이러한 불평 중에 가장 좋지 않은 행동은 상사에게 동료의 잘못을 일러바치는 행동입니다. 이러한 행동을 하고 싶은 마음이 든다면 다음의 두 가지 경우를 생각해보아야 합니다. 제대로 된 관리자라면 분명 자기 밑에 있는 사람들의 장단점을 이미 잘 파악하고 있을 것입니다. 이런 경우, 내가 굳이 일러바치지 않아도 관리자는 이미 상황을 판단하고 해결책을 모색하고 있을 것입니다. 그 상황에서 동료를 일러바치는 행동은 나의 이미지만 갉아먹는 행동이 됩니다. 부하 직원들의 문제를 인식하지 못하고 있는 관리자의 경우 내가 동료의 잘못된 점을 일러바친다고 해도 문제를 잘 해결할 수 없는 경우가 많습니다. 결국 동료의 문제를 당사자와 함께 원만히 해결해 나가는 것이 가장 바람직한 방법이라고 할 수 있습니다.

 

4. 새로운 것에만 집착하기

프로그래밍을 직업을 하다 보면 어떤 조직에서든 ‘리펙토링’, ‘절차 개선’에만 집착하는 사람들이 있습니다. 그러나 어떤 조직이든 이런 일들에만 많은 에너지를 쏟을 수는 없습니다. 물론, 위에서 말한 사안들은 장기적으로 보았을 때 해결하지 않으면 차후에 회사의 발목을 잡을 수도 있는 매우 중요한 사안들입니다. 하지만 이러한 제안을 할 때는 현재 조직에서 중점을 두고 있는 주요사안들, 윗사람의 반응 등을 고려하여 점진적으로 다가갈 필요가 있습니다.

안타까운 이야기이지만 다른 사람의 무관심에도 지속해서 같은 주장을 하는 사람은 짜증 나는 사람 취급을 당할지도 모릅니다. 같은 의견을 제시하더라도 항상 다른 사람의 상황과 팀 전체의 의견을 고려하여 적당한 시점에 적절한 방법으로 의견을 제시하는 것이 바람직합니다.

 

5. 협업하지 않기

제가 신입사원 시절 들었던 이야기 중에 아직도 가슴 깊이 새겨둔 말이 있습니다. ‘이 세상에서 가장 쉬운 일은 혼자 하는 일이다’라는 말입니다.

많은 프로그래머는 학생 신분에서 (돈을 받으며 직업으로 프로그래밍하는) 프로그래머로 한 단계 성장하는 과정을 겪습니다. 이 과정에서 많은 사람이 어려워하는 부분은 하나의 프로그램을 여러 사람과 협업하여 만들어내는 과정입니다. 물론, 처음에는 나 혼자 하는 것이 훨씬 빠르고 효율적이라고 생각할 수 있습니다. 그러나 다른 사람과 서로 도움을 주며 팀으로서 일을 완수하는 경험을 제대로 습득하지 못한다면 장기적으로 팀을 이끌거나 커다란 규모의 중요 프로젝트를 제대로 수행할 수 없게 됩니다.

다시 말해, 혼자서는 간단한 웹 사이트나 애플리케이션을 만들 수 있을지 몰라도 다른 사람과 협업하지 않고서는 대규모의 오픈소스 프로젝트나 시스템을 만들어낼 수 없다는 것을 빨리 자각해야 합니다.

 

6. 실력 없이 사람만 좋은 사람

호감이 가는 사람, 똑똑한 사람, 팀워크가 좋은 사람은 조직에서 여러 사람과 잘 어울려 지낼 수 있습니다. 그러나 이것만으로는 충분하지 않습니다. 진짜 일을 할 줄 아는 사람이 되어야 합니다.

만약 본인이 많은 프로그램이 엉망이라고 느껴지거나 생산성이 현저히 낮다고 느껴진다면 문제를 해결하기 위해서 노력해야만 합니다. 조금 더 설계에 많은 시간을 투자하고, 코딩 표준이나 단위 테스트 기법을 공부하는 시간에 투자한다면 기계적인 문제들은 얼마든지 나아질 수 있습니다.

또한 본인의 생산성이 회사에서 원하는 수준에 미치지 못한다고 느껴진다면 그 원인을 빨리 찾아야 합니다. 본인의 역량에 비해 너무 어려운 업무를 맡았거나, 기초가 부족한 상태에서 훈련 없이 실전 업무만을 급하게 처리해야 하는 상황은 아닌지, 혹은 프로그래밍 자체가 재미없고 자신의 적성이 다른 분야에 있는 것은 아닌지 빨리 판단하여 해결하는 것이 본인의 경력을 해치지 않는 방법입니다.

 

7. 일정을 자꾸 놓치기

소프트웨어 분야에서 일정을 지속해서 놓치는 것만큼 경력에 치명적인 것도 없습니다. 일정이란 상호 간의 ‘약속’이고 일정을 지키지 못한다는 것은 약속을 어긴 것이 되기 때문입니다. 물론, 현실 세계에서는 본인의 의사와 무관하게 일정을 지키지 못할 수밖에 없는 수많은 이유가 존재합니다. 그러나 뛰어난 프로그래머가 되기 위해서는 본인이 일정 내에 일을 완수하는 데에 걸림돌이 될만한 것들이 무엇인지 미리 인지하고 위험요소를 수시로 관리해야 합니다.

그럼에도 불구하고 무리한 일정과 넓은 개발범위로 인해 일정 내에 일을 마무리 짓는 것이 어렵다고 판단되는 경우에는 욕심을 부리지 말고 최대한 빨리 이슈를 제기해야 합니다. 한 달 이상 일정이 남은 상태에서 ‘이 일정 내에 좋은 품질의 개발을 끝내기 어렵다’라고 말하는 것과 오픈 직전에 ‘일정 못 맞추겠다’라고 말하는 것은 하늘과 땅만큼의 차이가 있습니다. 특히나 예정된 일정을 기반으로 외부 고객과의 차후 일정이 계획되어 있는 경우에는 더욱 문제가 심각합니다.

프로페셔널한 프로그래머는 본인의 경력을 스스로 관리하는 법을 알아야 하듯, 본인의 일정을 스스로 관리할 수 있는 능력도 필요합니다. 지속해서 일정을 놓치는 사람에게는 분명, 프로젝트를 관리하는 역할을 주지 않을 것입니다.

 

8. 급하지만 중요하지 않은 일에 열정 쏟기

스티븐 코비는 『성공하는 사람들의 7가지 습관』에서 시급성과 중요성에 따라 일을 사분면 매트릭스에 나누었습니다. 많은 사람은 이 가운데 ‘급하지만 중요하지 않은 일‘에 너무 많은 시간을 쏟는 경향이 있습니다. 예를 들어, 읽을 필요도 없는 이메일을 꼼꼼히 읽는 다거나 관련 없는 회의에 꼬박꼬박 참석하는 등의 일이 그렇습니다.

물론, 단기적으로 보면 이렇나 성향의 사람들은 성실한 사람으로 좋은 인상을 줄 수도 있습니다. 그러나 이러한 상황이 반복된다면 남들이 좀 더 중요한 일에 많은 시간을 투자하는 동안 자신의 시간을 낭비하였기 때문에 경력에 좋지 못한 영향을 미치는 것이 사실입니다. 본인의 경력을 한 단계 높은 차원으로 끌어올리기 위해서는 반드시 ‘급하지는 않지만 중요한 일’에 많은 열정을 쏟아야만 합니다.

 

9. 비밀실험(Skunkwork)에 초점을 맞추는 사람

프로그래머 중에는 회사업무와 별개로 개인적인 비밀 프로젝트를 진행하는 사람들이 있습니다. 간혹 이러한 프로젝트는 새로운 제품군이나 아이디어의 기반이 될 수도 있고, 마무리 지을 수 있는 능력만 있다면 건전한 투자인 것은 확실합니다. 그러나 많은 경우 일을 비밀리에 진행하는 사람들은 ‘재미있는 일에만 순간적으로 몰두‘할 뿐, 흥미를 잃게 되는 순간 일을 제대로 마무리 지을 수 있는 능력이 없는 경우가 많습니다. 또한, 회사의 서비스 기반을 만들기 위한다는 생각보다 다른 사람들에게 ‘짜잔~’하는 서프라이즈를 목표로 일을 진행하는 경우가 많습니다.

저는 현재 회사에서 매주 월요일 점심시간 1시간을 이용하여 프로그래밍 스터디를 진행하면서 pet project를 진행하고 있습니다. 이 프로젝트의 가장 큰 목적은 서비스에 검증 없이 적용하기 어려운 신기술을 마음껏 적용해보고 검증해보자는 취지였습니다. 그러나 최초 모임에서 제가 다른 동료들에게 가장 중요하게 설명한 부분은 ‘절대 업무시간에 해당 프로젝트 관련 일을 하지 말라’였습니다. 사실 프로그래머라는 직업은 업무시간과 여가의 구분이 불분명한 것이 사실입니다. 그러나 대부분 조직에서는 장기적인 미래를 위한 투자가 상황과 여건상 어렵기 때문에 매우 조심스럽게 진행하고 있는 것이 현실입니다.

이렇듯, 비밀실험을 하기 위해서는 반드시 세 가지 사항을 명심해야만 합니다. , 비밀실험을 해서는 안 됩니다. 즉, 모든 실험이나 프로젝트는 반드시 공개적으로 진행되어야 합니다. , 업무시간을 활용하는 것이 아니라면 그 누구에게도 허락받을 필요가 없습니다. 만약 업무시간의 일부분을 활용해야만 한다면 공식 근무시간의 10%~20% 미만이 되도록 노력해야 하며, 반드시 관리자를 설득하고 공감을 형성해야만 합니다. 프로페셔널 프로그래머는 반드시 본인에게 주어진 업무를 완수하는 조건으로 그 이상의 것을 할 수 있다는 점을 명심해야 합니다.

 

10. 공부하지 않기

이 세상의 모든 분야가 끊임없는 자기계발을 필요로 하지만, 소프트웨어 분야만큼 빠르게 변하고 최신 기술을 익혀야 하는 분야도 없을 것입니다. 물론, 새로운 기술들이 끊임없이 나오고 사라지더라도 운영체제, 알고리즘, 자료구조 등과 같이 근본적인 내용은 꽤 오랫동안 유지되는 분야이기는 합니다. 하지만 프로그래머로서의 성공적인 경력을 관리하기 위해서는 항상 끊임없이 공부하고 새로운 기술을 익히도록 노력해야 합니다.

새로운 기술을 꾸준히 익히면서 근본적인 기술에 대한 깊이를 더하는 것이 바로 앞서 말한 ‘급하지는 않지만 중요한 일’에 해당하는 것이며, 프로그래머로서 필수불가결한 조건입니다.

 

11. 자기 PR에만 열중하기

본인 자신을 PR하는 능력은 매우 중요한 역량 중 하나입니다. 아무리 뛰어난 일을 수행했더라도 본인이 직접 말하지 않는다면 아무도 모르고 지나가는 일들이 허다합니다. 그러나 겸손하고 적절한 방법으로 자기 PR을 하는 것과 자기가 한 일을 떠벌리고 다니는 것은 종이 한 장 차이입니다.

또한 실제 회사에 도움이 되는 일을 하는 시간보다 본인 PR에 투자하는 시간이 더 많은 경우 이기적이고 내실 없는 사람으로 찍히게 되며, 이러한 사실은 생각보다 금방 알려지게 되어 PR로 인한 득보다 실이 훨씬 더 커질 수 있음을 명심해야 합니다.

 

12. 중요하지 않은 역할에 매여있기

사실 조직에서는 모든 역할이 중요하며 각자의 역할이 조화를 이루어야만 좋은 결과를 낼 수 있습니다. 그러나 현실적으로 보았을 때, 회사는 전략적으로 중요하다고 여겨지는 업무와 그렇지 않은 업무가 존재합니다. 물론, 누군가는 중요하지 않은 임무를 수행해야만 합니다. 그러나 본인이 그러한 역할에 너무 오래 매여있는 경우 이를 타개할 방법을 찾아야만 합니다.

많은 사람이 ‘열심히만 하면 누군가 나를 알아봐 주고 도와주겠지?’라고 생각하지만 실제로 그런 경우는 극히 드뭅니다. 본인이 다른 업무를 하고 싶다고 어필하지 않았는데도 굳이 나서서 도와줄 리는 만무합니다. 주어지 상황에서 항상 최선을 다하는 자세는 무엇보다 중요하지만, 본인이 정말 올바른 길을 향해 잘 나아가고 있는지, 너무 벗어난 길을 오래 걷고 있는 것은 아닌지 항상 고민해 보아야 합니다.

===============================================================================================

http://ppss.kr/archives/63881

에서 퍼온 글 입니다.

엔지니어로서 중요한 마음가짐 인 것 같아 퍼왔습니다.

항상 되새김질 하며 살아야 할 거 같네요 ㅠㅠ