AI로 같은 캐릭터를 매번 똑같이 그리는 법 (초보자 가이드)

매도비는 매드업의 대표 캐릭터입니다. 통통한 흰 햄스터에 남색 M모자를 씌운 이 마스코트를 블로그 아이콘부터 카드, 삽화까지 화면 곳곳에 쓰려면 포즈가 여러 장 필요합니다. 인사하는 매도비, 검색하는 매도비, 차트를 보는 매도비처럼요. 그런데 AI로 이런 포즈를 그려 보면 금방 벽에 부딪힙니다. 같은 캐릭터를 달라고 했는데 매번 다르게 나옵니다. 어제는 없던 꼬리가 오늘은 생기고, 모자에 적힌 글자가 바뀌고, 안 입던 옷을 입고 나옵니다. 아무리 대표 캐릭터를 아껴도, 화면마다 얼굴이 다르면 그 캐릭터로 화면을 채울 수가 없습니다.

이 글은 AI 이미지 생성을 처음 다뤄 보는 분을 위한 것입니다. 같은 캐릭터가 왜 매번 달라지는지부터 시작해, 제미나이나 오픈AI 같은 도구로 같은 캐릭터를 여러 포즈로 뽑는 프롬프트를 한 줄씩 풀어 보고, 그 과정을 하네스라는 구조로 묶어 돌수록 정확해지게 만드는 방법까지 따라 할 수 있게 적었습니다. 중간에 낯선 말이 나오면 그때그때 풀어가겠습니다.

AI 이미지 생성에서 캐릭터가 매번 달라지는 이유

먼저 왜 이런 일이 생기는지부터 봅니다. AI 이미지 생성 모델은 요청을 하나씩 따로 처리합니다. 방금 전에 무엇을 그렸는지 기억하지 않습니다. 그래서 글로만 설명을 주면 모델은 빈칸을 매번 조금씩 다르게 채웁니다.

“통통한 흰 햄스터에 파란 모자”라는 말은 사람에게는 충분해 보입니다. 하지만 모델에게는 얼굴 비율, 모자 각도, 테두리 두께, 홍조 위치를 알아서 정해도 된다는 뜻으로 읽힙니다. 한두 장은 비슷하게 나오다가, 여러 장을 한꺼번에 뽑으면 캐릭터가 조금씩 어긋나기 시작합니다. 사람이 볼 때는 “같은 캐릭터를 그려줘”라고 분명히 말한 것 같은데, 모델에게는 그 말이 생각보다 헐거웠던 셈입니다.

매도비는 지켜야 할 생김새가 정해져 있습니다. 통통한 흰색 햄스터, 남색 야구모자에 흰 글자 M, 모자 꼭대기의 빨간 안테나 볼, 빨간 귀, 분홍 홍조, 굵고 매끈한 검정 테두리의 귀여운 스티커 그림체입니다. 이 생김새가 매 장 그대로 유지돼야 같은 캐릭터로 보입니다. 그래서 이 헐거움을 하나씩 조여야 합니다.

프롬프트로 캐릭터를 붙잡는 네 가지 장치

프롬프트는 AI에게 주는 지시문입니다. 캐릭터를 붙잡는 첫 번째 장치가 바로 이 프롬프트를 어떻게 쓰느냐에 있습니다. 매도비를 그릴 때 쓰는 프롬프트에는 네 가지가 들어갑니다. 하나씩 보겠습니다.

첫째, 캐릭터의 생김새를 설명하는 고정 문단입니다. 이걸 캐릭터 바이블이라고 부릅니다. 매번 새로 쓰지 않고 늘 같은 문장을 그대로 붙여 넣습니다. 표현이 조금만 달라져도 결과가 흔들리기 때문에, 문장 자체를 고정하는 것이 요령입니다.

둘째, 참고 이미지입니다. 글 설명만으로는 부족해서, 원본 이미지 파일을 함께 주고 “이 파일이 우리 캐릭터다, 이 그림과 똑같은 생김새와 비율로 그려라”라고 요청합니다. 실제로 해보면 참고 이미지를 주는 편이 글로만 설명하는 것보다 스타일 유지에 훨씬 결정적이었습니다.

