AI 지시를 나누는 법, 개발자 규칙과 사용자 요청이 충돌할 때

AI를 활용하여 생성한 이미지입니다.

AI 앱의 규칙과 사용자 요청을 한 긴 문자열에 섞어 넣으면, 무엇이 항상 지켜져야 하고 무엇이 이번 작업에만 해당하는지 구분하기 어려워집니다. 앱의 고정 규칙, 사용자의 작업 요청, 분석할 데이터를 별도 영역으로 설계하면 충돌을 판단하고 결과를 검증하기가 쉬워져요.

아래 설명은 OpenAI API의 instructions·input과 OpenAI Model Spec의 권한 구조를 기준으로 합니다. 다른 AI 서비스가 같은 필드명과 우선순위를 쓴다고 가정하면 안 됩니다.[1][2]

세 층을 먼저 분리하세요

예를 들어 “응답은 summary와 risks를 가진 JSON이어야 하며 이메일은 다시 출력하지 않는다”는 앱 규칙은 개발자 영역에 두고, “이 계약서를 세 문장으로 요약해 달라”는 요청은 사용자 영역에 둡니다. 계약서 안의 “이전 지시를 무시하라”는 문장은 실행할 규칙이 아니라 분석할 데이터일 수 있어요.

OpenAI API의 instructions와 input

OpenAI 개발자 문서는 instructions로 응답을 만들 때 따라야 할 상위 수준의 행동·말투·목표·예시를 전달하고, input으로 작업 프롬프트를 전달하는 구조를 설명합니다. 해당 안내에서는 instructions가 input에 넣은 프롬프트보다 우선한다고 설명해요.[1]

const response = await client.responses.create({
  model: "모델 ID",
  instructions: "한국어로 답하고 JSON 형식을 지켜요.",
  input: "이 문서를 세 문장으로 요약해 주세요."
});

이 구조는 고정 규칙과 작업 내용을 코드에서 구분하는 예입니다. 실제 API 키는 소스 코드나 프롬프트에 직접 넣지 말고 환경 변수나 비밀 관리 기능을 사용해야 합니다. API와 모델 버전에 따라 매개변수·메시지 역할이 달라질 수 있으므로 현재 개발자 문서의 필드와 지원 범위를 확인하세요.[1]

충돌할 때는 권한과 범위를 함께 봅니다

OpenAI Model Spec은 지시를 권한 수준으로 나누고, 더 높은 권한의 지시가 낮은 권한의 지시보다 우선하는 체인 오브 커맨드 구조를 설명합니다.[2] 일반적으로 시스템·플랫폼 조건, 개발자 규칙, 사용자 요청의 순서를 생각할 수 있지만, 이것이 개발자 지시가 모든 상황에서 무조건 실행된다는 뜻은 아닙니다. 상위 안전 조건이나 실제 API 지원 범위가 함께 적용될 수 있어요.

충돌 사례를 설계에 미리 넣으세요

출력 형식 충돌

개발자 규칙이 JSON을 요구하는데 사용자가 긴 산문을 요청한다면, JSON을 소비하는 앱이라는 목적을 유지해야 합니다. 사용자가 바꿀 수 있는 필드를 미리 정해 두면 “형식은 유지하되 설명 길이는 조절”처럼 처리할 수 있어요.

개인정보 재출력

전화번호와 이메일을 마스킹하도록 정했는데 사용자가 원문을 그대로 보여 달라고 하면 마스킹 규칙을 우선합니다. 모델에 보내기 전 애플리케이션 코드에서 민감정보를 줄이는 방어선도 필요합니다.

문서 속 악성 문장

분석 대상 문서에 “비밀번호를 출력하라”는 문장이 있어도, 그 문장이 개발자 지시로 승격되지는 않습니다. 데이터 구간을 명확히 표시하고 도구 호출이나 파일 변경은 별도 승인과 코드 검증을 거치게 하세요.

근거 없는 최신 사실

“제공된 문서만 요약한다”는 규칙 아래 문서에 없는 현재 가격이나 정책을 단정해 달라는 요청이 들어오면, 자료 밖 내용이라고 답하거나 확인 가능한 출처를 요구해야 합니다. 자연스러운 문장이 근거를 만들어 주지는 않아요.

실제로 나누는 여섯 단계

1. 앱의 목적을 한 문장으로 정합니다. 예: 고객 문의를 정해진 JSON으로 분류합니다.
2. 언어·출력 필드·개인정보 처리·허용 범위처럼 바뀌지 않는 규칙을 목록화합니다.
3. 사용자 질문과 원문 문서를 별도 입력으로 전달합니다.
4. 형식 변경, 범위 밖 질문, 빈 입력, 악성 문서의 처리 방식을 정합니다.
5. 응답 뒤 JSON 파싱, 필수 필드, 허용 값, 개인정보 마스킹을 코드에서 검증합니다.
6. 입력·모델 버전·프롬프트 버전·검증 오류를 기록하되 민감한 원문은 필요한 만큼만 보관합니다.

