React(리액트) 기술 블로그 최신 글

FE News 26년 11월 소식을 전해드립니다.

주요소식 26년 11월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. ​ Tailwind Labs is joining Shopify Tailwind CSS를 만든 Adam Wathan이 Tailwind Labs의 Shopify 합류를 발표했다. Tailwind CSS를 비롯한 오픈소스 프로젝트는 계속 MIT 라이선스로 남고 Tailwind 팀이 Shopify의 지원을 받아 유지보수를 이어 가므로, 이미 쓰고 있는 팀이 당장 바꿀 것은 없다. 대신 유료 컴포넌트·템플릿 모음 Tailwind Plus와 에이전트 스킬 모음 ui.sh는 신규 가입을 받지 않으며, Wathan은 사용자와 같은 문제를 겪는 실제 커머스 제품 안에서 프레임워크를 개발하고 싶었다고 배경을 설명한다. ​ ​ ​ Introducing tsrs: a Port of TypeScript to Rust Cloudflare와 VoidZero가 TypeScript 컴파일러를 Rust로 옮기는 tsrs를 Oxc 툴체인 안에서 개발한다고 발표했다. Go로 다시 작성한 TypeScript 7보다 WebAssembly 환경에 잘 맞고 메모리를 적게 쓰는 것이 목표로, 팀의 초기 벤치마크에서는 TypeScript 7.0보다 최대 8배 빠르고 메모리를 약 70% 덜 썼다. 비슷한 시기에 나온 ts-rust, Bun의 bun check, Vercel Labs의 tsc-ts도 함께 소개하며, 모두 실험 단계이므로 CI 타입 검사가 병목인 팀이라면 기존 tsc와 진단 결과를 비교하며 시험해 볼 만하다. ​ ​ ​ Making React Context Cheap with React Compiler Context 값이 바뀌면 그 Context를 읽는 모든 컴포넌트가 다시 렌더링되는 비용을 React Compiler로 줄이는 방법을 다룬 글이다. 라디오 버튼 5,000개 예제에서 컴포넌트를 나누지 않고 Context를 그대로 읽게 둔 채 메모이제이션을 React Compiler에 맡기면, 클릭 처리 시간이 useSyncExternalStore 스토어나 React.memo로 나눈 방식과 비슷한 수준이 된다. 저자는 렌더링 횟수보다 렌더링 한 번의 작업량이 사용자 체감을 좌우한다며, 렌더링을 없애기보다 싸게 만드는 데 집중하라고 권한다. ​ ​ ​ React 19.3 실험 단계였던 <ViewTransition>과 Fragment Refs가 안정화되었다. <ViewTransition>은 Transition으로 표시된 업데이트에서 요소의 등장, 퇴장, 갱신에 View Transition API 애니메이션을 적용하고, Fragment Refs로는 래퍼 요소 없이 형제 DOM 노드 묶음에 이벤트 리스너나 Observer를 연결할 수 있다. 컴포넌트를 서버 렌더링에서 제외하는 browser() API와 Trusted Types 지원도 추가되었으며, Strict Mode가 하이드레이션 중에도 Effect를 두 번 실행하므로 업그레이드 후에는 정리 함수가 없는 Effect부터 점검해 둬야 한다. ​ ​ ​ Remix 3 Remix 3이 Remix Jam 2026에 맞춰 첫 안정 버전으로 출시되었다. remix 패키지 하나에 라우터, 데이터베이스 관리, 스키마 검증, 에셋 서버, React가 아닌 자체 UI 런타임을 담은 풀스택 프레임워크이며, 기존 Remix 2 앱은 Remix 3이 아니라 React Router로 옮기게 된다. 10월 23일 나온 3.1은 코드 변경 없이 서버 렌더링을 약 두 배 빠르게 했고, 팀은 정식 출시 이후 SemVer를 지키겠다고 밝혔다. ​ ​ ​ >> FE News 26년 11월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. ▷ 구독하기

검색해도 안 나오는 SQL을 새로 만들다

K-Metrics 제작 후기 #2 검색해도 안 나오는 SQL을 새로 만들다 최고운 AX팀 AI로 더 나은 일하는 방식을 고민하는 AI 엔지니어 업무의 언어를 이해하고, 함께 쿼리를 고치기까지 지난 편에서는 동료들이 업무에서 사용하고 확인한 쿼리를 모아, 자연어로 찾아 재사용하는 이야기를 했어요. 등록된 쿼리로 답할 수 있는 질문이라면 새 SQL을 만들지 않고도 업무를 시작할 수 있죠. 그렇다면 검색이 “못 찾았어요”라고 답한 요청은 어떻게 처리할까요? 등록된 쿼리가 다루지 않는 대상을 조회하거나, 다른 기준으로 집계해야 한다면 새로운 SQL이 필요합니다. 이번 편은 그다음을 다룹니다. 검색으로 답하기 어려운 요청을 K-Metrics가 어떻게 새로운 SQL로 만드는지, 그 과정에서 업무 용어를 해석하고 필요한 조건을 사용자와 확인하는 방법을 살펴볼게요. 만들어진 쿼리를 업무 의도에 맞게 이어서 고치는 과정도 함께 다룹니다. SQL 한 번을 생성하는 것만큼, 그 SQL을 사용자의 업무 의도에 맞게 다듬어 가는 과정에 집중했습니다. 질문이 SQL이 되기까지 “지난달 A상품 신규 가입 고객 수를 연령대별로 보여 줘”라는 요청을 예로 들어볼게요. 이 질문에 답하려면 무엇을 셀지, 어떤 데이터를 사용할지, 기간과 집계 기준을 어떻게 적용할지 정해야 합니다. K-Metrics는 질문을 요구사항으로 나누고, 테이블·컬럼과 조건을 정해 SQL을 작성한 뒤 검증해요. 문제가 있으면 필요한 단계로 돌아가고, 재시도 한도 안에서 해결되지 않으면 남은 문제를 정리해 반환합니다. SQL 생성과 검증·재시도 흐름 이 과정을 모델에게 한 번에 맡기지 않고 여러 단계로 나눈 데에는 이유가 있습니다. 왜 자율 에이전트보다 단계별 워크플로우가 필요했을까? 검색이나 스키마 조회를 도구로 제공하고, 모델이 다음 행동을 선택하도록 만들 수도 있습니다. 판단하고 도구를 사용한 뒤 그 결과로 다음 행동을 정하는 ReAct 방식이라면, SQL 생성 외의 정보 탐색까지 유연하게 연결할 수 있죠. 다만 이 서비스에서는 그 자유도보다 운영 중 처리 과정을 추적하고 통제할 수 있는 구조가 더 중요하다고 봤어요. 그 출발점은 모델에게 한 번에 맡기는 판단의 범위를 정하는 일이었습니다. 온프렘 LLM의 제한된 컨텍스트를 효율적으로 쓰기 위해 작업을 작은 목표로 나눴어요. 테이블을 고를 때는 요구사항과 후보 설명을, SQL을 작성할 때는 선택한 스키마와 확정된 계획을 전달합니다. 각 단계가 해야 할 일과 필요한 정보를 함께 좁힌 것이죠. 작업을 나누고 나니, 단계 사이에서 반드시 지켜야 할 순서도 분명해졌습니다. 특히 생성한 SQL의 검증을 모델에게 도구로 주고 ‘필요하면 호출해’라고 맡기고 싶지는 않았어요. SQL 작성 뒤에는 구조 검증으로 이어지고, 결과에 따라 의도 검증이나 수정으로 넘어가도록 경로를 정했습니다. 모델이 복구 방향을 제안하더라도, 이동할 수 있는 단계와 재시도·종료 조건은 코드가 관리하도록 했어요. 자율 에이전트와 단계별 워크플로우의 차이 이렇게 단계와 경로를 명시하면, 결과가 잘못됐을 때 되짚을 지점도 생깁니다. 최종 SQL만 보는 대신 요구사항 해석·테이블 선택·컬럼 매핑의 중간 결과를 따라가며 어느 판단에서 문제가 시작됐는지 확인할 수 있어요. 단계별 입출력을 기준으로 프롬프트 수정과 테스트의 출발점도 좁혀 볼 수 있습니다. LangGraph는 이 설계를 실행 흐름으로 옮기는 데 사용했습니다. 단계별 결과는 상태로 전달하고, 검증 결과에 따라 앞 단계로 돌아가는 분기와 반복은 조건부 연결로 표현했어요. LangGraph로도 자율 에이전트를 만들 수 있고, ReAct에도 검증과 재시도 제한을 붙일 수 있습니다. 결국 선택의 핵심은 프레임워크의 우열이 아니라, 판단은 모델에 맡기되 반드시 거쳐야 할 검증과 재시도·종료 조건은 코드로 관리하겠다는 것이었어요. 사내에서 쓰는 용어를 실제 조건으로 만들기 생성 흐름을 나눴다고 해서 모델이 우리 행의 업무까지 이해하지는 못 합니다. 사용자가 평소 쓰는 줄임말도 알아들어야 하고, 짧은 요청에 생략된 업무 기

‘왜 이렇게 만들었을까’라는 질문으로 성장하는 웹 에디터 팀

