충돌은 예외가 아니다
Agent 운영에서 conflict는 예외가 아니라 기본 상태입니다. 사용자는 빠른 실행을 원하고, 정책은 보수적 판단을 요구합니다. 모델은 일반 지식을 말하고, 실제 파일은 다른 상태일 수 있습니다. 문서 A는 허용한다고 쓰고, 최신 약관 B는 금지한다고 말할 수 있습니다.
Conflict handling은 누가 이기는지 정하는 규칙입니다. 최신성 우선, 공식 출처 우선, 직접 관찰 우선, 사용자 승인 우선, 법적 제한 우선 같은 우선순위를 갖습니다. 모든 conflict를 모델이 자연어로 해결하게 두면 운영자가 나중에 이유를 추적하기 어렵습니다.
Normative Accumulation
Normative Accumulation은 규칙과 금지와 의무가 시간에 따라 쌓이는 과정을 관리하는 일입니다. 한 번 정책 문서를 읽었다고 끝나는 것이 아니라, 새 실패와 새 약관과 새 승인 기록이 계속 더해집니다. agent는 이 누적을 단순 메모로 두지 말고, 어떤 action에 어떤 제한이 붙는지 갱신해야 합니다.
근거는 항상 구체적이어야 하고, 가설 간의 관계는 항상 설명 가능해야 합니다. Finding은 역치를 제한해 오버피딩을 막아야 합니다. 작은 신호가 너무 쉽게 finding으로 승격되면 agent는 잡음까지 진실처럼 저장합니다. 반대로 충분한 finding이 쌓였는데도 절차가 바뀌지 않으면 학습하지 않는 agent가 됩니다.
Case: 광고 배치
광고 배치 agent를 생각해 봅시다. 사용자는 수익 극대화를 원합니다. 그러나 광고 플랫폼은 허용 크기, 클릭 유도 금지, 콘텐츠 가림 금지, 정책 위반 페이지 제한을 둡니다. 여기서 conflict는 수익 목표와 플랫폼 정책 사이에 생깁니다.
이때 agent에 넣을 데이터는 이런 식입니다. slotName, vendor, allowedSize, viewport, regionRule, policySource, lastCheckedAt, forbiddenStyling, clickInducementCheck, privacyNoticeUrl, servedContentProof. Guardrail은 단순히 '광고 조심'이 아니라 이렇게 다각적으로 저장된 정보를 보고 작동해야 합니다.
개발자가 달 guardrail은 명확합니다. 광고 단위 크기 allowlist, 모바일/PC 분기, 두 광고 네트워크 동시 호출 금지, CSS로 광고 꾸미기 금지, 광고 클릭 유도 문구 금지, privacy page 연결입니다. agent가 광고를 늘리려면 이 guardrail을 먼저 통과해야 합니다.
Case: 개인정보 CSV
두 번째 사례는 개인정보가 든 CSV 처리입니다. 사용자는 분석을 원하지만, 파일에는 이메일과 전화번호가 있을 수 있습니다. Agent는 먼저 schema를 읽고, 민감 필드를 분류하고, 마스킹 가능한지 확인해야 합니다. 외부 API로 보낼 때는 별도 승인과 최소화가 필요합니다.
이때 agent에 들어가는 데이터는 columnName, detectedType, sensitivity, retentionLimit, consentSource, maskingRule, exportAllowed, destination, approvalRequired, auditLogId처럼 쪼개집니다. Guardrail은 입력 단계부터 작동합니다. 민감정보 감지, 외부 전송 차단, 로그 마스킹, 보관 기간 제한, 결과물 공개 전 샘플 검토가 들어갑니다.
개발자의 자리
개발자는 prompt만 고치는 사람이 아니라 schema, validator, allowlist, denylist, approval UI, audit log를 모두 설계하는 사람입니다. Conflict가 생길 때 agent가 무엇을 보고 멈추는지 직접 정리해야 합니다.
법적 규제 준수는 guardrail의 최우선 목적입니다. 가드레일은 모델을 못 믿어서 다는 장식이 아니라, 자동화가 법적·정책적 선을 넘지 않게 하는 운영 구조입니다.
Taxonomy
- conflict taxonomy사실 충돌, 시간 충돌, 범위 충돌, 정책 충돌, 권한 충돌, 목적 충돌을 나눕니다.
- guardrail taxonomy입력 제한, retrieval 제한, action 제한, output 제한, escalation rule을 분리합니다.
- case structure taxonomy입력 case, action case, evidence case, approval case, remediation case를 따로 봅니다.
- developer control taxonomy프롬프트, schema, validator, allowlist, denylist, approval UI, audit log를 관리 지점으로 둡니다.
- incident taxonomynear miss, blocked violation, policy ambiguity, real failure, remediation을 사건 단계로 둡니다.
- normative accumulation taxonomy정책 문서, 실패 사례, 승인 기록, 금지 조건이 시간에 따라 쌓이는 방식을 봅니다.
- evidence threshold taxonomy가설, finding, accepted belief로 승격하는 근거 개수와 질을 따집니다.
- guardrail evidence taxonomy대상, 조건, 근거, 차단 사유, 재검토 조건을 guardrail 판단 근거로 둡니다.
- data handling taxonomy원본 데이터, 파생 데이터, 외부 전달, 보관, 삭제를 action risk로 나눕니다.
- remediation taxonomy중단, rollback, rule 추가, human review, regression test를 복구 절차로 둡니다.