같은 사이트의 모바일 성능 점수를 두 번 쟀습니다. 한 번은 62점, 한 번은 67점이 나왔습니다. 사이트는 그사이 한 글자도 바뀌지 않았습니다.
그 사이트를 진단해 달라는 부탁을 받았다면 어느 점수를 적어야 할까요. 저는 둘 다 적지 않기로 했습니다. 대신 같은 사이트를 두 번, 서로 모르게 진단했습니다. 두 결과가 겹친 곳은 믿고, 갈린 곳은 제가 직접 들여다봤습니다.
이 글은 사이트 진단을 에이전트에게 맡겨도 되는지 확인하려고 하루에 다섯 번 진단을 돌린 기록입니다. 대상은 사이트 세 곳입니다. 제 블로그 한 곳과 다른 회사 사이트 두 곳이고, 다른 회사는 업종만 남기고 이름을 지웠습니다. 회차 번호는 그날 하루 전체에 매긴 순서입니다.
- 1회차: 컨설팅 회사 사이트, 제가 손으로
- 2회차: 교육 기업 사이트, 에이전트(브라우저 있음)
- 3회차: 교육 기업 사이트, 에이전트(브라우저 없음, 2회차 결과를 보지 않음)
- 4회차: 제 블로그, 에이전트(브라우저 없음)가 진단하는 동안 저는 제 작업 창에서 브라우저로 따로 확인
- 5회차: 컨설팅 회사 사이트, 에이전트(1회차 결과를 보지 않음)
여기서 브라우저가 있다는 건 에이전트가 사람처럼 페이지를 화면에 띄워 볼 수 있다는 뜻입니다. 없으면 페이지의 코드만 읽습니다. 성능 점수는 어느 회차든 따로 도는 측정 도구가 재기 때문에, 브라우저가 없어도 점수는 나옵니다.
서로 모르게 돌린 비교는 두 종류였습니다. 하나는 같은 사이트를 사람 손과 에이전트가 따로 진단한 1회차와 5회차입니다. 다른 하나는 같은 사이트를 에이전트에게 도구만 달리 줘서 따로 진단하게 한 2회차와 3회차입니다. 앞의 쌍은 판정이 겹치는지를, 뒤의 쌍은 도구가 판정을 바꾸는지를 보여 줬습니다.
점수표는 이미 무료로 있어서, 사람 손이 도는 자리를 세기로 했습니다
사이트 진단이라고 하면 보통 점수표를 떠올립니다. 성능 몇 점, 접근성 몇 점, 검색 최적화 몇 점. 그런데 그 점수표는 크롬 개발자 도구 안에 들어 있는 Lighthouse(사이트를 재서 점수와 개선 제안을 보여 주는 무료 도구)가 이미 만들어 줍니다. 제가 같은 걸 한 장 더 만들어 드릴 이유가 없었습니다.
제가 만들고 싶었던 건 다른 쪽이었습니다. 고객사와 처음 만나기 전에 그 회사 사이트를 보고, 지금 사람 손으로 돌고 있는 일이 어디인지 세어 두는 것입니다. 문의를 받아서 옮겨 적는 일, 진단 신청에 답장하는 일, 사례를 올리는 일 같은 것들입니다. 에이전트를 붙일 자리는 대개 거기에 있습니다.
흔한 결론도 일단 미뤘습니다. 점수가 낮으면 느린 사이트고, 느리면 사진부터 줄이면 된다는 결론입니다. 틀린 말은 아닌데, 이 결론이 맞는지는 점수 하나로 알 수 없었습니다. 그걸 확인하는 데 하루가 걸렸습니다.
사람 손과 에이전트가 서로 모르고 같은 두 곳을 짚었습니다
1회차는 제가 손으로 했습니다. 컨설팅 회사 사이트를 도구로 재는 데 약 4분, 그 결과를 읽고 판단해 진단서를 쓰는 데 약 25분, 모두 약 29분이 걸렸습니다. 그날 밤 5회차에서 같은 사이트를 에이전트에게 다시 맡겼습니다. 제가 낮에 쓴 진단서는 보지 못하게 했습니다. 에이전트는 재는 데 약 8분, 판단하고 쓰는 데 약 6분, 모두 약 14분이 걸렸습니다. 재는 데 저보다 오래 걸린 건 화면 캡처와 파일 크기 합산까지 그 단계에서 했기 때문입니다.
한 가지 조건이 1회차와 달랐습니다. 5회차 에이전트는 그 사이 4회차에서 제가 새로 만든 규칙 하나를 가지고 있었습니다. 뒤에서 설명할, 무게 순위를 파일 종류별 합계로 정하는 규칙입니다. 파일 무게를 보는 규칙이라 버튼 위치와 문의 방식을 본 1·2순위 판정에는 쓰이지 않았습니다.
1순위와 2순위가 같았습니다. 진단 버튼이 첫 화면에서 세 화면 아래에 흐리게 놓여 있다는 것, 그리고 문의가 메일 앱을 여는 링크뿐이라 메일 앱이 없는 사람은 문의할 수 없다는 것입니다. 표현은 달랐지만 가리키는 자리는 같았습니다. 두 번째는 제가 처음에 세려던 자리이기도 합니다. 메일로 들어온 문의는 누군가 손으로 옮겨 적어야 하니까요.
갈린 곳은 3순위였습니다. 저는 모바일에서 화면의 가장 큰 요소가 뜨기까지 7.0초 걸린다는 점을 적었습니다. 에이전트는 4회차에서 만든 규칙대로 사이트가 내려받는 파일 크기를 종류별로 더해 보고, 외부 서비스에서 불러오는 파일(방문 분석 태그, 공유 버튼 위젯 같은 것)이 전체 784KB 가운데 523KB, 67%를 차지한다는 걸 짚었습니다. 도구가 보여 주는 개선 제안 목록에는 이 합계가 나오지 않습니다. 저는 그 목록을 위에서부터 읽었고, 그래서 못 봤습니다.
도구 하나를 빼자 판정이 바뀌었습니다
교육 기업 사이트에서는 더 이상한 일이 있었습니다. 화면을 자바스크립트로 그리는 사이트였습니다. 2회차에서는 에이전트에게 브라우저를 줬고, 3회차에서는 브라우저 없이 코드만 읽게 했습니다. 3회차는 2회차 결과를 보지 않았습니다.
두 판정이 정면으로 부딪쳤습니다. 브라우저로 화면을 본 2회차는 “첫 화면에 문의 버튼이 없다”고 했습니다. 코드만 읽은 3회차는 “문의 버튼은 있다, 다만 떠 있는 버튼이라 마우스를 올려야 이름이 보인다”고 했습니다.
처음에는 어느 쪽이 틀렸는지 가리려 했습니다. 그런데 둘 다 맞았습니다. 방문자 눈에는 버튼이 없고, 코드에는 버튼이 있습니다. 한쪽만 봤다면 “버튼을 새로 달자”나 “버튼은 이미 있다” 중 하나로 끝났을 겁니다. 두 판정을 겹쳐 놓고 나서야 “있는 버튼을 보이게 하자”가 나왔습니다.
그 뒤로 진단서의 버튼 판정을 두 가지에서 세 가지로 바꿨습니다. 있다, 없다, 그리고 코드에는 있는데 화면에는 안 보인다. 이 쌍에서 쓸모 있었던 건 겹친 곳이 아니라 갈린 곳이었습니다. 갈린 두 판정을 나란히 놓고서야 규칙이 하나 생겼습니다.
사람이 하는 사용성 평가도 원래 혼자 하는 일이 아니었습니다
이 결과를 정리하다가, 제가 새로 알아낸 게 아니라는 걸 알았습니다. 사용성 평가에서 오래 써 온 휴리스틱 평가(정해진 원칙 목록에 비춰 화면을 점검하는 방법)는 처음부터 여러 사람을 전제로 합니다. 닐슨 노먼 그룹은 같은 화면을 3~5명이 각자 따로 평가하라고 권합니다. 아무리 숙련된 사람도 문제 일부를 놓치기 때문이고, 여러 명을 쓰는 목적은 서로 독립된 관찰을 모으는 데 있다고 설명합니다.
성능 점수도 마찬가지입니다. Lighthouse 공식 문서는 점수가 흔들리는 이유를 대부분 조건 변화로 봅니다. 광고, 네트워크 경로, 측정하는 기기 같은 것들입니다. 그래서 점수를 한 숫자가 아니라 분포로 보라고 하고, 다섯 번 재서 가운데 값을 쓰면 한 번 잰 값보다 두 배 안정적이라고 적어 두었습니다.
사람이 평가하던 시절에는 이 권고를 지키기 어려웠습니다. 평가자 다섯 명을 모으는 건 비싸고, 대개는 한 명이 한 번 보고 끝냈습니다. 그래도 티가 잘 나지 않았습니다. 그 한 명이 경험으로 빈자리를 메웠기 때문입니다.
에이전트로 바꾸면 계산이 달라집니다. 두 번째 평가자가 싸집니다. 제가 실제로 한 조합은 손으로 한 번(약 29분), 에이전트로 한 번(약 14분)이었습니다. 두 번째 진단에 더 든 시간이 14분이었던 셈이고, 그중 판단·작성 6분은 추정치입니다. 대신 에이전트는 경험으로 빈자리를 메우지 않습니다. 개선 제안 목록을 받으면 그 목록을 믿고, 브라우저가 없으면 코드가 말하는 대로 믿습니다. 그래서 평가자를 늘리라는 권고가 사람일 때보다 에이전트일 때 더 중요해졌습니다.
막힌 곳: 에이전트도, 1회차의 저도 같은 목록을 믿었습니다
4회차에서 제 블로그를 진단했을 때입니다. 개선 제안 목록 맨 위에는 대표 사진 한 장이 있었습니다. 681KB로, 페이지 전체 전송량의 13.5%입니다. 에이전트는 진단서에 사진부터 줄이자고 1순위로 적었습니다. 1회차의 저도 같은 목록을 위에서부터 읽었으니, 제가 했어도 그렇게 적었을 겁니다.
그랬다면 저와 에이전트의 판정은 겹쳤을 겁니다. 하지만 그 겹침은 맞았다는 증거가 아니라, 같은 목록을 보고 같은 곳에서 함께 틀린 것입니다. 앞에서 믿은 1·2순위는 사정이 달랐습니다. 버튼 위치는 페이지 전체 캡처로, 문의 방식은 페이지 코드에서 입력 폼을 찾아서, 둘이 각자 사이트를 직접 확인한 판정이었습니다. 도구가 요약해 준 목록에서 나온 판정이 아니었습니다. 겹침을 믿으려면 둘 다 같은 요약을 믿은 게 아니라 각자 원본을 봤어야 합니다.
에이전트가 도는 동안 저는 제 작업 창에서 같은 사이트를 브라우저로 따로 열고, 내려받는 파일 크기를 종류별로 더해 봤습니다. 순서가 뒤집혔습니다. 외부 저장소에서 불러오는 글꼴 5개가 3,069KB, 전체의 61.0%였습니다.
개선 제안 목록은 고칠 수 있는 항목을 보여 주는 목록이지, 무게 순위표가 아니었습니다. Lighthouse 결과 파일에는 요청을 종류별로 묶어 전송량을 더한 resource-summary라는 항목이 따로 있습니다. 결과 파일을 열기 번거로우면 크롬 개발자 도구의 네트워크 탭에서 글꼴, 스크립트, 이미지처럼 종류를 하나씩 걸러 보면 됩니다. 탭 아래쪽에 걸러진 파일들의 전송량 합계가 나옵니다.
그 뒤로 무게 1순위는 항상 이 합계로 정하게 바꿨습니다. 5회차에서 외부 서비스 파일 67%를 잡아낸 건 사실 이 규칙이었습니다. 서로 몰랐기 때문이 아니라, 4회차에서 개선 제안 목록과 합계가 갈렸기 때문에 생긴 규칙이 잡은 것입니다.
되돌린 결정: 진단을 따로 떼어 돌리던 방식을 버렸습니다
처음에는 에이전트가 제 작업 폴더를 건드리지 못하게, 진단할 때마다 폴더 전체를 복사해서 그 안에서 돌렸습니다. 안전해 보였습니다. 그런데 첫 실행이 한 줄도 돌지 못하고 멈췄습니다. 복사본이 디스크를 다 채웠기 때문입니다.
생각해 보니 진단은 새 폴더 하나에 결과를 쓰는 일이라, 원래 건드릴 파일이 없었습니다. 복사를 빼고 돌리자 3회차가 13분 남짓에 끝났습니다. 두 번 재려면 한 번이 가벼워야 합니다. 막으려던 위험보다 막는 장치가 더 커서, 두 번째 진단을 돌릴 수조차 없었던 셈입니다.
아직 남은 문제: 다섯 번 재서 가운데 값을 쓰지는 못했습니다
공식 문서가 권하는 대로 다섯 번 재서 가운데 값을 쓰는 건 아직 하지 않았습니다. 지금은 회차를 비교할 때 점수 대신 전송량을 봅니다. 컨설팅 회사 사이트에서 점수는 5점 흔들렸지만 전송량은 두 회차 모두 784KB로 같았습니다. 교육 기업 사이트에서는 점수가 54점과 46점으로 8점까지 흔들렸습니다. 임시방편이지만, 적어도 흔들리는 숫자로 좋아졌다거나 나빠졌다고 말하지는 않게 됐습니다.
시간 기록도 일부는 추정입니다. 5회차의 판단·작성 약 6분과 2회차의 판단·작성 약 20분은 재지 않고 짐작한 값입니다. 에이전트가 쓴 진단서를 제가 검토하는 데 든 시간도 따로 재지 않았습니다. 그리고 서로 모르게 돌린 비교는 두 쌍뿐입니다. 사람 대 에이전트 한 쌍(1회차와 5회차, 5회차만 무게 합산 규칙을 가짐), 도구만 달리 준 에이전트 대 에이전트 한 쌍(2회차와 3회차)입니다. 같은 도구를 준 에이전트를 두 번 돌려 맞대 보는 건 아직 해 보지 않았습니다.
진단서에는 점수 목표를 적지 않았습니다
일부러 넣지 않은 것도 있습니다. 진단서에는 “이걸 고치면 90점이 됩니다” 같은 목표 점수를 적지 않습니다. 한 번에 5점, 8점씩 흔들리는 숫자로 약속을 할 수는 없었습니다. 대신 “고친 뒤 다시 재 보시라”고 적습니다.
사이트를 직접 고치거나 진단서를 대신 보내는 것도 하지 않습니다. 에이전트는 진단서까지 만들고, 보낼지 말지는 사람이 정합니다.
마치며: ‘한 번 잰 점수’가 아니라 ‘따로 두 번 잰 판정’
에이전트에게 진단을 맡겨도 되는지 물었을 때, 제가 해 본 두 쌍에서 얻은 답은 “한 번으로는 부족하고, 따로 두 번이면 쓸 만하다”였습니다. 한 번 잰 결과는 도구와 조건에 따라 흔들립니다. 제가 해 본 두 쌍에서, 각자 사이트를 직접 확인한 판정이 겹친 곳은 믿을 만했고 갈린 곳은 쓸모 있었습니다. 도구가 요약해 준 목록 하나를 둘이 같이 믿었다면 겹쳐도 믿을 수 없습니다. 사람 손과 에이전트가 따로 낸 1·2순위는 그대로 겹쳤습니다. 도구를 달리 준 두 판정은 부딪쳤고, 그 부딪침을 나란히 놓고서야 버튼 판정 규칙이 생겼습니다. 무게를 합계로 보는 규칙도 4회차의 갈림에서 나왔습니다.
에이전트에게 진단을 맡겨도 되는지 물었을 때, 제가 해 본 두 쌍에서 얻은 답은 “한 번으로는 부족하고, 따로 두 번이면 쓸 만하다”였습니다.
오늘 해 볼 만한 게 하나 있습니다. 다음에 무언가를 AI에게 진단하게 할 때, 사람이 한 번 하고 AI에게 한 번 더 시키되 서로의 결과를 보여 주지 마시길 권합니다. 제가 근거를 가진 조합은 여기까지입니다. 가리는 방법은 어렵지 않습니다. 저는 5회차 에이전트에게 사이트 주소와 진단 양식만 주고, 1회차 진단서가 든 폴더는 열지 말라고 지시에 적었습니다. 두 결과를 나란히 놓는 건 둘 다 끝난 뒤에 따로 했습니다. 혼자 일한다면 AI를 먼저 돌려도 되지만, 그 결과는 제 진단을 다 쓸 때까지 열지 않습니다. 가리는 건 양쪽입니다. AI에게 주는 지시문에는 내 결론을 넣지 않고, 내 진단이 끝나기 전에는 AI 결과를 보지 않는 것이 핵심입니다. 두 결과가 겹치는 곳부터 고치고, 갈리는 곳은 사람이 직접 들여다보면 됩니다. 제 경우엔 그 갈린 자리마다 다음 진단에 쓸 규칙이 하나씩 남았습니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- How to Conduct a Heuristic Evaluation (Nielsen Norman Group): https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/
- Lighthouse performance scoring (Chrome for Developers): https://developer.chrome.com/docs/lighthouse/performance/performance-scoring
- Lighthouse Variability (GoogleChrome/lighthouse): https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md