모든 프레임을 완벽하게

 (tonsky.me)
1P by GN⁺ | ★ favorite | 댓글 2개
  • UI는 사용자가 앱 품질을 판단하는 거의 유일한 표면이며, 어느 순간 스크린샷을 찍어도 화면 상태가 말이 되어야 신뢰가 쌓임
  • 완성도 높은 UI는 개발자가 다듬는 시간을 들였다는 신호가 되고, 코드 품질도 비슷하게 다듬었을 것이라는 합리적 휴리스틱이 됨
  • 실제 기준은 화면 전환 사이 흰색 깜빡임, 부분 로딩, 로딩 중 재배치, 상태 문구 불일치, 부정확한 애니메이션을 없애는 것임
  • 시작과 끝 상태가 좋아도 중간 프레임이 어긋나면 구성요소가 동기화되지 않은 느낌을 만들고, Photos 사례처럼 실제 변화가 없는 전환에서도 거짓 감각을 만들 수 있음
  • 애니메이션은 전환 이해를 도와야 하며, 시작·끝뿐 아니라 그 사이 모든 프레임까지 관리해야 정밀한 도구 같은 UI가 됨

핵심 원칙

  • Wayland의 명시 목표인 “every frame is perfect”는 현대 GPU 스택의 복잡성 속에서 제어권을 되찾으려는 기술적 목표임
  • 같은 원칙은 UI에도 적용되며, 앱의 어느 순간을 스크린샷으로 찍어도 화면이 자연스럽고 일관되어야 함
  • 사용자는 코드를 볼 수 없기 때문에 UI가 앱 품질을 판단하는 유일한 표면이 됨
  • UI가 잘 다듬어져 있으면 개발자가 폴리싱 시간을 들였다는 신호가 되고, 코드도 비슷한 수준으로 다듬었을 것이라는 판단으로 이어짐

