모듈러 프롬프트 트랜스파일링: 프로덕션 에이전트 프롬프트를 빌드 산출물로 관리하는 법

요약: Google Developers Blog의 모듈러 프롬프트 트랜스파일링 글은 프롬프트를 “긴 텍스트”가 아니라 빌드·검증·배포되는 소프트웨어 산출물로 다루자고 제안한다. 프로덕션 에이전트를 운영한다면 이 관점이 꽤 현실적이다.

AI 에이전트 프로젝트가 실패하는 이유는 모델이 부족해서만은 아니다. 초반에는 한 파일짜리 system prompt로 충분하다. 하지만 운영 단계로 가면 안전 정책, 도구 사용 규칙, 도메인 규칙, 출력 포맷, 에스컬레이션 조건, 고객사별 예외가 계속 붙는다. 어느 순간 프롬프트는 문서가 아니라 변경하기 무서운 control plane이 된다.

Google Developers Blog는 2026년 7월 16일 “Building scalable AI agents with modular prompt transpilation” 글에서 이 문제를 정면으로 다뤘다. 핵심 주장은 단순하다. 프롬프트를 정적 텍스트로 편집하지 말고, 모듈형 skill file을 작성한 뒤 transpiler로 최종 prompt artifact를 빌드하라는 것이다. 빌드 과정에서 import, 변수, 순환 의존성, drift를 검사하면 런타임 장애를 줄일 수 있다.

왜 긴 프롬프트는 운영에서 깨지는가

긴 프롬프트의 첫 번째 문제는 blast radius가 보이지 않는다는 점이다. 코드에서는 함수, 모듈, 테스트, 타입이 변경 범위를 보여준다. 프롬프트에서는 문장 하나가 전체 동작에 영향을 줄 수 있다. “필요하면 사용자에게 확인한다”라는 문장을 추가했더니 원래 자동 처리하던 워크플로우까지 멈추는 식이다.

두 번째 문제는 copy-paste drift다. 여러 팀이 비슷한 에이전트를 만들면 개인정보 처리, 내부 API 사용법, 금지 행동, 승인 규칙을 각자 복사한다. 처음에는 같지만 시간이 지나면 버전이 갈라진다. 보안팀이 한 문서를 고쳤는데 실제 운영 에이전트 7개 중 3개만 반영되는 일이 생긴다.

세 번째 문제는 deferred runtime error다. 템플릿 문자열이나 ad-hoc include를 쓰면 누락된 변수, 잘못된 import path, 순환 참조가 런타임 특정 케이스에서만 터진다. 평소에는 잘 되다가 드문 고객사 설정에서만 프롬프트 렌더링이 실패한다. 이건 모델 품질 문제가 아니라 빌드 시스템 부재 문제다.

프롬프트를 빌드 산출물로 본다는 뜻

프롬프트 트랜스파일링의 핵심은 source와 artifact를 분리하는 것이다. 개발자는 shared/safety.prompt.md, shared/tool_usage.prompt.md, agents/sre_agent.prompt.md처럼 작은 파일을 작성한다. 최종 배포 전 transpiler가 include를 해석하고, 환경 변수와 조건문을 채우고, macro를 펼쳐서 모델이 실제로 받을 하나의 prompt를 만든다.

이 구조는 프론트엔드 빌드와 비슷하다. 우리는 TypeScript를 브라우저에 그대로 넣지 않는다. 소스 코드를 lint, typecheck, bundle, minify한 뒤 산출물을 배포한다. 프롬프트도 마찬가지다. 사람이 읽고 리뷰하기 좋은 소스와, 모델이 실행에 쓰는 최종 artifact는 다를 수 있다.

중요한 점은 빌드가 deterministic해야 한다는 것이다. 같은 입력과 같은 설정이면 항상 같은 prompt가 나와야 한다. 그래야 리뷰, 테스트, 롤백이 가능하다. 빌드 결과를 golden file로 커밋하고 CI에서 재생성 결과와 비교하면 “소스와 배포 프롬프트가 다르게 흘러가는 문제”를 잡을 수 있다.

최소 구현 구조

처음부터 거창한 DSL을 만들 필요는 없다. 디렉터리 구조는 단순하게 시작하면 된다. prompts/shared에는 안전 정책, 개인정보 처리, 도구 사용 공통 규칙을 둔다. prompts/agents에는 역할별 프롬프트를 둔다. prompts/env에는 production, staging, customer-specific 설정을 둔다. 빌드 스크립트는 include 해석, 변수 치환, 순환 참조 검사, 미사용 변수 경고 정도만 해도 효과가 있다.

예를 들어 SRE triage agent라면 공통 안전 규칙, 로그 조회 규칙, 배포 이벤트 조회 규칙, destructive action approval 규칙을 나눌 수 있다. production에서는 remediation 제안은 가능하지만 실행은 승인 필요로 두고, staging에서는 더 넓은 자동 실행을 허용할 수 있다. 이 차이를 한 파일에서 if문처럼 관리하면 리뷰가 쉬워진다.

