React v18.0 : 오랫동안 준비되면 React의 새 메이저 버전 v18이 릴리즈 되었다.(영어)
18 버전 새 기능의 대부분은 새로운 concurrent 렌더러 위에 만들어졌고 18에서 가장 중요한 변경사항이다.
Concurrency는 기능이라기보다는 다양한 버전의 UI를 만들 수 있게 하는 메커니즘이다.
Concurrent는 엄밀히 호환 안 되는 변경사항이지만 대부분의 경우 변경 없이도 동작할 것이다.
Relay, Next, Hydrogen, Remix 같은 데이터 패칭 프레임워크에서 Suspense를 사용할 수 있다.
서버와 클라이언트에 걸쳐 앱을 만들 수 있는 Server 컴포넌트는 아직 개발 중이다.
18의 새로운 기능으로는 자동 배칭, 업데이트의 중요도를 구분할 수 있는 Transition, 로딩 상태를 선언적으로 지정할 수 있는 Suspense, 새 클라이언트/서버 렌더링 API가 있다.
Remix: The Yang to React's Yin : Remix를 칭찬하는 글이다. React는 UI를 만드는 라이브러리고 UI를 만들려면 상태가 필요한데 이 상태 관리는 React가 책임져 주지 않는다. 그래서 Redux, MobX, Apollo, SWR 등 다양한 라이브러리를 사용해서 상태를 관리하는데 이 상태는 보통 네트워크를 통해 서버에서 오게 되고 이 클라이언트와 서버 사이의 간격을 네트워크 캐즘이라고 한다. 네트워크로 데이터를 가져오기 위해 요청을 보내는데 이 요청하는 코드를 가져와야 하니까 네트워크 폭포수가 발생하고 이로 인해 렌더링은 느려지게 될 수 있다. React Router가 이 문제를 해결하기 위해 Remix의 접근방법을 가져와서 라우팅과 로더(데이터 가져오기), 액션(데이터 조작)을 도입해서 컴포넌트에서 데이터 패칭을 디커플링 할 수 있게 되었고 이도 충분히 좋지만 Remix를 사용하면 Backend for frontend의 역할까지 해주기 때문에 네트워크 캐즘을 Remix가 처리해 주어서 관련한 코드를 훨씬 더 적게 작성할 수 있게 되어 버그도 줄일 수 있다. Remix는 아직 테스트해보지 못했지만 꽤 재미있게 읽은 글이다.(영어)
<section> 버리고 HTML5 <article> 써야 하는 이유 : HTML에서 어디에 어떤 요소를 써야 하는지는 오랫동안 나오는 질문인데 이 글에서는 <section> 대신 <article>을 쓰라고 하고 있다. 여기서 <article>이 신문 기사 같은 글이라기보다는 옷 한 벌처럼 하나의 콘텐츠라고 생각하라고 한다. 그러면 <section>은 어디 쓰는지가 궁금할 수 있는데 목차를 정할 수 있도록 만들어진 컨테이너 이므로 신경 쓸 필요가 없고 <h1>등의 태그가 <section>과 만날 때 시각적으로는 어떻게 보이고 접근성 레벨에서는 어떻게 다른지를 설명하고 있다. <section>을 쓰면 안 되는 것은 아니지만 접근성 제공 측면에서 요약 정도 등에 스크린리더가 알 수 있게 <section>을 사용하면 된다고 하고 있다.(한국어)
Webpack → Vite: 번들러 마이그레이션 이야기 : Webpack을 번들러로 사용하고 있었지만 최근 새로운 번들러가 많이 나오면서 새로운 번들러를 테스트한다. 처음에는 esbuild를 사용해서 210초 걸리던 빌드를 2.16초로 만들었지만 프로젝트의 코드상 Babel을 빌드에 추가해야 했고 HMR 미지원이 아쉬웠다. 다음으로 Vite를 시도했고 설정 파일을 1/6로 줄이고 HMR도 지원되며 의존성과 소스코드를 따로 빌드하기 때문에 빠르게 개발 빌드를 실행할 수 있었다. 빌드도 250초에서 90초 정도로 줄어들었다.(한국어)
New in Chrome 100 : Chrome 브라우저의 100 버전이 릴리스 되었다(Firefox 100 버전도 곧 릴리스 될 예정이다.) 100 버전에서는 기본으로 원래의 User-Agent 문자열을 지원하지만 101 버전부터는 User-Agent 클라이언트 힌트 API로 축약된 User-Agent 문자열이 제공될 예정이다.(영어)
ECMAScript 스펙을 읽는 법 : Timothy Gu의 How to Read the ECMAScript Specification의 번역글이다. JavaScript의 명세인 ECMAScript의 명세는 처음 공부할 때는 권하지 않지만 JavaScript에 익숙해지기 시작하면 언어/플랫폼의 복잡성을 이해하는데 명세가 도움이 될 것이라고 하고 있다. 명세를 처음부터 끝까지 읽는 사람은 없으므로 필요한 부분을 찾아서 보는 게 좋다. 명세에서 많은 약칭과 규칙들이 있어서 처음 볼 때 어려운데 이러한 약칭을 설명하고 예시를 보여주고 있어서 한번 파악해두면 ECMAScript 명세를 볼 때 도움이 될 것이다.(한국어)
Introducing MDN Plus: Make MDN your own : MDN의 유료 구독 서비스로 변경/추가에 대한 알림, 문서 컬렉션 기능, PWA를 이용한 오프라인 지원을 이용할 수 있다. 이 기능을 사용하는 요금제로 MDN Plus 5로 월 $5(연 $50)으로 이용할 수 있고 새 기능을 먼저 써볼 수 있고 MDN과 직접 소통할 수 있는 $10 플랜도 존재한다.(영어)
그 밖의 개발 관련
Spring Framework RCE, Early Announcement : Spring 프레임워크에서 RCE(원격 코드 실행) 취약점이 발견되었다. 이 취약점은 VMware가 보고했고 JDK 9 이상에서 Spring MVC와 Spring WebFlux 애플리케이션에 존재하고 WAR 배포로 Tomcat에서 실행되었을 때 악용될 수 있고 Spring Boot의 실행할 수 있는 jar로 배포했을 때는 취약하지 않다. 이 취약점을 수정한 Spring 프레임워크 5.3.18, 5.2.20이 릴리스 되었고 Spring Book 2.6.6, 2.5.12가 릴리스 되었다.(영어)
GitHub Copilot Labs: GitHub이 공개한 AI 페어 프로그래머인 Copilot의 테크니컬 프리뷰를 하면서 제안 품질과 안정적인 기능을 개선하고 있는데 이를 더 도와줄 수 있는 GitHub Copilot Labs VS Code 익스텐션을 공개했다. 이 익스텐션에는 코드 설명하기(Explain this code), 코드 변환하기(Translate this code) 두 가지 기능을 제공한다. "Explain this code"는 코드 블록의 동작을 영어로 설명해 주는 기능이고 "Translate this code"는 해당 코드를 다른 프로그래밍 언어로 바꿔주는 기능이다. 이 익스텐션은 Copilot 익스텐션을 필요로 하므로 현재는 Copilot 익스텐션을 사용할 수 있는 사람만 사용 가능하다.(영어)
How to start using reusable workflows with GitHub Actions : GitHub Actions 워크플로우를 복사/붙이기 할 필요 없이 workflow_call로 다른 저장소의 워크플로우를 호출하는 방법을 설명한다. 액션에서 workflow_call를 지정하고 다른 저장소에서 uses로 호출할 수 있는데 저장소에서 접근 권한을 열어주어야 한다. 대신 private 저장소의 워크플로우는 참조할 수 없고 하나 이상을 참조할 수도 없다.(영어)
FastAPI의 시대. 아직도 Flask 쓰시나요? : 오랫동안 Python 웹 프레임워크로 Flask를 사용하다가 FastAPI로 갈아타면서 FastAPI가 왜 좋은지를 설명한 글이다. 전역 변수를 사용하는 Flask 대신 의존성 주입을 사용하는 FastAPI에서는 순수 함수로 코드를 작성해서 테스트도 쉽게 작성할 수 있고 context manager나 view decorator 대신 Depends를 이용해서 더 안전하고 쉽게 코드를 작성할 수 있다. 그 외에도 비동기에 기반한 동시성 제어 모델로 훨씬 좋은 성능을 보여주고 유효성 검사와 문서화 등 좋은 기능을 제공하고 있다고 한다.(한국어)
INTRODUCING DAGGER: A NEW WAY TO CREATE CI/CD PIPELINES : Docker을 만들었던 Solomon Hykes가 Docker, Inc에서 물러난 후에 돌아와서 Docker 초기 멤버들과 만든 새 프로젝트를 공개했다. Dagger는 Buildkit과 CUE 기반으로 CI/CD 파이프라인으로 레고처럼 컴포넌트를 조립해서 원하는 CI/CD 파이프라인을 만들 수 있는 게 특징이다. 복잡해지는 인프라와 애플리케이션의 요구사항을 맞추기가 더 어려워지는 Dagger를 이용해서 파이프라인을 소프트웨어로 다루어서 다음과 같은 장점을 가지고 파이프라인을 지속적으로 개선시킬 수 있다고 하고 있다.(영어)
쓰고 버리는 스크립트로 파이프라인은 연결하는 대신 선언적인 언어와 API 재사용 가능한 액션을 조합해서 사용한다.
액션은 안전하게 공유하고 재사용할 수 있다.
파이프라인은 로컬에서 테스트하고 디버깅 한 뒤 어떤 CI 시스템에서도 돌릴 수 있다.
모든 액션은 자동으로 캐싱된다.
Announcing Grafana Mimir, the most scalable open source TSDB in the world : Grafana에서 새로운 시계열 데이터베이스 Mimir를 오픈소스로 공개했다. Grafana Labs의 VP 테크놀로지인 Tom Wilkie는 Weaveworks에서 Julius Volz와 함께 Promethues의 장기 스토리지로 Cortex를 만들고 이를 CNCF에 기부했었다. 2019~2021년까지 Grafana Labs는 Cortex의 87% 정도를 기여했지만 Grafana의 사업상 AGPLv3 라이선스가 더 적합하고(이미 Grafana 프로젝트는 작년에 AGPLv3로 바꾸었고 Cortex는 Apache 라이선스다.) 기술에 대한 노력이 커뮤니티와 프로젝트에 다시 돌아올 수 있다고 얘기하고 있다. Mimir는 Cortex 1.10.0 버전을 포크해서 만들었고 Cortex보다 40배 빠르다고 하고 있다.(영어)
Is Your Cluster Ready for v1.24? : Kuberentes는 2020년 12월 Dockershim 폐기 예정을 공지했다. dockershim은 Docker 엔진을 Kubernetes의 컨테이너 런타임으로 사용할 수 있게 한다. 프로젝트 정책에 따라 1년의 유예기간을 두고 곧 출시될 v1.24에서는 dockershim이 제거될 예정이다. Docker 엔진에 대한 의존성이 있는지 검사하고(Docker Desktop으로 이미지를 빌드하는 건 Docker 의존성이 아님) 의존성이 있다면 다른 컨테이너 런타임으로 바꾸어야 한다. AWS EKS, Azure AKS, Google GKE 같은 매니지드 Kubernetes를 사용한다면 특별히 커스터마이징 하지 않는 이상 신경 쓸 필요는 없다. 만약 Docker를 런타임으로 유지해야 한다면 dockershim의 대체 소프트웨어인 cri-dockerd를 사용해야 한다.(영어)
What's Under the Hood of SaaS Companies (Hint: Why Multitenancy Matters) : 멀티테넌시가 SaaS 업체가 성공하기 위한 요구사항이라고 하고 있다. 초기 스타트업이 빠르고 지저분한 단일 테넌트 환경에서 시작할 수 있지만 성장하기 시작하면 멀티테넌트를 해결해야만 한다. 멀티테넌트를 활용하면 인프라를 공유하므로 수익에 직접적으로 영향을 미치고 고객의 통게를 뽑기도 훨씬 쉽다. 하지만 멀티테넌트에서는 Noisy Neighbor 문제가 존재하고 공유 리소스와 보안 문제가 존재한다.(영어)
IT 업계 뉴스
Christopher Alexander : 패턴랭귀지로 유명하고 프로그래밍의 패턴에도 큰 영향을 주신 Christopher Alexander님이 지난 3월 17일 영국 자신의 집에서 87세의 나이로 별세하셨다. 삼가 고인의 명복을 빕니다.(영어)
Google Domains is out of beta : 2015년에 런치 한 Google Domain이 베타를 끝내고 26개국에서 300개의 TLD를 지원하며 퍼블릭으로 열렸고(여태는 막혀있었는지 잘 모르겠지만...) 오픈 기념으로 20% 할인 이벤트도 진행 중이다.(영어)
Comments