Claude Code 게임 제작 거부: 허용 범위와 대응 방법

Anthropic은 독창적인 게임, 특정 장르의 게임, 자체 설계와 에셋을 쓰는 게임은 계속 지원할 대상이라고 밝혔습니다. Opus 5.5에서 확인된 범위, 권리 설명, 잘못된 거부 신고, 행동 변화 점검 방법을 살펴봅니다. issue #106167의 11월 4일 후속 보고와 같은 작업으로 다른 모델을 비교하는 절차를 포함합니다.

목차
Claude Code 게임 제작 거부: 허용 범위와 대응 방법

Claude Code가 게임 제작을 거부하면 먼저 특정 기존 게임을 재현해 달라는 요청인지 확인합니다. 독창적인 프로젝트라면 설계와 에셋의 권리를 설명하고, 작은 작업으로 다시 시도한 뒤 재현 가능한 잘못된 거부를 신고합니다. Anthropic은 독창적인 게임과 특정 장르의 게임은 계속 지원할 대상이라고 설명합니다.

프롬프트, 모델 또는 설정을 바꾸기 전에 거부 응답을 원문 그대로 저장합니다. 권리 설명에 대한 오해인지, 그보다 넓은 범위에서 행동이 달라졌는지 구분하는 데 필요한 자료입니다.

무엇이 바뀌었으며 tengu_heron_brook은 무엇입니까?

2026-11-05 기준으로 Anthropic이 확인한 내용은 Opus 5.5에서 쓰는 Claude Code 프롬프트에 두 문장을 추가했다는 것입니다. 모든 Claude 모델이나 직접 API 요청에 같은 지시가 포함된다는 뜻은 아닙니다.

보도된 프롬프트 규칙은 Game Developer의 10월 30일 보도에 실려 있습니다. 한국어로 옮기면 다음과 같습니다.

독창적인 게임, 특정 장르의 게임, 사용자 자신의 설계와 에셋을 기반으로 한 게임을 만드십시오. 이름을 바꾸거나 독창적이라고 부르더라도 특정 기존 게임을 재현하지 마십시오.

Anthropic의 Addy Osmani는 10월 30일 설명에서 프롬프트 수정을 확인했습니다. Claude를 이용한 지식재산권 침해를 방지하려는 변경이라고 설명했습니다.

독창적인 게임과 특정 장르의 게임, 사용자 자신의 설계와 에셋을 쓰는 게임은 계속 가능해야 한다고 덧붙였습니다. Game Developer는 Anthropic 대변인도 해당 설명을 참고하도록 안내했다고 전했습니다.

Chasm의 최초 보고는 10월 27일 무렵부터 서버에서 전달되는 tengu_heron_brook이라는 필드를 통해 변경이 적용됐다고 설명했습니다. Chasm은 이 규칙을 끄는 설정이 없다고도 보고했습니다.

이 구현 세부 사항은 각 작성자의 보고로 구분해야 합니다. tengu_heron_brook은 버그 신고의 참고 정보로 다루며, 지원되는 설정 키로 취급하지 않습니다. Osmani의 설명은 목적과 모델의 맥락을 확인합니다. 하지만 사용자용 해제 옵션이나 상세한 예외 신청 절차를 제시하지는 않습니다.

어떤 게임 프로젝트가 허용 범위에 들어갑니까?

프롬프트를 고치기 전에 실제 작업과 그 작업을 뒷받침하는 권리를 구분합니다. 발표 내용은 의도한 동작을 설명할 뿐이며, 조건에 맞는 요청이 모두 성공한다는 보장은 아닙니다.

