작성자 주: 이미지 API에서 HTTP 451과 image_safety 오류 코드가 반환되면 생성된 이미지가 필터링된 거예요. API 키가 승인되지 않은 게 아니죠. 이 글에서는 APIYI 문서의 설명과 재테스트를 바탕으로 401, 429 오류와 어떻게 다른지, 무엇을 바꿔야 하고 어떤 방식으로 재시도하면 안 되는지 설명해요.
이미지 API를 호출하다 갑자기 HTTP 451을 받고 error.code가 image_safety로 표시되면, 많은 분이 먼저 API 키가 만료됐거나 잔액이 부족한지, 프롬프트에 민감한 단어가 있는지 의심해요. 그래서 API 키를 바꾸거나 충전하고, 계속 재시도하지만 결과는 똑같이 실패하죠. 이 글에서 짚으려는 핵심은 451 image_safety는 생성된 이미지를 차단하며, 검토는 이미지 생성이 끝난 뒤에 이뤄진다는 점이에요. 따라서 계정이 아니라 화면 묘사를 중심으로 원인을 찾아야 해요.
이 글은 막연한 ‘콘텐츠 안전성 안내’가 아니에요. 아래 내용은 APIYI 문서의 HTTP 451 설명과 공개된 익명화 재테스트를 바탕으로 하며, 별도의 테스트 데이터를 만들어내지 않았어요.
핵심 내용: 이 글을 읽고 나면 1분 안에 451을 401, 429와 구분하고, ‘프롬프트의 변수 하나씩 수정하기’ 방식으로 이미지 생성을 다시 요청할 수 있어요.
이미지 생성 시 451 image_safety가 반환될 때 알아야 할 핵심
먼저 가장 중요한 결론부터 살펴볼게요. 모두 오류 메시지와 문서에 명시된 내용이므로 추측할 필요가 없어요.
| 핵심 사항 | 설명 | 도움이 되는 점 |
|---|---|---|
| 검토 대상은 출력 이미지예요 | message에 The generated image was filtered by the safety policy라고 표시돼요 |
API 키나 잔액을 의심할 필요가 없어요 |
| 사후 검토에 해당해요 | API가 이미지를 먼저 생성한 뒤 출력물을 안전성 검토하고, 통과하지 못하면 반환하지 않을 수 있어요 | “프롬프트에는 문제가 없어 보이는데” 차단되는 이유를 이해할 수 있어요 |
| 입력 내용이 위반이라는 뜻은 아니에요 | 사후 검토에서 거부됐다고 해서 프롬프트나 참조 이미지 자체에 명백한 위반 표현이 있다는 뜻은 아니에요 | 단어를 대거 삭제하거나 참조 이미지를 바꾸지 않아도 돼요 |
| 화면 묘사를 수정해야 해요 | 부정문을 추가하는 것보다 의상이나 구도 등 화면 요소를 명확하게 작성하는 편이 효과적이에요 | 문제를 겨냥해 수정해 시행착오를 줄일 수 있어요 |
| 같은 요청을 그대로 재시도하지 마세요 | 같은 조합으로 연속 실패했다면 재시도해도 451이 다시 발생할 가능성이 커요 | 시간과 호출 비용을 아낄 수 있어요 |
먼저 오류 코드를 확인하세요: 451 image_safety와 401, 429의 차이
오류가 발생하면 먼저 상태 코드와 error.code를 확인하세요. 코드부터 수정할 필요는 없어요. 다음은 APIYI 문서에 안내된 451의 내용이에요. (apiyi.com 문서 센터의 FAQ와 업데이트에도 수록돼 있어요.) 응답은 HTTP 451이고, error.code는 image_safety, message는 The generated image was filtered by the safety policy.예요. 여기서 핵심은 generated image예요. 즉, “이미 생성된 이미지”가 안전 정책에 따라 필터링됐다는 뜻이에요.
이 오류는 인증이나 요청 제한과는 전혀 다른 문제예요. 401은 일반적으로 모델에 요청이 전달되기 전에 인증에 실패했다는 뜻이고, 429는 요청이 너무 잦거나 채널이 혼잡하다는 뜻이에요. 잔액 관련 오류는 결제와 관련이 있죠. 이 세 가지는 모두 “무엇을 그렸는지”와 관계없지만, 451은 바로 “무엇을 그렸는지”와 관련이 있어요.
| 오류 | 일반적인 의미 | 발생 단계 | 올바른 대응 | 같은 요청을 그대로 재시도해도 될까요? |
|---|---|---|---|---|
HTTP 451 image_safety |
생성된 이미지가 출력 단계의 안전성 검토를 통과하지 못함 | 이미지 생성 후 | 화면 묘사를 수정하고, 변수 하나씩 확인하기 | 아니요. 같은 조합으로 연속 실패했다면 그대로 재시도하지 마세요 |
| HTTP 401 | API 키가 유효하지 않거나 올바르게 전달되지 않음 | 요청 진입 단계 | API 키와 요청 헤더 확인하기 | 아니요. API 키가 잘못됐다면 재시도해도 소용없어요 |
| HTTP 429 | 요청 제한에 걸렸거나 채널이 혼잡함 | 요청 진입 또는 대기 단계 | 일정 시간 기다린 뒤 재시도하고, 필요하면 채널 변경하기 | 네. 재시도 간격을 점차 늘리는 방식으로 재시도하세요 |
| 잔액 관련 오류 | 한도 부족 | 결제 확인 단계 | 충전하거나 한도 조정하기 | 아니요 |
특히 451과 401에 같은 재시도 로직을 적용하면 안 돼요. 401은 API 키 설정을 수정해야 하고, 451은 프롬프트를 수정해야 해요. 두 오류를 모두 “실패하면 3회 재시도”라는 공통 처리에 넣으면 원인을 파악하기 더 어려워져요.
이미지 생성 후에야 451 image_safety가 나타나는 이유
문서에서는 이 메커니즘을 사후 검수 또는 출력 측 검수라고 불러요. 간단히 말해 요청이 인증을 통과하면 모델이 프롬프트와 참조 이미지에 따라 이미지를 생성하고, 시스템이 생성된 이미지를 다시 안전성 검사해요. 검사에 통과하지 못하면 이미지를 반환하지 않고 451 오류를 바로 반환해요.
그래서 “프롬프트에 민감한 단어가 하나도 없는데도 차단되는” 상황이 생길 수 있어요. 원인은 특정 단어가 아니라 여러 조건이 결합된 결과로 모델이 실제로 생성한 장면이 필터에 걸린 데 있어요. 이를 이해하면 문제를 해결할 때도 ‘금지어 찾기’가 아니라 ‘최종 이미지 제어’에 초점을 맞추게 돼요.
451 image_safety 문서 재테스트 해석
APIYI 문서에는 익명화된 재테스트 결과가 공개되어 있으며, 사용 모델은 gpt-image-2.5-sunburst-vip예요. 인물 참조 이미지에 의상 설정을 요청한 사례로, 얼굴 클로즈업과 전신 정면·측면·후면 이미지, 흰색 배경을 포함해요. 아래 데이터는 모두 문서에 수록된 재테스트 결과이며, 이 글에서는 결과를 해석해 봐요.
| 문서 재테스트 조합 | 결과 | 소요 시간 | 설명 |
|---|---|---|---|
| 원래 프롬프트 + 원래 참조 이미지 | 3/3 실패 | 81.8–95.9초 | 기준 그룹, 일관되게 451 발생 |
| 같은 참조 이미지, 중립적인 일상복을 입은 상반신 이미지로 변경 | 1/1 성공 | 35.7초 | 전신 다중 뷰를 제거하자 통과 |
| 원래 프롬프트에서 참조 이미지를 제거하고 텍스트-이미지 변환 엔드포인트 사용 | 1/1 성공 | 29.1초 | 참조 이미지의 인물 특징을 제외하자 통과 |
| “옷을 완전히 갖춰 입고, 불투명하며, 성적으로 묘사하지 않음”만 추가 | 1/1, 여전히 451 | 216.8초 | 부정문은 효과 없음 |
| 성인 인물, 하이넥 긴소매 상의, 긴 바지, 운동화를 구체적으로 명시 | 3/3 성공 | 65.1–238.6초 | 의상을 긍정적으로 구체화하자 안정적으로 통과 |
문서 재테스트로 살펴보는 451 image_safety의 발생 방식
이 재테스트에서 가장 눈여겨볼 점은 두 번째와 세 번째 그룹이에요. ‘참조 이미지 속 인물 특징’과 ‘전신 다중 뷰’ 중 하나만 제외해도 이미지가 생성됐어요. 문서에서는 이를 근거로, 참조 이미지 속 인물 특징과 전신 다중 뷰가 함께 포함됐을 때 생성 이미지가 필터링됐을 가능성이 더 높다고 해석해요.
문서에서는 단정할 수 없는 점도 분명히 밝혔어요. 이 결과만으로 참조 이미지가 규정을 위반했다고 말할 수 없고, 특정 단어가 트리거였다고 단정할 수도 없어요. 중요한 부분이에요. 451 오류가 발생하면 참조 이미지를 바꾸거나 프롬프트에서 단어를 대거 삭제하는 개발자가 많은데, 그러다 보면 꼭 필요한 이미지 정보까지 빠질 수 있어요.
부정문으로 451 image_safety를 해결하기 어려운 이유
네 번째 그룹은 “옷을 완전히 갖춰 입고, 불투명하며, 성적으로 묘사하지 않음”이라는 문구만 추가했지만 여전히 451 오류가 발생했어요. 반면 다섯 번째 그룹은 성인 인물, 하이넥 긴소매 상의, 긴 바지, 운동화를 구체적으로 명시했고, 세 번 모두 성공했어요.
이유는 간단해요. 부정문은 모델에 ‘무엇을 하지 말아야 하는지’만 알려줄 뿐, ‘무엇을 그려야 하는지’는 알려주지 않아요. 결국 이미지가 어떻게 나올지 여전히 불확실하죠. 긍정적인 묘사로 상의, 하의, 신발을 명확히 지정하면 생성 결과를 더 잘 제어할 수 있고, 출력 단계의 검토도 통과하기 쉬워져요.
소요 시간에 관해서는 문서에서 보조 참고 자료로만 활용해야 하며, 시간만으로 검토가 어느 단계에서 이뤄졌는지 판단해서는 안 된다고 특별히 강조해요. 재테스트에서는 성공과 실패의 소요 시간 범위가 서로 겹치므로, “X초가 넘으면 검토에서 차단된 것”과 같은 판단 로직은 사용하지 않는 게 좋아요.
비교 안내: 위 표와 비교 이미지의 데이터는 모두 APIYI 문서 재테스트에서 가져왔어요. 원문은 apiyi.com 문서 센터의 이미지 출력 안전 검토 FAQ에서 확인할 수 있으니, 직접 겪은 오류와 비교해 보세요.
이미지 생성에서 451 image_safety가 반환될 때 빠르게 점검하기
모델 ID 재확인: 호출 중인 gpt-image 모델 확인하기
451 오류가 확인되면 두 번째로 모델 ID를 확인하세요. 문서에서 재현 테스트에 사용한 모델은 gpt-image-2.5-sunburst-vip예요. 호출 가능한 gpt-image 계열 모델과 각 모델의 이름은 APIYI 모델 목록을 기준으로 확인하세요. apiyi.com 콘솔의 모델 목록에서도 확인할 수 있어요.
모델 ID를 확인하는 이유는 두 가지예요. 첫째, 문제를 점검하는 동안 모델을 바꾸면 어떤 변수가 영향을 줬는지 판단할 수 없어요. 둘째, 모델명을 잘못 입력한 문제를 검토 오류로 오해하지 않도록 해야 해요. 모델명이 잘못되면 보통 다른 오류가 반환되며, image_safety가 반환되지는 않아요.
451 image_safety 문제 해결 시 요청 매개변수
이 글에서는 긴 코드를 다루지 않고, 문제를 해결할 때 고정해야 할 매개변수만 정리해요. 인터페이스는 OpenAI 호환 형식이며, base_url에는 https://api.apiyi.com/v1을 입력하고 SDK의 api_key만 본인의 Key로 바꾸면 돼요.
| 매개변수 | 예시 값 | 문제 해결 중 변경 가능 여부 |
|---|---|---|
base_url |
https://api.apiyi.com/v1 |
변경하지 않음 |
model |
APIYI 모델 목록 기준. 문서 재테스트에 사용한 gpt-image-2.5-sunburst-vip 등 |
변경하지 않음 |
| 엔드포인트 | 이미지 편집(참조 이미지 포함) 또는 텍스트-이미지 변환 | 변경하지 않음. 단, 참조 이미지의 영향을 별도로 테스트하는 경우는 제외 |
| 참조 이미지 | 기존 참조 이미지 | 변경하지 않음 |
| 크기, 수량 등의 매개변수 | 기존 값 유지 | 변경하지 않음 |
prompt |
기존 프롬프트 | 매번 변수 하나만 변경 |
코드에서는 451 전용 분기를 별도로 두는 것을 권장해요. 응답 상태 코드와 error.code를 확인하고, 상태 코드가 451이며 image_safety인 경우 해당 프롬프트를 기록한 뒤 자동 재시도를 중단하고, 수동 또는 규칙 기반으로 프롬프트를 수정하는 절차로 넘기면 돼요. 401은 Key 확인 분기로, 429는 지수 백오프 재시도 분기로 처리하고, 세 경로를 서로 섞지 마세요.
451 image_safety 단일 변수 문제 해결 단계
문서에 나온 문제 해결 방법을 다음 순서로 정리할 수 있어요.
- 나머지 조건 고정: 모델, 엔드포인트, 참조 이미지, 매개변수를 모두 그대로 두고 프롬프트만 변경해요.
- 매번 변수 하나만 변경: 예를 들어 의상만 바꾸거나 뷰 개수만 바꾸세요. 한 번에 세 군데를 바꾸면 안 돼요.
- 부정문 대신 긍정적인 묘사 사용: 상의, 하의, 신발을 구체적으로 적어요. 예를 들어 “목이 높은 긴소매 상의, 긴 바지, 운동화”처럼 작성하고, 필요하면 “성인 인물”이라고 명시하세요.
- 2~3회 재검증: 한 번 성공했다고 안정적이라고 볼 수는 없어요. 문서 재테스트에서는 안정적인 조합이 3회 모두 성공했어요.
- 기존 조합이 연속 실패하면 재시도 중단: 기준 조합이 3회 모두 실패했다면 기존 설정 그대로 다시 시도할 필요가 없어요.
- 원인을 찾을 때만 조합 분리: “전신 멀티뷰 제거”와 “참조 이미지 제거”를 각각 테스트해 어떤 조합이 필터를 작동시키는지 확인하세요.
🚀 빠른 시작: 먼저 깨끗한 환경에서 재현 및 검증하려면 APIYI apiyi.com에서 무료 테스트 크레딧을 받아 보세요. 동일한 Key로 모델과 매개변수를 고정한 뒤 변수를 하나씩 바꿔 비교하고, 검증을 마친 후 운영 환경에 연결하면 돼요.
451 image_safety 프롬프트 수정 예시
문서를 기준으로 다시 테스트하는 방식에 따라 수정 방향을 정리했어요. 실제 업무에 맞게 표현을 조정해도 됩니다.
| 수정 방향 | 비효율적인 표현 | 권장 표현 |
|---|---|---|
| 복장 | 노출하지 않기, 옷을 제대로 입히기 | 목까지 올라오는 긴소매 상의, 긴 바지, 운동화 |
| 인물 | 모델 한 명 | 성인 인물임을 명확히 지정 |
| 시점 | 얼굴 클로즈업과 전신 정면·측면·후면을 한 번에 생성 | 먼저 상반신 이미지를 생성하거나 시점을 단계별로 생성 |
| 스타일 | 섹시하게 연출하지 않기 | 중성적인 일상복, 자연스러운 자세 |
수정의 핵심은 모호한 부분을 줄이는 거예요. 설명이 구체적일수록 모델이 자유롭게 해석할 여지가 줄어들고, 생성 이미지가 필터링될 가능성도 낮아집니다.
자주 묻는 질문 FAQ
Q1: 451 image_safety란 무엇인가요?
이미지는 생성됐지만 출력 이미지가 안전성 검사를 통과하지 못해, 인터페이스가 이미지를 반환하지 않고 HTTP 451과 `error.code`가 `image_safety`인 오류를 반환한다는 뜻이에요. 이는 생성 후에 진행되는 검사로, 출력 측 검사라고도 해요.
Q2: 451 image_safety와 401은 어떻게 다른가요? 둘 다 재시도해야 하나요?
401은 요청이 들어오는 단계에서 발생하며 API 키가 유효한지와 관련이 있어요. 451은 이미지 생성 후에 발생하며 이미지 내용과 관련이 있어요. 두 오류에 같은 재시도 로직을 적용하면 안 돼요. 401은 API 키 설정을 수정하고, 451은 이미지 설명을 바꿔야 해요. 요청을 그대로 재시도해도 두 오류 모두 해결되지 않아요.
Q3: 451 image_safety와 429는 어떻게 구분하나요?
429는 요청 제한에 걸렸거나 채널이 혼잡한 경우예요. 대기 시간을 늘려 재시도하면 보통 해결되고, 필요하면 채널을 바꿀 수도 있어요. 451은 콘텐츠가 필터링된 경우라서, 같은 조합으로 계속 재시도해도 실패해요. `error.code`를 확인하면 구분할 수 있어요. 값이 `image_safety`라면 콘텐츠 문제로 처리하세요.
Q4: 451 image_safety가 발생하면 참조 이미지가 규정을 위반했다는 뜻인가요?
그렇게 단정할 수는 없어요. 문서에서 다시 테스트했을 때는 같은 참조 이미지에 중립적인 일상복을 입은 반신 이미지를 적용하자 이미지가 생성됐어요. 문서의 결론은 참조 이미지 자체가 규정을 위반했다기보다, “참조 이미지 속 인물의 특징과 전신 다중 뷰 조합이 생성 이미지의 필터링을 유발했을 가능성이 높다”는 거예요. 특정 단어가 필터링을 유발했다고 단정할 수도 없어요.
Q5: 사용 중인 gpt-image 모델을 확인하고 451 오류를 재현하려면 어떻게 해야 하나요?
다음 순서대로 진행하는 것을 권장해요.
1. APIYI apiyi.com에 가입해 API 키와 무료 테스트 할당량을 받으세요.
2. 모델 목록에서 gpt-image 계열의 정확한 모델 ID를 확인하세요.
3. `base_url`을 `https://api.apiyi.com/v1`로 설정하고 모델과 매개변수를 고정한 다음, 이 글의 절차에 따라 변수를 하나씩 바꿔가며 원인을 확인하세요.
Q6: 요청에 걸린 시간으로 검사 차단 여부를 판단해도 되나요?
권장하지 않아요. 문서에서도 응답 시간은 참고 자료일 뿐, 그것만으로 검사 단계나 차단 여부를 단정할 수 없다고 안내해요. 재테스트 결과 성공과 실패의 응답 시간 범위가 겹쳤어요. 응답 시간 임계값으로 판단 로직을 만들면 오판하기 쉬워요.
Q7: 프롬프트를 수정한 뒤 한 번 성공했으면 바로 배포해도 되나요?
아직 부족해요. 문서에서는 회귀 테스트를 2~3회 진행할 것을 권장해요. 한 번의 성공만으로는 안정성을 보장할 수 없어요. 재테스트에서 안정적으로 성공한 조합은 3회 중 3회 성공이었어요. 배포 전에 같은 기준으로 검증하는 것을 권장해요.
451 image_safety 핵심 요점
- 검토 대상: 451
image_safety는 생성된 이미지를 필터링하며, API 키를 검사하는 것이 아니에요. - 먼저 오류 코드 확인: 451, 401, 429는 각각 콘텐츠 검토, 인증, 요청 제한에 해당하므로 처리 방법이 달라요.
- 재시도 방식을 혼용하지 마세요: 401이면 API 키를 수정하고, 429이면 지수 백오프로 재시도하며, 451이면 이미지 설명을 바꿔야 해요.
- 변수는 하나씩 점검하세요: 모델, 엔드포인트, 참조 이미지, 매개변수를 고정하고 매번 프롬프트 한 곳만 바꿔 보세요.
- 긍정적인 묘사가 더 효과적이에요: 부정문을 덧붙이기보다 상의, 하의, 신발을 구체적으로 적는 편이 더 확실해요.
- 회귀 검증: 문구를 수정한 뒤 2~3회 다시 검증하고, 안정적으로 통과하면 배포하세요.
- 시작하는 방법: 모델 ID는 APIYI 모델 목록을 기준으로 확인하고, 무료 할당량으로 먼저 비교 검증해 보세요.
요약
이미지 생성에서 451 image_safety 오류가 발생했을 때 기억할 핵심 사항은 다음과 같아요.
- 오류의 성격: 출력 단계에서 검토가 이뤄져 생성된 이미지가 차단된 거예요. API 키, 잔액, 요청 제한과는 관계없어요.
- 오류 분류: 상태 코드와
error.code를 기준으로 451을 401, 429와 구분해 처리하세요. 같은 재시도 로직을 적용하면 안 돼요. - 수정 방법: 다른 변수는 그대로 두고, 부정문 대신 구체적인 옷차림과 구도에 대한 긍정적인 설명을 사용한 뒤 2~3회 회귀 검증하세요.
451이 발생하면 서둘러 API 키를 바꾸지 말고, 먼저 이미지 설명을 더 구체적으로 작성해 보세요. APIYI apiyi.com에서 같은 API 키와 모델을 고정한 채 변수를 하나씩 바꿔 비교하면, 안정적으로 이미지를 생성할 수 있는 문구를 빠르게 찾을 수 있어요.
📚 참고 자료
- APIYI FAQ: 이미지 출력 안전성 검토: 451
image_safety의 정의와 문제 해결 방법 - 링크:
docs.apiyi.com/faq/image-output-safety-review.md -
설명: 응답 형태, 후처리 검토 안내, 단일 변수 기준의 문제 해결 권장 사항을 포함해요.
-
APIYI 업데이트: 이미지 출력 안전성 검토(2026-11): 문서 재검증 기록
- 링크:
docs.apiyi.com/live/2026-11/image-output-safety-review.md - 설명:
gpt-image-2.5-sunburst-vip에서 익명화해 재검증한 결과와 결론의 범위를 담고 있어요.
작성자: APIYI 기술팀
기술 문의: APIYI apiyi.com 홈페이지에서 문의해 주세요. 이미지 API 오류 코드에 관한 자세한 내용은 docs.apiyi.com 문서 센터에서 확인할 수 있어요.
