AKwiki — 오픈카톡 대화를 일간 위키·기사로 바꾸는 커뮤니티 지식화 사례 화면

AI 커뮤니티(개인 개발) · 민간(참고) · 공통·범용 · 2026-08-27 게시

AI 커뮤니티 오픈카톡방들(3,700여 명 규모)의 대화를 주기적 '대화 내보내기' 자동화로 수집해, Obsidian과 AI 에이전트로 익명 인사이트 위키·1면 기사·이슈 분석·참여 네트워크·AI 검색까지 일간 발행하는 사이트. 흘러가는 채팅 지식을 보존·구조화하는 커뮤니티 지식화 패턴의 정교한 참고 사례로, 공공AX 커뮤니티의 대화 축적·아카이빙 운영에 그대로 응용할 수 있는 모델이다.

상세 정보

사례 성격
참고
출처 채널
오픈채팅
수집일
2026-08-28
태그
#커뮤니티위키 #지식관리 #익명화 #자동발행
실행 환경
브라우저만
망 요건
인터넷 필수
링크 점검
정상 (2026-11-02)

4축 평가

AX 단계AI-Enabled
업무 범위S2 Tool bundle
업무 완결성C2 부분 완결
권한(P축)P1 산출물 생성(잠정)
위험도R1 낮음
인간 통제해당 없음
증거 등급E1 코드·도구 확인
신뢰도중간

대화 수집→익명화→위키·기사·네트워크 분석→일간 발행의 전 과정을 에이전트 파이프라인으로 완결(C2)한 커뮤니티 지식화 모델 — 라이브 일간판으로 확인. 공공 업무 사례는 아니어서 참고 분류이나, 커뮤니티 지식 보존이라는 공공AX 운영 과제에 직접 이식 가능한 패턴 가치가 크다.

디자인 패턴 분석

『모두의 공공AX 디자인 패턴』 카탈로그 v0.7.1 기준 — 사례를 기관이 함께 쓰는 AI 부품과 그 조립으로 읽은 결과입니다. · 패턴 성좌에서 전체 보기 ↗

업무 패턴 B6 에이전트 오케스트레이터 보조 B7 콘텐츠 생성기 변형: 오케스트레이션

서비스 유형 9 인수인계·지식 보존 · 전이 단계 개인 사용 · 판정 카탈로그 v0.6

환경 축 배포:인터넷망 네트워크:인터넷 필수 모델:미확인 런타임:서버 구축 권한:P1 산출물 생성

이 사례의 패턴 구성도 — 층별 부품과 배선서비스 블록업무 컴포넌트제어 흐름공통 서비스운영D8.7D8.7 인수인계·지식…B6 · 주 패턴B6 에이전트 오케스트…B7B7 콘텐츠 생성기B′3B′3 병렬 팬아웃·수집B′1B′1 순차 파이프라인B′+B′+ 기억 관리A1A1 데이터 자산 서비스C5C5 가드레일 필터C8 · 보완 필요C8 권한 경계·킬스위치
패턴 구성도 — 층별 부품과 배선. 실선은 확인된 부품, 점선은 계획, 회색 점선은 보완이 필요한 필수 부품. 부품을 누르면 아래 상세로 간다.
제어 흐름(B′)
B′3 병렬 팬아웃·수집 B′1 순차 파이프라인 B′+ 기억 관리
공통 서비스(A)
A1 데이터 자산 서비스
운영(C)
C5 가드레일 필터
신뢰할 수 없는 입력
오픈카톡 대화 원문(외부 참여자 작성)
서비스 블록(D)
D8.7 인수인계·지식 보존
부품 배선
A1 → B6 · B6 → D8.7 · B6 → C5
참조 구현 후보
C5 가드레일 필터 흘러가는 채팅 지식을 익명화해 보존하는 커뮤니티 지식화 패턴이 공공AX 커뮤니티 아카이빙 운영에 참고될 만하다

판정 근거

오픈카톡 대화를 정기 자동화로 수집해 익명 인사이트 위키·1면 기사·이슈 분석·참여 네트워크·AI 검색까지 일간 발행하는 사이트로, 수집·익명화·구조화·기사작성·분석이라는 복수 역할이 나뉜 다중 에이전트가 협업해 B6(secondary B7 콘텐츠 생성)로 판정했다. '익명 인사이트'라는 명시적 익명화 처리가 C5 present에 해당한다. 흘러가는 채팅 지식을 보존하는 커뮤니티 지식화 패턴은 공공AX 커뮤니티 아카이빙 운영에 그대로 참고할 수 있다.

구현 가이드

주 패턴 B6 에이전트 오케스트레이터을 구현할 때

구현 단계

  1. 업무를 도구 목록으로 나누고 도구마다 읽기/쓰기, 되돌리기 비용을 적어 C8 권한표를 먼저 만든다.
  2. 단일 에이전트 + ReAct 루프(B′7)로 시작해 C9 평가 세트로 재고, 하위 작업이 분리될 때만 B′4·B′3으로 승급한다.
  3. 신뢰 불가 입력(외부 문서·API 응답)을 읽는지 확인하고, P2 이상이면 S5 계획 고정 또는 S6 격리를 설계한다.
  4. 단계 상태·되돌림(C3), 호출 추적(C4), 되돌리기 어려운 조치 앞 확인(F6)을 붙인다.
  5. 모델 장애 대비 C7과 킬스위치를 시험하고 결정적 재생(S10) 기록을 남긴다.

점검표

환경 조건

E3 MCP·CLI. E1 폐쇄망이면 A8 로컬 MCP 호스트 + A2 로컬 모델 변형만 가능하다. E2 해외 상용 API면 A2 게이트웨이 + C7 + C8 도구별 승인. E4가 P2 이상으로 올라가기 가장 쉬운 부품이라 C2·C3·C4·C8 킬스위치가 필수이며, 신뢰 불가 입력 + P2 이상이면 S5 또는 S6 + S9가 필요하다(§5 매트릭스).

주의할 점

기본 배선 예

A8 → B6 (B′7 · B′3) → C8 → C4 · B6 → F6 (실행 전 확인)

보완이 필요한 필수 부품

이 조합에서 카탈로그가 함께 갖추라고 권하는 부품 가운데 아직 확인되지 않은 것이다.

피해야 할 안티패턴

관련 가이드라인

이 사례가 쓰는 부품과 이어지는 공공 AX 안내서·지침이다 (부록 E 공공 AX 가이드라인 문서 해설 기준, 겹치는 부품이 많은 순).

같은 주 패턴(B6)을 쓰는 다른 사례

같은 업무 패턴으로 조립된 사례를 서비스 유형이 같은 것부터 모았다 외 2건. 구현할 때 비교해 볼 수 있다.

이 사례에 쓰인 패턴

B7 콘텐츠 생성기 업무 컴포넌트

영상·카드뉴스·교육자료·정보지·기사처럼 산출물 자체가 콘텐츠인 것을 AI가 만들고, 사람이 검수·편집해 발행한다.

PAX 사례 12건이 이 부품을 쓴다

맥락

보도자료·정책 홍보·교육자료·정보지 발간(유형 ⑥)에 쓴다. 공개(O) 자료가 대부분이지만 이미지 생성 등에서 해외 상용 API 의존이 강하다. 커뮤니티 대화를 정기 요약해 위키·기사로 발행하는 파이프라인도 이 부품의 변형이다(R25).

맞서는 힘(긴장)

  • 제작 속도 vs 사실·저작권 검수
  • 기관 톤 일관성 vs 매번 새로운 표현
  • 해외 상용 생성 API 품질 vs 벤더 의존

해법

주제·원자료·톤 가이드를 입력으로 받아 계획을 먼저 세우고(B′8) 대본·이미지·기사 초안을 만든 뒤, 형식 기준에 맞을 때까지 반복 개선한다(B′6). 기관 문체·표현 윤리는 A9 스타일 스킬로 고정하고, 보도자료 같은 공공 문서 입력은 A10으로 받는다. C5 저작권·사실검증과 C1 검수를 거쳐 사람이 발행하며, 이용자는 여러 안과 부분 재생성(F3)으로 결과를 고른다.

