26곳 전부 정리했다던 에러 문구, 사실은 절반짜리 "전부"였습니다 🧩

기획 일을 하면서 요건정의서에 “전체 화면 에러 문구 정비”라고 쓴 적이 있습니다. 나중에 QA에서 “이 화면은 왜 빠졌냐”는 질문을 받고서야, 제가 셀 때 리스트형 화면만 세고 상세 화면은 아예 목록에 넣지도 않았다는 걸 알았습니다. “전체”라고 썼지만 제 머릿속 전체는 처음부터 절반이었던 겁니다. 이번엔 제가 만드는 앱의 커밋 로그에서 똑같은 일이 벌어진 걸 봤습니다. 이번엔 제가 쓴 문장이 아니라 AI가 완료 보고에 남긴 문장이었다는 것만 달랐습니다.

“26곳 전부” 정리했다는 커밋

돈독(제가 혼자 만드는 자산관리 앱, https://don-doc.com )에는 화면에서 뭔가 실패하면 String(e) 형태로 원본 에러(스택트레이스가 섞여 나올 수 있는 개발자용 문구)가 그대로 노출되는 지점들이 있었습니다. 이번 달 초 커밋 하나가 이걸 정리했습니다. 커밋 메시지도, 뒤이은 마케팅 초안 문구도 같은 말을 했습니다. “이번엔 전부(26곳) 사람이 읽는 문구로 바꿨어요.”

문제는 이 “전부”가 코드 전체를 훑은 결과가 아니라, app/api/ 아래 라우트 파일이라는 특정 파일 패턴 하나를 훑은 결과였다는 겁니다. 서버 액션('use server'로 시작하는 함수)이나 화면 컴포넌트 안에 있는 같은 종류의 노출은 애초에 그 라우트만 보는 스캔 범위 밖이었습니다.

놓친 자리는 5개 파일, 8곳

이 사각지대는 열흘쯤 뒤 다른 브랜치가 드러냈습니다. 어떤 화면 컴포넌트 하나와 예산·거래 처리 로직 몇 곳에서 여전히 같은 패턴의 원본 에러 노출이 남아 있는 걸 보고, 그걸 닫는 커밋을 새 브랜치에 올린 겁니다. 두 브랜치를 나란히 대조해보니 정확히 5개 파일, 8곳이 남아 있었습니다. 화면 컴포넌트 하나, 예산·거래·자동제외·정리 로직을 다루는 파일 넷이었습니다. 전부 처음 정리 때와 똑같은 패턴이었는데, 딱 하나 다른 건 파일이 있는 위치였습니다. 라우트 폴더가 아니라는 것.

이 사각지대를 찾아낸 방법은 거창하지 않았습니다. 두 브랜치의 차이를 git diff로 파일 단위로 대조해본 것뿐입니다. 구조를 바꾸는 커밋이 아니라 문자열 하나씩 바꾸는 패턴이라, 원래 커밋과 충돌하는 지점도 없었습니다. 그냥 원래 정리가 안 본 자리를 그대로 마저 본 것뿐이었습니다.

마케팅 카피도 이걸 못 봤다

더 흥미로운 건, “전부 훑었다”는 그 선언을 코드 담당만 믿은 게 아니라는 겁니다. 그 커밋을 사용자 대상 콘텐츠로 옮기는 작업에서도 같은 문장이 그대로 쓰였습니다. “지난달엔 화면 2곳만 고쳤는데, 이번엔 API 전체를 훑었다”는 진행 서사로요. 검증해야 할 사람도, 그걸 사람들에게 알리는 사람도 똑같이 “26곳”이라는 숫자와 “전부”라는 단어를 그대로 받아들인 셈입니다. 숫자가 구체적이면 구체적일수록, 그 숫자가 뭘 세서 나온 숫자인지는 오히려 아무도 안 묻고 넘어가기 쉽습니다.

“26곳 전부”라는 문장에서, 26이 틀린 게 아니라 “전부”가 가리키는 범위 자체가 좁았습니다.

---

따라 하기

“이번엔 전부 처리했습니다” 같은 보고를 받으면, 저는 이제 숫자를 믿기 전에 그 숫자가 어떤 범위 안에서 나왔는지부터 확인합니다.

1. 원래 정리 커밋이 무엇을 범위로 잡았는지 diff로 확인한다

git show --stat <원래-정리-커밋-해시>

• 커밋 메시지의 “전부”라는 말을 믿지 않고, 실제로 바뀐 파일 목록을 봅니다. 파일 경로가 한 폴더(예: app/api/)에만 몰려 있다면, 그 커밋의 “전부”는 코드 전체가 아니라 그 폴더 안의 전부라는 뜻입니다.

2. 같은 패턴이 그 폴더 밖에도 있는지 직접 검색해본다

grep -rn "String(e)" --include="*.tsx" --include="*.ts" .

• 정리 대상이 된 패턴(여기서는 String(e))을 폴더 제한 없이 전체 검색해서, 원래 커밋이 손대지 않은 자리가 몇 곳 더 있는지 직접 셉니다. “전부”라는 보고를 받았을 때 제일 먼저 하는 검증이 이겁니다.

3. 발견된 후속 브랜치는 구조 변경이 섞였는지부터 본다

git diff --stat main <후속-브랜치>
git log main..<후속-브랜치>

• 사각지대를 닫는 브랜치가 있다면, 병합하기 전에 그게 같은 종류의 단순 치환인지 아니면 다른 구조 변경까지 끼어 있는지 확인합니다. 파일 수·줄 수가 작고 커밋 로그가 같은 패턴을 반복한다면, 원래 정리와 같은 성격의 후속 작업일 가능성이 높습니다.

✅ 이렇게 되면 성공 — 원래 커밋의 스캔 범위, 그 범위 밖의 전체 검색 결과, 후속 브랜치의 변경 성격까지 세 가지가 나란히 맞아떨어지면 그때 병합·정리 여부를 판단합니다.

⚠️ 막히면 — 전체 검색(2번) 결과가 원래 커밋의 파일 목록보다 훨씬 많이 나온다면, “전부”라는 보고 자체를 다시 써야 할 수도 있습니다. 숫자를 정정하는 게 아니라, 애초에 그 숫자가 무엇을 세는 숫자였는지부터 다시 정의해야 합니다.

배운 것

이번에 배운 건 “26이라는 숫자가 틀렸다”가 아닙니다. “전부”라는 말이 가리키는 범위를 아무도 다시 안 물었다는 겁니다. 저도 기획서에 “전체”라고 쓸 때 제가 셀 수 있는 것만 세고 그걸 전체라고 부른 적이 있습니다. 이제는 “전부 처리했습니다”라는 보고를 받으면, 그 전부가 어떤 파일 패턴·어떤 화면 종류를 기준으로 그린 원인지부터 한 번 더 묻습니다. 숫자가 클수록, 완결됐다는 말이 단정적일수록 그렇습니다.

오늘도 한 걸음. 🐴