Google for Developers Korea Blog

안드로이드에서 더욱 똑똑한 애니메이션 만들기

2019년 9월 16일 월요일

.post-body span { white-space: normal !important; }

<블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 양찬석(Google)님이 참여해 주셨습니다>이전 Google I/O에서 반응형 아키텍처 상에서 애니메이션을 잘 구현할 수 있는 기법을 몇 가지 말씀드렸습니다.

tl;dw? 이 32분짜리 동영상을 시청할 마음이 없는 분도 계실 것이므로, 프레젠테이션에서 다룬 주제를 글로 적어 소개해 드립니다. ☕️ #AnimationsMatter 애니메이션은 앱의 사용성에 중요한 역할을 한다고 생각합니다. 애니메이션으로 상태 변화나 전환을 설명하거나, 공간 모델을 확립하거나, 주의를 끌 수 있기 때문입니다. 애니메이션은 사용자가 앱을 올바로 이해하고 원하는 화면으로 이동하는 데 도움이 됩니다. 앱에서의 애니메이션 흐름

👈 애니메이션이 있는 경우와 없는 경우 👉 위 예제는 애니메이션 여부를 제외하고는 동일한 사용 흐름입니다. 애니메이션이 없으면 무엇이 바뀌었는지에 대한 설명 없이 상태가 갑자기 바뀐다는 느낌이 듭니다.
애니메이션이 중요하다고는 생각하지만, 현대 앱의 아키텍처 방식이 변화함에 따라 애니메이션을 구현하기 더 어려워지고 있다는 생각도 듭니다. 뷰 계층 밖에 있는 대부분의 상태 관리를 (ViewModel과 같은) 컨트롤러로 이동하고 있는데, 이런 컨트롤러는 뷰를 렌더링하는 데 필요한 앱의 현재 상태를 캡슐화하는 상태 객체(예: UiModel)를 게시합니다. 예를 들어 네트워크 요청이나 사용자가 시작한 작업이 완료될 때처럼, 데이터 모델에서 뭔가가 바뀔 때마다 업데이트된 전체 상태를 캡슐화하는 새 UI 모델을 게시합니다. 상태 객체의 스트림을 게시하는 ViewModel

상태 객체의 스트림을 게시하는 ViewModel
오늘은 이 패턴이나 그 이점에 초점을 맞추고 싶지 않습니다.이 주제에 관해서는 훌륭한 자료가 많이 있습니다. 단방향 데이터 흐름이나 MVI를 찾아보거나 MvRx 또는 Mobius와 같은 라이브러리를 찾아보세요. 반대로 뷰가 모델 스트림을 관찰하고, UI에 바인딩하는 스트림의 다른 쪽 끝 부분에 초점을 맞추고 싶습니다. 이 부분은 UI에 완전히 바인딩되는 어떤 새로운 상태가 주어지는 순수한 함수 같은 것입니다. UI의 현재 상태에 대해서는 생각하고 싶지 않습니다. 즉, UI에 대한 데이터 바인딩이 상태 비추적(Stateless) 이어야 합니다. 하지만 애니메이션은 상태 저장(Stateful)입니다. 애니메이션은 시간의 경과에 따라 하나의 값에서 다른 값으로 이동하는 것입니다. 이 점에서 본질적이 상충이 있습니다. 요즘 이런 이유로 많은 앱에서 애니메이션이 제거되어 실제로 사용성의 손실로 이어지고 있다는 점이 걱정스럽습니다.
무엇이 문제일까요? 우리가 이런 반응형 환경에서 애니메이션을 유지할 방법과 해결해야 할 과제를 구체적으로 파악하기 위해 살펴볼 수 있는 아주 작은 본보기가 있는데, 바로 로그인 화면입니다. 로그인 버튼과 진행률 표시기가 페이드 인/페이드 아웃 방식으로 나타나거나 사라지는 로그인 화면

로그인 버튼과 진행률 표시기가 페이드 인/페이드 아웃 방식으로 나타나거나 사라지는 로그인 화면

사용자가 로그인 버튼을 누르면 로그인 버튼을 숨기고 진행률 표시기를 표시하고 싶지만, 이때 로그인 버튼을 페이드 아웃하고 진행률 표시기를 페이드 인하는 방식으로 처리하고 싶다고 해봅시다. 이 화면과 (정적) 바인딩 로직에 대한 상태 객체는 다음과 같은 모습일 수 있습니다.

이런 변화를 애니메이션 으로 표현하고 싶을 경우 최초의 시도는 다음과 같은 모습일 수 있으며, 여기서 알파 속성을 애니메이션하고 마지막으로 페이드 아웃하는 경우 표시 유형 값을 설정합니다.

하지만 이는 다음과 같이 예기치 않은 결과로 이어질 수 있습니다.
반응형 앱에 애니메이션을 추가할 때 발생할 수 있는 문제

