SW개발과 규칙의 두얼굴 (개발문화 시리즈6)

이번 개발문화 이야기는 '규칙 준수 문화'다. 

우리 주변에서 규칙을 무시하는 현상을 자주 볼 수 있듯 소프트웨어 개발에 있어서도 규칙을 준수하지 않는 일은 자주 벌어진다. 물론 규칙을 정말 상세히 정하고 모든 사람이 규칙에 따라 소프트웨어를 개발한다고 더 잘되는 것은 아니다. 

계속 강조하지만 규칙은 최소한으로 정해야 하고 성숙된 개발문화에 의한 개발이 더 효율적이다. 그래도 규칙은 지켜야 하며 지킬 수 있고 지켰을 때 개발 효율이 최대화 되는 규칙을 만들어야 한다. 그럼 규칙을 무시하는 현상이 자주 벌어지는 이유를 살펴보자. 

첫째, 규칙을 지키지 않는 개발자들이 있다. 

보통 회사의 최고 개발자들에게서 종종 벌어지는 현상이다. 소수의 개발자들에게 목을 메고 있는 회사들은 그런 개발자들이 어떤 방식으로 개발을 하던지 그냥 놔두는 경우가 많다. 물론 핑계는 있다. 규칙을 따르면 짧은 기간 안에 개발을 끝낼 수가 없고 자신들이 최고이기 때문에 누가 도와줄 수도 없다고 한다. 

그러면서 프로세스를 따르지도 않고 문서도 안 만들면서 내용을 공유하지도 않는 경우가 많다. 이런 회사에서 규칙은 평범한 개발자들만 따라야 하는 형식적인 것이 되기 쉽다. 이런 과정에서 특정 개발자에 대한 종속성은 계속 커지고 개발 문화는 후퇴하게 된다. 결국 규칙은 있지만 실상은 주먹구구식으로 개발을 하는 것과 비슷하게 된다. 

둘째, 규칙이 너무 복잡하고 많은 경우이다. 

큰 회사일수록 자주 벌어지는 현상이다. 규칙이 회사 역량에 비해서 너무 많고 자세한 경우다. 세계적인 방법론을 흉내낼 때 종종 나타나며, 문제가 벌어질 때마다 규칙을 계속 추가하다 보면 규칙이 너무 많아지게 된다. 이런 조직은 관료화되어 규칙자체가 목적으로 변질된다. 원래 목적인 '소프트웨어를 가장 빠르고 효율적으로 개발하자'는 원칙과 거리가 먼 규칙을 지키기 위해서 앞뒤 가리지 않게 된다. 

결국 개발자들은 이런 규칙을 다 따르고는 도저히 개발이 안되므로 형식적으로 흉내만 내고 피해 다니는 요령을 키우게 된다. 개발 효율성은 오히려 주먹구구식 개발보다 떨어지곤 한다. 규칙은 꼭 필요한 것으로 최소화하고 개발문화와 절묘한 조화를 이뤄야 한다. 

셋째, 경영자들이 규칙을 무시하는 현상이다. 

가장 큰 문제 중 하나는 규칙을 정해 놓고 경영자들이 무시하는 것이다. 경영자들은 프로세스를 무시하고 아무 때나 요구사항을 뒤집고 자신이 전문이 아닌 기술적인 결정에 관여하기도 한다. 우리나라에서는 제왕적인 경영자가 워낙 많아 법은 있지만 왕은 지키지 않아도 된다고 생각한다. 

작은 회사들은 이런 경영자의 통찰력과 빠른 판단이 회사를 성장시키는데 큰 도움이 된다. 하지만 회사가 커지고 전문화되면 얘기가 달라진다. 소프트웨어 개발 과정에서 벌어지는 전문적인 분야에 대해서 한 경영자가 전문가보다 잘 알 수는 없다. 자칫 개발 과정에서 경영자의 개인적인 취향을 강요하는 현상이 벌어질 수도 있다. 

우리나라에서는 규칙과 법을 초월해야 더 막강한 권한을 가졌다고 생각하는 경향이 있어서 이런 일들이 더 자주 벌어지는 것이 아닐까 생각한다. 

결론은 꼭 지킬 수 있는 최소한의 규칙을 만들고 따르는 것이 중요하다. 대부분의 회사에서 소프트웨어 개발 프로세스는 너무 복잡하다. 산출물도 너무 많고 경직되어 있다. 중간에 승인절차가 너무 많은 경우도 수두룩하다. 

회사 성격에 따라서 필요한 프로세스가 다르기 때문에 획일적으로 말하기는 어렵지만 프로세스가 좀더 효율적으로 간단해질 필요는 있다. 그러면서 꼭 필요한 규칙은 만들어야 한다. 

예를 들어 보자. 코딩 컨벤션이 정해져 있다면 자신의 코딩 스타일과 달라도 따라야 하는 것이다. 공유도 규칙으로 강제화하기는 매우 어렵다. 소스코드 커밋(Commit)시 메시지는 몇줄 이상 남기고 소스코드에 주석은 몇줄에 한번씩은 남겨야 한다는 식으로 규칙을 정하면 형식에 치우칠 우려도 있고 자칫 효율이 더 떨어질 수 있다. 

서로 리뷰를 하면서 자연스럽게 개선해나가면 되는데 리뷰를 안하는 것이 문제가 된다. 그래서 리뷰는 일주일에 두번씩 한다고 하거나 소스코드 커밋(Commit)시 70% 이상은 리뷰를 해야 한다는 구체적인 규칙을 정해 놓으면 또 효율성은 떨어진다. 

아주 단편적인 몇가지 예만 들었지만 뭔가 안된다고 자꾸 규칙을 늘리면 규칙을 피해가는 부작용이 또 발생하므로 적절하게 균형을 맞춰서 개발문화를 성숙시키는데 더 노력해야 한다. 자칫하면 말도 안되는 규칙만 점점 늘게 된다. 규칙에 의한 제한보다는 '권장', '독려', '포상' 등이 더 효율적이다. 

이렇게 원래 목적과 점점 거리가 먼 규칙이 자꾸 늘어가는 이유는 효율적인 개발문화 환경에서 개발을 해본 적이 없는 사람들이 자꾸 규칙을 만들기 때문이다. 아무리 소프트웨어 이론을 많이 안다고 해서 효율적인 개발 규칙을 만들 수는 없다. 

가장 좋은 방법은 그런 경험이 많은 개발자들은 회사에 합류시켜서 성숙된 문화를 받아들이는 것이다. 문화를 글로 배울 수 없듯이 경험자들의 도움을 받는 것이 좋다. 기억해야 할 것은 규칙으로 결코 소프트웨어 개발 문제를 해결할 수 없으며 성숙된 개발문화를 형성하는데 더 노력을 해야 한다는 것이다.

이글은 ZDNet에 기고한 칼럼입니다.

서열문화가 SW산업 망친다. (개발문화 시리즈5)

이번 개발문화 이야기는 '서열이 지배하는 조직문화'다. 

