클로드코드.. 리팩토링

2026.06.07

리팩토링, 처음 해봤다

코드는 두 번 쓰인다 — 한 번은 기계를 위해, 한 번은 사람을 위해

2026 · 개발 단상 · CRM 개선 일지

오늘 처음으로 리팩토링이라는 것을 제대로 해봤다. 클로드 코드에게 refactor routes/mindmap.js라고 입력했을 때만 해도 그냥 코드 정리 정도겠거니 했다. 그런데 작업이 진행될수록 이게 단순한 청소가 아니라는 걸 알게 됐다.

재무보고서 파일을 리팩토링하다가 데이터가 통째로 날아갈 수 있는 버그를 발견했다. 캐비닛 파일 삭제 로직에서도 고아 레코드가 생길 수 있는 구조적 결함이 나왔다. 코드는 멀쩡히 돌아가고 있었는데, 들여다보니 속이 허술했던 것이다.

① 리팩토링이란 무엇인가

리팩토링(Refactoring)의 정의는 간단하다.

외부 동작은 그대로 유지하면서, 내부 코드 구조를 개선하는 작업 — Martin Fowler, 《Refactoring》

사용자 입장에서는 아무것도 바뀌지 않는다. 버튼을 눌렀을 때 동작하는 방식, 화면에 표시되는 결과, 저장되는 데이터 — 모두 동일하다. 달라지는 것은 오직 코드의 내부 구조뿐이다.

그렇다면 왜 하는가. 코드는 기계만 읽는 게 아니기 때문이다. 미래의 나 자신도, AI도, 혹시라면 동료도 읽는다. 기계는 지저분한 코드도 잘 실행하지만, 사람은 그렇지 않다.

② 왜 리팩토링은 필수적일 수밖에 없나

기술 부채의 누적

소프트웨어는 살아있는 유기체처럼 자란다. 기능을 하나 추가할 때마다 코드는 조금씩 복잡해진다. 처음에는 단순했던 구조가, 수십 번의 수정을 거치면서 누구도 한눈에 파악하기 어려운 덩어리가 된다. 이것을 기술 부채(Technical Debt)라고 한다.

// 기능 추가를 거듭할수록… 기능 1 추가 → 코드 +50줄 기능 2 추가 → 코드 +80줄 (기능 1 참조) 기능 3 추가 → 코드 +120줄 (기능 1, 2 참조) // 결국 버그 수정 한 곳 → 다른 곳에서 예상치 못한 오류 발생

숨은 버그는 리팩토링할 때 보인다

오늘 가장 인상 깊었던 발견이다. CRM의 재무보고서 저장 로직을 보면:

// 기존 코드 — 겉보기엔 문제없어 보임 db.exec(‘DELETE FROM financial_pl WHERE …’); // 즉시 커밋 const insert = db.transaction((rows) => { … }); // INSERT만 트랜잭션 insert(rows); // 만약 INSERT 도중 오류가 나면? // DELETE는 이미 커밋됨 → 데이터 전체 소실 💀

// 리팩토링 후 — DELETE + INSERT를 하나의 트랜잭션으로 const savePLBatch = db.transaction((companyId, year, rows) => { stmts.deletePL.run(companyId, year); // 트랜잭션 안 for (const r of rows) stmts.insertPL.run(…); // 트랜잭션 안 }); // INSERT 실패 → DELETE까지 함께 롤백 → 데이터 보존 ✅

코드는 돌아가고 있었다. 오류가 발생한 적도 없었다. 하지만 언제든 터질 수 있는 폭탄이 숨어있었던 것이다.

③ 리팩토링이 가져오는 것들

🔍

숨은 버그 발굴

구조를 다시 들여다보는 과정에서 평소엔 보이지 않던 결함이 드러난다

⚡

성능 개선

매 요청마다 반복되던 SQL 컴파일을 서버 시작 시 1회로 줄이는 등 효율화

📖

가독성 향상

111줄짜리 함수가 30줄로 줄어들면, 나중에 보는 눈이 달라진다

🤖

AI 협업 효율

클로드 코드는 코드를 매번 새로 읽는다. 깔끔할수록 더 정확하게 수정한다

🛡️

데이터 안전성

트랜잭션 구조 개선으로 예외 상황에서도 데이터가 보호된다

🧩

재사용성

반복 로직을 함수로 추출하면 나중에 다른 곳에서도 활용할 수 있다

④ 리팩토링을 어떻게 하나

오늘 CRM에서 반복적으로 적용된 리팩토링 패턴들이다.

패턴 1 — Prepared Statement 호이스팅

// Before: 요청마다 SQL을 매번 컴파일 router.get(‘/’, (req, res) => { const stmt = db.prepare(‘SELECT * FROM todos’); // 매번 res.json(stmt.all()); }); // After: 서버 시작 시 한 번만 컴파일 const stmts = { getAll: db.prepare(‘SELECT * FROM todos’), // 1회 }; router.get(‘/’, (req, res) => { res.json(stmts.getAll.all()); // 꺼내쓰기만 });

