기능정의서, 화면정의서는 무엇이고 왜 필요한 것일까?

개발해야 할 앱 또는 웹 시스템의 기능을 정리한 문서를 기능정의서, 이용 시 적용될 화면을 정리한 문서를 화면정의서라 합니다. 때에 따라 앱/웹에 적용 가능한 수많은 기능들 중 개발해야 할 기능을 정해야 할 필요가 있을 수도 있습니다. 때에 따라 수 백개에 달하는 앱/웹 화면을 모두 기억에 의존하여 표현하는 것은 불가능할 때도 있습니다.

 

 

 

기능정의서와 화면정의서의 필요성

 

한 마디로 개발자, 즉 기획자, 프로그래머, 디자이너가 사람이기 때문입니다. 그래서 기억에 한계가 있을 수 있습니다. 또한 많은 사람이 함께 개발하는 경우 서로 생각이 다를 수 있습니다. 심지에 같은 대상에 대하여 서로 다르게 이해하고 기억하고 있을 수도 있습니다.

 

이런 기억의 한계, 생각의 차이 등은 앱/웹 개발의 불안정성을 증가하게 됩니다. 이렇게 개발 진행되는 앱/웹 시스템은 개발이 진행될수록 버그나, 에러 등의 문제뿐 아니라 서로 간의 개발된 사항에 대한 만족, 불만족의 이견에 휩싸일 수 있습니다.

 

이런 문제를 줄이기 위한 방법으로 사전에 기능정의서, 화면정의서를 통해 상호 협의 결정된 내용을 정리하여 문서화한 후 개발하는 것입니다.

 

하다못해 MVP 개발, 애자일 개발 시에도 기능정의서나 화면정의서 같이 정형적인 문서는 아니더라도 상호 협의된 작업에 대한 공유는 남기게 됩니다. 이것이 회의나 브레인스토밍 결과 사진일 수도 있고, A4 용지나 카카오톡이나 슬랙 등에 적은 내용일 수도 있습니다.

 

그러나 기간이 정해진 복잡한 개발 계약의 경우 구조화 된 문서 양식인 기능정의서, 화면정의서는 개발에 참여하는 수 십 명, 수 백명의 개발자를 관리하고, 상호 협력을 올바르게 이끌어 내는데 판단의 기준이 되는 자료로 작용합니다.   

 

 

 

알 수 없는 마음의 작용. 선호와 변심

 

'왜 내 마음을 몰라?'라는 말만큼 당황스러운 말은 없습니다. 정확히 무엇을 원하는지 말하지 않고 알아서 다른 사람의 마음을 알 수는 없습니다. 일반 사람들은 드라마에 나오는 궁예처럼 관심법을 통달하지 못합니다.

 

그러므로 개발을 요구하는 고객 또는 온라인 서비스 개발 의뢰인의 마음을 읽어서 개발을 하는 것은 불안정하게 됩니다.

 

이러한 마음의 작용은 선호 등의 형태로 나타납니다. 이게 더 좋다. 이전 것보다 이번 것으로 하자 등의 말은 선호를 나타냅니다. 그러데 이런 말 만으로는 왜 더 나은 것인지에 대한 기준이 나타나지 않습니다. 단지 판단을 하는 사람의 선호일 것이라는 추정만 할 수 있을 뿐입니다. 그렇다면 담당자가 바뀌거나 품의 등으로 결제가 필요한 경우 이런 선호 바뀔 수 있다는 것을 의미합니다. 대리와 과정, 팀장의 선호는 다를 수 있기 때문입니다.    

 

결국 이런 의사 결정에 의한 개발은 불안정하게 되는 것입니다. 대표적으로 화면 컨펌에 따른 디자인 수정/변경을 선호의 작용의 예로 볼 수 있습니다.

 

물론 화면 수정/변경을 화면정의서로 완전히 방지할 수는 없습니다. 그러나 최소한 근거를 기반으로 최소화할 수는 있습니다.

 

