비대면 소프트웨어 개발에 가장 중요한 문서는?

 코로나19로 인해 전세계적으로 비대면 업무 방식이 확대되고 있고 소프트웨어 개발도 비대면 개발 방식이 크게 요구되고 있다. 비대면 업무 방식은 업무 효율성 증대와 생산성 향상에 기여를 하기 때문에 코로나19가 아니라도 도입이 필요하다.

글로벌 소프트웨어 회사인 깃랩은 코로나 이전에도 1300명 전직원이 재택근무를 했고, 구글이나 페이스북 같은 글로벌 소프트웨어 회사도 코로나19 이전부터 상당수의 직원이 풀타임 재택 근무를 수행했고, 현재는 재택 근무를 대대적으로 확대하고 있으며 앞으로 전면 재택 근무로 전환하겠다고 하는 회사도 많다. 이렇게 할 수 있는 이유는 이전부터 비대면 개발이 가능한 형태로 일을 해왔기 때문이다.

비대면 소프트웨어 개발을 위해서는 시스템, 프로세스, 문서, 문화 등 여러가지를 갖추고 있어야 한다. 이중에서 문서는 얘기를 해보려고 한다. 소프트웨어를 개발할 때 프로젝트에 따라서 다르지만 여러가지 문서를 작성한다. 이중에서 비대면 개발을 위해서 가장 필요한 문서는 무엇일까?

비대면 개발에 가장 중요한 문서는 스펙

필자가 생각하는 가장 중요한 문서는 “스펙”이다.

“스펙”은 비대면 개발을 위해서만 필요한 것이 아니고 소프트웨어 개발 전체에 가장 핵심적인 문서이다.

과거 80년대 전세계적인 소프트웨어 위기를 극복하기 위해 소프트웨어 공학이 급속히 발전하면서 소프트웨어 프로젝트 성공을 위해서 가장 중요한 요소로 “스펙”을 꼽았다.

2000년 이후 우리나라의 수많은 대기업들이 글로벌 회사로 성장하면서도 소프트웨어 개발의 문제를 겪으면서, 방법론, 프로세스, 고가의 툴 등을 도입하면서 문제를 해결하려고 했으나, 기대만큼 문제를 해결하지 못했고, 몇몇 회사들은 “스펙”의 중요성을 인식하고 “스펙” 작성 역량에 투자를 하고 있다.

많은 회사들이 소프트웨어를 개발할 때 대략의 요구사항을 가지고 개발자들이 밀접히 접촉하여 의논하면서 소프트웨어를 개발한다. “스펙” 문서를 주고, 자신이 담당한 부분을 나눠서 멀리 떨어진 장소에서 일할 수 있는 회사는 그렇게 많지 않다. 이유는 “스펙” 문서를 제대로 작성하지 못하기 때문이다.

애자일이나 스크럼 방식으로 개발을 하는 경우 과거처럼 “스펙” 문서는 필요 없다고도 하는데, 그렇지 않다. 방식만 다를 뿐이지 “스펙”은 필요하다.

다같이 모여서 개발을 한다면 수시로 의논하며, 조율하여 개발을 해나갈 수 있지만, 비대면 개발을 한다면 그렇게 할 수 없다. 자신이 개발할 부분이 명확하게 정의가 되어 있어야 서로 떨어져서 개발을 할 수 있다. 하지만 스펙 문서가 없이 개발하거나 대략의 요구사항을 가지고 서로 모여서 조율해가면서 개발하는 방식에 익숙한 대부분의 회사들은 비대면 개발을 할 수가 없다.

그럼 코로나 이전에도 1300명의 전직원이 재택근무를 하고 있는 깃랩이나, 수많은 직원이 집에서 일하고 있었던 구글이나 페이스북은 어떻게 진작에 비대면 개발을 광범위하게 수행하고 있었을까?

시스템, 프로세스, 문화, 문서 등 여러가지 요소가 있지만, 잘 작성한 스펙이 그중에서 중요한 역할을 한다. 코딩은 개발 단계에서 가장 많은 인원이 참여하는 단계다. 많은 개발자가 서로 떨어져서 일할 수 있도록 스펙을 잘 작성해서 공유하기 때문이다.

여기서 문제는 스펙을 잘 작성하는 것이 소프웨어 개발에서 가장 어려운 주제라는 것이다. 국내 많은 기업들이 소프트웨어 개발 역량을 글로벌 수준으로 끌어 올리는데 여전히 어려움을 겪고 있는 이유도 스펙 작성의 어려움이 한 요소로 작용하고 있다.

스펙 문서는 꼼꼼하게 모든 것을 방대하게 작성하는 것이 잘 작성하는 것도 아니고, 간단하게 작은 문서로 작성하는 것이 잘 작성하는 것도 아니다. 방대한 템플릿을 꼼꼼하게 채우는 것이 올바른 방법도 아니다.

스펙의 역할은 여러가지가 있지만, 개발자 관점에서는 스펙 문서를 보고 자신이 개발한 부분을 충분히 구현할 수 있을 정도가 되어야 한다.

잘 작성한 스펙 문서가 어떤 것인지는 칼럼에서 짧게 다룰 수 있는 주제는 아니다. 그래서 여기서 스펙 문서에 대해서는 구체적으로 자세히 설명하지는 않겠다.

거대한 방법론이나 소프트웨어 공학 이론에서도 소프트웨어 스펙을 작성하는 방법을 이론적으로 다루고 있고, 이를 따라하면 방대하고 복잡한 스펙을 작성해야 한다. 하지만 깃랩, 구글, 페이스북이 이런 방식을 따르고 있지 않다. 이론은 이론일뿐, 실전적인 방법으로 스펙을 작성하고 있다. 대부분의 회사는 이런 이론을 따라하다가는 백이면 백 실패한다.

스펙을 작성하는 방법은 피아노와 골프를 배우듯 실전적인 방법을 배워나가야 한다.

10배의 비용과 시간을 들여서 완벽하게 자세한 스펙문서를 작성할 수 있을지는 몰라도 대부분의 실제 프로젝트에서 그런 방법은 쓸모가 없다.

최소 비용으로 효과적으로 스펙을 작성하는 것이 실전적인 방법이다. 

스펙은 목적은 소프트웨어를 최단 시간, 최소 비용으로 개발하기 위한 것

소프트웨어 프로젝트에서 스펙을 잘 작성하는 목적은 소프트웨어를 최단 시간, 최소 비용으로 개발하기 위함이다.

그래서 거대 방법론에서 제안하는 수십가지의 문서를 작성하는 방법은 실전적인 프로젝트에서 효용성이 떨어진다. 많은 회사가 이 방법을 시도했다가 포기하거나 프로세스는 따르지만 정작 소프트웨어 문제를 해결하지 못한 상태가 계속 되곤 한다.

아직도 많은 회사들이 소프트웨어 개발에 문제를 가지고 있다. 대부분의 프로젝트는 계획된 일정에 끝내지 못한다. 그래서 계획된 사업 로드맵에 맞춰 제때 소프트웨어가 출시되지 못해서 많은 사업이 차질을 빚고 있다. 또한 출시된 소프트웨어는 여러가지 문제가 발생하고 유지보수에 어려움을 겪고 있다. 소프트웨어 회사의 사업을 영위하는데 큰 어려움을 주고 있는 것이다.

이러한 소프트웨어 문제를 해결하기 위해서는 소프트웨어 공학에서 언급하는 프로세스, 툴, 품질, 설계, 형상관리 등 여러가지가 다 필요하고 이러한 것들은 충분히 확보가 가능하다.

하지만 가장 근본적이고 어려운 “스펙"을 작성하는 역량을 확보하지만 않으면 넘을 수 없는 벽에 부딪히게 된다. 소프트웨어에 있어서 2류까지는 가능할지 몰라도 1류가 되기는 어렵다.

그래서 나는 기업들이 소프트웨어 문제를 해결하고 구글이나 페이스북과 같은 글로벌 수준의 소프트웨어 개발 역량을 확보하고 싶다면 개발자들이 스펙을 제대로 작성할 수 있는 역량을 확보할 수 있도록 해야 한다고 주장한다. 

스펙은 분석 아키텍트가 혼자서 스펙이라는 문서를 달랑 작성하면 되는 것이 아니다. 스펙을 제대로 작성한다는 것은 회사 전체가 같이 움직이는 것을 말한다. 모든 관련자가 요구사항을 충분히 수집에 협조하고, 여러 전문가가 참여를 하며 작성된 스펙 문서에 대해서 관련자들이 철저히 리뷰를 하고 변경관리도 제대로 해야 한다. 모든 직원들은 스펙 문서를 이해하고 읽고 이에 따라서 일할 수 있어야 하고, 개발자는 스펙 문서를 파악하고 떨어져서 개발을 할 수 있어야 한다. 이러한 관행을 갖추려면 많은 노력과 오랜 시간이 걸린다.

여기서 중요한 것은 방법론, 툴이 아니고 문화, 습관, 인식의 변화다. 또한 이런 것을 이끌려면 경영자의 강력한 의지도 중요하다. 몇년전 국내 S사에서 소프트웨어 역량의 근본적인 해결을 위해 내부에서 분석아키텍트를 양성하기 위한 노력을 시작했는데 이런 활동을 매우 긍정적으로 생각한다. 시간이 오래 걸리겠지만, 꾸준히 노력하면 글로벌 수준의 소프트웨어 역량을 갖추는데 중요한 발판이 될 것으로 생각한다.

대기업보다 움직이기 수월한 스타트업이나 중소기업은 노력여하에 따라서 스펙 작성 역량을 확보하기 더 용이하다. 소프트웨어 1류가 되고 싶다면 스펙에 관심을 가지고 스펙 역량을 확보해야 한다.

진짜 비대면 업무 방식 vs 가짜 비대면 업무 방식

 최근 코로나 19 때문에 비대면 업무 방식으로 전환이 강하게 요구되고 있다. 그러면서 비대면 업무 방식을 많이 추진하고 있는데, 가짜 비대면 업무를 하고 있는 회사도 많다.

비대면 업무 방식은 생산성이 높기 때문에 코로나 19가 아니더라도 도입이 권장된다. 그러면 진짜 비대면 방식으로 일하고 있는지, 가짜 비대면 방식으로 일하고 있는지 9가지 지표로 알아보자. 

툴, 시스템

재택근무를 도와주는 솔루션만 도입했다고 진짜 비대면 업무를 하는 것이 아니다. 

가짜 비대면 업무를 하는 회사는 몇 가지 특징이 있다. 완전한 비대면 업무 방식으로 일하기 위해서 필요한 시스템과 툴을 충분히 도입하지 않아서 여기 저기 구멍이 있는 경우다. 그래서 수시로 메신저나 이메일로 업무를 물어봐 가면서 처리하고 시스템을 따라 업무가 유기적으로 진행되지 않는다. 

또, 부서마다 사용하는 툴이 다른 경우도 있다. 진짜 비대면 업무를 하기 위해서 가장 중요한 시스템이 이슈 관리 시스템인데, 이것을 부서마다 다른 것을 쓰거나 일부 부서만 사용하는 경우다. 그러면 업무 협조 시 상황에 따라서 써야 하는 시스템이 달라서 매우 번거롭고 업무가 물 흐르듯 흐르지 않는다.

하지만 진짜 비대면 업무를 하는 회사는 필요한 시스템과 툴이 촘촘히 잘 구축되어 있고, 서로 연동이 잘 되어 있고, 모든 직원이 동일한 시스템을 쓰며, 내재화가 잘 되어 있다. 그래서 업무가 매끄럽게 흘러가고 한 두개의 대시보드에서 자신의 업무가 다 모니터링 되고, 관리자는 부서의 업무를 한눈에 파악할 수 있도록 되어 있다.

대부분 들어본 시스템과 툴이지만 전사적으로 제대로 구축하여 잘 쓰는 것은 매우 어렵다.

문서 관리

비대면 업무 방식을 주장하면서 문서를 개별 PC에서 작성해서 이메일이나 메신저로 서로 주고받으면서 공유하고, 관리를 하고 있다면 가짜 비대면 업무를 하고 있을 가능성이 높다.

