AI 작업 루프에 피드백을 심는 법
수정 요청이 생길 때마다 스킬이 똑똑해지는 구조를 만드는 아이디어와 그 함정.
Claude로 반복 작업을 할수록 같은 실수가 반복된다. 코드 스타일이 맞지 않거나, 커밋 메시지 형식이 틀리거나, 원하는 톤이 아니거나. 매번 고치다 보면 자연스럽게 드는 생각이 있다. “이 피드백이 자동으로 쌓이면 안 될까?”
아이디어: 수정 요청 → 스킬 자동 업데이트
구조는 단순하다. Claude가 결과물을 내놓고, 사용자가 수정을 요청하면 — Claude가 원인을 파악해서 해당 스킬 파일에 규칙을 추가한다. 의도가 불명확하면 되묻고, 명확해지면 기록한다.
반복되는 교정이 누적되면 스킬은 점점 정교해지고, 같은 실수는 줄어든다. 이론적으로는 깔끔하다.
실제로 구현하면 생기는 문제
Hook 타이밍이 맞지 않는다. user-prompt-submit hook은 Claude가 응답하기 전에 실행된다. “수정 요청”인지 판단하려면 이전 응답 맥락이 필요한데, shell hook에서 대화 맥락에 접근하는 건 제한적이다. stop hook — 응답 완료 후 실행되는 훅 — 이 더 적합한 시점이다.
자동 수정은 스킬을 망친다. 모든 수정 요청을 스킬에 넣으면 금방 비대해진다. 더 큰 문제는 원인 귀속이다. 문제가 스킬 부족 때문인지, 모델 추론 실수인지, 아니면 사용자의 기대치가 바뀐 건지 — 셋을 구분하지 않으면 잘못된 규칙이 쌓인다.
“수정 요청”과 “새 작업”의 경계가 모호하다. “이걸 바꿔줘”는 오탐하기 쉽다. 오탐 한 번이 스킬에 엉뚱한 규칙을 심는다.
더 안전한 구조
자동 적용보다 자동 감지 + 사람 확인이 현실적이다.
stophook에서 수정 패턴 감지- “이 내용을 스킬에 추가할까요?” 확인 요청
- 승인되면 스킬 파일 수정 + git commit
수정 내용을 세션 중 메모리에 쌓아두고, 세션 종료 시 일괄 검토하는 방식도 좋다. 스킬은 항상 git으로 추적해야 롤백이 가능하다.
핵심
피드백 루프는 강력하다. 하지만 자동화할 부분과 사람이 판단할 부분을 구분하지 않으면, 루프가 오히려 노이즈를 증폭시킨다. 스킬에 규칙을 추가하는 건 — 적을수록 좋다.