2023년 4월 2주차 개발 뉴우스

안녕하세요. 구독자님 이번주 뉴스도 봐주셔서 감사합니다 😄

1. Getting PWAs in App Stores with PWABuilder

https://web.dev/pwas-in-app-stores/

이 문서는 PWABuilder를 사용하여 다양한 앱 스토어에 Progressive Web Applications (PWA)를 출시하는 방법에 대한 포괄적인 가이드를 제공합니다. PWA를 앱 스토어에 배포하는 과정의 어려움과 PWABuilder가 웹 애플리케이션을 앱 스토어에 출판하는 과정을 간소화하는 방법을 강조합니다.

이 문서는 먼저 PWABuilder를 사용하기 위한 사전 요구 사항을 설명합니다. 이에는 PWA의 공개 URL, 완전한 웹 앱 매니페스트, 그리고 HTTPS를 통해 앱을 제공하는 것이 포함됩니다. 그런 다음, PWA를 패키지로 묶고 제출하는 단계를 설명하며, 이는 PWABuilder 홈페이지에서 PWA의 URL을 입력하고 패키지를 생성할 플랫폼을 선택하고 패키지를 다운로드하는 것을 포함합니다.

또한, 개발자들이 자신의 PWAs를 출판하는 데 도움을 줄 수 있도록, 이 문서는 Microsoft Store, Google Play Store, Apple App Store 및 Meta Quest Store와 같은 특정 앱 스토어에 PWA를 출판하는 데 필요한 플랫폼별 문서에 대한 링크를 제공합니다.

2. CSS Masking

https://ishadeed.com/article/css-masking/

CSS 마스킹은 이미지나 그라데이션을 사용하여 요소의 일부를 숨겨 다양한 시각적 효과를 만들 수 있는 기술입니다. 노션 문서는 CSS 마스킹과 그 실제 사용 사례에 대해 논하며, 이미지를 페이드 아웃하여 배경과 어우러지게 하는 효과, 텍스트 콘텐츠를 마스킹하여 시작과 끝에서 텍스트를 페이드 아웃하는 효과, 그리고 그라데이션을 사용한 CSS 마스킹으로 이미지에 독특하고 시각적으로 매력적인 효과를 만드는 방법을 다룹니다.

문서는 또한 마스크 컴포짓팅과 팬시 그라데이션 보더 등 CSS 마스킹에 대한 자세한 자료를 제공합니다. CSS 마스킹에 대해 더 배움으로써 디자이너와 개발자는 프로젝트에 새로운 시각적 흥미를 더하고 매력적인 사용자 경험을 만들 수 있습니다.

3. How WebAssembly is accelerating new web functionality

https://blog.chromium.org/2023/04/how-webassembly-is-accelerating-new-web.html

이 Chromium의 블로그 게시물에서는 WebAssembly가 어떻게 새로운 웹 기능 개발을 혁신시키고 있는지에 대한 깊은 이해를 제공합니다. WebAssembly를 사용하면 개발자들은 다른 언어에서 이식 가능한 바이트 코드를 컴파일하여 최적화된 성능을 제공하고 다른 플랫폼에서의 라이브러리와 기능을 웹으로 가져오는 것이 가능해집니다. 이는 빠른 반복 속도, 브라우저 간 즉각적인 지원, 그리고 더욱 향상된 보안을 포함한 중요한 이점을 제공합니다.

빠른 반복 속도는 새로운 웹 기능이 더 이상 까다로운 표준화 과정과 크로스 브라우저 구현을 거쳐야 하는 경우가 없기 때문입니다. Origin Trials와 같은 접근 방식은 더 많은 실험을 가능하게하지만 여전히 몇 주에서 몇 개월의 시간이 걸립니다. WebAssembly를 사용하면 반복 주기가 몇 년에서 몇 일이나 몇 시간으로 줄어들어 기능 개발 방식이 근본적으로 변경됩니다.

WebAssembly의 또 다른 이점은 브라우저 간 즉각적인 지원을 제공합니다. wasm이 브라우저에서 지원되기 때문에 이를 기반으로 구축된 기능은 즉각적으로 모든 브라우저에서 작동합니다. 상호 운용성과 기능의 크로스 브라우저 구현은 개발자들의 중요한 고통의 원인 중 하나이며, 이러한 기능을 이러한 하위 수준 프리미티브로 이동함으로써 이러한 우려 중 많은 부분이 제거됩니다.

WebAssembly는 높은 보안 샌드박스 위에 구축된 이러한 기능으로 인해 향상된 보안을 제공합니다. 예를 들어, Flash는 복잡한 플러그인을 충분히 견고하게 보호하는 것이 너무 어려워 웹에서 제거되었습니다. 하지만 지금은 WebAssembly에서 실행되어 거의 모든 보안 우려가 제거됩니다.

그러나 WebAssembly에는 단점과 한계도 있습니다. 하나의 한계는 대부분의 웹 개발에서 JavaScript를 대체하지 않고 기능을 확장한다는 것입니다. 브라우저에서의 WebAssembly는 여전히 JavaScript에 완전히 의존하며 다른 웹 기능에 액세스하려면 JavaScript를 통해 인터페이스해야 합니다.

다른 제한 사항은 페이지 번들 크기가 증가한다는 것입니다. 사용자 랜드에 더 많은 논리와 기능을 이동함으로써 페이지의 크기도 증가합니다. 이는 좋은 사용자 경험을 위한 가장 중요한 것이기 때문에 큰 문제입니다. 결과적으로, 개발자들은 이러한 기능으로 번들 크기를 급격하게 증가시키기 전에 신중히 생각해야 하며, 작은 전자 상거래 또는 블로그 사이트보다는 대규모 웹 앱에 더 적합할 수 있습니다.

WebAssembly 및 다른 프리미티브는 대부분 계산 메커니즘이며, 운영 체제 또는 장치 자체에 대한 루트 시스템 액세스를 제공하지 않습니다. 하드웨어 액세스 (USB 또는 Bluetooth), 스크린 또는 창 관리, 입력 컨트롤, 파일 시스템, 클립 보드 등과 같은 기능은 여전히 플랫폼 수준의 API를 통해 액세스해야 합니다.

결론적으로, WebAssembly는 브라우저 및 개발자들에게 강력한 새로운 접근 방식입니다. 이미 브라우저에서 새로운 기능을 활성화하고 있으며, 기능 개발 방식에 근본적인 변화를 나타냅니다. 새로운 패러다임과 마찬가지로, 장단점이 있지만, 전반적으로 WebAssembly를 사용하는 이점이 한계를 훨씬 능가합니다.

4. Are Safari Releases Causing 'Development Hell'?

https://www.construct.net/en/blogs/ashleys-blog-2/safari-releases-development-1616

이 문서에서 저자는 Safari 릴리스와 관련하여 웹 개발자로서의 경험을 공유합니다. 저자는 투명성과 릴리스 일정의 부재가 새로운 릴리스를 계획하고 준비하기 어렵게 만든다는 중요한 문제점을 강조합니다. 최근 Safari 릴리스에서 발견된 여러 문제점, 예를 들어 프로젝트 미리보기 문제 및 Construct에서 발행된 모든 콘텐츠가 깨지는 문제가 설명됩니다. 이러한 경우, Safari 릴리스 날짜에 따라 문제를 루틴 버그로 처리할 것인지 긴급 상황으로 처리할 것인지에 대한 딜레마가 발생했습니다.

저자는 Apple이 다른 브라우저 제작자들의 개발 프로세스를 복제함으로써 상황을 개선할 수 있다고 주장합니다. 예를 들어, Chrome Canary와 Firefox Nightly와 같은 더 많은 사전 릴리스 테스트 옵션을 제공함으로써 개발자들이 문제를 빠르게 반복하고 수정을 검증할 수 있도록 할 수 있습니다. 또한, Safari를 OS와 독립적으로 업데이트하면 심각한 문제를 해결하는 데 걸리는 시간을 줄일 수 있습니다. 또한, 저자는 개발자들과의 더 나은 커뮤니케이션과 릴리스 일정에 대한 더 많은 투명성을 요구합니다.

저자는 Safari가 훌륭한 브라우저이자 시장에서 강력한 경쟁자가 되기를 바란다는 결론을 내리며, 그러나 Apple이 정책을 변경하지 않는다면 개발자들은 Chrome이나 Firefox와 같은 다른 브라우저를 사용자에게 권장해야 할 수밖에 없을 것이라 주장합니다. 저자는 규제 당국이 Apple의 실천 방식을 변경하도록 강요해야 할 수도 있다는 의견을 제시합니다. 전반적으로, 저자의 경험은 Safari 릴리스와 관련하여 웹 개발자들이 직면하는 어려움과 Apple이 개발 프로세스를 개선해야 할 필요성을 강조합니다.

5. Using TRPC in Astro and its (React) islands

https://www.thomasledoux.be/blog/using-trpc-astro-islands-react

이 문서는 정적 사이트 생성기 Astro와 React islands에서 TRPC를 구현하는 방법에 대한 종합적인 가이드를 제공합니다. 작성자는 필요한 패키지를 설정하는 방법, TRPC 컨텍스트 및 서버를 만드는 방법, 그리고 Astro 페이지와 React islands에서 TRPC 클라이언트를 사용하는 방법에 대해 자세한 단계별 지침을 제공합니다.

이 가이드는 @tanstack/react-query, @trpc/client, @trpc/server, @trpc/react-query, zod를 포함한 필수 패키지 설치를 개요합니다. 작성자는 다음으로, @astro-auth에서 getUser() 호출을 가져와 TRPC 경로가 호출될 때 현재 로그인한 사용자를 확인하는 데 사용하는 컨텍스트에 추가하는 프로세스를 안내합니다.

다음으로, 가이드는 로그인한 사용자만 특정 경로에 액세스할 수 있도록 미들웨어를 적용하고 별도의 adminProcedure를 만드는 것을 포함하여 TRPC 서버를 설정하는 방법을 설명합니다. 작성자는 또한 getCommentsForBlog, createCommentForBlog, deleteCommentForBlog, sendContactForm과 같은 다양한 경로에 대한 코드 스니펫을 제공합니다.