셋째, 하지 말아야 할 것을 적는 부정 조건입니다. 꼬리 없음, 옷 안 입음, 모자 글자는 M 하나만. 모델이 자주 저지르는 실수를 미리 막는 문장입니다. “이렇게 그려라”만큼 “이건 하지 마라”가 중요합니다.

넷째, 생성한 뒤 스스로 검증하라는 지시입니다. “다 그린 다음 참고 이미지와 비교하고, 어긋나면 다시 그려라”라고 덧붙입니다. 여기서 잠깐 짚을 게 있습니다. 요즘 이미지 생성은 단순히 그림 한 장을 뱉는 것을 넘어, 지시를 받아 스스로 도구를 쓰고 결과를 확인하는 방식으로 동작할 수 있습니다. 이렇게 스스로 판단하며 일하는 AI를 에이전트라고 부릅니다. 에이전트에게 자기 검증을 시키면, 사람이 일일이 확인하기 전에 스스로 어긋난 결과를 걸러냅니다. 실제로 차트 장식선이 그림체와 어긋나자 지시받은 대로 스스로 다시 그린 경우를 확인했습니다.

같은 캐릭터를 여러 포즈로 뽑는 프롬프트 예시

말로만 하면 감이 안 오니, 실제로 쓰는 프롬프트의 뼈대를 그대로 옮깁니다. 아래 상자 안의 글을 통째로 복사해, ChatGPT나 제미나이 같은 도구의 대화창에 참고 이미지와 함께 붙여 넣는다고 생각하시면 됩니다. ←로 시작하는 줄은 설명용 주석이니 실제로 넣을 때는 빼면 됩니다. 네 가지 장치가 어떻게 한 덩어리로 묶이는지 보시면 됩니다.

reference-hi.png 파일은 우리 마스코트 "매도비"다:
통통한 흰색 햄스터, 남색 야구모자(흰 글자 M)와 모자 꼭대기의 빨간 안테나 볼,
빨간 귀, 분홍 홍조 볼, 굵고 매끈한 검정 아웃라인의 귀여운 스티커 그림체.
   ← 여기까지가 캐릭터 바이블. 늘 그대로 붙여 넣는 고정 문단.

이 참고 이미지와 똑같은 캐릭터·그림체·비율로 새 포즈를 그려서 저장해줘:
(1) search.png = 돋보기로 무언가를 찾는 포즈
(2) coffee.png = 커피를 들고 있는 포즈
(3) jump.png  = 폴짝 뛰는 포즈
   ← 포즈 줄만 바꿔 끼우는 부분. 여기만 갈아 끼우면 여러 장이 나온다.

각 이미지는 1024x1024 크기로.
   ← 크기 지정. 1024x1024는 가로세로가 같은 정사각형이라 나중에 다루기 편하다.
배경은 반드시 순수한 단색 흰색만 (그라데이션·그림자·바닥선 금지).
   ← 배경 규칙. 나중에 배경을 지우려면 흰색 단색이어야 한다(아래에서 설명).

꼬리 없음, 옷 안 입음, 모자 글자는 M 하나만.
   ← 부정 조건. 자주 나는 실수를 미리 막는다.

다 그린 다음 참고 이미지와 비교하고, 어긋나면 다시 그려줘.
   ← 자기 검증 지시. 에이전트가 스스로 결과를 확인하게 한다.

핵심은 캐릭터 바이블과 배경 규칙, 부정 조건, 검증 지시는 고정하고, 가운데 포즈를 설명하는 (1)(2)(3) 줄만 바꿔 끼운다는 데 있습니다. 그래서 한 번의 요청으로 같은 캐릭터를 여러 포즈로 한꺼번에 만들 수 있습니다. 열 개의 포즈가 필요하면 그 열 줄만 쓰면 됩니다.

배경을 투명하게 만드는 후처리

캐릭터가 잘 나와도 그대로 화면에 얹지는 못합니다. 카드나 아이콘에 캐릭터를 올리려면 배경이 투명해야 하는데, 여기서 초보자가 자주 막히는 지점이 있습니다. 이미지 생성 AI는 투명 배경을 직접 만들지 못합니다. 투명하게 그려달라고 해도 흰색이나 회색으로 채운 배경을 그려 줍니다.

