왜 하나만 써야 하는가?

이전의 글에 종종 소스코드관리시스템과 버그관리시스템은 하나만 써야 한다고 얘기를 한 적이 있다.
또한 내가 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%만 더 지나면 끝나야 한다. 

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

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

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

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

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

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

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

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

주먹구구를 더 좋아 하는 이유

이론과 실제는 다르다. 

모두들 착하게 살아야 한다는 것을 알지만 많은 사람들이 착하게 살지 않고, 운동을 해야 하는 것을 알지만 대부분의 사람들은 운동을 하지 않는다. 이유는 다 있다.

착하게 살고 꾸준히 운동을 하는 사람들은 꾸준히 하다보니 특별한 목적보다도 그 자체가 좋아하고 자연스러운 행동이 된다. 

소프트웨어 회사도 주먹구구식으로 개발하면 안되고 체계적으로 개발해야 한다는 것을 이론적으로는 알아도 그 구성원들은 막상 체계적으로 변화를 하려고 하면 완전히 적응되기 전까지는 크고 작은 거부감과 저항이 있게 된다.

그래서 주먹구구로 회기하려는 힘이 강하게 작용하게 된다.

많은 회사들은 자신의 회사는 주먹구구가 아니라고 생각할 것이다. 물론 Black and White로 구분할 수는 없지만 나의 경험에 의하면 우리 나라 소프트웨어 회사의 90% 이상이 주먹구구에 가깝게 개발을 하고 있고 나머지의 대부분은 체계적인 개발을 하려고 노력하고 있으나 너무 과해서 더 효율성이 떨어지거나 회사에 알맞는 체계를 갖추고 있지 못하다. 정말 극소수의 몇개의 회사들이 효율성 높은 체계를 가지고 있고 문화적으로 자리를 잡고 있다.

여기서는 주먹구구에서 벗어나기 어려운 장애 요인은 무엇이 있나 알아보자. 시간이 흐르고 자리를 잡으면 별거 아닌 것들이지만 변화에 대한 거부감들은 의외로 매우 강한 경우가 많다.

주먹구구로 계속 개발을 하다보면 초창기에는 특공대처럼 놀랄만큼 좋은 성과를 내지만 인원이 많아지고 프로젝트의 규모가 커지면서 프로젝트는 점점 늦어지고 문서는 여전히 거의 없고 정보는 공유가 안되고 회사가 도대체 어떻게 굴러가고 있는지 잘 파악이 안된다. 제품이 버그는 점점 많아지면서 고객의 신뢰를 점점 잃어가는 위기를 겪게 된다.

이를 극복하기 위해서 소프트웨어 회사가 체계를 제대로 갖춰가면 
개발 프로세스를 정립하고 
프로젝트를 수행하면서 문서를 만들고 
조직을 전문화하고
기반 시스템을 구축하고
공유 등 개발 문화를 정착시키기 위해서 애쓴다.

단어적으로 보면 아무도 거부할 것이 없지만 실제로 많은 저항에 부딛히게 된다.
제대로 정착하면 장점으로 가득차 있지만 오로지 단기적인 시각으로 단점만 보면 다음과 같은 것들이 있다.

개발자

