2011년 1월 31일 월요일

이번 프로젝트 내일 끝나?

SW개발 프로젝트가 언제 끝날지 정확하게 모르는 경우가 허다하다.

프로젝트를 진행하고 있는 개발자나 PM도 이 프로젝트가 언제 끝날지 전혀 감이 안잡히는 경우가 많다. 
하지만 분명한 것은 이 프로젝트가 예정된 종료일까지는 끝나지 않을 것이라는 것은 아주 잘 알고 있다.
이것을 알고 있다면 일정을 연기해야 하는데 언제로 연기를 해야 하는지 알 수 없으니 일정 연기를 요청하기도 어렵다. 일정을 연기 했으면 그 일정은 지켜야 하는데 연기된 일정도 전혀 근거가 없이 그냥 감으로 생각한 일정이기 때문이다. 이런 일정은 또 연기되기 마련이다.

그래서 Due date이 되어서어 끝나지 않음을 알고 일정 연기를 요청하고 한다. 이렇게 촉박하게 일정이 자주 연기가 되면 영업이나 마케팅 부서에서는 도저히 개발팀의 일정을 믿을 수 없어서 자신있게 비즈니스를 하기 어려워진다.

그럼에도 일정이 늦어지고 있는 것을 늦게 알려주는 이유는 미리 얘기를 해봤자 일찍 혼나기 밖에 더하겠냐는 생각때문이기도 하다. 일정이 촉박해지면서 매일 야근을 하면서 열심히 하는 모습을 보여주면 일정을 연기해도 큰게 혼나지 않을 것이라고 생각하곤한다. 

하지만, 경영자 입장에서는 밤새면서 일정 못지키는 프로젝트보다는 6시에 퇴근하고 약속한 일정을 지키는 프로젝트가 훨씬 낫다. 그렇다고 주먹구구로 개발하면서도 일정을 터무니없게 길게 잡으면 곤란할 것이다.

제대로된 조직, 프로세스, 시스템을 갖추고 있는 회사에서 SRS를 적절하게 썼다면 1년짜리 프로젝트에서 1주일 지연이 되는 것을 6개월전에도 알 수 있다. PM은 이런 일정 지연이 생기면 이를 복구하기 위한 다양한 기법들을 사용하게 된다. 따라서 일정에 맞춰서 프로젝트를 마칠 수 있는 가능성은 대단히 높아지게 된다.

더 이상 개발팀에게 "내일은 끝나나?"라고 물어볼 필요가 없다. 개발팀도 신뢰를 회복할 수 있을 것이다.
또한, 더 중요한 것은 6시에 퇴근을 하면서도 프로젝트를 더 일찍 끝낼 수 있다는 것이다.

심정적으로 경험적으로 이것이 믿어지지 않는 분들도 많겠지만, 필요한 만큼 적절히 체계화 된 개발을 하고 SRS와 설계를 적절하게 하면 프로젝트 일정도 지키고 개발자도 행복해진다.

여기서 중요한 것은 적절하게 하는 것이다. 적절하다는 것이 가장 어려운 것 중 하나다.

2011년 1월 22일 토요일

우리 회사에도 숨어서 놀고 있는 개발자가 있나?

소프트웨어 개발 조직은 전통적인 관리 방법이 별로 효과적이지 않습니다. 

소프트웨어 개발 조직은 프로세스와 시스템에 의한 자율적이고 투명한 방법이 필요합니다. 그런데 전통적이고 관료적인 관리 방법도 사용하지 않고 효율적인 프로세스와 시스템도 사용하고 있지 않는 조직에서는 개발자들이 어떻게 일을 하고 있는지 잘 파악안되곤 합니다.

물론, 놀고 있는 개발자를 찾아내고자 이 글을 쓰는 것은 아닙니다. 개발자들은 스스로 자신이 해야할 일을 찾아내고 스스로 관리해야 합니다. 물론 개발자에게 업무와 이슈가 할당되고 자신에게 주어진 일을 해야 하지만 이것이 다가 아니고 많은 일들은 스스로 해야만 회사가 경쟁력을 갖출 수 있습니다.

그러기 위해서는 효율적인 프로세스와 시스템을 갖추고 있어야 하고 문서화도 잘 해야 합니다. 그러다보면 누가 얼마나 많은 일을 했는지 자연스럽게 드러나게 됩니다. 거꾸로 들키지 않고 일을 하지 않기도 어렵습니다.

