Gemini(Nano Banana Pro)로 픽셀아트 RPG 캐릭터 만들기 — Stable Diffusion 일관성 문제 해결 (AI RPG 2편)

1편에서 캐릭터가 안 나온다고 했던 그 문제, 2편에서 해결합니다. Stable Diffusion으로 픽셀아트 RPG 캐릭터를 만들려고 했더니 일관성이 안 잡히고 쿼터뷰가 안 되더라고요. 결국 Google Gemini(Nano Banana Pro) 로 갈아탔더니 배경 제거, 후면/측면 뷰 생성, 스프라이트 시트까지 훨씬 수월하게 뽑았습니다.

Stable Diffusion으로 픽셀아트 캐릭터 — 왜 실패했나

처음엔 로컬에서 Stable Diffusion으로 캐릭터를 뽑았습니다. 프롬프트에 pixel art, RPG character, top-down view, 32x32, front view 이런 조합을 넣었죠. 결과는 이랬어요.

한 장에 여러 캐릭터가 겹쳐 나오고, 스타일도 제각각이고, 픽셀아트라기보다는 그냥 “픽셀아트 느낌 나는 일러스트”에 가깝습니다. 문제는 크게 세 가지였어요.

1. 일관성 유지가 안 됨. 같은 시드, 같은 프롬프트여도 다음 컷에서 얼굴·복장·비율이 바뀝니다. RPG에서 캐릭터 하나가 정면/후면/측면 이미지 세트를 가져야 하는데 그게 안 나와요. LoRA 학습 없이 Stable Diffusion 기본 모델로만 캐릭터 일관성을 잡는 건 사실상 불가능에 가깝습니다.

2. 쿼터뷰(탑다운) 앵글이 안 나옴. “quarter view”, “top-down”, “isometric” 같은 프롬프트를 다양하게 시도해도 결과는 대부분 정면 정지 이미지거나 아래처럼 이상한 각도로 뽑혔습니다.

3. 스프라이트 시트 형태가 안 나옴. 게임에 넣으려면 한 시트에 정면/후면/측면 걷기 프레임이 나열되어야 하는데, Stable Diffusion에 그걸 시키면 아래처럼 나옵니다.

“캐릭터 여러 명의 여러 포즈”는 되는데 “같은 캐릭터의 여러 뷰”는 안 됩니다. 이 차이가 게임에서는 결정적이에요.

Google Gemini(Nano Banana Pro)로 갈아탔다

그래서 Google Gemini의 이미지 생성 기능(Nano Banana Pro) 을 써봤습니다. 결론부터 말하면 문제가 대부분 풀렸습니다. 특히 다음 세 가지에서 Stable Diffusion 대비 압도적으로 편했어요.

캐릭터 일관성 유지

기준이 되는 정면 이미지 한 장을 먼저 뽑고, 그걸 그대로 Gemini에게 첨부해서 “이 캐릭터의 후면 뷰를 그려줘”라고 시키면 됩니다. 원본 이미지를 컨텍스트로 붙여넣기 때문에 얼굴·복장·색상이 그대로 유지돼요. Stable Diffusion에서 LoRA 학습 없이는 못 하던 걸 프롬프트만으로 처리합니다.

쿼터뷰(탑다운) 자연스럽게 생성

Nano Banana Pro는 쿼터뷰 앵글을 이해합니다. 배경까지 함께 요청하면 아래처럼 나옵니다.

이 정도면 그대로 게임 씬에 붙여도 무방한 퀄리티예요. 벽돌 텍스처, 항아리, 보물상자, HP/MP 바 위치까지 자연스럽게 잡혔습니다.

측면/후면 뷰 생성

“이 캐릭터의 측면 뷰(옆에서 본 걷기 자세)를 그려줘”라고 시키면 아래처럼 나옵니다.

정면 이미지의 갑옷 디자인, 망토 색깔, 얼굴이 그대로 유지됐습니다. 이게 Stable Diffusion 대비 가장 큰 차이예요.

실제 사용한 프롬프트 흐름

Gemini에 이런 순서로 요청했습니다.

