2017년 9월 19일 화요일

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

우리나라 회사에서 후배를 키우는 가장 흔한 방법은 '사수 부사수 시스템'이다필자도 오래 전부터 사수 부사수 시스템을 많이 봐왔고지금도 매우 일반적인 방식이다.
이 용어는 군대에서 유래했다. M60 기관총 등 중화기들은 대부분 2명 이상이 운용해야 하고 사수와 부사수가 같이 장비를 다룬다영화 속 람보는 M60 기관총을 혼자서 양손에 하나씩 두개를 들고 쐈지만원래는 2명이 쏴야 하는 무기다.
이런 사수 부사수 시스템에서는 사수는 주업무를 하고 부사수가 보조 업무를 하며 업무를 익힌다. 1, 2년 후에는 부사수가 사수가 되어 또 다시 부사수를 교육하는 시스템이다.
소프트웨어 회사에서도 비슷한 시스템을 가지고 있는 경우가 많다공식적이든 비공식적이든 사수 부사수 시스템을 가지고 있는 소프트웨어 회사에서는 신입개발자가 들어오면 회사에서 사수를 지정해준다사수 옆자리나 근처에 자리를 배정하여 사수와 많은 시간을 보내면서 하나씩 업무를 배워나갈 수 있도록 한다사수는 부사수에게 개발하고 있는 소프트웨어의 구조부터 기능소스코드빌드 방법업무지식회사의 시스템 사용법 등 많은 것을 가르쳐준다.

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

● 사수, 즉 선배가 후배 교육에 너무 많은 시간을 소비해야 한다후배 교육은 회사 입장에서 투자이기도 하지만 큰 비용이다선배는 오랜 기간동안 지속적으로 시간을 빼앗긴다. 후배 교육은 꼭 필요하지만 문제는 시간이 많이 들어간다는 것이다.

● 후배가 제대로 일을 하기까지 교육을 하는데 시간이 너무 많이 걸려서 현장 투입이 늦어진다회사마다 개인마다 다르기는 하지만 작게는 몇주부터 몇달이 걸리곤 한다부사수는 교육과 훈련을 어느 정도 받기 전까지는 제대로 일을 하기 힘들다.
이때까지는 한사람의 개발자가 들어온 것이 아니고 0.5 또는 0.3 인원이기도 하고심지어는 사수의 시간을 너무 많이 빼앗어서 마이너스 인력이 경우도 있다후배가 없을 때보다 전체 개발 기간을 더 지연시키기도 한다.

● 후배가 들어올 때마다 매번 반복적으로 가르쳐야 한다부사수가 다시 사수가 되어 후배를 가르치려면 상당한 시간이 걸리기 때문에 여전히 고참 개발자가 교육을 계속 해야 하고 시간 간격을 두고 5명의 개발자가 입사를 하면 교육 시간이 5배 들어간다.
● 사수도 많은 정보를 잊어버려서 제대로 교육을 하기가 쉽지 않다사수는 핵심 개발도 하고 교육도 하느라고 바빠서개발을 하면서 문서를 제대로 작성할 시간도 없다그래서 악순환이 반복된다아무리 후배를 교육해도 결국 모든 문제 해결 요청은 고참에게 몰려서 고참은 여전히 더 바쁘다.
● 부사수는 너무 자주 물어보면 사수의 시간을 빼앗는 것 같아 미안해서 잘 물어보지 않게 된다뻔뻔한 후배는 궁금한 것이 있을 때마다 잘 물어보겠지만사수가 얼마나 바쁜지를 매일 보게 되면 사수의 시간을 빼앗는 것을 미안해하곤 한다그래서 일을 그르쳐 문제를 만들고 나중에는 사수의 시간을 더 빼앗곤 한다.