또는 문서 공유 시스템을 쓰기는 하는데, 부서별로 서로 다른 시스템을 사용해서 타부서와 문서를 공유할 때는 이메일이나 메신저 등으로 파일을 전달하는 경우도 있다.

진짜 비대면 업무를 하려면 전사의 모든 문서를 하나의 문서 관리시스템에서 체계적으로 관리하고 있어야 한다. 물론 부서별 업무별로 권한 관리를 잘하여 보안 상으로도 문제가 없어야 한다.

문서의 작성, 협업, 리뷰, 관리, 공유 등 모든 작업이 하나의 시스템으로 관리가 되어야 효율적인 비대면 업무를 할 수 있다. 

문서 작성 역량

비대면 업무를 제대로 하기 위해서는 문서 작성 역량도 매우 중요하다.

문서를 많이 작성해야 한다는 의미는 아니다. 대면 업무 방식에서는 문서의 내용이 부족하면 수시로 옆에서 물어가며 일할 수 있지만 비대면 방식에서는 그렇게 하기 곤란하다.

기획 문서, 스펙 문서, 설계 문서 등 여러 종류의 문서들이 문서만 가지고 충분히 내용을 파악할 수 있어야 한다. 100%는 불가능하지만, 80~90% 문서로 충분히 내용을 전달할 수 있는 역량을 가지고 있어야 한다. 물론 이런 문서도 문서 관리시스템에서 협업과 리뷰를 통해서 만들어지므로 잘 작성될 가능성도 높아진다.

가짜 비대면 업무를 하는 회사는 문서를 가지고 일하기 어려워 일할 때 커뮤니케이션이 너무 많이 필요하다. 그래서 옆에 앉아서 같이 일하기를 원한다. 예를 들어 소프트웨어 회사에서 외주를 줄 때 스펙 문서를 기반으로 외주를 주지 못한다. 대략의 기획 문서를 기반으로 외주를 준 후에 요구대로 소프트웨어가 개발이 잘 안되니 옆에 끼고 설명을 해주거나 나중에 프로젝트 일정이나 품질에 문제가 생기는 것이 다반사다.

진짜 비대면 업무를 하기 위해서는 직원들이 모두 말보다는 문서 위주로 일하기 때문에 문서를 제대로 작성할 수 있는 역량이 필요하다. 그래서 채용 시 글을 잘 쓰는 사람을 뽑기도 하고, 직원들에게 글을 잘 쓰고 문서를 잘 작성하도록 교육할 필요가 있다.

물론, 비대면 업무를 계속 하면서 문서 작성을 계속 하고 리뷰를 거쳐 피드백을 많이 받게 되면 누구나 문서 작성 역량이 조금씩은 향상된다.

보고

진짜 비대면 업무를 하는 회사는 별도의 보고가 많이 줄어든다. 또한 보고를 위한 보고는 보기 어렵다.

별도의 보고가 따로 필요하지 않은 이유는 촘촘하게 커버되는 시스템에서 업무의 진행 상황을 훨씬 더 자세히 파악할 수 있기 때문이다.

직원들도 별도의 시간을 들여서 보고서를 작성하지 않고 본연의 업무에 더 많은 시간을 쏟을 수 있다. 

하지만, 가짜 비대면 업무를 하는 회사는 업무는 업무대로 다하고, 일일보고, 주간보고 등 여러 형태로 보고서를 작성해서 보고를 해야 한다. 보고 방식은 온라인이라 할지라도 낭비요소가 아닐 수 없다. 

관리자는 또 상위 관리자에게 보고를 하기 위해서 직원들의 보고를 취합하여 또 보고를 한다.

보고를 줄이는 것은 진짜 비대면 업무 방식의 증거이자 혜택이다.

화상 회의 빈도

가짜 비대면 업무를 하는 회사는 형식만 비대면이지, 수시로 화상 회의를 실시하여 대면 업무 방식과 별 차이 없이 일한다.

화상 회의는 실제 만나서 얘기하는 것보다는 전달성이 떨어지지만 이동하지 않고 커뮤니케이션을 할 수 있는 장점이 있는 것이다.

하지만 화상 회의를 너무 자주 한다면 차라리 모여서 일하는 것이 더 효율적이다.

회상 회의를 해야 하는 안건이 대부분 이슈 관리 시스템이나 여러 시스템에 온라인으로 등록되고 프로세스를 따라서 처리되며 화상 회의는 꼭 필요할 때 최소화해서 해야 한다. 그래야 진짜 비대면 업무 방식으로 일한다고 할 수 있다.

회상 회의도 비싼 수단이다. 하루의 10~20% 넘는 시간을 화상 회의에 사용하고 있다면 일단 의심을 해보자.

회의 결과 관리

가짜 비대면 업무를 하는 회사는 회의도 자주 하지만 회의 기록이 없거나 회의 결과 해야 할 업무의 추적이 잘 안된다.

그러고는 한참 있다가 “지난 번에 내가 시킨 일 어떻게 되고 있지?”하고 묻는다. 전형적인 대면 업무 방식과 다를 바가 없다.

회의를 자주하는 것과도 관련이 있다. 회의를 계획하에 하지 않고 수시로 소집하기 때문에 회의록도 제대로 남기지 않고 후속 관리도 잘 안된다.

진짜 비대면 업무를 하는 회사에서는 회의 빈도도 적을 뿐만 아니라, 필요한 회의는 미리 계획이 되어 있고 회의 결과가 제대로 정리, 공유되어 있다. 또한 회의 결과로 인해서 해야 할 일은 회사의 온라인 시스템에 등록되어 실시간으로 추적이 된다. 

회의록만 보아도 후속 업무의 처리 현황을 실시간으로 볼 수 있도록 시스템이 구축되어 있기도 하다.

예를 들어 소프트웨어 회사의 경우 유지보수를 위해서 소스코드를 볼 때 특정 소스코드의 한 줄만 보아도 해당 줄을 누가 언제 작성해서 관련된 요청은 언제 누가 했으며, 이와 관련된 회의는 언제 누가 진행했고, 결론은 어떻게 나왔는지 줄줄이 모두 몇번의 클릭으로 추적이 된다. 그래서 누가 와서 유지보수를 해도 소스코드의 역사를 훤히 볼 수가 있다.

메신저 사용

가짜 비대면 업무를 하는 회사는 메신저를 끼고 업무를 한다. 회상 회의까지는 아니지만, 수시로 여러 사람에게 메시지를 날리고 이거 저거를 물어본다. 회상 회의보다는 작지만 비용이 많이 들어가는 일이다. 답변을 하기 위해서는 하던 일을 중단해야 한다. 만약에 집중 업무를 하고 있던 경우라면 다시 집중하는데 필요한 시간까지 최소 30분은 그냥 날아간다. 이런 일이 한 두 건이면 모르겠지만, 메신저를 통해서 메시지가 여기저기서 수시로 쏟아지면, 정작 집중해서 본연의 업무를 할 시간이 부족하다.

메신저의 문제점 중 하나가 기록이 체계적으로 남지 않아서 회사의 정보 자산으로 축적되지 않는 다는 것이다. 

그래서 메신저는 정보 자산과 관련 업무를 위해서 가벼운 용도로만 최소화해서 사용해야 한다.

편리하다고 수시로 메시지를 날리는 것은 대면 업무 방식과 크게 다를 바가 없다. 

업무 만족도

가짜 비대면 업무를 하는 회사는 현재 회사에서 진행하는 비대면 업무 방식에 불만이 많다. 아무래도 과거 대면 방식보다 불편하고 업무 효율성이 떨어지기 때문이다. 원인은 여러가지가 있을 수 있다. 시스템이 충분히 구축되어 있지 않은 채로 강제로 몰아붙일 수도 있고, 역량은 안되는데 과도하게 시스템을 도입한 경우도 있다. 

직원들이 충분히 시스템에 적응하지 못한 경우도 있다.

진짜 비대면 업무를 하려면 추가로 시스템이 필요한지, 직원들의 문서 작성 역량 향상이 필요한지, 시스템 사용 교육이 더 필요한지 회사에 따라서 다를 것이다.

대면 업무 방식으로 오랫동안 일하던 회사가 하루 아침에 완전 비대면 방식으로 전환하기는 어렵다. 인식의 전화, 시스템 사용 적응, 문서 작성 역량 등 필요한 것이 한두개가 아니고 수년 걸리는 일도 있다. 전문가의 도움을 받아서 하나씩 하나씩 꾸준히 추진하는 수밖에 없다.

재택근무 가능 여부

가짜 비대면 업무를 하는 회사는 100% 재택 근무를 하지 못한다. 최근 뉴스에 100% 재택 근무를 하고 있는 미국의 많은 회사를 접한다. 1200명 전원이 회사 사무실 하나 없이 100% 재택 근무를 하는 깃랩도 있고, 구글, 페이스북도 100% 재택근무를 하는 직원이 꽤 많다.

하지만 가짜 비대면 업무를 하는 회사는 일주일에 1~3일 정도 재택근무를 하고 나머지는 회사에 나와서 일해야 한다. 또는 재택근무가 가능한 특수한 직군만 100% 재택 근무가 가능하다. 최근 코로나 때문에 이런 식으로 일부 재택근무를 하는 회사가 있다.

물론 재택근무가 100% 우월한 것은 아니다. 대면 업무 방식은 얼굴 보고 일하면서 팀워크가 증가하는 것도 있고, 생활 리듬에 안정을 주는 것도 있다. 하지만 여기서 얘기하는 것은 필요할 때 재택근무를 할 수 있냐는 것이다.

100% 재택근무가 가능해야 진짜 비대면 업무를 하고 있다고 볼 수 있다. 그런 역량을 가지고 모여서 일하는 것은 회사의 선택이다.

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

코로나19 시대에 비대면 소프트웨어 개발이 필수

코로나19가 우리의 일상을 바꾸고 일하는 방식도 변화 시키고 있다. 그러면서 여러 분야에서 직접 만나지 않고 일을 하는 비대면 방식으로의 업무 방식을 도입할 수 밖에서 없게 되었다.

이러한 비대면으로 일하는 방식은 소프트웨어 개발에 있어서 긍정적인 측면이 있다. 비대면 방식의 개발이 글로벌 수준의 소프트웨어 개발 방식과 일맥상통한다. 또한 비대면 방식은 소프트웨어 개발 비용의 감소와 효율적인 개발과도 맞닿아 있다. 그동안은 이런 비대면 방식의 개발이 많은 기업에서 도입이 어려웠다. 그동안 해오던 방식을 바꾸기 쉽지 않는 것이 한 이유인데, 이제는 필수적으로 비대면 방식을 도입해야 한다. 따라서 비대면 방식이 소프트웨어 개발에 어떠한 영향이 있는지 짚어보고자 한다.

그럼 소프트웨어를 비대면 방식으로 개발해야 하는 가장 큰 이유는 무엇일까?

개발 비용이 적게 들기 때문이다.

가장 큰 이유는 개발 비용이 적게 들기 때문이다. 믿기 어렵겠지만, 사실이다. 프로젝트가 점점 커지고, 복잡해지고, 유지보수까지 감안하면 그 비용의 차이는 점점 커진다. 

좀더 나아가 비대면 개발 방식을 재택 근무까지 확장하면 회사 입장에서는 거주지에 상관없이 개발자를 채용하는 이득이 있고, 꼭 하루 8시간 일하는 개발자를 채용할 필요도 없고, 개발자 채용이 훨씬 유연해진다. 또한 사무실 임대비용도 감소하여 많은 장점이 생긴다.

직원 입장에서도 개발 외의 시간을 덜 뺏기게 되어 업무 집중도가 높아지고, 감정 소모가 감소하는 장점이 있다. 전체적으로 개발 생산성도 향상된다. 하루 4시간 밖에 일하지 못하는 개발자에게도 취업의 기회가 생기고, 생활의 질도 올라갈 것이다. 

