How GitHub Actions renders large-scale logs : GitHub Actions에서 아주 긴 로그를 보여줄 때 성능 향상을 위해서 보이는 영역만 렌더링 하도록 virtualization이라는 기법을 사용했다. 초기 구현에서 React 라이브러리와 바닐라 자바스크립트를 비교했는데 구현의 제약 때문에 바닐라 자바스크립트를 선택했지만 제약사항이나 좋지 않은 UX 경험이 생겼다. 즉, 페이지에 2개의 스크롤 영역이 생겼고 테스트가 많이 되지 않아서 브라우저 탭이 비활성화되었다가 돌아온 경우 로그가 제대로 갱신되지 않거나 로그를 선택하면서 스크롤하는 경우는 선택된 영역이 깨지는 등의 문제가 발생했다. 초기와 달리 데이터를 살펴보니 99.51%가 5만 라인 이하의 로그를 가지고 있었고 2만 라인부터 브라우저가 어려움을 겪고 있었다. 그래서 보여줄 데이터만 메모리에 올리는 data virtualization은 버리고 UI virtualization만 사용하기로 결정하고 처음부터 다시 작성했다. 작성 전에 목표를 정해놓고 이 목표를 달성할 수 있는지 테스트를 하고 만들 수 있다는 판단이 들어서 작업한 결과 1주일 만에 모든 면에서 좋아진 초기 구현체를 얻었다고 한다.(영어)
Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP) : XSS 공격을 막기 위해 CSP를 사용하는데 Allowlist CSP는 대부분 건너뛸 수 있어서 공격을 제대로 막아주지 못하기 때문에 strict CSP를 사용하라고 하고 있다. strict CSP는 매 요청마다 다른 값을 응답 헤더로 알려주는 Nonce 방식과 스크립트마다 다른 값을 가지는 Hash 방식이 있는데 Nonce 방식은 매 요청마다 다른 값을 줄 수 있는 경우 적합하고 Hash 방식은 정적 파일을 서빙할 때 더 접합하다. strict CSP를 도입하기 위해서 두 방식 중 적합한 방식을 선택한 뒤에 Report-only 모드나 enforcement 모드를 선택해서 점진적으로 적용하면서 strict CSP에서 허용 안 되는 스크립트를 수정하면서 도입하라고 하고 있다.(영어)
requestIdleCallback으로 초기 렌더링 시간 14% 단축하기 : Line 증권 프론트엔드에서 Core Web Vitals의 LCP(Largest Contentful Paint)를 개선하기 위해 첫 페이지의 하단 부분을 지연 로딩하기로 결정하고 React의 lazy와 Suspense를 이용해서 webpack을 청크를 나누었지만 webpack의 동작과 섞여서 appendChild가 발생하면서 성능 개선이 충분히 되지 않았다. 이를 해결하려고 메인스 레드가 여유 있을 때 실행되는 requestIdleCallback를 사용해서 지연 로직을 새로 구현했고 700ms가 걸리던 초기 렌더링 시간을 600ms로 줄였다고 한다.(한국어)
Building a Settings component : 슬라이드와 체크박스가 있는 설정 컴포넌트를 만드는 과정을 보여준다. PostCSS Preset Env를 사용해서 CSS를 작성하는데 Grid를 이용해서 레이아웃을 반응형으로 구성하고 lch()로 색을 지정하고 color-scheme와 accent-color를 사용하는 방법을 보여준다. 슬라이드와 체크박스를 CSS로 디자인하는 방법까지 보여주는데 CSS를 최근에 안 봤더니 많은 게 달라졌구나 싶다.(영어)
Introducing Relay Hooks: Improved React APIs for Relay : React Hooks를 사용해서 만든 Relay Hooks으로 Facebook에서는 2019년 후반부터 실 서비스에서 이 방법을 적극적으로 사용하고 있다고 한다. Relay Hook은 Relay와 React를 사용한 Hook 기반의 API로 refetching과 페이지네이션에서 개발자 경험을 향상 시킬 수 있다고 한다.(영어)
웹 접근성 인증 받는 방법과 후기 : 국내 인증 기관에서 웹 접근성 인증을 받은 후기이다. 마지막에 접근성에서 주의해야 할 점이 정리되어 있기는 하지만 주로는 인증기관에 연락해서 인증절차를 진행하는 과정이 잘 나와있다. 글만 봐도 답답하고 어려운 과정이구나 싶은데 글에서도 필수로 해야 하는 게 아니면 인증을 받을 필요는 없어 보인다고 하고 있다. 실제로 진행해보지 않으면 알 수 없는 부분이고 삽질을 많이 할 수 있는 부분이라 유용한 글이다.(한국어)
그 밖의 개발 관련
Deprecating TLS 1.0 and TLS 1.1 : AEAD(authenticated encryption with associated data) 같은 현재 권장되는 암호화에 대한 지원이 부족하고 SHA-1에 의존하고 있는 등의 이유로 보안 전송 계층인 TLS 1.0(RFC 2246)과 1.1(RFC 4346)이 공식적으로 폐기되었다. 2008년부터 TLS 1.2(RFC 5246)가 권장되었고 2018년부터는 TLS 1.3(RFC 8446)이 권장되고 있다.(영어)
Improving large monorepo performance on GitHub : 아주 큰 모노 레포를 사용하는 사용자한테서 종종 push가 실패한다는 보고가 있었고 github 자체도 거대한 모노 레포라서 내부에서도 push 실패를 겪고 있었다. 이 문제를 해결하려고 Cyclops라는 프로젝트를 만들어서 Git 스토리지, 프로토콜, 클라이언트, Git 컨트리뷰터들과 협업해서 push 오류를 0에 가깝게 만들었다고 한다. 기본적으로 GitHub은 50개의 git push 혹은 패키징 안된 파일을 40MB 받을 때마다 레파지토리 유지보수를 실행하는데 이는 저장소 크기에 따라 수초에서 수분까지 걸린다. 아주 큰 모노 레포에서는 이 유지보수가 너무 자주 실행되었고 최대 시간 동안 유지보수를 완료하지 못하면서 push와 레퍼런스 업데이트에 다 문제를 겪였는데 git repack을 개선해서 이 문제를 해결했다고 한다.(영어)
파이썬의 패턴 매칭 도입에 얽힌 이야기 : 지난 2월 Python에 추가하기로 결정된 패턴 매칭 문법이 추가되었는데 이 결정 과정을 정리한 글이다. 2010년부터 패턴 매칭에 대한 논의가 있었지만 잘 진행이 안되다가 2016년 Python의 창시자인 Guido가 패턴 매칭에 대한 의견을 제시하지만 확신은 못했던 걸로 보인다. 하지만 2020년 6월 Guido가 다른 사람들과 패턴 매칭을 다룬 PEP 622를 공개하자 많은 논의가 이뤄지는 가운데 일주일 뒤 Guido가 PEP 622를 기반으로 한 playground를 만들어서 테스트해볼 수 있게 공유한다. 이에 대해 사람들은 다 결정하고 진행하는 게 아니냐고 비판하기 시작했고 Guido는 PEP 622의 2번째 버전을 내놓았고 최종 의사 결정 기관인 Python Steering Council로 결정이 넘어가게 된다. 그리고 Python Steering Council은 PEP 622를 대체할 PEP 634, 635, 636를 공개하고 지난 2월에 승인했다고 한다. 이런 내용을 자세히 보고 있지 않으면 알기 어려워서 재미있게 읽었다.(한국어)
로블록스: 메타버스의 새벽 : Craig Sherman이 쓴 Roblox: Dawn of the Metaverse의 번역글이다. 로블록스의 초기부터 로블록스의 설립자인 데이빗 배저키(David Baszucki)를 알게 되고 이후 실제 투자까지 하면서 성장 과정을 본 크레이그 셔먼이 지난달 30조 원의 가치가 된 로블록스와 메타버스를 소개하는 글이다. 로블록스에는 엔터테인먼트와 사회적 관계 두 가지를 모두 제공하는 몇 안 되는 서비스로 게임 중심이기 때문에 사용자가 즐길만한 요소가 처음부터 있었지만 게임 플랫폼이 아닌 메타버스를 우선했기 때문에 사용자들이 인간의 공동 경험(Human Co-Experience)을 할 수 있게 한다고 한다. 다른 게임에 비해 품질이 떨어진다고 무시받기도 하지만 로블록스는 이 기초를 만들기 위해서 10년을 투자했고 최근에 이 결과가 나오면서 품질에 신경 쓰고 있기 때문에 이 부분은 사용자를 통해서 금방 올라갈 수 있을 거라고 보고 있고 이제는 게임이 아니라 다른 엔터테인먼트 분야까지 넓히고 있다고 한다. "같은 문제에 도전하는 수많은 신생 기업들이 등장하고, 이런 기업들이 갑자기 인기를 끄는 이유를 도저히 이해할 수 없다면, 아마도 새로운 분야가 등장하는 것이다"라는 말이 인상적이었다.(영어)
How HashiCorp Works : HashiCorp가 어떻게 일하는지를 정리한 사이트이다. 크게 각 개인이 하는 관례, 매니저나 팀이 하는 관례, 회사가 하는 관례로 나누어져서 HashiCorp가 어떤 부분을 중요하게 생각하고 어떻게 일하는지가 자세하게 정리되어 있다. 개인적으로는 개인 부분에서 문제를 제기하기 위해 PRD(Problem Requirements Document)를 작성하고 이에 대한 해결책으로 RFC(Request for Comment) 문서를 작성해서 모두가 고민과 결정을 문서로 남기게 하도록 템플릿까지 만들어놓고 사용하는 부분이 인상적이었다.(영어)
Announcing the Deno Company : Node.js의 창시자이고 지금은 새로운 JavaScript, TypeScript 런타임인 Deno를 만들고 있는 Ryan Dahl이 Deno를 초기부터 같이 만들고 있는 Bert Belder와 함께 Deno로 회사를 만들었다. 초기 자본금은 430만 달러이고 Deno는 계속 MIT 라이선스가 유지될 것이고 오픈코어 비즈니스 모델(핵심 부분은 무료로 제공하고 상용 버전이나 애드온을 독점 소프트웨어로 판매하는 모델)도 도입하지 않을 것이라고 한다. 상용 애플리케이션은 따로 구축할 거라고 하는데 무엇을 만들지는 아직 공개되지 않았다.(영어)
Comments