스케치를 포토리얼 렌더로 변환

건축 도면(손 스케치, 입면도, SketchUp 또는 Revit 내보내기, 컬러 사이트 플랜, PDF 시트)을 풀프레임 DSLR로 촬영한 것 같은 사진으로 변환하며, 설계를 정확히 그대로 유지합니다. Gemini가 픽셀을 생성합니다 (gemini-3-pro-image, 레거시 generateContent). 당신의 역할은 해당 호출을 중심으로 도면 읽기, 브리프 작성, 비용 관리, 그리고 결과물이 제공되기 전에 모든 결과를 소스와 비교하여 확인하는 것입니다.

scripts/render.py가 메커니즘을 처리합니다. 패스당 한 번의 모델 호출로, 소스를 모델이 제공하는 10가지 화면 비율 중 가장 가까운 비율로 가장자리 확장(모델이 재구성할 필요가 없도록), 해당 비율로 렌더링, 소스 자체 사각형을 다시 크롭백, 재프레이밍 플래그 지정, 그리고 전후 비교 시트를 작성합니다. 아래 경로는 이 스킬의 폴더를 기준으로 합니다. render.py check를 통과한 Python을 사용하여 절대 경로로 스크립트를 호출하세요.

실행 환경

라이브 렌더링은 사용자 자신의 머신에서 GOOGLE_API_KEY가 설정된 Claude Code가 필요합니다. 로컬 셸이나 파일 시스템(예: claude.ai 채팅, Claude API 스킬 컨테이너)이 없는 경우, 도면을 읽고 브리지를 작성할 수 있으며 Python과 Pillow가 있으면 --prompt-only 프롬프트를 표시할 수 있지만 렌더링은 할 수 없다고 명확히 말하세요. 절대 키를 제공하겠다고 제안하지 마세요.

상시 정책 - 인용하되, 절대 의역하지 마세요

2026년 8월 28일에 제공된 사용자의 렌더 정책:

작업: 비용 절감을 위해 입력 이미지를 먼저 1K 품질로 렌더링합니다.

100% 정확한 기하학적 구조, 축척 및 비율을 유지합니다.

환각 현상 없음, 명시적으로 지시하지 않는 한 요소 추가/제거 없음.

재료를 실제 마감재(예: 테라코타 지붕, 사실적인 나무, 수영장, 조경)로 교체합니다.

출력물은 고급 DSLR 건축 사진처럼 보여야 합니다.

모든 편집 및 수정은 확인될 때까지 1K 품질로 유지됩니다.

승인 후, 동일한 이미지를 4K 품질로 업스케일합니다:

선명하고 세밀한 정확도를 제공하며 흐림이나 번짐이 없어야 합니다.

확대했을 때 모든 요소가 실제처럼 보이고 사실적이어야 합니다.

참조 이미지의 정확한 기하학적 구조와 디테일 충실도를 유지합니다.

최종 규칙: 항상 편집을 1K로 먼저 렌더링하고, 명시적 확인 후에만 4K로 향상시킵니다.

2026년 8월 31일에 제공된 사용자의 비교 시트 요구 사항:

앞으로 모든 렌더에서, 모든 렌더 후에 교차 검증을 위한 비교 시트를 원합니다. 모든 곳에 업데이트하세요.

둘 중 하나를 다시 말할 경우 인용하세요. 비용 수치 및 배경: references/policy.md.

하드 게이트

