AI 블로그 대표 이미지가 제각각이라 스타일 가이드를 만들었습니다

AI로 블로그 대표 이미지를 만들면 그림 한 장을 얻는 일 자체는 어렵지 않았습니다. 글의 주제를 설명하고 원하는 분위기를 적으면 몇 분 안에 결과가 나왔습니다. 그런데 글이 늘어나자 다른 문제가 보였습니다. 각각의 이미지는 괜찮아도 한 화면에 모아 놓으면 서로 다른 사이트의 그림처럼 보였습니다.

어떤 글에는 실제 프로그램 화면을 캡처한 이미지가 있었고, 어떤 글에는 오렌지가 강한 3D 그림이 있었습니다. 크기와 비율도 같지 않았습니다. 새 글을 쓸 때마다 “깔끔하게”, “미니멀하게” 같은 표현을 다시 적었지만, 이 정도 설명만으로는 지난 이미지와 같은 분위기가 이어지지 않았습니다.

그래서 이번에는 새 이미지를 잘 만드는 방법보다 다음 이미지도 같은 사이트의 이미지처럼 만드는 방법을 먼저 정리했습니다. 두 장의 기준 이미지를 고르고, 고정할 표현과 사용하지 않을 요소를 문서로 만들었습니다. 이 글은 일반적인 AI 이미지 프롬프트 모음이 아니라 minml에 실제로 적용한 대표 이미지 스타일 가이드 제작 기록입니다.

이미지 한 장씩 볼 때는 문제가 잘 보이지 않았습니다

기존 대표 이미지가 모두 나빴던 것은 아닙니다. 글의 내용에 맞는 화면 캡처는 사용 중인 도구를 바로 보여줬고, 개별 3D 이미지도 각 글의 주제를 설명했습니다. 문제는 홈 화면과 관련 글 목록처럼 여러 장이 함께 보일 때였습니다.

파일도 확인해보니 과거 이미지에는 776×338 화면 캡처와 1693×929 PNG가 함께 있었습니다. 최근에 만든 이미지는 1536×1024 WebP를 사용하고 있었습니다. 비율, 여백, 색상, 파일 형식 중 매번 같은 기준으로 결정한 항목이 적었던 셈입니다.

이 상태에서는 다음과 같은 일이 반복됐습니다.

• 새 글을 쓸 때 이전 프롬프트를 다시 찾아야 했습니다.
• “미니멀”이라는 같은 단어를 사용해도 오브젝트 수와 색상이 달라졌습니다.
• 결과가 마음에 들지 않는 이유를 구체적으로 설명하기 어려웠습니다.
• 대표 이미지와 공유용 이미지 경로를 각각 확인해야 했습니다.
• 생성 결과가 좋아 보이면 크기와 파일 용량 검사를 건너뛰기 쉬웠습니다.

대표 이미지 스타일을 통일한다고 글의 품질이나 검색 순위가 자동으로 좋아지는 것은 아닙니다. 클릭률도 따로 측정하지 않았습니다. 제가 해결하려던 문제는 더 단순했습니다. 독자가 작은 카드에서 이미지를 봐도 같은 사이트의 글이라는 느낌이 들고, 다음 이미지를 만들 때 판단 기준을 다시 만들지 않는 것이었습니다.

마음에 든 이미지 두 장을 기준으로 정했습니다

처음에는 색상 코드와 프롬프트만 문서에 적으려고 했습니다. 하지만 “차콜과 라벤더를 사용한다”는 문장만으로는 오브젝트의 둥근 정도, 그림자의 강도, 여백과 입체감을 정확히 전달하기 어려웠습니다. 그래서 이미 사이트에서 사용 중인 이미지 중 분위기가 가장 가까운 두 장을 기준 이미지로 골랐습니다.

첫 번째는 AI로 사이트를 만드는 과정을 표현한 이미지입니다.

두 번째는 Ghost에서 Astro로 옮기는 과정을 표현한 이미지입니다.

두 장을 고른 이유는 주제가 같아서가 아닙니다. 하나는 웹사이트 제작, 다른 하나는 마이그레이션을 다루지만 표현 방식은 비슷합니다. 밝은 배경 위에 큰 오브젝트가 가로로 놓이고, 차콜과 흰색이 대부분을 차지하며 라벤더와 오렌지는 강조에만 사용됩니다. 세부 문양을 읽지 않아도 왼쪽에서 오른쪽으로 이어지는 큰 형태가 보입니다.

