모든 프로덕트는 두 개의 프로덕트로 이뤄진다

유저에게 보여주는 프로덕트와 백오피스 프로덕트

1.

모든 프로덕트는 두 개의 프로덕트로 이뤄진다. 실제 유저가 보고 쓰는 프로덕트와 프로덕트를 관리하는 프로덕트인 백오피스 프로덕트. 백오피스 프로덕트는 어드민 시스템, 관리자 페이지 등등 회사에 따라서 다양한 이름을 가진다. 요즘은 내부 구성원들이 사용하는 프로덕트라고 해서 인터널 프로덕트라는 이름으로 불리기도 한다. 백오피스나 어드민이라는 단어에는 프로덕트라는 단어가 잘 붙지 않는데, 최근 인터널 프로덕트라는 단어가 쓰이면서, 백오피스의 중요성을 점점 많은 곳에서 알아가고 있는 것 같다.

2.

많은 프로덕트 아티클, 컨텐츠, 전문가들이 실제 유저들이 쓰는 프로덕트의 중요성을 말하지만, 실제 유저들이 사용하는 프로덕트만큼 중요한 백오피스, 인터널 프로덕트에 대해서는 크게 다루지 않는다. 아마 IT 해외에서는 좀 더 많을 거 같긴 하다. 백오피스의 경우, 실제 유저들이 쓰지 않고 조직 내부에 구성원들만 쓰다 보니 눈에 잘 띄지 않아서 그런 것 같다. 또한 많은 사람들 역시 겉에서 보이는 실제 유저들이 사용하는 프로덕트에 더 관심을 갖지, 그 프로덕트 뒤에 있는 백오피스에 대해서는 잘 관심을 갖지 않아서 그런 걸 수도 있고.

3.

많은 사람들의 관심도가 낮을지라도, 백오피스, 인터널 프로덕트는 실제 유저들이 사용하는 프로덕트만큼이나 중요하다. 백오피스 프로덕트가 없다면, 실제로 유저들이 사용하는 프로덕트를 대응하기 위한 여러 가지 운영 업무를 하기가 상당히 어려워진다. 회사마다 조금씩 다르지만, 조직에서는 백오피스 프로덕트를 이용해 유저를 조회하고, 상품을 등록하고, 결제 내역을 확인하는 등 운영에 필요한 업무를 진행할 수 있다.

4.

여기서 말하는 운영 업무란 시스템만으로 처리되지 않고, 사람이 직접 수기로 해줘야 하는 업무이다. 그리고 이 운영 업무는 시스템이 얼마나 고도화되었느냐에 따라 달라진다. 예를 들어서, 유저가 사용하는 프로덕트 내에 결제 취소 기능이 없다면, 담당자가 유저의 CS를 받아 직접 결제 취소 처리를 해줘야 한다. 이때 백오피스에서 결제 취소 처리가 가능하다면 좀 더 수월하게 운영 업무를 처리할 수 있다. 만약 백오피스가 없다면 이 때는 개발자가 결제 취소 관련 업무를 해줘야 한다. 이렇게 백오피스가 없다면 운영의 난이도가 급상승할 수밖에 없다.

5.

이외에도 마케팅 수신 동의 유저에게 마케팅 문자를 보내려고 하는데, 백오피스가 없어 유저 조회를 할 수 없다면, 직접 유저 DB를 담당하고 있는 백엔드 개발자에게 마케팅 수신 동의 조건으로 유저들의 이름, 전화번호 등을 추출해 달라는 요청을 해야 한다. 이런 식으로 백오피스가 갖춰져 있지 않다면, 운영 담당자 혹은 PM만으로는 운영 업무를 할 수 없고, 항상 개발자의 도움을 받아야 한다. 이렇게 개발자의 도움을 받는 운영 업무가 많을수록 팀 전체의 프로덕트 개발 속도는 느려질 수밖에 없다. 개발자가 프로덕트를 만드는 데 시간을 쏟는 대신, 운영 업무를 처리하는 데 시간을 쓰기 때문이다.

6.

