AI 에이전트에게 「조직의 규칙」을 전달하는 인프라를 설계하다

「조직 고유의 규칙을 AI 에이전트에게 어떻게 전달할 것인가」를 해결하는 Rule Repository를 제창합니다. 규칙을 프롬프트 (Prompt)에 작성하는 방식은 확장성 (Scale)이 없습니다. RAG (Retrieval-Augmented Generation)라면 감사가 불가능합니다. 규칙 엔진 (Rule Engine)은 비엔지니어가 유지보수하기 어려울 것입니다. Rule Repository는 이 과제에 대해 자연어 규칙 + 하이브리드 평가 + MCP/API 네이티브 통합이라는 접근 방식으로 임합니다. 본 기사에서는 과제의 구조와, Agentic 시스템을 설계할 때의 아키텍처 (Architecture) 판단을 해설합니다.

레포지토리: https://github.com/shibuiwilliam/rule-repository

문서: https://shibuiwilliam.github.io/rule-repository/

git clone https://github.com/shibuiwilliam/rule-repository.git
cd rule-repository
cp .env.example .env # GEMINI_API_KEY 를 설정
...

http://localhost:3000 에서 UI, http://localhost:8000/docs 에서 API, MCP 는 stdio로 접속 가능합니다.

2026년 5월 현재, AI 에이전트는 코드를 작성하고, 메일을 보내고, 경비를 처리하며, 계약서 초안을 작성합니다. 하지만 이러한 에이전트들이 참조하고 있는 것은 학습된 일반 지식이며, 조직 고유의 규칙이 아닙니다. 물론 프롬프트로 정보나 규칙을 입력할 수는 있지만, 에이전트를 활용할 때마다 인간이 정보나 규칙을 제공하는 것은 번거로운 일일 것입니다.

어떤 회사에는 다음과 같은 규칙이 있을 것입니다:

• 「잔업은 월 45시간까지. 36협정 신고가 완료된 경우에만 예외」
• 「30% 이상의 할인에는 VP 승인이 필요」
• 「NDA 계약에는 반사회적 세력 배제 조항을 필수 사항으로 한다」
• 「공개 API의 엔드포인트에는 rate limit을 설정할 것」

이것들은 Confluence의 깊은 곳, 취업 규칙 PDF, Slack의 핀 고정, CLAUDE.md 등에 산재해 있습니다. 에이전트가 이것들을 구조적으로 참조하는 메커니즘이 필요하다고 할 수 있습니다.

개별 에이전트에게 개별 규칙을 프롬프트로 가르칠 수는 있습니다. 하지만 조직 규모 (Organization Scale)에서는 세 가지 이유로 파탄 납니다.

1. 규칙은 변한다. 프롬프트는 추종하지 않는다.

법 개정, 사내 규정 개정, 예외 조건 추가 등등 —— 규칙은 끊임없이 변화합니다. 10개의 에이전트가 동일한 규칙을 참조하고 있는 경우, 규칙 변경 시 10곳을 업데이트하는 운영은 파탄 납니다. Single Source of Truth (단일 진실 공급원)가 필요합니다.

2. 판정의 감사를 할 수 없다.

「왜 이 에이전트는 이 경비를 승인했는가?」에 답할 수 없습니다. LLM의 추론 과정은 재현 불가능합니다. LLM 요청을 기록하고 트레이스 (Trace)하는 도구 (LangSmith, LangFuse 등)는 있지만, 이는 범용적인 LLM 옵저버빌리티 (Observability)이며, 특정 규칙 관리와 적용에 적합한 것은 아닙니다. 규제 산업 (금융, 의료, 인사)에서는 이것은 치명적입니다.

3. 도메인을 넘나들 수 없다.

신규 거래처와의 계약에는 법무 (반사회적 세력 조항), 재무 (여신), 컴플라이언스 (FCPA), 영업 (지불 조건) 등, 여러 도메인의 규칙이 동시에 적용됩니다. 각 부문이 독립적으로 규칙을 관리하는 한, 횡단적인 판정은 인간의 머릿속에서만 이루어질 수밖에 없습니다.