“본질에 집중하고, 질문으로 성장하다.” 미리캔버스 편집 기능을 만드는 미리디 웹 에디터 팀이 실제로 일하는 방식이에요. 이 팀에서는 “왜 이렇게 만들었을까”라는 질문 하나가, 기능을 만드는 사람을 구조를 설계하는 사람으로 자라게 해요. 그 성장과 협업의 이야기를 웹 에디터 팀 백동열, 김예지, 이은지 님에게 들어봤어요. 지난 1부에서는 웹 에디터 엔진 개발자가 어떤 일을 하고, 어떤 점에서 매력적인 직무인지 살펴봤어요. → 1부 인터뷰 바로가기 ‘왜 이렇게 만들었을까’를 묻다 보니, 이만큼 성장해 있었어요 Q. 1부에서 어떤 일을 하시는지는 들었는데요, 실제로 이 팀에서 일하면서는 어떻게 성장하셨어요? 구체적으로 궁금해요. 동열님: 저희 팀에는 “왜 이렇게 만들었을까”를 서로에게 계속 묻는 문화가 있어요. 그러다 보니 최근 프로젝트에서도 코드부터 짜지 않고, 이 기능이 정확히 어떤 문제를 풀어야 하는지부터 짚었어요. 예를 들어, 여러 화면에서 반복되는 로직을 하나로 관리해야 하는 문제는 싱글톤 패턴(하나의 객체만 만들어 두고 여러 곳에서 함께 쓰는 설계 방식)으로 풀었고, 나중에 기능이 늘어나도 구조를 크게 안 바꿔도 되도록 인터페이스와 추상화를 활용했어요. 도형을 되돌리거나 다시 실행하는 것처럼 복잡한 편집 동작은 커맨드 패턴으로 묶어서, 동작 하나하나를 안정적으로 관리할 수 있게 만들었고요. 여기에 Jotai(리액트에서 상태를 다루는 라이브러리)로 상태를 효율적으로 관리하고, 페이지가 많아져도 버벅이지 않도록 비동기 처리를 최적화하고 불필요한 렌더링을 막는 메모이제이션까지 적용했어요. 이런 식으로 문제를 정의하고, 그에 맞는 구조를 설계한 다음, 그 구조를 코드로 구현하는 순서를 자연스럽게 몸에 익히게 됐어요. 물론 시도한 방식이 늘 성공하지는 않았어요. 그래도 괜찮았던 건, 애자일 방식으로 일하다 보니 왜 안 됐는지 확인하고 다시 도전할 여유가 있었기 때문이에요. 은지님: 저는 조금 다른 방식으로 성장을 경험했어요. 처음 웹 에디터 팀에 왔을 때 마침 에디터를 새로 만드는 중이었는데, 그중에서도 애니메이션 기능을 처음부터 개발하는 일을 맡게 됐어요. 그전까지는 이미 만들어진 기능에 새 기능을 덧붙이거나 개선하는 일을 주로 해왔던 터라, 아무것도 없는 상태에서 시작해야 한다는 게 처음엔 꽤 막막했어요. 그래서 이전 버전의 애니메이션 구조를 하나하나 뜯어보고, 매주 시니어 동료들에게 설계 리뷰를 받으면서 애니메이션뿐 아니라 재생 가능한 기능 전반에 쓸 수 있는 인터페이스를 차근차근 잡아나갔어요. 이 과정을 거치고 나니, 기능을 처음부터 끝까지 설계하고 구현하는 힘이 확실히 붙었어요. 예지님: 저는 주니어 개발자다 보니 “이런 걸 일하면서 배울 수 있다니” 싶은 순간이 자주 찾아와요. 모던 프레임워크를 쓰면서도 객체지향, MVC, MVVM 같은 다양한 설계 패턴을 실제로 접하다 보니, 코드를 보는 눈이나 구조에 기능을 녹이는 능력이 조금씩 느는 게 스스로도 느껴져요. 가끔은 “혹시 나도 본질을 이해하기 시작한 걸까” 싶어서 재미있어지는 순간도 있어요. 지적 대신 질문으로, 서로의 성장을 돕는 방식 Q. 그 “왜 이렇게 만들었을까”라는 질문이 실제로는 어떻게 오가나요? 팀 분위기나 협업 방식이 궁금해져요. 동열님: 저희 팀은 코드를 쓰고, 그에 대해 솔직하게 피드백하는 문화를 중요하게 생각해요. 실제로 업무 중 작성한 코드를 리뷰 주제로 가져와서, 매주 다 같이 모여 다양한 의견을 자유롭게 나누고 있어요. 이 시간에는 어떤 방향으로 코드를 짜면 좋을지, 성능을 더 끌어올리려면 로직을 어떻게 구성할지, 놓친 실수는 없는지를 여러 관점에서 서로 짚어줘요. 재미있는 건 피드백을 주는 사람도 자기가 평소에 놓치고 있던 부분을 새롭게 알게 되는 경우가 많다는 거예요. 그러다 보니 모두에게 도움이 된다는 반응이 많고, 자연스럽게 서로 성장하는 건강한 피드백 문화가 자리 잡았다고 생각해요. 은지님: 저희는 정기적인 팀 회의와 회고를 통해서도 새로운 기술을 소개하거나 개발한 내용을 자유롭게 공유해요. 이 자리에서는 누구나 편하게

2026년과 이후 JavaScript의 동향 - 브라우저 밖의 JavaScript

브라우저 밖의 JavaScript 동향을 마지막으로 다루었던 2019년 시점(1부, 2부)에서는 Node.js 12와 막 1년을 넘긴 Deno를 소개하며 "Node.js와 같은 성공을 거둘 수 있을지는 아직 미지수"라고 썼습니다. 패키지 관리자 영역은 "npm의 독주 체제"라고 표현했고 npm 회사의 불확실한 상황에 맞서 Entropic, Open-Registry, GitHub Package Registry 같은 도전자가 등장했다고 전했습니다. 7년이 지난 지금 Node.js는 연 1회 릴리스로 일정을 바꾸기로 했습니다. Node.js 호환을 목표로 삼게 된 Deno와 Bun은 각각 Cloudflare와 Anthropic에 합류했고, npm은 GitHub의 일부가 되어 공급망 공격과 싸우고 있습니다. 이번 연재는 다음 네 편으로 구성됩니다. 1편: JavaScript(ECMAScript) 2편: 브라우저 밖의 JavaScript 3편: WebAssembly 4편: 라이브러리와 프레임워크 이 글에서는 먼저 2019년 이후 7년의 변화를 짧게 정리합니다. 이어서 Node.js의 사용 현황과 릴리스 일정, 주요 기능, Deno와 Bun, 서버 런타임 표준인 WinterTC, 공급망 공격으로 크게 바뀐 패키지 관리자와 레지스트리, 데스크톱과 모바일 애플리케이션 개발 도구, PWA와 XR, OpenJS Foundation을 차례로 살펴봅니다. 마지막으로 AI 코딩 도구가 런타임과 패키지 생태계를 어떻게 바꾸었는지 정리합니다. 번들러와 브라우저 밖의 WebAssembly는 짧게 언급만 합니다. WASI와 엣지 플랫폼에서의 WebAssembly 실행은 3편 WebAssembly에서 자세히 다룹니다. 이 글의 내용은 2026년 10월을 기준으로 작성되었습니다. 글을 읽는 시점에 따라 글의 내용과 사실이 다를 수 있습니다. 2019년 이후 7년 2019년 글을 쓸 때 Node.js의 최신 버전은 12.13이었습니다. 2026년 10월 현재 최신 버전은 26.12이고 그사이 메이저 버전이 열네 번 나왔습니다(참고: Node.js 26.12.0 릴리스). 숫자보다 큰 변화는 런타임의 역할입니다. 2019년의 Node.js는 서버와 빌드 도구를 실행하는 런타임이었다면, 지금의 Node.js는 TypeScript 파일을 바로 실행하고 테스트 러너와 SQLite, WebSocket 클라이언트를 내장하며 권한 모델로 파일과 네트워크 접근을 제한합니다. 2019년에 별도 패키지를 설치해야 했던 기능 상당수가 런타임에 내장되었습니다. 경쟁 구도도 달라졌습니다. 2019년에는 Node.js와 Deno를 비교했지만 지금은 Bun까지 세 런타임이 Node.js 호환성을 두고 경쟁합니다. 다만 2026년 10월 Deno 팀이 Cloudflare에 합류하면서 Deno 런타임의 개발은 1년 뒤 끝나게 되었습니다. 패키지 생태계에서는 2020년 GitHub이 npm을 인수하면서 2019년 글이 걱정한 "기술 외적인 불확실성"이 해소되었습니다. 그 대신 2025년부터는 공급망 공격이 가장 큰 문제가 되었습니다. 메인테이너 계정을 탈취해 악성 버전을 올리는 공격이 반복되었고 스스로 퍼지는 웜까지 등장했습니다. npm과 pnpm은 설치 스크립트를 기본으로 실행하지 않도록 바꾸었습니다. 표 1 2019년 이후 브라우저 밖의 JavaScript 주요 사건 시기사건 2020년 3월 GitHub, npm 인수 발표(4월 인수 완료) 2021년 9월 Electron, 8주 릴리스 주기로 전환(Electron 15) 2024년 10월 Deno 2 출시, Tauri 2.0 출시, React Native 0.76에서 새 아키텍처 기본화 2024년 12월 Node.js 22.12에서 require(esm) 플래그 제거 2025년 1월 WinterCG가 Ecma TC55(WinterTC)로 이동, pnpm 10에서 의존성 설치 스크립트 기본 미실행 2025년 9월 chalk, debug 등 메인테이너 계정 탈취, Shai-Hulud 웜 2025년 11월 npm classic 토큰