그래서 순서를 뒤집습니다. 배경을 아예 순수한 흰색으로 그려달라고 한 뒤, 그 흰색을 나중에 지웁니다. 지우는 방식은 이렇습니다. 이미지의 가장자리에서 시작해서, 서로 연결된 흰색을 바깥에서 안쪽으로 번지듯 지워 나갑니다. 색을 칠하는 물통 도구가 거꾸로, 지우개로 작동한다고 생각하면 됩니다. 이 방식을 flood fill이라고 합니다.

여기서 궁금해집니다. 캐릭터 몸통도 흰색인데 같이 지워지지 않을까요? 지워지지 않습니다. 매도비 몸통을 감싼 굵은 검정 테두리가 벽이 되어, 바깥에서 번져 오던 지우개가 몸통 안으로 넘어오지 못하게 막아 줍니다. 그래서 배경 흰색만 지워지고 몸통 흰색은 남습니다. 단, 이 방식은 배경이 단색일 때만 안정적입니다. 그라데이션이나 그림자가 섞이면 지울 흰색과 남길 흰색의 경계가 흐려지기 때문에, 프롬프트에서 배경 그라데이션과 그림자, 바닥선을 미리 금지한 것입니다.

배경을 지운 다음에는 투명한 여백을 채워 정사각형으로 맞춥니다. 이 배경 지우기와 정사각 맞추기, 크기 조절을 한 번에 해주는 작은 프로그램을 하나 만들어두고, 포즈마다 똑같이 돌립니다. 아래는 그 프로그램을 실행하는 한 줄입니다. 컴퓨터에서 명령을 입력하는 창인 터미널에 이렇게 칩니다.

python3 process.py search.png search-done.png --size 480

한 줄씩 뜯어보면, python3은 이 프로그램을 파이썬이라는 언어로 실행하라는 뜻이고, process.py가 우리가 만들어둔 프로그램 파일입니다. search.png는 방금 AI가 그린 원본, search-done.png는 배경이 지워지고 정사각으로 맞춰져 나올 결과 파일 이름입니다. --size 480은 가로세로 480픽셀 크기로 줄이라는 뜻입니다. 아이콘으로 쓰기에 알맞은 크기라 480을 골랐고, 더 크게 쓰려면 이 숫자만 바꾸면 됩니다.

코드를 다뤄 본 적이 없어 이 줄이 부담스럽다면, 이 단계는 배경을 지우고 정사각으로 맞추는 일일 뿐이니 무료 배경 제거 웹서비스나 이미지 편집기로도 대신할 수 있습니다. 같은 작업을 여러 장 반복할 때 프로그램이 편할 뿐, 원리는 배경 지우기와 정사각 맞추기가 전부입니다. 정사각형으로 맞추는 이 단계가 왜 꼭 필요한지는, 다음 이야기에서 이어집니다.

여기까지가 한 장을 만드는 전체 흐름입니다. 그림으로 보면 이렇습니다.

하네스가 무엇이고, 왜 실패를 기록하는가

여기까지 보면 매끄러운 과정처럼 보이지만, 처음부터 이랬던 것은 아닙니다. 지금의 이 과정은 여러 번 실패한 뒤 그 실패를 하나씩 고쳐 넣은 결과입니다. 그리고 그 고친 것들을 한 곳에 묶어둔 것을 하네스라고 부릅니다.

하네스는 AI에게 일을 시키는 판을 미리 짜둔 구조입니다. 프롬프트 한 줄이 아니라, 캐릭터 바이블과 참고 이미지, 그림을 그리는 방법, 배경을 지우는 후처리, 결과를 눈으로 확인하는 검수 절차, 그리고 지난 실패에서 얻은 규칙을 하나로 묶은 것입니다. 이 묶음을 파일로 저장해두면, 다음에 매도비를 그릴 때 매번 처음부터 헤매지 않고 지난번보다 나은 상태에서 시작할 수 있습니다.

이 하네스에서 특별한 부분은 마지막 조각, 실패에서 얻은 규칙입니다. 하네스 파일 안에 Lessons라는 칸을 두고, 실수할 때마다 무엇이 어긋났고 어떻게 고쳤는지를 날짜와 함께 적어 둡니다. 실제로 적혀 있는 몇 가지를 풀어 보겠습니다.