거버넌스 (Governance)라고 하면 「규칙을 지킵시다」라는 조직론이 되기 쉽지만, 여기서의 과제는 순수하게 기술적인 것으로 파악합니다.

에이전트의 실행 경로 (Execution Path)에 조직 규칙을 저지연 (Low Latency)으로 주입하고, 판정 결과를 구조화하여 응답하며, 모든 판정을 감사 가능하게 기록하는 시스템을 어떻게 설계할 것인가?

이것이 Rule Repository가 해결하고자 하는 문제입니다.

규칙 레포지토리를 업데이트하면, 모든 에이전트가 다음 호출부터 새로운 규칙을 참조합니다. 프롬프트 10곳을 업데이트할 필요는 없습니다.

「왜 이 에이전트는 이 경비를 승인했는가?」→ 감사 로그에 「Rule #R-042 에 근거하여, 금액이 임계값 이하였기 때문에 ALLOW」라고 기록되어 있습니다.

에이전트의 판정을 인간이 수정했을 때, 그 차이 패턴이 새로운 규칙 후보로서 제안됩니다 (Correction Flywheel). 조직 지식이 자동으로 형식화되어 갑니다.

신규 거래 계약을 투입하면 법무·재무·컴플라이언스·영업의 모든 규칙이 한 번에 평가됩니다. 부서의 장벽을 넘는 판정을 API 한 번으로 얻을 수 있습니다.

Agentic 시스템을 설계할 때, 「규칙을 어떻게 다룰 것인가」에는 여러 가지 접근 방식이 있습니다. 각각을 비교 검토합니다.

System: 당신은 HR 에이전트입니다. 다음 규칙을 준 따르십시오:
- 잔업은 월 45시간까지
- 심야 근무는 관리직 이외 금지
...

과제:

프롬프트 (Prompt)에 주입할 경우, 컨텍스트 윈도우 (Context Window)를 압박하여 본래 태스크의 정밀도가 떨어질 가능성이 있습니다. 또한, 판정의 재현성이 없습니다 (프롬프트의 버전 관리가 필요해집니다). 그리고 도메인 횡단 (Cross-domain)이 불가능합니다 (모든 도메인의 규칙을 모든 에이전트에 넣는 것은 비현실적입니다).

relevant_rules = vector_search(query=user_input, collection="rules")
response = llm.generate(context=relevant_rules, query=user_input)

과제:

매번 검색하기 때문에 판정의 일관성이 보장되지 않습니다 (임베딩 (Embedding)의 근방이 변할 수 있습니다). 수치 비교를 LLM에게 시키게 됩니다 ("52 > 45 인가?"는 계산이지 추론이 아닙니다). 또한 「어떤 규칙에 근거하여 판정했는가」를 확정할 수 없으며 (검색 결과는 확률적입니다), 감사 (Audit) 시에 「동일한 입력을 넣었을 때 동일한 규칙이 선택되는가」를 보장할 수 없습니다.

allow {
input.overtime_hours <= 45
}
...

과제:

규칙의 소유자 (법무, 인사, 재무)가 형식 언어 (Formal Language)를 작성할 수 없습니다. 또한 자연어의 뉘앙스 ("합리적인 범위", "원칙적으로" 등)를 표현할 수 없으며, 규칙을 형식 언어로 번역 및 유지보수하는 비용이 너무 높습니다 (규칙 1건당 수 시간의 엔지니어 공수). 나아가 LLM과의 통합이 설계에 포함되어 있지 않기 때문에, 판정에 해석이 필요한 규칙을 다룰 수 없습니다.

설계 방침:

규칙은 자연어로 유지하여 규칙 소유자가 직접 관리할 수 있도록 합니다. 단, 구조적 메타데이터 (modality, severity, scope, kind)를 부여하여 검색·필터·디스패치 (Dispatch)에 활용합니다. 평가는 2층 구조로 구성하여, 계산으로 풀 수 있는 것은 결정론적 (Deterministic)으로 처리하고, 해석이 필요한 것만 LLM에 맡깁니다. 모든 판정은 위변조가 불가능한 감사 로그 (Audit Log)에 기록하며, 에이전트는 MCP / SDK / API를 통해 호출하므로 프롬프트에 주입할 필요가 없습니다.