앞으로 이미지를 만들 때는 이 두 파일을 말로만 설명하지 않고 실제 참조 이미지로 함께 넣기로 했습니다. 글의 소재는 바꾸되 재질, 색상, 조명과 여백은 두 장에서 이어받는 방식입니다.

넣을 것보다 사용하지 않을 것을 먼저 적었습니다

AI 이미지 요청문에는 원하는 요소를 많이 적기 쉽습니다. 그러나 결과가 제각각이 된 원인을 돌아보니 무엇을 넣을지보다 무엇을 빼야 하는지가 더 중요했습니다. “세련된 인포그래픽”이라고 요청하면 작은 점과 얇은 연결선이 늘어날 수 있고, “감성적인 블로그”라고 하면 베이지 종이 질감이 생길 수 있습니다. 각각은 흔히 쓰이는 표현이지만 현재 minml의 이미지와는 맞지 않았습니다.

그래서 스타일 가이드에 다음 요소를 사용하지 않는다고 명시했습니다.

사용하지 않는 요소	제외한 이유
글자, 숫자, 로고와 워터마크	생성된 글자가 틀릴 수 있고 썸네일에서 읽기도 어려움
장식용 점과 불필요한 원형 표시	작은 요소가 늘어나면 주제보다 장식이 먼저 보임
얇은 선 위주의 인포그래픽	작은 카드에서 선과 단계가 뭉개짐
평면적인 2D 아이콘 모음	기준 이미지의 둥근 3D 클레이 재질과 달라짐
베이지 종이 질감과 거친 그레인	흰색에서 옅은 라벤더로 이어지는 배경과 충돌함
마젠타, 네온과 강한 그라데이션	차콜·흰색 중심의 차분한 색상보다 강하게 튐
너무 많은 단계와 작은 소품	대표 이미지가 설명서처럼 복잡해짐
사실적인 사진 표현	기존 3D 클레이 이미지와 같은 시각 언어를 만들기 어려움

금지 목록은 AI가 틀렸을 때 탓하기 위한 규칙이 아닙니다. 제가 원하는 결과를 더 구체적으로 판단하기 위한 체크리스트입니다. 결과에 작은 점이 있다고 무조건 버리는 것도 아닙니다. 색상표의 견본처럼 역할이 분명한 원형은 남길 수 있지만, 빈 공간을 채우기 위한 장식이라면 제외합니다.

한 글을 오브젝트 2~3개로 줄였습니다

글 전체 내용을 이미지 한 장에 다 넣으려고 하면 화면이 복잡해졌습니다. 이번 글만 해도 과거 이미지, 프롬프트, 색상, 파일 변환, 대체 텍스트와 검수까지 모두 표현할 수 있습니다. 하지만 이것을 각각 아이콘으로 만들면 작은 단계가 이어진 인포그래픽이 됩니다.

그래서 글의 핵심 질문을 먼저 한 문장으로 줄였습니다.

서로 다른 AI 대표 이미지를 하나의 기준으로 어떻게 맞췄을까?

이 문장에서 필요한 큰 오브젝트만 골랐습니다.

오브젝트	의미
왼쪽 흰색 이미지 카드	통일하기 전 또는 기준에 맞출 첫 번째 이미지
중앙 차콜 기준판	색상, 재질과 구도를 정한 스타일 가이드
오른쪽 흰색 이미지 카드	같은 기준을 적용한 다음 이미지

최종 이미지에는 이 세 덩어리만 크게 보이게 했습니다. 양쪽 카드에는 같은 라벤더 산 모양과 오렌지 포인트를 사용하고 중앙에는 색상과 형태를 확인하는 기준판을 배치했습니다. 실제 문서 화면을 그대로 그리거나 STYLE GUIDE 같은 글자를 넣지는 않았습니다. 제목과 본문이 이미 설명하는 내용을 이미지 안에서 다시 읽게 할 필요가 없었기 때문입니다.

기본 프롬프트는 변하는 부분을 하나만 남겼습니다

매번 새 프롬프트를 쓰지 않도록 고정 문장과 글마다 바꿀 문장을 나눴습니다. 현재 사용하는 기본 구조는 다음과 같습니다.

Create a wide blog feature image matching the supplied minml reference images:
minimalist 3D clay render, rounded matte objects, soft diffuse studio lighting,
gentle shadows, pale white-to-lavender background, charcoal and white primary
palette with restrained lavender and warm orange accents.