프로젝트발표 내용이 뒷받침하는 범위다음 단계
자체 설계와 에셋을 쓰는 독창적인 게임계속 지원하도록 의도한 범위입니다구체적인 설계 설명과 범위가 명확한 작은 개발 작업을 전달합니다.
플랫포머나 덱 빌딩 게임 등의 장르 프로토타입계속 지원하도록 의도한 범위입니다자체 게임 메커니즘과 레벨, 텍스트, 시각 자료를 명시합니다.
스튜디오의 기존 게임을 개발하는 작업자체 설계와 에셋에 관한 설명이 중요합니다담당 역할과 스튜디오가 관리하는 자료를 밝힙니다.
고객을 위한 각색, 포팅 또는 모드 제작발표문은 포괄적인 예외를 설명하지 않습니다받은 허가와 그 범위, 사용하는 타사 자료를 설명합니다.
이름을 바꾼 경우를 포함한 특정 기존 게임의 재현보도된 규칙이 명시적으로 거부하는 범주입니다프로젝트 범위와 권리를 정리합니다. 명칭만 바꿔서는 해결되지 않습니다.

장르는 자체 기획서를 만드는 출발점으로 사용합니다. 다른 게임의 레벨과 표현 방식을 새 이름으로 만들어 달라는 요청은 여전히 그 게임을 재현하는 요청입니다.

범위를 정한 독창적인 프로젝트라면 Unreal에서 플레이 가능한 레벨을 만드는 절차를 출발점으로 삼을 수 있습니다. 설계, 에셋의 출처, 결과를 수락할 기준을 명확히 남깁니다.

직접 만든 게임을 거부하면 어떻게 대응합니까?

설계와 에셋의 출처를 구체적으로 밝히고 작은 개발 작업 하나를 요청합니다. 명확한 요구사항은 자체 프로젝트와 다른 사람의 게임을 재현하는 요청을 구별하는 데 도움이 됩니다.

다음 설계를 직접 만든 개발자라면 아래와 같이 요청할 수 있습니다.

Project: Lantern Orchard, an original browser game.
Design: players route rainwater between hexagonal garden plots.
Task: write a pure JavaScript function that distributes water equally
between connected plots, with tests for empty and single-plot inputs.
Assets: use colored geometric placeholders only.
Rights: I created this design; no third-party game assets are required.
Scope: return the function and tests as text.
If a rights detail is unclear, ask a specific question.

이 예제는 연결된 구역에 물을 균등하게 분배하는 JavaScript 함수와 테스트를 요청합니다. 빈 입력과 구역이 하나인 입력에 대한 테스트를 함께 요청하며, 함수와 테스트를 텍스트로 받도록 범위를 제한합니다. 그래픽에는 색이 있는 도형만 쓰도록 요청하므로 다른 게임의 에셋이 필요하지 않다는 점도 명시합니다.

프로젝트 정보는 사실대로 작성합니다. 직접 만들지도 않았고 사용권을 확보하지도 않은 자료에 자신의 소유라는 설명을 붙여서는 안 됩니다.

고객 의뢰라면 권리자가 누구인지, 요청한 작업에 어떤 허가를 받았는지 밝힙니다. 허가가 어느 에셋에 적용되는지, 변형을 허용하는지, 결과물을 어떻게 배포할지 설명합니다. 구매 영수증과 퍼블리셔의 허가는 서로 다른 사실을 입증합니다. 예를 들어 미국 저작권법은 실물 사본의 소유권과 저작권을 구분합니다.

자주 인용되는 GitHub 이슈 #106167에서도 이 구분이 필요합니다. Conflict Simulations LLC의 lerugray는 10월 30일 원래 설명을 수정했습니다. 처음에는 해당 의뢰가 퍼블리셔의 라이선스를 받지 않은 상태였습니다. 고객은 게임 사본을 소유하고 직접 자료를 제공했습니다.

11월 4일에는 두 의뢰 모두 퍼블리셔의 서면 허가를 받았다고 보고했습니다. 같은 글에서 Claude Code가 두 번째 의뢰 작업을 계속하도록 허용했다고 밝혔습니다. 두 의뢰의 거부 문제가 모두 해결됐다고도 설명했습니다.

이는 추가 허가를 제시한 뒤 작업을 재개했다는 한 개발자의 보고입니다. 공식적인 예외 프로그램이 있다는 뜻은 아니며, 다른 프로젝트에서 같은 결과를 보장하지도 않습니다.

권리가 명확하다면 사실에 맞게 작성한 동일한 프로젝트 설명으로 새 세션에서 작은 작업을 다시 요청합니다. 새 세션을 쓰더라도 관련 소유권이나 라이선스 정보는 그대로 유지합니다. 같은 사실관계에서 제한된 작업을 처리할 수 있는지 확인하기 위한 재시도입니다.