이럴 때 쓴다

  • 콘텐츠 자체가 최종 산출물이고 반복 제작이 병목일 때
  • 기관 스타일을 스킬로 정리할 수 있을 때
  • 유형 ⑥ 정책·홍보 콘텐츠 제작

이럴 때는 쓰지 않는다

  • 내부 기안·보고서 초안이면(B1)
  • 규정에 근거한 답변이 핵심이면(B3)
  • 사실검증·검수 인력이 없어 공개 전 확인을 할 수 없을 때

얻는 것

  • 제작 시간 단축(보도자료 → 카드뉴스 15분)
  • 외주 의존 감소
  • 기관 템플릿으로 공유 가능

점검표

  • 기관 스타일 규범이 스킬로 분리되어 있는가
  • 발행 전 사실·저작권 검수가 운영되는가
  • 반복 개선에 최대 반복 횟수가 있는가
  • 이용자가 일부만 다시 만들 수 있는가(F3)

구조 — 참여 부품

  • A9 업무 규범 스킬 — 기관 스타일·표현 윤리 규범
  • A2 모델 서빙 계층 — 텍스트·이미지 생성 모델
  • C5 가드레일 필터 — 저작권·사실검증
  • C1 검토 큐 — 발행 전 검수
  • 홍보·발간 담당자 — 편집과 발행 결정

변형

  • 홍보물 생성: 카드뉴스·영상 등 홍보 콘텐츠(정의에 열거된 산출물)
  • 발간물·정보지 생성: 정보지·기사 등 발간 콘텐츠(정의에 열거된 산출물)
  • 교육자료 생성: 교육용 자료 제작(정의에 열거된 산출물)
  • 커뮤니티 지식화: 오픈채팅·게시판 등 비정형 커뮤니티 대화를 정기 자동 요약·익명화해 위키·기사로 발행(R25)

참조 구현 예

  • PAX ReleasePick — 보도자료 → 카드뉴스 15분, HWPX 보도자료 입력(카드 참조 구현)
  • PAX Public Cardnews — 카드뉴스 스킬(카드 참조 구현)
  • PAX 9e0778df3c0ad630 — 오픈카톡 대화를 위키·기사·이슈분석으로 구조화, B7-c 참고 모델(§13)

관련 부품

A9 끼울 자리 — 스타일 스킬 · F3 이용자 쪽 대응 — 결과 대안·부분 재생성 · B′6 배선 — 형식 목표까지 반복 개선 · B′8 배선 — 기획 먼저, 제작은 순서대로 · S8 보안 짝 — 독립 검증기

참고 자료

GoF Builder·Template Method · InfoQ Iterative Exploration

이 부품과 이어지는 가이드라인

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

B6 에이전트 오케스트레이터 업무 컴포넌트

역할을 나눈 LLM들이 도구를 호출하며 계획을 세우고 다단계 업무를 이어 가며, 사람은 승인과 예외 처리를 맡는다.

PAX 사례 15건이 이 부품을 쓴다

맥락

여러 시스템·도구(A8 MCP·API·문서)를 오가는 다단계 업무, 데이터 조회·분석 에이전트(유형 5b), 망분리 환경의 로컬 MCP 호스트에 쓴다. 하위 작업이 실제로 분리되거나 AI가 도구를 골라야 할 때만 해당한다.

맞서는 힘(긴장)

  • 자율성 vs 권한 통제(P2 이상에서 C8 필수)
  • 멀티에이전트의 분업 vs 조정 비용·충돌(X11)
  • 도구 출력 활용 vs 도구 출력 속 지시가 명령이 되는 위험(X13)
  • 탐색적 유연성 vs 재생·감사 가능성

해법

목표와 도구 목록(A8 MCP·API)을 받아 AI가 계획을 세우고 도구를 골라 호출하며, 필요하면 하위 전문 에이전트에 위임한다(B′4·B′7·B′8). 단일 에이전트에서 시작해 하위 작업이 분리될 때만 계층·병렬로 승급한다. 도구별 읽기/쓰기 권한과 실행 승인은 C8로, 단계 상태와 되돌림은 C3로, 모든 호출은 C4 추적 로그로 남긴다. 신뢰 불가 입력을 읽는 경우 S5 계획 고정이나 S6 격리로 도구 출력이 새 행동을 끼워 넣지 못하게 하고, 되돌리기 어려운 조치 앞에는 F6 확인을 둔다.

이럴 때 쓴다

  • 한 건의 처리가 여러 시스템 조회·작성·검증에 걸쳐 있고 AI가 도구 순서를 골라야 할 때
  • 하위 작업이 실제로 분리되거나 컨텍스트 창이 부족할 때
  • C8·C3·C4 통제를 함께 갖출 수 있을 때

이럴 때는 쓰지 않는다

  • 단계 순서가 고정된 파이프라인일 때(B′1을 가진 B1·B4)
  • 실제 흐름이 초안 → 사람 확정일 때(B1)
  • 스케줄러·크롤러 수준 자동화일 때(agent_system=true라도 B6 아님)
  • 단일 에이전트가 되기 전에 멀티에이전트부터 만들려 할 때(X11)

얻는 것

  • 여러 시스템을 오가는 업무 흐름 자체를 재설계
  • 도구 교체로 다른 기관이 그래프를 재사용 가능
  • First 지향 구조

점검표

  • 복수 LLM 역할·도구 호출 루프·AI의 계획 선택이 실제로 있는가(R2)
  • 도구별 읽기/쓰기 권한과 실행 승인이 명시되어 있는가
  • 모든 도구 호출이 추적되는가
  • 도구 출력이 새 행동을 촉발하지 못하게 막는 구조가 있는가

구조 — 참여 부품

  • 계획·감독 에이전트 — 목표를 쪼개고 도구·하위 에이전트를 선택
  • 전문 하위 에이전트 — 조회·작성·검증 등 역할별 수행
  • A8 MCP 서버·호스트 — 도구 인터페이스와 레지스트리
  • C8 권한 경계·킬스위치 — 도구별 권한·실행 승인·즉시 중단
  • C4 감사 로그·지표 — 호출 추적
  • 담당자 — 승인 관문과 예외 처리

변형

  • 멀티에이전트 오케스트레이션: 감독자가 역할별 에이전트에 일을 맡기고 결과를 합친다
  • 관문 내장형(스테이지-게이트): 파이프라인 안에 사람 승인 관문이 여럿 있다(R2)
  • 단일 에이전트 도구 연쇄: 하나의 에이전트가 계획하고 여러 도구를 호출한다(R2)
  • 자가검증 루프 내장: 실행 결과를 스스로 검증하고 재시도한다(R2)
  • 로컬 MCP 호스트: 망분리 환경에서 도구별 위험도·실행 승인·감사 대시보드를 갖춘다(E1 폐쇄망이면 이 변형만 가능)
  • 시뮬레이션: 여러 에이전트로 정책·여론 등을 모의 실행한다
  • 에이전트 함대 오케스트레이션: 한 사람이 다수의 독립 코딩 에이전트를 병렬로 지휘하고 일을 배정·수합한다(R25)

참조 구현 예

  • PAX 망분리 환경용 로컬 AI 에이전트 + KOSIS 공식 MCP — 로컬 MCP 호스트, 도구별 위험도·실행 승인·감사 대시보드(§9)
  • PAX MOPAN — RAG·MCP·워크플로 조합 바탕 시스템(카드 참조 구현)
  • PAX c54ee4b5fb3ee4c5 — Orca ADE — 여러 코딩 에이전트 병렬 지휘, B6-f 해외 참고(§13)

관련 부품

C8 필수 통제 — 도구별 권한·실행 승인 · A8 끼울 자리 — MCP 도구 · B′4 기본 배선 — 계층 분해·감독자 · B′7 시작 배선 — 단일 에이전트 ReAct에서 승급 · S5 보안 짝 — 계획 고정으로 도구 출력 인젝션 차단 · F6 이용자 쪽 대응 — 에이전트 행동 확인

참고 자료

Google ADK 8패턴 · Gulli ch.7 Multi-Agent·ch.6 Planning·ch.2 Routing · Springer Supervisor/Collaboration · GoF Mediator, Microservice Aggregator

이 부품과 이어지는 가이드라인

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

