2009년 7월 16일 목요일

모짜르트와 두 제자

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

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

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

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

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

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

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

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

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

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

2009년 7월 15일 수요일

레퍼런스 있어요?

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

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

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

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

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

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

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

2009년 7월 13일 월요일

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

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

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

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

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

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

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

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

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



2009년 7월 9일 목요일

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

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

이러한 생각의 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 담당자가 있는 것이 더 효율적입니다.

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

2009년 7월 3일 금요일

살아남은 개발자들

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

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

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

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

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

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

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

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

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

2009년 6월 29일 월요일

도대체 얼마나 자세히 적어 달라고?!

소프트웨어 개발자들에게 문서 작성은 고역이 아닐 수 없습니다. 그래서 문서는 소프트웨어를 개발한 후에 후배들에게 소프트웨어에의 스펙과 구조를 설명하기 위해서 작성하곤 합니다. 이런 경우에는 문서의 효용성도 별로 없을 뿐더러 문서가 제대로 작성되었는지 알기도 어렵습니다. 또 개발자들은 기억을 더듬어서 문서를 작성하기도 어려울 뿐더러 이러한 작업은 하기 싫은 고역이 될 수 밖에 없습니다.

소프트웨어를 개발하는데 있어서 필수적인 문서의 대부분은 개발한 내용을 정리하기 위해서 만드는 것이 아니고, 소프트웨어를 개발하는데 필요한 내용을 앞 단계에서 작성하는 것입니다.

즉, 설계를 하기 전에 스펙을 작성하고

구현을 하기 전에 설계서를 작성하고

테스트를 하기 전에 테스트 계획 및 TCL(Test Case List)를 작성합니다.

하지만 현실에서는 이렇게 작성된 문서를 가지고 다음단계 작업이 잘 안 된다는 문제가 있습니다.

즉, 다른 개발자가 작성한 스펙을 가지고 설계 및 구현(코딩)을 할 수가 없는 경우가 대부분입니다.

스펙을 제대로 작성하려면 남이 설계할 수 있을 정도로 상세하게 적어야 하는데, 잘못하면 백과사전이 되고 또는 흔히 빈약한 스펙서를 작성합니다. 이렇게 되면 스펙을 작성한 사람이 또 설계자에게 계속 스펙을 설명해줘야 합니다. 

이 글을 읽고 있으면서 이것이 뭐가 문제라고 생각하신다면 이미 가내수공업식 개발에 익숙해지신 겁니다. 한 개발자가 스펙도 작성하고 설계, 구현, 테스트를 모두 다하는 이런 가내수공업식 개발은 회사는 성장의 한계에 부딪히고, 개발자는 성장하지 못하는 악순환에 빠지기 쉽습니다.

개발문서는 그 문서를 보고 다음단계의 개발자들이 충분히 일을 진행할 수 있을 정도로 상세해야 합니다.

따라서 상세화 정도는 상황에 따라서 다르다는 것을 알 수 있습니다. 설계자가 해당 제품에 대해서 빠삭하게 알고 있으면 기능스펙을 적당히 적어도 문제가 없을 것이고, 신입사원에게 일을 시키려면 좀더 자세히 적어야 할 것입니다. 

또한, 좀더 작은 양으로 이해 가능한 문서를 작성하려면 소프트웨어를 다양한 뷰에서 바라보고 적어 주는 것이 좋습니다. 따라서 스펙을 작성할 때는 소프트웨어를 인터페이스에서 바라본 모습, UI에서 바라본 모습 그리고 기능, 비기능적인 내용을 적어주면 기능에 대하여 많은 양을 설명한 것보다 더 이해하기 쉽습니다.  설계에 있어서도 소프트웨어의 아키텍처를 데이터 관점, Flow 관점, 시간의 흐름, 시스템의 상태 등 다양한 관점에서 바라본 모습을 적당히 표현해 주는 것이 하나를 자세히 적어 주는 것보다 좋습니다.

매우 추상적인 글을 적어 놓은 것 같지만, 실제 개발문서를 제대로 적기 시작하면 잘 적었는지? 못 적었는지는 명확하게 구분 됩니다. 작성된 문서를 가지고 다음 단계 개발자들이 별 무리 없기 개발을 할 수 있고, 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