■ 사수-부사수 한계 극복하려면 개발때 분석-설계 제대로 해야
경영자는 그동안 문서가 너무 없어서 이런 일이 벌어진다고 생각하고 기존 소프트웨어의 문서를 만들라고 하는데 이미 개발된 시스템의 문서를 나중에 많는 것은 헛수고다문서는 원래 개발 전에 만들어야 제대로 만들 수 있다개발 후 만드는 문서는 필요한 정보의 10%나 제대로 적을 수 있을까 의문이다.
또한제대로 분석설계를 하지 않고 이미 만들어진 소프트웨어는 시간을 아무리 많이 준다고 하더라도 다시 문서로 정리하기 어려운 구조로 되어 있는 경우가 많다그래서 악순환이 계속되고 사수 부사수 시스템에서 영원히 벗어나기 어렵게 된다.
이런 사수 부사수 시스템을 계속 유지하는 한 기업은 현재 수준에서 벗어나기 어렵다회사를 조금만 키워도 개발 효율성은 점점 떨어져서경쟁력 저하를 가져온다사수 부사수 시스템을 유지하는 회사에서의 후배에게 정보를 전달하는 방법의 비율을 보면 다음과 같다.
문서/시스템 : 직접 교육/코칭 = 2:8 또는 1:9
문서나 시스템을 통해서는 10~20% 정도의 정보밖에 전달을 못하고 나머지는 사수가 직접 가르쳐야 한다이상적인 비율은 반대가 되어야 한다, 8:2 정도가 되는 것이 좋다.
대부분의 정보는 문서나 시스템을 통해서 얻어야 하고문서를 봐도 잘 모르겠는 정보는 멘토나 선배에게 물어보는 것이 좋다이것을 10:0 또는 9:1로 만드는 것은 거의 불가능하다오히려 더 비효율적이다.


8:2 정도만 되면 위에서 언급한 문제점의 대부분이 해결된다고참 개발자의 시간을 너무 많이 빼앗지 않게 되고신규 입사자가 아무리 못해도 마이너스 인력이 되지는 않는다스스로 공부를 할 수 있으니 후배의 노력에 따라서 얼마든지 빨리 배울 수도 있다또한 입사 후 실전 개발에 투입되는 시간은 훨씬 빨라진다.
그럼 사수 부사수 시스템을 탈피하는 방법은 무엇일까분석설계를 제대로 해서 개발을 하는 것이다말은 참 쉽다하지만 실제는 정말 어렵다물론 이슈관리시스템이나 위키시스템 등 소프트웨어 회사에 필수적으로 필요한 시스템은 잘 구축되어 있어야 한다.
분석설계 문서는 SW를 개발하는데도 필요하면 이 문서들은 나중에서 신입 사원을 교육시키는데도 매우 유용하다이런 체계를 갖춘 회사에서는 신입개발자가 입사를 해도 바로 개발에 투입이 가능하다물론 개발 능력을 갖춘 신입개발자여야 한다개발 능력 자체가 부족하다면 얘기가 안된다한사람 몫을 하려면 상당히 시간이 걸리기는 하겠지만 고참을 그렇게 많이 방해하지는 않는다궁금한 것이 있으면 문서나 시스템을 통해서 스스로 배울 수도 있고설계가 잘 된 시스템에서는 개발을 할 때 알아야 할
정보의 범위가 작다자신이 개발해야 할 시스템의 인터페이스와 요구사항만 알면 된다.
대부분의 외부 인터페이스가 잘 정의 되어 있고유닛 테스트는 이미 작성이 되어 있는 경우도 많다신입 개발자에게 시스템 내부의 하위 설계는 직접 맡기는 경우도 있다또는 고참 개발자가 내부 설계까지 해주고 내용만 채우도록 하는 경우도 있다시스템이 작은 서브시스템으로 잘 나눠져 있기 때문에 신입 개발자라도 개발에 참여하기 쉽고 문제가 생겨도 전체 시스템에 큰 영향을 주지는 않는다.
물론 이렇게 하려면 분석설계를 매우 잘해야 한다모든 회사가 성숙도와 역량이 달라서 회사마다 벌어지는 현상은 다르다필자는 상당한 성숙도를 가진 회사를 기준으로 설명을 하고 있다이우소프트도 그러한 방향을 향해 발전해 가고 있는 진행형이다.
아직 제대로 된 시스템도 구축이 안되어 있고 분석설계 문서도 제대로 쓴적이 없는 회사라면 어떻게 할까?한번에 극복할 수는 없다새로운 제품부터 분석설계를 하나씩 제대로 하는 습관을 들여야 한다방법론과는 상관이 없이 분석설계를 적절히 제대로 하는 것은 소프트웨어 개발의 기본이다이렇게 하나씩 제대로 해나가면 지식정보가 축적되고 점차 사수 부사수 시스템에서 벗어날 수 있을 것이다.

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