반응형 앱에 애니메이션을 추가할 때 발생할 수 있는 문제
여기서는 키를 누를 때마다 새로운 UI 모델이 게시되지만, 예상과는 달리 진행률 표시기가 계속 표시되는 것을 볼 수 있습니다! 또는 (데모를 위해 애니메이션 지속 시간을 과하게 늘린 상태에서) 제출 버튼을 누르면 결국 버튼과 진행률 표시기가 둘 다 사라져버리는 잘못된 상태로 이어질 수 있습니다. 이는 애니메이션에 올바로 처리되지 않는 종료 리스너와 같은 역효과가 있기 때문입니다.
이 반응형 환경에서 애니메이션을 작성할 때 애니메이션 코드에 필요한 몇 가지 특성이 있습니다. 이런 특성을 다음과 같이 분류해봤습니다.

재진입

연속

매끄러움

재진입 재진입은 애니메이션을 언제든지 중단했다가 다시 호출할 수 있어야 한다는 의미입니다. 새로운 상태 객체가 게시되는 경우, 애니메이션이 실행 중인 동안에도 새로운 상태에 맞는 애니메이션이 바인딩될 수 있도록 애니메이션을 준비해야 합니다. 이를 위해서는 실행 중인 애니메이션을 취소 또는 다시 타게팅할 수 있거나, 잠재적인 역효과(예: 리스너)를 모두 없앨 수 있어야 합니다.
연속 연속성은 애니메이션되는 값에 갑작스러운 변화가 생기지 않도록 하는 것입니다.이 속성을 입증하려면 누르거나 놓을 때 크기와 색상에 애니메이션 효과를 주는 뷰를 고려하세요. 누를 때 크기와 색상에 애니메이션 효과 부여

누를 때 크기와 색상에 애니메이션 효과 부여
애니메이션을 끝까지 실행하면 모든 모습이 보기 좋지만, 그러지 않고 빠르게 탭하면 애니메이션의 크기와 색상이 불연속적으로 변합니다. 이는 바인딩 코드에서 가정을 한 결과입니다(예: 페이드 애니메이션은 항상 0 알파에서 시작하는 것으로 가정함).
매끄러움 이 속성을 이해하려면 다음과 같이 뷰가 어떤 이벤트에 대한 반응으로 상단 왼쪽이나 오른쪽으로 움직이는 예를 생각해보세요. 더듬거리는 애니메이션

더듬거리는 애니메이션
뷰를 상단 오른쪽으로 두 차례 연속으로 빠르게 보내는 경우 뷰가 중간에서 멈춘 후에 목적지를 향해 계속 천천히 움직입니다. 이동 중간에 목적지를 바꾸면 뷰가 다시 멈추었다가 갑자기 방향을 바꿉니다. 이런 종류의 갑작스러운 정지나 방향 변화는 부자연스러워 보입니다. 현실 세계에서는 이런 식으로 움직이지 않기 때문입니다. 따라서 애니메이션을 계속 매끄럽게 유지하려면 이런 종류의 동작을 피하도록 해야 합니다.
Fixme 이제 바인딩 함수로 돌아가서 이런 문제를 수정해 봅시다. 먼저 연속성을 살펴봅시다. 알파 애니메이션은 항상 초기값부터 최종값까지(예: 페이드 인을 위해 0부터 1까지) 실행된다는 점을 알 수 있습니다. 그 대신에 초기값을 생략하고 최종값만 제공할 수 있습니다.

초기값을 생략하면 애니메이터가 현재 값을 읽고 그곳부터 시작합니다.이것이 바로 정확히 우리가 원하는 바로, 애니메이션 처리되는 속성에서 갑작스러운 변화를 방지해 줍니다. 이제는 함수를 재진입 가능하게 만들어 언제든 안심하고 다시 호출할 수 있도록 해봅시다.먼저 수행할 필요가 없는 작업은 어떤 것도 수행하지 않도록 해두면 안심할 수 있을 것입니다. 뷰가 이미 목표 값에 있는 경우에는 일찍 돌아올 수 있습니다.

다음으로, 실행 중인 애니메이터와 리스너를 저장하여 새 애니메이션을 시작하기 전에 이들을 취소할 수 있도록 해야 합니다. 이를 저장할 논리적 위치는 뷰 자체 내에 있지만, View는 이미 이를 수행하기 위한 편리한 메커니즘인ViewPropertyAnimator를 제공합니다. 이 메커니즘은 View.animate()에 대한 호출로 반환되는 객체로, 어떤 속성에 대해 새 애니메이션을 시작할 경우 그 속성에서 현재 실행 중인 모든 애니메이션을 자동으로 취소합니다. 대단하죠! 또한 ViewPropertyAnimator는 애니메이션이 끝까지 정상적으로 실행되는 경우에만 실행되고 애니메이션이 취소되는 경우에는 실행되지 않는 withEndAction 메서드도 제공합니다.이 역시 정확히 우리가 원하는 동작으로, 새로 입력된 목표 값으로 인해 애니메이션이 취소되는 경우 어떤 역효과(예: 표시 유형 변경)도 실행되지 않을 것이라는 뜻입니다. ViewPropertyAnimator로의 전환은 함수를 재진입 가능하게 만듭니다.

