AI로 글을 쓴다. AI로 번역한다. AI로 링크를 고친다. AI로 접속 통계를 낸다. AI에게 "여기 헷갈리지 않아?" 하고 물어보고, 또 AI로 고친다.
여기까지 오면 대개 이런 문제가 생긴다.
다들 사이트를 너무 잘 안다.
만든 사람은 버튼이 무슨 뜻인지 안다. AI도 사양서를 읽으면 "이 버튼은 관련 글이구나" 하고 이해한다. 운영자는 수없이 봐서, 조금 이상해도 머릿속에서 알아서 메워 버린다.
하지만 처음 온 사람은 다르다.
"이거 뭐지?" "어딜 눌러야 해?" "왜 여기만 영어야?" "뒤로 못 가겠는데." "글은 읽히는데, 왠지 찝찝해."
이 '왠지'가 필요하다.
그래서 마지막에 나온 아이디어가 꽤 재미있다.
드디어 디버깅 공정을 진짜 사람에게 외주 맡긴다.
게다가 지적 1건당 1엔. 한 사람당 최대 1,000엔.
사람이 AI의 일자리를 빼앗는 시대가 왔다. 담당 업무는 '위화감'이다.
1. 맡기고 싶은 건 코드 리뷰가 아니라 '처음 봤을 때 걸리는 곳'
이번에 필요한 건 전문가의 대규모 감사가 아니다.
- 버튼이 무슨 뜻인지 모르겠다
- 다음에 어디로 가야 할지 모르겠다
- 제목이 이상하다
- 스마트폰에서 누르기 어렵다
- 링크를 눌렀더니 다른 언어 페이지가 나온다
- 뭔가 눌렀더니 화면이 하얘졌다
- 문장으로는 맞는데, 사람이 읽으면 어색하다
- 여기에 이런 기능이 있으면 편하겠다
이런 것들이다.
미국 정부의 웹 가이드 Digital.gov는 사용성 테스트를, 실제 이용자가 제품이나 서비스를 써 보는 모습을 관찰하는 방법이라고 설명한다. [1] 영국 정부의 GOV.UK도 실제 이용자의 조작을 지켜보면 언어나 레이아웃 같은 구체적인 문제를 찾을 수 있다고 말한다. [2]
그러니까 "사람에게 한 번 만져 보게 한다"는 건 AI 시대에 갑자기 생긴 수상한 의식이 아니다.
예전부터 있던 사용성 테스트가 AI로 대량 생산하고 대량 수정할 수 있는 사이트로 돌아왔을 뿐이다.
2. 운영자 본인이 가장 제대로 테스트하지 못할 때가 있다
내 사이트를 매일 꼼꼼히 확인한다.
말은 쉽다. 하지만 글이 늘고, 언어가 늘고, 기능이 늘면 현실적으로 불가능하다.
게다가 '만든 사람이 본다'에는 또 다른 문제가 있다.
검색창이 어디 있는지 안다. 관련 글이 어디에 뜨는지 안다. 언어 전환이 어떻게 동작하는지도 안다. 조금 이상해도 "원래 그런 거지" 하고 넘어간다.
그리고 무엇보다 보는 게 귀찮다.
이게 의외로 중요하다.
귀찮음을 정신력으로 눌러서 "매일 100페이지씩 확인하자"고 하면 그 운영은 오래 못 간다. 그렇다면 귀찮은 공정 자체를 떼어 내면 된다.
운영자는 전부 보는 사람이 아니라,
무엇을 볼지 정하고, 모인 이상 징후를 고치는 구조를 만드는 사람
이 되면 된다.
3. 1건 1엔으로 사는 건 '아이디어'가 아니라 처음 보는 눈이다
1건 1엔이라는 숫자만 보면 엄청나게 싸다.
하지만 여기서 사고 싶은 건 그럴듯한 컨설팅 자료가 아니다.
처음 보는 눈이 한 번 걸렸다는 사실이다.
한 사람이 1,000개를 내면 1,000엔. 다만 같은 내용을 말만 바꿔 쓴 건 1건으로 센다. 한 사람당 보상 상한도 1,000엔이다.
이 상한은 꽤 중요하다.
"많이 내 주세요"라고 하는 순간, 세상은 갑자기 "AI한테 개선점 1만 개 뽑게 하면 1만 엔 아닌가?" 하는 방향으로 달려가기 시작한다.
그래서 건수에 따른 보상과 함께 다음 조건을 세트로 건다.
- 실제로 사이트를 봤을 것
- 실제로 있는 곳, 실제로 일어난 동작에 대해 쓸 것
- 같은 지적을 말만 바꿔 부풀리지 않을 것
- 상한을 정해 둘 것
참고로 1건 1엔은 이번 실험을 위한 설계일 뿐, 보편적인 적정 보수가 아니다. 오랜 시간이 걸리는 작업이나 전문적인 평가를 부탁한다면 시간과 난이도에 맞는 조건으로 바꿔야 한다.
4. 가장 큰 적은 'AI로 개선점을 1만 개 만들었습니다'
AI 사용을 금지할 필요는 없다.
문제는 사이트를 한 번도 보지 않고 쓴 개선안이다.
"일반적으로 웹사이트는 내비게이션을 알기 쉽게 만들어야 합니다." "접근성을 개선합시다." "반응형 대응을 최적화합시다."
다 맞는 말이다.
그리고 전부 이번에 원하는 게 아니다.
원하는 건 이런 관찰이다.
"이 페이지의 이 버튼, 누르면 어떻게 되는지 알 수 없었다." "이 제목 다음에 갑자기 이야기가 튀었다." "이 언어 버전에서만 관련 글이 다른 언어로 연결됐다."
AI는 이런 관찰을 짧게 다듬거나 중복을 묶는 보조 역할로 쓸 수 있다.
사람이 발견하고, AI가 정리한다.
순서를 뒤집지 않는 게 중요하다.
5. 한 건씩 채팅으로 보내면, 의뢰인이 먼저 죽는다
보고 수를 늘리고 싶다면 제출 방법도 설계해야 한다.
가장 괴로운 건 이런 방식이다.
"1번째입니다." "2번째입니다." "아, 3번째도 있어요." "추가로 4번째요."
채팅이 끝도 없이 길어진다.
이러면 디버깅을 외주 맡겼는데, 이번에는 보고를 모으는 새로운 수작업이 생긴다.
그래서 제출은 한꺼번에 받는다.
- 엑셀
- 스프레드시트
- txt
- 번호를 붙인 목록
- 복사해서 붙여 넣을 수 있는 텍스트
뭐든 괜찮다.
스크린샷도 원칙적으로 필요 없다. 이미지는 보기에는 편해도, 나중에 검색하고 중복을 없애고 AI로 처리할 때 마찰이 크다.
GOV.UK의 사용자 조사 가이드도, 타이핑한 메모는 나중에 보관하고 분석하기 쉽고, 관찰 하나를 항목 하나로 나누면 정렬과 분석이 쉽다고 한다. [3]
형식은 단순하면 된다.
위치 / 지금 어떤 상태인지 / 어떻게 하면 좋을지
버그라면 이렇게 쓴다.
위치 / 무엇을 했는지 / 무슨 일이 일어났는지
이것만으로도 뒤에서 AI가 꽤 많은 일을 할 수 있다.
6. 다국어 사이트에서 '번역됐다'와 '사람이 읽을 수 있다'는 별개의 문제다
다국어 사이트는 더 재미있다.
기계 기준으로는 12개 언어가 모두 생성에 성공했다. 빌드도 성공했다. HTTP 200이다. 링크도 존재한다.
그런데도 사람이 보면 평범하게 이상한 일이 있다.
- 일부에 원래 언어가 남아 있다
- 버튼만 번역이 이상하다
- 문장으로는 뜻이 통하지만 원어민에게는 부자연스럽다
- 글자가 길어져서 레이아웃이 깨진다
- 언어를 바꿨더니 관련 글만 원래 언어로 돌아간다
- 같은 글일 텐데 일부가 빠져 있다
이건 읽을 수 있는 사람만 보면 된다.
영어를 읽는 사람은 영어를. 한국어를 읽는 사람은 한국어를. 중국어, 스페인어, 포르투갈어, 인도네시아어, 태국어, 베트남어, 프랑스어, 독일어도 마찬가지다.
모든 사람에게 모든 언어를 보게 할 필요는 없다.
기계가 '생성됐다'를 확인하고, 사람이 '이거 자연스럽게 읽혀?'를 확인한다.
역할이 다르다.
7. 중복은 보상에서는 1건이지만, 분석에서는 엄청나게 중요하다
같은 사람이
"버튼이 헷갈린다" "버튼의 의미를 모르겠다" "이 버튼 뭐야?"
라고 세 번 썼다면 1건으로 충분하다.
하지만 서로 다른 세 사람이 각자 같은 버튼에서 멈췄다면 이야기가 달라진다.
그건 단순한 중복이 아니라 재현되는 마찰이다.
그래서 집계할 때는 이렇게 나눈다.
- 같은 사람이 말만 바꾼 것은 하나로 합친다
- 다른 사람이 독립적으로 낸 같은 지적은 빈도로 남긴다
"세 사람이 같은 곳에서 헤맸다"는 운영자의 취향보다 강하다.
GOV.UK도 실제 또는 예상 이용자를 대상으로 사용성을 자주 확인하고, 이용자의 행동을 반영하는 여러 기기에서 테스트하는 것을 서비스 표준으로 삼고 있다. [4]
사람 수를 늘리는 의미는 '의견 투표'가 아니라, 같은 마찰이 다른 사람에게도 생기는지 확인하는 것에 있다.
8. 완성형은 AI → 사람 → AI. 사람은 센서가 된다
최종 공정은 꽤 깔끔해진다.
- AI가 글을 생성한다
- AI가 번역한다
- AI가 링크, 구조, 화면 표시를 검사한다
- AI가 이미 알려진 문제를 고친다
- 사람이 실제로 읽고, 누르고, 헤맨다
- 사람이 '뭔가 이상해'를 텍스트로 낸다
- AI가 중복을 합친다
- AI가 심각도, 재현성, 수정 비용으로 분류한다
- AI가 수정 후보를 만든다
- 수정 후 다시 기계 검사와 사람의 확인으로 돌아간다
드디어 사람까지 파이프라인의 한 공정이 되었다.
다만 사람에게 남은 일은 단순 작업이 아니다.
사람이라서 느끼는 마찰을 감지하는 것이다.
오히려 역할이 격상됐다고 보는 편이 맞다.
기계에게는 "링크가 404인가"를 보게 하고, 사람에게는 "404는 아닌데 왜 여기로 보내졌는지 모르겠다"를 보게 한다.
기계에게는 "번역 문자열이 있는가"를 보게 하고, 사람에게는 "있긴 한데 보통 사람은 이렇게 말하지 않는다"를 보게 한다.
그편이 분업으로서 자연스럽다.
9. 테스터가 보면 PV도 늘어난다. 하지만 그걸 목적으로 삼지는 않는다
당연히 수십 페이지를 보게 하면 조회수는 늘어난다.
광고가 있는 사이트라면 일반적인 열람에 따라 광고가 표시될 수도 있다.
하지만 이건 어디까지나 부산물이다.
광고를 클릭하게 하거나, 광고 노출을 늘리는 것을 작업 조건으로 거는 설계는 전혀 다른 문제다.
사는 건 PV가 아니다.
사람이 페이지를 본 결과로 남는 관찰이다.
그 김에 접속이 조금 늘었다면, "사용자 테스트를 했더니 계산대도 살짝 울렸네" 정도로 생각하는 게 딱 좋다.
10. 자동화의 종착점은 '사람 제로'가 아니었다
AI를 쓰기 시작하면 "사람을 어디까지 없앨 수 있을까" 하는 생각이 들기 마련이다.
그런데 실제로 자동화를 밀어붙이면 반대 결론이 나올 때가 있다.
사람을 전부 없앨 필요는 없다.
사람만 가치를 낼 수 있는 자리까지 사람을 옮기면 된다.
글 초안. 번역. 중복 정리. 링크 검사. 분류. 집계. 수정안.
이 부분은 기계 쪽으로 넘긴다.
그리고 마지막에,
"처음 봤는데 무슨 뜻인지 모르겠어요" "여기 싫어요" "뭔가 이상해요" "이거 편하네요"
이것만 사람에게서 산다.
1건 1엔으로 사는 건 한 줄짜리 문장이 아니다.
나도 AI도 가질 수 없는, 다른 사람의 한순간의 위화감이다.
자동화를 끝까지 밀어붙인 끝에 사람이 돌아왔다.
그것도 담당 부서는 '뭔가 이상해'다.
더없이 사람답다.
- Digital.gov, “Usability testing digital.gov
- GOV.UK Service Manual, “Using moderated usability testing gov.uk
- GOV.UK Service Manual, “Taking notes and recording user research sessions gov.uk
- GOV.UK Service Manual, “4. Make the service simple to use gov.uk