개발자들이 얼마나 많은 일을 했는지 다음을 보면 알 수 있습니다.
  • SCM 사용기록 통계
    • 소스코드 라인수
    • 문서 갱신 기록
    • 다른 개발자의 코드를 리뷰한 기록
  •  Bug Track System 사용 통계
    • 보고한 이슈
    • 할당된 이슈
    • 해당 기간 동안 해결한 이슈
    • 댓글 수
  • 리뷰 기록
    • 리뷰 실시 기록
    • 리뷰 참석 기록
  • Wiki 작성 기록
  • 문서관리시스템 업데이트 기록

물론 이 기록들을 점수를 매겨서 누가 더 열심히 일했는지 절대로 알 수는 없습니다. 같은 소스코드 라인수라고 해도 서로 난이도가 다르고 버그를 똑같이 고쳐도 10분 걸리는 버그가 있는가 하면 한달동안 고쳐야 하는 버그가 있기 때문입니다. 따라서 평가에 직접적인 기준으로 삼는 것도 위험합니다.

개발자들은 이러한 시스템을 통해서 자신이 하는 작업들이 항상 기록에 남고 별도의 관리를 하지 않아도 항상 모니터링할 수 있습니다. 이러한 방법이 매일 해야 하는 일을 일일이 관리하는 것보다 훨씬 효율적입니다.

일안하고 숨어서 딴짓하는 개발자를 찾아내는 것은 그냥 부수적인 효과일 뿐입니다.

2011년 1월 20일 목요일

망할 회사로 옮겨타는 방법

많은 개발자들이 현재 회사에서 희망을 느끼지 못하고 회사를 옮깁니다. 그런데, 옮긴 회사도 별반 다를 바가 없는 경우가 많습니다. 그럼 어떤 회사로 주로 옮기게 될까요? (사실 좋은 회사 찾기 정말 힘듭니다.)

  • 망하지 않을 회사? (내가 다니는 동안에는 ...)
  • 정말 재미있는 일을 할 수 있는 회사 또는 좋은 사람과 같이 일할 수 있는 회사?
  • 이전 회사보다 연봉을 많이 주는 회사? (훨씬 많이)

이 모두 이직하는 회사의 조건들입니다. 하지만 아무리 재미있는 일을 할 수 있고 연봉이 많아도 회사가 망해버리면 소용이 없습니다.

망하지 않을 회사는 왠만해서는 망하지 않을 큰 회사이거나 작지만 알찬 회사일 것입니다. 큰 회사들이야 S사나 N사 등 다들 알고 계실 것입니다. 연봉도 작은 회사보다는 많죠. 이런 회사에서 일까지 재미 있다면 금상첨화지만 욕심 같네요. 주로 안정성 때문에 선택을 하게 되겠죠.

큰 회사도 좋지만 저라면 작지만 재미있게 일할 수 있고 성장 가능성이 높은 회사를 선택하겠습니다. 그럼, 작은 회사 중에서 망하지 않을 회사를 어떻게 고를 수 있을까요? 벤처투자가들이 이것을 알았다면 다들 떼돈을 벌었겠죠?

실제로 꽤 유명하고 규모도 큰 회사가 속은 썩어 있고 망하는 길로 가고 있는 회사는 의외로 많습니다.

제 블로그에 예전에 등록한 소프트웨어 회사의 개발 역량 평가표를 통해서 평가를 해보면 약간의 도움이 될 것입니다. 옮기려는 회사 내부에 이를 평가해줄 친구가 있다면 가능하겠지만 그렇지 않다면 알아낼 방법이 없겠죠. 물론 개발 역량이 회사의 성공을 위한 필요충분 조건은 아니지만 필요조건이기는 합니다.

회사의 내부 정보를 알아 낼 수 없다면 경영자를 살펴보는 것이 좋겠습니다. 대부분의 소프트웨어 회사가 특정 단계를 넘지 못하고 꺾이는 결정적인 이유는 경영자의 마인드에서 찾을 수 있습니다. 소프트웨어 회사에서 경영자가 소프트웨어를 이해하지 못한다면 특정 규모 이상으로 성장할 수 없습니다. CEO가 소프트웨어에 대한 이해가 부족하면 CTO가 이를 대신해주는데 우리나라 대부분의 소프트웨어 회사는 CTO가 없거나 CTO가 있어도 CTO역할을 하지 못하고 있습니다.

