30년 넘게 우리는 그것을 당연하게 여겼다. 오타를 치면 단어 아래 빨간 물결선이 생기고, 문법이 어색하면 초록선이 뜬다. 별도 버튼을 누를 필요도, 저장을 기다릴 필요도 없다. 그냥 거기 있다. 최근 Microsoft 개발 블로그에 올라온 추모 글은 이 너무나 당연한 패턴의 기원을 다시 조명한다. 그 설계를 만든 사람은 Tony Krueger다.
초기 Microsoft Word의 맞춤법 검사는 지금 기준으로 보면 거의 폭력적이었다. 사용자가 직접 실행해야 했고, 실행하면 프로그램이 모든 단어를 처음부터 훑을 때까지 다른 작업을 할 수 없었다. Auto Spell Check가 도입됐을 때도 마찬가지였다. 유휴 상태에서 미리 검사를 해두는 방식이었지만, 결국 사용자가 저장하거나 종료하려는 순간 검사가 시작되며 흐름을 끊었다. 많은 사용자가 이 기능을 아예 꺼버렸다. 피드백이 너무 거슬렸기 때문이다.
Krueger의 통찰은 단순했지만 근본적이었다. '피드백이 필요한 건 맞지만, 사용자를 멈춰 세워야 할 이유는 없다.' 그는 맞춤법 오류를 단어 아래에 즉시 표시하되, 사용자의 다음 입력을 조금도 차단하지 않는 방식을 설계했다. 결과는 오늘날 우리가 아는 그것이다. 빨간 물결선은 거기 있지만 강요하지 않는다. 사용자가 원할 때 처리하면 된다. 이 패턴은 이후 수십 년에 걸쳐 워드프로세서를 넘어 코드 에디터, 브라우저 입력창, 모바일 키보드까지 퍼졌다.
이 설계 원칙이 단순해 보이는 건 이미 너무 깊숙이 내면화됐기 때문이다. 당시 90년대 초반 환경을 생각하면 기술적 난이도는 결코 낮지 않았다. RAM이 4~8MB였던 시절, 영어 단어 목록 전체를 메모리에 올려놓고 실시간으로 비교하면서 렌더링까지 비침투적으로 처리하는 것은 지금의 단순 구현과 달랐다. Windows 95/NT의 선점형 멀티태스킹이 기술적 기반을 마련했고, Krueger는 그 위에서 가장 중요한 UX 판단—'언제 끊을 것인가'가 아니라 '어떻게 끊지 않을 것인가'—을 실행했다.
반세기가 지난 오늘, 같은 문제가 다른 형태로 반복된다. 안드로이드 사용자는 하루 평균 46개의 알림을 받는다. 대부분은 읽히지 않고 사라진다. 수화 앱 Thirsty Bot을 만든 개발자가 dev.to에 공유한 경험은 이 문제의 현재 단면을 잘 보여준다. 2시간마다 고정 간격으로 보내는 알림은 처음엔 무시되고 결국 비활성화된다. 메시지가 획일적이면 일주일이면 읽기를 멈춘다. 이 패턴은 알림이 '노이즈'가 되는 순간 사용자가 취하는 행동이 단계적으로 어떻게 진행되는지를 설명한다. 무시 → 비활성화 → 앱 이탈. 복구하기 어려운 경로다.
이 개발자가 찾은 해법은 Krueger의 철학과 같은 방향을 가리킨다. 사용자가 설정한 활동 시간대 안에서만 알림을 보내고, 40개 이상의 다양한 메시지로 예측 가능성을 낮추며, 음수 로그 직후 즉각적인 시각 피드백을 제공하는 것. 이 중 가장 큰 효과를 낸 건 '알림을 보내지 않는 시간대를 설정한 것'이었다. 앱이 깨우지 않는다는 신뢰가 생기자 사용자는 알림을 끄지 않았다. 피드백의 효과는 빈도가 아니라 타이밍과 신뢰에서 온다.
두 사례가 함께 가리키는 것은 하나다. 좋은 피드백 UX는 사용자에게 선택권을 주면서 흐름을 보존한다. 물결선은 사용자가 오타를 고치고 싶을 때 고칠 수 있게 거기 있지만, 고치지 않아도 글쓰기는 계속된다. 수화 알림은 마시고 싶을 때 마실 수 있게 신호를 보내지만, 쉬는 시간엔 침묵한다. 반대로 나쁜 피드백 UX는 사용자의 현재 맥락을 무시하고 자신의 타이밍을 강요한다. 이것이 알림 피로도와 기능 비활성화의 공통 원인이다.
마이크로 인터랙션 설계에서 이 원칙은 구체적인 판단 기준이 된다. 폼 유효성 검사는 제출 시점이 아닌 입력 완료 시점에, 에러 메시지는 필드를 차단하지 않는 방식으로, 진행 상태 피드백은 사용자 행동을 막지 않는 레이어에서. 이 판단들은 '기술적으로 가능한가'의 문제가 아니라 '사용자의 흐름을 얼마나 존중하는가'의 문제다. Tony Krueger가 30년 전 증명한 것처럼, 가장 오래 살아남는 UI 패턴은 사용자를 멈추지 않는 것들이다.
앞으로 AI가 생성한 인터페이스 코드가 빠르게 늘어날수록, 이 판단은 더 명시적으로 설계되어야 한다. 자동 생성 코드는 기능을 만들지만 타이밍을 판단하지 않는다. 언제 알릴 것인가, 얼마나 오래 보여줄 것인가, 무엇을 조용히 처리할 것인가. 이 결정들은 여전히 설계자의 몫이다. 물결선 하나가 30년을 살아남은 이유는 코드의 정교함이 아니라 그 뒤에 있는 판단의 정확함이었다.