특히 백오피스에서 중요한 파트 중 하나는 상품의 등록과 전시다. 거의 모든 B2C 프로덕트에서는 유형이든 무형이든 특정 상품을 판매한다. 특정 상품을 판매하기 위해서는 특정 상품을 등록해야 한다. 백오피스가 있다면 백오피스에서 등록을 해줄 수 있지만, 만약 백오피스가 없다면 상품 백엔드에 관련된 개발자에게 직접 상품 등록을 요청해야 한다. 그리고 이를 담당하는 개발자가 상품의 썸네일 이미지부터 시작해 상품 이름, 브랜드, 가격, 할인율, 상품 구매 가능 시간 등의 설정을 세팅해줘야 한다. 그리고 상품의 전시에 있어서도 백오피스가 갖춰져 있지 않다면, 수동으로 상품의 노출 순서를 변경해줘야 한다.

7.

이처럼 백오피스가 없다면, 개발자의 도움 없이 할 수 있는 운영 업무가 거의 없기 때문에 운영 업무의 난이도가 급격히 올라가는 동시의 프로덕트 개발 속도 역시 느려진다. 개발자가 시스템이나 프로덕트를 만드는 대신에 운영 대응에 시간을 쏟기 때문이다. 그래서 처음 프로덕트를 만들 때, 백엔드를 올바르고 정확하게 세팅했다면 그다음에는 백오피스 프로덕트를 유저들이 사용하는 프로덕트보다 먼저 만들어야 한다. 혹은 동시에 만들거나.

8.

프로덕트가 아무리 완벽하게 나와도 운영 대응이 없을 수는 없다. 회원 탈퇴 버튼을 찾지 못하는 회원의 CS를 받아서 회원 탈퇴를 도와줘야 할 수도 있고, 새로운 협력사와 새로운 상품을 만들어 판매를 해야 하는 일은 계속 생기고, 마케팅 수신 동의 유저 대상으로만 프로모션 문자를 보내야 하는 업무도 있고, 악성 유저들을 모니터링해서 계정을 정지시켜야 할 수도 있고, 이렇듯 유저 사이드의 프로덕트만 만들어서는 할 수 없는 업무들이 상당히 많기 때문이다. 그리고 백오피스 없이 유저 사이드의 프로덕트만 만들면 실제로 그 프로덕트를 운영하는 사람들은 무언가를 확인하거나 조치하기 위해서 개발자의 도움만 기다릴 수밖에 없는 상황이 되고, 이는 빠른 유저 운영 대응을 불가능하게 만든다.

9.

언뜻 보면 백오피스를 만들면서 동시에 유저 사이드의 프로덕트를 만드는 게 시간이 더 걸리고, 더 돌아가는 길이라고 생각할 수 있다. 그렇지만, 백오피스를 만들지 않으면 거의 모든 운영 업무들이 개발자들의 손을 거쳐야 하기 때문에 이후의 프로덕트 개발 및 개선에 있어서 더 시간이 오래 걸릴 수밖에 없다. 그래서 백오피스를 만드는 일은 선택적인 일이 아니라 필수적인 일이다.

10.

최근 노코드 툴로 유저 사이드의 프로덕트를 빠르게 만들어서 비즈니스 모델 혹은 아이디어를 검증하는 경우가 많다. 이 때도 노코드 툴이 사실 유저 사이드의 프로덕트만 만드는 것은 아니다. 노코드 툴 자체가 백오피스 기능을 해 주는 것이다. 하나의 노코드 툴이 완벽한 백오피스의 기능을 구현하는 것은 아닐지라도, 상품의 등록과 전시, 회원 조회 등 백오피스의 핵심 기능을 제공하기 때문에, 노코드 툴로 프로덕트를 만들어도 안정적으로 프로덕트를 운영할 수 있다.

11.

유저 사이드의 프로덕트를 만든다면, 백오피스 프로덕트는 항상 떼 놓고 생각할 수 없다. 유저 사이드의 프로덕트를 보며 개인적으로 다음과 같은 질문을 하는 게 백오피스 프로덕트를 떠올리는 데 도움이 많이 됐었다. "유저에게 이 상품을 보여주고 싶은데, 어디서 뭘 건드려야 상품을 보여줄 수 있지?" "유저에게 이 상품의 가격과 결제 수단을 변경해서 보여주고 싶은데, 어디서 뭘 조작해야 하지?" "특정 상품을 구매한 유저들을 한눈에 보고 싶은데, 어디서 볼 수 있지?". 잊지 말자 백오피스 프로덕트는 유저 사이드의 프로덕트를 구현하기 위한 필수 요소다. 선택적인 요소가 아니다.