지출 전에 물어보세요. 청구 가능한 호출 전에 사용자에게 이미지 수, 등급 및 비용을 알리고 명시적인 동의를 기다리세요. 그런 다음에만 --spend-ok를 추가하세요. 스크립트가 이를 강제합니다. --spend-ok 없이 실행하면 견적을 출력하고 키를 읽지 않고 종료 코드 3으로 종료됩니다. 동의는 정확히 견적한 내용을 다룹니다. 이후의 각 수정, 패치 또는 실패한 패스 재실행은 새로운 지출이므로 견적(이미지 1개, 1K, 최대 USD 0.268)을 제시하고 다시 동의를 받으세요. 계획과 가격을 하나의 메시지로 제시할 수 있습니다("다음: 뷰 02 수정 - 지붕 색상 수정. 1K 이미지 1개, 최대 USD 0.268. 진행할까요?"). 견적은 이미지 요율 기준입니다. Google은 각 시도의 입력 이미지(약 USD 0.0011), 프롬프트 텍스트 및 모델의 사고 토큰에 대해서도 비용을 청구하므로 실제 요금이 견적보다 약간 더 높을 수 있다고 말하세요.
4K는 이미지당, 승인 후에만 가능합니다. 사용자가 비교 시트에서 보고 이름으로 승인한 단일 이미지에 대해서만 upscale --confirmed를 실행하세요. 세트에 대해 "좋아 보인다"는 해당 세트를 4K로 가져가라는 승인이 아니며, "더 선명하게 해달라"는 4K로 다시 렌더링하라는 승인이 아닙니다. 어떤 단일 이미지인지 물어보세요. 다른 지출과 마찬가지로 견적을 제시하세요: 파일 이름, 이미지 1개, 4K, 최대 2회 시도, 최대 USD 0.48(시도당 USD 0.24).
절대 4K에서 반복하지 마세요. 모든 것을 먼저 1K에서 수정하세요. 4K 패스는 결함을 충실히 재현합니다. 4K 파일은 최종본이며 절대 수정되지 않습니다.
모든 패스는 시트를 제공하며, 당신이 먼저 검토합니다. 각 패스 후, Read 도구로 시트 이미지를 열고 references/review-checklist.md로 검토하세요. 발견된 문제와 함께 판정(일치 / 사소 / 주요)을 결정한 다음, 렌더링, 시트 및 시트가 보여주는 내용을 전달하세요. 시트 없이 렌더링하는 것은 완료된 것이 아닙니다.
절대 덮어쓰지 말고, 이 스킬 폴더 안에 쓰지 마세요. 스크립트는 파일 이름을 재사용하지 않으며 스킬 내부의 출력 폴더를 거부합니다. 직접 전달된 파일이나 소스를 이동, 이름 변경 또는 교체하지 마세요.
채팅에서 API 키를 절대 처리하지 마세요. 키를 요청하거나, 수락하거나, 출력하거나, 파일에 쓰지 마세요. 사용자가 키를 붙여넣으면 채팅에 노출되었다고 말하고, AI Studio에서 삭제하고 다시 생성해야 하며, 환경 변수로 새 키를 설정하는 방법을 알려주세요. 사용자 환경 변수가 .env 파일보다 낫고, 복사, 압축 또는 업로드되는 스킬 폴더에 .env를 절대 두지 마세요.
프로젝트당 한 번, 첫 번째 라이브 호출 전에 도면이 Google의 Gemini API(generativelanguage.googleapis.com)로 전송되어 렌더링된다고 말하세요. 클라이언트 도면은 기밀입니다. 사용자의 동의를 받으세요.
모든 재시도는 청구됩니다. 이미지를 반환하지 않은 시도도 포함됩니다. 프롬프트를 수정하세요. 나쁜 프롬프트를 구제하기 위해 --attempts를 올리지 마세요(스크립트가 최대 3회로 제한함).

이 스킬이 할 수 없는 것