ViewPropertyAnimator는 같은 속성에 대해 실행 중인 애니메이션을 취소하고 새 애니메이션을 시작할 것이라 말씀드렸습니다. 이는 부드러움 속성에 위배되고 앞서 본 것처럼 한 애니메이션이 갑자기 멈추고 다른 애니메이션이 시작되는 부자연스러운 애니메이션 문제로 이어질 수 있습니다(거리는 더 짧아지지만 지속 시간은 같음). 이 문제를 해결하기 위해 애니메이션 라이브러리를 살펴볼 수 있는데, 이 라이브러리에 익숙한 개발자가 많지 않다고 생각합니다.
Springterlude 스프링은 ‘동적 애니메이션’ Jetpack 라이브러리의 일부입니다. 많은 사람이 매우 탄력있는 애니메이션 예시를 보면서 이 라이브러리를 그냥 건너뛰었을지도 모른다고 생각합니다. 이 효과를 유용하게 활용할 수도 있지만, 늘 필요하거나 바람직한 것은 아니라서 그럴 겁니다. 하지만 이런 탄력성은 비활성화하고 애니매이션을 중단하고 다시 시작하는 기능 및 일반적인 애니메이션에 유용한 여러 가지 속성을 가진 물리 애니메이션 시스템으로 사용할 수 있습니다.
이전의 예로 다시 돌아가 스프링 애니메이션으로 다시 구현하면 부드러움 문제가 생기지 않는다는 점을 확인할 수 있습니다. 대신에 목적지 변경과 반복되는 시작 문제를 처리하여 현재의 속도를 지킴으로써 부드러운 애니메이션을 생성합니다. 리타게팅 시 속도를 유지하는 스프링 기반 애니메이션

리타게팅 시 속도를 유지하는 스프링 기반 애니메이션
SpringAnimation 작성은 일반적인 애니메이터와 많은 면에서 흡사해 보이는데, start()를 호출하는 게 아니라 animateToFinalPosition 메서드를 사용하는 점이 큰 장점입니다. 이 메서드는 애니메이션이 아직 시작되지 않은 경우 애니메이션을 시작하는 역할을 하지만, 애니메이션이 실행 중인 경우에는 애니메이션을 새 목적지로 리타게팅하여 갑자기 변경하지 않고 모멘텀을 유지한다는 점이 중요합니다.
View.animate처럼 스프링을 사용하기에 편리한 View API가 없다는 점이 아쉽긴 하지만(Jetpack에서만 지원됨), 다음과 같이 확장 함수로 빌드해 사용할 수 있습니다.

이렇게 하면 주어진 ViewProperty(평행이동, 회전 등)에 대한 스프링을 생성하거나 불러와 뷰의 태그에 저장할 수 있습니다.그러면 손쉽게 animateToFinalPosition 메서드를 사용하여 실행 중인 애니메이션을 업데이트할 수 있습니다.다음과 같이 이를 표시 유형 바인딩 함수에 사용합니다.

또한 종료 작업에서 스프링 애니메이션 종료 리스너를 사용하도록 전환해야 합니다. 이 gist에서 이에 대한 전체 코드를 찾을 수 있습니다. 또한 애니메이션을 어느 정도 구성할 수 있었으면 하는 생각도 들 것입니다. 지속 시간과 보간기를 지정하는 일반 애니메이션과는 달리, 스프링은 강성 및 감쇠비 설정을 통해 구성할 수 있습니다. 호출 사이트를 쉽게 구성할 수 있도록 하되, 실용적인 기본값을 제공하기 위해 적절한 매개변수를 허용하도록 확장 함수를 개선할 수 있습니다. 좀 더 완전한 구현에 대한 설명은 여기를 참조하세요.
바인딩 함수가 재진입, 연속성, 매끄러움이라는 특성을 지니도록 만들었습니다.이런 목적을 달성하기 위해 이 모든 바인딩 함수가 관련되어 있는 것처럼 보일 수 있지만, 실제로는 그중 몇 가지만 있으면 애플리케이션 전체에 사용할 수 있습니다. 여기에서 이 스프링 기법을 쉽게 사용할 수 있도록 패키지로 묶은 라이브러리를 찾을 수 있습니다.
Item Animator 이런 종류의 애니메이션을 사용하는 또 다른 예를 살펴봅시다. 이번에는 이런 원리를 RecyclerView.ItemAnimator에 적용해 봅니다. DefaultItemAnimator와 스프링 기반 ItemAnimator

👈 DefaultItemAnimator와 스프링 기반 ItemAnimator 👉
이 예에서는 애니메이션이 셔플 버튼을 사용하여 실행 중인 동안 데이터 세트에 발생하는 업데이트를 시뮬레이션합니다. 버튼을 두 번 연속으로 빠르게 누를 때 스프링 기반 애니메이터의 매끄러움이 큰 차이를 만들어낸다는 점에 주목하세요.왼쪽에서는 상자가 잠시 멈춘 다음에 방향을 바꾸지만,오른쪽에서는 매끄럽게 방향을 바꿉니다. 대부분의 앱이 아마도 네트워크의 많은 소스로부터 정보를 로드하여 RecyclerView에 표시할 것이라 장담합니다.이런 종류의 유연한 애니메이션을 사용하면 애플리케이션의 완성도가 더욱 높아져 훨씬 더 부드러운 사용 환경을 만들어 줄 것입니다. 여기에서 Plaid 샘플에 이런 종류의 애니메이터를 추가하는 PR을 찾을 수 있습니다. 더욱 똑똑한 애니메이션 이 글에서 설명한 원리가 반응형 앱에서 자연스럽게 애니메이션을 적용해 사용성을 개선하는 데 도움이 되기를 바랍니다. 실제로 설명한 원리에는 중요도에 차이가 있습니다.. 애니메이션 요구사항의 계층 구조

