2010년 12월 14일 화요일

해외에 소프트웨어를 팔려면 이것이 꼭 필요하다.

연초에 소프트웨어의 국제화와 지역화를 언급하면서 조만간 이에 대한 글을 올리겠다고 했는데, 벌써 10개월이 지났네요. 
2010/02/11 - [소프트웨어이야기] - 애플은 한국어와 한글을 구분하지 못한다?

그래서 간단하게 정리를 해보려고 합니다.

일단 다음의 기본 용어는 알아두는 것이 좋습니다.

 i18n(internationalization) - 국제화를 말하며 i와 n사이에 18개의 알파벳이 있어서 i18n으로 줄여말합니다. 소프트웨어가 여러 언어(locale)를 지원하기 용이한 형태로 만드는 것을 말합니다. i가 소문자인 이유는 알파벳엘(l) 또는 숫자일(1)과 혼동되기 때문입니다. 

 L10n(localization) - 지역화를 말하며 l과 n사이에 10개의 알파벳이 있어서 L10n으로 줄여말합니다. 소프트웨어를 해당 지역에서 사용할 수 있도록 메시지나 기능을 해당지역에 맞춰주는 것을 말합니다.

Locale - 지역화의 단위입니다. 한국어를 공식적으로 쓰는 나라는 우리나라밖에 없어서 (북한예외) Locale과 나라를 동일시하기도 하는데 영어만 아더라도 여러나라에서 쓰고 캐나다에서는 영어와 프랑스어를 모두 쓰게 됩니다. 따라서 Locale에는 언어 정보와 지역정보가 같이 포함되어 있습니다. 제 글에서는 국가와 혼영해서 사용했으니 알아서 이해하세요.

최근의 소프트웨어들을 보면 국경은 의미가 없어진지 오래입니다. 특히 스마트폰이 폭발적으로 보급되면서 개발자들과 세계 각국의 사용자들은 더욱 가까워졌습니다.

그래서 지역화된 소프트웨어가 더욱 절실해졌습니다. 그런데 우리나라 상황을 보면 아직도 많은 소프트웨어들이 국제화와 지역화에 관심을 기울이지 않고 있습니다. 그러다보니 국내에서 성공한 제품들을 들고 해외에 진출을 하다가 국제화와 지역화의 어려움에 막혀서 좌절하곤 합니다.

 국제화, 지역화 방법은 표준을 따라야 합니다.

국제화와 지역화에대한 소프트웨어 개발의 표준(De facto)이 정립된지는 매우 오래되었지만, 국내에서는 별로 관심을 받지 못하는 것이 사실입니다. 그렇게 어렵지 않은 기술임에도 관심들이 별로 없고 관심이 있다고 하더라도 흩어져 있는 정보를 모두 모아서 하나의 그림으로 보기 어려운 상황입니다. 어렵지는 않다고 했지만 매우 복잡하기 때문에 처음에 이해하기란 쉽지 않습니다.

대부분의 소프트웨어 회사들은 국제화와 지역화 과정에서 표준적인 방법을 따르지 않고 스스로 연구한 방법을 사용하다가 큰 낭패를 보게 됩니다. 왜냐하면 국제화와 지역화에 대한 방대한 지식을 소수의 개발자가 연구해서 체계화 하기란 불가능합니다. 전세계 수백명의 개발자들이 십수년간 모여서 완성한 것을 우습게 보면 안됩니다.

그래서 스스로의 방법은 대부분 실패하게 됩니다. 

 초기부터 국제화와 지역화를 고려해야 합니다.

소프트웨어 개발 초기부터 국제화와 지역화를 신경쓰지 않다가 제품을 다 완성한 후에 나중에 반영을 하게 되면 또 엄청난 비용이 들고 그 방법이 잘못되었다면 비용을 많이 들이고도 또 실패합니다.

소프트웨어가 다른 언어를 지원해야 할 가능성이 단 1%라도 있다면 저는 국제화와 지역화를 적용하여 소프트웨어를 개발합니다. 초기부터 적용하는 것은 비용이 추가로 거의 들지 않기 때문입니다.

 소프트웨어는 하나로 만들어야 합니다.

여러개로 지역화된 소프트웨어 별로 Master가 별도로 존재한다면 이를 관리하는데 또 엄청난 비용을 지불해야 합니다. 표준적인 방법들은 대부분은 하나의 소프트웨어에서 여러개의 언어(locale)을 지원할 수 있도록 미리 준비되어 있습니다.

Locale별로 여러벌의 소프트웨어가 존재한다면 이를 관리하는 비용은 기하급수로 증가하여 혼돈의 상태를 경험하게 됩니다. 이 과정에서 수많은 오류가 발생하고 해외 진출 실패의 주요 원인이 되곤 합니다.

 메시지 번역이 지역화의 전부가 아닙니다.

흔히들 우리나라에서 성공한 제품을 가지고 해외에 진출한다고 영어버전을 만들고 일본어, 중국어 버전을 만들곤 합니다. 이때 그냥 메시지만 번역을 해서 지역화된 제품이라고 생각하곤 합니다. 하지만 이런 제품을 해외에 가지고 나갔다가는 낭패를 보기 일쑤입니다. 외국과 우리나라가 그렇게 비슷하다고 생각하면 착각입니다.

숫자만하더라도 우리나라에서는 1,234.56이라고 쓰는 것을 독일에서는 1.234,56이라고 씁니다. 즉 콤마와 소숫점을 반대로 사용합니다. 

이런식으로 언어(locale)이 고려해야 할 것은 메시지외에도 Collate, Ctype, Monetary, Numeric, Time이 있습니다. 이것들은 표준적으로 정해 놓은 것이고 비표준적인 요소는 이보다 훨씬 많습니다. 비표준적인 요소들은 제품마다 별도로 분석해야 합니다.
 메시지도 단순히 번역하는 것이 다가 아닙니다.

간단한 예로 나라마다 어순이 다르고 단수, 복수의 표현이 다릅니다.

우리나라에는 단수, 복수에 따른 차이가 거의 없지만, 영어에는 복수가 있지요. 하지만 폴란드어는 1개일때 2~4개일때, 5개 이상일 때 서로 표현이 다릅니다. 게다가 12~14개로 넘어가면 또 반복이 됩니다.

이렇듯 거의 모든 요소에서 다른 나라에서는 과연 이대로 쓰는지 의심을 해봐야 합니다. 경험도 많이 필요합니다. 그러면서 자연스럽게 문장의 표현 방법도 글로벌하게 문제가 없는 방법을 사용하게 됩니다.

또한, 번역을 했을 때 문장의 길이가 천차만별이기 때문에 UI 디자인시 문장의 길이를 충분히 길다고 생각하고 디자인을 해야 합니다.

이러한 모든 것이 습관이 되어 있다면 간단한 일이지만 초기에는 매우 귀찮은 일이 됩니다.
 유니코드는 기본입니다.

