[웹기획가이드] 서비스정책? 개발정책? 운영정책?

안녕하세요? 야메군입니다. 정말 오랜만에 웹기획가이드를 올려봅니다. 가장 최근에 포스팅한 웹기획가이드가 2018년도 4월이니.. 벌써 1년이 훌쩍 지나버렸네요. 그간 많이 바빴던 것이 사실입니다만, 주제 또는 서두를 열어놓은 채 미완결된 글이 많았던 것도 사실입니다. 제 블로그의 웹기획가이드 코너에 새로운 글이 올라오기만을 기대하셨던 많은 독자 분들께 죄송하다는 말씀을 드리며, 오늘은 많은 기획자들이 어려워하는 기획 영역 중 하나인 정책에 대해 풀어보고자 합니다.

 

여러분은 혹시 정책(政策 , policy)이라는 단어의 뜻이나 개념에 대해 한 번쯤 생각해보신 적이 있나요? 우리는 온, 오프라인 미디어를 통해 정책이라는 단어를 비교적 쉽게 접하는 편입니다. 하지만 정책이라는 단어가 가진 의미를 정확하게 이해하고 있는 경우는 드문 편인데요. 그 이유는 아마도 정책이라는 단어가 사용되는 영역에 따라 조금씩 의미가 달라지기 때문이 때문이라 생각됩니다. 통상적으로 정책이란 단어는 국가 혹은 행정적인 관점에서 많이 다뤄지는데요. 여기서 사용되는 정책의 개념은 이렇습니다.

공공문제를 해결하고자 정부에 의해 결정된 행동방침을 말한다. 정책은 법률·정책·사업·사업계획·정부방침·정책지침·결의 사항과 같이 여러 형태로 표현된다. 정책에는 합법적 강제력을 수반하는 권위가부여되며, 따라서 이러한 정부의 결정이나 방침에 따르지 않을 때는 벌금·제재·감금·규제·제한 등의 조치를 받게 된다. - 행정학사전, 2009. 1. 15., 이종수

공공의 문제를 해결하고자 정부에 의해 결정된 행동방침을... 블라블라블라... 뭔가 심오한 느낌이죠? 하지만 그 다음 구절인 "정책은 법률·정책·사업·사업계획·정부방침·정책지침·결의 사항과 같이 여러 형태로 표현된다."는 내용을 보면 막연하게나마 정책이 가진 의미를 다음과 같이 떠올릴 수 있습니다.

아!! 정책은 뭔가를 진행하기에 앞서 정의해야 하는 규칙이구나...

여러분이 이해하신 것처럼 정책은 구체적인 무언가를 실행하기 앞서 정의해야하는 규칙입니다. 그럼 왜 규칙을 정의해야 할까요? 그 이유는 바로 모두가 합의된 규칙을 통해 실행단계에서 일관성을 유지하기 위함입니다. 또한 규칙을 정의하는 과정에서 여러 변수들을 고려함으로써 안정적인 실행을 하기 위해서이기도 합니다. 어떠세요? 정책의 의미에 대해 조금 더 이해가 되시나요? 기획자가 다뤄야하는 정책을 설명하기에 앞서 서두가 다소 길었는데요. 온, 오프라인을 막론하고 서비스를 기획하는 과정에서 꼭 한 번은 짚고 넘어가야 하는 정책은 그 역할이나 용도에 따라 각각 서비스 정책, 개발 정책, 운영 정책으로 세분화됩니다.

 

앞서 언급된 각 정책은 기획의 담당 범위 또는 유형에 따라 일부분만을 담당할 수도 있고 전체를 정의해야 할 수도 있는데요. 오늘은 신규 서비스 기획 관점에서 각각의 정책을 모두 수립해야 한다는 가정 하에 하나씩 살펴보겠습니다. 

 