사회적으로는 회사들이 몰려있는 수도권의 집값도 떨어지는 효과도 생길 것이다. 회사, 직원, 사회 모두가 이익이 된다.

문제는 얼굴을 보지 않고 일을 할 수 있냐는 것이다. 게다가 일을 열심히 하고 있는지 믿을 수 있냐는 것이다.

이제부터 사례를 비교해보고 어떻게 해야 비대면 방식으로 소프트웨어를 개발할 수 있는지 알아보자.

먼저, 미국의 경우를 보자.

미국에서는 이미 약 20%의 개발자는 재택근무를 하고 있다.

미국에서는 이미 약 20%의 개발자는 재택근무를 하고 있다. 대부분의 회사에서 개발자로 입사를 하면 재택근무를 선택할 수 있는 옵션이 있다. 코로나19 이후 재택근무는 훨씬 더 증가하고 있다. 즉, 미국에서는 이미 비대면으로 개발하는 방식에 익숙해져 있고, 비대면 개발에 별 문제가 없다.

미국에는 비정규직 포함 1200명의 직원이 모두 재택근무를 하고 있는 소프트웨어 회사가 있다. 바로 GitLab이다. GitLab의 모든 프로세스는 온라인으로 진행할 수 있도록 되어 있고, 문서를 통해서 개발이 이루어진다. GitLab은 급속도로 성장하고 있다.

Facebook은 개발자가 입사한 첫날 버그를 고친다. 이렇게 고친 버그는 전세계 서비스 된다. 개발자가 입사를 하면 버그관리시스템에서 버그를 할당해주고, 개발자는 온라인으로 주어진 정보를 바탕으로 소스코드를 내려 받고, 수정 후, 온라인으로 코드리뷰를 받고 소스코드를 등록한다. 한 사무실에 있는 동료들의 얼굴을 볼 수 있지만, 얼굴을 보지 않아도 일하는 방식은 똑같다.

최근 실리콘밸리의 소프트웨어 회사들은 대대적인 재택근무를 선언하고 있다. Facebook은 향후 5~10년에 걸쳐 직원 절반이 영원히 원격근무를 할 것이라고 한다. 이로 인해서 실리콘밸리 집값도 떨어지고 있다고 한다.

하지만 국내의 회사들은 전면적인 재택근무는 엄두를 내지 못하고 있다. 특정 직군만 재택근무를 시행하거나 일주일에 며칠만 재택근무를 시도하곤 한다. 아예 비대면으로는 일을 하기 어려운 상황이다.

그럼 우리나라 회사의 사례를 살펴보자.

스펙 문서를 보고 개발자가 개발을 못한다.

A사는 공공 프로젝트를 위주로 사업하던 회사다. 공공 프로젝트에서 업무를 분석하는 것은 가장 중요한 일이다. 그래서 업무 분석가가 핵심이다. 업무 분석가가 소프트웨어 스펙을 작성해서 개발자에게 넘겨주면 문서를 보고 개발하는 것이 목표였지만, 실제는 업무 분석가가 개발 기간 내내 옆에서 기능을 설명해줘야 했다. 업무 분석가는 프로젝트가 끝날 때까지 프로젝트에 묶여서 다른 프로젝트를 수행할 수가 없다. 회사 입장에는 수주할 수 있는 프로젝트가 줄어 들기 때문에 손해가 아닐 수 없었다. 하지만, 몇 년을 노력해도 스펙 문서를 전달해서 개발자들이 스펙 문서를 보고 개발한다는 목표는 달성하지 못했다.

B사는 신입 개발자가 입사를 하면 사수를 정해주고 이거 저거 가르쳐줘야 하는 것이 많다. 신입개발자는 최소 한달은 되어서 실제 개발에 투입이 될 수 있다. 사수인 고참 개발자도 시간을 많이 빼앗기고, 신입개발자도 월급 값을 하려면 시간이 오래 걸린다. 개발자가 입사할 때마다 이런 일은 반복된다. 신입 개발자에게 문서를 전달해주고 알아서 개발을 하게 하고 싶지만, 고참 개발자는 이를 위해서 문서를 따로 만들 시간이 없다.

왜 대면 개발이 문제인가? 대면으로 밖에 개발을 못하면 진짜 문제인가?

대면 위주로 개발하면 초기에는 뭔가 더 효율적인 것 같지만, 효율은 점점 떨어진다. 시간이 흐를수록 더 많은 개발자가 필요하고 초기 개발자가 유지보수에 더 매달려야 하고, 업그레이드 할수록 개발 비용이 증가한다. 

비대면 개발은 시스템, 문서 위주로 개발이 진행되기 때문에 자연스럽게 기록이 남고 혼선이 줄어들며 유지보수 준비가 된다. 

위기가 곧 기회

일본의 수출규제가 우리 부품 산업이 자립도를 높였듯이 위기가 곧 기회가 될 수 있다. 어쩔 수 없이 바뀌어야 하겠지만, 한국인의 저력과 맞물려서 소프트웨어 개발 역량이 몇 단계 업그레이드 될지도 모른다. 그러기 위해서 방법을 알아야겠다.

비대면 소프트웨어 개발을 하기 위해서는 크게 3가지가 필요하다.

첫째, 비대면 개발을 위한 시스템, 툴이 준비되어야 한다.

작은 툴부터 시스템까지 10~20여가지의 시스템이 도입되어서 내재화되어야 한다. 많은 것 같지만 적응해서 사용하다 보면 하나하나 필수적인 것이고 이것들 없이는 개발을 못할 것 같은 생각이 들것이다. 여러 회사를 살펴본 필자의 경험에 의하면 비대면 개발 프로세스를 위한 시스템, 툴을 촘촘히 전부 도입하고 있는 회사는 드물다. 일부 시스템만 사용하고 있어서 프로세스 중간중간 비대면 프로세스가 끊어지는 경우가 많다. 필수 시스템 중 몇가지만 예로 들면 문서관리시스템, 지식관리시스템, 소스코드관리시스템, 이슈관리시스템, CI시스템, 코드리뷰시스템 등이다. 추후 하나씩 자세히 알아보려고 한다. 이렇게 비대면 프로세스가 끊어지면 지속적으로 비대면 개발을 할 수 없고, 중간중간 얼굴을 보고 일하지 않으면 안된다.

둘째, 문서작성 역량이다.

단순히 워드 문서 같은 것을 말하는 것은 아니다. 온라인 시스템을 사용하려면 모든 것을 다 적어야 한다. 말로 하는 커뮤니케이션보다 글로 적는 커뮤니케이션에 익숙해져야 하고, 문서를 통해서 의사를 전달하고 문서를 보고 개발할 수 있는 수준의 문서를 작성할 수 있어야 한다. 그렇다고 자세하게 적는 것이 능사는 아니다. 최소한으로 문서를 적는 것이 더 중요하다. 이런 역설적인 말을 이해해야 한다. 개발에 관련된 문서는 많다. 기획문서, 스펙문서, 백서, 설계문서, 테스트 관련 문서 등 여러 문서를 온라인 프로세스를 통해서 작성하고 리뷰하고 확정하고 변경 관리를 해야 한다. 

셋째, 개발 문화다.

그중 대표적인 것이 수평 문화다. 온라인으로 비대면 개발을 하면 업무가 수평적으로 진행된다. 프로젝트에서 자신의 역할이 존재할 뿐이고 수직 관계가 없어져야 한다. 그래야 제대로 개발이 된다. 온라인에서도 수직관계가 여전히 존재한다면 일이 잘 진행 안될 것이다. 각자 자신이 맡은 일을 전문적으로 처리하는 것이다. 연공서열, 장유유서, 상명하복 이런 것들이 점점 희박해지고, 전문성이 강조되는 문화로 바뀌어 나가야 한다. 얼굴 안보고 일하면 이런 문화가 바뀔 가능성이 더 높아진다.

코로나19는 우리에게만 닥친 것이 아니다. 전세계가 동일한 환경에 처했다. 전세계가 비대면 방식으로 업무를 바꾸고 있고, 우리가 조금이라도 더 빨리 적응해 나가야 한다. 승부는 2,3년 안에 나게 되었다. 여기서 뒤쳐지면 따라잡기 어렵다.

비대면 방식이 소프트웨어 개발은 이제 선택이 아니고 필수가 되어가고 있다. 오늘은 비대면 방식의 개발에 대해서 간단히 소개만 했는데, 앞으로 하나씩 자세히 소개를 할까 한다. 하루아침에 습득할 수 있는 것은 아니지만, 차근차근 알고 익혀 나가는 것이 가장 빠른 길 일 것이다. 

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

[Software Spec Series 8] 어떻게 소프트웨어를 빠르게 개발하는가?

소프트웨어는 빠르게 개발하는 것이 매우 중요하다. 소프트웨어 개발 기간이 오래 걸린다면 적절한 시장 진입 시기를 놓칠 수 있다. 소프트웨어 시장 변화는 매우 빨라서 너무 오래 개발을 하면 그동안 시장의 상황이 바뀐다. 경쟁자들은 새로운 제품을 출시하여 우리 회사에서 지금 개발하고 있는 제품이 뒤쳐지곤 한다. 또한 오랜 프로젝트는 개발자와 프로젝트 참여 인원들을 지치게 만든다. 이런 현상이 프로젝트를 더욱 더디게 한다. 프로젝트가 기간이 길어지면 그동안 새로운 요구사항이 추가될 가능성이 높다. 기획자는 변화하는 시장의 상황을 무시할 수가 없기 때문이다. 그래서 프로젝트는 더욱 늘어지고 품질은 떨어진다.

최근의 대부분의 개발 방법론들은 소프트웨어를 빠르게 개발하는 것을 중요시하고 있으며 회사에서도 소프트웨어를 빠르게 개발하기 위한 많은 노력을 들이고 있다. 그럼 어떻게 해야 소프트웨어를 빠르게 개발할 수 있을까? 소프트웨어를 빠르게 개발하기 위해서 고려해야 할 것은 매우 많지만, 여기서는 스펙 관점으로 살펴보려고 한다.

(느린 순차적 개발)

빌딩을 쌓을 때는 1층을 쌓고 2층을 쌓아야 한다. 1층을 쌓기 전에 2층을 쌓는 것은 불가능하다. 조립식 빌딩이라면 얘기가 다르지만 대부분의 빌딩은 순차적으로 쌓아 나간다. 소프트웨어도 이런 방식으로 순차적으로 개발을 해야 한다면 매우 오랜 시간이 걸릴 것이다. 거대한 소프트웨어는 수십년이 걸릴 수도 있다.

하지만 소프트웨어는 빌딩과 같이 1층이 완성되기를 기다렸다가 2층을 만들 필요가 없다. 1층과 2층의 인터페이스만 잘 정하면 따로 만들어서 합치면 된다. 다 만들어서 나중에 합치는 방법도 있지만, 1층과 2층의 뼈대만 만들어 놓고 동시에 만드는 방법을 더 많이 사용한다. 나중에 합치게 되면 합치는 과정에서 문제가 발생하기도 하지만, 처음부터 합쳐 놓고 동시에 만들면 합치는 과정에서 생기는 문제가 줄어든다.

(빠른 병행 개발 - 개발 후 통합)

(빠른 병행 개발 - 통합 후 개발)

이렇게 소프트웨어를 동시에 개발하여 프로젝트 기간을 단축하려면 분석, 설계가 잘 되어 있어야 한다. 특히 컴포넌트를 잘 나누고 인터페이스를 견고하게 정의해야 한다. 인터페이스는 간결하게 정의를 해야 각 모듈 간의 연동이 쉬워진다. 인터페이스는 확고하게 정의를 해야 하며 나중에 함부로 바꾸면 안된다. 물론 한번 정의한 인터페이스가 프로젝트 종료 시까지 변경되지 않으면 가장 좋겠지만 쉬운 일이 아니다. 개발 도중에 인터페이스를 변경하면 처음에 잘 정의한 경우보다 수십배의 변경 비용이 들어간다. 따라서 분석, 설계 시 최대한 노력을 하여 인터페이스가 가능하면 변경되지 않도록 정의를 해야 한다.