지역화된 소프트웨어를 개발하다보면 항상 부딪히는 것이 문자코드의 충돌입니다.
유니코드를 사용하지 않아도 지역화된 소프트웨어를 개발할 수 없는 것은 아니지만, 여러 군데에서 매우 귀찮은 일이 발생하게 됩니다.
따라서 유니코드를 기본으로 생각하면 복잡한 문제들이 대부분 해소가 됩니다.
기존에 ANSI 프로그램만 작성을 하다가 유니코드 프로그램을 작성하는 것이 낯설고 어려울 수 있지만 이 또한 적응이 되고 나면 그렇게 어려운 일도 아닙니다.

단, 유니코드 및 문자셋, 코드셋, 인코딩 등 복잡한 컨셉을 모두 제대로 이해하는 것은 보통 어려운 일이 아닙니다. 그렇지 않다면 개발을 하다가도 "어찌어찌 하니 우연히 되더라"하는 식의 개발이 되기도 합니다.

유니코드가 적용된 지역화된 소프트웨어를 개발하려면 갖춰야할 기본 지식이 매우 많습니다.

 꾸준히 유지보수 할 수 있는 프로세스를 만들어야 합니다.

지역화된 소프트웨어를 만들때 흔히 발생하는 문제점이 처음에 한번 개발은 어떻게든 해 냈는데, 유지보수 단계에서 상당히 곤란한 상황에 처한다는 겁니다. 한국어를 포함해서 영어, 중국어, 일본어 그러고 여러 언어를 지원하다보면 패치를 만들어가 업그레이드를 할 때 매번 새로 추가된 메시지와 삭제, 변경된 메시지를 추려서 각각의 언어로 번역을 하고 제품에 반영해서 또 테스트를 해야 하는데 그게 잘 안되고 뒤죽박죽되기 일쑤입니다. 툭하면 어떤 언어에서는 메시지가 제대로 안나오곤 합니다.
지역화 프로세스는 번역과정을 빼고는 모두 자동화를 해서 추가로 비용이 들지 않아야 합니다.

각 개발자나 회사에서 스스로 만든 지역화 방법을 사용하면 좋지 않은 결정적인 이유가 유지보수 입니다. 대부분의 개인들이 만든 지역화 방법은 유지보수까지 완벽하게 반영하지 못한 것이 대부분이기 때문입니다.
 결론

필자는 무슨 소프트웨어를 만들지간에 국제화는 무조건 생각합니다. 이미 알고 있는 마당에서 비용이 추가로 들것도 별로 없습니다.
하지만, 초기에 국제화를 생각하지 않고 나중에 영업이 잘되서 해외 진출을 한번 해보려고 하면 국제화와 지역화는 큰 걸림돌이 될 겁니다. 
이 또한 알면 무지 쉬운데 모르면 한없이 어려운 분야 중 하나입니다.
"유비무환". 미리미리 준비해서 언제든지 글로벌 소프트웨어 회사들과 경쟁할 준비를 해놓읍시다.

이번 글에는 소프트에어의 국제화와 지역화의 필요성과 개념만 정리를 했는데, 그 구체적인 방법은 너무 광범위 해서 블로그 글로 모두 적기는 어려울 것 같습니다. 하지만 기회가 되면 한가지씩 올려 볼 수는 있을 것 같습니다.

혹시 소프트웨어의 국제화와 지역화가 필요하기는 한데 어려움을 겪고 있거나 이미 스스로 방법을 만들어서 쓴맛을 본 분들이 있으면 연락해주세요. 도움이 되어 드리면 좋겠습니다. :)

2010년 12월 3일 금요일

소스코드관리시스템 사용도 2차 조사 결과

2009년 2월에 이와 동일한 조사를 한 적이 있었습니다.
2009/02/22 - [기반시스템/소스코드관리] - 소스코드 관리 방법 조사 결과
그때도 약 20일간 조사를 했었고, 이번에도 마찬가지로 20일간 조사를 했습니다. 
2009년에는 109명이 참여를 했는데 이번에는 370명이 넘는 인원이 참여를 해서 더 정확한 결과가 나왔을 것으로 기대합니다.


이번 설문의 핵심은 소스코드관리시스템을 사용하는지? 사용하지 않는지? 또, 사용한다면 어떤 시스템을 사용하고 있는지를 알아내는 것이었습니다.

2009년초와 비교를 해보면 꽤 많은 변화가 있었음을 알 수 있습니다.
가장 큰 변화를 요약하면 다음과 같습니다.
  • 소스코드관리시스템 사용률의 향상
  • CVS, VSS의 몰락
  • Git의 약진
  • Subversion(SVN)의 꾸준한 증가
그럼 조사 결과를 살펴 보도록 하겠습니다.

소스코드관리시스템을 사용하고 있는 그룹에서만 통계를 내보면 여전히 Subversion이 압도적인 1위를 차지하고 있고, CVS와 VSS의 사용률이 많이 떨어지면서 Git가 크게 치고 나온 것을 알 수 있습니다. Mercurial의 가세까지 보면 분산소스코드관리시스템에 대한 관심이 많이 높아졌음을 알 수 있습니다.
또한 더 다양한 소스코드관리시스템의 사용을 시도해보고 있는 것이 눈에 띕니다.



소스코드관리시스템을 사용하는 비율도 많이 높아졌습니다. 그동안 책이나 블로그를 통해서 소스코드관리시스템을 사용하지 않고 소프트웨어를 개발하는 것은 기적에 가깝다고 하였는데, 이는 긍정적인 신호로 생각됩니다.
물론 소스코드관리시스템을 사용하고 있는 83%에서도 제대로 사용하고 있는 비율은 극히 낮습니다. 그래도 사용하기 시작한 것만 해도 큰 의미라고 생각됩니다.



많은 발전이 있었음에도 여전히 소스코드관리시스템을 사용하지 않는 개발자나 회사가 많이 있고 그 속에서의 비율은 큰 차이가 없어 보입니다.
소스코드관리시스템을 100%의 개발자들이 사용하고, 또한 제대로 사용할 수 있는 날까지 계속 노력을 합시다. 



저는 수많은 회사에서 소프트웨어 공학/경영 컨설팅을 진행하면서 소스코드관리시스템이 개발 문화를 긍정적으로 상당히 많이 바꾸는 것을 보아 왔습니다. 소스코드관리시스템 없이 소프트웨어를 개발한다는 것은 남들은 총들고 전쟁할 때 돌멩이 들고 싸우겠다는 것과 같습니다. 일단 무기가 있어야 싸움을 시작할 수 있을 것 아닙니까?
그리고 나서야 기술이나 전략이 의미가 있어집니다. 돌멩이 들고 싸우면서 전략을 논할 수는 없습니다.
물론 이와 같이 꼭 필요한 무기들은 몇가지 있습니다. 이런한 것들이 기본은 되어야 글로벌 소프트웨어 회사들과 경쟁이란 것을 생각해 볼 수 있습니다. 그렇다고 물론 경쟁이 된다는 것이 아닙니다. 이제 시작할 수 있다는 것 뿐입니다. 