서비스 정책; 누구냐 넌?
서비스 정책은 기획하고자 하는 서비스의 개념과 역할 그리고 개략적인 구조가 정의되는 단계로 서비스 기획에 있어 가장 중요한 과정이라 할 수 있습니다. 서비스 기획자는 서비스 정책 수립 과정을 통해 서비스를 구체화하게 됩니다. 흔히 기획의 꽃이라고 이야기하는 화면설계 과정을 과감히 생략하더라도 서비스 정책 수립과정은 절대로 생략해서는 안됩니다. 그 이유는 서비스 정책이 서비스의 골격을 잡아주는 역할을 하기 때문인데, 이후 자세히 후술하겠습니다.

[그림1] 각 정책의 수립시점

 

 

일반적으로 사업기획이 큰 의미에서 서비스의 개념을 정의하는 과정이라면, 서비스 정책은 그 개념을 구현하기 위해 필요한 세부 요소 즉, 단위 서비스들을 정의하게 됩니다. 명확한 이해를 위해 예를 하나 들어보죠. 여러분이 쏘카나 그린카와 같은 카셰어링(Carsharing) 서비스를 기획해야 하는 상황입니다. 이때 사업기획 단계에서 카셰어링 서비스에 대한 개념을 아래와 같이 정의하게 됩니다. 

 

"OOO"는 회원제로 운영되는 도시형 차량 대여서비스로 거주지 인근 거점에서 온라인(PC/Mobile) 비대면 방식을 통해 손쉽게 차량의 예약 및 대여, 반납이 가능한 서비스.

이와 같은 서비스 개념 정의 후, 이를 실제로 구현하기 위해 필요한 단위 서비스의 범위, 서비스의 개념에 부합하는 구조를 수립하는 과정을 우리는 서비스 정책을 수립한다고 이야기합니다. 카셰어링 서비스를 기준으로 본다면 회원, 예약/대여, 반납, 결제, 요금, 쿠폰, 마일리지, 사고처리에 이르는 서비스 전반에 걸친 단위요소들을 도출하거나 여기에 필요한 구조를 정의내리는 행위가 서비스 정책에 해당됩니다. 여기서 이해를 돕기 위해 회원이라는 단위 서비스를 예로 정의를 세분화하면 아래와 같습니다. 

NO.	구분	내용
1.	회원의 정의	"OOO"서비스에서 회원의 이용범위와 운영 목적 등을 정의.
2.	회원의 분류	"OOO"서비스의 회원 종류와 특성을 정의함. (일반회원, 기업회원, 정회원, 준회원 등)
3.	회원의 가입	"OOO"서비스 가입방법 및 가입 시 회원 종류 별로 수집할 정보를 정의함.
4.	회원의 활동	"OOO"서비스 가입 후 회원의 종류 별 활동 범위 및 권한을 정의함.
5.	회원의 탈퇴	"OOO"서비스 탈퇴에 따라 기간 별 보유해야할 정보와 삭제해야 할 정보를 정의함.

 

위와 같이 회원이라는 단위 서비스를 세분화하면 대략 5가지로 분류되며, 이를 각각 정의하면 회원 서비스에 대한 정책 정의가 완료됩니다. 이와 같은 방식으로 다른 단위 서비스를 정리하면 전체 서비스에 대한 정책수립을 마칠 수 있습니다. 참고로 서비스 정책을 정의할 때, 필요에 따라 서비스의 흐름을 손쉽게 파악할 수 있는 서비스 플로우(Flow)를 추가하기도 합니다.

 

아울러 서비스 정책을 작성할 때 Front 서비스만을 생각하는 경향이 종종 있습니다. 하지만 Back-office 서비스도 존재하는 만큼, 이에 대한 서비스 정책도 작성해야 합니다. 다만 Back-office 서비스의 상당 부분이 Front 서비스와 연계되어 있고, Back-office 서비스의 역할이 관리 운용 중심이기 때문에 통상적으로 서비스 정책 요건보다는 운영 정책 요건이 더 많은 편입니다.

 