실제 기준과 사례

  • 완벽한 프레임을 위해서는 화면 사이 흰색 깜빡임이 없어야 하고, 콘텐츠가 부분적으로 로딩된 상태나 로딩 중 레이아웃 재배치가 없어야 함
  • UI 내부 상태는 일관되어야 하며, 한 부분이 “1 update available”이라고 말할 때 다른 부분이 “Checking for updates...”라고 말하면 안 됨
  • 애니메이션은 자주 잊히며, 시작 상태와 끝 상태가 좋아도 그 사이가 어색하면 중간 스크린샷이 말이 안 되는 프레임이 됨
  • Safari 사례에서는 플레이스홀더 텍스트가 가운데에서 움직이지만 커서는 왼쪽 위치에서 애니메이션되어 두 구성요소가 서로 동기화되지 않은 느낌을 만듦
  • Photos 사례에서는 Crop과 Adjust 모드를 전환할 때 사진은 즉시 제자리로 이동하지만 크롭 테두리는 애니메이션되어, 모드 전환 중 무언가 미묘하게 바뀌는 거짓 느낌을 만듦
  • 검색 UI 사례에서는 전환 이해를 도와야 할 애니메이션이 오히려 돋보기 움직임을 따라가기 어렵게 만듦
  • Youtube 사례에서는 직사각형을 한 위치에서 다른 위치로 옮기는 단순한 작업에서도 이상한 움직임이 생기며, 이유와 관계없이 결과는 완벽하지 않은 프레임이 됨
  • Preview 앱의 확대 애니메이션까지 포함해 핵심은 시작과 끝 상태뿐 아니라 그 사이 모든 순간에도 주의를 기울여야 한다는 점임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 저자가 든 예시 중 일부가 나쁜 애니메이션인 건 맞지만, 글의 전제에는 동의하기 어려움
    컴퓨터 그래픽은 인간 시각 시스템의 특성을 활용하는 분야이고, 움직이는 것과 정지한 것은 다르게 지각됨. 따로 떼어 보면 “틀린” 프레임이 실제 시간 흐름 안에서는 가장 좋아 보일 수도 있음
    영화로 비유하면 빠른 트래킹 샷은 모션 블러 때문에 개별 프레임이 나빠 보일 수 있고, 광각 샷은 왜곡 때문에 사물이 “틀려” 보일 수 있지만, 극장에서 의도한 예술적 효과를 내면 올바른 선택임

    • 처음엔 “Every Frame Perfect”가 움직임에서의 버벅임이나 끊김을 엄격히 피하자는 뜻인 줄 알았고, 그건 전적으로 찬성함. 하지만 영화·영상·3D 기술 관점에서 보면 모션 블러 같은 시간적 아티팩트는 인간 시각 시스템에 가장 “맞게” 보일 뿐 아니라 가장 해석하기 쉬운 형태이기도 함
      올바른 블러를 움직임에 더하면 더 선명하게 느껴지지만, 정지 화면으로 보면 당연히 더 선명하지 않음. 핵심은 올바른 모션 블러가 해당 속도에서 인간이 지각 가능한 움직이는 디테일만큼만 선명하게 보이도록 보장한다는 데 있음. 따라서 정지된 모션 블러 프레임을 선명도나 해석 가능성 기준으로 평가하는 건 잘못됨
      글의 나머지는 구현 세부에는 집중하지만, 애초에 이런 애니메이션 중 일부가 존재해야 하는지 묻는 기회를 놓침. 움직임은 제한적으로 쓰면 좋은 어포던스가 될 수 있지만, 지금은 과용을 넘어 사용자의 시야와 인지 부하를 침범하는 경우도 있음. 디자이너와 PM은 이를 “세련된 현대 UX”의 표식처럼 보지만, 실제 좋은 디자인이 아니라 좋은 디자인을 흉내 내는 유행성 장식으로 퇴화한 면이 있음
    • 이 글은 좋은 사용 사례를 같이 보여줬다면 논지가 더 강해졌을 듯함. 그래도 프레임 하나하나보다 전환의 전체 느낌이 더 중요하다는 데 동의함
      제시된 일부 애니메이션은 분명 개선 가능해 보임. 이런 작은 즐거움을 더 밀어붙이는 데 AI가 꽤 좋게 느껴지는데, 예전에는 우선순위가 낮아 시간을 쓰기 어려웠기 때문임
    • 이 비유는 한 발 더 나간 것 같음. 영화와 달리 UI는 현실을 기록하는 게 아니라 화면의 모든 픽셀이 우리가 배치한 결과라서, 더 가까운 비유는 카툰임. 카툰의 중간동작은 불완전한 프레임이 아니라 실제로는 신중하게 만든 완성도 높은 프레임
      애니메이션 중간 프레임이 조금 “이상하게” 보여도 논리적으로 맞는 것과, 중간 상태가 실제로 말이 안 되고 그저 애니메이션 중에 무슨 일이 일어나는지 신경 쓰지 않은 결과인 것은 다름. 후자라면 차라리 애니메이션을 없애거나 더 단순하게 만드는 편이 낫다고 봄
    • 마지막 Preview 앱 확대 애니메이션은 반대 사례도 보여줌. 저자가 원하는 것처럼 모든 프레임은 따로 보면 완벽하지만, 움직임으로 봐야 문제가 드러남
    • 애니메이션을 프레임 단위로 뜯어봤을 때 항상 일관적이어야 한다는 생각은 별로 설득력 없음. 사용자는 실제로 그렇게 보지 않기 때문임
      UI 완성도를 소프트웨어 품질의 대리 지표로 보는 글의 관점은 좋고, 나쁜 애니메이션을 짚은 것도 맞음. 다만 프레임별 일관성은 애니메이션의 “좋음”을 재는 최선의 잣대는 아님

  • 일부 기기에는 아직 Sonoma가 있는데, 꾸준히 퇴행하고 있다는 말밖에 안 나옴
    저장 대화상자는 조금 흔들리긴 해도 예시처럼 혼란스럽지는 않음. Notes의 버튼은 패널 사이를 완벽하게 매끄럽게 이동함. Safari 바를 반복해서 포커스했다 해제하면 애니메이션이 가끔 깨지지만, 커서는 텍스트와 정확히 타이밍이 맞고 텍스트가 왼쪽으로 이동을 끝낸 뒤에야 페이드인됨. Preview 버그도 최근 문제인 듯하고, 재현되지 않음
    https://streamable.com/kx7op6
    Apple, Sony, IBM 같은 회사들이 아주 작은 디테일에 신경 쓰던 시절이 그리움. 특히 Apple은 iPhone으로 지금의 가치를 얻었는데, 당시 Windows Mobile이나 Symbian PDA와 비교해 특별히 대단한 기능을 한 것은 아니었고 오히려 기능적으로 뒤처진 부분도 있었지만, 몇 분 쓰고 벽에 던지고 싶지는 않은 올터치 기기였음. 지금 이런 애니메이션은 정확히 Windows Mobile과 Symbian 느낌을 다시 불러옴
    Steve가 OS X 애니메이션을 얼마나 좋아했는지 기억남. 무대에서 여러 번, 슬로모션으로 다시 재생하곤 했음. 지금의 것들은 iPhone 4 안테나 담당자가 겪은 운명을 만든 사람들에게 안겨도 이상하지 않을 수준임

    • 짧은 영상 속 애니메이션은 실제로 더 질서 있고 덜 혼란스러워 보임. Apple이 Sonoma에서는 AppKit을 쓰다가 지금은 SwiftUI로 바꾼 걸 수도 있겠음

  • 이런 불완전한 프레임이 없는 UI가 더 좋게 느껴질 것 같긴 한데, 이제는 누군가 각 클립을 고쳐서 실제로 어떻게 보일지 보여줬으면 함
    동시에 왜 모든 것에 움직임이 필요한지도 의문임. 이해하기로는 움직임은 토스트처럼 사용자가 동작을 시작한 위치와 다른 영역에서 UI가 미묘하게 바뀔 때 쓰는 게 맞음
    여기 나온 전환 중 상당수는 불필요해 보이고, 즉시 바뀌면서 즉각적인 재배치가 일어나도 충분히 좋게 느껴질 듯함

    • Safari 검색창의 “불완전한 프레임”은 실용적으로는 괜찮고, 스크린샷에서 더 좋아 보이게 만드는 방식은 오히려 나쁠 수 있음
      커서가 왼쪽에 나타나는 이유는 사용자가 실제로 그 지점에서 입력을 시작하기 때문임. UI를 아는 사람이라면 아마 거기를 볼 것임. 커서를 화면 가운데에 나타나게 했다가 이동시키는 건 불필요하고 산만함
      자리표시 텍스트가 왼쪽으로 미끄러지는 건 익숙하지 않은 사용자의 주의를 끌기 위한 것임
    • 슬롯머신은 항상 뭔가 움직여야 하고, 과도하게 역동적인 Apple 애니메이션도 그 역할을 함. 일반 UI 애니메이션은 화면 내용이 갑자기 바뀌면 힘들어하는 일반 사용자에게 도움이 되고, 프레임률을 부드럽게 보이게 하거나 API 호출·백엔드 처리 지연을 숨기는 데도 도움됨
    • UI가 좋은 게임을 해보면 애니메이션이 어디에나 쓰이는 걸 볼 수 있음. 즉시 전환은 이론상으로만 좋음
    • 모든 것에 움직임이 필요하진 않음. 대부분은 필요 없음. 이런 허튼 작업이 몇 명의 일자리를 만들고, 또 몇 명이 $BRAND의 디자인 언어가 대안보다 우월하다고 으스댈 명분을 줌
      예시 대부분은 애니메이션이 없다면 더 좋게 느껴질 가능성이 큼. 버튼을 눌렀으면 결과를 보여주면 됨. 춤을 춘 다음 보여주지 말고 그냥 보여줬으면 함
    • 전환 뒤 방향감 회복에는 움직임이 중요함
      움직임이 없으면 새로고침 때마다 뇌가 페이지 전체를 다시 훑어야 하는 경우가 많음

  • 이 글의 논증은 약하게 제시됐다고 봄. 더 나은 대안도 없고, 제시된 것들이 사용자에게 왜 부정적인지도 실제로 설명하지 않음. 부정적일 수는 있지만, 미디어의 스미어 프레임이나 전환 지점을 가리키며 비판하는 공허한 방식과 비슷함
    “모든 프레임이 말이 돼야 한다”는 기준도 감당하기 어려움. 불가능하다고 보고, 창 크기 조절 중에도 모든 프레임을 완벽하게 유지하려면 어떻게 할지 묻고 싶음
    저자 본인도 자신이 말한 기준을 실천하기보다 결함 있는 프레임을 지적하는 쪽이 쉬워 보임. 블로그의 헤더 링크를 눌러보면 클릭이 끝난 뒤 애니메이션이 재생됨. 본인의 UI 프로젝트를 보면 텍스트와 객체가 컨테이너 안에 머물지 않는 곳도 있음. 이런 원칙을 따라야 한다고 말한다면 스스로 보여줄 수도 있어야 함
    더 제대로 쓴 글이라면, 제시한 것들이 최종 사용자에게 왜 나쁜지와 대신 어떻게 처리할지에 집중했을 것임. 좋은 비판은 “무엇”뿐 아니라 왜와 어떻게까지 포함해야 함

    • 이 비판이 오히려 여기서 가장 공허해 보임
      글은 해결책이 아니라 아이디어를 제시하고 있음. 그걸 보지 못하고 여러 허수아비 논증을 세워 비판한 셈임
      더 중요한 건 글이 단정적으로 쓰이지 않았다는 점임. “I think”, “Next thought:”, “Probably”, “So yeah.”처럼 조심스럽게 쓰였음. 이 글은 한 사람이 자기 생각을 공유한 것이고, 여러 합리적인 사람이 비슷한 방향으로 생각하게 만들 만큼 꽤 완성된 생각임
      저자가 해결책을 제시하지 않았다고 해서 반드시 그래야 할 이유는 없음. 그런 기준은 이상하고 불합리함
      저자의 사이트를 공격하는 것도 별로 좋게 보이지 않음. 취향의 격차는 잘 알려져 있고, 개념적 기여가 실제 기술보다 앞선다는 이유로 벌주는 건 꽤 불쾌함
      더 제대로 된 비판이라면 이 커뮤니티의 정신에 맞게 더 관대했을 것임

  • 저자가 해결 예시를 포함했으면 좋겠다는 반응을 몇 개 봤음. 최근 이 글과 매우 비슷한 글을 썼고, 여기처럼 애니메이션의 문제를 자세히 다룬 뒤 어떻게 개선했는지도 설명했음
    궁금하면 여기에서 볼 수 있음: https://www.thisischris.dev/projects/project-6/

    • Android의 모바일 Chrome에서는 애니메이션이 동작하지 않는 것 같음

  • 나중의 완벽한 프레임보다 지금의 불완전한 프레임이 낫다고 봄. 모든 UI에서 지연 시간이 최우선이어야 함. 지연이 충분히 낮으면 자기 몸의 일부처럼 느껴지고 인지 부하가 줄어듦. 애니메이션은 여기에 특히 나쁜데, 수백 밀리초의 지연을 추가하기 때문임

    • 그건 잘못된 양자택일이라고 봄. 저자가 든 예시는 제대로 구현해도 전혀 느려지지 않을 것임
    • 제목이 Wayland 이야기라고 생각했을 수도 있고 그 생각은 맞음. 하지만 이건 Wayland 이야기가 아님

  • 부정적인 예시만큼 긍정적인 예시도 같이 있었으면 좋겠음. 지금 얻은 결론은 애니메이션을 피해야 한다는 것뿐인데, 저자가 실제로 말하려는 바는 그게 아닐 것 같음

    • “애니메이션을 피해야 한다”는 결론이 최악의 교훈은 아님. 일반적으로 애니메이션을 위한 애니메이션은 피해야 함. 예를 들어 휴대폰 키보드에서 글자를 칠 때마다 문자가 텍스트 입력칸으로 날아 올라가게 만든다고 상상해보면 됨

  • 좋은 애니메이션은 모든 프레임에서 완벽해 보이기보다 움직이는 동안 약간 속임수를 쓰는 경우가 드물지 않음. 카툰의 스미어 프레임처럼 잘못 멈추면 이상하지만 전체 애니메이션 안에서는 움직임을 시각적으로 설득력 있게 만드는 식임

    • 스미어 프레임은 이런 종류의 애니메이션에 자주 적용되는 기법은 아님. 거의 프레임 단위 애니메이션에 특화된 것이고, 이 글에는 스미어 프레임이 나오지 않음
    • 차이는 블러 프레임은 전체 효과를 위해 의도적으로 쓰였다는 데 있음. 여기 나온 애니메이션들은 다듬어지지 않은 앱을 드러내는 우발적 버벅임에 가까움
    • 이 비유는 맞지 않는다고 봄. 블러 프레임은 움직일 때 좋아 보이지만, 블로그 글의 프레임들은 움직일 때도 끔찍해 보임. 첫 예시는 너무 나빠서 처음 봤을 때는 위쪽에 버튼이 세 개 남을 줄 알았고, 결국 두 개뿐이라는 걸 깨닫는 순간 이상하고 방향감을 잃게 됨
    • macOS에서는 Apple이 OS와 앱에 SwiftUI를 쓰기 시작했을 때 시각 품질과 애니메이션 품질이 크게 바뀐 느낌이었음
      개발자는 아니지만, 아이콘이나 창이 예전처럼 또는 당연히 그래야 하는 방식으로 배치되거나 움직이지 않는 영역들이 느껴졌음
      이런 땜질 느낌은 시간이 지나도 바뀌지 않았음. OS와 앱 전반에 “원래 그랬다”고 말하고 싶을 만큼 예시가 많지만, 사실 그렇지 않았음. Apple은 기준을 세웠고 그 기준은 높았으며 품질은 뛰어났음
      SwiftUI로 같은 UI 배치나 애니메이션을 달성하려고 많은 해킹이 들어가는 것처럼 느껴짐
      마지막으로 자주 생각하는 건, 아날로그 창작은 정말 어려웠고 지금도 그렇다는 점임. 디지털에서는 나중에 다시 손보겠다고 생각해왔지만 실제로는 그러지 않고, 나쁜 것 위에 더 나쁜 것을 쌓아 올리는 경우가 많아 안타까움
    • Overwatch는 꽤 훌륭한 현대적 예시임 [1]. 아주 유려한 애니메이션이 많은데, 프레임을 멈춰 보면 정말 이상하게 보임
      [1]: https://youtu.be/vIdeGmN__Pw?t=550

  • 애니메이션이 전혀 없는 앱은 끔찍하게 느껴질 것임. Android가 있다면 개발자 설정에서 애니메이션 속도를 0x로 바꿔 직접 시험해볼 수 있음. 즉각적인 변화는 거슬리고, 무슨 일이 일어났는지 뇌가 처리하는 데 오히려 1초쯤 걸리며, 그 과정이 애니메이션이 있는 경우보다 더 느릴 수도 있음
    내 설정은 0.5x인데 충분하다고 느낌. 여전히 빠르지만 앱이 열리고 닫히는 건 볼 수 있음

    • Android에서 애니메이션을 꺼놓고 만족하며 쓰고 있음. 그나마 “즉각적”으로 느끼게 만드는 유일한 방법임. 입력에서 UI 변화로 이어지는 맥락에서는, 화려한 과도 상태가 없는 것보다 지연이 언제나 더 나쁘다고 봄
    • 내 경우는 아님. 항상 애니메이션을 끔. 그렇게 해도 괜찮고, 애니메이션이 끝나기를 기다릴 필요가 없어 훨씬 빨리 휴대폰을 조작할 수 있음
    • 나도 0.5x로 씀
      0x의 문제는 UI의 90% 정도에만 적용되는 것처럼 보인다는 점임. 어떤 것들은 여전히 애니메이션이 있고, 그 결과 박자가 아주 이상하게 느껴짐
      0.5x에서는 애니메이션 속도 설정의 영향을 이상하게 받지 않는 것들이 덜 거슬림
      제대로 동작한다면 0x를 쓸 것임
    • Android를 거의 10년 쓰다가 결국 새 제품이었을 때 iPhone 12 Mini로 넘어갔음. Android에서처럼 애니메이션을 끌 수 있는 기능은 아직도 그리움. 그냥 존재하기 위해 존재하는 모든 애니메이션을 끌 수 있다면 현재 휴대폰이 200%는 더 빨라질 거라고 110% 확신함
      필요하다면 처리에 1초를 쓰는 편이 낫고, 실제로 필요하다고도 생각하지 않음. 앱이 페이지를 바꿀 때마다 애니메이션 때문에 1초씩 느려지는 것보다 훨씬 낫고, 탐색할 때 모든 것이 당밀처럼 느껴짐
    • 모든 애니메이션은 UI와 제대로 상호작용할 수 없는 동안 낭비되는 시간일 뿐이라서, 전부 꺼버리는 편이 훨씬 좋음

  • 이 글은 공감됐지만, 긍정적인 예시도 있었으면 좋았겠음. 어조가 불평처럼 읽히지는 않았지만, 좋은 UI 구성에 대해 많이 모르는 입장에서는 무엇을 북극성으로 삼아야 할지 더 가까워졌다는 느낌은 받지 못했음

    • 최근에 바로 그런 내용을 썼음. 먼저 이 글과 개념적으로 비슷한 불완전함을 자세히 다루고, 이어서 직접 만든 개선 과정을 설명했음
      궁금하면 여기에서 볼 수 있음: https://www.thisischris.dev/projects/project-6/
    • 아니면 저자가 각각의 나쁜 예시가 제대로 구현됐다면 어떻게 보여야 하는지 목업으로 보여줬어도 좋았을 것임