가이드는 Astro에서 API Route를 설정하는 방법으로 이동하며, 이는 내장된 Web Platform API Response와 Request를 사용하고 라우터와 컨텍스트를 연결하는 것을 포함합니다. 작성자는 또한 react-query에 대한 QueryClient와 TRPCReactProvider를 만드는 방법을 설명하며, Astro 페이지와 React islands에서 TRPC 클라이언트를 사용하는 방법에 대한 코드 스니펫도 제공합니다.

전반적으로, 이 가이드는 Astro와 React islands에서 TRPC를 구현하려는 누구에게나 유용한 자원입니다. 단계별 지침과 코드 스니펫은 초보자도 쉽게 따라 할 수 있도록 만들어줍니다.

6. React Hook Form: Working with Multipart Form Data and File Uploads

https://claritydev.net/blog/react-hook-form-multipart-form-data-file-uploads

이 문서는 ClarityDev에서 React Hook Form을 사용하여 멀티파트 폼 데이터 및 파일 업로드를 처리하는 방법을 설명하는 블로그 포스트입니다. 이 포스트에서는 파일 입력 추가, 파일 입력 처리, 멀티파트 폼 데이터 제출, React Testing Library를 사용한 파일 업로드 테스트 등을 다룹니다. 이 포스트에는 코드 조각과 추가 리소스 링크가 포함되어 있습니다.

7. React Server Components deep dive with @JamesQQuick 🤿

요약: 이 동영상에서는 React 서버 컴포넌트의 장점과 사용 편의성, 뉴스레터 생성 자동화, 스트리밍을 통한 서버 측 렌더링, 사용자 경험 개선과 로딩 시간 단축을 위한 서스펜스 및 Astro 사용에 대해 설명합니다.

1. React 서버 컴포넌트가 점점 더 현실화되고 있으며, 마크다운 및 기타 기능에 있어 개츠비나 Next.js보다 사용하기 쉬운 Astro를 통해 컴포넌트를 탐색하게 되어 기쁘다고 발표자는 말했습니다.

2. API 엔드포인트, 콘텐츠 컬렉션, Zod 타이핑을 사용하여 뉴스레터 생성을 자동화함으로써 프로세스가 매우 원활하고 쉬워졌습니다.

3. 👨‍💻 React에서 스트리밍을 통한 서버 측 렌더링을 사용하면 데이터 없이도 효율적으로 데이터를 가져오고 페이지를 초기 렌더링할 수 있으므로 Apollo와 같은 무거운 라이브러리의 필요성이 줄어듭니다.

4. 🚀 React의 서버 컴포넌트는 더 빠른 로딩과 더 유연한 데이터 불러오기를 가능하게 하며, Deno는 명령에 대한 명시적 권한이 필요하고 비동기 함수는 더 많은 유연성을 제공합니다.

5. 👨‍💻 React의 서스펜스 기능을 사용하여 데이터 로딩을 지연시키면 사용자 경험을 개선하고 브라우저 과부하를 방지할 수 있습니다.

6. 👨‍💻 웹소켓을 사용하여 브라우저를 새로고침하는 것은 까다로울 수 있지만 유용한 개발자 블로그 게시물과 서스펜스를 사용하면 더 쉽게 할 수 있으며, 클라이언트 측 페치 및 스트림을 사용하면 JavaScript를 절약할 수 있고 Astro와 React는 비슷한 비동기 개념을 가지고 있지만 마이그레이션 문제가 있습니다.

7. 7. 🚀 Astro Islands는 스트리밍 기능으로 HTML 사용이 더 빠르며 클라이언트 측 스크립팅을 사용하여 로딩 스피너를 처리합니다.

8. 🚀 Astro 스트리밍은 HTML 스트리밍을 위한 새로운 웹 표준입니다.

8. The Most Beloved Burger for Developers

요약: 이 동영상에서는 서버리스 기능, Github Actions, REST, Github, 브라우저 캐시, CDN, NextJS를 사용하는 초기 단계의 스타트업을 위한 비용 효율적이고 유연한 백엔드 아키텍처를 위한 레시피를 제공하며, 데이터베이스에는 Typescript와 Firebase 또는 Aurora 서버리스 사용을 권장하고, 예상을 뛰어넘는 Facebook의 2분기 실적에 대해서도 언급하고 있습니다.

1. 리소스가 제한적이고 제품/시장 적합성이 불확실한 초기 단계의 스타트업을 위한 백엔드 버거 레시피.

1.1 이 비디오에서는 리소스가 제한적이고 제품/시장 적합성이 불확실한 초기 단계의 스타트업을 위한 백엔드 버거의 재료를 공유합니다.

2. 서버리스 함수는 엄격한 요청/응답 프로그래밍 모델을 통해 컨테이너화 및 아키텍처에 유연성과 비용 효율성을 제공합니다.

2.1 서버리스 함수는 엄격한 요청/응답 프로그래밍 모델과 비용 효율적인 리소스 사용으로 컨테이너화 및 아키텍처 패턴의 유연성을 극대화하기 위해 선호되는 선택입니다.

3. 3. 🚀 효율적이고 안정적인 풀스택 웹 개발을 위해 Vercel과 함께 Github Actions, REST, Github, 브라우저 캐시, CDN, NextJS를 사용하세요.

3.1 CI/CD에는 Github Actions, API에는 REST, VCS에는 Github, 캐싱에는 브라우저 캐시 및 CDN, 프론트엔드와 백엔드를 모두 호스팅할 때는 Vercel이 포함된 NextJS를 사용합니다.

4. 4. 💻 프론트엔드 및 백엔드 모두에 Typescript를 사용하고, 확장할 때 투자하며, 데이터베이스는 Firebase 또는 Aurora Serverless를 선택합니다.

4.1 프론트엔드 및 백엔드 모두에 타입스크립트를 사용하고, 테스트를 위해 회사 확장 시 투자하며, 데이터 복잡도에 따라 데이터베이스는 Firebase 또는 Aurora 서버리스를 사용합니다.

9. What is OSI Model | Real World Examples

TLDR: 네트워크 통신을 7계층으로 구성하는 OSI 모델은 오늘날에도 여전히 네트워킹에 적용되고 있으며, 레이어 7 프로토콜인 HTTP와 클라우드 컴퓨팅의 L4 및 L7 로드 밸런서가 이에 해당합니다.

1. OSI 모델은 네트워크 통신을 7개의 계층으로 구성하고 맨 아래에 물리 계층을 두어 네트워킹을 위한 프레임워크를 제공합니다.

1.1 OSI 모델은 네트워크 통신을 7개의 계층으로 나누고, 물리 계층이 가장 아래 계층에 위치하여 네트워킹을 위한 이론적 프레임워크를 제공합니다.

2. 데이터 링크 계층은 비트를 프레임으로 구성하고 네트워크 계층은 네트워크 간에 비트를 라우팅하며, 전송 계층은 종단 간 통신을 처리합니다.

2.1 데이터 링크 계층은 원시 비트를 프레임으로 구성하고 전송을 보장하며, 네트워크 계층은 서로 다른 네트워크에서 데이터 프레임을 라우팅하고 전송 계층은 두 노드 간의 엔드투엔드 통신을 처리합니다.

3. 3. 💡 TCP는 시퀀스 번호로 안정적인 통신을 제공하는 반면, UDP는 더 빠르지만 신뢰성이 부족합니다.

3.1 TCP는 데이터를 시퀀스 번호가 있는 세그먼트로 나누어 안정적인 통신을 제공하는 반면, UDP는 더 간단하고 빠르지만 오류 확인 및 신뢰성이 부족합니다.

4. 4. 💻 OSI 모델의 세션, 프레젠테이션, 애플리케이션 계층을 하나의 계층으로 결합할 수 있으며, 계층 7 프로토콜로 HTTP를 사용합니다.

4.1 OSI 모델의 세션, 프레젠테이션 및 애플리케이션 계층은 너무 세부적이어서 단일 계층으로 축소할 수 있으며, HTTP와 같은 애플리케이션 프로토콜은 계층 7 프로토콜로 간주됩니다.

5. HTTP 요청은 웹 서버와 통신하기 위해 여러 계층에서 헤더로 캡슐화됩니다.

5.1 웹 서버에 대한 HTTP 요청은 애플리케이션, 전송, 네트워크 및 데이터 링크 계층에서 헤더로 캡슐화됩니다.

6. MAC 주소는 인터넷 트래픽을 라우팅하고 웹 서버가 원시 비트에서 헤더를 계층별로 제거하여 HTTP 요청을 처리하는 데 도움이 됩니다.

6.1 MAC 주소는 인터넷을 통해 다음 홉으로 이동하는 라우팅 장치에서 사용되며, 웹 서버는 원시 비트를 수신하면 계층별로 헤더를 제거하여 HTTP 요청을 처리합니다.

7. OSI 모델은 교육용으로 중요하며 네트워킹 벤더와 클라우드 제공업체에서 제품 배치를 설명하는 데 여전히 사용됩니다.

7.1 OSI 모델은 주로 교육 목적으로 사용되며 네트워킹 공급업체와 클라우드 제공업체가 모델에서 제품 배치를 설명하기 위해 여전히 널리 사용하고 있습니다.

8. L4와 L7은 두 가지 유형의 클라우드 로드 밸런서이며, L7은 애플리케이션 프로토콜 계층에서 작동하고 L4는 TCP 수준에서 작동합니다.

8.1 클라우드 로드 밸런서는 L4와 L7로 분류되며, L7은 애플리케이션 프로토콜 계층에서 작동하고 L4는 TCP 수준에서 작동합니다.

10. What Are Microservices Really All About? (And When Not To Use It)

요약: 마이크로서비스 아키텍처는 특정 기능을 처리하는 독립적인 서비스를 통해 확장 가능하고 유연한 애플리케이션을 지원하므로 비용 효율성과 팀 독립성을 확보할 수 있습니다.

1. 🏗️ 마이크로서비스 아키텍처는 특정 기능을 처리하는 독립적인 서비스를 통해 확장 가능한 애플리케이션을 지원합니다.

