도허티 임계

컴퓨터가 느리던 시절에는 사람이 기다리는 쪽이 당연했습니다. 그 시간을 줄이려면 장비를 더 비싼 것으로 바꿔야 했으니 누구도 기다림을 고칠 거리로 세지 않았고, 2초 안에만 답이 오면 충분하다는 통념이 오래 통했습니다.

그런데 터미널 앞에 앉은 사람을 지켜보면 다른 장면이 보였습니다. 화면이 멈춘 2초 동안 사람은 자기가 다음에 무엇을 하려 했는지를 놓쳤습니다. 항목 하나를 고르려던 사람이 기다리는 사이 옆자리와 이야기를 시작하고, 돌아와서는 화면을 다시 훑었습니다. 기계는 2초를 썼는데 사람은 그보다 긴 시간을 잃은 셈입니다.

1982년 IBM 의 월터 도허티와 아빈드 타다니는 응답 시간과 작업량의 관계를 실제로 쟀습니다. 응답이 2초에서 0.4초로 줄자 같은 사람이 같은 시간에 처리하는 작업 건수가 눈에 띄게 늘었고, 늘어난 폭이 응답 시간이 줄어든 비율보다 컸습니다. 기계가 빨라진 만큼만 사람이 빨라진 것이 아니라, 기다림이 사라지자 일하는 방식 자체가 바뀐 것입니다. 이 0.4초가 두 사람의 이름을 따 도허티 임계로 굳었습니다.

조작한 시점부터 화면이 눈에 띄게 달라지는 시점까지의 간격을 재고, 그 값이 400밀리초, 곧 0.4초 아래인지를 봅니다. 여기서 재는 것은 서버가 일을 끝낸 시각이 아니라 사람이 변화를 알아챈 시각입니다. 서버가 0.2초 만에 답을 돌려줬어도 화면이 다시 그려지기까지 0.5초가 더 걸렸다면 사람이 겪은 값은 0.7초입니다.

0.4초라는 값은 사람의 주의가 버티는 길이에서 나옵니다. 조작과 반응 사이가 짧으면 방금 무엇을 눌렀는지가 머릿속에 그대로 남아 있어 다음 동작을 바로 잇습니다. 간격이 길어지면 그 기억이 흐려지고, 결과를 받은 뒤에 자기가 무엇을 하려 했는지 되짚는 데 시간을 한 번 더 씁니다.

체감은 구간마다 다릅니다.

1. 0.1초 이하 — 자기 손이 직접 움직인 것처럼 느낍니다. 글자를 치면 그 자리에 뜨고 스위치를 올리면 켜지는 정도의 즉각성입니다.
2. 0.4초 안팎 — 기다렸다는 느낌은 있지만 하던 생각은 이어집니다. 도허티 임계가 가리키는 자리입니다.
3. 1초를 넘김 — 흐름이 끊깁니다. 사람이 화면을 의식하기 시작하고 지금 되고 있는 것인지를 묻습니다.
4. 10초를 넘김 — 다른 일을 하러 갑니다. 창을 바꾸거나 휴대폰을 집습니다.

페이지덱에서도 같은 구간이 그대로 나타났습니다. 문서 목록을 태그로 걸러 내는 기능의 응답이 평균 0.9초였는데, 사용자는 태그를 누른 뒤 아무 일도 일어나지 않았다고 보고 한 번 더 눌렀습니다. 같은 요청이 두 번 나가면서 실제로는 더 느려졌습니다.

이 기준은 결과가 바로 올 것으로 기대하는 조작에만 걸립니다. 버튼을 누르거나 항목을 고르는 일이 그렇고, 문서 100건을 내보내는 것처럼 처음부터 오래 걸릴 줄 알고 시작한 작업에는 다른 잣대가 붙습니다.

화면의 반응 속도를 두고 무엇을 고칠지 정할 때 씁니다. 손대는 방향은 셋입니다. 실제로 빠르게 만드는 쪽, 빠르게 보이게 만드는 쪽, 기다림을 설명하는 쪽입니다.

