AI 이미지에 한글 글자 넣기 — SDXL 두 모델에 72장 그려보고 OCR로 채점한 결과 (2026)

이 측정은 시작도 전에 헛수고가 될 뻔했습니다. 이미지 일꾼에게 늘 물려주던 네거티브 프롬프트에는 text, watermark가 박혀 있습니다. 그걸 그대로 두고 돌렸다면 글자를 지우라고 시켜놓고 "글자를 못 그리네"라고 채점하는, 72장짜리 삽질이 될 뻔했습니다. 설정을 뜯어고치고 나서 뽑은 결과가 이 글입니다. 요청한 단어가 그대로 그려진 이미지는 한글 0/36, 영어 0/36으로 양쪽 다 바닥이었고, 갈린 건 정답률이 아니라 실패하는 방식이었습니다.

그 방식 차이가 썸네일 일감에서 뭘 바꾸는지 숫자로 정리된 걸 찾지 못해, 로컬 GPU를 밤새 굴리는 김에 직접 재봤습니다. 체크포인트 2종 × 단어쌍 6개 × 문자 체계 2종 × 반복 3회, 총 72장입니다. 2026년 7월 31일 로컬 ComfyUI에서 생성했습니다.

핵심은 이겁니다. 정답률로 보면 둘 다 0입니다. 그런데 "요청한 문자 체계의 글자가 읽히기라도 했는가"로 보면 한글 9/36, 영어 23/36으로 갈립니다. 짝지어 검정하면 이 차이는 우연으로 보기 어렵습니다(p=0.0043).

채점자부터 검증했습니다

채점을 맡길 일꾼부터 못 미더웠습니다. 이런 실험에서 가장 흔한 함정이 OCR을 진실로 취급하는 것이거든요. 감독을 못 하는 녀석을 앉혀두면 직원 평가가 통째로 헛것이 됩니다. 테서랙트가 한글을 못 읽는 건지, 모델이 한글을 못 그린 건지 구분하지 못하면 "한글은 안 된다"는 결론이 통째로 무너집니다.

그래서 채점 전에 계측기부터 재봤습니다. 같은 12개 단어를 노토 산스 CJK 폰트로 깨끗하게 렌더링한 다음, 모델 이미지와 완전히 동일한 OCR 설정으로 읽혔습니다.

계측기 검증	결과
한글 6단어 정확 판독	6/6
영어 6단어 정확 판독	6/6

한글도 영어도 6/6입니다. 채점 담당 일꾼은 제 몫을 했다는 뜻이고, 뒤에 나올 0/36은 채점자의 한계가 아니라 그림 쪽 결과입니다. 이 보정 단계가 없으면 아래 숫자는 아무 의미가 없습니다.

한 가지 더 조심한 게 있습니다. 이미지 생성에서 흔히 쓰는 네거티브 프롬프트에는 보통 text와 watermark가 들어갑니다. 글자를 지우라는 지시입니다. 그대로 두고 글자 렌더링을 측정하면 내가 글자를 지워놓고 "모델이 글자를 못 그린다"고 결론 내는 셈이 됩니다. 그래서 이 실험에서는 네거티브 프롬프트에서 text 계열을 전부 뺐습니다.

무엇을 시켰는가

업무 지시서는 양쪽 일꾼에게 똑같이 내렸습니다. 조건이 다르면 나중에 "그건 지시가 불공평했다"는 변명이 나오니까요. 단어쌍은 의미가 대응하도록 짰습니다. 사랑/LOVE, 커피/CAFE, 학교/SCHOOL, 행복/HAPPY, 바다/OCEAN, 서울/SEOUL. 한글은 2글자, 영어는 4~6글자입니다.

프롬프트 틀은 양쪽이 완전히 같고, 따옴표 안 단어만 바뀝니다.

A simple poster with the exact text '사랑' in bold sans-serif,
centered, plain background

• 체크포인트는 animagine-xl-4.0과 Illustrious-XL-v2.0 두 종입니다. 둘 다 애니메이션 계열 SDXL이고, 월급 안 나가는 일꾼입니다.
• 샘플러·스텝·CFG·해상도를 전부 고정했습니다(26스텝, CFG 6.5, 1024px).
• 같은 단어쌍의 한글판과 영어판은 같은 시드를 씁니다. 시드가 다르면 그림 자체가 달라져 비교가 성립하지 않습니다.
• 각 조합을 3회씩 반복했습니다. 한 번 실패했다고 자를 순 없으니 세 번씩은 시켜봤습니다.

채점은 OCR 결과를 정답 문자열과 대조하는 방식이고, 대소문자와 구두점 잡음은 무시했습니다. love.는 LOVE로 인정합니다.

실측 결과 — 정답은 0, 갈린 건 "글자꼴이라도 나왔는가"

72장을 다 뽑아놓고 성적표를 매겨보니, 이 일꾼들에게 줄 성과급은 없었습니다. 야근시킨 보람이 이 정도입니다.

