‘실행 전에 물어보라’는 수요를 찾았지만, 반대 사례가 나왔습니다

AI 요약

StareBrain 개발자는 사용자가 Siri나 Google Assistant의 무단 실행에 불만을 터뜨린 사례를 찾아 수요를 확인하려 했습니다. 검색을 두 차례 했지만 예상한 유형의 불만은 거의 찾지 못했습니다. 첫 검색에서 발견한 글은 오히려 Siri가 기본적으로 확인을 요청하며, 일부 사용자는 느리다는 이유로 확인을 끄는 설정을 찾는다는 내용이었습니다.

확인 절차를 원하는 상황은 어디일까요?

작성자는 검색 결과가 확인을 덜 원하는 쪽으로 기울었다면, ‘확인이 부족해 불편하다’는 가정은 적어도 문자 전송 같은 사례에는 맞지 않을 수 있다고 봅니다. 다만 불만이 App Store 리뷰나 특정 Subreddit처럼 일반 검색에 잘 잡히지 않는 곳에 있을 가능성도 남겨둡니다. 또 사용자가 모든 행동의 확인을 원하기보다 결제나 파일 삭제처럼 되돌리기 어렵거나 위험이 큰 작업에서만 확인을 바랄 수도 있다고 제시합니다. 어느 쪽인지는 아직 판단하지 않았으며, 반대 증거를 발견한 뒤에도 처음 가정을 계속 믿지는 않겠다고 씁니다.

Indie Hackers 반응

• @junyoungpark — 제 PC에서 데스크톱 비서를 매일 쓰는 경험과 같습니다. 앱 열기, 양식 작성, 검색 같은 일상 작업은 매번 확인을 물어보는 게 번거로워져서 그냥 ‘예’를 눌렀습니다. 되돌리기 어려운 작업, 즉 결제, 파일 삭제, 메시지 전송 전에는 확인을 남겼고, 대기 중인 작업보다 ‘중지’ 명령을 우선하는 규칙도 하나 뒀습니다. 확인보다 더 중요했던 건 작업이 실제로 실행됐는지 불확실할 때 비서가 재시도하지 않고 먼저 확인하는 점이었습니다. 메시지가 두 번 전송되는 일이 확인 누락보다 더 큰 문제입니다. 두 번째 해석이 맞을 것 같습니다. 사람들은 확인을 더 자주 받기보다 되돌릴 수 없는 작업의 안전을 원합니다.
• @john_forsythe — 오히려 이번 결과는 검색 방식 자체에 관한 발견입니다. 확인을 덜 원하는 사람은 공개적으로 불만을 말하고, 확인을 원하는 사람은 되돌릴 수 없는 일이 잘못되고 나서야 말한다면 검색은 수요가 아니라 불만을 표집합니다. 이 글의 송장 사례가 패턴을 보여줍니다. 되돌리는 비용이 클 때만 확인이 제 역할을 합니다. 가정을 접기 전에 기능 요청보다 사고 후기를 찾아보겠습니다. 사람들은 미리 안전장치를 요구하기보다 잘못된 전송이나 결제가 일어난 뒤 필요했다고 말하는 경우가 많습니다.
• @ryanshrott — Siri 사례를 보니 사람들이 또 다른 예·아니오 확인 창보다 비서를 더 빠르게 수정하는 방법을 원하는 건 아닌지 궁금합니다. 음성 받아쓰기 도구 DictaFlow를 만들었는데, 삽입한 글은 사용자가 전송하기 전까지 수정할 수 있습니다. 같은 음성 메시지를 초안으로 보여주는 방식과 바로 전송하는 방식을 비교하고, 수정 횟수와 중단된 작업을 추적해 보겠습니다. 확인 창을 더 원하는지 묻지 않고도 사용자가 더 많은 통제권을 원하는지 알 수 있습니다.
• @matthewstadnik — 반대 결과를 조용히 묻어두지 않은 점이 좋습니다. 그런 태도는 생각보다 드뭅니다. 제가 본 확인 수요도 두 번째 해석에 가깝습니다. 사람들은 ‘모든 걸 확인해 달라’고 하지는 않지만, 되돌리기 힘든 작업에서 문제가 생기면 화를 냅니다. 위험이 낮은 작업은 확인 없이 빠르게 처리하는 편이 낫습니다. 더 찾아본다면 가정이 틀렸다고 결론 내리기 전에 검색을 두 갈래로 나눠 보겠습니다. 되돌릴 수 없거나 위험이 큰 작업, 그리고 일상 작업을 하는 상시 비서입니다. 같은 ‘실행 전에 물어보기’라는 표현이어도 증거는 다를 수 있습니다. 검색을 다시 할 때 가정을 지지하는 결과만큼 반박하는 결과도 꼼꼼히 기록할 계획인가요?
• @brianainews — 유용한 검증입니다. 위험이 큰 작업과 작은 작업을 나누는 관점은 에이전트 설계에서 특히 중요해 보입니다. 확인으로 생기는 마찰은 되돌리기 쉬운 정도와 실수의 파급 범위에 맞춰야 합니다. ByteForward https://youtu.be/0YPSv4keATc
• @biyun_builds — 지난달 저도 같은 갈림길을 겪었습니다. 제 분야에서 쓰는 용어로 키워드 알림을 6주간 살펴봤는데, 결과 여섯 건 중 실제 문제를 겪은 사람은 한 명도 없었습니다. 전부 도구 제작자였습니다. 문제는 있었지만 제가 붙인 이름으로 표현되지 않았습니다. 사람들은 분야 이름 대신 증상을 설명합니다. 문제를 부르는 말이 아니라 실패가 어떻게 나타나는지 검색해 보세요. ‘확인’보다 ‘Siri가 엉뚱한 사람에게 문자를 보냈다’처럼요.
• @Luca_Rossi — 가정과 반대되는 결과를 찾는 게 가장 좋은 조사 결과입니다. 사람들이 확인 단계 없이도 에이전트에게 귀찮은 일을 맡긴다면, ‘먼저 물어보기’는 사용자의 불편보다 창업자의 두려움을 해결하는 기능일 수 있습니다. 실제로 발견한 ‘반대’가 무엇인지 궁금합니다. 확인 절차에 관한 침묵이었나요, 아니면 확인 없이 바로 실행하는 편을 선호한다는 명시적 의견이었나요?
• @slatecoil — 되돌릴 수 없는 작업에 관한 사례를 하나 보탭니다. 저는 이스라엘의 소상공인용 송장 소프트웨어를 만듭니다. 발행한 세금계산서는 영구 기록이라 수정하거나 삭제할 수 없고, 신용 전표로 취소해야 하며 원본과 취소 기록이 모두 남습니다. 그래서 자연스러운 히브리어 설명으로 송장을 작성하는 AI를 추가했을 때, AI는 초안까지만 만들고 저장은 사용자가 누르게 했습니다. 영수증을 읽어 비용을 입력하는 기능도 현재는 같은 방식이지만, 비용은 나중에 고칠 수 있으므로 일괄 업로드에서는 확인을 줄일 수도 있습니다. 저희에게 확인 절차는 실수를 되돌릴 수 없는 곳에서만 필요합니다. 두 번째 해석과 비슷합니다.
• @James_UtilitySEO — 오늘 저도 양쪽 입장에 있었습니다. AI가 작성한 커뮤니티 게시물의 승인 절차가 느려서 없애 달라고 했습니다. 하지만 잘못된 게시물은 계정 평판을 해치고 게시 후 되돌릴 수 없어서, 한 단어로 승인하는 절차는 남겼습니다. 되돌릴 수 있는지에 따라 나누는 설명이 제 경험과 정확히 맞습니다. 덧붙이면 실수의 비용을 누가 부담하는지도 중요합니다. 명령을 내리는 사람은 속도를 원하지만, 잘못된 메시지를 받은 사람이나 게시물에 이름을 건 브랜드, 뒷수습을 맡는 팀장이 비용을 치를 수 있습니다. 확인 수요는 그 사람들이 느끼며, 구매자도 최종 사용자와 다를 때가 많습니다. StareBrain의 구매자는 누구라고 생각하나요? 직접 쓰는 사람인가요, 아니면 실행 결과에 책임지는 사람인가요?
• @rajnish_rajnish — 두 번째 설명을 뒷받침하는 사례입니다. 제 이름으로 무언가를 보내기 전에 승인받는 Telegram 봇을 만들었습니다. 승인 버튼에 6자리 코드도 붙였지만, 버튼을 누르는 편이 더 쉬워서 그날 바로 코드를 껐습니다. 하지만 승인 절차는 유지했습니다. 제 이름으로 보낸 메시지는 되돌릴 수 없기 때문입니다. 제 경우 되돌릴 수 있는지에 따라 정확히 나뉩니다. 승인은 남기고 승인 과정의 추가 번거로움은 없앴습니다. 불만을 어디서 찾아야 할지에 관해서는, 사람들은 미리 확인 절차를 요구하지 않을 것 같습니다. 비서가 엉뚱한 사람에게 문자를 보낸 뒤에 글을 올리겠죠. 기능 요청보다 그런 사례를 찾아보겠습니다.
• @tommy_twitee — 실제 실행 내용의 미리보기를 시험해 보면 어떨까요? 수신자, 메시지, 전송 시점을 보여주는 식입니다. 사용자는 추가 탭을 싫어하면서도 수신자가 잘못됐는지는 확인하고 싶을 수 있습니다. 제안된 작업을 얼마나 자주 수정하거나 취소하는지, 확인 기능을 끄는지 함께 살펴보겠습니다. 그러면 방해가 싫은 것인지, 비서가 이해한 내용을 확인하고 싶은 것인지 구분하는 데 도움이 됩니다.
• @aryan_sinh — 일상적인 작업과 되돌릴 수 없는 작업의 차이가 핵심인 듯합니다. 되돌리는 데 큰 비용이 드는 작업에서만 확인을 원하는 사용자 사례를 찾으셨나요?

원문: Indie Hackers / 번역·요약: Trawling