프로젝트가 크고 참여 인원이 많을수록 순차적인 개발보다 병렬 개발이 훨씬 좋다. 수십명의 개발자가 참여하는 프로젝트에서 순차적인 개발이란 거의 불가능하다. 수십명의 개발자가 처음부터 잘 통합된 소스코드를 기반으로 병렬로 개발을 해야 프로젝트를 빨리 끝낼 수 있다.

(순차개발과 병행개발의 개발 속도 차이 비교)

인터페이스는 상호간의 약속이다. 클라이언트와 서버 모듈을 병렬 개발할 때 인터페이스는 클라이언트 개발팀과 서버 개발팀의 약속이다. 인터페이스를 확정하면 서로 약속을 한 것이고 서로 헤어져서 따로 개발을 해도 문제가 없을 정도로 신뢰를 할 수 있어야 한다.

프로젝트 기간 내내 인터페이스를 잘 유지하기 위해서는 지속적인 통합이 필요하며 유닛 테스트, 테스트 자동화도 유용하다. 개발자는 자신이 작성한 모듈을 완성한 후에 소스코드관리시스템에 등록하는 것이 아니라 좀더 잦은 주기로 등록을 하여 프로젝트 주기 내내 소스코드가 정상적으로 빌드가 되도록 유지해야 한다. 너무 늦게 통합을 할 경우 많은 문제를 발생시키는 “통합의 지옥”을 맛보게 된다.

커밋은 하나의 기능이 완성이 되었을 때, 전체 클래스 또는 전체 컴포넌트를 모두 구현할 때까지 기다릴 필요가 없다. 하지만 항상 빌드는 되어야 한다. 또한 내가 소스코드를 수정하는 동안 다른 곳을 수정한 동료들의 소스코드와 머지(Merge)가 잘 되어서 제대로 빌드가 되는지 확인을 해야 한다. 보통은 적어도 하루에 한두 번 이상 커밋을 한다. 며칠씩 커밋을 하지 않고 지나가지는 않는다.

지속적인 통합을 위해서는 툴을 사용해도 되고, 직접 스크립트를 작성해서 구축을 해도 된다. 지속적인 통합을 도와주는 툴을 CI툴이라고 하며 Jenkins, Bamboo 등이 있다. CI툴 자체가 중요한 것은 아니지만 CI툴은 지속적인 통합을 조금 쉽게 해준다. 중요한 것은 지속적인 통합 활동을 성실히 하는 것이다.

지속적인 통합을 위해서는 주기적인 빌드가 필수다. Build on commit을 하기도 하고 Daily build를 하기도 한다. 밤에 빌드를 한다고 해서 Nightly build라고 하기도 한다. 프로젝트 기간 내내 Daily build는 실패가 없어야 한다. Daily build가 실패하면 인터페이스가 깨졌거나, 어떤 개발자가 깨진 소스코드를 올렸을 수 있다. 빌드가 깨지면 여러 개발자들이 개발에 차질을 빚게 된다. Daily build가 깨진 것을 브로큰 트리(Broken tree)라고 부르며 즉각 해결을 해야 한다.

거대한 시스템일수록 병렬 개발은 꼭 필요하다. 거대한 시스템의 구조를 얼마나 간결하게 하는지가 설계의 중요 요소다. Architect는 복잡한 시스템을 최대한 간결하고 복잡도를 줄여서 시스템의 개발, 유지보수 효율을 높여야 한다. 병렬 개발을 할 때 어려운 점은 내가 필요로 하는 컴포넌트가 아직 구현이 안되어 있어서 기능을 확인할 수 없다는 것이다.

예를 들어보자. 나는 사용자 관리 화면을 개발하고 있고 getUserList()라는 함수가 필요하다. 나는 사용자 목록을 출력하는 화면을 만들고 있는데 getUserList()를 개발하는 개발자는 아직 이 함수를 구현하지 않은 상태다. 그럼 나는 getUserList() 함수가 개발되기 전까지는 내가 만든 사용자 목록 화면을 테스트 해볼 수가 없다. 그럴 때는 getUserList() 함수에 가짜 코드를 추가하면 된다. 실제로는 DB에 쿼리를 해서 사용자 목록을 가져와야 하지만, 가짜로 Hard coding을 해서 사용자 목록을 넘겨주는 것이다. 물론 이런 가짜코드는 필요에 따라서 언제든지 넣고 뺄 수가 있어야 한다.

C언어로 개발을 한다면 다음과 같은 형태가 될 것이다. 아주 간단한 예를 든다.

#define USE_FAKE
RET getUserList(userdata *pData[], int &num)
{
#ifdef USEFAKE
  // make fake data
  num = 2;
  pData[0]->userid = 1;
  pData[0]->username = “John”;
  pData[1]->userid = 2;
  pData[1]->username = “Tom”;
#else
  // get data from database
#endif
  return RET_SUCCESS;
}

(병행 개발을 위한 소스코드 예)

이와 비슷하게 개발 언어에 따라서 적절한 방법으로 병렬 개발하는 아이디어를 적용하면 된다. 병렬 개발을 위와 같이 각자 서로 다른 모듈을 개발하는 경우도 있고 하나의 모듈을 여러 개발자가 개발하는 경우도 있다.

잘 분석, 설계된 소프트웨어는 이와 같은 방법을 사용하여 병렬 개발을 진행하여 소프트웨어를 빨리 개발할 수 있다.

share with abctech.software

[Software Spec Series 4] 스펙의 역할

소프트웨어 프로젝트에서 스펙의 역할을 알아보자.

모든 프로젝트 이해관계자가 사용, 프로젝트의 중심

스펙은 프로젝트의 모든 요구사항이 모이며 프로젝트의 중심이 되는 문서다. 프로젝트의 모든 이해관계자가 스펙을 참조하거나 작성에 참여한다. 스펙은 다시 여러 프로젝트 이해관계자들이 받아서 자신의 역할을 수행한다. 프로젝트에서 가장 중요한 문서 하나를 꼽으라고 하면 스펙이다.

(프로젝트의 모든 이해관계자가 참조해야 하는 SRS)

고객, 마케팅 부서, 영업 부서는 어떠한 제품이 만들어지는지 알 수 있다.

스펙이 없거나 부실한 상태로 진행하는 프로젝트는 프로젝트가 완료되기 전까지 어떠한 소프트웨어가 개발될지 알기가 어렵다. 그러면 영업부서는 소프트웨어 개발이 완료되기 이전에 판매 준비를 하거나 계약을 할 수가 없다. 스펙이 잘 작성된 프로젝트인 경우 스펙만 보고도 최종적으로 개발될 소프트웨어가 무엇인지 정확하게 알 수 있다. 영업부서에서는 이를 보고 판매에 필요한 준비를 할 수 있다. 영업망을 확충하거나 세일즈 자료를 준비할 수 있다. 또한 고객을 만나서 개발도 완료되지 않은 소프트웨어를 미리 팔 수도 있다. 소프트웨어 개발이 완료된 후에 부랴부랴 판매를 시작한다면 이미 상당한 판매 기회를 놓치게 된 것이다. 그 외에 안전, 의료, 보안 등의 인증이 필요한 경우도 스펙이 잘 작성되어 있다면 소프트웨어 개발이 완료되지 않았음에도 인증을 신청해서 인증을 미리 획득할 수 있다. 인증은 종류에 따라서 1년 넘게 또는 수년이 걸리기도 한다. 소프트웨어 개발이 완료된 후에서야 인증을 진행하면 수년의 영업 기회를 날려버릴 수도 있다.

프로젝트관리자(PM)에게는 스펙이 프로젝트 관리의 기준이 된다. 일정산정, 인력 배분, 리스크 분석 등을 할 수 있다.

스펙이 제대로 작성되지 않는 프로젝트에서 프로젝트 관리자는 별로 할 일이 없다. 일정을 제대로 예측하기도 어렵고, 리스크 파악도 어렵다. 적정한 리소스 계획을 세우지 못한다. 프로젝트가 진행이 되도 정확하게 진척률을 파악할 수가 없다. 그래서 1년짜리 프로젝트가 8개월쯤 지나도 정확하게 1년 안에 프로젝트가 종료될지 예측이 안된다. 그러면 프로젝트 관리자는 프로젝트 성공을 위해서 무엇을 더 해야 하는지 알 수 없다. 그저 운에 맡기는 수밖에 없다. 프로젝트의 성격에 따라서는 단계별로 진행을 하여 짧은 주기로 여러 차례 업그레이드를 하면서 진행하는 경우도 있다. 이 경우도 주기만 짧을 뿐이지 짧은 주기에 해당하는 스펙을 적절히 작성하는 것도 똑같이 필요하다.

개발팀은 스펙을 통해서 개발팀이 개발해야 할 제품이 무엇인지 정확하게 알 수 있다.

스펙을 제대로 작성하지 않았다면 개발팀은 정확하게 무엇을 개발해야 하는지 파악하기 어렵다. 기획자나 분석 아키텍트에게 너무 많은 것을 수시로 물어봐야 해서 시간을 매우 낭비해야 한다. 개발자가 임의대로 생각해서 기능을 구현하게 되면 기획의 의도와는 완전히 다르게 되기도 한다. 개발자에게 주어진 너무 높은 자유도가 소프트웨어 아키텍처를 부실하게 만들기도 한다. 개발자에게 자유도는 필요하지만 소프트웨어 전체 아키텍처는 분석, 설계 시에 정해져서 개발자에게는 한정된 자유도만 주어야 한다. 그래야 기획 시 의도된 소프트웨어가 제대로 개발될 수 있다.

(프로젝트에서 SRS의 위치)

테스트팀은 스펙을 통해서 테스트 계획 및 테스트 케이스를 작성할 수 있다.

보통은 스펙 작성 후에 개발자들이 구현을 하는 동안 테스트팀은 테스트 준비를 한다. 테스트 계획을 세우고 테스트 설계를 해야 한다. 하지만 스펙이 없거나 부실하다면 테스트팀은 테스트 준비를 제대로 할 수가 없다. 소프트웨어가 개발된 후에 소프트웨어를 보면서 테스트 준비를 해야 하는데 이 방법으로는 테스트 일정도 예측할 수 없고 부실한 테스트를 할 수 밖에 없다. 소프트웨어 품질이 나빠지는 것은 당연한 결과다.

기술문서팀은 스펙을 통해서 매뉴얼과 도움말을 작성할 수 있다.

소프트웨어 스펙이 완성된 후에는 많은 일들이 벌어진다. 기술문서팀은 소프트웨어를 동작시켜 보지도 않고 매뉴얼을 미리 작성한다. 단지 화면 캡쳐만 소프트웨어 개발 후 추가할 뿐이다. 이뿐만 아니다. 고객지원 부서는 고객 지원에 필요한 준비를 해 놓고 교육팀은 교육 준비를 한다. 이처럼 소프트웨어 스펙을 보고 많은 사람들이 자신의 일을 수행해야 하는데 바쁘다고 스펙 없이 개발을 하는 것은 개발자 중심의 사고방식이며 프로젝트가 효율적으로 진행되지도 않는다.

외주 업체는 스펙을 통해서 외주 업무를 정확하게 파악하고 SRS를 기준으로 계약을 할 수 있다.

우리나라에서는 많은 소프트웨어 프로젝트가 스펙도 없이 진행이 된다. 대략의 요구사항을 기반으로 계약하고 진행되는 프로젝트는 정상적으로 진행되기 어렵다. 고객이 수시로 요구사항을 무리하게 바꿔도 하소연하기 어렵다. 또한, 분석을 제대로 하지 않고 진행을 하므로 요구사항만으로는 프로젝트의 규모를 제대로 산정하기 어렵다. 그래서 계약 시는 성공적인 계약으로 생각되지만 프로젝트를 진행할수록 손해를 보는 경우도 허다하다. 우리나라도 스펙을 기준으로 계약을 하는 관행이 자리잡아야 한다.

share with abctech.software

