Google Developers Korea Blog

더 프라이빗한 웹 만들기: third party 쿠키를 사용하지 않는 방법

Thursday, January 23, 2020

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 조은(Web GDE)님이 참여해 주셨습니다>
게시자: Justin Schuh(Director of Chrome Engineering)
지난 8월, 우리는 웹에서의 개인정보 보호 수준을 근본적으로 향상하기 위한 표준 세트를 개발하고자 (Privacy Sandbox라는) 새로운 이니셔티브를 발표했습니다. 이 오픈 소스 이니셔티브를 통해 웹을 더 프라이빗하게 만들고 유저를 보호하며, 퍼블리셔도 지원하는 것이 목표입니다. 오늘 업데이트된 계획을 제시하고 웹 브라우징의 개인정보 보호 수준 향상을 위해 개발자 여러분에게 도움을 청하고자 합니다.
웹 커뮤니티의 다양한 구성원과 이야기를 나눈 후, 지속적인 개선과 의견 수렴 과정을 거치면서 개인정보 보존과 Privacy Sandbox 같은 오픈 스탠다드 메커니즘을 통해 third party 쿠키를 사용하지 않도록 하는 방식으로 건전하면서 광고 지원을 받는 웹을 지속시킬 수 있다는 확신을 얻었습니다.
이런 접근방식은 유저, 퍼블리셔, 광고주의 요구와 이어지며 차선책으로 이동하는 도구를 개발하여 Chrome에서 third-party 쿠키 지원을 단계적으로 중단하고자 합니다. 우리는 이 작업을 2년 내로 끝내고자 합니다. 하지만 우리만으로는 목표에 도달할 수 없으며, 생태계의 구성원 모두 이러한 제안에 적극적으로 동참해주셔야합니다. 올 해 말까지는 첫 시범 운영에 돌입할 계획으로, 전환율을 평가하여 개인이 설정하는 방식으로 진행하고자 합니다.
사용자들은 데이터 사용 방식에 대한 투명성, 선택의 자유를 포함 하여 더 강력한 개인정보 보호를 요구하고 있으며 이처럼 늘어나는 요구를 충족시키기 위해 웹 생태계가 진화해야한다는 점은 분명합니다. 일부 브라우저는 third-party 쿠키를 차단하여 이런 문제에 대응했지만 애초 의도와는 달리 사용자와 웹 생태계에 모두 부정적인 영향을 주는 결과로 귀결될 수 있다고 생각합니다. 쿠키에 단순한 접근 방식을 취하면 광고가 수익 모델인 많은 웹사이트 비즈니스 모델 기반이 악화되므로, 사용자의 개인정보 보호와 통제권을 실제로 약화시키는 디지털 지문 (쿠키를 대체하기 위해 널리 퍼진 차선책) 같은 불투명한 기술을 사용하도록 유도합니다. 우리는 커뮤니티로써 더 나은 방법으로 문제를 해결할 수 있고, 또 그래야 한다고 믿습니다.
다행히도, 우리는 W3C와 같은 포럼에서 Privacy Sandbox의 기초를 이루는 메커니즘이 주요 사용 사례를 대변하고 올바른 방향으로 가고 있다는 긍정적인 의견을 받았습니다. 이런 의견과 다른 표준 참가자로부터 받은 관련 제안을 통해, 우리는 이 공간에서의 솔루션이 효과를 발휘할 수 있으리라는 자신감을 얻습니다. 대안을 만들어 Flash와 NPAPI를 단계적으로 지원 중단하기 위해 표준 커뮤니티와 함께 일한 경험은 우리가 함께 힘을 합쳐 복잡한 문제를 해결할 수 있다는 사실을 입증해 주었습니다.
우리는 또한 현행 웹 기술이 더욱 안전하고 개인정보를 철저히 보호하는 기술이 되도록 하기 위한 노력을 계속해 나갈 것입니다. 이전에 발표했듯이, Chrome은 2월부터는 SameSite 라벨을 포함하지 않은 쿠키를 same-site 전용으로 취급함으로써 안전하지 않은 cross-site 추적을 제한할 예정이며, 현재 사이트용으로 라벨이 지정된 쿠키에는 HTTPS를 통해 액세스해야 하도록 조치할 것입니다. 그러면 third-party 쿠키가 더욱 안전해져 더욱 정밀한 브라우저 쿠키 제어 권한을 사용자에게 제공할 수 있을 것입니다. 그와 동시에, 우리는 이런 종류의 기만적이고 침입적인 기술을 사용하지 못하도록 하기 위한 새로운 디지털 지문 방지 대책을 실행함으로써 은밀한 추적과 우회 접근을 감지하고 저지하기 위한 기술을 개발하는 중이며, 올해 말에 이런 대책을 실행할 수 있기를 바랍니다.
우리는 브라우저, 게시자, 개발자 및 광고주가 이런 새로운 메커니즘으로 실험해보고 다양한 상황에서 효과가 있는지 테스트하고, 광고 선택 및 측정, 서비스 거부(DoS) 방지, 스팸/사기 방지, 페더레이션 인증을 포함하여 다양한 지원 구현 기술을 개발할 기회를 갖도록 생태계 전반에 걸쳐 능동적으로 일하고 있습니다.
우리는 더욱 신뢰할 만하고 지속 가능한 웹을 함께 빌드하고자 하며, 이를 위해서는 개발자 여러분의 지속적인 참여가 필요합니다. GitHub를 통해 웹 표준 커뮤니티 제안에 관한 의견을 적극적으로 개진해 주시고 귀하의 요구에 부응하는지 확인해 주시기 바랍니다. 미흡하다고 생각하시면, GitHub를 통해 문제를 제기하거나 W3C 그룹으로 이메일을 보내주세요. 웹에 의존해 비즈니스를 하는 분이라면, 기술 벤더가 이 프로세스에 참여하도록 하고 귀하의 이익을 대변하는 트레이드 그룹과 의견을 나누시기 바랍니다. 우리는 웹 브라우징의 개인정보 보호 수준을 높이기 위한 노력의 진척 상황을 누구나 확인할 수 있도록 계속 관련 정보를 게시하겠습니다.

개발자를 위한 새로운 SameSite=None; 보안 쿠키 설정에 대비하기

Tuesday, January 14, 2020

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 조은(Web GDE)님이 참여해 주셨습니다>

게시자: Barb Palser, Google Chrome and Web Platform Partnerships

지난 5월, Chrome은 새로운 쿠키 분류 시스템(스펙)에서 사용할 수 있는 쿠키에 대한 안전 기본 모델(secure-by-default)을 발표했습니다. 이 이니셔티브는 웹에서 개인정보 보호 및 보안을 개선하기 위한 우리의 노력 중 하나입니다.
Chrome은 2020년 2월에 릴리즈되는 Chrome 80 버전에 새 모델을 구현할 예정입니다. Mozilla와 Microsoft도 각자의 일정에 맞추어 Firefox와 Edge에 새 모델을 구현하겠다고 밝혔습니다. 아직 Chrome의 모델 변화까지 몇 달 남아있지만, 쿠키를 관리하는 개발자는 현재 준비 태세를 평가해보아야 합니다. 이 블로그 게시물에서는 높은 수준의 개념을 설명하며, 개발자 가이드는 web.dev의 SameSite Cookies Explained를 참고하세요. Cross-site, same-site 쿠키 컨텍스트 이해하기 웹사이트에서는 일반적으로 광고, 콘텐츠 추천, 서드 파티 위젯, 소셜 임베드 및 다른 기능을 위한 외부 서비스를 통합합니다. 웹을 탐색할 때 이러한 외부 서비스가 브라우저에 쿠키를 저장한 후 개인화된 환경을 제공하거나 고객 참여도를 측정하기 위해 해당 쿠키에 접근할 수 있습니다. 모든 쿠키에는 쿠키와 연결된 도메인이 있습니다. 쿠키와 연결된 도메인이 사용자 주소 표시줄에 표시된 웹 사이트가 아닌 외부 서비스와 일치하는 경우, 이 도메인은 cross-site(또는 “third party”) 컨텍스트로 다루어집니다.
덜 명확한 cross-site 사용 사례 중 하나로 여러 웹사이트를 소유한 엔티티가 같은 속성에 걸쳐 쿠키를 사용하는 상황이 있습니다. 비록 같은 엔티티가 쿠키와 웹사이트를 소유하고 있지만 쿠키의 도메인이 쿠키가 접근하는 사이트(들)와 일치하지 않을 때는 여전히 cross-site 또는 “third party" 컨텍스트로 다루어집니다.