파이프라인은 도면 자체의 카메라를 유지합니다. 건물의 다른 면, 새로운 각도, 확대/축소, 자르기 또는 다른 화면 비율을 보여줄 수 없으며, 평면도를 원근법 또는 눈높이 뷰로 바꿀 수 없습니다: 트리에서 평면도가 그림으로 전송되면 다른 집으로 돌아왔고, 프롬프트 전용 카메라 이동은 매번 다른 별장을 제공했습니다(references/art-direction.md 섹션 13). 사용자가 이러한 작업을 요청하면 지출하지 말고 설명한 다음 3D 모델에서 해당 뷰의 새 내보내기를 요청하고 해당 내보내기를 새 작업으로 렌더링하세요. revise 또는 patch 메모에 카메라 또는 프레이밍 변경 사항을 절대 넣지 마세요. 그렇게 하면 스크립트가 !! CAMERA / FRAMING WORDS를 출력합니다.

또한 레이블 지우기, 패널 등록, 가파른 항공 사진 타일링 또는 배경 합성을 수행하지 않습니다(트리가 렌더링 주변에서 수행했던 작업, references/failure-modes.md). 이러한 작업이 효과적이었던 경우, 지출하기 전에 사용자에게 문구만으로는 충분하지 않을 수 있다고 경고하세요.

설정 확인 (머신당 한 번)

python scripts/render.py check를 실행하세요. Python, Pillow 및 PyMuPDF 버전, 시트 글꼴, 모델 ID 및 키가 발견된 위치(소스만, 값은 절대 아님)를 출력합니다. 키가 없으면 키를 설정하는 단계를 출력합니다. 가져오기에 실패하면 해당 Python으로 python -m pip install -r scripts/requirements.txt를 실행하세요. 키가 있으면 check --online은 무료 models.get 메타데이터 호출을 수행하여 키와 모델이 작동함을 증명합니다. 청구되지 않습니다.

단일 뷰 워크플로우

1. 인테이크

사용자로부터 다음을 받습니다: 디스크 경로상의 파일(붙여넣은 이미지에는 경로가 없음 - 파일 위치를 물어보세요), 뷰 이름, 그리고 네 가지 필드의 메모 - 재료, 조명, 환경, 기타(각각 선택 사항). 도면에서 모호하여 그림을 변경할 수 있는 사항(이 평평한 영역은 잔디인가 포장인가? 태양은 어느 방향에서 오는가?)은 추측하지 말고 물어보세요. 입력을 분류하세요:

여러 패널(층, 입면도)이 있는 시트 또는 뷰가 1페이지에 없는 PDF: 하나의 패널 또는 페이지를 내보내도록 하거나, ... Input 폴더에 직접 새로운 파일로 자르되, 작업당 하나의 뷰로 잘라내세요. 비교 시트가 해당 패널을 렌더링과 짝짓는다고 사용자에게 알리세요. 밀집된 가구 레이아웃은 트리에서 생성적으로 실패했습니다. 지출하기 전에 그렇게 말하세요.
파이프라인이 처리할 수 없는 요청(위 참조): 지출 전에 중지하고 설명하세요.
타이틀 블록, 영역 일정, 레이블 또는 법적 경계선이 있는 시트: 이러한 항목은 정확히 그려진 대로 유지되어야 하며 모델은 텍스트를 유지할 수 없습니다(브리프가 금지함). 렌더링 전에 잘라내고 렌더링 외부의 최종 시트에 변경되지 않은 상태로 다시 배치하세요. 법적 경계선은 주의 사항에 이름을 지정하여 벽으로 바뀌거나 지워지지 않도록 하세요.
도면과 모순되는 요청(그려진 엉덩이 지붕 대신 평평한 지붕): 지적하고 물어보세요. 정책은 사용자가 명시적으로 달리 말하지 않는 한 기하학적 구조를 그려진 대로 유지합니다.

2. 도면 읽기 및 브리프 작성

먼저 무료 --prompt-only 패스를 항상 --out과 함께 실행하세요(이 스킬 폴더 외부, 예: assets/test_sketch.png의 경우 스크래치 폴더). PDF의 1페이지를 래스터화하고 패딩된 입력을 <out>/_work/prompt-only/<view>_<tier>_padded.jpg(최대 2400픽셀)에 쓰며, 이는 보기 가장 쉬운 파일입니다. Read 도구로 열고 연구하세요. 그런 다음 references/art-direction.md에 따라 브리프 JSON을 작성하세요:

