brunch

You can make anything
by writing

C.S.Lewis

쉬어가기 편. 서비스 기획자에 대한 미신과 실체

"진짜 서비스 기획자는 이런가요?" 궁금했던 사람들 대.환.영.

벌써 <서비스기획학개론> 브런치북이 5회를 넘어가고 있습니다.

지금까지 열심히 서비스 기획의 기초에 대해 배우느라 지친 심신을 위로하기 위해, 이번 편은 쉬어가기 편을 준비해보았습니다!

IT 직군에 대해서 일반적으로 떠올리는 이미지가 있을 텐데요, 사실 현직에서 일하다보면 이전에 생각했던 모습과 다르다는 것을 많이 느낍니다.

오늘은 서비스 기획자에 대해 일반적으로 가지고 있는 ‘미신’과 그 실체에 대해 알아볼까요?



IT 기업 다니면 워라밸이 좋은가요?


서비스 기획자만 아니라 보통 IT 업계에 대해 전반적으로 워라밸이 좋다는 생각을 하는 분들이 많습니다.

결론부터 말씀드리면, 서비스 기획자의 워라밸이 좋다고 말씀드리기는 어렵습니다. 물론 회사와 부서에 따라 차이가 크겠지만요!

일단 IT 대기업들의 경우에는 재택근무, 자율근무제 등을 보장하는 기업들이 많기 때문에 업무를 수행하는 것에 있어서의 자율성은 큰 편이긴 합니다. 그렇다고 해서 work와 life 중 life를 더 잘 챙기게 되냐고 묻는다면, 그렇다고 말씀드리기 어렵습니다.

근본적인 원인은, IT 서비스는 24시간 휴식 없이 돌아가기 때문입니다. 나의 서비스가 계속 돌아가고 있는 만큼, 서비스를 만들고 운영하는 사람도 일을 완전히 off 하기 어렵습니다.

휴가를 가더라도 어쩔 수 없이 업무 메시지를 확인하거나, 분명 휴가 가기 전까지는 문제 없이 잘 돌아가던 서비스가 갑자기 휴가에 가니 제가 맡은 부분에 대해 오류가 발견되는 경우도 있습니다.

물론 한 서비스를 무조건 한 명이 맡는 건 아니기 때문에 팀원들이 백업을 해줄 수 있지만, 제가 기획한 특정 기능에 대해 오류가 발생하면 보통은 가장 잘 아는 담당자가 확인이 필요한 경우가 많습니다.

IT 서비스가 24시간 돌아간다는 것 외에도 서비스의 발전은 끝이 없고, 굉장히 빠르게 돌아가는 산업이기도 해서 일 자체가 많은 편이기도 합니다.

(진리의 사바사이고, 덜 바쁜 시기도 있지만, 제가 아는 많은 기획자 분들은 야근을 정말 많이 하는 것 같습니다..ㅎㅎ)



기획자는 기획만 하나요?


이전 화에서 말씀드렸던 것처럼, 기획자는 기획만 하는 직무는 아닙니다.

보통 입사 전에는 열심히 새로운 기능을 기획하고 해당 기능의 화면을 그리는,, 그런 이미지로 기획자를 상상하기 쉬운데요, 실제로는 기획보다는 기획 관련 부수적인 업무만 하다가 하루가 끝나는 경우도 많습니다.


대표적인 부수적인 업무로는 ‘CS’ (고객 문의) 처리가 있습니다. IT 서비스는 출시 시점에 완벽하게 나가는 게 베스트지만, 실제로 타이트한 출시 일정 때문에 모든 기능, 문구 등이 완벽하게 출시되는 건 쉽지 않습니다. 그렇기 때문에 사용자들은 IT 서비스가 제대로 동작하지 않아 불편함을 겪게 되고 이에 대해 문의를 하게 됩니다.

이때, 확인이 필요한 부분이 생기면 누구에게 전달이 될까요? 바로 문제가 생긴 부분을 기획했던 기획자입니다! 그 기능을 만든 사람이자, 스펙(specification)을 가장 잘 아는 사람이 바로 기획자이기 때문입니다.

