모듈형 프롬프트 Transpilation: AI 에이전트 프롬프트를 CI/CD에 넣는 방법
Google Developers Blog가 2026년 7월 16일 소개한 modular prompt transpilation은 AI 에이전트를 제품에 붙이는 팀이 꼭 봐야 할 주제입니다. 핵심은 프롬프트를 채팅창에 붙여 넣는 문장이 아니라 빌드 산출물로 다루자는 것입니다. 모놀리식 시스템 프롬프트는 처음에는 편합니다. 하지만 에이전트가 늘고, 권한이 복잡해지고, 팀원이 여러 명이 되면 금방 깨집니다.
이 글의 검색 키워드는 모듈형 프롬프트, prompt transpilation, AI agent CI/CD, 프롬프트 버전관리입니다. 실무 개발자에게 중요한 질문은 하나입니다. “프롬프트를 코드처럼 리뷰하고 테스트할 수 있는가?” 답이 아니면, 운영 중인 에이전트는 언젠가 추적 불가능한 방식으로 흔들립니다.
모놀리식 시스템 프롬프트의 문제
많은 팀이 에이전트 시스템을 이렇게 시작합니다.
너는 고객지원 에이전트다. 환불 정책을 지켜라. 개인정보를 노출하지 마라. 주문 조회 도구를 사용하라. 사용자가 화내면 공감하라. 관리자 요청은...
처음 50줄은 괜찮습니다. 200줄이 넘어가면 문제가 보입니다.
- 중복 규칙이 생긴다.
- 오래된 정책과 새 정책이 충돌한다.
- 어떤 기능이 어떤 문장에 의존하는지 알기 어렵다.
- 프롬프트 수정 후 영향 범위를 예측하기 어렵다.
- A/B 테스트와 롤백이 수동 작업이 된다.
코드라면 이런 상태를 그냥 두지 않습니다. 모듈로 나누고, 타입을 붙이고, 테스트를 만들고, CI에서 검증합니다. 프롬프트도 같은 방향으로 가야 합니다.
프롬프트 Transpilation이란 무엇인가
Transpilation은 한 형식의 소스를 다른 형식의 실행 가능한 산출물로 바꾸는 과정입니다. TypeScript를 JavaScript로 바꾸는 것과 비슷합니다. 프롬프트에서는 사람이 관리하기 쉬운 모듈 파일을 모델에 전달하기 좋은 최종 시스템 프롬프트로 합칩니다.
예를 들어 저장소 구조는 이렇게 만들 수 있습니다.
prompts/
base.md
policies/privacy.md
policies/refund.md
tools/order-lookup.md
tones/support.md
agents/refund-agent.prompt.yaml
refund-agent.prompt.yaml은 필요한 모듈을 선언합니다.
name: refund-agent
model: gpt-5.6-terra
includes:
- base.md
- policies/privacy.md
- policies/refund.md
- tools/order-lookup.md
- tones/support.md
checks:
required_tools:
- order_lookup
forbidden_terms:
- 관리자 비밀번호
빌드 스크립트는 이 선언을 읽고 최종 프롬프트를 생성합니다. 동시에 누락된 파일, 금지어, 도구 선언 불일치, 토큰 길이 초과를 검증합니다.
CI/CD에 넣어야 할 검증 항목
프롬프트 검증은 “문장이 예쁜가”를 보는 작업이 아닙니다. 운영 사고를 줄이는 정적 검사에 가깝습니다.
최소 검증 항목은 아래와 같습니다.
- 의존성 검증: include된 파일이 모두 존재하는가.
- 도구 검증: 프롬프트가 언급한 tool이 실제 런타임에 등록되어 있는가.
- 권한 검증: 에이전트 역할과 허용 tool scope가 충돌하지 않는가.
- 토큰 예산 검증: 최종 프롬프트가 모델 컨텍스트 예산을 과도하게 쓰지 않는가.
- 금지 패턴 검증: 비밀값, 내부 URL, 운영 계정 정보가 들어가지 않았는가.
- 중복 규칙 검증: 같은 정책이 다른 문장으로 반복되어 충돌 가능성이 없는가.
이 중 1~5번은 자동화가 쉽습니다. 6번은 LLM 리뷰를 보조로 붙일 수 있습니다. 중요한 것은 모든 프롬프트 변경이 PR에서 보이고, CI 결과로 통과 또는 실패가 남아야 한다는 점입니다.
테스트 케이스는 대화가 아니라 시나리오로 만든다
프롬프트 테스트를 단일 질문/응답으로 만들면 쉽게 속습니다. 실제 에이전트는 다단계 대화를 처리합니다. 따라서 테스트는 시나리오 단위가 낫습니다.
case: refund_without_order_number
steps:
- user: "환불해주세요. 주문번호는 몰라요."
- expect:
must_ask: "주문을 식별할 정보"
must_not_call: "refund_create"
- user: "이메일은 test@example.com이에요"
- expect:
may_call: "order_lookup"
must_not_reveal: "internal_notes"
이런 테스트는 완벽한 정답을 강제하지 않습니다. 대신 안전 경계와 필수 행동을 확인합니다. 에이전트 테스트에서 가장 중요한 것은 문장 취향이 아니라 하지 말아야 할 행동을 막는 것입니다.
버전관리와 롤백 전략
프롬프트가 운영 산출물이 되면 버전 전략도 필요합니다. 추천 방식은 세 가지입니다.
첫째, 프롬프트 번들에 semantic version을 붙입니다. refund-agent@1.4.2처럼 기록하면 장애 분석이 쉬워집니다.
둘째, 요청 로그에는 모델명과 프롬프트 번들 버전을 함께 남깁니다. 같은 모델이어도 프롬프트가 다르면 결과가 달라집니다. 나중에 “왜 어제부터 응답이 바뀌었나”를 찾으려면 이 정보가 필수입니다.
셋째, 롤백을 배포 시스템에 넣습니다. 프롬프트 변경이 코드 배포 없이 적용되는 구조라면 더더욱 필요합니다. 잘못된 프롬프트는 코드 버그만큼 빠르게 영향을 퍼뜨립니다.
작은 팀을 위한 현실적인 시작법
모듈형 프롬프트 시스템을 처음부터 거창하게 만들 필요는 없습니다. 작은 팀은 아래 4개 파일만으로 시작해도 효과가 있습니다.
prompts/base.md
prompts/safety.md
prompts/tools.md
prompts/agent.yaml
그리고 CI에서 다음만 검사합니다.
- 파일 존재 여부
- 최종 프롬프트 길이
- 금지어와 비밀값 패턴
- 도구 이름 불일치
이 정도만 해도 “누가 프롬프트를 고쳤는지 모르는 상태”에서 벗어납니다. 이후 에이전트가 늘어나면 역할별 모듈, 도메인 정책, 테스트 시나리오를 추가하면 됩니다.
실행 체크리스트
오늘 적용할 수 있는 순서는 다음과 같습니다.
- 현재 시스템 프롬프트를
base,policy,tools,tone으로 분리한다. - 각 에이전트가 어떤 모듈을 쓰는지 YAML로 선언한다.
- 빌드 스크립트로 최종 프롬프트를 생성한다.
- CI에서 누락 파일, 도구 불일치, 토큰 길이, 비밀값을 검사한다.
- 주요 실패 시나리오 5개를 테스트 케이스로 만든다.
- 요청 로그에 모델명과 프롬프트 번들 버전을 남긴다.
AI 에이전트 운영에서 프롬프트는 더 이상 메모장이 아닙니다. 코드와 똑같이 변경 이력, 리뷰, 테스트, 배포가 필요합니다. 모듈형 프롬프트 transpilation은 복잡한 이론이 아니라, 프롬프트를 운영 가능한 자산으로 바꾸는 가장 현실적인 방법입니다.