파일 단위는 너무 잘게 쪼개지 않는 것이 좋다. 한 문장짜리 모듈 100개는 오히려 추적을 어렵게 만든다. 기준은 “변경 주체와 변경 주기가 같은가”다. 보안팀이 관리하는 정책, 도메인팀이 관리하는 업무 규칙, 플랫폼팀이 관리하는 도구 사용 규칙은 분리할 가치가 있다.

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

첫째, missing import를 잡아야 한다. include 경로가 틀리면 빌드가 실패해야지 런타임에서 빈 문장으로 넘어가면 안 된다. 둘째, undefined variable을 잡아야 한다. {{ environment }}를 쓰는데 production 설정에 값이 없으면 배포 전 막아야 한다. 셋째, circular dependency를 잡아야 한다. 프롬프트 fragment를 graph로 보면 순환 참조를 찾기 쉽다.

넷째, golden file drift를 잡아야 한다. CI에서 transpiler를 실행해 최종 artifact를 만들고, 커밋된 artifact와 diff를 비교한다. 차이가 있으면 source 또는 artifact 중 하나가 최신이 아니다. 이 검사는 운영 장애보다 리뷰 누락을 막는 데 더 효과적이다.

다섯째, 정책 스냅샷 테스트를 만든다. 예를 들어 “production agent는 destructive command를 직접 실행한다고 말하면 안 된다”, “개인정보 원문을 외부 API로 전송한다고 말하면 안 된다” 같은 문자열·패턴 테스트를 둔다. 완벽한 eval은 아니지만, 가장 위험한 회귀를 빠르게 잡는다.

런타임 동적 skill 로딩

Google 글은 progressive disclosure도 언급한다. 모든 skill을 매번 base prompt에 넣으면 토큰을 낭비하고, 작업과 상관없는 규칙이 모델을 헷갈리게 한다. 안정적인 control plane은 base prompt에 두고, 작업별 세부 규칙은 런타임에 필요한 것만 retrieve하는 방식이 낫다.

예를 들어 고객지원 에이전트가 결제 질문을 받으면 billing skill만 가져오고, 보안 질문을 받으면 security skill만 가져온다. 이때 중요한 것은 동적 skill도 검증된 source에서만 가져와야 한다는 점이다. 사용자가 올린 문서나 외부 웹 페이지를 skill처럼 실행하면 prompt injection이 된다. skill registry는 버전, 소유자, 허용 에이전트, 테스트 결과를 가져야 한다.

동적 로딩은 관측성도 필요하다. 최종 답변만 저장하지 말고 어떤 skill 버전이 로드됐는지 기록해야 한다. “어제는 맞았는데 오늘은 왜 틀렸나”를 보려면 모델 버전, base prompt artifact hash, loaded skill list, 도구 호출 로그가 함께 남아야 한다.

에이전트가 자기 프롬프트를 고치게 할 때의 경계

Google 글의 흥미로운 지점은 에이전트가 새로운 incident를 해결한 뒤 새 skill module을 draft하고 pull request를 열 수 있다는 부분이다. 이건 강력하지만 위험하게 오해하면 안 된다. 에이전트가 실시간으로 자기 지시문을 바꾸는 게 아니다. 코드 변경 제안처럼 PR을 만들고, transpiler와 eval과 사람 리뷰를 통과한 뒤 배포하는 구조다.

이 경계가 없으면 운영 안정성이 무너진다. 장애를 해결하던 에이전트가 즉흥적으로 안전 규칙을 약화시키거나, 특정 고객사 예외를 전역 규칙으로 바꿀 수 있다. 따라서 agent-authored prompt change는 반드시 제한된 브랜치, 자동 테스트, 정책 리뷰어, 롤백 가능한 배포 파이프라인을 거쳐야 한다.

실무에서는 처음부터 자동 PR 생성을 허용하기보다 “개선 제안 리포트”부터 시작하는 게 낫다. 에이전트가 실패 원인, 필요한 규칙, 예시 입력·출력, 예상 영향 범위를 작성하게 하고, 사람이 이를 skill 파일로 반영한다. 패턴이 반복되면 PR 초안 생성까지 확장한다.

실행 체크리스트

• 현재 운영 중인 에이전트 프롬프트를 공통 정책, 도메인 규칙, 도구 규칙, 출력 포맷으로 분류한다.
• 변경 주체와 변경 주기가 다른 규칙은 별도 fragment로 분리한다.
• include 경로, undefined variable, circular dependency 검사를 빌드 단계에 넣는다.
• 최종 prompt artifact를 golden file로 저장하고 CI에서 drift를 검사한다.
• production, staging, customer-specific 설정을 명시적으로 분리한다.
• 동적 skill 로딩은 검증된 registry에서만 허용한다. 사용자 입력을 skill처럼 실행하지 않는다.
• trace에는 base artifact hash와 loaded skill version을 남긴다.
• 에이전트의 자기개선은 실시간 mutation이 아니라 PR·리뷰·eval·배포 흐름으로 제한한다.