문자 체계	정확히 맞음	요청 문자 체계 판독	아무 글자도 안 읽힘	문자 오류 중앙값
한글	0/36	9/36	20장	1.0
영어	0/36	23/36	11장	1.0

표의 각 열은 서로 다른 잣대라 더해도 36이 되지 않습니다. 판독된 9장과 아무것도 안 읽힌 20장 사이에 남는 한글 7장(영어는 2장)은 숫자·기호 잡음만 나온 경우로, 다음 절에서 따로 셉니다.

정확히 맞은 건 양쪽 다 0입니다. SEOUL을 요청해 soud가 나온 게 이번 72장 중 정답에 가장 가까운 결과였습니다. 영어도 못 씁니다.

그런데 세 번째 열이 갈립니다. 한글 요청 36장 중 한글 글자가 하나라도 읽힌 건 9장뿐이고, 나머지 27장에서는 한글로 볼 만한 획이 잡히지 않았습니다. 영어는 36장 중 23장에서 로마자가 읽혔습니다.

같은 시드·같은 프롬프트 틀로 짝지어 놓고 이 축만 비교하면, 영어만 성공한 쌍 18개, 한글만 성공한 쌍 4개입니다. 정확 McNemar 검정으로 p=0.0043입니다. 정답률은 둘 다 0이라 비교할 게 없지만, 글자꼴이라도 만들어내는 능력에서는 차이가 뚜렷했습니다.

실패하는 방식이 서로 달랐습니다

같은 0점이어도 일꾼이 말아먹는 방식은 달랐습니다. 영어 실패는 철자가 무너지는 쪽입니다.

• CAFE → CEAFFE (글자가 늘어남)
• SEOUL → soud
• LOVE → ep

로마자 형태는 유지하는데 글자 수와 순서가 어긋납니다. 사람 눈에는 "영어 단어처럼 생긴 무언가"로 보입니다. 일은 한 척하는데 결재는 못 하는 상태입니다.

한글 실패는 글자 자체가 성립하지 않는 쪽이었습니다. 27장에서는 판독 가능한 한글이 아예 없었고, 한글이 읽힌 9장도 상태가 이렇습니다.

• 사랑 → ㅎㅇ042) 05, 오종 3ㅁ
• 커피 → 96011 『0ㄷ
• 학교 → 보

숫자로도 갈립니다. OCR이 아무것도 읽어내지 못한 이미지가 한글 20장, 영어 11장입니다. 뭔가 읽히긴 했지만 < 06000 2처럼 숫자·기호 잡음만 나온 경우는 한글 7장, 영어 2장이었습니다. 한글 쪽은 "판독 자체가 안 됨"과 "글자 아닌 잡음"이 둘 다 영어보다 많았다는 뜻입니다.

자모가 분리돼 흩어지거나, 아예 획 몇 개만 남기고 퇴근해버립니다. 한글은 자모를 모아 한 글자를 만드는 구조라, 획이 조금만 어긋나도 글자로 성립하지 않습니다. 로마자가 한 글자씩 옆으로 늘어서는 것과 실패 양상이 다른 이유로 보입니다. 다만 이건 결과를 보고 붙인 해석이고, 이번 측정으로 검증한 사실은 아닙니다.

가장 눈에 띈 건 이 녀석들이 엉뚱한 문자를 그려온 경우입니다. 한글을 요청했는데 일본어 가나·한자로 보이는 글자를 그려낸 이미지가 있었습니다. 두 체크포인트 모두 애니메이션 이미지로 학습된 모델이라, "동아시아 문자"를 요청받았을 때 학습 데이터에 훨씬 많았을 일본어 쪽으로 끌려간 것으로 보입니다. 참고로 이번 OCR에는 일본어 데이터가 설치돼 있지 않아, 가나 출력은 수치상 "한글 아님"으로만 잡히고 별도 집계되지 않습니다. 이 부분의 근거는 이미지 육안 확인이지 표의 숫자가 아닙니다.

모델별로도 갈렸습니다

체크포인트	한글 문자 오류 중앙값	영어 문자 오류 중앙값
animagine-xl-4.0	2.75	1.225
Illustrious-XL-v2.0	1.0	1.0

숫자만 보면 Illustrious가 나아 보이지만, 두 녀석의 근무 태도를 보면 반대에 가깝습니다. Illustrious는 애초에 글자를 거의 안 그렸습니다. 시키면 빈 종이를 내는 식충이 쪽이고, 빈 이미지는 오류가 1.0에서 멈춥니다. animagine은 반대로 열정만 앞선 신입입니다. 글자를 적극적으로 그리려다 자모를 흩뿌려 오류가 2.75까지 올라갔습니다.