개별 개발자들이 과거에는 파워라고 생각했던 것들이 많이 줄어들게 된다.
과거에는 제품, 기술에 관련된 것들은 모두 개발자에게 물어 봐야 하고 개발자의 은총을 받아야만 일들이 진행이 되었다.
심지어는 프로젝트가 언제 끝나는지도 아무도 모르지만 개발자가 열심히 해서 끝내주기만 기다리곤 했다.
하지만 이제는 문서화를 통해서 제품의 스펙도 이미 다 공유가 되어 있고 개발자에게 물어볼 일들이 점점 줄어 들게 되었다. 개발자들은 이렇게 할 수 있도록 스펙(SRS)을 작성하는 일이 짜증나는 일이 됬다. 
나중에 마음에 내키는 대로 개발도 할 수 없게 된다.
과거에는 개발자에게 요청할 것이 있으면 직접 와서 부탁을 해야 했지만 이제는 시스템에 모두 등록이 되어서 개발자들이 이슈 처리를 잘하고 있는지 못하고 있는지 만천하에 드러나게 되었다.
소스코드를 수정한 것도 한줄한줄 완전히 투명하게 공개가 된다.
프로젝트를 진행할 때도 일정이 너무 상세하게 관리되어서 압박이 심하다.
개발자가 한두명이 퇴사를 해도 회사는 잘 굴러갈 것 같은 체계로 가고 있는 것들이 개발자는 불안해지고 파워를 점점 잃는 것을 거부하게 된다.

영업

과거에는 프로젝트를 할 때 별로 할 일이 없었다. 
개발자들이 SW를 만들어 주면 알아서 팔기만 하면 되었는데 이제는 스펙이라고 작성해와서 몇백페이지나 되는 문서를 꼼꼼히 읽어보고 사인을 하라고 한다. 그리고 나중에 잘못된 내용이 있으면 책임 지라고 한다.
개발이 힘들고 돌아다니는 것이 좋아서 영업을 하는데 공부는 개발자만큼 해야 하나보다.
고객의 요청도 개발자에게 가서 무조건 우기면 제품에 반영해주고 했는데 이슈관리시스템에 자세히 적어야 하고 내용이 만천하에 드러나므로 무조건 우길 수도 없게 되었다. 

경영진

옛날에는 내용을 파악하려면 담당자에게 와서 보고하라고 하면 되는데 이제는 시스템에서 확인해야 한다. 이게 더 좋다고 하지만 나는 영 불편하다.
프로젝트를 진행할 때 무조건 야근과 주말작업을 강요했는데 체계화 되면서 그러기 어려운 분위기가 되어가고 있다.

마케팅

옛날에는 제품 기능 목록 주욱 적어주면 개발자가 개발하고 이렇게 간단했는데 제품 기획을 제대로 하느라고 힘들다. 모든 내용이 문서화되고 시스템에 남기 때문에 나중에 딴 소리를 할 수 없다. 

결론

물론 모든 구성원이 이런 저항감을 가지는 것은 아니다. 변화의 필요성을 잘 알고 적극적으로 변화를 이끄는 많은 사람들이 있다. 이런 구성원이 많다면 회사는 계속 번창해 나갈 것이다. 회사의 분위기와 상황에 따라서 매우 다르다.

하지만 많은 회사들이 이런 이유들 때문에 많은 저항에 부딪혀서 적당한 정치적인 타협으로 기형적인 구조가 되어서 망하는 길로 들어서게 된다. 이러한 저항은 특이한 현상도 아니고 아주 자연스런 현상이다. 이러한 조직 구성원은 잘못된 생각을 가지고 있는 것이 아니고 인간의 자연스러운 본성에 가깝다. 따라서 이를 비난할 수는 없고 이들을 계속 이끄는 것은 회사의 책입니다.

이 고비를 넘어가면 회사의 모든 구성원들에게 그 혜택이 돌아가고 과거에는 어떻게 그렇게 일했는지 모르겠다고 회상하는 때가 온다. 그 중에서도 개발자에게 돌아가는 혜택이 가장 크다고 할 수 있다. 개발자에게 돌아가는 가장 큰 혜택의 개발자의 몸값을 높여준다는 것이다. 

나는 주먹구구 식으로 밖에 개발을 하지 못하는 개발자에게는 20년 이상의 경력이 있어도 연봉 5천도 아깝다. 하지만 체계적인 개발이 몸에 베어서 스펙도 잘 쓰고 설계도 잘하며 공유, 리뷰 문화에 익숙한 개발자는 연봉 1~2억도 아깝지 않다.

