한 줄. 떠나기 전에, 들어왔을 때보다 한 단계 깨끗하게.
Why this mindset
항상 정돈하는 습관을 들이자. 사용하지 않는 변수, import를 정리하자. 의도가 드러나는 변수명을 지을 수 있도록 노력하자. 그 이외에도 어떻게 하면 코드를 깨끗하게 관리할 수 있을지에 대해 고민하자.
Instructions
정돈은 따로 잡는 큰 행사가 아니다. 코드를 만질 때마다 곁들이는 작은 동작이다.
마무리 직전, 한 번 훑는다. 기능을 다 짠 뒤·커밋 직전·"이제 됐다" 시점에 파일을 한 번 더 위에서 아래로 본다. 안 쓰는 import, 안 쓰는 변수, 디버그용
print/console.log, 주석 처리만 해놓은 죽은 코드 — 보이면 그 자리에서 지운다.이름은 한 번 더 의심한다. 변수·함수·파일 이름이 "이게 뭐 하는 건지" 한눈에 드러나는지 다시 본다.
data,temp,result,handle,doStuff같은 이름은 거의 항상 더 좋은 이름이 있다.- 좋은 이름의 기준: 읽는 사람이 함수 본문을 안 봐도 의도를 짐작할 수 있는가.
- 떠오르지 않으면 "이 함수 한 문장으로 설명해줘"를 자기 자신한테 묻고, 그 문장에서 동사·명사를 뽑는다.
보이스카우트 룰. 원래 작업과 무관해도, 같은 파일에서 명백히 잘못된 작은 것이 보이면 지나가는 김에 고친다. 단, 별건 손대지 않는다 — "지나가는 김에"가 리팩터링 폭주가 되면 그건 정돈이 아니라 새 작업이다.
포맷·정렬은 도구에 맡긴다. prettier, eslint --fix, black, gofmt 같은 게 깔려 있으면 그걸 돌린다. 손으로 들여쓰기·따옴표·세미콜론을 다투지 않는다. 도구가 없는 프로젝트면 한 번 깔자고 제안만 하고, 본업을 멈추진 않는다.
정돈한 만큼만 정돈했다고 말한다. 사용자에게 마무리를 보고할 때 "이번에 정리한 것"을 짧게 한 줄 적는다. "안 쓰는 import 3개, 디버그 로그 2줄 제거.
tmpData→parsedRows로 이름 변경." 이게 다음에 누가 봤을 때의 이정표다.
Examples
기능 끝낸 직후:
- 사용자: "검색 기능 다 만들었어."
- Claude: "마무리 전에 한 번 훑었어 —
useState에서 안 쓰던loading, 위에 디버그console.log한 줄, 그리고data를users로 바꿨어. 지금이 더 읽기 좋아. 커밋해도 될 것 같아."
이름이 안 떠오를 때:
- 사용자: "이 함수 이름 뭐로 하지?"
- Claude: "이 함수 한 문장으로 풀면 '이메일 형식이 맞는지 검사해서 true/false 돌려준다'야. 그럼
isValidEmail정도가 자연스러워.checkEmail은 검사 후 뭘 하는지 모호해서 한 단계 약해."
선 긋는 흐름:
- 사용자: 기능 작업 중인데 옆 파일에 거대한 함수가 보임.
- Claude: "이 옆 파일에 100줄짜리 함수가 좀 어수선해 보이긴 해. 다만 지금 작업 범위 밖이라, 표시만 해두고 손은 안 댈게. 따로 정리할 일감으로 빼두면 좋겠어."
Pitfalls
- "나중에 한꺼번에 정리하지" → 그 "나중"은 거의 오지 않는다.
- 의미 없는 이름 (
data1,temp,foo,value)이 마이그레이션 없이 살아남는 일. - 안 쓰는 import·변수가 누적되면서 파일이 무거워 보이는 일.
- 정돈한답시고 작업 범위 밖까지 파헤쳐 PR이 거대해지는 일.
정돈은 완벽주의가 아니다. "내가 떠난 자리가 들어왔을 때보다 한 단계만 깨끗하면 된다." 그 한 단계가 매번 쌓이는 게 깨끗한 코드베이스다.