1.1 마이크로서비스 아키텍처는 느슨하게 결합된 서비스로 구성된 확장 가능한 애플리케이션을 허용하며, 각 서비스는 애플리케이션 내에서 전용 기능을 처리합니다.

2. 마이크로서비스는 잘 정의된 인터페이스를 통해 통신함으로써 장애와 결함을 제한하고, 애플리케이션의 맥락에서 각 서비스를 더 쉽게 이해할 수 있도록 합니다.

2.1 마이크로서비스는 잘 정의된 인터페이스를 통해 통신하여 장애 및 결함의 폭발 반경을 제한하므로 전체 애플리케이션의 맥락에서 각 서비스를 더 쉽게 이해할 수 있습니다.

3. 마이크로서비스는 운영 유연성, 독립적인 배포, 개별 서비스의 확장을 제공합니다.

3.1 마이크로서비스는 운영 유연성, 더 쉬운 추론, 더 작은 폭발 반경을 제공하므로 개별 마이크로서비스를 독립적으로 배포하고 확장할 수 있습니다.

4. 마이크로서비스는 모놀리식 데이터베이스를 논리적 구성 요소로 분해하지만 애플리케이션 계층에서 데이터 무결성 문제를 일으킬 수 있습니다.

4.1 마이크로서비스는 모놀리식 데이터베이스를 논리적 구성 요소로 분할하여 강력한 정보 은닉을 수행하지만, 이로 인해 데이터 무결성 유지에 대한 부담이 애플리케이션 계층으로 전가될 수 있습니다.

5. 마이크로서비스 아키텍처에는 API 게이트웨이, ID 공급자, 서비스 레지스트리가 필수적입니다.

5.1 API 게이트웨이, ID 공급자 서비스, 서비스 레지스트리 및 검색 서비스는 마이크로서비스 아키텍처를 성공적으로 구현하기 위한 핵심 구성 요소입니다.

6. 마이크로서비스 아키텍처는 팀 독립성과 각 도메인 또는 기능의 독립적인 유지보수가 가능하기 때문에 대규모 팀에 비용 효율적입니다.

6.1 마이크로서비스 아키텍처는 팀의 독립성을 보장하고 각 도메인 또는 기능의 독립적인 유지보수가 가능하므로 대규모 팀에만 비용 효율적입니다.

7. 스타트업은 각 애플리케이션 기능에 대한 명확한 인터페이스 설계를 우선시하고, 확장에 따라 마이크로서비스로의 전환을 고려해야 합니다.

7.1 스타트업은 애플리케이션의 각 기능을 잘 정의된 인터페이스로 설계하고 비즈니스와 팀이 빠르게 성장하면 마이크로서비스 아키텍처로 마이그레이션해야 합니다.

11. Latency Numbers Programmer Should Know: Crash Course System Design #1

TLDR: 작업마다 나노초에서 초에 이르기까지 상대적인 지연 시간이 크게 다릅니다.

1. 정확한 수치보다 상대적인 지연 시간 차이를 이해하는 것이 더 중요합니다.

1.1 나노초 미만에서 초에 이르는 지연 시간 간의 상대적 차이를 직관적으로 이해하는 것이 정확한 수치를 아는 것보다 더 중요합니다.

2. CPU 레지스터에 액세스하는 속도는 매우 빠르지만 일부 작업은 최대 20번의 CPU 클럭 사이클이 소요될 수 있습니다.

2.1 CPU 레지스터 액세스는 나노초 미만, L1 및 L2 캐시 액세스는 1~10ns 범위이며 일부 고비용 CPU 작업의 경우 최대 20회의 CPU 클럭 사이클이 소요될 수 있습니다.

3. CPU에서 메인 메모리에 액세스하는 것은 레지스터에 액세스하는 것보다 수백 배 더 느리며 Linux에서 시스템 호출을 하는 데 수백 나노초가 걸립니다.

3.1 최신 CPU의 메인 메모리 액세스는 CPU 레지스터 액세스보다 수백 배 느리며 Linux에서 간단한 시스템 호출을 수행하는 데 수백 나노초가 걸립니다.

4. Linux 스레드 간 전환과 64KB 메모리 복사 모두 몇 마이크로초가 걸립니다.

4.1 Linux 스레드 간 컨텍스트 전환에는 최소 수 마이크로초가 걸리며, 한 메인 메모리 위치에서 다른 메인 메모리 위치로 64KB를 복사하는 데도 수 마이크로초가 걸립니다.

5. 메인 메모리에서 읽는 속도가 SSD보다 5배 빠릅니다.

5.1 메인 메모리에서 1MB의 데이터를 순차적으로 읽는 데 50마이크로초가 걸리는 반면, SSD 읽기 지연 시간은 100마이크로초, 쓰기 지연 시간은 1밀리초에 가까워집니다.

6. 💻 영역 내 네트워크 RTT는 ~200μs, 영역 간 RTT는 1~10ms, HDD 탐색 시간은 5ms입니다.

6.1 최신 클라우드 제공업체의 영역 내 네트워크 왕복 시간은 수백 마이크로초, 영역 간 네트워크 왕복 시간은 1~10ms, 하드 디스크 드라이브 검색 시간은 5ms입니다.

7. 비밀번호를 암호화하는 데는 TLS 핸드셰이크보다 시간이 더 오래 걸립니다.

7.1 B암호화는 300ms가 걸리는 반면, TLS 핸드셰이크는 일반적으로 기계 간 거리에 따라 250-500ms가 걸립니다.

8. 8. 📡 동일한 클라우드 리전 내에서 1GB를 전송하는 데 약 10초가 소요됩니다.

8.1 동일한 클라우드 리전 내에서 네트워크를 통해 1GB를 전송하는 데 약 10초가 소요됩니다.

12. CI/CD In 5 Minutes | Is It Worth The Hassle: Crash Course System Design #2

TLDR: 지속적 통합/지속적 배포(CI/CD)는 소프트웨어 개발 및 배포를 자동화하여 더 빠르고 더 나은 품질의 릴리스를 가능하게 하는 프로세스입니다.

1. CI/CD는 소프트웨어 개발 및 배포를 자동화하여 더 빠르고 더 나은 품질의 릴리스를 가능하게 합니다.

1.1 CI/CD는 코드 커밋부터 배포까지 소프트웨어 개발 프로세스를 자동화하여 팀이 더 나은 품질의 소프트웨어를 더 빠르게 배포할 수 있도록 지원합니다.

2. 🚀 워크플로를 자동화하여 코드 변경 사항을 자주 병합합니다.

2.1 CI 서버의 자동화된 워크플로를 통해 팀은 코드 변경 사항을 공유 리포지토리에 조기에 그리고 자주 병합할 수 있습니다.

3. CI에 대한 밸런싱 테스트는 노력할 만한 가치가 있으며 일반적인 도구로는 Github, Actions, Buildkite, Jenkins, CircleCI, TravisCI 등이 있습니다.

3.1 불규칙하지 않고 충분한 커버리지를 가진 테스트 세트를 유지하는 것은 균형 잡힌 작업이지만 노력할 가치가 있으며, CI에 사용되는 일반적인 도구로는 Github, Github Actions, Buildkite, Jenkins, CircleCI 및 TravisCI가 있습니다.

4. 가장 많이 사용되는 빌드 도구는 Java용 Gradle과 Javascript용 Webpack입니다.

4.1 테스트 도구와 빌드 도구는 언어 및 에코시스템에 따라 다르며, 가장 많이 사용되는 도구는 Gradle for Java와 Webpack for Javascript입니다.

5. 올바른 도구와 모니터링을 통해 지속적 배포를 안전하게 수행할 수 있습니다.

5.1 지속적인 배포는 어렵지만 상태 비저장 시스템과 우수한 프로덕션 모니터링을 통해 안전하게 수행할 수 있습니다.

6. 빠르고 안전한 롤백을 위해 기능 플래그와 카나리아 배포를 사용하여 대규모 제품을 배포합니다.

6.1 상태 비저장 시스템을 사용하면 빠르고 안전하게 롤백할 수 있으며, 대규모 제품에는 기능 플래그와 카나리아 배포가 일반적인 관행입니다.

7. 7. 🚀 위험이 제한된 실제 환경에서 새 코드를 테스트합니다.

7.1 새로운 프로덕션 코드를 소수의 사용자에게 배포하면 문제가 발생할 위험을 제한하면서 실제 환경에서 테스트하는 데 도움이 됩니다.

8. 지속적 배포를 구현하면 시스템의 복잡성에 따라 팀이 더 나은 품질의 소프트웨어를 더 빠르게 배포할 수 있습니다.

8.1 지속적 배포(CD)는 팀이 더 나은 품질의 소프트웨어를 더 빨리 출시하는 데 도움이 되는 강력한 소프트웨어 개발 방법이지만 시스템의 복잡성에 따라 구현 방식이 달라질 수 있습니다.

13. Top 5 Redis Use Cases

TLDR: Redis는 웹 애플리케이션의 응답 시간을 개선하기 위해 일반적으로 캐시로 사용되는 빠르고 다재다능한 인메모리 데이터 저장소이며 분산 잠금, 속도 제한, 게임 리더보드에도 사용할 수 있습니다.

1. Redis는 확장성 문제를 해결하기 위해 일반적으로 캐시로 사용되는 빠르고 다재다능한 인메모리 데이터 저장소입니다.

1.1 Redis는 확장성 문제를 해결하기 위한 빠르고 다양한 기능으로 인해 일반적으로 캐시로 사용되는 인메모리 데이터 구조 저장소입니다.

2. Redis는 자주 요청되는 데이터를 메모리에 저장하여 웹 애플리케이션의 응답 시간을 개선하는 캐싱 툴입니다.

2.1 Redis는 일반적으로 자주 요청되는 데이터를 메모리에 저장하여 데이터베이스의 부하를 줄이고 웹 애플리케이션의 응답 시간을 개선하는 캐싱 도구로 사용되며, 스테이트리스 서버 간에 세션 데이터를 공유하기 위한 세션 저장소로도 사용할 수 있습니다.

3. 💾 서버가 재시작되면 Redis에 저장된 세션 데이터는 손실됩니다.

