클로드 코드가 스스로를 조종하는 법, '시스템 리마인더'

클로드 코드(Claude Code)가 긴 작업 도중 스스로 방향을 고쳐 잡는 장치인 '시스템 리마인더(system reminder)'의 작동 원리를 해부한 글이 해커뉴스에서 다시 주목받고 있다. 에이전트 하네스 설계를 다루는 개발자 블로그 '/dev/michael'에 올해 3월 올라온 글로, 시스템 프롬프트가 대화가 길어지면 사실상 사라진다는 문제에서 출발해 '어디에, 언제, 무엇을' 끼워 넣어야 모델이 실제로 따르는지를 정리했다.

무슨 일인가 — 10만 토큰 뒤에 시스템 프롬프트는 없다

글쓴이의 출발점은 간단하다. 최신 모델은 에이전트 작업을 잘하지만 비결정적이라 쉽게 헷갈린다. 보안에 '다층 방어'가 있듯 긴 에이전트 흐름에는 '다층 지시'가 필요하다는 것이다. 시스템 프롬프트에 아무리 공들여 써도 10만 토큰짜리 대화 안에서는 사실상 증발한다. 그래서 하네스가 얼마나 잘 '조종'하느냐가 하네스 공학의 핵심 경쟁력이 된다.

조종 채널은 여러 층이다. 시스템 메시지가 세계관과 과제를 깔고, 사용자 메시지는 모델이 가장 집중하는 채널이다. 모델이 작업하는 동안 써 둔 메시지를 도구 호출 사이에 끼워 넣는 '대기 메시지'도 있고, 도구 결과에 지시를 얹는 방법도 있다. 문제는 이들 각각에 모델이 매기는 '신뢰 등급'이 다르다는 점이다.

핵심 짚어보기 — 신뢰 위계와 '강제보다 넛지'

모델은 시스템·사용자 메시지에는 높은 주의를 두고, 도구 응답은 외부 정보, 즉 잠재적 적대 입력으로 취급하도록 훈련돼 있다. 파일 안에 '이전 지시를 전부 무시하라'가 적혀 있다고 따르면 프롬프트 인젝션이 너무 쉬워지기 때문이다. 그렇다면 모델이 실제로 따르는 조종 문구는 사용자 메시지 자리에 넣어야 한다. 글쓴이가 소개하는 방식은 시스템 프롬프트에 'system-reminder 태그가 오면 따르라'고 미리 못 박고, 대화 중간에 그 태그를 단 메시지를 흘려 넣는 것이다. 모델은 태그를 보는 순간 시스템 프롬프트의 약속을 떠올리고, 이것이 읽은 파일이 아니라 하네스에서 온 지시임을 안다.

또 하나의 원칙은 '강제보다 넛지'다. 하드 블록과 엄격한 검증으로 행동을 고정하려는 본능이 있지만, 수백 단계 세션의 모든 경로를 설계자가 미리 모델링할 수는 없다. 넛지는 모델의 판단을 대체하지 않고 그 위에 얹히기 때문에 더 잘 작동한다. 파일을 조각조각만 읽는 버릇처럼, 늘 금지할 수는 없지만 고쳐 주고 싶은 '성향'이 바로 리마인더의 영역이다.

글쓴이는 이 패턴을 처음 제품에 실은 곳이 앤트로픽의 클로드 코드 팀으로 보인다고 썼다. 리마인더는 주기적이거나 고정된 문구가 아니라 대화 상태에 반응해 발사된다. 사용자의 UI 조작, 토큰 소비 급증, 컨텍스트 비대화 같은 조건이 트리거다. 하네스 생애주기 이벤트(세션 시작, 턴 시작, 도구 결과, 컨텍스트 압축 등)마다 평가 지점을 두면 '세 번 연속 도구 실패', '압축 후 파일 내용이 요약돼 사라졌을 수 있음' 같은 리마인더를 자동으로 띄울 수 있다.

1인기업 실전 적용 포인트

• CLAUDE.md에 규칙을 쌓지 말고 '트리거 + 한 줄'로 쪼개라. 긴 규칙 파일은 대화가 길어지면 잊힌다. 훅(hook)으로 '파일 쓰기 전' 같은 시점에 짧은 리마인더를 주입하는 쪽이 효과적이다.
• 자체 에이전트를 돌린다면 도구 결과에 지시를 섞지 마라. 모델은 그 자리를 의심하도록 훈련돼 있다. 지시는 사용자 메시지 슬롯으로, 외부 데이터는 도구 결과로 분리한다.
• 실패 카운터 하나만 달아도 품질이 오른다. 같은 도구가 3회 실패하면 '접근을 바꾸라'는 문구를 자동으로 넣는 식이다. 무한 재시도로 토큰을 태우는 사고가 줄어든다.
• 컨텍스트 압축 직후 리마인더는 필수. 요약된 파일 내용을 실제 내용으로 착각하는 오류를 막으려면 '다시 읽어라' 한 줄이 필요하다.

전망 / 주의점

하네스 공학의 승부처가 모델 선택이 아니라 '언제 무엇을 상기시키는가'로 옮겨가고 있다는 게 이 글의 메시지다. 다만 리마인더도 토큰이고, 너무 자주 띄우면 정작 중요한 것이 묻힌다. 리마인더가 많아질수록 신호 대비 소음이 커지므로, 발사 조건을 좁게 설계하는 정밀도가 곧 품질이다.

출처: /dev/michael (https://michaellivs.com/blog/system-reminders-steering-agents/)