따라서 회사를 옮길 때 CEO 또는 CTO가 소프트웨어에 대해서 어떤 생각을 가지고 있는지 파악을 해보면 조금더 즐겁게 일할 회사, 그리고 앞으로 더 성장할 수 있는 회사로 옮길 가능성이 조금더 높아질 것입니다. 

2011년 1월 18일 화요일

평가를 어떻게 해야 할까?

개발자 여러분 평가철이 다가왔습니다. 이미 평가를 끝낸 회사도 있을 것이고 한창 평가를 하고 있는 회사도 있을 것입니다.

평가가 항상 만족스럽고 공정하다고 생각하나요? 그렇지 않은 분들이 더 많을 겁니다.

평가 시에 자주 보는 것은 개발자들 순위 매기기 입니다. 흔히 "나래비" 세운다고 하죠. (일본말에서 유래)
대부분의 개발자들은 이런 순위매기기의 결과가 공정하지 않다고 생각하고 팀워크를 깨기 일쑤입니다.

A평가를 받은 개발자와 D평가를 받은 개발자의 차이가 크지 않은 경우가 많습니다.  심지어는 더 잘한 개발자가 더 낮은 평가를 받는 경우가 흔합니다. 그런데 평가시스템에서 A는 10%, B는 50%, C는 30%, D는 30%를 할당 받아서 무조건 나눠야 하는 경우가 있습니다. 개발자가 5명밖에 안된다면 나누기도 어렵습니다. 기계적인 평가시스템 적용이 1년 동안 고생한 개발자들을 한순간에 힘을 잃게 할 수도 있다.

물론 D 평가를 받아야 할 개발자도 있을 수 있으나 열심히 일했고 성과도 꽤 잘 냈음에도 불구하고 D평가를 받는 개발자들도 있습니다. 그렇다고 평가를 관리자 마음대로 하라고 할 수도 없습니다. 그럼 더 엉망이 될 것입니다. 

평가는 불공평할 수밖에 없지만 불공평하다는 의식이 너무 팽배해지면 개발자들이 진정으로 열심히 하려고 하지 않을 것입니다. 평가를 잘 받기 위한 편법이 난무할 수 있습니다.

이렇게 평가가 공정하지 못하다는 인식은 평가의 기준이 애매하거나 없기 때문인 경우가 많습니다. 팀장 또는 관리자가 맘에 내키는 대로 평가를 하면 무슨 기준으로 평가를 했는지 알 수 없는 개발자들은 평가 결과를 납득하기가 어렵습니다.

그렇다고 너무 구체적인 평가 기준(KPI)도 문제가 됩니다. 몇가지 예를 보죠.

  • 개발 일정을 맞추면 평가를 잘 주겠다. 
    코드는 엉망으로 만들어서 유지보수를 어렵게 만들지만 일단 일정은 지킵니다. 하지만 나중에 유지보수 개발자들이 엄청난 고생을 하게 됩니다.
  • 버그를 많이 찾으면 평가를 잘 주겠다. 
    테스터는 스펙, 설계단계의 검토를 소홀히 하여 버그가 더 많이 발생하도록 합니다. 전체적으로 프로젝트 기간이 늘어나고 비용도 증가합니다.
  • 버그를 적게 만들면 평가를 잘 주겠다.
    개발자는 최대한 일을 적게 하려고 하게 됩니다. 약간의 리스크가 있는 시도도 두려워하게 되며 새로운 기술도 연구하지 않게 됩니다.

이쯤 되면 개발자는 공장의 생산직 직원처럼 평가가 불가능하다는 것을 눈치채셨을 겁니다. 개발자들은 원래 돈에 그렇게 좌지우지 되지 않는데 공정하지 않은 평가를 몇번 받게 되면 기분이 나빠서라도 평가를 잘 받기 위해서 편법을 동원할 수 있게 됩니다.