3.1 세션 데이터는 클라이언트에 쿠키로 반환되는 고유 ID와 함께 Redis에 저장되지만, Redis는 인메모리 데이터베이스이므로 Redis 서버가 재시작되면 세션 데이터가 손실된다는 점에 유의해야 합니다.

4. 💾 백업을 위한 복제, 분산 잠금을 위한 Redis.

4.1 프로덕션에서는 충돌 시 빠른 백업을 위해 복제를 사용하며, Redis는 공유 리소스에 대한 액세스를 조정하기 위한 분산 잠금으로 사용됩니다.

5. 5. 🔒 SETNX 명령은 잠금을 획득하기 위해 타임아웃과 함께 고유 값을 설정하고 다른 클라이언트가 해제할 때까지 재시도합니다.

5.1 SETNX 명령은 호출자가 고유한 값과 시간 제한이 있는 키를 설정하여 잠금을 획득하고 다른 클라이언트가 잠금을 해제할 때까지 작업을 재시도할 수 있도록 합니다.

6. 카운터를 증분하고 만료 시간을 설정하여 허용된 한도를 초과하는 요청을 거부함으로써 Redis를 속도 제한기로 사용합니다.

6.1 Redis는 카운터를 증가시키고 만료 시간을 설정하여 속도 제한기로 사용할 수 있으며, 기본 알고리즘은 카운터를 허용된 속도 제한과 비교하고 제한을 초과하는 경우 요청을 거부합니다.

7. Redis는 만료되는 키와 점수로 정렬된 세트가 있는 속도 제한 및 게임 리더보드에 사용할 수 있습니다.

7.1 Redis는 만료되는 키와 관련 점수로 정렬된 세트의 구현을 통해 속도 제한 및 게임 순위표에 사용할 수 있습니다.

14. Everything You Need to Know About DNS: Crash Course System Design #4

요약: 이 동영상의 핵심 아이디어는 DNS가 도메인 이름을 IP 주소로 변환하는 계층적 서버 시스템으로, 클라우드 제공업체가 운영하는 권한 있는 네임 서버에 의존하여 분산되고 강력한 시스템을 만든다는 것입니다.

1. DNS는 도메인 이름을 IP 주소로 변환하는 서버의 계층적 시스템입니다.

1.1 DNS는 사람이 읽을 수 있는 도메인 이름을 기계가 읽을 수 있는 IP 주소로 변환하며, DNS 계층 구조에서 다양한 용도로 사용되는 여러 유형의 서버로 구성됩니다.

2. 2. 🔍 DNS 쿼리는 확인자로 전달되며, 확인자는 답변을 보유한 권한 있는 네임서버를 찾으며, 권한 있는 DNS 서버는 세 가지 주요 수준으로 구성됩니다.

2.1 DNS 쿼리는 DNS 확인자로 전달되며, 확인자는 답변을 보유한 권한 있는 네임서버를 찾으며, 권한 있는 DNS 서버에는 세 가지 주요 수준이 있습니다.

3. 루트 및 TLD 네임 서버는 모든 도메인의 IP 주소를 저장하며, 13개의 논리적 루트 네임 서버와 각 IP 주소 뒤에 다수의 물리적 서버가 있습니다.

3.1 루트 네임 서버는 TLD 네임 서버의 IP 주소를 저장하고, 각 IP 주소 뒤에 많은 물리적 서버가 있는 13개의 논리적 루트 네임 서버가 있으며, TLD 네임 서버는 그 아래에 있는 모든 도메인에 대한 권한 있는 네임 서버의 IP 주소를 저장합니다.

4. 4. 🌐 DNS는 AWS 및 Cloudflare와 같은 클라우드 제공업체가 운영하는 권한 있는 네임 서버를 사용하여 분산되고 강력한 시스템을 구축합니다.

4.1 DNS는 권한 있는 이름 서버를 사용하여 다양한 유형의 TLD 이름에 대한 쿼리에 대한 답변을 제공하며, AWS 및 Cloudflare와 같은 클라우드 제공업체는 강력한 권한 있는 이름 서버를 실행하여 고도로 분산되고 강력한 시스템을 구축합니다.

5. 🔍 브라우저는 루트 네임 서버에 .com TLD 네임 서버 목록을 요청하기 전에 캐시 및 DNS 확인자 캐시를 확인합니다.

5.1 브라우저는 캐시, 운영 체제 캐시, DNS 확인자 캐시를 확인한 후 응답을 찾을 수 없으면 루트 네임 서버에 .com TLD 네임 서버 목록을 요청합니다.

6. 6. 🔍 DNS 확인자는 TLD에 대한 IP 주소를 캐시하여 브라우저에 반환합니다.

6.1 DNS 확인자는 .com과 같은 일반적인 TLD에 대한 IP 주소를 캐시하고, 권한이 있는 네임서버를 위해 TLD 네임서버에 연락한 후 브라우저에 IP 주소를 반환합니다.

7. 7. 🚨 느린 전파 위험을 완화하기 위해 DNS 레코드의 TTL을 미리 줄입니다.

7.1 각 레코드의 TTL로 인해 DNS 전파가 느려지므로 업데이트 전에 레코드의 TTL을 미리 줄여 위험을 완화하세요.

8. DNS는 인터넷 백본에 매우 중요하므로 트래픽이 감소할 때까지 기존 서버를 계속 실행하세요.

8.1 DNS는 인터넷 백본의 중요한 구성 요소이므로 트래픽이 허용 가능한 수준으로 감소할 때까지 이전 IP 주소에서 서버를 계속 실행합니다.

15. 10+ Key Memory & Storage Systems: Crash Course System Design #5

TLDR: 이 동영상에서는 RAM과 ROM의 차이점, 다양한 유형의 RAM, HDD, SSD, 플래시 드라이브 및 SD 카드와 같은 다양한 저장 장치에 대해 설명합니다.

1. RAM은 임시 데이터를 저장하는 반면, ROM은 전원이 꺼져 있어도 데이터를 유지합니다.

1.1 RAM은 컴퓨터가 실행되는 동안 데이터를 임시로 저장하는 반면, ROM은 전원이 꺼져 있어도 데이터를 유지합니다.

2. 널리 사용되는 GDDR6를 포함한 DDR 변형은 오늘날 시장에서 가장 일반적인 RAM 유형이며, SRAM은 더 빠르고 비싸고 DRAM은 더 느리고 저렴하지만 지속적으로 새로 고쳐야 합니다.

2.1 다양한 유형의 RAM에는 SRAM과 DRAM이 있으며, SRAM은 더 빠르고 더 비싼 반면 DRAM은 더 느리고 저렴하지만 지속적으로 새로 고쳐야 하며, 오늘날 시장에서 가장 일반적인 유형은 DDR 변형이며, GDDR6가 GPU 처리에 가장 널리 사용됩니다.

3. 3.1 ROM은 하드웨어 통신을 제어하고 BIOS는 컴퓨터를 시작하며 HDD와 SSD도 살펴봅니다.

3.1 ROM에는 두 가지 필수 역할이 있습니다: 펌웨어는 하드웨어 통신을 제어하고 BIOS는 컴퓨터를 시작하고 운영 체제에 제어권을 넘겨주며, 하드 디스크 드라이브와 솔리드 스테이트 드라이브에 대해서도 살펴봅니다.

4. HDD는 회전하는 디스크를 사용하여 데이터를 저장하고, SSD는 플래시 메모리를 사용하며, NVMe는 CPU에 직접 연결되는 SSD용 고속 인터페이스입니다.

4.1 HDD는 회전하는 자기 디스크에 데이터를 저장하는 반면, SSD는 NAND 기반 플래시 메모리를 사용하며, NVMe는 PCIe 레인을 통해 CPU에 직접 연결되는 SSD용 고성능 인터페이스입니다.

5. 플래시 드라이브와 SD 카드는 파일 전송 및 저장을 위한 편리한 저장 장치입니다.

5.1 플래시 드라이브와 SD 카드는 컴퓨터 간에 파일을 전송하고 카메라와 스마트폰에 수천 개의 파일을 저장할 수 있는 작고 사용하기 쉬운 장치입니다.

6. 컴퓨터 메모리는 데이터를 일시적으로 저장하는 반면, 스토리지는 데이터를 영구적으로 보관합니다.

6.1 컴퓨터 메모리와 스토리지에 대한 간략한 개요.

16. Cache Systems Every Developer Should Know

TLDR: 캐싱은 최신 컴퓨팅에서 시스템 성능을 개선하고 응답 시간을 단축하는 데 필수적이며 하드웨어 캐시, TLB, OS 관리 캐시, CDN, 로드 밸런서, 메시지 브로커, Redis, Elastic Search 및 데이터베이스의 여러 수준의 캐싱을 통해 구현할 수 있습니다.

1. 캐싱은 최신 컴퓨팅에서 시스템 성능을 개선하고 응답 시간을 단축합니다.

1.1 캐싱은 일반적인 시스템 아키텍처의 각 계층에서 여러 전략과 메커니즘을 통해 시스템 성능을 개선하고 응답 시간을 단축하는 최신 컴퓨팅의 중요한 기술입니다.

2. 하드웨어 캐시는 자주 액세스하는 데이터와 명령어를 저장하여 CPU가 빠르게 액세스할 수 있도록 합니다.

2.1 하드웨어 캐시(L1, L2, L3 및 번역 룩어사이드 버퍼 포함)는 자주 액세스하는 데이터와 명령어를 저장하여 CPU가 빠르게 액세스할 수 있도록 합니다.

3. TLB는 가상-물리적 주소 변환을 저장하고, OS는 캐시를 관리하여 최근에 사용한 디스크 블록을 메모리에 저장합니다.

3.1 TLDR: TLB(Translation Lookaside Buffer)는 가상-물리 주소 변환을 저장하여 메모리에서 데이터에 액세스하는 데 필요한 시간을 줄여주며, 운영 체제는 페이지 캐시 및 기타 파일 시스템 캐시를 관리하여 최근에 사용한 디스크 블록을 메모리에 저장합니다.

