AI 코딩 설정도 코드처럼 썩는다 — 가짜 보안 훅과 죽은 에이전트 11개
하네스(AI 도구를 내 방식대로 굴리는 설정·규칙·자동화 묶음)를 만드는 법은 전에 썼다. 그런데 만든 다음, 그 AI 코딩 설정이 계속 작동하는지는 아무도 점검하지 않는다.
며칠 전 처음으로 내 설정을 전수 점검했다. 몇 달 동안 잘 굴러간다고 믿었던 설정이다.
다 열어보고 든 생각은 하나였다. 절반이 조용히 죽어 있거나, 가짜로 작동하고 있었다.
가장 충격적인 건 보안 훅이었다. API 키가 새는 걸 막으려고 달아둔 훅이, 필드명 오타 하나 때문에 설치된 날부터 한 번도 실행된 적이 없었다. 개발 에이전트 11개는 주석 한 줄 때문에 세션에 등록조차 안 되고 있었다.
설정도 코드처럼 썩는다. 만들고 방치하면 죽은 참조와 작동 안 하는 안전장치가 쌓인다. 영어로는 이걸 설정 부패(config rot)라고 부른다.
누가 읽으면 좋은가
- Claude Code·Cursor에 CLAUDE.md·에이전트·훅을 세팅해 본 사람
- 설정을 한참 전에 만들어두고 그 뒤로 열어본 적 없는 사람
- “에러가 안 나니까 잘 돌고 있겠지”라고 믿고 있는 사람
한 줄로 요약하면, 설정 파일에 등록돼 있다는 것과 그 기능이 실제로 작동한다는 것은 전혀 다른 문제였다.
주석 한 줄에 사라진 에이전트 11개
점검에서 가장 먼저 걸린 건 개발 에이전트들이었다. architect, planner, code-reviewer… 정의 파일은 멀쩡히 다 있었다. 그런데 세션에서 단 하나도 호출되지 않고 있었다.
원인은 파일 맨 위에 무심코 넣은 주석 한 줄이었다. # Part of … 같은 한 줄이 그 아래 frontmatter 파싱을 깨뜨렸고, 시스템은 그 파일들을 에이전트로 인식하지 못했다. 정의는 있는데 시스템은 그들을 보지 못한 것이다.
11개가 이 상태였다. 에러도, 경고도 없었다. 그냥 명단에서 빠져 있었다.
한 번도 돌지 않은 보안 훅
더 무서운 건 보안 훅이었다. 시크릿이 화면에 노출되는 걸 막으려고 만든 훅인데, 코드는 tool_result라는 필드를 보고 있었고 실제로 들어오는 필드명은 tool_response였다.
단어 하나가 어긋나서 매칭이 한 번도 성립하지 않았다. 그 훅은 설치된 날부터 단 한 번도 돈 적이 없다.
문제는 오타만이 아니었다. 그 훅은 도구가 실행된 다음에 도는 구조였다.
설령 오타를 고쳐도, 가릴 시점엔 모델이 이미 결과를, 그러니까 시크릿을 다 본 뒤다. 사후에 가린들 소용이 없다. 구조 자체가 틀렸다.
그래서 실행 전에 차단하는 방식으로 다시 짰다. 정상 입력과 시크릿이 든 입력 32가지로 통과·차단을 확인한 뒤에야 “이제 진짜 작동한다”고 말할 수 있었다. 그 전 몇 달간, 나는 있지도 않은 안전장치를 믿고 있었던 셈이다.
조용히 쌓인 설정 부패
나머지도 결이 비슷했다.
작업 로그 파일은 동기화 스크립트가 빠진 채 무한히 커져 20MB가 돼 있었다. 그걸 매 세션 시작마다 통째로 읽느라 1~2초씩 까먹고 있었다.
훅 하나는 타임아웃을 5000으로 적어뒀는데 단위가 초였다. 5000초, 그러니까 83분짜리 타임아웃이 걸려 있던 셈이다.
라우팅 표의 23개 항목은 내 환경에 존재하지도 않는, 남의 설정에서 복사돼 온 에이전트를 가리키고 있었다.
여기에 하나 더. 모델을 새 버전으로 올린 것도 부패를 키웠다. 새 모델은 지시를 더 문자 그대로 따른다.
옛 모델의 느슨함을 이기려고 써둔 “반드시 X해라 / 즉시 실행” 같은 압박 표현이, 새 모델에선 오발동을 만들었다. 도구를 과하게 부르고 사소한 것마다 되물었다.
모델만 갈아타고 설정을 그대로 두면, 설정이 새 모델과 어긋난다.
‘있다’에서 ‘작동한다’까지
점검을 끝내고 남은 교훈은 한 문장이다. 설정 파일에 등록돼 있다고 그 기능이 도는 게 아니다.
주석 한 줄, 필드명 한 단어, 시간 단위 착각. 전부 에러도 경고도 없이 조용히 작동했다. 정확히는, 조용히 작동하지 않았다.
시스템은 멀쩡해 보였고, 나는 매일 잘 쓰고 있다고 믿었다. 그래서 “에러가 안 난다”는 건 “정상”의 증거가 못 된다.
죽은 설정은 비명을 지르지 않으니, 정기적으로 직접 열어보지 않으면 죽었다는 사실조차 모른다.
해법은 거창하지 않다. 코드에 테스트와 린트를 돌리듯, 설정도 정기적으로 감사하는 것뿐이다.
보안 훅이라면 시크릿 샘플을 넣어 정말 차단되는지 본다. 에이전트라면 실제로 호출되는지 본다. 자동 발행 같은 작업이라면 결과를 다시 읽어 확인한다.
내 경우 발행 후 검증이 빠져 있어서, 과거에 글 제목이 대량으로 날아간 적이 있다.
핵심은 “있다”에서 멈추지 않고 “작동한다”까지 확인하는 습관이다. 한 번 만들고 끝이 아니라, 코드처럼 주기적으로 들여다봐야 한다.
한계
- 한 사람의 설정을 한 번 점검한 기록이다. 다른 환경에서도 같은 비율로 썩는지는 모른다.
- 지금은 수동 전수 점검이다. 이걸 어떻게 자동으로 돌릴지는 다음 숙제고, “정기 감사”의 주기와 자동화는 아직 못 정했다.
- 부패 사례는 내 설정에 한정된다. 도구·버전이 다르면 다른 곳이 썩을 수 있다.
참고
- 하네스 엔지니어링 — CLAUDE.md만 쓴다고 끝나지 않는다
- 프롬프트 엔지니어링·에이전트·하네스, 무엇이 다른가
- CLAUDE.md·AGENTS.md를 명시적으로 쓰면 달라지는 것 — 측정 기록
저자 — Jason 황재승
cd4761.blogspot.com에서 개발 자동화와 AI 도구 운영 기록을 쓴다. 8년 차 프론트엔드. 만드는 법보다 만든 다음을 더 자주 들여다보려 한다.
태그: #AI설정 #config_rot #설정부패 #ClaudeCode #하네스 #에이전트점검 #보안훅 #개발자동화 #유지보수
댓글
댓글 쓰기