2010년 5월 10일 월요일

위기는 내부로부터 온다.

우리나라에서 소프트웨어 회사를 운영하기에 외적인 어려움들은 이미 많은 분들이 얘기를 해주셨습니다.
  • 정권이 바뀔 때마다 급변하는 환경, 특히 대통령 따라 왔다갔다하는 여건들...
  • 대기업과 중소기업간의 공정하지 못한 거래
  • 대형 SI업체들의 횡포
  • 공공기간을 포함한 고객들의 무리한 요구 및 낮은 가격
이런 것들은 천천히 얘기를 하고 오늘은 소프트웨어 내부적인 문제로 인해서 발생하는 위기에 대해서 얘기를 해보고자 합니다. 지금 소프트웨어 회사를 다니시는 많은 분들은 회사에서 항상 "위기다"라고 하는 말들을 들을 겁니다. 하지만 그 대부분의 원인을 "외부"에서 찾고 있는 경우가 많습니다. 물론 외부 환경도 기업을 잘 운영하는데 매우 중요하지만, 대부분 내부 원인은 간과하기 쉽습니다. 또한 말뿐인 위기가 아닌 진짜 회사가 어려워졌을 때 문제의 원인을 외부로 돌리는 경우가 많습니다.

단적인 예로 "티맥스"라는 국내 굴지의 소프트웨어 회사가 외부 요인때문에 어려워졌을까요? 나는 아니라고 봅니다. 내부 요인이 훨씬 더 컸다고 생각합니다.

우리나라 소프트웨어 회사들은 넘을 수 없는 벽이 앞에 존재하는 것처럼 보입니다. 강연이나 세미나에서 이런 문제를 얘기하면 작년만해도 "티맥스"라는 회사가 이 벽을 넘었다라고 주장하는 사람들이 있었지만, 이제는 그렇게 주장하는 사람이 없습니다. 우리가 기억하는 유명했던 수많은 소프트웨어 회사들 중에서 지금도 건전하게 꾸준히 성장하면서 글로벌 경쟁에서 뒤지지 않는 회사는 찾아보기 어렵습니다. 어떤 시기에 꼬꾸라졌거나 근근히 버티고 있거나 썩 나쁘지는 않지만 비전은 별로 없거나 합니다.

나는 이런 대한민국 소프트웨어 회사들이 맞닥드리는 "넘을 수 없는 벽"의 원인을 주로 소프트웨어 회사 내부에서 찾습니다. 소프트웨어 회사들이 주로 겪는 문제는 회사 조직이 커지면서 발생합니다. 조직이 커지면 이런 문제들이 발생합니다.
  • 새로 채용한 개발자들에게 지식과 경험의 전달이 안됩니다.
  • 개발자 인원은 많이 늘었는데, 생산성은 점점 떨어지고 야근만 늘어 납니다.
  • 프로젝트 규모는 점점 커지는데 관리가 안됩니다.
  • 국내에서는 꽤 경쟁력이 있는 소프트웨어였는데, 해외에서는 맥을 못춥니다.
  • 초창기에는 좋은 아이디어들이 많았는데, 더이상 창의적인 아이디어가 나오지 않습니다. 
  • 시장은 점점 레드오션으로 바뀌어서 수익성이 악화됩니다.
  이 모든 부작용이 거의 내부에서부터 나옵니다. 애초에 구멍가게 밖에 할 수없는 회사가 대부분이지만, 스스로는 그러한 사실을 알지 못합니다. 

개발자들도 스스로는 뛰어난 개발자라고 생각하지만, 코딩이나 좀 할 줄 알지 진짜 개발자들이 갖춰야할 능력이 무엇인지 모르는 경우가 태반입니다. 또한 관리자나 경영자는 소프트웨어에 대한 이해가 부족하여 마구 만들어서 많이 팔면 되는 것으로 착각을 합니다.

이러한 상황에서 우리나라에서 글로벌 경쟁력을 갖춘 소프트웨어 회사가 나오는 것은 거의 불가능합니다. 

하지만, 조금만 생각을 바꾸면 그리 어려운 일은 아닙니다. 소프트웨어 회사들이 조금씩만 바뀌고 좋은 저변이 확대가 되면 그중에서 분명히 성공하는 회사가 나올 겁니다.

