#업무 규칙 준수, 시스템 프롬프트에 적어 두는 것으로 충분한가

← 전체 목차 · 이전: 사람의 확인 지점은 도대체 어디에 두어야 하는가 · 다음: 도구 결과가 충돌하면 누구 말을 들어야 하나

"규칙을 시스템 프롬프트에 적고, 모델에게 지키라 하고, 출력할 때 위반 여부를 검사한다"는 방안은 한 번 찔러보면 뚫리는 종이 방어선이다. 문제는 표현이 부족해서가 아니라, 규칙을 담을 곳을 애초에 모델의 컨텍스트로 골랐다는 것 자체에 있다. 컨텍스트는 용량이 유한하고, 주의력이 감쇠하고, 말솜씨로 밀어붙일 수 있다 — 강한 제약을 담기에 태생적으로 맞지 않는 그릇이다.

#규칙이 새는 다섯 지점

연성 이탈이 특히 위험하다. 규칙 조문 자체는 바뀌지 않았는데 모델이 화법에 밀려 스스로 기준을 낮추는 것이므로, 어떤 규칙 조항의 명시적 충돌도 트리거되지 않는다.

#독립 규칙 엔진 + 전치 검증 + 후치 차단

규칙 입력   →  구조화 분해: 조건 / 동작 / 우선순위 / 예외 상황으로
            →  실행 가능한 검증 로직으로 전환, Agent 실행 링크와 분리

실행 결정 전 →  규칙 엔진 검증을 거침
              ├─ 부합   → 실행 단계로 진입
              └─ 불부합 → 즉시 차단 + 수정 요구 반환 (실행 단계 진입 자체를 불허)

출력 결과 후 →  후치 합규 스캔 → 묵시적 위반 식별

전체 과정 우회 →  유도 이탈 식별 모듈: 규칙을 우회하려는 질문 패턴을 감지
                → 조기에 규칙 강화 트리거, 기준 완화를 금지

규칙 변경   →  시각화 설정 갱신 → 규칙 엔진에 자동 동기화
              → 프롬프트를 고칠 필요 없이 분 단위로 반영

설계 요점 세 가지: 실행 링크와 분리(규칙이 더 이상 모델 컨텍스트에 기생하지 않음), 전치 차단이지 사후 보완이 아님(불부합 결정은 애초에 실행 단계로 못 들어감), 갱신 경로가 프롬프트를 우회함(반영 주기가 "재작성+전량 회귀"에서 분 단위로 압축됨).

#자연어 규칙과 예외의 처리

마지막 행의 논리를 주목해야 한다. 프롬프트 방안이 부정된 것이 아니라 장애 강등 수단으로 강등된 것이다 — 이것이야말로 프롬프트 방안이 주 방안이 될 수 없음을 거꾸로 증명한다.

#핵심 통찰

