r/promptengineering•5개월 전•9•5
내가 계속 다시 작성하는 시스템 프롬프트 패턴 — 그리고 모든 에이전트에 복사해 넣는 것
The system prompt pattern I keep rewriting — and the one I've copied to every agent
핵심 요약
35일간의 실제 운영 경험을 바탕으로, 추상적인 행동 지침보다 상태 확인 기반의 구체적 제약 조건이 에이전트 성능 유지에 훨씬 효과적임을 공유함.
- 시스템 프롬프트 최적화 — 톤이나 성격 정의 같은 모호한 지침은 제거하고 상태 확인 기반의 구체적 제약 조건을 유지함.
- 상태 기반 제약 — 행동 방식보다는 외부 상태를 참조하는 검증 가능한 조건이 컨텍스트 윈도우 압박 속에서도 더 잘 작동함.
- 명시적 실패 처리 — HTTP 상태 코드 확인이나 파일 경로 지정 등 에이전트가 모호함 없이 즉시 판단할 수 있는 지침이 필수적임.
- 운영 경험 공유 — 실제 크론 작업과 API 호출을 수행하는 프로덕션 환경에서 얻은 실전적인 프롬프트 엔지니어링 노하우임.
35일간의 프로덕션 에이전트 실행 경험. 데모가 아니라 크론으로 실행되고, API를 호출하고, 데이터베이스에 기록하는 실제 자율 작업들임.
여기 시스템 프롬프트에서 삭제하기로 배운 것들:
사라진 것들:
- 톤 지침 ("간결하게 하라", "명확하게 하라", "도움이 되게 하라") — 강제할 메커니즘이 없음. 공간만 차지함.
- 메타 프로세스 지침 ("행동하기 전에 단계별로 생각하라", "엣지 케이스를 고려하라") — 채팅 세션에서는 도움이 되지만, 자율 실행 시에는 노이즈 토큰만 추가함.
- 성격 프레이밍 ("너는 X의 전문가다") — 플레이그라운드에서는 좋아 보이지만, 프로덕션에서는 연극일 뿐임.
- 구체성 없는 부정적 제약 ("실수하지 마라", "데이터 손실에 주의하라") — 에이전트는 모호한 경고에 따라 행동할 수 없음.
살아남은 것들:
- 검증 가능한 조건이 포함된 번호 매겨진 제약: "write_to_db를 호출하기 전에: 레코드 ID가 존재하는지 확인하라. 그렇지 않으면 중단하고 [path]에 오류를 기록하라."
- 명시적 실패 상태: "이 curl이 HTTP 200 이외의 것을 반환하면 중단하라. 정확한 오류를 /tmp/errors.log에 기록하라. 재시도하지 마라. 진행하지 마라."
- 설명이 아닌 파일 경로와 도구 이름.
- 성격이 아닌 범위를 고정하는 한 줄짜리 역할 정의: "너는 2026-04-26 콘텐츠 파이프라인을 관리하고 있다. 작업 디렉토리는 [path]이다."
내가 배우는 데 가장 오래 걸린 패턴: 외부 상태를 참조하는 지침은 컨텍스트 윈도우 압박 속에서도 살아남음. 행동을 설명하는 지침은 윈도우가 가득 차면 사라짐.
"단계별로 생각하라"는 행동에 대한 지침임. "Supabase에 쓰기 전에, 현재 레코드를 가져와서 비교하라"는 상태에 대한 확인임. 전자가 희미해질 때 후자는 유지됨.
당신의 시스템 프롬프트에서 가장 오래 살아남은 것은 무엇인가? 그리고 작동을 멈췄을 때 당신을 놀라게 한 것은 무엇인가?
