Claude 말버릇 훅, 프롬프트 밖 통제의 힌트
말버릇을 바꾸는 작은 훅은 농담처럼 보이지만, 에이전트 제품의 중요한 설계 원칙을 보여준다. 반복되는 행동과 표현은 프롬프트가 아니라 실행 계층에서 통제해야 한다.
AI 뉴스를 놓치지 마세요
매주 핵심 AI 소식을 이메일로 받아보세요.
농담 같은 글이 드러낸 피로감
jola.dev의 글은 Claude Code가 반복해서 쓰는 특정 표현을 MessageDisplay 훅으로 치환하는 짧은 튜토리얼이다. 작성자는 Python 스크립트로 출력 delta를 읽고, 정해둔 표현을 다른 단어로 바꾼 뒤 displayContent를 반환한다. 결과적으로 Claude의 실제 응답 저장 내용이 아니라 터미널에 보이는 텍스트만 바뀐다.
이 글은 가벼운 패러디지만 개발자들이 느끼는 피로를 정확히 찌른다. AI 코딩 에이전트는 코드만 쓰지 않는다. 설명, 커밋 메시지, 요약, 변명, 칭찬, 경고를 계속 쓴다. 특정 문체가 반복되면 사용자는 모델의 도움이 아니라 모델의 습관을 읽고 있다는 느낌을 받는다. Claude Code hooks reference는 MessageDisplay가 화면 표시 내용을 바꿀 수 있지만 메시지를 차단하거나 transcript 자체를 바꾸는 제어권은 없다고 설명한다. hooks guide와 settings 문서는 이런 훅이 설정 파일에 연결되는 방식을 다룬다.
프롬프트가 아니라 하네스가 제어하는 영역
중요한 점은 이 문제가 "Claude에게 그 표현을 쓰지 말라고 말하면 되지 않나"로 끝나지 않는다는 것이다. LLM은 확률적 시스템이고, 긴 작업 중에는 지시를 잊거나 다른 문맥에서 같은 말버릇을 되살릴 수 있다. 훅은 모델의 판단이 아니라 실행 계층의 규칙이다. 그래서 출력 필터, 포맷터, 보안 검사, 알림, 감사 로그 같은 기능은 프롬프트보다 훅에 더 잘 맞는다.
| 제어 대상 | 프롬프트 지시 | 훅·하네스 제어 | 권장 용도 |
|---|---|---|---|
| 말투와 톤 | 대체로 가능 | 표시 계층에서 보정 | 사용자별 UX |
| 코드 포맷 | 가끔 누락 | 저장 후 자동 실행 | 일관성 유지 |
| 위험 명령 | 설득될 수 있음 | 실행 전 차단 | 보안 정책 |
| 로그·감사 | 모델이 생략 가능 | 항상 기록 | 운영 추적 |
| 비용 제한 | 추정에 의존 | 호출 계층에서 제한 | 예산 관리 |
Short Leash의 Fable 코딩 방법, OfficeCLI 문서 에이전트, Claude Code 토큰 세금은 모두 같은 교훈을 준다. 에이전트를 믿는다는 것은 모델에게 더 긴 지시문을 주는 것이 아니라, 모델 밖의 작업대와 안전장치를 설계하는 일이다.
사용자 경험도 안전장치다
말버릇 치환은 보안 기능처럼 보이지 않지만, 실제로는 신뢰의 표면과 연결된다. 에이전트가 매번 과장된 확신이나 비슷한 문장으로 답하면 사용자는 중요한 경고도 소음으로 받아들인다. 반대로 출력 계층에서 톤을 절제하고, 위험한 작업에는 다른 시각적 표시나 확인 흐름을 줄 수 있다면 사용자는 더 빨리 판단한다. 이는 단순 미학이 아니라 장기 사용성의 문제다.
MessageDisplay 훅은 transcript를 바꾸지 않는다는 점도 중요하다. 표시와 기록을 분리하면 UX 실험을 하면서도 감사 가능한 원본을 남길 수 있다. 기업 환경에서는 화면에 보이는 민감어 마스킹, 내부 용어 치환, 경고 배너 삽입, 초보자용 설명 축약 같은 기능으로 확장할 수 있다. 단, 표시만 바꾸면 모델 자체의 행동은 바뀌지 않는다. 정책 집행에는 PreToolUse나 PostToolUse 같은 다른 훅과 권한 시스템이 필요하다.
한국 개발조직의 적용법
국내 개발팀은 AI 코딩 도구를 도입할 때 프롬프트 템플릿과 가이드 문서에 많은 시간을 쓴다. 그러나 반복되는 운영 요구는 훅으로 옮기는 편이 낫다. 예를 들어 파일 수정 뒤 포맷터 실행, 개인정보 패턴 탐지, 특정 경로 쓰기 차단, 사내 티켓 번호 확인, 배포 명령 전 확인은 모델의 선의에 맡길 일이 아니다. Davit와 Apple 컨테이너 개발자 UX처럼 도구 UX는 결국 작은 마찰을 어디에 배치하느냐의 문제다.
개인 개발자에게도 의미가 있다. 자기만의 출력 취향, 금지어, 요약 형식, 알림 방식을 훅으로 만들면 에이전트가 조금 더 자기 작업환경에 들어온다. 다만 이 글처럼 표시 텍스트만 바꾸는 훅은 재미있는 출발점일 뿐이다. 진짜 생산성은 테스트, 타입체크, 권한, 비용, 로그가 연결될 때 나온다.
자주 묻는 질문
Q1: MessageDisplay 훅이 Claude의 실제 답변을 바꾸나요?
A: 화면에 표시되는 delta를 바꿀 수 있지만 transcript나 모델에 저장되는 원문을 바꾸는 제어권은 없다. 그래서 UX 보정에 가깝다.
Q2: 말버릇 문제는 프롬프트로 해결하면 안 되나요?
A: 간단한 경우에는 된다. 하지만 반복적이고 일관된 제어가 필요하면 실행 계층의 훅이 더 안정적이다.
Q3: 기업에서 쓸 만한 훅 예시는 무엇인가요?
A: 위험 명령 차단, 비밀키 탐지, 포맷터 자동 실행, 테스트 강제, 감사 로그, 배포 전 확인, 사내 용어 표시 보정이 실용적이다.
Q4: 훅이 보안을 완전히 해결하나요?
A: 아니다. 훅은 강력한 통제점이지만 권한 설계, 샌드박스, 코드 리뷰, CI 정책과 함께 써야 한다.
Q5: 개발자에게 가장 중요한 교훈은 무엇인가요?
A: 모델에게 모든 규칙을 기억시키려 하지 말고, 반복되는 규칙은 도구 계층에 넣어야 한다. 에이전트 UX는 프롬프트와 하네스의 합이다.
📰 원본 출처
jola.dev이 기사는 AI 기술을 활용하여 작성되었으며, 원본 뉴스 소스를 기반으로 분석 및 해설을 추가한 콘텐츠입니다. 정확한 정보 전달을 위해 노력하고 있으나, 원본 기사를 함께 확인하시기를 권장합니다.