데이터가 개발팀에 주는 영향

현재 메인으로 개발 중인 서비스는 비디어스와 필름업입니다.
그중에서도 당장 많은 개발을 하고, 논의를 하는 서비스는 비디어스입니다.

이전 라이브러리에서 몇 번 다룬 적 있지만, 서비스 대부분과 마찬가지로, GA를 이용해서 데이터를 수집하고 있습니다.
그런데 벌써 이 데이터를 수집하고, 내부에서 한 달 단위로 대시보드를 공유하고 논의한 지 1년이 되었습니다.
1년 넘게 A가 매달 데이터를 정리하고, 광고나 마케팅, 스프린트 등이 진행될 때 데이터에 어떤 영향이 있는지 공유해왔습니다.

1년이 되니 가장 크게 달라진 점은 데이터의 기준이 생겼다는 점입니다.
초기 서비스의 경우 데이터의 기준을 잡기 어렵다고 생각합니다. 다른 서비스의 기준을 가져와 사용하려고 해도, 너무 천차만별이기 때문에 활용하기가 어렵습니다.

예를 들어 a서비스가 출시 한 달 만에 가입자 수 100명이 되었다고 할 때, 어떤 노력의 결과로 100명이 되었는지 정확히 알 수가 없습니다.
그런 부분을 차치하고, 우리 서비스도 한 달 내 가입자수 100명을 목표로 한다고 하면 실제로 잘되지 않는 경우가 많고, 어떤 노력을 해야 하는지 갈피도 잡기 어렵습니다.
단순히 광고를 돌려서 유입을 만들고, 목표 가입자 수에 도달할 수는 있겠지만, 비용 문제도 있을뿐더러 정답이 아니라고 생각했습니다.

그래서 우리만의 기준을 갖추기 위해 광고 금액도 우리에 맞도록 조절하고, 광고 외 여러 커뮤니티 홍보 등 여러 시도를 하고, 데이터를 쌓아왔습니다.
그렇게, LAH만의 기준이 갖춰졌습니다.

지난주, 기준 데이터가 갖춰지고 데이터를 보면서 자유롭게 생각을 나누고 논의를 했는데, 너무 즐거운 시간이었습니다.
그중, 이 과정이 개발팀에 끼치는 영향이 있었는데 공유해 볼까 합니다.

스프린트 기간은, 많은 개발 조직에서 꽤 고민이 되는 부분입니다. 그리고 LAH처럼 매우 작은 개발 조직인 경우 더더욱 많은 고민이 됩니다.
일반적으로 스프린트 기간이라고 하면 2주 내외로 진행하는 조직이 많습니다. 많은 곳에서 이렇게 진행하니 아마 여러 시행착오 끝에 적절한 기간을 찾은 것이라는 생각이 들지만,
LAH와 같이 작은 개발 조직의 경우, 큰 기능을 개발할 때면 2주로는 턱없이 부족한 경우가 생깁니다. 현재 개발 중인 BM 관련 기능이 대표적이라고 할 수 있겠네요.

그래서 과거에 몇 가지 시도를 했었습니다. 강제로 2주에 맞추기 위해 기능을 BE, FE로 나눠서 다른 스프린트로 진행해 본 적도 있고, 어떤 기능의 CRUD 중 CR 과 UD를 나눠서 진행해 본 적도 있습니다.
하지만 매번 결과가 좋지 않았습니다. 그래서 기능 개발에 필요한 세부 일감을 정의하고 스프린트 기간을 역산해서 길게 구성도 해봤습니다.

이번에 개발팀과 함께 데이터를 보면서 논의하니, 단순히 “이 기능 만들면 좋다”와 같이 추상적인 얘기를 나누는 것이 아니라, “사용자들이 ~이렇게 사용하고 있는 것으로 보이는데, ~이 부분이 이탈 가능성이 보이니 ~이렇게 개선해 보면 좋을 것 같다”와 같이 지표를 기준으로 얘기하는 모습을 볼 수 있었습니다. 또는 “~이렇게 사용할 것으로 생각했는데, ~이렇게 사용하고 있는 걸 보니, ~이 부분의 개선은 우선순위가 떨어지겠네요”와 같은 얘기도 나눴습니다.

대부분의 논의가 데이터 위에서 이뤄지게 되었습니다. 이 전제가 의외로 스프린트 기간에 큰 영향을 미치게 되었습니다. 왜냐하면 스프린트 기간이 길면 이러한 개선 기능이 많이 들어가게 되는데 지표의 개선과 연결해 보기가 어렵기 때문이라고 생각합니다. 분명 전부 아는 내용이었지만, 실제로 겪는 경험에서 오는 힘이 있는 것 같습니다.

서비스를 운영하는 과정은, 산 정상에서 물줄기를 우리가 원하는 호수로 이끄는 과정 같은데, 1년 동안 물을 흘려보니 이제야 전체 물길을 바라볼 수 있게 된 것 같습니다. 그리고 조금씩 물길을 내주는데, 이제 그 내준 물길이 호수로 어떻게 가는지 볼 수 있겠다는 생각이 듭니다.

“데이터가 주는 힘”이라고 하면 여러 부분이 있겠지만, 이번에 경험한 것은, 논의 과정에서 다수의 생각을 끌어내는 힘 같습니다. 그리고 이 과정에서만큼은 개인의 직군이 개입하지 않는 점도 좋았습니다. 가끔 개발하다 보면, 실제 서비스에서의 효용성과 개발 난이도를 저울질할 때가 있는데, 그런 생각이 자연스럽게 차단되는 것 같습니다. 또는 기획자 입장에서 “이걸 개발할 수 있는가” 라는 제약 없이 의논할 수 있는 것 같습니다.

올해는 이 과정을 통해, 모든 지표가 J를 그리길 바라봅니다.

---