우리나라는 옛날부터 서열을 매우 중요시 한다. 사람들이 모이면 서로 나이를 비교하고 서열을 정한다. 회사에서도 대리, 과장, 부장이 되려고 열심히 일한다. 직급에 따라 업무가 달라지고 급여도 서열에 비례한다. 물론 많은 변화가 있어 왔지만 뿌리깊게 자리 잡은 서열문화의 뿌리는 여전히 튼튼하다.

소프트웨어 산업에서도 서열 문화는 조직 문화에 많은 영향을 주었고 그로 인해서 많은 문제와 생산성 저하를 불러일으켰다. 소프트웨어 개발자도 직급에 따라 서열화 되며 주로 윗사람이 일을 시키고 아랫사람은 시키는 대로 일하는 형태가 많다.

이러한 수직적인 조직문화는 수평적인 조직 문화에 비하여 소프트웨어 개발에는 적합하지 않다. 자율성과 창의성이 강조되는 소프트웨어 개발 현장에서 수직적인 조직문화는 자칫 창의력을 저해하고 수동적인 마인드를 형성할 수 있다. 

내 경험에 의하면 소프트웨어 개발에 적합한 효율적인 조직은 수평적인 조직이다. 각자 역할을 나눠서 일을 하지만 상하관계는 아니다. 업무도 그렇게 수평적으로 전문화된다. 역할은 프로젝트 규모에 따라 세분화되기도 하고 크게 몇 개로 나뉘기도 한다. 

큰 프로젝트에서는 아주 많은 역할로 나뉜다. 소프트웨어 아키텍트, 프로그래머, 프로젝트 매니저, 프로덕트 매니저, 리스크 매니저, 빌드 엔지니어, 테크니컬 라이터 등 여러 역할이 있지만 이들은 상하 관계가 아니다. 전문화된 일을 하는 것이다.

그런데 수직적인 조직문화를 가진 소프트웨어 회사에서는 이들 역할과 비슷한 이름을 사용한다고 하더라도 수직적인 관계는 그대로 유지가 된다. 윗사람이 시키고 아랫사람은 지시에 따르는 스타일로 일을 한다. 그리고 전문적인 역할 구분 없이 윗사람이 모든 것을 결정할 권한을 갖는 경우가 많다.

개발자는 신참이나 고참이나 모두 소프트웨어 엔지니어다. 고참이 되면 그냥 시니어 엔지니어가 되는 것이다. 과장, 부장이나 연차에 따라 책임, 수석이 되는 것은 서열 중심의 조직에서 나타나는 현상이다. 물론 회사 대표 개발자에게는 수석 사이언티스트(Chief Scientist), 펠로우 엔지니어(Fellow Engineer) 등 특별한 타이틀이 있을 수 있지만 모두 소프트웨어 엔지니어다.

그 외에도 태크니컬 스티어링 커미티(Technical Steering Committee)나 아키텍트 그룹(Architect Group) 등의 조직이 있을 수 있지만 능력과 경험에 따른 역할의 구분이지 이들을 윗사람으로 생각하지는 않는다. 

부서간 커뮤니케이션에서도 서열은 많은 영향을 미친다. 합리적인 결정보다 서열에 의한 결정이 종종 발생한다. 대리급 개발자가 영업부서의 부장에게 직급으로 눌려서 합리적인 결정을 못하기도 한다. 이렇게 서열문화는 생산성을 떨어뜨리고 개발자의 전문성 향상을 저해한다. 

최근에 몇몇 젊은 회사에서 서열 파괴 시도를 하고 있다. 직원들간 직급을 모두 없애고 서로 이름을 부르며 나이와 상관없이 모두에게 존칭을 사용하는 것이다. 이러한 시도는 상당히 긍정적으로 평가한다. 물론 부작용이 없는 것은 아니다. 연공서열을 파괴 했을 뿐이지 나이 어린 사람이 또 윗사람이 되어서 서열화가 되는 경우도 발생한다.

결국 서열을 없애고 조직을 수평화시키는건 제도만으로 완성되는 것이 아니다. 조직이 전문화되고 전문가를 우대하는 문화도 정착이 되어야 한다. 각자 역할에서 전문가로 성장할 수 있고 관리자를 넘보지 않아도 대우를 받으며 일할 수 있어야 한다. 

소프트웨어 산업은 특수성이 강하다. 엄청나게 복잡한 지식산업이면서 예술성이 강하다. 서열에 의한 역할분담이나 지시에 의한 업무 진행은 소프트웨어 개발에 적합하지 않다. 서열보다는 각자의 특성, 실력에 따라서 수평적으로 일을 나눠서 하는 수평적인 조직문화가 필요하다. 

수평적인 조직이라도 다 같이 똑 같은 일을 하는 것은 아니다. 일반적으로 고참은 더 어려운 일을 하고 리뷰도 많이 한다. 대우도 서열보다는 실력에 의해서 차별화 되어야 한다. 그러려면 모든 개발이 투명화 되어 모든 개발자의 실력과 성과가 만천하에 드러나야 한다. 

결국 서열을 없애고 수평적인 조직을 만들기 위해서는 개발 방식 자체도 바뀌어야 한다. 조직뿐만 아니라 프로세스, 시스템도 모두 바뀌어야 한다. 제도만 바꿔서는 실패할 가능성이 크다. 모든 문화는 서로 얽혀 있어서 하나만 바꾼다고 될 일은 아니다. 연관된 모든 문화를 같이 바꿔야 하고 꾸준히 투자해야 한다. 

가장 중요한 것은 경영진의 마인드이다. 그래야 꾸준히 변화의 추진력을 얻을 수 있다. 변화는 1,2년에 마무리되는 것이 아니고 회사가 지속되는 한 끊임없이 투자를 해야 하는 것이다. 

본 칼럼은  ZDNet Korea에 기고한 글입니다.

SW개발의 8:2 법칙, 그리고 불편한 진실 (개발문화 시리즈4)

이번 개발문화 이야기는 '가내 수공업식 개발문화'다. 즉, 8:2 법칙에 관한 이야기다.  소프트웨어 개발에 있어 시스템과 개발자에 의존하는 비율이 8:2정도가 되어야 한다는 것이다. 

그럼 다른 분야는 어떨까? 예술적일수록 시스템에 의존하는 비율이 낮고, 체계화되고 규모가 클수록 시스템 비율이 높아져서 인력에 대한 유연성은 증가한다. 

소프트웨어 개발에 있어 가장 중요한 요소는 사람이다. 즉, 개발자이다. 그런데 전적으로 개발자에게 의존하는 개발방식은 효율도 떨어지고 리스크도 높다. 특히 소수 인력에 의존하는 방식은 가내수공업 형태를 벗어나지 못한다.

비단 소프트웨어 분야 뿐만이 아니다. 전통 도자기 등 시스템화로 인해 산업화를 못 이루고 맥이 끊겨 사라져버린 분야가 얼마나 많은가? 임진왜란 때 수많은 도공을 납치해간 일본은 도자기 생산을 체계화해서 산업화에 성공했다. 유럽 수출을 시작으로 부를 쌓아서 선진국이 되는 발판을 마련했다. 