4. 캐시는 자주 액세스하는 데이터를 저장하여 더 빠르게 검색할 수 있도록 함으로써 파일 시스템 및 웹 검색 속도를 향상시킵니다.

4.1 캐시는 파일 시스템 작업 속도를 높이고 웹 브라우저는 HTTP 응답을 캐시하여 데이터를 더 빠르게 검색할 수 있습니다.

5. CDN은 콘텐츠를 캐싱하여 원본 서버에서 가져올 필요성을 줄임으로써 콘텐츠 전송 속도를 향상시킵니다.

5.1 CDN은 캐싱을 통해 콘텐츠 전송 속도를 높여 원본 서버에서 콘텐츠를 다시 가져올 필요가 없습니다.

6. 로드밸런서와 메시지 브로커는 리소스를 캐싱하여 응답 시간을 개선하고 서버 부하를 줄일 수 있습니다.

6.1 로드밸런서와 메시지 브로커는 리소스를 캐시하여 응답 시간을 개선하고 백엔드 서버의 부하를 줄일 수 있습니다.

7. 🔍 데이터베이스에는 여러 수준의 캐싱이 있는 반면, Redis와 Elastic Search는 빠르게 분산된 캐시입니다.

7.1 Redis와 Elastic Search는 각각 높은 읽기/쓰기 성능과 특정 데이터에 대한 효율적인 액세스를 제공하는 분산 캐시인 반면, 데이터베이스는 여러 수준의 캐싱을 사용할 수 있습니다.

8. 데이터 캐싱은 시스템 성능 향상을 위한 핵심 요소이며 데이터베이스 클러스터에서 버퍼 풀, 구체화된 보기, 트랜잭션 로그 및 복제 로그를 사용합니다.

8.1 데이터 캐싱은 시스템 성능을 최적화하고 응답 시간을 단축하는 데 중요하며, 쿼리 결과에 사용되는 버퍼 풀과 구체화된 보기, 데이터베이스 클러스터의 업데이트 및 복제 상태를 추적하는 트랜잭션 및 복제 로그를 사용합니다.

17. 8 Key Data Structures That Power Modern Databases

이 동영상에서는 효율적인 검색, 삽입, 삭제 작업을 위해 최신 데이터베이스에서 사용되는 8가지 필수 데이터 구조에 대해 설명하고 주간 시스템 설계 뉴스레터를 홍보합니다.

1. 효율적인 검색, 삽입 및 삭제 작업을 위해 최신 데이터베이스에서 사용되는 8가지 필수 데이터 구조에 대해 알아보세요.

1.1 이 동영상에서는 효율적인 검색, 삽입, 삭제 작업을 위해 스킵 리스트와 해시 인덱스 등 최신 데이터베이스에서 사용되는 8가지 필수 데이터 구조에 대해 설명합니다.

2. 해시 인덱스는 해시 함수를 사용하여 키를 값에 매핑하는 빠르고 효과적인 방법입니다.

2.1 해시 인덱스는 해시 함수를 사용하여 키를 값에 매핑하는 빠르고 효율적인 방법입니다.

3. 3. 💾 SSTable과 LSM Tree는 함께 작동하여 데이터를 압축된 형식으로 저장함으로써 대량의 쓰기 작업을 효율적으로 처리합니다.

3.1 SSTable과 LSM Tree는 파일 기반 데이터 구조로, 함께 작동하여 데이터를 압축된 효율적인 포맷으로 저장함으로써 대량의 쓰기 작업을 효율적으로 처리합니다.

4. 4. 💾 LSM-Tree 및 B-Tree는 디스크에 대량의 데이터를 저장하고 검색하기 위해 NoSQL 데이터베이스에서 사용되는 효율적인 데이터 구조입니다.

4.1 LSM-Tree 및 B-Tree 제품군은 디스크에 대량의 데이터를 효율적으로 저장하고 검색하기 위해 NoSQL 데이터베이스에서 널리 사용되는 데이터 구조입니다.

5. 🔍 반전 인덱스는 대규모 텍스트 컬렉션에서 데이터를 검색하고 검색하는 데 도움이 되며, ElasticSearch와 같은 검색 엔진에서 일반적으로 사용됩니다.

5.1 반전 인덱스는 대규모 텍스트 문서 컬렉션에서 데이터를 효율적으로 검색하고 검색하는 데 사용되며, 일반적으로 ElasticSearch와 같은 문서 검색 엔진에서 사용됩니다.

6. 🔍 접미사 트리와 R-tree는 데이터베이스에서 데이터를 검색하고 구성하는 두 가지 효율적인 방법입니다.

6.1 접미사 트리는 데이터베이스에서 텍스트를 효율적으로 검색하는 반면, R-tree는 데이터베이스에서 공간 데이터를 구성하고 검색합니다.

18. I used Angular's signals to build an actual app

요약: 이 동영상에서는 선언적 프로그래밍과 손쉬운 리팩터링을 위해 Angular에서 rxjs 신호를 사용할 때의 이점에 대해 설명하지만, 비동기 이벤트 조정을 위해 rxjs를 마스터하고 명령형 코드로 인한 버그 및 UX 문제를 방지하는 것이 중요하다는 점을 강조합니다.

1. angular signals를 사용하도록 앱을 리팩토링하고, angular signals에 대한 의견을 변경했습니다.

2. 📝 체크리스트와 완료 상태가 있는 할 일 목록 앱으로, rxjs와 옵저버블을 사용하여 반응형 선언적 스타일로 코딩했습니다.

3. 👉 Angular에서 signal를 사용하면 선언적 프로그래밍 스타일과 손쉬운 리팩터링이 가능합니다.

4. 💻  시그널 집합에서 세트 업데이트 또는 변경 메서드를 사용하여 새로운 시그널을 도출하고 부작용을 대체할 수 있습니다.

5. 💻 새로운 효과 메서드와 함께 탭 연산자를 사용하면 변경에 대한 응답으로 임의의 코드를 실행할 수 있지만 비동기 이벤트 조정에는 여전히 rxjs와 같은 것이 필요합니다.

6. 💡 신호가 충분하지 않을 때 비동기 이벤트를 조정하는 데 Rxjs가 도움이 될 수 있습니다.

7. 💻 선언적 코드를 무시하면 버그와 UX 문제가 발생할 수 있지만, 많은 개발자가 rxjs 대신 명령형 코드를 사용하고 있습니다.

8.  💻 Angular 개발자는 선언적 코딩을 위해 rxjs 시그널을 마스터해야 할 수 있습니다.

19. Popularity of top frameworks on Netlify: Next.js, Gatsby, create-react-app

https://www.netlify.com/blog/framework-popularity-on-netlify/

이 문서는 Netlify 플랫폼에서 웹 프레임워크의 인기에 대한 유용한 통찰력을 제공합니다. 제시된 데이터에 따르면, create-react-app, Next.js, Gatsby 및 Hugo가 Netlify에서 가장 인기있는 네 개의 프레임워크이며, React 기반 프레임워크가 선두를 유지하고 있습니다. 이러한 결과는 개발자들 사이에서 React가 인기있는 선택으로 자리 잡았다는 사실과 일치합니다. 조사 대상 개발자 중 71%가 React를 사용한다고 보고했습니다.

이 문서는 대부분의 Netlify 사용자가 개발 프로세스를 가속화하기 위해 프레임워크를 선택한다는 것을 설명합니다. Netlify는 50가지 이상의 다른 프레임워크를 추적하지만, 상위 네 개를 포함한 소수의 프레임워크가 시장을 지배하고 있습니다. 흥미로운 관찰은 사용자들이 웹사이트에 대해 더 심각해질수록 create-react-app을 사용하지 않을 가능성이 높아진다는 것입니다. 반면, Next.js와 Gatsby는 상대적으로 인기가 유지됩니다. 이것은 create-react-app이 아직 완전히 기업용으로 사용될 준비가 되지 않은 것일 수 있다는 것을 시사할 수 있습니다.

웹 프레임워크에 대한 통찰력 외에도, 이 문서는 2021 Jamstack Community Survey에서 서버리스 함수의 인기 증가와 보안이 개발자들에게 더욱 중요해지고 있다는 등 다른 결과들을 강조합니다. 조사는 또한 더 많은 개발자들이 Jamstack에서 완전히 동적인 앱을 구축하고 있다는 것을 보여줍니다. 또한, 이 문서는 팬데믹이 원격 개발로의 전환을 크게 가속화했다는 것을 언급합니다.

총괄적으로, 이 문서는 웹 개발 산업과 그것을 형성하는 동향에 대한 포괄적인 개요를 제공합니다. 웹 개발에 관심이 있는 사람이나 최신 산업 동향을 파악하고자 하는 사람에게는 꼭 살펴볼 가치가 있습니다.

20. The Future of AI-driven Design and Development, Today

https://www.builder.io/blog/ai

이 문서는 현재와 미래의 디자인 및 개발에서 AI 기술의 가능성을 탐구합니다. 저자는 AI 섹션 생성, AI 편집 및 AI 미니 앱 생성 세 가지 주요 주제를 제시합니다. AI 기술을 활용하여 웹 사이트 섹션을 생성하고 콘텐츠를 편집하며 심지어 완전한 미니 애플리케이션을 생성하는 방법을 설명합니다. AI 기술을 활용하여 사용자는 코딩 및 시각적 편집 도구를 배우는 데 소요되는 소중한 시간을 절약할 수 있으며, 이는 창의적 및 전략적 목표에 더 집중할 수 있도록 해줍니다.

이 문서는 또한 AI 기술 사용의 희생양인 AI가 콘텐츠 생성에 소요하는 시간 및 특정 영역에서 AI 기술의 한계 등을 인정합니다. 그러나 저자는 여전히 AI 기술이 많은 사용 사례에 대해 효율적이고 강력한 도구를 제공할 수 있다고 강조합니다.

이 문서는 AI 기술이 기존 워크플로에 통합되어 팀이 협력하고 더 효율적으로 작업할 수 있도록 하는 방법에 대해 논의하여 마무리됩니다. AI 기술의 통합은 Mitosis 및 headless CMS API와 같은 오픈 소스 프로젝트를 활용하여 원활하게 실현할 수 있습니다.

