적대적 검토
Adversarial Review
출시 전에 스스로 최악의 사용법을 시도해 허점을 찾아내는 내부 점검 절차
쉽게 말하면
적대적 검토란 제품을 세상에 내놓기 전에, 만든 사람이 일부러 나쁜 의도로 그 제품을 써 보면서 허점을 찾는 절차다.
비유하자면 새 자물쇠를 만든 회사가 자물쇠 따는 사람을 불러 직접 열어보게 하는 것과 비슷하다. 평소 점검은 "이 기능이 잘 작동하는가"를 확인하지만, 적대적 검토는 "이 기능으로 가장 그럴듯한 거짓말을 만들어 보라", "이 기능을 가장 나쁘게 쓰면 어떻게 되는가"라는 과제를 스스로에게 던진다. 문제를 처음 발견하는 사람이 사용자나 기자가 아니라 만든 사람 자신이 되도록 순서를 바꾸는 것이다.
특히 지도나 의료 정보처럼 사용자가 화면에 나온 내용을 곧이곧대로 사실로 받아들이는 서비스에서는, "해서는 안 될 말을 걸러내는" 일반적인 점검만으로는 부족하다. "틀린 내용을 그럴듯하게 사실처럼 말하는" 상황은 따로 만들어 보지 않으면 발견되지 않기 때문에, 적대적 검토가 별도로 필요해진다.
기사에서 이렇게 나와요
기사는 지도 위 생성형 기능이 하루 만에 철회된 사례를 두고 "출시 전 적대적 검토를 넣는다"를 제품 만드는 쪽이 가져갈 교훈으로 꼽는다. 오해하기 쉬운 지점은 이것이 외부 해커의 공격을 막는 보안 점검이라는 생각인데, 실제로는 내부 팀이 스스로 최악의 시나리오를 만들어 보는 자체 검증 절차에 가깝다.
직접 해보기
새로 만들거나 검토 중인 기능이 있다면 아래 질문을 그대로 팀 내부에 던져 본다.
- 이 기능을 이용해 만들 수 있는 가장 그럴듯한 거짓 정보는 무엇인가?
- 사용자가 그 거짓 정보를 사실로 착각할 가능성이 얼마나 되는가?
- 그 오답이 화면에서 사라지지 않고 캐시나 검색 결과에 남으면 어떻게 되는가?
답이 쉽게 나온다면, 그 시나리오를 실제로 재현해 보고 출시 전에 고친다.