패턴 2 — 함수 추출

// Before: 같은 로직이 여러 핸들러에 인라인으로 반복 router.get(‘/’, (req, res) => { const result = rows.map(r => ({ …r, data: JSON.parse(r.data) // 여기도 })); }); router.post(‘/’, (req, res) => { const result = { …row, data: JSON.parse(row.data) }; // 저기도 }); // After: 한 번 정의, 여러 곳에서 호출 function parseRow(r) { return { …r, data: JSON.parse(r.data) }; } router.get(‘/’, (req, res) => res.json(rows.map(parseRow))); router.post(‘/’, (req, res) => res.json(parseRow(row)));

패턴 3 — 트랜잭션 통합

// Before: DELETE와 INSERT가 각각 독립 실행 db.prepare(‘DELETE FROM table WHERE id=?’).run(id); // 즉시 커밋 db.transaction((rows) => { … })(rows); // INSERT만 트랜잭션 // After: 하나의 트랜잭션으로 묶기 db.transaction((id, rows) => { stmts.delete.run(id); // 트랜잭션 안 for (const r of rows) stmts.insert.run(r); // 트랜잭션 안 // 실패 시 전체 롤백 ✅ })(id, rows);

⑤ 주의할 점

기능 커밋과 리팩토링 커밋을 반드시 분리하라

기능 추가와 리팩토링을 같은 커밋에 섞으면, 나중에 문제 발생 시 원인을 추적하기 어려워진다.

“동작이 동일하다”는 말을 맹신하지 마라

오늘 calendar.js에서 ID 생성 패턴이 통일됐을 때, “단순 실수”인지 “의도적 차이”인지 원작자만 알 수 있었다. 코드를 작성한 사람이 직접 확인하는 단계가 필요하다.

줄수가 늘어나는 리팩토링은 한 번 더 확인

줄수가 줄어드는 건 대체로 안전하다. 그런데 줄수가 늘어난다면, 새로운 로직이 추가된 건 아닌지 살펴봐야 한다.

외부 API, 미들웨어 변경은 특히 신중하게

일반 라우트 핸들러와 달리, 미들웨어는 모든 요청의 관문이다. 여기서 문제가 생기면 전체 기능이 멈춘다. 초기화 타이밍, 클로저 참조 방식을 꼭 확인하라.

배포 후 주요 기능 한 번씩 눌러보기

복잡한 테스트 없이도 “눈으로 써보기”만으로 대부분의 문제를 잡을 수 있다. pm2 재시작 후 에러 로그 확인도 필수다.

⑥ 언제 리팩토링을 해야 하나

개발의 세 단계가 있다고 한다.

Make it work
일단 돌아가게

→

Make it right
올바르게 구조화

→

Make it fast
성능 최적화

처음부터 완벽한 코드를 쓰려는 건 욕심이다. 기능이 동작하게 만드는 것이 먼저고, 그 다음에 구조를 다듬는 것이 올바른 순서다. 리팩토링은 두 번째 단계다.

실용적인 타이밍: 기능 추가/수정이 완료된 후, 배포 전에 해당 파일을 리팩토링한다. 매번 할 필요는 없지만, 주요 작업이 마무리될 때마다 한 번씩 돌려보는 것이 좋다.

⑦ AI 코딩 시대에 리팩토링이 더 중요한 이유

클로드 코드 같은 AI 코딩 도구는 “일단 돌아가는 코드”를 빠르게 만드는 데 탁월하다. 하지만 AI는 기존 패턴을 그대로 따라가는 경향이 있다. 처음에 지저분하게 짜인 패턴이 있으면, 이후 기능을 추가할 때도 그 패턴을 답습한다.

상태	AI 코딩 효율	결과
코드가 지저분할 때	파악 느림, 오해 가능성	엉뚱한 곳 수정, 버그 유발
코드가 깔끔할 때	빠른 파악, 정확한 이해	정확한 수정, 실수 감소

AI와 함께 개발한다면, 리팩토링은 AI에게 더 좋은 작업 환경을 만들어주는 일이기도 하다. 사람이 읽기 좋은 코드가 AI도 읽기 좋은 코드다.

“코드는 쓰는 것보다 읽히는 횟수가 훨씬 많다.
리팩토링은 미래의 나를 위한 배려다.”

Post Views: 364

Earth-Traveler

클로드코드.. 리팩토링

클로드코드.. 리팩토링

① 리팩토링이란 무엇인가

② 왜 리팩토링은 필수적일 수밖에 없나

기술 부채의 누적

숨은 버그는 리팩토링할 때 보인다

③ 리팩토링이 가져오는 것들

④ 리팩토링을 어떻게 하나

패턴 1 — Prepared Statement 호이스팅

패턴 2 — 함수 추출

패턴 3 — 트랜잭션 통합

⑤ 주의할 점

⑥ 언제 리팩토링을 해야 하나

⑦ AI 코딩 시대에 리팩토링이 더 중요한 이유

댓글 남기기 응답 취소