회사 규모가 크나 작으나 회사 시스템에 대한 의존도가 매우 낮고 개별 개발자에 의존하는 회사는 개발자들을 효율적으로 활용하지도 못한다. 개발자들이 퇴사하면 큰 타격을 입고 새로운 개발자가 들어와도 효율적으로 일하는데 많은 노력과 시간이 필요하다. 

개발자들이 실력에 맞는 일을 적절하게 골고루 나눠 하지 못하고 한쪽으로 치우치기 일쑤고 고급 개발자들이 소방수역할을 하는 경우가 많다. 회사 규모는 큰데 여전히 가내수공업 형태를 못 벗어난 결과다. 

이런 현상은 회사가 시스템을 효율적으로 갖추지 못해서 벌어진다. 회사 시스템이란 개별 직원과 대비되는 회사의 전반적인 체계를 말한다.소프트웨어 회사 또는 소프트웨어를 개발하고 있는 모든 회사라면 갖춰야 할 시스템은 다음의 4가지가 있다. 

조직, 프로세스, 문화, 기반시스템이다. 

4가지를 잘 갖추고 있다면 특정 개발자에게 의존하는 리스크는 줄고, 개발자들도 더 효율적으로 일할 수 있다. 개발자가 이직을 해도 빠른 시간 안에 적응이 가능한다. 이것은 개발자와 회사 모두에게 이익이 된다. 

이렇게 되려면 소프트웨어 개발이 시스템에 의존하는 비율이 80%정도는 되어야 한다. 나머지 20%는 도저히 시스템으로 커버가 어려운 부분이다. 하지만 대부분의 회사는 8:2가 아니라 2:8 또는 1:9이기 때문에 문제다.

개인 회사이거나 아주 작은 회사도 지속적으로 성장하려면 시스템에 의존하는 비율을 0%에서 시작하여 20%, 50%, 80%로 차츰 높여가야 한다. 

특정 개발자가 빠져 나가면 대부분의 개발 경험과 지식도 함께 빠져나가게 되는 경우 회사는 매우 불안한 상황에 놓인다. 이런 상황을 개발자가 의도적으로 만든 것은 아니다. 회사의 시스템이 워낙 부실하기 때문이다. 

이런 상황이라면 개발자도 워낙 바빠서 그런 상황에 신경 쓸 겨를이 없다보니, 상황은 더욱 악화된다. 단기적으로는 개발자 가치가 올라가서 더 좋을 것 같다. 하지만 장기적으로 보면 이런 환경에서 개발자는 적절한 성장 기회를 얻지 못한다. 아키텍처는 신경 쓰지도 못하고 여기저기 불려다니면서 재미없고 힘든 문제 해결에 주로 투입된다. 개발자 본인에게도 장기적으로는 손해다. 

여기에는 몇 가지 논란이 있을 수 있다. 

첫째, 그럼 개발자는 교체 가능해야 하는 부품인가? 

회사가 시스템을 갖춰야 하는 이유는 개발자를 교체 가능하도록 하기 위한 것이 아니다. 리스크를 줄이고 좀더 효율적으로 개발하기 위해서이다. 개발 중에는 교체가 쉽게 되는 일이 있고, 어려운 일이 있다. 교체가 쉽게 되는 일까지 회사 핵심개발자들의 시간을 많이 빼앗으면 안된다. 회사 핵심 개발자들은 좀더 중요한 일을 해야 한다. 

그러려면 쉬운 일들, 과거에 해놓은 일들을 다른 사람이 할 수 있는 시스템이 필요하다. 이런 상황에서는 핵심 개발자가 퇴사해도 유지보수에 큰 문제가 없다. 하지만 미래의 중요한 프로젝트에 타격을 입기 때문에 개발자들의 가치는 결국 커진다. 물론 아주 작은 회사는 상황이 다르다. 

둘째, 시스템을 아주 잘 갖추고 있는 대기업이 소프트웨어 개발을 더 잘해야 하는 것 아닌가? 

시스템은 회사의 상황과 역량에 알맞게 적절히 갖춰야 한다. 하지만 큰 회사들은 여기서 큰 불균형을 이루는 경우가 많다. 프로세스를 과도하게 복잡하게 하고 사용하기도 힘든 비싼 시스템들을 구축해 사용을 하기는 하지만 효율성 측면에서의 개발문화는 한참 뒤쳐져 있다. 

이런 상황에서 프로세스는 형식적으로 흐르고 비싼 시스템은 장식물에 그치는 경우가 많다. 개발효율로 따지만 주먹구구보다 더 못한 경우도 있지만, 보험의 성격이 있어서 쉽게 포기하지도 못한다. 

소프트웨어 회사가 갖추어야 할 시스템, 즉, 조직, 프로세스, 문화, 기반시스템은 교과서에 딱 정해져 있는 것은 아니다. 회사 규모, 성격 등에 따라서 계속 바뀌어 나가야 한다. 부족해도 문제고 과도해도 안된다. 

개발자 혼자 회사를 하면 혼자서 모든 것을 다해야 하지만, 10명, 30명, 100명으로 늘 때마다 조직 구성이 달라져야 한다. 하지만 많은 회사들이 큰 규모에 비해서 이런 구분 없이 개발자에게 너무 많은 일을 맡기고 있는 경우가 많다. 

보통은 회사가 커지면서, 테스트, 빌드, 시스템관리, 기술지원, 고객지원, 영업지원 등과 같은 일들은 전문조직으로 분리해야 한다. 어려운 점은 적절한 시점에 적절한 규모로 조직을 변화시켜야 한다는 것이다. 

그럼, 프로세스는 어떤가? 여기에도 극과 극이 있다. 명시적인 프로세스가 아예 없거나 너무 복잡한 경우도 많다. 프로세스는 최대한 단순하고 자유도를 높이면서도 핵심적인 요소들은 빠지지 않도록 해야 한다. 이 또한 회사의 역량이 높아감에 따라서 계속 바뀌게 된다. 

많은 회사들이 열악한 개발 문화와 낮은 역량을 비싼 기반시스템이 해결해 줄 것으로 착각한다. 꼭 필요한 기반시스템도 있지만 오히려 해가 되는 경우가 훨씬 더 많다. 소수의 필수 시스템을 제외하고는 적절한 시점에 필요하면 사용하면 된다. 꼭 비싼 시스템이 아니라도 상관없다. 개발자당 연 사용료가 수백, 수천만원하는 종합선물세트 시스템을 구축해 놓고 극히 일부 기능만 쓰는 경우도 많다. 툴로는 결코 문화나 역량을 극복할 수 없다. 

반대 경우도 문제인건  마찬가지다. 필수 기반시스템 하나 없이 주먹구구로 개발하는 회사라면 좋은 오픈소스 기반시스템들이 있으므로 잘 선택한뒤 제대로 가이드를 받아 사용하면 된다. 과도한 경우보다는 개선하기가 쉽다. 

