AI로 광고 소재를 대량 생산하면 브랜드가 흔들린다는 말을 자주 듣습니다. 저희는 원인이 AI의 감각이 아니라 규칙이 놓인 위치에 있다고 봅니다. 이 글은 저희가 자사 이미지를 만들면서 실제로 밟은 것들과, 그 과정에서 저희 브랜드 문서에서 발견한 오류를 다룹니다.
문서에 적어 둔 규칙은 왜 안 지켜지나
생성형 AI로 소재를 만드는 자리에서 브랜드 가이드는 거기 없습니다. 프롬프트를 쓰는 사람의 기억 속에 있거나, 다른 탭에 열려 있습니다. 규칙이 지켜지는지는 결과물이 나온 뒤 사람이 눈으로 볼 때 처음 확인됩니다.
문제는 눈으로 보면 대부분 괜찮아 보인다는 것입니다. 대비가 조금 모자란 색, 폰트가 살짝 다른 글자, 규격이 어긋난 여백은 한 장만 보면 넘어갑니다. 소재를 스무 장 만들면 스무 번 넘어갑니다.
메타 어드밴티지+처럼 매체가 조합을 자동 생성하는 환경에서는 이 문제가 커집니다. 사람이 검수할 수 있는 양보다 만들어지는 양이 많아지기 때문입니다.
규칙이 사람 손을 거치면 조용히 어긋납니다
저희 브랜드 문서에는 색 조합별 대비비가 적혀 있습니다. 「밝은 바탕에 강조색을 글자로 쓰지 마라, 대비 1.4:1이라 안 보인다」 같은 문장입니다.
이번에 이미지를 만들면서 그 숫자를 옮겨 적지 않고 직접 계산했습니다. 결과가 갈렸습니다.
| 조합 | 문서에 적힌 값 | 직접 계산한 값 | 판정 |
|---|---|---|---|
| 강조색 글자 / 밝은 바탕 | 1.4 : 1 | 2.95 : 1 | 재현 안 됨 |
| 흰 글자 / 강조색 버튼 | 3.2 : 1 | 3.20 : 1 | 일치 |
| 잉크 글자 / 강조색 버튼 | 5.5 : 1 | 5.77 : 1 | 사실상 일치 |
| 진한 강조색 글자 / 밝은 바탕 | 8.2 : 1 | 8.19 : 1 | 일치 |
2026년 8월 27일 기준, WCAG 상대휘도 식으로 계산했습니다.
넷 중 셋은 소수점까지 맞았습니다. 하나만 틀렸습니다. 다행히 결론은 바뀌지 않습니다. 2.95:1도 본문 기준 4.5:1과 큰 글자 기준 3:1을 둘 다 넘지 못하므로, 「쓰지 마라」는 판단은 그대로입니다.
바뀌지 않았기 때문에 아무도 몰랐습니다. 결론이 맞으니 숫자를 다시 확인할 이유가 없었습니다. 규칙을 문서에 적어 두면 이런 오류는 검증되지 않은 채로 남습니다.
색은 색이 아니라 「색 + 바탕」입니다
강조색을 쓰지 말라는 규칙이 아닙니다. 같은 색이 어느 바탕에 올라가느냐로 판정이 갈립니다.
이것이 프롬프트로 전달하기 어려운 종류의 규칙입니다. 「우리 브랜드 색은 이 파랑입니다」까지는 말할 수 있지만, 「단 밝은 배경에서는 이 파랑 대신 저 파랑을 쓰고, 버튼 위 글자는 흰색이 아니라 잉크색입니다」는 조건문입니다. 조건문은 프롬프트보다 코드에 적는 편이 확실합니다.
오류가 조용한 이유
브랜드 규칙 위반은 대부분 에러를 내지 않습니다. 저희가 이번에 밟은 것들이 전부 그랬습니다.
사람이 손으로 배너를 만들던 때에는 매체별 규격을 하나씩 맞춰 가며 작업했기 때문에, 어긋난 것이 그 자리에서 눈에 띄었습니다. 생산 속도가 올라가면 그 자리가 사라집니다.
- 대비가 모자란 색 조합 — 그려집니다. 안 읽힐 뿐입니다
- 버튼 위 흰 글자 — 그려집니다. 보기에는 오히려 그럴듯합니다
- 폰트에 없는 글자 — 빈 네모로 그려지거나 다른 폰트로 대체됩니다
세 번째는 이 글의 도해를 만들다 실제로 겪었습니다. 코드용 글꼴로 한글을 그렸더니 네 글자가 전부 빈 네모가 됐습니다. 스크립트는 정상 종료했고 파일도 만들어졌습니다. 이미지를 열어 보기 전까지는 알 수 없었습니다.
이 종류의 오류는 「검수를 꼼꼼히 한다」로 막히지 않습니다. 만드는 양이 늘어나는 만큼 놓치는 양도 같이 늘어나기 때문입니다.
그래서 규칙을 어디에 두나
저희가 자사 이미지를 만들 때 쓰는 방식은 단순합니다. 색·글꼴·여백을 생성 스크립트 안의 상수로 두고, 대비비는 문서에서 가져오지 않고 계산합니다.
- 색은 이름이 아니라 값으로 고정합니다. 「코발트」가 아니라 실제 코드값입니다
- 바탕이 밝은지 어두운지에 따라 강조색을 함수가 고르게 합니다. 사람이 매번 판단하지 않습니다
- 대비비는 계산해서 확인합니다. 문서에 적힌 값을 믿지 않습니다 — 위에서 하나가 틀렸습니다
- 글꼴은 필요한 글자가 그 글꼴에 있는지부터 봅니다
이 방식의 이점은 규칙이 지켜지는 것 자체보다, 규칙이 틀렸을 때 그것을 알 수 있다는 데 있습니다. 계산되는 값은 재확인할 수 있지만 문서에 적힌 값은 아무도 다시 세지 않습니다.
생성형 AI 이야기로 돌아오면, 프롬프트에 브랜드 규칙을 길게 쓰는 것보다 규격이 정해진 부분을 아예 생성 밖으로 빼는 쪽이 안정적입니다. 저희 블로그 도해 규칙을 정할 때도 같은 판단을 했습니다. 사람이 매번 지켜야 하는 규칙은 결국 안 지켜집니다.
자주 묻는 질문
브랜드 가이드 문서를 만들 필요가 없다는 뜻인가요?
아닙니다. 문서는 왜 그렇게 정했는지를 남기는 자리로 여전히 필요합니다. 다만 기계가 매번 지켜야 하는 값은 문서가 아니라 실행되는 코드에 있어야 합니다. 둘은 역할이 다릅니다.
대비비를 왜 직접 계산하나요? 검사 도구가 많은데요.
도구를 쓰는 것도 좋습니다. 요점은 계산 여부가 아니라 어느 시점에 확인하느냐입니다. 결과물이 나온 뒤에 검사하면 고칠 것이 이미 스무 장입니다. 만드는 순간에 계산하면 애초에 틀린 것이 안 나옵니다.
이런 규칙을 프롬프트에 다 적으면 되지 않나요?
부분적으로는 됩니다. 다만 조건이 붙는 규칙은 프롬프트에서 잘 지켜지지 않습니다. 「밝은 배경일 때만」 같은 단서는 생성할 때마다 판단이 흔들립니다. 판단이 흔들리면 안 되는 것부터 코드로 옮기고, 흔들려도 되는 것을 AI에 맡기는 순서가 낫습니다.
소재를 많이 만드는 게 의미가 없다는 뜻인가요?
많이 만드는 것 자체는 이제 어렵지 않습니다. 저희가 보는 차별점은 만드는 양이 아니라 무엇을 버릴지 아는 기준이고, 브랜드 규칙은 그 기준 중 자동으로 판정할 수 있는 부분입니다. 자동으로 걸러지는 것을 사람이 보고 있을 이유가 없습니다.
마무리
브랜드가 흔들리는 것을 감각의 문제로 보면 검수를 늘리게 되고, 규칙의 위치 문제로 보면 생성 단계를 고치게 됩니다. 저희는 후자를 택했고, 그 과정에서 저희 문서의 숫자 하나가 몇 달간 틀린 채로 있었다는 것을 알게 됐습니다.
지금 쓰고 계신 브랜드 가이드에서 기계가 매번 지켜야 하는 값이 몇 개인지, 그중 실제로 계산되고 있는 것이 몇 개인지 세어 보시면 됩니다.
참고: 이 글의 대비비는 2026년 8월 27일 자사 팔레트를 WCAG 상대휘도 식으로 직접 계산한 값입니다. 문서와 다른 항목은 문서 쪽을 정정할 예정입니다.