2012년 10월 15일 월요일

생각은 쉽게 바뀌지 않는다.

많은 회사에서 경영자, 개발자들이 소프웨어를 좀더 효과적으로 개발하기 위해서 다양한 시도를 한다.
문서를 작성하고 소스코드를 관리하고 이슈를 관리하고 프로젝트 관리 기법을 도입한다. 이런 외형적인 시도를 해도 생각은 쉽게 바뀌지 않는다. 특히 경영자들의 마인드가 잘 바뀌지 않는다. 소프트웨어 개발을 제대로 이해하지 못했기 때문이다.

실리콘 밸리와 우리나라에서 소프트웨어를 개발할 때 가장 큰 차이를 보이는 것이 있다.

스펙을 바꾸는 것이 얼마나 큰 일인지에 대한 생각이다. 실리콘밸리에서는 스펙을 바꾸는 일이 개발팀에 엄청나게 큰 부담을 주고 일정과 비용이 영향을 주는지 경영진을 비롯한 모든 직원들이 알고 있기 때문에 스펙을 쉽게 바꾸려고 하지 않는다. 그렇기 때문에 스펙을 작성할 때 철저히 리뷰를 한다. 리뷰를 소홀히 하다가 나중에 빠진 거나 잘못된 것을 바꾸기가 쉽지 않기 때문이다. 그래서 스펙이 제대로 적히고 잘 검토가 되고 프로젝트에서 매우 중요한 역할을 한다.

그런데 우리나라에서는 스펙을 바꾸는 것이 얼마나 큰일인지 잘 인식하지 못한다. 경영자뿐만 아니라 개발자도 그런 경우가 많다. 어차피 주먹구구식으로 개발하기 때문에 스펙 변경을 대수롭지 않게 생각하거나 자포자기식 개발자도 많다. 그래서 스펙을 작성하기 않기도 하거나 대충 작성하다 마는 경우가 많다.

교육을 하고 설득을 하고 귀가 아프도록 얘기를 해도 피부로 느끼기 전에는 생각이 잘 바뀌지 않는다. 이는 방법론에 따라서 다른 얘기는 아니다. 이미 스펙이 결정된 후에는 어떠한 방법론에서도 스펙 변경은 큰 일이다. 

물론 스펙 변경이 불가능한 것이 아니다. 비용 증가를 감수하고도 변경해야 할 이유가 있으면 합리적이고 적절한 절치를 통해서 변경해야 한다.

보통의 경영진은 프로젝트 진행 도중에 이런 저런 요구를 하고 싶게 마련이다. 프로젝트에 관여해서 영향력을 행사하고 싶은 욕구가 있는 경우도 있다. 이럴 때 요구사항을 잘 받아주는 개발자가 우리나라에서는 더 높은 평가를 받곤하지만 회사 전체적으로는 손해가 되는 일이다. 정말 급한 요구사항이 아니라면 다음 버전으로 미루면 되는 일이다. 

소프트웨어 개발에서 스펙을 함부로 바꾸면 안된다는 것만 깨달으면 소프트웨어 공학의 80%는 터득한 것이다. 거의 대부분의 다른 문화는 다 여기서 파생된다. 안타까운 것은 외워서 되는 것이 아니라는 것이다.

댓글 2개:

  1. 책 잘 보고 있습니다. 취업 준비생으로서 포트폴리오를 위하여 진행 중인 개인 프로젝트에 소스 관리 프로그램인 git과 github, 그리고 간단한 스펙 흉내등을 통하여 최대한 효율적인 작업을 진행하려 노력하고 있습니다.

    git의 사용으로 인한 성공적입니다. 물론 제 나름대로의 사용으로서는 아주 만족스런 사용이라 실무와의 갭을 실감 할 수 없어 아쉽습니다.

    좋은 내용 감사합니다.

    답글삭제
  2. 안녕하세요. 임덕규님
    잘하고 계시네요. git 사용법은 간단하지만 제대로 쓰려면 경험이 좀 필요합니다. Tag와 Branch도 활용하고 책에 어느 정도 소개가 되어 있으니 참조하세요. 간단한 소프트웨어는 스펙도 간단하게 작성할 수 있습니다. 이슈관리시스템을 이용해도 됩니다.
    실무에서는 스펙의 규모가 크기 때문에 얘기가 완전히 달라집니다. 이것은 실무에서 직접 배우는 것이 좋습니다. 그래도 이렇게 마음가짐을 가지고 경험을 하고 있으면 도움이 많이 될 겁니다.
    문제는 왠만한 회사를 가면 또 주먹구구식 환경이기 때문에 문제가 되죠. 꾸준히 노력하세요.

    감사합니다.

    답글삭제