개발 정책; 그래서 뭘 어떻게 개발하자는건데?
서비스 개발 정책은 개발정의서, 개발명세서와 같이 다양한 이름으로 불립니다. 이 정책서는 앞서 정의된 서비스 정책을 기반으로 실제 서비스를 개발하기 위한 요건 정리의 목적을 가지고 있습니다. 한마디로 기획적 관점에서 작성하는 개발가이드라 할 수 있습니다. 그런데 일부 기획자의 경우 별도의 개발 정책서를 작성하지 않고 화면설계서의 상세설명(Description)에 녹이곤 합니다. 이러한 이유는 두 가지로 볼 수 있습니다. 하나는 개발 정책에 대한 이해가 부족한 경우, 다른 하나는 개발 정책서를 별도로 작성할 필요성을 느끼지 못하는 경우입니다.

[그림2] 회원가입 정보입력 단계에서 고려해야 할 개발 정책

 

개발 정책서에 대한 이해를 돕기 위해 잠시 다른 이야기를 해보죠. 일반적으로 완성된 화면설계서는 리뷰과정을 거쳐 개발자에게 전달되고 개발이 완료되었다는 통보를 받고 테스트를 진행하게 됩니다. 그런데 이 과정에서 기획자들은 이런 생각을 하게 됩니다.

'이게 뭐야!? 이걸 다 개발했다고 던진거야?'

개발 완료를 통보받은 후, 떨리는 마음으로 살펴보니 서비스는 온통 버그 투성이에 기획서에 담긴 기획 내용의 태반은 빠져있는 사실이 확인됩니다. 이때 여러분은 어떤 생각을 하게 될까요? 아마도 많은 수의 기획자들은 개발자의 꼼꼼하지 못함을 탓하지 않을까 싶습니다. 그런데 이러한 헬게이트가 발생한 원인이 정말 개발자가 꼼꼼하지 못하기 때문일까요? 물론 그럴수도 있지만 챗바퀴 돌 듯 반복되는 경험에 저는 이런 생각을 해봤습니다.

'혹시 기존의 화면설계서는 개발자가 보기에 어려운 게 아닐까?'

결론적으로 말하자면 "그렇다." 입니다. 우리가 흔히 접하게 되는 화면설계서는 UI/UX 기반의 시각적 표현 문서입니다. 이 시각적인 비주얼을 표현하는 화면설계서는 디자인 또는 퍼블리싱 작업에는 적합할 수 있습니다. 하지만 개발 시엔 시각화된 UI/UX로 인한 시선 분산이 발생합니다. 우리가 미술관에 갔을 때, 그림에 대한 설명에 먼저 눈이 가기 보다 그림에 눈이 먼저 가는 것과 같은 이치죠. 

 

이러한 상황은 개발자가 화면설계서의 상세 설명에 기술되어 있는 개발 요건에 집중하지 못하는 결과가 야기되며, 여기저기 이가 빠진 채 개발되는 결과로 이어지게 됩니다. 이와 같은 문제를 최소화하기 위해서는 텍스트 중심의 개발 정책서를 통해 개발자가 요건을 명확히 파악할 수 있는 환경을 제공해야 합니다. 

 

ID	1 Depth	2 Depth	3 Depth	기능 명	로그인구분		기능설명	개발정의
					로그인	비로그인
1	약관동의				X	O
F_1.1				이용약관	-	-

 

 

위는 보편적으로 사용하는 개발 정책정의서의 양식입니다. 이 양식을 바탕으로 페이지 단위로 개발을 요하는 기능을 정의해줌으로써 개발 정책서 작성을 완료할 수 있습니다. 위 양식의 각 항목 작성 방식은 다음의 내용을 참고하시면 됩니다.

 

항목 구분	설명
ID	페이지에 귀속된 기능의 단계를 구분하기 위한 표기. (F는 Function의 약자)
Depth	페이지의 depth를 구분.
기능 명	기능의 명칭을 작성.
로그인 구분	해당 기능 이용 시, 로그인의 유무에 따라 이용 가능여부를 O/X로 표기.
기능설명	해당 기능 자체에 대한 설명내용 수록.[각주:1]
개발정의	해당 기능을 개발하기 위한 요건을 정의.[각주:2]
비고	해당 기능 개발을 위해 추가로 전달해야 하는 내용 전달.

 