2017년 9월 5일 화요일

나쁜 회의가 회사를 망친다

나쁜 회의 문화가 회사를 망친다.
잦은 회의와 장시간 회의 때문에 일 할 시간이 없다고 하소연하는 사람이 많다. 특히, 고참 개발자들에게는 그 폐해가 더 크다. 개발과 회의는 두뇌의 모드가 완전히 달라서 섞어서 하게 되면 개발 효율이 나지 않고, 많은 회의에 끌려 다니다 보면 어느새 개발자로서의 정체성을 잃어버리게 된다. 이런 시간이 지속되면 개발자의 경력에서 벗어나 돌아올 수 없는 어정쩡한 관리자의 길을 걷게 된다.
그럼, 우리 주변에서 흔히 볼 수 있는 회의의 나쁜 증상들을 살펴보자.
“여러분, 회의 좀 합시다.”
상급자의 요구에 의해서 수시로 소집되는 회의 유형이다. 갑자기 소집을 하기 때문에 주제와 내용이 회의 참석자들에게 충분히 공유되지 않고, 참석자들은 각자의 업무 계획이 있었는데 갑작스런 회의 때문에 일정도 틀어지고, 부족한 준비로 회의 진행도 부실하게 된다.
“직급이 깡패.” 회의를 하면서 서로 합리적으로 논의하여 결정을 못하고 상명하복식으로 무조건 윗사람이 결정하는 회의 유형이다. “편하게 얘기들 해보세요”라고는 하지만 편하게 얘기할 수 없고 결국에는 윗사람이 독단적으로 결정한 것을 통보하는 회의가 되곤한다.
“그럼, 네가 한번 해봐." 아이디어를 꺼내면 얘기를 꺼낸 사람이 일을 떠맡는 유형. 그러다 보니 해야할 얘기나 아이디어가 있어도 쉽사리 얘기를 꺼내지 못하게 된다.
“설명 좀 해 줘봐.” 상급자가 모르는 내용이 있거나 업무를 파악하기 위해서 실무자나 팀장들을 소집해서 브리핑을 받는 회의 유형. 업무 내용파악을 위해 수시로 실무자들을 불러서 시간을 낭비한다.
“언제 끝날지 모르는 마라톤 회의.” 어려운 주제를 일단 회의시간에 만나서 끝장을 보려고 진행하는 회의 유형. 사전 의논이나 조율없이 달랑 회의에 참석해서 난상토론을 하면서 몇시간을 훌쩍 넘기는 회의. 그렇게 장시간 회의를 하고 결론을 짓지 못하고 다음에 결정하자고 하기도 한다.
“회의는 회의.” 회의에서 나온 결론이나 업무들이 추적이 안되는 유형, 회의는 열심히 하는데 그 뒤에 어떻게 처리가 되는지 추적이 잘 안되는 경우가 많다. 이를 확인하기 위해서 다시 회의를 소집하기도 한다. 또한, 회의에서 결정된 사항들이 제대로 기록되고 관리가 안돼서 나중에 회의 참석자들끼리 회의 내용에 대해서 다툼을 하기도 한다.
이외에도 비효율적인 회의 유형은 다 나열 할 수 없을 만큼 많다. 많은 회사에서 중간 관리자, 고참 개발자들은 회의에 불려다니느라고 낮에는 일을 못하고 어쩔 수 없이 밤에 일을 하고 있다. 그러다 보면 고참 개발자들은 개발할 시간이 점점 부족해져서 결국에는 개발과는 멀어지게 된다. 회사 입장서는 중요한 개발 자원을 잃게 되는 것이다.
이우소프트에서는 5,6년에 걸쳐서 회의 문화 개선을 위해서 노력을 해왔고, 이제는 어느 정도 정착이 되어가고 있다. 이를 몇가지만 간단히 소개하려고 한다.
■ 가능하면 짧게…최소 24시간 전에 아젠다 공지
첫째, 가급적 회의는 하지 않는다.
회의의 관행을 바꾸는 가장 중요한 요소다. 불필요하거나 다른 것으로 대체 가능한 회의는 최대한 줄여야 한다. 회의의 비용은 상상 이상으로 엄청나다. 회의를 하면서 소모하는 비용도 크지만, 기회 비용은 그보다 더 크다. 무조건 회의는 1/10로 줄인다는 생각으로 시작하자. 진행하는 일을 모두 온라인 시스템으로 공유하면, 회의는 획기적으로 줄일 수 있다. 정보 공유, 업무 진행상황 확인, 업무 지시 등과 관련된 거의 모든 회의는 할 필요가 없고 온라인 시스템을 통하면 된다. 꼭 필요할 때만 회의를 통해서 논의를 하면 회의를 최소화할 수 있다.
둘째, 최소 24시간 전에 상세한 Agenda와 함께 회의를 초청한다.
그래도 회의를 하는 것이 효율적일 때는 미리 회의를 초청한다. 이때 상세한 Agenda를 공유하고 발표자료나 참고자료는 미리 같이 배포를 해서 참석자들이 완전히 숙지를 하고 들어올 수 있게 한다. 덜렁덜렁 내용도 모르고 회의에 참석하는 것은 금기다. 회의 시간에 자료를 발표하거나 낭독하는 것은 시간 낭비다. 이렇게 하면 회의 때문에 업무에 지장을 초래하는 일이 줄어들고 회의 시간도 짧아진다.
피치 못하게 급작스럽게 소집되는 회의도 시스템을 통해서 Agenda와 회의 자료를 등록 후 회의를 소집한다.
셋째, 회의시간은 가능하면 짧게 한다.
보통 30분을 넘기지 않도록 하고 길어야 1시간을 넘기지 않도록 한다. 그러기 위해서 회의 참석자들은 회의 주제와 내용을 사전에 모두 파악하고 빠른 결론을 내기 위해서 노력을 한다. 모두 회의에 집중해야 하며, 중간에 전화를 받거나 잠깐 나갔다 오는 행동은 금지되어 있다.
넷째, 회의록은 실시간으로 작성한다.
가급적 회의록은 회의를 하면서 동시에 작성한다. 작성되고 있는 회의록은 회의 참석자 모두가 볼 수 있게 해서 즉석에서 수정하도록 한다. 또한 회의록에는 2가지가 꼭 적힌다. 결정사항과 “Action Items”다. 회의에서 어떠한 결론을 냈는지는 별도의 항목에 정리를 하고 회의 이후에 해야 할 일들은 “Action Items”로 따로 정리한다. 회의 참석자들은 실시간으로 내용을 확인해서 동의를 해야 한다. “Action Items”에는 꼭 담당자와 Due date를 지정한다. 회의 후에 바로 이슈관리시스템에 Task를 생성해서 모든 관련자들이 실시간으로 “Action Items”의 진행을 추적할 수 있도록 한다.
다섯째, 회의록은 전직원에게 공유된다.
회의록은 회의 참석자 외에도 전직원에게 공유하는 것이 좋다. 회의록 공유는 성숙된 공유 문화의 중요한 요소다. 실시간으로 공유된 회의록에는 누구나 회의 내용에 질문을 하거나 의견을 줄 수가 있다. 또한 회의 내용이 모두에게 공유가 되면서 업무는 투명하게 진행이 된다. 정보는 독점을 할 때보다 공유를 할 때 더 큰 힘을 발휘한다. 이우소프트는 회의록을 위키시스템을 통해서 작성하고 있다. 따라서 모든 회의록은 손쉽게 검색이 가능하여 회의 내용에 대한 다툼이 없다. 해야 할 일은 이슈관리시스템과 연계돼서 회의와 관련된 모든 업무가 추적된다.
회의는 매우 중요하다. 잘하면 약이 되고 잘못하면 독이 된다. 회의 문화의 변화는 회의 이전에 정보 공유 시스템을 통한 공유 문화가 우선되어야 한다. 그래야 회의가 줄어들면서 회의 문화가 개선되기 시작한다.

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