FE News 26년 10월 소식을 전해드립니다.

주요소식 ​ The Story of VS Code Visual Studio Code 공식 채널이 공개한 약 1시간 38분 분량의 다큐멘터리로, Erich Gamma가 이끈 취리히 팀이 브라우저용 편집기 컴포넌트 Monaco Editor를 만들던 시기부터 데스크톱 VS Code 발표와 오픈 소스 전환까지의 과정을 30여 명의 관계자 인터뷰로 보여 준다. 확장을 별도 프로세스에서 실행하고 한번 공개한 API는 바꾸지 않는 원칙, TypeScript 서버에서 출발한 LSP, UI와 확장 호스트를 분리한 구조가 원격 개발과 vscode.dev로 이어진 배경을 설명한다. 후반부에서는 GitHub Copilot의 출발과 Ask, Edits, Agent Mode로 이어진 AI 기능, Cursor 같은 포크를 바라보는 VS Code 팀의 시각도 소개한다. ​ ​ Native is now the future of mobile at Shopify 2020년 React Native 전면 도입을 선언했던 Shopify가 모바일 앱을 다시 Swift와 Kotlin 네이티브로 옮긴다고 발표했다. 코딩 에이전트 덕분에 두 플랫폼에 각각 구현하는 비용이 줄면서 공유 구현보다 네이티브의 이점이 커졌다는 판단으로, Shop 앱은 12주 만에 재구축했고 화면을 작은 체크포인트로 나눠 테스트, 시각 비교, 적대적 코드 리뷰, 사람의 승인을 거치게 하는 Helix 시스템을 만들었다. React Native Skia, FlashList, Restyle 등 Shopify가 관리해 온 오픈소스의 향후 계획도 공개해, 이 라이브러리를 쓰는 프로젝트라면 전환 일정을 확인해 둬야 한다. ​ ​ 토스 FE 개발자들의 검증법 토스 웨비나에서 Front AI 팀이 AI로 만든 결과물을 검증하는 방법을 소개한 세션이다. 코드에서 시나리오를 추론해 E2E 테스트를 자동 생성하려던 시도가 실패한 뒤, 얼굴 인식 결제처럼 실수 비용이 큰 영역에서 테스트를 직접 작성하며 디바이스 팜 조작 도구, 액션 로그 조회 스킬처럼 테스트를 막던 요소를 해결하는 도구를 만들어 온 과정을 설명한다. 사람이 CI 실패 원인을 파악하도록 만든 replay 도구를 에이전트에 그대로 넘기자 버튼 문구 변경 같은 실패를 스스로 고쳤다는 경험은 AI 검증 체계를 고민하는 FE 팀이 참고할 만하다. ​ ​ penpot 브라우저에서 쓰거나 직접 설치해 운영할 수 있는 오픈소스 디자인, 프로토타이핑 플랫폼이다. 디자인을 SVG, CSS, HTML 같은 개방형 표준으로 표현하고 CSS Grid와 Flex 레이아웃, 디자인 토큰, 컴포넌트를 기본 기능으로 제공하며, MCP 서버를 통해 Cursor나 Claude Code 같은 AI 에이전트가 컴포넌트, 토큰, 레이어 구조를 읽고 수정할 수 있다. 셀프 호스팅이 가능해 디자인 데이터를 사내에 두어야 하는 조직이 검토해 볼 만한 MPL-2.0 라이선스 프로젝트다. ​ Full Course: Spec-Driven Development with Coding Agents DeepLearning.AI와 JetBrains가 만든 명세 주도 개발(Spec-Driven Development) 강좌의 전체 영상으로, 마크다운 명세를 먼저 쓰고 코딩 에이전트가 이를 구현하게 하는 흐름을 WebStorm과 Claude Code로 Next.js 예제 앱을 만들며 보여 준다. mission.md, techstack.md, roadmap.md로 프로젝트 헌장을 만든 뒤 기능마다 명세를 작성하고 컨텍스트를 비운 상태에서 구현을 맡기는 반복 과정을 설명한다. 기존 코드베이스에서 헌장을 역으로 만드는 방법과 Spec Kit, OpenSpec 같은 공개 SDD 도구도 소개해, 코딩 에이전트 결과물의 일관성을 고민하는 개발자에게 도움이 된다. ​ ​ >> FE News 26년 10월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움

집 나간 네트워크는 돌아왔는데 React.lazy는 왜 안 돌아올까

들어가며 파트너(업주)님이 영업 내내 주문을 받는 배민주문접수 웹뷰를 개발하던 중 QA 과정에서 네트워크 OFF -> ON으로 변경 후 다른 화면으로 이동 시 오류 화면이 노출된다는 티켓을 전달받았습니다. 원인을 파악해 보니 브라우저가 모듈 로드 실패를 기억하고 있었고, 이는 버그가 아니라 HTML 스펙에 명시된 동작이었습니다. 더 곤란한 것은 프런트엔드 빌드 도구인 Vite 공식 문서가 안내하는 해결책 중 […] 집 나간 네트워크는 돌아왔는데 React.lazy는 왜 안 돌아올까 first appeared on 우아한형제들 기술블로그.

FE News 26년 9월 소식을 전해드립니다.

26년 9월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. 주요소식 ​ ​ The AI Engineering Skills Map Andrew Ng이 DeepLearning.AI 팀과 함께 1만 건이 넘는 채용 공고 분석과 전문가 인터뷰, 설문을 종합해 정리한 AI 엔지니어링 역량 지도다. AI 애플리케이션 구축·배포, 소프트웨어 엔지니어링 기본기, 코딩 에이전트 활용, 그리고 무엇을 만들지 정하는 일(shaping the build) 네 가지를 지금 익힐 가치가 큰 역량으로 꼽는다. 저자는 이 역량들이 "AI 엔지니어"라는 직함에 한정되지 않고 풀스택, 데이터, DevOps를 포함한 모든 개발자에게 필요해진다고 보며, 앞으로 무엇을 학습 우선순위에 둘지 고민하는 개발자에게 참고할 만한 정리다. ​ How We Migrated lovable.dev Away from Next.js 월 4,200만 방문 규모의 lovable.dev를 Next.js에서 Cloudflare workerd 런타임 위의 TanStack Start로 옮긴 기록이다. 전면 재작성 대신 6개월간 두 프레임워크를 동시에 운영하면서 프록시 워커가 라우트 단위로 분기하도록 하고, 사용자 여정에 따라 묶은 라우트 그룹을 순차 전환했으며 실제 코드 이전은 대부분 AI 에이전트가 처리했다. 빌드 시간은 6~9분으로 줄고 중위 TTFB는 49% 빨라졌으며 개발 환경 메모리 사용량은 8GB에서 1.5GB로 내려간 수치도 함께 공개해, 대규모 프로덕션 앱의 프레임워크 전환을 무중단으로 진행하는 방법론으로 참고할 만하다. ​ How AI text watermarking works: a visual guide AI가 생성한 텍스트에 눈에 보이지 않는 표식이 어떻게 새겨지는지를 다섯 단계로 나눠 시각적으로 설명하는 가이드다. 워터마크는 글자가 아니라 단어와 단어 사이의 선택에 숨는데, 비밀 키로 후보 단어를 초록과 빨강으로 나누고 초록 쪽으로 확률을 살짝 기울인 뒤 검출 시 같은 방식으로 다시 색을 칠해 초록 비율을 세는 방식이다. 가벼운 편집은 표식을 희석하는 정도지만 표현이 겹치지 않게 다시 쓰면 사실상 지워지고, 키를 가진 쪽만 검증할 수 있어 공개된 "AI 탐지기" 사이트로는 확인할 수 없다는 실무적인 한계도 함께 짚는다. ​ Bun 1.4 Bun 1.4의 헤드라인은 코어를 Zig에서 Rust로 재작성한 것이다. 시작 시간은 Linux에서 2배, Windows에서 2.5배 빨라졌고 HTTP 서버의 메모리 사용량은 13~48% 줄었다. 내장 헤드리스 브라우저 자동화(Bun.WebView), Bun.Image, Bun.markdown, Terminal과 cron API가 추가되었고 Node.js 26.3.0 호환으로 1,517개 테스트가 새로 통과한다. React 사용자에게 눈에 띄는 것은 React Compiler 지원으로, Babel이나 SWC를 거치지 않고 Bun 자체 파서 안에서 컴파일러가 돌기 때문에 약 860개 컴포넌트 규모의 코드베이스에서 빌드 시간이 71ms 늘어나는 데 그쳐 Babel 플러그인 대비 약 20배 빠르다. ​ Next.js 16.3 Next.js 16.0 이후 가장 큰 업데이트로, 코드 변경 없이 얻는 개선과 옵트인 기능이 함께 담겼다. dev 서버는 Turbopack의 디스크 캐싱과 메모리 축출이 기본 활성화되어 메모리 사용량이 최대 90% 줄었고, next build에도 디스크 캐싱이 적용되어 CI 반복 빌드가 최대 5.5배 빨라졌다. 옵트인 기능인 Instant Navigations는 cacheComponents와 partialPrefetching 플래그를 켜면 Suspense 인라인 로딩 상태나 'use cache'로 표시한 UI를 추출해 내비게이션 전에 클라이언트로 실어 보내, 서버 주도 모델을 유지하면서 SPA 수준의 반응성을 확보한다. 이 외에 retry()로 서버 컴포넌트를 다시 가져올 수 있는 catchError 에러 바운더리, Vite 호환 import.meta.glob, root params가 추가되었