[Software Spec Series 2] 소프트웨어 프로젝트 실패의 원인

우리 주변에서 실패한 소프트웨어 프로젝트를 보는 것은 어려운 일이 아니다. 프로젝트를 성공하는 방법을 배우기 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패하는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

• 약속된 일정 내에 제품 또는 서비스를 출시하지 못했다.
• 소프트웨어가 요구되는 품질을 충족하지 못했다. (기능 요구사항, 성능, 안정성, 사용성, 확장성 등)
• 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
• 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
• 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
• 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자.

• 고객의 요구사항을 충분히 파악하지 못했다.
• 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당히 많은 시간을 소모하여 정작 개발 기간이 부족하게 되었다.
• 스펙과 설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 하였다.
• 작성된 스펙을 프로젝트 이해관계자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발하였다.
• 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어졌다.
• 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 하였다.
• 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작했다. 나중에 잘못된 코드를 고치느라고 시간이 더 소요되었다.
• 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕하느라고 시간을 많이 지체했다.
• 일정관리를 대충해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못했다.
• 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패했다.
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 했다.
• 프로젝트 팀원들의 팀워크에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트가 산으로 갔다.
• 도입한 외부 필수 기술이 기대처럼 동작하지 않았다. 이것을 프로젝트 막바지에 알게 되었다.
• 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못했다.
• 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해졌다.

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인은 “스펙”이다. 가장 많은 원인이 스펙과 관련이 있다. 또한 소프트웨어 버그의 절반 이상은 스펙으로부터 발생한다고 알려져 있다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가도 소프트웨어를 무사히 완성하기도 한다. 소수의 경험 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 찰떡 같이 알아듣고 개발을 잘하기도 한다. 하지만, 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 인수 테스트 계획이 필요하다.

소규모 프로젝트에서의 성공 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 반대로 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사에서는 이런 함정에 종종 빠진다. 개발은 문서대로 진행되지 않을 뿐만 아니라 문서가 너무 많아서 수시로 바뀌는 요구사항을 문서에 제대로 반영하지 못한다.

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 이해관계자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 소프트웨어 프로젝트 성공은 어렵다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다. 꾸준히 투자하는 방법 외에 기가 막힌 방법은 없다.

share with abctech.software

한국 회사와 불가리아 회사

필자는 꽤 오래 전에 비슷한 일을 하는 두 회사를 접했다.

두 회사 모두 웹프레임워크를 개발하는 회사였다.

한국 회사는 웹프레임워크를 솔루션 형태로 개발해서 3~5천만원을 받고 약간의 SI를 더해서 한국 회사들을 대상으로 영업을 하고 있었다. 고객 중에는 외국회사도 있었고, 매출을 꽤 일으키고 있었다. 보유 기술 자체는 좋았다. 하지만 기획, 스펙, 설계 같은 것은 제대로 된 것이 없었다. 고객이 생기면 고객의 요구사항대로 만들고 고쳐서 구축해주기 급급했다. 그렇게 여러 프로젝트들이 동시에 진행되고 있었다.

그렇게 회사를 운영하면 곧 망할 것이 확실했지만 워낙 희망에 차 있어서 그렇게 말해줄 수가 없었다. 현재 회사가 눈에 띄지 않는 것으로 보아 없어진 것으로 예상된다.

비슷한 시기에 불가리아 회사에서 개발한 웹프레임워크를 인터넷으로 접하게 되었다. 가격은 약 100만원 수준이었다. 데모 사이트가 너무 잘 구축되어 있어서 내가 필요한 것들이 다 제공되는지 쉽게 확인할 수 있었다. 여러 개발 언어를 지원하며 메뉴얼이 매우 잘 만들어져 있었다. 커스터머 서비스는 온라인으로만 진행이 되었다. 서비스 데스크 시스템이 잘 구축되어 질문을 하면 온라인으로 바로 답변이 왔다. 한국회사의 솔루션에 비해서 가격은 엄청나게 싸지만 성장 가능성은 엄청나 보였다. 직원이 많지도 않지만 이 회사는 곧 세계적인 회사가 될 것이라고 생각했다.

이 회사가 Telerik다. 2014년에 Progress software라는 회사에 2억6천만불(약 3천억) 에 인수되었다.

여기서 조삼모사의 교훈을 다시 생각해본다. 물론 조삼모사도 역량이 있어야 가능하다. 역량이 없다면 조사모삼 밖에는 할 수가 없다.

이 두 회사만의 현상은 아니다. 한국과 외국의 여러 소프트웨어 회사를 대표해서 보는 것 같아서 씁쓸하다. 

소프트웨어 스펙은 왜 쓰기 어려운가?

스펙을 잘 쓰는 것은 소프트웨어 프로젝트를 성공하기 위한 가장 중요한 요소중 하나라는 것은 이미 수차례 강조한 얘기다.

스펙을 적절히 제대로 작성하지 않았다는 얘기는 건설에서 설계도를 제대로 만들지 않고 건설을 하는 것과 같이 소프트웨어 프로젝트에서도 여러가지 문제를 야기시킨다.

• 프로젝트가 종료 일정을 지키지 못할 가능성이 높다.
• 소프트웨어 아키텍쳐가 엉망이 될 가능성이 높다.
• 소프트웨어 품질을 보장하기 어렵다.
• 개발자들이 야근에 내몰려 혹사를 당하기 쉽다.
• 개발에 관련된 지식 축적이 어렵다.
• 추후 요구사항이 변경되어도 소프트웨어에 어떠한 파급효과가 있는지 예측하기 어렵다.
• 업그레이드 프로젝트를 효과적으로 진행하기 어렵다.

실제로 많은 회사들에서는 소프트웨어 스펙을 잘 쓰기 위해서 많은 투자를 한다. 그럼에도 왜 스펙을 잘 쓰기 어려운가? 또한 개발자들이 분석 설계를 잘 할 수 있는 뛰어난 아키텍트로 성장이 잘 안되는가?

많은 개발자들은 독학을 통해서 뛰어난 프로그래머가 되기도 한다. 하지만 왜 스펙 작성은 독학으로 잘 안되는가? 스펙은 프로그래밍보다 훨씬 많은 측면으로 분석을 해야 하고 복잡하기 때문이다. 스펙 작성은 골프와 피아노에 비견되곤 한다. 그래서 스펙 작성을 골프와 피아노에 비교를 해보았다.

소프트웨어 스펙 작성	골프	피아노	효과
책을 보고 스스로 공부해서 스펙을 적는다.	골프 잘치는 책을 보고 혼자서 연습한다.	피아노 교본을 보고 혼자서 연습한다.	역효과
강연을 듣고 필요성을 절감해서 스펙을 적는다.	타이거 우즈 특강 모임에서 깨달은 바가 있다.	피아노 잘치는 법이라는 강연을 듣는다.	미미한 효과
인터넷에서 좋다는 Template을 구해서 각 항목을 채운다.	좋다는 골프채를 구매해서 골프를 친다.	좋은 피아노를 사서 열심히 연습한다.	미미한 효과 또는 역효과
일하면서 뛰어난 선배들이 작성한 스펙을 본다.	골프 연습장에 골프를 잘치는 프로가 많아서 수시로 골프 치는 것을 볼 수 있다.	피아노 교습소에 뛰어난 피아니스트가 있어서 연주를 수시로 볼 수 있다.	좋은 환경
스스로 스펙을 작성하고 뛰어난 아키텍트 선배의 리뷰를 받는다.	골프 코치에게 골프를 배우고 연습을 반복한다.	피아노 선생님에게 피아노 치는 것을 배우고 연습을 반복한다.	발전 가능성이 높은 환경
수년간 지속적으로 스스로 스펙을 작성하고 뛰어난 아키텍트 선배의 리뷰를 받는다.	수년간 실전 골프를 치면서 지속적으로 골프 코치에게 스윙을 교정받고 배운다.	수년간 피아노를 치면서 지속적으로 선생님에게 피아노 치는 것을 배운다.	발전 가능성이 가장 높은 방법
본인 스스로도 타 프로젝트의 수많은 스펙의 리뷰에 참여한다.	후배들의 골프 스윙도 봐주면서 이론적으로도 지식을 쌓는다.	후배들이 피아노를 치는 것을 봐주면서 조언을 해준다.	발전 가능성이 가장 높은 방법

이쯤 설명하면 많은 회사들이 왜 스펙을 잘 작성하기 어려운지 이해가 될 것이다.

개인관점으로 보면 좋은 환경을 갖춘 곳에서 일하는 것이 가장 좋다고 할 수 있다. 회사입장에서는 회사를 좋은 환경으로 만들고 좋은 관행을 만들어야 한다. 그럼 회사가 가져야 할 좋은 관행이란 무엇이 있을까?

• 뛰어난 아키텍트를 여러명 보유한다.
• 작은 프로젝트라도 스펙을 제대로 작성하고 개발하는 문화를 만든다.
• 철저한 정보 공유, 투명한 개발 환경
• 경영진을 비롯하여 많은 프로젝트 관련자들이 스펙을 충분히 리뷰한다.

그럼 반대로 이를 저해하는 나쁜 관행들은 무엇이 있을까?

• 빠르게 개발한다는 명목하게 주먹구구식 개발을 신봉한다.
• 원칙보다 기법에 현혹되어 여러 방법론을 기웃거린다.
• 복잡한 프로세스가 문제를 해결해 줄것으로 맹신하고 강요한다.
• 코딩이 가장 중요하다고 생각한다.
• 작성된 스펙에 관심들이 없어서 리뷰에 소홀하다가 개발 후에 부담없이 변경을 요구한다.
• 상명하복의 조직문화

이런 문화에서는 뛰어난 아키텍트가 있다고 하더라도 무용지물일 뿐이다. 회사는 좋은 관행을 만들어가고 개인들은 좋은 습관을 가지도록 노력할 때 수년 후에는 스펙을 제대로 작성할 수 있는 역량을 갖추고 소프트웨어 개발 역량이 글로벌 회사들과 경쟁할 중요한 기초 역량을 갖추어 가고 있다고 할 수 있다.

share with abctech.software

핵심은 아키텍트다

우리나라에는 뛰어난 프로그래머가 참 많다. 우리나라에서 연봉 4천만원 받는 개발자의 능력과 하는 일을 보고 외국의 억대 연봉 개발자가 입이 떡 벌어졌다는 우스개 소리가 인터넷에 떠돌고 있다. 전혀 근거가 없는 얘기는 아니다. 우리나라에서는 개발자가 많은 분야의 일을 해야 하고 밤을 지새면서 엄청난 양의 일을 소화하곤 하기 때문에 일단 많이 배우고 매우 빠르고 숙달되어 있다.

​

하지만 이것도 잠깐이다. 세월이 흘러 10년차, 20년차 개발자가 되고 나면 외국의 억대 연봉을 받았던 개발자와 비교해서 분석, 설계 역량에서 많이 뒤떨어지게 된다. 결국 연봉 값을 하게 된다. 이는 개발자들의 기본적인 재능이 아니라 환경차이 때문에 벌어지는 일이다.

​

우리나라에서는 빨리빨리 문화, 상명하복 문화를 비롯해서 여러가지 환경 때문에 아무리 좋은 프로세스를 도입한다고 해도 개발자들에게 분석, 설계 역량이 차근차근 축적이 되어서 10년, 20년 후에 뛰어난 아키텍트로 성장하기가 매우 어렵다.

[사진=Pixabay]

그럼에도 불구하고 우리나라에서는 아키텍트라는 단어에 많이 집착한다. 소프트웨어업계에 아키텍트가 부족하여 발전이 안된다고 하기도 하고, 너도나도 회사에서 아키텍트라는 타이틀을 만들어 남발하기도 한다. 이렇게 아키텍트에 집착하는 것은 여전히 뛰어난 아키텍트가 많이 없어 그에 따른 갈증이 있기 때문으로 해석된다.

​

