아무도 쓰지 않는 서비스를 만들며 배운 것

우리 회사에는 서로 다른 방식으로 일하는 두 팀이 있다.

개발팀은 티켓 기반의 스프린트 구조로 일한다. Linear에 해야 할 일을 등록하고 담당자를 정한 뒤, 상태를 변경하며 진행 상황을 관리한다.

도서를 만드는 출판팀은 WBS를 중심으로 일한다. 한 권의 책이 기획부터 출간까지 어떤 단계를 거치는지 정리하고, 엑셀 간트차트 위에서 전체 일정을 관리한다.

출판 일정은 계획대로만 흘러가지 않는다. 앞 단계의 작업이 밀리면 그 뒤에 연결된 일정도 함께 밀린다. 엑셀에서는 이때 편집자가 후속 일정을 일일이 수정해야 했다. 하나의 작업이 늦어질 때마다 여러 셀의 날짜를 다시 입력하고, 간트차트도 새로 맞춰야 했다.

이런 작업은 당연히 귀찮다. 관리가 번거로우니 최신화가 늦어지고, 최신화가 늦어지니 관리자는 간트차트만 보고 현재 상황을 파악하기 어려워진다. 전체 일정을 한눈에 보기 위해 만든 WBS가 정작 실제 현황을 제대로 보여주지 못하고 있었다.

그 모습을 보면서 굳이 이걸 엑셀로 관리해야 하나 싶었다.

엑셀보다 나은 도구를 만들면 쓸 것이라고 생각했다

웹 서비스로 만들면 상당 부분 해결할 수 있을 것 같았다.

앞 작업의 일정이 변경되면 후속 일정을 자동으로 계산하고, 작업별 상태를 표시하고, 프로젝트 전체의 진행 상황을 간트차트에서 확인할 수 있다. 반복되는 출판 공정은 WBS 템플릿으로 제공하고 필요한 알림도 보낼 수 있다. 팀과 프로젝트를 구분하거나 관리자에게 필요한 화면을 만드는 일도 가능했다.

나는 엑셀 시트를 그대로 웹에 옮기기보다 출판 업무에 맞는 WBS를 만들고 싶었다. 여러 프로젝트를 어떻게 비교할지, 작업 상태와 일정 변경을 어떻게 연결할지, 편집자와 관리자가 각각 어떤 정보를 봐야 할지 고민했다. 엑셀에서는 구현하기 어려웠던 기능도 하나씩 추가했다.

그렇게 사이드 프로젝트로 WBS 웹앱을 만들었다. 일정 관리가 편해졌고 기능도 많아졌다.

하지만 편집자들은 이 웹앱을 좀처럼 사용하지 않았다.

한동안은 기능에서 이유를 찾았다. 사용법이 어려운지, 화면이 복잡한지, 알림이나 대시보드가 더 필요한지 생각했다.

그러다 엑셀을 사용할 때도 WBS가 매번 최신 상태로 갱신되지는 않았다는 사실을 다시 보게 됐다. 내가 세운 가설은 단순했다. 갱신이 불편해서 미루는 것이니, 갱신을 편하게 만들면 자주 관리할 것이라고 생각했다.

웹앱은 날짜를 입력하고 일정을 조정하는 수고를 줄여주었다. 그런데 일정을 갱신하려면 편집자가 하던 일을 멈추고 별도의 웹앱을 열어야 했다.

입력 자체는 편해졌지만, 입력하러 가는 과정은 그대로였다.

문제는 기능이 아니라 워크플로우였다

편집자는 원고와 메일, 메신저를 오가며 일한다. 동료와 일정을 논의하고, 외부 필자의 답변을 확인하고, 변경된 내용을 공유한다. 일정이 바뀌는 순간도 대부분 그 과정에서 발생한다.

반면 WBS는 그 흐름 바깥에 있었다. 편집자가 일부러 찾아가서 갱신해야 하는 별도의 관리 도구였다(엑셀과 마찬가지로). 웹앱을 잘 만들었다고 해서 그 행동이 저절로 습관이 되는 것은 아니었다.