그리고 나면 진짜 개발 실력, 전략, 마케팅이 필요한 때입니다. 하지만 국내 대부분의 소프트웨어 회사들은 아직 글로벌 경쟁은 생각하지도 못할 수준인데 단순히 요소기술만 가지고 경쟁을 할 수 있다고 착각하는 경우가 많습니다.

이번 조사 결과를 보면서 점점 긍정적인 신호들을 느낍니다. 앞으로 좀 더 깊은 내용들도 풀어 나가도 될 것 같습니다.

조사에 협조해주신 모든 분들께 감사드립니다.

2010년 11월 14일 일요일

2차 소스코드관리시스템 사용도 조사 Poll

약 2년전쯤 제 블로그에서 어떤 소스코드관리시스템을 사용하고 있는지 조사를 한 적이 있습니다. 

시간도 꽤 흘러서 그동안 어떤한 변화가 있었는지 알고 싶어집니다. 특히 그동안 소스코드관리시스템을 사용하는 비율이 어느정도 높아졌는지가 가장 궁금하더군요. 또한 최근에 분산소스코드관리시스템에 대한 관심의 증가가 실제로 사용도에 영향을 주는지도 궁금합니다.

설문은 간단하게 사용하시는 소스코드관리시스템을 체크하면 됩니다. 만약에 보기에 없다면 Other 항목에 직접 적어 넣으시면 됩니다.

많은 참여 부탁합니다.

소스코드는 어디에 보관하세요? (최신 소스코드의 기준이 되는 저장 장소를 선택해주세요. 다중 선택 가능)
 

2010년 11월 11일 목요일

문서화 딜레마

우리나라 소프트웨어 회사 중에서 문서를 제대로 작성하고 있는 곳을 찾기란 그리 쉬운 일이 아닙니다.

제대로 작성한다는 의미는 꼭 필요한 만큼 적절히 효과적으로 작성하는 것입니다.

대부분의 소프트웨어 회사는 변변한 문서 하나 없이 개발을 하고 있고 반대로 소수의 회사는 불필요한 문서를 잔뜩 만들어서 오히려 효율성을 떨어뜨리고 있습니다.

물론 제대로 하고 있는 회사도 있지만 그 수는 극히 적습니다.

대부분의 여러분들도 겪은 현상이거나 앞으로 겪을 것입니다. 변변한 문서하나 제대로 만들지 않고 소프트웨어를 개발하고 있는 회사는 구멍가게 이상의 규모로 성장하기 어렵습니다. 회사의 규모가 커지면서 문서가 부족하면 커뮤니케이션 비용이 기하급수로 증가하기 시작합니다. 회사가 작았을 때 숨어있던 문제들이 마구 터져 나오기 시작합니다.

이미 문제가 되기 시작한 이후에 문서를 만들어보자는 결심을 하기도 합니다. 하지만 이미 제품을 다 개발한 이후에 유지보수하는 제품의 문서를 제대로 만드는 것은 거의 불가능합니다.

문서의 주목적은 소프트웨어를 제대로 개발하기 위한 것이지 유지보수를 위한 것이 아닙니다. 유지보수 단계에서 문서를 만들면 문서에 많은 내용이 빠지게 되고 의욕도 떨어지게 됩니다.

하지만 문제는 또 다른 곳에 있습니다. 그동안 제대로 문서를 만들지 않고 개발을 해온 개발자들이 문서를 만들자고 결심만 했다고 해서 문서를 작성하는 실력이 갑자기 생기지는 않습니다.

즉, 문서를 만드는 실력이 부족하다는 겁니다.

본인들은 문서를 잘 작성할 줄 아는데 바빠서 만들지 못한다고 합니다. 그래서 시간만 있다면 문서를 언제든지 만들 수 있다고 합니다. 이렇게 말하는 것자체가 문서를 제대로 만들어 본적도 없고 문서를 만들지도 모른다는 반증입니다. 왜냐하면 바쁠 수록 문서를 적절히 잘 만들어야 프로젝트 시간이 단축되기 때문입니다.

그러다보니 제대로 된 문서도 없이 유지보수가 뒤죽박죽이 되어서 항상 고참 개발자들이 유지보수에 매달려야 해서 계속 바쁘게 되고 그러다보니 문서를 제대로 만드는 실력을 향상할 기회는 또 없게 됩니다. 새로운 프로젝트를 시작해도 또 과거의 방식으로 문서도 제대로 없이 개발을 하게 됩니다.

개발자들이 코딩을 잘하는 이유는 수년에 결쳐서 코딩을 계속 해 왔기 때문입니다. 철저히 훈련이 잘 되어 있습니다. 다들 실력차이는 나지만 코딩을 못하는 개발자는 개발자도 아니죠. 

그렇듯 문서도 계속 작성을 해봐야 잘하게 됩니다. 처음부터 기가막히게 멋진 문서를 만들 필요는 없습니다. 항상 기록을 남기는 습관을 들이는 것도 문서를 잘 작성하는 실력을 키우는데 좋은 도움이 됩니다.

물론 프로젝트에서 필요한 문서는 단순히 글을 잘 작성한다고 되는 것도 아닙니다. 하지만 글을 쓰는 습관이 출발점입니다.  그리고 프로젝트에서 필요한 문서는 원래 선배들이 제대로 작성을 해 왔다면 문서를 리뷰할 때 참석해서 문서 작성 방법을 배울 수 있습니다. 하지만 안타깝게도 선배에서 문서 작성법을 배울 수 있는 회사는 우리나라에 그렇게 많지 않습니다. 대부분은 스스로 해 나가야 합니다. 이에 관련된 책들의 도움을 받는 것도 방법 중 하나 입니다.

명심할 것은 욕심을 부리지 않는 것입니다. 너무 많은 내용을 완벽하게 적으려고 하면 오히려 금방 질려서 포기하게 됩니다. 또한 바쁘니까 나중에 몰아서 만든다는 생각도 버려야 합니다. 문서는 지금 이순간이 아니면 만들 수 없습니다.  지금 필요한 만큼만 적당히 적게 만들어야 합니다.

2010년 11월 2일 화요일

내가 지금 하고 있는 일의 가격

개발자 여러분... 
아침에 출근하셔서 여러분들이 하루종일 일하는 업무의 가격을 생각해보신 적이 있으신가요?
이것을 여러분의 "하루의 부가가치"로 생각을 하죠. 