B′3 병렬 팬아웃·수집 제어 흐름

의존성 없는 하위 작업을 동시에 돌리고 결과를 취합하는 배선이다. 구획형은 서로 다른 부분을, 투표형은 같은 작업을 여러 번 돌려 다수결로 합친다.

PAX 사례 8건이 이 부품을 쓴다

맥락

다중 출처 검색, 여러 후보 생성 방법의 병렬 적용, 같은 추출을 여러 번 돌려 다수결하는 앙상블에 쓴다. B6 로컬 호스트 변형(유형 5b)이 이 배선을 쓰고, S6 맵리듀스는 이 원형의 격리·보안형이다.

맞서는 힘(긴장)

  • 지연 단축·관점 다양화 vs 호출 수·비용 증가
  • 취합 규칙의 단순함 vs 결과가 엇갈릴 때의 판정 기준
  • 하위 작업 독립성 가정 vs 실제로는 의존이 있는 경우

해법

작업을 서로 의존하지 않는 하위 작업으로 나눠 동시에 실행하고, 결과를 결정적 규칙이나 합성 단계로 취합한다. 구획형은 하위 작업마다 다른 출처·관점을 맡기고, 투표형은 같은 작업을 여러 번 돌려 다수결·일치 여부로 신뢰도를 정한다. 결과가 엇갈리면 보류해 사람에게 보낸다. 신뢰 불가 문서를 다룬다면 문서마다 격리 인스턴스를 두고 규칙으로 합쳐 S6으로 만든다.

이럴 때 쓴다

  • 하위 작업이 진짜로 독립일 때
  • 병렬화가 지연을 의미 있게 줄일 때
  • 단일 실행의 우연한 오류를 다수결로 줄여야 할 때

이럴 때는 쓰지 않는다

  • 하위 작업이 서로의 결과에 의존할 때(B′1·B′8)
  • 호출 비용을 늘릴 여유가 없을 때
  • 단일 에이전트가 아직 제대로 동작하지 않을 때(X11)

얻는 것

  • 지연 단축
  • 다관점·다출처 결과
  • 다수결로 우연한 오류 감소

점검표

  • 하위 작업이 서로 독립인가
  • 취합 규칙과 불일치 처리 규칙이 정의되어 있는가
  • 병렬화로 얻은 지연·품질 이득을 쟀는가

구조 — 참여 부품

  • 분배기 — 하위 작업으로 나눠 동시에 실행
  • 하위 작업 실행기 — 출처·관점·방법별 처리
  • 수집기 — 규칙·다수결로 취합하고 불일치 건 보류

변형

  • 구획(Sectioning): 서로 다른 부분 작업을 병렬로 돌린다(UrbanLaw 5인 AI 패널)
  • 투표(Voting): 같은 작업을 여러 번 돌려 다수결로 정한다

참조 구현 예

  • UrbanLaw 5인 AI 패널 — 구획형(카드)

관련 부품

S6 격리·보안형 — 격리 LLM·맵리듀스 · B′4 이웃 — 계층 위임 · B6 배선 자리 — 유형 5b 로컬 호스트 변형 · B3 다중 출처 접지(UrbanLaw 5인 AI 패널)

참고 자료

Google ADK #3 Parallel Fan-out · Gulli ch.3 Parallelization · Heiland Microservice Horizontal · adaptive.live 병렬화(구획·투표)

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

B′1 순차 파이프라인 제어 흐름

한 단계의 출력을 다음 단계의 입력으로 넘기는 고정 순서 배선이다. 한 프롬프트에 많은 일을 몰아 시켜 품질이 떨어지는 문제를 막는다.

PAX 사례 109건이 이 부품을 쓴다

맥락

B4 인식 파이프라인의 기본 배선이며, B1·B0·B5 안에서도 흔하다. 단계 순서가 업무 절차로 미리 정해져 있고 AI가 순서를 고를 필요가 없을 때 쓴다.

맞서는 힘(긴장)

  • 디버깅·출처 추적의 쉬움 vs 병렬화 불가로 인한 지연
  • 단계 분리의 품질 이점 vs 단계가 늘수록 오류 누적
  • 고정 순서의 예측 가능성 vs 예외 경로 처리의 경직성

해법

업무 절차를 단계로 나누고 각 단계의 입력·출력 형식을 정해 앞 단계 출력을 다음 단계에 넘긴다. 단계 사이에 형식 검증(스키마)을 두어 오류가 번지기 전에 멈추고, 멈춘 건은 C1 검토 큐나 C3 재처리로 보낸다. 판정·산수 단계는 가능한 한 규칙(B′9)으로 두고 모델은 추출·서술 단계만 맡긴다. 단계 순서를 AI가 바꿔야 한다면 B′8이나 B′7로 옮긴다.

이럴 때 쓴다

  • 업무 절차가 고정 순서로 정해져 있을 때
  • 각 단계를 따로 검증·추적해야 할 때(유형 ② 접수·심사, ⑧ 취합·변환)
  • 단일 에이전트에서 시작하는 첫 배선일 때

이럴 때는 쓰지 않는다

  • 하위 작업이 서로 독립이라 동시에 돌려야 지연이 줄 때(B′3)
  • 입력에 따라 AI가 다음 도구를 골라야 할 때(B′7)
  • 긴 업무를 계획부터 세워야 할 때(B′8)

얻는 것

  • 디버깅과 출처 추적이 쉬움
  • 단계별 품질 검증 가능
  • 구현이 가장 단순

점검표

  • 단계마다 입력·출력 형식이 정의되어 있는가
  • 단계 사이 검증에서 실패하면 멈추는가
  • 단계별 중간 결과를 추적할 수 있는가

구조 — 참여 부품

  • 단계 처리기 — 각 단계에서 추출·변환·작성 수행
  • 단계 간 형식 검증 — 다음 단계로 넘기기 전 스키마 확인
  • C3 상태 머신·롤백 — 실패 단계 재처리

관련 부품

B4 기본 배선 — 인식 파이프라인 · B′8 대안 — 순서를 계획으로 정할 때 · B′9 짝 — 판정 단계를 규칙으로 · C3 기록처·되돌림 — 실패 단계 재처리

참고 자료

Google ADK #1 Sequential · Gulli ch.1 Prompt Chaining · Heiland Multi-layer · adaptive.live 프롬프트 체이닝

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

B′+ 기억 관리 제어 흐름

세션 안의 맥락과 세션을 넘는 장기 기억을 유지하는 배선이다. 공공에서는 개인정보 축적과 직결되므로 등급·비식별 없이 장기 기억을 두지 않는다.

PAX 사례 15건이 이 부품을 쓴다

맥락

다회차 상담, AI 코딩 지원처럼 이전 결정·서식을 이어 써야 하는 업무에 쓴다. S3 컨텍스트 방화벽은 이 원형을 의존 대상으로 두고, 이용자 쪽 면은 F8 대화 이력·되돌리기다. 사건 기록은 C4가 맡는다.

맞서는 힘(긴장)

  • 맥락 유지로 인한 효율 vs 개인정보·등급 정보 축적
  • 장기 기억의 편의 vs 기억 오염(잘못된 기억의 재사용)
  • 토큰 절약 vs 요약 과정의 정보 손실

해법

세션 기억과 장기 기억을 구분하고, 장기 기억에 넣을 항목(결정·제약·서식 프로필 등)을 명시적으로 정한다. 저장 전 E5 등급을 확인하고 C5로 비식별하며, 기억은 신뢰 구역을 분리해(S3) 지시와 섞이지 않게 한다. 보관 기간과 삭제·열람 경로를 두어 이용자가 F8로 확인·되돌릴 수 있게 하고, 사건·처리 기록은 기억이 아니라 C4에 남긴다.

이럴 때 쓴다

  • 다회차 업무에서 이전 결정·제약을 이어 써야 할 때
  • 같은 맥락을 반복 주입해 비용·지연이 커질 때(§7.5)
  • 비식별과 보관 규칙을 운영할 수 있을 때

이럴 때는 쓰지 않는다

  • E5 S 이상 정보를 비식별 없이 저장해야 할 때
  • 처리 이력·감사 기록이 목적일 때(C4)
  • 단발성 질의응답일 때