내가 줄인 것은 WBS를 수정하는 수고였다. 정작 편집자의 업무 안에 WBS를 갱신할 계기를 만드는 데에는 충분히 신경 쓰지 못했다.

이 차이를 이해하고 나니 개발팀이 Linear를 사용하는 방식이 다르게 보였다.

개발팀도 모든 일을 Linear 화면에서 시작하지 않는다. 많은 논의는 Slack에서 벌어진다. 대화를 나누다가 Linear를 호출해 티켓을 만들고, 스레드의 내용을 티켓에 반영하고, 담당자나 작업 상태를 변경한다.

Linear는 별도의 서비스지만 개발자가 매번 대화를 멈추고 Linear로 이동할 필요는 없다. 실제 업무가 일어나는 Slack 안에서 필요한 일을 처리할 수 있기 때문이다.

WBS에도 이런 접점이 필요했다. 편집자가 Slack에서 일정 변경을 논의하다가 @wbs를 호출하면, 같은 스레드에서 작업 상태를 바꾸거나 일정을 조정할 수 있게 하는 방식이다. 요청에 필요한 정보가 부족하면 에이전트가 같은 스레드에서 다시 물어볼 수도 있다.

이 생각을 바탕으로 기존 WBS 웹앱과 연결되는 에이전트를 기획하고 만들었다.

전체 프로젝트의 일정과 작업 간의 관계를 살펴보는 일은 웹앱이 맡는다. 여러 프로젝트를 비교하거나 간트차트를 확인하고, 템플릿을 관리할 때도 웹 화면이 적합하다. Slack 에이전트는 편집자가 평소 일하는 자리에서 WBS를 갱신할 수 있게 해준다. 일상적인 변경은 Slack에서 처리하고, 전체 현황을 봐야 할 때 웹앱으로 이어지는 구조다.

두 도구는 서로 경쟁하지 않는다. 웹앱은 프로젝트 정보를 관리하는 중심이고, Slack 에이전트는 그 중심으로 들어가는 자주 쓰는 입구다.

도구를 사용하는 순간만 봐서는 부족하다

무언가를 기획할 때 우리는 눈앞에 보이는 불편을 기능으로 해결하려 한다. 일정 변경이 번거로우면 자동 계산 기능을 만들고, 현황을 파악하기 어려우면 대시보드를 만든다. 갱신이 늦으면 알림을 추가한다.

필요한 기능들이다. 하지만 기능이 문제를 해결할 수 있다는 사실과 사람들이 그 기능을 사용한다는 것은 별개의 일이다.

그 기능을 사용하기 위해 무엇을 멈춰야 하는지, 어디로 이동해야 하는지, 같은 내용을 다시 입력해야 하는지도 함께 살펴봐야 한다. 도구 안에서 일어나는 일만 볼 게 아니라 사용자가 그 도구에 들어오기 전과 빠져나간 뒤의 과정까지 봐야 한다.

새로운 도구가 기존의 업무 흐름을 바꾸려면 사람들이 기꺼이 갈아탈 만큼 압도적인 효용을 제공해야 한다. 그 정도의 변화가 아니라면 지금 일하고 있는 흐름 안으로 들어가는 편이 현실적이다. 사용자가 하던 일을 멈추지 않아도 새로운 기능의 효용을 얻을 수 있어야 한다.

내가 처음 만든 WBS 웹앱은 기존 업무 방식을 바꾸기에는 충분히 강력하지 않았고, 편집자의 일상적인 업무 흐름과도 떨어져 있었다. 기능은 많았지만 그 기능이 필요한 순간과 제품이 놓인 장소가 달랐다.

사용자는 업무를 위해 도구를 사용한다. 도구를 사용하기 위해 매번 자신의 업무 흐름을 바꾸지는 않는다. 제품의 경계를 화면이나 저장소로 한정하면 사용자가 실제로 일하는 과정을 놓치게 된다.

결국 제품은 사용자의 업무 흐름 안에서 작동해야 한다.