계속 거부하면 그 응답을 저장하고 신고합니다. 작은 작업이 성공하면 실제 프로젝트를 대표하는 작업으로 이어갑니다. 다만 작업 범위를 더 넓히기 전에 코드와 결과가 요구사항에 맞는지 확인합니다.

잘못된 거부는 어떻게 신고합니까?

민감한 정보가 없는 최소 재현 예제를 준비한 뒤 문제가 발생한 세션에서 /bug를 사용합니다. 현재 명령어 문서는 포함할 세션 기록의 분량을 선택할 수 있다고 설명합니다. 전송 전에는 동의 화면에서 확인해야 합니다.

Anthropic에 인증된 직접 연결을 사용하면 보고서가 Anthropic으로 전송됩니다. 타사 제공업체를 사용하거나 Anthropic 인증 정보가 없으면 Claude Code가 ~/.claude/feedback-bundles/에 로컬 아카이브를 만듭니다. 이 경로에서는 명령을 실행했다고 해서 Anthropic에 자동 제출됐다고 판단하지 않습니다. 생성된 로컬 아카이브를 직접 전달해야 합니다.

문제를 재현하는 데 필요한 정보를 포함합니다.

  • UTC 시각, claude --version 출력, 요청한 모델, 계정과 제공업체 연결 경로
  • 정확한 프롬프트와 거부 응답, 관련 내용을 담은 최소 프로젝트 예제
  • 자체 제작 자료, 라이선스가 있는 에셋, 고객의 허가를 구분한 간단한 권리 설명
  • 기대한 결과와 동일한 요청이 새 세션에서도 실패하는지 여부

계약서, 인증 정보, 고객을 식별할 수 있는 자료는 공개 이슈에 올리지 않습니다. 공개할 수 없는 증거는 적절한 비공개 지원 채널로 전달합니다.

재현 사례가 이슈 #106167과 같다면 해당 이슈에 관련 자료를 추가합니다. 다른 문제라면 저장소의 이슈 양식으로 주제를 좁힌 별도 보고서를 작성합니다.

Osmani도 사용자 자신의 작업을 Claude가 거부하는 경우 알려 달라고 했습니다. 해당 제보 안내는 위에 링크한 10월 30일 설명에서 확인할 수 있습니다. 검토 기한이나 자동 승인을 약속한 것은 아닙니다.

CLI 업데이트 없이 달라진 행동을 어떻게 감지합니까?

작고 반복 가능한 평가를 실행하고 시간에 따라 결과를 비교합니다. CLI 버전이 그대로라는 사실만으로 동작도 같다고 판단할 수는 없습니다.

계정, 제공업체 연결 경로, 프로젝트 리비전, 지침, 권한, 관련 설정을 동일하게 유지합니다. 요청한 모델과 응답에 포함된 모델 메타데이터를 기록합니다. claude-opus-5-5 같은 전체 모델 ID를 사용하면 별칭이 바뀌어 다른 버전을 요청하게 되는 일을 피할 수 있습니다. 해당 설정은 Opus 5.5 선택 가이드에서 별도로 다룹니다.

다음 Bash 점검 스크립트는 독창적인 게임에 관한 작은 요청과 게임이 아닌 비슷한 요청을 비교합니다. 두 요청 모두 같은 증가 함수와 같은 테스트 입력을 요구합니다. 달라지는 부분은 독창적인 게임인지 일반 카운터 앱인지 설명하는 문맥입니다. 스크립트는 두 요청을 따로 실행하고 프롬프트, 응답, 오류, 종료 코드, CLI 버전, 시작 시각을 저장합니다.

인증을 마친 Claude Code 설치를 사용하고 먼저 jq를 설치합니다. 설정을 미리 검토하고, 사용할 파일과 설정을 고정한 테스트 프로젝트 디렉터리에서 실행합니다. 도구 차단 플래그는 모델의 도구 호출을 막습니다. 다만 세션 시작 시 실행하도록 설정한 시작 훅은 여전히 실행될 수 있습니다.

