Claude Code로 이미지 생성 자동화하는 법: JSON 프롬프트, Gemini API, 참조 이미지 편집까지

이미지 한 장 만들 때마다 모델 사이트를 열고 프롬프트를 다시 치고, 결과를 내려받아 작업물에 붙이고 있다면 이미 작업 흐름이 끊기고 있는 겁니다. 이 글은 Claude Code 안에서 이미지 생성, 프롬프트 구조화, 참조 이미지 편집까지 한 번에 묶는 실전 방식을 정리합니다.

영상의 핵심도 여기 있습니다. 좋은 이미지 모델이 있는 것과, 그 모델을 지금 쓰는 작업 환경 안으로 끌어오는 것은 완전히 다른 문제입니다. 웹 페이지 시안, 블로그 썸네일, SNS 비주얼처럼 여러 장을 연속으로 만들어야 할수록 차이는 더 커집니다.

 

코딩 작업 화면에서 구조화된 이미지 생성 지시가 여러 비주얼 결과로 확장되고 그 결과가 웹페이지 시안으로 바로 이어지는 장면

 

브라우저에서 한 장씩 만드는 방식이 왜 빨리 막힐까

처음에는 모델 웹 UI가 제일 쉬워 보입니다. 하지만 반복 작업이 시작되면 병목이 금방 드러납니다.

가장 먼저 무너지는 건 컨텍스트입니다. 이미지를 만들고, 다시 에디터로 돌아오고, 또 브라우저에서 프롬프트를 고치고, 결과 파일을 옮기는 식으로 흐름이 계속 잘립니다. 웹사이트 제작이나 글 편집 중이라면 이 왕복이 그냥 귀찮은 수준을 넘어 집중력을 깎아먹습니다.

그다음은 프롬프트 품질입니다. 사람은 처음 한두 장은 자세히 쓰지만, 장수가 늘어나면 결국 추상어로 버티게 됩니다. "세련되게", "미니멀하게", "프리미엄 느낌으로" 같은 말만 남으면 결과가 애매해지고 수정 횟수만 늘어납니다.

마지막은 반영 단계입니다. 이미지가 괜찮게 나와도 끝이 아닙니다. 파일명 정리, 비율 변경, 대체 이미지 생성, 실제 작업물 교체가 다시 손작업으로 남습니다. 실전에서 더 피곤한 건 생성 자체보다 이 뒤처리입니다.

 

 

이 워크플로에서 먼저 잠가야 할 것은 기능보다 키와 비용이다

많은 사람이 스킬 설치부터 보지만, 실제로는 API 키와 비용 통제가 먼저입니다.

이미지 생성 API를 Claude Code에서 쓰려면 우선 Google AI Studio 쪽 키가 필요합니다. 공식 문서는 Gemini API key 문서와 이미지 생성 문서에서 확인할 수 있습니다. 영상도 같은 흐름으로 진행합니다. AI Studio에서 키를 만들고, 그 키를 Claude Code 쪽 환경 변수로 넘겨 실제 생성 요청에 씁니다.

보통 연결은 아래처럼 시작합니다.

export GEMINI_API_KEY="YOUR_API_KEY"

 

여기서 끝내면 안 됩니다. 자동화된 이미지 생성은 재미로 몇 장 돌릴 때보다 훨씬 빨리 비용이 새기 쉽습니다. 특히 에이전트가 반복 생성과 변형을 계속 시도하는 구조라면 더 그렇습니다. 그래서 키를 만든 직후에 Gemini API pricing 문서를 확인하고, 프로젝트 지출 한도를 먼저 잡아두는 편이 안전합니다.

이건 사소한 팁이 아니라 운영 기준입니다. 기능이 다 붙은 뒤에 비용을 보겠다고 하면 늦습니다.

이미 Claude Code 환경을 꾸준히 쓰고 있다면 이 단계는 금방 넘어갈 수 있습니다. 아직 기본 세팅이 흔들린다면 먼저 Claude Code 잘 쓰는 법: 2026년 생산성 높이는 설정, 플러그인, MCP 서버 가이드 같은 글로 작업 환경부터 정리한 뒤 붙이는 편이 낫습니다.

 

 

품질과 실행을 분리하면 디버깅이 쉬워진다

영상에서 보여준 구조를 단순화하면 두 단계입니다.

1. 일반 요청을 구조화된 JSON 프롬프트로 바꾸는 단계
2. 그 결과를 실제 이미지 생성 API 호출로 넘기는 단계

 

이 분리가 중요한 이유는 문제를 섞지 않게 해주기 때문입니다.

