🧭

운영 규칙을 에이전트에게 넣는 법

규칙집을 통째로 매번 읽히지 않고도, 필요한 순간에 필요한 만큼만 꺼내 쓰게 만드는 설계 패턴 — 상시(코어)·상황(전문)·경위 3층 + 트리거 라우팅.

LLM 에이전트(대화하며 스스로 판단해 작업을 수행하는 AI)에게 "이렇게 일해라"는 규칙을 계속 늘려가다 보면 두 가지 문제에 부딪힙니다. 하나는 규칙이 길어질수록 매 턴 참고하는 정보 창(컨텍스트, 한 번에 모델이 읽어들이는 분량)을 규칙만으로 잠식하는 문제, 다른 하나는 규칙이 많아질수록 "이 규칙이 지금 상황에 해당하는지"를 에이전트가 놓치는 문제입니다. 이 문서는 이 둘을 함께 푸는 설계 패턴을 다룹니다 — 특정 도구·제품 이름이 아니라 패턴 자체를 봅니다(경로·파일명은 전부 예시).

3층상시 · 상황 · 경위

5~7줄코어 요약 목표 길이

1턴트리거 매칭 시 전문 로드 시점

이 짝꿍에서 보는 것

상시 로드는 얇게, 상황별 본문은 트리거로 그때 불러오는 3층 구조
"이 상황이면 이 규칙" 트리거표를 만드는 법
문서로만 존재하는 권고형 규칙과, 자동으로 걸러내는 강제형 훅의 차이
이 구조가 흔히 깨지는 지점(함정) 5가지

문제

왜 규칙을 통째로 매번 읽히면 안 되나

가장 단순한 접근은 "규칙을 전부 적어서 세션이 시작할 때마다 통째로 읽힌다"입니다. 처음 규칙이 몇 개 안 될 때는 잘 됩니다. 문제는 규칙이 쌓일수록입니다.

① 비용 문제

규칙이 쌓일수록 상시 주입 분량이 늘어나, 매 턴 쓸 수 있는 예산(컨텍스트)을 규칙 그 자체가 잠식합니다. 정작 작업에 쓸 여유가 줄어듭니다.

② 적용 문제

규칙이 많아지면 지금 상황에 어떤 규칙이 해당하는지 에이전트가 놓칩니다. "있는데 안 걸리는" 규칙이 늘어나, 규칙집은 커지는데 실제 준수율은 그대로거나 떨어집니다.

비유: 신입 사원에게 사규집 300쪽을 첫날 다 외우게 하는 것과 같습니다. 웬만해선 다 못 외우고, 외운 것도 정작 필요한 순간에 어느 조항인지 못 찾습니다. 필요한 조항을 그 상황에서 바로 펼쳐볼 수 있게 만드는 편이 낫습니다.

그래서 답은 "규칙을 다 넣거나 다 빼거나"가 아니라 — 언제, 얼마나 넣을지를 설계하는 것입니다. 다음 절의 3층 구조가 그 답입니다.

설계

3층 구조 — 상시 · 상황 · 경위

규칙을 "얼마나 자주 읽히는가" 기준으로 세 층으로 나눕니다. 층이 다르면 담아도 되는 분량과 상세도도 달라집니다.

① 코어상시 로드

→

② 전문상황 주입

→

③ 경위보관 · 필요 시만

① 코어 요약 — 상시 로드

트리거 문구 + 핵심 행동을 5~7줄로 압축합니다. 세션이 시작될 때마다 항상 붙는 부분이라, 여기 넣는 만큼 매 턴 비용이 듭니다. 그래서 "무엇을 조심해야 하는지"만 담고, "왜·어떻게"는 다음 층으로 미룹니다.

② 전문 본문 — 상황 주입

트리거가 매치된 그 턴에 한해서만 통째로 불러 적용합니다. 예외 조건·경계 사례·근거까지 자세히 적어도 괜찮습니다 — 트리거가 안 걸리면 애초에 안 읽히니까요.

③ 경위 · 실증 — 보관층

이 규칙이 왜 생겼는지, 과거에 무엇이 깨져서 이 조항이 붙었는지를 기록합니다. 평소엔 안 읽지만, "왜 이 규칙이지?"를 물을 때 추적할 수 있게 남겨 둡니다.

층	예시 경로(가상)	언제 읽히나
코어	`rules/search.md`	세션마다 항상
전문	`rules-full/search.md`	"검색 실행 직전" 트리거 매치 시, 그 턴만
경위	`decision-log/search-tuning.md`	필요할 때 수동 조회(평소엔 안 읽음)

비유: 코어는 냉장고 문에 붙여둔 포스트잇(항상 보임, 딱 한 줄), 전문은 그 포스트잇이 가리키는 서랍 속 설명서(필요할 때 꺼내 읽음), 경위는 그 설명서가 왜 그렇게 쓰였는지 적힌 오래된 회의록(평소엔 안 열어봄)입니다.

라우팅

트리거표 — "이 상황이면 이 규칙"

코어 요약만으로는 "지금 어떤 전문 문서를 읽어야 하는지"를 알 수 없습니다. 그래서 상황과 규칙 파일을 잇는 트리거표(라우팅 인덱스)를 하나 둡니다. 매 응답 전에 이 표를 훑고, 걸리는 행이 있으면 그때 전문을 불러옵니다.

