2012년 12월 6일 목요일

개발자, 회사의 과거인가 미래인가

개발자는 소프트웨어 회사의 가장 중요한 자산이면서 서로 상반된 2가지 가치를 가지고 있다.

첫 번째는 ‘과거의 가치’이고
두 번째는 ‘미래의 가치’이다.

나는 과거의 개발자일까? 미래의 개발자일까? 스스로 판단하기는 어려울 것이다. 동료나 경영진에게 내가 퇴사를 하면 어떻게 될까?라는 질문을 해보면 짐작할 수 있다.

내가 퇴사를 하면 과거에 개발해 놓은 제품들을 어떻게 하지?라는 생각이 가장 먼저 들면 ‘과거의 개발자’에 가깝다.

반대로 내가 퇴사를 하면 과거에 개발해 놓은 제품들은 문제가 없는데 미래에 개발할 제품은 누가 개발하지?라는 생각이 들면 ‘미래의 개발자’라고 볼 수 있다.

회사나 개발자 입장에서 권장되는 개발자 타입은 미래 가치를 많이 지닌 “미래의 개발자”이다. 미래의 개발자가 지금은 가치가 적은데 미래에 가치가 높다는 의미가 아니다. 미래에 가치가 더 있고 시간이 흐를수록 점점 가치가 높아진다는 의미다.

과거의 가치를 더 많이 가지고 있는 ‘과거의 개발자’는 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식이 머리 속에 있기 때문에 동료나 신입개발자와 지식을 공유하기 어렵다. 본인이 의도해서 그렇게 한 것은 아니지만 결과적으로 자신이 과거에 만들어 놓은 소프트웨어를 인질삼아 회사와 인질극을 벌이고 있는 것과 같다.

물론 이런 개발자가 퇴사를 한다고 회사가 망하는 것은 아니지만 적게든 많게든 타격을 입게 되고 심한 경우 회사는 퇴락의 길을 걷기도 한다. 따라서 회사는 이런 개발자에게 질질 끌려 다니곤 한다. 이런 상태의 개발자는 스스로도 상황의 피해자일 뿐이다.

미래의 가치를 가진 ‘미래의 개발자’는 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수를 수월하게 할 수 있도록 개발 과정에서 적절히 문서화를 해 놓았고, 아키텍처를 깨끗하게 만들었으며 모든 이슈는 이슈관리시스템에 기록으로 남겨 놓았다. 그리고 Peer review를 통해서 이미 많은 지식을 동료들과 공유를 한 상태다.

이런 합리적인 개발 과정을 통해서 본인은 분석, 설계 능력이 꾸준히 향상되어 왔으며, 회사도 성장에 걸맞게 프로세스와 개발문화가 발전되어 왔다. 유지보수에 허덕이지 않으므로 신기술에 대한 연구에 소홀하지 않아서 미래에는 과거 제품들보다 한 단계 수준 높은 제품을 만들어 낼 것이다.

언뜻 보기에는 과거의 엄청난 폭풍 코딩을 통해서 짧은 시간에 많은 제품을 만들어내는 성과를 낸 ‘과거의 개발자’가 영웅처럼 보이지만 미래의 가치를 지닌 ‘미래의 개발자’가 진정한 영웅이다.

필자는 대기업부터 작은 소기업까지 여러 소프트웨어 회사를 다니면서 개발자와 경영진을 대상으로 소프트웨어 개발에 대해서 강연이나 세미나를 많이 한다. 그럴 때 이런 질문을 하곤 한다.

“오늘 회사를 그만둬도 당장 큰 문제가 발생하지 않는 사람 손들어 보세요”.
“오늘 회사를 그만두면 회사가 당장 큰 일 나는 사람 손들어 보세요”.

이 두 가지 질문 중에서 두 번째 질문에 손을 드는 사람이 상당히 많다. 특히 주변에 특정인을 가리키며 손을 들라고 하는 경우가 많다. 이런 사람은 십중팔구 ‘과거의 개발자’이다.

과거에 엄청나게 많은 일을 해냈지만 대부분은 유지보수에 치여 본인도 발전 못하고 격무에 시달리고 있는 경우이다. 수많은 문제와 이슈는 본인만 알고 있어서 수시로 불려 다니고 정작 본인은 개발할 시간이 없고 발전도 어렵다.

