나는 개발자가 아니다
문제의 본질을 파악하는 방법
프로덕트 개발자들의 뇌는 요구사항을 들었을 때, 즉각적으로 그에 대한 해결책을 고민하도록 설계되어 있는 것 같다. 예를 들어, 유저에게 푸시를 보내고 싶다는 PM/PO의 말을 들으면, 아차하는 순간 전 국민에게 푸시를 보냈을 때도 문제없는 시스템을 만들 방법에 대해 고민을 하는 식이다.
얼핏 보면 빠르게 문제 해결하는 데에 도움이 될 것 같아 보이나, 실상은 다르다. 아래는 내가 겪은 실제 예시이다.
우리 팀은 앱에 대한 온보딩 경험을 개선하고자 실험을 진행중이었다. 유저가 가입을 마친 뒤에, 앱을 사용하는 튜토리얼을 보여주는 식이었다. 실험의 가장 큰 문제는 모수가 적다는 것이었는데, 하루에 가입하는 유저가 한정되어 있다보니, 일주일을 기다려도 충분한 모수가 모이지 않는다는 것이었다. 그 원인은 명확했다.
옆 팀에서는 특정 실험군(A)은 회원 가입을 하지 않고도 앱을 일부 사용할 수 있었고, 특정 서비스를 사용하고자 하면 가입을 유도하고 가입 후 해당 서비스로 바로 랜딩을 시켜주었다. 이 실험군이 신규유저의 40%를 납치하고 있었기 때문에, 우리 실험군은 적은 모수에 허덕이고 있었다. 유저가 신규 가입을 했을 때, 우리 팀이 만든 온보딩 프로세스를 보여주고 싶었기 때문에 A 실험군을 우리 팀의 모수에서 제외하고 있었기 때문이다.
하지만, 다행히도 방법은 있었다. A 실험군에서 반 이상은 가입 후에 아무 서비스로도 랜딩되지 않고 있었기에, 이 유저들만 우리 실험군에 포함시켜도 큰 도움이 되었다. 작은 문제가 남아있었는데, 우리의 AB테스트 시스템상 이 일부 모수만 실험군에 포함시키는 것이 간단하지 않았다. 아래는 옆 팀의 프론트 개발자 B씨와 나의 대화이다.
B : 일단 실험군에는 모두 포함시키고, 나중에 데이터를 볼 때 구분할 수 있도록 하는 거 어때요?
나 : 오, 좋은 방법이네요!
B : 신규 가입후에 호출하는 api가 있는데, 그 api에서 실험군에 포함시킬 유저만 DB에 저장하면 될 거 같아요.
나 : 기술적으로는 -이렇게 저렇게- 가능할 거 같네요. 그렇게 진행하시죠
사실 작업은 그리 간단하지 않았다. DB를 만드려면 DBA 분들의 승인을 받아야했는데 이 과정이 꽤 스트레스였기 때문이다. 또한 DB에 저장할 필드들 또한 고민이 되었다. 하지만, 실험이 얼마 남지 않았기에 묵묵히 작업을 했다.
문제를 파악한 것은 그로부터 4시간 여가 지난 후 였다. 혹시나하고 찾아보니, 특정 유저를 편입된 실험군에서 삭제 하는 기능이 존재했던 것이다. 이 방법을 알았다면 문제는 30분만에 해결되었을 것이었다.
내가 시간을 낭비한 이유는 뭘까? 내가 문제의 본질을 파악하려않았기 때문이다. 문제의 본질은 어떻게든 우리 팀이 원하는 유저만 실험군에 포함시키는 것이었다. 하지만 나는 “실험군에 포함시킬 유저만 DB에 저장” 하는 것을 문제로 설정해버렸다. 문제의 본질이 아닌 요구 사항 만을 믿은 대가로 나는 3시간이 넘는 시간을 낭비했고, 스트레스도 받았다. 아마 주름도 한 개 쯤 더 생겼을 것이다.
아마 이 글을 보고, 바보 같은 일이라고 생각하며 웃어넘길 수도 있다. 하지만 잠시만 집중력이 흐트려져도 이런 일은 흔히 발생할 수 있다. 개발자들은 유저/기획자의 요구 사항을 구현하는 것에 익숙해져 있기 때문이다.
이러한 문제를 해결하는 방법은 뭘까? 우습게도 내게는 나를 개발자로 생각하지 않는 것이 도움이 됐다. 나는 개발자가 아니라, 문제를 해결하는 사람이고, 문제를 해결하기 위한 무기 중에 프로그래밍 능력/지식이 있는 것이라고 말이다. 덕분에 지금은 요구 사항을 들었을 때, 정말 필요한 것인지, 다른 방법은 없는지 먼저 고민한다. 이 과정에서, 요구 사항 자체가 불필요한 것임이 들어나기도 한다! 앞서 나온 예시에서, 내가 이 방법을 적용했다면 3시간이 넘는 시간을 벌었을 것이고, 그 과정에서 의사소통 했던 모든 사람들의 시간을 아낄 수 있었을 것이다. 피부 미용은 덤이다.