그래서 이를 위해서 기법을 쫓기 보다는 실제로 필요한 것이 무엇인가 생각하고 실질적인 접근이 필요합니다. 잘못 익힌 기법은 독이 될 수 있습니다.

2009년 5월 26일 화요일

왜 이리 버그가 많아요?

소프트웨어 릴리즈는 그 성격에 따라서 몇 가지 형태로 구분이 됩니다.

소프트웨어는 그 종류가 셀 수 없이 많아서 획일적으로 얘기할 수는 없어도, 릴리즈를 구분하여 부르는 것은 필요합니다. 릴리즈를 구분하다는 것은 현재 릴리즈가 어떠한 것이고, 그에 따라서 어떠한 프로세스를 따라야 하고, 어떠한 기대값을 가져야 하는지 그 이름만 들어도 알 수 있게 합니다.

하지만, 팩키지를 개발하는 소프트웨어 회사는 나름대로 릴리즈 구분에 익숙해져 있지만, SI회사, 게임회사, 포탈 등의 서비스 회사, 금융회사들은 릴리즈는 그냥 릴리즈라는 생각을 하고 합니다. 따라서 수많은 릴리즈를 함에도 불구하고 각 릴리즈를 부르는 버전도 없는 경우가 허다하고, 개발자가 임의대로 릴리즈를 하는 경우도 많습니다.

그럼 릴리즈를 어떻게 구분하여 부르면 의사 소통에 도움이 될지 알아보죠.


업그레이드 릴리즈 (Upgrade release)

계획된 일정에 따라서 제품의 주요한 기능이 바뀌어서 릴리즈 되는 것을 일컫습니다. 그 규모와 성격에 따라서 메이져 또는 마이너 업그레이드라고 하고 정상적인 개발 프로세스를 거치며 테스트로 전 기능에 걸쳐서 철저하게 이루어 지는 것이 보통입니다.


패치 릴리즈 (Patch release)

특정 기능에서 발생한 버그나 작은 기능을 개선한 것들을 모아서 릴리즈 하는 것을 말합니다. 보통 계획적으로 일정을 잡거나 업그레이드 릴리즈 후 고객들의 반응을 보고 패리 릴리즈 일정을 잡기도 합니다. 보통 유지보수 개발자들이 개발을 담당하고 테스트로 업그레이드 릴리즈 때보다는 간소화 하기도 합니다.


핫픽스 (Hotfix)

심각한 버그가 발견되어서 긴급하게 특정 고객을 대상으로 또는 전체 고객에게 버그를 수정한 버전을 전달하는 것을 말합니다. 이 경우 사안이 긴급하여 개발 및 테스트 프로세스가 상당부분 생략되며, 이로 이한 위험부담을 어느 정도 감수하는 릴리즈를 말합니다.

또 제품의 완성도에 따라서 알파, 베타, RC 릴리즈로 나뉠 수 있습니다.


알파 릴리즈는 제품의 기능은 구현이 다 되었으나 버그는 좀 있을 수 있습니다. 하지만, 제품을 더이상 써 볼 수 있는 정도의 심각한 버그는 없어야 합니다.


베타 릴리즈는 제품의 심각한 버그는 거의 없어서 기능을 거의다 정상적으로 사용할 수 있는 상태를 말합니다.


RC 릴리즈는 제품을 출시할 수 있는 정도로 사소한 버그가 몇개만 포함된 버전을 말합니다.


이렇게 릴리즈를 나누는 이유는 각 릴리즈에 따라서 들어가는 비용과 개발 프로세스가 다르고, 리스크가 다르기 때문입니다. 이러한 구분이 없이 그냥 개발자가 소프트웨어를 수정하는 대로 릴리즈를 하고 있다면, 테스트 등 릴리즈에 들어가는 비용을 들이지 않는 주먹구구식 개발일 가능성이 높습니다. 하지만 이러한 마구잡이식 릴리즈가 결국 더 많인 비용을 이미 지불하고 있다는 것을 알아야 합니다.