2012년 5월 14일 월요일

문서를 작성하면 더 오래 걸린다는 고정관념

최근에 국내 유수 대학의 컴퓨터 공학 교수를 만난 적이 있다. 그 교수님도 문서를 작성하면서 Software를 개발하면 더 오래 걸린다고 굳게 믿고 있었다. 

어느 정도 이해가 되는 상황이다. 원래 소프트웨어 공학은 실전에서 발전해 온 것이기 때문에 교수가 실전적으로 잘 아는 분야는 아니다. 교수는 이론적으로는 잘 알고 있지만 실전은 상대적으로 약하기 때문이다. 특히 우리나라에서 쌓은 실전은 더욱 약할 수 있다. 또한 국내 개발자들을 데리고 일한다는 가정을 하고 얘기를 하는 것이라면 더욱도 그렇다.

물론 문서를 작성하면서 개발을 해야 한다고 생각한다. 그래야 제대로 개발을 할 수 있다.
하지만 문서를 작성하면서 개발을 하면 개발 기간이 거의 2배로 들어간다고 한다.
우리는 시간이 촉박하므로 문서를 작성하지 않고 개발해야 한다고 한다.

이 생각은 국내 회사의 대부분의 개발자와 경영자가 생각하고 있는 바와 크게 다르지 않다.

일부분은 맞는 측면이 있다.

문서를 어떻게 작성해야 하는지 잘 모르는 개발자를 데리고 개발을 하면서 문서까지 잘 작성해달라고 하면 시간이 훨씬 더 걸리는 것이 당연하다.

그럼 소프트웨어를 개발하면서 문서를 작성하는 이유는 무엇일까?
바로 소프트웨어를 더 빨리 개발하기 위한 것이다. 
이말을 진정으로 이해하고 있는 개발자를 만나는 것은 쉬운 일이 안다. 

그런데 왜 이렇게 다들 다르게 생각하고 있는 것일까? 

첫째, 앞에서 언급했다시피 역량 문제가 있다. 역량이 떨어지면 문서를 잘 적지도 못하고, 문서에 무슨 내용을 적어야 하는지도 모른다.

둘째, 국내 교수, 경영자, 개발자 모두 문서를 작성한다고 하면 세계적인 유명한 방법론을 기준으로 생각하는 경향이 있다.

세계적인 방법론은 수십가지가 있고, 대부분은 수십가지의 문서를 만들어야 한다. 하지만 대부분의 실리콘밸리의 SW회사들은 이런 방법론을 따르지 않는다. 회사의 규모, 성격에 따라서 매우 다르다. 국방부 프로젝트 또는 대규모 프로젝트를 주로 하는 회사는 상당히 많은 문서를 만들지만 그렇지 않은 회사들은 꼭 필요한 문서 몇가지만 만는다.

셋째, 우리나라에서는 문서를 나중에 만드는 문제가 있다. 문서는 개발을 빨리하기 위해서 만드는 것인데 다 개발해 놓고 문서를 만들면 시간만 추가로 들어갈뿐만 아니라 문서의 내용도 충실히 작성할 수가 없다. 이렇게 작성한 문서는 나중에 효용성도 떨어진다. 문서는 다음단계를 진행하기 위해서 앞서서 만드는 것이다.

넷째, 문서를 얼마나 자세히 적어야 하는지 잘 모르고 있다. 대부분 문서를 너무 상세히 적어야 하는 것으로 생각하고, 처음에는 의욕적으로 적기 시작하는데 점점 지쳐가고 나중에는 업데이트도 잘 안된다. 문서는 상황에 맞게 최소화 해서 만들어야 한다. 그래야 중복이 줄어들고 낭비가 줄어든다.

문제점을 정리하면 다음과 같다.
  • 개발자 역량의 차이
  • 수십개의 문서를 만들어야 하는 것으로 착각
  • 문서를 나중에 추가로 만든다.
  • 문서를 너무 자세히 적으려고 한다. 

소프트웨어를 개발하면서 문서를 제대로 작성하는 이유는 개발을 빨리 하기 위해서이다. 
  • 문서는 필요한 만큼만 최소한으로 작성을 하고 
  • 문서를 작성해야 리뷰를 할 수 있고, 
  • 일을 효율적으로 나눠서 할 수 있고,
  • 각 부서가 문서를 가지고 병행해서 전문적인 업무들을 진행할 수 있다.

역량이 떨어지고 인식이 안바뀌어서 계속 주먹구구식 개발에 머문다면 경험이 쌓이지도 않는다. 당장은 역량이 떨어져도 스펙을 제대로 작성하고 설계를 작성하고 리뷰하는 경험을 꾸준히 쌓아야 한다. 그래야 문서를 작성하는 것이 진짜로 소프트웨어를 빨리 개발하는 것을 경험하게 될 것이다. 
그리고 이렇게 빨리 소프트웨어를 개발하는 것을 경험해본 사람들은 다시 옛날로 돌아가지 않는다.

