사업부의 한계

우리나라 많은 기업들이 선택하고 있는 사업부제는 단기적인 성과를 내기에는 유리하나 장기적인 관점으로 보면 문제가 많다.

물론 사업부제 자체의 문제를 말하는 것은 아니다. 우리나라에서 사업부가 어떻게 동작하는지를 보면 된다. 

사업부는 사업부내에 모든 기능 조직을 포함하여 마치 하나의 회사처럼 동작을 하며 모든 전략, 매출 등을 책임지고 물론 그 성과에 대한 보상도 사업부가 누리는 것이다.

얼핏 들으면 아주 그럴듯 하지만 사업부의 이익과 회사의 이익이 상반되는 경우는 대단히 많다. 이런 경우 사업부에서는 회사 전체의 이익을 따르지 않는다.

그럼 소프트웨어 쪽으로 포커스를 해보자. 사업부제에서 소프트웨어 개발을 담당한 부서가 쪼개져서 각 사업부로 흩어지게 된다. 그러면서 전사적으로 소프트웨어 역량이 많이 떨어지게 된다.

• 전사적으로 일관된 소프트웨어 전략을 구사할 수 없다.
• 사업부간 소프트웨어 지식이 공유되지 않는다.
• 사업부간 인력의 왕래가 자유롭지 않다.
• 소프트웨어는 하드웨어의 부속물로 전락하는 경우가 많다. 특히 사업부의 장이 하드웨어 출신인경우이다.
• 단기적인 이익에 급급해서 소프트웨어 아키텍처는 크게 신경쓰지 못한다.
• 전사적인 큰 그림은 그리지 못한다.

이런 체제에서는 위에서 지시하면 뭘 빨리 만들어 내기는 하지만 흉내만 낼뿐 금방 밑천이 드러나게 된다.
사실 기업의 경영자들이 이러한 것을 모르는 것이 아니다. 그래서 기업의 조직 구조는 수시로 바뀌지만 인내심이 부족한 경영자들은 금방 다시 사업부제로 돌아온다. 그래도 그럴 것이 대기업의 최고 경영자들도 6개월, 1년안에 눈에 띄는 성과를 내지 못하면 자리를 보존하기 어려운 환경에서 그렇게 하기란 쉬운 일이 아니다.

많은 대기업들이 소프트웨어 역량을 향상하고 싶다면 소프트웨어 조직을 분리를 해야 한다. 사업부에서는 반대를 하겠지만 우선 가능한 부분부터 소프트웨어 조직을 통합하여 좀더 전문적이고 장기적인 관점으로 투자를 해야한다. 단기적인 성과에 집중하는 전략의 폐해는 이미 드러났다. 

이것이 변화가 가능한 중소, 중견 기업에 기대를 거는 이유이다. 

왜 소프트웨어에서 실패를 할까?

많은 회사들인 하드웨어보다는 소프트웨어에서 더 실패를 많이 한다. 사실 우리나라의 여러 산업분야에서 하드웨어는 이미 세계최고 수준에 이르렀다. 그런 회사들 조차 낙후된 소프트웨어 역량 때문에 경쟁력을 잃곤 한다.

그 이유는 무엇일까?

첫째, 하드웨어는 제대로 설계를 하면서도 소프트웨어 설계는 아예 없거나 엉성하기 그지 없다. 

소프트웨어는 인류가 만들어낸 모든 지식 산업 중에서 가장 복잡하다고 한다. 그럼에도 불구하고 우리나라에서는 소프트웨어 만큼 엉성하게 만드는 것도 없다. 
작은 집을 만들던, 빌딩을 만들던간에 설계 없이 만드는 것은 없다. 하다못해 작은 장난감도 잘 만들어진 설계가 필요하다. 그럼에도 소프트웨어는 설계없이 만드는 경우가 허다하다.

사실 하드웨어는 제대로 설계를 하지 않으면 아예 동작하지 않는다. 하지만 소프트웨어는 대단히 소프트하다는 착각에 대충 만들어서 통합이 안되거나 동작을 잘 안하면 조금씩 고쳐서 해결 할 수 있을 것으로 생각한다. 하지만 이는 대단한 착각이다. 하드웨어는 만들어 놓고 쓰다가 망가지면 버리면 되지만 소프트웨어는 한번 만들어 놓은 아키텍처가 생각보다 오래가고 나중에 발목을 잡게 된다.

또한, 하드웨어는 고객이 원하는대로 마음대로 변경해주지 않는다. 하지만 소프트웨어는 쉽게 바꿀 수 있다는 착각하에 고객마다 다른 제품을 만들어서 제공하는데, 이런 회사들은 대부분 미래에 유지보수를 감당하지 못하게 된다. 
공공 입찰의 경우 제대로된 스펙과 설계서를 요구하긴 하지만 대부분 페이지 수만 채운 형식적인 것이고 실제 개발에 제대로 쓰이지 않는다. 결국 개발자들이 머리 속으로 설계를 해서 개발하는 것이 일반적이다.

