실행 차단 훅이 엉뚱한 폴더를 검사할 때: cd 명령 추적으로 경로 판별 고치기

문제 제기 · 검사 도구가 '어디를 보는가'가 틀렸을 때

코드를 원격 저장소에 올리기 전에 자동으로 실행되어 "이 올리기를 검토할지 말지"를 판단하는 작은 프로그램이 있습니다. 개발에서는 이런 자동 실행 프로그램을 훅(hook)이라고 부릅니다. 이 훅은 미리 정해둔 검토 대상 폴더 목록(화이트리스트)에 든 폴더에서 올리기가 일어날 때만 검토를 겁니다. 목록 밖 폴더는 건드리지 않는 것이 원칙입니다.

그런데 이 훅이 지금 올리려는 게 어느 폴더인가를 잘못 판단하고 있었습니다. 명령어 안에 폴더를 옮기는 부분(cd)이 들어 있으면 그걸 따라가지 못해, 처음 열려 있던 폴더를 기준으로 검사했습니다. 그 결과 막아야 할 걸 통과시키고, 통과시켜도 될 걸 막는 일이 동시에 일어났습니다.

이 글은 특정 도구 하나의 이야기가 아니라, 실행을 감시·차단하는 모든 자동화에 적용되는 원칙을 다룹니다. 검사 규칙 자체가 맞아도 그 규칙을 어느 폴더에 적용할지가 틀리면 도구 전체가 신뢰를 잃습니다.

---

왜 위험한가 · 정반대 방향의 두 증상

같은 원인 하나에서 정반대 방향의 두 가지 증상이 나왔습니다. 이게 위험한 이유는, 하나만 보면 원인을 반대로 진단하기 쉽기 때문입니다.

• 막지 말아야 할 걸 막음(오탐): 관리 대상인 A 폴더가 열린 상태에서 cd 관리레포B && git push처럼 B 폴더로 옮겨 올리기를 했더니, 실제 대상은 B인데 도구가 A를 기준으로 검사해 차단했습니다. 실제로 control 세션에서 blog 올리기가 막힌 사례가 있었습니다. 개발자는 "왜 정상 작업이 막히지?"라며 훅을 꺼버리고 싶어집니다.
• 막아야 할 걸 통과시킴(누락): 반대로 관리 대상이 아닌 폴더가 열린 상태에서 cd 관리레포 && git push를 하면, 도구는 처음 열린 폴더가 비관리라고 보고 검토 없이 통과시켰습니다. 이건 검토 규칙 자체를 우회할 수 있는 구멍입니다.

오탐은 도구를 짜증나게 만들어 결국 무력화시키고, 누락은 도구가 있으나 마나 한 상태로 만듭니다. 둘 다 "검사 도구를 믿을 수 없다"는 같은 결말로 이어집니다.

---

원인 확인 · '무엇을 볼지'는 맞았는데 '어디를 볼지'가 틀렸다

도구의 명령 해석기는 git -C <경로> 형태로 폴더를 직접 지정한 경우만 인식했습니다. 하지만 cd로 폴더를 옮긴 뒤 올리는 형태는 추적하지 못했습니다. 그 결과 판별 기준이 항상 처음 열려 있던 폴더로 고정됐습니다.

명령 형태	도구가 본 폴더	실제 대상 폴더	결과
git -C 경로 push	지정한 경로	지정한 경로	정상
A에서 cd B && git push	A	B	잘못 차단
비관리에서 cd 관리 && git push	비관리	관리	검토 누락

검사할 규칙 자체는 맞았습니다. 다만 그 규칙을 어느 폴더에 적용할지를 정하는 입력이 틀려서, 오탐과 누락이 한꺼번에 생긴 것입니다. 자기 도구에서 이런 증상이 보인다면, 먼저 "규칙이 틀렸나"가 아니라 "규칙을 적용하는 대상 좌표가 맞나"를 의심하는 편이 빠릅니다.

---

어떻게 고쳤나 · 폴더 이동을 따라가게 만들기

핵심은 명령어를 조각(세그먼트) 단위로 읽으면서 cd와 pushd를 추적해, 올리기가 실제로 실행될 시점의 폴더를 다시 계산하는 것입니다. 처리 순서는 다음과 같습니다. 자기 환경에서 그대로 적용할 수 있도록 번호로 정리합니다.