소프트웨어를 잘 이해하고 있는 경영자가 점점 많아지고, 아무리 작은 회사라도 소프트웨어를 개발하는데 꼭 필요한 프로세스, 시스템, 문화등을 적절히 도입하고 이러한 환경에서 성장한 개발자들이 서로 혼합되면서 전체 소프트웨어 산업을 끌어올릴 수 있을 것으로 생각합니다.

그 첫걸음이 경영자와 개발자들의 소프트웨어 공학에 대한 이해입니다. 소프트웨어가 왜 그냥 마구 개발하면 안되는지, 어떻게 해야 적은 비용으로 짧은 시간에 품질 좋은 소프트웨어를 만드는지 이해를 하는 것이 시작입니다. 모든 경영자와 개발자가 이런 것에 관심을 가져줄 것으로 생각하지는 않습니다. 단지 그 비율이 조금씩 증가하기를 기대합니다.

2010년 5월 4일 화요일

Hotfix에서의 소스코드관리

아래 글에 차우차우님께서 Hotfix에 대한 질문을 해 오셔서 Hotfix에 대해서 좀더 자세히 설명하고자 합니다.

좋은글 잘 봤습니다. Hotfix가 많아질때의 대쳐방법이 궁금한데요 각 fix마다 해당하는 문제에 대한 fix만 만들면 될지 아니면 나중에 있는 Hotfix에 이전에 나온 hotfix를 모두 포함시켜야할지 판단하기가 어려울때가 있습니다. 그리고 각 Hotfix를 만들때도 버전관리시스템에 Hotfix에 대한 태깅을 해야하는지도 궁금합니다.







우선 Hotfix의 정의부터 알아봅시다. 회사마다 용어는 조금씩 다르게 쓰고 있으니 절대적인 정의는 아닙니다.

Hotfix란 "미리 계획되지 않은 긴급한 패치"를 말합니다.
계획된 일정이라는 것이 1년전부터 계획된 것인지 1주일된 계획인지는 회사마다 상황마다 다르고 Hotfix의 긴급도도 10분안에 해결을 해야 하는지 1주일 안에 해결해야 하는지 또 다릅니다. 하지만 이렇게 계획되지 않았지만 긴급하게 수정을 해야 하는 것을 hotfix라고 합니다.

일반적으로 Crash, Block, Security 이슈등으로 긴급하게 Hotfix를 내보냅니다.
Crash란 프로세스가 멈추거나 Database를 망가뜨려 시스템에 더이상 동작되지 않거나 데이터가 파손되는 상태를 말합니다.
Block은 설치가 안되거나 로그인이 안되는 등의 장애로 아무런 일도 못하는 상황을 말합니다. 
Security이슈는 보안에 문제가 생겨서 외부의 침입이 발생하고 있거나 위험한 상황을 말합니다.

여기서 Hotfix의 긴급성에 대해서 얘기를 하는 이유는 수많은 회사들이 긴급하지도 않은 버그(이슈, 기능)을 해결하고 Hotfix 형태로 릴리즈하는 것이 관행화되어 있기 때문입니다. 즉, Patch 일정을 계획하여 진행하지고 않고 그날 그날 개발자가 버그 수정해서 빌드한 후 그냥 고객에게 전달하거나 업데이트 서버에 올리는 것이지요.

그럼 Hotfix와 정식 패치의 차이점은 무엇인지 알아보죠.

 Hotfix 정식 Patch
계획되지 않은 긴급한 패치
보통 충분히 테스트 되지 않고 릴리즈
또다른 문제를 일으킬 가능성이 매우 높음
다른 개발일정에 영향을 줌
고객은 수정된 버전을 바로 받아볼 수 있음
미리 계획됨
계획된 테스트를 수행하고 릴리즈
일상적인 수준의 리스크를 가지고 있음
계획된 일정대로 개발이 가능
고객은 개발사의 일정을 기다려야 함

즉 Hotfix 상황이 아닌데 Hotfix처럼 릴리즈를 하는 것은 정식 Patch의 장점은 모두 버리고 단점만 취하게 되는 겁니다. 유일한 장점은 고객이 개발사에 오전에 전화를 하면 오후에 새로운 버전을 보내준다는 것인데, 이것이 고객에게 장점일지는 생각해 봐야 합니다.

