최근에 국내 유수 대학의 컴퓨터 공학 교수를 만난 적이 있다. 그 교수님도 문서를 작성하면서 Software를 개발하면 더 오래 걸린다고 굳게 믿고 있었다.
어느 정도 이해가 되는 상황이다. 원래 소프트웨어 공학은 실전에서 발전해 온 것이기 때문에 교수가 실전적으로 잘 아는 분야는 아니다. 교수는 이론적으로는 잘 알고 있지만 실전은 상대적으로 약하기 때문이다. 특히 우리나라에서 쌓은 실전은 더욱 약할 수 있다. 또한 국내 개발자들을 데리고 일한다는 가정을 하고 얘기를 하는 것이라면 더욱도 그렇다.
물론 문서를 작성하면서 개발을 해야 한다고 생각한다. 그래야 제대로 개발을 할 수 있다.
하지만 문서를 작성하면서 개발을 하면 개발 기간이 거의 2배로 들어간다고 한다.
우리는 시간이 촉박하므로 문서를 작성하지 않고 개발해야 한다고 한다.
이 생각은 국내 회사의 대부분의 개발자와 경영자가 생각하고 있는 바와 크게 다르지 않다.
일부분은 맞는 측면이 있다.
문서를 어떻게 작성해야 하는지 잘 모르는 개발자를 데리고 개발을 하면서 문서까지 잘 작성해달라고 하면 시간이 훨씬 더 걸리는 것이 당연하다.
그럼 소프트웨어를 개발하면서 문서를 작성하는 이유는 무엇일까?
바로 소프트웨어를 더 빨리 개발하기 위한 것이다.
이말을 진정으로 이해하고 있는 개발자를 만나는 것은 쉬운 일이 안다.
그런데 왜 이렇게 다들 다르게 생각하고 있는 것일까?
첫째, 앞에서 언급했다시피 역량 문제가 있다. 역량이 떨어지면 문서를 잘 적지도 못하고, 문서에 무슨 내용을 적어야 하는지도 모른다.
둘째, 국내 교수, 경영자, 개발자 모두 문서를 작성한다고 하면 세계적인 유명한 방법론을 기준으로 생각하는 경향이 있다.
세계적인 방법론은 수십가지가 있고, 대부분은 수십가지의 문서를 만들어야 한다. 하지만 대부분의 실리콘밸리의 SW회사들은 이런 방법론을 따르지 않는다. 회사의 규모, 성격에 따라서 매우 다르다. 국방부 프로젝트 또는 대규모 프로젝트를 주로 하는 회사는 상당히 많은 문서를 만들지만 그렇지 않은 회사들은 꼭 필요한 문서 몇가지만 만는다.
셋째, 우리나라에서는 문서를 나중에 만드는 문제가 있다. 문서는 개발을 빨리하기 위해서 만드는 것인데 다 개발해 놓고 문서를 만들면 시간만 추가로 들어갈뿐만 아니라 문서의 내용도 충실히 작성할 수가 없다. 이렇게 작성한 문서는 나중에 효용성도 떨어진다. 문서는 다음단계를 진행하기 위해서 앞서서 만드는 것이다.
넷째, 문서를 얼마나 자세히 적어야 하는지 잘 모르고 있다. 대부분 문서를 너무 상세히 적어야 하는 것으로 생각하고, 처음에는 의욕적으로 적기 시작하는데 점점 지쳐가고 나중에는 업데이트도 잘 안된다. 문서는 상황에 맞게 최소화 해서 만들어야 한다. 그래야 중복이 줄어들고 낭비가 줄어든다.
문제점을 정리하면 다음과 같다.
- 개발자 역량의 차이
- 수십개의 문서를 만들어야 하는 것으로 착각
- 문서를 나중에 추가로 만든다.
- 문서를 너무 자세히 적으려고 한다.
소프트웨어를 개발하면서 문서를 제대로 작성하는 이유는 개발을 빨리 하기 위해서이다.
- 문서는 필요한 만큼만 최소한으로 작성을 하고
- 문서를 작성해야 리뷰를 할 수 있고,
- 일을 효율적으로 나눠서 할 수 있고,
- 각 부서가 문서를 가지고 병행해서 전문적인 업무들을 진행할 수 있다.
역량이 떨어지고 인식이 안바뀌어서 계속 주먹구구식 개발에 머문다면 경험이 쌓이지도 않는다. 당장은 역량이 떨어져도 스펙을 제대로 작성하고 설계를 작성하고 리뷰하는 경험을 꾸준히 쌓아야 한다. 그래야 문서를 작성하는 것이 진짜로 소프트웨어를 빨리 개발하는 것을 경험하게 될 것이다.
그리고 이렇게 빨리 소프트웨어를 개발하는 것을 경험해본 사람들은 다시 옛날로 돌아가지 않는다.
"문서를 작성해보자"라고 생각을 굳혔으면 "스펙"(SRS) 문서를 먼저 작성해보라고 권한다. 스펙문서만 제대로 작성해도 80%는 해결 된 것이다. 그리고 역량이 좀더 늘면 다른 문서들을 하나씩 작성해보기 바란다.
image by Mirandala