회사 규모에 맞게 안정적이며 꾸준히 역량을 향상하면서 개발을 하려면 개발자에게만 책임을 지울 것이 아니라 회사가 더 많은 것을 갖추고 있어야 한다. 그러기 위해서 꾸준한 투자와 변화는 필수다. 작년과 올해 조직, 프로세스가 똑같고 변화를 위해 투자를 한 것이 하나도 없다면 회사는 책임을 회피하고 있는 것이다.

리스크를 줄이고 개발자가 보다 효율적으로 일할 수 있는 환경을 만들려면 회사가 80%를 갖출 수 있도록 노력해야 한다.

본 칼럼은 ZDNet Korean에 기고한 글입니다.

SW개발과 빨리빨리 문화의 저주(개발문화 시리즈3)

이번에 다룰 개발문화 이야기는 '빨리빨리 문화'다. 

일을 빨리 하자는게 나쁜 건 아니다. 오히려 이런 '빨리빨리 문화' 덕분에 우리나라가 짧은 기간에 성장했을지도 모른다. 더 짧은 시간에 똑 같은 일을 해낼 수 있다는 것은 경쟁력이 있는 것이다. 우리는 그동안 많은 산업분야에서 '빨리빨리 문화'의 혜택을 입었고, 관련 노하우도 많다. 

그런데, 이런 '빨리빨리 문화'가 소프트웨어 분야에서는 독이 되는 경우가 많다. 실제로 독이 되는 경우를 많이 보았다. 시제품은 빨리 만드는데 본제품을 완성하는데는 시간이 훨씬 오래 걸리며 품질도 떨어지고 시간이 흐를수록 유지보수가 무척 어려워져서 제품을 포기하는 경우도 흔하다. 상황을 수습하지 못해, 회사의 종말로 이어질 때도 있다. 

유독 왜 소프트웨어 분야에서 '빨리빨리 문화'가 문제가 되는 것일까?  원인은 세가지로 요약할 수 있다. 

첫째, 소프트웨어는 훨씬 복잡하다. 다른 분야에는 미안하지만 소프트웨어는 가장 복잡한 지식산업이다. 빨리 개발해야 한다고 열심히 코딩부터 시작해서 으쌰으쌰 개발하면 아키텍처는 뒤죽박죽 되고 개발 기간도 오래 걸린다. 그렇다고 차근차근 모든 설계서를 만들고 설계서대로 개발하면 좋겠지만 그렇게 하면 웬만한 프로젝트를 마무리는데 10년쯤 걸릴 것이다. 절묘한 절충이 가장 어렵다. 

둘째, 소프트웨어는 예술이다. 소프트웨어 아키텍처를 만들어 가는 과정은 예술과 비슷하다. 예술은 재촉한하거나 야근을 한다고 해서 빨리, 더 좋은 결과가 나오는 것은 아니다. 수많은 요구사항과 비즈니스 전략 등을 종합하여 가장 적합한 아키텍처를 만드는데 시간이 부족하면 부실한 아키텍처가 되고 개발에 들어갔거나 유지보수시 이를 바꾸려면 비용은 100배, 1000배가 더 든다. 

셋째, 소프트웨어는 생명체와 같다. 소프트웨어는 건축에서 개념을 가져온 것도 많고 실제 비슷한 것도 많다. 하지만 빌딩은 일단 완공되면 100년동안 기본 구조가 거의 안바뀌지만 소프트웨어는 보통 출시되도 계속 성장한다. 소프트웨어는 출시 후부터 초기 개발비용보다 약 4배의 돈이 더 드는 것으로 알려져 있다. 하지만 아키텍처가 부실하다면 4배가 아니라 40배의 비용을 더 들이고도 업그레이드 및 유지보수가 어려울 수 있다. 

그럼, '빨리빨리 문화'가 문제니 차근차근 천천히 개발을 해야 할까? 그건 전혀 아니다. 수많은 성공한 글로벌 소프트웨어 회사들은 천천히 개발을 해서 성공한 것이 아니다. 소프트웨어 개발의 최대 미덕은 소프트웨어를 빨리 개발하는 것이다. 소프트웨어 개발을 조금이라도 느리게 하는 모든 방법론, 규칙, 제약, 프로세스는 잘못된 것이다. 

'빨리빨리 문화'가 소프트웨어 개발을 오히려 더 느리게 하고 다른  문제들도 일으키기 때문에 문제라는 것이다. '빨리빨리 문화'는 소프트웨어 개발 프로젝트에서 다음과 같은 것들을 유발한다. 

-프로젝트 지식, 정보, 자료 공유의 부재 
-부실하고 확장성이 떨어지는 아키텍처 
-특정 개발자에게 종속됨 
-수많은 중복된 코드 
-개발자의 인간다운 삶과 성장 포기 
-점점 증가하는 유지보수 비용 

이런 현상은 개발 방법론과는 상관없이 벌어진다. SRS(Software requirements specification) 형태로 스펙을 제대로 쓰던 TDD를 하던 이는 모두 소프트웨어를 빨리 개발하기 위한 방법이다. 문서작성, 코드리뷰, 프로세스 등 모든 것은 소프트웨어를 빨리 개발하려는 것인데 이런 것들이 개발을 느리게 하니 그냥 개발하자고 하는 것은 완전히 착각이다. 

물론 이런 방법들이 소프트웨어를 빨리 개발하는데 도움이 되려면 뛰어난 아키텍트도 필요하고 회사의 개발문화 성숙도도 높아야 한다. 

빌딩을 빨리 만들겠다고 벽돌부터 서둘러 쌓아야 한다고 생각하는 사람은 없을 것이다. 기초공사와 설계가 잘되어야 어떤 방식으로든 빌딩을 빨리 만들 수 있다. 소프트웨어도 견고하고 확장성이 있는 아키텍처가 있어야 요구사항 변경에 대응이 잘되고 협업이 용이하며 개발 기간을 단축하고 비용도 절약할 수 있다. 

사실 무리한 일정 압박이 아키텍처에 큰 문제를 일으킨다는 것을 개발자 대부분은 잘 알고 있다. 그럼에도 '빨리빨리 문화'를 가속화시키는 주범은 따로 있다. 바로 경영자와 고객이다. 

대부분의 경영자에게 단기 성과는 생존 문제다. 회사 오너라면 조금 낫지만 많은 경영자들은 2년, 3년 단기 계약을 한다. 그 기간 안에 가시적인 성과를 내지 않으면 재계약이 어려워질 수 있다. 소프트웨어에 대한 깊은 이해도 부족하지만 미래를 고려할 시간은 더욱 없다. 6개월, 1년안에 성과를 내는 것이 가장 중요한 경영자는 영업이 가장 중요하고 단기 매출에 집착하며 아키텍처는 신경 쓸 여유가 없다. 