얻는 것

  • 토큰 낭비 감소
  • 맥락 상실 방지
  • 서식·결정의 재사용

점검표

  • 장기 기억에 들어가는 항목이 명시되어 있는가
  • 저장 전 비식별이 되는가
  • 보관 기간과 삭제 경로가 있는가
  • 기억이 지시와 구분된 구역으로 주입되는가

구조 — 참여 부품

  • 기억 저장소 — 세션·장기 기억 보관(로컬 저장 등)
  • C5 가드레일 필터 — 저장 전 비식별
  • S3 컨텍스트 방화벽 — 기억 구역을 지시와 분리
  • F8 대화 이력·되돌리기 — 이용자가 이력 열람·되돌리기

변형

  • 세션 기억: 한 세션 안의 대화·작업 맥락을 유지한다
  • 장기 기억: 세션을 넘어 결정·제약을 저장하고 다음 세션에 되읽는다(MCP 메모리 서버 등)
  • 서식 기억: 읽어 둔 기관 서식을 프로필로 캐시해 재사용한다

참조 구현 예

  • PAX 17ed2d7a88c03119 — 기관 서식을 프로필로 캐시해 재사용하는 서식 기억(§13)
  • PAX c483c6ad4ccff0ab — 세션 종료 훅으로 결정·제약을 로컬 SQLite에 저장하고 다음 세션에 되읽는 MCP 메모리 서버(§13 A8)

관련 부품

C5 필수 전제 — 비식별 · S3 보안 짝 — 기억 구역 분리 · F8 이용자 쪽 대응 — 대화 이력·되돌리기 · C4 경계 — 사건 기록은 C4 · A8 메모리 서버를 MCP 도구로 제공

참고 자료

Gulli ch.8 Memory · Towards AI #6 · aiux Thread History

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

A1 데이터 자산 서비스 공통 서비스

흩어진 업무 기록을 정제·라벨링해 AI 부품이 붙여 쓸 수 있는 데이터셋·라벨·데이터 사전 형태의 기준선으로 제공한다.

PAX 사례 110건이 이 부품을 쓴다

맥락

학습 모델(A2.5·B2), 지식 접지(B3)의 코퍼스, 평가 세트(C9)의 정답 출처가 필요한 과제라면 모두 이 부품을 쓴다. 서비스 유형 5a·9·10·11에서는 필수 기반이다. 비LLM 규칙 기반 대민 안내에서는 A2를 거치지 않고 결정론 조회의 대상이 된다(R21).

맞서는 힘(긴장)

  • 정제 품질 vs 구축 기간·라벨링 인력 비용
  • 과제 전용 가공(빠름) vs 기관 공통 기준선(재사용)
  • 데이터 활용 범위 vs 데이터 등급(E5) 보호
  • 기준선 고정(재현성) vs 원천 갱신 반영

해법

원천 기록을 수집→정제(중복·결측 처리)→라벨링→정의 문서화 순으로 가공하고, 결과를 정제 데이터셋·라벨·데이터 사전의 세 산출물로 고정해 제공한다. 'N건→M건 정제'처럼 정제 전후 규모와 기준을 기록하고, 변수·테이블·인터페이스 정의서로 소비 부품이 같은 정의를 쓰게 한다. 기준선은 버전으로 관리해 C9 평가 세트의 정답 출처와 C6 재학습의 입력으로 재사용한다. 데이터 경계는 부품별로 두고(DB per Service), 타 기관 데이터와의 결합은 A4로 분리한다.

이럴 때 쓴다

  • 예측·추천기(B2)나 비전 모델(A2.5)을 학습·재학습할 때
  • 지식 접지(B3)의 코퍼스를 구축할 때
  • 평가 세트(C9)의 정답 출처가 필요할 때
  • 서비스 유형 5a-agg·9·10·11처럼 A1이 필수인 조립

이럴 때는 쓰지 않는다

  • 공공 API 응답을 가공 없이 조회만 할 때(A3)
  • 정제·정의 없이 파일을 올려 바로 검색하는 경우(태그 대상 아님)
  • 타 기관 데이터 결합이 핵심일 때는 A4를 함께 태그해 계약·키 매핑을 따로 드러낸다

얻는 것

  • 모델 교체와 무관하게 남는 기관 자산
  • C9·C6·B3가 같은 기준선을 재사용
  • 데이터 사전이 기관 간 표준 확산의 단위가 됨

점검표

  • 정제 전후 규모와 정제 기준이 기록되어 있는가
  • 데이터 사전(정의·단위·출처)이 있는가
  • 기준선에 버전이 있고 평가용 분할이 학습용과 분리되어 있는가
  • 데이터 등급(E5)에 맞는 가명·비식별 처리가 적용되었는가

구조 — 참여 부품

  • 원천 시스템·기록 — 가공 전 업무 기록을 내주는 출처
  • 정제·라벨링 파이프라인 — 중복 제거·결측 처리·라벨 부여·품질관리를 수행
  • 데이터 사전 — 정의·단위·출처를 문서로 고정해 소비 부품이 같은 뜻으로 쓰게 함
  • C9 평가 세트·회귀시험 — 기준선을 정답 출처로 사용
  • A2.5 비LLM 학습 모델 — 기준선으로 학습·재학습하는 소비 부품

변형

  • 학습데이터 구축형: 영상·이미지 등을 수집해 품질관리 단계(중복 제거·재라벨링·학습/검증/평가 분리)를 거쳐 학습 기준선으로 만든다.
  • RAG 코퍼스 정본화형: 법령·규정 원문을 현행 시행본 기준으로 정본화하고 조문 구조·메타데이터를 부여해 색인한다.
  • 지표 표준화형: 여러 자료원의 지표를 도메인별로 표준화하고 정의·단위·분모·결측·원본 링크를 메타데이터로 관리한다.
  • 자동 피처 파이프라인형: 수집→정제→파생 변수 생성→자동 검증→담당자 승인을 주기 실행하고 승인만 사람에게 남긴다.

관련 부품

C9 소비처 — 기준선이 평가 세트의 정답 출처 · A4 짝 — 자기 기관 정제(A1)와 타 기관 결합(A4) · B3 소비처 — 지식 접지의 코퍼스 · C6 선행 — 재학습 입력이 되는 기준선 · A2.5 소비처 — 자체 학습 모델의 학습 데이터

참고 자료

computer.org 데이터 증강 · Heiland 데이터 계층 · Microservice 패턴 DB per Service · GoF Builder

이 부품과 이어지는 가이드라인

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

C5 가드레일 필터 운영 컴포넌트

개인정보·환각·편향·형식 오류가 프롬프트나 산출물에 들어가지 못하게 시스템이 경계에서 걸러낸다. 비식별 전처리, 출처 검증, 구조적 출력 제약이 대표 변형이다.

PAX 사례 44건이 이 부품을 쓴다

맥락

외부 모델을 부르거나 대민에 답하는 모든 B 부품. 특히 E2 해외 상용 API, E5 S 이상 데이터, B3 지식 접지 상담, 유형 ① 대민 상담, ④ 기안, ⑥ 콘텐츠, ⑦ 대조·점검, ⑨ 인수인계, ⑬ 비식별·정제 도구.

맞서는 힘(긴장)

  • 차단의 엄격함 vs 과잉 차단으로 인한 유용성 저하
  • 비식별 강도 vs 문맥 보존
  • 결정적 검증의 신뢰성 vs 구현 범위

해법

프롬프트가 기관 밖으로 나가기 전 PII를 마스킹하고 원복 키를 보관하는 비식별 전처리기를 둔다. 응답에는 인용을 원본(법령정보센터·통계표 등)과 대조하는 출처 검증기와, JSON 스키마·허용 목록 같은 구조적 출력 제약을 건다. 근거가 없으면 답하지 않거나 '확인 필요'로 표시한다. 차단 사유는 C4에 남기고, 이용자에게는 F1 출처와 F7 한계 안내로 보인다. 사람이 하는 팩트체크·법무 심의는 C5가 아니라 C1.2에 둔다.

이럴 때 쓴다

  • E2 해외 상용 API로 행정망 본문이 외부로 나갈 때(필수)
  • E5 S 이상 개인정보·민감정보를 다룰 때
  • B3 대민 응답처럼 인용·수치의 정확성이 신뢰의 핵심일 때
  • C5가 필수인 유형 ①④⑥⑦⑨⑪⑬

