README 따라 해보는 사람에게 돈을 준다면? AI 시대의 사용자 테스트
핵심 요약
- README 작성자가 당연히 알 거라고 여긴 내용에서 처음 온 사람은 막힐 수 있습니다.
- AI가 설치에 성공했다고 해서 실제 사용자에게도 설명이 충분한 것은 아닙니다.
- 유료 사용자 테스트는 설치와 첫 실행처럼 구체적인 과제를 정해 진행할 수 있습니다.
- 사용자가 막힌 부분을 고친 뒤 다른 사람에게 다시 맡겨보면 나아졌는지 확인할 수 있습니다.
AI에게 문서를 다듬게 하고, 실행 환경을 갖춘 AI 에이전트에게 설치 절차를 점검하게 할 수 있습니다. 그렇다면 README를 따라 해보는 사람에게 굳이 돈을 줄 이유가 있을까요? 사람이 설명을 읽다가 어디서 헷갈리는지, 도움이 필요할 때 어떻게 행동하는지는 직접 지켜봐야 알 수 있습니다.
작성자에게는 당연한 단계도 설명이 필요합니다
README는 프로젝트를 소개하고 사용법을 알려주는 문서입니다. 소프트웨어를 처음 접한 사람은 이 문서를 보며 설치를 시작하고, 프로젝트에 대한 첫인상도 갖게 됩니다.
작성자는 이미 프로젝트를 잘 압니다. 필요한 프로그램을 설치해뒀고, 명령어를 어느 폴더에서 실행해야 하는지도 알고 있습니다. 그러다 보니 설명에서 한 단계가 빠져도 좀처럼 알아차리지 못합니다.
가령 README에 “설치 후 실행하세요”라고 적혀 있다고 해보겠습니다. 처음 온 사람에게는 설치가 끝났는지 판단할 기준부터 필요할 수 있습니다. 화면에 아무것도 나타나지 않으면 성공한 건지, 중간에 멈춘 건지 헷갈립니다.
이럴 때는 정상적으로 실행됐을 때 나오는 문구나 화면을 보여주면 됩니다. 실행 방법뿐 아니라 성공을 알아보는 방법까지 안내해야 사용자가 다음 단계로 넘어갈 수 있습니다.
AI의 성공과 사람의 이해는 따로 확인해야 합니다
AI에게 “처음 사용하는 사람처럼 이 문서를 검토해줘”라고 요청하면 빠진 설명이나 모호한 표현을 찾는 데 도움을 받을 수 있습니다. 명령을 실행할 수 있는 에이전트라면 설치 절차가 실제로 작동하는지도 점검할 수 있습니다.
다만 AI가 어떻게 성공했는지는 따져봐야 합니다. 문서에 없는 내용을 알고 있어서 빈틈을 메웠다면, 설치에 성공했다는 이유만으로 README의 설명이 충분했다고 보기는 어렵습니다.
예를 들어 설치 명령에 오류가 있다고 해보겠습니다. AI가 오류 메시지를 해석하고 다른 명령을 써서 해결했다면 유용한 발견입니다. 하지만 README를 그대로 따라 하면 막힌다는 증거이기도 합니다. 최종 결과만 확인하면 이 차이를 놓치게 됩니다.
AI에게 초보자 역할을 맡겨도 실제 초보자처럼 행동한다고 보장할 수는 없습니다. 사람은 낯선 용어가 나오면 검색하거나 동료에게 물어보기도 합니다. 아예 작업을 중단할 수도 있습니다. 실제로 어떤 선택을 하는지는 사용자를 관찰해야 알 수 있습니다.
그래서 AI로 점검할 때는 완료 여부와 함께 문서 밖에서 보충한 단계도 살펴봐야 합니다.
돈을 주고 맡길 과제는 작고 구체적으로 정합니다
README를 읽어달라는 부탁만으로는 어디까지 해봐야 하는지 알기 어렵습니다. 유료 테스트를 한다면 참가자에게 무엇을 시도해달라는 건지부터 분명히 정하는 편이 좋습니다.
예를 들어 이렇게 과제를 줄 수 있습니다.
이 README를 보고 설치한 뒤 예제 하나를 실행해주세요. 20분이 지나면 멈춰도 됩니다. 이해되지 않는 표현과 다음 행동을 고민한 지점을 알려주세요.
여기서 20분은 과제를 구체적으로 정하기 위해 든 예시입니다. 실제로 얼마의 시간을 줄지는 설치 난이도와 대상 사용자에 맞춰 정하면 됩니다.
참가자는 문서가 대상으로 삼은 독자와 비슷한 사람이어야 합니다. 비개발자용 도구라면 개발 경험이 많은 사람이 성공했다는 것만으로 쓰기 편한지 판단하기 어렵습니다. 개발자용 라이브러리라면 관련 언어는 알지만 해당 프로젝트는 처음 보는 사람이 적절할 수 있습니다.
보상은 성공 여부와 관계없이 지급하도록 정할 수 있습니다. 실패한 시도에서도 무엇을 고쳐야 할지 알 수 있기 때문입니다.
관찰하는 동안에는 바로 답을 알려주고 싶어도 잠시 기다려야 합니다. 참가자가 어디서 멈췄는지, 왜 도움을 요청했는지부터 기록합니다. 테스트를 이어가려고 설명을 보탰다면 그 내용도 남깁니다. 그때 해준 설명이 바로 README에 빠져 있던 내용일 수 있습니다.
막힌 이유가 꼭 문서에만 있지는 않습니다
테스트에서 문제가 드러났다고 해서 답이 늘 “설명을 더 쓰자”인 것은 아닙니다.
실행 위치를 한 줄 덧붙이거나 지원하는 운영체제를 명확히 적는 것만으로 풀리는 문제도 있습니다. 하지만 설치 단계 자체가 지나치게 복잡하다면 설명을 보충하는 데서 그치지 않고 프로그램의 설치 방식부터 손봐야 할 수도 있습니다.
그래서 “사용자가 이해하지 못했다”는 기록만으로는 부족합니다. 어느 문장을 읽고 어떤 행동을 했는지, 그때 어떤 결과를 예상했는지까지 짚어야 어디를 고칠지 알 수 있습니다.
수정한 뒤에는 해당 절차를 처음 접하는 다른 사람에게 같은 과제를 맡겨볼 수 있습니다. 앞선 참가자는 이미 해결 방법을 배웠으므로, 그 사람에게 다시 맡겨서는 처음 사용할 때의 경험을 확인하기 어렵습니다.
이때 AI로 실행 절차도 점검하면 각각 무엇을 확인할지 분명해집니다. AI로는 명령과 예제가 작동하는지 확인하고, 사람이 직접 해보는 과정에서는 설명을 이해하고 다음 행동을 선택할 수 있는지 살펴보는 겁니다.
AI의 도움으로 문서를 쓰고 검토할 때도 사람이 실제로 따라 할 수 있는지 판단할 기준은 필요합니다. README를 읽고 따라 해볼 사람에게 비용을 지급하는 것도 그 기준을 얻는 한 가지 방법입니다. 처음 온 사람이 설명을 읽고 도움 없이 첫 실행의 성공을 알아보는지까지 확인해볼 수 있습니다.
댓글
댓글을 불러오는 중...