제대로 된 CTO가 있다면 CEO가 그렇게 마음대로 할 수는 없지만 우리나라에서는 CTO가 제대로 역할을 하기 어렵다. 

고객도 문제다. 우리나라 고객들은 이중적이다. 우리나라 개발사에는 버그를 당장 내일 고쳐줄 것을 요구하지만 글로벌 회사는 6개월 후에 고쳐주는 것을 고마워한다. 글로벌 회사는 아무리 얘기를 해도 빨리 고쳐주지 않는 다는 것을 알기 때문이다. 

우리나라 고객들은 개발자가 고객 회사에 들어와서 일해주기를 원한다. 스펙을 제대로 정리하고 효율적인 커뮤니케이션을 통해서 개발하는데 익숙하지 않기 때문에 옆에 앉혀놓고 종을 부리듯이 개발하기를 원한다. 

국내에서는 그런 고객의 입맛에 맞춰줘서 성공한 사례가 꽤 있다. 이런 문화는 국내 시장의 진입장벽이 되기도 한다. 그렇게 해서 우리나라에서는 1위에 등극했지만 이를 바탕으로 글로벌 시장으로 나아가는데는 큰 문제가 있다. 

개발문화가 비효율적이고 아키텍트의 역량이 떨어져서 세계 시장에서 패하는 경우가 많다. 그럼 외국 고객은 어떨까? 다는 아니지만 대부분 버그를 내일 고쳐 준다고 하면 의아하게 생각한다. 특히 매우 중요한 시스템이라면 이런 개발사의 신속한 대응은 오히려 개발사에 대한 신뢰를 떨어뜨리기도 한다. 

우리나라 개발사끼리는 이러한 고객 요구사항에 서로 잘 맞춰주겠다고 진흙탕싸움을 하고 있기 때문에 모두 다 힘들어지고 그 폐해는 고스란히 개발자에게 돌아간다. 개발자는 인간다운 삶을 포기해야 하기도 하고 그런 개발 환경에서는 개발자로서 성장하기도 힘들어진다. 

'빨리빨리 문화'가 바뀌기 어려운 것은 사실이다. 고객도, 경영자도, 개발자도 바뀌어야 한다. 내가 어떻게 세상을 바꾸겠는가? 하지만 세상을 바꾸는 첫걸음은 내가 바뀌는 것이다. 내가 바뀌는 것의 시작은 깨닫는 것이다. 지금은 당장 나만 바뀌면 나만 손해를 볼 것이다. 

하지만 내가 바뀌고 동료가 바뀌지 않으면 '빨리빨리 문화'는 영원히 바뀌지 않을 것이다. 회사에서 아키텍처의 중요성을 깨닫고 아키텍트를 키우고 영업과 개발의 균형을 유지하는데 노력하고 급하게보다는 제대로 빨리 개발하기 위한 방법들을 강구해야 한다. 

기반시스템, 방법론, 프로세스 모두 적절히 필요하다. 다른 여러가지 개발문화의 성숙도를 높여가는 것도 '빨리빨리 문화'를 고치는데 도움이 된다. 결국 우리가 바꿔 나가야 한다. 

'닭이 먼저냐 달걀이 먼저냐' 이슈와 비슷하지만 개발문화 성숙도 문제를 깨닫는 것만으로도 의미가 크다. 문화란 글이 아니라 경험을 통해서 배워야 하고 경험자에게 배워야 시행착오를 줄일 수 있다. 꾸준히 관심을 가지고 익히는 자세가 필요하다.

이글은 ZDNet Korea에 기고한 글입니다.

QA팀이 필요없다고?

최근에 평가 자리에서 만난 유망하다는 스타트업의 대표의 이야기이다.

회사의 조직구조를 보니 테스트를 하는 팀이 보이지 않았다. 그래서 "QA팀이 없는냐"고 물어보니 "우리회사의 개발자들은 실력이 뛰어나서 테스트가 필요없는 프로그램을 만든다"라는 답변을 들었다. 그리고 본인(CEO)은 개발자들을 믿는다고 한다. (다른 회사는 믿음이 부족해서 버그가 생기나? ^^)

좀더 자세히 물어보니 내부에는 테스트인력이 없고 테스트를 고객이 해주는 것이었다. 삼성등의 대기업이 주 고객인데 패치도 자주 나갈뿐더러 고객이 테스트담당자가 있어서 패치가 나올때마다 꼼꼼하게 테스트를 해준다는 것이다.

사실 이런 얘기 하나만 들어도 회사가 얼마나 형편없는지 알 수 있다. 당장은 동작하는 소프트웨어를 만들어 낼 수는 있지만 그 이상은 택도 없을 것이다.

겉으로는 유망한 스타트업이고 Global Service를 준비중이며, 대규모 IR을 진행하고 있다고 한다. 그래도 꽤 유망하다는 스타트업이 이런 정도의 수준이라니 실망스럽기 짝이 없다.

회사의 품질관리를 고객에게 맡긴다는 것도 우습고 고객이 비용을 들여서 테스트를 해준다는 것도 우습다. 고객은 확인하는 정도의 Acceptance Test라면 말이 되지만 이렇게 같이 개발하는 형태의 개발은 세계적으로 유래를 찾아보기 어려울 것 같다.

이런 형태가 가능한 것이 스펙도 불확실한 상태에서 개발을 하다보니 고객과 개발사가 같이 으쌰으쌰하면서 개발을 한다. 주먹구구의 대표적인 행태이다. 이러다 보니 제대로 기획된 제품이 만들어지기 보다는 고객 담당자 취향대로 개발이 되곤 한다.

필자의 경험에 의하면 많은 회사들이 이 회사와 크게 다르지 않다. 또한번 갈길이 멀고 넘어야 할 산이 많다는 것을 느낀다.

주먹구구식 개발이 통하는 이유

우리나라의 많은 소프트웨어 회사들은 주먹구구식 개발에 대한 환상이 있다.

특히, 첫번째 시스템을 주먹구구식으로 개발을 해서 성공했는데 지금은 좀더 체계를 갖췄는데 더 개발이 잘 안된다면 과거 진짜 주먹구구식으로 개발할 때를 그리워하고 그 때로 돌아가고 싶어 한다.

여기 이와 관련된 과거 글이 있다. 

2012/07/26 - [소프트웨어이야기] - 옛날에는 개발을 더 잘했는데

주먹구구식으로 개발을 하다가 현재 체계를 갖추려고 노력하고 있다면 아직은 불완전할 뿐더러 반쯤은 주먹구구인 것이다. 그럼 주먹구구식 개발은 어떤 것인지 정의를 내려보자. 크게 5가지로 설명할 수 있다.

첫째, 스펙/설계 없이 개발을 하는 것이다. 또는 기능명세서, 시방서 등의 문서에 기능만 정리하여 개발하는 것이다. 이 방법은 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍처를 만들 수도 없고, 개발자들이 효과적으로 일을 나눠서 개발할 수도 없으며 프로젝트 진척상황을 거의 파악할 수 없다. 일정 지연은 일상이고 그야말로 끝나봐야 아는 것이다.

