brunch

라이킷 105 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by June Jun 21. 2020

기획 산출물 #1 기능 정의서

개발자와 어떻게 커뮤니케이션할까?

돼요 안돼요?

내가 생각하는 수 없이 멋지고, 번뜩이는 아이디어를 기획안에 녹여내었다. 정말 내가 생각했지만 기가 막히는 아이디어였다. 이제 개발자에게 기획안을 전달하는 리뷰 시간을 가지게 되었고, 나는 혼돈과 분노의 감정에 휩싸이게 되었다. 기능의 실현 가능성도 고려하지 않았고, 기능의 세부적인 동작과 어떤 데이터가 필요한지, 데이터가 어떻게 활용되는 건지 아무것도 고려하지 않았기 때문이다. 수없이 많은 "No!"를 리뷰 시간에 듣고 나서 나는 기획안을 새로 작성하게 되었다.

이번 글은 번뜩이는 아이디어를 기획안으로 녹여내는 과정에 있어 가장 처음으로 작성하는 기능 정의서에 대한 생각을 적어보았다.

글의 순서는 아래와 같다.

1. 기능 정의서는 무엇이며, 왜 작성하는 걸까?
2. 기능 정의서, 어떻게 작성하는 걸까?
3. 그래서 작성한 기능 정의서로 어떻게 개발자와 이야기를 나눌까?

기능 정의서는 무엇인가요?

기능 정의서는 각각의 기능에 대해 정의를 내리고(무엇), 개발 요건 등을 담은 설명을 통해 기능이 어떻게 구현되어야 하는지(어떻게 만드는지)를 기재한 문서다. 본격적인 기획의 가장 첫 단계이며, 첫 단계이니만큼 개발하고자 하는 기능 또는 프로젝트의 방향성을 잡아주는 역할이 되기도 한다. 사실 이 앞 단계에 요구사항 정의를 내리기도 하는데, 현재 몸 담고 있는 회사에서는 개발자와의 협의를 통해서 요구사항 정의는 생략하고, 기능 정의서 초안을 리뷰하는 시간을 통해 개발 구현 가능 여부를 확인하고, 이후에 상세 기획을 진행하고 있다.

기능 정의서는 왜 작성하는 거예요?

기능 정의서는 기획한 기능에 대해 개발자와 소통하기 위함이며, 개발자에게 해당 기능을 어떻게 구현해달라고 요청하는 문서와 같은 개념이라고 생각하면 된다. 기획자가 "무엇"에 해당하는 기능을 정리하고 기능의 동작에 대한 부분들을 기재하고 개발자와 얘기함으로써 어떻게 구현할지를 개발자로부터 보완한다. 그렇게 해서 각각의 기능들을 만들어내고, 하나의 앱을, 하나의 프로젝트를 구현하게 된다.

어떻게 작성하는 걸까요?

나의 경우 보통 버전 관리를 별도로 작성하고 기능 정의서 내에는 기능 ID, 기능이 들어가는 페이지, 주요 기능, 기능 정의, 기능 설명 정도만 작성하여 개발자와 소통한다. 하지만 회사 프로세스나 또는 프로젝트에서 필요에 따라서 예외/처리가 추가되기도 하고, 기능 설명도 더 세분화해서 진행하는 경우도 있다. 보통은 엑셀로 작성하나, 나의 경우는 개발자의 편의를 위해 JIRA와 연동하기 쉽도록 Confluence(컨플루언스)에 템플릿을 만들어 작성하고 있다.

1. 버전 / 수정 이력 관리하기

버전 / 수정 이력을 남기는 건 꽤나 중요하다. 별거 아니라고 생각할 수도 있겠지만, 일은 혼자 하는 게 아니기 때문에 수정 이력을 기재하지 않으면 어느 순간 기획이 꼬이고, 개발이 꼬이고, 모든 게 꼬여버리게 된다.

일단 제일 먼저 버전과 수정 이력을 관리할 수 있는 양식을 만들어 준다. 피피티나 엑셀로 작성할 때도 마찬가지다. 버전 및 수정 이력을 관리하지 않으면 나중에 어떤 부분이 수정되었는지, 초기 기획과 달라진 부분이 무엇인지도 파악하지 못해 프로젝트가 점점 산으로 가게 된다. 또한 프로젝트 진행은 혼자 하는 게 아니다. 만약 변경된 부분들을 기재하지 않게 되면 하지 않기로 했던 부분이 덜컥 개발되었다고 나온다거나, 기획이 변경되었음에도 초기 기획 때의 기능이 툭하고 나와버릴 수 있다.

