클론 존재 상태를 '없음'으로 잘못 기록한 문서 정정

오늘 docs/sites-detail.md 를 수정했다. love mac 클론이 실제로는 존재하는데, 문서에 "클론 없음"이라고 잘못 기록되어 있던 부분을 정정한 것. 원인은 zsh glob 패턴 오판이었다.

뭐가 일어났나

처음에 내가 클론 존재 여부를 확인하는 스크립트를 돌렸을 때, glob 패턴이 예상과 다르게 동작했다. zsh의 glob expansion 이 특정 상황에서 예기치 않은 결과를 내놨고, 그 결과를 그대로 문서에 박아 버렸던 거다. 즉, 자동화 검사 단계에서 false negative 가 발생했는데, 그걸 못 잡고 넘어갔던 셈.

# zsh glob 오판 예시
# 의도: "love_mac*" 패턴으로 클론 디렉토리 찾기
ls love_mac*  # 예상: "love_mac_clone" 등이 나열됨
              # 실제: glob이 expand 안 되어 "no matches" 같은 결과

# 정정 후: 명시적 경로 확인
test -d ./love_mac_clone && echo "exists" || echo "not found"

glob 패턴이 왜 헷갈리나

zsh (그리고 bash도 마찬가지)에서 glob 은 단순한 문자열 매칭이 아니다. 몇 가지 까다로운 부분이 있다:

내 경우, 스크립트가 glob을 사용해서 디렉토리를 탐색했는데, 특정 shell 설정에서 매칭 실패했던 것 같다. 그래도 스크립트는 에러 없이 "클론 없음"이라고 결론 내린 거. 자동화 검사가 조용히 실패한 것.

왜 이걸 회고로 남기나

문서의 정확성은 팀의 신뢰도와 직결된다. 특히 상태 정보(클론 존재 여부, 배포 상황, 설정 값 같은)는 다른 팀원들이 의사결정할 때 쓰인다. 만약 누군가 "love mac 클론이 없다"라고 믿고 작업 계획을 세웠다면, 나중에 실제로 존재한다는 걸 알았을 때 혼란이 생긴다.

이번 건 다행히 early catch 했지만, 만약 deployment 단계에서 발견됐다면 더 심각했을 거다. 자동화 검사 → 문서 작성 → 팀 배포 의 chain 어느 단계든 한 번의 오판이 퍼질 수 있다는 뜻이다.

배운 점 + 다음부턴

1. glob 대신 명시적 파일 체크 쓰기 — test -d 나 [[ -d ... ]] 처럼 shell builtin 을 쓰는 게 더 신뢰할 수 있다.
2. 자동화 검사 결과를 맹신하지 않기 — 특히 상태 정보는 script 로만 확인하지 말고, 사람이 한 번 sanity check 하기.
3. 문서 버전 관리 시 "언제, 누가, 왜" 남기기 — 그럼 나중에 이상한 값이 있을 때 원인 추적이 쉽다.
4. 팀에 알리기 — 이런 오류 패턴을 팀과 공유하면, 다른 팀원이 비슷한 상황에서 미리 방지할 수 있다.

결국 이번 정정은 작은 문서 수정이지만, 자동화의 한계와 휴먼 검증의 필요성을 다시 한번 깨닫는 기회가 됐다.

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

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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