체계적으로 바꿔갈려면 감당할 만큼씩 단계적으로 변화를 해야 한다. 보통의 중소기업이 이렇게 단계적으로 변화를 하려면 2~3년 정도의 시간이 걸리고 대기업은 훨씬 더 오래 걸린다. 
또한 그 과정에서 뻔히 보이는 저항에는 굴복하지 말고 슬기롭게 헤쳐나가야 한다. 여기서 가장 중요한 것은 최고경영자의 통찰력과 의지이다. 그래서 최고경영자의 책임은 더욱 무겁다.

개헤엄은 아무리 잘 해도 개헤엄

나의 경험에 의하면 우리나라 소프트웨어 회사들의 대부분은 Global 경쟁력을 거의 갖추고 있지 못하며 여전히 국내에서만 좀 통하는 주먹구구식 개발 방법에 의존하고 있다.

이런 회사들은 자신들도 모르는 사이에 슬금슬금 그 한계가 다가오게 된다. 이미 한계를 넘어버리면 복구하기는 정말 어려워진다.

지금의 방법으로는 한계에 다다르고 있다는 징후는 다음과 같은 것들이 있다.

• 개발자 인원수는 과거보다 훨씬 많은데 개발 효율은 훨씬 떨어지고 프로젝트는 데드라인을 못 지킨다.
• 매출은 많이 늘었는데 순이익은 급격히 나빠지고 있다.
• 신입 개발자들을 계속 뽑고 있는데 실제 프로젝트에 도움이 잘 안된다. 밥값을 하려면 몇 개월씩 걸린다.
• 회사의 핵심 개발자들이 퇴사를 하고 있다.
• 신규 개발보다 유지보수에 비용이 점점 많이 들어가고 있다.
• 회사내에서 지식의 공유가 안되고 커뮤니케이션이 안되고 있다.
• 제품들의 버그가 과거보다 훨씬 많아지고 있는데 그 원인을 잘 모르겠다.  
• 개발자들의 전체적인 사기가 과거만 못하다. 옛날에는 인원은 적지만 모든 개발자들이 한마음으로 똘똘 뭉쳐있었다.
• 바쁜 개발자들은 항상 너무 바쁜데, 핑핑 노는 개발자들도 있는 것 같다. 하지만 누가 어떻게 놀고 있는지 잘 파악이 안된다.

이 중에서 2~3개라도 일치하면 한계에 다다르고 있다는 신호다.

소프트웨어 회사가 한계를 넘어가면 다음과 같은 길을 가게 되어 있다.

• 더욱더 밀어 붙이다가 그대로 망하는 길로 달려간다. 
• 상황이 악화됨에 따라서 구조조정으로 회사의 규모를 줄이고 목숨을 연명한다.
• 개발 방법에 변화를 시도한다. Global 경쟁력을 갖추려고 노력한다. 

대부분의 회사는 망하는 길로 치닫는다. 그래서 우리나라에는 성공한 SW회사가 손에 꼽을 만큼밖에 되지 않는다. 또한 Global 경쟁력을 갖추고 세계 시장을 호령하는 회사는 더욱더 찾아보기가 어렵다.

가장 좋은 방법은 한계에 다다르기 전에 회사를 변화시키는 것이다. 제대로 된 길로 가는 것은 빠르면 빠를수록 좋지만 아직 주먹구구식 개발을 하고 있다면 지금이 가장 빠른 시기이다.

하지만 변화는 어렵다.

"변화는 개를 두발로 걷게 하는 것과 같다."라는 말이 있다. 두발로 열심히 걷던 개도 잠시 눈을 돌리면 어느새 네발로 걷게 된다. 즉, 변화는 자꾸 과거로 회귀하려는 성질이 있다. 그래서 기업에서의 대부분의 변화는 실패로 끝나게 된다.

개헤엄은 개헤엄을 뿐이다. 

개헤엄은 아무리 숙달되고 능숙해져도 개헤엄일뿐이다. 절대로 자유형을 이길 수 없다.

