서비스 개선 프로세스, 진단-가설-검증

 

서비스를 운영하다 보면 개선 요청이 사방에서 들어와요.
경영진의 의견, 고객센터 문의, 경쟁 서비스 소식, 팀원의 아이디어까지 전부 일리가 있어 보입니다.
그런데 이걸 들어오는 대로 처리하다 보면 한 달 동안 많이 바꿨는데 무엇이 나아졌는지는 모르는 상황이 생겨요.
저도 그런 경험이 있어서, 개선 일을 진단, 가설, 검증 세 단계로 나눠서 하는 습관을 들이기 시작했어요.

 

개선은 보통 해결책에서 시작하려는 유혹이 커요.
"이 버튼 위치를 바꾸자", "팝업을 넣자" 같은 아이디어가 먼저 나오는 거죠.
하지만 무엇이 문제인지 확인하기 전에 해결책부터 고르면, 문제가 아닌 곳을 고치거나 원인을 놓치게 돼요.

세 단계는 질문으로 바꿔 말할 수 있어요.
진단은 "정말 문제가 있고, 어디에 있는가"를 묻고, 가설은 "왜 그렇고 무엇을 하면 나아질 것인가"를 묻고, 검증은 "해 봤더니 정말 그랬는가"를 묻습니다.
이 순서를 지키면 회의에서도 지금 어느 질문을 다루는지 서로 알 수 있어서 이야기가 덜 헤매요.

 

진단의 목적은 문제를 선명하게 만드는 거예요.
숫자로는 퍼널이나 이탈 지점, 지표의 추이를 봅니다.
말로는 사용자 문의와 인터뷰, 사용 관찰에서 반복되는 불편을 모아요.
둘이 같은 곳을 가리키면 문제일 가능성이 높고, 둘이 어긋나면 더 파 봐야 할 지점이에요.
진단에서 흔한 실수는 목소리가 큰 의견을 문제로 착각하는 거예요.
고객센터에 자주 들어오는 문의가 전체 사용자의 불편을 대표하는지는 따로 확인해야 합니다.
불만을 직접 말하는 사용자는 일부이고, 말없이 떠나는 사람이 훨씬 많을 수 있으니까요.

여기서 한 가지 지키는 규칙이 있어요.
문제를 "사용자가 가입을 많이 포기한다"처럼 현상으로 적고, "가입 폼이 길어서"처럼 원인은 아직 적지 않는 거예요.
원인을 미리 적어 버리면 이후의 생각이 그쪽으로 굳어 버리거든요.
또 문제의 크기도 같이 적어요.
몇 퍼센트가 영향을 받는지, 그 사용자가 서비스에 얼마나 중요한 사람들인지를 적어 두면 우선순위를 정하기 쉬워집니다.

 

가설은 원인에 대한 추측과 해결책, 기대하는 결과를 한 문장으로 묶은 거예요.
저는 "A 때문에 B 현상이 생기는 것 같다. 그래서 C를 하면 D 지표가 오를 것이다"라는 틀을 써요.
문장이 이렇게 구체적이어야 나중에 맞았는지 틀렸는지 판단할 수 있어요.

가정으로 한 가지 써 볼게요.
"가입 폼의 입력 칸이 많아서 중간에 포기하는 것 같다. 그래서 필수 항목을 줄이고 나머지는 가입 후에 받으면 가입 완료 비율이 오를 것이다."
이 문장에는 원인, 해결책, 지표가 다 들어 있어요.
가설은 한 번에 여러 개 나오는 게 정상이니, 확신도와 영향도, 비용으로 간단히 순서를 매겨서 하나씩 해 봅니다.
틀릴 수 있는 문장이라는 점이 가설의 장점이에요.
틀렸다는 사실도 배움이 되니까요.

 

검증은 가설이 맞는지 가장 작은 비용으로 확인하는 단계예요.
A/B 테스트가 가장 깔끔하지만, 트래픽이 적으면 어렵습니다.
그럴 때는 일부 사용자에게만 먼저 적용하거나, 적용 전후를 비교하거나, 사용자 몇 명을 직접 관찰하는 방법도 있어요.
방법이 무엇이든 시작하기 전에 성공 기준과 확인 기간을 정해 두는 게 중요합니다.

앞의 가입 폼 가설을 검증한다고 가정해 볼게요.
신규 방문자의 절반에게는 기존 폼을, 나머지 절반에게는 필수 항목을 줄인 폼을 보여 주고 두 주 동안 가입 완료 비율을 비교합니다.
성공 기준은 "완료 비율이 눈에 띄게 오르고, 가입 후 첫 주 이용 비율은 떨어지지 않는 것"으로 미리 적어 둬요.
항목을 줄여서 가입은 늘었는데 정작 이용하지 않는 사용자만 늘었다면 성공이라고 부르기 어렵기 때문이에요.

결과가 나오면 세 갈래로 판단해요.
가설이 맞았으니 확대할지, 틀렸으니 접을지, 애매하니 조건을 바꿔 다시 해 볼지예요.
특히 틀렸을 때 "그럼 진단이 틀렸나, 가설이 틀렸나"를 구분해서 보면 좋아요.
진단이 틀렸다면 문제 자체를 다시 봐야 하고, 가설이 틀렸다면 원인에 대한 다른 추측으로 돌아가면 됩니다.

 

이 모든 과정을 기록하지 않으면 석 달 뒤에 같은 아이디어를 다시 내놓는 일이 생겨요.
저는 개선 한 건당 한 장짜리 카드를 만들어요.
항목은 문제 현상, 근거(숫자와 말), 가설, 검증 방법과 기간, 성공 기준, 결과, 배운 점, 다음 행동 정도예요.
길게 쓰지 않고 항목마다 한두 줄이면 충분하고, 팀이 함께 보는 공유 문서에 쌓아 둡니다.

신경 쓰는 건 실패한 카드도 지우지 않는 거예요.
안 된 이유가 기록으로 남아야 다음 사람이 같은 길을 되풀이하지 않거든요.
카드를 모아 두면 분기 끝에 돌아볼 때 어떤 종류의 가설이 잘 맞았는지도 보여요.
입력 부담을 줄이는 가설은 자주 맞는데 문구 톤을 바꾸는 가설은 잘 안 맞는다면, 다음 우선순위를 정하는 데 참고가 됩니다.

 

진단, 가설, 검증은 단순해 보이지만 지키기가 은근히 어려워요.
급할수록 가설 없이 바로 해결책으로 뛰어들게 되니까요.
그래도 개선 요청을 받았을 때 "이건 진단이 끝났나요?"라고 한 번 되묻는 것만으로도 일이 많이 정돈된다고 느껴요.

남은 질문은 정성적인 개선, 예를 들어 브랜드 느낌이나 문구 톤처럼 숫자로 검증하기 어려운 일을 이 틀에 어떻게 넣을지예요.
이런 경우에는 성공 기준을 사용자 평가나 관찰 소견으로 잡아야 할 것 같은데, 좋은 방법을 더 찾아보고 있어요.