이렇게 해서는 당장 제대로 만드는 것을 떠나서 미래에 벌어지는 수많은 문제들을 점점 키우게 된다.

둘째, 소프트웨어는 완전히 다른 기업 문화를 요구한다.

하드웨어는 몇몇 천재가 기가막힌 물건을 만들어 낼 수 있다. 물론 하드웨어 분야도 수많은 사람들의 협업으로 돌아가지만 소프트웨어와는 사뭇 다르다.

소프트웨어 개발은 거의 모든 단계에서 대단한 협업이 필요하다. 또한 수평적인 조직 문화가 필요하다.

윗사람이 지시하고 이를 따르고 보고하고 통제하는 문화로는 절대로 소프트웨어를 제대로 개발할 수 없다.
자율적으로 판단하고 공유하고 리뷰하고 능동적으로 대처하는 문화가 필요하다. 관리자가 철저히 통제하고 관리하는 문화는 이를 저해하게 된다.

세째, 소프트웨어를 잘아는 경영자가 필요하다.

많은 사람들이 소프트웨어는 하드웨어를 동작하는데 도움을 주는 부수적인 부품으로 생각한다. 이런 하드웨어적인 마인드로는 소프트웨어를 절대로 잘 개발할 수 없다. 소프트웨어를 담당하고 있는 경영자라면 소프트웨어를 매우 잘 알고 제대로 된 소프트웨어 경험이 많아야 한다. 그래야 소프트웨어 전략을 수립할 수 있다. 

축구를 해본적도 없는 관중 수준의 사람에게 축구 감독을 맡길 수는 없다. 

안타까운 것은 우리나라는 소프트웨어 분야에 있어서는 너무나 갈길이 멀다는 것이다.
다행인 것은 많은 사람들이 소프트웨어에 관심을 가지기 시작했다는 것이다. 냄비처럼 확 끓었다가 식는 것이 반복하지만 않았으면 좋겠다.

삼성이 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개발 문화와는 잘 어울리지 않는다. 이 내용은 나중에 자세히 글을 따로 써야 할 것 같다.

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

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

결론

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

우리나라 소프트웨어 회사에는 ???이 없다.

우리나라 소프트웨어 회사에는 없는 것이 참 많다.

물론 있는 것도 많다. 머리 좋고 충성심 높은 개발자도 있고, 기반시스템도 갖추고 있는 경우도 종종 있다. 또한 뛰어난 요소기술을 갖추고 있는 경우도 많다.

프로세스와 시스템은 갖추려고 상당히 노력을 하고 있어서 효과를 보는 경우도 간혹 있지만 이 또한 거의 대부분 수박 겉핧기 식에 머무른다. 아주 초보적인 기능만 쓰거나 잘못 사용하는 경우가 많다. 

하지만 대부분의 회사가 거의 갖추고 있지 못한 것들이 있다. 이런 것들을 넘지 못하면 글로벌 소프트웨어 회사로 가는 길은 멀게만 느껴진다.

1. 개발문화가 없다.

소프트웨어 개발을 정해진 프로세스대로 딱딱 진행해서 잘되면 참 좋겠다. 하지만 절대로 그렇게 되지 않는다. 물론 프로세스를 따르지만 프로세스에 모든 것을 다 담을 수는 없다. 모든 절차를 프로세스화 하면 오히려 효율이 떨어진다. 아니 개발을 거의 못할 것이다. 

프로세스는 최소화하고 나머지는 개발 문화로 커버를 하는 것이다. 

개발문화 중에서 가장 중요한 것은 공유와 협업의 문화이다. 물론 많은 개발자들이 공유와 협업을 하고 있다고 생각할지도 모르겠다. 하지만 그 수준에서는 정말 많은 차이가 난다. 

또한 회사내에서 정말 자리잡기 어려운 문화이다. 개발자들 하나하나가 습관을 바꿔야 하는 어려운 난관이 가로막고 있다. 처음에는 강제화를 해야 하는데 무엇을 강제화 해야 하는 지가 문제이다.

공유와 협업 관련된 키워드를 몇가지를 들면 다음과 같은 것들이 있다.

SRS review, SRS sign, Architecture review, Code review, Coding convension, Doxygen, Component, Interface, Wiki, Bug track, Engineering Onepager, Broken tree, Common library

공유와 협업의 문화가 자리를 잡으면 위에 언급한 모든 것들이 확연하게 바뀌게 된다. 하나하나가 엄청난 항목이므로 자세한 설명은 생략한다.

2. 개발자들의 롤모델이 없다.

 