여러분의 연봉은 "하루의 부가가치" x "일년동안 일한 날"에서 회사에서 여러분에게 사용한 비용을 제하면 됩니다.
대기업은 보통 60~70%를 비용으로 제하면 되고, 중소기업들은 30~50%정도의 비용이 듭니다.

여러분은 자신이 만들어 내는 부가가치에 비해서 높은 연봉을 받고 있나요? 낮은 연봉을 받고 있나요?
회사입장에서는 연봉보다 높은 부가가치가 있는 개발자를 더 많이 보유하기를 원하고 있습니다.

물론 이보다 좀더 복잡하기는 합니다만 일단 간단히 생각해보죠.

여기서 문제는 "하루의 부가가치"가 얼마나 되는지 측정하기 어렵다는 겁니다. 특히 여러분 스스로는 자신이 매우 가치있는 일을 하고 있다고 생각하지만, 다른 사람들의 시각으로는 그렇지 않을 수 있습니다.

모두들 알고 계시듯이 모든 재화의 가격은 시장의 원리에 의해서 결정됩니다.
수요가 많고 공급이 적으면 가격이 올라가고, 공급이 넘치면 가격은 떨어지게 됩니다.

여기에 개발자들이 높은 연봉을 받는 두가지 방법이 있습니다.

 첫째, 부가가치를 높여서 높은 연봉을 받는 개발자

즉, 회사에 돈을 많이 벌어다 주고 미래에도 더 많은 돈을 벌어다 줄 개발자입니다.
이런 개발자들의 특징은 다음과 같습니다.
  • 자신의 경력에 알맞는 일을 수행한다. 즉, 고참이 되어서도 맨날 코딩에만 매달리는 것이 아니고 설계, 요구사항 분석에 집중하며 프로젝트를 이끈다.
  • 문서화와 리뷰를 잘하여 지식의 공유를 원활하게 하여 모든 개발자들이 서로 향상되는데 기여한다.
  • 커뮤니케이션이 능통하여 복잡한 이슈들을 잘 해결한다.
  • 회사의 중요한 기술적인 의사결정에 중요한 역할을 하여 회사의 기술 방향을 결정하여 회사가 기술적으로 올바른 길을 가도록 기여한다.
 둘째, 자신이 없으면 회사에 손해를 끼치게 해서 높은 연봉을 받는 개발자

현재는 돈을 많이 벌어다 주는 개발자들이라도 곧 손해를 끼치게 하는 개발자들이 수두룩합니다. 
이런 개발자들의 특징은 다음과 같습니다.
  • 항상 바쁘다는 핑계로 문서도 만들지 않고 프로세스를 지키지 않으며 자신만 알 수 있는 코드를 마구 쏟아 낸다.
  • 후배들을 적극적으로 양성하기 않고 여전히 본인이 가장 많은 코딩을 한다. 막상 후배들을 시킬려고 해도 가르키기가 어렵고 본인이 제일 바쁘다.
  • 회사의 개혁 시도를 방해하고 항상 본인은 열외라고 생각한다.
 결론은 자신의 연봉에 걸맞는 부가가치가 높은 일을 해야 합니다.

소프트웨어 프로젝트에서 어려운 업무일수록 비싼 일입니다. 물론 모든 업무는 가치가 있고 꼭 해야 하는 일입니다. 하지만 이제 대학을 갓 졸업한 신입사원도 할 수 있는 일을 연봉을 3~4배나 많이 받는 개발자가 하고 있다면 연봉이 아까울 것입니다. 물론 그러한 일도 신입사원보다 2~3배 잘하기는 할 겁니다. 하지만 프로젝트에는 신입사원은 절대로 할 수 없는 어려운 일이 수두룩 합니다.

개발자들이 하는 업무를 크게 나누어서 간단히 비교를 하면 다음과 같습니다.

Coding < Low level design < High level design < Spec

코딩에서 있어서는 신입사원보다 크게 잘할 것도 없지만, 설계나 스펙은 수십배, 수백배 잘할 수 있는 분야입니다. 코딩도 그렇다고 생각하는 사람들은 코딩에 설계와 스펙을 짬뽕해서 생각하고 있는 것일 가능성이 매우 높습니다.

이외에 개발자는 잘하기 어려운 전문적이거나 매우 귀찮은 일을 개발자가 하는 경우도 있습니다. 

QA(Test), Project Management, B/R 등이 여기에 포함됩니다.

자신이 첫번째 개발자에 해당하는지 두번째 개발자에 해당하는지 잘 생각해봅시다.

두번째 개발자들이 주도하는 회사의 미래는 뻔합니다. 언제 망하는지는 시간 문제일 뿐입니다. 이런 회사들은 보통 한번의 성장을 이룬 다음에 첫번째 또는 두번째 변곡점에서 보통 망하게 됩니다. 즉, 회사가 성장하는 것이 망해하고 있는 것과 거의 같은 의미입니다. 이런 경우 성장하지 않거나 느리게 성장하는 것이 차라리 오래 살아 남는 길입니다.

주변에서 크게 성장한 다음에 망해간 수많은 소프트웨어 회사들을 생각해보세요. 이러한 특징들이 고스란히 드러납니다. 눈에 띄지 않게 조용히 망한 회사들은 셀 수 없을 만큰 수두룩합니다.

첫번째 개발자가 될지 두번째 개발자가 될지는 여러분의 선택입니다. 주변의 환경때문에 어쩔 수 없다는 것은 핑계에 불과합니다. 방법을 몰라서 그런 것이라면 마음만 열면 많은 도움을 받을 수 있습니다.

2010년 10월 11일 월요일

QA팀은 없다고 생각하라

저는 여러 소프트웨어 회사를 접할 기회가 많기 때문에 우리나라의 소프트웨어 현실을 다양하게 보게 됩니다.

많은 회사들이 전문 QA팀없이 개발자가 테스트를 하곤합니다. 제가 접한 소프트웨어 회사들의 대략 70% 이상이 전문화된 QA가 없었습니다. 심지어는 대기업에 속한 회사들도 QA팀 없이 개발자나 팀장이 테스트를 하는 경우도 있습니다.

그 이유야 제가 이전에 여러번 언급했듯이 주먹구구식 개발이나 형식에 치우친 프로세스를 채용한 회사들은 개발자가 아니면 그 기능을 속속들이 잘 모르기 때문에 개발자나 팀장이 테스트를 할 수 밖에 없고 누가 좀 도와준다고 하더라도 Random 테스트 밖에 수행을 하지 못합니다.

이 이슈는 차치하고 소수의 QA팀을 가지고 있는 회사들에서는 QA테스트가 제대로 이루어지고 있는지 확인을 해볼 필요가 있습니다. 제 경험에 의하면 많은 회사들이 QA팀이 있다고 하더라도 QA팀을 충분히 활요하지 못하고 있었습니다. 이런 경우들이 존재합니다.

