잘 굴러가는 백오피스 만들기

인터널 프로덕트라는 개념은 이제 프로덕트를 만드는 사람들에게 꽤 익숙하다. 회사 바깥, 다시 말해 프로덕트를 실제로 사용하고 수익창출의 원동력이 되는 사용자들이 아닌 사내의 사용자들을 대상으로 하는 인터널 프로덕트는 회사에서 수익을 내는 직접적인 창구는 아니지만, 회사에서 수익을 잘 내고 쉽게 내기 위한 핵심 도구다. 그럼에도 인터널 프로덕트를 처음부터 꼼꼼하게 만들어나가는 조직은 거의 없다. 이유는 간단하다. 일단 돈을 벌고 봐야 하기 때문이다. 대부분의 스타트업-IT 기업에서는 수익화에 대한 가설을 먼저 증명해야 그 과정을 고도화할 기회가 주어진다.

그러다 보니, 인터널 프로덕트는 어느 조직에 가든 매 순간 부족했던 리소스와의 타협과 포기로 점철돼있기 마련이다. 바로 그런 프로덕트를 개선할 기회가 주어졌다면, 자. 양 소매를 걷어붙이고 본격적으로 뛰어들어야만 한다. 인터널 프로덕트는 또 다른 기회의 영역이니까. 이 글은 핀치, 데이블, 그리고 웨이브에서 백오피스 - CMS, CRM, 기타 운영 전반에 필요한 툴 - 을 설계하고 배포한 경험을 압축해 회고하는 글이다. 이 글을 통해 인터널 프로덕트, 백오피스, CMS, CRM, 기타 조직의 업무효율을 위한 뒷단의 모든 제품을 만드는 사람들이 조금이라도 덜 외로웠으면 하는 바람이다.

당연한 얘기지만 쉽지 않은 얘기: 고객의 니즈 파악하기

대부분의 제품은 필연적으로 필요한 백오피스가 이미 구성돼 있고, 프로덕트 매니저가 백오피스에 투입된다면 그것은 ‘뭔가 얼기설기 엮어놓은’ 백오피스를 개선해야 할 필요성을 조직 내에서 공감했기 때문이다. 백오피스라고 해서 거창한 자체 개발 프로덕트일 필요는 없다. 프로덕트의 운영과 바로 연동되어 있는 스프레드시트, 자동화 엑셀 등도 모두 넓은 의미의 백오피스에 속한다. 때로는 이러한 형태를 그대로 두거나 과정만 자동화/고도화시키는 게 더 효율적인 선택일 수 있고. 그러므로 백오피스 프로젝트를 맡았다면, 일단 이 프로젝트를 정말 진행하는 게 맞는지부터 확인해야 한다. 실제로 해당 업무를 진행하는 사내 사용자가 거대한 고통을 겪고 있는가? 프로덕트를 개선했을 때의 이익이 새로운 프로덕트에 적응할 불편함보다 큰가? 이 부분부터 면밀히 따져야 실무와 동떨어져 기껏 만들었는데 모두가 투덜거리는 더 큰 문제덩어리를 만들지 않을 수 있다.

정말로 새로운 백오피스의 기능을 만드는 게 맞다고 판명이 났다면, 그 다음으로 중요한 건 사내 사용자의 니즈 파악이다. 지금 고객은 어떤 점에서 불편함을 겪고 있는가? 객관적으로 불편하고 관리도 어렵지만 고객이 스스로 익숙해져 있는 기능이 있는가? 이 개선으로 인해 고객에게 제공할 가치는 무엇인가? 마치 조직 바깥의 험난한 세상에게 프로덕트를 제공할 때처럼, 인터널 프로덕트를 설계할 때에도 사용자 관점에서의 제품 설계가 핵심이 되어야 한다. 엄청나게 당연한 소리지만 생각보다 쉽지 않다. 왜냐면 백오피스를 쓰는 대부분의 실무 인력은 엄청나게 바쁘니까. 그들은 크고 작은 불만사항은 있지만, 일단 그 불만을 삼키고 당장 오늘 해야 하는 일을 현재의 시스템으로 해내고 있다. 그래서 간단한 요청 양식 등을 채워서 요청만 보내고, 이에 해당하는 기능을 프로덕트 팀이 구현하는 식으로 일이 굴러가기 쉽다.