트리거 (이 상황이면)	규칙 파일(예시)	핵심 1줄
외부 채널에 응답을 보내려 함	`rules/comms.md`	정해진 발신 경로로만 — 화면 출력은 도달이 아니다
파일을 고친 뒤 "고쳤다"고 말하기 직전	`rules/code-quality.md`	재현 → 수정 → 증명 3단계를 거친다
검색이 실패했거나 빈손으로 돌아왔을 때	`rules/search.md`	같은 질의 반복 대신 표현을 바꿔 한 번 더
매 단계 확인을 묻고 싶을 때	`rules/autonomy.md`	파괴적·비가역적이 아니면 스스로 판단해 진행

표의 왼쪽 칸이 핵심입니다. "규칙 이름"이 아니라 상황 문구로 색인해야, 에이전트가 실제로 그 상황에 처했을 때 매칭됩니다. 규칙 이름을 안다고 상황을 알아채는 건 아닙니다.

함정: 상황 문구를 너무 좁게 적으면(예: 정확히 이 단어가 나올 때만) 같은 뜻의 다른 표현에서 매칭이 빠집니다. 정확한 문장이 아니라 상황군으로 적어야, 표현이 조금 달라도 걸립니다.

강제

권고형 규칙 vs 강제형 훅

트리거표가 잘 설계돼도 결국은 에이전트의 자체 판단(권고형, soft)에 기댑니다. 압박이 크거나 맥락이 복잡한 상황에서는 규칙을 알아도 놓칠 수 있습니다. 그래서 놓치면 대가가 큰 소수의 규칙은 문서가 아니라 훅(hook, 특정 시점에 자동으로 끼어드는 검사기)으로 감싸 강제합니다.

권고형 (문서만)

장점 — 유연하고 예외 판단이 가능합니다. 단점 — 압박·피로 상황에서 특히 놓칠 수 있습니다.

강제형 (자동 검사)

장점 — 기계적으로 걸려 놓칠 수 없습니다. 단점 — 유연성이 떨어져, 정말 필요한 예외까지 막힐 수 있습니다(별도 예외 통로가 필요).

훅은 보통 세 시점 중 하나에서 끼어듭니다.

① 실행 전위험 동작 직전 차단

→

② 실행 후결과 검사·흔적 기록

→

③ 응답 직전발신 전 최종 게이트

주의: 강제형 훅은 "이건 꼭 지켜야 한다"고 판단된 소수에만 씁니다. 전부 훅으로 두르면, 예외적으로 필요한 정상 동작까지 막혀버립니다 — 어디를 강제할지 고르는 것 자체가 설계 판단입니다.

함정

흔한 함정 5가지

① 오래된 규칙(stale): 도구나 모델이 바뀌었는데 규칙 문구가 예전 상태를 가정한 채 남아 있으면, 지키려 할수록 오히려 지금 기준에 안 맞는 행동을 하게 됩니다. 정기 점검 주기가 필요합니다.

② 트리거 문구 표류: 실제 발화가 트리거 문구와 미묘하게 다른 표현으로 나타나면 매칭이 빠집니다. "정확히 이 단어"가 아니라 "이 상황군"으로 적어야 합니다.

③ 코어가 비대해짐: 처음엔 한 줄이던 요약이 사례가 쌓일 때마다 조금씩 길어져, 결국 상시 로드 분량 자체가 규칙 더미가 되어버립니다. 늘어나면 그만큼 전문층으로 내려보내는 정리가 같이 있어야 합니다.

④ 죽은 포인터: 코어가 "전문 참고"라고 가리키는 문서가 지워지거나 옮겨졌는데 포인터만 남아 있으면, 트리거가 걸려도 실제로는 아무것도 안 읽힙니다.

⑤ 기입 주체 공백: "이 값을 누가, 언제, 어디에 적는가"가 규칙에 없으면 결국 아무도 안 적습니다. 규약에는 조건뿐 아니라 기입 주체·시점·자리까지 있어야 실제로 지켜집니다.

마무리

한 장 요약

한 줄: 규칙을 다 외우게 하지 않고 상시(코어 5~7줄) + 상황(전문, 트리거 매칭 시) + 보관(경위)의 3층으로 나누고, "상황 문구 → 규칙 파일" 트리거표로 그 순간 필요한 것만 불러옵니다. 놓치면 안 되는 소수는 문서가 아니라 자동 훅으로 강제합니다.

① 3층 분리 — 상시는 얇게(비용), 상황은 트리거로(적용), 경위는 보관만(추적).

② 트리거는 상황 문구로 — 규칙 이름이 아니라 "이럴 때"로 색인해야 매칭됩니다.

③ 강제는 소수에만 — 놓치면 대가가 큰 것만 훅으로 감싸고, 나머지는 판단에 맡깁니다.

④ 정기 점검 — stale·죽은 포인터·비대해진 코어는 저절로 안 고쳐집니다.

이 문서는 특정 시스템의 실제 이름·경로를 담지 않습니다. 경로·파일명은 전부 예시이며, 여기서 소개한 건 어떤 LLM 에이전트 운영 환경에도 옮겨 쓸 수 있는 설계 패턴입니다.

🧭 운영 규칙 설계 — 코어 · 트리거 · 훅 · 짝꿍 문서
내용 = 일반화된 설계 패턴(특정 시스템의 이름·좌표는 예시로만 표기)