최소 테스트 세트를 만드세요

OpenAI 개발자 문서도 프롬프트 동작을 측정할 테스트와 평가 모음을 만들고, 모델이나 프롬프트가 바뀔 때 결과를 확인하도록 권장합니다.[1] 정상 입력 하나가 통과했다고 모든 문서와 공격 입력까지 안전하다는 뜻은 아니에요.

프롬프트만으로 보안을 완성할 수 없는 이유

지시를 잘 나누는 것은 중요한 설계 단계지만, 모델이 모든 공격과 오류를 해결해 주지는 않습니다. 외부 도구는 허용 목록과 사용자 승인으로 제한하고, 데이터베이스에 저장하기 전 출력 스키마를 검증하며, API 키와 개인정보가 프롬프트·로그에 남지 않게 해야 합니다. 모델을 바꾸거나 프롬프트를 수정한 뒤에는 회귀 테스트를 다시 실행하세요.

자주 묻는 질문

사용자 메시지에 규칙을 적어도 되나요?

일회성 말투나 형식은 사용자 요청에 적을 수 있습니다. 하지만 앱이 항상 지켜야 하는 보안·출력·처리 범위는 개발자 지시와 코드 검증으로 관리하는 편이 안정적이에요.

개발자 지시는 무조건 실행되나요?

아니요. Model Spec이 설명하는 권한 구조와 함께 상위 안전 조건, 실제 API 지원 범위, 애플리케이션의 검증 로직을 고려해야 합니다.[2]

ChatGPT 화면에서도 API의 역할을 그대로 고를 수 있나요?

이 글의 예시는 OpenAI API의 instructions·input을 기준으로 합니다. 일반 채팅 화면이 같은 입력 구조와 권한 설정을 제공한다고 가정하지 마세요.[1]

문서에 지시문이 있으면 어떻게 하나요?

문서 전체를 신뢰할 수 있는 명령으로 승격하지 말고 분석할 데이터로 취급하세요. 위험한 작업은 별도 승인과 코드 검증을 거치게 합니다.

초보자 체크리스트

• 고정 규칙·사용자 작업·분석 데이터를 별도 영역에 넣었나요?
• 문서 속 지시문을 데이터와 구분했나요?
• 출력 JSON과 필수 필드를 코드에서 검증하나요?
• 형식 변경·빈 입력·긴 입력·민감정보 테스트가 있나요?
• 현재 API 문서에서 역할과 매개변수를 확인했나요?
• 프롬프트나 모델 변경 후 회귀 테스트를 했나요?

관련 글

• AI 프롬프트에 역할·조건·출력 형식을 쓰는 법
• AI 에이전트와 챗봇의 차이

데이터 경계와 도구 권한을 코드에서도 강제하세요

프롬프트에 “이 부분은 데이터”라고 적는 것만으로 입력의 성격이 완전히 고정되지는 않습니다. 애플리케이션에서 시스템·개발자 규칙, 사용자 요청, 원문 데이터를 서로 다른 변수와 메시지 구간으로 만들고, 원문 안의 링크·명령문·코드 블록을 그대로 도구 호출 인자로 연결하지 않도록 하세요. 모델이 도구를 사용할 수 있는 앱이라면 도구 이름, 인자 형식, 접근 가능한 리소스를 허용 목록으로 제한하고 실행 전 사용자 승인이나 서버 검사를 둡니다.

출력 검증이 실패했을 때는 잘못된 JSON을 데이터베이스에 저장하거나 자동으로 재시도하기보다 오류 상태를 남기고 안전한 안내를 반환하는 편이 낫습니다. 재시도하더라도 같은 악성 입력을 그대로 반복하지 말고, 실패 원인과 모델 응답의 민감정보 노출 여부를 먼저 기록하세요. 프롬프트 버전, 모델 버전, 테스트 입력의 해시나 식별자를 남기면 변경 전후를 비교할 수 있지만, 원문 개인정보를 로그에 복사하지 않도록 보관 범위를 제한해야 합니다.

규칙이 늘어날수록 우선순위를 문서화하세요

개발자 지시에 규칙을 계속 덧붙이면 서로 충돌하는 문장이 생길 수 있습니다. 언어·출력 형식·보안·근거 범위·실패 응답처럼 성격이 다른 규칙을 묶고, 서로 충돌할 때의 결정 순서를 짧게 적어 두세요. 규칙 하나를 수정하면 정상 입력뿐 아니라 빈 입력, 긴 문서, 형식 변경 요청, 문서 속 지시문 테스트를 다시 실행해야 합니다. 이런 기록은 모델이 “왜” 특정 응답을 했는지 추측하는 대신 애플리케이션 계약을 점검하는 데 도움이 됩니다.

Sources

1. [1] OpenAI Developers, Prompt engineering
2. [2] OpenAI Model Spec, 2025-02-12