"처음부터 완벽할 수 없다"는 걸 데이터로 증명한 팀
1996년 ACM에 발표된 논문 하나가 최근 Hacker News에서 다시 화제가 됐습니다. 제목은 Windows 95 User Interface: A Case Study in Usability Engineering. 30년 가까이 된 문서인데, 읽다 보면 솔직히 좀 부끄러워집니다. 지금 우리가 '애자일하게 개발한다'고 말하면서 실제로는 얼마나 사용자 테스트를 체계적으로 운영하고 있는지 되묻게 되거든요.
워터폴을 버리고, 프로토타입을 '살아있는 명세'로 삼다
Windows 95 UI 팀은 디자이너 12명, 개발자 12명 규모였습니다. 지금 기준으로도 작지 않은 팀인데, 이들이 선택한 방식은 문서 기반 명세가 아니라 프로토타입 자체를 명세로 활용하는 것이었습니다. Figma가 없던 시절이니 당연히 코드로 만든 프로토타입이었겠지만, 이 접근 방식은 오늘날 Figma Dev Mode나 Design Token 기반 핸드오프 워크플로우가 지향하는 방향과 본질적으로 같습니다. "이 컴포넌트가 실제로 어떻게 동작해야 하는가"를 문서가 아니라 살아 움직이는 결과물로 공유하는 것.
설계 프로세스는 세 단계로 구조화됐습니다. 탐색(Exploration) → 급속 프로토타이핑(Rapid Prototyping) → 정교화(Fine Tuning). 지금 식으로 말하면 Discovery, Iteration, QA에 해당하는데, 각 단계마다 사용자 테스트 결과가 다음 단계의 입력값이 됐습니다.
Start 메뉴는 처음부터 그 모습이 아니었다
사용자 입장에서는 당연하게 느껴지는 UI가 사실 수십 번의 실패를 거친 결과라는 걸 이 케이스스터디는 여실히 보여줍니다. 초기 탐색 단계에서 팀은 파일 캐비닛(File Cabinet) 은유의 2분할 구조를 시도했는데, 사용자 테스트 결과는 냉혹했습니다. 초보자가 프로그램을 실행하는 데 평균 9.5분 이상 걸렸고, 더블클릭·창 관리·파일 계층 구조를 제대로 이해하지 못했습니다.
여기서 팀이 내린 결단이 흥미롭습니다. 기존 UI와의 일관성보다 사용 빈도 높은 작업의 효율성을 우선하기로 한 것입니다. 초보자 전용 셸(shell) 실험은 학습 전이 문제로 폐기됐지만, 그 과정에서 얻은 단일 클릭·높은 가시성·메뉴 중심 상호작용 개념이 결국 Start 메뉴로 이어졌습니다. 실패한 프로토타입에서 인사이트를 건진 거죠. 이게 진짜 반복 설계입니다.
작업 표시줄(Task Bar)도 마찬가지입니다. 최소화된 창을 '플레이트'로 표시하는 초기안은 테스트에서 실패했고, 모든 작업을 항상 표시하는 현재 방식으로 수렴했습니다. Figma에서 볼 때는 그럴듯했던 아이디어가 실제 사용 맥락에서 무너지는 경험, 저도 한두 번 한 게 아닌데—그 팀은 그걸 데이터로 잡아냈습니다.
699건, 81%—이 숫자가 말하는 것
이 프로젝트에서 가장 인상적인 부분은 문제 추적 시스템(Problem Tracking) 입니다. 관계형 데이터베이스를 구축해서 모든 사용성 문제를 기록하고, 담당자를 배정하고, 해결 상태를 관리했습니다.
- 총 699건의 사용성 진술 수집
- 551건이 실제 문제로 분류
- 심각도 1단계(15%), 2단계(43%), 3단계(42%)로 분류
- 최종 해결률 81%, 부분 해결 8%, 미해결 11%
그리고 미해결 항목은 그냥 묻힌 게 아니라 다음 버전 설계의 출발점 데이터로 이관됐습니다. 이게 진짜 UX 채무 관리입니다. 요즘 말로 하면 백로그 관리와 같은데, 사용성 이슈를 버그처럼 트래킹하고 버전 간 연속성을 유지한 거죠.
정교화 단계의 총괄 실험 결과도 구체적입니다. Windows 3.1 대비 주요 작업 시간이 절반 수준으로 단축됐고, 21개 만족도 항목 중 20개에서 향상이 확인됐습니다. 20명 대상 장기 현장 연구에서는 주요 사용성 결함이 발견되지 않았고, 수정된 건 일부 문구와 도움말뿐이었습니다. 이 정도면 출시 전 QA가 제대로 된 거죠.
지금 우리는 이만큼 하고 있나요
Hacker News 댓글들을 보면 흥미로운 공통된 정서가 읽힙니다. Windows 95, NT4, 2000 시절이 오히려 Microsoft UI의 전성기였다는 것, 그리고 Apple도 Jony Ive 이후 '미관을 위해 기능을 희생하는' 경향이 생겼다는 것. 누군가는 "UX 디자이너들이 지속적인 변화를 만들어야 한다는 강박이 문제"라고 꼬집었는데, 이 말이 뼈를 때렸습니다. 사용자는 익숙해질 기회조차 없이 매번 새로 배워야 하는 UI—마치 누군가 내 집 가구를 몰래 바꿔놓는 기분이라는 비유가 정확합니다.
현대 UI 개발에서 우리가 놓치는 게 바로 이겁니다. 측정 가능한 사용성 지표 없이 디자인을 바꾸는 것. Lighthouse 점수는 챙기면서 실제 사용자가 특정 작업을 완료하는 데 걸리는 시간, 오류율, 만족도는 체계적으로 트래킹하지 않습니다. A/B 테스트를 한다고 해도 클릭률이나 전환율 같은 비즈니스 지표 중심이고, 사용성 자체를 추적하는 데이터베이스를 운영하는 팀은 드뭅니다.
30년 전 방법론이 지금도 유효한 이유
Windows 95 팀이 입증한 건 단순합니다. "처음부터 완벽할 수 없음을 인정하고, 반복을 통해 완성한다." 그리고 그 반복이 의미 있으려면 사용자 테스트 결과를 데이터로 관리하고, 문제를 추적하고, 해결 여부를 검증해야 합니다.
요즘 팀들이 스프린트마다 배포하면서도 사용성이 나아지지 않는 이유 중 하나는, 반복은 하되 측정이 없기 때문입니다. 프로토타입을 만들고 리뷰 미팅을 하는 것과, 실제 사용자가 그 프로토타입 앞에서 어디서 멈추는지를 관찰하는 것은 완전히 다른 일입니다.
로딩 스켈레톤을 넣을지, 버튼 레이블을 어떻게 쓸지, 모달을 쓸지 드로어를 쓸지—이런 결정들이 감이나 디자이너 취향이 아니라 실제 테스트 데이터에서 나와야 합니다. 30년 전 Windows 95 팀이 했던 것처럼요. 그게 지금도 이 논문이 읽힐 가치가 있는 이유입니다.