그대로 복사하는 것은 권하지 않습니다. 이 저장소는 상용, 오픈소스 AI 도구의 지침 구조를 비교하는 참고 자료로는 유용하지만, 각 파일의 출처와 버전, 사용 권리를 확인하지 않으면 현재 제품의 실제 설정이라고 단정할 수 없습니다.
system-prompts-and-models-of-ai-tools 저장소는 Cursor, Windsurf Agent, VSCode Copilot Agent, Replit Agent, v0, Lovable, Manus, Devin, Perplexity, Gemini, Claude Code, Cline, Bolt, RooCode 등 여러 도구 이름으로 시스템 프롬프트와 모델 관련 텍스트를 모읍니다. 패키지를 설치해 실행하는 프로젝트라기보다 파일을 읽고 비교하는 자료 모음에 가깝습니다.
긴 프롬프트를 처음부터 문장별로 베끼기보다 역할, 제약, 출력 형식으로 나누면 설계 의도가 보입니다.
코딩 도구의 지침이 긴 이유는 “전문 개발자처럼 답하라”는 성격 부여 때문만이 아닙니다. 파일 구조를 읽는 순서, 패치를 표현하는 방식, 도구 호출 조건처럼 제품 코드와 맞물리는 계약이 포함되기 때문입니다. 이 계약을 떼어 다른 챗봇에 붙이면 도구가 없거나 출력 소비자가 달라 제대로 작동하지 않을 수 있습니다.
역할, 제약, 출력 형식은 서로 연결돼 있습니다. “파일을 수정하는 에이전트”라는 역할이 있어도 실제 쓰기 도구가 없으면 실행할 수 없고, XML 출력 형식이 있어도 이를 파싱하는 코드가 없다면 단순한 텍스트 장식이 됩니다. 각 문단 옆에 대응하는 도구와 검증 코드를 적어 보면 재사용 가능한 원칙과 원래 제품에만 필요한 계약이 구분됩니다.
긴 프롬프트에는 같은 규칙이 여러 위치에서 다른 표현으로 반복될 수 있습니다. 이를 그대로 옮기면 새 시스템에서 우선순위가 모호해지거나 사용자 요청과 불필요하게 충돌할 수 있습니다. 반복 문구를 하나의 요구사항으로 묶고 어떤 실패 사례 때문에 존재하는지 설명할 수 있을 때만 자체 지침에 포함하는 편이 좋습니다.
먼저 제품명, 도구 이름, 파일 경로와 특수 태그를 가린 뒤 문장의 목적을 다시 적어 봅니다. 예를 들어 “특정 패치 도구를 호출하라”는 문구의 일반 목적은 변경을 구조화하고 검토 가능하게 만드는 것일 수 있습니다. 자신의 시스템에는 다른 편집 방식이 있다면 목적은 유지하되 호출 형식은 실제 도구 계약에 맞춰 다시 설계해야 합니다.
모델의 성격을 묘사하는 문구는 행동 보장과도 구분합니다. “정확하고 안전한 전문가”라고 역할을 부여하는 것보다 삭제 전 승인, 허용 디렉터리 확인, JSON 스키마 검증처럼 관찰 가능한 규칙이 시험하기 쉽습니다. 참고 프롬프트에서 멋진 표현을 가져오기보다 어떤 입력에서 어떤 행동을 해야 하는지 조건으로 바꾸는 편이 낫습니다.
출력 태그도 다음 구성 요소가 실제로 요구하는 최소 필드만 남깁니다. 원래 제품의 UI가 읽던 상태 메시지나 내부 표식을 그대로 노출하면 사용자에게 불필요한 정보가 보이거나 파서 오류가 생길 수 있습니다. 출력 계약은 샘플뿐 아니라 스키마와 실패 처리 코드로 검증해야 합니다.
저장소를 학습 자료로 쓸 때는 제품 전체를 한꺼번에 비교하지 말고 같은 기능의 문단을 나란히 보는 편이 낫습니다. 예를 들어 코딩 에이전트끼리 파일 수정 규칙을, UI 생성 도구끼리 코드 출력 형식을 비교합니다.
다음 질문을 표로 남기면 재사용할 원칙과 제품 고유 문구가 분리됩니다.
좋은 문구를 찾는 것보다 지시를 실행 가능하게 만든 주변 구조를 읽는 것이 더 중요합니다.
비교표에는 문구의 길이보다 실패 조건을 넣는 것이 유용합니다. 두 코딩 에이전트가 모두 “테스트하라”고 적어도 하나는 테스트 명령을 스스로 찾고 다른 하나는 사용자에게 확인하도록 설계됐을 수 있습니다. 권한이 없거나 테스트가 실패했을 때의 행동까지 비교해야 지침의 실제 차이가 드러납니다.
한 제품의 전체 프롬프트가 길다는 이유로 더 정교하다고 판단해서도 안 됩니다. 도구 정의가 시스템 프롬프트에 포함된 제품과 코드에서 별도로 주입되는 제품은 텍스트 길이를 직접 비교할 수 없습니다. 시스템 메시지, 도구 스키마, 애플리케이션 검증과 사용자 인터페이스를 합친 전체 흐름을 비교 단위로 잡습니다.
먼저 현재 시스템이 자주 실패하는 대표 입력을 모으고 기준 결과를 기록합니다. 그다음 참고 프롬프트에서 추출한 원칙 하나만 추가해 성공률, 불필요한 거절, 도구 호출 수와 응답 길이를 비교합니다. 여러 규칙을 한꺼번에 붙이면 어느 문구가 효과를 냈는지, 어느 문구가 충돌을 만들었는지 알기 어렵습니다.
도구 관련 지침은 정상 사례뿐 아니라 권한 부족, 존재하지 않는 파일, 명령 실패와 부분 결과를 포함해야 합니다. 출력 형식은 필드 누락, 잘못된 타입, 긴 문자열에서 파서가 어떻게 반응하는지 시험합니다. 모델이 규칙을 지키지 않았을 때 애플리케이션이 위험한 실행을 막는지도 별도의 완료 조건입니다.
지시 계층 충돌도 재현해야 합니다. 시스템 제약과 반대되는 사용자 요청, 검색 문서 안의 명령형 문장, 도구 출력에 섞인 프롬프트가 들어왔을 때 원래 데이터와 실행 지시를 구분하는지 봅니다. 공개된 방어 문구를 추가했다는 사실보다 실제 권한 검사가 일관되게 작동하는지가 중요합니다.
수집 저장소의 파일이 제조사가 공식 공개한 현재 프롬프트인지, 과거 버전의 추출본인지, 커뮤니티가 재구성한 자료인지 파일마다 다를 수 있습니다. 서비스 업데이트 뒤에도 이름은 같고 내부 지침은 바뀔 수 있습니다. 따라서 “실제 비밀 지침”이라는 표현보다 출처가 표시된 시점의 스냅샷으로 다루는 편이 정확합니다.
내용이 길고 구체적이라는 이유만으로 진위를 증명하지는 못합니다. 커밋 시점, 파일 안의 제품 버전, 공식 문서와 일치하는 공개 동작을 함께 확인하고, 확인할 수 없는 부분은 가설로 표시해야 합니다.
파일별로 원출처, 수집 방법, 저장소 커밋과 확인 날짜를 함께 기록하면 서로 다른 신뢰 수준을 구분할 수 있습니다. 공식 리포지토리에 공개된 지침, 제품 출력에서 관찰한 문자열, 제3자가 재구성한 문서는 같은 증거가 아닙니다. 출처가 불명확한 파일은 제품의 실제 내부 지침이 아니라 비교용 텍스트로만 다루는 편이 안전합니다.
두 버전의 차이를 볼 때는 단어 추가, 삭제만 보지 말고 대응하는 제품 기능이 바뀌었는지 확인합니다. 새 도구 이름이 들어왔다면 실제 릴리스에 그 기능이 있는지, 보안 문구가 사라졌다면 코드 수준 검사로 이동한 것인지 알 수 없습니다. 프롬프트 diff만으로 제품 정책 변화나 보안 약화를 단정하지 않아야 합니다.
자체 시스템에 참고했다면 어느 시점의 파일에서 어떤 원칙을 가져왔는지 남깁니다. 나중에 원본 저장소가 바뀌어도 현재 지침의 근거를 추적할 수 있고, 오래된 모델명이나 폐기된 도구 계약을 정기적으로 제거할 수 있습니다.
보안 연구자는 프롬프트에 적힌 금지 규칙과 실제 모델의 행동이 일치하는지 살펴볼 수 있고, 개발자는 역할과 도구 계약을 분리하는 방법을 참고할 수 있습니다. 그러나 방어 문구를 공개된 텍스트와 똑같이 붙이는 것만으로 탈옥을 막을 수는 없습니다. 입력 검증, 도구 권한, 출력 검사 같은 코드 수준의 통제가 함께 있어야 합니다.
저작권과 서비스 약관도 별도 문제입니다. 원문 역시 내용을 그대로 상업적으로 복사하기보다 구조와 논리를 참고하라고 주의를 줍니다. 내부 지침에 민감한 정보가 섞여 있다면 재배포 전에 출처와 사용 범위를 확인해야 합니다.
프롬프트 안에 API 키나 실제 내부 주소처럼 비밀이어야 할 값이 있다면 연구 자료라는 이유로 다시 게시해서는 안 됩니다. 값이 이미 공개됐더라도 노출 영향을 확인하고 저장소 운영자나 해당 서비스의 적절한 신고 경로를 검토해야 합니다. 분석에는 비밀값 자체보다 왜 지침에 들어갔고 어떤 경로로 노출됐는지를 최소한으로 기술하면 충분합니다.
공격 문자열을 제품 프롬프트에 그대로 섞어 방어 예시로 넣는 것도 주의가 필요합니다. 모델은 고정된 문구를 회피하도록 보일 수 있지만 표현이 바뀌면 다시 실패할 수 있습니다. 입력 출처 분리, 최소 도구 권한, 실행 전 대상 검증과 출력 스키마처럼 프롬프트 바깥의 통제를 함께 시험합니다.
최종 지침에는 수행할 역할, 절대 넘지 말아야 할 권한 경계, 실제 존재하는 도구의 사용 조건, 기계가 읽을 출력 형식과 실패 시 행동을 최소한으로 남깁니다. 같은 뜻의 수식어와 제품 고유 예시는 줄이고, 예외가 많은 규칙은 코드나 정책 엔진으로 옮길 수 있는지 검토합니다.
각 규칙에는 관찰 가능한 테스트를 연결합니다. “안전하게 행동한다” 대신 삭제 대상 확인과 승인 없이는 실행하지 않는지, “정확한 JSON” 대신 스키마 오류 시 재시도하고 실행을 중단하는지 검사합니다. 모델을 바꾸거나 도구를 추가할 때 이 회귀 테스트를 다시 돌려야 프롬프트가 문서가 아니라 운영 계약으로 유지됩니다.
이 저장소를 가장 생산적으로 쓰는 방법은 “최고의 프롬프트”를 찾는 것이 아닙니다. 여러 제품이 반복해서 두는 역할, 제약, 출력 계약을 추출하고, 자신의 도구와 검증 코드에 맞는 최소 지침으로 다시 설계하는 것입니다.
좋은 결과는 가장 긴 프롬프트를 복제한 상태가 아니라 필요한 규칙이 적은 문장으로 설명되고 코드와 테스트가 나머지를 강제하는 상태에 가깝습니다. 저장소는 설계 선택의 사례집으로 활용하되 진위가 불확실한 문구, 원래 도구에 종속된 계약과 사용할 권리가 없는 원문은 자체 제품에서 분리해야 합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.