여기서부터는 Rule Repository 설계에서 내린 판단과 그 근거를 해설합니다. Agentic한 소프트웨어 시스템을 만드는 소프트웨어 엔지니어 여러분께 참고가 되기를 바랍니다.

처음에는 모든 규칙을 LLM에 전달했습니다. 하지만 측정 결과, 전체의 약 40%는 수치 비교나 테이블 참조로 확정되는 판정이었습니다.

판단: 규칙에 kind 필드를 갖게 하여, 종류에 따라 평가 레이어를 전환합니다.

COMPUTATIONAL → asteval (샌드박스 수식 평가)
DEFINITIONAL → lookup table 참조
PROCEDURAL → state machine check
...

효과:

• COMPUTATIONAL 규칙은 p50 = 20ms로 판정 완료됩니다 (LLM은 1000ms 이상).
• 비용: 결정론적 판정은 $0입니다 (LLM은 $0.002/판정).
• 일관성: 결정론적 판정은 100% 재현 가능합니다.

교훈: Agentic 시스템에서는 「LLM에 던지기 전에 규칙 기반 (Rule-based)으로 해결할 수 없는가」를 항상 물어야 합니다. LLM은 최후의 수단이어야 합니다.

Gemini 3의 공식 문서에 「temperature를 낮추면 추론 품질이 저하되어 루프에 빠진다」는 기재가 있습니다. 실제로 0.2로 설정했더니 판정이 이상해졌습니다.

판단: temperature는 항상 기본값 (1.0)으로 합니다. 결정적인 답을 원한다면 LLM이 아니라 결정론적 레이어를 사용합니다.

교훈: LLM의 거동을 「파라미터로 제어하려고」 하는 것은 취약 (Fragile)합니다. 아키텍처 레벨에서 「LLM에게 무엇을 묻고, 무엇을 묻지 않을 것인가」를 설계하는 편이 더 견고합니다.

「왜 DENY 했는가」를 나중에 설명할 수 없는 시스템은 「규칙 관리」로서 불충분할 것입니다.

판단: 감사 로그(Audit log)는 append-only 테이블로 합니다. 각 행이 이전 행의 해시(Hash)를 포함하는 체인(Chain) 구조입니다. UPDATE/DELETE는 PostgreSQL 트리거(Trigger)를 통해 물리적으로 거부합니다.