"문서를 작성해보자"라고 생각을 굳혔으면 "스펙"(SRS) 문서를 먼저 작성해보라고 권한다. 스펙문서만 제대로 작성해도 80%는 해결 된 것이다. 그리고 역량이 좀더 늘면 다른 문서들을 하나씩 작성해보기 바란다.

댓글 8개:

  1. 항상 도전과 생각할 거리를 주시는 포스트에 감사드립니다.

    선배의 경험이 잘 전달되어야 하나 이러한 경험이 없는 선배들에게서
    좋은 개발문화를 만들어가는 것은 참 어렵다는 생각이 듭니다.
    관련한 지식들이 잘 전달될 수 있도록 훈련받을 수 있는 기회가 있다면,
    그리고 그 기회가 잘 이어져갈 수 있도록 지속적인 케어가 될 수 있다면 참 좋겠습니다.
    관련된 서적이 출간되고, 강연 및 멘토링으로 이어질 수 있는 기회가 있다면 좋겠습니다.

    답글삭제
  2. 안녕하세요~ 계속 읽기만 하는 김성하 입니다.
    덕분에 늘 좋은 글 잘 보고 있습니다. 오늘 글 읽는 중 조금 어색한 부분이 있어서요~

    [셋째, 우리나라에서는 문서를 나중에 만드는 문제가 있다. 문서를 개발을 빨리하기...]

    에서 "문서를" 이 아니라 "문서는" 또는 "문서란" 이 맞는 것 같습니다.

    괜한 글 읽어주셔서 감사합니다.

    앞으로도 좋은 글 부탁 드립니다.

    답글삭제
  3. 문서작성을 해야한다고 하면, 경영자들이 이상한 문서를 요구하는것도, 개발속도를 느리게 하는 요소 중 하나라고 생각합니다.

    답글삭제
  4. 졸업 작품 할 적에 교수님의 "책에는 그렇게 되어 있지만~~"이라는 말씀이 떠오릅니다. 코딩부터 빨리 하라고 하셔서 그 꼬인 설계, 문서를 6주 작성한 코드 4달 동안 풀어야 했던 기억이 납니다...

    답글삭제
  5. 남종환님 안녕하세요.

    블로그 상단의 추천도서에 제가 쓴 책이 있고 근본적인 이슈에 대해서 심도 있게 다루고 있고 교과서식으로 따라 할 수 있도록 되어 있습니다.

    물론 강연이나 컨설팅도 많이 진행하고 있습니다.

    관심이 많으시니 점점 나아질 겁니다.

    답글삭제
  6. 안녕하세요. 감사합니다.

    그외에도 오타가 좀 있네요. ^^

    답글삭제
  7. ruwin126님 안녕하세요.

    어떤 문서를 어떻게 작성해야 하는지 대부분 모르기 때문에 경영자들은 엉뚱한 문서를 요구하곤 합니다.
    "문서가 없어서 문제다"라는 말은 많이 들어 봤고, 세계적인 방법론에서는 많은 문서를 요구하니 그렇게 하면 되는줄 착각하기도 합니다.
    그런 경영자를 개발자들이 설득하기란 쉬운 일이 아니죠. ^^

    답글삭제
  8. 주의사신님 안녕하세요.

    교수들은 소프트웨어 사이언스가 전문인 사람들입니다. 산업현장에서 오랫동안 개발해 보지 않으면 소프트웨어 공학에 능통할 수는 없습니다.

    교수들이 산업용 소프트웨어를 많이 개발해 본 경우도 마찬가지입니다. 소프트웨어 사이언스적으로 개발을 한 것이지 공학적인 것은 아닙니다.

    따라서, 대부분의 교수들은 공학적으로 어떻게 체계적으로 효율적으로 문서를 작성해야 하는지는 잘 알지 못한다고 할 수 있습니다. 심지어는 소프트웨어공학 교수들도 진짜 공학은 잘 모르는 경우도 있습니다.

    좀 어폐가 있지만 이론적인 소프트웨어공학을 가르치는 겁니다. 물론 이런 이론도 없는 것보다는 많이 도움이 되고 학교에서는 소프트웨어공학도 이론적으로 새로운 연구와 시도를 많이 해보고 산업계에 도움을 준다고 생각합니다.

    결론은 "소프트웨어공학은 이론이 아니라 실전이다"라고 할 수 있습니다.

    PS) 졸업작품도 시간이 촉박하면 빨리 스펙/설계를 작성하고 개발하는 것이 가장 빨리 개발할 수 있는 방법이죠. ^^

    답글삭제