모듈형 프롬프트 transpilation 운영법: 시스템 프롬프트를 빌드 산출물로 다루기

요약: 시스템 프롬프트가 길어질수록 문제는 문장력이 아니라 변경 관리입니다. 모듈형 프롬프트 transpilation은 프롬프트를 텍스트 파일이 아니라 빌드, 검증, 배포되는 소프트웨어 산출물로 다루는 방식입니다.

긴 시스템 프롬프트가 깨지는 진짜 이유

처음 만드는 AI 에이전트는 보통 하나의 시스템 프롬프트로 충분합니다. 역할, 말투, 도구 사용 규칙, 출력 형식 정도만 들어갑니다. 하지만 운영으로 넘어가면 프롬프트가 빠르게 커집니다. 보안 정책, 개인정보 처리, 장애 대응 규칙, 부서별 예외, 고객별 금지어, 승인 절차가 계속 붙습니다.

이때 문제는 토큰 수만이 아닙니다. 더 큰 문제는 변경 범위를 알기 어렵다는 것입니다. 코드에서는 함수, 모듈, 테스트가 변경의 경계를 만들어줍니다. 반면 거대한 프롬프트 파일은 한 문장을 바꿨을 때 어떤 업무에 영향을 주는지 예측하기 어렵습니다.

Google Developers Blog의 modular prompt transpilation 글은 이 문제를 “프롬프트 유지보수성이 에이전트 신뢰성”이라고 정리합니다. 핵심 제안은 단순합니다. 프롬프트를 작은 파일로 나누고, include와 변수, macro를 사용해 최종 시스템 프롬프트를 빌드 산출물로 생성하라는 것입니다.

transpilation 파이프라인의 기본 구조

실무에서는 다음 구조가 가장 이해하기 쉽습니다.

• source prompt: 사람이 수정하는 모듈형 파일
• shared policy: 여러 에이전트가 공통으로 쓰는 안전·개인정보·승인 규칙
• task skill: 특정 업무에만 필요한 절차와 판단 기준
• environment variable: production, staging, read-only 같은 실행 환경 값
• transpiled artifact: 실제 모델에 들어가는 최종 프롬프트
• golden file: 빌드 결과가 의도대로인지 비교하는 기준 파일

예를 들어 SRE triage agent라면 공통 안전 정책, 로그 조회 규칙, remediation 승인 규칙, incident summary 출력 형식을 나눌 수 있습니다. 운영 환경이 production이면 “파괴적 액션은 승인 필요”를 넣고, staging이면 더 넓은 실험 권한을 줄 수 있습니다.

중요한 건 런타임 문자열 조립이 아니라 빌드 타임 검증입니다. 누락된 include, 정의되지 않은 변수, 순환 참조는 배포 전에 실패해야 합니다. 특정 고객 요청이 들어왔을 때야 프롬프트가 깨지는 구조는 프로덕션 에이전트에 맞지 않습니다.

CI에서 반드시 잡아야 할 오류

모듈형 프롬프트를 도입하면 테스트해야 할 항목도 코드와 비슷해집니다.

첫째, dependency graph 검증입니다. prompt A가 shared/safety를 include하고, shared/safety가 다시 prompt A를 include하면 순환 참조가 됩니다. 일반 템플릿 엔진에서는 런타임 오류로 터질 수 있으니 빌드 단계에서 막아야 합니다.

둘째, 변수 스키마 검증입니다. environment, allow_remediation, customer_tier 같은 값은 타입과 허용값이 있어야 합니다. 문자열로 아무 값이나 넣을 수 있으면 테스트가 의미 없어집니다.

셋째, golden file diff입니다. 소스 파일에서 최종 프롬프트를 다시 생성했을 때 커밋된 산출물과 다르면 빌드를 실패시킵니다. 이렇게 해야 “레포의 프롬프트”와 “프로덕션에 들어간 프롬프트”가 달라지는 drift를 줄일 수 있습니다.

넷째, 정책 snapshot 테스트입니다. 예를 들어 “환불 실행은 human approval 필요” 같은 문장이 최종 산출물에 반드시 포함되는지 테스트합니다. 프롬프트는 자유 텍스트지만, 중요한 정책은 테스트 가능한 불변 조건으로 다뤄야 합니다.

progressive disclosure와 같이 써야 하는 이유

모든 skill을 매번 시스템 프롬프트에 넣으면 컨텍스트가 오염됩니다. 에이전트가 지금 하지 않는 업무의 규칙까지 읽으면서 모델의 집중도가 떨어집니다. 그래서 안정적인 base prompt와 task-specific skill을 분리해야 합니다.

base prompt에는 변하지 않는 정체성, 금지 행동, 권한 원칙, 도구 사용의 기본 정책만 둡니다. 세부 업무 절차는 skill 형태로 두고, 필요할 때만 로드합니다. 이 방식은 Agent Skills나 MCP 기반 에이전트 운영과도 잘 맞습니다.

실제 운영에서는 다음 순서가 좋습니다.

1. base prompt는 항상 로드합니다.
2. skill metadata만 먼저 노출합니다.
3. 사용자 요청이 특정 skill 설명과 맞으면 해당 skill 본문을 로드합니다.
4. skill이 추가 reference나 script를 요구하면 그때만 가져옵니다.
5. 작업 후 어떤 skill이 사용됐는지 로그에 남깁니다.

이렇게 하면 토큰 비용도 줄고, 특정 업무 규칙 변경의 영향 범위도 좁아집니다.

에이전트가 프롬프트를 수정하게 할 때의 안전장치

가장 흥미로운 부분은 에이전트가 자기 instruction layer의 개선안을 제안할 수 있다는 점입니다. 예를 들어 장애 대응 에이전트가 새로운 오류 패턴을 해결했다면, 그 경험을 바탕으로 새 skill 모듈을 제안하고 PR을 열 수 있습니다.

하지만 절대 런타임에서 즉시 자기 프롬프트를 바꾸게 하면 안 됩니다. 안전한 방식은 코드 변경과 같습니다.

• 에이전트가 변경안을 파일로 생성합니다.
• transpiler가 include, 변수, 순환 참조를 검증합니다.
• eval 세트로 기존 케이스 회귀를 확인합니다.
• 사람이 diff를 리뷰합니다.
• 승인된 변경만 배포합니다.

이 흐름을 만들면 운영 로그가 프롬프트 개선으로 이어지지만, 통제권은 팀이 유지합니다.

바로 실행할 체크리스트

• 시스템 프롬프트를 base, policy, skill, output format으로 나눴는가?
• include 경로와 변수 스키마를 빌드 단계에서 검증하는가?
• 최종 프롬프트 산출물을 golden file로 비교하는가?
• 중요한 정책 문장은 snapshot 테스트로 보호하는가?
• 모든 skill을 항상 로드하지 않고 progressive disclosure를 쓰는가?
• 프롬프트 변경은 PR, 리뷰, eval을 거쳐 배포되는가?
• 운영 로그에서 나온 개선안을 자동 반영하지 않고 제안으로만 다루는가?

프롬프트 엔지니어링이 커지면 글쓰기 문제가 아니라 빌드 시스템 문제가 됩니다. 시스템 프롬프트를 코드처럼 다루는 팀이 에이전트 운영에서도 더 빨리 안정화됩니다.