이런 현상은 비단 소프트웨어 업계만의 문제는 아니다. 우리나라는 여러 산업분야에서 선진국을 빠르게 따라 잡으면서 실행력은 앞서기도 한다. 하지만 시스템 설계 능력은 겉모습을 보고 따라잡을 수 있는 것이 아니다. 선배에서 후배로 여러 세대를 거치면서 축적된 경험과 노하우가 전승되어 와야 하는 것이라서 우리끼리 독학으로 따라잡을 수는 없는 것이 당연하다.

​

■ 비즈니스 이해해야 좋은 아키텍처 나와

​

소프트웨어 아키텍트는 어떤 사람을 말하는 것인가?

​

한마디로 정의하면 소프트웨어 시스템을 설계하는 사람이다. 소프트웨어 시스템을 작은 모듈까지 축소하면 대부분의 개발자들은 아키텍트이기도 하지만 이슈가 되는 것은 상당히 커다란 시스템을 설계할 수 있는 능력을 가진 사람이 아키텍트다.

​

누구나 하기도 하고 누구나 잘할 수 있을 것 같은 소프트웨어 분석 설계가 어려운 이유는 아키텍트는 일반 개발자 또는 프로그래머와는 완전히 다른 역량을 요구하기 때문이다.

​

좋은 아키텍처는 비즈니스에 대한 이해에서 나온다. 대부분은 현재뿐만 아니라 미래 비즈니스 전략도 잘 알아야 한다. 또한 기술적으로도 상당 수준이어야 한다. 업무에 빠삭한 도메인전문가(업무전문가)와는 또 다르다. 문서로 소프트웨어 스펙이나 설계서를 작성할 수 있어야 하고 다른 사람이 이 문서를 보고 소프트웨어를 개발 할 수 있어야 한다. 의외로 이런 역량을 고루 갖추고 있는 뛰어난 소프트웨어 아키텍트는 흔하지 않다.

​

우리나라는 도메인 전문가가 나름 그 역할을 하고 있다. 업무는 모르는 것이 없이 잘 알지만 분석, 설계 역량은 떨어지고 문서로 스펙과 설계를 작성해서 다른 사람에게 일을 시키지 못하기 때문에 옆에 붙어서 설명을 너무 많이 해줘야 하고, 개발 도중 문제가 생길 때마다 해박한 업무 지식으로 문제를 해결해 나간다. 물론 개발 효율성은 떨어질 수 밖에서 없다.

​

왜 소프트웨어 회사에 뛰어난 아키텍트가 필요한가?

​

개발자 3~4명이 진행하는 소규모 프로젝트는 어떻게 개발을 하든지 소프트웨어 개발이 가능하다. 각 개발자들의 프로그래밍 역량이 뛰어나다면 매우 훌륭한 소프트웨어도 만들 수 있다. 하지만 규모가 점점 커지면 개별 프로그래머들의 역량이 뛰어나다고 성공적으로 소프트웨어를 만들기는 어렵다.

​

개발 복잡도는 소프트웨어 규모에 기하급수로 비례해서 복잡해진다. 또한, 어찌어찌 소프트웨어 개발에 성공을 했다고 하더라도 몇 년 안에 더 큰 문제가 나타난다.

​

설계가 제대로 되지 않은 소프트웨어는 업그레이드를 할수록 아키텍처가 복잡해지고 곧 유지보수가 새로 개발하는 것보다 어려운 시점이 오게 된다. 물론 회사에 뛰어난 아키텍트가 있는 경우에도 프로젝트

일정이나 복잡한 프로세스에 밀려서 아키텍처를 소홀히 하곤 한다. 그 대가는 미래에 꼭 몇배로 치르게 되어 있다.

​

■ "국내엔 축적된 노하우 계승해줄 선배들 부족"

​

그럼, 왜 우리나라에는 소프트웨어 아키텍트가 부족한가?

​

빨리 빨리 개발 문화부터 상명하복 조직 문화 등 간접적인 원인도 너무나 많지만 가장 큰 원인은 축적된 아키텍처링 노하우를 계승 시켜줄 선배들이 부족하기 때문이다. 그러다 보니 개발 기술은 발달을 하는데 커다란 소프트웨어 시스템을 설계해서 수십, 수백명이 체계적으로 일을 나눠서 문서를 보고 개발을 하는 경험을 해볼 환경이 거의 없다.

​

소프트웨어 설계에 관련된 좋은 책은 많지만 골프 책이 아무리 많다고 골프 코치가 없으면 소용이 없다. 프로그래밍은 코치가 없어도 책을 보고 배울 수 있는 분야다. 하지만 분석과 설계는 코치 없이 배우는 것이 불가능하다. 또한, 몇 개월 가지고는 부족하다. 수년간 같이 일하면서 노하우를 전승 받아야 한다.

​

아키텍트를 양성하기 위해서 회사들은 어떤 노력들을 하고 있는가?

​

대학에서 요구공학이나 소프트웨어 아키텍처 디자인 관련된 강좌 코스에 직원들을 보내기도 하고, 강사를 초빙해서 강의를 듣기도 한다. 물론 다 도움이 되는 일이지만 기대만큼 빠른 성과가 나지는 않는다. 시험을 통해서 아키텍트 양성 후보를 선발하기도 한다. 알고리즘 시험을 보기도 하는데 그런 방법은 고참 개발자는 아키텍트 후보가 된다는 이상한 공식이 성립하기도 한다.

​

이렇게 자생적으로 소프트웨어 아키텍트를 양성하기 위해서 피나는 노력을 하지만 기대만큼 단기간에 성과가 나고 있지 않다. 물론

수십년 동안 노력을 한다면 분명히 성과가 있겠지만, 수십년을 기다릴 만큼 인내심을 가진 회사는 거의 없다. 결국 제도와 프로세스로 강제화를 하지만 이 문제는 그렇게 해결이 되지 않는다. 오히려 방해가 된다.

​

그럼 아키텍트는 어떻게 양성해야 하는가?

​

교육도 좋고 뛰어난 아키텍트를 영입하는 것도 좋은 방법이다. 하지만 가장 좋은 것은 좋은 관행들을 지속적으로 유지하는 것이다.

■ 아키텍트를 양성하는 세 가지 방법

​

첫째, 소프트웨어를 개발할 때 분석, 설계를 제대로 해서 진행하는 것이다. 물론 문서로 제대로 작성하고 서로 리뷰하고 진행해야 한다. 이런 경험들이 축적되어야 한다. 급하다고 빨리 코딩부터 시작하는 경우가 있는데 그러면 프로젝트는 더 오래 걸리고 노하우가 축적되지 않는다. 물론 학습비용이 필요하기 때문에 처음에는 코딩부터 빨리 시작하는 것이 더 빨리 개발하는 방법일 수도 있다. 하지만 시간이 흐를수록 프로젝트는 더 오래 걸릴 것이다.

​

둘째, 아키텍트 그룹을 운영하는 것이다. 보통은 가상 조직으로서 Technical Steering Committee나 Architect Group과 같은 이름을 가진다. 회사의 중요한 기술적인 이슈를 논의하고 결정하는 위원회이며 분석, 설계 문서를 집중적으로 리뷰하기도 한다. 아키텍트 후보로 선발된 인원은 이 조직에 참여하여 수년간의 훈련을 받으면 자연스럽게 아키텍트로 성장하게 된다.

​

셋째, 아키텍트 후보를 선발하는 것이다. 앞으로 아키텍트로 성장할 가능성이 높은 개발자를 후보로 선발하여 수년간 훈련을 시켜야 한다. 물론, 아키텍트는 우수하고 일반 프로그래머는 우수하지 않다는 것이 아니다. 성향이 다를 뿐이다. 그리고 성향에 따라서 적합한 일이 좀 다를 뿐이다. 아키텍트로 성장하려면 다음과 같은 성향이나 소질이 있어야 한다. 글을 잘 쓰고, 다른 사람의 얘기를 잘 들어주고, 창의력이 좋고, 분석적으로 사고를 하고, 정보를 잘 조직화하고, 꼼꼼하며, 논리적인 사고를 하고, 문제의 핵심을 잘 찾고, 인내심이 좋아야 한다. 이를 모두 만족하는 사람은 없지만 몇가지가 일치하면 후보로 선발하여 키워야 한다.

​

막상 얘기를 해보면 회사에 꼭 필요한 아키텍트를 키우는 데는 기가 막힌 방법이 없다. 골프를 잘 배워서 잘 치는데 기가 막힌 방법이 없는 것과 같다. 물론 잘못 배워서 잘못치는 방법은 부지기수로 많다. 좋은 환경에서 뛰어난 선배들이 좋은 관행을 유지하며 꾸준히 후배들을 가르쳐 주는 것이 가장 보편적인 방법이다. 이렇게 실무를 통해서 배우는 것이 학교에서 수업을 배우는 것보다 몇십배 더 많은 것을 배울 수 있다.

​

조급하다고 되는 것도 아니고, 프로세스로 강제화 한다고 되는 것도 아니다. 뛰어난 소프트웨어 아키텍트를 여러 명 보유하는 것은 회사의 미래를 결정짓는 결정적인 요소이기 때문에 무시할 수도 없다. 꾸준한 투자를 해야 한다.

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

소프트웨어 프로젝트는 왜 실패하는가?

우리는 주변에서 실패한 소프트웨어 프로젝트를 보는 것이 그리 어려운 일은 아니다. 프로젝트의 규모가 커지고 기간이 길어지며 많은 인원이 투입될수록 프로젝트 실패 확률은 증가한다. 

프로젝트 성공을 위해서는 프로젝트를 제대로 진행하는 방법을 연구하는 것도 필요하지만 프로젝트가 왜 실패했는지 살펴보는 것도 도움이 될 것이다. 프로젝트 실패에 대한 기준은 제각각이다. 그래서 어떤 경우에 프로젝트가 실패했다고 할 수 있는지 알아보자.

• 약속된 일정 내에 제품 또는 서비스를 출시 못했다.
• 소프트웨어가 시장에서 요구되는 품질을 충족하지 못했다. (요구사항, 성능, 안정성, 사용성 등)
• 프로젝트에 꼭 필요한 기술 개발에 실패했다. 
• 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
• 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
• 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.

직접적인 실패와 억지로 일정을 맞추려다 보니 다른 문제를 야기하는 간접적인 실패까지 예로 들어봤다. 이런 저런 이유로 실패하는 프로젝트는 매우 많다. 또한 실패하는 이유도 매우 다양한다. 필자는 이 중에서 가장 중요하다고 생각하는 하나에 대해서 얘기를 하려고 한다. 우선은 프로젝트를 왜 실패하는지 다양한 원인을 알아보자. 

• 고객의 요구사항을 충분히 파악하지 못함
• 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당부분의 시간을 소모하여 개발 기간이 부족하게 됨
• 스펙/설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 함
• 작성된 스펙을 관련자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발함
• 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어짐
• 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 함
• 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작함. 나중에 잘못된 코드를 고치느라고 시간이 더 소요됨
• 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕함
• 일정관리를 대충 해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못함
• 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패함
• 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 함
• 프로젝트 팀원들의 팀웍에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트는 산으로 감
• 도입한 외부 필수 기술이 기대처럼 동작하지 않는다.
• 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못함
• 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해짐

이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 간단히 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인을 “스펙"이라고 생각한다. 

다른 영역도 중요한 것이 사실이지만 스펙을 적는 것은 소프트웨어를 개발하는데 가장 중요하면서 가장 어렵다. 스펙을 적는 것을 “분석” 또는 “분석/설계”라고 한다. 설계가 여기에 왜 포함되었는지 의아한 사람도 있을 텐데, 분석 시에 상위 설계의 상당부분이 포함이 되는 경우가 많고 프로젝트에 따라서 다르지만 분석과 설계는 그 경계가 모호하기 때문에 같이 다루는 경우가 많다.

프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가면서 소프트웨어가 무사히 완성을 하기도 한다. 소수의 경험이 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 개발을 잘하기도 한다. 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 테스트 문서도 전달하기도 한다.

소규모 프로젝트에서의 성공의 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.