둘째, SVN, Git 등의 소스코드관리시스템과 Jira, Mantis, Redmine 등의 이슈관리시스템 없이 개발하는 것이다. 둘중 하나라도 사용하지 않으면 심각한 문제이다. 일단 쓰기만 하더라도 다행이지만 제대로 쓰는 것은 정말 어렵다. 대부분은 10% 정도의 기능밖에 사용하지 못하지만, 100% 기능을 활용해야 한다.

셋째, 혼자 북치고 장구치고 다하는 것이다. 일을 전문적으로 나눠서 하는 것이 아니고, 혼자서 기획, 분석, 설계, 코딩, 테스트, 빌드 등등 다 하는 것이고 이런 개발자가 여럿이고 서로 중복되서 일을 하기도 한다. 첫째에서도 언급했듯이 스펙이 제대로 작성되어야 일을 효과적으로 나눌 수 있는데 스펙이 없거나 부실하면 이런 현상이 벌어진다. 또, 회사의 조직이 소프트웨어 개발에 알맞게 효과적으로 구성되어 있지 않아도 이런 일이 벌어진다. 소프트웨어는 전문가들이 협업하여 개발하는 것이다.

넷째, 프로세스 없이 대충 개발하는 것이다. 흔히들 프로세스는 개발을 더 느리게 만든다고 주장하곤 한다. 그러면서 회사에서 프로세스를 만들려고 하면 반대 주장을 펼친다. 과거에 개발하던 방법을 서로 암묵적으로 알고 있다가 대충 개발을 하고 서로 이심전심으로 문제를 해결해 나간다.

다섯째, 리뷰, 공유 없이 개발하는 것이다. 가끔은 대충 기능목록 작성해서 마케팅이나 영업, 경영진과 리뷰를 하기도 하지만 제대로 된 리뷰는 아니다. 개발자를 제외하고는 지금 어떤 제품을 만드는지 정확하게 파악이 안된다. 심지어는 개발자들도 잘 모른다. 다 만들어봐야 어떤 제품을 만들었는지 알게 된다. 그러니 만들기 전에는 무슨 문제가 발생할지 몰라서 만드는 도중에 수많은 문제가 발생하고 재작업은 수시로 이루어 진다. 심지어는 80%쯤 만들었다가 아키텍처가 잘못된 것을 발견하고 다 버리고 다시 만들기도 한다.

정도의 차이는 있을 수 있다. 다섯가지 중에서 하나 이상이면 아직 주먹구구식 개발에서 완전히 벗어난 것이 아니다. 스스로도 주먹구구식으로 개발을 하고 있는지 평가를 해보자.

2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표

그럼에도 불구하고 주먹구구식 개발이 여전히 통하는 이유는 무엇일까?

첫째, Software의 크기가 아주 작다.

빌딩은 제대로 된 분석/설계 없이, 프로세스 없이 만드는 것은 불가능하다.

하지만 개집은 그런 것 필요 없다. 대충 만들어도 문제 없이 만들 수 있다. 한 사람이 머리 속으로 모든 것을 설계해서 만들 수 있는 정도의 규모라면 주먹구구식 방법도 훌륭한 방법이다.

둘째, 이직률이 극도로 낮다.

한번 개발을 해 놓으면 개발자들이 절대로 퇴사를 하지 않고 끝까지 책임져준다. 

셋째, 회사 규모가 작다.

개발자도 몇 명 안되서 서로 너무 잘 알고 모든 이슈가 더 구두로도 공유가 되고 급한 이슈는 자리에서 바로 일어나서 공유가 되고 논의할 수 있다. 가족적인 분위기에서 주먹구구식 방법이 훌륭하게 작동한다.

넷째, 소프트웨어 업그레이드가 없다.

한번 개발해 놓은 시스템이 업그레이드가 필요 없는 경우이다. 어떻게 든 첫번째 개발을 해 놓으면 문제가 없다.

그럼, 주먹구구식 개발이 앞으로도 계속 통할까?

회사가 잘되면 회사는 커지게 되어 있다. 개발자 수는 많이 늘게 되고 더 이상 자리에서 일어나 뒤로 돌아도 모든 개발자의 얼굴을 볼 수 없게 된다. 과거처럼 공유가 그렇게 잘 되지 않는다.

개발자들이 영원히 이직하지 않고 직원으로 있기를 바란다면 너무 큰 욕심이다. 개발자들은 언젠가는 이직을 하게 마련이고, 개발자들이 이직을 해도 개발은 잘 돌아가도록 되어 있어야 한다. 주먹구구식으로 계속 개발을 하게 된다면 아무리 가족적인 분위기라고 하더라도 직원이 Risk 요인이 된다.

Software 회사의 경영자라면 지금 대충 잘 굴러가는 것 같다고 해서 방심하면 안된다. 회사가 잘 되면 회사는 커지고 직원도 늘고 더 복잡해질 것이다. 문제를 모르고 방심하다가 문제가 터지고 나면 터진 댐을 막으려고 하는 것처럼 어렵다. 항상 미리 준비를 해야 하는 것이다.

물론, 처음부터 제대로 하는 것이 가장 빨리 개발하는 방법이고 좋지만 그것을 깨닫기는 매우 어렵다. 대부분은 문제가 터진 후에 우왕좌왕 한다. 주먹구구식 개발이 지금은 통할지도 모른다. 하지만 곧 주먹구구식 개발이 문제가 되는 상황이 올 것이고 이미 문제가 되고 있다면 너무 늦지 않았기만 바랄 뿐이다. 늦었다고 생각할 때가 가장 빠른 때이다.

7명이 할 수 있는 일을 70명이 하고 있는 이유

최근에 한 글로벌 소프트웨어 회사(Y사, 가칭)의 한국 지사 관계자에게 들은 이야기이다.

비단 Y사 얘기만은 아니다. 세계적인 소프트웨어 회사의 한국지사에서 종종 벌이지는 일이다.

Y사의 본사에서는 처음에 한국지사를 만들었을 때 한국에서도 미국의 개발 프로세스를 따를 것을 종용했다고 한다. 하지만 한국에서 채용된 개발자들은 미국의 개발 프로세스는 너무 무겁다고 한국 방식으로 개발했다고 주장을 했다. 그리고는 미국의 개발 주문에 대해서 믿을 수 없는 속도로 해결을 해나가기 시작했고, 미국 본사는 이런 경이로운 결과를 보고는 한국식 개발을 묵인할 수 밖에 없었다.

그뒤 몇 년이 지난 지금은 어떻게 되었을까? 미국 본사의 개발 프로세스를 착실히 따른 호주 지사와 엄청난 차이를 보이고 있다고 한다. 똑같은 일을 호주 지사에서는 7명이 처리를 하고 있고 한국 지사에서는 70명이 야근까지 해야 간신히 처리를 하고 있다고 한다. 