- QA팀에게 개발자의 일을 떠넘기는 경우
QA팀이 무슨일을 하는 것인지 정확하게 모르는 경우입니다.

- QA팀에게 테스트를 할 수 있는 충분한 정보를 제공하지 않는 경우
QA팀이 있다고 해도 또 주먹구구식으로 테스트를 하거나 QA팀이 제품의 기능을 알아내기 위해서 제품을 일일이 써보는 수밖에 없는 경우입니다. 수박 겉핧기씩 테스트를 할 수 밖에 없고 많은 버그는 고객들이 찾아줍니다. 

- QA팀의 테스트 결과를 비난하는 경우
QA팀의 책임이 무엇인지 모르는 경우입니다.

이 중에서 첫번째에 대해서 얘기를 해보려고 합니다. 
소프트웨어 회사들이 QA팀 없이 개발을 하다가 QA팀이 생기고 또는 테스트 전담 인원이 생기면 개발팀의 자신들이 그동안 해 왔던 테스트를 QA팀에서 대신 해줄 것으로 착각을 하곤합니다.

엄밀히 말하면 이는 잘못된 생각입니다. 대부분의 개발자들이 하는 테스트는 QA테스가 아닙니다. 개발자들이 개발과정에서 당연히 해야할 유닛테스트와 통합테스트일 뿐입니다. 

개발자들은 자신들이 하던 테스트를 도와줄 사람이 생겼다고 생각하고 대충 구현을 해서 QA팀에 넘겨버립니다. 그러면 QA팀에서는 버그투성이인 제품을 테스트하느라고 시간을 낭비하곤 합니다. 그래서 정작 제대로 된 테스트는 해보기도 어려운 경우가 허다합니다. 이런 회사들의 특징은 개발자와 QA팀이 타이트하게 붙어서 개발자가 개발을 하는대로 바로바로 테스트를 해줍니다. 혹시 이런 형태로 개발을 하고 있다면 QA팀을 전문가로 생각하지 않고 개발팀의 심부름꾼 정도로 생각하고 제대로 활용하지 못하고 있고 생각할 수 있습니다.

개발자들은 QA팀이 없다고 생각하고 완벽하다고 생각하는 코드를 작성해서 QA팀으로 넘겨야 합니다. QA팀은 이렇게 만들어진 제품을 제대로 검증할 책임이 있습니다.

먼저 QA팀의 역할이 무엇인지 정확하게 이해해야만 QA팀이 제 역할을 할 수 있습니다.

2010년 10월 4일 월요일

개발팀장과 프로젝트관리자(PM)

오랫만에 찾아뵙니다.
요즘 워낙 바쁜 날을 보내고 있다는 핑계로 블로그 포스트를 자주 못하고 있습니다. 다시 힘을 내서 시작하려고 합니다.

최근에 컨설팅에 많은 시간을 보내고 있는데, 컨설팅을 하면서 주로 겪게 되는 현실적인 얘기 위주로 적어볼까 합니다. 그 중에서 가장 흔히 보게 되는 것이 개발팀장의 애매한 포지션입니다.

당신이 개발자라면 또는 개발팀장이라면 어떠한 일을 하고 있는지 잘 살펴 보시기 바랍니다. 제가 여러 회사를 컨설팅하면서 만나본 개발팀장의 역할은 천차만별이었습니다. 

공통점은 있습니다. 개발자로서 오랫동안 일을 하다가 개발팀장이 되었다는 것입니다. 
하지만 현재 하고 있는 일들은 천차 만별입니다.

어떤 개발팀장은 여전히 코딩에 90% 매진하고 있고, 어떤 사람은 프로젝트 관리만 하고, 어떤 사람은 회사 경영회의 쫒아다니면서 바쁜 나날을 보내고 있고, 어떤 사람은 코딩도 하고 관리도 하고 정신 없이 시간을 보내는 사람도 보았습니다.

개발팀장은 "개발팀"의 "장"이란 의미를 가지고 있어서 관리자로서의 역할을 요구하고 있는 듯하지만 대부분의 소프트웨어 회사에서는 가장 경험이 많고 뛰어난 개발자들이 맡고 있습니다.  

하지만 회사에서는 "장"이라는 의미에 따라서 개발자로서의 뛰어난 역할도 계속 해주기를 원하면서 관리도 하기를 원하는 경우가 많습니다. 개발팀에서 필요한 관리란 일반관리와 프로젝트관리인데, 보통 개발팀에서 일반관리는 할일이 별로 많지 않습니다. 일반관리 이슈가 매우 크다면 프로세스나 시스템을 개선해야 할 것입니다. 

따라서 이슈가 되는 것은 프로젝트 관리인데, 이것이 그렇게 만만한 일이 아닙니다. 즉, 개발팀장이 최고의 개발자로서 스펙도 잡고, 설계, 코딩도 하면서 할 수 있을 만큼 프로젝트관리가 간단하지 않습니다. 보통 어디하나 펑크가 나게 되어 있습니다. 

제 경험상 보통 프로젝트 관리에서 문제가 생기는 경우가 많습니다. 개발팀장은 개발자체는 원래 하던일이고 익숙하지만 프로젝트 관리는 경험도 적고 대부분 방법도 모르기 때문에 상식선에서 개발하느라고 바쁜 시간에 짬을 내서 하기 때문에 문제가 생기기 십상입니다.

그래서 필자는 개발팀장은 계속 최고의 개발자로서 개발 조직을 기술적으로 이끌고, 프로젝트 관리는 전문 PM(Project Manager)에게 맡기는 것을 권장합니다. 물론 개발자 출신으로 꼼꼼하고 관리를 좋아하는 사람이 PM으로 성장하는 것도 좋습니다.

개발조직이 10명 미만이고 대부분 소규모 프로젝트만을 진행한다고 하면 PM을 따로 두지 않아도 어떻게든 프로젝트가 진행이 될 수 있을 겁니다. 하지만 조직이 커지고 프로젝트가 복잡해지고 많은 프로젝트를 수행한다면 프로젝트의 성패는 요소기술에 달려 있지 않다는 것을 알게 될 것입니다. 이쯤되면 전문 PM이 없다면 가장 뛰어난 개발팀장들은 기술에 매진하지 못하고 잘하지도 못하는 프로젝트 관리에 허덕일 것입니다.

개발팀장은 쉽게 대체가 되지 않지만 PM은 외부에서 영입을 하는 것도 가능합니다. 즉 외부에서 영입한 사람이 할 수 있는 일을 회사에서 가장 바쁘고 가치 있는 일을 하는 개발팀장에게 맡기는 것은 비효율적입니다.

그렇다고 PM이 아무나 할 수 있다는 뜻은 아닙니다. 이또한 전문적인 일로서 전문가가 해야 하는 일입니다.

