운영이 없는 프로덕트는 없다
운영을 모르면 반쪽짜리 PM, PO가 된다
1.
프로덕트를 만들어본 경험이 많지 않다면 프로덕트의 모든 기능을 시스템으로 만들고 자동화해서, 특별히 관리를 해주지 않아도 돌아가는 프로덕트를 꿈꾼다. 시스템과 자동화를 통해서 대부분의 업무를 처리하고, 자신은 프로덕트의 방향성을 설정하고, 데이터를 멋지게 분석해서 프로덕트의 개선을 이뤄내는 등의 흔히 말하는 멋진 일을 하고 싶어 한다.
2.
프로덕트를 만드는 직군에 있는 모든 사람들은 이런 상상을 해봤을 것이다. 흔히 PM, PO 하면 이런 것들을 기대하기도 하고. 그러나 시스템과 자동화만으로 돌아가는 프로덕트는 없다. 모든 프로덕트는 운영을 필요로 하고, 운영이 없는 프로덕트는 없다. 다만 그 운영의 범위가 얼마나 되고, 얼마나 까다로운지에 대한 차이만 있을 뿐이다.
3.
아무리 CS 자동화 툴을 통해 여러 가지 시나리오에 대한 답을 만들어 놨다고 하더라도, 유저들은 어떻게든 담당자와 연락할 수 있는 방법을 찾아서 연락을 한다. 이런 유저 대응을 비롯해, 프로덕트의 많은 부분은 운영으로 이루어져 있다. 특정 이커머스에서 파는 상품들은 자동으로 판매 등록이 되는 것이 아니다. 누군가가 커머스 사이트 뒤에서 수동으로 판매하려는 상품을 등록한 것이다. 이 역시도 운영 업무다.
4.
O2O 서비스를 하거나, 오프라인에서의 행사와 관련된 프로덕트라면, 운영의 난이도는 몇 배는 더 높아진다. 오프라인에서의 유저 행동을 IT 기반의 프로덕트로 모두 대응하기에는 한계가 있다. 유저들의 실제 행동을 프로덕트에서의 안내문이나 알림 등으로 유도하는 것에는 한계가 있기 때문이다. 특히 콘서트처럼 짧은 시간 안에 많은 유저들을 대응해야 하는 경우에는 그 난이도가 더 높아지고.
5.
이런 운영에서 역시도 정책이 필요하다. 예를 들어 오프라인 콘서트를 개최하고, 앱 내에서 입장 순서를 보여주는 것으로 프로덕트가 구현이 되었다고 하자. 이때 네트워크 오류로 인해서 특정 유저들의 앱에서 오류가 난다거나, 아니면 전체 유저에게서 오류가 난다고 했을 때 어떤 식으로 유저들을 확인하고 입장시킬 것인지에 대한 정책이 필요하다. 이런 대비책 없이 행사를 진행한다고 했을 때, 문제가 나지 않으면 괜찮지만 혹시라도 문제가 발생한다면 대형 사고로 번질 수 있다.
6.
온라인의 운영 업무이든, 오프라인의 운영 업무이든, 운영 업무는 과소평가되기 쉽다. 왜냐면 시스템을 만드는 게 아니라, 사람이 어떻게 대응할지에 관한 내용이니까. 그러나 운영 업무를 과소 평가하면 프로덕트를 넘어선 서비스를 운영하는 데 있어서 어려움을 겪을 수밖에 없다. 서비스는 프로덕트만으로 이뤄지지 않는다. 서비스를 전개해 나가는 것은 프로덕트와 운영이 함께 조화를 이뤄야 한다.
7.
또한 프로덕트가 잘 만들어지지 않고, 프로덕트 내부의 정책이 명확하지 않다면 프로덕트 바깥의 운영 정책을 정확히 짤 수 없다. 왜냐면 지금의 프로덕트가 유저의 행동에 대해서 어디까지 커버가 가능하고, 어디까지 커버가 불가능한지를 알아야 이를 바탕으로 여러 가지 시나리오를 세워, 이에 대응하는 운영 정책을 마련할 수 있기 때문이다.
8.
내부의 운영 업무에 대해서는 자동화를 못해서 어쩔 수 없이 하는 수동 운영 업무인지, 아니면 시스템화할 수 없는 부분인지에 대해서 구분해야 한다. 전자에 대해서는 해당 운영 업무를 빠르게 자동화해서, 내부의 업무를 효율적으로 할 수 있는 방법을 찾아야 한다. 한 번에 모든 부분에 대한 자동화를 할 수 없더라도, 단계적으로 자동화를 진행해야 한다.
9.
전자의 업무에 대해서는 빠르게 자동화를 하지 않으면, 해당 업무의 담당자는 똑같은 업무를 반복하면서 지치기 쉽다. 반복하면 할수록, 이 업무에 대해서 시간을 쓰는 것이 맞나, 이 업무의 의미가 무엇인가 하는 생각을 할 수밖에 없다. 물론 자동화가 안되어 있다면 해당 업무에 대해서 시간을 쓰는 것이 맞고, 모든 업무는 의미가 있지만 사람인 이상 위에 나온 생각들을 할 수밖에 없다.
10.
또한 저런 생각이 드는 것은 해당 업무가 손에 익고, 익숙해졌다는 것이고, 그 순간부터 휴먼 에러가 날 가능성이 높아진다. 스스로가 다 알고 있다고 생각하기 때문에, 이번에도 똑같겠지 하면서 기계적으로 업무를 반복하게 되고, 이 과정에서 조금의 차이가 생기는 순간 바로 휴먼 에러가 발생하게 된다.
11.
반면 아무리 자동화와 시스템화를 해서 프로덕트를 촘촘하게 구성해도, 사람이 대응할 수밖에 없는 운영에 관련된 업무들이 있다. 대표적인 것이 CS다. CS를 하다 보면, 정말 예상치 못한 문의들을 많이 받게 된다. 자주 묻는 문의나 질문들은 어느 정도 프로덕트를 개선하거나, CS 자동화를 통해서 해결할 수 있다. 그러나 정말 에지 케이스라고 부르는 특이한 문의 사항이나 에러 사항 등은 자동화나 프로덕트로 해결하기가 너무 어렵다. 오히려 자동화나 프로덕트로 해결하려는 시도가 결과의 임팩트 측면에서 봤을 때 리소스 낭비가 되기 쉽기도 하고.
12.
이런 시스템화, 자동화할 수 없는 운영 정책들은 프로덕트의 상황에 맞게 계속 사람이 대응하는 수밖에 없다. 대신 프로덕트, 운영 이해도에 상관없이 누가 대응을 하더라도 일관된 퀄리티나 일관된 프로세스로 대응할 수 있도록 하는 운영 정책을 짜야한다. 그리고 프로덕트의 개선 및 업데이트에 맞춰서 이 운영 정책 역시도 업데이트가 될 수 있도록 해야 하고.
13.
결국 좋은 프로덕트를 만들고, 좋은 서비스를 운영하고 싶다면, 운영의 중요성에 대해 이해해야 한다. 그리고 운영의 중요성을 이해하기 위해서는 여러 유형의 운영 업무를 직접 손에 흙 묻혀가면서 해봐야 한다. 운영의 중요성을 이해하지 못하고, 그저 사람이 대응하는 업무는 '내가 할 일이 아니고 다른 누군가가 해야 할 일이야'라고 생각한다면, 반쪽짜리 PM, PO가 될 수밖에 없다.