사람이 직접 쓰는 프롬프트는 짧거나 장황하거나 둘 중 하나가 되기 쉽습니다. 반면 JSON으로 바꾸면 어떤 요소를 통제하고 있는지 바로 보입니다. 예를 들어 이미지 유형, 피사체 설명, 배경 환경, 프레이밍, 조명, 표면 재질 같은 항목을 분리해 다룰 수 있습니다.

이렇게 되면 결과가 별로일 때도 "다시 써보자"로 가지 않습니다. 조명이 문제인지, 배경이 문제인지, 구도가 문제인지 항목별로 손볼 수 있습니다. 실전에서 이 차이가 큽니다.

두 번째 단계는 실행과 반영을 맡습니다. 여기서 비율, 해상도, 참조 이미지 입력 같은 옵션을 붙입니다. 그래서 결과가 이상할 때도 프롬프트 문제인지, 실행 옵션 문제인지, 참조 이미지 입력이 꼬인 건지 나눠 볼 수 있습니다.

결국 이 구조의 장점은 이미지를 더 화려하게 만드는 데만 있지 않습니다. 실패 원인을 더 빨리 좁힐 수 있다는 데 있습니다.

 

 

새 이미지 생성보다 더 실용적인 건 참조 이미지 편집일 때가 많다

처음 테스트는 새 이미지 생성으로 시작하는 게 쉽습니다. 9:16 SNS용 비주얼, 블로그 썸네일, 랜딩 페이지 히어로 이미지처럼 비율과 목적이 분명한 작업이 좋습니다.

이때 요청은 짧은 미사여구보다 작업 맥락이 중요합니다.

• 어디에 들어갈 이미지인지
• 어떤 비율이 필요한지
• 한 장만 필요한지 변형이 여러 개 필요한지
• 현실 사진 느낌인지 제품 렌더 느낌인지
• 반드시 살아야 하는 핵심 요소가 무엇인지

 

영상에서도 사람 전신, 손에 든 오브젝트, 기기, 로고 같은 조건을 섞어 테스트합니다. 완벽한 인물 재현까지는 아니어도, 구조화된 요청이 단순 자연어 프롬프트보다 더 많은 요소를 맞춰준다는 점은 분명하게 보입니다.

하지만 실제 업무에서는 참조 이미지 편집이 더 유용할 때가 많습니다. 이미 만든 썸네일이나 시안이 있고, 거기서 로고만 바꾸거나 일부 요소만 교체하고 싶은 경우입니다.

여기서 가장 자주 막히는 건 모델이 아니라 파일 경로입니다. 참조 이미지 기반 편집은 "이 이미지"라고 말하는 것으로 끝나지 않습니다. 원본 파일이 로컬에 실제로 있어야 하고, 스킬이 그 파일 경로를 입력값으로 넘길 수 있어야 합니다.

다운로드 폴더에 있을 거라고 생각했는데 이름이 다르거나, 세션이 접근할 수 없는 위치에 있거나, 아예 내려받지 않은 상태면 바로 막힙니다. 이 지점은 사소해 보여도 자동화 체감을 크게 깎습니다.

 

 

사람들이 자주 오해하는 실패 포인트

이 방식은 분명 편하지만, 몇 군데는 애초에 기준을 잘 잡아야 덜 헤맵니다.

막히는 지점	먼저 볼 것	왜 여기서 자주 틀릴까
이미지가 계속 애매하게 나옴	JSON 프롬프트 구조	실행 문제가 아니라 요청 구조가 빈약한 경우가 많습니다.
호출이 예상보다 많아짐	지출 한도와 재시도 횟수	자동화가 붙으면 사람 손보다 훨씬 빨리 비용이 쌓입니다.
참조 이미지 편집이 안 됨	원본 파일 경로와 접근 가능 여부	"이 이미지"라고 말하는 것만으로는 입력이 전달되지 않습니다.
결과는 나오는데 운영이 불편함	스킬 설치 위치와 작업 흐름	일회성 테스트 구조를 그대로 쓰면 반복 작업에서 다시 귀찮아집니다.

 

 

API 키를 채팅창에 그대로 붙여 넣는 편의

영상에서도 게으르면 할 수 있는 방법처럼 지나가지만, 이건 정말 임시방편에 가깝습니다. 키가 대화 기록에 남고, 나중에 어디까지 노출됐는지 관리하기도 귀찮습니다. 가능하면 환경 변수나 별도 비밀값 관리 방식으로 넣는 편이 낫습니다.

 

 

비용 통제 없이 생성부터 돌리는 습관