개발 정책 작성 시, 필요에 따라 기능과 기능의 상호작용 또는 상관관계를 설명하기 위해 논리 프로세스를 추가하여 서술형으로 구성된 개발 정책서의 이해를 도와야 합니다. 위의 내용을 참고하여 개발 정책을 정의하면 개발자와의 커뮤니케이션을 훨씬 더 수월하게 풀 수 있으며, 기획과 개발 과정에서 누락된 내용을 비교적 손쉽게 찾을 수 있다는 점에서 개발 정책서 작성이 필요합니다.   

운영 정책; 누구를 위해 종을 울리나?
운영이란 단어의 뜻에서 미루어 짐작해보더라도 앞서 정의했던 서비스 정책과 개발 정책에 비해 운영 정책은 비교적 명확한 목적성을 띄고 있습니다. 한마디로 서비스의 운영을 위해 고려되어야할 다양한 요소를 담아놓은 정책이라 할 수 있죠. 보통 운영이라고 하면 대 고객 측면의 운영만을 생각하는 경우가 있는데, 운영 정책은 외부 고객 뿐만 아니라 내부 고객의 업무 효율성도 중요한 관점에서 다뤄져야 합니다. 다시 말해 외부 고객과 내부 고객 사이에 적절한 접점을 맞춰야 한다는 말이죠.

 

그럼 내/외부 고객을 바라보는 운영 정책은 각각 어떤 것들이 있고 또 어떻게 나눠야 할까요? 관련해서 여러가지 기준점과 분류 방법이 있을텐데 저는 두 가지로 나눠봤습니다. 먼저 고객의 행위에 따라 서비스의 대응이 이루어지는 운영 측면 그리고 서비스의 행위에 따라 고객이 대응하는 운영 측면으로 나뉘게 되는데요. 이 기준으로 운영의 요소를 분류해보면 아래와 같습니다.

구분	내용
고객의 행위 우선	고객응대(1:1 상담, 채팅상담), 이벤트 프로모션, 게시판 등.
서비스의 행위 우선	각종 커뮤니케이션 채널(이메일, SMS, PUSH, KakaoTalk), 노출전시 등.

 

위의 분류 기준은 행위의 우선순위이며, 어떻게 행위할 것인가? 그리고 어떻게 대응할 것인가?를 운영 정책으로 수립하게 됩니다. 위 분류에서 1:1 상담 항목을 예로 들어보죠. 우선 이 과정을 Flow로 정리 해보겠습니다. 일반적으로는 고객 문의가 접수된 시점부터 글을 읽고, 답변을 남긴 후 고객에게 답변이 완료되었음을 알리면 고객은 답변을 확인하고 답변의 만족도를 선택함으로써 Flow가 마무리 됩니다. 

[그림3] 서비스 내 운영 정책의 개략적인 구조

 

아마도 해당 영역의 개발 정책을 정의할 때 문의가 남겨진 시점에서부터 각 단계 별 Flag 값을 어떻게 처리할 지, 상호작용을 어떻게 설계할 지가 정리되어 있을 겁니다. 그럼 운영 정책에서는 뭘 해야할까요? 질문이 남겨진 시점에서 빠른 시간 내에 원활한 답변이 이루어질 수 있도록 문의가 남겨진 시점에서 몇 시간 이내에 답변 처리를 해야 할 지를 정의해야 합니다. 또한 답변을 접수한 CS 직원이 스스로 처리하지 못하는 경우, 어떤 프로세스에 따라 답변 처리 할 지에 대한 정책도 정의하게 됩니다.

 