이럴 때는 쓰지 않는다

  • E1 로컬 PC 완결로 데이터가 밖으로 나가지 않을 때 비식별은 불필요해질 수 있다(§5 매트릭스, 단 출처 검증은 별개)
  • 사람이 수행하는 심의만 있을 때(C1.2로 태그)
  • 적대적 입력 탐지가 목적일 때(S8)

얻는 것

  • 개인정보 외부 유출 차단
  • 환각 인용 감소
  • 상용 API 사용 조건 충족

점검표

  • 외부 전송 전 무엇이 걸러지는지 답할 수 있는가
  • 인용이 원본과 대조되는가
  • 근거 없을 때의 동작이 정해져 있는가
  • 차단 사유가 기록되는가

구조 — 참여 부품

  • 비식별 전처리기 — 외부 전송 전 PII 마스킹과 원복
  • 출처 검증기 — 인용을 원본과 대조해 환각을 걸러냄
  • 출력 제약 — 스키마·허용 목록·금칙어로 출력 형식 제한
  • F1 출처 표시 — 검증된 출처를 이용자에게 보임

변형

  • 로컬 비식별 전처리기: 외부 전송 전 PII 마스킹·원복(PAX에서 독립 부품으로 확인)
  • 출처 검증기: 인용을 법령정보센터·KCI·CrossRef 원본과 대조
  • 구조적 출력 제약·스키마 검증: JSON 스키마·허용 목록으로 출력 범위를 고정(v0.6 식별 신호 추가)
  • 근거 재대조형 환각 검증: 추출값의 근거 문장을 원문에서 재대조해 '문서확인/AI추정/문서에없음'으로 재분류

참조 구현 예

  • PAX Korean Stats MCP — KOSIS 통계 출처 자동 인용

관련 부품

F1 이용자 쪽 대응 — 검증된 출처 표시 · F7 이용자 쪽 대응 — 근거 없을 때 한계 안내 · A2.4 짝 — 민감정보 외부 유출 대응 · C1.2 구분 — 사람이 하는 심의 · S8 구분 — 적대적 입력 탐지 · S13 변형 후보 — 로컬 비식별 게이트

참고 자료

Fowler Guardrails · InfoQ Output Guardrails·Model Critic · Gulli ch.18 Guardrails · Heiland 규칙 기반 안전장치 · Proxy · Decorator

이 부품과 이어지는 가이드라인

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

D8.7 인수인계·지식 보존 서비스 블록

전임자 파일 더미를 업무·월별 정리본으로 바꾸고 결정·전례를 남기는 내부 운영 블록이다. 공직 순환보직이 만드는 한국 특유의 블록이다.

PAX 사례 37건이 이 부품을 쓴다

맥락

담당자 교체 때 업무 지식을 넘기고 보존하는 업무. §7.3 유형 ⑨ 인수인계·지식 보존(D8.7, P0). PAX 37건(주 부품 B0 68%, B1 16%). 업무 영역별 PAX 건수(557건 태깅): 공통·범용 14, 인사·복무 8, 문서·기안 4, 기획·정책 4, 감사·법무 3, 시설·안전 3, 데이터·통계 1.

맞서는 힘(긴장)

  • 전임자 파일을 통째로 넘기는 편의 vs 등급 문서 무단 코퍼스화·PII 축적
  • 정리 표준화 vs 업무별 다양성
  • 기억 축적 vs 보관 기한·개인정보 규칙
  • 정리본 수준 vs 검색 가능한 지식(승급 비용)

해법

먼저 B0 문서 정리로 전임자 파일을 업무·월별 정리본으로 바꾸고, 결정·전례를 원문 위치와 함께 남긴다(F1). 정리가 쌓이면 A1 문서 자산화와 B3 접지로 후임이 질문해 찾는 지식으로 승급하고, 업무·필드·관계 구조가 필요하면 A6 온톨로지를 붙인다. 공유 전에는 C5 비식별로 개인정보를 거르고, S2 권한 인식과 C8 접근 범위로 등급 문서가 무단 코퍼스가 되지 않게 한다. 기억은 B′+ 기억 관리의 개인정보 규칙을 따르고 F8로 이력을 남긴다.

이럴 때 쓴다

  • 인사이동 때 업무 지식이 사라지는 문제
  • 후임이 같은 질문과 실수를 반복할 때
  • 결정·전례를 근거와 함께 남겨야 할 때

이럴 때는 쓰지 않는다

  • 현재 담당자의 문서 검색이 목적이면 D8.1
  • 공유 전 비식별 자체가 산출물이면 D8.8(우선순위상 인수인계가 먼저이므로 목적을 확인)
  • 개인 메모 도구로 인계 목적이 없으면 D8.0 검토

얻는 것

  • 인사이동 시 지식 손실 감소
  • 후임의 적응 기간 단축
  • 결정·전례의 근거 보존

점검표

  • 정리본의 결정·전례가 원문 위치와 연결되는가
  • 공유 전 개인정보가 걸러지는가
  • 등급 문서의 접근 범위가 제한되는가
  • 도구 자체가 담당자 이동으로 멈추지 않도록 저장소·라이선스가 있는가

구조 — 참여 부품

  • 전임자 — 파일과 판단 근거를 남김
  • 후임자 — 정리본을 읽고 질문해 찾음
  • B0 결정적 도구(문서 정리) — 파일 더미를 정리본으로
  • A6 지식그래프 서비스 — 업무·필드·관계 구조(승급 시)
  • B3 지식 접지 상담 — 정리본에 접지한 질의응답(승급 시)
  • C5 가드레일·비식별 — 공유 전 개인정보 제거

변형

  • 정리본 생성형: B0 문서 정리로 업무·월별 정리본 생성(내편이음).
  • 로컬 메모 자산화형: 실무자 메모를 로컬에서 자산화(MemoMindAI).
  • 현장 관제판형: 3교대 공용 PC용 인수인계 대시보드(소방 장비서무).

참조 구현 예

  • 내편이음 — §7.3 유형 ⑨ 참조 구현, 인수인계 정리본
  • 눈치코치 — §7.3 유형 ⑨ 참조 구현
  • 소방 장비서무 인수인계 대시보드 — 카탈로그 D8.7 카드 예: 3교대 공용 PC용 로컬 관제판
  • MemoMindAI — 카탈로그 D8.7 카드 예: 실무자 메모를 로컬에서 자산화
  • dd784289395c2afb — §13 D8.7 참조 구현: 화성특례시·병무청에 이어 지방의회로 확산된 신규자 지식창고

관련 부품

A6 승급 시 기반 — 온톨로지 · B3 승급 경로 — 접지 질의응답 · B′+ 기억 관리 — 개인정보 규칙 · X9 이 블록이 막는 함정 · S2 필수 보안 — 권한 인식

참고 자료

카탈로그 §7.3 유형 ⑨ · 카탈로그 §7.4 유형 ⑨ 위협 모델 · 카탈로그 §13 참조 구현 레지스트리 D8.7

이 부품과 이어지는 가이드라인

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

C8 권한 경계·킬스위치 운영 컴포넌트

AI 부품이 할 수 있는 일의 상한을 P0~P4로 못 박고, 도구별 실행 승인·읽기/쓰기 분리·속도 제한·즉시 중단 스위치를 제공한다.

PAX 사례 22건이 이 부품을 쓴다

맥락

도구를 호출하거나 시스템에 쓰는 B6 오케스트레이터, A8 MCP 서버·호스트, B8 레거시 오버레이, 처분 보조(P3) 서비스. 유형 ⑤b 데이터 에이전트, ⑨ 인수인계(접근 범위).

맞서는 힘(긴장)

  • 자동화 범위 vs 통제
  • 승인 절차의 안전 vs 이용 마찰
  • 도구 설명의 편의 vs 실제 권한과의 일치 검증 비용

해법

