AI가 느리게 느껴지는 문제를 모델 성능 탓으로 돌리지 말고 1982년의 '도허티 임계값' 400밀리초를 설계 기준으로 삼으라는 글이다. 컴퓨터와 사용자가 서로 기다리지 않는 400ms 아래에서 생산성이 오른다는 원칙을 AI 시대에 다시 적용한다. 해법은 더 싼 추론이 아니라 약 일주일의 프런트엔드 작업과 '완료'의 정의를 바꾸는 것이라고 본다.
AI 기능을 쓰다 보면 응답이 느리다는 불만이 나오고, 흔히 그 원인을 모델 성능이나 추론 비용으로 돌린다. 이 글은 그 전에 인터랙션 설계부터 보라고 말한다.
근거로 든 것이 1982년 제시된 도허티 임계값이다. 컴퓨터와 사용자가 400밀리초 아래에서 주고받을 때 어느 쪽도 상대를 기다리지 않아 작업이 흐르듯 느껴지고 생산성이 오른다는 기준이다. 글은 이 오래된 원칙이 LLM 응답처럼 실제로는 느릴 수밖에 없는 작업에도 여전히 적용된다고 본다. 즉 실제 연산을 빠르게 만드는 대신, 체감 지연을 설계로 흡수하라는 것이다.
저자는 이 문제의 해법을 '더 싼 추론'이 아니라 약 일주일 분량의 프런트엔드 작업과 '완료'의 정의를 바꾸는 일로 규정한다. 디자이너에게는 스트리밍 출력, 스켈레톤·진행 표시, 낙관적 업데이트 같은 대기 경험 패턴을 응답 지연을 전제로 설계하는 몫이 돌아간다.