요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사들에서는 이런 함정에 종종 빠진다. 개발은 문서대로 되지도 않을 뿐만 아니라 수시로 바뀌는 요구사항을 문서가 너무 많아서 문서에 반영도 제대로 못한다.

 

따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 관련자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.

좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 말짱 공염불일 뿐이다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다.

이 방대한 얘기를 짧은 글로 어떻게 소개할 수 있을지 걱정은 되지만, 개발자가 어떻게 하면 소프트웨어 분석, 설계 역량을 가질 수 있으며 회사는 어떻게 그런 역량을 축적할 수 있는지 다음에 몇 개의 글을 통해서 조금 더 자세히 얘기를 해보고자 한다.

share with abctech.software

이우소프트에는 이것이 있다 vs. 없다

개발자 캐리어 보장이 있다.

• 개발자가 원하면 영원히 개발자로서의 경력을 보장해준다.
• 개발자에게 나이가 많다고 관리를 강요하거나 권유하지 않고 본인의 적성과 역량에 따라서 진로를 결정하면 된다.

남녀 차별이 없다.

• 남여에 따른 역할,대우의 차이가 전혀 없다.
• 100% 역량에 따른 차이 밖에 없다.
• 결혼, 육아에 따른 차별이 없다.

아키텍트가 있다.

• SW아키텍트가 있고 스펙, 설계와 기술적인 이슈 해결을 담당한다. 코딩도 한다.
• 무조건 고참이라고 아키텍트가 되는 것은 아니다.
• 아키텍트가 되기 위한 까다로운 자격을 충족해야 한다.
• 아키텍트는 사원부터 수석 연구원까지 있다.
• 여자 아키텍트도 있다.

관리만 하는 개발팀장이 없다.

• 개발팀장이 있기는 한데 휴가 결재가 하는 일의 대부분이다.
• 개발팀장은 Technical leader로서 개발만 잘하면 된다.

전문가가 있다.

• 자신의 일에 전문가가 되지 않으면 살아남을 수 없다.
• 하지만 전문가라면 의견이 존중되는 수평적인 조직이다.
• 비전문가가 감놔라 대추놔라 하지 못한다.

영어 이름이 있다.

• 모든 직원이 서로 영어 이름을 부르고 한국 이름은 사용이 금지되어 있다.
• 팀장님과 같은 직책으로 부르는 것도 금지되어 있다.
• 수평적인 생각을 정착하기 위해서 영어 이름을 사용하며 모두 동일한 존칭을 사용한다.

직급에 따른 서열이 없다.

• 개발자들은 직급이 아무것도 말해주지 않는다.
• 역량에 맞게 일을 분배하고 개발을 할 뿐이다.
• 아키텍트가 따로 있고 PM이 일을 분배할 뿐이다.

잔디밭이 있다.

• 8층 사무실 문을 열고 나가면 하늘 정원의 잔디밭이다.  
• 잔디밭에 누워서 햇볕을 쐬면서 머리를 식히자.

운동 시설이 있다.

• 체육관, GX, 웨이트 트레이닝, 골프 등의 시설이 직원들에게 제공된다.
• 건강관리를 위해서 꾸준히 운동을 할 것을 권장하며 여러 종목의 코치를 채용하여 운동을 지도하고 있다. 물론, 자기 계발과 운동을 할 수 있는 시간을 보장한다.

파티션이 없다.

• 파티션이 전혀 없이 책상들끼리 붙이 있다. 
• 모든 직원이 한눈에 보인다.

어린이집이 있다.

• 직원에게는 무료로 제공되는 어린이집이 있다.
• 출생 6개월부터 초등학교 입학 전까지 보육을 할 수 있다.
• 자녀와 같이 출퇴근을 할 수 있다.

회의록이 있다.

• 모든 회의가 하나도 빠짐없이 기록이 된다.
• 회의록은 거의 실시간으로 기록되고 모든 직원에게 공유된다.
• 회의에 참석하지 않은 사람도 언제든지 모든 회의록을 볼 수 있다.
• 그리고 결정된 사항은 모두 철저히 추적 관리가 된다.

코리안 타임이 없다.

• 회의시간이 1초도 늦는 직원은 없다.
• 1초라도 늦은 직원은 회의 참석자 전원에게 커피를 사야하고 2번째 늦을 때는 전직원에게 피자를 사야 한다.
• 커피는 얻어 먹었지만 아직 피자는 못얻어 먹었다. 언제 피자를 먹을 수 있을지 기다리고 있다.

전문 PM이 있다.

• 전문PM이 합리적으로 일정,리스크 등 프로젝트 관리를 한다.
• 억지를 부리지 않는다.
• 그렇게 해서 최단 시간에 프로젝트를 끝내고 있다.

일정 강요가 없다.

• 경영진이 말도 안되는 일정을 억지로 밀어붙이지 않는다.
• 1,2일 단위로 개발자가 산정하며 개발자가 예측한 일정을 다른 사람이 무시하지 않는다.
• 그래도 일정이 부족하면 PM은 온갖 방법을 동원해서 일정 단축 전술을 구사하고 그래도 부족하면 일정을 연기한다.
• 필요 시 일정은 구현 시작 전에 연기하므로 비즈니스 부서에서는 일정을 조율하는데 큰 문제가 없다.

몰입이 있다.

• 하루 8시간 업무에 완전히 몰입해야 한다.

야근이 없다.

• 강요된 야근이 없다.
• 일정을 합리적으로 결정하고 몰입해서 일해야 하기 때문에 야근이 필요 없다.
• 가끔 스스로 선택해서 야근을 하는 사람들이 있기는 하지만 강요는 없고 본인이 선택하는 것이다.
• 강요된 야근은 장기적으로 SW의 품질을 떨어뜨리고 기업 문화를 퇴보 시킨다.
• PM이 야근 카드를 꺼내는 경우는 정말 피치 못할 때이고 단기적으로 사용해야 한다.

스펙이 있다.

• 소프트웨어를 개발할 때는 항상 스펙을 작성한다.
• 큰 프로젝트는 SRS를 작성하고 작은 프로젝트나 프로토타입 개발 시에는 One-pager를 작성하다.
• SRS가 완료되면 모든 Stakeholder의 대표들이 서명을 한다.
• 프로젝트 계획은 스펙을 기초로 합리적으로 수립한다.
• 스펙은 변경되면 문서를 업데이트해서 최신 버전을 유지한다.

일정이 지연되는 프로젝트가 없다.

• 지연되는 프로젝트가 하나도 없다.
• 합리적인 일정 수립과 철저한 프로젝트 관리를 통해서 일정은 무조건 지킨다.
• 일정은 협력사와의 약속이므로 목숨처럼 지킨다.
• 출시 일정은 SRS가 끝날 때 확정한다.

60세 개발자가 있다.

• 나이는 개발자인지를 결정하는데 아무런 영향을 주지 않는다.

보고서가 없다.

• 개발자에게 보고서 강요가 없다. 주간보고도 없다.
• 개발자는 개발만 하면 된다.
• 문서는 개발문서만 쓰면 된다.

재택근무가 있다.

• 회사에서 자격을 부여한 개발자는 재택근무를 선택할 수 있다.
• 가끔 회사에 나와서 회의를 하고 커뮤니케이션은 거의 이슈관리시스템을 이용한다.

서울에도 스마트워크 센터가 있다.

• 본사에 동탄에 있는만큼 서울 북부 거주자 등 지역적인 어려움이 있는 직원들은 서울에 있는 스마트워크 센터에서 일할 수 있다.

E-mail이 없다.

• 모든 커뮤니케이션은 이슈관리시스템을 이용한다.
• E-mail은 주로 외부인과만 주고 받는다.
• 내부 모든 커뮤니케이션은 기록이 되고 공유가 되며 추적이 된다.

개발자에게는 가장 빠른 PC가 있다.

• 회사가 감당할 수 있는 한도 내에서 개발자에게 가장 빠른 PC를 지급한다.
• 빠른 CPU와 SSD를 장착하여 빌드 속도를 2배 빠르게 한다.
• 그만큼 개발자는 일을 더 많이 해야 한다. 그리고 정시 퇴근해라.

피어 리뷰가 있다.

• 개발자가 작성하는 코드 대부분을 리뷰한다. 리뷰를 통해서 버그를 찾고 공유, 학습을 한다.
• 더 중요한 것은 스펙, 설계 리뷰다.
• 개발자는 자신의 업무시간의 20%는 동료를 위한 리뷰에 사용해야 한다.
• 시니어 개발자는 20% 이상을 리뷰에 할애한다.

마시고 죽자는 회식이 없다.

• 원치 않는 음주 회식에 참여해서 끌려 다닐 필요가 없다.

즉석 라면이 있다.

• 회사 식당에서 제공하는 아침 메뉴 중에는 즉석 라면이 있다.
• 요리사가 별도로 맛을 낸 해장 라면을 즉석에서 끓여주고 충무김밥이 제공된다.

꼭 지켜야 하는 문화가 있다.

• 공유, 협업, 커뮤니케이션이 꼭 지켜야 하는 문화다.
• 공유와 협업을 철저히 하지 않으면 같이 일을 할 수 없다.

개발 프로세스가 개발 문화를 이기기 어려운 이유

우리나라의 많은 기업들은 SW 개발에 실패를 했다.

그뒤 선진 소프트웨어 개발 방법을 배우고자 노력을 많이 했고, 그 결과 개발 방법론, 프로세스를 도입하였다.

하지만 그 결과 SW개발은 더욱 비효율적으로 바뀌게 되었다. 그 이유는 무엇일까?

SW 개발에 있어서 정교한 프로세스를 정하면 프로세스에 매몰되고 프로세스가 점점 복잡해져 간다.

완벽한 프로세스는 없는 것이 당연하고 문제는 계속 생긴다. 이때마다 이를 해결하기 위한 프로세스를 계속 만들어가면 괴물 프로세스가 탄생하게 된다.

SW를 가장 효과적으로 개발하는 방법은 프로세스에 상관없이 가장 적절한 과정으로 개발하는 것이다. 그 적절한 과정은 성숙한 개발 문화 속에 있다.

하지만 많은 회사들은 애매하고 어려운 개발 문화보다는 명백하고 따라하기 쉬운 개발 프로세스에 집중해왔다. 그 결과 주먹구구식을 개발할 때보다 개발 효율성은 더 떨어졌다.

프로세스를 통해서 효율적인 개발 과정을 제대로 정의하기 어려운 이유는 아래 대화를 보자. 최고의 소프트웨어 실전 전문가에게 질문을 하면 아래와 같이 답을 할 것이다.

 

Q. 모든 소스코드는 코드리뷰를 다 해야 하나요?

A. 아니요, 그때 그때 달라요.

Q. 코드리뷰에 꼭 포함해야 하는 필수 리뷰어는 누구 인가요?

A. 그때 그때 달라요.

Q. 스펙은 꼭 작성해야 합니까?

A. 그때 그때 달라요.

Q. 스펙을 작성할 때 가장 중요한 부분은 어디 인가요?

A. 그때 그때 달라요.

Q. 설계서는 꼭 작성해야 하나요?

A. 그때 그때 달라요.

Q. 효율적으로 설계서를 작성하는 방법은 무엇인가요?

A. 그때 그때 달라요?

Q. 매번 경우마다 다른데 개발 프로세스는 어떻게 정하죠?

A. 그래서 프로세스를 너무 자세히 정하면 안됩니다. 최소한으로 정하고 개발자들의 판단력을 믿어야 합니다.

Q. 대기업은 그래서 프로세스 테일러링을 통해서 프로젝트마다 적절히 프로세스를 간소화해서 산출물도 줄이는 등 개발 프로세스를 효율적으로 적용하려고 노력하고 있습니다.

A. 이 또한 하다하다 안되니까 형식적으로 진행하는 겁니다. 심지어는 개발도 잘 모르는 사람들이 테일러링을 합니다.

Q. 알아서 하라고 하면 과거처럼 스펙도 없고, 공유도 안하고 주먹구구식으로 하지 않을까요?

A. 그렇기 때문에 역량과 문화가 중요합니다. 문화가 아무리 좋아도 역량이 안되면 공염불입니다.

