아기 UX기획자가 바라본 기획자의 역할

“왜 단위테스트 진행을 안해요! 어제 다 개발완료 찍어서 넘겼잖아!!” 쩌렁쩌렁 울리는 회의실 안에 바짝 긴장한 물에 젖은 아기 기획자 한마리가 벌벌 떨고 있었다. 이것이 내가 경험한 아기 기획자 세계.

2020년. 나는 졸업 후, 외국계 광고 회사를 거쳐 UX 기획일을 하게 되었다. 그리고 중간에 투입된 프로젝트. 보안때문에 여러 회사의 많은 인원이 고객사의 회사에 들어가 몇 개월간 일을 하게 되었고, 곧 서비스 출시를 앞두고 있다. 그 속에서 과연 아기 기획자는 무엇을 할 수 있었을까? 그리고 아기 기획자가 본 기획의 세계란 무엇이었을까.

최근에는 스타트업이나 외국에서는 Agile방식으로 프로젝트를 진행하기도 하나, 아직까지 한국에서 많은 기업들이 채택하고 있는 프로젝트 프로세스가 waterfall 방식이라면 99% 이렇게 돌아간다.

기획 - 디자인 - 퍼블리싱 - 개발

그 중에서 기획자는 기획 앞 단계 일을 맡겠고, 개발 단계까지 모두 자신이 기획한 것이 제대로 결과물이 나왓는지 끝까지 책임져야 한다. 그러므로 매우 책임감이 막대하고, 다른 파트보다 챙겨야 할 일들이 많다.

나는 아기 기획자였기 때문에 처음에는 하나의 파트에서 떨어지는 작은 일들을 맡아 하다가, 나중에서야 하나의 꼭지를 온전히 맡게 된 케이스였다. 그 후부터 나의 고군분투기는 시작되었다.

1. 기획자는 커뮤니케이션을 한다.

기획자의 아주 중요한 역할 중 하나가 바로 커뮤니케이션이다. 기획을 하기 위해선 여러가지 상황이 존재한다. 서비스가 출시될 환경을 말하는 것인데, 그 상황은 기획을 하기 위한 제한이 되기도 하고 요건이 되기도 한다. 그 상황을 고려해 서비스 요건을 수립하고 정책을 세운다. 그러한 환경들은 대게 마케팅팀, 상품팀 등에 의해 좌지우지되는 경우가 많기 때문에 여러 팀들과 소통하게 되며, 그것들을 화면단에 넘겨 UI기획을 한다. 그렇게 기획한 것들을 디자인팀에게 넘기고, 내가 기획한 것이 개발 단까지 제대로 되었나 확인해야 하기때문에 대게 모든 부서와 커뮤니케이션 하게 된다고 할 수 있다.

이 상황에서 엄청난 지식이 필요하다. 디자인도 알아야하고, 개발 지식도 있어야 똑똑한 기획자가 될 수 있다. 화면 기획은 레이아웃이나 타이포를 어느 정도 알아야 보기에 좋은 화면 기획을 할 수 있고, 사용자를 고려한 화면이 된다. 디자이너 출신 UX기획자가 많은 편이지만, 한국에는 다양한 전공의 기획자가 많으므로 똑똑한 기획자가 되기 위해선 디자인 지식도 필요해 보인다. 또한, 개발 지식도 알아야 내가 기획한 정책이나 화면이 기술적으로 가능한지 캐치할 수 있고 불필요한 커뮤니케이션을 줄이거나, 커뮤니케이션 할 때 원활하게 진행이 된다. 그렇지 않으면 개발자와의 회의에서 무시당하는 수가 있고 아무것도 못알아 들을 수 있다는 슬픈 현실 ㅠㅠ

2. 기획자는 화면정의서를 만든다.

화면 정의서는 프로젝트마다 다양한 언어로 불리우고 있다. Story Board 또는 그의 약자 SB. 어떤 곳에는 MMI라고도 하고 화면 정의서라고 부르기도 한다. 이것은 어떤 서비스를 웹이나 앱 또는 키오스크등에 녹일 때 사용자들에게 어떻게 보이게 될 것이냐 하는 화면을 기획한 문서이다. 여기에는 와이어프레임으로 표현 된 화면 모습과 각 화면에 표현된 구성 요소들이 정의되어 있다. 예를 들면 어떤 버튼이 있다면 이 버튼은 어떤 역할을 하는 버튼인지, 이 버튼을 누르면 어떤 일이 일어나는지 등이 상세하게 정의되어 있다. 이 문서는 앞으로 디자이너들과 개발자들이 보고 내가 기획한 것을 결과물로 만들어 내는 데에 쓰이며 화면 정의서는 대게 파워포인트로 만들어 지지만, 최근에는 XD나 Axure등 다양한 툴들로 만들어 지고 있다.

