치지직 PiP로 보는 웹 인터페이스의 조작 경험
이번 월드컵을 보기 위해 치지직을 켜두고 있다가, 웹서비스가 피해야 할 사용자 경험의 실수를 보게 됐다. 우선 아래 영상을 보고 무엇이 문제인지 생각해보자.
치지직은 스트리밍 서비스이고 같은 내용이라도 여러 사람이 중계할 수 있는 구조이기 때문에, 영상을 보는 중에 다른 방송들을 살펴볼 수 있는 PiP 기능을 제공한다. 화면에는 경기 영상이 PiP 형태로 떠 있고, 사용자는 그 주변의 화면을 클릭하거나 PiP의 위치를 옮길 수 있다. 얼핏 보면 별다른 문제가 없어 보일 수 있지만, 실제로 사용해보면 사용자가 기대하는 동작과 서비스가 실제로 처리하는 동작 사이에 꽤 불편한 차이가 있다. 문제는 크게 두 가지다.
첫 번째 문제는 PiP 화면을 드래그해서 이동할 수 있는데도, 그것이 이동 가능한 영역이라는 시각적 힌트가 전혀 없다는 점이다. 웹에서 어떤 요소를 드래그할 수 있다면 보통 마우스 커서가 바뀌거나, 손잡이처럼 보이는 영역이 생기는 등 사용자가 조작 가능성을 추측할 수 있는 단서가 제공된다. 이를 흔히 어포던스를 제공한다고 말한다. 그런데 치지직의 PiP는 화면 위에 마우스를 올려도 커서 모양이 바뀌지 않는다. 실제로는 드래그가 되지만, 사용자는 그 기능이 있다는 사실을 우연히 발견하기 전까지 알기 어렵다.
이건 사실 그리 큰 문제는 아니다. 구현된 기능을 사용자에게 제대로 제공하지 못한다는 점에서 아쉽다는 정도다. PiP의 위치를 옮기는 기능은 꽤 유용하다. 하지만 기능이 있다는 신호가 없으면 그 기능은 아는 사람만 쓰는 숨겨진 기능이 된다. 물론 이 선택을 완전히 이해하지 못하는 것은 아니다. 서비스 입장에서는 PiP 위치를 옮기는 기능을 적극적으로 드러내고 싶지 않았을 수도 있고, 영상 위에서 커서가 바뀌는 일이 시각적 노이즈라고 판단했을 수도 있다. 그래서 이 문제는 불편하지만, 어느 정도는 의도적인 기획 선택으로 받아들일 수 있다.
두 번째 문제는 첫 번째 문제보다 더 심각하다. PiP 영상 위 투명한 영역을 클릭했을 때 사용자의 의도와 다르게 동작한다는 점이다. 화면상으로는 아무것도 없는 배경처럼 보이는 영역이지만, 실제로 클릭해보면 뒤에 있는 화면이 클릭되지 않고 PiP를 드래그하는 것과 같은 방식으로 처리된다. 사용자는 눈에 보이는 대로 "비어 있는 공간"을 클릭했다고 생각하지만, 브라우저와 DOM 입장에서는 그곳이 PiP 컴포넌트의 사각형 영역 안에 포함되어 있는 "배경이 투명한 공간"이다. 결과적으로 사용자는 클릭할 수 있어야 한다고 느끼는 영역을 클릭하지 못한다.
첫 번째 문제는 기능을 발견하기 어렵게 만들 뿐이라 사용자 경험에 마이너스가 되지는 않는다. 하지만 두 번째 문제는 사용자가 하려던 조작을 직접 방해한다. 사용자는 웹의 DOM이 사각형 박스로 구성되어 있다는 사실에 관심이 없다. 컨트롤러 영역과 영상 영역이 같은 박스로 묶여 있고, 투명하게 보이는 부분도 실제로는 이벤트를 받는 영역이라는 내부 구현 사정은 사용자에게 아무 의미가 없다. 사용자가 보는 것은 화면이고, 사용자가 기대하는 것은 보이는 대상에 맞는 조작이다. 사용자가 경험한 것은 클릭할 수 있는 링크를 눌렀는데 아무 동작도 하지 않았다는 것이다. 예상한 동작을 하지 않으면 사용자는 일단 불편함을 느낀다.
더 나쁜 점은 사용자가 이 문제를 피하기 위해 불필요한 학습을 해야 한다는 것이다. 사용자는 특정 영역을 클릭하려면 먼저 PiP를 다른 곳으로 옮겨야 한다는 사실을 배워야 한다. 하지만 이 학습은 서비스의 핵심 가치를 이해하기 위한 학습이 아니다. 그냥 잘못 설계된 인터페이스를 피해가기 위한 학습이다. 좋은 인터페이스는 사용자가 이런 우회 방법을 익히도록 만들지 않는다. 사용자가 눈으로 본 구조와 실제 조작 가능한 구조가 최대한 일치하도록 만드는 것이 기본이다.
처음에는 이 문제가 모바일 퍼스트 개발 과정에서 생긴 부작용이 아닐까 의심했다. 모바일 화면을 우선해서 개발하면 마우스 커서나 호버 상태 같은 데스크톱 환경의 세부 처리는 뒤로 밀리기 쉽다. 또한, 터치 환경에서는 클릭 가능한 영역을 너무 세밀하게 나누는 것이 오히려 사용성을 해칠 수 있기 때문에, 보이지 않는 여백까지 넓게 터치 영역으로 잡는 선택이 합리적일 때도 있다.
하지만 테스트해본 결과 치지직은 데스크톱 브라우저와 모바일 브라우저를 명시적으로 구분해 다른 기능을 제공하고 있었다. User agent를 바꿔 확인해보면 이번에 문제가 된 PiP 기능은 데스크톱 브라우저에서만 제공되고, 모바일 브라우저에서는 제공되지 않는다. 따라서 이 PiP는 모바일 화면을 우선하여 개발된 기능이 아니라, 데스크톱 사용자를 위해 별도로 제공된 기능이다. 그렇다면 이 문제는 환경 전환 과정의 부작용이라기보다, 데스크톱 전용 기능인데도 데스크톱의 표준 인터페이스인 마우스 조작과 동작에 대한 기대값이 충분히 설계되거나 테스트되지 않아 발생한 문제에 가깝다.
2026년 7월 1일 기준으로, 다른 서비스들은 이 문제를 각자 다른 방식으로 피하고 있다.
YouTube는 불필요한 투명 여백 없이 PiP 영역 전체를 비디오 영역으로 채우는 사각형으로 구현해 투명한 클릭 영역 문제가 생길 여지를 없앴다. 흥미로운 점은 YouTube도 PiP 위에 마우스를 올렸을 때 커서 모양을 바꾸지는 않는다는 것이다. 다만 드래그하는 동안에는 커서가 바뀐다. YouTube의 PiP는 창의 네 모서리에만 위치할 수 있고, 충분히 드래그하지 않으면 원래 자리로 돌아간다. 그래서 드래그 중 커서 변화는 "이 요소는 움직일 수 있고, 지금 이동 조작이 진행 중이다"라는 신호를 주는 역할을 한다. 화면 위에서 처음부터 커서가 바뀌지 않는 점은 여전히 아쉽다. 하지만 크기를 변경할 수 있는 경계에서는 커서가 바뀌는 것을 보면 의도적인 선택으로 보인다.
![]() |
| PiP창에 커서를 올려도 모양이 변하지 않는다 |
![]() |
| 하지만 창 이동 중에는 커서가 변한다 |
![]() |
| PiP 창 경계에 마우스를 올리면 커서가 변한다 |
Twitch는 더 단순한 선택을 했다. YouTube와 마찬가지로 PiP 영역을 투명한 영역 없는 사각형으로 만들었지만, PiP 창을 사용자가 옮길 수 없게 했다. PiP 영역이 사각형이기 때문에 투명한 영역이 생길 일이 없고, 사용자가 움직일 수 없는 요소이기 때문에 드래그 가능성을 알려줄 필요가 없다. 기능을 줄인 만큼 인터페이스의 애매함도 줄어든다.
![]() |
| Twitch PiP는 움직일 수 없다. |
TikTok과 SOOP은 직접 PiP UI를 구현하지 않고 브라우저의 API를 사용한다. 이 방식에서는 브라우저가 제공하는 PiP 경험에 기대게 된다. 서비스가 직접 세밀한 UI를 통제하기는 어렵지만, 반대로 서비스가 잘못 만든 투명 영역이나 드래그 처리 때문에 사용자를 헷갈리게 만들 가능성도 줄어든다. 다만 둘의 구현에는 차이가 있다. SOOP은 Picture-in-Picture API를 사용하는 반면, TikTok은 비교적 새로 추가된 Document Picture-in-Picture API를 사용한다. 덕분에 TikTok은 단순한 비디오 요소만 띄우는 것이 아니라 UI를 더 구성할 수 있지만, Safari 브라우저에서는 PiP를 실행할 수 없다.
![]() |
![]() |
| TikTok Floating Player | |
또 다른 스트리밍 서비스인 Kick이라는 스트리밍 서비스는 또 다른 방식으로 문제를 해결한다. Kick은 PiP에 일종의 툴바를 보여주고, 사용자가 그 툴바를 드래그할 때만 PiP를 이동할 수 있게 한다. 그리고 툴바가 이동 조작을 담당한다는 신호를 커서 모양으로 보여준다. 움직일 수 있는 영역과 움직일 수 없는 영역을 명확히 나누고, 조작 가능한 곳에는 조작 가능하다는 표시를 제공하는 방식이다. 특히 움직일 수 있는 영역을 애플리케이션의 툴바와 유사하게 구성하였다. PC 사용자는 툴바를 잡고 창을 옮기는 패턴에 익숙하기 때문에, 이 조작을 쉽게 예측할 수 있다.
![]() |
| Kick PiP는 툴바를 드래그해야만 움직일 수 있다 |
![]() |
| 툴바 이외의 화면은 드래그해도 이동할 수 없다는 것을 커서 모양으로 표현한다. |
이 중 어떤 서비스의 해결책이 가장 우월하다고 말할 생각은 없다. 전부 데스크톱 웹 사이트를 사용하는 사용자가 어떤 경험을 할지 고민하여 나온 디자인이다. 해결책은 모두 다르지만 사용자가 조작 가능한 영역을 예측할 수 있는 디자인이다. 이들 모두 사용자가 보는 영역과 조작 가능한 영역이 일치한다. 웹을 만드는 사람은 DOM, 박스 모델, 이벤트 버블링, 포인터 이벤트 같은 개념을 알고 있다. 하지만 사용자는 그런 구조를 보지 않는다. 사용자는 영상이 어디에 떠 있는지, 버튼이 어디에 보이는지, 비어 있는 공간에 어떤 컨텐츠가 있는지를 본다. 따라서 인터페이스는 내부 구현의 모양이 아니라 사용자가 인식하는 화면의 모양을 기준으로 설계되어야 한다.
어떤 방식으로 이 문제를 해결할지는 결국 서비스를 만드는 사람의 선택이다. PiP를 YouTube나 Twitch처럼 투명한 영역이 생기지 않도록 만들 수도 있고, Kick처럼 이동 가능한 툴바를 별도로 둘 수도 있다. 아니면 브라우저의 PiP API에 맡길 수도 있다. 치지직처럼 직접 구현한 PiP 위에 컨트롤러를 얹는 형태가 사용성에 도움이 된다고 생각된다면, 이 디자인을 유지하면서 투명 영역이 클릭을 가로채는 문제만 없애는 방법도 있다. 이 예제를 확인해보자.
이 예제는 어떤 영역이 클릭을 가로채는지 확인하기 위해 배경을 클릭하면 색이 바뀌도록 만들었다. 왼쪽 붉은 정사면체를 그리는 캔버스는 치지직과 마찬가지로 컨트롤러 옆 빈 공간이 투명한 영역을 차지하고 있어 배경 클릭이 전달되지 않는다. 하지만 오른쪽 푸른색 정사면체를 그리는 캔버스는 컨트롤러 왼쪽 영역이 실제로 빈 공간이다. 이 예시는 컨트롤러를 캔버스 위치에 겹치게 두고 CSS의 transform 프로퍼티를 이용해 위치를 바꾼 것이다. 이렇게 하면 화면상으로는 PiP 위에 컨트롤러가 붙어 있는 것처럼 보이지만, 부모 컴포넌트의 실제 사각형 영역은 투명한 여백을 포함하지 않는다. 이 구현이 정답이라는 뜻은 아니다. 더 좋은 해결책이 있을 수도 있다. 구현 방식을 설명하기보다는, 사용자가 빈 공간이라고 인식하는 영역을 실제로 빈 공간으로 취급하도록 만드는 일이 어렵지 않다는 것을 보여주고 싶었다.
사실 이런 UX 문제는 큰 문제는 아니다. 평소라면 별 생각 없이 넘겼을만한 이슈다. 작은 UX 문제 하나가 서비스의 성패를 결정하지는 않는다. 서비스가 성공하거나 실패하는 이유는 대체로 더 큰 곳에 있다. 사용자가 원하는 콘텐츠를 제공하는지, 충분한 가치를 주는지, 다른 대안보다 이 서비스를 써야 할 이유가 있는지가 훨씬 중요하다. PiP의 투명 영역 클릭 문제 하나 때문에 사용자가 바로 서비스를 떠나는 일은 없다.
하지만 이런 작은 좌절감들은 서비스에 대한 사용자의 감정을 서서히 바꾼다. 스티브 크루그는 이처럼 사소한 결함들이 사용자의 호감을 조금씩 깎는 현상을 호감도 저장소가 바닥나는 과정이라고 표현했다. 그리고 저장소가 완전히 바닥났을 때 사용자는 서비스를 떠난다. 잘 만들어진 서비스가 이런 사소한 디테일에 무너지는 것만큼 아쉬운 일도 없다. 사용자의 입장에서 조금만 더 깊이 고민한다면, 이런 아쉬운 상황은 얼마든지 막을 수 있다.








댓글
댓글 쓰기