[1단계 — 기준 이미지 생성]
"쿼터뷰 픽셀아트 RPG 게임 캐릭터.
갑옷을 입은 기사, 오른손에 검, 왼손에 방패, 정면 뷰.
스타일은 SNES 시절 클래식 RPG 픽셀아트."

[2단계 — 배경 제거]
(1단계 결과 이미지 첨부)
"이 캐릭터만 남기고 배경을 완전히 투명하게 만들어줘.
스프라이트로 쓸 거야."

[3단계 — 후면 뷰]
(2단계 결과 첨부)
"이 캐릭터의 뒷모습을 그려줘.
같은 갑옷·같은 망토 색깔·같은 비율.
쿼터뷰 앵글 유지."

[4단계 — 측면 뷰]
"이 캐릭터의 옆모습을 그려줘.
걷는 자세, 검은 오른손에, 방패는 왼손에 유지."

프롬프트 수정으로 잡은 한계

한 번에 완벽하진 않았습니다. 특히 캐릭터를 뒤집었을 때 칼과 방패의 위치가 바뀌는 문제가 있었어요. 후면 뷰를 뽑았더니 검이 왼손으로 옮겨가 있는 식입니다. AI가 미러링을 그대로 반영한 거죠.

해결은 프롬프트에 명시적으로 못 박는 것:

"칼은 오른손에, 방패는 왼손에 항상 유지할 것.
후면 뷰에서도 관찰자 기준이 아니라 캐릭터 기준으로 오른손."

이렇게 캐릭터 기준 좌우를 명시하니 잡혔습니다. 프롬프트 엔지니어링이 여전히 중요하다는 뜻.

자동화하고 싶은데 — API 비용 이슈

여기까지 하면 캐릭터 하나는 잘 나옵니다. 그런데 RPG에는 NPC가 수십, 수백 명 필요해요. 마을 사람 A, 상인 B, 대장장이 C, 병사 D…. 이걸 웹 UI에서 하나씩 그리는 건 비효율적입니다.

Gemini API로 자동화하면 되는데, 여기서 문제가 생깁니다. Nano Banana Pro는 현재 유료 API에서만 접근 가능해요. 무료 티어에서는 이미지 생성 API가 제한되어 있어서 자동화하려면 그대로 과금됩니다.

간단히 계산해보면:

• NPC 1명당 정면/후면/측면 3장 + 배경 제거 요청 1장 = 최소 4번의 API 호출
• NPC 50명이면 200번
• Nano Banana Pro의 이미지 생성 요금이 붙으면 프로토타입 단계에서도 몇 만원 단위가 쉽게 나옴

이 부분은 아직 결론을 못 냈습니다. 옵션은 세 가지:

• API로 자동화하고 비용을 감수한다 — 상용화 관점에선 합리적
• 주요 캐릭터만 Gemini로, 잔챙이 NPC는 Stable Diffusion에 LoRA로 학습해 로컬에서 뽑는다 — 하이브리드
• 일단 웹 UI로 필요한 만큼만 수동으로 뽑는다 — 프로토타입 단계엔 이게 제일 쌈

일단은 세 번째로 가되, 스프라이트 시트 자동 생성 파이프라인은 3편에서 시도해볼 예정입니다.

정리

• Stable Diffusion으로 픽셀아트 RPG 캐릭터를 뽑을 때 캐릭터 일관성과 쿼터뷰 앵글이 잘 안 됨. LoRA 학습 없이는 사실상 무리.
• Google Gemini(Nano Banana Pro) 는 원본 이미지를 컨텍스트로 붙여 넣을 수 있어서 후면/측면 뷰 생성과 배경 제거가 자연스럽게 됨.
• 프롬프트에서 좌우(칼/방패 위치) 는 캐릭터 기준으로 명시해야 미러링 오류를 막을 수 있음.
• API 자동화는 비용이 걸림돌 — 프로토타입 단계에선 수동으로, 상용화 단계에서 API + 로컬 하이브리드 검토 예정.

다음 편에서는

캐릭터가 나왔으니 이제 맵 위에서 실제로 걷게 만들어야 합니다. 1편에서 만든 SAM v3 마스크에 이번에 뽑은 스프라이트를 얹고, 이동/충돌 판정을 붙이는 단계로 갑니다. 다음 편에서 뵙겠습니다.