부품별 허용 권한 범위(P0 읽기 전용 ~ P4 자율 처분)를 정하고, 도구 목록마다 읽기/쓰기를 분리한다. 위험도가 높은 도구는 실행 전 사람 승인(C2·F6)을 받게 하고, 호출 상한(속도 제한)을 둔다. 전역 킬스위치로 즉시 중단할 수 있게 하고, 승인·실패·중단 이력을 C4에 남긴다. MCP 도구는 설명과 실제 권한이 일치하는지 A8 6축 검증으로 확인한다.

이럴 때 쓴다

  • E4 P2 이상(필수, First 관문)
  • E3 MCP·CLI 환경에서 에이전트가 도구를 호출할 때
  • B6 오케스트레이터에 상용 API를 쓰는 경우(A2 + C7 + C8 도구별 승인)
  • 유형 ⑤b-host, ⑨ 인수인계(접근 범위)

이럴 때는 쓰지 않는다

  • 도구 호출·시스템 쓰기가 없는 서술 전용 코파일럿(P1)
  • B0 결정적 도구로 AI가 행동을 고르지 않을 때

얻는 것

  • 되돌릴 수 없는 조치 방지
  • 도구 설명과 실제 권한의 불일치(X7) 예방
  • 감사 가능한 행동 기록

점검표

  • AI가 쓸 수 있는 시스템 목록을 답할 수 있는가
  • 도구별 읽기/쓰기 구분과 위험도가 있는가
  • 고위험 도구에 실행 승인이 걸려 있는가
  • 킬스위치가 있고 누가 누를 수 있는지 정해져 있는가
  • 도구 설명과 실제 권한이 일치하는가

구조 — 참여 부품

  • 권한 정책 — 부품·도구별 허용 범위(P0~P4)와 읽기/쓰기 구분
  • A8 MCP 서버·호스트 — 도구 설명과 실제 권한의 일치 검증 대상
  • F6 에이전트 행동 검토·확인 — 실행 전 이용자 승인 화면
  • 킬스위치 — 전역 즉시 중단
  • C4 감사 로그·지표 — 승인·실패·롤백·중단 이력

변형

  • 읽기 전용·쓰기 배제: 도구 세트를 읽기 전용으로 한정하거나 쓰기 기능을 설계에서 배제
  • 도구별 위험도·실행 승인: 도구마다 위험도를 평가하고 고위험 도구는 실행 전 승인
  • 판정 필드 비도달 설계: AI가 판정·업무 필드에 쓸 수 없게 코드 수준으로 분리
  • 속도 제한: 도구 호출 상한(Rate Limiter)
  • 킬스위치: 전역 즉시 중단과 기존 절차 전환

참조 구현 예

  • PAX 망분리 환경용 로컬 AI 에이전트 — 도구별 위험도 평가·실행 승인·감사 대시보드(§9, PAX 557건 태깅에서 C8이 운영 중(present)으로 확인된 2건 가운데 하나. 구현 단계까지 합치면 22건)
  • PAX 갈피 법령 MCP — 쓰기 배제 설계

관련 부품

C7 짝 — 막는 통제와 이어 가는 통제 · F6 이용자 쪽 대응 — 에이전트 행동 검토·확인 · A8 의존 — 도구 설명과 실제 권한의 일치 · C2 의존 — 고위험 도구는 사람 승인 · C4 기록처 — 승인·실패·롤백 로그 · S1 짝 — 단일 진입점에서 요청 상한·인증

참고 자료

aiux Agent Action Review · Towards AI 체크포인트 휴리스틱 · Gulli ch.18 Guardrails · Access Token · Rate Limiter · Bulkhead · PAX 원칙 2.5

이 부품과 이어지는 가이드라인

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

X11 처음부터 멀티에이전트 안티패턴

하위 작업이 분리되지 않는데 에이전트를 여럿 두어 조정 비용만 늘리는 함정이다. 단일 에이전트로 되돌리면 더 잘 되는 경우가 많다.

맥락

B6 오케스트레이터를 설계하거나 B′3 병렬·B′4 계층 분해를 도입하려는 과제, 특히 단일 에이전트 구성을 시도해 본 기록이 없는 과제.

맞서는 힘(긴장)

  • 역할 분리의 설계 명료함 vs 에이전트 간 조정 비용
  • 병렬 처리의 지연 단축 vs 결과 통합의 복잡도
  • 기술적 인상 vs 단순한 구조의 품질·비용

해법

B′ 원형 선택 규칙대로 단일 에이전트(B′1 순차, B′7 ReAct 도구 루프)에서 시작한다. 하위 작업이 진짜로 분리되거나, 병렬이 지연을 의미 있게 줄이거나, 컨텍스트 창이 부족할 때만 B′3 병렬·B′4 계층 분해로 승급한다. 승급 판단은 C9 평가 세트로 단일 구성과 비교해 내린다. 에이전트끼리 충돌·중복이 관측되면 B′4 감독자 계층이나 B′2 라우터로 정리하거나 단일 에이전트로 후퇴한다. B6 태그는 R2 요건(복수 LLM 역할 + 도구 호출 루프 + AI가 계획·도구를 선택)을 만족할 때만 붙인다.

이럴 때 쓴다

  • 에이전트가 여럿인데 하위 작업의 입력·출력이 서로 얽혀 독립적으로 돌지 않는다
  • 단일 에이전트 구성과 비교한 기록이 없다
  • 에이전트끼리 충돌·중복·재작업이 관측된다
  • 호출 비용·지연이 에이전트 수에 비례해 늘었는데 품질 개선 근거가 없다

이럴 때는 쓰지 않는다

  • 하위 작업이 진짜로 분리되고(서로 다른 데이터·도구), 병렬이 지연을 줄이거나 컨텍스트가 부족해 승급한 경우
  • R2 요건을 만족하는 B6로, 단일 구성보다 나음이 C9로 확인된 경우
  • 고정 순서 파이프라인을 B′1으로 정직하게 서술한 경우

얻는 것

  • 구조도가 명료하고 기술적으로 인상적이다
  • 역할별로 프롬프트를 나눠 관리하기 쉬워 보인다

점검표

  • 하위 작업이 서로 다른 데이터·도구로 독립적으로 도는가
  • 단일 에이전트 구성과 C9로 비교한 기록이 있는가
  • 승급 사유가 문서에 적혀 있는가
  • 에이전트 사이 충돌을 정리하는 감독자·라우터가 있는가

구조 — 참여 부품

  • B′1 순차 파이프라인 — 시작점이 되는 단일 흐름
  • B′7 ReAct 도구 루프 — 단일 에이전트 도구 사용의 기본형
  • B′4 계층 분해·감독자 — 하위 작업이 분리될 때만 승급하는 형태
  • C9 평가 세트·회귀시험 — 단일 vs 멀티 구성을 같은 자로 비교

변형

  • 페르소나 분할형: 같은 문서를 읽는 작업을 역할 이름만 다른 에이전트 여럿에 나눔
  • 고정 파이프라인 위장형: 실제로는 고정 순서 단계인데 에이전트 N개로 서술(R2상 B6 아님)
  • 무감독 협업형: 감독자·라우터 없이 에이전트끼리 대화하며 결과를 합침

관련 부품

B′7 대체 — 단일 에이전트 도구 루프에서 시작 · B′1 대체 — 고정 순서면 순차 파이프라인으로 · B′4 승급 목표 — 하위 작업이 분리될 때만 · B′2 정리 수단 — 충돌·중복을 라우터로 분기 · C9 판단 근거 — 단일 vs 멀티 비교

참고 자료

Towards AI '단일 에이전트에서 시작해 승급' · Google ADK Hierarchical·Coordinator · Gulli ch.7 Multi-Agent

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

X13 도구 출력이 지시가 되는 에이전트 안티패턴

검색 결과·첨부·API 응답을 읽은 모델이 그 안의 문장을 새 명령으로 받아 도구를 부르는 구조를, 탐지 필터 하나로 지키려는 함정이다.

맥락

E4가 P2 이상(시스템 쓰기·처분 보조)이면서 민원 입력·제출 서류·웹 문서·타 기관 API 응답 같은 신뢰 불가 입력을 읽는 에이전트. 특히 B6·5b 데이터 에이전트.

맞서는 힘(긴장)

  • 범용 에이전트의 유연성 vs 신뢰 불가 입력 뒤의 행동 제약
  • 단일 LLM 구조의 단순함 vs 격리·계획 고정의 설계 비용
  • 탐지 필터의 손쉬움 vs 증명 가능한 보증