@crafty의 애니메이션 요구사항의 계층 구조
재진입은 정확성에 관한 속성입니다. 이 속성이 없으면 애니메이션이 단절될 수 있습니다.ViewPropertyAnimator를 사용하거나 애니메이션 코드에 주의를 기울여 애니메이션이 중단되었다가 다시 호출될 수도 있는 상황을 적절히 처리하세요. 연속성은 갑작스러운 변화나 이동을 방지함으로써 사용자 환경의 개선에 도움이 됩니다.이는 애니메이션 코드에서 섣부른 가정을 피하고 애니메이션 간의 손쉬운 이전을 보장하는 문제입니다. 매끄러움까지 더하면 금상첨화일 것입니다 🎂. 이를 통해 애니메이션이 더욱 자연스럽게 느껴지고 역동적인 변화, 중단, 리타게팅이 가능합니다. 애니메이션이 앱을 더욱더 즐겁고 재미있게 사용할 수 있도록 해 줄 뿐 아니라, 더욱더 쉽게 이해할 수 있도록 해주는 요소라 믿어 의심치 않습니다. 이런 기법을 습득하여 앱에 애니메이션을 훌륭하게 활용하실 수 있기를 바랍니다.

원본에서 더욱 빠른 AMP: AMP + SSR = ⚡

2019년 9월 11일 수요일

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 조은(Webtech GDE)님이 참여해 주셨습니다>
AMP는 현재 AMP 페이지를 훨씬 더 빠르게 로드할 수 있게 AMP 페이지에 적용할 수 있는 서버사이드 렌더링(SSR) 기법을 공식적으로 지원합니다. 우리의 테스트 결과, 유명한 FCP 측정항목에서 최대 50%라는 엄청난 속도 증가를 보여줍니다. Google AMP Cache는 한동안 이 기법을 활용해왔지만, 이제는 개발자가 자신의 도메인에서도 이 기법을 사용할 수 있습니다! 주요 사이트 환경을 제공하기 위해 AMP를 사용 중이라면, 이 추가적인 최적화 프로그램의 설치가 특히 중요합니다. AMP 페이지와 비 AMP 페이지가 있는 '페어링된 AMP 설정'을 사용 중이라 할지라도, 사용자가 Twitter 앱을 사용하는 것과 같이 AMP Cache가 사용되지 않는 경우에 이 기법으로 사용자를 위한 최적의 성능을 보장할 수 있습니다. SSR은 React 또는 Vue.js와 같은 클라이언트측 페이지를 렌더링하는 프레임워크를 위한 FCP(first-contentful-paint) 시간을 개선하기 위한 기법입니다. 클라이언트측 렌더링의 단점은 페이지 렌더링에 필요한 모든 자바스크립트를 먼저 다운로드해야 한다는 점입니다. 그래서 사용자가 페이지의 실제 콘텐츠를 볼 수 있을 때까지의 시간이 지연됩니다. 이 문제를 완화하기 위해, React와 Vue.js는 둘 다 탐색 요청 시 서버에서 DOM을 사전에 렌더링하도록 지원합니다. 그러면 클라이언트측 자바스크립트가 렌더링을 픽업하는데, 이는 (리)하이드레이션이라는 프로세스입니다. 결과적으로 사용자는 콘텐츠를 훨씬 더 빠르게 볼 수 있게 됩니다. AMP SSR은 AMP 보일러플레이트 코드를 제거하고 서버에서 페이지 레이아웃을 렌더링하는 방식으로 작동합니다. AMP 보일러플레이트 코드가 존재하는 목적은 페이지 로드 시 콘텐츠 점프를 방지하기 위해서입니다. 이 코드는 AMP 프레임워크가 다운로드되고 페이지 레이아웃이 확정될 때까지 페이지 콘텐츠를 숨깁니다. 따라서 AMP 페이지는 다른 클라이언트측 프레임워크와 똑같은 문제, 즉 자바스크립트를 다운로드할 때까지 렌더링이 차단되는 문제를 겪게 됩니다. 보일러플레이트 코드를 제거하면 AMP SSR의 FCP 시간이 50% 더 빨라집니다. 다음은 AMP 파일과 그 파일의 SSR 버전이 어떻게 다른지 비교한 내용입니다(자세한 설명을 보려면 공식 가이드 참조).

