프로덕션에서 실패하지 않는 AI 에이전트 시스템 프롬프트 작성법

목차

2026년 7월 업데이트.

TL;DR: 프로덕션 시스템 프롬프트는 5개의 레이어로 구성된다: 정체성(에이전트가 누구이고 무엇을 할 수 없는지), 컨텍스트(환경에 대해 무엇을 아는지), 작업(성공이 단계별로 어떻게 보이는지), 출력 형식(가장 과소평가된 레이어), 엣지 케이스(입력이 실패할 때 무엇을 할지). 대부분의 프롬프트는 레이어 4와 5를 건너뛰기 때문에 실패한다. 출력 형식을 먼저 작성하라 — 실제로 원하는 것을 정확하게 생각하도록 강제한다.

[운영자 관점] 나는 컨설팅 브랜드와 Pickleland(텍사스주 플루거빌에 있는 피클볼 시설)에서 30개 이상의 AI 에이전트를 프로덕션에서 운영하고 있다. 내가 새로 작성한 것보다 다시 작성한 시스템 프롬프트가 더 많다. 대부분 첫 번째 버전이 테스트에서는 잘 작동하다가 프로덕션에서 조용히 품질이 저하되기 때문이다. 오래 지속되는 프롬프트를 작성하는 방법에 대해 내가 배운 것이다.

아무도 인정하지 않는 시스템 프롬프트 문제

대부분의 에이전트 시스템 프롬프트는 약 20분 만에 작성되고, 두세 가지 예시로 테스트되고, 그 후에는 다시 건드리지 않는다. 모델이 배포된다. 잠시 동안은 잘 작동한다. 그러다가 무언가가 바뀐다 — 입력이 더 지저분해지고, 모델이 업데이트되고, 새로운 엣지 케이스가 나타난다 — 그러면 에이전트는 쓰레기를 생성하기 시작한다. 조용하게. 대규모로.

문제는 원래 프롬프트가 나빴던 게 아니다. 대부분의 프롬프트가 ‘행복한 경로’를 보여주기 위해 작성된다는 것이다. 에이전트를 구축할 때 염두에 두었던 입력을 위해 설계되었지, 에이전트가 실제로 볼 전체 입력 분포를 위한 게 아니다.

프로덕션 시스템 프롬프트의 5개 레이어

내가 작성하는 모든 시스템 프롬프트를 5개의 레이어로 생각한다. 이 순서로 나타날 필요는 없지만 모두 존재해야 한다.

레이어 1: 정체성

정체성은 모델에게 자신이 누구인지와 운영상의 제약이 무엇인지를 알려준다. 롤플레이 캐릭터가 아니라 — 이 에이전트가 무엇을 하고 하지 않는지에 대한 기능적 정의다.

강력한 정체성 레이어는 세 가지 질문에 답한다:

• 이 에이전트는 무엇을 담당하는가?
• 명시적으로 담당하지 않는 것은 무엇인가(에스컬레이션하거나 거부해야 하는)?
• 어떤 기준을 유지하는가?

‘하지 않는’ 범위를 명시하는 것이 대부분의 운영자가 건너뛰는 부분이다. 이것 없이는 모델이 자신의 영역 밖에서 도움이 되려고 할 것이고 — 그게 바로 문제가 생기는 지점이다.

레이어 2: 컨텍스트

컨텍스트는 에이전트가 자신의 환경에 대해 알고 있지만 사용자 메시지에는 없는 것이다. 현재 날짜와 시간(동적으로 주입 — 모델의 내부 시간 감각은 절대 믿지 말 것), 외부 시스템의 관련 상태, 작업 설명에서 명확하지 않은 비즈니스 규칙이 포함된다.

내가 검토하는 대부분의 에이전트는 컨텍스트가 부족하다. 가정하지 마라. 주입하라.

레이어 3: 작업

작업 레이어는 에이전트가 단계별로 무엇을 하는지 설명한다. “고객 돕기”가 아니라 — 실제 의사결정 흐름이다. 지시문이 아니라 순서도처럼 작성하라. 순서도는 모호한 경우에 원하는 것을 추론할 필요성을 줄이기 때문에 더 견고하다.

레이어 4: 출력 형식

이것이 가장 과소평가된 레이어이며 무음 실패에 가장 책임이 있는 것이다.

출력 형식을 정확하게 지정하지 않으면 모델은 사람 독자에게는 올바르게 보이지만 다운스트림 파싱을 깨트릴 만큼 일관성이 없는 출력을 생성한다. 출력 형식을 먼저 작성하라. 구조화된 출력에는 정확한 스키마를 지정하라. 산문 출력에는 구조, 길이, 톤 제약을 지정하라.

고위험 에이전트에는 정의된 JSON 스키마와 함께 Claude의 구조화된 출력을 사용한다.

레이어 5: 엣지 케이스

엣지 케이스 레이어가 답하는 질문: 입력이 모호하거나, 불완전하거나, 잘못된 언어이거나, 적대적이거나, 명확히 잘못된 경우 에이전트는 무엇을 하는가? 각 엣지 케이스에 대해 모델에게 명시적인 응답 경로를 제공하라.

시간이 지나면서 시스템 프롬프트를 유지하는 방법

프로덕션 시스템 프롬프트는 살아있는 문서다:

1. 주간 스팟 체크. 각 고위험 에이전트의 5~10개의 무작위 출력을 예상 출력과 대조하여 검토한다.
2. 모델 업데이트 후 검토. 기반 모델 버전이 바뀔 때마다 평가 프레임워크의 전체 골든 세트에 대해 에이전트를 실행한다.
3. 엣지 케이스 로그. 에이전트가 잘못 처리한 입력에 대한 지속적인 로그를 유지한다. 세 개 이상의 항목이 패턴을 공유할 때 명시적인 규칙을 추가한다.
4. 프롬프트 버전 관리. 모든 중요한 변경사항은 프롬프트 파일 상단에 버전 주석을 받는다.

자주 묻는 질문

프로덕션 시스템 프롬프트는 얼마나 길어야 하나요?

5개 레이어를 모두 커버할 만큼 충분히 길게. 2분 안에 읽고 드리프트를 발견할 만큼 충분히 짧게. 대부분의 에이전트에서 200~600단어다.

복잡한 작업을 여러 에이전트로 분할해야 하는 시점은 언제인가요?

작업에 다른 컨텍스트, 다른 출력 형식, 또는 다른 오류 처리가 필요한 두 가지 이상의 별개 모드가 있을 때. 패턴에 대해서는 이벤트 트리거 대 스케줄 에이전트를 참조하라.

테스트에서 작동했던 프롬프트가 프로덕션에서 실패하는 가장 일반적인 이유는 무엇인가요?

테스트 입력이 프로덕션 분포를 대표하지 않았다. 상상된 입력이 아닌 실제 프로덕션 트래픽에서 테스트 세트를 구축하라.