변화가 어렵고 개발자들이 자꾸 과거로 돌아가고 싶어하더라도 과거로 돌아가서는 이미 성장해버린 회사는 더 이상 과거의 방법이 통하지 않는다. 개헤엄을 이길려면 새로운 자유형을 배워야 한다.

그래야 경쟁도 할 수 있고 살아남을 수 있다. 

Global 경쟁력을 갖추는 방법은 프로세스, 조직, 시스템, 문화를 체계를 갖추고 변화시켜 나가는 것이다. 변화에 성공해야 개발자와 회사 모두가 행복해진다.

스펙에 있어서는 안될 표현들

필자는 여러 개발자들이 작성해 놓은 스펙문서를 볼 기회가 많다. 대부분 99.9% 스펙이라고 하기에는 내용적으로 부족하고 리뷰도 부족한 문서들이지만 우선 각 문장을 하나씩 보다라도 고쳐할 부분이 매우 많다.

스펙(SRS)은 작성을 하고나면 이를 토대로 비즈니스도 하고 설계/구현도 하고 테스트팀은 테스트를 준비한다. 따라서 각 내용은 매우 정확하게 적어야 하며 두루뭉실하게 적으면 안된다. 하지만 정확한 표현을 하는 습관을 가지고 있지 않은 거의 대부분의 개발자들은 무심코 대충 작성을 하게 된다. 이는 수많은 오해를 유발해서 재작업과 품질 저하를 초래한다.

사실 원칙은 간단하다. 오해를 불러일으키지 않게 정확하게 작성해야 하고 범위를 구체적으로 명시해야 한다. 또한 정량적인 테스트가 가능하도록 설명해야 한다. 비즈니스 관련된 부분은 예외이다.

그럼 스펙을 작성할 때 피해야 할 표현들에는 어떤 것이 있나 알아보자.

SMTP를 지원해야 하다.
지원한다는 말은 대단히 모호한 표현이다.  지원해야 하는 범위를 아주 구체적으로 기술해야 한다.

1~5의 값을 가진다.
1,2,3,4,5인지? 1,3,5인지? 1~5의 float값인지? 그 정밀도와 가질 수 있는 값을 정확하게 기술해야 한다.

데이터를 효율적으로 저장해야 한다.
효율적이라는 표현은 모호한 단어로서 피해야 한다. 메모리나 CPU 자원 대비 효율적인지,  Storage 용량을 적게 차지해야 하는지, 성능이 중요한지 구체적으로 적어야 한다. 또한 정확하게 요구되는 수준을 수치로 표시하는 것이 좋다.

사과, 배, 복숭아 등등을 지원해야 한다.
등등은 사용해서는 안된다. 지원해야 하는 모든 항목을 다 나열해야 한다.

기존의 값과 동일하다.
기존이 무엇인지 구체적으로 명시를 하고 해당 문서가 있으면 Link를 걸어줘야 한다.

충분한 메모리를 할당해야 한다.
충분하다는 것이 정확하게 얼마인지를 명시해야 한다.

사용자에게 친숙한 화면을 제공해야 한다.
어떠한 사용자가 친숙함을 느끼기 위해서 제공해야 하는 정확한 요구를 구체적으로 설명해야 한다.

일반적인 조건을 모두 만족해야 한다.
일반적인 조건을 구체적으로 기술해야 한다. 또한 일반적이지 않은 상황에서 시스템이 어떻게 되는지도 설명이 되어야 한다.

필요한 경우 메모리를 추가로 할당한다.
필요한 경우를 정확하게 판단할 수 있는 조건을 구체적으로 설명해야 한다. 수치가 나오면 좋다.

이외에도 수많은 표현들이 있다. 개발자라면 적어도 개발문서에서 이런 표현들이 나오지 않도록 항상 조심하는 습관을 갖는 것이 좋겠다. 이것도 하루아침에 이뤄지지 않는다.