html 요소에서 변환된 속성을 통해 서버측에서 렌더링된 AMP 페이지를 식별할 수 있습니다. <html amp transformed="self;v=1"> 주: AMP 캐시는 자체 플래그를 설정하는데, 예컨대 Google AMP Cache에서는 다음을 추가합니다. <html amp transformed="google;v=1">
이 속성이 설정되면 유효성 검사기가 SSR 처리된 AMP를 유효한 AMP로 취급합니다. SSR 처리된 AMP 최적화는 AMP 사양의 규칙을 위반하므로 문서를 무효화하며, 이것이 바로 이 새로운 플래그로 이 사례를 표시해야 하는 이유입니다. 플래그와 최적화가 모두 적용된 문서는 유효한 것으로 간주되어 계속 진행해도 좋습니다. AMP SSR에 대해 자세히 알아보려면 AMP 채널의 설명 동영상을 시청하거나 AMP SSR 가이드를 읽어보세요. AMP의 SSR 처리 방법은? SSR 처리된 AMP를 수동으로 작성한다는 건 말이 안 됩니다. 대신에, 컴파일러가 하는 일과 마찬가지로 AMP 파일을 SSR 버전으로 자동으로 변환하는 도구를 사용합니다. 사용자가 문서를 요청하기 전에 미리 이런 변환이 이루어지는 것이 이상적일 것입니다. 하지만 요청 시 변환을 실행할 수도 있습니다(변환 작업을 반복해서 계속 실행하지 않도록 결과를 캐시해야 함). 현재는 AMP SSR을 위해 사용 가능한 도구는 다음 두 가지입니다.

AMP Optimizer: 최적화된 AMP를 생성하기 위한 NodeJs 라이브러리. Express로 사이트를 구동하는 경우 express 미들웨어에 관심이 있으실 수도 있습니다. 

AMP Packager: Signed Exchange 제공과 함께 유용한 go 명령줄 도구.

주: 이러한 도구는 SSR을 수행할 뿐 아니라, AMP 프레임워크 미리 로드, 헤드 재정렬 등의 다른 최적화도 수행합니다. Next.js 지원 최신 Next.js 9 릴리스가 별도 구성 없이 AMP SSR을 기본적으로 지원한다는 점이 무척 기대됩니다. Next.js 9은 현재 AMP 우선 페이지와 하이브리드 AMP 페이지에 대해 기본적으로 최적화된 AMP를 렌더링합니다. 따라서 Next.js는 AMP 페이지를 빌드하기 위한 훌륭한 선택입니다. 다음 단계는? 우리는 앞으로 두 가지 큰 추진 과제를 계획해두고 있습니다. 1. AMP 프레임워크(v0.js)를 자체 호스팅하기 위한 옵션. 예, 맞습니다. 더는 cdn.ampproject.org에서 AMP를 다운로드할 요가 없을 것입니다. 이는 다음과 같은 두 가지 장점을 지니게 될 것입니다.

더 빠른 상호작용: AMP 프레임워크를 다운로드할 때 cdn.ampproject.org에 대한 HTTPS 연결을 하나 더 설정할 필요가 없어지게 됩니다.

더 쉬운 QA: 새 AMP 릴리스로 전환하고 싶은 시점을 제어할 수 있습니다.

하지만 개인정보 보호상의 이유로, AMP 캐시는 캐시된 AMP 페이지를 제공할 때 캐시 원본과 일치하도록 AMP 스크립트 URL을 다시 쓴다는 점을 유념하세요. 2. WordPress 통합: 공식 AMP wordpress 플러그인 v1.3에서는 AMP SSR을 기본적으로 지원합니다. 모든 이를 위한 AMP SSR AMP 페이지를 게시할 경우 서버측에서 렌더링된 AMP 페이지를 게시해야 합니다. HTML 또는 CSS의 축소와 유사하게, AMP Optimizer 또는 Go 변환기의 실행이 빌드/렌더링 체인의 정상적인 한 부분이어야 합니다. 렌더링 성능의 개선으로 FCP 시간에 큰 차이가 생기지만, 더욱 중요한 점은 사용자 환경의 차이입니다. 게시자: Sebastian Benz, Google 디벨로퍼 어드보케이트

기다리는 시간을 더 가치있게 만들기 : 새로운 AMP 로딩 표시기

