SW회사 ‘사수 부사수 시스템’의 문제점

우리나라 회사에서 후배를 키우는 가장 흔한 방법은 ‘사수 부사수 시스템’이다. 필자도 오래 전부터 사수 부사수 시스템을 많이 봐왔고, 지금도 매우 일반적인 방식이다.

이 용어는 군대에서 유래했다. M60 기관총 등 중화기들은 대부분 2명 이상이 운용해야 하고 사수와 부사수가 같이 장비를 다룬다. 영화 속 람보는 M60 기관총을 혼자서 양손에 하나씩 두개를 들고 쐈지만, 원래는 2명이 쏴야 하는 무기다.

​이런 사수 부사수 시스템에서는 사수는 주업무를 하고 부사수가 보조 업무를 하며 업무를 익힌다. 1, 2년 후에는 부사수가 사수가 되어 또 다시 부사수를 교육하는 시스템이다.

소프트웨어 회사에서도 비슷한 시스템을 가지고 있는 경우가 많다. 공식적이든 비공식적이든 사수 부사수 시스템을 가지고 있는 소프트웨어 회사에서는 신입개발자가 들어오면 회사에서 사수를 지정해준다. 사수 옆자리나 근처에 자리를 배정하여 사수와 많은 시간을 보내면서 하나씩 업무를 배워나갈 수 있도록 한다. 사수는 부사수에게 개발하고 있는 소프트웨어의 구조부터 기능, 소스코드, 빌드 방법, 업무지식, 회사의 시스템 사용법 등 많은 것을 가르쳐준다.

사수 부사수 시스템이 장점이 없는 것은 아니지만 많은 문제점을 가지고 있다. 어떤 문제를 가지고 있는지 알아보자. 정확하게는 사수 부사수의 문제라기 보다는 후배에게 지식을 전수할 준비가 안되어 있어서 주먹구구식으로 진행되는 사수 부사수 시스템의 문제이다. 

■ 사수-부사수 한계 극복하려면 개발때 분석-설계 제대로 해야

경영자는 그동안 문서가 너무 없어서 이런 일이 벌어진다고 생각하고 기존 소프트웨어의 문서를 만들라고 하는데 이미 개발된 시스템의 문서를 나중에 많는 것은 헛수고다. 문서는 원래 개발 전에 만들어야 제대로 만들 수 있다. 개발 후 만드는 문서는 필요한 정보의 10%나 제대로 적을 수 있을까 의문이다.

또한, 제대로 분석, 설계를 하지 않고 이미 만들어진 소프트웨어는 시간을 아무리 많이 준다고 하더라도 다시 문서로 정리하기 어려운 구조로 되어 있는 경우가 많다. 그래서 악순환이 계속되고 사수 부사수 시스템에서 영원히 벗어나기 어렵게 된다.

이런 사수 부사수 시스템을 계속 유지하는 한 기업은 현재 수준에서 벗어나기 어렵다. 회사를 조금만 키워도 개발 효율성은 점점 떨어져서, 경쟁력 저하를 가져온다. 사수 부사수 시스템을 유지하는 회사에서의 후배에게 정보를 전달하는 방법의 비율을 보면 다음과 같다.

문서/시스템 : 직접 교육/코칭 = 2:8 또는 1:9

즉, 문서나 시스템을 통해서는 10~20% 정도의 정보밖에 전달을 못하고 나머지는 사수가 직접 가르쳐야 한다. 이상적인 비율은 반대가 되어야 한다. 즉, 8:2 정도가 되는 것이 좋다.

대부분의 정보는 문서나 시스템을 통해서 얻어야 하고, 문서를 봐도 잘 모르겠는 정보는 멘토나 선배에게 물어보는 것이 좋다. 이것을 10:0 또는 9:1로 만드는 것은 거의 불가능하다. 오히려 더 비효율적이다.

8:2 정도만 되면 위에서 언급한 문제점의 대부분이 해결된다. 고참 개발자의 시간을 너무 많이 빼앗지 않게 되고, 신규 입사자가 아무리 못해도 마이너스 인력이 되지는 않는다. 스스로 공부를 할 수 있으니 후배의 노력에 따라서 얼마든지 빨리 배울 수도 있다. 또한 입사 후 실전 개발에 투입되는 시간은 훨씬 빨라진다.

그럼 사수 부사수 시스템을 탈피하는 방법은 무엇일까? 분석, 설계를 제대로 해서 개발을 하는 것이다. 말은 참 쉽다. 하지만 실제는 정말 어렵다. 물론 이슈관리시스템이나 위키시스템 등 소프트웨어 회사에 필수적으로 필요한 시스템은 잘 구축되어 있어야 한다.

분석, 설계 문서는 SW를 개발하는데도 필요하면 이 문서들은 나중에서 신입 사원을 교육시키는데도 매우 유용하다. 이런 체계를 갖춘 회사에서는 신입개발자가 입사를 해도 바로 개발에 투입이 가능하다. 물론 개발 능력을 갖춘 신입개발자여야 한다. 개발 능력 자체가 부족하다면 얘기가 안된다. 한사람 몫을 하려면 상당히 시간이 걸리기는 하겠지만 고참을 그렇게 많이 방해하지는 않는다. 궁금한 것이 있으면 문서나 시스템을 통해서 스스로 배울 수도 있고, 설계가 잘 된 시스템에서는 개발을 할 때 알아야 할

정보의 범위가 작다. 자신이 개발해야 할 시스템의 인터페이스와 요구사항만 알면 된다.

대부분의 외부 인터페이스가 잘 정의 되어 있고, 유닛 테스트는 이미 작성이 되어 있는 경우도 많다. 신입 개발자에게 시스템 내부의 하위 설계는 직접 맡기는 경우도 있다. 또는 고참 개발자가 내부 설계까지 해주고 내용만 채우도록 하는 경우도 있다. 시스템이 작은 서브시스템으로 잘 나눠져 있기 때문에 신입 개발자라도 개발에 참여하기 쉽고 문제가 생겨도 전체 시스템에 큰 영향을 주지는 않는다.​

물론 이렇게 하려면 분석, 설계를 매우 잘해야 한다. 모든 회사가 성숙도와 역량이 달라서 회사마다 벌어지는 현상은 다르다. 필자는 상당한 성숙도를 가진 회사를 기준으로 설명을 하고 있다. 

아직 제대로 된 시스템도 구축이 안되어 있고 분석, 설계 문서도 제대로 쓴적이 없는 회사라면 어떻게 할까?한번에 극복할 수는 없다. 새로운 제품부터 분석, 설계를 하나씩 제대로 하는 습관을 들여야 한다. 방법론과는 상관이 없이 분석, 설계를 적절히 제대로 하는 것은 소프트웨어 개발의 기본이다. 이렇게 하나씩 제대로 해나가면 지식정보가 축적되고 점차 사수 부사수 시스템에서 벗어날 수 있을 것이다.

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