해법

과제의 AI가 읽는 입력 중 기관 밖에서 작성된 것을 untrusted_inputs로 나열하고, §4.2 신뢰 불가 입력 규칙대로 S4 행동 선택기(미리 정한 행동 중 선택만, 결과가 LLM으로 돌아가지 않음), S5 계획 후 실행(외부 데이터를 읽기 전에 도구 호출 계획을 고정), S6 격리 LLM(도구 있는 LLM은 외부 데이터를 읽지 않고, 읽는 LLM은 도구가 없음) 중 하나를 갖춘다. S3 컨텍스트 방화벽과 S8 독립 검증기는 보조로 붙이되 S8만으로는 규칙을 충족하지 못한다. C8 승인 게이트도 신뢰 불가 입력 규칙의 대체 통제로 인정되지 않는다(R6). 그 전 단계에서는 E4를 P0~P1 읽기·산출물 범위에 묶어 두는 것이 곧 보안이다.

이럴 때 쓴다

  • E4가 P2 이상이고 untrusted_inputs가 비어 있지 않은데 S4·S5·S6이 모두 없다(신뢰 불가 입력 규칙 위반)
  • 외부 문서를 읽는 LLM이 같은 컨텍스트에서 쓰기 도구를 호출할 수 있다
  • 인젝션 대책이 탐지 필터·프롬프트 경고문뿐이다
  • 읽은 텍스트 중 어떤 것이 어떤 도구를 부를 수 있는지 답하지 못한다

이럴 때는 쓰지 않는다

  • E4가 P0~P1로 읽기·산출물 생성에만 묶여 도구 호출·시스템 쓰기가 없는 경우(S4·S5·S6 판정 전제 불충족, R6)
  • S4·S5·S6 중 하나가 구조적으로 갖춰진 경우(보안 목적 서술이 없어도 구조가 일치하면 충족)
  • AI가 읽는 입력이 모두 기관 내부에서 작성된 경우

얻는 것

  • 단일 LLM 범용 에이전트로 구조가 단순하다
  • 새 입력·새 도구를 자유롭게 붙인다

점검표

  • untrusted_inputs가 나열되어 있는가
  • 신뢰 불가 입력을 읽은 LLM이 쓰기 도구를 직접 부를 수 없는가
  • S4·S5·S6 중 하나가 구조로 구현되어 있는가
  • S8 탐지를 유일한 방어로 두지 않았는가

구조 — 참여 부품

  • S4 행동 선택기 — LLM이 정해진 행동 중 선택만 하게 제약
  • S5 계획 후 실행·코드 후 실행 — 외부 데이터를 읽기 전에 도구 계획 고정
  • S6 격리 LLM·맵리듀스 — 읽는 LLM과 도구 있는 LLM을 분리
  • S8 독립 검증기·이중 심판 — 보조 탐지. 단독으로는 보증이 아님

변형

  • 문서 속 지시: 첨부·제출 서류 안의 문장대로 에이전트가 도구를 호출
  • API 응답 오염: 타 기관 API·웹 검색 결과에 섞인 지시가 후속 행동을 바꿈
  • 탐지 단독 방어: 인젝션 탐지 필터(S8) 하나만 두고 구조적 제약이 없음

관련 부품

S6 대체 — 읽는 LLM과 도구 있는 LLM 격리 · S5 대체 — 외부 데이터 읽기 전 계획 고정 · S4 대체 — 정해진 행동 중 선택만 · S3 보조 — 신뢰 구역 분리 표기 · S8 보조 — 탐지(단독으로는 보증 아님) · S10 기록처 — 사고 재현

참고 자료

Beurer-Kellner 외(2025) 지도 원칙 '신뢰 불가 입력을 읽은 뒤에는 그 입력이 결과적 행동을 촉발할 수 없도록 제약' · Beurer-Kellner #1 Action-Selector, #2·#5 Plan-Then-Execute, #3·#4 Dual LLM

이 부품과 이어지는 가이드라인

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

X14 재생할 수 없는 사고 안티패턴

잘못된 처분이 나갔는데 그때의 프롬프트·검색·도구 호출 순서를 아무도 복원하지 못하는 함정이다. 지표는 있는데 기록이 없다.

맥락

E4가 P2 이상, 특히 P3 처분 보조(지급·승인·반려 결과에 직결)에 관여하는 AI 부품. 모델·프롬프트가 자주 바뀌는 상용 API 과제.

맞서는 힘(긴장)

  • 집계 지표의 손쉬움 vs 건별 재생 기록의 저장·보호 비용
  • 개인정보 최소 보관 vs 사고 재현 가능성
  • 빠른 모델·프롬프트 변경 vs 버전별 재현

해법

S10 결정적 재생으로 프롬프트·검색 결과·도구 호출·정책 결정·실행 흔적을 시각·주체·컨텍스트 해시와 함께 순서대로 기록하고, 필요하면 변조 방지 서명을 붙인다. 기록은 S1 단일 진입점에서 시작해 C4와 같은 파이프라인으로 적재하되, C4가 '얼마나'를 세고 S10은 '정확히 무엇이 일어났나'를 되돌리게 역할을 나눈다. 모델·프롬프트·설정 조합을 C9로 버전 고정해 그 시점의 구성을 재현할 수 있게 하고, 재생 기록을 C3 롤백·이의제기의 근거로 쓴다. 개인정보는 C5 비식별과 E5 등급에 맞춘 보관 기간으로 다룬다.

이럴 때 쓴다

  • 처리 건수·정확도 같은 집계 지표는 있으나 건별 프롬프트·검색·도구 호출 기록이 없다
  • '이 답의 근거 문서와 도구 호출 순서를 지금 볼 수 있는가'에 답하지 못한다
  • P3 처분 보조에 관여하면서 재생 기록이 없다
  • 모델·프롬프트 버전을 기록하지 않는다

이럴 때는 쓰지 않는다

  • B0 결정적 도구처럼 같은 입력이면 같은 출력이 나와 재생이 자명한 경우
  • E4가 P0~P1이고 산출물을 사람이 전건 확정해 AI 출력이 처분에 직접 닿지 않는 경우(S10 필요도는 낮지만 C4는 여전히 필요)
  • S10 수준의 건별 추적이 구현된 경우

얻는 것

  • 저장 비용과 개인정보 보관 부담이 적다
  • 집계 지표만으로 운영 보고가 가능하다

점검표

  • 임의의 과거 건 하나를 골라 프롬프트·검색·도구 호출 순서를 복원할 수 있는가
  • 기록에 당시 모델·프롬프트 버전이 포함되는가
  • 기록의 변조 방지 장치가 있는가
  • 이의제기 처리에 재생 기록이 쓰이는가

구조 — 참여 부품

  • S10 결정적 재생 — 빠진 부품. 사고를 그대로 재현
  • C4 감사 로그·지표 — 집계 지표는 있으나 재생에는 부족
  • S1 AI 게이트웨이·단일 진입점 — 모든 호출의 기록 시작점
  • C3 상태 머신·롤백 — 재생 기록을 근거로 되돌림·이의 처리

변형

  • 지표만 있는 형: 대시보드 집계는 있으나 건별 입력·호출 기록이 없음
  • 최종 출력만 저장형: 산출물만 저장하고 프롬프트·검색·도구 호출 순서는 버림
  • 버전 미고정형: 기록은 있으나 당시 모델·프롬프트 버전을 몰라 재현 불가

관련 부품

S10 대체 — 건별 결정적 재생 기록 · C4 짝 — 같은 파이프라인의 집계 지표 · S1 끼울 자리 — 기록이 시작되는 단일 진입점 · C3 이용처 — 롤백·이의제기의 근거 · C9 선행 — 모델·프롬프트 버전 고정

참고 자료

DistriNet 행위 기록(부인 방지) · Distributed Tracing · Beurer-Kellner Log Entity Actions

이 부품과 이어지는 가이드라인

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

X7 도구 설명 ≠ 실제 권한 안티패턴

MCP 도구 설명은 '조회'인데 코드는 쓰기·실행 권한을 가져, 설명만 믿고 도구를 부르는 에이전트가 의도하지 않은 변경을 일으키는 함정이다.

