Frontend Lab | 프론트엔드 기술 실험과 깊이 있는 학습 내용을 공유하는 공간입니다.개인로컬에선 그대로인데 CI에서만 25초 빨라졌습니다
DOM을 안 쓰는 테스트 파일 121개가 파일마다 jsdom을 부팅하던 낭비를 Vitest 프로젝트 분리로 걷어냈습니다. 10코어 로컬에서는 wall time이 그대로였는데 4-vCPU CI에서만 실행당 25초가 줄어든 이유를 실측으로 따라갑니다.
Frontend Lab | 프론트엔드 기술 실험과 깊이 있는 학습 내용을 공유하는 공간입니다.
개인팔로우하면 블로거에게 내 GitHub 이름과 프로필 사진이 보여요.
최근 글
캐시가 hit인데 매번 콜드 빌드였습니다 — GitHub Actions Next.js 캐시 키가 죽어 있던 이유
캐시 복원은 초록불이었고 67MB가 정상적으로 내려왔습니다. 그런데 빌드는 캐시가 아예 없을 때와 같은 4분이었습니다. hit 로그가 보증하지 않는 것 — 캐시가 거치는 두 단계, 그리고 캐시 키에서 구조적으로 빠지는 입력을 대조군 실측으로 확인합니다.
매일 쓰던 getByRole 때문에 테스트가 26배 느렸습니다 — RTL·jsdom 성능 분석
매일 쓰던 getByRole이 사실은 트리 전체를 훑고 있었습니다. Meta 디자인 시스템에서 34초짜리 테스트 파일이 느려진 원인을 찾아 1.3초로 줄이기까지, RTL과 jsdom 내부에서 실제로 벌어지는 일.
TypeScript 6 업그레이드인 줄 알았는데, 문제는 "설정"이었습니다
TypeScript 6으로 올리자 baseUrl·rootDir·types 기본값이 차례로 빌드를 깨뜨렸다. 각 변경의 "왜"를 microsoft/TypeScript PR diff까지 추적해 보니, 이건 버전을 올리는 이야기가 아니라 "올바른 설정"에 도달하는 이야기였다 — baseUrl은 TS7로 가는 청소, types는 순수 성능 개선. 게다가 이 셋은…
[Typescript로 설계하는 프로젝트] id?: string을 버려라. 상태가 다르면 타입도 달라야 한다.
무분별한 옵셔널 타입이 낳은 안티 패턴에서 벗어나, Tagged Type(Discriminated Union)과 도메인 모델링으로 안전하고 견고하게 데이터를 설계하는 방법을 알아봅니다.
[누가 시키지도 않았는데 번들러 만들기] 4. 소스맵: 번들된 코드에서 원본의 흔적 찾기
수천 줄로 합쳐진 번들 파일에서 에러가 나면 어떻게 원본 위치를 찾을까요? 소스맵의 VLQ 인코딩 원리와 magic-string이 변환 이력을 관리하는 방식을 직접 구현하며 이해합니다.
[누가 시키지도 않았는데 번들러 만들기] 3. 번들링과 스코프: 파일 합치기의 기술
단순히 파일을 합치는 것과 번들링은 다릅니다. 변수 충돌을 막기 위한 함수 스코프 전략과 브라우저를 위한 런타임 구현 과정을 깊이 있게 다룹니다.
[누가 시키지도 않았는데 번들러 만들기] 2. 코드를 데이터로 보는 법 (AST Graph)
정규표현식으로 import 문을 찾으려다 실패한 경험, 그리고 AST 추상 구문 트리를 통해 코드를 데이터로 바라보는 관점을 소개합니다. 파일 시스템을 그래프로 변환하는 과정을 직접 구현해봅니다.
[누가 시키지도 않았는데 번들러 만들기] 0. 프롤로그: 질문이 구현이 되는 순간
수많은 소스 코드가 어떻게 하나의 결과물로 합쳐질까요? 당연하게 사용하던 번들러의 블랙박스를 열고, 직접 손으로 구현하며 그 답을 찾아봅니다.
[누가 시키지도 않았는데 번들러 만들기] 1. 개념과 도구: 번들러의 등장 배경
코드를 번들링해야 하는 기술적 이유와 자바스크립트 모듈 시스템의 발전 과정을 살펴봅니다. 또한 번들러 구현의 기반이 되는 Magic String 라이브러리를 소개합니다.
결제 시스템 리팩토링: if문 지옥에서 디자인 패턴(Factory, Adapter)으로 탈출하기
복잡한 비즈니스 로직을 if문 지옥에서 구해내는 Adapter, Factory, Strategy 패턴 적용기. Zod를 활용한 타입 안전성 확보와 Code Splitting 팁까지.
2025 회고: 글 33개, PR 38회, 발표 3회로 '보여주는 개발자'가 되다
2025 회고: 글 33개, PR 38회, 발표 3회로 '보여주는 개발자'가 되다 2025년은 "숨어서 잘하는 개발자" 에서 "보여주고 나누는 개발자" 로 방향을 튼 해였습니다. 시작점은 2024년 12월 23일, 한 개발자의 피드백이었습니다. "평소 기술 관련 답변을 잘 해주시는데, ...
2025 Teoconf 발표 후기
🎤 발표 후기: ‘내가 하고 싶은 말’ 대신 ‘청중이 가져갈 한 문장’을 찾기까지 이번 테오콘 발표는 내게 하나의 도전이었다. 디자인 시스템 배포라는, 나에게 깊은 경험이지만 청중에게는 다소 생소할 수 있는 주제를 어떻게 풀어낼 것인가. 그리고 그 과정에서 “발표는 기술을 나열하는 자...
하루 만에 끝날 줄 알았던 디자인 시스템 배포가 3주 걸린 이유
별거 아니겠지라고 생각했던 NPM 패키지 배포가 어떻게 3주간의 삽질로 이어졌는지, 그리고 그 과정에서 배운 타협의 기술
[Typescript로 설계하는 프로젝트] 타입 한 줄로 552개 파일을 2주 만에 안전하게 수정한 방법
"회원 구조가 바뀌었습니다. 552개 파일을 수정해야 합니다." 보통은 이렇게 됩니다 - 어디를 수정해야 하는지 찾느라 1주 - 수정하다가 놓친 곳 때문에 버그 발생 - 회귀 테스트에 또 1주 - QA에서 엣지 케이스 발견 - 결국 한 달... 하지만 우리는 2주 만에, 사이드 이펙트 ...
React 에러 구조 설계: throw만으로 선언적 에러 핸들링 하기
0. 프롤로그 throw를 보던중 문득 깨달았다. typescript try { throw new Error('error'); } catch (error) { throw error; // 상위로 전파된다 } 에러는 계층을 따라 전파된다. 그럼 에러 클래스도 계층 구조로 설계할 수 있지 ...
구글 개발자가 인정한 성능 최적화 기여 후기 - AI와 함께한 gemini-cli 오픈소스 여정
구글 개발자에게 인정받은 성능 최적화: gemini-cli 기여 후기 이 글을 읽고 나면 - AI와 협업해서 오픈소스 기여하는 방법을 알게 됩니다 - 성능 최적화 PR이 더 좋은 평가를 받는 이유를 이해합니다 - 구글같은 대기업 프로젝트에 기여하는 전략을 배웁니다 - 실제 머지된 PR ...
feconf 2025 발표 후기
시작 마이크를 잡는 순간 정말 내가 말해도 되는건가? 나 해도되는건가? 이 생각이 든 건 몇 달 전부터였다. 어느 모임에서 feconf 2024 라이트닝 연사자 분을 만나게 되었다. 재미있게 이야기 하던 도중 나에게 날아든 질문이 있었다. "상욱님도 이거 잘 하실 수 있을 것 같아요! ...
4시간 만에 Node.js PR 승인받기
4시간 만에 Node.js PR 승인받기 AI 페어 프로그래밍으로 오픈소스 진입 장벽 낮추기 “무조건 Node.js에 내 코드를 넣고 말겠다!” 오픈소스 기여가 점점 재미있어지고, 자신감도 차오르던 시기였다. 하지만 매일같이 이슈를 살펴봐도 여전히 모르는 부분이 많았다. C++ 코드가 ...
Next.js 오픈소스 기여: 2번 실패 후 성공 후기
Next.js 오픈소스 기여: 2번 실패 후 성공 후기 들어가며 "띠링" 새벽 2시, 내 핸드폰에 또 다른 GitHub 알림이 울렸다. 발신자: vercel/next.js [[제목] : Re:[vercel/next.js] Fix remote pattern (80294) (PR 80428...
Context API를 활용한 DropZone 구현하기
[React Component] Context API를 활용한 DropZone 구현하기 평소처럼 Mantine의 Dropzone을 사용하고 있었는데, 문득 내부 구현이 궁금해졌습니다. 어떻게 이렇게 깔끔한 API를 제공할 수 있을까? tsx // Mantine Dropzone 사용 중....
Type Guard를 활용한 여러가지 Button 구현하기
[React Component] Type Guard를 활용한 여러가지 Button 구현하기 드디어 디자인 시스템 프로젝트가 시작되었습니다! 팀에서 가장 먼저 구현하기로 한 컴포넌트는 Button입니다. 디자인 시스템에서 Button은 특별합니다. 가장 많이 사용되고, 가장 다양한 형태를...
15줄에서 2줄로: useSyncExternalStore 기반 React Toast 시스템 설계법
들어가며 안녕하세요, 여러분! 프론트엔드 개발자라면 누구나 한 번쯤 만들어보는 토스트 UI. 간단해 보이지만, 막상 구현하다 보면 "이걸 어떻게 앱 어디서든 쉽게 호출하지?", "종류별로 다른 스타일은 어떻게 관리하지?" 같은 고민에 빠지게 됩니다. 최근 mantine의 토스트 컴포넌트...
개발자에서 기여자로: 기술 블로그와 오픈소스가 바꾼 나의 2025년 상반기
들어가며 2025년 상반기를 돌아보니, 가장 크게 변화한 것은 "나만 알고 있던 지식을 세상과 나누기 시작 했다"는 점이다. 그동안 개발자로서 쌓아온 경험들과 고민을 글로 정리하고, 오픈소스에 기여 하면서 진정한 의미의 성장을 경험한 상반기였다. --- 🌟 기술 블로그: 지식 공유의 ...
[Typescript로 설계하는 프로젝트] "같은 로직 또 복사했어요?" Domain 모델로 책임 분리하기
들어가며 오후 4시, 또 다시 울리는 슬랙 알림... [기획자]: "저번에 만든 사용자 상태 로직 잘 쓰고 있어요! 그런데 이번엔 사용자가 특정 액션을 할 수 있는지 검증하는 로직도 추가해 주세요." [나]: "네, 어떤 검증 로직인가요?" [기획자]: "사용자가 글을 작성할 수 있는지...
[Typescript로 설계하는 프로젝트] "원래 있던 기능이니 금방 하시죠?" 당하지 않는 Service Layer 설계 전략
들어가며 겨우 백엔드의 요청을 쳐내고 다시 피곤함에전 모습으로 테스크를 마무리하려는 순간 이번엔 제 슬랙이 울립니다. [기획자]: "급하게 기획이 바뀌어서요. 이거 프론트에서 추가로 수정해 주셔야 할 것 같아요. 아직 마무리 다 안 하신 거 맞죠?" [나]: "네 아직 마무리 안 했어요...
[Typescript로 설계하는 프로젝트] "원래 있던 기능이니 금방 하시죠?" 당하지 않는 Service Layer 설계 전략 With Di
들어가며 겨우 백엔드의 요청을 쳐내고 다시 피곤함에전 모습으로 테스크를 마무리하려는 순간 이번엔 제 슬랙이 울립니다. [기획자]: "급하게 기획이 바뀌어서요. 이거 프론트에서 추가로 수정해 주셔야 할 것 같아요. 아직 마무리 다 안 하신 거 맞죠?" [나]: "네 아직 마무리 안 했어요...
[Typescript로 설계하는 프로젝트] Type 설계의 시작: 견고한 서버 API Type 설계하기
들어가며 피곤에 쩔은 모습으로 하나의 테스크를 마무리 하는 순간 백엔드 개발자가 다가옵니다. "죄송하지만 이번에 만든 api 중에 하나의 리스폰스가 변동 될 것 같습니다." "User로 정의한 스키마 중에 name이 빠질 것 같아요." 순간 머릿속에서 여기저기 대강 흩어져 있는 User...
[Typescript로 설계하는 프로젝트] Type 설계의 시작: 견고한 서버 API Type 설계하기 With DI
들어가며 피곤에 쩔은 모습으로 하나의 테스크를 마무리 하는 순간 백엔드 개발자가 다가옵니다. "죄송하지만 이번에 만든 api 중에 하나의 리스폰스가 변동 될 것 같습니다." "User로 정의한 스키마 중에 name이 빠질 것 같아요." 순간 머릿속에서 여기저기 대강 흩어져 있는 User...
[Typescript로 설계하는 프로젝트] 당신의 Type, 어디까지 연결되어 있나요?
[타입으로 설계하는 프로젝트] 당신의 Type, 어디까지 연결되어 있나요? 들어가며 플래닝이 끝나고 난 뒤 저에게 주어진 테스크를 살펴 봅니다. "뭐시기 뭐시기 기능 수정 및 삭제" 큰 기능 아니니 그냥 지워도 될거라는 저의 생각은 조만간 큰 버그를 가져왔습니다. 테스트 서버에 올려보니...