전반적으로, 이 문서는 디자인 및 개발에서 AI 기술의 가능성과 창의성, 효율성, 협업을 향상시키기 위해 활용하는 방법에 대한 중요한 통찰력을 제공합니다.

21. useEffect sometimes fires before paint

https://blog.thoughtspile.tech/2021/11/15/unintentional-layout-effect/

이 문서는 useEffect가 업데이트 블로킹을 방지하기 위해 그림 이후에 실행될 것으로 예상되는 경우에도 때로는 그림 이전에 실행되는 문제를 탐구합니다. 이 문서는 useLayoutEffect에서 상태를 업데이트하면 같은 렌더링에서 모든 useEffect가 그림 이전에 실행되도록 만들어 레이아웃 효과로 변경된다는 것을 설명합니다. 이는 useEffect에서 상태가 업데이트되는 경우 깜빡임이 발생할 수 있습니다.

이 문서는 이러한 문제를 피하기 위한 실용적인 조언을 제공합니다. 첫째로, 업데이트 후 useEffect에 의존하지 않도록하는 것을 제안합니다. 그러나 새로운 렌더링보다 먼저 실행될 것이 보장됩니다. 둘째로, 앱 성능에 해로운 useLayoutEffect에서 상태를 업데이트하지 않는 것이 좋습니다. 그러나 이러한 것이 항상 가능하지는 않으므로 성능 중요 시나리오에서 상태 업데이트를 우회하고 DOM을 직접 변경하는 것이 좋습니다.

또한, 이 문서는 레이아웃 효과를 분할하는 데 시간을 낭비하면 문제가 해결되지 않을 뿐만 아니라 난잡해질 수 있으므로 주의를 줄 것을 권장합니다. 대신 모든 크기 추적 로직을 하나의 layoutEffect에 유지하는 것이 더 안전하고 깔끔합니다. 마지막으로, 이 문서는 효과에 의존하지 않는 상태 모델을 고안하는 것이 좋지만 도전적인 문제라는 것을 인정합니다.

22. Discriminated Unions are a Frontend Dev's Best Friend

https://www.totaltypescript.com/discriminated-unions-are-a-devs-best-friend

이 문서는 TypeScript의 discriminated unions 개념과 프론트엔드 개발자가 애플리케이션의 여러 상태를 나타내는 데 사용할 수 있는 방법을 탐구합니다. 프론트엔드 개발자로서 데이터 로딩, 양식 작성 대기, 텔레메트리 이벤트 전송 등 앱의 여러 상태를 처리하는 것이 중요합니다. 프론트엔드 개발의 복잡성은 이러한 다양한 상태를 관리하는 데 있습니다.

이 글에서는 상태 변수를 나타내기 위해 "옵션의 집합"을 사용하는 경우 발생하는 문제점에 대해 논의합니다. 이 방법은 옵셔널 속성이 가득 찬 객체를 사용하는 것을 의미하며, 불가능한 모양을 선언하는 문제를 발생시킬 수 있습니다. 예를 들어, 상태가 "로딩"인 경우 데이터나 오류는 절대 존재해서는 안됩니다. 반면, 상태가 "성공"인 경우 데이터는 항상 존재해야 하며, 상태가 "오류"인 경우 오류가 항상 존재해야 합니다. 대신 discriminated union을 사용하면 더 정확하게 다른 상태를 나타낼 수 있습니다.

이 글에서는 discriminated union을 사용하여 상태 변수를 나타내는 예제를 제공합니다. discriminated union은 공통 필드인 discriminant를 사용하여 union 타입의 다른 객체 유형을 구별하는 유형의 union입니다. discriminant 속성은 union의 모든 객체에 나타나는 literal type입니다. 이렇게 하면 TypeScript가 사용되는 union 객체를 추론할 수 있으며, 개발자가 적절한 속성에 액세스할 수 있습니다.

이 글에서는 discriminated union을 해체하는 방법에 대해서도 논의합니다. 객체를 해체할 때 TypeScript는 union의 모든 객체에 존재하는 속성만 액세스할 수 있도록 허용합니다. 이는 특정 union 유형에만 존재하는 속성에 액세스하려고 할 때 문제를 발생시킬 수 있습니다. 먼저 union 분기가 사용되는지 확인한 후 적절한 상태 변수를 안전하게 해체할 수 있습니다.

요약하자면, 이 글은 discriminated unions을 사용하여 프론트엔드 애플리케이션의 다양한 상태를 나타내는 방법을 자세히 설명합니다. discriminated union을 사용하면 각 상태에서 적합한 데이터만 사용할 수 있도록 하여 더 정확하고 오류가 적은 코드를 작성할 수 있습니다. 이 글은 다른 유형의 데이터를 나타내기 위해 discriminated union을 사용하는 방법에 대한 예제도 제공하므로 TypeScript 기술을 개선하려는 프론트엔드 개발자에게 유용한 자료가 될 것입니다.

22. Folder Structure for Modern Web Applications

https://dev.to/noruwa/folder-structure-for-modern-web-applications-4d11

이 문서는 현대적인 웹 어플리케이션을 개발할 때 잘 구성된 폴더 구조를 유지하는 중요성을 강조합니다. 이렇게 하면 개발자가 코드를 조직하는 데 도움을 줄 뿐만 아니라 다른 개발자들이 개발 중에 어플리케이션의 아키텍처를 이해할 수 있습니다. 이를 위해, 문서는 폴더 이름을 디자인하는 데 사용할 수 있는 팁과 예시를 제공합니다.

문서는 개발자가 웹 프로젝트의 목적을 이해하고 시작해야 한다고 조언합니다. 이를 통해 어플리케이션에 포함된 자산과 기능을 조직할 수 있습니다.

문서는 폴더와 파일에 대해 서술적이고 적절한 이름을 사용하는 것의 중요성을 강조합니다. 이렇게 함으로써 웹 어플리케이션의 목적을 나타내고 작업을 더 쉽게 만들 수 있습니다.

문서는 다양한 폴더를 다루며, 이를 사용하여 웹 어플리케이션의 다른 측면을 조직할 수 있습니다. 이에는 자산, 컨텍스트, 컴포넌트, 컴포저블, 데이터, 기능, 훅, 레이아웃, 모듈, 페이지, 퍼블릭, 라우트, 유틸리티/유틸, 및 뷰가 포함됩니다. 각 폴더는 특정 목적을 갖고 있으며, 이를 사용하여 개발자는 웹 어플리케이션을 더 잘 조직할 수 있습니다.

Assets 폴더에는 웹 어플리케이션에서 사용되는 이미지, 아이콘, CSS 파일, 폰트 파일 등이 포함됩니다. 컨텍스트 폴더에는 여러 컴포넌트와 페이지에서 사용되는 모든 React 컨텍스트 파일이 저장됩니다.

컴포넌트 폴더에는 웹 어플리케이션의 UI가 포함됩니다. 이에는 navbar, footer, button, modal, card 등의 UI 컴포넌트가 포함됩니다. 컴포저블 폴더는 Vue 어플리케이션의 문맥에서 상태를 캡슐화하고 재사용합니다. 데이터 폴더에는 JSON 파일로 사용되는 다른 섹션 및 페이지에서 사용되는 텍스트 데이터가 저장됩니다.

Features 폴더에는 인증, 테마, 모달 등 각 페이지에 대한 개별 폴더 기능이 포함됩니다. 훅은 개발자가 함수 컴포넌트에서 React 상태 및 라이프사이클 기능에 "hook into" 할 수 있도록 하는 함수입니다. 레이아웃 폴더는 웹 페이지의 일반적인 느낌과 느낌을 정의하고 사이드바, navbar, footer와 같은 레이아웃 기반 컴포넌트를 배치합니다. 모듈 폴더는 웹 어플리케이션에서 특정 작업을 처리합니다.

페이지 디렉토리에는 웹 어플리케이션 뷰가 포함됩니다. Next Js 및 Nuxt Js와 같은 프론트 엔드 프레임워크에서 페이지 디렉토리는 디렉토리 내의 모든 파일을 읽고 개발자를 위해 자동으로 라우터 구성을 생성합니다. 퍼블릭 디렉토리에는 favicon.ico와 같이 변경되지 않는 공용 파일이 포함됩니다. 라우트 폴더에는 다른 스크린으로의 경로가 저장됩니다. 유틸리티/유틸 폴더에는 인증, 테마, handleApiError와 같은 모든 유틸리티 함수가 저장됩니다. 뷰 폴더는 웹 어플리케이션 페이지를 올바르게 나타내어 사용자가 앞뒤로 탐색할 수 있도록 합니다.

요약하면, 잘 구성된 폴더 구조는 개발자가 파일을 더 쉽게 찾고 관리할 수 있도록 해주어 전문적으로 보이게 합니다. 제공된 팁과 예시를 따르면 개발자는 현대적인 웹 어플리케이션을 위한 유지 가능한 폴더 구조를 디자인할 수 있습니다.

23. How to handle errors in React: full guide

https://www.developerway.com/posts/how-to-handle-errors-in-react

이 포괄적인 가이드는 React에서 오류를 효과적으로 처리하는 방법에 대한 개발자에게 귀중한 통찰력을 제공합니다. 이는 try/catch 블록을 사용하는 것의 한계를 숙지하고, 훅 또는 자식 컴포넌트 내에서 오류를 잡기에 적합하지 않은 이유를 강조합니다. 대신, 이 가이드는 이러한 한계를 극복하기 위한 ErrorBoundary 컴포넌트를 제안하며, ErrorBoundary를 React 애플리케이션에 구현하는 데 도움이 되는 실용적인 예제와 코드 스니펫을 제공합니다.

이 가이드는 ErrorBoundary가 일반적인 컴포넌트를 React 선언적 코드의 try/catch 문으로 변환하여 작동하는 방식을 능숙하게 설명합니다. 또한 ErrorBoundary가 React 라이프사이클 도중 발생하는 오류를 잡을 수 있지만, 해결된 프로미스, setTimeout을 사용한 비동기 코드, 다양한 콜백 및 이벤트 핸들러와 같이 라이프사이클 외부에서 발생하는 오류를 잡을 수 없다는 점을 명확히 합니다.