소프트웨어 개발자들은 3,4년만 지나도 위가 잘 안 보인다. 개발자로서 계속 일을 할 수 있을지 확신이 안 선다. 개발을 계속 하고 싶기는 한데 20년이 지나도 개발을 계속 하고 있는 고참을 본 적이 없어서 그 모습이 잘 그려지지 않는다. 사실 아주 드물게 관리직을 포기하고 개발직에 머물고 있는 고참들이 있지만 그 모습이 그렇게 우러러 보이지 않는다.

그래서 개발자 10년에 관리는 전혀 안하고 개발에만 매진하는 개발자를 찾기는 매우 어렵다. 그렇게 관리와 개발 양다리에서 헤매다가 대부분은 관리로 넘어가던가 업계를 떠나게 된다.

하지만 소프트웨어 개발자라는 자리는 코딩만 놓고 보면 5년짜리 개발자나 20년짜리 개발자나 타이핑 속도가 별반 차이가 나지 않는다. 하지만 아키텍처나 회사의 전략을 바라보는 시각은 엄청난 차이가 난다. 하지만 우리나라에서는 그런 개발자를 키워내지 못하기 때문에 롤모델도 없고 개발자는 방황하고 하는 악순환이 계속되고 있다.

3. CTO가 없다. 

소프트웨어 회사의 꽃은 CTO다. 하지만 거의 모은 우리나라 소프트웨어 회사에는 CTO가 없다. 가끔 직함이 CTO인 경우는 있지만 거의 대부분 진짜 CTO는 아니다. 다른 일을 하는데 직함만 CTO인 경우이다.

CTO가 없다면 회사의 중요한 기술적인 결정을 할 수 있는 최고 책임자가 없다는 뜻이다. 따라서 중요한 기술적인 결정이 영업적인 입장에서 결정되는 경우가 많아진다. 고참 개발자들이 가끔 저항을 해보기도 하지만 우리나라에서는 직급에서 눌리는 것을 극복하기는 쉽지 않다.

또한 CTO급이 아니라면 고참 개발자들의 시각도 최고 수준에는 못 미치기 때문에 제대로 결정을 못하고 설득력도 떨어지게 된다. 

소프트웨어 업계에서 20년 이상은 개발자로 꾸준히 제대로 성장해야 CTO급이라고 할 수 있는데 우리나라에는 그런 개발자가 거의 없는 것도 한 이유이다.

당분간은 좋은 CTO를 구하고 싶어도 쉽게 구하지 못할 것이다.

4. 마케팅이 없다.

 

대부분은 치밀한 계획보다는 번뜩이는 아이디어로 시작을 해서 초기에 성공을 거두었기 때문에 마케팅에 대해서는 거의 모르고 오로지 개발자들의 마법에 의존해서 소프트웨어를 개발하곤 한다. 

어느 정도 커지기 시작하면 마케팅에도 관심을 가져야 하는데 대부분의 소프트웨어 회사에는 개발과 영업만 존재하게 된다.

마케팅도 경험을 가진 마케팅 전문가가 부족하기 때문에 왠만한 대기업을 제외하고는 마케터를 구경하기 어렵다. 마케팅에 관심이 있는 회사 주먹구구 방법밖에 모르기 때문에 별효과를 못 보거나 개발자가 알아서 개발해 줄 때보다 못한 경우도 많다.

하나하나가 워낙 갈길이 멀고 무거운 주제들이라서 마음이 무겁지만 천천히 고쳐나가야 할 것들이다.

90%에서 끝나지 않는 프로젝트

Software 개발 프로젝트에서 일정이 늦어지는 경우는 흔하다. 초기 일정을 완벽하게 맞추어서 끝내는 프로젝트는 구경하기 힘들 정도이다.

그 중 대부분의 프로젝트는 90%까지는 진도가 착착 잘 나가는데 10%를 남기고 나서 일정이 계속 지연되곤 한다. 남은 10%를 끝내기 위해서 90% 끝내는데 걸리는 시간보다 더 오래 걸리는 프로젝트를 보는 것은 그리 쉬운 일이 아니다. 설령 일정에 밀려서 출시를 해도 버그가 많은 알파버전 수준의 제품을 출시해서 고객들의 원성을 사기 일쑤이다.

경영자는 매달 개발자들이 하는 다음달이면 끝난다는 얘기를 반복해서 듣게 된다.

이러한 상황을 개발자들은 그렇게 심각하게 보지 않는 경우가 많다. 하지만 비즈니스를 하는 사람은 이것이 비즈니스를 하는데 얼마나 심각한 문제가 되는지 잘 알고 있다.

소프트웨어 공학은 프로젝트 일정을 단축하고 계획대로 개발할 수 있도록 하기 위한 방법에 온 힘을 기울여 왔다. 소프트웨어 공학에서 다루는 거의 모든 분야는 일정 준수에 포커스를 하고 있다고 해도 과언이 아니다.