[4편] 리뷰피드는 정말 발견의 공간이 될 수 있을까?

WORXPHERE 12명의 사용자와 함께 가설을 깨고 다시 세운 이야기 안녕하세요, 저는 잡플래닛 프로덕트팀 프로덕트 디자이너 최경미입니다. 이번 글은 우리 팀이 ‘검색해야만 닿던 리뷰가, 사용자가 자연스럽게 발견하고 머무는 공간이 될 수 있을까?’라는 질문을 안고 12명의 사용자를 만난 뒤, 그것이 모두에게 통하지는 않는다는 걸 직접 확인한 이야기입니다. 짧게 말하면, 우리가 세운 가설과 사용자가 실제로 원하는 모습은 다를 수 있다는 걸 다시 배운 사흘이었습니다. 확인해보고 싶었던 것 “리뷰를 보려면 무조건 검색 밖에 없다” 먼저 데이터를 살펴봤습니다. 웹·앱 사용자 중 검색을 통해 기업 페이지에 도달한 비율은 각각 41.6%, 27.5%에 불과했습니다. 그렇다면 나머지 사용자는 어디에서, 어떻게 기업 페이지로 들어오고 있을까요? 재방문이 이어지지 않는 구조 MAU의 88%가 기업 페이지를 방문하지만, 2회 이상 방문한 사용자는 40%로 줄어듭니다. 일반 리뷰 조회도 58%에서 2회 이상은 31%에 그쳤습니다. 낮은 리뷰 작성률 활성 사용자 기준 리뷰 작성 완료율은 약 8%, 신규 가입 후 14일 내 작성 완료율도 9% 수준이었습니다. 저조한 재작성률 리뷰 작성 후 60일 내 다시 작성한 비율은 11.4%에 그쳤습니다. 이 숫자들을 한 줄로 요약하면 아래와 같습니다. 사용자는 잡플래닛에 들어오지만, 다시 방문하거나 직접 참여하는 단계까지는 좀처럼 이어지지 않고 있었습니다. ‘역구조 탐색’이라는 큰 가설 “검색이 아니라, 리뷰를 통해 기업을 발견할 수 있다면?” 지금까지의 잡플래닛은 검색 → 기업 페이지 → 리뷰 구조였는데, 이 흐름을 한번 뒤집어보기로 했습니다. 리뷰 피드 → 리뷰 발견 → 궁금해진 기업으로 이동 이를 검증하기 위해 5개의 가설을 세웠습니다. 역구조 탐색 리뷰를 먼저 노출하면 기업 페이지 혹은 리뷰 상세로 이동할까? 소비 지속성 탭·필터로 맥락별 리뷰를 연속 탐색할 수 있게 하면, 소비가 이어질까? 작성 전환 (권한 있는 경우) 유도 질문이나 면접 인사이트가 있으면 작성으로 이어질까? 작성 전환 (권한 없는 경우) 블라인드 vs 더보기 UI 중 어떤 형태가 더 궁금증을 유발할까? 면접 질문 탐색 면접 질문만 모아보면 더 잘 찾을 수 있을까? 피그마 프로토타입이 아닌 ‘진짜 프로토타입’으로 5개의 가설을 검증하려면 사용자가 실제로 클릭하고, 스크롤하고, 탭을 오가는 경험이 필요했습니다. 정적인 화면만으로는 부족했습니다. 그래서 실제로 동작하는 React 프로토타입을 만들고 GitHub Pages로 배포했습니다. AI를 활용해 인터랙션을 구현한 덕분에, 참여자들은 진짜 서비스처럼 화면을 탐색할 수 있었습니다. 이 경험의 밀도가 UT의 품질을 크게 좌우했습니다. UT는 내부 리허설 3명과 외부 참가자 9명, 총 12명을 대상으로 진행했습니다. 외부 참가자는 이직이 급한 사용자 7명과 그렇지 않은 사용자 2명으로 구성했고, 신입부터 10년 차까지 디자이너·UX 리서처·영업·연구개발·건축시공 등 다양한 직군을 만났습니다. 역구조 탐색은 작동했을까요? ‘역구조 탐색’이라는 큰 가설 아래, 어떤 형태로 보여주느냐에 따라 결과는 완전히 달랐습니다. 가설 1. 역구조 탐색 리뷰를 먼저 노출하면, 사용자는 리뷰를 통해 기업을 탐색하게 될 것이다 가설 1–1. 리뷰 원문 카드 → 9명 중 0명 가설 1–2. 리뷰 요약 타이틀 카드 → 9명 중 5명 가설 1–1. 리뷰 원문을 카드로 노출하면, 사용자는 내용을 읽다가 해당 기업이 궁금해져 기업명을 통해 기업 페이지로 이동할 것이다.가설 1–2. 리뷰의 한 줄 요약을 카드로 노출하면, 사용자는 제목만 보고도 해당 기업이 궁금해져 리뷰 상세 페이지로 이동할 것이다. 피드를 본 사용자 누구도 리뷰 원문을 읽다가 기업 페이지로 넘어가지 않았습니다. (가설 1–1) 뭘 놓치고 있었을까요? UT 전에는 하나의 피드 안에서 리뷰를 발견하고 소비하도록 만들 수 있다고 생각했습니다. 하지만 실제 사용자에게 리뷰는 새로운 기업을 찾는 콘텐츠가 아니라, 이미 알고 있는 회사를 판단하고 검

Unity를 모르는 프론트엔드 개발자가 AI로 Unity 서비스를 React로 옮긴 방법

이 글은 C#/Unity 경험이 없는 프론트엔드 개발자가 운영 중인 Unity 서비스를 React/Next로 마이그레이션하며, 검증 지점을 코드에서 자연어 명세로 옮긴다는 발상을 바탕으로 AI 협업 흐름 전체를 설계한 과정을 다룹니다. 특히 읽지 못하는 원본 코드를 AI가 관측 가능한 동작 중심의 명세로 번역하고, 그 명세를 구현·검증·리뷰가 참조하는 단일 기준으로 삼는 하네스 엔지니어링 접근을 설명합니다. 또한 iOS Safari의 한글 IME 이슈 사례를 통해 AI가 제시하는 '가장 흔한 정답'이 내 상황에 맞는지는 개발자가 판단해야 함을 보여주고, 단락 단위 가상 스크롤 전환 과정에서 AI를 "가설을 싸게 만들고 빠르게 버리는" 도구로 활용하는 구체적인 방법을 다룹니다. 나아가 hook 기반 자동 안전장치와 도메인별 AI 리뷰어 분리, 그리고 자율성을 의도적으로 제한한 트레이드오프 판단까지, 정확성이 중요한 마이그레이션 작업에서 AI에게 어디까지 맡길지 정하는 판단력을 실무적 관점에서 살펴보는 글입니다.

끝나지 않는 루프 에이전트를 멈추기까지