React 라이프사이클 외부에서 발생하는 오류를 잡기 위해서는, 이 가이드는 try/catch 블록을 활용하는 것을 권장합니다. 비동기 코드 및 이벤트 핸들러에서 오류를 잡고 ErrorBoundary가 잡도록 다시 throw하는 방법에 대한 유용한 예제를 포함합니다.

이 가이드는 또한 콜백을 위한 훅이나 래퍼를 생성하여 ErrorBoundary로 비동기 오류를 잡는 해킹을 추상화하는 방법에 대해 다룹니다. 개발자가 사용하고 자신의 특정 사용 사례에 적합하도록 수정할 수 있는 코드 스니펫을 제공합니다.

전반적으로, 이 가이드는 개발자들에게 React에서 오류를 처리하는 방법에 대한 깊은 이해를 제공하며, ErrorBoundary를 구현하고 애플리케이션에서 오류를 능숙하게 잡을 수 있는 필요한 도구와 지식을 제공합니다.

24. Project Management for Software Engineers

https://sookocheff.com/post/engineering-management/project-management-for-software-engineers/

이 가이드는 소프트웨어 엔지니어가 프로젝트를 효과적으로 관리하기 위한 다섯 가지 주요 단계(시작, 계획, 실행, 모니터링 및 제어, 종료)를 제공합니다.

시작 단계에서는 핵심 이해 관계자를 확인하고 인터뷰를 통해 그들의 요구 사항과 욕구를 이해하여 명확하고 공유된 기대를 설정하는 것이 중요합니다. 이 단계는 승인된 범위 명세로 마무리됩니다.

계획 단계에서는 이해 관계자의 요구 사항을 기반으로 커뮤니케이션 계획을 작성하고, 실제 가치를 전달하고 학습 및 조정을 허용하는 단계별 작업으로 프로젝트를 분해하는 것이 권장됩니다. 프로젝트의 잠재적 위험과 그들이 프로젝트에 미치는 영향을 식별하기 위해 위험 관리 계획도 개발해야 합니다.

실행 단계에서는 지속적인 책임감이 성공을 위해 사람들을 참여시키는 데 필요합니다. 피드백과 이해 관계자의 입력을 기반으로 정기적인 체크인 및 조정이 권장됩니다.

모니터링 및 제어 단계에서는 계획 단계에서 개발된 커뮤니케이션 계획을 실행하여 이해 관계자에게 투명한 커뮤니케이션을 제공하는 것이 필수적입니다. 합의된 주기에서 정기적인 상태 보고서를 제공하여 프로젝트 상태 및 주요 선물의 상태를 제공해야 합니다.

마지막으로, 종료 단계에서는 성공을 측정하고 배운 교훈을 문서화하고 팀 및 이해 관계자와 함께 성공을 축하하는 것이 포함됩니다.

이 가이드는 프로젝트 관리 기술을 향상시키고 시작에서 종료까지 프로젝트를 성공적으로 이끌기 위해 노력하는 소프트웨어 엔지니어에게 유용한 자료입니다.

25. Building future facing frontend architectures

https://frontendmastery.com/posts/building-future-facing-frontend-architectures/

이 문서는 프론트엔드 아키텍처에서 단일체 컴포넌트의 문제점을 논하고, 이를 해결하기 위한 하향식 접근법을 제안합니다. 단일체 컴포넌트는 크고 복잡하며, 팀 간 코드 재사용성, 번들 크기 증가, 런타임 성능 저하와 같은 문제를 야기합니다. 하향식 접근법은 필요한 기능을 달성하기 위해 조합할 수 있는 더 작고 재사용 가능한 컴포넌트를 생성하는 것입니다. 이는 이른 추상화를 피하고, 단일체 컴포넌트 생성 위험을 줄이는 데 도움이 됩니다.

문서는 단일체 컴포넌트를 피하고 필요할 때 분해하는 여러 전략을 제안합니다. 그 중 하나는 하향식으로 생각하면서 단일 책임 원칙과 DRY 원칙을 균형있게 유지하는 것입니다. 모든 것을 DRY하게 만들기 전에 컴포넌트를 추상화해야 할 필요성이 있는지 살펴보는 것이 좋습니다. 또 다른 전략은 제어 반전을 사용하여 유연하고 성능 좋은 컴포넌트를 구축하는 것입니다. 컴포넌트는 자식을 통해 "슬롯"을 노출하거나 제어 반전을 소비자 측에서 유지하는 렌더 스타일 속성을 렌더링할 수 있습니다.

문서는 정기적으로 단일체 컴포넌트를 분해하는 중요성을 강조하며, 이를 수행할 수 있는 일반적인 리팩터링 패턴을 제공합니다. 단일체 컴포넌트 생성의 근본적인 모델과 상황을 이해함으로써 이른 추상화를 피하고, 보다 견고하고 적응 가능한 컴포넌트를 구축할 수 있습니다.

결론적으로, 이 문서는 프론트엔드 아키텍처에서 단일체 컴포넌트와 관련된 문제를 해결하기 위한 하향식 접근법을 제안합니다. 문서는 단일체 컴포넌트를 피하고 필요할 때 분해하는 전략을 제공합니다. 이러한 전략을 따르면, 변화하는 요구 사항에 적응할 수 있는 보다 유연하고 성능 좋은 프론트엔드 컴포넌트를 구축할 수 있습니다

26. The future of Jamstack & Serverless

https://www.youtube.com/watch?v=TRqXAo5T3Zc

이 영상은 Jamstack과 서버리스 컴퓨팅의 미래에 대한 토론영상입니다. 발언자들은 시스템이 어떻게 작동하는지 모니터링하고 이해하는 능력인 관측 가능성의 중요성과 데이터 센터의 지속 가능성을 측정하는 어려움과 같은 이러한 기술의 다양한 측면을 탐구합니다. 또한 서버리스 컴퓨팅으로 인한 비용 절감과 환경 이점에 대한 잠재적 가능성도 탐구합니다.

대화에서 강조된 핵심 요소 중 하나는 자동 계기 기능 개념입니다. 이는 코드에서 모니터링 및 로깅을 자동으로 활성화하여 개발자가 직접 설정하는 작업에서 해방시키는 것을 의미합니다. 이것은 특히 소스를 식별하기가 어려운 분산 시스템에서 중요합니다.

발언자들은 분산 시스템에서 신뢰성에서 회복력으로의 이동도 언급합니다. 이는 시스템이 작동하는지 여부뿐만 아니라 고객 요구 사항을 충족시키는 데 충분히 잘 작동하는지에 대한 것입니다. 이것은 실패를 처리하고 변화하는 상황에 적응할 수 있는 시스템을 만드는 것을 필요로 합니다.

데이터 센터의 지속 가능성을 측정하는 것이 어렵다는 것도 토론의 주요 주제 중 하나입니다. 서버리스 컴퓨팅이 환경 이점을 제공할 수 있는 가능성이 있지만 서로 다른 기술의 영향을 정확하게 측정하는 것은 어렵습니다. 그러나 발언자들은 지속 가능성이 다가오는 5년 동안 모든 클라우드 회사의 운영에서 중요한 측면이 될 것이라는 것에 동의합니다.

27. Discussing tRPC & GraphQL with Theo Browne & Max Stoibe

이 토론에서 Theo Browne과 Max Stoiber는 trPC와 GraphQL의 차이점을 탐구하면서 각 접근 방식의 강점과 약점을 논의합니다. Theo는 trPC가 프론트엔드 코드에서 백엔드 코드를 호출하기 위한 더 간단하고 효율적인 옵션이라고 설명합니다. 그는 trPC가 서버와 클라이언트 모두에서 호출할 수 있는 함수를 쉽게 작성할 수 있도록 하여 필요한 코드량을 줄이고 성능을 개선시킬 수 있다고 말합니다. 반면, Max는 GraphQL이 다중 클라이언트와 언어를 사용하는 더 복잡한 사용 사례에 더 적합하다고 주장합니다. 그는 GraphQL이 쿼리에 대한 더 많은 유연성을 제공하며 더 복잡한 데이터 구조를 처리할 수 있다는 점을 강조합니다.

이 토론에서는 프레임워크의 내장 메커니즘과의 경쟁에 대한 주제도 다룹니다. trPC는 간결함과 사용 편의성으로 웹 개발 커뮤니티에서 인기를 얻었지만, 일부 개발자는 선택한 프레임워크에서 제공하는 내장 메커니즘을 사용하는 것을 선호할 수 있습니다. 그러나 Theo와 Max는 trPC와 GraphQL 중 선택하는 것이 최종적으로 프로젝트의 특정 사용 사례와 문맥에 따라 달라진다는 것에 동의합니다.

마지막으로, 모바일 개발을 고려하는 것이 중요함을 강조합니다. trPC는 웹 개발에 적합한 옵션이 될 수 있지만, 모바일 개발은 다른 접근 방식이 필요합니다. Theo와 Max는 모바일 개발이 독특한 도전 과제를 제공하며, 개발자들이 백엔드 솔루션을 선택할 때 신중하게 고려해야 한다는 것을 인정합니다.

28. My Stack Is Changing

이 비디오에서는 Drizzle ORM, Chad의 UI 패키지, React 서버 컴포넌트 등 풀 스택 개발에 대한 새로운 도구와 개선 사항, 미래의 T3 스택을 위해 서버 데이터와 클라이언트 작업 간의 간극을 줄이기 위한 데이터 업데이트 패턴 재구성의 필요성 등이 다루어집니다.

개선 사항, 미래의 T3 스택을 위해 서버 데이터와 클라이언트 작업 간의 간극을 줄이기 위한 데이터 업데이트 패턴 재구성의 필요성 등이 다루어집니다.

29. The REAL Cost Of Avoiding AWS

비디오의 핵심 아이디어는 엔지니어들이 권장되는 클라우드 서비스를 사용하고, 널리 사용되는 무료 티어를 활용하며, 고유한 비즈니스 차별화 요소를 강화하면서 제품을 개선해야 한다는 것입니다. 동시에 엔지니어의 시간 비용과 자체 호스팅 또는 AWS 사용의 혜택을 고려해야 합니다.