1. 명령어를 && 같은 구분자로 조각냅니다.
2. 조각을 앞에서부터 읽으며 cd를 만나면 현재 폴더를 갱신합니다. 절대경로면 통째로 교체하고, 상대경로면 지금 폴더에 이어 붙입니다.
3. cd와 git -C가 함께 있으면, cd로 보정한 폴더 위에 다시 -C 경로를 적용합니다.
4. 이렇게 계산한 최종 폴더를 검토 대상 판별에 사용합니다.

가장 중요한 안전장치는 해석할 수 없는 이동은 억지로 추측하지 않는다는 규칙입니다. 다음 경우들은 값을 비워두고 기존 동작(처음 열린 폴더 기준)으로 되돌립니다.

• $VAR처럼 변수로 된 경로 — 훅 실행 시점에 값을 알 수 없음
• ~(홈 폴더 기호) — 사용자 환경에 따라 달라짐
• -(직전 폴더로 돌아가기) — 이전 상태를 추적해야 정확히 알 수 있음
• 경로 인자가 아예 없는 cd

이 폴백 규칙에는 분명한 이유가 있습니다. 이 도구의 계약은 "검토 대상 목록 밖의 폴더는 절대 막지 않는다"입니다. 판단이 애매하다고 해서 '일단 더 넓게 막자'로 가면 이 계약이 깨집니다. 그래서 애매할 때는 막는 쪽이 아니라 원래 동작을 유지하는 쪽으로 폴백합니다.

---

적용 체크리스트와 전후 비교

실행을 감시·차단하는 훅을 만들거나 고칠 때 확인할 항목입니다.

• 명령어 안에 cd, pushd 등 작업 폴더를 바꾸는 요소가 있는지 파싱하는가?
• 절대경로와 상대경로를 구분해 현재 폴더를 갱신하는가?
• 변수·기호처럼 해석 불가능한 입력을 만났을 때의 기본값이 정해져 있는가?
• 그 기본값이 '더 넓게 막기'가 아니라 '원래 동작 유지'인가(도구의 안전 계약 기준)?
• 오탐·누락·회귀·폴백·보호를 각각 검증하는 테스트 케이스가 있는가?

A에서 B로 이동 후 올리기	A 기준으로 검사해 잘못 차단	B를 대상으로 정확히 검토
비관리에서 관리로 이동 후 올리기	검토 없이 통과(우회 구멍)	관리 폴더로 인식해 검토
변수·기호 등 해석 불가한 이동	처음 열린 폴더 기준	처음 열린 폴더 기준(그대로 유지)
목록 밖 폴더	막지 않음	여전히 막지 않음(계약 유지)

검증은 총 14가지 경우로 진행했습니다. 오탐 1건, 누락 4건, 기존 동작이 그대로인지 보는 회귀 6건, 폴백 2건, 목록 밖 폴더를 건드리지 않는지 확인하는 보호 1건입니다. 회귀 6건을 둔 이유는 새 로직이 이미 잘 되던 경로 판별까지 망가뜨리지 않았는지 확인하기 위해서입니다.

---

한계와 주의사항

이번 방식에도 한계가 있습니다. 명령어를 정적으로 파싱해 폴더를 재현하는 접근이므로, 셸의 모든 동작을 완벽히 재현하지는 못합니다. 이번 수정에서 폴백으로 넘긴 입력은 변수로 된 경로($VAR), 홈 폴더 기호(~), 직전 폴더로 돌아가기(-), 경로 인자가 없는 cd였습니다. 이처럼 실행 시점에야 값이 정해지거나 이전 상태를 알아야 하는 형태는 해석 불가로 두고 기존 동작으로 물러섭니다. 즉 정확도를 100% 보장하지 않으며, 대신 안전 계약을 깨지 않는 방향으로 물러섭니다.

이 트레이드오프를 명확히 이해하는 것이 중요합니다. 폴백은 "막아야 할 것을 놓칠 수 있음"을 감수하고 "막지 말아야 할 것을 막지 않음"을 지키는 선택입니다. 만약 여러분의 도구가 반대 성격(보안 차단처럼 놓치면 안 되는 경우)이라면, 폴백 방향을 반대로 — 애매하면 막는 쪽으로 — 잡아야 합니다. 정답은 도구의 계약이 무엇이냐에 달려 있습니다.
마지막으로 얻은 교훈을 한 문장으로 요약합니다. 검사 도구가 '무엇을 검사할지' 규칙이 맞더라도, '어디를 보고 있는지'가 틀리면 오탐과 우회가 동시에 생긴다. 실행을 막는 도구는 명령어가 실제로 실행될 폴더를 최대한 똑같이 재현해야 하고, 재현이 불가능한 입력의 기본값은 도구의 안전 계약에 맞춰 정해야 합니다.