프로세스는 복잡할수록 손해다. 문제만 없다면 프로세스가 없는 것이 제일 좋다. 문제가 있기 때문에 최소한의 제약을 가하는 것이다. 프로세스가 간단할수록 성숙도가 높다. 물론 주먹구구라서 프로세스가 없거나 간단한 회사는 예외다.

하라고 해서 억지로 하는 상황이라면 효과를 기대하기는 어렵다.

문화라고 하는 것은 "왜"가 아니고 "그냥 그렇게" 하는 거다.

그냥 스펙을 적절히 작성하는 것이고, 그냥 필요한 만큼 설계를 하며, 그냥 코드 리뷰를 한다.

모든 직원이 그냥 그렇게 할 수 있을 때 문화로 정착되었다고 할 수 있다.

그렇게 되면 과거로 돌아가자고 해도 모두 반대한다.

프로세스는 절대로 문화를 이기기 어렵다. 효율성이 몇배 차이가 난다. 10배 이상 차이가 날 때도 있다.

프로세스 보다는 SW 개발의 원리를 깨우쳐야 한다. 각 분야에 전문가들이 최소의 프로세스 하에서 최선의 판단을 해서 진행하면 된다.

잘 안된다고 프로세스를 점점 복잡하게 하고 너무 과하게 적용한다면 문제는 점점 커질 것이다.

개발 문화가 점점 성숙해 질수록 프로세스는 만들었다가 간소화 시켰다가 없앴다가를 반복하게 될 것이다. 그래도 신입직원을 위해서 읽을만한 프로세스 문서는 존재하게 된다. 하지만 기존 직원들은 숨쉬는 것처럼 익숙해지고 원리를 깨우쳤기 때문에 프로세스 문서를 계속 보거나 프로세스를 따라하기 위해서 억지로 행하지는 않게 된다.

이쯤되면 SW를 좀 개발할 수 있게 됐다고 자신 있게 말할 수 있다.

개발자가 입사 첫날 버그를 고칠 수 있어야 하는 이유

회사에 새로운 직원들이 입사하면 업무를 가르치느라고 많은 노력이 들어간다. 특히 지식 산업인 소프트웨어 분야는 새로운 개발자가 입사를 하면 알려줘야 하는 것이 매우 많다. 회사마다 다르지만 신규 입사한 개발자가 개발에 투입되는 데는 짧게는 일주일부터 길게는 6개월까지 걸린다. 6개월은 내가 인터뷰 한 회사 중에 있었다. 알아야 할 지식과 법규가 많아서 6개월은 공부를 해야 개발에 투입된다고 한다. 

그러다 보니 입사 후 빨리 업무에 투입될 수 있는 동일직종 경력자를 선호하곤 한다. 이런 회사가 많을수록 개발자들은 이직 시 선택의 폭이 좁아지게 된다. 개발자들이 주로 같은 분야로만 옮겨 다니다 보니 이직도 어렵고 업계간 개발자 순환이 잘 안 된다.  

여기 가상의 A, B, C, D 회사가 있다. 

A사는 김부장이 개발 전반의 내용을 다 꿰뚫고 있어서 신규 개발자가 입사하면 김부장이 1주일 정도 교육을 해줘야 한다. 김부장은 다른 어떤 직원보다 개발 내용을 많이 알고 있어서 웬만한 이슈는 다 김부장을 통해야 해결이 된다. 개발자가 입사를 할 때마다 김부장이 교육을 하기 때문에 개발자들이 김부장에게 많이 의존하고 김부장은 회사의 경영진에게도 신망이 두텁다. 

B사는 개발자 입사 시 개발에 필요한 기본적인 제품에 대한 지식이나 기술을 교육 시키기 위해서 선배들이 돌아가면서 며칠 동안 교육을 해야 한다. 물론 교육을 받자마자 신규 개발자들이 개발을 제대로 하지는 못한다. 사수에게 꾸준히 개발 내용을 전수 받아야 한다. 

C사에서는 업무를 잘 알지 못하면 개발을 하기 어렵기 때문에 업무를 모두 파악하는데 6개월 이상이 걸리고 그때까지는 신규 개발자는 허드렛일 밖에 못한다. 고참이 10분이면 할 수 있는 일을 신규 개발자는 몇 시간이 걸리고 잘못될 위험성도 높아서 신규 개발자에게는 일을 제대로 시키지 못한다. 그러다 보니 신규 개발자가 많이 입사를 해도 고참들은 여전히 바쁘다. 

D사에서는 고참들이 기존 제품의 유지보수에 매달려 있어서 신규 개발자에게 업무를 제대로 전달하지 못한다. 그러다 보니 신규 프로젝트는 신규 개발자들이 담당하게 되었고 기존의 개발자들은 여전히 유지보수에 매달리고 있다. 

A~D사 모두 신규 개발자가 입사하마자 스스로 일할 수 있는 체계를 갖추고 있지 못하고 있다. 이런 구조의 회사는 작은 규모였을 때는 문제가 안보이지만 회사가 커질수록 문제가 급속도로 드러나서 개발 효율은 바닥을 치게 된다. 이런 회사에서는 기존의 고참 개발자들은 신규 개발자들의 무능함과 열정 부족을 탓하게 되고 신규 개발자들은 정보 공유 부족으로 개발하기 어려운 환경을 탓하게 된다. 

필자는 여러 회사에서 강연이나 세미나를 할 때 신규 개발자가 입사 후 개발에 투입되어서 버그를 고치는데 시간이 얼마나 걸리는지 물어본다. 그리고 그 과정에서 고참 개발자들이 얼마나 업무를 가르쳐 주기 위해서 시간을 투자해야 하는지 물어본다. 이 질문에 대한 대답을 통해서 그 회사의 개발체계와 개발 문화의 성숙함을 알 수 있다. 대부분의 회사가 일주일 이상 걸리고 몇 달까지 걸리는 회사도 있었다. 또한 많은 회사들이 사수/부사수 제도를 이용하여 고참들이 많은 시간을 투자하여 가르쳐주고 있다. 

내가 생각하는 가장 이상적인 답변은 고참 개발자들의 시간은 거의 투자하지 않고 신규 입사 개발자가 입사 첫날 또는 둘째 날까지 스스로 버그를 고치는 것이다. 고참들은 코드 리뷰를 해주는 정도면 충분하다. 이렇게 할 수 있는 회사는 자세히 물어보지 않아도 성숙한 개발 체계와 개발 문화를 갖추고 있다는 것을 알 수 있다. 불행히도 필자가 접한 우리나라의 수십 개의 회사 중에서 그런 회사는 없었다. 

미국에 취업을 해본 개발자들은 알겠지만, 개발자가 입사했을 때 선배들이 뭘 자세히 가르쳐주는 회사는 많지 않다. 이슈를 할당해주면 알아서 고쳐야 하고 개발 프로세스대로 코드 리뷰 등을 진행할 뿐이다. 물어보면 가르쳐주기는 하는데 먼저 나서서 가르쳐 주는 경우는 별로 없다. 회사는 학교가 아니기 때문이다. 

필자가 CEO로 있는 이우소프트에서도 신규 개발자에게는 이슈를 그냥 할당해주고 개발자는 하루 이틀 안에 이슈를 해결하고 코드리뷰를 진행한다. 물론 여기에 약간의 문제가 있다. 이제부터 어떻게 해야 이렇게 할 수 있고 문제가 무엇인지 얘기를 해보고자 한다. 그럼 시간 순서대로 따라가보자. 

• 2주일 전 - 신규 개발자용 개발 PC를 준비한다.
• 1주일 전 - 신규 개발자가 입사하기 며칠 전에 PM이 미리 신규 개발자가 해결할 수 있을만한 쉬운 버그 몇 개를 할당 해 놓는다.
• 3일 전 - 신규 개발자용 개발 PC에 개발환경을 구축한다. 이미지 백업 받아 놓은 것을 이용해서 한번에 구축한다. 
• 입사 당일 9시 - PM이 개발자에게 이슈관리시스템 URL을 알려주고, 신규 입사자들이 봐야 하는 가이드가 적혀 있는 사이트 URL을 알려준다. (Wiki 등)
• 10시 - 가이드대로 소스코드관리시스템에서 소스코드를 내려 받아서 Build script를 이용해서 Full build를 수행한다.
• 11시 - Build가 진행되는 동안 PM이 알려준 이슈관리시스템의 URL에 접속해서 내가 할당 받은 버그(이슈)를 확인한다. 첫 번째로 고칠 버그를 선택한다.
• 12시 - 식사
• 13시 - 개발 프로세스 문서를 통해서 기본적인 개발 프로세스를 확인한다.
• 14시 - 첫 번째 버그를 고친다. 첫 번째 버그는 간단한 버그라서 스펙/설계 문서 도움 없이 고칠 수 있다.
• 15시 - 소스코드를 commit하고 코드리뷰를 등록한다. 회사에 따라서 코드리뷰를 종료하고 commit하는 회사도 있다.
• 16시 - 리뷰어가 코드리뷰를 진행하고 Confirm을 한다.
• 17시 - 해당 버그 이슈가 close 된다.
• 이제 좀더 빠른 속도로 다른 버그들을 고쳐나간다.
• 개발자의 역량을 확인하고 좀더 어려운 버그와 신규 기능을 할당한다. 

이렇게 진행하기 위해서는 몇 가지 전제조건이 있다. 

• 개발 시스템이 제대로 구축되어 있어야 한다. 이슈관리, 소스코드관리, 빌드 등이 잘 시스템화 되어 있어야 한다.
• 스펙, 설계, 개발 가이드, 개발 프로세스 등의 개발 정보가 Doc, Wiki, Issue 등에 문서로 충분히 기록되어 있어야 한다.
• 신규 입사자가 이와 같은 개발환경에 익숙해서 입사하자 마자 일을 할 수 있어야 한다.

하지만 현실적으로 마지막 조건에 문제가 발생한다. 대학에서 소프트웨어를 전공한 개발자도 이슈관리시스템을 한번도 써보지 못하고 입사를 하는 경우가 대부분이다. 기껏해야 Subversion이나 Git의 기본기능을 써본 것이 개발 시스템을 써본 것의 전부인 경우가 많다. 그래서 회사에서 아무리 준비가 잘 되어 있다고 하더라도 입사 첫날 버그를 고치기는 어렵다. 그래서 기본적인 개발 프로세스와 개발 시스템에 대한 교육을 먼저 시키고 진행을 해야 한다. 이 때문에 하루, 이틀 지연이 될 뿐이지 그 이후에 개발을 하는 것은 별 문제가 없다. 

이런 환경에 개발을 한다면 본인도 자연스럽게 공유를 중심으로 한 개발 문화를 자연스럽게 익히고 대부분의 지식과 경험은 선배들이 남겨놓은 문서를 통해서 습득하게 된다. 그래서 선배 개발자들은 신규 개발자가 입사를 하면 시간을 더 빼앗기는 것이 아니라 귀찮았던 일을 덜어주게 되고 선배 개발자들은 더 어려운 일을 하게 되고 새로운 일을 할 수 있다. 물론 문서로 모든 지식이 공유되는 것은 아니고 선배에게 물어봐야 하는 시간이 상당히 줄어드는 것이다. 공유를 하고 후배 개발자들이 일을 하기 쉽게 만들어 놓는 것은 바로 자신이 앞으로 나아갈 수 있게 만드는 것과 같다. 

신입 개발자가 입사를 하면 아무 것도 가르쳐주지 말고 버그만 달랑 할당해보자. 그리고 무슨 일이 벌어지는지 보자. 선배를 귀찮게 하지 않고 스스로 첫날 버그를 해결하면 문제가 없는 것이고 2,3일 넘어가도 버그를 못 고치면 뭔가 문제가 있는 상황이다. 어떠한 문제 때문에 신입 개발자가 버그를 고치지 못하는지 잘 분석해보자. 거기에 회사의 만들어 나가야 할 개발체계, 개발문화가 있다. 

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