전례없는 팬데믹 상황으로 비대면 생활이 강조되면서 우리 삶 전반에 걸친 여러 서비스가 디지털로 전환 되고 있습니다. 디지털 혁신을 가속시키는 머신러닝과 같은 기술의 발전이 이를 가능하게 하는데 크게 일조하고 있습니다. 뉴노멀 시대의 핵심 기술인 “머신러닝”을 쉽게 배울 수 있도록 구글코리아와 생활코딩이 “머신러닝 야학" 2기를 시작합니다.
“머신러닝 야학"은 구글코리아와 생활코딩이 함께 진행하는 온라인 무료 머신러닝 교육 프로젝트로, 초등학생부터 직업으로 머신러닝을 시작하려는 분들까지 머신러닝에 관심 있는 분이라면 누구나 참여할 수 있습니다. 지난 8월에 시작한 1기에는 아이와 함께 머신러닝을 공부하기 위해 참여한 엄마부터 해외에서 대학 졸업을 앞둔 학생까지 총 19,004명의 참가자가 머신러닝 야학을 통해 공부했습니다.
“머신러닝 야학"은 혼자서도 충분히 학습 가능한 온라인 동영상 강의와 전자책을 제공합니다. 그러나 혼자 공부하면서 느낄 수 있는 고립감이나 소통의 부재 등 온라인 교육의 단점을 보완하기 위해 커뮤니티가 함께 합니다. 각 트랙별 온라인 진도표를 학우들과 공유하여 교류할 수도 있고 현업에서 활동 중인 머신러닝 엔지니어와 구글코리아 엔지니어로 구성된 조력자들로부터 궁금증에 대한 도움을 받을 수 있습니다.
오는 1월 4일부터 시작되는 “머신러닝 야학" 2기에서는 지난 1기와 마찬가지로 누구나 쉽게 머신러닝의 본질을 배울 수 있는 ▲머신러닝 1, 코드를 통해서 머신러닝을 이용하고 싶은 사람들을 위한 ▲TensorFlow를 이용한 머신러닝 수업, 보다 깊은 내용을 학습하고 싶지만 코드는 다루고 싶지 않은 사람들을 위한 ▲orange3를 이용한 머신러닝을 수강하실 수 있습니다. 더불어, 이번 2기에는 새롭게 ▲Tensorflow 심화수업과 자바스크립트를 이용해서 머신러닝을 할 수 있는 ▲Tensorflow.js 수업도 제공됩니다.
머신러닝이 가진 무한한 가능성이 지겨운 것이 아닌, 설레이는 것이 될 수 있도록 노력했습니다. 머신러닝의 생산자가 되기 전에 사용자가 우선 되어 볼 수 있도록 수학, 코딩, 원리를 최대한 배제했습니다. 그 빈자리를 꿈으로 채워볼 수 있도록 머신러닝 야학이 조력자들과 함께 지원하겠습니다. 꿈을 꾸게 된다면 노력하지 않아도 노력하게 될 것입니다.
12월 22일부터 머신러닝 야학 홈페이지(http://ml.yah.ac/)를 통해 신청 가능하며, 머신러닝에 관심 있는 누구나 무료로 참여할 수 있습니다. 1월 4일부터 15일까지 교육과정이 제공되며, 강의를 모두 수강한 참가자에게는 1월 19일에 진행되는 온라인 수료식에서 수료증도 제공합니다.
2021년 새해 계획은 세우셨나요? 이직, 자기 계발, 혹은 새로운 공부를 하는 것에 목표를 두신 분들은 “머신러닝 야학"과 함께 힘차게 시작해보세요!
이 글은 SameSite 쿠키 속성 변경 사항을 다룬 시리즈 중 일부입니다.
SameSite 쿠키 설명
SameSite 쿠키 레시피
Schemeful Same-Site
Schemeful Same-Site는 (웹)사이트의 정의를 단순히 등록 가능한 도메인에서 스킴 + 등록 가능한 도메인으로 바꿉니다. 'same-site'와 'same-origin'의 이해에서 자세한 설명과 예시를 찾을 수 있습니다.
주요 용어: 이는 사이트의 보안에 취약한 HTTP 버전(예: http://website.example)과 보안이 강화된 HTTPS 버전(예: https://website.example)이 이제는 서로에게 교차 사이트로 간주된다는 의미입니다.
여러분의 웹사이트가 이미 HTTPS로 완전히 업그레이드된 상태라면 영향이 없어 걱정할 필요가 없습니다. 웹사이트를 아직 완전히 업그레이드하지 않았다면 이 문제부터 우선적으로 해결해야 합니다. 하지만 사이트 방문자가 HTTP 사이트와 HTTPS 사이트 간에 이동하는 사례가 있는 경우 그처럼 흔히 일어나는 상황과 관련 SameSite 쿠키 동작에 관해 아래에 간략히 설명합니다.
경고: 장기 계획은 타사 쿠키에 대한 지원을 단계적으로 완전히 중단하고 이를 대체 쿠키를 유지하는 개인정보 보호 기능으로 바꾸는 것입니다. 스킴 간에 전송할 수 있도록 쿠키에 대해 SameSite=None; Secure를 설정하는 것은 HTTPS로의 완전한 마이그레이션에서 임시 솔루션으로만 생각해야 합니다.
이런 변경 사항을 사용해 Chrome과 Firefox에서 모두 테스트할 수 있습니다.
Chrome 86부터는 chrome://flags/#schemeful-same-site를 사용합니다. Chrome Status 페이지에서 진행 상황을 추적하세요.
Firefox 79부터는 about:config를 통해 network.cookie.sameSite.schemeful을 true로 설정합니다. Bugzilla 문제를 통해 진행 상황을 추적하세요.
쿠키에 대한 기본값으로 SameSite=Lax로 변경하는 주된 이유 중 하나는 CSRF(교차 사이트 요청 위조)로부터 보호하기 위함이었습니다. 하지만 네트워크 공격자가 여전히 쿠키를 변조해 나중에 사이트의 보안 HTTPS 버전에서 사용할 기회로 비보안 HTTP 트래픽을 악용할 수 있습니다. 스킴 사이에 이런 교차 사이트 경계를 추가로 만들면 위와 같은 공격에 대한 추가적인 방어 수단이 됩니다.
주요 용어: 아래의 예에서 URL이 모두 동일한 등록 가능 도메인(예: site.example)을 가지고 있지만 스킴은 서로 다르며(예: http://site.example과 https://site.example), 이를 교차 스킴이라고 합니다.
웹사이트의 교차 스킴 버전 간 탐색(예: http://site.example에서 https://site.example로 연결)에서는 이전에 SameSite=Strict 쿠키 전송을 허용했습니다. 이제는 이것을 교차 사이트 탐색으로 처리합니다. 즉, SameSite=Strict 쿠키가 차단될 것이라는 뜻입니다.
HTTP에서 HTTPS로의 교차 스킴 탐색.
HTTP → HTTPS
HTTPS → HTTP
SameSite=Strict
⛔ 차단됨
SameSite=Lax
✓ 허용됨
SameSite=None;Secure
경고: 모든 주요 브라우저는 스크립트나 iframe과 같은 능동 혼합 콘텐츠를 차단합니다. 또한 Chrome과 Firefox를 포함한 브라우저는 수동 혼합 콘텐츠를 업그레이드하거나 차단하는 쪽으로 작동합니다.
여기서 변경하는 사항은 모두 완전한 HTTPS로 업그레이드하기 위한 작업을 하는 동안의 일시적 수정으로만 생각해야 합니다.
하위 리소스의 예로는 이미지, iframe 그리고 XHR이나 Fetch로 수행되는 네트워크 요청 등을 들 수 있습니다.
이전에는 웹페이지에서 교차 스킴 하위 리소스를 로드하면 SameSite=Strict 또는 SameSite=Lax 쿠키 전송이나 설정이 허용되었습니다. 이제는 다른 모든 타사 또는 교차 사이트 하위 리소스와 똑같은 방식으로 처리되는데, 이는 곧 어떤 SameSite=Strict 또는 SameSite=Lax 쿠키라도 차단될 것이라는 뜻입니다.
또한 브라우저에서 비보안 스킴의 리소스가 보안 페이지에 로드되는 것을 허용한다 하더라도, 타사 쿠키나 교차 사이트 쿠키에 Secure가 필요하므로 이러한 요청에 대해 모든 쿠키가 차단될 것입니다.
HTTPS를 통한 교차 스킴 하위 리소스를 포함한 HTTP 페이지.
이전에는 웹사이트의 교차 스킴 버전 간에 게시할 경우 SameSite=Lax 또는 SameSite=Strict로 설정된 쿠키 전송이 허용되었습니다. 이것은 이제 교차 사이트 POST로 처리되므로 SameSite=None 쿠키만 전송 가능합니다. 기본적으로 비보안 버전을 제공하는 사이트에서 이런 상황이 발생할 수 있지만, 로그인 또는 체크아웃 양식 제출 시 사용자를 보안 버전으로 업그레이드할 수 있습니다.
하위 리소스와 마찬가지로, 보안(HTTPS) 컨텍스트에서 비보안(HTTP) 컨텍스트로 요청이 이루어질 경우에는 타사 쿠키나 교차 사이트 쿠키에 Secure가 필요하므로 이런 요청에 대해 모든 쿠키가 차단됩니다.
경고: 여기서 최선의 해결책은 양식 페이지와 대상에서 모두 HTTPS와 같은 보안 연결을 보장하는 것입니다. 이는 특히 사용자가 민감한 정보를 양식에 입력할 경우에 중요합니다.
HTTP에서 HTTPS로의 교차 스킴 양식 제출.
Chrome과 Firefox에서는 개발자 도구와 메시징이 제공됩니다.
Chrome 86부터는 DevTools의 Issue 탭에 Schemeful Same-Site 문제가 포함됩니다. 사이트에 대해 다음과 같은 문제가 강조 표시되는 모습이 보일 수 있습니다.
탐색 문제:
'동일 사이트 요청에 대해 쿠키가 계속 전송되도록 하기 위해 완전히 HTTPS로 마이그레이션'—쿠키가 Chrome의 이후 버전에서 차단될 예정이라는 경고.
'동일 사이트 요청에 대해 쿠키가 전송되도록 하기 위해 완전히 HTTPS로 마이그레이션'—쿠키가 이미 차단되었다는 경고.
하위 리소스 로드 문제:
'동일 사이트 하위 리소스로 쿠키가 계속 전송되도록 하기 위해 완전히 HTTPS로 마이그레이션' 또는 '동일 사이트 하위 리소스에 의해 계속해서 쿠키가 설정되도록 허용하기 위해 완전히 HTTPS로 마이그레이션'—쿠키가 Chrome의 이후 버전에서 차단될 예정이라는 경고.
'동일 사이트 하위 리소스로 쿠키가 전송되도록 하기 위해 완전히 HTTPS로 마이그레이션' 또는 '동일 사이트 하위 리소스에 의해 쿠키가 설정되도록 허용하기 위해 완전히 HTTPS로 마이그레이션'—쿠키가 이미 차단되었다는 경고. 후자의 경고는 양식을 POST할 때 나타날 수도 있습니다.
Schemeful Same-Site를 위한 테스트 및 디버깅 팁에서 자세한 내용을 확인할 수 있습니다.
Firefox 79부터는 about:config를 통해 network.cookie.sameSite.schemeful을 true로 설정하면 콘솔에 Schemeful Same-Site 문제에 대한 메시지가 표시됩니다. 사이트에 다음과 같은 메시지가 표시될 수 있습니다.
'스킴이 일치하지 않으므로 cookie_name 쿠키가 http://site.example/에 대해 곧 교차 사이트 쿠키로 처리됩니다.'
'스킴이 일치하지 않으므로 cookie_name 쿠키가 이미 http://site.example/에 대한 교차 사이트로 처리되었습니다.'
링크와 하위 리소스 중 일부가 여전히 비보안 URL을 가리킬 가능성이 있습니다.
이 문제를 수정하는 한 가지 방법은 HSTS(HTTP Strict-Transport-Security)와 includeSubDomain 지침을 사용하는 것입니다. 페이지 중 하나에 우연히 비보안 링크가 포함되어 있더라도 HSTS + includeSubDomain을 사용하면 자동으로 브라우저에서 보안 버전을 대신 사용하게 됩니다.
사용자 보호를 위해 사이트를 완전히 HTTPS로 업그레이드할 것을 강력히 권장하지만, 스스로 업그레이드할 수 없다면 호스팅 공급자에게 문의해 그런 옵션을 제공할 수 있는지 알아보시기 바랍니다. 스스로 호스트하는 경우에는 인증서를 설치하고 구성할 수 있는 여러 가지 도구를 제공하는 Let's Encrypt를 이용해보세요. 또한 CDN이나 HTTPS 연결 기능을 제공할 수 있는 다른 프록시 뒤로 사이트를 이동하는 방법을 알아볼 수도 있습니다.
그 방법 역시 가능하지 않다면 해당 쿠키에 대한 SameSite 보호 수준을 완화해보세요.
SameSite=Strict 쿠키만 차단되는 경우 보호 수준을 Lax로 낮출 수 있습니다.
Strict 쿠키와 Lax 쿠키가 모두 차단되고 쿠키가 보안 URL로 전송되거나 보안 URL에서 설정되는 경우에는 보호 수준을 None으로 낮출 수 있습니다.
쿠키를 전송하는 대상 URL이나 쿠키를 설정하는 소스 URL이 비보안이면 이 임시 해결책이 실패하게 될 것입니다. 그 이유는 SameSite=None은 쿠키에 Secure 속성이 필요하며, 이는 비보안 연결을 통해서는 해당 쿠키를 전송하거나 설정할 수 없다는 뜻이기 때문입니다. 이 경우에는 사이트를 HTTPS로 업그레이드해야 그 쿠키에 액세스할 수 있습니다.
결국에는 타사 쿠키에 대한 지원이 단계적으로 완전히 중단될 것이므로 이는 임시 방편일 뿐임을 기억하세요.
SameSite 속성이 없는 쿠키는 SameSite=Lax를 지정해 동일한 교차 스킴 동작이 이 쿠키에도 적용되는 것처럼 처리됩니다. 안전하지 않은 방법에 대한 일시적 예외가 여전히 적용됩니다. 자세한 내용은 Chromium SameSite FAQ에서 Lax + POST 완화를 참조하세요.
WebSocket 연결은 페이지와 동일한 보안 수준이라면 계속 동일 사이트로 간주될 것입니다.
동일 사이트:
https://에서 wss:// 연결
http://에서 ws:// 연결
교차 사이트:
http://에서 wss:// 연결
https://에서 ws:// 연결
사진: Julissa Capdevilla(Unsplash에서 발췌)
오늘은 Android Gradle 플러그인(AGP) 버전 7.0.0-alpha01과 더불어, Canary 채널을 통해 Android Studio Arctic Fox(2020.3.1)의 첫 번째 버전을 출시하는 날입니다. 이번 출시를 통해 Android Studio의 버전 번호와 Gradle 플러그인의 버전 번호를 조정합니다. 덕분에 Gradle 플러그인이 Android Studio 버전 관리 체계와 분리되고, Android Studio가 각 릴리스에 연계된 IntelliJ 버전과 연도가 더 명확해지게 되었습니다.
Android Studio Arctic Fox(2020.3.1)를 통해 Android Studio의 기반이 되는 IDE인 IntelliJ IDEA에 맞춰 보다 세심하게 조정된 연도 기반 시스템으로 변경됩니다. 연도, 기반이 되는 IntelliJ 버전 및 기능, 패치 레벨 같은 여러 가지 중요한 속성을 인코딩하기 위한 버전 번호 지정 체계를 변경 중입니다. 이러한 명칭 변경을 통해 Android Studio에서 사용 중인 IntelliJ 플랫폼의 버전을 빠르게 파악할 수 있습니다. 뿐만 아니라 각 주요 버전은 Arctic Fox부터 시작해 정식 코드명을 갖게 되고, 그 다음부터는 알파벳순으로 이름이 지정되므로 어떤 버전이 더 새로운 버전인지 쉽게 알 수 있죠.
최신 버전의 Android Studio를 사용해 최신 기능 및 품질 개선의 이점을 누리시기 바랍니다. 더 쉽게 최신 버전을 유지할 수 있도록, Android Studio를 Android Gradle Plugin 버전에서 확실히 분리하는 방향으로 버전을 변경했습니다. 기억해야 할 한 가지 중요한 세부 사항은 IDE를 업데이트할 때 빌드 시스템이 앱을 컴파일하고 패키지화하는 방식에는 아무런 영향이 없다는 점입니다. 반면, 앱 빌드 프로세스 변경 및 APK/번들은 프로젝트 AGP 버전에 따라 결정됩니다. 따라서 프로젝트 AGP 버전이 Android Studio 버전과 다른 주기로 업데이트될 수 있으므로, 개발 주기 후반부라도 Android Studio 버전을 업데이트하는 것이 안전합니다. 마지막으로, AGP 버전을 안정적 릴리스에서 유지하는 한, 새 버전 시스템을 사용하면 귀하나 귀하의 팀이 전보다 훨씬 더 쉽게 앱 프로젝트에서 Android Studio의 안정적 버전과 Preview 버전을 모두 동시에 실행할 수 있습니다.
이전의 번호 지정 시스템에 따른다면 이 릴리스는 Android Studio 4.3이었을 것입니다. 하지만 새로운 번호 지정 시스템에서는 Android Studio Arctic Fox(2020.3.1) Canary 1 또는 그냥 Arctic Fox입니다.
Intellij 버전
이전 이름
이전 - 번호 시스템
신규 - 연도 번호 시스템
새 코드명
전체 이름
2020.3
4.3 Canary 1
4.3
2020.3.1
Arctic Fox
Android Studio Arctic Fox(2020.3.1) Canary 1
앞으로 Android Studio 버전 번호 체계는 다음과 같은 방식으로 작동합니다.
<IntelliJ 버전 연도>.<IntelliJ major 버전>.<Studio major 버전>
첫 두 개의 번호 그룹은 특정 Android Studio 릴리스의 기반이 되는 IntellIj 플랫폼의 버전을 나타냅니다. 이 릴리스의 경우에는 2020.3입니다.
세 번째 번호 그룹은 Studio 주 버전을 나타내는데, 1부터 시작해 주 릴리스가 나올 때마다 1씩 증가합니다.
각 버전을 더 쉽게 참조할 수 있도록 주 릴리스에 코드명도 부여하는데, 동물 이름을 사용해 A에서 Z까지 알파벳순으로 지정합니다. 이번 최초 릴리스 이름은 Arctic Fox입니다.
AGP 7.0.0에서는 시맨틱 버전 관리 원칙을 채택하고 AGP에서 요구하는 Gradle 버전에 맞춰 조정합니다. Android Studio와 Android Gradle 플러그인 간의 호환성은 변경되지 않습니다. AGP의 안정적 버전을 사용하는 프로젝트는 Android Studio 최신 버전으로 열 수 있습니다.
AGP 버전 관리 철학과 이번에 새로 나오는 주 릴리스에서 제공할 AGP 7.0의 새로운 기능에 대한 세부 정보를 설명하는 또 다른 글을 곧 게시할 예정입니다.
Arctic Fox의 경우 아직은 기능 개발 초기단계일 뿐이지만, 코드 편집기, 앱 검사 도구, 레이아웃 편집기부터 임베디드 에뮬레이터까지 IDE의 폭넓은 영역에 걸쳐 200여 가지 품질 개선 문제와 버그를 해결하는데 많은 시간을 투자했습니다. 특정 버그 수정에 대해서는 출시 노트를 확인해 보세요.
Jetpack Compose를 사용해보려는 분을 위해 기기/에뮬레이터에 @Preview composable 배포와 같은 새로운 업데이트가 다수 있습니다.
미리보기 composable 배포
뿐만 아니라 새로운 Layout Validation Tool을 사용해 레이아웃이 다양한 화면 크기, 글꼴 크기, Android 색상 보정/색맹 모드에 반응하는 방식도 확인해 보세요. Layout Editor를 사용할 때 Layout Validation 도구 창을 통해 이 도구에 접근할 수 있습니다.
마지막으로, 최신 Android Platform 도구와 Android 11 기기로 MacOS(다른 플랫폼은 곧 나올 예정임)를 실행하는 분은 Run 버튼 기기 선택 대화상자 → Pair Devices Using Wi-Fi로 이동하여 Wireless ADB 기능에 대한 IDE 통합을 시험해 볼 수 있습니다.
Wireless ADB 기능에 접근하는 메뉴
Wireless ADB 설정 창