지금 일반관리자, 개발팀장, PM 등이 마구 섞여서 일을 하고 있다면 일단 임무를 나누어서 생각하는 습관을 들여야 할 것입니다. 그리고 현재 어느부분에서 문제가 생기고 있고 어느 역할을 보충해야 할지 계획을 세워서 조직을 튼튼하게 해야 합니다. 그렇지 않고 개발자 인원수만 늘여서는 현재의 많은 문제들이 해결되지 않습니다.

2010년 8월 3일 화요일

개발자의 파워는 어디에서 오는가?

뛰어난 개발자를 관리자로 써먹는 것 같이 개발조직에 비효율적인 일은 별로 없습니다.

하지만 현실에서는 이런 일이 흔히 벌어지고 있습니다. 실제로 저도 여러 회사에서 자주 접하고 있습니다.
여러가지 이유가 있을 수 있겠지만 주요 이유는 회사에서 개발자로서 꾸준히 성장할 수 있는 Career Path를 보장하기 않기 때문입니다.

회사에서 파워를 가지려면 팀장이 되어야 하고, 그래야 개발자들을 거느리며 힘을 행사할 수 있게 됩니다.
하지만 일단 팀장이 되고나면 개발에 전념할 시간은 점점 줄어들게 됩니다. 그렇다고 개발을 포기하고 관리만 하기에는 관리할 일의 양도 얼마 되지 않고, 파워가 줄어들게 될 까봐 걱정을 하게 됩니다.

흔히들 개발자는 행정적인 파워가 없어도 기술력에 따른 카르스마에서 파워가 생긴다고 하지만 이는 실제 현장에서는 공허한 얘기가 됩니다.

제대로 세팅된 소프트웨어 회사라면 개발팀은 관리할 것이 그렇게 많지 않습니다. 하지만 그렇지 못한 회사는 이래저래 관리할 일이 점점 늘어나게 되서 불필요하게 팀장의 관리에 많이 의존하게 됩니다.

이렇게 뛰어난 선임개발자들이 개발과 관리를 넘나드는 사이에 기술은 점점 멀어지게 되고 돌아올 수 없는 강을 건너는 경우가 예사입니다.

결국 100원짜리 개발자를 10원짜리 관리자로 만들고 맙니다.

물론 개발자 중에는 관리능력도 뛰어나서 관리자 역할을 훌륭하게 수행해 내는 사람도 있습니다. 
이 경우 개발자가 개발보다 관리에 관심이 많고 관리 능력이 더 뛰어나다면 관리자로 전환하는 것도 좋을 겁니다. 하지만 개발과 관리 둘다 능력이 좋다면 개발을 선택하는 것이 좋을 겁니다. 개발이 훨씬 부가가치가 높으며 다른 사람으로 쉽게 대체할 수가 없습니다. 둘다 훌륭하게 수행해내기를 바란다면 욕심입니다. 

뛰어난 개발자를 개발자로 있게하려면 회사에서 경력을 보장해줘야 합니다. 
개발자로 꾸준히 성장할 수 있는 Position을 만들어야 하고 연봉에서 대우을 해줘하고 관리자 이상의 파워를 가질 수 있는 제도를 마련해줘야 합니다. 그렇지 않는다면 뛰어난 개발자들이 개발과 관리사이에서 끊임없이 고민하다가 많은 개발자들이 관리자로 전환되면서 회사에 손해를 끼치게 될 겁니다.

수평적인 조직구조를 가진 외국의 회사들과 다르게 수직적인 조직구조를 가지고 있는 우리나라 회사에서 개발자에게 힘을 실어주기란 쉽지 않습니다. 그래서 제도적으로 뒷받침이 되지 않으면 어렵다는 것입니다.

현실적으로 쉽지 않은 일임을 공감합니다. 개발에 대한 전문성을 인정해주는 분위기가 같이 성장을 해야 개발자 경력 보장도 점점 이루어질 것입니다.

2010년 7월 8일 목요일

소프트웨어 개발자를 위한 소통의 장

그동안 블로그에 글을 쓰면서 여러 개발자분들의 의견을 듣는데 많은 불편함을 느껴왔습니다.
블로그의 글에 댓글을 남기면 약간 소통이 되기는 해도 주로 일방적인 전달을 벗어나지 못했습니다.
그렇게 해서는 많은 의견을 주고 받을 수도 없고, 소프트웨어를 개발하면서 생기는 수많은 문제들을 해결하는데 실질적인 도움을 주기 어려웠었습니다.

그래서, 소통을 좀더 강화하고자 allofsoftware 메일링리스트를 만들었습니다.

메일링리스트가 어떤것인지 다들 잘 알고 계시겠지만 간단히 설명하자면 allofsoftware 메일링리스트에 가입을 하시면 allofsoftware@googlegroups.com으로 보내는 모든 메일을 수신하실 수 있습니다. 거꾸로 내가allofsoftware@googlegroups.com으로 메일을 보내면 모든 가입자가 메일을 받아 봅니다.

소프트웨어 공학에 대해서 궁금한 것이나 실제로 소프트웨어를 개발하면서 닥치는 문제들을allofsoftware@googlegroups.com으로 메일을 보내면 모든 가입자들이 내용을 보고 서로 답장을 보내면서 토론을 이어갈 수 있습니다. 이를 통해서 댓글을 통해서만 간단한 질문을 할 수 있는 것을 넘어서 현실적인 문제를 많은 개발자와 즉시 의논할 수 있을 것으로 기대합니다. 저 또한 열심히 답변을 보내도록 하겠습니다.

가입방법은 블로그 오른쪽 사이드바에 아래와 같은 위젯이 있습니다. 여기에 Email주소를 입력하면 됩니다. 간단하죠?

많은 성원 부탁합니다. 

2010년 7월 7일 수요일

애플이 아이폰4에서 한글을 바꾼 이유는...

얼마전 아래와 같은 아이폰의 Localization에 대한 글을 올린적이 있습니다.

심각한 내용은 아니었고, 아이폰의 다국어 설정 화면에서 우리말을 선택하는 항목이 "한국어"라고 적혀 있어야 하는데 "한글"이라고 적인 것에 대한 포스트였습니다. 그뒤로 'Localization(L10n)과 Internationalization(i18n)에 대한 글을 한번 작성해야 지'하고 마음만 먹고 있었는데 너무 바빠서 블로그에 글 자체를 자주 못올리고 있습니다.

그런차에 아이폰을 iOS4.0으로 업그레이하니 제 블로그의 글 때문은 절대로 아니겠지만(^^), 아이폰의 다국어 설정 화면에서 "우리말"을 지칭한 항목이 "한국어"로 바뀌었더군요.


사소한 변화이기는 하지만 애플이 우리말을 조금 더 잘 이해하게 된 것 같습니다. 아니면 한국어 담당 개발자를 더 뽑았을 수도 있고요. 아무튼 좋은 변화입니다.

