Copy & Paste의 종말

직업상 다른 개발자들이 작성해 놓은 코드를 볼 기회가 정말 많습니다.

그러다보면 자주 접하는 것이 복사된 코드들입니다. 

소소코드 Copy & Paste는 개발자의 대단히 큰 잘못입니다. 즉, 소스코드를 복사해 놓는 것은 쉽지만 그로 인해서 지속적으로 회사와 후배들이 부담을 져야 하기 때문입니다. 즉, 회사의 생산성을 갉아 먹는 행동입니다. 그런 개발자는 해고가 되어야 마땅하지요.

한쪽 제품이나 컴포넌트에서 사용한 함수나 소스코드들을 복사해 와서 다른 제품이나 컴포넌트에서 사용하는 것입니다. 동일하게 그대로 사용하는 경우도 있고, 약간 수정해서 사용하는 경우도 있습니다.

이런 일이 반복되다보면 비슷한 코드들이 회사의 전체 소스코드 중에서 여기 저기 산재하게 됩니다. 그러다가 버그가 발생하는 그중 일부는 고쳐지고, 일부는 여전히 버그를 가지고 있습니다. 또 해당 기능이 변경이 될 때도 이를 모두 찾아서 변경하기란 쉬운 일이 아닙니다. 이쯤 되면 개발은 창의적인 작업이 아닌 점점 노동이 되어 갑니다.

이런 공통적인 소스코드들은 공통모듈을 잘 계획해서 공통적으로 사용할 수 있어야 합니다. 공통모듈은 전사적으로 관리가 되어서 효율적으로 사용할 수 있도록 해야 하며, Copy & Paste의 욕구가 생겨도 시간을 약간 더 들여서 공통모듈화 하는 노력을 들이는 것이 필요합니다.

공통모듈을 관리하려면 당연히 소스코드관리시스템을 잘 사용해야 하고, 각 제품이나 컴포넌트들이 공통모듈들과 더불어 효과적으로 빌드가 가능하도록 빌드 스크립트도 준비가 되어야 합니다.

Peer review, code review가 정착되어서 다른 팀에서 서로 모르고 중복된 작업을 하는 것을 줄여야 합니다.

또, 특정 고객을 위한 커스트마이즈된 제품을 만들 때 대규모 소스코드 복사가 일어나는데, 이를 통제없이 만들고 방치하면 함수 몇개 복사한 것과는 비교도 안되는 큰 비용을 치뤄야 합니다. 물론 상황에 따라서 다르기는 하지만, 이런 경우에는 가능하면 소스코드 브랜치를 줄이고 브랜치를 만들더라도 소스코드관리시스템을 이용하여 잘 관리를 해야 합니다. 그리고 추후 Merge를 통해서 브랜치의 수명 주기를 짧게 가져갈 필요가 있습니다.

여기저기 복사된 쌍둥이 소스코드들... 참 문제가 아닐 수 없습니다.

고객이 요구사항을 너무 자주 바꿔요.

우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다.

예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행

일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리는 개발을 하는 쪽이나 고객이나, 일단 대충으로 요구사항으로 개발을 하고 나중에 서로 맞춰나가는 것이 상당 부분 관행화된 측면이 있습니다.

개발회사와 개발자가 요구사항을 분석하고 통제하는데 능력을 갖추고 있다면 100%는 아니지만, 고객의 요구사항 변경을 상당부분 통제 가능한 범위 안으로 가져올 수도 있습니다. 

스스로가 주먹구구 식으로 개발을 하면서 고객에게만 덤터기를 씌우는 것은 스스로에게 이득이 될 것이 없습니다.

변화하지 못하는 회사들의 공통점

회사가 변화하지 못한다는 것은 더 이상 발전이 없고 점점 쇠퇴해 간다는 것을 의미합니다.

변화하지 못하는 회사들은 항상 핑계를 대기 마련입니다. 어떠한 종류의 핑계들을 대며 변화하지 못하고 정체되어 있는 회사들의 공통점을 얘기해보죠.

첫째, 항상 바쁩니다.

주먹구구식으로 일을 하면서 항상 바쁘고, 또 바빠서 변화를 받아들일 수 없다고 합니다. 물론 핑계죠. 지금과 같이 일을 하면 계속 더 바빠지고 뒤죽박죽이 될 것이므로 혁신을 해나가야 하는데, 이를 핑계로 개발자들이 경영자에게 겁을 주면 대부분 잘 넘어갑니다.

