에이전트의 말투를 바꿔도 실제 업무의 승인과 기록이 흔들리지 않도록 두 일을 나누는 설계를 제안했다.

무엇이 문제였나 — 문제: 에이전트의 말투와 지시를 고칠 때마다 실제 업무까지 다시 검사해야 하거나, 검사를 줄이면 업무 기록을 믿기 어려울 수 있다. 어떻게 풀었나 — 방법: 대화와 말투 설정은 한 영역에 두고, 실제 업무는 다른 영역에서 정해진 승인과 기록 절차를 거치게 한다. 그래서 뭐가 좋아졌나 — 결과: 파일럿 구현에서는 persona 변경 뒤 실행 측 재검증이 없었고, 한 A/B 검사에서 정해 둔 실행 기록 항목에 persona 정보가 섞이지 않았다.

안내 직원의 설명 방식을 바꿔도 결제 창구의 승인 절차와 장부 기록은 그대로 유지하는 것과 비슷하다. 두 업무는 나뉘어 있지만, 필요한 정보는 정해진 통로와 절차를 거쳐 전달된다.

논문 정보

Yisen Xi · Independent Researcher, Beijing, China · arXiv preprint arXiv:2608.27427v1 [cs.SE] · 2026

왜 중요한가

에이전트가 결제나 규제 문서 작성처럼 실제 업무를 하면서도 담당자가 말투와 지시를 계속 고쳐야 하는 경우가 있다. 이 설계는 바꿔도 되는 설정과 승인·기록을 유지해야 하는 업무를 나눠 관리하는 방법을 제시한다.

핵심 지표

지표값설명
persona 변경 후 실행 측 재검증률 R0.00재검증 이벤트 / pe개발/파일럿 구현의 V1 메커니즘 검사에서 5개 모델 설정에 걸쳐 보고된 값이다. 경쟁군 비교 결과는 아니다.
지정 실행 기록 필드의 persona 결합도0고정 입력 IC memo 파이프라인의 한 A/B 쌍에서 hard-asserted semantic fields의 불변성을 확인한 결과다.
PES로 수렴한 설계 결정5건2026-07-19부터 2026-08-17까지 기록된 결정이다.
비교한 오픈소스 플랫폼8개2026-08-27 기준 공개 문서와 저장소를 바탕으로 세 설계 차원을 비교했다.

어떻게 동작하나

논문은 persona와 실행 지시가 모두 자연어로 표현되므로 한 관리 영역 안에서는 두 종류의 변경을 구분하기 어렵다는 전제에서 출발한다. 다만 단일 영역 설계가 논리적으로 불가능하다고 주장하지는 않는다. 세 목표(자유로운 persona 변경, 실행 감사 가능성, 둘의 분리)를 함께 달성하려면 변경 종류를 구분하는 구조, 모델 입력 밖의 집행 지점, persona 변경에도 유지되는 감사 기준이 필요하다는 구성적 논증을 제시한다. PES에서는 persona를 낮은 통제 영역에 두고, persona가 없는 실제 실행을 높은 통제 영역에 둔다. 브리지는 승인표, DLP, 감사 기록을 적용하며, 요약 정보는 돌아올 수 있지만 업무 데이터 본문은 원칙적으로 실행 영역에 남긴다. 예외는 DLP 마스킹을 거친 등급화된 정보 이동이다. 사례는 금융기관용 디지털 직원 플랫폼의 단일 테넌트 개발/파일럿이다. 한 달간 다섯 설계 결정을 기록했고, 고정 입력 IC memo의 retrieve-then-generate 작업으로 persona 변경 전후 실행을 검사했다. V1은 시스템 감사 로그에서 재검증률 R을 확인했고, V2는 감사 스키마와 한 A/B 쌍에서 지정 필드의 불변성을 확인했다. 논문은 복원한 이전 빌드도 탐침했지만 대조군 재검증률은 제시하지 않는다. 통계적 유의성, 신뢰구간, 지연 시간이나 운영 비용은 보고하지 않았다.

핵심 수식:

G1 ∧ G2 ∧ G3 ⇒ {typed change objects, external enforcement point, stable audit anchor}
R = N_re-validation / N_persona-change; C_record,persona = 0