WORXPHERE 끝나지 않는 AI 에이전트 루프를 멈추기까지 React On Rails → Next.js 마이그레이션으로 시작한 루프 엔지니어링 안녕하세요. 웍스피어에서 잡플래닛 서비스를 담당하고 있는 프론트엔드 개발자 강태완입니다. 잡플래닛은 10년 넘게 운영된 서비스입니다. 오랜 시간 서비스를 운영하면서 Rails 위에 React가 붙고, 거기에 Next.js까지 들어왔습니다. 지금의 프론트엔드를 아주 단순하게 표현하면 대략 이런 구조입니다. 오래된 화면은 Rails가 렌더링하고, 그 안에서 React 컴포넌트가 동작합니다. 페이지를 이동하면 React가 들고 있던 상태도 함께 사라집니다. 한 페이지 안에서는 React를 사용하고 있지만, 페이지를 넘어 상태를 이어가기는 어렵습니다. 이전 단계의 값을 다시 전달하거나 복원하는 별도의 처리가 필요해서 페이지가 이어질수록 처리도 복잡해졌습니다. SEO도 비슷했습니다. 못 하는 건 아니지만, Rails와 React에 렌더링이 나뉘어 있다 보니 페이지마다 따로 챙겨야 할 부분이 있었습니다. 이런 불편함 때문에 지금은 오래된 Rails 페이지를 하나씩 Next.js로 옮기고 있습니다. 그런데 마이그레이션 기간이 길어질수록 또 다른 문제가 생겼습니다. 아직 안 옮긴 페이지는 Rails에 있고, 옮긴 페이지는 Next.js에 있습니다. 예를 들어 Rails와 Next.js 양쪽에서 공통으로 노출되는 상단 GNB를 수정하려면 두 프로젝트를 모두 수정해야 합니다. 한쪽만 고치면요? 당장은 아무 일도 일어나지 않습니다. 그리고 한참 뒤에 누군가 발견합니다. “어? 여기랑 저기 UI가 다른데요?” 그때 알게 됩니다. 아, 한쪽만 고쳤구나. 그래서 가능한 한 빨리 마이그레이션을 끝내는 것 자체가 이중 관리 비용을 줄이는 방법이었습니다. 문제는 옮겨야 할 페이지가 한두 개가 아니었다는 겁니다. 페이지마다 원본을 확인하고, Next.js로 구현하고, 다시 원본과 비교하는 비슷한 작업이 계속 반복됐습니다. 이 반복을 좀 줄여보고 싶어서 AI 에이전트를 사용하기 시작했습니다. 에이전트를 썼는데, 제가 더 바빠졌습니다 처음에는 단순하게 생각했습니다. “이 Rails 페이지를 Next.js로 옮겨줘.” 에이전트가 구현하면 결과를 확인하고, 다른 부분이 보이면 다시 요청했습니다. 수정이 끝나면 또 확인했습니다. 페이지 하나를 옮기는 데도 이 과정을 몇 번씩 반복해야 했습니다. 페이지가 많아지니 제가 확인해야 할 결과도 같이 늘어났고요. 에이전트를 쓰면 제가 편해져야 하는데, 제가 계속 에이전트를 감시하고 있었습니다. AI가 코드를 쓰는 속도보다 사람이 결과를 확인하는 속도가 느렸습니다. 병목은 에이전트가 아니라 사람 쪽에 있었습니다. 그러다 루프 엔지니어링에 대한 이야기를 접했고, 아이디어는 단순했습니다. 에이전트에게 사람이 매번 프롬프트하지 말고, 에이전트에게 프롬프트하는 프로그램을 만들자. 생각해보니 마이그레이션은 이 방식과 꽤 잘 맞아 보였습니다. 이미 원본 Rails 페이지가 있습니다. Next.js로 구현하고, 원본과 비교하고, 다르면 다시 고치면 됩니다. 그래서 사람이 반복하던 요청과 확인을 루프로 옮기기 시작했습니다. Workflow({ scriptPath: '.claude/workflows/rails-migration-loop.js', args: { page: 'welfare-review-write', phase: 'verify', }, }) 구현과 검증을 반복하다 보면 자연스럽게 원본에 가까워지고, 어느 순간 끝날 거라고 생각했습니다. 처음 돌려본 결과는 꽤 인상적이었습니다. 루프가 안 멈췄습니다. “더 고칠 게 있어?”라고 물으면 영원히 끝나지 않는다 첫 시도는 사실상 무한 루프였습니다. 루프에게 준 목표는 단순했습니다. “이 페이지를 Next.js로 옮겨줘.” 문제는 그다음이었습니다. 루프는 매 라운드마다 에이전트에게 “더 고칠 게 있어?”라고 물었습니다. 그러면 에이전트는 항상 고칠 것을 찾아냈습니다. “여백이 2px 정도 어색합니다.” 그걸 고치면 다음에는 타입을 조금

웹뷰 다음의 레일을 깔다: 당근이 Lynx를 선택한 이유

안녕하세요, 당근 프론트엔드코어팀 리더 Tony입니다. 저희 팀은 프론트엔드 엔지니어들이 쓰는 개발 환경과 배포 인프라를 만들어요. 이 글은 레퍼런스가 거의 없던 기술 Lynx를 검토해서 프로덕션 앱에 넣기까지의 기록이에요. 새로운 기술을 도입할지 고민해 본 분이라면 판단의 과정이 참고가 될 거예요. 웹뷰와 성능 문제 당근 앱의 여러 화면은 웹뷰로 만들어져 있습니다. 웹뷰는 화면을 열 때 웹 문서와 데이터를 네트워크에서 가져와 실행하는데, 이 초기 로딩 문제가 오래된 과제였어요. SSR을 활용하면 서버에서 미리 웹 문서를 그리는 식으로 JavaScript 평가와 DOM 조작의 성능 병목을 줄일 수 있어요. 하지만 웹 문서와 초기 데이터를 네트워크로 가져와야 하는 경로 자체는 남습니다. 실제 웹 화면과 비슷한 네이티브 화면을 웹뷰가 로드되기 전에 보여주는 방법도 있어요. 서비스 워커로 클라이언트 앱을 캐싱해 네트워크 요청 이전에 UI를 그리는 방법도 있고요. 다만 이런 최적화는 제품 복잡도를 높입니다. 주어진 제약 안에서 최적화하는 것도 중요하지만, 개발자가 의도한 UI를 첫 프레임부터 그릴 수 있는 실행 환경이 필요했어요. 우리가 정말 풀고 싶었던 문제는 로딩 시간을 몇 밀리초 더 줄이는 데 있지 않았습니다. 사용자가 로딩을 느끼지 못하게 만들고 싶었습니다. 새로운 실행 환경에 필요했던 조건 사용자가 만나는 첫 프레임에는 분리된 임시 화면이 아닌 실제 제품 UI가 보여야 했습니다. 네이티브 앱을 유지한 채 화면 단위로 적용할 수 있어야 했습니다. 프론트엔드 번들은 앱 바이너리와 독립적으로 배포할 수 있어야 했습니다. 큰 전담 조직 없이 프론트엔드, iOS, Android 엔지니어 한 명씩으로 시작할 수 있어야 했습니다. 문제가 생기면 기존 웹뷰로 돌아갈 수 있어야 했습니다. 당근 앱 전체를 새로운 크로스플랫폼 프레임워크로 교체하는 일은 목표가 아니었어요. 당근에서 콘텐츠를 만나는 핵심 경험인 홈 피드, 실제 거래가 일어나는 채팅처럼 비즈니스의 중심이 되는 화면은 빠르고 안정적인 네이티브 스택으로 유지해야 했고요. 우리가 찾은 것은 웹뷰가 맡아온 일부 화면을 더 빠르고 깊게 최적화할 수 있는 렌더링 계층이었습니다. 2025년 3월, 한 동료가 슬랙에 Lynx를 소개하는 글을 올렸어요. 제가 찾던 조건과 맞닿은 설계가 하나씩 눈에 들어왔습니다. Lynx? Lynx Lynx는 React와 CSS에 가까운 개발 모델로 iOS와 Android의 UI를 만들 수 있는 크로스플랫폼 기술이에요. 모바일 UI 전체를 Lynx로 구성할 수도 있고, 기존 네이티브 구성 안에 UI 블록으로 넣을 수도 있어요. Lynx를 검토하며 가장 먼저 살펴본 것은 React나 CSS의 사용법이 아니었습니다. Lynx가 채택한 JavaScript 엔진과 첫 화면의 렌더링 과정부터 눈에 들어왔어요. 1. 작고 빠르게 시작하는 JavaScript 엔진 JavaScript 엔진을 평가할 때 보통 실행 성능부터 비교해요. 복잡한 연산의 처리 속도와 벤치마크 점수도 중요한 기준이지만, 모바일 UI에서는 런타임을 준비하는 비용도 사용자의 로딩 경험에 직접 영향을 줍니다. 사용자는 화면이 열리는 순간을 경험하니까요. Lynx의 메인 스레드 런타임은 PrimJS(QuickJS)를 사용해요. PrimJS는 작고 애플리케이션에 삽입하기 쉬운 엔진으로 설계됐고, 낮은 런타임 초기화 비용이 주요 특성이에요. 우리가 풀려던 문제에서는 최대 처리량보다 엔진 시작 비용이 더 중요했습니다. 화면 하나를 위해 런타임을 준비하고, 필요한 JavaScript를 실행하고, 첫 UI를 보여주는 과정에 잘 맞는 특성이었어요. Main Thread Runtime - Lynx GitHub - lynx-family/primjs: JavaScript Engine Optimized for Lynx 작고 임베드 가능한 런타임은 실행 환경을 직접 구성할 여지도 줘요. 호스트 앱이 노출할 API를 제한할 수 있고, 공통 Polyfill과 자주 사용하는 코드를 런타임 가까이에 둘 수 있어요. 화면 진입

항공 프론트엔드 구축기 (2/10): Vue2 디자인 시스템을 React로 옮기기

FE News 26년 8월 소식을 전해드립니다.