답변달기
GN⁺   [-]
Lobste.rs 의견들

  • 이 글의 기본 전제가 틀렸다고 봄. 이런 앱을 프레임 단위로 쓰지는 않음
    기본 애니메이션 수업만 들어도 움직임을 인식하는 방식은 정지 이미지와 다르다고 배움. "squash and stretch" 데모를 찾아보면, 프레임별로는 어떤 객체의 치수가 따로 보면 말도 안 되지만 움직임 속에서는 아름답게 작동하는 걸 볼 수 있음

    • 글의 예시들은 움직이는 상태에서도 아름다워 보이지 않음
    • 요점은 애니메이션이 못생겼다는 게 아니라, 사용 가능한 UI를 작동하지 않는 애니메이션 시퀀스로 대체하는 시간 구간을 만들었다는 데 있음
      심지어 자르기 예시처럼 프로그램 상태를 잘못 보여줄 수도 있음. 사용자는 UI가 다시 조립되는 동안 3분의 1초 정도 머리를 꺼두고 기다린 뒤에야 프로그램을 계속 쓸 수 있음

  • Wayland 프로젝트가 말하는 프레임 완전성이 이런 뜻은 전혀 아니라고 봄
    오히려 창 크기 조절처럼 더 낮은 수준의 기술 세부사항을 말하는 것에 가까움. 예를 들면 콘텐츠가 비동기로 리사이즈된다거나, 수직 동기화가 깨져 화면 찢김이나 이상한 대각선 아티팩트가 생긴다거나, 손상 영역 보고가 직사각형 부분 영역으로 이뤄지는 경우 같은 것들임
    물론 낮은 수준의 세부사항과 높은 수준의 애니메이션이 둘 다 프레임 단위로 완벽하면 좋겠음

    • 동의함. 그리고 글쓴이도 그렇게 보는 것 같음

      Wayland is talking about the technical side of things (modern GPU stacks are very complex and Wayland is trying to take control back) but it could be applied to UI too.

  • 이런 애니메이션을 테스트하고, 시간이 지나도 이런 속성이 깨지지 않게 확인하는 테스트를 작성하고 싶다고 해보자
    오늘날 웹 앱과 네이티브 앱에서 이런 속성을 테스트하는 최신 기법은 무엇일까? 이벤트 루프를 제어하지 못해서 작성하고 싶은 특정 범주의 테스트가 사실상 불가능하거나 매우 어려운 경우도 있을까?

    • 네이티브 Android 앱에 대해서만 말할 수 있음. Jetpack Compose UI 도구킷을 쓰면 UI를 구동하는 시계 자체를 제어할 수 있어서, 전환의 어느 지점이든 정적 스크린샷 테스트로 캡처할 수 있음
      또는 Paparazzi 같은 도구로 전환 전체를 Animated PNG로 기록해 자동 회귀 테스트를 할 수도 있음
    • 이상적으로는 크기 정보가 노출되고, 범용 레이아웃 엔진은 독립적으로 테스트 가능하며, 애니메이션도 분리되어 있어야 함
      그러면 두 지점을 각각 검증하고, 마지막에 최종 상태만 확인하면 됨. 애니메이션은 시간 입력에 고정되기보다 외부에서 단계별로 구동할 수 있어야 함

  • YouTube 예시는 View Transitions의 사례가 거의 맞다고 봄
    “이 요소가 바뀌면 자동으로 형태를 바꿔라”라고 선언하는 방식이고, 결과적으로 기술적으로는 인상적이지만 약간 흐물흐물해 보이는 전환이 나오며, 요소들이 둥둥 떠다니고 서로 변형됨
    아주 멋진 기술이지만, 탐색 시의 작은 강조 효과 말고는 훌륭해 보이는 경우를 거의 못 봤음. 너무 산만해지지 않으려면 아주 절제해서 써야 함

답변달기