G1은 persona의 자유로운 변경, G2는 실행 추적성, G3는 둘의 분리다. 첫 식은 논문의 Proposition 1에 제시된 구성적 주장이지 형식적 불가능성 증명은 아니다. N_re-validation은 실행 측 재검증 이벤트 수, N_persona-change는 persona 변경 이벤트 수다. C_record,persona는 논문이 A/B 검사에서 확인한 지정 실행 기록 필드와 persona 버전의 결합도를 가리키며, 한 쌍의 검사 결과가 0이었다.

한계와 주의할 점

  • 근거는 한 금융기관의 단일 테넌트 개발/파일럿과 한 직원의 IC memo 검사에 한정된다. 생산 시스템에서의 결과나 다른 산업에 대한 통계적 일반화는 없다.
  • 경쟁 구조와 비교한 브리지 지연, 승인 조회 비용, 운영 복잡도 수치는 보고되지 않아 PES가 더 저렴하다는 것은 논문의 구조적 주장에 머문다.
  • V1의 R=0은 구현 메커니즘 검사 결과이고, V2의 0은 한 A/B 쌍의 지정 필드 검사 결과다. 반복 실험이나 유의성 분석이 없어 일반적 효과로 해석할 수 없다.
  • 논문은 형식적 보장을 주장하지 않는다. 제안된 성질은 계약 브리지가 명세대로 구현될 때 성립하며, run과 conversation ID 연결은 미완성 제품 항목이다.
  • 위협 분석은 개략적이다. 제공자 직접 호출과 모델 호출 정책은 PES 범위 밖이며, 오픈소스 비교는 공개 자료에 기초한다.
  • 브리지의 스키마 검사나 차단 처리가 빠지고 직접 API 또는 자유형 통로가 남으면 권한 우회와 영역 간 격리가 무너질 수 있다.
  • 허용된 업무 요청이 사회공학으로 조작되거나 persona 편집 권한이 탈취되면, 고정된 핵심 신원만으로는 허용 도구의 표현이나 선택을 막지 못할 수 있다.
  • DLP의 정보 등급이나 마스킹 설정이 잘못되면 제한된 본문이 노출되거나 정상 업무 정보가 과도하게 차단될 수 있다.
  • 낮은 통제 영역에서 모델 제공자를 직접 호출하면 영역 간 데이터 이동을 통제해도 모델 호출 정책은 우회될 수 있다.

단계별 도입 로드맵

단계목표액션기대 효과
Phase 1PES 적용 조건과 경계 계약을 정한다.여러 사용자가 함께 쓰는지, 실행 감사가 필요한지, persona가 자주 바뀌는지 확인한다. persona와 핵심 신원·업무 권한을 구분하고 두 영역, 직원 식별자, 허용 통로, 업무 요청 형식, 정보 등급, 승인 규칙, 기본 차단 원칙을 정한다.변경 가능한 대화 설정과 조직이 기록해야 할 업무 실행의 경계를 명확히 한다.
Phase 2통제된 파일럿에서 분리 구조를 확인한다.대화 영역과 SOP 실행 영역을 분리하고 승인표, DLP, 감사 기록이 적용되는 브리지를 구현한다. 고정 입력 업무에서 persona 변경 전후를 비교해 재검증률과 지정 기록 필드의 불변성을 측정한다. 대화 ID와 실행 ID 연결, 승인 누락, 역방향 정보 이동도 점검한다.persona 변경이 실행 재검증을 유발하지 않는지, 감사 기록의 지정 필드가 유지되는지 확인한다.
Phase 3여러 사용자와 테넌트에서 운영 비용과 회복력을 평가한다.여러 운영자와 테넌트에서 브리지 지연, 승인 대기 시간, 실패와 복구 비용을 측정하고 한 영역에 모은 구조와 비교한다. 프롬프트 주입, 프로필 오염, 사회공학, 제공자 우회를 시험하고 격리·복구·수동 승인 절차를 점검한다.단일 파일럿의 메커니즘 확인을 운영 규모의 성능·보안·복구 근거로 확장한다.

원문 PDF: 2026-08-29-persona-execution-separation-an-architecture-pattern-for-evolving-llm-ag.pdf