사용자명 하나 바뀌었을 뿐인데 — 하드코딩된 절대경로 추적기

노트북을 바꿨더니 빌드 스크립트가 엉뚱한 곳에 파일을 떨군다

지난번 노트북을 새 맥으로 옮기면서 빌드 환경을 다시 맞췄습니다. 그 과정은 어찌어찌 끝났는데, 며칠 뒤 더 조용하고 음흉한 문제가 하나 남아 있었다는 걸 깨달았습니다.

바로 macOS 사용자명이 바뀌었다는 사실입니다.

이전 노트북 홈 디렉터리: /Users/hy
새 노트북 홈 디렉터리: /Users/hs

별것 아닌 것 같죠? 그런데 그동안 프로젝트 여기저기에 /Users/hy/... 같은 절대경로를 하드코딩해 둔 게 꽤 있었습니다. 빌드 산출물 저장 위치, 문서, 스크립트, 심지어 에디터/도구 설정 파일까지요. 사용자명이 바뀌는 순간 이 경로들은 전부 "존재하지 않는 폴더"를 가리키게 됩니다.

문제는 이게 에러로 안 터지는 경우도 많다는 겁니다. 예를 들어 빌드 스크립트가 mkdir -p로 폴더를 만들고 거기에 결과물을 복사하면, 에러 없이 /Users/hy라는 엉뚱한 폴더가 새로 생기고 거기에 파일이 쌓입니다. 정작 나는 /Users/hs에서 그 파일을 찾고 있고요. 조용히 어긋나는 거죠.

그래서 이번엔 작정하고 프로젝트 전체에서 옛 사용자명 경로를 싹 찾아 고쳤습니다. 그 과정을 정리해 봅니다.

사전 준비: 무엇을 찾을 것인가

목표는 단순합니다. 프로젝트 안에서 옛 절대경로 /Users/hy가 박힌 모든 곳을 찾아내는 것. 핵심 도구는 grep 하나면 충분합니다.

찾기 전에 한 가지만 정해두면 좋습니다. 무시할 폴더입니다. node_modules나 빌드 캐시 안에는 내가 손댈 필요 없는(또는 손대면 안 되는) 경로가 잔뜩 들어 있어서, 빼고 봐야 결과가 깔끔합니다.

Step 1. grep으로 하드코딩 경로 전수 조사

먼저 프로젝트 루트에서 옛 경로가 들어간 파일을 모두 찾습니다. -r(재귀), -l(파일명만), -n(줄 번호)을 상황에 맞게 씁니다.

# 어떤 "파일"에 /Users/hy 가 들어있는지 (node_modules 제외)
grep -rln "/Users/hy" . | grep -v node_modules

저는 결과가 이렇게 나왔습니다.

BUILD.md
build_aab.sh
store/CHANGELOG.md

문서, 셸 스크립트, 변경 이력 — 종류가 제각각이죠. 다음은 각 파일의 몇 번째 줄에 박혀 있는지까지 봅니다.

grep -n "/Users/hy" BUILD.md build_aab.sh store/CHANGELOG.md

BUILD.md:7:| AAB 배포 | `/Users/hy/Documents/workspace/apk_build_files/...` |
BUILD.md:23:... `/Users/hy/Documents/workspace/apk_build_files/...` 에 복사됨.
build_aab.sh:7:RELEASE_DIR="/Users/hy/Documents/workspace/apk_build_files/chainPlay"
store/CHANGELOG.md:4:> AAB 파일: `/Users/hy/Documents/workspace/apk_build_files/...`
store/CHANGELOG.md:106:- [ ] AAB 빌드 후 ... 에 복사

💡 확장자로 범위를 좁히고 싶다면 --include를 씁니다.
grep -rln "/Users/hy" . --include="*.md" --include="*.sh" --include="*.json" | grep -v node_modules

여기서 중요한 포인트 하나. 문서(BUILD.md)와 실제 스크립트(build_aab.sh)는 한 쌍이라는 점입니다. 문서에 적힌 경로만 고치고 스크립트를 안 고치면, 빌드는 여전히 옛 경로에 파일을 떨굽니다. 반대도 마찬가지고요. 같이 봐야 합니다.

Step 2. 문서·스크립트 경로 한 번에 치환

경로가 정확히 같은 문자열이라면 치환은 간단합니다. 한 파일 안에 여러 번 나오면 "전부 바꾸기"를 쓰면 되고요.

스크립트의 경우, RELEASE_DIR 한 줄만 바꾸면 됩니다.

# build_aab.sh
RELEASE_DIR="/Users/hs/Documents/workspace/apk_build_files/chainPlay"
#                   ↑ hy → hs

이 스크립트는 뒤에서 mkdir -p "$RELEASE_DIR"로 폴더를 알아서 만들기 때문에, 경로 문자열만 새 사용자명으로 맞춰주면 그대로 동작합니다.

커맨드라인에서 일괄 치환하고 싶다면 sed도 좋습니다. 다만 macOS의 sed는 -i 뒤에 빈 확장자('')를 꼭 붙여야 합니다(리눅스와 다른 부분이라 자주 헷갈립니다).

# macOS: 백업 없이 제자리 치환
sed -i '' 's#/Users/hy#/Users/hs#g' BUILD.md build_aab.sh store/CHANGELOG.md

⚠️ 경로 치환에 sed를 쓸 땐 구분자를 /가 아니라 #로 두는 게 편합니다. 경로 안에 /가 잔뜩 들어 있어서 s/.../.../ 형태면 이스케이프 지옥에 빠지거든요.