Show only 2–3 large simple objects that communicate [ARTICLE CONCEPT],
with a strong silhouette, generous negative space, and a calm composition
readable at thumbnail size. Landscape 3:2, 1536 × 1024.

No text, letters, numbers, logos, watermark, decorative dots, thin line art,
flat infographic styling, beige paper texture, busy multi-step flow,
photorealism, or neon gradients.

여기서 글마다 바꾸는 핵심은 [ARTICLE CONCEPT]입니다. 이번에는 “서로 다른 두 이미지 카드를 중앙의 스타일 기준판으로 통일한다”는 장면을 넣었습니다. 스타일과 금지 요소까지 매번 바꾸면 참조 이미지를 사용해도 결과의 범위가 다시 넓어집니다.

OpenAI의 이미지 API 참조에는 가로 이미지 크기로 1536×1024가 나열돼 있고 PNG, WebP와 JPEG 출력 형식도 안내돼 있습니다. 저는 이번에 Codex의 내장 이미지 생성 기능으로 1536×1024 PNG를 만든 뒤, 사이트에 저장할 때 WebP로 변환했습니다. API 예제를 그대로 사용했다는 뜻은 아니며, 실제 minml 작업 환경에서는 생성과 최종 저장 단계를 나눴습니다.

생성 결과를 그대로 발행하지 않았습니다

프롬프트와 참조 이미지를 넣어도 결과가 자동으로 발행 가능한 것은 아닙니다. 생성된 이미지를 원본 크기로 열고 다음 항목을 확인했습니다.

1. 글자나 로고처럼 읽어야 하는 요소가 없는가
2. 큰 오브젝트가 세 개를 넘지 않는가
3. 차콜과 흰색이 주조색이고 라벤더·오렌지가 포인트에 머무는가
4. 배경이 밝고 그림자가 너무 강하지 않은가
5. 작은 카드로 줄여도 양쪽 이미지와 중앙 기준판이 구분되는가
6. 장식만을 위한 점, 선과 작은 소품이 생기지 않았는가
7. 기준 이미지와 나란히 보았을 때 재질과 분위기가 이어지는가

이번 결과의 중앙 기준판에는 둥근 색상 견본이 있습니다. 가이드에서 장식용 점을 금지했지만 이 원형들은 빈 공간을 꾸미기 위한 요소가 아니라 팔레트를 보여주는 역할이 있어 남겼습니다. 반대로 화면 주변에 흩어진 작은 점이나 연결선이 생성됐다면 다시 만들었을 것입니다. 규칙을 기계적으로 세는 것보다 각 요소의 역할을 설명할 수 있는지를 기준으로 삼았습니다.

PNG를 WebP로 바꾸고 파일명도 다시 정했습니다

내장 이미지 생성 결과는 PNG로 저장됐습니다. 이 파일을 1536×1024인지 확인한 뒤 WebP 품질 84로 변환해 다음 경로에 저장했습니다.

public/content/images/2026/08/ai-feature-image-style-guide-clay.webp

최종 파일은 17,838바이트였습니다. 비교를 위해 확인한 과거 1693×929 PNG 한 장은 876,042바이트였습니다. 이것은 스타일 가이드만으로 파일이 작아졌다는 증거가 아닙니다. 이미지 내용과 압축 형식이 다르고 WebP 변환의 영향도 큽니다. 다만 대표 이미지 규칙에 크기와 저장 형식을 함께 넣으니, 생성할 때마다 파일 용량을 뒤늦게 발견하는 문제는 줄일 수 있습니다.

파일명도 생성 도구가 만든 긴 이름을 그대로 쓰지 않았습니다. 연도와 월 폴더 아래에 글의 내용을 알 수 있는 영문 이름을 사용했습니다. 나중에 글 파일만 보더라도 어떤 이미지인지 찾기 쉽고, 비슷한 파일을 다시 만들 때 구분하기도 편합니다.

글의 대표 이미지와 공유 이미지를 함께 확인했습니다

이미지 파일을 저장해도 글과 연결하지 않으면 화면에 나타나지 않습니다. minml의 Markdown 글 앞부분에는 대표 이미지와 공유 이미지를 지정하는 항목이 있습니다. 이번 글에는 같은 WebP 파일을 연결하고, 그림의 내용을 설명하는 대체 텍스트를 따로 적었습니다.

