천천히, 꾸준히
기록하는 개발 블로그

---
title: "AI 시대, knip으로 Dead Code 말끔히 정리하기"
date: 2026-05-29
tags: [Frontend, CI]
---

최근에 AI로 코드를 많이 작성하면서, 코드의 이해와 퀄리티에 대한 이슈가 많이 부각되고 있습니다.

생성 속도가 빨라진만큼, 코드가 방대해지고 기획도 자주 바뀌면서 **dead code**(사용하지 않는 코드)가 빠르게 쌓입니다.

이번에는 knip을 사용해 사용하지 않는 코드를 정리하고, 이를 린트와 함께 CI에 적용하여서 프로젝트 관리하는 방법을 알아봅니다.

실제 회사의 모노레포 프로젝트에 knip을 도입하고, biome·knip·테스트를 GitHub Actions에 적용하여 **158개 파일, 8,443라인, 16개 의존성**을 걷어냈고, 매 PR에 적용되도록 자동화하였습니다.

## 1. knip

[knip](https://knip.dev/)은 프로젝트 안에서 **사용하지 않는 파일·export·의존성**을 찾아주는 데드코드 분석 도구입니다. 단순히 문자열을 검색하는 것이 아니라, 프레임워크와 도구 설정을 바탕으로 진입점부터 import 그래프를 따라가며 실제로 도달 가능한 코드와 그렇지 않은 코드를 구분합니다.

knip을 도입하는 이유를 다음과 같이 설명합니다.

---
title: "[번역] TanStack Router and Query"
date: 2026-05-27
tags: [번역, React]
---

> 원문 : https://tkdodo.eu/blog/tan-stack-router-and-query

TanStack Router가 TanStack Query와 잘 통합된다는 것은 놀라운 일이 아닙니다. 결국 같은 `스택`에서 나왔으니까요. 그런데 잠깐 — TanStack Router는 이미 캐싱을 지원하지 않나요?

```tsx title="Loader Data" twoslash
export const Route = createFileRoute('/dashboard/$dashboardId')({
  component: Dashboard,
  staleTime: 10_000,
  loader: ({ params }) => fetchDashboard(params.dashboardId),
});

function Dashboard() {
  const dashboard = Route.useLoaderData();

---
title: "번들러 완전 정복 — webpack부터 tsdown까지"
date: 2026-05-26
tags: [React]
---

> 이 글은 동일한 코드를 7개 번들러/빌드 도구로 각각 빌드해보는 실습 프로젝트를 바탕으로 작성했습니다.  
> Github Project 참고: [bundler-example](https://github.com/geonhwiii/2026-bundler-example.git)

---

## 들어가며

프론트엔드 개발을 하다보면 webpack부터 시작해서 rollup, esbuild, tsup, vite, rolldown, tsdown 등 새로운 번들러와 빌드 툴이 계속해서 등장합니다. 왜 이렇게 많은 번들러가 등장하는 걸까요?

각 도구들은 단순히 트렌드가 아니라, 이전 세대 번들러가 가진 한계나 새로운 환경(브라우저, Node.js, 개발 방식 등)에서 발생하는 문제를 해결하기 위해 만들어집니다.

이 글에서는 번들러가 존재하는 이유부터 시작해서, 현재 프론트엔드 생태계에서 주요하게 쓰이는 7개 도구를 동일한 소스 코드로 직접 빌드해보며 비교합니다.

---
title: "[번역] What is Object Mutation in JavaScript?"
date: 2026-05-07
tags: [번역, React]
---

> 원문 : https://playfulprogramming.com/posts/object-mutation

최근, 저희는 [Playful Programming의 커뮤니티 블로그](https://playfulprogramming.com/)를 [정적 사이트 생성기 프레임워크인 Astro](https://astro.build/)를 사용하도록 다시 작성했습니다. 이 사이트의 인기 기능 중 하나는 다크 모드 토글로, 다크 모드 순수주의자들이 (저 같은) 라이트 모드 일반인들을 비웃을 수 있게 해줍니다.

<Video src="https://playfulprogramming.com/content/crutchcorn/posts/object-mutation/theme_toggle.mp4" client:visible />

> 농담은 그만두고, 사이트에 라이트 모드를 지원하고 그것을 기본 설정으로 만드세요 - [중요한 접근성 문제입니다](https://www.vice.com/en/article/ywyqxw/apple-dark-mode-eye-strain-battery-life).

마이그레이션 과정에서, 다크 모드 토글을 트리거하는 코드를 작성했습니다:

```ts
// ...
const initialTheme = document.documentElement.className;

---
title: "[번역] How to Communicate"
date: 2026-05-03
tags: [번역]
---

> 원문 : https://playfulprogramming.com/posts/how-to-communicate/

수많은 엔지니어들과 일하다 보면, 그들은 정말 뛰어난 두뇌를 가지고 있는 경우가 많습니다. 마음만 먹으면 거의 무엇이든 해낼 수 있는 사람들이죠. 하지만 대부분은 결정적인 약점을 하나 가지고 있습니다. 바로 **커뮤니케이션**입니다.

조직에서 요구하는 커뮤니케이션 수준에 부합하는 개발자를 만난 적은 거의 없습니다. 다만 그런 개발자들은 대체로 빠르게 그룹의 리더로 성장하더군요. 자신과 동료들의 막힘을 더 빠르게 풀어내며 실제 생산성을 끌어올리거나, 동료들이 일하는 방식을 한 단계 끌어올려 더 생산적이라고 느끼게 만들거나, 혹은 둘 다 해내기 때문입니다.

제가 그동안 의지해 온 커뮤니케이션 도구함 속 여러 도구들을 함께 살펴보겠습니다.

### 효율적인 메시지의 해부학

팀에 효과적인 메시지를 작성하는 일에는 생각보다 많은 요소가 들어갑니다. 가벼운 잡담은 그저 즐거움이 목적이지만, 특정 목적을 가진 커뮤니케이션은 목표가 완전히 달라집니다.

이제 여러분의 1순위 목표는 즐거움이 아니라, **정보를 전달하고, 변화를 이끌어내며, 그 과정을 직설적으로 해내는 것**입니다.