이외에도 처음 없었던 기능을 갑자기 필요할 것 같다고 해서 추가할 수도 있고, 이번 개발에서는 진행하지 않기로 한 것을 해달라고 할 수도 있습니다.

 

만약 앱/웹 시스템 회사가 자체 개발하는 것이라면 팀 간 협의를 통해 추가 개발 진행할 수도 있습니다.

 

그러나 계약 기간과 개발 비용을 정하고 진행하는 개발의 경우 매우 큰 문제를 발생할 수도 있습니다. 이는 개발 계약의 수행과 관련한 매우 위험한 시도가 될 수도 있는 것입니다. 

 

이 또한 기능정의서로 완전히 방지할 수는 없습니다. 국내 계약의 성격 상 갑의 우월적 지위는 강력하기 때문입니다.

 

그러나 기능정의서의 존재는 근거를 가지고 협상을 할 수 있느냐, 감정 대결이 되느냐를 결정지우는 근거가 될 수 있습니다.

 

  

 

기능정의서, 화면정의서는 무엇인가?

 

기능정의서와 화면정의서는 이름 그대로 기능과 화면을 정의한 문서입니다. 정의라는 말에서 알 수 있듯이 무엇을 개발해야 하는지 정하는 문서이기도 합니다.

 

그렇기에 기능정의서와 화면정의서가 없다면 무엇을 개발할지 정하지 않고 일단 개발하는 것과 같습니다.

 

물론 요구 사항 명세서가 있기는 합니다. 그러나 이는 요구하는 사람 중심의 문서입니다. 개발을 요구하는 사람이 어떻게 개발이 될지 모두 고려하여 정리를 했다면 기능정의서나 화면정의서와 같은 역할을 요구 사항 명세서가 할 수도 있습니다. 

그런데 이 정도라면 직접 개발을 하거나, 직접 프리랜서 개발자를 뽑아 진행하지 개발을 온전히 외부에 맡기지는 않을 것입니다.

 

그러기에 요구 사항은 요구일뿐 어떻게 개발할 것인지에 대한, 투입된 개발자 또는 개발 환경 하의 개발을 위한 설계에 충분한 문서라고 할 수는 없습니다.

 

그러기에 요구 사항 분석을 통해 상세화 한 후, 이를 어떻게 개발할 지에 대한 부분이 필요하게 됩니다.

 

이때의 무엇을 어떻게 개발할지에 대한 구체적인 문서가 기능정의서와 화면정의서인 것입니다. 기능정의서와 화면정의서는 요구 사항에서 나오는 문서로 해당 개발 프로젝트에 대한 앱/웹 시스템에 대한 개발 내용을 구체화합니다.

 

   

 

기능정의서의 작성

 

기능정의를 작성하는 방법이 학문적으로나 기술적으로 정해진 것은 없습니다. 단지 개발될 기능이 무엇인지, 어떻게 개발되어야 하는지 잘 정리되어 있으면 됩니다.

 

일반적으로 앱/웹 시스템의 기능은 전체 기능과 파생되는 기능으로 구분되기도 합니다. 어떤 기능의 작동 프로세스가 진행되면서 다시 구분되는 몇 개의 하위 기능 프로세스가 완료되면서 기능의 흐름을 형성하기도 합니다. 이때는 기능을 트리 형태로 정리하면 기능의 내용을 파악하는데 도움이 될 수 있습니다.

 

기능에 따라 독립된 완결된 작동을 하는 것이 아닌  여러 기능의 작동에 활용되는 공통 기능이 존재할 수도 있습니다. 이 경우 공통 기능을 여러 기능의 하위로 넣어 여러 번 정리하는 것보다는 따로 공통 기능으로 정리하고, 각 기능에서는 공통 기능이 있다는 것만 표시하는 것이 기능을 파악하는데 효과적일 수 있습니다.

 