2010년 6월 8일 화요일

마이크로소프트, 구글의 소스코드 트리의 비밀?

오늘 출근을 해서 메일을 확인하니 독자로부터 메일이 한통 와있더군요.

책에 대한 리뷰의 글이어서 감사히 읽었습니다. 질문도 하나 있어서 답변 겸 블로그에 글을 남깁니다.

질문은 다음과 같습니다.
나는 마이크로소프트 같은 커다랗고 프로세스가 잘 정립된 회사의 형상 관리툴의 소스트리를 보고 싶다. 그들이 모듈을 어떤 식으로 분리하고 어떤 구조로 트리를 구성하는지, 중복되는 코드들을 어떤 식으로 제거하고 또 공유하는지, 체크인 되는 코드의 코멘팅은 어떤 규칙으로 하는지 등이 너무 너무 궁금하다. 1시간 만이라도 들어가서 차근차근 살펴볼 수 있다면 내 실력은 훨씬 나아질 것이다.

사실 책에서는 이러한 내용은 구체적으로 설명되어 있지는 않지만 전체 맥락을 이해하고 경험이 있다면 질문에 해당하는 내용이 책에 포함 되어 있다는 것을 알 수 있을 겁니다. 

결론부터 먼저 말씀드리자면 최종 결과물인 "소스코드 트리"만 보면 배우기 어렵다는 겁니다. 잘 작성된 SRS를 몇개 보고 SRS를 제대로 작성하는 법을 배우기 어려운 것과 비슷합니다. 따라서 소스코드 트리를 보는 것이 큰 도움이 안된다는 것을 말씀드립니다. 하나의 사례를 보는 것에 족할 겁니다. 자칫 그 방법이 가장 좋은 방법인 줄로 착각을 하게 되면 시각이 굳어져서 손해를 볼 수도 있습니다.

좀더 쉽게 설명하면 타이거우즈(요즘 조금 부진하지만)가 골프치는 모습을 보고 골프를 배우기는 어렵고, 김연아가 스케이트 타는 것을 보고 따라하기 어렵다는 겁니다. 어떻게 해서 이러한 결과물이 나오는지 그 과정과 훈련 방법을 알아야 하겠지요. 

그런 과정에 관련된 내용이 책에서 상당히 많이 언급하려고 노력했습니다.

그 과정이라는 것도 각자의 수준에 따라서 보이는 것이 다릅니다. 수준을 1~10정도로 정의할 때 수준이 '1'인 사람은 아무리 설명해도 '2'나 '3'의 내용만 이해가 가능합니다. 수준이 '5'인 사람은 '6'이나 '7'정도가 이해할 수 있습니다. 그래서 올바른 방법으로 꾸준히 차근차근 훈련(경험)을 해 나가야 성장합니다. 

그외의 끝내주는 방법은 없습니다.

위 질문의 요지를 보면 다음과 같습니다.
  1. 모듈을 어떤식으로 분리하는지?
  2. 소스트리를 어떻게 구성하는지?
  3. 중복되는 소스코드를 어떻게 제거하는지?
  4. 공통모듈은 어떻게 공유하는지?
  5. 코멘트는 어떤 규칙으로 작성하는지?
결론부터 말씀드리면 다음과 같습니다.

 구체적인 방법은 회사마다 다르지만 원리는 똑같다.

이것을 모두 이해하려면 1~10 정도의 수준에서 '7'~'8' 이상은 되어서 합니다. 그렇지 않고 아직 소스코드관리시스템의 일부기능만 간신히 쓰고 있고 SRS도 아직 제대로 작성하지 않고 있고 리뷰도 하지 않고 있다면 수천명의 개발자들이 어떻게 뒤죽박죽 되지 않고 소프트웨어를 개발할 수 있는지 이해가 가지 않을 겁니다.

그게 소프트웨어 공학입니다. 어떠한 상황에서도 가장 짧은 시간에 적은 비용으로 소프트웨어를 개발하기 위한 실전적인 방법으로 진화를 해온 것입니다.

조금더 구체적으로 들어가보도록 하겠습니다. 모든 사람들이 이해를 하고 동의할 것으로 생각하지 않습니다. 왜냐하면 각자의 경험과 수준이 있기 때문에 보이는 것이 다르기 때문입니다. 

1. 모듈은 어떤 식으로 분리를 하는지?
천차만별이지만 원리는 있습니다. 책에서도 원리에 대해서 설명하기 위해서 노력을 했습니다. 
책이 있으니 한번 더 보시면 되겠지만 한번더 설명을 하면 "컴포넌트"와 "인터페이스"를 어떻게 나누느냐가 핵심인데, 어떤 툴이나 방법을 쓰냐는 중요하지 않습니다. 생각하는 방법도 서로 다르지만 대체로 설계단계에서 개발자들끼리 서로 모여서 종이나 칠판에 "컴포넌트"와 "인터페이스"를 그려가며 가장 깨끗하게 나오는 구조를 그려갑니다. 문제가 있으면 다시 지우고 그리고를 여러번 반복합니다.
이때 SRS가 없다면 모든 기능을 다 고려할 수 없기 때문에 제대로 아키텍쳐를 작성할 수 없습니다. SRS가 그냥 있기만 한다고 되는 것도 아니고 제대로 작성이 되어야죠. 아키텍쳐에는 회사의 미래전략도 모두 포함되기 때문에 단순히 기능만 다 있다고 되는 것도 아닙니다. SRS이슈로 넘어가면 또 하루 종일 설명을 해야 합니다.
아키텍쳐에 많은 영향을 미치는 사람들은 주로 선임 개발자들이고 개발팀 규모가 엄청나게 크면 한사람이 전체 모든 컴포넌트와 인터페이스를 분리할 수 없기 때문에 수직적으로 나뉘게 됩니다. 개발자들은 서로 여러 설계 리뷰에 참석을 하게 되고 리뷰자들은 서로 중첩이 됩니다. 선임개발자들은 최상위 아키텍쳐 리뷰에 참석도 하고 자신이 맡은 컴포넌트의 아키텍쳐 회의를 주도하고 여기에는 하위 개발자들도 참석을 합니다.
아키텍쳐 리뷰도 실제로 여러번 해보지 않으면 책을 아무리 봐도 어떻게 진행하는지 알기 어렵습니다.