주요소식 26년 8월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. State of CSS 2026 매년 진행되는 CSS 생태계 설문 조사인 State of CSS의 2026년 결과다. 2026년 5월 15일부터 6월 29일까지 진행되어 4,902명이 응답했고, 앵커 포지셔닝(Anchor Positioning)이 "가장 마음에 드는 신규 기능"과 "브라우저 지원 때문에 쓰지 못해 아쉬운 기능" 양쪽에서 1위를 차지했다. CSS의 AI 생성 비율이 평균 28%에 그쳤다는 응답도 눈에 띄는데, 다음 프로젝트에서 어떤 CSS 기능과 도구를 채택할지 판단하려는 개발자에게 참고할 만한 자료다. Hydration and Rendering Strategies 웹 렌더링 전략의 진화를 화면이 시각적으로 준비되는 시점과 실제로 상호작용 가능해지는 시점 사이의 간극을 줄인다는 관점에서 정리한 글이다. SSG·ISR부터 CSR, SSR, 스트리밍 SSR, 아일랜드 아키텍처, React Server Components까지 계보순으로 훑으며, 각 전략이 설정 복잡도·번들 크기·하이드레이션 지연·빌드 시간을 서로 맞바꾼다는 점을 짚는다. 콘텐츠 사이트에는 정적 생성과 아일랜드를, 앱에는 Server Components를 쓰고 이색적인 방식은 측정 가능한 성능 문제가 있을 때만 도입하라는 결론이 실용적이다. How does a request travel in ~200ms? 하나의 HTTP 요청이 약 200밀리초 동안 거치는 여정을 단계별로 보여 주는 인터랙티브 시각화 도구다. DNS 해석, TCP 연결, TLS 협상, 커널, Node의 이벤트 루프, Postgres 작업, 응답이 클라이언트로 되돌아오는 경로까지 요청의 생애주기 전체를 추적하며 각 단계가 전체 지연 시간에서 차지하는 비중을 보여 준다. 추상화 뒤에 감춰져 있던 네트워크·시스템 계층을 구체적으로 이해하고 싶은 개발자에게 좋은 학습 자료다. Announcing Vite+ Beta 런타임 관리, 패키지 관리, 프런트엔드 도구를 하나의 워크플로로 통합하는 웹 개발 툴체인 Vite+의 베타 출시 소식이다. Vite, Vitest, Rolldown, tsdown, Oxlint, Oxfmt를 하나의 스택으로 묶어 vp dev, vp check, vp test, vp build 같은 명령 체계로 제공하며, 알파 이후 500개 이상의 PR이 반영되어 스마트 캐싱과 조직 템플릿·프록시 등 엔터프라이즈 기능이 추가되었다. 1,300개 이상의 공개 저장소가 이미 사용하고 있다고 밝히고 있어, 프런트엔드 툴체인의 통합 흐름을 지켜보는 개발자에게 참고가 된다. Ant, a lightweight JavaScript runtime 기존 엔진을 감싸지 않고 자체 "Ant Silver" 엔진 위에 처음부터 만든 경량 JavaScript 런타임이다. Node 호환 API와 VM 샌드박스, WebAssembly를 내장하고 9MB 단일 바이너리로 실제 npm 패키지와 TypeScript를 실행하며, 자체 패키지 매니저와 레지스트리·배포 플랫폼까지 하나의 생태계로 구성된다. 50MB가 넘는 런타임을 감당하기 어려운 서버리스 함수, 엣지 컴퓨팅, 임베디드 환경을 겨냥한 프로젝트다. >> FE News 26년 8월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. ▷ 구독하기

FE News 26년 7월 소식을 전해드립니다.

주요소식 26년 6월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다. TypeScript 7.0 RC Go로 재작성된 네이티브 컴파일러를 탑재한 TypeScript 7.0의 릴리스 후보(RC)가 공개되었다. 기존 타입 체크 로직과 구조를 그대로 유지한 채 포팅해 6.0보다 약 10배 빠르며, Bloomberg, Figma, Google, Slack, Vercel 등 여러 기업의 팀과 프리릴리스 빌드를 테스트해 왔다. 향후 한 달 내 정식 릴리스될 예정으로, 대규모 코드베이스에서 타입 체크와 빌드 속도로 고생해 온 팀이라면 미리 검증해 볼 가치가 있다. Ship the policy, not the code 프런트엔드와 백엔드처럼 별도로 배포되는 두 시스템에 동일한 비즈니스 규칙을 구현할 때 발생하는 코드 중복과 불일치 문제를 다룬다. 백엔드가 "allowedActions": ["CANCEL"] 같은 결정값을 내려보내거나, CASL이나 JSON Schema 같은 표준 형식으로 정책 자체를 데이터로 직렬화해 전송하는 방안을 제시한다. 마이크로서비스나 BFF 구조에서 규칙 일관성을 고민하는 개발자에게 실용적인 관점을 제공한다. Getting started with loops Claude Code 팀이 코딩 에이전트에게 프롬프트를 반복 입력하는 대신 "루프를 설계"하는 접근을 정리한 글이다. 트리거 방식과 종료 기준에 따라 턴 기반, 목표 기반, 시간 기반, 프로액티브 4가지 유형으로 분류하고, 검증 절차를 스킬(SKILL.md)로 인코딩해 자가 검증 능력을 높이는 방법을 소개한다. 명확한 종료 기준 설정과 대규모 실행 전 파일럿 테스트 등 토큰 사용량 관리 팁도 함께 제안한다. React Doctor AI 에이전트가 작성한 React 코드의 품질 문제를 자동으로 잡아내는 도구다. 상태 관리, 이펙트, 성능, 아키텍처, 보안, 접근성 전반을 검사하며 Next.js, Vite, TanStack, React Native, Expo 등 대부분의 React 환경을 지원한다. Claude Code, Cursor, Codex 같은 AI 에이전트와 연동되고, GitHub Actions를 통한 PR 자동 리뷰도 가능하다. vercel/eve Vercel이 공개한 파일시스템 기반의 지속형(persistent) AI 에이전트 프레임워크다. 시스템 프롬프트는 instructions.md, 도구는 tools/, 온디맨드 절차는 skills/ 디렉터리에 두는 식으로 에이전트의 구성 요소를 코드가 아닌 디렉터리 구조로 관리해 검사와 확장이 쉽다. 마크다운과 타입 정의된 함수만으로 에이전트를 구성하는 접근은 코드 중심 프레임워크 대비 낮은 진입 장벽을 제공한다. >> FE News 26년 7월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다. 매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다. ▷ 구독하기

왓챠 웹 PiP 적용기 — Document PiP는 어떻게 동작하고, 무엇이 어려웠나

