가설

기능을 만들자는 제안은 대개 "이거 있으면 좋을 것 같은데요" 로 시작합니다. 듣는 사람도 대체로 동의합니다. 문제는 만들고 난 뒤입니다. 두 달을 들여 내놓고 2주가 지나면 누군가 "효과 있었나요" 라고 묻는데, 여기서 대화가 갈립니다.

한 사람은 "숫자가 좀 오른 것 같다" 고 하고, 다른 사람은 "그건 같은 주에 돌린 광고 때문" 이라고 합니다. 어느 쪽도 증명할 수 없습니다. 만들기 전에 무엇이 얼마나 오르면 성공인지를 아무도 적어 두지 않았기 때문입니다. 그래서 팀은 다음 분기에도 같은 방식으로 다음 기능을 고르고, 지난 두 달에서 배운 것 없이 시작합니다.

더 자주 벌어지는 일은 해석이 뒤늦게 만들어지는 쪽입니다. 지표가 오르면 이번 기능 덕이라 하고, 안 오르면 홍보가 부족했다거나 시기가 나빴다고 합니다. 두 설명 모두 결과를 보고 나서 만든 것이라 다음 판단에 쓸 수 없습니다. 가설은 이 순서를 뒤집습니다. 만들기 전에 무엇을 기대하는지와 무엇을 보면 틀렸다고 인정할지를 먼저 적어 두고, 결과는 그 문장에 대고 읽습니다.

한 문장 안에 네 조각이 들어가야 검증할 수 있는 형태가 됩니다.

1. 대상. 누구에게 적용되는 추측인지를 좁힙니다. 전체 사용자인지, 가입 첫 주인 사람인지, 무료 요금제를 쓰는 팀인지에 따라 결과가 전혀 다르게 나옵니다.
2. 변경. 무엇을 바꿀지를 구체적으로 적습니다. "온보딩을 개선한다" 는 무엇을 했는지 나중에 알 수 없는 문장이고, "가입 직후 예시 문서 한 개를 자동으로 만들어 준다" 는 알 수 있는 문장입니다.
3. 예상 결과. 어떤 지표가 어디에서 어디로 움직일지를 숫자로 적습니다. "첫 문서를 만드는 비율이 34퍼센트에서 40퍼센트로 오른다" 처럼 지금 값과 목표 값을 함께 둡니다. 지금 값이 없으면 오른 것인지 원래 그랬던 것인지 구분되지 않습니다.
4. 판정 기준. 언제 어떤 조건에서 확인할지를 미리 정합니다. 2주 동안 각 무리에 1,000명이 모이면 본다는 식입니다. 이 조각이 없으면 숫자가 유리해 보이는 시점에 실험을 멈추게 됩니다.

네 조각을 붙이면 한 문장이 나옵니다. "가입 첫 주 사용자에게 예시 문서를 자동으로 만들어 주면, 첫 문서 작성 비율이 34퍼센트에서 40퍼센트로 오를 것이다. 2주간 무리당 1,000명 기준으로 확인한다."

여기에 하나가 더 필요합니다. 틀렸다고 인정할 조건입니다. 40퍼센트를 못 넘으면 이 해법은 접는다는 문장을 같이 적어 둬야, 결과가 36퍼센트로 나왔을 때 "그래도 올랐으니 유지하자" 는 논의로 흐르지 않습니다.

쓰는 사람은 대개 그 문제를 맡은 프로덕트 매니저이고, 혼자 쓰지는 않습니다. 앞 단계인 문제 정의에서 누구의 어떤 문제를 풀지 못 박아 두었다면, 가설은 그 문제에 붙이는 해법 쪽 추측입니다. 예상 결과의 지금 값은 데이터를 다루는 사람이 뽑아 주고, 변경 내용은 디자이너·개발자와 같이 앉아야 실제로 만들 수 있는 크기로 적힙니다.

읽는 사람은 넷이고 보는 자리가 다릅니다.