1. 실제로 줄이기 — 한 번에 받아 오는 양을 줄이고, 같은 요청의 결과를 잠시 보관해 두고 다시 쓰고, 자주 쓰는 목록은 미리 받아 둡니다. 0.9초짜리 태그 필터가 0.3초로 내려가면 뒤의 두 방법은 꺼낼 일이 없습니다.
2. 끝난 것처럼 먼저 보여 주기 — 옵티미스틱 UI 가 이 자리에 들어갑니다. 서버의 답을 기다리지 않고 성공을 가정해 화면을 먼저 바꾸는 방식입니다. 즐겨찾기를 누르면 별이 즉시 차고, 서버가 실패로 답하면 그때 되돌립니다. 열에 아홉 이상 성공하는 조작에만 씁니다.
3. 기다림을 설명하기 — 로딩 상태와 스켈레톤 UI 가 여기 해당합니다. 스켈레톤은 내용이 들어올 자리를 회색 뼈대로 먼저 그려 두는 방식입니다. 걸리는 시간은 그대로지만 사람이 화면이 멈췄다고 보지 않습니다. 1초 남짓까지 통하고, 그보다 길어지면 진행률처럼 끝을 가늠할 정보가 있어야 합니다.

피드백의 속도 기준으로도 씁니다. 피드백은 조작에 대한 반응을 그 자리에서 알려 주는 것을 가리키는 말인데, 그 자리가 얼마나 빨라야 하는지를 이 기준이 정합니다. 버튼을 눌렀을 때 눌린 모양으로 바뀌는 마이크로 인터랙션이 0.4초 안에 들어가는 이유도 같습니다. 뒤따르는 저장이 2초 걸리더라도 눌렸다는 사실만은 즉시 알려 줍니다.

"이거 누르고 반응 오기까지 0.9초 걸려요. 도허티 임계를 한참 넘습니다."

느리다는 인상 대신 잰 값을 근거로 이 화면을 고치자고 말하는 것입니다.

"서버 쪽을 지금 더 못 줄이면 스켈레톤이라도 넣죠."

실제 시간을 줄이는 길이 막혔으니 기다림을 설명하는 쪽으로 가자는 제안입니다.

"저장은 오래 걸려도 되는데 눌렸다는 표시는 바로 나와야 해요."

작업 전체와 첫 반응을 나눠 보자는 말입니다. 0.4초가 걸리는 쪽은 첫 반응입니다.

페이지덱에서는 민서가 시안을 넘길 때 이 숫자가 나옵니다. 조작마다 눌린 직후에 바뀌는 것과 서버 답을 받고 바뀌는 것을 따로 적어 두면, 태오가 앞쪽을 지킬 수 있는지 먼저 답하고 뒤쪽이 1초를 넘길 것 같으면 그 자리에 무엇을 띄울지 둘이 정합니다.

0.4초를 서버 응답 목표로 읽는 경우가 가장 많습니다. 개발 쪽에서 평소 재는 값이 서버가 답을 돌려주기까지의 시간이라 그렇게 옮겨 읽기 쉽습니다. 하지만 이 기준이 가리키는 값은 사람이 겪은 시간이고, 거기에는 네트워크를 오가는 시간과 화면을 다시 그리는 시간이 함께 들어갑니다. 서버 200밀리초를 목표로 잡고 달성했다고 적어 두면, 사용자가 1초 가까이 기다리는 화면이 지표상으로는 통과한 상태로 남습니다.

모든 작업을 0.4초 안에 끝내야 한다고 읽는 것도 흔합니다. 임계라는 말이 상한처럼 들리니 그렇게 읽힙니다. 이 기준이 요구하는 것은 작업의 완료가 아니라 응답의 시작입니다. 30초 걸리는 내보내기라도 누른 순간 진행 표시가 뜨면 사람은 제품이 반응했다고 여깁니다. 오해를 그대로 두면 팀은 어차피 못 지킬 목표라며 재기를 그만두고, 정작 0.4초 안에 들어갈 수 있었던 작은 조작들이 방치됩니다.