1부에서 “왓챠 웹이 PiP를 지원한다”고 알려드렸습니다. 이번 편은 실제 적용기 입니다. 특히 DRM 영상·자막·왓챠파티가 얽힌 실서비스에 붙이는 건 전혀 다른 일이었습니다. 📑 목차 1. 들어가기 전에 — 웹 PiP에는 두 종류가 있습니다 (#b1c2) 2. 동작 원리 — Document PiP는 어떻게 가능한가 (#f285) 3. 적용기 ① “옮기는 한 줄”이 React에선 안 통한다 (#8117) 4. 적용기 ② “안 끊긴다”던 영상이, 가끔 굳는다 (#5cfd) 5. 적용기 ③ ‘X’를 누르면 끝내는 걸까, 크게 보는 걸까 (#d231) 6. 요약 — 적용 순서 한 눈에 보기 (#261d) 7. Q&A — 한 발 더 들어가기 (#d392) 8. 못다 한 것 (#27f5) 들어가기 전에 — 웹 PiP에는 두 종류가 있습니다 바로 Standard PiP와 Document PiP 입니다. 이 둘은 할 수 있는 일이 다릅니다. 📌 용어 안내. 사실 “Standard PiP”는 공식 명칭이 아닙니다. 영상 하나만 띄우는 원래 API의 정식 이름은 그냥 Picture-in-Picture API이고, 나중에 나온 Document Picture-in-Picture API가 이를 확장한 것입니다. 그런데 둘 다 “PiP”라 부르면 구별이 안 돼서, 이 글에선 앞엣것을 편의상 Standard PiP로 부르겠습니다. 핵심 차이는 “무엇을 떼어내느냐” 입니다. Standard PiP는 브라우저가 <video> 하나만 floating 창으로 띄웁니다. 간단한 대신 우리가 DOM으로 그리는 자막, 커스텀 컨트롤, 다음 화 버튼은 따라가지 못합니다. Document PiP는 진짜 별도의 window를 열어줍니다. 그 안에 우리 DOM을 통째로 옮기면 자막도 컨트롤도 그대로 살아 있습니다. 대신 Standard PiP보다 관리가 복잡합니다. 왓챠는 왓챠만의 브랜딩된 UI와 자막을 그려야 하기 때문에, 되도록 Document PiP를 지원하기로 했습니다. 그리고 Document PiP를 지원하지 않는 Safari 등에서는 Standard PiP로 fallback시켰습니다. 동작 원리 — 영상을 옮기는데 왜 안 끊길까 앞서 “Document PiP는 우리 DOM을 통째로 새 창으로 옮긴다”고 했습니다. 크롬 공식 가이드의 예시를 보면 꽤 간단하게 적용할 수 있습니다. pipButton.addEventListener('click', async () => { const player = document.querySelector("#player"); // PiP 창을 연다 const pipWindow = await documentPictureInPicture.requestWindow(); // 플레이어를 PiP 창으로 옮긴다 ← 이 한 줄이 핵심 pipWindow.document.body.append(player); }); 📄 출처: 크롬 공식 가이드 — Document Picture-in-Picture 💡 직접 확인해보기 크롬이나 엣지를 쓰신다면, 지금 개발자도구(F12) 콘솔에 이렇게 쳐보세요. documentPictureInPicture 진짜로 브라우저에 내장된 기능이라는 걸 바로 볼 수 있습니다. 반대로 Safari나 Firefox에서 쳐보면 undefined가 나옵니다 — 아직 이 API를 지원하지 않기 때문이죠. 다시 코드로 돌아와보면 requestWindow()로 창을 열고, append(player)로 플레이어를 그 창에 옮긴다. 끝입니다. 말은 간단하지만, 생각해보면 이상한 일입니다. 재생 중인 영상을 다른 창으로 뜯어 옮기는데, 어떻게 끊기지 않을까요? 스펙과 브라우저 코드를 열어보면, 두 가지 장치가 맞물려 이걸 가능하게 합니다. ① 어떻게 우리 코드가 새 창(pipWindow)을 직접 채울 수 있나? 본인인증을 붙여본 개발자라면 이런 흐름이 익숙할 겁니다. 인증 창을 하나 띄우고 → 사용자가 그 안에서 인증을 끝내면 → 결과만 콜백으로 돌려받습니다. 정작 그 창 안에서 무슨 일이 벌어지는지 우리가 들여다보거나 손댈

React와 DoS

1. 들어가며 안녕하세요. AIPD팀 정승화입니다. 최근 모던 웹 생태계는 클라이언트 사이드에서 서버 사이드로 그 중심이 이동하고 있습니다. React Server Components(RSC)와 Server Actions의 등장이 대표적인 예입니다. 클라이언트의 로직이 서버로 이동하면서 클라이언트의 한계를 넘어선 일도 할 수 있게 되었습니다. 하지만 기존 클라이언트 개발에서는 겪을 수 없었던 '서버 보안 위협'에도 그대로 노출되게 되었습니다. 관련해 이번 포스팅에서는 최근 발견된 React의 DoS(Denial of Service) 관련 취약점을 분석하고 그 원인인 React Flight Protocol(RFP)을 간단히 살펴보겠습니다. 이 글을 통해 React의 독자적인 데이터 전송 방식인 React Flight Protocol(RFP) 구조를 이해하고, 조작된 페이로드가 Node.js의 싱글 스레드 환경을 어떻게 무력화하는지 그 메커니즘을 파악할 수 있을 것입니다 2. 만악의 근원(?) React Flight Protocol 이 취약점을 이해하려면 먼저 React가 서버 컴포넌트를 브라우저로 전송하는 방식, 즉 React Flight Protocol(RFP)을 이해해야 합니다. RFP는 RSC를 직렬화하여 전송하기 위한 전용 프로토콜입니다. JSON으로는 표현하기 어려운 컴포넌트 트리, 비동기 의존성, Suspense 경계 등을 처리하기 위해 독자적인 타입 기호를 사용합니다. 기호의미설명 $Lazy/Reference다른 청크를 참조하거나 지연 로딩되는 컴포넌트를 정의합니다. @Reference ID다른 청크의 ID를 가리킬 때 사용합니다. (예: $@1) JJSON 모델실제 컴포넌트 트리나 UI 구조가 담긴 JSON 데이터입니다. MModule클라이언트 컴포넌트 파일의 경로 정보를 담습니다. IInlined인라인된 데이터나 비동기 요청의 결과를 의미합니다. RFP는 서버에서 직렬화되어 클라이언트로 전송됩니다. 그리고 React 서버는 클라이언트에서 넘어온 요청을 자체 기준에 따라 역직렬화하고 실행합니다. 3. Node.js와 DoS React 서버는 대부분 Node.js와 같은 싱글 스레드 런타임 환경에서 동작합니다. 따라서 역직렬화 과정에서 특수 참조 기호($)로 인한 순환 참조를 적절히 처리하지 못하면 스레드가 무한 루프에 빠져 블로킹 상태가 될 수 있습니다. 최근 발생한 취약점인 CVE-2025-55184는 바로 이 지점을 노렸습니다. 공격자가 조작된 RFP 페이로드를 서버로 보내면 서버는 이를 해석하려다 순환 참조의 늪에서 헤어나오지 못하게 됩니다. 이는 단순한 정보 탈취보다 치명적일 수 있습니다. 서버 자체를 무력화하여 서비스 전체를 다운시킬 수 있기 때문입니다. 4. React 서버 공격해보기 (PoC) React는 RSC 동작을 검증할 수 있는 테스트 환경을 갖추고 있습니다. 이 환경을 활용해 실제 DoS 공격이 어떻게 이루어지는지 테스트할 수 있습니다. React 팀이 문제를 해결하기 위해 적용한 두 단계의 패치 과정을 살펴보겠습니다. DoS 취약점 해결은 한 번에 끝나지 않고 두 차례에 걸쳐 진행되었습니다. 각 패치가 어떤 문제를 해결하려 했는지 코드를 통해 확인해 보겠습니다. 4-1. 자기 순환 참조 방지하기 첫 번째 문제는 페이로드가 자기 자신을 계속 참조하는 경우입니다. 공격자가 React 서버로 다음과 같이 조작된 데이터를 전송한다고 가정해 봅시다. 핵심은 then이 자기 자신을 가리키도록 하여 Promise가 영원히 resolve되지 않게 만드는 것입니다. import requests target = "http://localhost:3000" timeout = 5 requests.post( target, files={"0": ("", '"$@0"')}, headers={ "rsc-action": "file:///Users/seunghwajeong/space/react/fixtures/flight/src/actions.js#increment", }, timeout=timeout, ) 이

MFE 환경에서 공통 헤더(GNB) 개편하기

안녕하세요. 인프랩 프론트엔드 개발자 고슈입니다. 작년 8월, 인프런의 헤더(GNB)가 새롭게 단장했습니다! 🎉 인프런의 헤더는 여러 프론트엔드 환경에서 동작해야 하는 복잡한 구조로 이루어져 있어, 기존에도 여러 문제가 있었는데요. 1. 헤더를 왜 개편하게 되었는가 기존 헤더 개편된 헤더 인프런의 헤더는 런칭 이래로 변경된 적이 거의 없었는데요. 현재 인프런은 강의, 챌린지, 멘토링, 클립, 커뮤니티를 핵심 서비스로 정의하고 있습니다. 디자인 개편 자체는 이미 완료되었지만, 그 과정이 단순하지만은 않았는데요. 2. MFE 아키텍처와 Module Federation 2-1. 인프랩 팀의 프론트엔드 아키텍처 모놀리식 아키텍처에서 도메인 별로 프로젝트 분리 모놀리식에서 도메인 분리로 초기 인프런은 내부에서 Antman이라 부르는, 자체 자바스크립트 프레임워크 기반의 모놀리식 프로젝트로 서비스를 운영하고 있었는데요. 서비스 규모가 커지면서 개발자 수도 늘고, 빌드 속도도 느려지기 시작했습니다. 가장 큰 문제는 하나의 서버에 프론트엔드와 백엔드가 함께 올라가 있다 보니, 한쪽에서 장애가 발생하면 서비스 전체가 마비된다는 점이었습니다. 이를 해결하기 위해 리액트로 마이그레이션을 진행하면서, 도메인별로 프로젝트를 분리하게 되었습니다. 프론트엔드 기준으로 모노레포도 있고, 폴리레포(싱글레포)도 있고, 형태는 다양하지만 각 도메인이 독립적으로 운영되는 마이크로프론트엔드(MFE)구조입니다. 이렇게 분리된 애플리케이션들은 리버스 프록시를 통해 하나의 서비스로 동작하고 있습니다. 사용자가 접속한 URL 경로에 따라 프록시가 적절한 애플리케이션으로 요청을 라우팅해 주는 방식인데요. 리버스 프록시란, 클라이언트의 요청을 받아 내부의 여러 서버 중 적절한 곳으로 전달해 주는 중간 서버입니다. 사용자는 하나의 도메인에 접속하지만, 실제로는 뒤에 있는 여러 애플리케이션 중 하나가 응답하게 됩니다. 백엔드 역시 서버가 분리되면서 한쪽 장애가 전체로 퍼지는 문제는 해소되었고, 프론트엔드 관점에서도 각 애플리케이션이 독립적으로 빌드·배포되기 때문에 런타임 오류나 배포 실패가 다른 서비스에 영향을 주지 않게 되었습니다. 패키지별로 다양한 환경을 구성할 수 있고, 코드 충돌도 줄어들었습니다. 분리했더니, 더 바빠졌다 하지만 공통으로 사용하는 컴포넌트가 있는 경우엔, 변경할 때마다 모든 패키지에 반영하고 배포해야 한다는 번거로움이 있었는데요. 특히 헤더가 대표적이었습니다. 헤더는 여러 서비스가 추가되고 실험이 이루어지면서 변경이 빈번했습니다. 헤더를 한 번 수정하면 다음과 같은 과정을 거칩니다. 레거시 Antman 쪽 헤더 코드 수정 및 배포 리액트 헤더 공통 모듈 코드 수정 및 배포 공통 모듈을 사용하는 각 도메인 패키지 업데이트 및 배포 즉, 공통 모듈을 사용하는 패키지가 10개라면, 10개 모두 배포해야 하는 셈이었습니다. 이 문제를 해결하기 위해 몇 가지 방법을 검토했습니다. 방법 1: 서버 사이드 컴포지션 프론트엔드 전용 서버를 두고, 그곳에서 헤더와 각 애플리케이션의 결과물을 조합하여 하나의 HTML로 렌더링해 내려주는 방식입니다. 하지만 모든 트래픽이 한 서버에 집중되고, 해당 서버에 장애가 생기면 모든 페이지가 마비된다는 단점이 있었습니다. 방법 2: CI/CD 디스패치를 통한 자동 배포 공통 모듈에 변경이 생기면, 워크플로우로 각 패키지에 디스패치하여 자동 배포하는 방식입니다. 방법 3: 런타임 로딩 (Module Federation) 번들링된 JS를 S3에 올려두고, 각 애플리케이션이 런타임에 이를 가져와 실행하는 구조입니다. Webpack의 Module Federation을 활용한 방식인데요. 헤더 모듈만 배포하면 모든 애플리케이션에 즉시 반영되고, 롤백도 S3 파일 경로만 변경하면 되어 유지보수가 용이합니다. 물론 트레이드오프도 있었습니다. 런타임에 JS를 불러오는 만큼 네트워크 상태에 의존하게 되고, CSR 기반이라 SEO에 불리하며, 공유 의존성 관리 등 러닝 커브가 늘어난다는 점이 있었는데요. 그럼에도 저희는 독립적인 환경에서

웹 서버가 터졌다: Next.js SSR에서 TanStack Query gcTime이 만든 OOM

0. 들어가며 안녕하세요. 중고나라 웹개발팀입니다. 현재 중고나라 웹개발팀은 웹 서비스를 리뉴얼하는 과정에서, 기술 스택을 변경하는 큰 규모의 마이그레이션을 진행했습니다. (Next.js Page Router → App Router, React 18 → 19) 리뉴얼을 마치고 출시 전 부하 테스트를 돌렸는데 문제가 터졌습니다. 웹 서버에서 OOM이 발생하는 것입니다. 그래프를 보면 단순한 Memory Peak가 아니었습니다. 메모리가 GC 되지 않고 계속 쌓이는 패턴이었습니다. Memory Leak이 발생해 Pod OOM Killed 확인 (Datadog) 원인을 추적한 결과, Server Component에서 TanStack Query(React Query)의 QueryClient를 클로저가 오랫동안 참조하고 있어 GC되지 못하는 것이 문제였습니다. 이 글에서는 이 메모리 이슈의 원인과 트러블슈팅을 공유하고, 문제의 원인이었던 TanStack Query의 gcTime이 왜 문제가 되었는지 분석한 내용을 설명하고자 합니다. 1. 사전 배경: App Router + TanStack Query SSR 구조 본격적인 트러블슈팅에 앞서, 문제가 발생한 코드를 먼저 짚고 넘어가겠습니다. Next.js App Router에서는 layout과 page가 동일한 요청 스코프 내에서 렌더링됩니다. 이 구조에서 React.cache()로 감싼 QueryClient를 요청 단위로 공유하고, 서버 컴포넌트에서 데이터를 prefetch한 뒤 dehydrate를 통해 클라이언트에 전달하는 패턴을 사용하고 있었습니다. const getQueryClient = React.cache(() => new QueryClient()); React.cache()로 감싼 함수는 동일 요청 내에서 같은 값을 반환하므로, 하나의 요청에서는 하나의 QueryClient가 공유됩니다. 요청이 끝나면 이 QueryClient는 자연스럽게 GC 대상이 되는데, 이 글의 핵심은 바로 이 전제가 깨지는 상황입니다. 전역 layout에서 렌더링되는 GNB 헤더에서, 이 QueryClient를 통해 GNB API를 prefetch하는 구조였습니다. import { dehydrate, HydrationBoundary } from '@tanstack/react-query'; // 서버 컴포넌트 GnbHeader에서 gnb API 응답 캐시 export default async function GnbHeader() { const queryClient = getQueryClient(); await queryClient.prefetchQuery({ queryKey: ["gnb"], staleTime: 1000 * 60 * 30, // 30분 gcTime: 1000 * 60 * 60, // 1시간 queryFn: () => fetchGnb(), }); return ( <HydrationBoundary state={dehydrate(queryClient)}> <HeaderView /> </HydrationBoundary> ); } (fyi. 신규 웹은 TanStack Query v5를 이용하고 있습니다.) GNB는 자주 변하지 않으니 캐시를 오래 유지하겠다는 의도였습니다. 페이지 레벨에서도 동일한 QueryClient를 통해 검색·상품 상세 등의 API를 prefetch했습니다. 즉, 하나의 HTTP 요청 안에서 GNB prefetch, 검색 결과, 상품 상세 등 모든 query 데이터가 하나의 QueryClient 인스턴스에 누적되는 구조였습니다. 정리하면 아래와 같습니다. QueryClient는 React.cache()로 감싸 request scope 내에서 재사용된다. GNB query에 긴 gcTime(1시간)이 설정되어 있다. app/layout.tsx └── Header.tsx (QueryClient 생성 + GNB 캐시 gcTime 1시간) └── page.tsx (동일 QueryClient 재사용, 검색/상품 API 캐시 추가) 기능적으로는 아무 문제가 없었기에, 별다른

리액트의 현재와 미래, 그리고 AI: React Summit US 2025 참관기

카카오뱅크 프론트엔드 클랜이 React Summit US 2025에 다녀왔습니다. 이 글에서는 현장에서 직접 확인한 AI 실무 엔지니어링, 리액트 거버넌스의 변화, 그리고 추상화 속 기본기의 중요성 등 프론트엔드 생태계의 가장 뜨거운 최신 기술 흐름을 현장의 열기와 함께 공유합니다.

[디자인 시스템 어떻게 만들었어요?(3)] Tree Shaking과 구형 브라우저 대응

지난번 YDS(Yogiyo Design System) v2 컴포넌트 라이브러리 구축기에 이어, 이번 글에서는 YDS v2 컴포넌트 라이브러리와 같은 외부 라이브러리가 서비스 애플리케이션 번들 결과물에 미치는 영향을 살펴봅니다. 또한, 구형 브라우저에 대한 하위 호환성 확보를 위해 요기요 FE 팀이 거친 기술적인 고민과 그 해결 과정들을 공유하고자 합니다. 들어가며 현재 요기요 FE팀은 주요 FE 프로젝트의 기반 프레임워크로 Next.js를 채택하여 사용하고 있습니다. Next.js는 React 기반의 프레임워크로서 웹 개발에 필요한 도구들을 기본적으로 제공합니다. 이러한 편의성 덕분에 개발자는 인프라 설정보다 비즈니스 로직 구현에 더 집중할 수 있는 환경을 갖추게 됩니다. 반면, 라이브러리를 개발하는 과정에서는 다음과 같은 오해에 빠지기 쉽습니다. 오해 1. Next.js가 알아서 Tree-shaking 해줄 것이다. Next.js automatically optimizes bundles by code splitting, tree-shaking, and other techniques. However, there are some cases where you may need to optimize your bundles manually. Next.js는 Code Splitting과 Tree Shaking을 통해 번들 사이즈를 최적화합니다. 이런 특징 때문에 라이브러리 개발자는 사용하지 않는 코드가 빌드 과정에서 알아서 제거될 것이라고 기대하곤 합니다. 하지만 라이브러리가 Tree shaking이 가능한 요건들을 충족하지 못했다면, 프레임워크의 최적화 기능은 무용지물이 됩니다. 라이브러리가 어떤 모듈 시스템(ESM or CJS)으로 배포되는지, Side-Effect를 어떻게 관리하는지, 하나의 파일로 번들링되어 있는지 혹은 모듈 트리구조를 유지하고 있는지에 따라 Next.js는 불필요한 코드를 제거하지 못하고, 결국 사용되지 않는 코드까지 번들에 포함하는 상황이 발생할 수 있습니다. 오해 2. Next.js를 쓰면 구형 브라우저 호환성 문제에서 자유롭다. Next.js 공식문서에 따르면 fetch, URL, Object.assign() 등 자주 사용되는 폴리필이 기본으로 제공됩니다. next-polyfill-nomodule을 통해 다양한 polyfill을 주입하지만, 이는 <script nomodule> 특성상 Chrome 64 미만의 구형 브라우저에서만 로드됩니다. 또한, ESM을 지원하는 브라우저용인 next-polyfill-module은 제한적인 기능만 지원하고 있습니다. 이 때문에 Promise.allSettled()처럼 Chrome 76부터 지원되는 메서드를 사용할 경우, 64~76 버전 사이의 Chrome 브라우저에서는 polyfill을 지원 받지 못하는 사각지대가 발생합니다. 따라서 프로젝트에서 Next.js 기본 제공 범위를 초과하는 API를 사용하고 있다면, 호환성 보장을 위해 개발자가 직접 누락된 폴리필을 확인하고 대응해야 합니다. 요기요 FE에서는 이러한 문제를 해결하기 위해 라이브러리 번들링 전략 개선과 Custom Polyfill 서비스를 구축하였습니다. 자세한 내용은 아래에서 이어서 설명하겠습니다. Tree Shaking을 위한 여정 ESM Tree shaking은 빌드 과정에서 사용되지 않는 코드를 제거하여 최종 번들 크기를 최적화하는 기법입니다. 정적인 import와 export 구문을 분석해 모듈 간의 참조 관계를 파악하고, 실제 실행에 필요 없는 코드를 선별해 삭제합니다. 결국, 코드의 정적 분석이 가능한 ESM을 채택해야만 완전한 Tree Shaking을 구현할 수 있습니다. 따라서 서비스 애플리케이션의 번들 크기를 최적화해 주기 위해서는 라이브러리 차원에서의 ESM 지원이 필수적입니다. Side-Effect 라이브러리를 ESM으로 배포했다고 해서, Tree Shaking이 자동으로 완벽하게 작동하는 것은 아닙니다. Webpack이나 Rollup 같은 번들러는 애플리케이션의 안전한 동작을