흔히 하는 실수 중의 하나가 평가가 이렇게 부정확한데도 불구하고 평가에 의해서 A와 D 등급의 개발자를 엄청난 연봉 인상의 차이를 두면 개발자들이 더욱 열심히 일할 것이라고 생각하는 것입니다. 이는 착각이며 자칫하면 평가만 잘 받기 위한 편법이 난무하게 되며 평가의 결과는 불공정하다는 불만만 팽배하게 됩니다.

공정한 평가는 필요하지만 100% 공정하기는 불가능합니다. 그렇다고 평가를 하지 않을 수 없습니다. 평가는 잘못 휘두르면 안 한 만도 못하게 되고 그렇다고 안 할 수도 없는 균형잡기 어려운 줄타기입니다. 그리고 다음과 같은 기준은 세울 수 있습니다.

  • 평가 기준은 회사의 비전과 일치해야 한다.
  • 평가 기준은 평가자나 피평가자 모두가 납득해야 한다.
  • 평가 기준은 연초에 미리 정해야 한다. 
  • 평가 기준은 객관적이어야 한다. 즉 평가 가능해야 한다.
  • 평가 결과를 너무 믿지 말아야 한다. 적당히 활용해야 한다.
평가의 목적은 결과를 보고 상과 벌을 주기 위한 것이 아닙니다. 평가기준이 회사의 비전을 절묘하게 잘 반영하여 하나의 목표를 가지고 매진할 수 있도록 하기 위한 것입니다. 잘 만들어진 평가 기준은 평가 결과를 가지고 벌을 주지 않아도 이미 목표를 달성한 것입니다.

A를 받은 개발자는 기분이 좋고 C나 D를 받아도 별로 기분이 나쁘지 않은 그런 평가 어디 없을까요?

2011년 1월 17일 월요일

기존 소프트웨어를 버리고 언제 새로 만들어야 할까?

Windows Vista가 나온지 얼마 되지도 않은 시점에서 Windows7이 나온다고 하더나 이제는 Windows8이 출시될 것이라는 얘기가 떠돌고 있습니다.
아이폰4도 출시된지 알마 안된 시점에서 아이폰5가 출시될 것이란 얘기가 나왔습니다. 어쩔 때는 이것이 진짜인지 그냥 루머인지 구분이 안되기도 합니다.

소프트웨어 개발을 제대로 이해하고 있는 사람들이라면 Windows7이 출시됨과 동시에 또는 이미 그 이전에 Windows8은 시작이 되었다는 것을 알 수 있습니다.

소프트웨어는 끊이 없이 업그레이드가 되어야 합니다. 그러다보면 새로운 요구를 더이상 담을 수 없는 시점이 오게 됩니다. 그래서 소프트웨어의 아키텍쳐도 끊이 없이 발전하게 됩니다. 

지금의 소프트웨어가 새로운 요구를 더이상 담을 수 없는 그릇이 되게 되면 이미 상당히 늦었다고 볼 수 있습니다.
미래에 생길 요구사항을 미리 예상하여 그 구조를 만드는 것이 소프트웨어 아키텍쳐링입니다. 물론 예언자처럼 미래의 모든 상황을 예측할 수는 없지만 상당부분 예측을 해야 하며 여기서 성공을 하느냐, 실패를 하느냐에 따라서 비즈니스의 성공이 달려있습니다.

그런데 현실에서 보면 소프트웨어 아키텍쳐를 바꿔야할 시점을 놓친 회사들이 매우 많습니다. 이런 회사의 특징은 다음과 같습니다.
  • 소프트웨어에 기능을 추가하거나 버그를 수정하려고 해도 기존의 소스코드가 워낙 복잡해서 분석도 어렵고 고치는데 시간이 많이 들어간다.
  • 버그를 수정해도 이전에 없었던 문제가 자꾸 다시 생겨난다.
  • 유지보수에 바빠서 신규 제품 개발은 꿈도 못 꾼다.
  • 기존 제품을 잘 알고 경험이 많은 개발자들은 유지보수하느라고 바빠서 새로운 아키텍쳐를 연구할 시간이 없다. 그래서 신규 개발자를 투입했는데 진도가 안나간다.