2019년 9월 9일 월요일

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 조은(Webtech GDE)님이 참여해 주셨습니다>
게시자: Andrew Watterson, Google AMP Project 제품 디자이너
이 게시물은 AMP 디자인 팀에서 작성한 글입니다. 우리는 AMP 컴포넌트와 전체적인 사용 환경을 유용하고 액세스하기 쉽고 세련되게 만들 책임이 있는 제품 디자이너와 연구자로 구성된 팀입니다. 우리가 어떤 일을 하고 어떤 성과물을 내놓고 있는지 확인하려면 GitHub 또는 Contributor Slack에서 UI 및 접근성 작업 그룹과 진행하는 다양한 활동을 살펴보세요.
AMP가 웹 사용자의 일상적 사용 환경을 개선하는 가장 중요한 방법 중 하나는 개발자가 빠르게작동하는 사이트를 만들도록 돕는 일입니다. AMP만 가지고 있는 장점은 한상 무대 뒤에서 개선하고 있다는 점입니다. 우리는 개발자가 따로 어떤 일도 할 필요 없이 AMP를 사용하는 사이트에 속도 개선 사항을 적용할 수 있습니다. 성능 모범 사례는 항상 AMP의 모든 측면에 적용되어있지만, 실제 속도 는 전체 이야기의 절반에 불과합니다. 엔지니어가 기술적인 세부 사항을 계속 열심히 다루는 동안, 우리 디자인팀에서는인지 속도를 개선하는 작업에 착수합니다. 기다림이란 늘 우리 인생의 한 부분이겠지만, AMP 엔지니어들이 우리가 제어할 수 없는 부분(예: Facebook 게시물 또는 YouTube 동영상) 이거나 그냥 용량이 큰 경우 AMP 페이지 내에서 더 빠르게 만들 수 없습니다. 하지만 많은 증거를 통해 사용 환경에 따라 기다려야 하는 상황에 대한 느낌 이 달라진다는 점이 분명히 드러납니다. AMP 페이지를 어느정도 사용해보셨다면 2015년부터 AMP가 사용한 로딩 표시기에 익숙할 것입니다. 원래 AMP 로딩 표시기

오늘부터 우리는 새 로딩 표시기를 사용합니다. 새 AMP 로딩 표시기

우리가 어떻게 여기까지 왔는지 말씀드리겠습니다. 우리는 다음 세 가지 목표를 정하고 시작했습니다.

더 빠르게 로딩되는 느낌이 들게 한다.

무슨 내용이 표시될지 독자가 알도록 한다. 2016년 이후로 AMP 페이지에 표시할 광고에는 다른 로딩 표시기를 사용해왔으므로, 사람들은 광고를 주 콘텐츠와 즉시 구분할 수 있습니다. 우리는 동영상, 트윗, Facebook 게시물 등, 더 많은 유형의 콘텐츠에 이러한 로딩 표시기를 확장하고 싶었습니다. 이는 예컨데 인내심을 가지고 동영상이 로드되기만을 기다렸는데, 결국 동영상을 시청할 수 없는 상황이 벌어지지 않도록 하려는 것이었습니다.

디자인을 현대화한다. 이 목표에 대해서는 숫자로 정량화할 수 없지만, AMP 팀의 많은 사람이 우리가 쓰던 로더를 시각적으로 더 세련되게 만들 수 있으리라 느꼈습니다.

우리는 디자인을 세련될 뿐 아니라 중립적으로 유지할 필요도 있었습니다. AMP와 함께 제공되는 UI는 어떤 AMP 페이지의 디자인과도 잘 어울려야 합니다. 즉, 극적 표현력을 살린 색이나 너무 튀는 스타일은 지양해야 한다는 뜻입니다. 우리는 일정 시간 후 콘텐츠가 '로드'될 것임을 표시하는 10가지 종류의 로딩 표시기 디자인에 대한 프로토타입을 만들어 2,500명의 웹 사용자를 대상으로 로드 시간이 얼마나 걸릴 것 같은지 예측해 보라는 질문을 던졌습니다. 사람은 무척 짧은 시간을 추정하는 데는 능숙하지 못하므로, 예측의 정확도가 중요한 게 아니라 그 추세가 중요했습니다. 참가자들은 기존의 AMP 로딩 표시기나 기본적인 스피너와 같은 종래의 옵션에 비해 우리가 새로 디자인해서 선보인 몇몇 프로토타입을 보고서는 거의 1초 정도 로딩 시간이 덜 걸릴 것으로 예측했습니다. 우리는 이 데이터와 디자인 과정에서 큰 관심을 끌었던 몇몇 관찰 사항을 바탕으로 한 가지 디자인을 골랐습니다. 우리는 다음 세 가지 원칙에 이르렀습니다.

때로는 로더가 없는 게 더 낫다. 사용자는 자신이 기다리고 있다는 걸 미처 깨닫기 전에 로더를 표시하면 오히려 사용자의 주의를 흩트리면서 사이트의 작동 속도가 느린 것처럼 보이게 만들 수 있습니다.

흥미로움을 유지한다. 이미 백만 번도 넘게 봤을 법한 똑같은 스피너를 반복해서 봐야 하는 상황은 페이지가 로딩되기를 기다리는 사용자에게 도움이 되지 않습니다.

일관성을 유지한다. 한 페이지에 각각 고유한 디자인과 타이밍을 가진 여러 항목을 로드하면 주의가 분산되고 너저분해 보입니다.

우리는 마지막 원칙을 충족시키기 위해 다양한 크기, 콘텐츠형 아이콘, 배경에 맞춰 디자인을 조정할 수 있도록 했습니다. 첫 번째와 두 번째 원칙의 경우, 여러 단계에 걸쳐 로더를 애니메이션으로 제공함으로써 충족시켰습니다. 즉, 처음에는 아무 것도 표시되지 않다가 중간에 애니메이션을 하나 보여준 다음, 마지막으로는 콘텐츠가 로드될 때까지 루프를 이루며 회전하는 스피너를 표시하는 것으로 마무리합니다. 따라서 콘텐츠 로드 시간이 0.5초 미만일 때는 로더가 전혀 표시되지 않고, 로드 시간이 3.5초를 꽉 채우지 않는 한 스피너는 반복하지 않습니다. 콘텐츠형 아이콘의 예