정사각형으로 맞추는 단계가 왜 꼭 필요한지, 그 답이 첫 번째 실패에 있습니다. 처음에는 캐릭터 이미지들의 가로세로 비율이 제각각이었습니다. 어떤 건 세로로 길고 어떤 건 정사각이었죠. 그런데 블로그 화면은 아이콘을 정사각 칸에 넣어 보여줍니다. 세로로 긴 이미지를 정사각 칸에 억지로 끼우니 캐릭터가 눌려서 찌그러져 보였고, 아이콘 비율이 깨졌다는 지적을 받았습니다. 그래서 후처리에 정사각으로 맞추는 단계를 꼭 넣기로 하고, 그 규칙을 Lessons에 적었습니다.

두 번째 실패는 도구를 바꾸게 만든 사건입니다. 처음에는 구글 제미나이로도 이미지를 만들었는데, 제미나이가 자기가 직접 그리는 대신 외부의 다른 이미지 서비스로 작업을 넘겨 버리는 경우가 있었습니다. 그때 나온 그림은 꼬리 달린 생쥐, 글자가 뭉개진 모자, 안 입던 옷처럼 캐릭터가 완전히 깨진 결과였습니다. 그래서 그런 상황이 감지되면 결과를 버리고 오픈AI 쪽으로 다시 그린다는 규칙을 적었고, 캐릭터가 중요한 작업은 오픈AI를 기본으로 삼기로 했습니다.

세 번째 실패는 검수에 관한 것입니다. 파일이 생겼다고 해서 캐릭터가 제대로 나온 것은 아닙니다. 방금 말한 깨진 그림도 파일은 멀쩡히 만들어졌지만, 열어 보니 캐릭터가 깨져 있었습니다. 그래서 화면에 올리기 전에 사람이 한 장 이상 직접 열어, 앞서 정한 생김새가 전부 들어 있는지 눈으로 확인하는 단계를 규칙으로 넣었습니다. 자동으로 돌아가는 과정이라도, 마지막에 사람 눈이 한 번 들어가는 편이 안전합니다.

실패를 규칙으로 되먹여 돌수록 똑똑해지는 구조

이 Lessons 칸이 하는 일은 그냥 메모가 아닙니다. 다음에 매도비 이미지를 만들 때, 하네스는 작업을 시작하기 전에 이 규칙들을 먼저 읽습니다. 그래서 정사각으로 맞추는 단계를 잊지 않고, 제미나이가 엉뚱하게 새는 상황을 경계하고, 화면에 올리기 전에 눈으로 검수합니다. 한 번 겪은 실패가 규칙으로 남아 다음 작업의 출발점이 됩니다. 이 되먹임이 하네스를 돌릴수록 낫게 만듭니다.

이 되먹임을 그림으로 그리면 한 방향으로 흐르지 않고 고리처럼 돕니다. 작업을 하고, 어딘가에서 실패하고, 그 실패를 규칙으로 적고, 다음 작업이 그 규칙을 먼저 읽고, 다시 작업으로 돌아옵니다. 한 바퀴 돌 때마다 규칙이 하나씩 늘어, 다음 바퀴가 조금 더 매끄러워집니다.

여기가 AI 에이전트를 쓰는 방식에서 가장 중요한 지점입니다. 사람이 매번 “아 맞다, 정사각으로 맞춰야지”, “아 맞다, 이건 깨졌으니 다시 해야지” 하고 기억하는 대신, 그 교훈을 파일에 적어 에이전트가 매번 먼저 읽게 만드는 것입니다. 사람의 경험을 글로 옮겨 시스템 안에 심어두면, 그 경험이 사람의 머릿속이 아니라 하네스 안에 쌓입니다. 담당자가 바뀌어도 규칙은 파일에 남습니다.

같은 구조가 더 큰 일에서도 돌아간다

