‘스펙 없음’의 관행과 문제점
요즘 스타트업 개발 조직
1. 삐걱대는 프로젝트 진행
기획 측에서 나온 RD(요구 문서)를 SRS(aka 스펙)으로 삼아 프로젝트를 진행하는 요즘 스타트업 개발 조직들이 끝없이 겪을 문제와 그로 인한 비용 증가를 한문단으로 잘 정리했다. 애초에 스펙 문서의 존재를 모르는 것 같기도 하다. 비용 증가만 있으면 그나마 다행, 기획과 개발 측 상호 간 감정의 골이 깊어져 가 최후에 개발 조직 전체가 이직해버리는 사례도 흔하다.
65p. 소프트웨어 스펙의 모든것. 한빛미디어2. 일정이 부족해요
스펙을 작성하고 나서야 일정이 부족할지 충분할지 알 수 있다. 하지만 대개 스펙을 확인하지 않고 “일정이 부족하니 바로 개발 시작하죠”라는 말을 한다. 스펙을 기준으로 한 산정 기준을 보지도 않고 무작정 일정이 부족하다는 말을 하는 것은 자신이 해당 업무에 프로페셔널이 아님을 증명하는 말이다. 분석이고 뭐고 다 모르겠고 그냥 자신이 정한 일정에 맞추라는 뜻으로 뿌리 깊은 한국 관료주의 문화와 맥을 같이하는 사고방식이다. 스펙을 확인해보고 정말 일정이 부족하다면 해당 프로젝트에 인원을 보충하던지, 버전을 나눠서 서비스를 배포하면 될 일이다. 타협의 여지를 애초에 차단하는 식의 대화를 구사하는 사람과는 가급적 같은 팀에 있지 않아야 한다.
69p. 소프트웨어 스펙의 모든것. 한빛미디어3. 나도 내가 뭘 원하는지 몰라
소프트웨어를 정말 소프트해서 언제든 요구사항을 추가/변경할 수 있다고 생각하는 것도 일정과 비용 증가를 가져온다. 스펙을 작성한 후 결과물을 리뷰하면 그때서야 아이디어가 샘솟는 것이다. 아이디어가 추가 피쳐이거나 아키텍처에 영향이 없는 속성 변경 정도이면 버전 관리를 하면 되므로 문제가 없다. 그 반대의 모든 경우 개발을 뒤엎어야 하므로 일정이 늘어나게 된다. 이런 경우도 힘이 빠지고 감정이 상하는 상황이 흔하게 발생한다. 아래 문단에서 고객은 개발자에게 개발을 요청하는 모든 이를 지칭한다.
69p. 소프트웨어 스펙의 모든것. 한빛미디어4. 우리는 그렇게 안 해요
워터폴 방법론을 비판하며 애자일을 흉내 내는 조직들이 많다. 촉박한 일정의 스타트업에 적합한 방법이라 흉내 낸다고 한다. 그리고 스펙 문서 작성은 “우리 방식”이 아니라고 한다. 일정이 촉박해 문서 작성할 시간이 없다고 한다. 아래 제시된 그래프를 보면 생각이 많아질 것이다. 적어도 지금보다 더 성장하고 싶은 조직이라면 말이다. 솔직해지자. 시간 충분하면 누구나 스펙 작성할 수 있나?
73p. 소프트웨어 스펙의 모든것. 한빛미디어5. 나가며
스펙 문서가 만능은 아니다. 소프트웨어 공학이란 게 그렇다. 어설피 쥐어주면 없으니만 못하다. 하지만 제대로 다룬다면 그만큼 경제적이고 건강한 조직이 없다. 소프트웨어 공학 자체의 목적이 “소프트웨어를 최소 비용으로 최단기간에 개발한다”이기 때문이다. 이런 조직, 어디 없나?