우리의 디자인은 세 가지 목표를 모두 만족시켰습니다. 즉, 인지 속도에 관해 고무적인 데이터를 얻었고, 디자인이 더욱 세련되게 바뀌었다고 확신하며, 독자가 무슨 내용이 표시될지 알 수 있도록 개선했습니다. 개발자를 위한 AMP의 유연성 유지를 위해 해결해야 할 몇 가지 추가적인 세부 사항이 있었습니다. 우리는 콘텐츠가 로드되기 전에 새로운 디자인 자리표시자 이미지, 메시지 또는 맞춤 로딩 표시기를 표시하는 AMP의 능력과 충돌하지 않도록 하고 싶었습니다. 단순한 자리표시자 이미지가 있는 콘텐츠의 경우, 우리는 여전히 표시될 내용이 더 있음을 독자에게 알리고 싶으므로 컬러 이미지로 눈에 잘 띄는 특별한 버전의 로딩 표시기를 화면에 띄울 것입니다. 메시지나 맞춤 로딩 표시기처럼, 그보다 더 복잡한 자리표시자의 경우에는 우리의 디자인이 개발자의 디자인과 충돌하지 않도록 기본 로더를 전혀 표시하지 않을 것입니다. 다양한 콘텐츠형 아이콘

우리는 앞으로 몇 주에 걸쳐 AMP 페이지 중 몇 퍼센트에 대해서만 제한적으로 새로운 로딩 표시기를 제공하는 라이브 실험을 진행하면서, 사이트 성능 통계뿐 아니라 커뮤니티 의견도 면밀히 주시하여 최종적으로 가다듬는 작업을 수행할 예정입니다. 우리의 목표는 이런 의견을 바탕으로 최종 확정된 새 로더를 모든 AMP 페이지의 모든 구성요소로 전개하는 것입니다. 새로운 디자인이 마음에 드시길 바라고, 한 번에 하나씩 작고 세부적인 사항을 차근차근 개선할 수 있도록 웹의 사용자 환경을 향상하는 데 아낌없는 성원을 보내주시면 고맙겠습니다.

AutoML로 문서 태깅 구현하기

2019년 9월 4일 수요일

.post-body span { white-space: normal !important; }

<블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 김택민(MachineLearning GDE)님이 참여해 주셨습니다>
기업에서 송장 처리, 애플리케이션 검토, 계약 분석 등의 작업을 지원하기 위해서는 사진, 문서, 메모 등 여러 유형의 컨텐츠를 디지털화하는 것이 선행되어야 합니다. Google Cloud에서는 고객이 컨텐츠를 디지털화할 수 있는 여러 방법을 제공합니다. 사전에 훈련된 머신러닝 API 를 사용할 수도 있고 AutoML Suite를 기반으로 Document Understanding AI를 적용할 수도 있습니다.
이번 글에서는 문서 처리를 목적으로 하는 Cloud AutoML 기반의 문서 태깅 (Document Tagging)에 대해서 알아보겠습니다. 문서 태깅은 문서에서 의미를 가지는 응답(혹은 값)이나 고객, 계좌 번호, 총액 등과 같은 필드(또는 태그)를 뽑아내어 키-값의 쌍의 형태로 구성하는 것을 의미합니다. 여기서 ‘태그’란 분석하고자 하는 항목이고 ‘값’은 그 태그에 대응하는 실제 결과입니다. 아래 예제를 통해 AutoML을 사용하여 문서 형태의 이미지에서 서명, 도장, 사각형 영역 등 문서 처리에 필요한 주요 정보를 뽑아보겠습니다.
기존의 솔루션
몇 년 전까지만 하더라도 문서를 디지털화한다는 것은 단순히 문서를 스캔하여 클라우드에 이미지 형태로 저장한다는 의미였습니다. 현재는 더 나은 도구와 기법들 특히, 머신러닝 덕분에 서류 뭉치들을 분석 가능한 구조적 데이터로 변환하고 이로부터 유용한 정보를 얻어낼 수 있습니다.
최근까지는 사전에 정의된 문서에 대해서만 정규 표현식이나 OCR 과 같은 규칙 기반 (rule-based)의 알고리즘을 사용하여 문서를 디지털화할 수 있었습니다. 새로운 형식의 문서에 대해서는 적용하기 어려울 수도 있고 키워드 매칭이나 텍스트 기반 NLP 모델에서 문제가 될 수도 있습니다. 물체 인식 (Object Detection) 및 개체 인식 (Entity Recognition)은 지난 몇 년간 많은 주목을 받았으며 이 분야에서 상당한 개선을 이루었습니다. Cloud AutoML이라고 불리는 AI 서비스 집합은 최소한의 머신러닝 지식만 가지고도 고객에게 고품질의 머신러닝 모델을 제공할 수 있습니다.
GCP 솔루션: 대규모의 AutoML 고유한 비즈니스 문제를 해결하는 모델을 만들기 위한 토대로 삼을 수 있는 폭넓고 다양한 AutoML 서비스가 있습니다. 예를 들어, 문서 디지털화의 경우 아래와 같은 구조를 가집니다.
cloud ai solutions suite.png