하지만 프로덕트 매니저는 약간의 뻔뻔함을 가지고 프로덕트의 실사용자에게 접근해 그들의 패인 포인트를 수집할 기회를 반드시 얻어야 한다. 그렇게 실사용자의 목소리를 들어야만, 그들이 요청을 준 기능 개선의 의도를 파악하고 단순한 기능 추가나 수정이 아니라 프로덕트 관점에서 더 나은 개선을 이루고 실사용자에게도 만족스러운 결과를 가져다 줄 수 있다.

사례: 액셀을 통한 콘텐츠 편성 기능 추가 요청

매번 사용자가 접속할 때마다 새로운 콘텐츠, 혹은 혹할 만한 콘텐츠로 시선을 끌어야 하는 OTT 서비스들은 자동 추천화 뿐만 아니라 사람만이 골라낼 수 있는 고감도 큐레이션을 제공한다. 이 큐레이션 목록을 생성하고 등록할 때, 액셀을 통해 업로드하게 해달라는 요청이 있었다.

실제로 만나서 얘기를 들어보니 큐레이션 목록을 만들 때 현재의 백오피스에서 큐레이션시 제공하고 있는 메타데이터 검색 기능이 제대로 작동하지 않아, 메타 정보를 별도의 창에서 검색해 복사-붙여넣기를 하고 있었다. 그래서 메타 정보를 백오피스에 일일이 타이핑하는 것보다 액셀에 복붙한 후 이를 형식에 맞춰 업로드하는 게 빠르고 편하다는 실무자들의 니즈가 있었다.

하지만 액셀을 통한 큐레이션 목록 등록 기능을 추가한다고 해도, 근본적인 문제점은 사라지지 않는다. 그것은 큐레이션 목록을 만들 때의 메타 검색이 불편하다는 점이다. 액셀은 임시방편이다. 결국 사용자가 원하는 것은 작업시간을 단축하고 빠르게 큐레이션 목록을 생성하는 것이고, 사용자는 그 해답으로 액셀을 제시했던 것이다.

결과적으로, 액셀을 통한 콘텐츠 편성 기능은 제외했다. 대신 큐레이션 목록을 만드는 새로운 백오피스에서는 메타 검색 기능을 대폭 개선해 실무자들이 실제로 검색하는 단위와 자주 검색하는 검색어 위주로 결과가 빠르게 매칭될 수 있게 하는 일종의 사내 SEO를 거친 버전의 검색 기능을 추가했다.

리소스 확보하기

인터널 프로덕트에 쓰이는 개발 및 디자인 리소스는 언제나 풍부하지 않고, 사실 풍부할 이유도 없다. (물론 풍부하면 좋겠다. 그건 그냥 꿈 같은 거지.) 하지만 인터널 프로덕트의 개선을 통한 가치창출을 리더십에 설득하고 이를 위한 최소한의 리소스를 할당받아 실질적인 개선을 이루는 것 역시 프로덕트 매니저의 책임이다. 인터널 프로덕트 개선은 누군가가 주시하지 않으면 아주 손쉽게 개발과제의 후순위로 밀려난다. 이를 언제나 조직 내에 일깨우자. 항상 인터널 프로덕트를 메인으로 보고 있는 개발자 1~2명, 디자이너 1명만 있어도 작고 빠른 개선은 손쉽게 이룰 수 있다.

우선순위 조정하기