뻔히 다 알다시피 우리나라 대부분의 소프트웨어 회사들은 초창기에 뛰어난 몇몇 개발자들이 주먹구구식으로 상당히 좋은 소프트웨어를 개발해서 좋은 평가를 받으면서 성장해왔습니다. 그런데 회사가 커지고 소프트웨어가 커지면서 작은 조직일 때는 드러나지 않은 주먹구구 방식 때문에 효율성이 급격히 떨어지게 됩니다. 그러다보니 항상 유지보수에만 매달리고 신규 개발에는 투자를 못하게 됩니다. 대부분의 경우 소프트웨어 아키텍쳐가 4~5년 넘어가게 되면 더이상 버티기 어려운 상황에 닥치게 됩니다.

이미 마지막 기회를 놓친 회사들은 끊임 없는 유지보수에 매달리면서 회사의 쇠락을 지켜볼 수 밖에 없습니다. 수많은 회사들이 지금이 마지막 기회라는 것을 인지하지 못하고 지나쳐 버리는 것을 보면 안타깝습니다. 그나마 영업이 잘되는 회사는 막대한 인원과 자금을 투입하여 점점더 되돌아 오기 어려운 길로 가버리기 때문에 회생하기 더 어려워 집니다. 이렇게 침몰하는 거대한 여객선 같은 소프트웨어 회사들이 상당히 많고 경영진들이 이를 알지 못하는 경우도 매우 많습니다. 경영진들은 개발에서 구멍이 났다는 것을 알아도 그 구멍을 어떻게 매워야 하는지 정확하게 모르는 경우가 대부분입니다. 그래서 이런 저런 시도를 하다가 침몰만 가속화 시키곤 합니다. 그래도 시도를 안할 수는 없겠죠.

그럼, "언제 다시 만들어야 하는지?" 질문으로 돌와와 보죠. 
회사마다 제품의 성격과 규모마다 다르지만 대부분은 첫번째 제품이 개발되면서 이미 두번째 제품의 기획도 시작이 되어야 합니다. 또한 두번째 제품을 누가 개발을 할지 언제 개발을 할지 계획을 미리 가지고 있어야 합니다.
첫번째 제품은 개발 후에 유지보수는 어떻게 진행을 하고, 누구는 두번째 제품에 투입이 되어야 하는지 등의 계획을 미리 가지고 있어야 한다는 뜻입니다.
이 얘기는 무슨 뜻이냐면 처음부터 개발을 체계적으로 하면 된다는 뜻입니다. 분석이 제대로 되고 설계가 제대로 되어야 해결이 된다는 얘기 입니다.

그럼 이미 첫번째 제품을 주먹구구식으로 개발을 한 회사는 어떻게 해야 할까요? 지금이라도 두번째 제품을 체계적으로 다시 기획을 해야겠죠. 주먹구구의 결과로 필요한 상당히 많은 자료는 개발자들의 머리속에 들어 있습니다. 이것들을 끌어내서 문서화 하면서 두번째 제품을 기획하고 분석을 해내야 합니다. 개발자들은 이미 기본의 제품이 가지고 있는 문제점과 개선점을 아주 잘 알고 있습니다. 문제는 이것들이 문서화가 되어 있지 않고 리뷰가 안되었다는 겁니다. 이것들을 문서로 끌어내는 것만으로도 두번째 제품의 상당한 스펙이 됩니다. 또한 업계 동향과 신기술도 끊임 없이 조사를 해야 합니다.

그럼 이미 두번째 제품을 만들 마지막 기회를 놓친 회사들은 어떻게 해야 할까요? 
늦었다고 생각할 때가 가장 빠른 때입니다. 쉽지는 않겠지만, 큰 고통이 따른 변화가 필요합니다. 기존의 영업의 손실을 감수하고라도 유지보수 정책의 전면적인 변화가 필요하며 새로 투자를 더 해야 할 수도 있습니다. 회사의 조직과 프로세스의 전면적인 개혁도 필요할 것입니다. 즉, 다시 원칙에 충실해야 한는 거죠. 이 과정에서 개발자나 회사 모두 고통이 따르겠지만 이렇게 해서 성공할 것 같으면 시도를 할 수도 있고 그런 확신이 없다면 그냥 지켜보는 수 밖에 없을 겁니다. 

귀사의 소프트웨어는 어느 시점에 와 있나요? 곰곰히 생각해보시기 바랍니다.

2011년 1월 9일 일요일

왜 나만의 방법이 실패하는지? (NIH 신드롬)