{"elements": ["2층 블록, 엉덩이 지붕, 프레임 왼쪽 절반", "..."],
 "finishes": ["따뜻한 오프화이트 석회 플라스터 벽", "..."],
 "cautions": ["프레이밍: 빌라는 너비의 20-78%를 차지하고 처마는 높이의 37%; 커지거나 재중앙화되거나 하늘이 추가되면 결과는 실패", "..."]}

elements: 모든 건물 요소, 개구부, 지붕 형태, 층, 난간, 수영장, 포장 구역, 식재 매스 및 가구 항목, 위치 및 개수(최대 30개 항목, 160자).
finishes: 실제 재료(최대 15개, 120자).
cautions: 측정 가능한 프레이밍 앵커를 먼저, "...하면 결과는 실패" 테스트와 함께; 그런 다음 층 수, 객체가 아닌 제도 아티팩트, 이 프레임에 특정한 부정적 요소(최대 10개, 160자).

브리프를 짧게 유지하세요 - 긴 브리프는 트리에서 프레이밍을 잃었습니다. 작업 옆에 저장하세요(예: <out>/_briefs/<view>.json). 더 긴 재료 또는 설정 텍스트는 --materials / --environment에 속합니다(메모는 총 4000자 가능).

3. 플래그 선택

지붕이 테라코타가 아닌 경우(평평한 슬래브, 멤브레인, 슬레이트, 금속, 녹색 지붕)? --no-terracotta-example를 추가하고 브리프에 지붕 주의 사항을 넣으세요("모든 지붕은 평평함 - 타일 없음, 경사 없음, 테라코타 없음" 또는 "날개 지붕은 평평한 슬래브 - 타일 없음, 경사 없음") 그리고 실제 지붕 마감재를 명명하세요. 공유 충실도 브리프는 테라코타를 예시 마감재로 사용하며 평평한 지붕의 빌라에 빨간색 기와 지붕을 추가했습니다. 플래그는 해당 긍정적 예시를 제거합니다. 주의 사항은 여전히 테라코타를 부정적 요소로 명명할 수 있습니다.
기본 등급은 1K입니다. 키 요소가 1K에서 약 20픽셀 미만이 될 경우에만 --size 2K(동일한 정가)를 제안하세요(넓은 부지 항공 사진의 경우처럼). 사용자가 동의한 후에만 사용하세요. 4K는 절대 드래프트 등급이 아닙니다.
입력이 준비된 사본(축선 정리, 레이블 지워짐, 흰색 공백 미리 채워짐)인 경우? 수정되지 않은 내보내기를 --original FILE로 전달하여 시트가 실제 원본과 짝을 이루도록 하세요.
입력이 ... Input 폴더에 있으면 --out은 기본적으로 형제 03 Output 폴더로 설정되고, 그렇지 않으면 <input folder>/03 Output로 설정됩니다. 이 스킬 폴더 안에 절대 위치할 수 없습니다.

4. 프롬프트 감사 (무료)

브리프와 메모를 사용하여 --prompt-only로 다시 실행하고, 출력된 프롬프트를 읽고, 도면에 없는 요소를 요청하는 내용이 없는지 확인하세요.

5. 견적, 요청, 렌더링

게이트 플래그 없이 명령을 실행하여 견적을 얻고(종료 코드 3), 사용자에게 견적을 제시하고 동의를 기다리세요. 그런 다음 --spend-ok를 사용하여 다시 실행하세요. 라이브 호출은 일반적으로 20-60초가 소요되지만 한 번의 시도는 최대 15분까지 기다릴 수 있으며 포그라운드 Bash 호출보다 깁니다: 라이브 패스는 백그라운드(run_in_background)에서 실행하고 기다리세요. 라이브 명령이 중단되면 render.py status를 실행하고, 중단된 패스를 청구될 가능성이 있는 것으로 보고하고 재실행 전에 물어보세요. 여러 뷰: 배치 총액(뷰 x 1K x 최대 2회 시도)을 견적하고 배치에 대해 하나의 동의를 받은 다음 뷰를 하나씩 실행하세요.

