주니어 PM의 제작 속도 8배 개선한 백오피스 제작기
하루에 1개만 만들던 것, 이젠 8개도 거뜬히 만들어요 - 백오피스
01. 반복 업무, 어떻게 해결할까?
격주 1회 정도씩 요청되는 업무 A가 있었습니다. 업무 분량이나 반복 주기를 고려했을 때, 자동화 측면에서 우선순위가 대단히 높지는 않았습니다. 그래서 필요시에는 미리 일정을 확보해두고 개발자가 1일을 투자해 A를 완성해내곤 했습니다.
그런데 사업 전략이 수정됨에 따라 A의 중요도와 빈도가 과거에 비해 높아졌습니다. (측정이 쉬운) 빈도 기준으로 표현하자면 업무의 무게는 거진 3배 이상으로 늘어났는데요, 그렇다고 다른 업무들의 무게가 그만큼 줄어든 것은 아니었기 때문에 전체 리소스 효율화 관점에서- 반복 업무 A에 대응할 새로운 방법이 필요했습니다. 대안을 떠올리기 위해 했던 생각은 다음과 같습니다.
(1) 일단, 반복의 필요성이 타당한가?
지금껏 습관적으로 반복해왔던 업무라면 이 반복을 효율화할 것이 아니라 반복을 제거하는 것이 필요하기 때문에 떠올렸던 생각인데- 업무 A는 여러 유관 부서의 협력을 취합함과 동시에 고객에게 공개되는 UI에 직결되어 있기 때문에 단번에 수행하는 것이 어렵다고 판단했습니다. 일정한 간격을 두고 단건별로 반복 대응이 필요한 업무라는 점을 인지했습니다.
(2) 반복되는 내용과 범위를 파악할 수 있는가?
비유해서 표현하자면, 알맹이를 담는 그릇의 형태는 항상 동일한테 어떤 알맹이를 담느냐는 업무 필요 시점마다 달랐습니다. 반복 가능한 요소와 수동 입력이 필요한 요소를 나눌 수 있었습니다.
이번엔 어떤 알맹이가 좋으려나~그리고 이 반복 과정을 더 비효율적으로 만드는 요소에 '불필요한 업무 전달 과정'이 있다는 것도 알게 되었습니다. 팀 기능/역할을 고려해보면 2개의 팀만 협력해도 될 일인데 5개의 팀이 함께 하고 있었습니다. 업무 A에 대해 잘 아는 팀, 필요성을 제기하는 팀, 실제 업무에 접근할 수 있는 팀 등이 분화되어 있기 때문이었습니다. 그래서 업무 A의 접근성을 높일 수 있는 방법 도 동시에 고민했습니다.
그런 고민들을 거쳐- 백오피스 기능을 제작하기로 결정했습니다. 이유를 요약하자면 아래와 같습니다.
(1) 비개발 조직의 업무 접근성을 높이면서
(2) 반복 불가 요소를 사람이 입력하면 > 그것들을 반복된 형태로 자동 출력할 수 있도록
사실은 침이 꼴깍 넘어가는 결정이었습니다. 어제 기획/디자인하고 오늘 개발해 QA 및 배포를 마치기도 하는 우리 팀에서, 3주 이상 소요될 것으로 예상되는 프로젝트를 촉발하는 것이 조금 떨렸기 때문이었는데요. 기능의 당위성&가능성 을 고려했을 때 지금이 적시라는 (좀처럼 찾아오지 않는) 확신이 들었습니다.
02. 한 달 동안 배운 것
그런 고민을 거쳐 시작한 백오피스는 4.5주만에 버전1 배포에 성공했고, 그 뒤로도 사용 현황을 추적하며 자잘한 업데이트를 이어 왔습니다. 배운 점을 기록하며 프로젝트 과정을 돌아보려 합니다.
(1) 자유도와 Quality Control 간의 균형이 필요하다
반복 업무를 효율화할 시스템을 만든다는 건 설레는 목표였지만, 시스템의 복잡도나 사용자(동료들) 니즈의 다양성을 떠올리니 조금 걱정이 되기도 했습니다. 제가 알고 있는 것을 수렴시켜야겠다는 생각이 들었고, 업무 A에 시간을 할애하는 5개 팀의 대표적인 구성원들을 모셔 업무 A를 수행하며 발생하는 반복 요소를 취합했습니다. 다양한 경험담을 들으며 다각도로 업무 A의 문제를 파악함과 동시에- 요구사항 간의 우선순위 배정이 반드시 필요하겠다는 깨달음도 함께 얻었습니다.
모두가 백오피스를 반겼지만, 필요한 기능 범위에 대한 생각은 달랐습니다. 특히, 워낙 빠듯하게 개발이 필요한 경우가 잦았던 업무인지라- 모든 제약 사항을 없애고 다 사용자가 직접 입력할 수 있는 방식을 선호하는 입장도 있었습니다. '나중에 요구사항이 이것도, 저것도 생길 것 같으니 일단 기능을 다 열어둘까'에 대한 유혹도 사실 있었습니다.
하지만 자유도를 높인다는 것은, 사용자의 재량과 역량에 의존하는 정도가 높아진다는 것과 같습니다. 시스템이 막아주지 않으면 사람이 적당히 판단해서 데이터를 입력해야 하기 때문입니다. 각 구성원의 업무 A에 대한 이해도와 역량과는 무관하게, 언제든 휴먼 에러는 발생할 수 있습니다. 게다가 업무 A의 고객 접점도를 고려하면 휴먼 에러 1건의 리스크를 무겁게 받아들일 필요가 있었습니다.
더불어 단순 에러 방지가 아니라 업무 A의 평균 Quality를 높이기 위해서도 시스템 제약사항이 필요했습니다. 그간 업무 A를 수동으로 수행하며 적재되었던 러닝을 곳곳에 반영시켰습니다. 예를 들어- 사실 무한으로 작성해도 '틀린 것은 아닌' 요소에 권장 글자 수와 제한 글자 수를 표기하고 플레이스 홀더 하단 문구를 통해 바로 글자 수에 대한 피드백을 받을 수 있도록 했습니다.
P.S. 그간 자유도가 너무 높아 오히려 어려웠는데 이제 어느 정도가 '적당한 수준'인지 알 수 있어 안심된다는 사용 후기를 받기도 했습니다.
(2) 넛지가 제약만큼 강할 때도 있다
사실 시간이 부족해 일부 복잡 요소는 제약 사항을 최소화하기도 했는데, 버전 1 배포 후 그 부분에서 휴먼 에러가 발생했습니다. 이 때 '백오피스 계정 권한을 생성할 것이냐', '복잡하더라도 일일이 제약 사항을 둘 것이냐' 등 여러 안이 제시되었습니다.
일정상 그 어떤 안도 채택하기가 어려웠습니다. 대신 에러의 리스크가 큰 지면에서는 변경사항 발생 후 저장 버튼 클릭시 경고 알럿을 띄웠습니다. 실서버에 바로 반영될 예정이니 반드시 [미리보기] 링크를 통해 확인한 후 저장버튼을 누르라는 내용이었습니다. 일종의 중문을 둔 것인데요. 백오피스 배포 이래로 3건 발생했던 휴먼 에러가 0건으로 감소했습니다.
사실 그간은 고객에게 노출되는 지면 위주의 프로젝트를 진행하며- 권장형 알럿을 거의 사용하지 않았습니다. 알럿은 명확한 피드백 목적으로만 사용하고, 권장하거나 넛징하는 것이 필요할 때는 가급적 바디 콘텐츠를 활용했습니다. 알럿은 지금 보는 화면의 흐름을 뚫고 노출되는 것이기 때문에 사용자를 깜짝 놀라게 할 수 있기 때문이었는데요.
백오피스에서는 알럿의 단점보다는 장점이 잘 발현될 수 있었습니다. UX의 흐름을 끊긴 하지만 그래서 내용에 대한 주목도를 더 높일 수 있었습니다. 그래서 알럿에 작성한 내용이 제약/규제 만큼의 힘을 발휘해 에러 건수를 감소시킬 수 있었던 것 같습니다.
(3) 프로젝트 구성원과 자주 대화하고 불편한 점은 내가 제일 먼저 빠르게 긁어드리자
업무 중 불편한 점은 없으신지 개발자 헬스 체크를 하러 찾아 뵈었는데 PRD 때문에 다소 난감하셨다는 것을 알게 되었습니다. 화면 갯수는 많은데 화면 간 연관도가 높아, 숲(전체 구조)과 나무(각 화면)를 동시에 봐야 하기 때문이었습니다.
그도 그럴 것이, 프로젝트와 관련된 PRD가 크게 세 종류로- 모니터 2대로 다 보기에는 어려웠습니다.
- 백오피스 정책 전반
- 데이터를 입력하는 화면과 정책
- 입력한 데이터를 출력하는 화면과 정책
모니터를 1대 더 꼽을까 싶던 차에, 개발자께서 "조금 날것의 방식이긴 한데.. 각 화면별 정책은 종이로 뽑아서 보면 어떨까요? 전체 정책은 모니터로 보고요! 종이 넘겨가면서 화면 하나씩 뽀개간다는 재미도 있을 것 같고 종이가 더 보기 편할 것 같아요."라고 제안해주셨습니다. 바로 화면별 UI와 정책이 담긴 문서를 PDF 파일로 제작하고 인쇄했습니다.
인쇄한 기획서를 화면 순서대로 배치하는 중한 화면의 개발이 끝날 때마다 한 장씩 함께 넘겨가며 프로젝트를 진척시켜나가는 통쾌함은 컸습니다. 의외로 이런 것들이 프로젝트 전체의 분위기를 견인하기도 했습니다. 함께 일하는 동료의 성향을 파악해 업무 방법에 변주를 주는 것도 PM의 근사한 센스가 될 수 있겠다는 생각이 드는 대목이었습니다.
(4) '제작'이 아니라 '전파 후 내재화'까지가 프로젝트의 끝이다
백오피스도 제품이라는 사실을 새삼 깨달았습니다. 고객향 제품은 제작 후에 유통하고, 설득하고 전환시키는 후속 퍼널까지 당연하게 챙기면서- 내부 제품인 백오피스는 '제작하면 끝'이라는 은근히 안일한 생각도 조금은 있었던 것 같습니다. 백오피스 제작 전후로 문서 가이드를 작성해 공유하고, 유관자 미팅으로 구두 전달을 완료하면 백오피스 사용률이 자연스레 높아질 것이라고 생각했던 것이지요.
백오피스 배포 후 1개월이 지난 시점. 업무 A와 관련된 태스크 중 10%만이 백오피스를 사용하고, 나머지는 모두 이전 방식대로 제작되고 있다는 현황을 파악했습니다. 유관자들을 찾아뵙고 백오피스 기능을 설명해드리니 "헉 이런 것도 되는 건지 몰랐어요. 다음엔 꼭 써야겠네요, 너무 편하다!"와 같은 놀람의 반응이 대다수였습니다. 사용 방법이 아니라 장점부터 전파해 "나도 쓰고 싶은 마음"을 들게 하는 게 먼저라는 생각이 들었습니다. 그래서..
(1) 주요 배포건의 성과를 축하하는 슬랙 채널에 백오피스의 기능을 자랑했습니다. 원래는 하루에 1개만 제작할 수 있었던 것을 실제로 13개까지 제작한 경험을 널리 전파했습니다.
(2) 특히 업무 A의 창발 시점을 주로 주도하는 구성원(PM)들께는 백오피스로 제작한 화면들을 직접 보여드리고 개발 일정을 확보하지 않고도 백오피스를 통해 바로바로 콘텐츠를 수정할 수 있다는 장점을 강조했습니다.
그렇게 관심부터 얻은 후, FAQ를 적재하고 (반복되는 FAQ는 기능으로 적용하며) 백오피스를 개선해나갔습니다. 가이드 문서도 3번에 걸쳐 수정했는데요. 모든 걸 자세하게 설명하기보다는 가장 큰 혼선이 있을 수 있는 지점만 꼽아 추가 설명을 기재하고, 나머지는 모두 백오피스 내 UX에 의존해 자연스럽게 사용할 수 있도록 했습니다.
그 결과 백오피스 사용률이 10% => 17% => 32%로 개선될 수 있었습니다. 신규 제작건에서는 모든 신규 제작건 뿐 아니라 기존 방식대로 제작된 것들을 백오피스로 수정 제작하는 케이스도 생겼습니다. 더불어 신규 제작건에서는 모두 백오피스를 사용하는 것으로 인지적인 합의도 이룰 수 있었습니다. (백오피스를 가장 자주 사용하는 팀의 업무 가이드 문서에 놀러갔다가 알게 된 것!)
03. 낯선 경험과 역량과 정확도
업무 비효율을 차근차근 해소해나갈 수 있다는 점이 가장 즐거웠지만, 처음 고민하고 처음 실패해서 처음 배우는 것들이 많아 더 남다른 의미를 가진 프로젝트였습니다. 자칫 비즈니스 임팩트가 낮아보일 수 있는 일이기 때문에 프로젝트 초반에 유관자를 설득하는 방법부터 달랐고- 여러 태스크를 하나의 시스템으로 통합하면서 다른 직무 동료의 일과 입장을 더 들여다보는 계기가 되기도 했습니다.
학부에서 머신러닝 개론 강의를 듣다가, 이론은 다 잊어버리고 교수님의 설명만 기억이 나는 부분이 있습니다. 동일한 모델로 반복 학습시키지 않고, 여러 개의 모델로 다양한 유형의 성공/실패를 학습시켜서 높은 정확도의 모델을 만드는 앙상블 기법에 대한 설명이었는데요. PM으로서의 제 역량을 머신러닝 모델의 정확도에 비유한다면- 프로젝트/프로덕트의 경계를 넓히며 다양한 경험을 하는 게 정확도 개선의 방법일 수도 있겠습니다.