이렇게 수립된 운영 정책은 개발 정책에 일부 반영되어 정책을 시스템화하는데 사용되며, 조직 내부의 원활한 운영을 목적으로 사용되기도 합니다. 이에 따라 개발 정책과 운영 정책은 상호 보완적으로 접근해야 하며, 정책 수립시점 역시도 복합적으로 물리는 경향을 보입니다.  

정책 작성을 위한 꿀팁
첫 번째로 정책을 작성할 때는 정책의 종류를 막론하고 목차를 먼저 정리하는 습관을 가져야 합니다. 이를 통해 정책 상에서 빠진 항목이 무엇인지를 점검하고 목차의 흐름이 정책서를 읽는 순서에 따라 자연스럽게 배치되어 있는지도 점검함으로써 보는 이로 하여금 쉽게 이해될 수 있는 구조를 가질 수 있어야 합니다. 이를 위해서는 MS-Word와 같은 문서 툴을 무작정 실행하기 보다 마인드 맵(Mind map) 툴을 활용해 간결하게 목차를 정리해보는 습관을 들이는 것도 좋습니다.

1. 목차를 먼저 정리해라.

2. 명확한 단어를 사용하고 문장을 단순화해야 한다.

두 번째로 해당 서비스에 대한 이해 또는 IT 전반의 이해가 부족한 사람이라도 쉽게 이해될 수 있는 보편성에 기인한 단어를 사용해야 합니다. 또한 간결한 문장구조를 갖춰 글이 쉽게 읽힐 수 있어야 합니다. 정책을 정리하는데 있어 장문의 문장, 비문이 가미된 문장은 그 의미가 이해되지 않거나 명확성이 떨어질 수 있습니다. 이를 최소화하기 위해서는 정책을 정리하고 여러 번 읽어봄으로써 문장을 단순화시키는 과정을 거쳐야 합니다. 물론 두 번째 팁은 반복적인 글쓰기를 통해서도 익힐 수 있으며, 기획자에게 있어서 글쓰기의 중요성은 이미 여러 번 강조한 바 있습니다.  

마치며
지금까지 서비스를 기획하는데 있어서 꼭 거치게 되는 정책에 대해 이야기를 풀어봤는데요. 개발 정책은 신규 기획이 아니더라도 비교적 자주 작성할 기회가 생기지만 서비스 정책부터 개발, 운영 정책에 이르는 전반을 모두 다룰 기회는 1년에 한 번쯤이 될까 말까합니다. 

 

때문에 정책에 대한 이해나 개념이 부족한 경우 정책을 작성할 때마다 막막한 경우가 생기게 됩니다. 마치 뭘 그릴 지 정하지 않은 상태에서 흰 도화지를 펼쳐놓은 느낌이랄까요? 이러한 느낌을 반복하지 않으려면 각 정책의 개념 이해와 꿀팁을 통해 언급한 두 가지의 노하우를 내 것으로 만드는 습관을 길러보시기 바랍니다. END.

 

 

야메군. Web와 Mobile, Digital 카테고리 SME(Subject Matter Expert). 웹기획 18년차로 네이버 웹기획자 커뮤니티 "웹(WWW)를 만드는 사람들"에서 운영진으로 활동하고 있으며, 딴지일보를 시작으로 아이러브스쿨, 짱공유닷컴, YES24 등의 회사를 거쳐, 민간 IT 원천기술 연구소 "Valhalla Lab"에서 Pattern recognition과 Machine learning, Natural Language Processing 기술의 상업적 이용방법에 대해 연구. 현재 하나투어에서 데이터 기반 서비스 설계 중. 2016년 7월 7일, 웹/모바일 기획자의 업무능력 향상으로 위한 Guide Book "처음부터 다시배우는 웹기획(정재용, 최준호, 조영수 공저)" 출간.

 

1. EX. 사용자의 이메일 계정을 입력할 수 있는 input box. [본문으로]
2. EX. 해당 Input box에 최대 200 byte의 텍스트 작성 가능. 사용자 계정과 이메일 서버 이름은 한글 및 일부 특수문자 작성 불가 등... [본문으로]