이미지 생성은 한 장으로 끝나지 않습니다. 마음에 안 들어 다시 만들고, 비율을 바꾸고, 변형을 늘리면 호출 수가 금방 쌓입니다. 사람 손으로도 그런데 에이전트가 대신 반복하면 더 빨라집니다. 그래서 비용은 나중에 확인할 게 아니라 먼저 제한해야 합니다.

 

 

스킬만 설치하면 품질도 자동으로 올라갈 거라는 기대

설치는 시작일 뿐입니다. 실제 결과 차이는 요청을 얼마나 구조화했는지, 작업 맥락을 얼마나 명확히 넘겼는지에서 갈립니다. 설치만 끝내고 JSON 결과를 한 번도 읽어보지 않으면, 왜 결과가 애매한지 계속 감으로만 추측하게 됩니다.

 

 

첫 결과가 완벽해야 한다는 기대

인물, 특정 제품, 브랜드 요소는 어느 정도 맞아도 어색함이 남을 수 있습니다. 이 흐름의 장점은 첫 결과의 완성도보다 수정 속도에 있습니다. 구조화된 프롬프트와 참조 이미지를 바꿔가며 빨리 재시도할 수 있다는 쪽으로 보는 편이 맞습니다.

 

 

이 방식이 특히 잘 맞는 사람과 아닌 사람

이 흐름은 아래처럼 반복 생산이 이미 있는 사람에게 잘 맞습니다.

• 웹사이트나 랜딩 페이지를 만들면서 비주얼도 같이 뽑아야 하는 사람
• 블로그, 유튜브, SNS용 이미지를 연속으로 만드는 사람
• 한 장보다 이미지 세트와 변형본이 더 자주 필요한 사람
• 프롬프트를 손으로 길게 쓰는 데 금방 지치는 사람
• 기존 이미지를 바탕으로 빠르게 수정 반복을 해야 하는 사람

 

반대로 가끔 한 장만 만들고 끝나는 사용자라면 굳이 이 구조를 다 붙일 필요는 없습니다. 그 경우는 웹 UI가 오히려 더 간단할 수 있습니다. 이 방식은 반복 작업이 이미 시작된 사람에게 특히 유효합니다.

 

 

처음 세팅할 때는 이 순서가 덜 헷갈린다

처음이라면 아래 순서가 가장 안전합니다.

1. Claude Code 기본 환경을 먼저 정리한다.
2. Google AI Studio에서 API 키를 만든다.
3. 결제 상태와 지출 한도를 먼저 잠근다.
4. JSON 프롬프트 단계만 먼저 테스트한다.
5. 생성 스킬을 연결해 새 이미지부터 만든다.
6. 마지막에 참조 이미지 편집을 붙인다.

 

이 순서를 추천하는 이유는 단순합니다. 처음부터 모든 걸 한 번에 붙이면 어디서 깨졌는지 알기 어렵기 때문입니다. 반대로 구조화된 프롬프트 결과를 먼저 확인하면, 문제를 품질 단계와 실행 단계로 분리해서 볼 수 있습니다.

반복해서 쓸 계획이라면 스킬도 일회성 테스트보다 전역으로 다룰지, 특정 환경에만 둘지를 먼저 정하는 편이 낫습니다. 실제로 자주 쓰는 워크플로는 설치 위치가 애매하면 나중에 더 귀찮아집니다.

 

 

FAQ

이 방식이 웹 UI보다 항상 더 좋은가요?

아닙니다. 가끔 한 장만 만들고 끝나는 작업이라면 웹 UI가 더 빠를 수 있습니다. 이 구조는 반복 생성, 변형본 생산, 참조 이미지 편집처럼 작업 흐름이 길어질 때 진가가 납니다.

 

참조 이미지 편집이 안 되면 무엇부터 확인해야 하나요?

대부분은 모델 문제가 아니라 입력 파일 문제입니다. 원본 이미지가 로컬에 실제로 있는지, 파일명이 맞는지, 현재 세션이 그 경로에 접근할 수 있는지부터 확인하는 편이 가장 빠릅니다.

 

마무리

이 영상에서 배울 만한 건 특정 이미지 모델의 이름이 아닙니다. 더 중요한 건 이미지 생성을 Claude Code 같은 작업 환경 안으로 넣어, 프롬프트 작성과 API 호출, 파일 반영을 한 흐름으로 바꾸는 사고방식입니다.

지금 이미지 생성 때문에 창을 계속 옮겨 다니고, 프롬프트를 매번 다시 쓰고, 결과 파일 반영에서 다시 끊기고 있다면 먼저 바꿔야 할 건 모델이 아니라 워크플로입니다.