한 지원 엔지니어가 봇이 왜 모든 것에 동의하기 시작했는지 묻기 위해 Slack에 시스템 프롬프트 (System Prompt)를 붙여넣었습니다. 세 사람이 서로 다른 버전으로 답변했습니다. 그중 어느 것도 프로덕션 (Production) 환경에서 실행 중인 것과 일치하지 않았습니다. main 브랜치의 문자열이 다시 병합되지 않은 핫픽스 (Hotfix) 브랜치에서 덮어씌워졌던 것입니다.

그날 오후는 4시간을 허비했습니다. 해결책은 단 한 문장이었습니다. 하지만 그 문장을 라이브로 적용하는 데는 풀 리퀘스트 (Pull Request), 스테이징 배포 (Staging Deploy), 그리고 변경 작업 시간 (Change Window)이 필요했습니다.

하드코딩된 시스템 프롬프트는 문제가 생기기 전까지는 괜찮아 보입니다. 하지만 문제가 생기면 매우 예측 가능한 방식으로 비용이 발생합니다.

무엇을 하드코딩이라고 하는가

하드코딩은 단순히 파일 상단에 const SYSTEM_PROMPT = "You are..."라고 적는 것만을 의미하지 않습니다. 다음과 같은 경우도 포함됩니다:

• 전체 프롬프트 텍스트를 담고 있는 환경 변수 (Environment Variables) (SYSTEM_PROMPT=You are a...)
• 지시 사항이 담긴 문단이 포함된 채 리포지토리 (Repo)에 커밋된 JSON 설정 파일 (Config Files)
• 변경을 위해 ollama create가 필요한 SYSTEM 지시문이 포함된 모델 파일 (Modelfiles)
• 마이그레이션 배포 (Migration Deploys) 시에만 업데이트되는 데이터베이스 시드 (Database Seeds)
• 6개월 전 영구적으로 변해버린 피처 브랜치 (Feature Branch) 내의 "임시" 문자열

공통점은 다음과 같습니다: 지시 텍스트를 변경하려면 배포 (Deploy), 재빌드 (Rebuild), 또는 인프라 변경 (Infrastructure Change)이 필요하다는 점입니다. 만약 제품 관리자 (Product Manager)가 엔지니어링 팀의 도움 없이 톤 (Tone)을 조정할 수 없다면, 그 프롬프트가 어느 파일에 있든 상관없이 하드코딩된 것입니다.

초기 단계에서 이것이 허용되었던 이유

프로토타입 (Prototype) 단계에서는 하드코딩이 합리적입니다. 개발자 한 명, 모델 하나, 프롬프트 하나. 플레이그라운드 (Playground)에서 복사하여 app.py에 붙여넣고 배포하면 됩니다. 프롬프트를 수정하는 사람이 코드를 배포하는 사람이기 때문에 피드백 루프 (Feedback Loop)가 빠릅니다.

하지만 프로덕션 환경은 네 가지 방식으로 그 가정을 깨뜨립니다.

더 많은 사람이 프롬프트를 다룹니다. 제품 팀 (Product)은 페르소나 (Persona)를 작성합니다. 법무 팀 (Legal)은 준수 언어 (Compliance Language)를 검토합니다. 지원 팀 (Support)은 실패 사례를 보고합니다. 엔지니어링 팀 (Engineering)은 수정 사항을 병합합니다. 자연어 (Natural Language)에 대한 Git 디프 (Diff)를 검토하는 것은 고통스러운 일입니다. "never"를 "avoid"로 단 한 단어만 바꿔도 동작이 극적으로 변할 수 있지만, 라인 기반의 디프 도구 (Line-based Diff Tools)는 그 위험을 명확하게 드러내지 못합니다.