결국 기능정의서는 개발할 앱/웹의 기능이 무엇이고 어떻게 되어야 하는지 개발자가 잘 파악할 수 있게 정리만 되면 됩니다.

 

규모가 작은 앱/웹 시스템의 경우 회의 시 화이트보드에 적은 내용을 공유하는 것 만으로 기능정의는 충분할 수도 있습니다. 그러나 개발 규모가 커지고 복잡해지면 이렇게 회의를 통해 기능을 정리하고 공유하는 것은 불가능해집니다.

 

실제 제가 경험한 대규모 프로젝트는 제가 투입되기 전 수개월 오전 9시에서 오후 6시까지는 회의만 하고, 6시 이후 개발을 하고 있었는데 진행되는 내용이 없었습니다. 그렇게 회의를 했지만 확정된 기능이 없었습니다. 아니 제가 회의에 한번 참여해 본 느낌은 이렇게 어떻게 기능을 확정한다는 것이니 알 수 없는 상황이었습니다. 1시간 회의면 참여한 팀들이 의견 하나씩 내면 끝나는 상황이었습니다.

 

이렇게 아주 복잡한 시스템 개발에서는 회의로 기능 정의하는 것은 이런 문제를 야기합니다. 기능 정의가 되지 않습니다. 그러므로 초기 분석/설계가 선행되어야 합니다.

 

이러한 개발 상황에 따른 기능정의 방법에 대한 것이 경험이나 기획 역량의 한 부분이라 할 수 있습니다.

 

 

 

화면정의서의 작성 

 

화면정의서 구조의 기본은 IA 또는 메뉴라 할 수 있습니다. 어차피 정의할 화면은 앱/웹 시스템 메뉴에 존재하기 때문입니다. 

 

이는 매우 간단해 보일 수도 있습니다. 그러나 수 백개의 화면이 있는 앱/웹의 화면정의를 하다 보면 이 간단한 일이 결코 간단하지만은 않다는 것을 느끼게 될 것입니다.

 

제가 참여한 프로젝트에서 이전 운영 중인 시스템을 분석하는 일이 있었습니다. 그런데 분석이 안되었습니다. 개발자와 이야기를 해보아도 결론은 분석 불가였습니다. 이 시스템을 운영 중인 담당자와도 이야기해 보았으나 분석 불가였습니다

 

결국 기존 운영 중인 시스템과 별개로 개발하게 되었습니다.

 

물론 분석 불가에는 기존 개발된 기능 코드가 분석 불가하게 때문이기도 했습니다. 그러나 대형 시스템에서 기획자의 설계 문서가 분석 불가한 이유도 있었습니다.

 

주로 기획자의 앱/웹 설계는 화면 중심의 설계서입니다. 이것도 분석이 불가한 경우도 있습니다. 같은 화면이 중간중간 나타나기도 하고, 또 때로는 같은 화면 같은데 조금씩 다를 수도 있습니다. 결정적으로 화면과 화면의 흐름을 이해할 수 없는 경우도 있고, 화면이 구성이 기능의 작동과 매칭되지 않는 경우도 있습니다. 

 

화면정의서 없이 바로 화면 설계를 할 경우 이런 혼동은 쉽게 발생합니다. 기획자는 사람이고, 사람의 뇌는 그렇게 기억이 일관되지 않기 때문입니다. UX가 이런 뇌의 작동에 기반하는 것이기도 합니다.

 

특히 스토리보드와 같이 페이지로 구분되는 경우 더욱 기억의 모호성을 증대시킵니다. 이는 사람인 이상 어쩔 수 없는 패시브 현상입니다.

 

그래서 한눈에 개발될 앱/웹 시스템 화면 구조를 파악할 수 있는 화면정의서가 필요한 것입니다. 

 

물론 규모가 큰 시스템인 경우 화면정의서가 복잡하고 내용도 많아 한눈에 확인하게 어렵게 될 수 있습니다. 이때 정리하는 것이 프로젝트 경험 및 화면 기획 스킬이 됩니다.