CREATE TABLE audit_log (
id BIGSERIAL PRIMARY KEY,
prev_hash TEXT NOT NULL,
...

효과: 위조할 경우 체인(Chain)이 깨지므로 즉시 탐지할 수 있습니다. 증적(Evidence)으로 활용 가능합니다.

교훈: Agentic 시스템에서는 「에이전트가 왜 그 행동을 했는가」에 대한 설명 책임(Accountability)이 반드시 요구됩니다. 감사를 사후에 추가하는 것은 설계 난이도를 10배 높입니다. 처음부터 내장하십시오.

데이터 계층(Data layer)으로서 스토리지, PostgreSQL, Elasticsearch (검색), Neo4j (관계 그래프)를 사용하지만, 모두 PostgreSQL을 주(Main)로 하며 나머지는 파생 뷰(Derived view)입니다.

판단: 모순이 발생하면 PostgreSQL이 승리하며, 나머지를 재구축합니다. reconcile 스크립트로 Neo4j를 재생성하고, reindex로 Elasticsearch를 재생성합니다.

교훈: 복수의 데이터 스토어(Data store)를 사용하는 시스템에서는 「무엇이 진실인가」를 명시하는 것이 중요합니다. 그렇지 않으면 디버깅 불가능한 데이터 불일치에 빠지게 됩니다. 「Derived view는 깨질 수 있다. Source of Truth는 깨뜨리지 않는다」가 원칙입니다.

규칙은 effective_period.valid_until로 퇴역시키며, 물리 삭제하지 않습니다.

이유: 과거의 판정을 소급하여 설명할 필요가 있기 때문입니다. 「2025년 3월 시점에는 이 규칙이 유효했으며, 이 판정이 반환되었다」를 재현할 수 있어야 합니다.

교훈: 규칙/정책(Rule/Policy) 계열의 시스템에서 DELETE를 허용하면 과거 판정의 재현성이 상실됩니다. Soft delete가 아니라 「유효 기간의 종료」로 취급하는 것이 적절합니다.

response = client.generate_content(
contents=prompt,
config=GenerateContentConfig(
...

자유 형식(Free-form) 텍스트에서 정규 표현식으로 verdict를 추출하는 것은 너무 취약(Fragile)합니다.

교훈: LLM을 「API로서 사용」한다면, 응답은 항상 구조화된 출력(Structured output)으로 제약해야 합니다. 파싱(Parsing) 실패에 대한 핸들링 코드를 작성하는 시간보다 스키마(Schema)를 정의하는 시간이 더 짧습니다.

법무 고유의 로직(일본법의 조/항/호 파싱)이나 인사 고유의 로직(36협정 예외) 등을 코어 엔진(Core engine)에 넣으면, 각 계층의 관심사가 혼탁해져 유지보수가 어려워집니다.

판단: Domain Pack은 독립 패키지로 구성하며, 공통 인터페이스(_core)에만 의依存하게 합니다. 서버 내부 모듈을 import 하지 않습니다.

packages/domain-packs/
├── _core/ # manifest schema, base prompts
├── legal/ # 법무 고유 (프롬프트, 분석기, 템플릿)
...

효과: 서버 본체의 코드 변경 없이 새로운 도메인을 추가할 수 있습니다. 각 도메인의 전문가가 자신의 Pack만 유지보수할 수 있습니다.

교훈: Agentic 시스템이 복수의 도메인을 다루는 경우, 도메인 지식을 플러그인(Plugin)화하는 설계는 필수입니다. 코어가 모든 도메인을 알고 있는 설계는 금방 파탄 납니다.

REST API는 인간(프론트엔드)을 위한 것입니다. 에이전트를 위해서는 설계 단계부터 MCP (Model Context Protocol)를 포함합니다.

이유: MCP 대응 에이전트 (Claude Code, Cursor 등)가 늘어나고 있습니다. REST API를 MCP로 래핑(Wrap)하는 사후 통합보다, 처음부터 MCP를 설계에 포함하는 것이 에이전트 경험(Agent experience)을 더 좋게 만듭니다.

# 에이전트로부터의 이용 (MCP 경유)
verdict = await mcp_client.call_tool("evaluate_subject", {
"kind": "business_event",
...

교훈: 「에이전트가 사용하는 에이전트용 시스템」을 설계한다면, 에이전트의 통합 프로토콜을 처음부터 의식해야 합니다. 사후 통합은 「할 수는 있지만」 「사용하기 편한」 시스템이 되지는 않습니다.

AI 에이전트를 조직에 도입할 때, 많은 팀은 「에이전트의 똑똑함」에 집중하곤 합니다. 에이전트 아키텍처 (Agent Architecture), 프롬프트 튜닝 (Prompt Tuning), 도구 선택 (Tool Selection), 평가 벤치마크 (Evaluation Benchmark) 등등 말입니다. 하지만 그 이면의 병목 현상(Bottleneck)으로서, 에이전트가 참조하여 제어에 포함해야 할 규칙에 접근할 수 없다는 점이 항상 존재합니다.

Rule Repository는 이 과제에 대한 하나의 해결책을 제시하는 것을 목적으로 합니다.

• 규칙은 자연어로 유지하며, 구조화된 메타데이터 (Structured Metadata)로 검색 가능하게 한다
• 평가는 「규칙 기반 (Rule-based) → LLM」의 2단계 구성으로 하여, LLM을 최후의 수단으로 사용한다
• 모든 판정을 위변조가 불가능하게 기록하고, 설명 가능하게 (Explainable) 한다
• 도메인 지식 (Domain Knowledge)은 플러그인 (Plugin)으로 격리하여, 코어 (Core)를 가볍게 유지한다
• 에이전트 통합 (MCP)을 사후 적용이 아닌 설계 단계부터 포함한다

이러한 원칙들이 Rule Repository에 국한되지 않고, 에이전틱 (Agentic)한 시스템을 설계하는 엔지니어들에게 참고가 되기를 바랍니다.