물론 ‘과거의 개발자’양산이 개발자에게 책임이 있는 것은 아니다. 소프트웨어 개발 환경이 회사에서 제공하는 프로세스, 시스템이 열악한 상태에서 전적으로 개발자의 내공에 의존을 하기 때문에 개발자도 어쩔 수 없이 ‘과거의 개발자’가 되어 버리는 것이다.

‘과거의 개발자’가 주도하는 회사는 엄청난 개발자 Risk를 안고 있는 것이다. 뛰어난 개발자가 많지만 이들이 한두 명만 나가도 회사가 휘청대며, 유지보수에 발목을 잡혀서 앞으로 나가기 어려운 상태인 경우가 많다.

회사는 개발자가 개발에 전념할 수 있고 개발 과정에서 꾸준히 성장할 수 있도록 환경을 제공해야 한다. 개발자 경력을 보장하는 것은 물론이고 프로세스와 기반시스템을 제대로 갖추고 개발문화 구축에 제도적인 노력해야 한다. 그렇게 해서 개발자 내공에 의존하는 개발이 아닌 시스템에 의존한 개발이 되어야 한다. 그런 환경에서야 개발자가 최고의 활약을 할 수 있다.

그래야 개발자도 행복하게 개발을 할 수 있고 회사도 개발자 Risk가 줄어든다. 이런 환경에서 성장하는 개발자는 신참때는 주로 코딩을 하지만 고참이 되어 갈수록 설계, 분석에 집중하고 문서를 통한 협업에 능숙해진다. 이런 방법이 개발자와 회사 모두에게 좋은 방법이다.

여전히 개발자의 내공에 의존한 개발 환경을 가진 회사에서 유지보수에 허덕인다고 개발자를 탓하지는 말자. 지금이라도 ‘미래의 개발자’를 위한 환경에 대해서 고민해보자.

책에도 다 있고 이론은 많지만 현실에서 실천이 어려운 것이다. 이론으로는 배울 수 없고 경험에 의해서 밖에 배울 수 없기 때문이다. 책과 이론은 약간의 도움을 줄 뿐이다.


이 글은 Tech it에 기고한 글입니다.

댓글 5개:

  1. 이 글이 뜻 하는 바는 알겠지만, 논리?예시가 적절치 못 한 것 같아서 한 글자 남깁니다. 예시로 들었던, 적절한 문서와 좋은 아키텍처는 보는 사람 입장에 따라서 천차만별입니다. 동일한 문서와 아키텍처도 충분하다고 하는 사람이 있는 반면, 부족하다는 사람도 분명 있습니다. 그렇다고 그 개발자가 과거의 개발자 인가요? 예시가 비약적인 면이 있습니다. 그리고, 유지보수에 허덕되는 사람은 과거 개발자가 아니라, 여러가지 에러케이스에 대응하지 못 한 수준 낮은 개발자 일 뿐 이라고 생각이 듭니다. 글쓰신 분이 컨설턴트라, 개인의 능력 보다는 회사 개발 프로세스의 중요성에 대해 강조 하는데 글의 주안점이 있는 것 같습니다.

    답글삭제
  2. 물론 개발 프로세스도 중요 합니다. 하지만 적절하지 못한 개발 프로세스는 업무의 가중이라는 점도 충분히 컨설턴트 해 주실 수 있는 부분이라고 보여지네요. 많은 이들이 보고, 겪은 것과 같이, 수 많은 제도와 프로세스 때문에 소프트웨어가 하향평준화 될 수 있는 위험도가 분명히 있습니다.

    답글삭제
  3. 제 글중에 http://allofsoftware.net/entry/소프트웨어-관료화 가 있습니다.
    이글을 보면 적절치못한 프로세스로 인해서 효율성이 오히려 낮아지는 위험에 대해서 경고하고 있습니다. 참고하세요.

    답글삭제
  4. 안녕하세요. 저는 컨설턴트이기 전에 소프트웨어 개발자입니다. 따라서 개인의 역량을 매우 중요한 요소로 보고 있습니다. ^^ 각 글마다 주안점이 다르므로 여러 글을 읽어보시고 종합적으로 생각하시면 좋겠습니다.

    답글삭제
  5. 와... 이렇게 좋은 블로그를 이제서야 발견하게 되다니 ㅠㅠ
    요즘 개발자와 함께 일하는것 때문에 많은 고민인데,
    주옥같은 글 감사합니다. ^-^

    답글삭제