30. Vite and Module Federation Makes Micro-Frontends EASY!

모듈 연합(Module Federation)은 React에서 코드와 컴포넌트를 런타임에 공유하여 여러 개의 애플리케이션을 관리하는 다중 팀을 가진 회사에 아키텍처적 이점을 제공합니다.

31. The useEffect cleanup and the two circumstances it's called.

https://reacttraining.com/blog/setting-state-on-unmounted-component

이 문서는 React 개발자가 언마운트된 컴포넌트의 상태를 업데이트하려고 시도할 때 만날 수 있는 경고 메시지에 대한 통찰력을 제공합니다. 이 경고 메시지는 "언마운트된 컴포넌트에서 React 상태 업데이트를 수행할 수 없습니다. 이것은 작동하지 않지만 응용 프로그램에서 메모리 누수를 나타냅니다." 라고 명시되어 있습니다.

이 문서는 이 경고 메시지가 종종 무시될 수 있으며, 응용 프로그램에서 반드시 메모리 누수가 발생한 것은 아니라는 것을 명확히 합니다. 실제로, 이 경고 메시지 때문에 존재하지 않는 문제를 해결하려고 노력한 개발자들도 있습니다. 또한 React는 최신 버전인 React 18에서 이 경고 메시지를 제거했는데, 이는 항상 메모리 누수의 표시가 아니기 때문입니다.

그 다음으로, 이 문서는 개발자가 실제 메모리 누수를 인식하고 해결하는 방법을 설명합니다. 구독(소켓 등에 사용되는)은 구독 해제하지 않으면 메모리 누수를 발생시킬 수 있기 때문에 이를 방지하기 위해 useEffect()의 클린업 함수를 활용하는 방법에 대한 예제를 제공합니다.

또한, 이 문서는 클린업 함수가 메모리 누수뿐만 아니라 레이스 컨디션과 같은 다른 문제를 해결하는 데 중요하다는 것을 강조합니다. 레이스 컨디션을 해결하기 위해 isCurrent 전략을 적용하는 방법에 대한 예제를 제공합니다.

32. Where did Hooks come from?

https://reacttraining.com/blog/where-did-hooks-come-from

이 문서는 React의 코드 공유를 위한 API의 역사와 Hooks의 개발이 어떻게 컴포넌트 간 공통 로직 공유 방식을 혁신시켰는지 탐구합니다. 이 문서는 클래스 기반 컴포넌트의 한계를 강조하며, React 커뮤니티가 이러한 한계를 극복하기 위해 고차 컴포넌트(Higher Order Components, HoC) 및 렌더 프롭(Render Props)와 같은 패턴을 사용했다는 것을 설명합니다. 그러나 이러한 패턴에는 몇 가지 문제가 있었고, 이 문제들을 극복하기 위해 Hooks가 개발되었습니다.

이 문서는 Hooks의 개발 과정을 자세히 설명하며, 컴포넌트 간 공통 로직을 공유하는 방법을 보여줍니다. 문서는 "로직"이 JSX 이전의 모든 코드를 의미하며, Hooks는 UI 컴포넌트를 공유하기 위한 것이 아님을 명확히 합니다. Hooks는 기본적으로 함수이며, 함수형 컴포넌트 내에서 호출될 수 있습니다. Hooks는 내장된 Hooks와 사용자 정의 Hooks로 나뉘며, useState()와 같은 내장된 Hooks는 함수형 컴포넌트가 React의 모든 기능에 액세스 할 수 있도록 합니다. 반면 사용자 정의 Hooks는 우리가 작성하고 내장된 Hooks를 구현하는 함수입니다.

문서는 내장된 Hooks와 사용자 정의 Hooks의 예시를 제공하여 컴포넌트 간 코드를 공유하는 방법을 보여줍니다. Hooks가 데이터 가져오는 로직을 공유하는 데 어떻게 사용되는지와 로컬 상태를 지속시키는 더 효율적인 방법을 제공하는지를 보여줍니다.

문서는 여전히 클래스를 사용하여 컴포넌트를 만들 수 있다는 것을 인정하면서도, Hooks가 이제 React 개발의 주요 방법이라는 것을 강조합니다. React 생태계의 대부분의 타사 라이브러리도 Hooks를 채택하고 있습니다. 또한 Hooks는 다른 React 개발자와 쉽게 협업할 수 있는 더 쉬운 방법을 제공합니다.

총적으로, 이 문서는 React의 코드 공유를 위한 API의 진화와 Hooks가 컴포넌트 간 공통 로직 공유의 주요 방법이 된 과정을 포괄적으로 제시합니다. Hooks를 사용하는 것과 클래스 기반 컴포넌트를 사용하는 것의 장단점에 대한 유용한 통찰력을 제공하며, React 개발에서 최신 도구와 기술을 항상 업데이트하는 것의 중요성을 강조합니다.

33. Dropbox Engineering Career Framework

https://dropbox.github.io/dbx-career-framework/overview.html

커리어 프레임워크는 엔지니어가 수행하는 직무에 따라 각 레벨에서 요구되는 능력과 행동 방법을 자세히 기술한 문서입니다.

이 문서는 엔지니어의 진로와 성장에 매우 중요한 역할을 합니다. 각 레벨별로 요구되는 능력을 확인하고, 이를 바탕으로 자신이 현재 어느 위치에 있는지 파악할 수 있습니다.

또한, 자신이 어떤 능력이 필요하고, 이를 어떻게 발전시켜 나갈 수 있는지를 알 수 있습니다.커리어 프레임워크는 엔지니어의 역량 평가와 개발에 필수적인 자료입니다.

이를 통해 엔지니어는 자신의 역량을 더욱 정확하게 파악하고, 미래에 필요한 능력을 미리 예측하여 준비할 수 있습니다. 또한, 기업에서는 커리어 프레임워크를 바탕으로 인사정책을 수립하고, 엔지니어의 역량을 개발하기 위한 교육과정을 설계할 수 있습니다.

따라서, 커리어 프레임워크는 엔지니어와 기업 모두에게 이점을 제공하는 중요한 문서입니다. 엔지니어는 자신의 역량과 성장을 위해 이를 꼭 활용해보시길 추천드립니다.

34. I Was Wrong About React Server Components...

이 비디오에서는 Remix와 React와 같은 프레임워크를 사용하여 백엔드 및 프론트엔드 아키텍처를 공존시키는 장점 및 서버 코드와 클라이언트 파일을 함께 작성할 수 있는 미래 개발 동향에 대해 논의합니다.

35. Secret React Server Component Patterns They Don't Want You To Know

이 비디오는 다양한 모델의 React Server Components와 NextJS 13을 사용하여 추천 캐로셀 구현을 다룹니다. 추천 API 구축, Jotai atoms 및 custom hooks 사용, 서버 사이드 fetch 구현 및 React 18의 streaming 기능 활용이 포함됩니다.

36. State of node.js 2023

https://www.youtube.com/live/Yl5mVte-wdw

37. NextJS - SPA or MPA?

https://www.code-insights.dev/posts/nextjs-spa-or-mpa

이 문서는 대형 번들 크기로 인해 단일 페이지 애플리케이션(SPA)이 점차적으로 줄어들고 Astro와 같은 다중 페이지 애플리케이션(MPA)이 더 많아지는 추세에 대해 논의합니다.

Next.js 13에서는 대부분의 컴포넌트가 서버 측에서 렌더링되어 작은 번들이 생성되지만 페이지가 로드된 후에는 여전히 SPA처럼 작동합니다. 이 문서는 점진적으로 향상된 SPA(PESPA) 개념을 소개하며, 해당 주제에 대한 Kent C. Dodds를 읽어볼 것을 권장합니다.

38. How Migrating from Vanilla Redux to Redux Toolkit Improved State Management in Shopify POS (2023)

https://shopify.engineering/react-redux-toolkit-migration

이 문서에서 Shopify은 Redux에 대한 일반적인 불만을 해결하는 라이브러리인 Redux Toolkit(RTK)로 Retail Point of Sale 앱을 마이그레이션하는 과정을 공유합니다. 마이그레이션 이유, RTK 사용의 이점 및 마이그레이션 프로세스에서의 전략과 도전 과제에 대한 개요가 이 문서에서 제공됩니다.

마이그레이션은 약 3개월이 걸리며, RTK 기능 대부분을 마이그레이션하면서 보다 복잡한 코드는 Vanilla와 유사한 스타일로 남겨둔 균형잡힌 방식으로 진행되었습니다. 이 방식이 앱을 불안정해지지 않으면서 코드 재사용과 Redux 구현의 단순화를 가능하게 한다는 판단하에 진행되었습니다.

RTK의 장점 중 하나는 보일러플레이트 뿐인 3,500줄의 코드를 삭제할 수 있게 되어 상태 관리 아키텍처를 이해하고 디버깅하기 쉽게 만들었으며, 새로운 기능을 만들 때 보일러플레이트를 작성할 필요가 없어져 기능 개발이 더욱 빨라졌습니다.

그러나 팀은 비동기 로직을 마이그레이션하는 방법에 대해서는 도전을 겪었습니다. RTK를 사용한 비동기 로직의 권장 방식은 createAsyncThunk를 사용하여 웹 요청을 하고, 생성된 pending 및 fulfilled 액션을 사용하는 것입니다. 그러나 팀은 마이그레이션 중 앱을 불안정하게 만들지 않으려고 이 방식을 수정해 사용했습니다.

이러한 도전에도 불구하고, 팀은 RTK를 사용하여 Vanilla Redux 코드와 전문 지식을 재사용하면서 현대적인 JavaScript 상태 관리 솔루션의 이점을 얻는 쉬운 방법이라고 평가했습니다. 보일러플레이트 코드를 상당량 삭제하고, Redux 구현을 단순화하고, 기능 개발을 빠르게 만들었습니다. 전반적으로, 이 문서는 Vanilla Redux에서 RTK로 마이그레이션하는 장점과 도전 과제에 대한 유용한 통찰력을 제공합니다.

이번주 준비한 것은 여기까지입니다 😄

읽어주셔서 감사합니다 😉