NIH(Not invented here) 신드롬이란?
카츠와 알렌(Katz & Allen)은 기업연구에서 “선진 기업의 연구조직은 흔히 자신들이 직접 개발하지 않은 기술이나 연구 성과에 대해 배타적 성향으로 보인다”고 주장하며 이러한 현상을 NIH 신드롬이라고 정의했다.

소프트웨어를 개발하는데 있어서도 NIH신드롬과 유사한 현상이 많이 발생합니다.
개발하는데 필요한 라이브러리나 개발 방법, 개발툴들을 모두 입맛에 맞게 직접 만들어서 쓰는 경우를 말하는 겁니다.

우리나라의 개발자들이나 소프트웨어 회사들은 특히나 더 자신만의 방법들을 선호하는 경향이 있는 것으로 생각됩니다. 여러가지가 이유가 있겠지만 몇가지만 나열해보면 다음과 같습니다.
  • 라이브러리를 구매하는 비용을 비싸다고 생각한다. 특히나 회사에서 개발에 필요한 라이브러리는 잘 안사준다.
  • 더 좋은 방법이나 라이브러리, 툴이 있을 수도 있지만 이것들을 찾을 시간이 없이 바쁘거나 귀찮다.
  • 관련 자료들이 대부분 영어로 되어 있는데 영어가 딸려서 영어로 된 자료는 꺼려한다.
  • 외부의 기술이나 방법은 자신이나 회사의 상황에 맞지 않는다고 생각한다.
  • 자신의 기술과 실력이 더 우월하다고 생각한다.
  • 주변에 경험이 많은 선배들이 적어서 자문을 구하기가 어렵다.
이러한 현상은 집을 만들어야 하는 사람이 나에게 알맞은 망치는 내가 더 잘 만든다고 생각하고 망치도 직접 만드는 것과 비교할만 합니다.

 상용 라이브러리는 비싸다.

흔히들 상용라이브러리는 너무 비싸다고 생각하고 직접 만들어 쓰는 경향들이 있습니다. 하지만 직접 만들어 쓸 때 발생하는 유지보수 비용은 미처 생각하지 못하고 이런 결정을 하는 경우들이 많습니다. 아니 이런것들을 고려하는 것은 커녕 개발자들이 무슨 라이브러리를 만들었는지 회사에서는 또는 동료들은 잘 모르는 경우도 있습니다.
물론 세상에 이전에는 없었던 라이브러리던가 진짜 그 회사만의 독특한 상황을 반영한 라이브러리나 툴이 없는 경우는 예외일 것입니다. 경계할 것은 이런 경우는 그렇게 흔하지 않기 때문에 착각하면 안될 것입니다.

일단 직접 만들고 나면 유지보수 비용이 상용 라이브러리를 썼을 때보다 비용이 몇배 더 드는 경우가 아주 흔합니다. 이때 직접 개발한 것이 훨씬 비싸다는 것을 깨달았어도 이쯤되면 다시 되돌리기가 매우 어렵습니다. 앞으로도 비용이 계속 더 들 것이지만 이를 되돌리는데도 너무 비용이 많이 들기 때문에 그냥 계속 가는 수밖에 없는 경우가 많습니다.

요즘은 오픈 소스 라이브러리가 매우 많으므로 선택의 폭이 매우 넓습니다. 이때 오픈 소스를 수정해서 쓰게 되면 나중에 오픈 소스가 업그레이드 되었을 때 머지(Merge)하는 것이 어려울 수 있으므로 이에 따른 비용도 감안해서 검토해야 합니다.

 직접 만들 시간은 있어도 남이 만든 좋은 것을 찾을 시간은 없다.
사실 대한민국의 개발자들은 항상 바쁜 것처럼 보입니다. 그래서 차분하게 검토할 여유가 없습니다. 이는 매우 안타깝게 생각합니다. 또한 뭔가 계속 코딩을 해야 일한 것 같은 분위기는 검토하는데 시간을 쏟는 것을 어렵게 만듭니다.

라이브러리를 무작정 직접 만들기보다는 쓰기 적합한 좋은 상용라이브러리가 없는지 미리 검토하는데 시간과 노력을 투자하는 것이 대충 만들어 놓고 나중에 후회하는 것보다는 훨씬 효율적입니다. 물론 모든 검토 결과 직접 만들어 쓰거나 오픈 소스를 수정해서 사용하는 것이 더 좋다는 결론이 날 수도 있습니다. 하지만 이런 결정을 하기 위해서 쏟은 노력과 시간은 그렇게 아깝지 않습니다.

 영어자료는 꺼려진다.