남은 10%의 일정이 그렇게 잘 안끝나는 주요 원인들은 다음과 같은 것들이 있다.

• 스펙을 충분히 제대로 작성하지 않았다. 단순한 요구사항을 가지고 개발자들이 알아서 개발을 한다.
• 설계가 허술해서 인터페이스가 자주 바뀐다. 통합이 잘 안되서 통합하는데 시간이 많이 소요된다.
• 상세 일정이 없이 큰 단위의 마일스톤만 가지고 있다. 일정관리는 거의 안한다.
• 리스크 관리는 해본적도 없다.
• 제품이 개발되기 전까지 스펙이 공유가 안되서 영업이나 경영층에서 프로젝트 막바지에 제품의 모습을 보고 요구사항을 계속 추가로 요청한다. 
• 프로젝트 일정에 테스트 일정을 충분히 고려하지 않았다. 테스트 케이스를 제대로 만들지 않고 테스트 인력이 부족해서 테스트 할 때마다 계속 새로운 버그가 발견되서 끝나지를 않는다.

개발 방법론이 라이프 사이클들은 여러가지가 있고 최근에 유행을 타는 것들도 있지만 결국에는 스펙을 상세히 제대로 작성하는 것이 근본적인 프로젝트 일정을 지키는 방법이다. 스펙을 제대로 작성하지 않고 여러가지 기법으로 해결할 수는 없다. 스펙을 작성하는 방법이 어찌되었든 스펙이 정확하고 상세해야 정교한 일정 예측 및 관리가 가능해지게 된다. 이런 경험이 점점 쌓이면 일정을 지키는 프로젝트가 점점 늘어 갈 것이다. 그러기 때문에 스펙을 잘쓰는데는 10~20년의 경험이 필요한 것이다.

대충 개발자들이 알아서 개발해주고 일정은 하늘(개발자인가?)에 맡기는 방법에 익숙해진 개발자들은 이런 정교한 일정관리에 거부감을 가질 수는 있으나 결국에는 일정을 지키는 방법이 개발자의 역량을 향상시키는 방법과도 일치하기 때문에 개발자 손에 달린 프로젝트가 개발자에게 파워를 가져다 준다는 생각은 버리는 것이 좋다.

프로젝트 일정은 10%가 남았다면 진짜로 10%만 더 지나면 끝나야 한다. 

이슈관리시스템을 쓰면서 일이 더 많아졌다.

이슈관리시스템을 쓰기 시작하면서 일이 오히려 더 많아졌다고 하소연하는 경우들이 많다.

이슈관리시스템을 쓰지 않다가 또는 전사적으로는 쓰지 않고 소수의 팀내에서만 쓰다가 이슈관리시스템을 전사적으로 제대로 쓰기 시작하면서  일이 더 많아졌다고 하곤 한다.

이것은 오히려 긍정적인 신호이다. 이슈관리시스템을 쓰지 않고는 회사내의 모든 이슈를 다 표면위로 드러낼 수도 없고 관리도 할 수 없다.

일이 많아졌다고 느끼는 것은 절대적인 일이 늘어난 것이 아니고 숨어 있던 이슈들이 모두 공유된 것 뿐이다. 이슈관리시스템이 없다면 잊혀지거나 개인이 알아서 챙기다가 유야무야되는 이슈들이 매우 많다. 이슈관리시스템은 모든 이슈들이 등록이 되고 개인의 의지에 따라서 해결이 되고 안되고가 결정이 되는 것이 아니고 전사적으로 공개적으로 처리가 된다. 물론 많은 이슈는 처리하지 않고 해결하는 것으로 종료된다.

이슈가 빠짐없이 처리되는 것은 물론 이슈를 처리하는 과정은 완전히 투명하게 공개가 된다.
억지주장을 해도 모두 알게 되고 요청을 무시하거나 늦장을 부려도 누구나 알 수 있다. 완전히 투명하게 업무가 진행된다. 투명한 업무처리를 싫어하는 사람들은 이를 꺼려할 수는 있지만 전사적으로는 대단히 큰 강점이 된다. 

따라서 이슈관리시스템에는 버그 뿐만 아니라 업무요청, 자료요청, 새로운 아이디어 등 온갖 이슈는 모두 등록하는 것이 좋다. 또한 이슈관리시스템을 사용하면서 전화로 구두로 요청하는 것은 거의 없애야 하면 이슈를 공유하고 논의하는 회의의 대부분은 사라져야 한다. 회의에 불려가는 시간도 줄어야 하며 전화나 구두로 요청하는 인터럽트도 많이 줄어야 한다. 이렇게 세이브된 시간은 쉬거나 좀더 창의적인 일을 하는데 쏟는 것이 좋겠다.

이슈관리시스템은 전사적으로 제대로 쓰는 것만으로도 회사의 개발문화에 많은 변화를 가져온다.