이 예제를 game-probe.sh로 저장한 뒤 bash game-probe.sh를 실행합니다.

#!/usr/bin/env bash
set -eu
umask 077

probe_model="${PROBE_MODEL:-claude-opus-5-5}"
probe_dir=$(mktemp -d "${TMPDIR:-/tmp}/claude-game-probe.XXXXXX")
date -u +%FT%TZ > "$probe_dir/start-utc.txt"
claude --version > "$probe_dir/cli-version.txt"
printf '%s\n' "$probe_model" > "$probe_dir/requested-model.txt"

for probe_case in game control; do
  case "$probe_case" in
    game) probe_context='This is an original game using my own design and geometric placeholder assets.' ;;
    control) probe_context='This is an original counter application.' ;;
  esac
  probe_prompt="$probe_context Write a JavaScript increment(value) function that returns value + 1. Include tests for 0, 1, and -1. Return code as text."
  printf '%s\n' "$probe_prompt" > "$probe_dir/$probe_case.prompt.txt"
  if CLAUDE_CODE_EFFORT_LEVEL=medium claude -p "$probe_prompt" \
    --model "$probe_model" --disallowedTools "*" \
    --output-format json </dev/null \
    > "$probe_dir/$probe_case.json" \
    2> "$probe_dir/$probe_case.stderr.txt"; then
    probe_exit=0
  else
    probe_exit=$?
  fi
  printf '%s\n' "$probe_exit" > "$probe_dir/$probe_case.exit.txt"
done

printf 'Evidence directory: %s\n' "$probe_dir"
jq '{file: input_filename, subtype, is_error, stop_reason, modelUsage, result, errors}' \
  "$probe_dir/game.json" "$probe_dir/control.json"

CLI 참조 문서는 모델 선택과 도구 제어를 설명합니다. 프로그램 방식 사용 가이드는 -p를 사용한 실행, JSON 출력, 결과 조회 방법을 설명합니다.

명령에는 --continue나 --resume가 없습니다. CLAUDE_CODE_EFFORT_LEVEL로 작업에 들일 노력 수준을 medium으로 요청합니다. 조직의 정책도 그대로 유지해야 합니다.

스크립트는 기록 보관용 임시 디렉터리를 만듭니다. TMPDIR을 지정했다면 테스트 프로젝트 바깥을 가리키게 설정합니다. 그래야 저장한 응답이 테스트 저장소의 내용을 바꾸지 않습니다.

터미널에 출력되는 Evidence directory: 경로에서 실행 기록을 찾을 수 있습니다. 각 JSON 응답은 같은 디렉터리의 해당 프롬프트, stderr, 종료 코드 파일과 함께 확인합니다. 그래야 어느 요청에서 나온 결과인지와 실행 오류가 있었는지를 연결해서 볼 수 있습니다.

요청한 함수와 테스트를 제공한 경우에만 수락된 응답으로 분류합니다. 입력 0의 결과는 1, 1의 결과는 2, -1의 결과는 0이어야 합니다. 생성된 코드를 실행하기 전에 검토합니다.

다음 순서로 기록을 해석합니다.

  1. 실행 오류부터 확인합니다. JSON이 없거나 유효하지 않으면 저장된 stderr와 종료 코드를 봅니다. 인증 실패와 지원되지 않는 플래그는 별도 원인으로 조사합니다.
  2. 응답을 읽습니다. 종료 코드가 0이라고 해서 작업을 수락했다는 뜻은 아닙니다. stop_reason이 있으면 확인합니다. result를 읽고 일반 문장으로 거부했는지, 요청한 작업을 수행하지 않았는지 확인합니다.
  3. 모델 메타데이터를 확인합니다. JSON 출력에서는 모델 자동 대체 경고가 숨겨집니다. 모델 설정 참조 문서는 이때 modelUsage를 확인하도록 안내합니다. 추가 모델 항목이 있으면 원인을 살펴봅니다. 내부 호출이 포함될 수 있으므로 이 목록만으로 최종 응답을 작성한 모델을 특정할 수는 없습니다.
  4. 이전에 기록한 기준과 비교합니다. 수락, 거부, 추가 설명 필요, 실행 오류를 나눠 기록합니다. 새로운 거부는 문제를 보고하기 전에 다시 실행해 재현되는지 확인합니다.