1. 합규는 저장 문제이지 표현 문제가 아니다 — 후보자의 실패는 프롬프트를 잘 못 쓴 것이 아니라, 규칙을 담을 유일한 장소로 모델 컨텍스트를 골랐다는 데 있다. 저장 위치를 바꾸면(독립 규칙 엔진) 앞선 모든 추궁이 동시에 해소된다.
2. "모델이 말을 안 듣는다"는 근본 원인을 가리는 오귀인이다 — 이탈을 저장/실행 검증/갱신 세 단계의 메커니즘 결핍으로 쪼개야 한다. 원인을 모델로 돌리면 이후 동작은 모델 교체·온도 조정·강조 추가에 머물고, 링크로 돌려야 엔진·검증층·갱신 통로를 보강하는 쪽으로 간다.
3. 연성 이탈은 합규 설계에서 반드시 별도로 다뤄야 할 공격면이다 — 규칙 자체는 바뀌지 않았는데 모델이 화법에 밀려 기준을 스스로 완화한다. 규칙 조문 자체로는 이걸 잡을 수 없고, 질문 패턴에서 걸러내는 유도 이탈 식별 모듈이 있어야 한다.
4. 전치 차단과 후치 스캔은 성질이 다른 두 방어선이며 하나라도 빠지면 안 된다 — 전치 검증은 "잘못된 결정이 실행에 진입하지 못하게" 하고, 후치 합규 스캔은 "묵시적 위반을 식별"한다. 후자는 전치 규칙이 반드시 불완전함을 전제로 한다. 전치만 하면 표현 층위의 묵시적 위반을 놓치고, 후치만 하면 오류가 이미 발생한 뒤다.
5. 규칙 변경 속도가 아키텍처 선택을 결정한다 — 프롬프트 방안의 숨은 비용은 매 변경마다 전량 회귀 테스트를 해야 한다는 것이며, 반영 주기가 길다는 것 자체가 합규 리스크다(규칙은 바뀌었는데 시스템은 옛 규칙대로 돈다). 시각화 설정+자동 동기화로 반영을 분 단위로 압축하는 것이, 정확성과 변경 민첩성을 동시에 잡는 유일한 길이다.
6. 자연어 규칙은 "모델이 변환하고 사람이 검토한다"가 답이다 — 규칙 대형모델로 제도 텍스트를 구조화 규칙으로 바꾸는 것은 "코드로 직접 못 쓴다"를 풀고, 비기술 인력도 규칙 유지보수에 참여하게 한다. 사람 검토는 모델의 변환 오류가 곧장 온라인 규칙이 되지 않게 막는다 — 모델은 변환에만 쓰고, 준수에는 쓰지 않는다.
7. "엔진이 판정 못 하는 경우"와 "엔진이 죽은 경우" 각각에 길을 남겨야 한다 — 전자는 경계 상황을 자동으로 사람 검토로 승격(Agent 자율 판정 불허)이고, 후자는 프롬프트 강화+핵심 지점 사람 검토로 강등하며 고위험 업무를 일시 중단하는 것이다. 합규 체계의 성숙도는 흔히 이 두 안전망에서 갈린다.

#엔지니어링 실전 Tips

• 프롬프트를 강등 방안으로 자리매김할 것: 프롬프트 강화는 "규칙 엔진 장애"라는 조건에서만 등장한다. 평소에는 방어선이 아니고 장애 시에만 임시 방어선이라는 위치를 못 박으면 많은 설계 논쟁이 저절로 사라진다.
• "실행 단계 진입 불허"를 하드 제약으로 쓸 것: 전치 검증의 가치는 이 한마디에 다 있다. "검증 실패해도 로그만 남기고 계속 실행"으로 구현하면 엔진은 관찰자로 퇴화하고 프롬프트 방안과 본질적으로 다를 게 없어진다.
• 예외 상황은 별도 화이트리스트로, 메인 규칙 집합에 섞지 말 것: 예외가 메인 규칙에 섞이면 우선순위 판정과 규칙 가독성을 동시에 오염시킨다. 독립 화이트리스트라야 "이것은 예외다"라는 사실 자체가 감사 가능해진다.
• 규칙 갱신 반영 시간을 온라인 지표로 모니터링할 것: 이것은 효율 지표가 아니라 합규 지표다. 규칙은 이미 바뀌었는데 시스템이 아직 옛 규칙으로 도는 그 구간이 바로 노출 구간이다.
• 모델에게 "규칙 변환"을 맡기고 "규칙 준수"는 맡기지 말 것: 제도 텍스트를 구조화 규칙으로 바꾸는 것은 모델이 잘하는 생성 작업이며 사람 검토가 받쳐준다. 반면 준수는 확정적 제약이므로 엔진에 맡겨야 한다.
• 강등 시 업무 범위도 함께 줄일 것: 방안의 강등 동작은 제약 수단을 바꾸는 것만이 아니라 "고위험 업무 자율 실행 일시 중단"까지 포함한다. 제약 강도만 낮추고 업무 범위를 안 줄이면, 방어선이 얇아진 상태에서 노출 면적은 그대로 유지되는 셈이다.
• 경계 상황은 "Agent 자율 판정 불허"라고 명시적으로 써 둘 것: 모호한 영역이 가장 쉽게 "모델이 알아서 판단하게" 구현된다. 그것이야말로 이 논제가 애초에 부정한 경로다.