소프트웨어 프로젝트에서 스펙 작성의 중요성에 대해 얘기를 해보면 공감을 하는 사람도 있는가 하면 부정적인 의견을 가지고 있는 사람도 많다. 대부분은 스펙에 대한 오해에서 비롯된 것이다. 이 오해를 해소하는 것은 매우 중요하다. 오해가 풀려야 스펙 작성의 주요성을 공감할 수 있고 스펙 작성을 위해 노력할 것이다. 스펙 작성에 대한 어떠한 오해들이 있는지 알아보자.

스펙을 적는 것이 좋은 줄 몰라서 안 적는 게 아니다.

스펙을 제대로 적고 소프트웨어를 개발하는 것이 좋은 줄은 아는데 어떤 사정 때문에 스펙을 제대로 적고 있지 않다는 얘기다. 필요하면 언제든지 제대로 적을 수 있다고 주장하기도 한다. 일단, 이렇게 주장을 하는 경우는 스펙 작성이 소프트웨어 프로젝트에서 얼마나 중요하고 필요한지 잘 모를 가능성이 매우 높다. 스펙은 누가 시켜서, 의무라서 작성하는 것이 아니라 소프트웨어 프로젝트를 성공시키는 중요한 요소이기 때문에 작성하는 것이다. 그래서 이를 제대로 깨닫고 있는 경우라면 스펙을 작성하지 않을 리가 없다. 단, 프로젝트의 성격에 따라서 스펙의 양과 작성법은 달라질 수 있다. 스펙을 작성하고 있지 않다면 스펙을 제대로 작성하는 것이 프로젝트를 성공하는데 얼마나 중요한지 모르는 것이다.

소프트웨어를 만들어 보기 전에는 천재도 내용을 다 알 수 없다.

맞는 말이기도 하다. 우리는 100% 모든 것을 아는 것만 프로젝트로 수행하지는 않는다. 성공을 장담할 수 없는 알고리즘을 개발하기도 하고, 한번도 사용해보지 않는 상용 라이브러리를 사용해서 소프트웨어를 개발하기도 한다. 또한, 프로젝트 중후반까지 고객의 요구사항을 다 파악하지 못하기도 하고, 고객 요구사항이 계속 바뀌기도 한다. 그 외에도 소프트웨어 프로젝트는 어려움투성이다. 그래서 일단 개발해 봐야 한다는 주장도 있지만 필자는 반대로 그러기 때문에 스펙을 제대로 작성해야 한다고 주장한다. 스펙에는 이런 어려움과 미지수까지 사실 그대로 적시를 해야 하며, 스펙을 작성하는 도중에 검증을 통해서 불확실성을 줄여 나가야 한다. 이런 어려운 프로젝트를 수행하면서도 프로젝트 성공 가능성을 높이는 가장 좋은 방법은 스펙을 적절하게 작성하는 것이다.

나도 작성할 줄 아는 데 적을 시간이 없다.

시간이 없어서 스펙을 작성하지 못한다는 것은 모순과 같다. 스펙을 제대로 작성하는 이유는 최단 시간에 소프트웨어를 개발하는데 필요하기 때문이다. 스펙이라고 얘기를 하면 방대한 문서가 먼저 떠오르지만, 스펙은 상황에 따라서 가장 적절하게 작성해야 하고 의외로 적게 잘 작성한 스펙도 많다. 프로젝트의 일정이 절대적으로 짧아서 스펙을 작성할 시간이 없어서 그냥 프로젝트를 진행한다면, 대부분의 경우 스펙을 제대로 작성하는 것보다 프로젝트는 더 오래 걸린다. 모든 프로젝트는 적절한 인력과 시간이 필요하지만 비즈니스 상황상 시간이 절대적으로 부족하다면 스펙을 작성하지 않는 것보다 스펙을 효율적으로 신속하게 작성하고 프로젝트를 진행하는 것이 낫다. 스펙을 항상 일정한 절차를 거쳐서 상세하게 작성해야 한다는 것은 오해에 불과하다. 프로젝트의 여건에 맞게 프로젝트를 가장 빨리 끝낼 수 있는 방법으로 작성하는 것이 스펙을 제대로 작성하는 방법이다.

나도 작성해 보았는데 우리 경우는 달라서 적기가 어렵다.

많은 회사에서 자신들은 일반적인 소프트웨어가 아니라서 스펙을 작성할 수 없다고 한다. 이유는 매우 다양하다. 게임이라서, 펌웨어라서, 라이브러리라서, 매주 업데이트를 해야 해서, 회사 내부용이라서 다르다고 한다. 우리는 달라서 스펙을 작성할 필요가 없다고 주장하는 것은 스펙을 제대로 작성하지 못하는 것에 대한 핑계와 오해일 뿐이다. 스펙 관점으로 보면 모든 소프트웨어는 같다. 모든 소프트웨어는 스펙이 존재하며 스펙을 적절히 작성하는 것은 소프트웨어 프로젝트를 성공하는데 중요한 요소다. 스펙을 적절히 작성한다는 의미에 대해서 이 시리즈에서 얘기를 할 것이다.