버전 관리는 회사 내 일정한 프로세스를 수립하는 것이 좋다. 나의 경우에 기획 내부에서의 변경사항들은 마이너 업그레이드로 조정한다. 이를 테면 1.0에서 1.1로 업데이트한다. 그리고 개발자와의 리뷰를 진행하고, 리뷰를 통해서 나온 수정, 보완, 개선 사항을 반영하게 될 경우 메이저 업그레이드를 진행(1.0 -> 2.0)한다. 혹은 주요 기능이 추가되거나, 변경되는 경우에 메이저 버전을 업데이트하는 경우도 있다. 이는 앞서 말했듯 회사 내 일정한 규칙을 정하는 것이 좋다.

2. 기능 정의서 작성하기

버전 관리 양식을 만들었다면, 이제 기능 정의를 내리는 시간이다. 딱히 정해진 양식은 없지만 개발자와 논의해서 반드시 들어가야 하는 내용들을 정하는 것이 좋다. 결국 이 문서를 가장 많이 보는 건 개발자이기 때문이다.

가. 기능 ID 부여하기

ID는 각 기능별로 부여한다. ID는 고유한 번호로써 하나의 기능에 하나의 ID만 부여한다. ID를 부여하는 이유는 추후에 해당 ID를 토대로 기능이 무엇이었는지를 파악하거나 검색하기 쉽게 하기 위함이며, 의사소통 간에도 다소 긴 명칭 대신 ID를 이용해서 명확하게 의사를 전달하기 위함이다. 기능 ID를 부여하는 방법은 딱 정해진 것은 없고, 회사 내에서 규칙을 수립하면 된다. 나의 경우에는 7자리의 일련번호를 부여한다. 규칙은 아래와 같이 적용하고 있다.

나. 페이지(Depth)

기존에는 페이지 구조를 나누거나 기능의 상/하위 관계를 나누곤 했었는데, 개발자와 논의 끝에 해당 기능이 반영되는 페이지만 기재하는 걸로 변경하였다. 그리고 각각의 장단점이 있겠지만, 결국은 해당 기능이 어디서 구현되는 지를 표현해주면 되는 작업이다. 대신 우리는 기능에 대한 자세한 내용은 기능 설명 부분에 추가하였다.

다. 주요 기능

기능의 명칭을 기재하는 영역이다.

라. 기능 정의

기능이 동작하는 액션, 주요 역할을 기재한 영역이다. 앞서 말한 주요 기능(명칭)이 하는 역할을 의미한다.

마. 기능 설명

기능 정의를 내림에 있어 가장 공을 들이는 부분이다. 일단 우리 회사의 경우 프로젝트를 진행할 때 산출물로 기능 정의서와 화면 설계서, 제플린(디자인)만 생성해서 진행하기로 하였기 때문에 기능 정의를 상당히 자세하게 기재하고 있다.

나의 경우 기능 설명 부분은 유저에게 보이는 영역인 프론트 영역과 유저에게 보이지 않는 백 영역을 구분지어서 작성하려고 하고 있다. 주로 작성하는 내용은 아래와 같다.

1. 프론트 영역 : Type, 문구, 표기 방법(시간 또는 지역 등), 각 부분이 동작하는 방식, 페이지 이탈 또는 이동 등 화면에 보이는 부분들을 위주로 기재

2. 백 영역 : 화면에 표시되는 정보 / 정보의 종류, User Action에 따라 어떤 정보들을 나타내고 처리하는지, User가 입력한 데이터는 무엇인지, User가 입력한 데이터에 따른 출력은 어떻게 되는지를 기재

개발자와는 어떻게 소통하나요?

이제 작성한 기능 정의서를 토대로 개발자와 리뷰를 가지는 시간을 가지면 된다. 사실 개발자와의 소통은 꽤 어렵다고 느껴질 수도 있는데, "No!"를 외치는 경우들도 많고, 꽤나 자세한 설명을 요하는 경우도 있기 때문이다. 하지만 개발자들이 하기 싫어서 그러는 건 절대 아니다. 기획이나 디자인에서는 간단한 작업, 별거 아닌 작업일지라도 개발자에게는 꽤나 큰 작업이 될 수도 있다. 시스템을 유지해야 하고, 변경 시 어떤 상황들이 터질지 모르기 때문에 개발자의 입장에서는 가급적이면 잘 진행되고 있는 시스템을 건드리고 싶지 않기 때문이다. 내가 생각하지 못했던 부분들이나 더 자세한 내용을 요구하는 경우에도 마찬가지로 기능에 대해 전체적으로 구조를 짜고, 설계함에 있어 필요하기 때문이다. 이러한 이유 때문에 나는 종종 개발자와 짧거나 긴 미팅을 수시로 가지는 편이기도 하고, 기능 구현 여부, 시스템 적용 가능성을 계속해서 이야기하곤 한다. 물론 그래도 예상치 못한 의외의 상황들은 항상 있다.