둘째, 자기 회사는 매우 독특한 줄로 착각합니다.

1명짜리 소프트웨어 회사나 1,000명짜리 소프트웨어 회사나 소프트웨어를 개발하는 원리는 별반 다르지 않습니다. 그런데, 우리는 금융이라서 안전성이 매우 주요해서 프로세스는 도입할 수 없다. 우리는 포탈이라서 신속히 개발을 해야 하므로 문서를 쓸 시간이 없다. 우리는 게임을 만들기 때문에 일반적인 개발 방법은 통하지 않는다. 이와 같은 온갖 핑계를 댑니다. 물론 기존의 방법이 익숙하고 변화는 귀찮은 일이지만 변화하지 않고는 살아남기 어렵죠.

셋째, 경영자가 회사가 어떻게 돌아가는지 잘 모릅니다.

물론 경영자자 소프트웨어 개발에 대해서 개발자만큼 속속들이 잘 알 수는 없습니다. 그래서 CTO를 두는 것이고 CTO가 없다면 경영자가 소프트웨어 개발이 어떻게 이루어지는지 전체를 보는 눈이 있어야 합니다. 그렇지 않은 경영자들은 개발자에게 속아넘어가기 십상입니다. 우리나라에서는 CTO를 제대로 두고 있는 회사가 별로 없는 것이 안타깝습니다. 설령 CTO가 있다고 하더라도 그 역할과 파워가 많이 축소되어 있는 경우가 많습니다.

넷째, 회사에 파벌과 정치가 난무합니다.

회사의 변화는 Global 경쟁력을 갖춰나가고 효율성을 높이기 위한 방향으로 진행이 되어야 하지만, 정치가 난무하는 회사는 각 파벌들의 이익에 따라 회사가 좌지우지 됩니다. 이러한 회사에서 살아남는 방법은 승자에 편승하거나 떠나야죠. 정치판에 오래 몸을 담그면 자신도 물들어서 빨리 떠나는 것이 좋습니다.

다섯째, 개발자들이 우물 안에 개구리입니다.

개발자들이 자신의 실력을 과대포장하여 경영자들을 현혹하고 자신의 기술이 최고인양 착각하는 것입니다. 이러한 개발자들이 포진해 있는 회사는 아주 왜곡된 결과물들을 낳으며 금방 밑천이 드러나게 됩니다. 이러한 개발자일수록 자신의 기득권을 지키기 위해서 경영자를 쉽게 속이려고 합니다.

이 외에도 과거에 잘못된 방향으로의 변화 시도에 대한 아픈 기억들을 가지고 있어서 변화에 두려움을 갖고 있는 회사들도 있고, 방법을 몰라서 고민하는 회사도 있고, 재정적으로 충분한 여유가 없어서 가만히 있는 회사들도 있습니다. 하지만 어떻게든 변화하지 않으면 점점 후퇴한다는 것을 알아야 합니다.

변화하는 회사들의 공통점

여러 소프트웨어 회사들을 컨설팅 하다 보니 빠르게 변화해서 성공적으로 변신하는 회사가 있는가 하면 조그만 변화도 어렵게 어렵게 시도를 하면서 아주 더디게 변화하는 회사들도 있습니다.

A회사는 단 2개월 만에 목표한 바를 150% 달성하기도 하고

B회사는 1년 동안 처음에 계획하고 기대한 목표치의 50%밖에 달성하지 못하기도 합니다.

 물론 회사에 있어서 변화는 어렵습니다. 기존의 습관을 버리는 것도 어렵고, 기존의 방법이 잘못되었다는 것을 알아차리기도 어렵습니다. 설령 안다고 하더라도 기존의 방법을 구축해 놓은 사람들이 변화를 가로막고 심지어는 기득권을 지키려고 방해를 하기도 합니다. 또 변화 후에 더 좋아진다는 확신을 얻기가 어렵기 때문에 변화 자체는 항상 불안한 것입니다.

하지만 변화하지 않으면 더 이상의 발전이 없기 때문에 점점 경쟁력을 잃어서 결국은 끝나게 됩니다. 그래서 회사에 있어서 변화는 필수적입니다.

그럼 변화하는 회사들은 어떤 특징이 있는지 알아보겠습니다.

첫째, 경영자의 식견이 가장 중요합니다.