사장 입장에서는 이게 더 중요합니다. "조용히 놀고 있는 일꾼"과 "틀린 걸 자신 있게 제출하는 일꾼" 중 후자가 내 시간을 더 잡아먹습니다. 빈 포스터는 한눈에 걸러지지만, 그럴듯한 한글 비슷한 획은 축소된 썸네일에서 놓치기 쉽습니다. 결과물을 사람이 확인해야 하는 이유는 AI 환각을 거르고 검증하는 방법에서 다룬 것과 같은 구조입니다.

그래서 한글 들어간 이미지는 어떻게 만드나

이 일꾼들에게 뭘 시키고 뭘 뺏어야 하는지로 옮기면 이렇습니다.

로컬 SDXL 계열에 한글을 직접 그리게 하는 건 이번 조건에서 성립하지 않았습니다. 36번 굴려 정답 0회, 한글 글자꼴이 읽힌 것도 9회입니다. 시드를 더 돌려 건지는 방식은 기대값이 너무 낮습니다.

영어도 마찬가지입니다. "한글은 안 되니 영어로 넣자"는 흔한 우회인데, 정확히 맞은 영어 단어도 0/36이었습니다. 글자꼴이 더 자주 나올 뿐 철자는 무너집니다. 짧은 단어라고 다르지 않았습니다.

실무 답은 글자라는 업무를 이 일꾼에게서 회수하는 것입니다. 배경·일러스트만 모델에게 시키고, 글자는 그 위에 편집 도구로 얹습니다. 폰트가 정확하고, 수정이 자유롭고, 자간·줄바꿈을 통제할 수 있습니다. 로컬 SDXL로 배경을 뽑는 방법은 로컬 이미지 생성 SDXL 실측에 정리해뒀습니다.

글자까지 한 번에 뽑아야 한다면 그 일에 맞는 일꾼을 따로 고용하세요. 한글 텍스트를 처리하는 썸네일 도구들은 따로 비교해봤습니다. 이번에 측정한 두 체크포인트는 애니메이션 이미지 생성용이지 타이포그래피용이 아닙니다.

이 숫자를 어디까지 믿어도 되나

일꾼 둘 굴려본 결과를 전체 업계 평가로 쓰면 곤란합니다. 이 숫자의 한계를 그대로 적어둡니다.

• 애니메이션 계열 SDXL 체크포인트 2종만 측정했습니다. 텍스트 렌더링을 개선한 최신 모델이나 상용 서비스에는 옮겨 읽을 수 없습니다. 이 글은 "AI가 한글을 못 그린다"가 아니라 "이 두 체크포인트가 이 조건에서 못 그렸다"입니다.
• 프롬프트 문구를 한 종류만 썼습니다. 문구를 바꾸거나 컨트롤넷·인페인팅 같은 보조 기법을 쓰면 결과가 달라질 수 있습니다.
• 2~6글자 단어만 시험했습니다. 문장은 더 어렵습니다.
• 채점은 OCR 판독 기준입니다. 사람 눈에는 읽히는데 OCR이 놓친 경우가 있을 수 있어, 계측기 검증(한글 6/6·영어 6/6)을 그 하한으로 함께 실었습니다.
• 반복 3회는 같은 프롬프트의 재생성이라 완전히 독립된 시행이 아닙니다. 36장이라는 표본 수가 주는 인상보다 실제 불확실성은 큽니다.
• 가나·한자 출력은 이번 OCR 설정으로 별도 집계되지 않았습니다. 해당 서술의 근거는 이미지 육안 확인입니다.
• 측정 시점은 2026년 7월 31일입니다.

한 줄로 남기면, 이번 72장에서 정확한 글자는 어느 문자 체계로도 나오지 않았고, 한글은 글자꼴에 도달하는 단계에서 이미 걸렸습니다. 영어로 바꿔 우회하는 방법도 이번 조건에서는 통하지 않았습니다.

시네의 선택은 단순합니다. 그림은 모델에게, 글자는 편집기에게. 글자를 모델에게 맡겨 아끼는 시간보다, 틀린 획을 골라내며 재생성하는 시간이 더 비쌌습니다.

참고자료

• 테스트 방법론: cinevyze 고정 테스트셋 IMG-02-S 문자 체계 축, 실행기 run_hangul_img.py, 채점기 hangul_score.py
• 통계: 짝지은 이분 결과에 정확 McNemar 검정, 각 비율에 95% Wilson 구간
• 계측기 검증: 노토 산스 CJK 합성 렌더 12건에 동일 OCR 설정 적용
• 원자료: 생성 이미지 72장·OCR 전문·생성 파라미터와 aggregate.json을 실행 아티팩트에 보존

이 글은 cinevyze 운영자가 해당 모델을 테스트하고, 생성된 72장을 결정론적 채점기로 채점한 뒤 결과를 비교·검수해 정리·편집했습니다. 무엇을 어떻게 테스트할지·판단·사실확인은 모두 사람이 했고, 글 다듬는 일부 과정에 AI 도구의 도움을 받았습니다.