맥락

E3 MCP·CLI 설정 환경에서 A8 MCP 서버·호스트를 만들거나 가져다 쓰는 과제. 특히 업무 시스템 MCP(쓰기, P2)와 공공데이터 MCP(읽기, P0)가 한 호스트에 함께 연결된 경우.

맞서는 힘(긴장)

  • 빠른 MCP 래핑 vs 도구별 권한 분리
  • 도구 하나로 묶는 편의 vs 읽기/쓰기 분리의 운영 부담
  • 에이전트 자율 호출 vs 실행 전 승인

해법

A8의 각 도구에 실제 권한 수준(P0~P4)을 설명과 함께 명시하고, C8 권한 경계로 읽기 전용 도구와 쓰기 도구를 서로 다른 서버·인증으로 분리한다. 쓰기·실행 도구는 도구별 실행 승인과 호출 상한, 킬스위치를 둔다. 반입하는 MCP 서버는 S11 인제스천·공급망 검증에서 PAX 6축(권한 표면·비밀·공급망·위생·인젝션·데이터 흐름)을 통과해야 활성화한다. 사람에게는 F6 에이전트 행동 검토·확인으로 실행 전 무엇을 할지 보여 주고, 승인·실패는 C4에 남긴다.

이럴 때 쓴다

  • MCP 도구 설명과 실제 권한(쓰기·삭제·발송)이 다르다
  • 읽기와 쓰기 도구가 같은 서버·같은 인증 토큰을 쓴다
  • 도구별 권한 수준·실행 승인이 문서에 없다
  • 6축 검증에서 권한 표면이 '주의'로 나왔다

이럴 때는 쓰지 않는다

  • 읽기 전용 MCP로 설계되어 쓰기 기능이 배제된 경우
  • 쓰기 도구가 있지만 설명에 부수 효과가 명시되고 C8 실행 승인이 있는 경우
  • MCP가 아닌 결정적 스크립트로 권한이 코드에 고정된 경우

얻는 것

  • 기존 API를 빠르게 에이전트 도구로 만든다
  • 도구 수가 적어 관리가 쉬워 보인다

점검표

  • 모든 도구의 설명에 실제 권한과 부수 효과가 적혀 있는가
  • 읽기와 쓰기 도구가 서로 다른 인증을 쓰는가
  • 쓰기 도구에 실행 전 승인이 있는가
  • 반입 MCP가 6축 검증을 통과했는가

구조 — 참여 부품

  • A8 MCP 서버·호스트 — 도구 설명과 실제 권한이 일치해야 하는 곳
  • C8 권한 경계·킬스위치 — 읽기/쓰기 분리, 도구별 승인
  • S11 인제스천·공급망 검증 — 반입 시 6축 검증
  • F6 에이전트 행동 검토·확인 — 실행 전 사람에게 행동을 보여 줌

변형

  • API 통째 래핑: 기존 API 클라이언트를 감싸 조회·수정 함수가 같은 도구·인증으로 노출
  • 과대 인증: 조회 도구가 쓰기 권한 토큰으로 실행됨
  • 설명 누락: 도구 설명에 부수 효과(삭제·발송)가 적혀 있지 않음

관련 부품

C8 대체 — 읽기/쓰기 분리와 도구별 실행 승인 · A8 발생 자리 — 도구 설명과 권한이 일치해야 하는 곳 · S11 선행 — 반입 시 6축 검증 · F6 이용자 쪽 대응 — 실행 전 행동 확인 · X13 이웃 안티패턴 — 권한 표면이 넓을수록 인젝션 피해가 커짐

참고 자료

PAX MCP 6축 검증(권한 표면·비밀·공급망·위생·인젝션·데이터 흐름) · Microservice Access Token

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

X8 MCP 서버 개수 세기 안티패턴

MCP 서버를 몇 개 만들었는지가 성과가 되고, 실제 업무에서 호출되는지·흐름이 바뀌었는지는 아무도 묻지 않는 함정이다.

맥락

공공데이터·업무 시스템을 MCP로 감싸는 과제, MCP 서버를 사례 단위로 등록하는 커뮤니티 아카이브, 'MCP N종 구축'을 성과 지표로 둔 과제.

맞서는 힘(긴장)

  • 보고하기 쉬운 개수 vs 측정하기 어려운 업무 전환
  • 서버 제공자 책임 vs 호스트·업무 쪽 활용 책임
  • 빠른 확장 vs 서버마다의 검증·유지보수

해법

서버마다 그것을 호출하는 B 업무 컴포넌트와 업무 산출물을 연결해 '어느 업무의 어떤 산출물에 쓰이는가'를 적는다. C4 감사 로그·지표로 호출 수·호출 주체·업무 건을 집계하고, transition.stage와 파급력 척도(M1~M5)로 전환 경로를 추적한다(PAX: 도구 수보다 전환 경로를 추적). R18대로 서버 제공자 사례(5b-server)와 호스트 통합 사례(5b-host)를 나눠 서버 쪽은 A8·S11·문서화된 스키마를, 호스트 쪽은 C4·F1·S5|S6을 갖춘다. 호출되지 않는 서버는 레지스트리에서 정리한다.

이럴 때 쓴다

  • 성과가 MCP 서버·도구 개수로 보고된다
  • 호출 수·호출 주체·업무 건 지표가 없다
  • 서버를 호출하는 업무 산출물이 서술되지 않는다
  • 흐름이 바뀌었다는 서술 없이 'MCP 기반 전환'을 주장한다

이럴 때는 쓰지 않는다

  • 단일 MCP 서버를 만들어 A8·S11·문서화된 스키마를 갖춘 5b-server 사례(R18). 서버 제공 자체가 사례 단위이므로 개수를 성과로 주장하지 않으면 함정이 아니다
  • MCP 서버 여러 개를 호스트 업무에 연결하고 호출 지표를 C4로 집계한 경우

얻는 것

  • 성과를 개수로 명확히 보고할 수 있다
  • 공공 API를 빠르게 에이전트 도구로 공개한다

점검표

  • 서버마다 호출하는 업무 산출물이 적혀 있는가
  • 서버별 월 호출 수와 호출 주체를 말할 수 있는가
  • 호출되지 않는 서버를 정리하는 절차가 있는가
  • 성과 지표가 개수가 아니라 업무 전환으로 잡혀 있는가

구조 — 참여 부품

  • A8 MCP 서버·호스트 — 개수로 세어지는 도구 인터페이스
  • C4 감사 로그·지표 — 호출 수·호출 주체·업무 건을 집계하는 빠진 부품
  • B 업무 컴포넌트 — 서버를 실제로 호출해 산출물을 만드는 쪽
  • S11 인제스천·공급망 검증 — 서버 제공자 쪽 필수 검증(R18)

변형

  • 개수 성과형: 'MCP N종 구축'이 과제의 주요 성과 지표
  • 호스트 없는 서버: 서버만 공개하고 어떤 호스트·업무에서 쓰이는지 기록이 없음
  • 방치 서버: 원천 API 변경 후 갱신되지 않아 호출이 실패하는 서버가 목록에 남음

관련 부품

C4 대체 — 서버별 호출 지표 · A8 발생 자리 — 개수로 세어지는 도구 인터페이스 · B6 교정 목표 — 도구를 호출해 산출물을 만드는 업무 컴포넌트 · S11 서버 제공자 필수 — 반입·공급망 검증(R18) · X1 이웃 안티패턴 — 탑재·개수를 성과로 세는 같은 뿌리

참고 자료

PAX '도구 수보다 전환 경로를 추적' · PAX 파급력 척도 M1~M5 · Microservice Service Discovery

웹북에서 전체 프로필 보기 ↗ · 패턴 성좌 디렉터리에서 보기 ↗

실무 도입 카드

필요한 것

실행환경: 브라우저만 · 망 요건: 인터넷 필수

첫 3단계

① 링크 접속 → ② 내 업무 데이터로 시험 → ③ 동료와 결과 검증

주의사항

성과 수치는 출처가 확인된 것만 신뢰하세요

전이 절차(보안검토→품의→배포)는 전이 플레이북을 참고하세요.

비슷한 업무의 사례