경영자가 변화의 필요성을 인식하고 변화의 올바른 방향을 파악할 수 있는 능력이 있어야 합니다. 경영자가 소프트웨어 기술을 자세히 알지 못해도 무엇이 필요한지 캐치해 낼 수 있는 능력은 있어야 합니다. 

둘째, 경영자의 의지가 중요합니다.

모든 변화는 반대와 방해에 부딪히게 됩니다. 그 방해는 그럴싸한 포장으로 둔갑해 있기 때문에 경영자의 의지가 강하지 않으면 쉽게 좌절하게 됩니다.

마지막으로 직원들의 Open mind입니다.

변화는 항상 힘들지만 올바른 변화는 회사의 경쟁력도 높여주지만 직원들의 가치도 올려줍니다. 그런데, 변화의 과정이 귀찮고 어렵다고 또 현재의 기득권을 잃게 될 것 같다고 변화를 거부하면 평생 그 자리에 머물러 있게 될 것 입니다. 

결국 변화는 경영자에게 달려 있다고 말하는 것 같은데 많은 부분 경영자에 달려 있는 것 맞습니다. 따라서 깨어 있는 직원들은 스스로 변화를 모색하기 보다는 경영자를 설득하여 경영층의 후원도 받아내야 변화에 성공할 수 있습니다. 

오늘의 잡담 - 개발자와 영어

이 소프트웨어라는 것이 미국에서 처음 만들어지다 보니 엄청나게 많은 자료들이 영어로 되어 있고, 대부분의 커뮤니케이션의 영어로 진행되고 영어가 마치 소프트웨어 업계에서는 표준어가 된 듯합니다.

나 자신도 영어를 지독히 싫어했고, 최근 2,3년간 영어 공부에 열을 올리고 있지만, 제가 처음 소프트웨어를 시작할 때부터 영어를 잘했다면은 지금 내 모습이 달라졌을 것을 생각합니다.

대부분의 프로그래밍 언어가 영어 기반이고, 메뉴얼 원본은 다 영어인데, 영어로 된 원서를 읽으려면 번역서보다 10배이상 속도도 느리고 이해가 잘 안되니 항상 번역서만 찾아 다녔었던 기억이 납니다.

이제와서 뛰어난 개발자가 되려면 영어도 잘해야 한다고 말하기도 쑥스럽지만, 영어를 유창하게 하지 못하는 개발자는 이미 기회를 반쯤 버리고 경쟁하는 것과 같다고 생각합니다.

일단 소프트웨어 업계로 들어서면 너무 바빠지는 것이 일반적이라서 개발자가 왠만해서는 영어 공부를 하기 쉽지 않습니다. 학교 다닐 때 미리미리 영어 공부 유창하게 될 때까지 하고 오세요.

이미 개발자로 일하고 있고, 영어가 부족하다면 음... 알아서 꾸준히 공부하세요.