더 많은 사용자가 안정적인 동작에 의존합니다. 스테이징 (Staging) 환경에서 약간 어색하게 들리는 프롬프트는 한 명의 테스터에게만 영향을 미칩니다. 하지만 프로덕션 (Production) 환경에서의 동일한 프롬프트는 수천 명에게 영향을 미칩니다. OpenAI의 2025년 4월 GPT-4o 업데이트는 이를 극단적인 규모로 보여주었습니다. 시스템 프롬프트의 조정이 모델을 과도하게 아첨하게 만들었고, 수정 사항이 배포되기 전까지 1억 8천만 명 이상의 사용자에게 영향을 미쳤습니다. 저희는 From Playground to Production에서 이러한 운영상의 실패를 분석했습니다.

모델은 사용자 모르게 변화합니다. 제공업체는 사용자의 배포와 무관하게 모델 업데이트를 출시합니다. 하드코딩된 프롬프트는 그대로 유지되지만, 동작은 그렇지 않습니다. LaunchDarkly의 프롬프트 버전 관리 가이드는 이로 인해 발생하는 불일치를 "프롬프트 드리프트 (Prompt Drift)"라고 부르며, 배포 로그에서 변경된 내용이 없을 때는 이를 진단하기가 더 어렵습니다.

반복 주기(Iteration frequency)가 배포 주기(Deploy cadence)를 앞지릅니다.

실무에서의 안티 패턴 (Anti-pattern)

다음은 성숙한 팀에서 하드코딩된 시스템 프롬프트가 만들어내는 결과들입니다. 이 중 하나 이상을 경험해 보셨을 수도 있습니다.

배포 결합 (Deploy coupling)

모든 톤(Tone) 조정이 CI/CD를 거쳐야 합니다. 컴플라이언스 (Compliance) 관련 수정 사항은 동일한 릴리스 트레인 (Release train) 내에서 관련 없는 기능 작업 뒤에서 대기해야 합니다. 팀은 오버헤드 (Overhead)가 너무 높기 때문에 작은 개선 작업을 중단하게 됩니다. 프롬프트 품질은 정체됩니다.

롤백 마찰 (Rollback friction)

프롬프트 변경이 장애를 일으켰을 때, 롤백(Rollback)은 다른 변경 사항이 포함되었을 수도 있는 커밋을 되돌리고, 아티팩트(Artifact)를 다시 빌드하며, 재배포하는 것을 의미합니다. Lee Hanchung의 GPT-4o 아첨(Sycophancy) 사건 분석에 따르면, 빠른 롤백 경로의 부재가 영향 범위(Blast radius)를 증폭시켰습니다. 하드코딩된 프롬프트는 귀하의 가장 느린 롤백 메커니즘을 그대로 상속받습니다.

버전 모호성 (Version ambiguity)

"화요일 오후 3시에 프로덕션에서 실행된 것은 무엇인가요?" 프롬프트가 코드 내에 있으면, 그 대답은 "해당 릴리스의 다른 모든 변경 사항과 뒤섞인, 배포된 커밋 중 무엇"이 됩니다. 프롬프트 전용 버전 관리 시스템은 버전 번호와 차이점(Diff)으로 답합니다.

프롬프트 확산 (Prompt sprawl)

템플릿이 없으면 팀은 지역(Locale)별, 고객 등급별, 실험별로 프롬프트를 포크(Fork)하게 됩니다. system_prompt_v2_final_us.ts와 system_prompt_v2_final_us_legal_review.ts 같은 파일들이 기하급수적으로 늘어납니다. 무엇이 여전히 해당 프롬프트를 참조하고 있는지 아무도 확신할 수 없기 때문에, 아무도 오래된 것을 삭제하지 않습니다.

공급자 간 중복 (Cross-provider duplication)

OpenAI와 Anthropic을 모두 사용하는 팀은 종종 공급자별로 별도의 하드코딩된 문자열을 유지합니다. 문구(Wording)가 어긋나게 됩니다. 한쪽 SDK 호출에 적용된 수정 사항이 다른 쪽에서는 잊혀집니다. 저희의 LLM 불가지론적 아키텍처 가이드에서 대안을 다루고 있습니다.

대신 해야 할 일 (과도한 엔지니어링 없이)