매일 정식 Patch를 내거나 하루에 몇차례 정식패치를 내는 회사도 있습니다. 대표적인 예가 Anti-virus 회사입니다. 이렇게 매일 릴리즈를 해도 정식 계획을 가지고 테스트를 수행하면서 릴리즈를 합니다. 따라서 매일 패치를 내보낸다고 Hotfix는 아닙니다.

개발사는 소프트웨어의 릴리즈 일정을 계획하여 진행을 해야 개발 일정을 안정적으로 가져갈 수 있으며 소프트웨어의 품질 수준을 일정하게 유지할 수 있습니다. 그렇지 않고 호떡집에 불난 모양으로 문제가 생기면 언제나 Fire fighting mode로 개발자가 알아서 불끄고 배포하고 하면 일정도 계획하기 어렵고 개발자들은 항상 야근에 시달리면서도 항상 품질 리스크를 안고 있으며 툭하면 더 큰 폭탄이 터지곤 합니다.

정식 패치 일정은 회사마다 다르므로 성격에 맞게 정의를 해야 합니다. 정식 패치 일정을 계획하여 실천하는데 최대의 "적"은 영업부서입니다. 영업부서에서는 이러한 Hotfix의 위험성을 잘 모르기 때문에 고객의 요구는 바로 들어주기를 원합니다. 따라서 정식 패치 일정은 회사의 규정으로써 정의를 해 놔서 무조건 따르게 하는 것이 좋습니다.

또한, Hotfix를 결정하는 위원회를 두는 것이 좋습니다. 위원회라고 하니까 거창하지만 개발의 대표들과 영업의 대표가 참석을 하면 됩니다. 거기서 영업은 Hotfix의 필요성을 주장하고 개발은 Hotifx의 문제점을 주장합니다. 그래도 Hotfix가 무리하게 나가게 될 경우 나중에 생기는 문제점의 상당부분 영업에게 도의적인 책임이 돌아가게 됩니다. 하지만 이러한 논의도 없이 그냥 Hotifx가 나가고 문제가 생기면 항상 모든 것은 개발자들이 독박을 쓰게 되어 있습니다.

 Hotfix 소스코드관리

일단 Hotfix에 대해서 설명을 하느라고 사설이 길었습니다. 이제부터 Hotfix를 내보낼 때 소스코드 관리를 어떻게 하는 것이 좋을지 설명하도록 하겠습니다.

질문은 크게 두가지입니다.
1. 새 Hotfix에 기존 Hotfix를 포함해야 하는지?
2. Hotfix도 태깅을 해야 하는지?

정답을 먼저 말씀드리면 
1. 그때 그때 다르다.
2. Absolutely - 절대적으로

일단 2번이 답이 간단하므로 먼저 설명을 드리겠습니다. Tagging은 Baseline설정의 한 방법인데, 개발팀 바깥으로 나가는 모든 릴리즈는 Baseline이 설정되어야 합니다. 즉, 태깅이 되어야 합니다.
Baseline은 모든 변경의 기준선으로서 모든 릴리즈는 Baseline(태깅)으로 통제가 되어야 합니다.
그럼 개발팀 바깥이란 무엇일까요? 
테스트팀에게 테스트를 부탁하기 위해서 만들어 내는 빌드도 태깅을 해야 한다는 의미입니다.
이렇게 만들어진 버전은 버그 관리시스템에 등록이 되며 모든 버그, 이슈의 발생지의 이름이 되며 버그 수정의 기준이 됩니다. 

과거 CVS나 VSS등 1세대 소스코드 관리시스템은 Tagging(Label등)이 상당히 부담스러운 작업이었습니다. Tagging을 하면 소스코드를 그대로 복사를 하기 때문에 소스코드가 수백MB짜리 프로젝트를 할 때는 Tagging하는데 시간도 오래 걸렸고, 오래 쓰다보면 디스크 용량도 엄청나게 차지하곤 했습니다. 지금이야 Tera바이트 디스크를 쓰지만 과거에는 수백MB짜리 소스코드를 자주 태깅하는 것이 쉬운 일은 아니었습니다.