3. 기획자는 단위테스트를 진행한다.

단위테스트란 무엇인가? 단위테스트란 대게 기획자가 기획한 대로 기능이 제대로 돌아가는지 보는 개발 테스트이다. 테스트는 단위테스트와 통합테스트로 나뉘어지는데, 줄인말로 ‘단테’, ‘통테’로 부르기도 한다. 단위테스트 문서는 엑셀로 관리하고 대게 화면ID단으로 문서를 만들게 된다. 개발자마다 단위테스트를 어디까지 봐야하는지 의견이 다르고 프로젝트마다 다르니, 각 프로젝트에서 수행되는 대로 따라가면 될 것 같다. 내가 맡았던 프로젝트에서는 제대로 화면이나 이미지가 나오지 않더라도, 버튼을 눌렀을때, 제대로 된 기능을 수행한다면 통과하는 것으로 정의했고, 세부적인 것들은 통합테스트에서 진행하는 것으로 가이드가 나왔다.

단위테스트는 아래와 같았고 결과는 Pass, Fail, N/A였으며, 1차로 개발자가 진행해서 패스가 되면 다음이 2로 기획자가 테스트를 해수 기획자가 기획한 대류 개발이 되었는지 확인하는 단계였다. 이 전 GUI테스트라고도 하는 퍼블검수는 기획자가 하는 때도 있지만 각 역할 분담에 따라 내가 맡은 프로젝트에서는 디자인팀에서 하게 되었으므로 화면이 제대로 잘 나오는지, 레이아웃 배치가 맞는지 등은 단위테스트 대상에서 제외되었다.

[단위테스트 예시]
1. [전화 상담]버튼을 눌렀을 때 로그인 시 전화 상담 팝업 페이지가 뜨는가?

2. 비 로그인시, [마이페이지] 메뉴를 눌렀다면, 통합 로그인 페이지로 이동하는가?


만약 1차 개발자 단위테스트에서 Fail이 나왔다면 개발을 다시 해서 Pass가 나올 때까지 검수 후 기획자로 테스트를 넘겨야 한다. 또한 테스트가 퍼블 미개발 또는 다른 파트 미개발로 인해 테스트 불가 시 N/A처리를 하고 사유를 비고란에 적어 기획자에게 넘겨주어야 한다. 이것이 무슨 말인가 하면, 큰 서비스일 경우 개발자도 각 파트별로 나뉘어져 있다. GNB, 플로팅 버튼 등 공통을 개발하는 파트, 상품파트를 개발하는 개발파트, 전시파트를 개발하는 개발파트 등으로 나뉘는데, 하나의 서비스 화면은 서로 얽히고 얽혀 있으니 한 파트에서 개발이 안되었거나 하는 것은 개발 후에야 단위테스트가 진행이 될 수 있는 것이다. 이 파트는 다른 파트의 개발이 완료될 때까지 기다렸다가 기획자에게 넘기는 것이 맞지만, 각 파트별로 맡는 회사가 다르고 프로젝트 진척률에 영향을 미칠 수 있으므로 우선 N/A로 처리 후 개발 완료 시 다시 N/A건만 재검토 하는 방법을 사용하는 것 같다.



지극히 내가 경험했던 프로젝트를 바탕으로 크게 3가지 꼭지로 써 본 것이라 매우 편협적일 수도 있다. 댓글로 다양한 방식을 알려주면 나에게도, 또 이 글을 읽는 다른 사람에게도 많은 도움이 될 수 있으리라 생각한다. 다음 파트에서는 화면 기획서를 쓰는 방법, 프로젝트 진척 관리 시 기획자의 개발자와의 소통 법 등에 관해 써 내려가고 싶다. 아기 UX디자이너로 기획파트를 배우고 있는 나에게 격려의 눈길을 보내주면 참 감사하겠다. 파예는 계속 파이팅 하고.