첫날부터 50페이지짜리 PromptOps 플레이북이 필요한 것은 아닙니다. 지시문(Instructional text)을 불변의 코드(Immutable code)처럼 취급하는 것을 멈춰야 합니다.

시스템 프롬프트의 외부화 (Externalize the system prompt)

문자열을 런타임(Runtime)에 가져오는 프롬프트 레지스트리(Prompt registry)로 이동시키세요. PromptForge는 {{variable}} 구문을 사용하여 템플릿을 저장하고, 모든 편집 사항을 버전 관리하며, REST API를 통해 콘텐츠를 제공합니다. 애플리케이션은 fetch를 호출하여 일반 텍스트를 받고, 이를 SDK에 전달합니다. 배포 파이프라인은 실행될 필요가 없습니다.

불변 버전 관리 (Version immutably)

모든 편집은 새로운 버전을 생성합니다. 이전 버전은 읽기 가능하며 프로모션(Promote)할 수 있는 상태로 유지됩니다. 롤백은 Git 히스토리를 되돌리는 것이 아니라, 프로덕션이 버전 N-1을 가리키도록 하는 것입니다.

채널(Channels)을 통한 환경 분리

스테이징(Staging) 환경은 편집 사항을 즉시 확인하기 위해 latest를 사용합니다. 프로덕션(Production) 환경은 승인(Promotion) 시에만 변경되는 stable을 사용합니다. 자세한 내용은 Stable Is the New Production을 참조하세요.

구조적 설정(Structural Config)은 코드 내에 유지

API 키, 모델 ID, 도구 스키마(Tool schemas), 속도 제한(Rate limits), 재시도 정책(Retry policies)은 타입(Types) 및 테스트와 함께 코드 내에 유지됩니다. 오직 자연어 지시 사항(Natural language instruction) 레이어만 외부로 분리합니다. 도구 정의(Tool definitions)를 프롬프트 레지스트리(Prompt registry)에 섞어 넣는 것은 또 다른 혼란을 야기합니다.

전후 시나리오 비교

이전 (하드코딩된 경우):

const SYSTEM = `You are Acme Corp's support agent.
Never discuss competitors. Escalate billing issues to a human.
Respond in a friendly but professional tone.`;
...

법무팀에서 GDPR 관련 문구 추가를 요청합니다. 엔지니어링 팀이 PR(Pull Request)을 올립니다. QA가 스테이징을 테스트합니다. 목요일에 배포가 진행됩니다. PR에 포함된 오타로 인해 에스컬레이션(Escalation) 규칙이 완화됩니다. 금요일에 고객 지원 요청량이 급증합니다. 롤백(Rollback)을 하려면 또 다른 배포가 필요합니다.

이후 (외부화된 경우):

