소프트웨어 디자인 (설계) 문서
새로운 소프트웨어 프로젝트를 시작하게 되면 디자인 (설계) 문서를 작성하는 경우가 많습니다. 빅테크를 비롯한 많은 회사에서 디자인 문서를 중요하게 생각합니다. 하지만 디자인 문서가 그저 불필요한 오버헤드로 전락하게 되는 경우도 많은데요. 애자일 환경에서는 디자인 문서가 필요 없다는 의견도 있습니다만 저는 그에 반하는 입장입니다. 다만 애자일 환경에서의 디자인 문서는 그 목적이 폭포수 개발 방식 때와는 다소 달라졌다고 보는 편이죠.
저는 디자인 문서의 목적은 커뮤니케이션이라고 생각합니다. 디자인 문서를 통해 개발팀뿐 아니라 모든 이해관계자와 의사소통을 보다 명확하게 할 수 있는 거죠. 사람의 언어가 생각을 정확하게 표현하는데 한계가 있기 때문에 언어로만 이루어지는 커뮤니케이션은 항상 어렵습니다. 반면 눈에 보이는 실체를 바탕으로 하는 커뮤니케이션은 상대적으로 쉬운 편이죠. 따라서 애자일 개발에서는 중간 결과물을 지속적으로 이해관계자에게 보여주고 피드백을 받으며 소프트웨어를 작성합니다. 서로 잘못 이해한 부분이 있다면 피드백을 통해 교정하고 이해를 개선할 수 있습니다.
하지만 프로젝트를 시작하기 전이라면 보여줄 중간 결과물이 아직 없죠. 프로토타입을 제작하기도 하지만 전체 프로젝트를 조망할 수 있는 프로토타입을 빠르게 제작하는 것이 항상 쉽지는 않습니다. 공식적인 디자인 문서를 작성하지 않더라도 개발 시작 전에 파워포인트 등 최소한의 회의 자료를 준비하는 과정이 있을 텐데요. 디자인 문서의 목적도 동일합니다. 프로젝트 초기의 커뮤니케이션을 위해 필요한 결과물이죠. 디자인 문서를 통해 앞으로 무엇을 (What) 어떻게 (How) 개발할 것인지 서로 소통하는 것입니다. 물론 디자인 문서는 언어로만 이루어지기 때문에 중간 결과물을 이용하는 것에 비해 명확하게 작성하기 더 어려운 것은 사실입니다. 그러나 본격적인 개발에 앞서 전체를 조망하며 논의를 ‘도와주는’ 도구로써의 가치가 있습니다.
이런 관점에서 보면 디자인 문서에서 가장 중요한 요소는 바로 문제 정의입니다. What에 해당되는 내용이죠. 서로 문제라고 생각하는 부분이 다르면 제대로 된 커뮤니케이션이 어렵습니다. 회의에서 어떻게 해결할지 논의하다 방향을 잃어도 제자리로 돌려줄 북극성 같은 존재가 바로 명확한 문제 정의입니다. 그럼에도 불구하고 디자인 문서에 문제 정의가 명확하지 않거나, 몇 페이지가 넘는 다른 문서로의 링크만 있거나, 심지어 없는 경우도 있습니다. 언제 어느 순간이든 항상 쉽게 참조할 수 있도록 문제 정의는 한두 문단으로 간결하고 분명하게 작성해야 합니다.
문제가 명확하게 정의되면 다음 단계는 요구사항을 정리하는 것입니다. 요구사항이 만족해야 하는 조건은 간단합니다. 주어진 요구사항이 모두 구현된 소프트웨어가 위에서 정의된 문제를 해결할 수 있는지 확인하면 됩니다. 디자인 문서를 읽는 사람들이 서로 다른 문제 정의를 가지고 있다면 필요한 요구 사항에 합의하기 어렵습니다. 따라서 명확한 문제 정의가 잘 정리된 요구 사항을 만드는데 필수적입니다.
요구사항이 작성되면 이제 요구사항을 만족 시기키 위한 소프트웨어의 디자인을 제시합니다. 이 단계에서 던지는 질문은 "주어진 디자인에 따라 만들어진 소프트웨어는 요구사항을 모두 충족시킬 수 있는가?"입니다. 결국 문제 정의는 요구사항과 밀접하게 연결되고, 요구사항은 제시되는 디자인과 연결되어 문서 전체가 일관된 논리적 구성을 가지게 됩니다.
요구사항을 만족하는 디자인을 찾다 보면 모든 요구사항을 만족시키는 여러 개의 디자인을 만들 수도 있습니다. 또는 일부 요구사항을 만족시키지 못하지만 훨씬 높은 효율이 기대되는 디자인도 있을 수 있죠. 디자인 문서에서는 보통 몇 개의 가능한 디자인을 제시하고 각각의 장점과 단점을 분석하여 최적의 디자인을 선택할 수 있도록 합니다. 이해관계자들은 주어진 제안을 바탕으로 최적의 디자인을 선정하고 그 과정에서 요구사항의 일부를 변경할 수도 있습니다.
디자인을 제안할 때 중요한 점은 사용되는 기술이나 테크닉을 선택한 ‘이유’를 설명하는 것입니다. 왜 비동기 통신을 사용하는지, 왜 RDBMS를 사용해야만 하는지 등을 설명해야 개발자 간의 의사소통이 더 쉬워집니다. 뿐만 아니라 개발이 진행되면서 초기 디자인과 다른 접근이 필요하다고 결론을 내리게 될 경우, 디자인 문서를 참조하여 기존 선택의 이유를 확인하고 새로운 접근이 다른 부분과 충돌되는 것은 없는지 확인할 수 있습니다.
마지막으로 중요한 것은 디자인 문서는 법이 아니라는 점입니다. 개발을 진행하면서 더 좋은 방법을 발견할 수도 있고, 요구사항 우선순위에 변경이 일어날 수도 있습니다. 디자인 문서는 중간 산출물이고, 프로젝트가 진행되면서 계속 업데이트가 일어나는 문서입니다. 애자일 환경에서 모든 계획은 상황이 바뀌면 변경될 수 있습니다.