이 방식은 이미지 생성에만 쓰이지 않습니다. 매드업에서는 회사의 코드 저장소들을 AI 에이전트가 읽어 기능 지도를 그리는 작업에도 같은 구조를 씁니다. 이 작업의 이름은 featuremap인데, 여기서도 저장소를 분석하는 에이전트들이 일을 시작하기 전에 lessons 파일을 먼저 읽습니다. 이 파일에는 과거 실행에서 쌓인 코드 해석 규칙만 담습니다. 저장소에 화면이 몇 개더라 같은 한 번 쓰고 마는 사실은 매번 코드에서 다시 세고, 여기에는 반복해서 쓸모 있는 규칙만 적습니다.

featuremap의 lessons 파일은 매도비의 Lessons 칸보다 한 단계 더 자랐습니다. 어떤 빌드 과정이 특정 상황에서 깨진다는 사실이 다섯 번째 실행에서 발견됐는데, 여섯 번째와 일곱 번째 실행에서도 같은 문제가 이어지자, 몇 번째 실행에서 어떻게 우회했는지가 회차별로 차곡차곡 쌓였습니다. 그 결과 다음 실행자를 위한 안내가 파일에 남습니다. 이 우회가 세 번 연속 유일하게 통하는 길이었으니, 고쳐지기 전까지는 확인에 시간 쓰지 말고 바로 이 방법을 쓰라는 식입니다. 실행을 거듭할수록 파일이 두꺼워지고, 그만큼 다음 실행이 덜 헤맵니다. 실패가 쌓일수록 똑똑해지는 것입니다.

직접 따라 해보기

작은 브랜드 캐릭터나 마스코트가 있다면, 위 과정을 그대로 따라 해볼 수 있습니다. 순서는 이렇습니다.

1. 캐릭터의 생김새를 한 문단으로 적습니다. 색, 모자, 눈, 특징적인 소품까지 구체적으로 씁니다. 이것이 캐릭터 바이블이고, 앞으로 모든 요청에 그대로 붙일 고정 문단입니다.
2. 가장 잘 나온 그림 한 장을 참고 이미지로 정합니다. 앞으로 이 그림을 기준으로 삼습니다.
3. ChatGPT나 제미나이 같은 이미지 생성 도구에, 캐릭터 바이블과 참고 이미지, 원하는 포즈, 부정 조건, 자기 검증 지시를 위 예시처럼 한 덩어리로 묶어 요청합니다.
4. 나온 이미지는 배경을 지우고 정사각으로 맞춥니다. 코드가 부담되면 배경 제거 웹서비스로 대신해도 됩니다.
5. 마지막으로 눈으로 확인해, 캐릭터 바이블에 적은 생김새가 다 들어 있는지 봅니다.

그리고 실패하면 반드시 적어 두세요. “모자 글자가 자꾸 두 개로 나온다”, “옆모습을 요청하면 꼬리가 생긴다” 같은 것을요. 다음 요청 프롬프트에 그 교훈을 부정 조건으로 한 줄 추가하면, 같은 실수가 줄어듭니다. 이 적어두고 되먹이는 습관 하나가, 그때그때 손으로 그리는 것과 시스템으로 캐릭터를 뽑는 것을 가르는 지점입니다.

이 블로그에 쓰인 매도비

지금 이 블로그의 주제 아이콘과 글 곳곳의 매도비는 모두 이 하네스로 만든 결과물입니다. 대표 캐릭터 하나를 여러 포즈로 늘려두니, 새 글이나 새 화면을 만들 때마다 어울리는 포즈를 골라 얹기만 하면 화면이 채워집니다. 아래 여덟 장은 인사, 검색, 차트, 생각, 커피, 점프, 읽기, 쓰기 포즈로, 전부 같은 캐릭터 바이블과 같은 후처리를 거쳤습니다. 모자와 안테나볼, 귀, 홍조, 테두리가 여덟 장 모두에서 같은 모양으로 유지되는지 직접 확인해 보시기 바랍니다.

캐릭터 하나를 매번 똑같이 뽑는 문제는 작아 보이지만, 그 뒤에는 실패를 기록해 다음 실행에 되먹이는 구조가 있습니다. 다음에는 이 하네스로 포즈를 몇 장 더 늘리고, 그때 새로 배운 규칙을 다시 Lessons에 적을 차례입니다. 🐹