# Reuse Not Rewrite

> Surveys what already exists before writing new code, and refuses to delete code whose purpose is unknown. When a request would replace, remove, or duplicate existing functionality, this skill greps the codebase, reads git history for buried reasons, and prefers small extensions over fresh rewrites. 새 코드를 짓기 전에 코드베이스 안에 이미 있는 것을 먼저 살피고, 모르는 코드를 함부로 치우지 않게 만드는 엔지니어링 철학 스킬.

- Skill: `kwakseongjae/reuse-not-rewrite` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kwakseongjae/reuse-not-rewrite`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kwakseongjae/reuse-not-rewrite/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kwakseongjae (https://skillmd.com/u/kwakseongjae)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kwakseongjae/reuse-not-rewrite

---


> **한 줄.** 새로 짜기 전에, 이미 있는 걸 한 번 더 본다. 모르는 코드는 함부로 치우지 않는다.

## Why this mindset

과거에 작성된 코드는 함부로 무시되거나 다시 짜이지 않아야 합니다.
거기엔 누군가의 시간·시행착오·이유가 박혀 있습니다. 잘 만들어진 코드베이스라면, *재활용하는 것*이 새로 짓는 것보다 거의 항상 빠르고 안전합니다.
그리고 — 알지 못하는 코드를 치우기 전에는, *왜 거기 있는지*부터 봅니다. 이유가 안 보이는 것이, 그 자체로 치우지 말아야 할 이유일 때가 많습니다.

## Instructions

손이 새 파일로 가기 전에, 코드베이스 안을 한 번 둘러본다.

1. **새로 짜기 전에 *같은 일 하는 게* 있는지 본다.**
   Grep·Glob·디렉토리 트리·옆 사람·이전 PR. 비슷한 함수·유틸·컴포넌트가 80%만 맞아도 그쪽을 살짝 늘리는 게, 새로 짓는 것보다 거의 항상 가볍다.

2. **모르는 코드는 치우지 않는다.**
   "이거 안 쓰이는 것 같다"는 거의 항상 *내가 모르는* 거지 *안 쓰이는* 게 아니다. 지우기 전에 — git blame으로 누가·언제·왜 넣었는지, grep으로 호출처가 진짜 없는지, 커밋 메시지에 단서가 있는지 본다. 1~2분 살피는 게 며칠짜리 사고를 막는다.

3. **재활용이 어색하면, 그 어색함을 *단서*로 본다.**
   "쓰려니까 이름이 안 맞아", "결합이 너무 많아서 가져다 쓸 수 없어" 같은 어색함은 그 자체로 *지금 코드의 약한 자리*가 어디인지 알려준다. 그 자리를 살짝 다듬으면 — 다음 사람도 같이 재활용할 수 있게 된다. 새로 짜서 옆에 두지 않는다.

4. **"내 식으로 다시 짜는 게 빠르다"는 충동을 한 번 의심한다.**
   AI도 사람도 자기 손에 익은 형태로 다시 짜는 쪽으로 자주 기운다. 빠른 것 같지만, *남은 코드와의 이질감*·*리뷰 부담*·*기존 테스트와의 충돌*까지 합치면 보통 더 느리다. 정말 다시 짜야 한다면, *왜 기존 코드가 안 맞는지* 한 줄로 적은 뒤에 시작한다.

5. **무엇은 재활용하고, 무엇은 새로 짜는가의 기준.**
   - 재활용: 같은 *의도*의 코드가 70% 이상 맞을 때, 작은 수정으로 둘 다 만족 가능할 때.
   - 새로 짜기: 의도 자체가 다를 때, 끼워 맞추는 비용이 새로 짓는 비용보다 클 때, 기존 코드가 이미 *왜 있는지 모르는 상태로* 부패해 있을 때 (이 경우엔 아무에게도 미안하지 않다).

## Examples

**"이거 이미 있는데" 발견:**
- 사용자: "사용자 이메일 검증 함수 하나 만들어줘."
- Claude: "잠깐, `utils/validators.ts`에 `isValidEmail`이 이미 있어. RFC 5322 기반으로 짜둔 거고, 다른 두 군데서도 쓰고 있어. 새로 짜는 대신 이걸 import해서 쓰자. 부족한 게 있으면 그 함수를 살짝 늘리면 돼."

**"왜 이렇게 짜여 있지" 멈춤:**
- 사용자: "이 `setTimeout(fn, 100)` 이상해 보여. 지워줘."
- Claude: "지우기 전에 — `git blame`으로 봤더니 6개월 전에 *iOS Safari 렌더 타이밍 이슈* 때문에 추가한 거야 (커밋 메시지에 명시돼 있어). 지금도 그 이슈가 살아있는지 한 번 확인하고 결정하자. 아니면 우회 이유 한 줄을 주석으로 남기고 그대로 두는 게 더 안전해."

**재활용이 어색해서 살짝 다듬어 쓰기:**
- Claude: "기존 `formatDate`가 거의 맞는데 *타임존* 인자가 없어서 못 쓰고 있어. 새 함수 만들지 말고, `formatDate`에 옵션 인자 하나 추가하자 — 한 줄이면 돼. 다음에 같은 일 하는 사람도 한 군데만 보면 되니까."

## Pitfalls

- "어차피 모르겠으니까 새로 짜자" → 같은 일 하는 코드가 두 벌 → 다음 사람이 어느 걸 봐야 할지 모름
- "안 쓰이는 줄 알았는데" → 지운 뒤에 production에서 호출처 발견
- 재활용 핑계로 *너무 안 맞는* 코드를 억지로 끼워 맞추기 (반대편 함정)
- 본인이 짠 코드만 신뢰하고 남이 짠 코드는 일단 의심하기
- "리팩터링"이라는 이름으로 *이해 안 되는 코드*를 *내 식으로* 갈아엎기

이미 있는 코드는 *낡은 게* 아니라 *살아남은 것*이다. 살아남은 데에는 이유가 있다. 그 이유를 한 번 보고 들어가는 것이, 코드베이스의 시간을 거슬러 함께 작업하는 자세다.