시제품을 사용자 손에 맡기는 단계 - 필드 테스트에서 무엇을 얻어야 하는가

시제품이 개발실의 검증을 통과하고 나면, 많은 창업자분들이 다음 단계로 양산을 떠올리십니다. 그런데 그 사이에 건너뛰기 쉬운 계단이 하나 있습니다. 시제품을 개발자가 아닌 사람들의 손에 일정 기간 맡겨보는 필드 테스트입니다. 이 계단을 건너뛴 제품은 출시 후에야 진짜 사용자를 처음 만나게 되고, 그때 발견되는 문제는 이미 양산된 수량만큼의 무게로 돌아옵니다.

결론을 먼저 말씀드리면, 필드 테스트의 목적은 "제품이 잘 작동하는지 확인하는 것"이 아니라 "우리가 상상하지 못한 사용 방식을 발견하는 것"입니다. 잘 작동하는지는 개발실에서 이미 확인했습니다. 필드에서 얻어야 할 것은 개발자라면 절대 하지 않을 방식으로 제품을 다루는 진짜 사용자들의 모습이며, 그 발견의 양은 우연이 아니라 테스트를 어떻게 설계했는지에 비례합니다.

개발자의 손을 떠난 시제품은 상상하지 못한 방식으로 다뤄지기 시작합니다.

개발실의 검증과 필드의 검증은 다른 것을 봅니다

개발자는 제품을 곱게 씁니다. 설명서대로 조작하고, 이상하면 원인을 짐작하고, 충전을 잊지 않습니다. 사용자는 다릅니다. 설명서를 읽지 않고, 버튼을 길게 눌러야 할 곳에서 연타하고, 물기 있는 손으로 만지고, 몇 주씩 서랍에 방치했다가 다시 꺼냅니다. 이 차이가 필드 테스트의 존재 이유입니다. 개발실의 검증이 "설계대로 만들어졌는가"를 본다면, 필드의 검증은 "설계의 전제가 현실과 맞는가"를 봅니다.

그래서 필드에서 발견되는 문제의 목록은 기능 오류보다 다른 것들로 채워지는 경우가 많습니다. 사용자가 제품의 상태 표시를 다른 의미로 오해하고 있었다든가, 예상과 전혀 다른 장소에 두고 쓴다든가, 우리가 핵심이라 여긴 기능은 안 쓰고 부가 기능만 쓴다든가 하는 발견들입니다. 이것들은 고장이 아니라 정보이며, 양산 전에 얻을 수 있는 가장 값진 정보입니다.

누구에게, 몇 대를, 얼마나 맡길 것인가

테스트 참가자 선정에서 가장 흔한 함정은 우호적인 지인들로만 채우는 것입니다. 가까운 사람들은 불편을 참고, 좋은 점을 찾아 말해줍니다. 따뜻하지만 배울 것이 적은 피드백입니다. 필요한 것은 우리 제품의 실제 목표 고객에 가까우면서, 불편을 불편이라고 말해줄 사람들입니다. 지인을 포함하더라도 "칭찬은 필요 없고 걸리는 점만 말해 달라"고 역할을 명확히 부탁하는 것이 좋습니다. 사용 환경도 섞여야 합니다. 같은 제품이라도 아파트와 주택, 사무실과 현장에서 다른 문제를 드러냅니다.

수량은 시제품을 몇 대 만들 것인가의 논의와 이어집니다. 필드 테스트를 계획에 넣는 순간, 시제품 수량은 검증용 몇 대에서 배포용까지 포함한 수로 늘어나고, 여러 대를 같은 품질로 만드는 문제가 시제품 단계에서 미리 등장합니다. 기간은 첫인상이 아니라 습관을 볼 수 있을 만큼이어야 합니다. 처음 며칠의 신기함이 걷히고 제품이 일상이 된 뒤의 모습, 그리고 방치되었다가 다시 쓰이는 모습까지 담기는 기간을 잡는 것이 좋습니다.

필드 테스트는 제품이 실험대가 아니라 누군가의 일상에 놓였을 때를 관찰하는 일입니다.

기록이 설계되어야 발견이 남습니다

필드 테스트의 성과는 참가자의 기억력에 맡기면 증발합니다. "쓰다 보니 괜찮았어요"라는 회수 시점의 소감은 몇 주간의 경험이 뭉개진 요약일 뿐입니다. 기록은 두 겹으로 설계합니다. 한 겹은 제품이 스스로 남기는 기록입니다. 언제 켜지고 얼마나 쓰였는지, 어떤 오류가 몇 번 났는지를 제품 안에 남겨두면, 사용자가 말해주지 않는 진실이 회수 후에 읽힙니다. 양산 후의 진단 경로를 시제품 기판에 심어두는 이야기를 드린 적이 있는데, 필드 테스트는 그 설계가 첫 수확을 거두는 무대입니다.

다른 한 겹은 사람의 기록입니다. 다만 참가자에게 긴 일지를 요구하면 며칠 만에 멈추므로, 부담을 최소로 설계합니다. "걸리는 순간이 있으면 그 자리에서 한 줄만 보내 달라"는 방식과, 중간에 한두 번 짧은 통화로 근황을 묻는 방식의 조합이 현실적입니다. 그리고 회수하는 날의 대화가 가장 밀도 높은 수확의 시간입니다. 제품을 앞에 두고 "평소처럼 한번 써 보시겠어요"라고 청하면, 말로는 나오지 않던 오해와 습관이 눈앞에서 재현됩니다.

발견은 다음 차수의 도면으로 돌아가야 합니다

회수된 발견들은 목록으로 정리되어 다음 차수의 설계 수정으로 이어질 때 비로소 값을 합니다. 이때 모든 피드백을 반영하려는 유혹을 경계해야 합니다. 여러 사람에게서 반복해서 나온 문제와 한 사람의 취향을 구분하고, 양산 전에 고쳐야 할 것과 다음 세대로 미룰 것을 나누는 판단이 필요합니다. 기능을 계속 더하다 개발이 끝나지 않는 함정은 필드 테스트 이후에 가장 자주 나타납니다. 필드 테스트는 제품을 완벽하게 만드는 단계가 아니라, 양산이라는 큰 결정을 근거 있게 내리기 위한 단계입니다.

판단 기준은 한 문장입니다

"양산 수량을 결정하는 회의에서, 우리는 개발실의 데이터 외에 무엇을 근거로 내밀 수 있는가." 실제 사용자들의 몇 주가 담긴 기록과 발견의 목록이 그 자리에 있다면, 양산은 도박이 아니라 판단이 됩니다. 필드 테스트에 드는 몇 주는 양산 후에 문제를 만나는 몇 달에 비하면 언제나 싼 값입니다.

일상 속에 놓인 몇 주의 기록이 양산 결정의 가장 든든한 근거가 됩니다.

제언: 필드 테스트는 시제품 계획에 처음부터 넣으십시오