광고 차단·개인정보 페이지에서 서비스 잔재 텍스트 제거

세 군데 파일에서 money/ssul 관련 잔재를 한꺼번에 제거한 작업이었다.

왜 이런 "잔재"가 생기나

리팩터링이나 서비스 방향 전환을 하고 나면, 주요 진입점은 깔끔하게 바뀌어 있는데 구석에 있는 파일들은 예전 텍스트나 로직이 그대로 남아 있는 경우가 꽤 흔하다. 이번에도 그 전형적인 패턴이었다. Post.astro, privacy.astro, AntiAdblock.astro — 셋 다 직접적인 "기능 파일"이 아닌 레이아웃/정책/부가 컴포넌트 쪽이라 메인 정리 작업 때 시선이 잘 안 닿는 영역이다.

그래서 첫 번째 정리 커밋 이후에도 이런 "purge remaining" 커밋이 하나 더 나오게 된 거다. 완벽하지 않았던 게 아니라, 오히려 이 정도면 꼼꼼하게 마무리한 편이라고 본다. 문제는 이런 잔재를 어느 시점에 발견하느냐인데, 이번엔 배포 전에 훑어보다 잡았다.

각 파일이 들고 있던 맥락

privacy.astro는 특히 방심하기 쉽다. 법적 고지성 텍스트 안에 서비스 명칭이나 기능 설명이 섞여 있으면, 코드 검색으로는 안 걸리는 자연어 형태로 남아 있는 경우가 있다. AntiAdblock.astro 쪽은 수익 구조가 바뀌면 광고 차단 대응 문구 자체를 다시 써야 하는데, 이전 맥락의 언어가 남아 있으면 사용자 입장에서 혼란스럽다.

이런 류 정리 작업에서 챙겨야 할 것들

• 텍스트 검색 범위를 넓게 잡기 — 코드 식별자가 아닌 자연어 문자열까지 포함해서 grep 또는 IDE 전체 검색을 돌려야 잔재가 잘 잡힌다
• 레이아웃/정책/비기능 파일 별도 체크 — 기능 파일 위주로 리뷰하다 보면 layouts/, pages/policy 같은 폴더는 건너뛰기 쉽다
• 컴포넌트 안의 하드코딩 문구 — 특히 AntiAdblock 같은 UX 문구성 컴포넌트는 서비스 맥락에 굉장히 종속적으로 작성되어 있을 때가 많음

# 잔재 탐지할 때 쓰는 패턴
grep -r "money\|ssul" src/ --include="*.astro" -l

이런 식으로 커밋 직전에 한 번 더 돌려보는 게 습관이 되면, 이번 같은 follow-up 커밋을 줄일 수 있다. 물론 이번엔 배포 전에 잡았으니 결과적으론 문제없이 마무리됐다.

코드리뷰 맥락에서도 마찬가지인데, 팀원이 "기능 구현" PR을 올렸을 때 레이아웃이나 정책 페이지까지 눈이 가는 리뷰어가 많지 않다. 그래서 이런 잔재 제거 커밋은 결국 직접 전체를 훑어보는 사람이 잡게 된다. 리드 포지션에서 "배포 전 한 번 더 전체 텍스트 grep 돌려보기"를 루틴으로 만들어두면 팀 전체적으로 이런 상황이 줄어든다.

셋 다 작은 파일이고 변경 자체도 핀포인트였겠지만, 사용자에게 보이는 문구와 법적 문서 안의 내용은 사소해 보여도 신뢰도에 영향을 준다. 그 이유 하나만으로 이 커밋은 충분히 가치 있었다.

끝.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.