기획 부서에서 주는 문서가 충실치 않아서 스펙을 적을 수가 없다.

기획 부서에서 제대로 기획서를 작성해서 전달하면 소프트웨어 스펙을 작성하는데 많은 도움이 된다. 하지만 기획 부서에서 고객 요구사항을 제대로 파악하지 못하거나, 소프트웨어 비전과 전략을 제대로 정리해서 전달하지 못하는 경우는 매우 흔하다. 심지어는 기획을 거치지 않고 요구사항 몇 줄을 가지고 개발팀으로 넘어와서 스펙을 작성해야 하는 경우도 있다. 그렇다고 기획팀을 핑계로 스펙 작성에 소홀하면 그 피해는 고스란히 개발팀에게 떨어지고, 프로젝트는 실패를 향해 달려갈 수 있다. 기획이 부실하다면 소프트웨어 분석을 담당한 분석 아키텍트가 기획이 해야 할 역할도 일부 수행하는 것이 좋다. 소프트웨어의 비전과 전략을 파악하고 고객 요구사항을 좀더 파악해야 한다. 그리고 스펙에서 전략에 해당하는 부분은 기획 부서의 확인을 받아야 한다. 기획 부서의 핑계를 대 봤자 모든 문제는 개발팀에게 부담으로 되돌아 온다.

폭포수 모델과 달리 우리는 Agile이라서 잘 적을 필요 없다.

스펙을 제대로 작성하는 것은 폭포수 모델에서나 하는 것이라는 오해다. 스펙 작성이 어렵다는 것은 익히 알려져서 Agile을 선택하는 회사도 있다. Agile을 적용하면 스펙을 어렵게 작성하지 않아도 된다는 오해에서 비롯된 것이다. 현실에서 폭포수 모델을 사용하는 소프트웨어 회사는 거의 없다. 방법론과는 상관없이 소프트웨어 스펙은 중요하다. Agile이라고 하더라도 스펙의 내용이 바뀌지는 않는다. 적는 방법만 달라질 뿐이다. 폭포수 모델에서 소프트웨어 스펙을 잘 작성할 수 있는 역량을 가지고 있다면 Agile을 적용한 프로젝트에서도 효율적으로 스펙을 작성할 수 있다. Agile을 적용한 프로젝트에서도 스펙은 잘 작성해야 한다.

잘 적은 샘플 보여주세요.

우리는 프로그래밍을 배울 때 좋은 샘플을 많이 보면서 배웠다. 이 방법은 매우 유용했다. 그래서 스펙 작성을 배울 때도 샘플을 보여 달라고 한다. 그리고 샘플에 적힌 내용을 자신의 프로젝트에 맞게 바꾸곤 한다. 이렇게 스펙을 작성하고 작성법을 배운다면 100% 실패한다. 세상의 모든 프로젝트는 서로 다른데 샘플을 보고 작성한다는 것은 어불성설이다. 샘플 보면서는 각 항목의 숨겨진 뜻과 생략된 내용, 적는 과정을 알 수 없다. 10년에 걸쳐서 피아노를 연습한 피아니스트의 현재 연주 동영상을 보고 그대로 따라하는 것과 다를 바가 없다. 많은 경우 샘플을 도움이 되기 보다는 독이 된다. 샘플에 적혀 있는 내용은 그 상황에서만 맞는 내용인데 샘플을 보고 따라서 적다가는 잘못된 방법이 반복되고 고착화 될 수 있다. 샘플에 잘못된 방법으로 적힌 내용이 있는 경우에는 더욱 문제가 된다. 잘못된 것인데도 불구하고 이렇게 적는 것이 올바른 방법인줄로 착각하고 샘플을 참고하여 계속 잘못된 방법으로 적게 된다. 샘플을 보고 작성하는 것보다 혼자서 많은 생각을 하면서 직접 맨땅에 작성해보는 것이 더 나을 때가 많다. 그럼에도 불구하고 대부분의 사람들은 샘플에 대한 유혹을 꺾을 수가 없다.

실리콘밸리에서는 한번 적으면 스펙이 변경되지 않는다는 겁니까?

현실 프로젝트에서 프로젝트 도중에 스펙이 변경되지 않는 경우는 거의 없다. 스펙이 변경되기 때문에 스펙을 작성하지 못하는 것이 아니고 스펙 변경이 기정 사실이고 그럼에도 불구하고 스펙을 제대로 작성해야 한다. 변경이 잦은 프로젝트는 프로젝트 이해관계자들이 서로 다른 스펙을 참조하는 실수도 발생한다. 두 개발자가 서로 다른 스펙을 보고 개발을 한다면 소프트웨어는 통합이 안되거나 버그를 만들어 낼 것이다. 또한 영업에서 구버전의 스펙을 참조하면 엉뚱한 영업을 할 수도 있다. 그래서 스펙의 변경 관리는 매우 중요하다. 변경이 잦은 프로젝트에서는 스펙을 작성하는 방법도 바뀔 수 있다. 변경을 쉽게 받아들이기 위한 노하우를 적용해야 한다. 모든 프로젝트는 다르며 작성법도 프로젝트 성격에 맞게 적용해야 한다.