이런 형태의 구조는 쉽게 이해할 수 있을 뿐만 아니라 프로덕션 환경에 배포하기도 쉽습니다. 모든 구성 요소는 확장 가능하고 서버리스 (serverless) 형태이며, 기존 GCP를 기반으로 프러덕션 환경에서 사용 가능합니다.

태깅된 문서—이미 주석 처리된 데이터가 없으면 AI Platform Data Labeling Service를 사용할 수 있습니다.

OCR 및 객체 감지—Vision API와 최근에 AutoML 제품군에 추가된 AutoML Vision Object Detection으로 이 기능을 수행할 수 있습니다.

병합 및 특징 처리—간단한 Jupyter 노트북이나 Python을 기반으로 컨테이너화된 솔루션을 사용하는 것처럼, 이 기능을 수행할 수 있는 여러 가지 다른 방법이 있습니다.

개체 인식—최근에 AutoML 제품군에 추가된 AutoML Natural Language의 새로운 기능인 개체 추출을 사용하여 수행할 수 있는 기능입니다.

후처리—특징 처리와 비슷한 방식으로 수행할 수 있는 기능입니다.

전체 파이프라인은 Cloud Composer를 사용하여 구성하거나 Google Kubernetes Engine(GKE)을 사용하여 배포할 수 있습니다. 하지만 일부 비즈니스 제약 조건 (예: GCP에 대한 맞춤설정 내부 데이터화 파이프라인 빌드, 법률 문서에서 규칙 추출, 문서에서 민감한 정보를 수정한 후 파싱 등)에서는 위에 언급한 아키텍처 외에 개발할 수 있는 추가 맞춤설정이 필요합니다. 이와 같은 요구 사항에 관한 자세한 내용과 지원은 판매팀에 문의하실 수 있습니다.
값 생성 서로 다른 머신러닝 솔루션은 저마다의 비즈니스 혹은 기술적인 장점이 있고, 우리 고객 중 상당수가 이와 같은 솔루션을 사용하여 사용자 경험 개선, 운영 비용 절감, 전체 오류 감소 등의 다양한 목적을 달성해왔습니다. 이 글에서 설명하는 솔루션과 같이 의료, 금융 서비스 및 미디어 등 여러 분야에 적용될 수 있습니다. 예를 들어, 다음과 같은 사례들이 있습니다.

EHR (Electronic Health Records)에서 자동으로 지식 추출.

영수증에서 주요 키-값 쌍 생성.

금융 문서에서 필드 가져오기.

고객 불만 사항에 관한 텍스트 이해.

은행 수표, 전표 및 기타 데이터의 태그 지정.

다음 단계
딥러닝의 시대에는 전이 학습 (Transfer Learning)과 같이 훈련 과정을 간소화하는 방법이 점점 요구되고 있습니다. 이 글에서 소개한 문서 태그 지정도 수천 장의 이미지 없이도 문서를 디지털화할 수 있었으며 테스트를 거쳐 성공적으로 실무 환경에 배포되었습니다. 머신러닝 기반의 솔루션에서는 데이터 가변성은 여전히 중요한 요소이지만 AutoML은 자동적으로 기본적인 문제들을 해결해주고 수천 장 정도의 적은 이미지만 사용해서 모델을 훈련할 수 있습니다.
고객이 문서를 처리하도록 돕은 일은 전 세계의 정보를 정리하고 구성하여 누구든 손쉽게 접근하고 이를 유용하게 활용할 수 있도록 하겠다는 Google 사명에 완벽히 부합하는 일입니다. 이 글을 공유함으로써, 우리는 더 많은 조직에서 클라우드로의 전환을 고려하는 계기가 될 수 있으면 좋겠습니다. Cloud AutoML Vision, Cloud AutoML Natural Language, Cloud Storage와 같은 도구는 데이터셋을 구성하고 사용자 환경을 개선하는 데 도움이 될 수 있습니다. 이 글의 예제인 문서 태그 지정은 특정 문제에 대해 간단하고 대상이 정해진 문제입니다. 좀 더 다양하고 강력한 문서 처리 및 정보 추출 기술에 관해서는 Google의 Document Understanding AI 솔루션을 참고해주세요. AutoML은 파터사를 통해 솝쉽게 배포할 수 있고 별도의 머신러닝 지시기 없더라도 End-to-end Document Unerstanding AI 솔루션의 핵심 요소입니다. 당사 웹사이트에서 더 자세히 알아보실 수 있습니다.

안드로이드에서 더욱 똑똑한 애니메이션 만들기

원본에서 더욱 빠른 AMP: AMP + SSR = ⚡

기다리는 시간을 더 가치있게 만들기 : 새로운 AMP 로딩 표시기

AutoML로 문서 태깅 구현하기

Contents

검색

Tag

Archive

Feed