1/20

https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html

구글에서 Privacy Sandbox라는 웹 브라우저에서의 개인정보보호를 근본적으로 개선할 수 있는 기준을 세우는 프로젝트를 진행하고 있다. (user-agent string 제거한다는 것도 그 일환이다.) 최근 블로그 글에서는 서드파티 쿠키를 없애겠다는 의지를 강하게 드러내고 있다.

쿠키는 로그인 정보, 사이트에 방문한 이력이나 이용기록과 같은 개인정보를 담은 데이터 조각이다. 로그인, 장바구니 등 세션관리를 도와주고, 사용자가 편집한 개인화 설정을 담고 있다. 그 중에서도 광고업계에서는 쿠키를 사용자의 행동을 기록하고 분석하는 용도로 사용하는데, 특히 3rd-party 쿠키는 쿠키의 도메인과 현재 보고 있는 페이지의 도메인이 다를 경우를 의미하며, 여러 사이트를 넘나들면서 사용자의 인터넷 활동을 추적할 수 있게 도와준다. 이를 통하여 사용자에게 맞는 광고를 제공할 수 있다.

최근 웹에서의 프라이버시 논의가 계속 이어지고, 원하지 않는 데이터를 제 3자에게 넘기는 행위를 부정적으로 생각하는 사람은 점점 늘어나고 있다. 타겟팅 광고로 이득을 보는 건 데이터를 넘긴 사용자가 아닌, 알지 못하는 어떤 제 3의 회사인 것도 문제가 될 수 있다. 파이어폭스, 사파리 등 크롬 외의 브라우저에서는 이미 서드파티 쿠키를 제한하고 있는 곳이 많다. 크롬도 그 흐름에 동참하겠다는 의미로 읽힌다.

실제로, 당장 2월이 되기 전에 적용해야 하는 설정이 생겼다. SameSite=None 보안 쿠키 설정을 Chrome 80 버전부터 적용한다고 밝혔다. SameSite 속성을 None으로 레이블을 지정하고, Secure 설정을 가진 쿠키에 한하여 cross-site tracking이 가능하고, 해당 속성을 설정하지 않으면 사이트 전체에서 계속 액세스 할 수가 없게 된다. (Google Developers 블로그 글)

서드파티 쿠키 없이, 광고는 어떻게 서빙되고 정보를 수집할 수 있을까. 브라우저를 가진 구글, 기기를 가진 애플과 같이 큰 회사들은 문제가 없어 보인다. 애플은 아이폰 등 기기 내에서만 데이터를 저장하여 개인화된 콘텐츠나 정보를 제공한다고 한다. 중앙에서 수집하지 않고도, 사용자에게 잘 맞는 개인화 기술을 선보이겠다는 것이다. 구글은 크롬 브라우저와 구글 서비스를 통해 수많은 정보를 수집, 보유하고 있다. 어떤 의미에서는 구글은 크롬 브라우저로 정보를 수집하면서, 규모가 작은 회사들에서 정보를 수집하는 것을 원천봉쇄하는 것처럼 보이기도 한다. 구글도 그런 비판을 의식해서, 별도의 기준을 마련하여 투명하게 정보를 전달할 수 있는 방법을 만들겠다고 한다. 아직 정확한 방향은 제안되지 않았지만 말이다.

웹 개발자로, 이런 흐름과 변화를 잘 눈여겨 보아야겠다는 생각을 한다.

1/21

Serverless라는 이름은 아무래도 오해를 불러일으키기 좋은 것 같다. 나는 이 용어가 '서버 없는'이라는 의미의 형용사라고만 생각했다. 서버리스는 클라우드 제공자가 동적으로 머신 자원을 할당하는 것이지, 진짜 서버가 필요 없는 것은 아니다. 사용자 입장에서 서버가 가려져 있는 것은 맞지만.

한편 참 잘 지은 이름이라는 생각도 든다. 코딩 잘 모르던 시절에도 이 용어를 듣고 단번에 외워버렸고, 서버 개발보다 프론트엔드 개발을 먼저 공부해서 취업해야겠다는(?) 생각도 했으니 말이다. 뭐, 실제로 서버 개발에 필요한 여러 가지 지식을 모르고도 서비스를 만들 수 있다는 점에서 '서버가 없다'고 할 수 있겠다.

그러니까 이번주부터 AWS lambda와 관련한 작업을 하게 되어서, (내가 할 작업과 관련해서는) Serverless가 AWS lambda의 코드 배포를 자동화해주는 프레임워크라는 걸 다시금 떠올려서 메모.

1/22

요즘 출퇴근길에 틈틈이 slideshare에 올라와 있는 Redis와 관련한 발표자료를 보고 있다. 설에는 유투브에 있는 영상인 우아한테크세미나: 우아한 레디스 by 강대명님을 볼 것이다.

1/24

회사에서 쓰는 용어 중에 익숙하지 않거나/영어로 어떤 의미인지 정확하지 않은 것을 정리해 본다.

batch: '일괄(처리)'라는 뜻의 단어. 개별적으로, 요청이 있을 때마다 실시간으로 처리하는 것이 아니고, 한꺼번에 일괄적으로 자료를 처리한다. '배치를 돌리다'라는 식으로 표현을 쓰던데, 영어로는 'execute(run) a batch file'이라고 쓰는 것 같다. 사용자에게 당장 응답해줄 필요 없는 서비스에 적용할 수 있다. (ex. 통계, 정산 등)

cron: 위키피디아에서는 "유닉스 계열 컴퓨터 운영체제의 시간 기반 잡 스케줄러"라고 한다. 정기적인 배치 작업을 수행하는 데에 활용된다. cron job은 스케줄된 작업 그 자체를 의미한다. 반복작업을 자동화하는 데 유용하게 사용된다. 크론 표현식이 있는데 이건 해당 작업을 할 때 한번 살펴보는 것으로..

CI(Continuous Integration): '지속적 통합'은 자동화된 빌드와 테스트가 수행되고 난 후 개발자가 코드의 변경사항을 중앙 리포지토리에 정기적으로 병합하는 개발방식을 의미한다. 문화적 구성요소(ex. 자주 통합하도록 학습한다) + 자동화 구성요소(빌드 서비스)로 이뤄져 있다. 지속적 통합을 위한 제품에는 여러 가지가 있는데, Jenkins는 그 중에서도 가장 인기가 좋은 오픈소스 프로젝트로, 버전관리, 컴파일, 테스트 등 work flow를 제어한다.

1/25

말로만 여러 번 듣던 svelte를 슬쩍 써봤다. vue를 처음 써봤을 때처럼 정말 간결하고 쉽다! react가 비판 받는 지점들을 해결해내는 데에 초점을 둔 것 같다. create-react-app의 번들 파일 크기는 물론이고 preact보다도 작은 크기의 번들 파일로 실행이 가능하다고 한다. 또, svelte는 가상 DOM을 사용하지 않아서 속도가 매우 빠르다. svelte는 그 자체로 컴파일러이고, 런타임에서 로드되지 않는다. 그럼에도 reactive하단다. 웹은 계속 요동치고 변한다. 그래서 재밌다.