인터페이스에서 마우스를 올리면 설명이 뜨는 툴팁은 흔하지만, 잘 만든 툴팁과 그냥 동작하는 툴팁 사이에는 사용자가 말로 설명하기 어려운 미묘한 차이가 있다. FrontPrep이라는 면접 문제 서비스를 만드는 개발자가 겪은 사례가 그 차이를 잘 보여준다. 이 서비스는 면접 문제 옆에 회사 로고를 띄우고, 로고에 마우스를 올리면 회사 이름을 툴팁으로 보여준다. 문제는 지연 시간을 0으로 설정해 두었더니, 커서를 화면 위로 스쳐 지나가기만 해도 지나가는 경로의 모든 로고에서 툴팁이 순간순간 튀어나왔다는 점이다. 의도하지 않은 시각적 소음이 계속 발생한 것이다.
지연을 넣으니 생긴 새로운 문제
가장 단순한 해결책은 200밀리초의 지연을 두는 것이다. 커서가 로고 위에 잠깐이라도 머물러야 툴팁이 뜨게 하면, 그냥 스쳐 지나가는 동작으로는 툴팁이 열리지 않는다. 실제로 이 방법으로 원래의 문제는 사라졌다. 그러나 곧바로 다른 문제가 생겼다. 같은 면접 문제를 여러 회사가 물어보는 경우, 한 줄에 로고 여러 개가 나란히 붙어 있다. 사용자가 이 로고들을 옆으로 훑어보며 이름을 확인하려 하면, 로고를 옮길 때마다 매번 200밀리초를 다시 기다려야 했다. 하나하나 확인하는 흐름이 뚝뚝 끊겨 답답하게 느껴진 것이다. 즉 지연은 '실수로 여는 것'을 막는 데는 좋지만, '의도적으로 연달아 보는 것'에는 방해가 된다.
페이지가 따뜻한지 물어보는 방식
저자가 택한 해법의 핵심은 페이지에 '따뜻함(warm)'이라는 상태를 두는 것이다. 로고에 커서가 들어오면 컴포넌트는 먼저 페이지가 따뜻한지 묻는다. 따뜻하면 지연 없이 즉시 툴팁을 연다. 차가우면 200밀리초 타이머를 시작하고 기다린다. 커서가 로고를 50밀리초 만에 스쳐 지나가면 타이머가 아직 도는 중이므로, 커서가 빠져나갈 때 타이머를 취소해 툴팁은 아예 열리지 않는다. 반대로 커서가 충분히 머물러 툴팁이 한 번 열렸다가 닫히면, 이때 공용 상태를 관리하는 프로바이더가 300밀리초짜리 쿨다운 타이머를 시작한다. 이 쿨다운이 끝나기 전에 다음 로고로 넘어가면 그 툴팁은 곧바로 열린다. 새 툴팁이 열릴 때마다 이전 툴팁이 걸어둔 쿨다운을 취소하는 구조라, 로고 사이를 계속 옮겨 다니는 동안에는 페이지가 계속 따뜻하게 유지된다.
결과적으로 사용자가 처음 한 곳에 관심을 두는 순간에는 지연이 작동해 오작동을 막고, 일단 관심을 보인 뒤 이웃한 항목들을 둘러볼 때는 지연이 사라져 즉각 반응한다. 여기에 더해, 따뜻한 상태에서 열리는 툴팁은 등장 애니메이션까지 건너뛴다. 즉시성을 나타내는 플래그를 데이터 속성으로 넘겨 CSS가 진입 애니메이션을 생략하도록 했기 때문이다. 이 덕분에 연속해서 항목을 살필 때는 애니메이션 대기 없이 딱딱 붙어 반응하는 느낌을 준다.
구현에서 눈여겨볼 실무 포인트
기술적으로 주목할 부분은 따뜻함 상태를 리액트 state가 아니라 ref로 관리했다는 점이다. 이 값이 바뀔 때마다 페이지의 모든 툴팁을 다시 렌더링할 필요가 없고, 실제로 이 값은 이벤트 핸들러 안에서만 읽히기 때문이다. 불필요한 리렌더링을 피하려는 전형적인 최적화다. 지연 시간의 숫자 자체도 근거가 있다. 저자의 경험상 150밀리초보다 짧으면 커서가 트리거를 지나가기만 해도 대부분 툴팁이 열려버리고, 250밀리초보다 길면 반응이 굼뜨고 고장 난 것처럼 느껴진다. 그 사이에서 200밀리초가 균형점이었다는 것이다. 다만 이 값은 로고를 훑어보는 특정 인터페이스에 맞춘 것이므로, 다른 맥락에서는 각자 검증이 필요하다.
이 패턴은 사실 새로운 발명이 아니라 브라우저 툴바를 비롯한 여러 곳에서 이미 쓰이고 있다. 처음 하나를 열 때는 뜸을 들이지만, 인접한 메뉴로 옮겨갈 때는 즉시 열리는 경험을 떠올리면 된다. 문제는 많은 개발자가 이 동작을 당연하게 누리면서도 그 안에 이런 설계가 들어 있다는 사실을 인지하지 못한다는 점이다. 그래서 직접 툴팁을 만들 때는 이 두 번째 동작을 빼먹고, 단순한 고정 지연만 넣어 답답한 경험을 만들곤 한다.
저자는 이 대목에서 AI 도구와 인간의 판단에 대한 이야기로 마무리한다. AI에게 툴팁을 만들라고 하면 동작하는 툴팁은 잘 만들어 주지만, 그것이 잘 다듬어진 결과물인지 최종적으로 판단하는 것은 결국 사람의 몫이다. 동작하는 것과 완성도 있는 것을 가르는 세부는 수년간의 경험과 실수, 연습에서 나오는 안목에서 비롯된다. 다만 색상, 접근성, 폼, 애니메이션, 타이포그래피처럼 다른 엔지니어나 디자이너의 안목이 담긴 스킬을 빌려 쓰면 그 감각을 앞당겨 배울 수 있다. 저자 역시 자신이 겪은 이 문제를 코드베이스에서 점검하도록 돕는 클로드 스킬을 만들어 공유했는데, 각 코드베이스마다 툴팁 라이브러리와 구현 방식이 다르더라도 적용할 수 있도록 설계했다고 밝혔다. 결국 도구가 초안을 만들어 주더라도, 자신의 기준에 맞는지 판단하고 출시 여부를 결정하는 사람은 여전히 개발자 자신이라는 메시지다.