1. 디자이너와 개발자. 변경 조각을 읽고 만들 범위를 잡습니다. 여기가 흐리면 두 사람이 서로 다른 것을 만듭니다.
2. 데이터를 보는 사람. 예상 결과와 판정 기준을 읽고 어떤 값을 어떻게 나눠 볼지 미리 준비합니다. 실험이 끝난 뒤에 이걸 정하면 결과에 맞춰 기준이 움직입니다.
3. 결정하는 사람. 이 추측에 두 달을 쓸지 2주를 쓸지 판단합니다. 틀렸을 때 잃는 것이 클수록 프로토타입처럼 싼 방법으로 먼저 확인하자는 결론이 나옵니다.
4. 몇 달 뒤의 팀. 그때는 아무도 이 결정의 맥락을 기억하지 못합니다. 남아 있는 문장 하나가 같은 시도를 두 번 하지 않게 막아 줍니다.

그래서 가설은 개인 메모가 아니라 팀이 함께 보는 글입니다. 실험이 끝나면 결과를 같은 문서에 이어 적고, 맞았는지 틀렸는지와 다음에 무엇을 할지를 남깁니다.

"이거 가설로 한번 적어 볼까요? 지금은 무엇을 확인하려는 건지가 안 보여요."

만들자는 주장을 검증 가능한 문장으로 바꿔 달라는 요청입니다.

"가설은 40퍼센트였는데 36퍼센트 나왔어요. 기준대로면 접는 게 맞죠."

미리 정해 둔 판정 기준을 결과에 맞춰 바꾸지 말자는 말입니다.

"판정 기준이 없어서 언제 끝내야 할지 모르겠어요."

숫자를 보는 시점이 정해지지 않아 실험이 계속 떠 있다는 뜻입니다.

페이지덱에서 가입 첫 주 이탈이 문제로 올라왔을 때, 지현은 사용자 리서치에서 들은 말 중 "빈 문서를 보면 뭘 써야 할지 모르겠다" 는 반응을 골라 가설을 적었습니다. 예시 문서를 자동으로 만들어 주면 첫 문서 작성 비율이 34퍼센트에서 40퍼센트로 오를 것이라는 문장이었습니다.

민서가 예시 문서 화면을 만들고 태오가 A/B 테스트로 절반에게만 보여 주도록 붙였습니다. 2주 뒤 결과는 36퍼센트였습니다. 방향은 맞았지만 기준에는 못 미쳤고, 팀은 예시 문서를 더 만드는 대신 다른 기회로 넘어가기로 했습니다. 미리 적어 둔 문장이 없었다면 이 논의는 "그래도 올랐잖아요" 에서 멈췄을 겁니다.

가설은 맞히려고 쓰는 것이라고 생각하기 쉽습니다. 적어 둔 숫자를 달성하면 잘한 일이고 못 넘기면 실패한 일처럼 보이기 때문입니다. 실제로 가설의 값은 맞고 틀림이 아니라 다음 판단을 바꿔 주는 데 있습니다. 틀린 가설은 그 방향에 더 쓸 돈과 시간을 아껴 주므로 그 자체로 소득입니다. 맞히는 것을 목표로 삼으면 팀은 확실히 오를 만한 작은 변경만 고르게 되고, 크게 틀릴 수 있지만 크게 바뀔 수도 있는 시도는 아무도 제안하지 않습니다.

숫자만 붙으면 가설이라고 보는 것도 흔합니다. "이 기능으로 재방문율을 높인다" 에 숫자를 하나 넣으면 형태는 갖춰 보입니다. 하지만 어떤 결과가 나오면 틀렸다고 인정할지가 없으면 그 문장은 확인할 수 없습니다. 어떤 결과가 나와도 설명이 붙기 때문입니다. 네 가지 리스크 중 사람들이 이걸 원하는지를 묻는 자리가 특히 그렇습니다. 원한다는 것을 반증할 조건을 적지 않으면 낮은 숫자도 "아직 알려지지 않아서" 로 넘어가고, 그 기능은 몇 분기를 더 살아남습니다.