프롬프트 transpilation 설계법: 에이전트 지시문을 빌드·검증·배포하는 방법

프로덕션 에이전트의 시스템 프롬프트는 어느 순간 코드보다 위험한 파일이 된다. 처음에는 역할, 말투, 도구 사용 규칙 몇 줄이면 충분하다. 하지만 운영이 시작되면 개인정보 처리, 승인 기준, 장애 대응, 출력 포맷, 고객별 예외, 금지 행동, escalation rule이 계속 붙는다. 결국 1개 파일에 조직의 운영 정책이 모두 들어가고, 작은 문장 변경이 어느 워크플로우를 깨뜨리는지 아무도 확신하지 못한다.

Google Developers Blog가 2026년 7월 16일 공개한 글은 이 문제를 “prompt transpilation”이라는 빌드 시스템 문제로 다룬다. 핵심은 프롬프트를 사람이 직접 붙여 넣는 텍스트가 아니라, 모듈화된 source file에서 생성되는 build artifact로 관리하자는 것이다. 소프트웨어에서 소스 코드, 템플릿, 빌드 결과물, 테스트, 배포를 나누듯 에이전트 지시문도 같은 방식으로 다루자는 접근이다.

이 글은 새로운 유행어를 소개하는 글이 아니다. 이미 AI 에이전트를 운영 중인 팀이 왜 시스템 프롬프트를 쪼개야 하는지, 어떤 검증을 CI에 넣어야 하는지, 에이전트가 자기 지시문을 직접 바꾸는 대신 PR을 열게 해야 하는 이유를 실무 기준으로 정리한다.

단일 시스템 프롬프트가 깨지는 세 가지 이유

첫 번째 문제는 blast radius가 보이지 않는다는 점이다. 코드 변경은 함수, 모듈, 호출부, 테스트를 보면 영향 범위를 추정할 수 있다. 반면 시스템 프롬프트에 한 문장을 추가하면 전체 대화 정책에 영향을 줄 수 있다. “장애 상황에서는 적극적으로 해결책을 제안하라”는 문장이 고객 데이터 삭제 요청에도 적용될 수 있다. 리뷰어는 그 위험을 diff만 보고 알기 어렵다.

두 번째는 copy-paste drift다. 여러 팀이 각자 에이전트를 만들면 공통 정책이 복사된다. 개인정보 마스킹 규칙, 내부 API 사용법, 승인 필요 작업 목록, 금지 표현 같은 항목이 에이전트마다 조금씩 달라진다. 한쪽은 최신 보안 정책을 반영했는데 다른 쪽은 3개월 전 문구를 그대로 쓰는 일이 생긴다.

세 번째는 런타임 오류다. 프롬프트가 커지면 문자열 템플릿, 조건문, include 흉내를 쓰게 된다. 그런데 빠진 변수, 잘못된 경로, 순환 참조, 오타가 배포 전에는 드러나지 않고 특정 케이스에서만 터진다. 에이전트가 고객 앞에서 “{{ customer_name }}” 같은 템플릿 변수를 그대로 출력하면 신뢰가 바로 떨어진다.

프롬프트를 소스와 빌드 결과물로 나눠라

prompt transpilation의 기본 구조는 간단하다. 개발자는 작은 prompt module을 작성한다. 예를 들어 shared/safety.prompt.md, shared/tool_usage.prompt.md, domain/refund_policy.prompt.md, agents/sre_agent.prompt.md처럼 역할과 관심사를 나눈다. 최상위 agent prompt는 필요한 모듈을 include하고, 환경변수나 배포 설정에 따라 조건부 문구를 렌더링한다.

빌드 단계에서는 transpiler가 모든 include를 해석하고, 변수 값을 주입하고, macro를 확장해 최종 시스템 프롬프트를 만든다. 모델에는 이 결과물만 들어간다. 중요한 점은 최종 결과물을 사람이 직접 수정하지 않는다는 것이다. 소스 파일을 고치고 빌드를 다시 돌려야 한다.

이 구조의 장점은 변경 범위가 보인다는 데 있다. 안전 정책을 바꾸면 shared/safety만 리뷰하면 된다. 특정 에이전트의 조사 단계만 바꾸면 해당 agent template만 보면 된다. 공통 모듈이 바뀌면 어떤 agent가 영향을 받는지 dependency graph로 알 수 있다.

CI에서 반드시 잡아야 할 검증 항목

프롬프트 모듈화는 파일을 나누는 것만으로 끝나지 않는다. 빌드 검증이 없으면 오히려 복잡도만 늘어난다. 최소한 네 가지 검사는 CI에 넣어야 한다.