그렇게 된 이유가 분석/설계도 없이 빨리빨리 개발을 하다보니 아키텍처가 엉망이고 개발자들이 많이 바뀌었는데 내용을 아는 사람도 별로 없다고 한다. 뭐 하나 고치려고 해도 보통 어려운 것이 아니라고 한다.

전해 들은 얘기라서 과장이 있다고 해도 문제가 심각하고 이미 많이 망쳐 놓은 것은 사실이다.

글로벌 소프트웨어 회사라고 하더라도 한국에 와서 착각하는 것들이 있다. 놀라운 속도를 보여주는 한국식 개발방식을 신기해 하지만 그 문제점을 피부로 심각하게 알지 못한다.  스펙도 제대로 작성하지 않고 분석/설계/구현을 섞어서 빠르게 개발하는 것이 신기해 하지만 얼마나 큰 문제가 있는지 실리콘밸리 회사들도 잘 모른다. 그런 식으로 개발해 본적이 없기 때문이다.

그렇다고 글로벌 소프트웨어 회사가 본사의 개발 프로세스를 강제화 한다고 잘 적용되는 것은 아니다. 한국에서 잔뼈가 굵은 개발자들은 몸에 밴 개발 방식 때문에 적응하기가 매우 어렵다. 차라리 신입사원들을 뽑아서 교육시키면서 개발을 하는 것이 더 빠를지도 모른다.

이는 한국의 소프트웨어 회사 내부에서도 그대로 적용된다. 글로벌 소프트웨어 회사의 개발 프로세스가 아무리 좋다고 하더라도 한국의 소프트웨어 회사에는 바로 적용이 안된다. 대부분은 무리한 시도이고 실패한다.

변화를 감당할 수 있을만큼씩 조금씩 바꿔나가야 한다.

삼성이 M&A를 통해서 이번에는 소프트웨어 경쟁력을 갖출 수 있을까?

필자가 1년반쯤 전에 쓴 삼성의 소프트웨어 경쟁력에 대한 글을 보면 새삼 감회가 새롭니다. 요즘 한창 이슈가 되고 있는 M&A 등의 이슈를 다루고 있다. 단순한 상황 뿐만 아니라 방법도 제시를 하려고 했었다.
아래는 해당 글들이 있다.

2010/01/05 - [소프트웨어이야기] - 삼성은 왜 소프트웨어를 잘 만들지 못할까?
2010/01/23 - [소프트웨어이야기] - 삼성이 바다를 출시해서는 안되는 이유
2010/02/08 - [소프트웨어이야기] - 삼성이 앞으로도 소프트웨어를 잘 만들 수 없는 이유
2010/03/02 - [소프트웨어이야기] - 삼성이 소프트웨어 분야에서도 최고가 되려면?

삼성이 왜 소프트웨어 경쟁력이 부족하고 어떻게 소프트웨어 경쟁력을 갖출 수 있는지 나름대로 방법을 제시했었다. 특히 3/2 글에서는 좀더 실패를 해서 소프트웨어 중요성을 더 깨달아야 한다고 했었는데 좀더 실패를 경험한 모양이다.

그 때 제시를 했던 것이 크게 두가지였다.

첫째, 소프트웨어 회사 M&A이다. 물론 국내 소프트웨어 회사는 아니다. 국내의 다른 소프트웨어 회사와 비교하면 삼성의 소프트웨어 역량은 차라리 높은 편이다. Global한 경쟁이 안된다 뿐이지 국내에서는 잘하는 셈이다. 그도 그럴 것이 우수한 소프트웨어 인력 싹 쓸이 해갔고 그동안 효율적이지는 않지만 소프트웨어에 물질적으로 엄청난 투자를 해왔기 때문이다. 그럼에도 글로벌 Software회사와는 엄청난 차이를 보이고 있는 것은 어쩔 수 없다. 심지어는 몇명이 뭉쳐서 만든 실리콘밸리의 스타트업 회사보다 개발 문화나 역량 면에서 못한 것은 안타가운 일이다.

둘재, 소프트웨어를 잘아는 전문 경영인들을 확보해야 한다. 이들이 조직내에서 밀리지 않도록 꾸준한 지원도 필요하다. 그동안 소프트웨어 전문가들이 있었음에도 조직내에서 제 목소리를 내지 못하고 단기적인 비즈니스 논리에 밀려서 제대로 힘을 못써왔고 많이들 밀려나고 말았다.

그럼 이번에는 삼성이 제대로 소프트웨어 역량을 강화할 수 있을 것인가? 궁금하지 않을 수 없다. 

삼성이 이토록 소프트웨어 역량 강화에 관심을 가지는 이유는 살아남기 위해서이다. 진작부터 여런 산업 분야에서Hardware보다 Software 비중이 점점 높아지고 있었는데 공룡 조직의 느린 움직임으로는 이를 따라 잡지 못하고 있었다. 연일 신문에서는 소프트웨어를 떠들지만 사실 단어로서 의미 이상을 느끼고 있는지 모르겠다. Hardware 중심으로 마인드가 박힌 조직이 단시일내에 바뀌기란 불가능하다. 

최고 경영층에서 M&A를 강조하고 있기 때문에 뭔가 사기는 살 것이다. 하지만 M&A를 통해서 절대로 사올 수 없는 것이 있다. 바로 "Soft적인 기업 문화"이다. 소프트웨어 역량을 갖추기 위해서는 "Soft적인 기업 문화"가 필요한다. 삼성과는 너무나 거리가 멀다. 

지금 Hardware는 잘하고 있는데 Software가 부족해서 "사온다"의 의미로는 이미 너무나 부족해졌다. 

필자는 "삼성의 상당한 조직은 완전히 Software적으로 재편되어야 한다"고 생각한다. 이는 삼성 뿐만이 아니다. 이제 상당히 많은 산업 분야가 Software가 중심이고 Hardware는 부가적인 것이 이미 되었고 점점 더 가속화가 되고 있다.

M&A를 통해서 핵심 기술과 특허를 사올 수는 있지만 이는 "공룡에 분칠"하는 정도일 것이다. 지금 필요한 것은 대대적인 조직문화 탈바꿈이고 이를 이끌 수 있는 "수혈"이 필요하다. 수혈은 소프트웨어 전문 경영인을 말한다. 물론 몇몇 우수한 소프트웨어 전문 경영인들이 있기는 하지만 조직에 비해서는 너무나도 적은 인원이고 더 큰 힘도 필요하다. 지금 바뀌지 않으면 기회가 없을지도 모른다.

안타까운 것은 이러한 시도가 너무나 무모해 보이기도 한다. 이러한 변화를 기존 조직의 기득권층이 과연 받아들이고 융합이 될 것인가? 필자는 어렵다고 본다. 따라서 전 조직이 아니라 소프트웨어 비중이 높은 조직부터 바뀌거나 아예 기존 조직과 거리를 두는 새로운 조직을 만드는 것이 차라리 가능성이 있어 보인다.

