잠시 중단했던 소프트웨어 국제화 칼럼을 재개한다.
2024년 3월 24일 일요일
소프트웨어 국제화는 나중에 적용하면 늦는다 (24)
2021년 1월 1일 금요일
"소프트웨어 스펙의 모든 것" 책을 출판했습니다.
그동안 블로그를 통해서 연재를 시작했던 "소프트웨어 스펙" 시리즈를 책으로 출판했습니다.
블로그를 통해서 얘기를 시작했지만, 서두 부분만 진행을 했는데, 책을 출판하는 것이 많은 개발자에게 도움이 될 것 같아서 한빛미디어를 통해서 책을 출간하게 되었습니다.
책을 통해서 소프트웨어 프로젝트에서 가장 중요한 스펙에 대해서 익히는데 많은 도움이 될 것입니다.
2020년 10월 17일 토요일
비대면 소프트웨어 개발에 가장 중요한 문서는?
코로나19로 인해 전세계적으로 비대면 업무 방식이 확대되고 있고 소프트웨어 개발도 비대면 개발 방식이 크게 요구되고 있다. 비대면 업무 방식은 업무 효율성 증대와 생산성 향상에 기여를 하기 때문에 코로나19가 아니라도 도입이 필요하다.
글로벌 소프트웨어 회사인 깃랩은 코로나 이전에도 1300명 전직원이 재택근무를 했고, 구글이나 페이스북 같은 글로벌 소프트웨어 회사도 코로나19 이전부터 상당수의 직원이 풀타임 재택 근무를 수행했고, 현재는 재택 근무를 대대적으로 확대하고 있으며 앞으로 전면 재택 근무로 전환하겠다고 하는 회사도 많다. 이렇게 할 수 있는 이유는 이전부터 비대면 개발이 가능한 형태로 일을 해왔기 때문이다.
비대면 소프트웨어 개발을 위해서는 시스템, 프로세스, 문서, 문화 등 여러가지를 갖추고 있어야 한다. 이중에서 문서는 얘기를 해보려고 한다. 소프트웨어를 개발할 때 프로젝트에 따라서 다르지만 여러가지 문서를 작성한다. 이중에서 비대면 개발을 위해서 가장 필요한 문서는 무엇일까?
비대면 개발에 가장 중요한 문서는 스펙
필자가 생각하는 가장 중요한 문서는 “스펙”이다.
“스펙”은 비대면 개발을 위해서만 필요한 것이 아니고 소프트웨어 개발 전체에 가장 핵심적인 문서이다.
과거 80년대 전세계적인 소프트웨어 위기를 극복하기 위해 소프트웨어 공학이 급속히 발전하면서 소프트웨어 프로젝트 성공을 위해서 가장 중요한 요소로 “스펙”을 꼽았다.
2000년 이후 우리나라의 수많은 대기업들이 글로벌 회사로 성장하면서도 소프트웨어 개발의 문제를 겪으면서, 방법론, 프로세스, 고가의 툴 등을 도입하면서 문제를 해결하려고 했으나, 기대만큼 문제를 해결하지 못했고, 몇몇 회사들은 “스펙”의 중요성을 인식하고 “스펙” 작성 역량에 투자를 하고 있다.
많은 회사들이 소프트웨어를 개발할 때 대략의 요구사항을 가지고 개발자들이 밀접히 접촉하여 의논하면서 소프트웨어를 개발한다. “스펙” 문서를 주고, 자신이 담당한 부분을 나눠서 멀리 떨어진 장소에서 일할 수 있는 회사는 그렇게 많지 않다. 이유는 “스펙” 문서를 제대로 작성하지 못하기 때문이다.
애자일이나 스크럼 방식으로 개발을 하는 경우 과거처럼 “스펙” 문서는 필요 없다고도 하는데, 그렇지 않다. 방식만 다를 뿐이지 “스펙”은 필요하다.
다같이 모여서 개발을 한다면 수시로 의논하며, 조율하여 개발을 해나갈 수 있지만, 비대면 개발을 한다면 그렇게 할 수 없다. 자신이 개발할 부분이 명확하게 정의가 되어 있어야 서로 떨어져서 개발을 할 수 있다. 하지만 스펙 문서가 없이 개발하거나 대략의 요구사항을 가지고 서로 모여서 조율해가면서 개발하는 방식에 익숙한 대부분의 회사들은 비대면 개발을 할 수가 없다.
그럼 코로나 이전에도 1300명의 전직원이 재택근무를 하고 있는 깃랩이나, 수많은 직원이 집에서 일하고 있었던 구글이나 페이스북은 어떻게 진작에 비대면 개발을 광범위하게 수행하고 있었을까?
시스템, 프로세스, 문화, 문서 등 여러가지 요소가 있지만, 잘 작성한 스펙이 그중에서 중요한 역할을 한다. 코딩은 개발 단계에서 가장 많은 인원이 참여하는 단계다. 많은 개발자가 서로 떨어져서 일할 수 있도록 스펙을 잘 작성해서 공유하기 때문이다.
여기서 문제는 스펙을 잘 작성하는 것이 소프웨어 개발에서 가장 어려운 주제라는 것이다. 국내 많은 기업들이 소프트웨어 개발 역량을 글로벌 수준으로 끌어 올리는데 여전히 어려움을 겪고 있는 이유도 스펙 작성의 어려움이 한 요소로 작용하고 있다.
스펙 문서는 꼼꼼하게 모든 것을 방대하게 작성하는 것이 잘 작성하는 것도 아니고, 간단하게 작은 문서로 작성하는 것이 잘 작성하는 것도 아니다. 방대한 템플릿을 꼼꼼하게 채우는 것이 올바른 방법도 아니다.
스펙의 역할은 여러가지가 있지만, 개발자 관점에서는 스펙 문서를 보고 자신이 개발한 부분을 충분히 구현할 수 있을 정도가 되어야 한다.
잘 작성한 스펙 문서가 어떤 것인지는 칼럼에서 짧게 다룰 수 있는 주제는 아니다. 그래서 여기서 스펙 문서에 대해서는 구체적으로 자세히 설명하지는 않겠다.
거대한 방법론이나 소프트웨어 공학 이론에서도 소프트웨어 스펙을 작성하는 방법을 이론적으로 다루고 있고, 이를 따라하면 방대하고 복잡한 스펙을 작성해야 한다. 하지만 깃랩, 구글, 페이스북이 이런 방식을 따르고 있지 않다. 이론은 이론일뿐, 실전적인 방법으로 스펙을 작성하고 있다. 대부분의 회사는 이런 이론을 따라하다가는 백이면 백 실패한다.
스펙을 작성하는 방법은 피아노와 골프를 배우듯 실전적인 방법을 배워나가야 한다.
10배의 비용과 시간을 들여서 완벽하게 자세한 스펙문서를 작성할 수 있을지는 몰라도 대부분의 실제 프로젝트에서 그런 방법은 쓸모가 없다.
최소 비용으로 효과적으로 스펙을 작성하는 것이 실전적인 방법이다.
스펙은 목적은 소프트웨어를 최단 시간, 최소 비용으로 개발하기 위한 것
소프트웨어 프로젝트에서 스펙을 잘 작성하는 목적은 소프트웨어를 최단 시간, 최소 비용으로 개발하기 위함이다.
그래서 거대 방법론에서 제안하는 수십가지의 문서를 작성하는 방법은 실전적인 프로젝트에서 효용성이 떨어진다. 많은 회사가 이 방법을 시도했다가 포기하거나 프로세스는 따르지만 정작 소프트웨어 문제를 해결하지 못한 상태가 계속 되곤 한다.
아직도 많은 회사들이 소프트웨어 개발에 문제를 가지고 있다. 대부분의 프로젝트는 계획된 일정에 끝내지 못한다. 그래서 계획된 사업 로드맵에 맞춰 제때 소프트웨어가 출시되지 못해서 많은 사업이 차질을 빚고 있다. 또한 출시된 소프트웨어는 여러가지 문제가 발생하고 유지보수에 어려움을 겪고 있다. 소프트웨어 회사의 사업을 영위하는데 큰 어려움을 주고 있는 것이다.
이러한 소프트웨어 문제를 해결하기 위해서는 소프트웨어 공학에서 언급하는 프로세스, 툴, 품질, 설계, 형상관리 등 여러가지가 다 필요하고 이러한 것들은 충분히 확보가 가능하다.
하지만 가장 근본적이고 어려운 “스펙"을 작성하는 역량을 확보하지만 않으면 넘을 수 없는 벽에 부딪히게 된다. 소프트웨어에 있어서 2류까지는 가능할지 몰라도 1류가 되기는 어렵다.
그래서 나는 기업들이 소프트웨어 문제를 해결하고 구글이나 페이스북과 같은 글로벌 수준의 소프트웨어 개발 역량을 확보하고 싶다면 개발자들이 스펙을 제대로 작성할 수 있는 역량을 확보할 수 있도록 해야 한다고 주장한다.
스펙은 분석 아키텍트가 혼자서 스펙이라는 문서를 달랑 작성하면 되는 것이 아니다. 스펙을 제대로 작성한다는 것은 회사 전체가 같이 움직이는 것을 말한다. 모든 관련자가 요구사항을 충분히 수집에 협조하고, 여러 전문가가 참여를 하며 작성된 스펙 문서에 대해서 관련자들이 철저히 리뷰를 하고 변경관리도 제대로 해야 한다. 모든 직원들은 스펙 문서를 이해하고 읽고 이에 따라서 일할 수 있어야 하고, 개발자는 스펙 문서를 파악하고 떨어져서 개발을 할 수 있어야 한다. 이러한 관행을 갖추려면 많은 노력과 오랜 시간이 걸린다.
여기서 중요한 것은 방법론, 툴이 아니고 문화, 습관, 인식의 변화다. 또한 이런 것을 이끌려면 경영자의 강력한 의지도 중요하다. 몇년전 국내 S사에서 소프트웨어 역량의 근본적인 해결을 위해 내부에서 분석아키텍트를 양성하기 위한 노력을 시작했는데 이런 활동을 매우 긍정적으로 생각한다. 시간이 오래 걸리겠지만, 꾸준히 노력하면 글로벌 수준의 소프트웨어 역량을 갖추는데 중요한 발판이 될 것으로 생각한다.
대기업보다 움직이기 수월한 스타트업이나 중소기업은 노력여하에 따라서 스펙 작성 역량을 확보하기 더 용이하다. 소프트웨어 1류가 되고 싶다면 스펙에 관심을 가지고 스펙 역량을 확보해야 한다.
2020년 9월 18일 금요일
진짜 비대면 업무 방식 vs 가짜 비대면 업무 방식
최근 코로나 19 때문에 비대면 업무 방식으로 전환이 강하게 요구되고 있다. 그러면서 비대면 업무 방식을 많이 추진하고 있는데, 가짜 비대면 업무를 하고 있는 회사도 많다.
비대면 업무 방식은 생산성이 높기 때문에 코로나 19가 아니더라도 도입이 권장된다. 그러면 진짜 비대면 방식으로 일하고 있는지, 가짜 비대면 방식으로 일하고 있는지 9가지 지표로 알아보자.
툴, 시스템
재택근무를 도와주는 솔루션만 도입했다고 진짜 비대면 업무를 하는 것이 아니다.
가짜 비대면 업무를 하는 회사는 몇 가지 특징이 있다. 완전한 비대면 업무 방식으로 일하기 위해서 필요한 시스템과 툴을 충분히 도입하지 않아서 여기 저기 구멍이 있는 경우다. 그래서 수시로 메신저나 이메일로 업무를 물어봐 가면서 처리하고 시스템을 따라 업무가 유기적으로 진행되지 않는다.
또, 부서마다 사용하는 툴이 다른 경우도 있다. 진짜 비대면 업무를 하기 위해서 가장 중요한 시스템이 이슈 관리 시스템인데, 이것을 부서마다 다른 것을 쓰거나 일부 부서만 사용하는 경우다. 그러면 업무 협조 시 상황에 따라서 써야 하는 시스템이 달라서 매우 번거롭고 업무가 물 흐르듯 흐르지 않는다.
하지만 진짜 비대면 업무를 하는 회사는 필요한 시스템과 툴이 촘촘히 잘 구축되어 있고, 서로 연동이 잘 되어 있고, 모든 직원이 동일한 시스템을 쓰며, 내재화가 잘 되어 있다. 그래서 업무가 매끄럽게 흘러가고 한 두개의 대시보드에서 자신의 업무가 다 모니터링 되고, 관리자는 부서의 업무를 한눈에 파악할 수 있도록 되어 있다.
대부분 들어본 시스템과 툴이지만 전사적으로 제대로 구축하여 잘 쓰는 것은 매우 어렵다.
문서 관리
비대면 업무 방식을 주장하면서 문서를 개별 PC에서 작성해서 이메일이나 메신저로 서로 주고받으면서 공유하고, 관리를 하고 있다면 가짜 비대면 업무를 하고 있을 가능성이 높다.
또는 문서 공유 시스템을 쓰기는 하는데, 부서별로 서로 다른 시스템을 사용해서 타부서와 문서를 공유할 때는 이메일이나 메신저 등으로 파일을 전달하는 경우도 있다.
진짜 비대면 업무를 하려면 전사의 모든 문서를 하나의 문서 관리시스템에서 체계적으로 관리하고 있어야 한다. 물론 부서별 업무별로 권한 관리를 잘하여 보안 상으로도 문제가 없어야 한다.
문서의 작성, 협업, 리뷰, 관리, 공유 등 모든 작업이 하나의 시스템으로 관리가 되어야 효율적인 비대면 업무를 할 수 있다.
문서 작성 역량
비대면 업무를 제대로 하기 위해서는 문서 작성 역량도 매우 중요하다.
문서를 많이 작성해야 한다는 의미는 아니다. 대면 업무 방식에서는 문서의 내용이 부족하면 수시로 옆에서 물어가며 일할 수 있지만 비대면 방식에서는 그렇게 하기 곤란하다.
기획 문서, 스펙 문서, 설계 문서 등 여러 종류의 문서들이 문서만 가지고 충분히 내용을 파악할 수 있어야 한다. 100%는 불가능하지만, 80~90% 문서로 충분히 내용을 전달할 수 있는 역량을 가지고 있어야 한다. 물론 이런 문서도 문서 관리시스템에서 협업과 리뷰를 통해서 만들어지므로 잘 작성될 가능성도 높아진다.
가짜 비대면 업무를 하는 회사는 문서를 가지고 일하기 어려워 일할 때 커뮤니케이션이 너무 많이 필요하다. 그래서 옆에 앉아서 같이 일하기를 원한다. 예를 들어 소프트웨어 회사에서 외주를 줄 때 스펙 문서를 기반으로 외주를 주지 못한다. 대략의 기획 문서를 기반으로 외주를 준 후에 요구대로 소프트웨어가 개발이 잘 안되니 옆에 끼고 설명을 해주거나 나중에 프로젝트 일정이나 품질에 문제가 생기는 것이 다반사다.
진짜 비대면 업무를 하기 위해서는 직원들이 모두 말보다는 문서 위주로 일하기 때문에 문서를 제대로 작성할 수 있는 역량이 필요하다. 그래서 채용 시 글을 잘 쓰는 사람을 뽑기도 하고, 직원들에게 글을 잘 쓰고 문서를 잘 작성하도록 교육할 필요가 있다.
물론, 비대면 업무를 계속 하면서 문서 작성을 계속 하고 리뷰를 거쳐 피드백을 많이 받게 되면 누구나 문서 작성 역량이 조금씩은 향상된다.
보고
진짜 비대면 업무를 하는 회사는 별도의 보고가 많이 줄어든다. 또한 보고를 위한 보고는 보기 어렵다.
별도의 보고가 따로 필요하지 않은 이유는 촘촘하게 커버되는 시스템에서 업무의 진행 상황을 훨씬 더 자세히 파악할 수 있기 때문이다.
직원들도 별도의 시간을 들여서 보고서를 작성하지 않고 본연의 업무에 더 많은 시간을 쏟을 수 있다.
하지만, 가짜 비대면 업무를 하는 회사는 업무는 업무대로 다하고, 일일보고, 주간보고 등 여러 형태로 보고서를 작성해서 보고를 해야 한다. 보고 방식은 온라인이라 할지라도 낭비요소가 아닐 수 없다.
관리자는 또 상위 관리자에게 보고를 하기 위해서 직원들의 보고를 취합하여 또 보고를 한다.
보고를 줄이는 것은 진짜 비대면 업무 방식의 증거이자 혜택이다.
화상 회의 빈도
가짜 비대면 업무를 하는 회사는 형식만 비대면이지, 수시로 화상 회의를 실시하여 대면 업무 방식과 별 차이 없이 일한다.
화상 회의는 실제 만나서 얘기하는 것보다는 전달성이 떨어지지만 이동하지 않고 커뮤니케이션을 할 수 있는 장점이 있는 것이다.
하지만 화상 회의를 너무 자주 한다면 차라리 모여서 일하는 것이 더 효율적이다.
회상 회의를 해야 하는 안건이 대부분 이슈 관리 시스템이나 여러 시스템에 온라인으로 등록되고 프로세스를 따라서 처리되며 화상 회의는 꼭 필요할 때 최소화해서 해야 한다. 그래야 진짜 비대면 업무 방식으로 일한다고 할 수 있다.
회상 회의도 비싼 수단이다. 하루의 10~20% 넘는 시간을 화상 회의에 사용하고 있다면 일단 의심을 해보자.
회의 결과 관리
가짜 비대면 업무를 하는 회사는 회의도 자주 하지만 회의 기록이 없거나 회의 결과 해야 할 업무의 추적이 잘 안된다.
그러고는 한참 있다가 “지난 번에 내가 시킨 일 어떻게 되고 있지?”하고 묻는다. 전형적인 대면 업무 방식과 다를 바가 없다.
회의를 자주하는 것과도 관련이 있다. 회의를 계획하에 하지 않고 수시로 소집하기 때문에 회의록도 제대로 남기지 않고 후속 관리도 잘 안된다.
진짜 비대면 업무를 하는 회사에서는 회의 빈도도 적을 뿐만 아니라, 필요한 회의는 미리 계획이 되어 있고 회의 결과가 제대로 정리, 공유되어 있다. 또한 회의 결과로 인해서 해야 할 일은 회사의 온라인 시스템에 등록되어 실시간으로 추적이 된다.
회의록만 보아도 후속 업무의 처리 현황을 실시간으로 볼 수 있도록 시스템이 구축되어 있기도 하다.
예를 들어 소프트웨어 회사의 경우 유지보수를 위해서 소스코드를 볼 때 특정 소스코드의 한 줄만 보아도 해당 줄을 누가 언제 작성해서 관련된 요청은 언제 누가 했으며, 이와 관련된 회의는 언제 누가 진행했고, 결론은 어떻게 나왔는지 줄줄이 모두 몇번의 클릭으로 추적이 된다. 그래서 누가 와서 유지보수를 해도 소스코드의 역사를 훤히 볼 수가 있다.
메신저 사용
가짜 비대면 업무를 하는 회사는 메신저를 끼고 업무를 한다. 회상 회의까지는 아니지만, 수시로 여러 사람에게 메시지를 날리고 이거 저거를 물어본다. 회상 회의보다는 작지만 비용이 많이 들어가는 일이다. 답변을 하기 위해서는 하던 일을 중단해야 한다. 만약에 집중 업무를 하고 있던 경우라면 다시 집중하는데 필요한 시간까지 최소 30분은 그냥 날아간다. 이런 일이 한 두 건이면 모르겠지만, 메신저를 통해서 메시지가 여기저기서 수시로 쏟아지면, 정작 집중해서 본연의 업무를 할 시간이 부족하다.
메신저의 문제점 중 하나가 기록이 체계적으로 남지 않아서 회사의 정보 자산으로 축적되지 않는 다는 것이다.
그래서 메신저는 정보 자산과 관련 업무를 위해서 가벼운 용도로만 최소화해서 사용해야 한다.
편리하다고 수시로 메시지를 날리는 것은 대면 업무 방식과 크게 다를 바가 없다.
업무 만족도
가짜 비대면 업무를 하는 회사는 현재 회사에서 진행하는 비대면 업무 방식에 불만이 많다. 아무래도 과거 대면 방식보다 불편하고 업무 효율성이 떨어지기 때문이다. 원인은 여러가지가 있을 수 있다. 시스템이 충분히 구축되어 있지 않은 채로 강제로 몰아붙일 수도 있고, 역량은 안되는데 과도하게 시스템을 도입한 경우도 있다.
직원들이 충분히 시스템에 적응하지 못한 경우도 있다.
진짜 비대면 업무를 하려면 추가로 시스템이 필요한지, 직원들의 문서 작성 역량 향상이 필요한지, 시스템 사용 교육이 더 필요한지 회사에 따라서 다를 것이다.
대면 업무 방식으로 오랫동안 일하던 회사가 하루 아침에 완전 비대면 방식으로 전환하기는 어렵다. 인식의 전화, 시스템 사용 적응, 문서 작성 역량 등 필요한 것이 한두개가 아니고 수년 걸리는 일도 있다. 전문가의 도움을 받아서 하나씩 하나씩 꾸준히 추진하는 수밖에 없다.
재택근무 가능 여부
가짜 비대면 업무를 하는 회사는 100% 재택 근무를 하지 못한다. 최근 뉴스에 100% 재택 근무를 하고 있는 미국의 많은 회사를 접한다. 1200명 전원이 회사 사무실 하나 없이 100% 재택 근무를 하는 깃랩도 있고, 구글, 페이스북도 100% 재택근무를 하는 직원이 꽤 많다.
하지만 가짜 비대면 업무를 하는 회사는 일주일에 1~3일 정도 재택근무를 하고 나머지는 회사에 나와서 일해야 한다. 또는 재택근무가 가능한 특수한 직군만 100% 재택 근무가 가능하다. 최근 코로나 때문에 이런 식으로 일부 재택근무를 하는 회사가 있다.
물론 재택근무가 100% 우월한 것은 아니다. 대면 업무 방식은 얼굴 보고 일하면서 팀워크가 증가하는 것도 있고, 생활 리듬에 안정을 주는 것도 있다. 하지만 여기서 얘기하는 것은 필요할 때 재택근무를 할 수 있냐는 것이다.
100% 재택근무가 가능해야 진짜 비대면 업무를 하고 있다고 볼 수 있다. 그런 역량을 가지고 모여서 일하는 것은 회사의 선택이다.
2020년 7월 29일 수요일
비대면 소프트웨어 개발을 위한 핵심 시스템 10가지
비대면으로 소프트웨어를 효과적으로 개발하기 위해서는 필수적으로 도입해야 하는 툴, 시스템이 있다. 이 툴 중 대부분은 비단 소프트웨어 개발 뿐만 아니라 회사의 일반 업무에도 필요한 시스템이다. 소프트웨어 회사가 아니라도 관심을 가지고 보자. 툴과 시스템을 도입하는 것은 회사의 문화, 인식, 프로세스를 바꾸는 것보다는 쉽다.
좋은 툴, 시스템을 도입해야 개발 및 업무 효율성이 배가 된다. 툴, 시스템은 오랫동안 진화를 해왔고, 지금도 진화하고 있다. 이것들을 잘 선택하는 것도 실력이다. 워낙 많은 툴, 시스템을 도입해야 하기 때문에 선택도 쉽지는 않다. 그렇다고 잘 도입해서 사용하고 있는 한 회사의 사례를 그대로 따라하는 것도 좋은 것은 아니다. 회사마다 프로젝트의 성격, 규모, 문화, 환경이 다르기 때문이다.
꼭 비싼 툴을 도입하는 것이 좋은 것은 아니다. 그렇다고 무료 툴이 무조건 좋은 것도 아니다. 비싼 툴은 비싼 값을 하지만 기능이 너무 많거나 복잡해서 회사에 따라서는 오히려 과한 경우도 있다. 회사의 규모, 문화, 프로세스에 따라서 적합한 툴의 조합을 잘 선택해야 한다.
툴, 시스템을 도입하는 것은 쉽지만 잘 쓰는 것은 어렵다. 도입만 하고 안쓰거나 형식적으로 쓰는 경우도 많다. 툴만 도입하고 프로세스와 연계를 안하거나 회사의 상황에 너무 과한 툴, 시스템을 도입한 경우에도 정착에 실패할 수 있다.
회사의 기존 프로세스를 잘 적용할 수 있는 시스템을 선택하기 보다는 툴, 시스템의 철학에 맞게 회사의 프로세스와 업무 방식을 바꾸는게 낫다. 업무 방식은 좀더 자율적이고 능동적이어야 하며 수평적으로 바뀌어야 한다. 그래야 비대면 업무가 효율적으로 진행될 뿐만 아니라 생산성도 증가한다.
각 툴, 시스템들은 서로 연결이 되어서 유기적으로 작동한다. 한 회사에서 개발한 여러 툴 세트를 쓰면 연동이 잘 되기는 하지만 그렇다고 한 회사의 툴을 쓰는 것이 무조건 좋은 선택은 아니다. 회사의 프로세스와 잘 엮어서 여러 회사의 툴을 섞어 사용하기도 한다.
그럼 비대면 소프트웨어 개발을 위해서 꼭 도입해야 할 시스템을 알아보자.
1. 문서 공유 시스템
문서들이 직원들의 각자 PC에서 생산되고 이메일을 통해서 돌아다닌다면 보통 혼란스러운 것이 아니다. 문서의 버전을 관리하기도 어렵고, 보관도 어렵다. 문서 공유 시스템을 도입하면 문서의 버전을 철저히 관리하고 적절한 공유, 권한 제어, 외부 전달, 백업이 가능하다. 비용이 들기는 하지만 비용 이상의 생산성 향상을 줄 수 있는 시스템이다.
가장 마음이 드는 기능 중 하나는 검색 기능이다. 시스템마다 차이는 있지만 회사의 수만 개의 문서 중에서 내가 찾는 문서를 간단한 검색을 통해서 몇 초 만에 찾아준다. 문서의 본문까지 모두 찾아주는 시스템도 있으니 매우 편리하다.
몇몇 문서 공유시스템은 PC의 파일 탐색기와 연동하여 편리하게 사용할 수 있도록 해준다.
회사의 문서를 외부 공간인 클라우드에 저장하는 것에 보안 상 우려를 하는 기업도 있지만, 회사 내부에서 여기저기 문서가 굴러다니는 것보다 더 안전할 수 있다.
대표적인 시스템으로는 Dropbox, Apple iCloud, Google Drive, MS Sharepoint, Amazon WorkDocs 등이 있다.
국내 기업으로는 사이버다임사의 문서관리시스템이 있다.
2. 문서 공동 작업/리뷰 시스템
문서 공유 시스템과 접목하여 문서를 공동 작업 및 리뷰할 수 있도록 하는 시스템이다. 여러 사람이 동시에 문서를 작업해도 충돌 없이 같이 작업할 수 있다. 완벽한 문서 공동 작업 솔루션이 나온 것은 그렇게 오래되지 않았다. 불과 수년 전만 해도 상상하기 어려웠던 기능인데, 이제는 일반화 되었다.
문서를 리뷰할 수 있는 기능도 제공한다. 문서 리뷰를 실시하면 여러 관련자가 문서의 곳곳에 자신의 의견을 댓글로 남기면서 토론을 할 수 있다. 그 결과를 문서에 반영하고 다시 리뷰를 진행하는 사이클로 진행된다. 이렇게 문서 온라인 리뷰를 진행하면 관련된 모든 사람의 의견을 꼼꼼히 문서에 반영할 수 있다. 이런 시스템 없이 오프라인으로 문서를 리뷰하고 반영하는 것은 보통 어려운 일이 아니다. 오프라인으로 문서를 작성한 것보다 훨씬 완성도 높은 문서를 작성할 수 있다.
이렇게 문서를 온라인으로 보관하고 공동 작업하고 리뷰하는 프로세스를 적용하고 적응해 나가면 어느덧 비대면 업무 방식에 익숙해져 간다.
대표적인 시스템으로는 MS Office 365, Google Docs, Apple iWork 등이 있다.
3. 요구사항 관리 시스템
소프트웨어를 개발하는데 있어서 가장 중요한 것 하나를 꼽으라면 요구사항을 분석해서 스펙을 작성하는 일이다. 스펙을 문서화 하기 위해서 MS Word로 작성하기도 하고, GoogleDocs, Wiki를 이용하기도 하지만, 전문적인 관리시스템을 사용하기도 한다.
MS Office와 같은 문서 위주의 편집 툴을 사용하여도 소프트웨어 요구사항을 충분히 분석하고, 협업하고, 리뷰할 수 있지만, 전문적인 요구사항 관리 시스템은 조금 더 많은 기능을 제공한다.
요구사항을 수집, 관리, 협업, 리뷰, 버전 관리, 요구사항 추적, 재활용 등에서 좀더 많은 기능 및 편리함을 제공한다. 요구사항 분석 역량을 충분히 갖춘 회사라면 한번 도입해 볼만하다.
대표적인 시스템으로는 Jama, Orcanos, DOORS, ReqSuite, Accompa 등이 있다.
4. 이슈 관리 시스템
이슈 관리 시스템은 소프트웨어 회사만 필요한 시스템이 아니다. 이슈 관리 시스템은 버그 관리 시스템에서 출발하여 점차 진화를 거듭하여 회사의 모든 이슈를 관리하는 시스템으로 성장하였다. 이제는 거의 모든 형태의 회사에 필요한 시스템이 되었다.
이슈 관리 시스템은 단순히 설치해서 사용하는 것 만으로는 그 혜택을 다 볼 수 없다. 회사의 업무 철학과 방식이 바뀌어야 한다. 업무 방식을 지시와 보고 형태에서 자발적 업무와 모니터링 형태로 바뀌어야 한다. 일일이 업무를 지시하고 추후 결과 보고를 받는 형태로 업무를 계속 하면서 그 프로세스를 이슈 관리 시스템에 적용하면 비대면 프로세스로 전환하기도 어렵고, 이슈관리시스템의 철학과는 좀 멀어지고 업무 효율성도 떨어진다.
이슈 관리 시스템이 완전히 정착되면 모든 업무가 투명하게 진행되는 효과가 있다. 투명한 업무 진행을 꺼려하는 조직도 있지만, 적응하고 나면 업무 생상선이 대폭 증가하는 것을 경험할 수 있다.
이슈 관리 시스템을 도입하여 효과를 최대로 보고 비대면 업무를 효율적으로 진행하려면 업무 방식을 바꾸는 것에 많은 노력을 들여야 한다는 것을 명심하자.
대표적인 시스템으로는 Jira, Redmine, Mantis, Bugzilla, Trello 등이 있다.
Jira는 상용 소프트웨어지만 현재 10유저까지는 무료로 제공하고 있어서 스타트업에서 매우 유용하게 쓸 수 있다.
5. 소스코드 관리 시스템
소스코드 관리 시스템을 사용하지 않는 소프트웨어 회사는 거의 없을 것이다. 만약에 특별한 이유로 소스코드 관리 시스템을 사용하고 있지 않다면 꼭 도입을 해야 한다. 특별한 이유라는 것도 소스코드 관리 시스템을 사용하지 못하는 결정적인 이유는 아닐 것이다.
소스코드 관리 시스템은 도입은 쉽지만 제대로 쓰는 것이 만만치는 않다. 브랜치, 머지, 베이스라인, 체크인에 대한 여러가지 규칙을 잘 만들고 지켜야 한다.
소스코드 관리 시스템은 중앙 집중형과 분산형이 있으니 회사의 상황에 맞게 선태하면 된다.
대표적인 시스템으로는 Subversion, Git, Murcurial, Perforce 등이 있다.
설치형, 클라우드 형이 있으며, 클라우드 형으로는 Github, Gitlab, Bitbucket 서비스 등이 있다. 각자 유/무료 정책이 있으니 비교하여 선택하면 된다.
6. CI(지속적인 통합) 시스템
개발자들이 서로 떨어진 장소에서 얼굴 안보고 실시간으로 협업을 하기 위해서는 소스코드가 항상 빌드가 가능한 상태로 유지가 되어야 한다. 소스코드는 매시간, 매분 새로 업데이트가 된다. 그런데, 한 개발자가 빌드가 안되는 상태의 소스코드를 등록하면 개발팀 전체가 개발에 차질이 생긴다. 개발자는 항상 빌드 가능한 소스코드를 등록해야 하며 이 규칙은 매우 엄격하다.
CI(지속적인 통합) 시스템을 이용하면 소스코드를 등록할 때마다 소스코드를 점검하고, 빌드 가능한 상태를 유지하도록 도와준다. 이때 회사의 코딩 규칙 검사, 자동 테스트 등을 수행하며 소스코드의 버그를 줄여주기도 한다.
CI 시스템이 잘 구축되어 있으면 개발자는 자신이 담당한 모듈을 코딩해서 소스코드 관리시스템에 등록하기만 하면 된다. 나머지는 시스템이 알아서 해준다.
대표적인 시스템으로는 Jenkins, Bamboo, Cirble CI, GitLab CI 등이 있다.
7. 코드 리뷰 시스템
코드 리뷰는 온라인, 오프라인으로 진행하며 여러가지 방법이 있지만, 비대면 개발을 위해서는 코드 리뷰 시스템이 필수다. 모여서 코드 리뷰를 할 필요가 없고, 온라인 코드 리뷰 시스템에 코드 리뷰를 등록하면 관련된 수많은 사람이 온라인으로 코드 리뷰를 진행한다. 온라인 코드 리뷰는 오프라인보다 훨씬 많은 사람이 참여할 수 있고, 시간을 많이 절약해준다. 그래서 코드 리뷰를 좀더 활성화하는데 도움을 준다.
회사의 프로세스마다 다른데, 소스코드를 등록한 후에 코드 리뷰를 하기도 하고, 코드 리뷰를 통과한 소스코드만 회사의 메인 소스코드 저장소에 등록하도록 하기도 한다.
코드 리뷰가 활성화 된 회사일수록 개발자가 더 잘 성장한다. 그리고 고참 개발자가 될수록 코드 리뷰에 더 많은 시간을 할애해야 한다. 고참 개발자는 코드 리뷰를 통해서 후배를 양성하기도 하지만, 본인이 성장하는 수단이 되기도 한다.
많은 회사들이 코드 리뷰 도입에 실패하지만, 좋은 온라인 코드 리뷰 시스템을 도입하면 코드 리뷰 정착에 도움이 된다.
대표적인 시스템으로는 Gerrit, Crucible, GitHub, GitLab, Review Board 등이 있다.
8. 지식 공유 시스템
소프트웨어 회사만 필요한 시스템은 아니다. 회사에서 업무를 하다 보면 공유할 수많은 정보, 지식이 생성된다. 지식 공유 시스템이 없다면 이런 정보는 연기처럼 사라지거나 개인의 저장소에 묵히게 된다.
정보를 생산할 때 실시간으로 정보를 정리하여 공유할 시스템이 필요하다. 그래서 지식 공유 시스템은 비대면 개발의 핵심이다.
회사, 제품, 프로젝트, 프로세스 등 여러가지 분야로 잘 나뉘어서 정리된 지식과 정보는 이 사람 저 사람 찾아다니면서 물어보지 않아도 업무를 할 수 있게 해준다. 원격으로 접속 가능한 시스템이므로 지역적인 제약없이 일할 수 있다.
대표적인 지식 공유 시스템은 Wiki와 KMS다. Wiki의 용도는 매우 다양하다. 이를 회의록으로 사용하는 경우도 많고 회의록 기능을 강화한 Wiki 시스템도 있다.
설치형, 클라우드형이 있다. 장단점이 있으니 상황에 맞게 선택해야 한다.
대표적인 Wiki 시스템으로는 Confluence(10유저 무료), Bookstack(무료), Wiki.js(무료) 등이 있다.
KMS는 국내업체인 사이버다임과 날리지큐브가 제공하고 있다.
9. 화상 회의 시스템
비대면 개발을 하더라도 얼굴을 보고 회의를 해야 할 때도 있다. 재택 근무가 완벽하게 진행되어 모든 업무를 문서와 시스템으로 진행한다고 하더라도, 정서상의 이유와 팀워크 유지를 위해서 얼굴을 보고 얘기를 할 필요도 있다. 또 온라인으로, 문서로 쉽게 답이 안나오는 이슈는 얼굴 보고 논의하는 것이 훨씬 효율적이다. 이럴 때는 웹캠을 이용해서 화상 회의를 실시하는 것이 좋다.
화상 회의는 주기적인 프로젝트 회의로 진행하기도 하고, 이슈가 있을 때 비정기적으로 실시하기도 한다.
회상 회의는 1:1 뿐만 아니라 여러 명이 동시에 회의를 할 수도 있다. 여러 명이 원활히 화상 회의를 하기 위해서는 빠른 인터넷도 필수다. 화상 회의는 일반 회의와 마찬가지로 용건만 짧게 빠르게 진행해야 한다.
화상 회의 시스템은 부가 기능으로 녹화, 화면 공유, 화이트 보드, 그룹 스케줄러 기능을 제공하기도 한다.
대표적인 시스템으로는 Teams, Skype Business, Google Meet(hangout), Zoom 등이 있다.
10. 협업 시스템
협업을 위한 여러가지 기능을 한꺼번에 넣어 놓은 종합 선물세트다. 소프트웨어 회사 뿐만 아니라 모든 형태의 회사에 비대면 업무를 효율적으로 진행하기 위해서 필요한 시스템이다.
기본적으로 팀 관리, 채팅, 파일관리 등이 기본 기능이지만 화상 회의, Wiki 등 위에서 언급한 여러가지 툴 중 일부를 포함하고 있는 경우도 많다.
비대면 업무 필요성이 증가할수록 도입하는 기업이 늘 것으로 생각된다.
대표적인 시스템으로는 Teams, Slack, Swit, 잔디, 라인웍스 등이 있다.
이상 10가지의 시스템을 알아봤는데, 이런 시스템을 모두 사용한다고 완벽하게 비대면으로 소프트웨어를 개발할 수 있는 것은 아니다. 또한 모두 비대면으로 소프트웨어를 개발해야 더 생산성이 높은 것은 아니다. 시스템을 잘 활용하여 개발과 업무를 진행하면 비대면 비율이 높아질 수 있다. 그 자체가 개발 및 업무 생산성이 높아지는 것과 일맥상통한다.
2020년 7월 10일 금요일
코로나19 시대에 비대면 소프트웨어 개발이 필수
개발 비용이 적게 들기 때문이다.
미국에서는 이미 약 20%의 개발자는 재택근무를 하고 있다.
스펙 문서를 보고 개발자가 개발을 못한다.
위기가 곧 기회
2020년 4월 26일 일요일
[Software Spec Series 11] 스펙 문서에 대한 오해
문서 이름이 문제
일단, 스펙 문서라고 하여 여러가지 이름의 문서가 사용되고 있다. “기능명세서”, “요구사항 기술서”, “시방서” 등이 있다. 하지만 이런 문서를 보면 이름만 봐도 스펙 문서라는 생각이 안 든다. 왠지 스펙의 극히 일부분의 내용이 적혀 있을 것으로 생각되고 실제로 내용을 보면 이름에 걸맞게 내용도 반쪽짜리 또는 극히 일부의 내용만이 언급되어 있다. 나름 노력을 해서 스펙 문서라고 적어서 이를 토대로 프로젝트를 진행하지만 주먹구구식 프로젝트보다 약간의 진보가 있을 뿐 큰 차이는 없다. 스펙 문서는 이름도 중요하다. 누가 봐도 스펙 문서라는 것을 알 수 있도록 SRS라고 부르거나 Specification이라는 말이 들어간 이름을 쓰는 것이 좋다.
문서 내용의 문제
“기능명세서”, “요구사항 기술서”, “시방서” 등의 이름을 가진 문서들은 대부분 요구사항이나 기능에 집중된 내용이 들어 있다. 그래서 이런 문서는 “스펙”이라고 하기에는 반쪽짜리 문서다. 스펙 문서는 비전, 전략, 기능, 환경, 비기능, 시스템 특성 등 여러가지를 포함해야 한다. 또한 요구사항도 그대로 적는 것이 아니라 잘 분석이 되어서 여러 기능이나 비기능으로 분해가 되어 있어야 한다. 이런 분서에서 빠져 있는 내용은 프로젝트를 진행하면서 수많은 문제와 혼동을 야기할 것이다.
절차의 문제
“스펙” 문서라고 하면 일반적으로 인정하는 프로세스가 있다. 작성과 리뷰, 승인 과정을 거친다. 그래서 책임을 지고 작성하는 “분석 아키텍트”가 정해지고 프로젝트에서 적절한 분석 시간을 할당 받는다. 분석 활동으로 공식적으로 인터뷰, 워크샵, 관찰, 토론 등을 진행할 때 이해관계자들의 협조를 받으며 공식 리뷰에 많은 이해관계자들이 자신의 의무를 다하기 위해서 신중하고 꼼꼼하게 리뷰를 하고 승인을 한다. 승인에 대한 압박감도 상당하다. 우리는 “스펙”이라는 용어를 듣는 순간 이러한 프로세스도 거쳤을 것이라고 생각을 한다. 이런 절차 없이 개발팀에서 알아서 작성해서 진행을 하면 안된다.
필자는 “스펙”, “소프트웨어 스펙” 또는 “SRS”라는 용어를 사용하길 권장한다. 이런 용어를 사용해서 대화를 한다면 서로 같은 의미로 소통을 하고 있을 가능성이 높다. 특히 외국인 개발자를 채용하거나 글로벌 업체와 협력을 하게 된다면 용어의 사용은 매우 중요하다. “스펙”, “SRS”라는 용어로 소통을 하고 문서를 작성할 때 외국 업체와의 협업이 더 원활할 것이다. 물론 용어만 쓴다고 되는 것은 아니다. “스펙”, “SRS”를 제대로 작성할 수 있어야 한다.
share abctech.software
2020년 4월 12일 일요일
[Software Spec Series 10] 요구사항과 스펙의 차이
“요구사항"이라는 용어는 소프트웨어 업계 외에서도 일반적으로 의미와 비슷한 뜻으로 사용된다. 고객이나 이해관계자가 요구하는 것을 뜻한다. 하지만 소프트웨어 “스펙”은 좀 다른 의미를 가지고 있다. 그래서 수많은 회사에서 또, 여러 개발자들이 그 의미를 미묘하게 서로 다르게 생각하고 있나보다. “스펙”도 소프트웨어 업계 외에서도 많이 사용한다. 취업 시장의 후보자도 “스펙”이란 용어를 쓰고, 스마트폰 등 디바이스도 “스펙”이란 용어를 쓴다.
일반적인 의미로 소프트웨어도 “스펙”은 비슷한 의미를 가지고 있지만, 소프트웨어 “스펙”이라고 하면 머리 속에 그려지는 모습이 있다. 그리고 그 모습은 전세계 개발자들이 공통적으로 생각하는 것이 있다. 적어도 이런 내용들이 포함되어 있고 이런 절차를 통해서 만들었을 것이라는 생각을 할 수 있다.
그래서 요구사항은 한 줄 또는 몇 줄에 불과하지만 그 요구사항을 잘 분석해서 스펙을 작성하면 수 페이지 또는 수십, 수백 페이지의 문서가 될 수도 있다. 그래서 스펙을 제대로 작성하지 않고 요구사항만 가지고 프로젝트를 시작하면 큰 재앙이 닥칠 수 있다. 특히 외주 프로젝트라면 그 재앙은 회사를 매우 어렵게 할 수도 있다.
내부에서 진행하는 프로젝트든 외주나 SI로 진행하는 프로젝트든 스펙을 제대로 작성하지 않고 요구사항 수준의 요청으로 진행을 하면 분석이 제대로 되지 않았기 때문에 프로젝트를 진행하는 내내 수많은 문제가 발견되고 난상토론, 불 끄기, 고치기 반복이 발생한다. 물론 스펙을 적절히 잘 작성하면 이런 문제 상황을 훨씬 줄어든다.
지금도 수많은 사람들이 “요구사항”과 “스펙”이란 용어를 혼동해서 사용을 하고 있다. “요구사항”과 “스펙”의 차이를 사전적으로 아무리 설명해도 그 차이를 실감하기는 불가능하다. 외울 수는 있어도 금방 잊어버려서 실전 개발 프로젝트에 적용을 하지 못한다. 유일한 방법은 소프트웨어 “스펙”의 원리를 제대로 이해하면 “요구사항”과 “스펙” 차이를 명확하게 알게 된다. 그래서 이 시리즈에서는 “스펙”의 원리에 대해서 자세히 다루고 있다.
(요구사항과 스펙의 차이) |
2020년 3월 29일 일요일
[Software Spec Series 9] 여러 종류의 스펙 문서 유형
이슈관리시스템의 한 줄 또는 몇 줄의 설명
스펙이라고 하면 수십에서 수백페이지의 문서를 먼저 떠올리지만 상황에 따라서는 Jira나 Redmine과 같은 이슈관리시스템의 이슈 하나, 또는 한 줄이 스펙이 될 수도 있다. 보통 작은 유지보수를 위한 변경에서 주로 적용되지만 무엇을 개발해야 하는지 명확하게 정의가 된 것이라면 한 줄 또는 몇 줄의 글이라도 훌륭한 스펙이 될 수 있다.
엔지니어링 One-pager
SRS 등의 제법 큰 템플릿을 가진 문서에 정식으로 스펙을 작성하기에는 프로젝트의 규모가 작거나 이슈가 별로 없을 경우에 작성을 한다. 이슈관리시스템에 간단히 이슈를 정리하고 진행하기도 하지만 굳이 엔지니어링 One-pager라는 문서를 작성하는 이유는 스펙을 작성하는 정식 절차를 밟기 위함이다. One-pager라도 스펙을 일단 작성하면 공식 리뷰를 거쳐서 여러 사람의 의견이나 도움을 공식적으로 받을 수 있다. 그러면 개발하려고 하는 방향이 맞는지 이미 다른 팀에서 비슷한 것을 개발하거나 검토해 놓은 것이 있는지 더 좋은 방법은 없는지 의견을 받을 수 있다. 또한 One-pager의 내용은 공식적으로 다른 사람, 다른 팀에게 공유가 되어서 회사내에서 지식 공유에 도움이 된다.
보통 다음과 같은 경우에 엔지니어링 One-pager를 작성한다.
- 메모리를 50% 절약하는 알고리즘 구현 시도
- 최신 버전의 Visual Studio로 이식하는 프로젝트
- 새로운 그래픽 엔진으로 교체를 하는 일주일짜리 프로젝트
수십페이지의 SRS
가장 일반적으로 스펙을 작성하는 방법이다. 비즈니스 전략, 환경, 기능, 비기능, 성능 등 소프트웨어를 개발하면서 고려해야 할 대부분의 내용이 포함되어 있다. 이 책에서는 SRS에 대한 내용을 자세히 다룰 것이다.
수백, 수천페이지의 거대 방법론의 스펙 문서
거대 방법론에서는 문서를 수십개 이상 작성하기도 한다. 이런 방법론에서는 스펙이 하나의 문서로 정리되는 것이 아니고 여러 개의 문서에 분산되어서 작성된다. 장점으로는 프로젝트에 투입된 역할별로 필요한 문서를 정해서 보면 되는 것이다. 단점으로는 중복이 많이 발생하고 하나의 업무를 하기 위해서 매우 많은 문서를 봐야 한다. 또한 한번 작성하고 나면 수정이 매우 어렵다. 아래와 같은 문서들이 그 예다.
- 요구사항정의서
- 업무기능분해도
- 업무흐름도
- 액터카달로그
- 유스케이스 다이어그램
- 논리 ERD
- 도메인 엔티티 정의서
- 분석패키지 다이어그램
- 코드정의서
- 인터페이스 정의서
- 컴포넌트 명세서
- 화면 정의서
- 메뉴 구조도
기타
- 테스트 코드로 스펙 작성하기
- 소스코드로 스펙 작성하기
- 유저 스토리
2020년 3월 15일 일요일
[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
2020년 2월 16일 일요일
[Software Spec Series 6] 스펙과 프로젝트의 성공
많은 프로젝트들이 첫번째 버전을 성공했다가 이를 업그레이드하는 두번째 프로젝트에서 실패를 한다. 이를 “두번째 버전 신드롬”이라고 부른다. 첫번째 버전은 규모도 작고 적은 인원으로 진행을 해서 성공 확률이 높았지만 첫번째 제품의 성공을 기반으로 두번째 버전을 만들 때는 프로젝트의 규모가 커지면서 실패 확률이 확 높아진 것이다. 부실한 스펙 하에서 개집 만들기에 성공해 놓고 스스로 마천루를 개발할 수 있다고 착각하면 안된다.
스펙과 프로젝트 성공 확률의 상관관계를 아래 그래프로 살펴보자. 감을 잡기 위해서 개념을 설명하는 것이다. 숫자적인 의미를 부여하려는 것이 아니다. 프로젝트 성공과 관련된 수많은 요소가 있지만 그 중에서 스펙과의 관계만 살펴보자.
(프로젝트 규모와 프로젝트 성공확률과의 성관관계) |
스펙을 부실하게 작성하면 프로젝트의 규모가 커지면서 프로젝트 성공 확률이 확 떨어지지만 스펙을 잘 작성하면 프로젝트의 규모가 커져도 프로젝트 성공 확률이 급격히 줄어들지 않는다.
share with abctech.software
2020년 1월 19일 일요일
[Software Spec Series 4] 스펙의 역할
모든 프로젝트 이해관계자가 사용, 프로젝트의 중심
스펙은 프로젝트의 모든 요구사항이 모이며 프로젝트의 중심이 되는 문서다. 프로젝트의 모든 이해관계자가 스펙을 참조하거나 작성에 참여한다. 스펙은 다시 여러 프로젝트 이해관계자들이 받아서 자신의 역할을 수행한다. 프로젝트에서 가장 중요한 문서 하나를 꼽으라고 하면 스펙이다.
(프로젝트의 모든 이해관계자가 참조해야 하는 SRS) |
고객, 마케팅 부서, 영업 부서는 어떠한 제품이 만들어지는지 알 수 있다.
스펙이 없거나 부실한 상태로 진행하는 프로젝트는 프로젝트가 완료되기 전까지 어떠한 소프트웨어가 개발될지 알기가 어렵다. 그러면 영업부서는 소프트웨어 개발이 완료되기 이전에 판매 준비를 하거나 계약을 할 수가 없다. 스펙이 잘 작성된 프로젝트인 경우 스펙만 보고도 최종적으로 개발될 소프트웨어가 무엇인지 정확하게 알 수 있다. 영업부서에서는 이를 보고 판매에 필요한 준비를 할 수 있다. 영업망을 확충하거나 세일즈 자료를 준비할 수 있다. 또한 고객을 만나서 개발도 완료되지 않은 소프트웨어를 미리 팔 수도 있다. 소프트웨어 개발이 완료된 후에 부랴부랴 판매를 시작한다면 이미 상당한 판매 기회를 놓치게 된 것이다. 그 외에 안전, 의료, 보안 등의 인증이 필요한 경우도 스펙이 잘 작성되어 있다면 소프트웨어 개발이 완료되지 않았음에도 인증을 신청해서 인증을 미리 획득할 수 있다. 인증은 종류에 따라서 1년 넘게 또는 수년이 걸리기도 한다. 소프트웨어 개발이 완료된 후에서야 인증을 진행하면 수년의 영업 기회를 날려버릴 수도 있다.
프로젝트관리자(PM)에게는 스펙이 프로젝트 관리의 기준이 된다. 일정산정, 인력 배분, 리스크 분석 등을 할 수 있다.
스펙이 제대로 작성되지 않는 프로젝트에서 프로젝트 관리자는 별로 할 일이 없다. 일정을 제대로 예측하기도 어렵고, 리스크 파악도 어렵다. 적정한 리소스 계획을 세우지 못한다. 프로젝트가 진행이 되도 정확하게 진척률을 파악할 수가 없다. 그래서 1년짜리 프로젝트가 8개월쯤 지나도 정확하게 1년 안에 프로젝트가 종료될지 예측이 안된다. 그러면 프로젝트 관리자는 프로젝트 성공을 위해서 무엇을 더 해야 하는지 알 수 없다. 그저 운에 맡기는 수밖에 없다. 프로젝트의 성격에 따라서는 단계별로 진행을 하여 짧은 주기로 여러 차례 업그레이드를 하면서 진행하는 경우도 있다. 이 경우도 주기만 짧을 뿐이지 짧은 주기에 해당하는 스펙을 적절히 작성하는 것도 똑같이 필요하다.
개발팀은 스펙을 통해서 개발팀이 개발해야 할 제품이 무엇인지 정확하게 알 수 있다.
스펙을 제대로 작성하지 않았다면 개발팀은 정확하게 무엇을 개발해야 하는지 파악하기 어렵다. 기획자나 분석 아키텍트에게 너무 많은 것을 수시로 물어봐야 해서 시간을 매우 낭비해야 한다. 개발자가 임의대로 생각해서 기능을 구현하게 되면 기획의 의도와는 완전히 다르게 되기도 한다. 개발자에게 주어진 너무 높은 자유도가 소프트웨어 아키텍처를 부실하게 만들기도 한다. 개발자에게 자유도는 필요하지만 소프트웨어 전체 아키텍처는 분석, 설계 시에 정해져서 개발자에게는 한정된 자유도만 주어야 한다. 그래야 기획 시 의도된 소프트웨어가 제대로 개발될 수 있다.
(프로젝트에서 SRS의 위치) |
테스트팀은 스펙을 통해서 테스트 계획 및 테스트 케이스를 작성할 수 있다.
보통은 스펙 작성 후에 개발자들이 구현을 하는 동안 테스트팀은 테스트 준비를 한다. 테스트 계획을 세우고 테스트 설계를 해야 한다. 하지만 스펙이 없거나 부실하다면 테스트팀은 테스트 준비를 제대로 할 수가 없다. 소프트웨어가 개발된 후에 소프트웨어를 보면서 테스트 준비를 해야 하는데 이 방법으로는 테스트 일정도 예측할 수 없고 부실한 테스트를 할 수 밖에 없다. 소프트웨어 품질이 나빠지는 것은 당연한 결과다.
기술문서팀은 스펙을 통해서 매뉴얼과 도움말을 작성할 수 있다.
소프트웨어 스펙이 완성된 후에는 많은 일들이 벌어진다. 기술문서팀은 소프트웨어를 동작시켜 보지도 않고 매뉴얼을 미리 작성한다. 단지 화면 캡쳐만 소프트웨어 개발 후 추가할 뿐이다. 이뿐만 아니다. 고객지원 부서는 고객 지원에 필요한 준비를 해 놓고 교육팀은 교육 준비를 한다. 이처럼 소프트웨어 스펙을 보고 많은 사람들이 자신의 일을 수행해야 하는데 바쁘다고 스펙 없이 개발을 하는 것은 개발자 중심의 사고방식이며 프로젝트가 효율적으로 진행되지도 않는다.
외주 업체는 스펙을 통해서 외주 업무를 정확하게 파악하고 SRS를 기준으로 계약을 할 수 있다.
우리나라에서는 많은 소프트웨어 프로젝트가 스펙도 없이 진행이 된다. 대략의 요구사항을 기반으로 계약하고 진행되는 프로젝트는 정상적으로 진행되기 어렵다. 고객이 수시로 요구사항을 무리하게 바꿔도 하소연하기 어렵다. 또한, 분석을 제대로 하지 않고 진행을 하므로 요구사항만으로는 프로젝트의 규모를 제대로 산정하기 어렵다. 그래서 계약 시는 성공적인 계약으로 생각되지만 프로젝트를 진행할수록 손해를 보는 경우도 허다하다. 우리나라도 스펙을 기준으로 계약을 하는 관행이 자리잡아야 한다.
share with abctech.software
2020년 1월 5일 일요일
[Software Spec Series 3] 스펙에 대한 오해의 증거
스펙을 적는 것이 좋은 줄 몰라서 안 적는 게 아니다.
소프트웨어를 만들어 보기 전에는 천재도 내용을 다 알 수 없다.
나도 작성할 줄 아는 데 적을 시간이 없다.
나도 작성해 보았는데 우리 경우는 달라서 적기가 어렵다.
기획 부서에서 주는 문서가 충실치 않아서 스펙을 적을 수가 없다.
폭포수 모델과 달리 우리는 Agile이라서 잘 적을 필요 없다.
잘 적은 샘플 보여주세요.
실리콘밸리에서는 한번 적으면 스펙이 변경되지 않는다는 겁니까?
share with abctech.software
2019년 12월 26일 목요일
[Software Spec Series 2] 소프트웨어 프로젝트 실패의 원인
- 약속된 일정 내에 제품 또는 서비스를 출시하지 못했다.
- 소프트웨어가 요구되는 품질을 충족하지 못했다. (기능 요구사항, 성능, 안정성, 사용성, 확장성 등)
- 프로젝트에 꼭 필요한 기술 개발에 실패했다.
- 아키텍처가 엉망진창이 되어서 유지보수가 어렵게 됐다.
- 프로젝트에 계획된 예산보다 많은 비용을 지출했다.
- 프로젝트 내내 야근을 거듭하여 조직의 사기가 떨어지고 퇴사자가 많이 발생했다.
- 고객의 요구사항을 충분히 파악하지 못했다.
- 제품의 방향을 빨리 정하지 못하고 우왕좌왕하면서 프로젝트 앞부분에서 상당히 많은 시간을 소모하여 정작 개발 기간이 부족하게 되었다.
- 스펙과 설계를 제대로 작성하지 않고 코딩을 시작해서 엉뚱한 방향으로 개발을 하였다.
- 작성된 스펙을 프로젝트 이해관계자들이 충분히 리뷰 하지 않아 잘못된 스펙으로 개발하였다.
- 프로젝트를 진행할수록 새로운 요구사항이 계속 발견되어서 프로젝트가 한없이 늘어졌다.
- 변경된 요구사항을 제대로 관리하지 않아서 프로젝트 팀원들이 서로 다른 기준으로 개발을 하였다.
- 상명하복식으로 지정된 출시 일정을 맞추기 위해서 급하게 코딩부터 시작했다. 나중에 잘못된 코드를 고치느라고 시간이 더 소요되었다.
- 충분히 훈련되지 않은 개발자들을 투입하여 초반에 우왕좌왕하느라고 시간을 많이 지체했다.
- 일정관리를 대충해서 프로젝트가 지연되고 있다는 징후를 눈치채지 못했다.
- 리스크 관리를 하지 않아서 리스크로 인해서 프로젝트를 실패했다.
- 프로젝트 막판에 경영진이나 주요 고객이 프로젝트 방향을 완전히 틀어서 거의 처음부터 다시 개발해야 했다.
- 프로젝트 팀원들의 팀워크에 문제가 있어서 지속적으로 불화가 발생하여 프로젝트가 산으로 갔다.
- 도입한 외부 필수 기술이 기대처럼 동작하지 않았다. 이것을 프로젝트 막바지에 알게 되었다.
- 테스트 팀에 제대로 된 스펙을 전달하지 못해서 테스트 준비를 제대로 하지 못했다.
- 회사의 표준 프로세스를 강요하여 문서를 너무 많이 만들다 보니 정작 개발에는 소홀해졌다.
이외에도 실패 원인은 끝도 없이 많을 것이다. 이를 분류해보면 스펙, 프로젝트팀, 프로젝트 관리, 고객, 기술 등 다양하다. 필자는 이중에서 가장 중요하게 생각하는 요인은 “스펙”이다. 가장 많은 원인이 스펙과 관련이 있다. 또한 소프트웨어 버그의 절반 이상은 스펙으로부터 발생한다고 알려져 있다.
프로젝트가 아주 작다면 스펙을 제대로 적지 않고 요구사항 몇 줄로 개발해 나가도 소프트웨어를 무사히 완성하기도 한다. 소수의 경험 많은 개발자가 개발을 주도하는 경우 요구사항을 대충 알려줘도 찰떡 같이 알아듣고 개발을 잘하기도 한다. 하지만, 수백명이 투입되는 대규모 프로젝트에서는 매우 잘 정리된 스펙 문서가 필요한 경우가 일반적이다. 외국에 외주를 줄 경우 자세히 적힌 스펙 문서와 인수 테스트 계획이 필요하다.
소규모 프로젝트에서의 성공 경험을 대규모 프로젝트에 적용해서 실패를 하기도 하고, 반대로 대규모 프로젝트의 방법론이 중소규모 프로젝트에서 실패의 원인이 되기도 한다.
요구사항이 누락되거나 충분히 분석이 안된 스펙도 문제지만 너무 자세히 적거나 많은 문서를 적는 것도 문제가 된다. 대규모 방법론을 따르는 회사에서는 이런 함정에 종종 빠진다. 개발은 문서대로 진행되지 않을 뿐만 아니라 문서가 너무 많아서 수시로 바뀌는 요구사항을 문서에 제대로 반영하지 못한다.
따라서 엄격한 프로세스로 규제를 하는 것도 어렵다. 자율에 맡겨도 쉽지 않다. 필자가 생각하는 가장 좋은 방법은 원칙만 지킬 수 있는 최소한의 프로세스가 있는 환경에서 좋은 문화를 가지는 것이다. 빨리빨리 문화를 지양하고 적절히 분석하고 설계를 한 후 프로젝트를 진행하는 것이 더 빠르다는 인식을 공유해야 한다. 실제로 가장 빠른 방법이다. 모든 이해관계자들이 스펙을 철저히 리뷰하고 쉽게 요구사항을 바꾸지 않아야 한다. 이런 문화와 관행을 만들어가는 것이 프로세스보다 더 중요하다. 그래야 회사에 역량이 축적된다. 그렇게 좋은 문화와 축적된 역량이 충분해야 어떠한 프로젝트라도 성공으로 이끌 수 있다.
좋은 환경이 있어도 스펙을 제대로 적을 수 있는 역량이 부족하다면 소프트웨어 프로젝트 성공은 어렵다. 스펙을 제대로 적는 역량은 소프트웨어를 개발하는데 있어서 가장 어려운 역량이며 소질이 있는 개발자도 제대로 하려면 10년 이상의 경험과 노력이 필요하다. 꾸준히 투자하는 방법 외에 기가 막힌 방법은 없다.
share with abctech.software
2019년 12월 25일 수요일
[Software Spec Series 1] 머릿말
프레드릭 브룩스는 이렇게 말했다. "소프트웨어 개발에 있어서 가장 어려운 일은 개발 자체가 아니라, 무엇을 개발할지 결정하는 일이다." 이 말은 과거에도 유효했고, 현재도 유효하고, 미래에도 유효하다.
소프트웨어 프로그래머는 인공지능으로 대체될 가능성이 매우 높은 직업이다. 하지만 소프트웨어 스펙을 작성하는 분석 아키텍트는 인공지능으로 대체될 가능성이 가장 낮은 직업 중 하나다. 아무리 인공지능이 발전을 해도 스펙을 대신 작성해주는 세상이 올 가능성은 거의 없다. 그래서 스펙을 작성하는 일은 어렵지만 더욱 가치가 있다.
스펙을 잘 쓰는 방법을 정립해 놓은 것을 요구공학(Requirement engineering)이라고 한다.
공학이라고 하면 왠지 이론적인 것으로 생각된다. 하지만 공학은 실전에 비롯되었다. 과학을 현실에 적용하면서 과학과 현실의 간극을 메꿔주는 것이 공학이며 현실에서 벌어진 문제를 해결하면서 공학은 발전을 해 나간다. 즉, 이론적인 뒷받침도 있지만 공학은 실전이 먼저다. 요구공학도 이론적인 연구가 많이 되어 있지만 실전을 기반으로 발전되어 왔다. 하지만 현대의 요구공학은 이론적인 연구도 상당히 많이 더해져서 내용이 상당히 방대해졌다.
이런 방대한 요구공학 이론을 보고 왠만한 소프트웨어 회사에서 배우고 따라한 다는 것은 거의 불가능하다. 피아노 백과사전을 보고 피아노를 배우는 것과 비슷할 것이다. 아직 소프트웨어 공학이 내재화 되지 않은 소프트웨어 회사에서 요구공학 이론을 적용하는 것은 의미 없는 몸부림이다. 그렇게 한다면 오히려 주먹구구식 개발보다 효율이 떨어지는 것은 시간 문제다. 실제 우리나라의 많은 소프트웨어 회사들이 겪고 있는 문제다.
요구공학 즉, 스펙을 잘 작성하는 방법은 가르칠 수는 있는데, 배울 수는 없다. 무슨 뚱딴지 같은 소리인가 할 것이다. 하지만 이를 다른 분야의 예를 들면 바로 이해가 된다. 피아노를 잘 치는 방법을 가르칠 수는 있어도 그렇게 배워서는 피아노를 잘 칠 수 없다. 골프를 잘 치는 방법을 가르칠 수는 있어도 그렇게 해서는 골프를 잘 칠 수 없다. 가르치는 것이 의미는 있지만 피아노를 잘 치고, 골프를 잘 치려면 훈련을 해야 한다. 1,2년이 아니고 수년 이상 훈련을 하면서 코칭을 해야 비로소 피아노를 잘 치고, 골프를 잘 칠 수 있다. 코딩을 배우는 것과는 매우 다르다.
그래서 요구공학 책은 많아도, 책을 보고 배워서 스펙을 작성해도 실력이 잘 늘지 않는다. 특히나 이론에 아주 충실한 책들은 아무리 좋은 책이라고 하더라도 현실에 적용하기는 더욱 어렵다. 회사 경영진들은 대부분 매우 조급하다. 꾸준히 투자하고 훈련하면 10년 걸릴 일을 1,2년 안에 성과를 내려고 한다. 피아노 1,2년 안에 늘 수 있는 실력에 한계가 있듯이 스펙을 작성하는 것도 그렇게 빨리 성과가 나지는 않는다. 서두르다가는 오히려 역효과만 난다. 그래서 많은 회사에서 스펙 작성 역량 확보에 실패한다. 그리고 해봤더니 안되더라. 요구공학은 엉터리라고 한다. 피아노 1,2년 연습하고 쇼팽의 곡을 못 친다고 실망하는 것과 비슷하다.
스펙을 잘 작성하기 위해서는 실전에 따른 노하우의 축적이 필요하다. 노하우 백과사전을 만들어서 봐도 배울 수는 없다. 노하우는 스스로 현실에서 익히는 것이다. 그래서 경험이 중요하다. 단, 잘못된 방법으로 시도한 경험으로는 좋은 노하우 축적이 안된다. 오히려 왜곡된 생각이 쌓인다. 그래서 좋은 코치가 필요하다. 코치와 같이 실전 프로젝트를 수행하면서 스펙을 직접 써보고, 피드백을 받아야 한다. 피아노, 골프 모두 같은 방식으로 배운다. 스펙을 작성하는데 있어서 일반적인 코치는 회사의 고참 개발자, 경력이 많은 분석 아키텍트다. 하지만 우리나라 소프트웨어 회사에서는 그런 역량이 있는 선배를 찾아보기 힘든 것이 현실이다. 그래서 코칭을 제대로 받을 수가 없다.
스펙을 작성하는 기법만 알아서는 스펙을 잘 쓸 수 없다. 개발 문화, 관행, 습관, 프로세스, 원리, 원칙을 알고 접근해야 한다. 앞으로 시리즈 글에서 스펙을 잘 작성하는데 필요한 모든 분야를 다룰 것이다.
운동은 원리를 몰라도 코치가 가르쳐주는 대로 무조건 반복 훈련을 해도 성과를 내고 경지에 오를 수도 있다. 하지만 소프트웨어 개발은 원리를 모르고 기계적으로 따라해서는 제대로 발전하기 어렵다. 오히려 엉뚱한 함정에 빠져서 고치기 힘든 나쁜 습관이 몸에 베일 수 있다. 그래서 원리를 아는 것도 배우 중요하다. 그래서 앞으로 원리를 이해하는데 도움이 되는 많은 얘기를 할 것이다.
소프트웨어 개발은 “적절히”가 매우 중요하다. “적절히”를 제대로 이해하는데 10년, 20년 걸린다. 피아노, 골프도 마찬가지다. 처음부터 완벽하게 이해하려는 것은 욕심이다. 시행착오를 거치면서 원리를 하나씩 깨우칠 때 “적절히” 하는 노하우를 하나씩 터득할 수 있다. 이 시리즈를 통해서 노하우를 터득해 나가보자.
share with abctech.software
2018년 4월 20일 금요일
프로세스가 개발 문화를 이기기 어려운 이유
2017년 12월 1일 금요일
한국 회사와 불가리아 회사
2017년 8월 19일 토요일
소프트웨어 스펙은 왜 쓰기 어려운가?
- 프로젝트가 종료 일정을 지키지 못할 가능성이 높다.
- 소프트웨어 아키텍쳐가 엉망이 될 가능성이 높다.
- 소프트웨어 품질을 보장하기 어렵다.
- 개발자들이 야근에 내몰려 혹사를 당하기 쉽다.
- 개발에 관련된 지식 축적이 어렵다.
- 추후 요구사항이 변경되어도 소프트웨어에 어떠한 파급효과가 있는지 예측하기 어렵다.
- 업그레이드 프로젝트를 효과적으로 진행하기 어렵다.
소프트웨어 스펙 작성
|
골프
|
피아노
|
효과
|
책을 보고 스스로 공부해서 스펙을 적는다.
|
골프 잘치는 책을 보고 혼자서 연습한다.
|
피아노 교본을 보고 혼자서 연습한다.
|
역효과
|
강연을 듣고 필요성을 절감해서 스펙을 적는다.
|
타이거 우즈 특강 모임에서 깨달은 바가 있다.
|
피아노 잘치는 법이라는 강연을 듣는다.
|
미미한 효과
|
인터넷에서 좋다는 Template을 구해서 각 항목을 채운다.
|
좋다는 골프채를 구매해서 골프를 친다.
|
좋은 피아노를 사서 열심히 연습한다.
|
미미한 효과 또는 역효과
|
일하면서 뛰어난 선배들이 작성한 스펙을 본다.
|
골프 연습장에 골프를 잘치는 프로가 많아서 수시로 골프 치는 것을 볼 수 있다.
|
피아노 교습소에 뛰어난 피아니스트가 있어서 연주를 수시로 볼 수 있다.
|
좋은 환경
|
스스로 스펙을 작성하고 뛰어난 아키텍트 선배의 리뷰를 받는다.
|
골프 코치에게 골프를 배우고 연습을 반복한다.
|
피아노 선생님에게 피아노 치는 것을 배우고 연습을 반복한다.
|
발전 가능성이 높은 환경
|
수년간 지속적으로 스스로 스펙을 작성하고 뛰어난 아키텍트 선배의 리뷰를 받는다.
|
수년간 실전 골프를 치면서 지속적으로 골프 코치에게 스윙을 교정받고 배운다.
|
수년간 피아노를 치면서 지속적으로 선생님에게 피아노 치는 것을 배운다.
|
발전 가능성이 가장 높은 방법
|
본인 스스로도 타 프로젝트의 수많은 스펙의 리뷰에 참여한다.
|
후배들의 골프 스윙도 봐주면서 이론적으로도 지식을 쌓는다.
|
후배들이 피아노를 치는 것을 봐주면서 조언을 해준다.
|
발전 가능성이 가장 높은 방법
|
- 뛰어난 아키텍트를 여러명 보유한다.
- 작은 프로젝트라도 스펙을 제대로 작성하고 개발하는 문화를 만든다.
- 철저한 정보 공유, 투명한 개발 환경
- 경영진을 비롯하여 많은 프로젝트 관련자들이 스펙을 충분히 리뷰한다.
- 빠르게 개발한다는 명목하게 주먹구구식 개발을 신봉한다.
- 원칙보다 기법에 현혹되어 여러 방법론을 기웃거린다.
- 복잡한 프로세스가 문제를 해결해 줄것으로 맹신하고 강요한다.
- 코딩이 가장 중요하다고 생각한다.
- 작성된 스펙에 관심들이 없어서 리뷰에 소홀하다가 개발 후에 부담없이 변경을 요구한다.
- 상명하복의 조직문화
share with abctech.software