하지만 Subversion은 Tagging을 하는데 HDD 용량을 거의 쓰지 않습니다. 시간도 아무리 커다란 소스코드도 몇초면 끝납니다. 그래서 Tagging하는데 아무런 부담을 느낄 필요가 없습니다. 모든 정식빌드에 대해서 태그를 남길 수 있습니다. 여기서 말하는 정식 빌드란 개발자가 개발하면서 테스트를 하기 위해서 IDE(통합개발환경)에서 빌드하는 것을 제외한 공식적인 빌드를 말합니다. 엄밀히 말하면 공식빌드는 개발자의 일이 아니며 빌드팀의 업무입니다. 또한 별도의 빌드장비에서 이루어 집니다. 하지만 작은 회사라면 개발자가 겸업을 할 수는 있습니다. 그렇다고 하더라도 빌드장비는 필요합니다. 개발자 시스템은 더러운 환경(Dirty environment)이기 때문에 항상 일정한 빌드를 만들어 낼 수 있다는 보장이 없기 때문입니다. 개발자에게 이러한 일에 신경을 쓰게 하는 것보다 시스템을 하나 사주는 것이 훨씬 비용이 싸게 먹힙니다.

그럼 두번째 Hotfix간의 포함관계입니다.
Hotfix를 해야할만한 심각한 버그가 발생하면 Hotfix를 평가해야 합니다. 평가 항목은 다음과 같습니다.
  1. 상세한 버그 내용
  2. 버그에 영향을 받는 고객의 범위. 한 고객에게서만 발생한 것인지? 모든 고객에서 발생하는지?
  3. 버그로 인해서 발생하는 고객의 예상 피해
  4. 버그를 얼마나 빨리 해결해야 하는지
  5. 고객의 피해로 인해서 발생하는 회사의 비즈니스적인 손해
  6. 버그 수정에 투입해야 하는 인력 및 자원
  7. 기존 개발일정에 미치는 영향
여기서 기술적으로 가장 신속하고 심각하게 고민해야 하는 것이 빨리 버그를 분석하여 광범위한 버그인지 특정 상황에서만 발생하는 버그인지 판단을 해야 합니다. 

Hotfix라는 것은 태생적으로 또다른 문제를 발생시킬 가능성이 대단히 높기 때문에 한 사이트에서만 발생하는 버그를 고치기 위해서 모든 고객에게 Risk가 있는 Hotfix를 배포하는 것은 좋지 않습니다. Hotfix가 미치는 범위는 가능하면 좁게 가져가는 것이 좋습니다.

이렇게 되면 결론은 나왔습니다. 
Hotfix들이 모든 고객이나 특정 고객 집단에서 광범위하게 발생한 것이라면 합쳐지는 것이 좋겠습니다.
그렇지 않고 소수의 고객에게만 서로 다르게 발생하는 문제라면 별도의 Hotfix를 만들어서 각각 배포를 하는 것이 좋겠습니다. 

또한 Hotfix를 배포한 후에 정식버전에 앞서 배포한 Hotfix를 모두 포함해야 하는지도 판단해봐야 합니다. 이또한 회사마다 상황이 다르기 때문에 입니다. 따라서 Hotfix를 일으킨 버그의 성격과 제품의 상황을 보고 판단해야 합니다.

소스코드관리시스템을 제대로 쓰지 않으면 이러한 여러 Hotfix의 관리도 불가능합니다. 하지만 소스코드관리시스템을 제대로만 사용한다면 매우 쉬운 일입니다.



Hotfix를 작성할 때 Branch및 Tag를 어떻게 만드는지 간단한 예입니다. Hotfix를 만들기 전에 Hotfix용 브랜치를 만든 후에 작업 완료후 Release할 때는 꼭 Tag를 만듭니다. 그리고 Hotfix간의 Merge는 Hotfix와 Trunk간의 Merge는 3Way Merge를 이용해서 거의 자동으로 할 수가 있습니다.

여기서는 소스코드관리시스템 관점으로만 설명을 했는 위의 모든 활동들이 버그관리시스템(이슈관리시스템)과 긴밀하게 연동이 되어서 진행이 되게 됩니다.

 마무리