필자는 삼성이 Soft하게 바뀌는 것이 국내 소프트웨어 산업에도 많은 도움이 될 것으로 생각한다. Soft적인 마인드는 자연스러운 공생의 길을 가게 만들것이다.

미우나 고우나 삼성은 국내 소프트웨어 업계 뿐만아니라 전체 경제에 막대한 영향을 주고 있으므로 잘 되어야 한다. 

소프트웨어에 있어서는 과거처럼 안 된다는 것을 빨리 깨달아야 한다. 
소프트웨어는 생각하는 것보다 1,000배쯤 어렵고 복잡한 것이다. 
돈주고 쉽게 사올 수 있는 것도 아니다. 
소프트웨어적인 역량이 있는 회사만이 좋은 회사를 사와도 도움이 되는 것이다.
지금의 마인드를 바꿀 수 없다면 점점 뒤쳐질 수 밖에 없을 것이다.

왜 하나만 써야 하는가?

이전의 글에 종종 소스코드관리시스템과 버그관리시스템은 하나만 써야 한다고 얘기를 한 적이 있다.
또한 내가 2008년에 작성한 소프트웨어 회사의 개발 역량 평가 표에는 20점 중 2점을 차지하고 있다.

2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표 

종종 "여러개를 쓰면 어떤가?"하는 궁금증이 있어서 그 이유를 설명하고자 하다.

소스코드관리시스템을 여러개 쓰고 있다면?

 
회사가 아무리 크더라도 소스코드관리시스템은 하나만 쓰는 것이 좋다. 한 종류의 시스템을 여러개 설치에서 쓰는 것도 좋지 않다. 또한 특별한 이슈가 없는 경우라면 하나의 Repository에 소스코드를 관리하는 것이 좋다.

여러 시스템을 쓰는 경우는 대부분 팀마다 각자 취향에 따라서 VSS도 쓰고 SVN도 쓰고 Git도 쓰는 경우이다. 이러한 경우 각자 핑계들이 있다. Visual Studio에 최적화된 VSS를 써야 한다는 둥, 오픈소스를 이용하기 때문에 Git가 좋다는 둥의 주장을 하다가 각 팀에서 알아서 쓰기로 결정을 종종 하게 된다.

팀마다 다른 시스템을 쓰게 되면 여러가지 문제가 발생한다. 

첫째, 공통 모듈 관리가 전혀 안되서 공통 모듈을 서로 복사해서 쓰기도 하고 비슷한 모듈을 따로 개발하기도 한다. 공통모듈이 없는 SW회사는 거의 없다. 관리를 안할 뿐이다. 이것이 얼마나 큰 문제가 되냐고 생각하는 사람들도 있다. 하지만 제품이 많아지고 고객이 많아지면 이렇게 복사된 공통모듈로 개발은 엉망진창이 된다. 유지보수 비용이 몇배로 들게 된다. 

둘째, 개발자는 각 팀마다 스위치가 자유로워야 하는데 서로 다른 시스템을 배우기 위해서 시간이 들어간다. 기본 기능은 배우는데 얼마 안걸리지만 완전히 손에 익어서 능수능란하게 쓰기에는 시간이 걸리는데 괜히 쓰지않아도 될 시간이 들게 된다.
그외에 전사적으로 관리가 잘 안되서 백업도 비용이 더 많이 들고 여러가지 문제가 발생한다. 주먹구구 식으로 작은 규모로 대충 개발할 때 문제가 눈에 안 띨분이지 나중에 댓가를 치르게 된다.  나중에 문제가 발생한 후에 통합은 거의 불가능하다 처음부터 하나를 써야 한다.

버그관리시스템을 여러개 쓰고 있다면?

 
버그관리시스템은 개발자들만 쓰는 것이 아니다. CEO를 비롯해서 전직원 모두가 쓰는 시스템이다.
그런데 각 팀마다 서로 다른 시스템을 쓰고 있는 경우라면 십중팔구 개발자나 QA팀만 쓰고 있는 경우이다. 전사적으로 통일된 결정이 없었고 회사의 지원이 없어서 개발자들이 팀내에서 알아서 결정해서 쓰는 경우가 많다. 이는 반쪽만 사용하고 있는 경우이다.

버그관리시스템은 개발을 포함해서 회사의 거의 모든 이슈가 관리되는 곳이다. 기껏해야 회계나 HR이슈들이 빠질 뿐이다. 그런데 팀마다 다른 시스템을 쓰고 있다면 이슈가 통합되서 관리도 안되고 통계도 안나오고 개발팀 바깥의 부서에서는 여러 시스템을 모두 써야 하는 불편함도 있다.

또한 여러 시스템을 다 배워야 하기 때문에 이만저만 불편한 것이 아니다. 이또한 나중에 통합은 어려우므로 처음에 하나로 잘 결정해야 한다.

SVN과 Git를 같이 쓰는 경우는?

 
종종 SVN을 쓰면서도 출장을 자주 나가서 출장지에서 직접 개발을 해야 하는 경우들도 있다. 이런 경우 SVN과 Git를 연동해서 쓰면 유용하다.

SVN만 사용하면 출장을 나가서 1주일동안 여러가지 기능과 버그를 수정했을 경우 복귀후 Commit을 하게 되면 그동안 수정한 내용이 한번에 커밋이 되서 관리가 어려워진다.

이때 SVN Repository를 Git에 담아서 출장을 가서 개발할 때마다 여러번 Commit을 하면 복귀후 SVN과 다시 통합을 하면 그 History가 고스란히 합쳐진다.

이런 경우 처럼 Git를 보조적으로 쓰는 것도 좋다.

다른 시스템은 쓸 필요가 없나?

 
나는 보통의 SW회사에서 소스코드관리시스템과 버그관리시스템 2개면 충분하다고 주장한다. 사실 왠만큼 회사가 커지기 전까지는 이 두가지면 충분하다. 

결재가 필요하기 때문에 전자결재를 위한 그룹웨어를 도입하고 싶어하기도 한다. 하지만 소프트웨어 회사에서 그룹웨어는 그렇게 효율적이지 않다. 전자결재는 SW개발 문화와는 잘 어울리지 않는다. 이 내용은 나중에 자세히 글을 따로 써야 할 것 같다.

그 외에 작업관리, 고객요청관리, 테스트 관리등 여러가지 관리의 필요성을 느끼게 된다. 
일단 이 두개만 가지고 쓸 수 있는 한 최대한 써보기를 권한다. 그러면 의외로 거의 모든 것을 다 커버하게 된다는 것을 알게 될 것이다.

그후에 회사의 규모가 정말로 커져서 인원이 몇백명이 되고 좀더 관리를 잘 하고 싶으면 테스트관리나 서비스데스크등 개발자들에게는 부담이 안되지만 관리에 도움이 되는 시스템을 우선적으로 도입하면 좋다.

결론

 
나중에 통합은 어렵다. 이미 여러개의 시스템을 쓰고 있다면 합칠 수 있다면 지금이라도 합치는 것이 좋다. 나중에는 늦는다.