2. 소스트리를 어떻게 구성하는지?
이 부분이야 말로 회사마다 천차만별입니다. 회사마다 제품의 특성이 다르고 프로세스가 다르기 때문에 같을 수가 없습니다. 소스트리를 구성할 때 고려해야 할 것들은 정말로 많고, 그 회사의 경험이 많은 고참 개발자가 아니면 좋은 결정을 할 수가 없습니다. 
소스트리는 한번 제대로 구성을 해놓으면 10년이상 지속될 수 있는 것이기 때문에 상당히 신중해야 합니다.
제품의 성격, 각 제품간의 관계, 사용하는 개발언어, 공통모듈 현황, 미래의 개발계획, 빌드 프로세스, 테스트 프로세스 등이 모두 고려되어야 합니다.
일반적으로 한번에 제대로된 소스트리를 만드는 것은 거의 불가능에 가깝습니다. 대부분은 몇년 해보다가 뒤엎는 경우를 수차례 반복합니다. 
그렇다고 Google이나 Microsoft의 소스트리를 흉내낸다고 제대로 되지는 않습니다. 아마 100% 실패할 것입니다.

3. 중복되는 소스코드를 어떻게 제거하는지?
완벽한 제거란 있을 수 없습니다. 최소화 하는 것이지요. 이것을 이해하려면 SRS, Architecture Design, Peer Review를 모두 잘 이해하고 있어야 하는데 쉽지 않습니다.
우리나라와 같이 각 개발자들이 모두 슈퍼맨에 되어서 알아서 개발하는 구조에서는 해결이 불가능한 이슈입니다.
책에서도 꽤 설명을 하고 있지만 다시 설명을 해보겠습니다. Peer Review를 한다고 가정을 하고 SRS, Architecture, Source Code 모두를 Review한다고 가정을 해보죠. 일단 Review를 충분히 한다는 것이 중요합니다. 개발자들은 이미 상당히 많은 내용을 서로 공유하고 있습니다. 보통 개발하는 시간의 20%는 Review를 위해 사용한다고 합니다. 그리고 고참이 될 수록 더 많은 시간을 Review에 할애 합니다. 
대부분은 개발할 시간도 없는데 언제 Review를 할 시간이 있냐고 합니다. 또한 "SRS는 언제 쓰고 있느냐, 빨리 개발해야지"라고 주장합니다. 그러면 "SRS쓰고 Review할 시간은 없어도, 개발하고 고치고, 개발하고 또 고치고 할 시간은 있느냐?"라고 반문을 하죠.
Review를 적절하게 하는 것이 개발을 가장 빨리 하는 방법이기 때문에 소프트웨어공학에서 주장하는 것이지요.
이런 리뷰를 거친 설계과정에서 중복되는 모듈은 컴포넌트로 빠지고 코딩과정에서도 서로 중첩된 리뷰를 하기 때문에 중복된 코드가 발생할 가능성도 적어지고 있다고 하더라도 쉽게 발견되고 공통 모듈화 할 수 있습니다.

4.공통모듈은 어떻게 공유하는지?
이또한 회사마다 다릅니다. 하지만 공통모듈이 없는 회사를 본적이 있습니다. 아니 많습니다. 각 개발자들이 다 알아서 개발을 하고 있어서 어디에 중복된 모듈이 있는지 알지도 못합니다.
공통모듈은 분석, 설계 과정을 통해서 잘 분리가 되어야 하고 당연히 이를 담당한 개발자나 개발팀이 별도로 존재합니다. 공통모듈이 이를 사용하는 개발자나 개발팀에서 잘 사용할 수 있도록 적절한 프로세스를 갖추고 있어야 합니다. 공통모듈은 소스코드 수준에서 공유하는 회사도 있고, Static library 또는 Dynamic library형태로 공유하기도 합니다. 그에 따른 적절한 공통모듈 Release프로세스를 가지고 있어야 하며 절적한 스케쥴도 유지를 해야 합니다.
회사의 공통모듈은 한개가 아닙니다. 수십개, 수백개가 될 수도 있습니다.
컴포넌트간의 공통모듈이 있고, 제품간의 공통모듈이 있고, 회사 전체 공통모듈이 있을 수 있습니다. 공통모듈은 소스코드가 될 수도 있고, Text파일일 수도 있고, 이미지파일일 수도 있습니다.
이런 공톰모듈을 적절하게 잘 사용할 수 있는 소스트리 구성이 중요합니다. 따라서 최고의 고참이 아니면 소스트리 구성이 어렵습니다.

5.코멘트는 어떤 규칙으로 작성하는지?
이부분도 회사마다 다르지만 규칙은 있다는 겁니다. 
아무것도 제대로 갖춰지지 않은 회사에서 코멘트는 정말 중요합니다. 달랑 소스코드 하나 있는 것이기 때문에 코멘트가 없으면 소스코드를 파악하기 정말 어렵습니다. 특히 해당 개발자가 퇴사를 하고나면 정말로 난감합니다.
하지만 제대로 된 소프트웨어 회사에서는 모든 것이 서로 얽혀 있고 정보들이 서로 중첩되어 있어서 코멘트만이 유일한 정보는 아닙니다. 모든 소스코드의 History는 소스코드관리시스템에 등록이 되어 있어서 Blame을 해보면 누가 언제 등록을 한 소스코드이고 해당하는 Message와 관련된 Issue의 번호를 가져올 수 잇습니다. 그리고 왠만한 소스코드는 서로 중복되어서 리뷰가 되었고, 소스코드관리시스템에 누가 리뷰를 했는지 기록이 되어 있습니다. 
즉, SRS - Architecture - SCCM - Issue Track - Source Code - Brain(뇌, 리뷰) 들이 서로 관련이 있고 얽혀 있어서 코멘트에 목숨거는 상황은 아니게 됩니다.
그래도 코멘트는 작성을 하고 규칙은 각 회사마다 별도로 가지고 있어야 합니다. 
우리나라 같은 경우 영어로 작성을 해야 하는지 한글로 작성을 해야 하는지 정해야 하고, 파일주석, 함수주석, 라인 주석에 대한 규칙을 정해야 하고, 내용, 형식에 대해서도 정의를 해야 합니다.
하지만 너무 복잡한 규칙과 지키기 어려운 엄격한 규칙은 없느니만 못하기 때문에 적절히 규칙을 정해야 합니다.

 결론 
 
위의 모든 것을 한꺼번에 할 수는 없습니다. 회사의 규모에 따라서 3~5년 이상 걸릴 것들도 있습니다. 결코 계단 10개를 한걸음에 뛰어오를 수는 없습니다. 용어만 알고 있거나 한번씩 경험해 봤다고 아는 척해서도 안됩니다. 회사 전체가 같이 움직일 수 있어야 합니다. 현실은 많은 의욕이 넘치는 개발자들이 머리속의 지식과 이상은 level 10인데 실제 실력과 경험은 level 2에서 헤매고 있는 겁니다. 그래도 다른 개발자들보다 용어도 많이 알고 말싸움에서 이기고 잘 안되는 것은 다른 사람들 탓을 하곤 합니다. 이것이 제가 여러 현장에서 겪는 현실입니다.
차근 차근 노력해 가는 것이 올바른 방법이고 전문가의 도움을 통해서 제대로 된 길로 가장 빠르게 가는 것이 유일한 방법입니다.