웹 페이지 상의 외부 리소스가 사이트 도메인과 일치하지 않는 쿠키에 접근할 때, 이를 cross-site 또는 “third party" 컨텍스트라고 합니다.

반대로 same-site (또는 “first party") 컨텍스트에서 쿠키 접근은 쿠키의 도메인이 사용자 주소 표시줄에 표시된 웹사이트 도메인과 일치할 때 발생합니다. same-site 쿠키는 개별 웹사이트에 로그인한 사용자의 로그인 상태를 유지하고, 사용자의 기본 설정을 기억하거나 사이트 분석을 지원하는 데 널리 사용됩니다.

웹 페이지 상의 리소스가 유저가 접속한 사이트와 일치하는 쿠키에 접근한 경우, 이를 same-site 또는 “first-party” 컨텍스트라고 합니다.

쿠키 보안과 투명성을 위한 새로운 모델

현재, same-site 컨텍스트에서만 쿠키에 접근 가능하게 하기 위해, 개발자는 두가지 설정 중 (SameSite=Lax 또는 SameSite=Strict) 하나를 적용할 수 있습니다. 하지만 극소수의 개발자만 이 권장 사항을 따르므로 대부분의 same-site 쿠키가 cross-site 요청 위조 (CSRF) 공격 같은 위협에 불필요하게 노출됩니다.

더 많은 웹사이트와 유저들을 보호하기 위해 새로운 안전 기본 모델(secure-by-default)에서는 별도로 명시하지 않는 한 모든 쿠키를 외부 접근으로부터 보호하는 것으로 가정합니다. 개발자는 새로운 쿠키 설정인 SameSite=None 을 사용하여 cross-site 접근을 위한 쿠키를 설정해야합니다. SameSite=None 속성이 존재할 때 HTTPS 연결에서만 cross-site 쿠키를 사용하도록 추가로 Secure 속성을 사용해야합니다. 이를 통해 cross-site 접근과 관련한 위험이 완화되지는 않지만 네트워크 공격에 대한 보호 기능은 제공됩니다.

당장 눈에 보이는 보안 이점을 넘어서 cross-site 쿠키를 명시적으로 선언하면 더 나은 투명성과 유저 선택을 지원할 수 있습니다. 예를 들어 브라우저는 유저에게 여러 사이트 사이에 접근하는 쿠키와는 별개로 단일 사이트에서만 접근하는 쿠키를 관리하는 디테일한 제어 기능을 제공할 수 있습니다.

2020년 2월부터 Chrome에 적용됩니다.

Chrome에서는 2월 공개될 예정인 Chrome 80부터 SameSite 값을 선언하지 않은 쿠키를 SameSite=Lax 쿠키로 취급합니다. 보안 접속을 제공하는 경우에 SameSite=None; Secure 설정을 가진 쿠키에 접근하는 경우에만 외부 접근이 가능합니다. SameSite=None 및 Secure 에 대한 Chrome Platform Status 트래커는 최신 출시 정보에 맞추어 계속 업데이트될 것입니다.

Mozilla는 Firefox에서 cross-site 쿠키에 대한 SameSite=None; Secure 요구사항의 구현과 새로운 쿠키 분류 모델을 지원하겠다는 의사를 밝혔습니다. Microsoft는 최근 Microsoft Edge 80에 우선 실험적으로 이 모델을 구현하기 시작하겠다는 계획을 발표했습니다.

어떻게 준비해야하나요 - 이미 알려진 복잡한 작업들

Cross-site 쿠키를 관리하는 경우 SameSite=None; Secure 설정을 이러한 쿠키에 적용해야 합니다.

대부분의 개발자들에게는 구현이 간단하겠지만, 아래와 같은 복잡하고 특별한 케이스를 찾아내기 위해 지금 당장 테스트를 시작하는 걸 강력히 권장합니다

아직 None 값을 지원하지 않는 언어와 라이브러리가 있으므로, 쿠키 헤더에 개발자가 직접 None 값을 설정해야합니다. 이 Github 저장소에서는 다양한 언어, 라이브러리, 프레임워크에서 SameSite=None; Secure 구현을 위한 안내를 제공합니다.

일부 버전의 Chrome, Safari, UC Browser를 포함한 일부 브라우저에서는 None 값을 의도하지 않은 방식으로 처리할 수 있으므로 개발자가 이런 클라이언트를 위한 예외 케이스를 만들어야할 수 있습니다. 이전 버전의 Chrome을 사용하는 Android WebView가 이 케이스에 포함됩니다. 알려진 호환 불가능 클라이언트 목록을 확인해 보세요.

추후에 Android WebView에 새로운 쿠키 모델이 적용되겠지만, 앱 개발자는 HTTP(S) 헤더와 Android WebView의 CookieManager API를 사용해 접근하는 쿠키에 대해 모두 None 값을 지원하는 Chrome 버전을 기준으로 Android WebView에 알맞는 쿠키 설정을 해야합니다. 

SSO(Single Sign-On) 또는 내부 애플리케이션과 같은 일부 서비스가 2월 출시 일정에 맞춰 준비되지 않을 경우, 엔터프라이즈 IT 관리자는 Chrome 브라우저를 레거시 동작으로 임시로 되돌리기 위한 특별 정책을 구현해야 할 수도 있습니다.

first-party 와 third-party 컨텍스트에 모두 접근하는 쿠키가 있는 경우, same-site 컨텍스트에서 SameSite=Lax의 보안 이점을 누리기 위해 별개의 쿠키를 사용하는 방법을 고려할 수도 있습니다.

SameSite Cookies Explained에서 위와 같은 상황에 대한 구체적인 안내와 문제 제기 및 질문을 위한 채널을 제공합니다.

Chrome의 새로운 동작이 사이트 또는 쿠키에 미치는 영향을 테스트하려면 Chrome 76 이상에서 chrome://flags로 이동하여 'SameSite by default cookies' 및 'Cookies without SameSite must be secure' 실험실 기능을 사용할 수 있습니다. 또한 이런 실험실 기능은 Chrome 79 베타 사용자 중 일부에게는 자동으로 활성화됩니다. 실험실 기능이 활성화된 베타 버전의 일부 사용자는 아직 새 모델을 지원하지 않는 서비스를 사용할 때 비호환성 문제를 겪을 수도 있습니다. 그럴 때는 chrome://flags로 이동해 베타 실험실 기능을 비활성화하면 선택 해제할 수 있습니다.

Same-site 컨텍스트에서만 접근되는 쿠키(same-site 쿠키)를 관리하는 경우 개발자 측에서 필요한 조치 사항은 없습니다. SameSite 속성이 누락되었거나 아무런 값도 설정되어 있지 않더라도 Chrome이 외부 항목에서 이런 쿠키에 접근하지 못하도록 자동으로 차단할 것입니다. 하지만 모든 브라우저에서 same-site 쿠키를 기본적으로 보호하는 것은 아니므로, 알맞은 SameSite 값(Lax 또는 Strict)을 반드시 적용하고 브라우저의 기본 동작에 의존하지 않는 것이 좋습니다.

마지막으로, 웹사이트에 서비스를 제공하는 벤더와 다른 사업자의 준비 상태가 걱정될 경우, 필수 설정이 누락된 cross-site 쿠키가 페이지에 들어 있을 때 Chrome 77 이상에서 Developer Tools 콘솔에서 경고 를 확인할 수 있습니다.

(쿠키 도메인)에서 교차 사이트 리소스와 관련된 쿠키가 `SameSite` 속성 없이 설정되었습니다. Chrome의 향후 릴리스에서는 교차 사이트 요청이 `SameSite=None` 및 `Secure`로 설정되어 있는 경우 교차 사이트 요청으로만 쿠키를 제공합니다. 개발자 도구의 Application>Storage>Cookies에서 쿠키를 검토할 수 있으며, https://www.chromestatus.com/feature/5088147346030592 및 https://www.chromestatus.com/feature/5633521622188032에서 더 자세한 내용을 볼 수 있습니다.

(일부 Google 서비스를 포함한) 일부 공급자는 2월에 Chrome 80이 출시될 때까지 남은 몇 개월간 필요한 변경 사항을 구현할 것입니다. 파트너에게 연락해 그들의 준비 상황을 확인해 볼 수도 있을 것입니다.

제5회 구글플레이 인디 게임 페스티벌이 개최됩니다!

Thursday, January 9, 2020

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

국내 중소 게임 개발사의 해외 진출 및 비즈니스 경쟁력 강화를 지원하는 ‘제5회 구글플레이 인디 게임 페스티벌’이 개최됩니다!

구글플레이 인디 게임 페스티벌은 무한한 가능성을 지닌 국내 인디 게임 개발사를 발굴하고 건강한 모바일 게임 생태계 활성화를 지원하기 위해 지난 2016년 세계 최초로 한국에서 개최됐는데요. 이후 미국, 유럽, 동남아시아 등으로 프로그램이 확산됐습니다. 한국에서는 4회에 걸쳐 1,000여 개발사가 구글플레이 인디 게임 페스티벌에 참가해 무려 1,200개 이상의 게임을 출품했습니다!

한편 작년 구글플레이 인디 게임 페스티벌에서 Top 3 개발사로 선정된 ‘반지하게임즈(서울 2033: 후원자)’, ‘스튜디오 냅(카툰 크래프트)’, ‘핸드메이드 게임(룸즈: 장난감 장인의 저택)’은 국내외 시장에서 인디 게임의 혁신성과 저력을 보여주며 국내 인디 게임의 위상을 높이고 있는데요.
서울 2033: 후원자는 텍스트 기반의 어드벤처 게임이라는 독특한 장르로 많은 유저들에게 사랑받으며 구글플레이가 선정한 ‘2019 올해를 빛낸 인디 게임'에 선정됐습니다. 해외 유저 비율이 약 88%에 달하는 카툰 크래프트와 총 매출 중 해외 매출 비중이 약 60%를 차지하고 있는 룸즈: 장난감 장인의 저택은 국내뿐만 아니라 미국, 일본 등 해외 시장에서도 쾌거를 이루고 있습니다.
국내외에서 흥행을 거두며 승승장구하고 있는 세 개발사에게 앞으로도 많은 관심 부탁드립니다!
구글플레이 게임 액셀러레이터 어워드(Google Play Games Accelerator Awards) 신설
이번 인디 게임 페스티벌에서는 기존 Top 3, Top 10, Top 20 이외에 구글플레이 게임 액셀러레이터 어워드가 신설돼 개발사 혜택이 더욱 확대됐는데요.
Top 20 중 2개 개발사는 구글플레이 액셀러레이터 프로그램에 참여할 수 있는 기회를 얻어 6개월 간 구글 전문가로부터 개발 지원을 받게 됩니다. 구글플레이 액셀러레이터 프로그램은 높은 잠재력을 갖고 있는 중소 게임 개발사가 안드로이드 생태계에서 성장을 가속화할 수 있도록 지원하는 프로그램입니다.
이 프로그램의 일환으로 개발사는 미국 샌프란시스코와 싱가포르에서 진행되는 부트캠프에 초대돼 각각 1주일, 3일 동안 구글 및 게임 업계 전문가의 맞춤형 멘토링을 받을 예정입니다. 부트캠프에서는 게임 개발, 디자인, 비즈니스 개발, 유저 확보 및 수익화, 게임 테스팅 워크샵, 리더십 트레이닝 등 다양한 세션이 진행됩니다.
더욱 확대된 참여 기회...50인 이하 국내 게임 개발사 누구나 지원 가능
또한 올해는 보다 많은 국내 중소 게임 개발사의 참여를 독려하기 위해 인디 게임 페스티벌 참여 기회가 확대됐습니다. 기존 직원 30인 이하 기준에서 50인 이하 국내 게임 개발사로 확대됐으며 구글플레이에 게임을 출시하지 않아도 베타 버전으로 참가 신청이 가능합니다.
게임 유저 및 업계 전문가와 직접 소통할 수 있는 결승 이벤트
구글플레이 인디 게임 페스티벌 결승 이벤트는 오는 4월 25일 서울에서 개최됩니다!
혁신성, 재미, 디자인, 기술력과 품질을 기준으로 사전심사를 거쳐 선정된 Top 20 개발사는 결승 이벤트 현장 부스에서 유저와 업계 전문가들에게 직접 게임을 선보일 예정입니다. 당일 현장에서 일반 유저 심사위원단과 전문가 심사위원단의 투표를 통해 Top 10 개발사에게 프레젠테이션 기회가 주어지며, 프레젠테이션 후 심사위원단의 의견을 종합해 Top 3 개발사가 선정됩니다.
국내 중소 게임 개발사의 비즈니스 성장 및 해외 진출 돕는 체계적⬝실질적 혜택 제공
Top 20 개발사는 결승 이벤트 참여 기회와 함께 ▲구글 플레이스토어 내 ‘플레이 인디’ 및 ‘인디 게임 페스티벌 Top 20 특집’ 코너에 게임 소개 ▲유튜브 크리에이터 영상 내 게임 소개 ▲프레젠테이션 트레이닝 등의 혜택을 받습니다.
Top 10 개발사는 Top 20 개발사 혜택에 추가로 ▲구글 플레이스토어 ‘인디 게임 페스티벌 Top 10 특집’ 코너에 게임 소개 ▲플레이 인디 코너에 인디 게임 페스티벌 Top 10 수상자 개별 인터뷰 게재 ▲구글 전문가의 그룹 컨설팅을 제공받습니다.
최우수작으로 선정되는 Top 3 개발사에게는 구글플레이 게임 홈페이지 메인 배너⋅금주의 신규 추천 게임 콜렉션 등 구글 플레이스토어 내 다양한 노출 기회가 주어집니다. 또한 Top 10 개발사 혜택에 추가로 ▲플레이 인디 코너 내 에디터 추천 게재 ▲Top 3 개발사 별 유튜브 크리에이터 게임 소개 영상 제작 및 플레이 인디 코너 내 크리에이터 추천 게재 등 게임 홍보 마케팅 지원 ▲구글 전문가의 기술 및 비즈니스 맞춤 컨설팅 ▲최신 안드로이드 기기 1대 ▲게임 개발 지원금도 제공됩니다.
제5회 구글플레이 인디 게임 페스티벌 참가를 원하는 게임 개발사는 1월 9일 오후부터 3월 2일까지 공식 웹사이트를 통해 지원할 수 있습니다. Top 10과 Top 3 개발사는 4월 25일에 개최되는 결승 이벤트에서 선정될 예정입니다.참가 자격과 수상 혜택 등에 대한 더 자세한 내용은 제5회 구글플레이 인디 게임 페스티벌 웹사이트에서 확인해보세요! 올해에도 다양한 장르의 혁신적인 게임을 선보일 구글플레이 인디 게임 페스티벌에 많은 관심과 응원 부탁드립니다!

Google Play Indie Games Festival 2020이 곧 시작됩니다!

Monday, December 23, 2019

Google Play는 국내 중소 게임 개발사를 발굴하고 건강한 게임 생태계 활성화를 지원하기 위해 Indie Game Festival을 2016년부터 매년 개최하고 있습니다. Google Play Indie Game Festival 2020의 참가 신청은 2020년 1월 중 시작될 예정이며, 상세 일정은 추후 웹사이트 및 블로그/페이스북에 공지됩니다. 웹사이트에서 Indie Games Festival 2020에 대한 안내 메일을 신청하면 대회 오픈 및 일정에 대한 공지 메일을 받을 수 있습니다. 한국 중소 게임 개발사의 성장을 응원하는 Google Play Indie Game Festival 2020에 대한 많은 기대와 관심 부탁드립니다.

웹사이트 바로가기
페이스북 바로가기

TensorFlow Lite를 사용해서 몸동작 인식한 중국 국민체조 앱의 케이스를 소개합니다

Friday, November 29, 2019

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 송호연(MachineLearning GDE)님이 참여해 주셨습니다>
게스트 게시자: Keith Chan, Vincent Zhang(OliveX Engineering 팀 소속) 팔단금이란? 8가지 순서로 나뉘어진 단련 법을 의미하는 것으로서 중국에서 공식 공인된 운동법으로 현대 스트레칭의 효시로 불립니다.
소개 OliveX는 홍콩에 본사를 두고서 피트니스 관련 소프트웨어에 주력하는 회사로, 2018년 회사 창립 이래로 200만 명 이상의 사용자에게 서비스를 제공하고 있습니다. 사용자 대부분은 노년층이며, Baduanjin 앱은 사용자의 부상 가능성을 최소화하면서도 팔단금(Baduanjin)을 수련하도록 도와줍니다. 이런 목적을 달성하기 위해, 우리는 스마트폰 앱에 최신 인공지능 기술을 활용하여 팔단금 수련 동작을 자동으로 탐지하여 사용자에게 알맞은 피드백을 제공합니다. 목표와 요구사항 팔단금은 8가지 종류의 팔다리 동작과 호흡 조절법으로 이루어진 대중적인 운동입니다. 정신과 육체의 건강을 모두 개선해주는 팔단금 수련을 위해서는 정확한 동작과 호흡 조절이 매우 중요합니다.
몸동작을 취하는 애니메이션 인물

사용자는 'Smart Baduanjin' 앱을 통해 자신의 동작을 추적하는 AI를 사용하여 수련 동작을 올바로 취하고 있는지 확인할 수 있습니다. 우리는 최신 머신러닝 기술을 활용하여 사용자가 단순히 운동 동영상을 보고 따라서 운동하는 기존의 학습 방식을 사용자가 자신의 몸동작에 관한 피드백을 실시간으로 받으면서 보다 즐겁게 운동할 수 있는 대화식 환경으로 바꾸기를 바랍니다. 또한 이런 기능으로 노년층 유저들이 팔단금을 더 효과적으로 수련하고 부상 위험도 줄이는 데 도움이 될 수 있기를 희망합니다. ‘Smart Baduanjin’ 앱의 스틸 컷

우리는 목표를 분석하고 우선순위를 정한 후 다음과 같이 전반적인 제품 요구사항을 정의했습니다.

보통 실외에서 팔단금을 수련하면서 쓰는 용도이므로, 제품을 '모바일' 기반으로 만들 필요가 있음

팔단금을 수련할 때, 사용자는 보통 시연 동영상을 따라 동작을 취하면서 화면에 등장하는 코치의 동작을 모방하므로, 동영상을 소리와 함께 재생할 수 있는 제품이어야 함

사용자에게 귀중한 실시간 피드백을 제공하려면 전면 카메라로 사용자의 몸동작을 포착해야 함

특히 몸동작 인식에 관해, 우리는 알고리즘이 다음 작업을 수행하기를 바랍니다.

전체 수련 동작 순서에서 각각의 팔단금 동작 인식

사용자가 취하는 몸동작의 정확성을 기준으로 점수 부여

만족스럽지 못한 동작에 대한 교정 지도 기능 제공

기술 분석 ML 프레임워크 선택 위 요구사항을 바탕으로, 우리는 프로젝트 구현을 위해 적합한 딥 러닝 프레임워크를 선택해야 했습니다. 특히, 우리는 다음과 같은 특징을 가진 프레임워크를 찾고 있었습니다.

휴대기기를 위한 강력한 지원을 제공하고 중급부터 저급 스마트폰에서도 원활히 실행 가능함

친화적 API 디자인과 풍부한 디버깅 도구

성숙한 커뮤니티 지원과 리소스 사용 가능

우리는 종합적인 조사와 평가를 거친 후 TensorFlow Lite가 우리의 요구사항에 부합한다는 점을 깨달았습니다. 그 밖에도, Google은 인체의 다양한 포즈를 탐지하도록 특별히 디자인한 앱인 PoseNet을 오픈소스로 공개하고 TensorFlow.js를 기반으로 하는 데모 코드를 제공했습니다(편집자 주: 우리는 최근에 TensorFlow Lite를 기반으로 하는 PoseNet 샘플을 발표했음). Google은 우리가 오픈소스 코드의 도움을 받아 인체 포즈 인식을 위한 초기 작업을 완료하는 데 도움을 주었을 뿐 아니라, 우리의 동작 인식 알고리즘이 자바스크립트에서 훌륭한 성능을 발휘하므로 휴대기기에서 원활하게 작동할 수 있으리라는 확신도 주었습니다. 알고리즘 몸동작 인식 우리는 개발 초기 단계에서 기존의 몸동작 인식 알고리즘을 조사했습니다. 현재, 주류 알고리즘은 주로 순차적 동영상 프레임 분석을 기반으로 합니다. 이런 알고리즘이 우리의 요구사항을 충족할 수는 있겠지만, 네트워크가 상당히 복잡하고 이런 네트워크에서 추론을 실행하면 많은 계산 리소스가 소비됩니다. 하지만 휴대기기에서 모델을 실행해야 한다는 까다로운 요구사항이 있었으므로, 정확성과 성능 사이에서 절충점을 찾아야 했습니다.
우리가 택한 접근 방식은 PoseNet을 통해 주요 인체 관절을 먼저 포착한 다음, 인체 관절이 움직이는 순서를 기반으로 특정한 동작을 인식하는 것이었습니다. PoseNet은 17개의 인체 관절만 추적하므로, 전체 크기 이미지에 비해 계산량이 대폭 줄었습니다. 아래에서 알고리즘의 워크플로를 보여드리겠습니다. 우리는 먼저 PoseNet을 사용하여 입력 동영상에서 인체 관절 데이터를 추출한 다음, 인체 관절 데이터를 기반으로 동작을 분류했습니다. PoseNet을 사용하여 인체 관절을 포착하는 방법

주요 동작 기술적 접근 방식을 결정한 후에는 앱을 위해 인식할 주요 몸동작을 정의할 필요가 있었습니다. 우리는 이를 위해 몸동작 인식 문제를 전형적인 머신러닝 분류 문제로 변환했습니다. 아래는 주요 팔단금 동작을 정의한 방법의 샘플입니다. 주요 팔단금 동작 차트

우리는 일반적인 심층신경망을 훈련하여 사용자의 몸동작을 분류했습니다. 하이퍼 매개변수 조정과 훈련 데이터 최적화/확대를 여러 차례 반복한 후에 얻은 최종 모델은 아래 그림과 같이 훌륭한 정확도를 보여 제품 요구사항을 충족할 수 있었습니다. 정확도 및 동작 그래프

휴대기기에서 해결해야 할 난제 딥 러닝 모델을 완성한 후, 우리가 다음으로 밟은 단계는 iOS 및 Android 휴대기기에 모델을 배포하는 작업이었습니다. 처음에는 TensorFlow Mobile을 사용해보았습니다. 하지만 인식 결과를 실시간으로 얻어야 했는데 TensorFlow Mobile은 이 요구사항에 부합하는 성능을 발휘하지 못했기에 적합한 옵션이 아니었습니다.
우리가 성능 문제를 해결하려고 한창 애쓰던 무렵, Google은 성능 측면에서 TensorFlow Mobile보다 크게 향상된 TensorFlow Lite를 내놓았습니다. 이 두 솔루션을 아래와 같이 비교할 수 있습니다.
TensorFlow Mobile과 TensorFlow Lite를 비교하는 표

TensorFlow Mobile과 TensorFlow Lite를 비교하는 표

또한 아래 표는 모델에 대한 최초 벤치마크 결과를 나타낸 것입니다.

벤치마크 수치를 기준으로, 우리는 512x512 입력 크기를 기반으로 하는 대부분의 Android 기기에서는 실시간으로 몸동작을 인식할 수 없다는 결론을 내렸습니다. 이 문제를 해결하기 위해 머신러닝 모델을 프로파일링한 결과, PoseNet에 병목 현상이 발생해 계산 시간의 95%를 소비했다는 사실을 밝혀냈습니다. 그래서 우리는 PoseNet 입력 크기와 하이퍼 매개변수를 조정하고, 동작 인식 알고리즘을 다시 훈련하여 발생한 정확성 손실을 줄어든 입력 크기로 보상했습니다. 마침내, 우리는 Android에서 MobileNet을 위해 입력 크기로는 337x337 RGB, 너비 승수로는 0.5를 선택했습니다.
우리의 대상 사용자는 대부분 중장년층이므로, 주요 사용자가 대체로 저사양 기기를 보유한 경향이 있습니다. PoseNet 매개변수를 조정하여 성능을 개선했지만, 여전히 썩 만족스럽지는 않았습니다. 따라서 우리는 어느 스마트폰에나 있는 가속기인 GPU에 의지했습니다. Google에서 마침 그 무렵에 TensorFlow Lite GPU 대리자(시험용)를 내놓았는데, 우리는 그 덕분에 많은 엔지니어링 리소스를 절약했습니다.
모바일 GPU 덕분에 모델 실행이 현저히 가속화되었습니다. 사용자들 사이에서 인기 있는 여러 기기에서 벤치마크를 실시한 결과가 아래 표에 나와 있으며, GPU 대리자를 사용한 경우와 그렇지 않은 경우를 비교할 수 있습니다. 사용자들 사이에서 인기 있는 여러 기기에서 실시한 벤치마크 결과(GPU 대리자를 사용한 경우와 그렇지 않은 경우).

사용자들 사이에서 인기 있는 여러 기기에서 실시한 벤치마크 결과(GPU 대리자를 사용한 경우와 그렇지 않은 경우).

노년층 사용자의 팔단금 동작 움직임은 비교적 느리므로, TensorFlow Lite GPU 대리자(시험용)를 통합한 후 대부분의 기기에서 우리 제품이 원활하게 작동할 수 있었습니다.
애니메이션으로 구현한 팔단금 동작

결론 우리는 iOS와 Android에서 모두 Smart Baduanjin 제품을 성공리에 완성해 테스트에 참여한 사용자들로부터 호평을 받았습니다. 우리는 ML 기술과 TensorFlow를 활용하여 팔단금 초보자가 시연 동영상을 따라 동작을 익힐 수 있도록 하기 위한 '가이드 모델'을 제공했습니다. 우리는 숙련된 팔단금 수련자가 실력을 더욱 키울 수 있도록 점수와 같은 소중한 피드백을 제공했습니다. 현재, ‘Smart Baduanjin’은 App Store와 Google Play에서 모두 무료로 제공됩니다. 한편, OliveX는 다른 피트니스 운동에 인체 포즈 추정을 적용할 방법을 적극적으로 연구하고 있습니다. 우리는 수련자 몸동작의 정확성이 매우 중요하다는 점에서 다른 많은 운동 수련 역시 팔단금과 마찬가지라는 점을 깨달았습니다. 올바른 몸동작은 신체 부상을 방지할 뿐 아니라, 운동의 효율성을 높이는 데도 도움이 됩니다. 따라서 우리는 팔단금 프로젝트에서 얻은 지식과 기술을 다른 영역에도 이전하고 싶습니다.

프로덕션 환경에서 실제로 사용되는 머신러닝, TensorFlow Extended(TFX)에 대해 소개합니다

Thursday, November 21, 2019

.post-body span { white-space: normal !important; } 게시자: Robert Crowe, Konstantinos (Gus) Katsiapis, Kevin Haas(TFX 팀을 대표해 게시함)

사람들은 머신러닝에 대해 생각할 때, 보통은 지금 만들 수 있는 훌륭한 모델에 대해서만 생각합니다. 결국, 대다수 연구 논문에서 초점을 맞춰 설명하는 내용이기도 합니다. 하지만 그런 멋진 모델을 실제 사용 환경에서 사용할 수 있도록 하고 싶다면 모니터링, 신뢰성, 유효성 검사 등, 프로덕션 솔루션에 필요한 모든 사항에 대해 생각해봐야 합니다. 그게 바로 Google에서 TensorFlow Extended(TFX)를 만들어 우리의 머신러닝(ML) 파이프라인을 위한 프로덕션 수준의 지원을 제공하는 이유입니다. 우리는 모든 곳의 개발자가 프로덕션 수준 TFX 파이프라인을 통해 모델을 만들고 배포할 수 있도록 오픈소스 커뮤니티와 함께 TFX를 공유하고 있습니다.
Google은 TFX가 필요했기 때문에 TFX를 만든 것이며, 그 전에는 우리의 요구를 충족시켜 줄 만한 것이 없었습니다. Google, 좀 더 일반적으로 Alphabet은 대부분의 자사 제품에 ML을 광범위하게 사용합니다. 사실, Google이 만든 최초의 ML 파이프라인 프레임워크는 TFX가 아니었습니다. TFX는 이전부터 이루어진 여러 차례의 시도를 통해 진화한 결과물로, 지금은 Google의 대다수 ML 프로덕션 솔루션을 위한 기본 프레임워크가 되어 있습니다. TFX는 Google 이외에 Twitter, Airbnb, PayPal을 비롯한 우리 파트너들에게도 깊은 영향을 미쳤습니다. 단순히 ML만의 문제가 아닌 TFX 애플리케이션에 ML을 결합할 계획을 세우기 시작할 때, 일반적으로 ML에 대해 생각할 수 있는 모든 사항을 고려할 것입니다. 지도 학습을 수행할 경우에는 라벨을 지정한 데이터를 가져오고 데이터셋에 가능한 입력 데이터를 위한 공간이 충분히 확보되어 있는지 확인하는 등의 작업이 여기에 포함됩니다. 또한 피쳐셋에 포함되는 예측 정보는 최대화하면서도 피쳐셋의 차원은 최소화하고 싶을 것입니다. 공정성에 대해 생각해보고 애플리케이션이 불공정하게 편향되지 않도록 해야 합니다. 드물게 발생할 뿐이지만 중요한 상황이 벌어지는 조건에 대해 예측할 수 있는 헬스케어와 같은 애플리케이션에서는 특히 드물게 발생하는 조건도 고려해야 합니다. 마지막으로, 이런 애플리케이션은 시간이 흐르면서 새로운 데이터가 유입되고 조건이 바뀜에 따라 진화하는, 살아 있는 솔루션이 될 것이라는 점을 염두에 두고 데이터의 수명 주기 관리를 계획해야 합니다. 하지만 그 모든 점 외에도, 소프트웨어 애플리케이션을 프로덕션 환경에 적용한다는 점을 잊어선 안 됩니다. 즉, 안전과 보안뿐 아니라 확장성, 일관성, 모듈성, 테스트 가능성을 비롯하여, 어떤 프로덕션 소프트웨어 애플리케이션이라도 가지고 있는 모든 요구사항이 그대로 적용된다는 뜻입니다. 이제는 모델을 단순히 훈련하는 차원을 훌쩍 넘어섰습니다! 이런 문제는 그 자체로 모든 프로덕션 소프트웨어 배포 시에 맞이하게 되는 해결 과제이며, ML을 수행한다는 이유만으로 잊어도 되는 문제가 아닙니다. 어떻게 이 모든 요구를 충족시키고 새롭고 놀라운 모델을 프로덕션 환경에 적용해야 할까요? 그 해답은 바로 TFX입니다. TFX를 사용하면 프로덕션 소프트웨어 배포와 모범 사례에 대한 요구사항 중 다수를 포함하는 프로덕션 ML 파이프라인을 만들 수 있습니다. 이는 데이터를 내부 데이터화하는 단계부터 시작해 데이터 유효성 검사, 특징 추출, 훈련, 평가, 서빙의 순서로 흘러갑니다. TensorFlow 자체 외에, Google은 ML 파이프라인의 각 주요 단계를 위한 라이브러리인 TensorFlow Data Validation, TensorFlow Transform, TensorFlow Model Analysis도 만들었습니다. 또한 서버 팜(TensorFlow Serving), 네이티브 모바일 애플리케이션(TensorFlow Lite), 자바스크립트 애플리케이션(TensorFlow JS)을 비롯한 다양한 배포 대상을 위한 프레임워크도 만들었습니다. TFX는 라이브러리를 활용하는 일련의 파이프라인 구성 요소를 구현하고, 개발자가 자체적인 구성 요소를 만들 수도 있도록 허용합니다. 이 모든 것을 함께 연계하기 위해, Google은 파이프라인 저장, 구성 및 오케스트레이션과 같은 작업을 위한 몇 가지 수평적 계층을 만들었습니다. 이런 계층은 파이프라인과 파이프라인에서 실행하는 애플리케이션을 관리하고 최적화하는 데 실로 중요합니다. 프로덕션 환경의 ML은 많은 도전적 과제를 안겨주는데, Google은 그에 대한 모든 해법을 가지고 있는 것처럼 행세하지 않습니다. TFX는 ML 커뮤니티에서 계속 발전하고 진화하는 분야이며, 이러한 발전에 대한 기여를 적극적으로 환영합니다. 프로덕션 환경에서 머신러닝이 안고 있는 난제에 대한 개요를 훌륭하게 설명한 이 논문을 참조하시기 바랍니다. '파이프라인'과 '구성 요소'란 무엇일까요? TFX 파이프라인은 각각 다른 작업을 수행하는 구성 요소의 시퀀스로 생성됩니다. 구성 요소는 'DAG', 즉 Directed Acyclic Graph로 구성됩니다. 하지만 정확히는 어떻게 구성되어 있을까요?

TFX 구성 요소로는 driver, executor, publisher라는 세 가지 주요 부분이 있습니다. 이들 중 드라이버와 publisher의 두 부분은 주로 변경할 수도 있지만 아마도 절대 그럴 필요가 없을 상용구 코드입니다. 개발자가 실제로 자신의 코드를 삽입하고 사용자 설정을 하는 부분은 바로 executor입니다.
driver는 실제 환경의 상태를 검사하여 어떤 작업을 수행해야 할지 결정함으로써 작업 실행을 오케스트레이션하고 executor에게 메타데이터를 피드합니다. publisher는 executor의 결과를 받아 메타데이터 저장소를 업데이트합니다. 하지만 executor는 실제로는 각 구성 요소에 대한 작업이 수행되는 곳입니다.
그래서 첫째, 구성 요소에 대한 구성이 필요하고 TFX에서는 Python을 사용하여 그런 구성이 수행됩니다. 다음으로, 구성 요소에 대한 입력과 결과를 보낼 장소가 필요합니다. 바로 메타데이터 저장소가 그 역할을 합니다. 메타데이터 저장소에 관해 좀 더 자세히 설명하겠지만, 지금은 대부분의 구성 요소에 대해서는 입력 메타데이터가 메타데이터 저장소에서 오고 결과 메타데이터가 메타데이터 저장소에 다시 기록된다는 점만 알아두시기 바랍니다.

데이터가 파이프라인을 통해 이동함에 따라, 구성 요소는 이전의 구성 요소에서 생성된 메타데이터를 읽고, 파이프라인의 하부에 있는 구성 요소에서 사용하게 될 메타데이터를 작성합니다. 파이프라인의 시작 및 끝에서처럼 몇 가지 예외는 있지만, 대다수의 부분에서는 데이터가 위와 같은 방식으로 TFX 파이프라인을 통해 흐릅니다.
TFX 파이프라인 오케스트레이션 이 모든 구성 요소를 구성하고 이런 파이프라인을 관리하려면 오케스트레이션이 필요합니다. 그런데 오케스트레이션이란 정확히 무엇이고 오케스트레이션이 어떤 도움이 되는 걸까요? ML 파이프라인을 만들고 그 파이프라인을 구성하는 구성 요소의 시퀀스를 정의하고 그 실행을 관리하려면 오케스트레이터가 필요합니다. 오케스트레이터는 작업을 트리거하고 구성 요소를 모니터링하는 데 사용할 수 있는 관리 인터페이스를 제공합니다. 파이프라인의 다음 단계를 시작하기만 하면 될 경우에는 작업을 인식하는 아키텍처로 충분합니다. 이전의 구성 요소가 작업을 마치자마자 다음 구성 요소를 곧바로 시작할 수 있습니다. 하지만 작업과 데이터를 인식하는 아키텍처는 훨씬 더 강력하며, 수많은 실행이 이루어지는 동안 모든 구성 요소로부터의 모든 아티팩트를 저장하므로 실제로 어떤 프로덕션 시스템에 대해서도 거의 필수적인 요건이라 할 수 있습니다. 바로 그 메타데이터를 확보하면 훨씬 더 강력한 파이프라인이 생성되고, 만약 메타데이터를 확보하지 못했더라면 매우 어려웠을 많은 일들이 가능해지므로, TFX는 작업과 데이터를 인식하는 파이프라인 아키텍처를 구현합니다. 개방적이고 확장 가능한 TFX를 구현하는 방법 중 하나는 오케스트레이션을 사용하는 것입니다. Google은 별도의 구성 없이 바로 사용 가능한 Apache Airflow와 Kubeflow를 위한 지원을 제공하지만, 필요하다면 다른 오케스트레이터를 사용하기 위한 코드를 작성할 수 있습니다. 마음에 드는 워크플로 엔진이 이미 있다면, TFX와 함께 그 엔진을 사용하도록 실행기를 빌드할 수 있습니다.
왜 메타데이터를 저장해야 할까요? TFX는 ML 파이프라인을 위한 메타데이터를 정의하고 저장하고 쿼리하기 위한 오픈소스 라이브러리인 ML-Metadata(MLMD)를 사용하여 메타데이터 저장소를 구현합니다. MLMD는 관계형 백엔드에 메타데이터를 저장합니다. 현재 구현에서는 별도의 구성 없이 SQLite 및 MySQL을 바로 사용할 수 있도록 지원하지만, 기본적으로 어떤 SQL 호환 데이터베이스에 대해서든 ML-Metadata를 확장하는 코드를 작성할 수 있습니다. 그렇지만 메타데이터 저장소에 정확히 무엇을 저장하는 것일까요? 첫째, 개발자가 훈련한 모델에 관한 정보, 개발자가 모델을 훈련할 때 사용한 데이터, 그리고 평가 결과를 저장합니다. 우리는 이런 유형의 메타데이터를 '아티팩트'라고 지칭하는데, 아티팩트에는 속성이 있습니다. 데이터 자체는 데이터베이스 외부에 저장되지만, 데이터의 속성과 위치는 메타데이터 저장소에 보관됩니다. 다음으로, 우리는 각 구성 요소가 실행될 때마다 해당 실행 기록을 보관합니다. ML 파이프라인은 긴 수명에 걸쳐 새로운 데이터가 들어오거나 조건이 변경됨에 따라 수시로 실행되므로, 해당 기록을 보관하는 것이 디버깅, 재현 및 감사에 중요하게 됩니다. 마지막으로, 우리는 데이터 객체가 파이프라인을 따라 흐를 때 데이터 객체의 계보 또는 출처도 포함합니다. 따라서 파이프라인을 통해 전후로 추적하여 데이터와 코드의 변경에 따른 구성 요소의 출처와 실행 결과를 파악할 수 있습니다. 이는 파이프라인의 최적화나 디버그가 필요할 때 실로 중요하며, 이것이 없다면 최적화나 디버그에 상당한 어려움이 있을 것입니다.
메타데이터로 작동되는 기능 이제 메타데이터 저장소에 무엇이 저장되는지 알게 되었으므로, 이 저장소에서 얻는 기능상 이점에 대해 살펴봅시다. 첫째, 모든 데이터 아티팩트의 계보와 출처를 알고 있으면 파이프라인에서 앞쪽과 뒤쪽으로 추적할 수 있습니다. 예를 들어 모델을 훈련할 때 어떤 데이터를 사용했는지, 새로운 특징 추출이 평가 측정항목에 어떤 영향을 미쳤는지 등을 파악할 수 있습니다. 일부 사용 사례에서는 데이터의 출처와 결과를 추적하는 이 기능이 규정이나 법률에 정해진 필수 요건인 경우도 있습니다. 이 기능은 현재의 모델이나 현재의 결과를 위한 것만은 아니라는 점을 기억하세요. 시간이 흐르면서 새로운 데이터를 가져와 모델을 다시 훈련할 때 데이터와 결과가 어떻게 바뀔지 파악하는 데도 관심 있으실 것입니다. 종종 어제나 지난주에 실행한 모델 실행 결과와 비교해 결과가 개선되거나 악화된 이유를 알고 싶을 것입니다. 프로덕션 솔루션은 일회용이 아니라 필요한 만큼 오랫동안 사용되므로, 몇 개월이나 몇 년의 수명을 가질 수 있습니다. 또한 필요할 때만 구성 요소를 다시 실행하고 웜 부팅을 사용하여 훈련을 계속함으로써 파이프라인을 훨씬 더 효율적으로 만들 수도 있습니다. 개발자는 실행에 몇 시간이나 며칠이 걸릴 수 있는 큰 데이터세트를 종종 다루게 된다는 점을 유념하세요. 이미 하루 동안 모델을 훈련했는데 좀 더 훈련하고 싶은 경우 처음부터 다시 시작하는 대신 직전에 훈련을 끝낸 부분부터 시작할 수 있습니다. 메타데이터에 모델에 관한 정보를 저장해두었다면 훨씬 더 쉽습니다. 또한 입력 또는 코드가 바뀌었을 때 파이프라인의 다른 구성 요소만 다시 실행하여 이들을 훨씬 더 효율적으로 만들 수도 있습니다. 구성 요소를 다시 실행하는 대신, 캐시에서 이전 결과를 그냥 끌어올 수 있습니다. 예를 들어 파이프라인을 새로 실행할 때 훈련자의 매개변수만 변경되는 경우에는 파이프라인이 어휘와 같은 데이터 전처리 아티팩트를 재사용할 수 있으며, 데이터 볼륨이 크면 데이터 전처리 비용이 비싸다는 점을 고려하면 이를 통해 많은 시간을 절약할 수 있습니다. TFX와 MLMD를 사용할 때 별도의 구성 없이 이런 재사용이 가능한데, 더 간단한 '파이프라인 실행' 인터페이스가 표시되며 실행할 구성 요소를 수동으로 선택하는 문제를 걱정할 필요가 없습니다. 이 점 역시 처리 시간을 단축하는 데 도움이 됩니다. 구성 요소의 입력 데이터와 결과를 메타데이터에 저장했다면 훨씬 더 쉬울 것입니다.
구성 요소? 어떤 종류의 구성 요소일까요? 이제 오케스트레이터가 있으므로, TFX에 기본으로 제공되는 구성 요소에 대해 얘기해봅시다. 하지만 먼저 Apache Beam에 대해 얘기해봅시다. Apache Beam에 대해 먼저 설명한 후 기본 구성 요소에 대해 설명하겠습니다. 대량의 데이터, 특히 ML 작업 부하와 같은 계산 집약적 데이터의 분산 처리 문제를 다루려면 Apache Spark, Apache Flink 또는 Google Cloud Dataflow와 같은 분산 처리 파이프라인 프레임워크가 필요합니다. TFX 구성 요소는 대부분 여러 실행 엔진에서 실행 가능한 통합 프로그래밍 모델인 Apache Beam 상에서 실행됩니다. Beam 덕분에 개발자가 이미 가지고 있는 분산 처리 프레임워크를 사용하거나, 우리가 선택한 분산 처리 프레임워크를 강제로 사용하지 않고 개발자가 원하는 프레임워크를 선택할 수 있습니다. 현재, Beam Python은 Flink, Spark 및 Dataflow 실행기에 실행할 수 있지만, 새로운 실행기가 추가되고 있습니다. 또한 직접 실행기도 포함하고 있는데, 이 실행기를 사용하면 노트북과 같은 로컬 시스템에서 개발 중인 TFX 파이프라인을 실행할 수 있습니다. 기본 구성 요소

TFX는 처음 설치할 때 완벽히 구비된 기본 구성 요소 집합을 포함하는데, 각 구성 요소는 프로덕션 ML 파이프라인의 각기 다른 부분에 맞춰 설계되었습니다. 예를 들어 Transform 구성 요소는 Apache Beam을 사용하여 어휘를 생성하거나 기본 구성 요소 분석(PCA)을 실행하는 등, 특징 추출 변환을 수행합니다. 이와 같은 변환은 Dataflow를 사용하여 Flink나 Spark 클러스터 또는 Google Cloud에서 실행할 수 있습니다. Apache Beam의 이식성 덕분에, 코드를 변경하지 않고 이들 사이에서 이전할 수 있습니다. Trainer 구성 요소는 TensorFlow만 사용합니다. 놀라운 모델을 만들어 훈련할 생각만 하던 때를 기억하시나요? 그게 바로 여기서 사용할 코드입니다. 현재, TFX는 tf.estimators만 지원합니다. 호환성에 관한 다른 정보는 여기에 나열되어 있습니다. 어떤 구성 요소는 무척 단순합니다. 예를 들어 Pusher 구성 요소는 Python만 있으면 주어진 작업을 수행할 수 있습니다. 이 모든 것을 한데 모아서 오케스트레이터로 관리하면 TFX 파이프라인을 가지게 되는 것입니다. 한쪽에서는 데이터를 내부 데이터화하고 다른 쪽에서는 SavedModel을 배포 대상 중 하나 이상으로 푸시합니다. 여기에는 TensorFlow Hub, TensorFlow JS를 사용하는 자바스크립트 환경, TensorFlow Lite를 사용하는 네이티브 모바일 애플리케이션, TensorFlow Serving을 사용하는 서버 팜, 또는 위 모든 것이 포함됩니다. 이제 이들 각 구성 요소를 좀 더 자세히 살펴봅시다. 데이터 읽어오기 먼저 ExampleGen을 사용하여 입력 데이터를 내부 데이터화합니다. ExampleGen은 Beam에서 실행되는 구성 요소 중 하나입니다. 이 구성 요소는 지원되는 다양한 소스와 유형에서 데이터를 읽어와 훈련과 평가로 분할하고 tf.examples 형식으로 지정합니다. ExampleGen을 위한 구성은 매우 간단한데, 단 두 줄의 Python 코드에 불과합니다. 다음으로, StatisticsGen은 Beam을 사용하여 데이터를 완전히 한 차례 통과하는 것을 하나의 완전한 epoch로 만들고 각 특징에 대해 설명적인 통계 수치를 계산합니다. 이를 위해 StatisticsGen은 Jupyter 노트북에서 실행할 수 있는 시각화 도구를 위한 지원을 포함하는 TensorFlow Data Validation(TFDV) 라이브러리를 활용합니다. 이를 통해 데이터를 탐색하여 이해하고, 있을지 모를 문제를 찾을 수 있습니다. 이는 전형적인 데이터 랭글링 작업으로, 우리 모두가 모델을 훈련하기 위해 데이터를 준비할 때 수행하는 것과 같은 일입니다. 그 다음 구성 요소인 SchemaGen 역시 TensorFlow Data Validation 라이브러리를 사용합니다. 이 구성 요소는 StatisticsGen에 의해 생성된 통계 정보를 살펴보고 특징 값의 데이터 형식, 값의 범위, 카테고리를 포함하여, 특징의 기본 속성에 대한 추론을 시도합니다. 필요에 따라 스키마를 검사하고 오케스트레이션해야 합니다(예: 표시될 것으로 기대하는 새 카테고리 추가). 그 다음 구성 요소인 ExampleValidator는 StatisticsGen과 스키마(SchemaGen의 출력이거나 사용자 큐레이션의 결과일 수 있음)에서 통계 정보를 받으며 문제가 있는지 찾아봅니다. 이 구성 요소는 누락된 값 또는 스키마와 일치하지 않는 값, 훈련/서비스 제공 간의 편중, 데이터 드리프트를 포함한 다양한 이상 클래스를 찾으며, 찾은 내용에 대한 보고서를 생성합니다. 항상 새 데이터를 받게 되므로 문제가 발생할 때 이를 알아차려야 합니다. 특징 추출 Transform은 더 복잡한 구성 요소 중 하나로, 더 많은 구성뿐 아니라 추가 코드도 필요합니다. Transform은 Beam을 사용하여 특징 추출을 수행하는데, 특징에 변환을 적용해 모델의 성능을 향상합니다. 예를 들어 Transform은 어휘를 생성하거나 값을 분류하거나 입력에 대해 PCA를 실행할 수 있습니다. 개발자가 작성하는 코드는 모델과 데이터세트를 위해 어떤 특징 추출을 수행해야 하느냐에 따라 결정됩니다. Transform은 데이터를 완전히 한 차례 통과하는 것을 하나의 완전한 epoch로 만들고 두 가지 다른 종류의 결과를 생성합니다. 모든 예제에 대해 동일한 숫자인 특징의 중앙값 또는 표준편차 계산과 같은 작업의 경우, Transform은 상수를 출력합니다. 예제마다 다른 값을 정규화하는 것과 같은 작업의 경우, Transform은 TensorFlow Op를 출력합니다. 그런 다음, Transform은 이러한 상수 및 연산자를 이용해 TensorFlow 그래프를 출력합니다. 그래프는 밀폐되어 있으므로, 그와 같은 변환을 적용하는 데 필요한 모든 정보를 담고 있고 모델을 위한 입력 단계를 형성하게 됩니다. 즉, 훈련과 서비스 제공 사이에 동일한 변환이 일관되게 적용되어 훈련/서비스 제공의 편중을 없애준다는 뜻입니다. 대신에 훈련 환경에서 서비스 제공 환경 또는 애플리케이션으로 모델을 이동하고 두 장소에서 모두 같은 특징 추출을 적용하려는 경우 변환이 똑같기를 바라겠지만 때로는 똑같지 않다는 사실을 발견하게 됩니다. 우리는 그런 상황을 훈련/서비스 제공의 편중이라 부르는데, Transform은 개발자가 모델을 실행하는 어디서든 정확하게 같은 코드를 사용하여 이런 편중을 제거합니다. 모델 훈련 이제는 최종적으로 모델을 훈련할 준비를 마쳤으며, 모델 훈련은 전체 프로세스에서 사람들이 머신러닝을 생각할 때 흔히 떠올리게 되는 부분입니다. Trainer는 Transform에서 변환 그래프와 데이터를 가져오고 SchemaGen에서 스키마를 가져온 후, 작성한 모델링 코드를 사용하여 모델을 훈련합니다. 이것이 일반적인 모델 훈련이지만, 훈련이 완료되면 Trainer는 두 가지 다른 SavedModel을 저장합니다. 하나는 프로덕션 환경에 배포되는 SavedModel이고, 다른 하나는 모델의 성능 분석에 사용할 EvalSavedModel입니다. 단계 수나 웜 부팅의 사용 여부와 같은 Trainer를 위한 구성을 예상하실 것입니다. Trainer를 위해 만드는 코드가 모델링 코드이므로, 필요한 만큼 단순하거나 복잡하게 만들 수 있습니다. 훈련 프로세스를 모니터링하고 분석하려면 일반적인 방법과 똑같이 TensorBoard를 사용할 수 있습니다. 이 경우에는 현재 모델 훈련의 실행을 보거나 여러 차례의 모델 훈련 실행에서 얻은 결과를 비교할 수 있습니다. 이는 위에서 설명한 ML-Metadata 저장소이기에 가능한 일일 뿐입니다. TFX를 사용하면 이런 종류의 비교 작업을 상당히 수월하게 수행할 수 있다는 점을 자주 확인할 수 있습니다. 충분히 좋은가요? 모델 훈련을 마쳤는데, 결과가 어때 보입니까? Evaluator 구성 요소는 Trainer가 생성한 EvalSavedModel과 원본 입력 데이터를 받아 Beam과 TensorFlow Model Analysis 라이브러리를 사용하여 심층 분석을 수행합니다. 이는 전체 데이터세트에서 최상위 레벨 결과만 살펴보는 것이 아니라, 데이터세트의 개별 조각 수준에서 그보다 더 깊은 곳을 들여다보는 것입니다. 이는 모델의 각 사용자의 사용 환경이 개별 데이터 요소에 따라 결정되므로 중요한 사항입니다. 모델이 전체 데이터세트에서 잘 돌아갈 수도 있겠지만, 모델이 사용자가 제공하는 데이터 요소에서 제대로 작동하지 않을 경우 사용자 환경 역시 열악해집니다. 이 점에 대해서는 다음 게시물에서 자세히 다루겠습니다. 이제 모델의 성능도 살펴보았는데, 그대로 프로덕션 단계로 진행해야 할까요? 이미 프로덕션 환경에 있는 모델보다 나은가요, 아니면 못한가요? 단순히 새 모델이라는 이유로 성능이 나쁜 모델을 프로덕션 단계로 푸시하고 싶지는 않을 것입니다. 그래서 ModelValidator 구성 요소가 Beam을 사용해 앞서 설명한 비교 작업을 수행하는데, 개발자가 정의한 기준에 따라 새 모델을 프로덕션 단계로 푸시할지 여부를 결정합니다. ModelValidator가 새 모델이 프로덕션 단계로 넘어갈 준비가 되었다고 판단할 경우에는 Pusher가 모델을 배포 대상으로 실제로 푸시하는 작업을 수행합니다. 그와 같은 대상은 모바일 애플리케이션을 개발 중인 경우에는 TensorFlow Lite가 될 수 있고, 자바스크립트 환경에 배포 중인 경우에는 TensorFlow JS가 될 수 있으며, 서버 팜에 배포 중인 경우에는 TensorFlow Serving이 될 수 있습니다. 또는 위의 모두가 될 수도 있습니다. 이젠 어디로 가야 할까요? TFX 및 ML 파이프라인의 일반적인 기본 개요를 제공하고 주요 개념을 소개하는 것이 이 게시물의 목표였습니다. 이어지는 게시물에서는 필요에 따라 TFX를 확장할 수 있는 방법에 대한 논의를 비롯해, TFX에 대해 더 깊이 알아보도록 하겠습니다. TFX는 오픈소스이므로, Google에서는 소프트웨어 및 ML 커뮤니티에서 TFX의 개선에 도움을 받길 기다리고 있습니다. TFX 개발자 가이드도 참고해보세요. 관련 주제 TensorFlow Extended: 머신러닝 파이프라인과 모델의 이해(Google I/O’19) TFX: TensorFlow 기반 프로덕션 스케일의 머신러닝 플랫폼(KDD 2017) YouTube에 소개된 TFX

더 프라이빗한 웹 만들기: third party 쿠키를 사용하지 않는 방법

개발자를 위한 새로운 SameSite=None; 보안 쿠키 설정에 대비하기

제5회 구글플레이 인디 게임 페스티벌이 개최됩니다!

Google Play Indie Games Festival 2020이 곧 시작됩니다!

TensorFlow Lite를 사용해서 몸동작 인식한 중국 국민체조 앱의 케이스를 소개합니다

프로덕션 환경에서 실제로 사용되는 머신러닝, TensorFlow Extended(TFX)에 대해 소개합니다

Tag

Archive

Feed

Google Korea

Products

Developers