이 부분에 대해서는 할 말이 별로 없습니다. 영어는 소프트웨어 개발자를 평생 따라다닙니다. 꾸준히 공부하는 수 밖에 없을 겁니다.

 이건 우리에게는 맞지 않다.
"우리회사는 다르다."라고 생각하는 것은 착각입니다. 우리에게 필요한 것의 99.99%는 이미 다 나와 있다고 생각하면 됩니다. 즉, 있을 것은 다 있고 문제는 가격, 배우는 비용 등입니다. 
그리고 프로세스나 툴을 보면 특히나 자신의 회사가 독특하다고 생각하는 사람들이 많습니다. 물론 이 세상에 똑같은 회사는 하나도 없습니다. 하지만 소프트웨어를 개발하는 방법은 거의 모든 회사가 별로 다르지 않습니다. 유명한 툴이나 흔히 사용하는 프로세스가 자신의 회사와는 맞지 않다면 자신의 회사에 딱 알맞은 것을 무조건 만들기보다는 회사의 프로세스가 잘못된 것이 아닌가 먼저 검토해보는 것이 좋습니다. 회사의 프로세스가 잘못된 경우가 99%입니다.
거꾸로 말하면 세계적인 툴이나 프로세스를 쓰면서 이에 적응해 가는 것이 개발을 더욱 효율적으로 만드는데 도움이 될 수 있습니다.

 내가 더 잘한다.
지금 내가 가지고 있는 지식은 99%이상 선각자들이 이룩해 놓은 것들입니다. 모짜르트도 제대로된 방법으로 훈련을 받지 못했으면 지금같이 위대한 작곡가가 되지 못했을 겁니다. 
99%의 것을 배우는데 노력하고 거기에 내가 1%를 더하는 것이 올바른 방법일 겁니다. 

물론 특정 분야에서 이전의 모든 선각자보다 뛰어난 사람이 있을 수 있습니다. 이렇게 뛰어난 개발자라면 그 실력을 망치를 만드는데 쓰기 보다는 빌딩을 만드는데 쓴다면 더 뛰어난 빌딩이 만들어 질 겁니다.
물론 망치를 제일 잘만드는 사람은 망치를 만들어서 팔면 될 것입니다.

 물어보고 싶은데 물어볼 사람이 없다.
이 부분도 안타깝습니다. 대분의 개발자들의 경험담을 들어보면 회사에 입사에서 별로 배우지 못했다고 합니다. 회사를 입사해서 스스로 거의 모든 것을 만들어야 했고 선배들이 별로 없는 경우가 많았고, 회사가 커진 다음에 입사를 한 경우에도 선배들도 유지보수에 바빠서 각자 개발하느라고 정신이 없어서 선배들에게 별로 배울 기회가 없었다고들 합니다.
다행이라면 요즘은 인터넷을 통한 소셜 커뮤니티가 발달해서 정보를 공유하기 훨씬 수월해졌습니다. 이런 다양한 외부 자원들을 활용하는 것도 좋은 방법입니다.

 결론
소프트웨어를 개발하면서 내가 겪는 거의 모든 상황은 이전에도 있었습니다. 그것도 매우 여러번 발생했었고 그에 대한 해결책도 이미 다 나와있습니다. 라이브러리, 툴, 프로세스 거의 모든 것이 이미 나와있고 이중에서 꼭 필요한 것을 제대로 찾아서 사용하는 것이 매우 중요하며 쉽지 않은 일입니다. 
뭔가 툴이나 라이브러리를 만들고 싶으시면 한번 더 생각해봅시다.

2011년 1월 3일 월요일

매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일)