첫째, missing import 검사다. include 경로가 존재하지 않으면 빌드 실패로 처리해야 한다. 런타임에서 모델이 엉뚱한 빈 지시문으로 실행되면 안 된다. 둘째, undefined variable 검사다. 템플릿에서 {{ environment }}를 쓰는데 배포 설정에 값이 없으면 실패해야 한다. 기본값으로 조용히 넘어가면 환경별 정책이 틀어질 수 있다.

셋째, circular dependency 검사다. A가 B를 include하고 B가 다시 A를 include하면 프롬프트가 중복되거나 빌드가 멈춘다. dependency graph를 만들면 이런 순환을 쉽게 잡을 수 있다. 넷째, golden file drift 검사다. 소스에서 다시 렌더링한 결과와 커밋된 최종 artifact가 다르면 빌드 실패로 처리한다. 이렇게 해야 repo에 있는 내용과 실제 배포 내용이 어긋나지 않는다.

추가로 추천하는 검사는 금지 문구, 필수 섹션, 출력 포맷, 승인 필요 작업 목록이다. 예를 들어 “삭제, 결제, 외부 전송은 승인 필요”라는 문구가 모든 프로덕션 에이전트에 들어 있는지 검사할 수 있다.

progressive disclosure로 토큰 낭비를 줄여라

모듈화된 skill file이 많아지면 모든 지시문을 매번 넣고 싶어진다. 하지만 에이전트가 모든 스킬을 항상 로드하면 컨텍스트가 낭비되고, 작업과 무관한 규칙이 모델을 방해한다. 이때 필요한 패턴이 progressive disclosure다.

기본 시스템 프롬프트에는 절대 바뀌면 안 되는 규칙만 둔다. 정체성, 안전 경계, 승인 기준, 도구 사용의 최상위 원칙처럼 모든 작업에 공통인 내용이다. 작업별 상세 지침은 런타임 도구로 검색하거나, 라우터가 필요한 skill module만 추가한다.

예를 들어 SRE triage agent가 결제 장애를 조사할 때는 로그 조회, 배포 이력 확인, metric 해석 스킬만 불러오면 된다. 법무 문서 검토 스킬이나 마케팅 문안 스킬은 필요 없다. 이렇게 하면 토큰 비용이 줄고, 모델이 불필요한 역할을 섞을 가능성도 낮아진다.

에이전트가 지시문을 직접 바꾸게 하지 마라

운영 중인 에이전트는 새로운 실패 사례를 가장 먼저 본다. 그래서 에이전트가 “이번 장애 유형을 다음부터 더 잘 처리하려면 새 규칙이 필요하다”고 제안하는 것은 유용하다. 하지만 그 자리에서 자기 시스템 프롬프트를 직접 수정하게 하면 안 된다. 자기 수정은 감사와 재현성을 깨뜨린다.

더 안전한 방식은 PR 기반이다. 에이전트가 새 skill module 초안, import 변경, 테스트 케이스를 작성해 pull request를 연다. transpiler가 빌드 검증을 돌리고, eval이 기존 행동을 깨뜨리지 않는지 확인하고, 사람이 리뷰한 뒤 merge한다. 에이전트는 운영 경험을 코드 변경 제안으로 바꾸지만, 배포 권한은 기존 소프트웨어 프로세스에 남긴다.

이 방식은 “자기개선”을 막는 것이 아니라 통제 가능한 자기개선으로 바꾸는 것이다. 중요한 운영 시스템에서는 빠른 적응보다 변경 이력과 되돌릴 수 있음이 더 중요하다.

실행 체크리스트

프롬프트 transpilation은 대기업만의 문제가 아니다. 에이전트가 2개 이상이고, 공통 정책이 반복되고, 시스템 프롬프트가 300줄을 넘었다면 이미 도입을 검토할 시점이다.

실행 순서는 다음과 같다.

• 현재 시스템 프롬프트에서 안전, 도구, 출력 포맷, 도메인 지식을 분리한다.
• 공통 규칙은 shared/, 에이전트별 규칙은 agents/, 업무별 지식은 skills/로 나눈다.
• include, variable, macro를 지원하는 템플릿 빌드 과정을 만든다.
• missing import, undefined variable, circular dependency 검사를 CI에 넣는다.
• 렌더링 결과를 golden file로 저장하고 drift를 검사한다.
• 모든 프로덕션 에이전트에 승인 필요 작업 목록이 포함되는지 테스트한다.
• 에이전트의 지시문 변경은 직접 반영이 아니라 PR로만 받는다.

처음부터 거대한 프레임워크를 만들 필요는 없다. 가장 큰 시스템 프롬프트 하나를 세 파일로 쪼개고, 빌드 결과가 기존 프롬프트와 같은지 검사하는 것부터 시작하라. 그 작은 차이가 나중에 에이전트 운영 사고를 줄인다.