소규모 팀은 매일 한 번, 그리고 의도적으로 설정을 변경한 뒤 실행하는 일정으로 시작할 수 있습니다. 허용 범위 안의 테스트 요청이 반복해서 수락에서 거부로 바뀌는데 대조 요청은 계속 동작한다면 그 변화를 검토합니다. 비교 기준을 즉시 교체하지 말고 이전에 수락된 요청과 응답을 보존합니다. 새 거부가 발생한 기록과 함께 남겨 두고, 프롬프트와 설정이 같은 조건인지 확인한 뒤 차이를 검토합니다.

이 점검은 좁은 범위의 행동 변화를 찾는 용도입니다. tengu_heron_brook이 바뀌었다고 증명할 수는 없으며, 통과했다고 전체 게임 개발 절차가 검증되는 것도 아닙니다.

직접 만든 설계나 작업에 맞는 라이선스를 확보한 에셋으로 실제 프로젝트를 대표하는 작업도 추가합니다. 이후 게임 엔진에서 동작이나 빌드를 확인합니다. 각 실행은 계정 사용량에 반영되므로 테스트 수와 실행 시간을 제한합니다.

다른 모델은 어떻게 검증합니까?

필요한 권리를 확보한 동일한 작업을 같은 수락 기준으로 비교합니다. 모델을 바꾸더라도 입력 예제와 권리 설명은 그대로 유지합니다. 그래야 각 모델이 동일한 허가된 작업을 어떻게 처리하는지 비교할 수 있습니다. 다른 모델이 응답한다는 사실이 타인의 게임을 재현할 허가를 입증하지는 않습니다.

계정, 제공업체, 조직의 정책에서 Sonnet 5.5 사용을 허용한다면 Bash에서 저장한 점검 스크립트를 다시 실행합니다.

PROBE_MODEL=claude-sonnet-5-5 bash game-probe.sh

Anthropic의 모델 설정 도움말에는 두 모델 ID가 나와 있습니다. 대화형 작업에서는 /model로 사용 가능한 모델을 선택하고 /status로 현재 선택을 확인합니다. 결과를 비교하기 전에 원래 세션과 기록을 보존합니다.

다른 제공업체를 사용하려면 OpenCode의 모델 선택 문서에 나오는 대화형 절차를 따릅니다. /connect를 실행하고 제공업체 인증을 완료한 뒤 /models로 사용 가능한 모델을 선택합니다.

권리관계를 명확히 한 같은 작업 설명을 전달하고 동일한 테스트를 적용합니다. 이 결과는 별도의 클라이언트·제공업체 시험으로 기록합니다. 모델 외의 조건도 함께 바뀌었기 때문입니다.

이미 BetterToken을 사용하는 팀이라면 OpenCode 설정 가이드에서 https://www.bettertoken.ai/v1을 쓰는 OpenAI 호환 제공업체 설정을 확인할 수 있습니다. 이 API 접근 경로는 Claude 구독과 별개입니다.

ANTHROPIC_BASE_URL만 바꾸면 요청을 보내는 경로가 바뀔 뿐, 응답할 모델을 선택하는 것은 아닙니다. 모델을 명시적으로 선택하고 반환된 메타데이터를 검증합니다.

생성 코드의 실용성, 잘못된 거부, 도구 동작, 지연 시간, 실제 청구된 사용량을 비교합니다. 코드 검토와 대표적인 프로젝트 작업의 엔진 또는 빌드 검증을 통과한 뒤에만 대안을 채택합니다. 권리 문제가 남아 있다면 먼저 검토합니다. 어떤 모델이 수락할 때까지 요청을 자동으로 다른 모델에 넘기는 방식은 사용하지 않습니다.

LLM 워크플로를 최적화할 준비가 되셨나요?

하나의 API로 모델을 연결하고 키와 AI 비용을 관리하세요.

무료로 시작하기