featureImage: "/content/images/2026/08/ai-feature-image-style-guide-clay.webp"
featureImageAlt: "서로 같은 분위기의 이미지 카드 두 장과 중앙의 차콜 스타일 기준판을 배치한 3D 클레이 이미지"
ogImage: "/content/images/2026/08/ai-feature-image-style-guide-clay.webp"

대체 텍스트에는 “AI 이미지”처럼 넓은 말만 넣지 않았습니다. 화면을 보지 못해도 주요 오브젝트와 관계를 이해할 수 있도록 양쪽 카드와 중앙 기준판을 설명했습니다. 검색어를 반복하기 위한 문장으로 만들지도 않았습니다.

발행 전에는 글 페이지에서 대표 이미지가 보이는지, 홈 목록의 작은 카드에서도 잘리지 않는지, 공개 이미지 주소가 정상 응답하는지 확인합니다. 파일이 로컬에 있다는 사실과 실제 사이트에서 불러와진다는 사실은 구분해서 검사합니다.

스타일 가이드가 대신 결정하지 못하는 것도 있습니다

규칙을 만들고 나니 프롬프트 작성과 검수는 쉬워졌지만, 글의 핵심을 정하는 일까지 자동화되지는 않았습니다. 특히 다음 항목은 매번 제가 판단해야 했습니다.

• 글에서 독자가 가장 먼저 알아야 할 장면이 무엇인지
• 그 장면을 어떤 오브젝트 2~3개로 줄일지
• 참조 이미지와 비슷하지만 이전 그림을 그대로 반복하지는 않았는지
• 생성된 세부 요소가 장식인지 실제 의미가 있는지
• 이미지가 글의 내용을 과장하거나 존재하지 않는 결과를 암시하지 않는지
• 대체 텍스트가 실제 결과를 정확히 설명하는지

예를 들어 서버 작업 글에서는 서버, 작업 화면과 안전을 나타내는 방패가 필요했습니다. 백업 글에서는 원본을 보관하는 상자와 복구된 사이트가 핵심이었습니다. 모든 글에 노트북과 AI 로봇을 반복해서 넣으면 색상은 통일돼도 각 글의 주제가 구분되지 않습니다.

스타일 가이드는 선택지를 줄여주지만 주제를 대신 정해주지는 않습니다. 저는 AI에게 재질과 조명, 구도를 반복해서 설명하는 시간을 줄이고, 그 대신 이번 글을 어떤 장면으로 보여줄지에 더 집중하려고 이 문서를 만들었습니다.

앞으로는 같은 순서로 대표 이미지를 만듭니다

현재 정한 작업 순서는 다음과 같습니다.

1. 글의 핵심을 한 문장으로 줄입니다.
2. 그 문장을 큰 오브젝트 2~3개로 바꿉니다.
3. 기준 이미지 두 장을 참조로 넣습니다.
4. 고정 프롬프트에서 글의 장면만 바꿉니다.
5. 글자, 장식용 점, 얇은 선과 과도한 소품을 검사합니다.
6. 1536×1024 WebP 품질 84로 저장합니다.
7. 의미 있는 영문 파일명을 사용합니다.
8. 대표 이미지, 공유 이미지와 대체 텍스트를 함께 연결합니다.
9. 데스크톱과 모바일 카드, 공개 이미지 주소를 확인합니다.

이 순서가 모든 블로그에 맞는 정답은 아닙니다. 사진이 중요한 여행 블로그나 제품 실물이 필요한 리뷰에서는 실제 사진을 기준으로 삼는 편이 더 적합할 수 있습니다. minml은 AI 도구, 블로그 이전과 정적 사이트 운영처럼 눈에 보이지 않는 과정을 자주 다루기 때문에 단순한 3D 오브젝트가 잘 맞았습니다.

이번 스타일 가이드를 만든 뒤 승인 결과나 방문자 반응이 달라졌다고 말할 단계는 아닙니다. 아직 측정하지 않은 효과를 성공 사례처럼 적고 싶지는 않습니다. 지금 확인한 변화는 새 글마다 이미지 방향을 처음부터 정하지 않아도 되고, 결과를 남길지 다시 만들지 설명 가능한 기준이 생겼다는 것입니다.

앞으로 새 대표 이미지를 만들면서 예외가 반복되면 가이드도 수정할 예정입니다. 중요한 것은 한 번 정한 스타일을 영원히 지키는 것이 아니라, 왜 이 결과를 선택했는지 다음 작업에서도 확인할 수 있게 남겨두는 일이라고 생각합니다.

참고한 공식 문서

• OpenAI 이미지 API 참조