저는 변경 내용을 눈으로 확인하면서 고치고 싶어서 파일별로 직접 수정했습니다. 자동 치환이 편하긴 하지만, CHANGELOG처럼 "과거 기록" 성격의 문서는 의미상 손대도 되는지 한 번 더 따져보는 게 좋습니다. 이번 경우엔 "AAB 파일을 어디서 찾으면 된다"는 안내 경로라서 현재 환경에 맞추는 게 맞았습니다.

Step 3. 외부 도구 설정까지 잊지 말기

프로젝트 폴더 안만 본다고 끝이 아닙니다. 프로젝트 밖, 도구 설정에도 옛 경로가 숨어 있을 수 있습니다. 저는 블로그 글 초안을 저장하는 커스텀 스킬 설정 파일에도 /Users/hy/... 저장 경로가 박혀 있었습니다.

그래서 홈 디렉터리의 설정 폴더까지 한 번 더 훑었습니다.

# 도구 설정 폴더에 남은 옛 경로 확인
grep -rln "/Users/hy" ~/.claude 2>/dev/null

이런 설정은 보통 "한 번 적어두고 잊는" 종류라, 막상 옛 경로가 가리키는 폴더가 없어지면 "왜 파일이 저장이 안 되지?" 하고 한참 헤매게 됩니다. 사용자명을 바꿨다면 같이 점검해 두는 게 좋습니다.

Step 4. 마무리 검증 — 정말 다 고쳤나?

수정을 마쳤으면, 처음 썼던 grep을 그대로 한 번 더 돌립니다. 결과가 비어 있어야 안심이죠.

grep -rln "/Users/hy" . | grep -v node_modules || echo "✅ 옛 경로 모두 정리됨"

✅ 옛 경로 모두 정리됨

이렇게 "고치기 전 grep → 수정 → 고친 후 같은 grep" 으로 감싸면, 빠뜨린 곳 없이 마무리됐는지 확실하게 확인할 수 있습니다.

자주 쓴 명령어 요약

목적	명령
경로가 든 파일 찾기	`grep -rln "/Users/hy" . \| grep -v node_modules`
줄 번호까지 보기	`grep -n "/Users/hy" <파일들>`
확장자로 범위 좁히기	`grep -rln "..." . --include=".sh" --include=".md"`
macOS 제자리 치환	`sed -i '' 's#/Users/hy#/Users/hs#g' <파일들>`
도구 설정까지 점검	`grep -rln "/Users/hy" ~/.claude`
최종 검증	`grep -rln "/Users/hy" . \| grep -v node_modules` (비어야 정상)

트러블슈팅: 이런 함정들

에러가 안 나서 더 위험하다: mkdir -p가 들어간 스크립트는 옛 경로에 폴더를 새로 만들어 버립니다. "빌드는 성공했는데 결과물이 어디 갔지?" 싶으면 경로부터 의심하세요.
sed -i가 macOS에서 에러: 리눅스 습관대로 sed -i 's/.../.../' 하면 command c expects \ followed by text 같은 에러가 납니다. macOS는 sed -i '' 처럼 빈 백업 확장자를 줘야 합니다.
문서만 고치고 스크립트를 잊음: 가장 흔한 실수. grep 결과에 .md와 .sh가 같이 나왔다면 둘 다 손봐야 짝이 맞습니다.
프로젝트 밖 설정을 놓침: ~/.config, ~/.claude, 에디터 워크스페이스 설정 등 홈 디렉터리 쪽도 한 번은 grep 해보세요.

정리 — 핵심 흐름 한눈에

grep으로 전수 조사 — grep -rln "옛경로" . | grep -v node_modules
줄 번호까지 확인 — 어디에 몇 개 박혀 있는지 파악
문서·스크립트를 한 쌍으로 고치기 (한쪽만 고치면 어긋남)
프로젝트 밖 도구 설정도 점검
같은 grep으로 최종 검증 — 결과가 비면 끝

그래서 얻은 진짜 교훈: 사용자명은 통일하자

이번 일을 겪고 나서 내린 결론은 의외로 단순합니다.

노트북을 바꾸더라도, macOS 사용자명(홈 디렉터리 이름)은 예전 것과 통일하는 게 가장 편하다.

생각해 보면 이 모든 수고는 hy가 hs로 바뀌었기 때문에 생긴 일입니다. 만약 새 맥을 설정할 때 사용자명을 이전과 똑같이 만들었다면, /Users/hy/... 절대경로들은 새 노트북에서도 그대로 유효했을 거고, 위의 grep-치환 작업은 애초에 필요 없었겠죠.

물론 더 근본적인 해법은 "애초에 절대경로를 하드코딩하지 않는 것"입니다. 스크립트라면 $HOME이나 $(cd "$(dirname "$0")" && pwd) 같은 상대적 기준을 쓰는 게 정석이고요. 하지만 현실적으로 문서나 메모, 도구 설정 곳곳에 절대경로가 스며드는 걸 100% 막기는 어렵습니다.

그러니 두 가지를 같이 챙기는 걸 추천합니다.

새 환경을 만들 땐 사용자명을 통일 — 가장 손쉬운 보험
그래도 스크립트에선 $HOME 등 상대 기준 사용 — 환경에 덜 묶이는 코드

저는 이번에 사용자명을 새로 정해버린 탓에 경로를 한바탕 정리했지만, 덕분에 "내 프로젝트가 어디어디에 절대경로를 박아뒀는지"를 전부 파악하는 계기가 됐습니다. 다음 노트북 이사 때는 더 매끄럽겠죠. 같은 길을 가실 분이라면, 새 맥 사용자명을 정하는 그 순간에 이 글을 떠올려 주시길 바랍니다.