본문 바로가기

개발자

뛰어난 개발자는 타고 나는 것 1. 처음부터 똑똑한 개발자를 뽑아라. 2. 똑똑하지 않는 개발자를 채용해 놓고 똑똑한 개발자로 바꾸려고 시도하지 마라. 3. 특출나게 똑똑하지 않은 개발자도 다 적절한 역할이 있다. 4. 그 역할을 찾아서 제 역할을 하도록 하라. 각 개발자에게 알맞은 역할을 찾아 주고 제대로 일하게 하는 것만으로도 얼마나 힘든지 아는가? 소프트웨어 회사 경영자와 관리자에게 전하는 말입니다. 요즘은 뛰어난 개발자를 구별하기 정말 어렵습니다. Labor market에는 실업자가 넘쳐나지만 뛰어난 개발자는 눈을 씻고 찾아봐도 볼 수가 없습니다. 뛰어난 개발자는 이직을 잘하지 않고 노출이 잘 안되기 때문입니다. 그래서 적당한 개발자, 또는 해당 분야에 경험이 좀 있는 정도의 개발자를 그냥 채용하는 경우가 많습니다. 하지만, .. 더보기
개발자 부품화 vs. 만능 개발자 개발 프로세스를 너무 따지만 개발자가 부품화 되고 창의성이 줄어든다고 합니다. 또 분석, 설계, 구현, 테스트를 나눠서 하게 되면 부품화되고 비인간적이라고 하기도 합니다. 그래서 개발자가 이것 저것 다하는 만능의 역할을 수행하게 합니다. 투수는 공만 던지고, 골키퍼는 골만 막는 것은 부품화일까요? 이렇게 전문화되지 않고 모두 만능으로 잘하는 동네 축구를 해서 어떻게 세계적인 소프트웨어와 경쟁할 수 있을까? 잘 하고 싶어도 동네축구를 계속 하는 이유는 제대로 된 방법을 경험해 본적이 없어서 그렇습니다. 개발자가 한명인 회사나 개발자가 50명인 회사가 개발하는 방법은 크게 다르지 않습니다. 개발자가 개발 전반의 모든 일을 다 알아서 하고 프로젝트는 개발자의 역량과 의지에 달려있습니다. 동네 축구를 벗어나기 .. 더보기
거짓말쟁이 개발자 의도적이던, 의도적이지 않던 간에 개발자의 거짓말은 개발자 스스로의 신뢰를 떨어뜨릴 뿐만 아니라 회사의 중요한 결정을 잘못된 방향으로 이끌기도 합니다. 거짓말쟁이 개발자들은 거짓말을 하면서도 본인이 거짓말을 하고 있다는 것을 자각하지 못하거나 온갖 합리화를 할 수 있는 핑계로 무장을 하여 진실을 말하고 있는 자기 최면에 빠지기 도합니다. 사람들은 계속 속아주지는 않습니다. 결국 신뢰도 떨어지는 개발자가 될 수 있습니다. 모르는데 아는 것처럼 말하는 것 이름 한번 들어본 기술 또는 샘플 코드 한번 돌려본 것 가지고 아는 척하는 경우를 흔히 볼 수 있습니다. 이때는 자신이 어느 정도 아는지 정확하게 밝혀야 합니다. "들어는 봤다", "프로젝트에 적용해 봤다", "남을 가르칠 수 있다" 중요한 의사 결정에 있.. 더보기
시한부 프로그래머 우리나라 개발자들은 10년 후가 매우 불확실합니다. 오랫동안 프로그래머로서 일할 수 있도록 보장이 되지도 못하고, 그런 Role model을 본 적도 별로 없기 때문이죠. 그래서 5년~7년쯤 일하고 나면 미래를 걱정해야 할 시기가 도래합니다. 윗사람들은 자꾸 관리를 하라고 하고, 선배들을 봐도 15년차 개발자보다 15년차 관리자가 회사 내에서 영향력도 더 크고, 연봉도 더 높습니다. 개발이 좋기는 한데 계속 개발자로만 머물려면 미래를 많이 희생해야 합니다. 그래서 개발과 관리 양다리를 걸치기도 하는데, 결국 관리도 잘 못하고 개발도 잘 못하는 어정쩡한 상태가 계속 되기도 합니다. SW선진국에서는 기본적으로 개발자의 Career path는 확실히 개발자냐 관리자냐 구분이 됩니다. 내가 개발자로 머물고 싶다.. 더보기
Copy & Paste의 종말 직업상 다른 개발자들이 작성해 놓은 코드를 볼 기회가 정말 많습니다. 그러다보면 자주 접하는 것이 복사된 코드들입니다. 소소코드 Copy & Paste는 개발자의 대단히 큰 잘못입니다. 즉, 소스코드를 복사해 놓는 것은 쉽지만 그로 인해서 지속적으로 회사와 후배들이 부담을 져야 하기 때문입니다. 즉, 회사의 생산성을 갉아 먹는 행동입니다. 그런 개발자는 해고가 되어야 마땅하지요. 한쪽 제품이나 컴포넌트에서 사용한 함수나 소스코드들을 복사해 와서 다른 제품이나 컴포넌트에서 사용하는 것입니다. 동일하게 그대로 사용하는 경우도 있고, 약간 수정해서 사용하는 경우도 있습니다. 이런 일이 반복되다보면 비슷한 코드들이 회사의 전체 소스코드 중에서 여기 저기 산재하게 됩니다. 그러다가 버그가 발생하는 그중 일부는 고.. 더보기
고객이 요구사항을 너무 자주 바꿔요. 우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다. 예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행 일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리.. 더보기
오늘의 잡담 - 개발자와 영어 이 소프트웨어라는 것이 미국에서 처음 만들어지다 보니 엄청나게 많은 자료들이 영어로 되어 있고, 대부분의 커뮤니케이션의 영어로 진행되고 영어가 마치 소프트웨어 업계에서는 표준어가 된 듯합니다. 나 자신도 영어를 지독히 싫어했고, 최근 2,3년간 영어 공부에 열을 올리고 있지만, 제가 처음 소프트웨어를 시작할 때부터 영어를 잘했다면은 지금 내 모습이 달라졌을 것을 생각합니다. 대부분의 프로그래밍 언어가 영어 기반이고, 메뉴얼 원본은 다 영어인데, 영어로 된 원서를 읽으려면 번역서보다 10배이상 속도도 느리고 이해가 잘 안되니 항상 번역서만 찾아 다녔었던 기억이 납니다. 이제와서 뛰어난 개발자가 되려면 영어도 잘해야 한다고 말하기도 쑥스럽지만, 영어를 유창하게 하지 못하는 개발자는 이미 기회를 반쯤 버리고 .. 더보기
과거의 개발자 vs. 미래의 개발자 개발자는 2가지의 상반된 가치를 가지고 있습니다. 하나는 과거의 가치 또 하나는 미래의 가치입니다. "이 사람들 나가면 과거에 개발해 놓은 것 어떡하지?"라는 생각이 들면 과거의 가치를 가진 개발자이고 "이 사람들 나가면 미래에 개발은 누가 하지?"라는 생각이 들면 미래의 가치를 가진 개발자입니다. 과거의 가치를 가진 개발자들은 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식은 머리 속에 있기 때문에 자신이 과거에 만들어 놓은 소프트웨어를 인질 삼아서 회사와 인질극을 벌이고 있는 것과 같습니다. 이렇게 된 원인이 상당부분 회사에 있다고 하더라도, 개발자의 가치는 인질범과 별반 다를 바가 없습니다. 기존 소프트웨어를 망칠까봐 대우해줄 수 밖에 없습니다. 미래의 가치를 가진 개발자.. 더보기
개발자들이 바글바글한 외딴섬에 떨어진다면 개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까? Language 기초를 다시 가르칠까요? UML을 가르칠까요? 문서 작성법을 훈련 시킬까요? 개발방법론을 가르칠까요? 팀워크를 키워줄까요? OOP를 가르칠까요? 어떻게 하시겠습니까? 나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement .. 더보기
개발자는 억울하다. 회사에서 제대로 배우고 성장할 기회를 갖지 못한 채 혼자서 북치고 장구치고 밤새가면서 개발하여 회사를 성장시켜놨는데 이제는 골치덩어리 개발자가 되어 버렸습니다. 이제는 문서도 안 만들고, 프로세스도 지키지 않으며, 정보를 꽉 쥐고 내놓지 않으려는 "꼴통개발자"로 보이기 십상입니다. 실제로 한참 후배들은 그런 고참개발자를 "꼴통" 또는 "철밥그릇"이라고 부릅니다. 당장은 그런 고참 개발자가 없으면 회사가 안 돌아 갈 것 같으니까, 잡아두고 있지만, 프로세스를 정비하고 시스템을 구축하여 정보가 공유되고 후배들이 그들을 대신할 수 있으면 언제 든지 내쳐질 것 같습니다. 살기 위해서는 소스코드와 업무지식을 내 놓지 않고 꽉 쥐고 있어야 하는데, 점점 쉽지 않아집니다. 이렇게 된 가장 큰 이유는 회사의 소프트웨어.. 더보기