6. 시트 검토

Read 도구로 <out>/_Before After - <view>_1K.jpg를 여세요. references/review-checklist.md를 따르세요: 프레이밍 및 비율, 개수, 개구부, 지붕 형태, 층, 추가 또는 누락된 객체, 텍스트, 재료, 사실감. 주황색 "aspect a -> b (framing changed)" 메모 또는 스크립트의 WARNING 라인은 모델이 재프레이밍했음을 의미합니다: 해당 렌더는 수정되거나 승인될 수 없으므로 더 강력한 프레이밍 앵커와 실패한 패스가 정확히 무엇을 했는지 명명하는 주의 사항("PREVIOUS ATTEMPT FAILED: ...")을 사용하여 소스에서 다시 렌더링하세요. 뷰의 두 1K 렌더가 재프레이밍되면 재시도하지 말고 중지하고 보고하세요. 시트가 세부 사항을 판단하기에 너무 작을 때는 렌더 자체를 여세요.

7. 보고

사용자에게 제공: 렌더 경로, 시트 경로, 발견한 문제와 함께 판정, 비용(render.py status에 표시됨), 그리고 선택 사항 - 이 이미지를 4K로 승인, 한 가지 수정, 한 영역 패치, 또는 소스에서 다시 렌더링.

수정 루프 (1K 유지)

revise "<current render>" --notes "<one change>". 규칙:

패스당 한 번의 변경. 한 번의 편집에 여러 변경 사항이 있으면 전체 프레임이 재생성되는 경향이 있습니다.
객체의 대상 상태를 설명하고 수정 사항은 설명하지 마세요("입구 문은 견고한 따뜻한 청동색 목재에 두 개의 수직 풀 바가 있습니다", "문 고쳐"). 작성하기 전에 렌더를 확대하세요: 색상 변경은 추가가 아닙니다.
이전 이미지는 수정 중인 이미지입니다. 시트는 이를 새 파일과 짝짓습니다(BEFORE · <view>_1K / AFTER · <view>_1K_rev02).
현재 파일(작업의 가장 최신 비-4K 패스)만 수정할 수 있습니다. 다른 파일을 선택하면 스크립트가 이름을 지정합니다. 2K 렌더의 수정은 1K로 생성되고 _1K_revNN으로 명명됩니다.
구성 자체가 잘못된 경우(카메라 이동, 피사체 확대, 재프레이밍 경고) 수정하지 마세요: 더 나은 브리프를 사용하여 소스에서 render를 다시 실행하세요.

패치 (로컬 수정, 1K 유지)

patch "<current render>" --box x0,y0,x1,y1 --notes "<the change>" (박스는 프레임의 분수, 0,0은 왼쪽 상단). 박스는 잘리고, 전체 1K로 편집되고, 크기가 조정되어 프레임 내부 가장자리에 36픽셀 페더로 붙여넣어집니다. 박스 외부의 모든 픽셀은 바이트 단위로 동일하게 유지됩니다. 하나의 객체 또는 한 영역(발명된 벽, 잘못된 식물, 문)에 사용하세요. 무엇을 변경해야 하는지, 명확하게 보여야 한다고 말하세요. 변경하려는 바로 그 대상을 유지하라고 말하지 마세요. 박스의 각 측면은 최소 72픽셀이어야 합니다.

4K (승인된 이미지 하나)

사용자가 이름으로 이미지를 승인하면("<view>_1K_rev02" 승인), 실행하세요:

python /full/path/to/scripts/render.py upscale "<path/to/file>" --confirmed

스케치-투-포토리얼-렌더