const content = await promptClient.get("acme-support", {
  locale: "en-GB",
  compliance: "gdpr",
...

법무팀이 PromptForge에서 템플릿을 수정합니다. 스테이징은 latest를 통해 이를 즉시 반영합니다. QA가 검증합니다. 누군가 이를 stable로 승인(Promote)합니다. 프로덕션은 다음 요청 시 업데이트됩니다. 만약 에스컬레이션 기능이 망가진다면, 이전 버전을 승인(Promote)하면 됩니다. 며칠이 아닌 몇 분 만에 해결됩니다.

하드코딩이 여전히 합리적인 경우

예외 상황에 대해서는 솔직해져야 합니다.

고정된 프로토타입 및 일회성 스크립트. 코드가 프로덕션 사용자에게 도달할 일이 없다면 자유롭게 하드코딩하십시오.

진정으로 정적이며 법적으로 고정된 프롬프트. 규제 대상인 일부 출력물은 거의 변경되지 않으며, 이미 배포 게이트(Deploy gates)를 반영하고 있는 공식적인 변경 관리(Change control)를 필요로 합니다. 그렇다 하더라도 버전 관리(Versioning)는 감사(Audit)에 도움이 됩니다.

엔드 투 엔드(End-to-end) 기준 10ms 미만의 극단적인 지연 시간(Latency) 예산. 레지스트리 호출은 밀리초(ms)를 추가합니다. 매우 타이트한 경로에서는 공격적으로 캐싱(Caching)하거나 시작 시점에 프리로드(Pre-load)할 수 있습니다. 이는 외부화된 프롬프트를 캐싱하는 것이지, 패턴 자체를 포기하는 것이 아닙니다.

외부 HTTPS 통신이 불가능한 에어갭 시스템 (Air-gapped systems). 빌드 시점 (Build time)에 가져와서 아티팩트 (Artifact)에 포함시키거나, 정해진 일정에 따라 레지스트리 (Registry)로부터 동기화하십시오. 안티 패턴 (Anti-pattern)은 네트워크 호출 그 자체가 아니라, 프롬프트 수정을 애플리케이션 배포 (Deploy)와 결합하는 것입니다.

기다림의 비용

Adaline의 2026 PromptOps 분석에 따르면, 프롬프트를 임시방편 (Ad-hoc)으로 관리하는 팀은 이전 작업을 재현하거나 적절한 버전 관리 (Versioning)가 있었다면 잡아냈을 문제를 디버깅하는 데 프롬프트 엔지니어링 시간의 30–40%를 낭비하는 것으로 추정됩니다.

하드코딩 (Hardcoding)은 이미 보유하고 있는 인프라 (Git, CI/CD)를 사용하기 때문에 더 저렴하게 느껴집니다. 하지만 숨겨진 비용은 장애 대응 (Incident response), 반복 속도 (Iteration velocity), 그리고 어떤 프롬프트가 라이브 상태인지 아무도 모르는 Slack 스레드에서 나타납니다.

Andreessen Horowitz는 AI 시대를 위한 신흥 개발자 패턴 (Emerging Developer Patterns for the AI Era)에서 프롬프트를 소스 코드 (Source code)처럼 취급해야 한다고 주장했습니다. 이는 프롬프트가 소스 코드 안에 존재해야 한다는 뜻이 아닙니다. 프롬프트 역시 소스 코드가 받는 것과 같은 운영상의 엄격함, 즉 버전 관리 (Versioning), 리뷰 (Review), 롤백 (Rollback), 그리고 명확한 소유권 (Ownership)을 누릴 자격이 있다는 의미입니다. 프롬프트 레지스트리 (Prompt registry)는 애플리케이션 바이너리 (Application binaries)와 결합하지 않고도 그러한 엄격함을 제공합니다.

시작하기

가장 자주 변경되는 시스템 프롬프트를 선택하십시오. 보통 고객 접점인 지원 (Support), 영업 (Sales), 또는 온보딩 (Onboarding) 관련 프롬프트입니다.

1. PromptForge에 템플릿으로 복사합니다.
2. 한 서비스 내의 하드코딩된 문자열 하나를 API 호출 (API fetch)로 교체합니다.
3. 프로덕션 (Production) 환경은 stable을, 스테이징 (Staging) 환경은 latest를 가리키도록 설정합니다.
4. 테스트 수정을 수행하고, 이를 승격 (Promote)시킨 후, 롤백 (Rollback)이 작동하는지 확인합니다.

단 하나의 프롬프트라도 외부화하면 그 차이를 느낄 수 있을 만큼 충분합니다. 안티 패턴은 특정 도구를 사용하지 않는 것이 아닙니다. 매주 변경되는 설정 (Configuration)처럼 동작하는 지시문 텍스트를 배포 아티팩트 (Deploy artifacts)처럼 취급하는 것이 바로 안티 패턴입니다.

배포 워크플로 (Deployment workflow)에 대해서는 Decoupling Prompt Updates from CI/CD를 읽어보세요. 멀티 프로바이더 (Multi-provider) 설정의 경우, LLM Agnostic Architecture with REST Prompts를 참조하십시오.

원문은 PromptForge에 게시되었습니다.