인터널 프로덕트의 특성상, 실사용자의 니즈가 그렇게 크지 않거나 오히려 실사용자의 편의를 해치는데도 개선을 해야 하는 상황이 있다. 기술부채가 쌓여 프로덕트를 관리하는 기능의 유지가 어려울 때나, DB 관리 및 보안 등의 이슈가 있을 때다. 인터널 프로덕트를 주로 보는 개발자의 관점에서는 이러한 이슈가 가장 시급하고 큼직할 수밖에 없다. 하지만 인터널 프로덕트에 얽힌 실사용자를 대변하고 그들의 관점에서 프로덕트의 개선을 이끌어 나가야 하는 건 프로덕트 매니저라는 걸 잊지 말자. 만약 어젠다의 우선순위를 조정할 때 개발 관점에서 높은 가치를 지닌 어젠다에 실사용자의 불편함을 해결할 수 있는 어젠다가 밀려난다면, 최대한 이를 타협하고 양쪽을 충족시키는 게 최선이겠지만 그건 사실 상당히 어렵다. 대신 실사용자의 불편함도 빠른 시일 내에 해결할 수 있도록 사용자로부터 비롯된 개선 과제를 작은 사이즈로 잘게 쪼개 큼직한 기술개발과제 사이사이에 잘 끼워넣을 수는 있다. 어떤 방법을 써서라도 사용자의 불편함을 해소하는 데에 집중하고, 이 관점을 함께 일하는 사람들에게 설득할 수 있어야 한다. 실사용자 대변을 포기하는 순간, 백오피스는 사용자에게 외면받는 프로덕트가 될 수밖에 없으니까.

지속 개선을 (어떻게든) 해내기

KPI를 측정하고 달성 여부나 추이에 따라 지속적으로 제품을 개선하는 이터레이션을 돌릴 수 있는 대부분의 프로덕트에 비해, 인터널 프로덕트는 KPI라는 것을 측정하기조차 쉽지 않다. 대부분 비용과 시간의 효율화를 목적으로 하기 때문이다. 실무자의 업무 시간을 측정하고 이것이 얼마나 줄었는지 확인할 수는 있지만, 목표치보다 효율화가 덜 되었다고 해서 해당 기능을 추가로 개선할 수 있는 시간은 거의 없다. 하나의 기능을 릴리즈하고 나면 백오피스의 다른 기능을 릴리즈하고 보살펴야 할 가능성이 훨씬 높기 때문이다. 그럼에도 인터널 프로덕트에서 이터레이션 개념은 매우 중요하며, 할당받은 리소스를 반드시 적절하게 나누어 유지보수에 인력을 투입해야 한다. 모든 프로덕트가 그렇듯 한 번의 개선으로 문제를 완벽하게 해결할 수 없으므로 큰 아이디어에 합의한 초기 개선 버전을 배포한 후에도 사내 사용자의 피드백을 수집해 기능을 밀착 개선해야만 한다. 나의 경우엔 해당 기능을 사용하는 누구나 스프레드시트로(노션 DB를 쌓아도 좋다) 불편사항, 제안, 버그를 남겨놓게 했고 이 시트를 개발자와 함께 일주일에 한 번씩 점검한다. 이후 스프레드시트에 진행 여부 혹은 기타 피드백을 남겨둔다.

일개미를 행복하게

모든 프로덕트의 핵심은 사용자를 만족시키는 것이다. 인터널 프로덕트도 다를 건 없다. 하지만 단지 사내 제품이라는 이유만으로 우리는 프로덕트를 만들 때 들이는 많은 공과 품을 쉽게 포기하거나 타협하려는 유혹에 빠지기 쉽다. 대충 해도 일단 만들어지긴 할텐데. 대충 해도 일단 배포는 되는데. 대충 넘겨도 크게 문제되는 건 없을 텐데. 주어진 리소스는 너무나 적고 개선과제는 너무나 많으니 더더욱 그렇다. 하지만 그 과정에서 “잠깐만요!!!”를 외치고 사용자 관점의 제품 관리를 꿋꿋하게 고수하는 게 인터널 프로덕트 매니저의 미덕이자 업일 것이다.