필자가 컨설팅을 진행했던 수많은 회사들 중에서 80% 이상은 불난 호떡집처럼 매일 불끄느라고 정신이 없습니다.
  • 너무 바빠서 새로운 기술을 연구할 시간도 없다고 한다.
  • 프로젝트를 진행할 때도 가장 빠른 방법으로 문서도 작성하지 않고 가장 뛰어난 개발자가 바로 코딩부터 한다고 한다.
  • 고객들은 기다려주지 않기 때문에 요구하자마자 바로 며칠 안에 제품에 기능을 반영해야 한다고 한다.
  • 제품에 버그가 발견되면 하루 이틀 안에 버그를 수정해줘야 한다. 그렇지 않으면 고객들이 엄청나게 컴플레인을 한다.
  • 사소한 버그 수정도 빨리 해야 하기 때문에 신입 개발자들에게는 시킬 수가 없다. 고참 개발자가 2시간이면 고칠 것을 신입 개발자를 시키면 2일이 걸릴 뿐더러 고참 개발자가 신입 개발자에게 일을 시키고 검토해주는데 2시간이 넘게 걸린다.
  • 제품의 아키텍처가 취약해서 기능을 추가할 때 아주 애를 먹는다. 언제 시간을 내서 아키텍처를 깨끗하게 새로 만들고 싶지만, 유지보수에 바빠서 도저히 그럴 시간이 나지 않는다.
  • 이러다 보니 수시로 야근이다. 
  • 운동할 시간도 없어서 몸이 점점 망가진다.
  • 영어공부도 하고 싶은데 시간이 없다.

이런 회사의 미래는 누구나 짐작할 수 있습니다. 
설령 제품이 고객들 입맛에 맞고 영업도 잘되어서 큰 성공을 이뤘다고 하더라도 시간이 흐를 수록 채산성은 악화되고 개발자들의 사기는 떨어지고 있을 겁니다. 자꾸 옛날에 개발이 더 잘되었다고 회상할 것입니다.

매일 불끄기 모드로는 회사가 성장할 수 없습니다.

회사에서 해야 할 일은 4가지로 구분할 수 있습니다.

 구분중요한 일 중요하지 않은 일  
 시급한 일 A B
 시급하지 않은 일 C D

A. 중요하고 시급한 일
중요한 계약을 따기 위해서 급하게 해결해야 하는 일

B. 중요하지 않으나 시급한 일
일상적으로 제품에 버그를 잡는 일
고객들의 기능 추가 요청을 들어주는 일

C. 시급하지는 않으나 중요한 일
새로운 기술을 연구하는 일
회사의 개발 프로세스를 꾸준히 발전시켜 나가는 일
새로운 아키텍처를 연구하는 일
차세대 제품을 개발하는 일
회사의 개발 문화를 발전시키는 일

D. 중요하지도 않고 시급하지도 않은 일
이런 일은 영원히 미뤄도 된다. 나중에 중요해지거나 시급해질 때 해도 된다.

이 중에서 회사의 미래를 결정짓는 일들은 "C. 시급하지는 않으나 중요한 일"들입니다.
어치파 "A중요하고 시급한 일"은 누구나 열심히 하게 되어 있습니다. 하지만 "B. 중요하지 않으나 시급한 일"을 처리하느라 "C. 시급하지는 않으나 중요한 일"을 처리 하지 않으면 미래는 없습니다.

제가 만난 수많은 회사들 중 대부분은 C에는 거의 신경을 못쓰고 있습니다. B를 조금이라도 소홀히 하면 회사가 당장 망할 것 같은 생각을 하면서 C는 전혀 손을 못댑니다. 거의 99:1인 경우도 많습니다. 하지만 회사를 망하게 하는 것은 C를 소홀히 하는 것이 장기간 지속되는 경우입니다. 평상시에 B와 C에 균형을 가지고 투자를 해야 합니다. 20%~30%는 C에 꾸준히 투자를 해야 합니다. 꾸준히 투자를 하지 않으면 어느날 갑자기 투자를 할 수 없습니다. 지금은 너무 바빠서 중요한 것을 알지만 지금은 투자를 할 수 없다고 말한다면 영원히 중요한 일에 투자를 할 시간은 생기지 않을 겁니다.

"C. 시급하지는 않으나 중요한 일"에 투자를 하는 방법은 여러가지가 있지만 가장 좋은 방법 중에 하나는 조직을 나누는 것입니다. 일부 조직은 항상 중요한 일을 할 수 있도록 하는 겁니다. 또한 개발자들에게도 중요한 일을 소홀히 하지 않도록 항상 상기를 시켜주는 것이 좋습니다.

당장 어렵다면 해야할 일들을 A, B, C, D로 나누기를 먼저 해보시기 바랍니다.