reuse-not-rewrite

name	reuse-not-rewrite
description	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. 새 코드를 짓기 전에 코드베이스 안에 이미 있는 것을 먼저 살피고, 모르는 코드를 함부로 치우지 않게 만드는 엔지니어링 철학 스킬.
when_to_use	Use whenever existing code is about to be replaced, removed, or duplicated — phrases like "rewrite", "from scratch", "새로 만들자", "다시 짜자", "갈아엎자", "처음부터", "리팩터링하자", "이거 안 쓰는 것 같아", "지워도 돼?", or the impulse "내 식으로 다시 짜는 게 빠를 것 같아". Strongest against vibe-coding "이거 다 새로 짜줘" requests and hesitation in front of legacy code.
allowed-tools	Read Grep Glob Bash(git *)

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

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에서 호출처 발견
• 재활용 핑계로 너무 안 맞는 코드를 억지로 끼워 맞추기 (반대편 함정)
• 본인이 짠 코드만 신뢰하고 남이 짠 코드는 일단 의심하기
• "리팩터링"이라는 이름으로 이해 안 되는 코드를 내 식으로 갈아엎기

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