증상 — 글자가 얹히는 이미지에서만 결과가 두 방향으로 갈라졌다
SGK 스튜디오는 고객사에 납품하거나 자사 채널에 올릴 산출물을 손으로 만들지 않는다. 카드뉴스와 썸네일, 상세페이지, 제안서 슬라이드, 짧은 영상까지 AI 에이전트 여러 대가 역할을 나눠 맡는 파이프라인으로 찍어낸다. 같은 종류를 몇 번이고 다시 만들어야 하는 일이라, 매번 새로 설계하지 않으려고 짠 구조다.
이 파이프라인에서 유독 한 종류만 결과가 안 나왔다. 글자가 이미지 위에 얹히는 산출물, 그러니까 카드뉴스와 썸네일이다. 글만 뽑는 산출물은 문제가 없었고 슬라이드도 그럭저럭 넘어갔는데, 한글이 이미지에 올라가는 순간 결과물이 참고 대상으로 삼은 계정들의 카드와 확연히 달랐다.
더 이상한 건 실패가 두 방향으로 갈렸다는 점이다. 벤치마크로 본 해외 빌더는 카드 한 장을 통째로 이미지 생성 모델에 맡겼는데, 로고가 뭉개지고 정해 둔 가로세로 치수를 안 지켜서 3회씩 다시 뽑아야 했다. 우리 파이프라인은 정확히 반대였다. 카드 한 장을 통째로 HTML로 그렸더니 글자는 한 글자도 안 틀렸는데, 이미지가 없었다.
두 결과물을 나란히 놓으면 증상이 대칭이었다. 한쪽은 그림은 있는데 글자가 깨졌고, 다른 쪽은 글자는 완벽한데 그림이 없었다. 같은 자리에서 서로 반대 방향으로 실패하고 있었다는 사실이 이 조사의 출발점이다.
처음 의심한 것 — 생성 모델이 한글을 못 쓰는 게 원인이라고 봤다
처음 세운 가설은 도구 선택 문제였다. 이미지 생성 모델은 한글 글자를 제대로 못 쓴다, 그러니 글자가 들어가는 산출물은 생성 모델에 맡기지 말고 브라우저 렌더로 만들면 그만이다 — 이게 우리 1차 판정이었다.
이렇게 판정한 근거는 네 가지였고, 넷 다 실제로 확인한 것들이었다.
- 한글 조판이 정확하다 — 자간과 줄바꿈 위치를 브라우저가 알아서 잡아 준다
- 정해 둔 가로세로 치수를 어긋나는 법 없이 지킨다
- 수정이 CSS 한 줄이다 — 밴드 높이를 바꾸려고 이미지를 다시 뽑을 일이 없다
- 같은 입력이면 같은 그림이 나온다 — 재현성 100%
네 근거는 지금도 사실이다. 틀린 것은 근거가 아니라 결론이었다. 우리는 저 넷을 근거로 '우리 방식이 품질에서 앞선다'고 적었고, 그 한 문장이 카드 품질 문제를 한동안 덮었다. 결과물이 참고 대상과 다르게 보인다는 신호가 계속 들어왔는데도, 판정이 이미 서 있으니 신호를 품질 편차로만 읽었다.
그 판정이 맞는지 무엇으로 확인했나?
확인 수단은 세 가지였고, 공통 규칙이 하나 있었다. 인상을 적지 말고 개수를 세자는 것.
- 참고 계정 카드 전수 열람 — 팔로워 상위 계정 두 곳(각각 188K·57K)의 카드 24개를 실제로 열어 구성 요소를 하나씩 셌다 (2026년 8월 29일)
- 한국어 공개 게시글 코퍼스 전문 스캔 — 22,648건, 그 안에 담긴 프롬프트 블록 24,959개. 어떤 도구가 몇 개 글에서 언급되는지 셌다
- 영어권 빌더 채널 자막 95편과 공개 저장소 열람 — 별 382개가 붙은 디자인 매뉴얼을 포함해 레시피 원문을 직접 읽었다
세 수단의 공통점은 우리 결과물을 보지 않는다는 데 있다. 우리가 만든 카드를 아무리 오래 들여다봐도 '우리 방식이 낫다'는 판정은 반증할 수 없다. 반증하려면 이미 잘 되고 있는 쪽의 결과물을 세어야 했다. 그래서 첫 수단이 우리 산출물 검토가 아니라 남의 카드 전수 열람이었다.
숫자를 세는 방식도 정해 놨다. 카드 한 장을 열면 이미지 영역과 텍스트 영역이 각각 몇 퍼센트를 차지하는지, 라벨과 워터마크가 어디에 붙는지, 그리고 글자만으로 이루어진 카드가 몇 개인지를 기록했다. 마지막 항목이 가설을 죽였다.
알리바이 — 텍스트만으로 된 카드는 24개 중 0개였다
세어 보니 카드 24개 가운데 글자만으로 이루어진 카드는 0개였다. 하나도 없었다. 전부 이미지 영역과 텍스트 밴드가 겹쳐 있는 구조였다.
구조는 두 계정이 거의 같았다. 위쪽 60~70%가 이미지다. 생성한 그림이든 실사 사진이든 화면 캡처든, 어쨌든 렌더로는 못 만드는 종류가 그 자리를 채운다. 아래 30~40%가 짧은 라벨과 굵은 헤드라인 두 줄이고, 워터마크는 카드마다 늘 같은 자리에 붙는다.
여기서 처음 가설이 무너졌다. '생성 모델이 한글을 못 쓴다'는 관찰 자체는 맞았다. 틀린 것은 거기서 '그러니 전부 렌더로 만들면 된다'로 넘어간 추론이다. 잘 되고 있는 카드들은 애초에 둘 중 하나를 고르지 않았다.
이 숫자는 우리 카드가 참고 대상보다 나쁘다는 뜻도 아니었다. 아예 같은 종류가 아니었다는 뜻이다. 품질을 비교한 게 아니라 비교 대상이 아닌 물건을 비교했고, 그 상태로 우위를 적었다. 글자만 있는 카드를 만들어 놓고 품질 우위라고 쓰면 안 되는 이유가 이 0개에 다 들어 있다.
그러면 도구를 바꾸면 풀리는 문제였나?
반대편 실패가 그 답을 준다. 카드 전체를 생성 모델에 맡긴 쪽은 도구를 안 바꿔서 실패한 게 아니다. 같은 모델로 3회를 다시 뽑아도 로고는 계속 뭉개졌고 규격도 안 맞았다. 재생성 횟수를 늘려서 넘을 벽이 아니었다.
글자가 조금만 많으면 거의 백퍼 오타
도구를 갈아 끼우는 선택지가 얼마나 넓은지도 같이 셌다. 게시글 22,648건을 전문으로 훑어 도구별 언급 글 수를 뽑았다.
이 표가 말해 주는 건 순위가 아니다. 언급 빈도가 곧 품질은 아니고, 무엇을 먼저 열어 볼지만 정해 준다. Nano Banana가 273건으로 급하게 올라온 반면 Photoshop이 106건으로 이미 주변부라는 사실 정도가 읽히는 전부다.
그래도 한 가지는 분명해졌다. 상위권 도구를 아무거나 골라도 한글 글자가 깨지는 증상은 그대로였다. 도구 교체는 해법이 아니었고, 우리와 벤치마크 양쪽 모두 이 문제를 도구 고르기로 다뤘다가 반대 방향으로 실패했다.
진짜 원인 — 이미지는 생성도 렌더도 아니고 합성이었다
두 실패를 겹쳐 놓고서야 원인이 보였다. 양쪽 모두 카드 한 장을 통째로 한 도구에 맡겼다. 한쪽은 글자를 못 만드는 도구에 글자까지 맡겼고, 다른 쪽은 질감과 사물과 인물을 못 만드는 도구에 배경까지 맡겼다. 방향만 반대일 뿐 실수는 같았다.
카드 한 장은 단일 산출물이 아니었다. 성격이 전혀 다른 두 층이 겹쳐 있는 물건이고, 각 층을 잘 만드는 도구가 서로 다르다. 우리는 그 층을 가르지 않은 채 도구부터 골랐고, 그래서 어느 쪽을 골라도 절반이 망가졌다.
한국어에서는 이 결론이 더 세게 걸린다. 로고든 썸네일이든 카드뉴스든, 한글 글자를 이미지 생성에 맡기면 거의 반드시 오타가 난다는 게 코퍼스 전반에서 반복해 나온 단일 결론이었다. 영어권 레시피를 그대로 들여오면 안 되는 자리가 정확히 여기다.
고친 방법 — 층을 갈라 각자 잘하는 쪽에 맡겼다
고친 방법은 단순했다. 카드 한 장을 두 층으로 가르고, 층마다 잘하는 도구를 따로 붙였다.
조립은 한 번에 끝난다. 배경을 CSS 배경 이미지로 깔고 그 위에 텍스트 밴드를 얹은 다음, 브라우저 자동화로 화면을 통째로 찍는다. 1080x1080 화면을 2배 해상도로 열고, 폰트와 배경이 다 그려질 때까지 2,500ms를 기다린 뒤에 촬영한다. 카드 한 장이 파일 하나로 떨어진다.
이 과정에서 1차 판정도 같이 정정했다. 한글 조판과 규격, 재현성이 참고 대상보다 낫다는 부분은 실측대로 살려 뒀다. 미달이었던 것은 품질이 아니라 구조였고, 그 구멍은 배경 이미지가 들어오는 순간 닫힌다. 판정을 통째로 뒤집는 대신 틀린 문장 하나만 갈아 끼웠다.
다만 여기엔 아직 닫히지 않은 자리가 있다. 배경을 뽑을 유료 생성 경로가 지금은 없다. 붙어 있는 이미지 생성 서비스는 2026년 9월 3일 확인 기준 잔액 0의 무료 등급이라 오늘 쓸 수 있는 길이 아니었다. 방법을 아는 것과 결제 경로가 열려 있는 것은 다른 문제고, 이 글이 닫은 것은 앞쪽뿐이다. 그동안 배경 자리는 실사 사진과 화면 캡처로 메운다.
같은 실수를 막는 장치 — 산출물마다 다섯 층으로 팀을 세운다
카드 한 장을 잘 고치는 것만으로는 같은 실수가 다시 난다. 다음번에 상세페이지를 만들 때, 그다음에 쇼츠를 만들 때 또 통째로 한 도구에 맡길 테니까. 그래서 산출물마다 팀을 세우고 그 팀의 뼈대를 다섯 층으로 고정했다.
조립 순서도 정해 놨다. 폴더를 먼저 만들고, 반복 실행 매뉴얼을 붙이고, 작업 표준 문서를 쓰고, 판단을 맡을 에이전트를 세우고, 마지막에 발행 경로를 연결한다. 순서를 바꾸면 판단이 필요한 자리에 반복 실행이 들어가서 품질이 무너진다.
팀을 만들라고 지시할 때 반드시 넣는 문장이 둘 있다. 에이전트 폴더와 매뉴얼 폴더를 구분해서 만들라는 문장, 그리고 판단이 필요한 일과 반복 실행을 나눠 달라는 문장이다. 이 둘을 빼면 결과가 문서 파일 하나로 전부 뭉친다. 실측으로 확인한 기본 실패 형태다.
팀을 세울지 말지도 미리 판정한다.
- 앞으로 3회 이상 만들 것 같으면 팀을 세운다
- 1회성이고 다시 안 만들면 팀을 세우지 않고 그냥 만든다 — 초기 세팅에 드는 시간이 실제로 길다
- 고객사에 납품할 산출물이면 무조건 세운다. 수정 요청이 반드시 오기 때문이다
테스트에도 순서를 뒀다. 팀 전체를 돌리기 전에 에이전트를 하나씩 단독으로 불러 결과를 본다. 전부 돌린 다음 디버깅하면 다섯 층 가운데 어디가 틀렸는지 안 보인다. 이번 사고도 층을 안 갈랐기 때문에 어느 도구가 문제인지만 계속 따졌던 셈이다.
값 하나를 여러 층이 나눠 정하는 자리를 놓쳐 판단이 뒤집힌 사례는 이 자리에도 있다. 근거를 붙였는데도 최종 값이 아니었던 기록도 층을 하나 빠뜨리면 확인 절차가 통째로 헛돈다는 같은 문제를 다룬다.
왜 1차 결과물은 그대로 채택되지 않는가?
실측에서 가장 실무적으로 쓸모 있던 사실이 이거다. 1차 결과물은 채택되지 않았다. 우리가 본 사례가 전부 3차에서 통과했다. 그래서 지금은 3회 반복을 처음부터 일정과 비용에 넣고 시작한다. 한 번에 나올 거라고 잡으면 그 계획이 어긋난다.
재지시 문구도 다시 썼다. 증상을 구체적으로 말한 지시만 결과를 바꿨고, 아래 넷은 실제로 통했던 문장들이다.
- "전체 이미지 가로세로 높이를 1200으로 고정해 줘"
- "샘플 이미지를 줄 테니 이걸 바탕으로 다시 만들어 줘"
- "디자인 매뉴얼이 제대로 연동 안 된 것 같아. 확인하고 개선해 줘. 폰트는 프리텐다드로 고정"
- "자막이 음성에 따라 제대로 나오지 않고 있어. 받아쓰기 매뉴얼 확인해서 고쳐 줘"
반대로 "더 잘 만들어 줘"는 아무것도 바꾸지 못한다. 무엇이 어긋났는지 지목하지 않으면 다음 결과물도 같은 자리에서 어긋난다.
층을 갈라 놓으면 비용도 층별로 잡힌다. 텍스트 밴드 쪽은 브라우저 렌더라 0원이고, 돈이 드는 자리는 배경과 영상뿐이다.
표본이 얇아서 아직 일반화하지 않기로 한 자리도 그대로 적어 둔다. 한국어 코퍼스에서 썸네일을 따로 다룬 글은 후보 22건뿐이었고, 제품 사진 컷의 진짜 사례는 14건, 그대로 게시할 수 있는 완결형 인포그래픽 사례는 사실상 1건이었다. 이 정도 표본으로 레시피를 확정하면 다음 사고를 준비하는 셈이다.
밖으로 나가기 전 검사도 세 가지로 고정했다.
- 리서치가 붙은 산출물에는 없는 사실이 섞인다 — 검증 없이 내보내지 않는다
- 저작권 있는 레퍼런스는 방향을 지시하는 재료지 납품물이 아니다
- 접속 키는 매뉴얼 문서에 적지 않고 환경 설정 파일에 둔다
산출물 품질을 사람 눈 대신 기계 검사로 거른 다른 기록은 한국어 번역체를 자동으로 잡은 이야기에 있다. 회사 안에서 카드뉴스나 상세페이지, 제안서 같은 산출물을 반복해 찍어내야 하는 상황이라면 상담에서 저희가 실제로 쓰는 층 구분을 더 구체적으로 나눌 수 있다.