참고로 제 개인 블로그(http://raymond.pe.kr)에서는 영어 공부에 대한 주제로도 글을 꾸준히 올리고 있습니다. 혹시 영어 공부에 관심이 있으시다면 미미하나마 도움이 되면 좋겠네요.

"영어는 가까이하기엔 너무 먼 당신이다" - 매우 다가갔다고 생각하면 어느덧 또 멀어져 있는.......

이 소스코드는 나 밖에 못 건드려!

"우리 팀은 각자 맡고 있는 소스코드가 다 달라서 서로 충돌 날 일이 전혀 없어요"

"이 소스코드를 수정해야 하면 나한테 얘기해, 내가 고쳐 줄게"

"내가 지금 고치고 있으니 너도 고치려면 내가 끝낼 때까지 기다려"

"지금 이거 한창 고치고 있으니 중간에 다른 것은 끼어들 수 없어요. 이거 다 끝날 때까지 기다려주세요."

이와 같은 현상이 친숙하나요? 그럼 Parallel

Development(병행개발)와는 거리가 멉니다.
Development를 제대로 수행하려면 소스코드관리시스템을 단순히 소스코드 저장소 용도로 사용해서는 부족합니다. 소스코드관리시스템을 제대로 사용하기 위한 프로세스와 규칙이 필요하며 Branch와 Tag, Merge를 용도에 맞게 능숙하게 사용할 수 있어야 합니다.

개발을 이런 식으로 순차적으로 기다렸다가 해야 한다거나 다른 사람이 이 소스코드를 고치고 있지 않은지 걱정을 하고 있거나 이것 때문에 소스코드를 고칠 때 항상 Lock을 걸어야 한다면 이만 저만 불편한 것이 아닙니다. 개발 속도도 떨어지게 됩니다.

아키텍처적인 이슈를 제외하고는 개발자들은 서로 같은 소스코드를 얼마든지 동시에 수정할 수 있고, 소스코드가 충돌이 일어나더라도 얼마든지 쉽게 해결할 수 있어야 합니다. 또한 동일한 소스코드를 기반으로 길고 짧은 프로젝트를 동시에 진행하면서 나중에서 손쉽게 Merge를 할 수 있어야 합니다. 이런 식으로 개발을 하지 않으면 대형 프로젝트는 너무 오래 걸릴 수 밖에 없습니다.

또한 이 때문에 각 개발자들이 Component Owner식으로 자신만 소스코드를 다룰 수 있다면 개발자들간에 소스코드 공유가 취약해지며 서로 단절된 개발을 하기 십상이 됩니다.

하지만 이런 Component Owner방식에 익숙한 환경에서는 이것이 너무 당연하게 생각이 되므로 이것을 바꾸려는 생각을 하기란 쉽지가 않습니다. 지금이 방식이 익숙하고 별 문제가 없어 보이고 또 이런 환경에서 발생한 문제들을 온갖 편법으로 피해 왔기 때문에 바꾸기가 쉽지 않습니다. 하지만 이로 인해 발생하는 문제들은 무시할 수 없습니다.

모짜르트와 두 제자

모짜르트가 두 명의 제자에게 피아노 레슨을 한적이 있답니다.

한 명은 이제 막 피아노를 시작한 완전 초자이고

또 한 명은 이미 연주를 능숙하게 할 줄 아는 사람이었다고 합니다.

모짜르트는 누구에게서 더 많은 레슨비를 받았을까요?

바로 두 번째 사람이었습니다.

첫 번째 사람은 완전 초자이므로 모짜르트가 시키는 대로 그대로 따라와줘서 진도도 잘 나가고 강습에 문제가 없는 반면 두 번째 사람은 자기스타일을 고집하기도 하고 오랫동안 몸에 익은 습관을 버리기가 어려워서 먼저 그 습관을 다 없애고 다시 배워야 하기 때문에 배우는 시간도 몇 배 더 오래 걸리고, 가르치기도 더 어려웠다고 합니다. 그래서 레슨비를 더 많이 받아야 했습니다.

소프트웨어 컨설팅을 할 때도 아무것도 없는 회사는 맨땅에게 건물을 짓는 것과 같아서 상당히 빨리 성과를 낼 수 있습니다. 하지만 어설프게 프로세스와 시스템을 이것 저것 많이 만들어 놓은 회사들은 비효율적인 것들을 모두 부수고 다시 만들어야 하기 때문에 시간이 더 오래 걸리고, 기존에 그렇게 만들어 놓은 사람들의 반대와 방해에 부딪혀서 어려움에 봉착하는 일이 많습니다.

잘못된 길로 들어 선 회사들은 빨리 다시 되돌아 와야 합니다. 

되돌아 오기에는 너무 먼 길로 간 경우도 종종 있습니다. 이런 경우는 어쩔 수 없습니다. 환자에게 너무 큰 칼을 대면 죽을 수도 있으니까요. 비효율적이지만 익숙한 방법으로 계속 해나가는 수밖에는 없습니다. 그러면서 서서히 조금씩 바꾸는 것이 사망하지 않고 바꿀 수 있는 방법입니다.

성급하게 이것 저것 마구 시도해서 나쁜 습관만 잔뜩 들지 말고, 차근차근 제대로 갖춰 나갑시다.

레퍼런스 있어요?

컨설팅을 하다보면 종종 듣는 질문이 레퍼런스 있냐는 말입니다.

또 이걸 시행하면 시행전보다 몇%의 생산성의 향상을 가져오는지 수치로 알려달라고 하는 사람들도 있습니다.

히딩크가 한국에서 와서 기초 체력훈련에 집중할 때 반대 했던 많은 사람들처럼 소프트웨어를 개발하기에는 너무나 기초가 취약한 수많은 기업에서 아주 기초적인 것들을 도입할 때도 종종 이런 말을 듣게 됩니다. 

레퍼런스는 Global 소프트웨어 회사 전부이고, 생산성 향상을 논할 수 없을 만큼 기초적인 것이다라고 말을 해야 하지만, 그렇게 얘기를 하면 기분이 나쁠 수 있으므로 애둘러서 말해야 합니다.

아직도 국내 소프트웨어 개발 환경 및 역량 수준이 Global 수준과 너무나 큰 차이가 나는 것이 현실입니다. 레퍼런스를 따질 때가 아니고 기초부터 다시 다져야 합니다.

정부에서는 Global 수준의 소프트웨어 개발 방법을 배우기 위해서 외국인들을 활용하려고 하는 정책들이 나오고 있는데, 또, 헛돈을 쓰는 시행착오로 끝날 것이 불 보듯 뻔합니다. 국내 현실을 전혀 모르는 외국인들이 과연 국내 소프트웨어 회사들을 어떻게 바꿀 수 있을지 그림이 안 나옵니다. 영어도 잘 안 통하는 한국에서 또 뜬구름 잡는 소리만 하고 비싼 세금으로 만든 비용을 받아 가겠죠. 

결과를 지켜봐야겠습니다.

누가 소스코드를 몰래 바꿔놨다.

누군가 몰래 여러분 회사의 소스코드를 바꿔놓는 일이 가능한가요? 진짜 이런 일이 일어 날 수 있는 환경이라면 당장 고쳐야 합니다.

실제로 이러한 걱정을 하는 회사도 많이 있습니다. 

영화 슈퍼맨3를 보면 한 프로그래머가 은행 이자의 우수리 돈을 자신의 계좌로 몰아서 스포츠카를 사는 장면이 나옵니다. 또, 퇴사하는 직원이 악의를 품고 소스코드를 몰래 바꿔놓지 않을까 걱정을 하기도 합니다.

정상적인 시스템과 프로세스를 갖춘 회사라면 이러한 걱정을 할 필요가 없으나 그렇지 못한 대부분의 소프트웨어 회사들에서는 언제든지 일어날 수 있는 일입니다.

정상적인 경우라면 소스코드의 모든 변경은 기록에 남게 됩니다. 또 소스코드를 변경하기 위해서는 버그ID(또는 이슈ID)가 있어야 합니다. 이것이 소스코드 변경 승인의 역할을 대신하기 때문에 소스코드를 변경 시 버그 ID가 없다면 소스코드 변경이 차단되도록 되어 있는 경우도 있습니다.

또, 버그ID도 가짜로 만들어서 등록을 했다고 하더라도, Peer review에서 이상한 코드는 발견이 되게 됩니다. Peer review를 통과 했다고 하더라도, Build팀에서 빌드를 하면서 바뀐 소스코드와 버그ID를 체크하는 과정에서 가짜 버그 ID가 발각 될 수 있습니다. 여기까지 통과를 하였다고 하더라도, 테스트에서 걸리게 되어 있습니다. 이것도 통과를 하였다고 하더라도, 모든 변경의 이력은 기록이 남아 있고, Log가 존재하므로 추후 추적이 가능해집니다.

제대로 시스템과 프로세스가 갖추어져 있다면 누가 소스코드를 마음대로 바꾸지 않을까 걱정할 필요가 없습니다. 이를 걱정하고 온갖 프로텍트 장치를 해 놓는 것은 오히려 개발 효율성을 떨어뜨리게 됩니다.

모든 것이 다 Open되어 있고 허술한 것 같아 보이지만, 이렇게 하는 것이 오히려 더 안전하고 투명하게 개발이 진행되며 생산성을 훨씬 더 높이는 방법입니다.

개발자는 코딩만 해야 한다.

제목을 보시고 무슨 말도 안되는 얘기를 하느냐고 생각하시는 분이 대부분일 겁니다.

이러한 생각의 Gap은 소프트웨어를 개발하는데 있어서 개발자의 역할에 대한 인식의 차이에서 비롯합니다.

현실을 보면 개발자라는 이름으로 정의된 소프트웨어 엔지니어들은 대단히 많은 일을 합니다. 

요구사항 분석도 하고, 설계도하고, 코딩도 하고, 테스트도 하고, 빌드도 하고, 팩키징도 하고, 고객지원도 하고, 전화도 받고, 영업도 지원하고, 서비스 회사인 경우에는 실제 운영서버 관리도하고, 장애 해결도 하고, 정말 여러가지 일을 합니다.

이것을 역할로 바꿔보면, Software Analyst, Software Architect, Coder, QA Engineer, Build Engineer, Release Engineer, Technical support engineer, Technical sales engineer, System administrator 등의 서로 다른 역할 들입니다.

이런 일들을 모두 다른 사람이 해야 한다고 하면 배부른 소리하고 있다고 할 겁니다. 물론 그것은 아니죠. 이중에서 개발자가 Coder의 역할만 하는 것은 아니고 몇 가지 역할을 겸해서 할 수는 있습니다. 심지어는 위의 모든 일을 한 명의 개발자가 수행할 수도 있습니다. 하지만 그렇다고 하더라도, 이 각각의 일들은 원래 다른 역할이라는 것을 알아야 합니다. 특히 코딩과 테스트는 한 사람이 동시에 잘 해내기 어려운 조합이기도 합니다. 따라서 여유가 되고 기회가 된다면 적절한 시점에 똑같은 만능개발자를 수평적으로 인원수만 늘릴 것이 아니고, 각각의 역할로 쪼개야 합니다.

그 중에서 개발자(코더)의 역할은 정해진 설계에 따라서 혹은 할당받은 버그에 대하여 소스코드를 수정하고 소스코드관리시스템에 등록하면 끝나는 겁니다. 나머지는 다른 사람들이 할 일이죠. 이것이 지켜지지 않으면 이중에서 비싼 인력인 개발자가 싼 인력이 수행할 수 있는 일들에 치여서 점점 효율성이 떨어지고, 자잘한 사고도 많이 일어납니다. 개발자는 개발이 전문이지, 테스트 전문가도 아니고, 빌드와 릴리즈 전문가는 더욱더 아니라서 코딩 이외의 일들은 잘 해내지도 못합니다. 따라서 조직이 커지고 있다면 적절한 시점에 역할이 분리되지 않으면 커다란 공장에서 수많은 개발자들이 체계적이지 않은 방법으로 인형에 눈깔 붙이듯이 서로 뒤죽박죽 뒤섞여서 일하게 될 수 있습니다. 

지금은 조직이 작아서 개발자가 여러가지 일을 다하더라도 "모드전환스위치"를 가지고 있어서 서로 다른 일을 할 때는 스위치를 잘 해야 합니다. 그리고 언제든지 일을 떼어줄 준비를 하고 있어야 합니다.

개발자 4명보다 개발자 3명과 테스터 1명이 더 효율적입니다.

개발자 30명보다 개발자 20명과 테스터 6명과 빌드/릴리즈 담당자 1명과 3명의 Technical Support 담당자가 있는 것이 더 효율적입니다.

물론 숫자는 절대적인 것이 아니지만, 회사는 계속 커가는데, 구멍가게나 가내수공업식으로 계속하고 싶지 않으면 역할에 분리에 대해서 고민해야 합니다.

살아남은 개발자들

소프트웨어 업계에서 주변을 둘러보면, 실력은 없으면서 탁월한 생존력으로 살아남은 개발자들을 볼 수 있습니다.

소프트웨어 개발 실력은 떨어지지만, 업무지식을 속속들이 알고 있는 개발자

회사의 개발정보를 꼭꼭 숨겨서 자신만 알고 있는 개발자

과거에 개발해 놓은 소스코드의 문서도 만들지 않고 뒤죽박죽으로 섞어놔서 자신이 아니면 유지보수를 못하게 만들어 놓은 개발자

탁월한 인화력으로 후배 개발자들과 똘똘 뭉쳐있는 개발자

미래에 경쟁이 될만한 새싹은 미리 밟아 버리는 개발자(관리자)

화려한 언변으로 경영자들에게 거짓된 신임을 얻고 있는 개발자

위와 같은 방법의 생존이 소프트웨어 업계에서 살아가는 한 방법이기도 하지만, 또 일부 기술은 부러운 기술이기도 하지만, 이는 결국 회사와 개발자 모두의 경쟁력을 갉아 먹고, 그 부메랑은 개발자에게 돌아옵니다. 이런 방식으로는 10년, 20년 꾸준히 소프트웨어 엔지니어로서 일을 하면서 성장하기는 어렵습니다. 개발자로서 오래 살아남고 싶다면, "생존력"보다는 "경쟁력"이 필요합니다.

"경쟁력"이 구체적으로 무엇인지는 제 블로그 전반에서 계속 주장하고 있으니 살펴보세요. ^^