합치면 깔끔해 보였는데, 하나는 가짜였습니다 🪤

돈독(제가 혼자 만드는 자산관리 앱, https://don-doc.com )을 돌리다 보면, 코드를 점검하는 AI 에이전트가 매주 “이거 두 군데 겹쳐요”라는 지적을 몇 개씩 남깁니다. 예산 화면에서 지출을 계산하는 로직도 그중 하나였어요. /api/budget과 /api/dashboard, 두 곳에 거의 똑같은 계산 코드가 각각 따로 박혀 있었습니다.

지적은 6주 가까이 그대로 이월됐습니다. 급하지 않았거든요. 겉보기엔 “그냥 하나로 합치면 끝나는 일”이었으니까요.

그런데 막상 정리하려고 자세히 들여다보니, 합칠 대상 자체가 문제였습니다.

라인 단위로 대조해보니, 하나는 가짜였다 ⚠️

정리 후보로 지목된 함수가 하나 있었어요. 이름도 그럴듯하고, 테스트 코드까지 붙어 있어서 딱 “이걸 정본으로 삼고 나머지를 여기로 갈아치우면 되겠다” 싶었습니다.

그런데 실제로 어디서 쓰이는지 찾아보니, 이 함수는 자기 자신의 테스트 말고는 아무 데도 쓰이지 않는 죽은 코드였습니다. 반면 실제 예산 화면과 대시보드는 각자 따로 계산 코드를 갖고 있으면서도, 사용자가 항목 하나하나에 지출 금액을 직접 입력해둔 값이 있으면 그 값을 우선으로 쓰는 처리가 둘 다 들어 있었어요. 그런데 정본으로 삼으려던 그 함수엔 이 처리가 통째로 빠져 있었습니다.

두 화면끼리는 완전히 똑같았습니다. 그래서 “합쳐도 안전하다”는 판단이 나온 거였는데, 정작 합칠 대상으로 지목한 함수 자체가 그 둘과 다른 물건이었던 거예요. 만약 그대로 가져와 갈아치웠다면, 항목별로 지출 금액을 직접 정해둔 사용자 화면에서 숫자가 조용히 어긋났을 겁니다. 에러가 나는 것도 아니고, 그냥 다른 숫자가 나오는 채로요.

두 곳이 똑같아 보인다고 해서, 합칠 대상까지 똑같은 건 아니었습니다.

다행히 실행하기 전에 라인 단위로 대조하다가 걸러졌습니다. 지금은 이 항목을 “정리 보류”로 다시 내려두고, 정본부터 실제 로직에 맞게 고친 다음에 합치기로 순서를 바꿨습니다.

---

정리하다 보니, 또 다른 게 보였다

같은 날 이 문제를 들여다보다가 다른 것도 눈에 띄었습니다. 이미 완성해서 저장까지 끝낸 작업 세 건 — 문구 수정 하나, 다크모드 대비 수정 하나, 방금 그 예산 문제와는 별개로 이미 끝나 있던 현금흐름 계산 정리 하나 — 이 원격 저장소엔 전혀 올라가지 않은 채 이 기기에만 남아 있었습니다.

전에도 비슷하게 방치된 작업이 있었는데, 그건 그래도 원격에는 올라가 있어서 최소한 백업은 되어 있는 상태였어요. 이번 건 그것도 아니었습니다. 이 기기 하나가 고장 나면 세 건 전부 처음부터 다시 만들어야 하는 상태였던 거예요.

원인은 단순했습니다. 작업 공간을 새로 만들어서 그 안에서 작업했는데, “저장해뒀다”와 “원격에 올려뒀다”를 같은 걸로 착각하고 다음 일로 넘어간 거였습니다. 저장은 이 기기 안에서 끝나는 일이고, 원격에 올리는 건 별도의 동작인데, 그 사이 간격을 확인할 방법이 따로 없었습니다.

지금은 이렇게 확인한다

두 가지를 바꿨습니다. 하나, 코드를 하나로 합치자는 제안이 나오면 이름이 비슷하다고 바로 진행하지 않고, 실제로 지금 쓰이는 자리의 코드와 나란히 놓고 줄 단위로 맞춰본 뒤에 진행합니다. 둘, 작업을 끝냈다고 표시하기 전에 원격 저장소에 실제로 올라가 있는지까지 확인하고 나서 “완료”라고 적습니다.

두 가지 다 별로 대단한 습관은 아닌데, 이걸 안 하고 있었다는 게 오히려 신기했습니다.

따라 하기

이번엔 코드 명령어와, AI에게 실제로 시킨 대조 작업을 같이 남깁니다. 코드 두 군데가 겹쳐 보일 때, 그리고 작업이 정말 원격까지 올라갔는지 확인할 때 이 순서를 그대로 쓰시면 됩니다.

1. 합치기 전에, 실제 사용처와 줄 단위로 대조하기

이름이 같아 보인다고 바로 갈아치우면 안 됩니다. 합칠 대상이 지금 실제로 쓰이고 있는 코드인지부터 확인해야 해요.

📋 프롬프트 — 복사해서 AI에 붙여넣으세요

너는 리팩토링 전에 코드를 검증하는 역할이야.
합치려는 함수 A(<파일경로:줄번호>)와,
실제로 화면에서 쓰이는 함수 B·C(<파일경로:줄번호>)를
로직 단위로 한 줄씩 비교해줘.

- A에는 있는데 B·C에 없는 처리, 반대로 B·C에는 있는데
  A에 없는 처리를 각각 구체적인 줄 번호로 짚어줘.
- "완전히 동일하다"는 결론을 낼 때는 반드시 그 근거(대조한 줄 범위)를
  함께 제시해.
- A가 지금 어디에서도 쓰이지 않는 코드라면 그것부터 먼저 알려줘.

✅ 이렇게 되면 성공 — A와 B·C 사이에 안 맞는 처리가 있으면 줄 번호와 함께 나옵니다. 완전히 같다는 답이 나와도, 대조한 범위가 근거로 같이 붙어 있어야 믿을 수 있습니다.

⚠️ 막히면 — “같아 보입니다”처럼 근거 없는 답이 오면, “어느 줄과 어느 줄을 비교했는지 그대로 보여줘”라고 되물으세요.

2. 완성한 작업이 정말 원격에 올라갔는지 확인하기

이 기기에만 남아 있는 작업이 있는지, 명령 하나로 한 번에 찾을 수 있습니다.

git fetch origin
git log --branches --not --remotes --oneline

• git fetch origin — 원격 저장소의 최신 상태부터 로컬로 받아옵니다. 이걸 안 하면 오래된 기준으로 비교하게 됩니다.
• git log --branches --not --remotes --oneline — 로컬엔 있는데 원격 어디에도 없는 작업만 걸러서 보여줍니다. “저장해뒀으니 끝났다”는 착각을 여기서 바로잡을 수 있어요.

✅ 이렇게 되면 성공 — 아무것도 안 나오면 전부 원격에 올라가 있는 상태입니다. 뭔가 나오면, 그게 이 기기에만 남아 있는 작업입니다.

⚠️ 막히면 — 결과에 낯선 작업 이름이 나오면 git log -p <해당 커밋>으로 내용을 먼저 확인한 다음, 문제없으면 git push origin <이름>으로 원격에 올리세요.

배운 것

이번에 배운 건 두 가지예요. 겉보기에 똑같은 코드도, 합칠 대상 자체가 지금 실제로 쓰이는 코드가 맞는지부터 확인해야 한다는 것. 그리고 “저장했다”와 “올렸다”는 다른 동작이라, 둘 사이 간격을 눈으로 확인할 방법을 따로 만들어둬야 한다는 것.

둘 다 거창한 기술이 아니라 확인 습관 하나 차이였습니다. 다음 정리부터는 이 두 가지부터 먼저 체크하려고요.

오늘도 한 걸음. 🐴