일주일 안에 끝내는 작은 검증 실험

헬로뭘드 작성 가이드 · 2026년 10월 4일

실험은 제품이 성공할 것이라는 증거를 모으는 행사가 아닙니다. 다음 결정을 바꿀 수 있는 정보를 얻는 과정입니다. 앱을 만들기 전에 사람이 서비스를 대신 제공해도 중요한 가설을 시험할 수 있습니다.

가장 먼저 틀려서는 안 되는 가정을 고르기

점심 추천 서비스에 필요한 가정은 여러 가지입니다. 팀이 메뉴 선택을 불편해하는지, 추천을 신뢰하는지, 반복해서 쓰는지, 누가 돈을 내는지입니다. 모두 한 번에 확인하려고 하면 결과가 나빠도 이유를 구분할 수 없습니다.

아직 문제의 강도가 불확실하다면 첫 질문은 ‘추천 알고리즘이 정확한가?’보다 ‘도움이 제공되면 실제 선택에 사용하고 다음에도 요청하는가?’입니다. 사업에 미치는 영향이 크고 근거가 적은 가정부터 확인하세요.

‘재사용률 60%’만 적으면 무슨 일이 있었는지 알기 어렵습니다. 모집한 5개 팀 중 3개 팀인지, 추천을 실제로 받은 3개 팀이 모두 돌아온 것인지 구분해야 합니다. 모집 수, 정상 전달 수, 선택 수, 재요청 수를 함께 남기세요.

예를 들어 두 팀이 휴가여서 추천을 받지 못했다면 이를 서비스 거절과 같은 것으로 세지 않습니다. 그렇다고 결과에서 조용히 빼서 비율을 높이지도 않습니다. 처음 정한 분모의 결과와 실제 노출된 집단의 결과를 함께 쓰고 관찰이 부족했다는 한계를 표시합니다.

‘유용했어요’라는 답은 피드백입니다. 추천한 식당에 갔다는 답은 사용의 단서입니다. 운영자가 재촉하지 않아도 다시 요청한 행동은 반복 필요의 단서입니다. 이 셋을 같은 성공 지표로 합치지 마세요.

재요청도 무료라는 조건이나 운영자와의 친분 때문에 생길 수 있습니다. 참여 경로, 제공한 혜택, 재촉 여부를 기록해야 결과를 이해할 수 있습니다. 작은 표본의 결과는 다음 실험을 정하는 데 쓰고, 시장 전체에 일반화하지 않습니다.

가설을 지지하는 신호: 예상한 행동이 정한 조건에서 관찰됨. 기간이나 모집 경로를 바꿔 반복되는지 확인합니다.
가설과 맞지 않는 신호: 정상적으로 추천을 받았지만 선택하거나 돌아오지 않음. 이유를 듣고 고객군·문제·해결책 중 무엇을 수정할지 정합니다.
판단할 수 없는 결과: 휴가, 전달 실패, 너무 짧은 관찰 기간 등으로 기회 자체가 없었음. 실패나 성공으로 포장하지 않고 설계를 보완합니다.

무료 반복 사용이 확인되어도 유료 수요가 확인된 것은 아닙니다. 다음 실험에서는 실제 결제 주체에게 제공 범위와 가격을 명확히 제안해야 합니다. 아직 제공하지 못하는 기능을 가능한 것처럼 약속하지 마세요.

수동 실험 동안 팀당 추천에 걸린 시간, 정보 확인 비용, 문의 대응 시간을 기록합니다. 한 팀에는 쉬운 작업도 여러 팀이 동시에 요청하면 지속하기 어려울 수 있습니다. 자동화할 부분은 이 기록을 바탕으로 정하면 됩니다.

실험 전 가설, 관찰한 행동, 한계, 바꾼 판단을 짧게 적습니다. ‘실험 후’ 버전을 저장하고 다음에는 한 가지 조건만 바꿔보세요. 결과가 좋지 않아도 불필요한 개발을 줄이거나 고객군을 좁혔다면 의사결정에 쓰인 실험입니다.