오늘 얘기 중에서 가장 중요한 메시지는 Hotfix는 함부로 남발하지 말자는 겁니다.
지금 모든 릴리즈를 Hotfix처럼 하고 있다면 Release 정책을 세워야 합니다. 

Hotfix남발은 비용이 더 많이 들뿐만 아니라 제품의 품질을 떨어뜨리고 개발자를 혹사하고 회사의 이미지도 깍아먹습니다. 영업이나 고객이 Hotfix에 너무 길들여져 있어서 바꾸기 어렵다면 정식 릴리즈 일정을 현재의 Hotfix일정과 비슷하게 가져가고 그 간격을 차차 정당한 수준으로 늘려가는 것이 좋습니다. 그래야 일주일에 몇번이라도 집에가서 식구들과 식사를 할 수 있지 않겠습니까?

2010년 5월 3일 월요일

혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까?

소스코드관리에 대해서 얘기를 하다보면 혼자서 개발을 하기 때문에 별 고민 없이 대충 소스코드를 관리하는 경우를 많이 봤습니다.

Subversion 등의 소스코드관리시스템을 쓰더라도 그냥 소스코드를 백업 받는 수준으로 사용하고 많이 사용하면 Baseline설정(Tagging)정도 하곤하더군요. 그러면서 혼자서 개발을 하기 때문에 소스코드의 브랜치/머지가 필요 없다고 생각합니다. 하지만 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황은 꼭 발생하기 마련입니다. 만약에 이러한 상황에서 브랜치/머지를 능수능란하게 하지 못하면 기존의 수작업에 의존하는 방식으로 처리를 하면서 소스코드관리시스템이 주는 큰 혜택을 누리지 못하게 됩니다.

또, 개발자는 한명이 아니더라도 마치 혼자서 개발을 하는 것처럼 개발자들끼리 담당 소스코드를 철저히 나눠서 서로 충돌이 나는 일이 없도록 개발을 하는 경우가 허다합니다. 이런 것을 Component Owner라고 하고 이런 체제에서는 개발자들 간의 기술의 공유가 어려워지고 회사의 규모가 커질수록 개발 효율성은 점점 떨어지게 됩니다.

그럼, 어떤 상황에서 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황이 발생하는지 알아보도록 하겠습니다.

첫째, Hotfix인 경우입니다.
소프트웨어의 종류는 워낙 다양하기 때문에 획일적으로 말할 수 없습니다. 그래서 간단한 예를 하나 들어보죠. 매일 한번씩 패치를 만들어서 정해진 시간에 인터넷으로 업데이트를 하는 소프트웨어를 개발하고 있다고 칩십니다. 오늘 오후 5시에 내보낼 패치에 들어갈 Bug fix와 Feature를 열심히 넣고 있는데 긴급 Hotfix 상황이 발생한 겁니다. 따라서 정식 패치때까지 기다릴 수는 없고 일단 시급한 버그 하나만 고쳐서 서둘러서 업데이트를 해줘야 합니다. 이러한 상황에서 소스코드관리시스템을 사용하는 능숙도에 따라서 대처하는 방법들이 매우 다릅니다.

 하수

소스코드관리시스템을 거의 제대로 쓰지 못하는 경우, 오늘 고치고 있는 소스코드를 수동으로 하나씩 지워서 원래 버전을 만들어냅니다. 이러한 경우는 믿기 힘들겠지만 제가 컨설팅을 하면서 많은 회사들이 이렇게 하고 있다는 것을 접했습니다. 이렇게 원래 버전을 만들어서 Hotfix를 만들어서 내보낸 후에 다시 재작업을 합니다.

 중수
이보다 조금더 나은 경우, 원래 고치고 있던 소스코드의 디렉토리를 임시로 백업 받아 놓고 소스코드관리시스템에 있는 어제 버전의 소스코드를 다시 Check out합니다. 이렇게 Check out한 소스코드를 가지고 Hotfix를 만들어서 내보내고 오늘 작업하던 백업을 받아 놓은 소스코드와 Merge tool을 이용해서 Merge를 한 후에 정기 업데이트 버전을 만들어서 내보내는 방법입니다. 아까보다는 조금 나아 졌지만, 여전히 수작업에 많이 의존을 하고 귀찮은 작업들을 해줘야 합니다.

 고수