회사의 규모나 CS 전문 조직의 유무에 따라 기획자는 해당 문의를 바로 처리를 하거나, 사내 CS 조직을 통해 받게 됩니다. 이 문의에서 사용자가 겪는 현상이 무엇인지, 원인은 무엇인지, 대응 방법은 무엇인지 등을 파악해야 합니다. 서비스의 동작에 어떠한 문제가 있어 추가적인 확인이 필요하면 개발에 확인 요청을 해야하고, 기능 자체에 대한 문의라면 개발 확인 없이 바로 답변을 하기도 합니다.


CS 외에도 리서치나 통계 분석 등의 업무도 일상적으로 수행합니다. 어찌보면 당연한 이야기입니다. 비슷한 서비스를 제공하는 타사는 어떤 기능들을 출시하고 있는지, 시장 트렌드는 어떤지 등을 지속적으로 리서치하고, 우리 서비스는 어떻게 사용되고 있는지 통계를 보며 파악해야 사용자가 원하고 필요한 기능들을 기획할 수 있습니다.

따라서 기획자는 보통 실제 기획 단계에 들어가기 전에 리서치를 하게 되고, 필요에 따라 딥하게 타 서비스 벤치마킹을 하게 되는 경우도 있습니다.


기획자는 개발자랑 사이가 안 좋은가요? / 개발자는 항상 안 된다고 하나요?



개발자는 절대 안 된다고만 하지 않습니다.

오히려 개발자, 디자이너 모두 함께 과제에 대해서 고민해주시고 기획자가 가져간 안 외에도 가능한 안들에 대해 먼저 의견을 적극적으로 주시는 편입니다.

문제를 해결할 수 있는 방법은 여러 가지이기 때문에 기획자가 개발/디자인 관점에서 생각할 수 없는 부분을 채워넣어주시기도 하고, 가끔은 사용성 개선을 위해 먼저 특정 기능에 대해 수정 제안을 주시기도 합니다.


다만, 서로의 생각이 다르고, 이를 맞추기 위해 직군 상관없이 많은 이야기를 나누는 건 사실입니다!

기획자는 보통 사용자의 시선으로 서비스를 바라보고, 개발자는 개발적인 측면에서 서비스를 바라보게 됩니다. 이로 인해 특정한 기능에 대해 이야기를 할 때, 기획자가 이해하는 내용과 개발자가 바라보는 시선이 다른 경우가 많습니다.  기획에서 원하는 기능이 개발 자체가 불가한 경우도 있고, 개발적으로 효율적인 구현 방안이 UX 측면에서 수용하기 어려운 상황이 발생하기도 합니다.


이렇듯 서로 다른 입장 속에서 의견을 교환하고 생각을 조율하는 과정이 필요하고, 이를 위해 많은 의사소통이 이루어집니다. 이때 한쪽에서 다른 쪽의 상황을 이해하지 못하고 고집을 부린다면 언성이 높아질 수도 있겠지만..! 흔한 케이스는 아닙니다.

IT 서비스를 만드는 사람들은 다들 자신의 서비스에 대한 애정이 있고, 최선의 방향을 찾고 싶어하는 공통의 목표가 있습니다. 서로의 이야기를 듣고 이해하며, 더 나은 해결책을 찾기 위해 논의를 계속하는 거지, 절대 사이가 좋지 않아서 싸우는 게 아닙니다! (다들 먹고 살자고 하는 일인 걸요 ㅎㅎ)




오늘은 쉬어가기 편으로 서비스 기획자에 대한 생각과 진실에 대해 이야기해보았는데요,

이번 편이 서비스 기획자의 실제 업무를 조금 더 이해하고. 가까워지는 시간이 되었으면 좋겠습니다.

다음 화는 다시 <서비스기획학개론> 본편으로 돌아오겠습니다!

이전 05화 4. IT 서비스의 Product Lifecycle
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari