솔직히 고백하자면, 저는 구글을 맹신하는 편이었습니다. 주니어 디자이너로서 레퍼런스를 찾을 때나 UI 가이드를 잡을 때, 구글의 머터리얼 디자인(Material Design)은 언제나 정답지처럼 느껴졌기 때문입니다. 논리적이고, 군더더기 없고, 사용자의 행동을 예측한 듯한 그 완벽함에 경외심마저 들었습니다. 하지만 최근 제프 스타(Jeff Starr)라는 개발자이자 작가가 겪은 2026년의 구글 DMCA(디지털 밀레니엄 저작권법) 처리 과정을 보며, 저는 믿었던 도끼에 발등이 찍히는 듯한 충격을 받았습니다. 그리고 동시에, 우리가 서비스를 만들 때 'Unhappy Path(예외 상황)'를 어떻게 설계해야 하는지에 대해 뼈저린 교훈을 얻었습니다.
상황은 이렇습니다. 제프 스타는 수년간 자신의 책 불법 복제본을 발견할 때마다 구글에 신고했고, 구글은 이를 즉각적으로 처리해 왔습니다. 시스템은 매끄러웠고 신뢰할 수 있었죠. 하지만 2026년, 상황이 급변했습니다. 여느 때처럼 신고서를 제출했지만, 구글은 처리가 아닌 '반려' 통보를 보냈습니다. 이유는 황당하게도 "당신이 저작권자라는 것을 확신할 수 없다"였습니다. 심지어 허위 신고 시 법적 책임을 물을 수 있다는 위협적인 문구까지 덧붙였습니다.
문제는 여기서부터 시작됩니다. 당황한 제프가 "저는 저자 제프 스타가 맞습니다. 무엇을 더 제출해야 합니까?"라고 묻자, 구글은 구체적인 가이드는 전혀 주지 않은 채 "저작권 소유 주장에 대한 근거를 더 설명해달라"는 모호한 답변만 앵무새처럼 반복했습니다. 신분증을 원하는지, 출판 계약서를 원하는지, 아니면 혈액형이라도 알려달라는 것인지 알 수가 없었죠. 결국 제프는 자신이 운영하는 사이트, 서치 콘솔(Search Console) 인증 내역, 소셜 미디어 계정 등 온갖 증거를 긁어모아 장문의 메일을 보냈지만, 돌아온 것은 차가운 매크로 답변이었습니다. "조치를 취하지 않기로 결정했습니다. 해당 웹사이트 소유자와 직접 해결하세요."
이것은 UX 관점에서 볼 때 단순한 '실수'가 아니라, 거대한 시스템이 사용자를 절벽으로 밀어버린 '설계된 재앙'입니다. 저는 이 사례를 보며 기획서 빈칸을 채우듯 막연하게 화면을 그렸던 제 자신을 반성했습니다. 우리가 흔히 말하는 '엣지 케이스'나 '코너 케이스'에서 사용자가 겪는 좌절감은 상상을 초월합니다. 특히 구글처럼 독점적인 지위를 가진 플랫폼이 자동화된 봇(Bot) 뒤에 숨어버리면, 사용자는 무력감을 넘어 분노를 느낍니다.
그렇다면 우리 같은 실무자들은 이 참사를 반면교사 삼아 무엇을 해야 할까요? 저는 '문서 깎는 노인'이라는 별명답게, 개발팀과 기획팀에 전달할 세 가지 구체적인 액션 아이템을 정리해 보았습니다.
첫째, '모호한 검증'을 없애고 '명시적인 요구사항'을 UI에 박아야 합니다.
사용자가 무언가를 증명해야 할 때, "자격을 증명하세요"라는 추상적인 텍스트는 죄악입니다. 제프의 사례에서 구글이 실패한 결정적인 이유는 'How(어떻게)'를 알려주지 않았기 때문입니다. 입력 폼이나 반려 메일에는 반드시 "사업자 등록증 사본, 혹은 ISBN이 포함된 출판 계약서 PDF를 첨부하십시오"와 같이 구체적인 파일 형식과 종류를 명시해야 합니다. 사용자가 고민하게 만들지 마십시오. 고민하는 순간, 그것은 나쁜 디자인입니다.
둘째, 자동화의 끝에는 반드시 '사람'으로 연결되는 비상구를 만들어야 합니다.
AI나 자동화 봇은 효율적이지만, 완벽하지 않습니다. 구글의 시스템은 제프가 아무리 강력한 증거를 제출해도 정해진 알고리즘을 벗어나는 순간 '처리 불가'로 판단하고 닫아버렸을 가능성이 큽니다. 챗봇이나 자동 응답 시스템을 설계할 때는, 2~3회 이상 문제가 해결되지 않거나 사용자가 부정적인 키워드(환불, 신고, 법적 대응 등)를 반복할 경우 즉시 '상담원 연결'이나 '수동 검토 요청' 버튼을 활성화하는 로직을 심어야 합니다. 이것은 기술의 문제가 아니라, 서비스의 태도 문제입니다.
셋째, 거절의 이유를 '납득 가능한 언어'로 설명해야 합니다.
"내부 규정에 따라 거절되었습니다"라는 말은 "우리는 너를 도울 생각이 없다"는 말과 같습니다. 거절 메시지는 개발자 콘솔에 찍히는 에러 로그가 아닙니다. 사용자가 다음에 무엇을 수정해야 성공할 수 있는지 알려주는 '내비게이션'이어야 합니다. "제출하신 이미지의 해상도가 낮아 식별이 불가능합니다"라거나 "첨부된 링크가 만료되었습니다"처럼, 수정 가능한 원인을 제시해야 합니다.
우리는 구글이 아닙니다. 우리 서비스에서 이런 일이 발생한다면, 사용자는 쌍욕을 하고 떠나는 것으로 끝나지 않습니다. 그들은 다시는 돌아오지 않을 것이고, 소셜 미디어에 악평을 쏟아낼 것입니다. 개발 가이드(Handoff) 문서를 작성할 때, 화려한 인터랙션보다 더 중요한 것은 에러 상황에서 사용자를 구출하는 이 '생존 로직'들입니다. 오늘 여러분이 작성 중인 기획서나 디자인 시안에, 과연 'Unhappy Path'를 걷게 될 사용자를 위한 배려가 1px이라도 들어가 있는지 다시 한번 점검해 보시길 바랍니다.