Subversion등의 소스코드 관리시스템을 제대로 사용한다면 이보다 좀더 손쉽습니다. 
우선 어제 릴리즈를 한 소스코드의 Baseline(Tag)에서 Hotfix용 브랜치를 만듭니다. 기존에 개발하고 있던 디렉터리는 그대로 놔두고 새로운 디렉터리에 Hotfix를 Check out 받습니다. 보고된 버그를 수정하여 자동화된 빌드스크립트를 이용해서 Hotfix를 만들어내고 업데이트에 올립니다. 정상적으로 Hotfix가 배포된 것을 확인하고 Hotfix 브랜치는 Trunk로 Merge를 합니다. 이때 3Way Merge 툴을 이용하면 됩니다. 
3Way Merge를 적용하려면 3개의 기준점이 필요합니다. 3개의 기준점은 다음과 같습니다.

Base - 어제 릴리즈한 Baseline(Tag)
Their - 오늘 Hotfix 릴리즈한 Baseline(Tag)
Mine - Trunk의 Head revision(최신소스)

3Way Merge를 통하면 거의 99% 자동으로 Merge가 되고 Conflict가 나는 소스코드들도 KDiff3나 P4Merge등의 GUI가 뛰어난 3Way Merge툴을 이용하여 쉽게 Merge를 할 수 있습니다.

그리고 현재 로컬에서 고치고 있던 소스코드와 통합을 해야 합니다. 이를 Rebase라고 하는데 SVN에서는 Update명령을 내리면 서버에서 바뀐 내용이 자동으로 Working copy와 통합이 됩니다. 이때도 3Way Merge를 이용하게 됩니다.

즉, 개발자는 소스코드 내용 고치는데만 신경을 쓰면 되고 나머지는 소스코드관리시스템이 다 알아서 해 줍니다. 소스코드 통합하는데 불과 얼마 걸리지 않고 혼동도 없습니다. 시간은 하수,중수의 수십분의 1이면 가능하게 됩니다.

혼자 개발하더라도 제대로 하지 않으면 이렇게 혼동이 있고 소스코드관리시스템의 기능을 잘 사용만하며 이렇게 손 쉬운데 개발자가 수십명, 수백명이서 하수, 중수의 방법으로 어떻게 소프트웨어를 제대로 개발할 수 있을까요?

물론 이것이 다는 아니죠. 기능을 충분히 사용하는 것은 이제 시작입니다. 더 큰 조직에서 조직적으로 제대로 사용하려면 프로세스, 규칙, 문화 등과 접목되어서 돌아가야 하는데, 이는 더 어렵습니다. 그러데 하물며 기능도 제대로 사용을 못하는 회사가 대부분인데 그 다음은 말할 필요하고 없죠.

Hotfix 경우 외에도 기존 소스코드에 큰 변경을 가해서 성공 여부를 확신할 수 없는 기능을 추가할때.
시간이 오래 걸리는 기능을 추가하면서 중간 중간에 다른 변경에 대한 릴리즈를 해야 할 때.
등 혼자서 개발을 하더라도 Branch/Merge를 해야 할 경우는 수도 없이 나오게 됩니다.

소스코드관리를 너무 쉽게 생각하면 안됩니다. 잘해 놓으면 무척 쉽고 개발에 매우 큰 도움을 주지만, 대충대충 하다보면 큰 발목을 잡히게 됩니다. 혼자 개발하더라도 제대로 하겠다는 마음가짐을 가지고 완벽하게 전체 기능을 다 알아야 합니다. 그리고 나면 이좋은 것을 왜 지금까지는 제대로 하지 않았을까 아쉬움이 들겁니다.

책을 보고 해보는 방법도 있지만 시간이 좀 많이 걸리겠지요. 주변에서 잘아는 사람에게 물어보는 것은 시간을 절약할 수 있는 좋은 방법입니다. 주변에 그런 사람이 없다면 블로그에 궁금한 것을 올려주세요. 제가 힘이 닿는한 잘 설명드리겠습니다. 제가 쓴 책(소프트웨어개발의 모든 것)에서는 이러한 부분이 이론적이 아닌 실제 방법을 자세히 설명하고 있으니 보시는 것도 도움이 많이 될 것입니다.