AI 블로그 작가에게 자기 그림 그리는 손을 달아준 이야기

베르톨트에게 블로그 글을 맡기면서 제일 먼저 빈 곳은 문장이 아니었다. 문장은 규칙 문서와 발제 dossier를 읽히면 어떻게든 따라왔다. 문제는 이미지였다. 글은 길어지고, 구조는 복잡해지고, 목록에는 썸네일 자리가 생겼는데 정작 글을 쓰는 AI 작가는 손에 펜만 들고 있었다.

내 요구는 단순했다. “글에 맞는 이미지를 스스로 만들어 넣게 하자.” 하지만 곧바로 막혔다. 생성형 AI에게 전부 맡기면 편할 것 같지만, 기술 블로그에서 이미지는 장식이 아니라 정보다. 박스 하나, 화살표 하나, 라벨 하나가 본문과 어긋나면 글 전체의 신뢰가 깨진다.

시작점은 텍스트 과잉이었다

블로그는 이미 전면 AI 저작으로 돌아가고 있었다. second가 발제를 만들고, blog 리포가 글로 만들고, 발행 스크립트가 dev와 main을 밀어 라이브까지 보낸다. 최근에는 집필 주체도 Claude Code 러너에서 헤르메스 직원 베르톨트로 옮기는 중이었다.

그런데 베르톨트가 쓰는 글은 자연히 텍스트 중심이 됐다. 아키텍처 흐름을 설명해도 그림이 없고, 비교를 해도 표나 문장만 있다. 특히 목록과 상세 페이지에 썸네일 자리가 생긴 뒤에는 빈자리가 더 또렷했다.

초기 제약은 세 가지였다.

• 비용 0: 별도 유료 이미지 서비스는 쓰지 않는다.
• Astro 불가침: 빌드 파이프라인에 다이어그램 플러그인을 새로 끼워 리스크를 만들지 않는다.
• 정적 배포 유지: Cloudflare Pages에는 완성된 PNG만 올린다.

즉, 목표는 멋진 이미지 한 장을 뽑는 일이 아니라 글쓰기 절차 안에 이미지 제작 단계를 넣는 것이었다.

생성형과 코드 렌더를 갈랐다

처음에는 “생성형 이미지로 다 하면 되지 않나”라는 생각이 가장 쉽다. 그런데 리서치와 실측을 거치면 그 생각은 빨리 무너진다. 생성형 모델은 텍스트 정확도가 올라와도 여전히 확률적이다. 라벨이 깨질 수 있고, 항목을 빼거나 지어낼 수 있고, 같은 프롬프트에서도 박스 수와 화살표 방향이 흔들린다.

그래서 이미지를 네 종류로 나눴다.

분류	맡은 일	만드는 손	텍스트
썸네일	글의 핵심 은유 한 장면	생성형 이미지	없음
구조도	흐름·관계·아키텍처	D2 코드 렌더	정확해야 함
인포그래픽	분류·비교·단계	SVG 직접 작성	본문과 1:1 일치
은유 삽화	감각적 보충	생성형 이미지	없음

판단 기준은 한 줄이면 됐다.

정확한 정보가 실리는 이미지는 코드로 만들고, 생성형 이미지는 텍스트 없는 은유에만 쓴다.

이 결정이 파이프라인의 척추가 됐다. 즉, 생성형 AI의 장점은 “그럴듯한 장면을 만드는 능력”에만 쓰고, 정보의 정확성은 D2와 SVG처럼 소스가 남는 방식에 맡긴다.

코드로 그리는 이미지는 수정 가능해야 했다

구조도는 D2로 잡았다. 텍스트로 박스와 화살표를 선언하고, 렌더러가 레이아웃을 계산한다. 직접 PNG 출력은 Playwright 의존이 깨져 있어서 D2 → SVG → PNG 두 단계로 고정했다. --layout elk를 붙이니 직각 라우팅이 안정돼 기술 블로그에 맞았다.

인포그래픽은 SVG를 직접 쓰는 쪽으로 갔다. 분류·비교·단계처럼 본문과 같은 텍스트가 박혀야 하는 이미지는 생성형으로 뽑을 수 없다. SVG는 <rect>와 <text>로 카드·번호·화살표를 선언하면 되고, rsvg-convert로 PNG를 만들면 한글도 깨지지 않았다.

이번 글 자체에도 그 구조를 그대로 썼다.

이 방식의 장점은 “예쁘다”보다 “다시 고칠 수 있다”에 있다.

• 소스가 남는다: 박스 하나를 바꾸려면 D2나 SVG 한 줄을 고치면 된다.
• 본문과 대조 가능하다: 이미지에만 있는 주장을 만들지 않는다.
• 배포가 단순하다: 사이트 빌드는 PNG를 정적 파일로 읽기만 한다.

기술 블로그의 이미지는 그림 파일이 아니라, 글의 일부다. 그래서 이미지도 git diff로 설명 가능해야 했다.

썸네일은 스타일 앵커로 수렴했다

정확한 정보가 없는 썸네일은 생성형이 맞았다. 다만 “멋지게 그려줘”는 스타일이 아니다. 그래서 스타일 탐색을 별도 라운드로 뺐다. 세션이 후보 프롬프트를 만들고, 이미지를 생성하고, 나는 고르기만 했다.

품평은 꽤 직선적이었다.

• R1: “다 개성 있는데 다 좀 촌스럽다”
• R3: “깔끔한데 밋밋하고 좀 무섭다”
• R4: “너무 댄디하고 군더더기 많다”

최종 좌표는 말랑한 클레이 재질 × 핵심 은유 하나 × 적당한 요소 수였다. 어두운 따뜻한 갈색 배경, 크림색 본체, 코랄 레드 포인트, 텍스트 없음. 이 프롬프트 블록을 IMAGE_STYLE.md에 박제했다.

여기서 중요한 건 완벽한 한 장을 찾은 게 아니라는 점이다. 스타일은 나중에 바꿀 수 있다. 프롬프트 블록과 규칙 문서만 바꾸면 다음 글부터 다른 방향으로 재생성된다. 되돌릴 수 있는 결정은 문서로 고정하고, 산출물은 그 문서에서 반복 생성되게 한다.

의외의 핵심은 헤르메스 설정이었다

중간에 삽질도 있었다. 나는 한 번 “코덱스 구독으로는 이미지 API가 안 된다”고 잘못 단정했다. 그런데 내가 바로 반박했다.

“코덱스 구독으로 이미지 제작되는데”

코드를 확인하니 실제로 헤르메스에는 openai-codex 이미지 플러그인이 있었다. 별도 API 키 없이 Codex 인증으로 gpt-image-2를 쓸 수 있는 경로였다. 문제는 도구가 없던 게 아니라, 도구가 있는데 베르톨트 프로필에서 쓰도록 켜지지 않은 상태였다는 점이다.

여기서 두 번째 함정이 나왔다. 본체 설정을 고쳤는데 베르톨트는 계속 FAL 기본값을 보려고 했다. 이유는 프로필 분리였다. --profile bertholdt로 뜬 에이전트는 본체 config가 아니라 프로필 config를 읽는다. 결국 베르톨트 프로필 쪽에 이미지 provider를 넣고 게이트웨이를 다시 띄운 뒤에야 성공했다.

이건 이미지 파이프라인의 곁가지 같지만, 사실 운영 교훈은 크다. 헤르메스에서 “한 직원”은 단순한 말투가 아니라 독립 프로필이다. 공유 설정인지 프로필별 설정인지는 소스로 확인해야 한다.

글쓰기 규칙으로 박제했다

마지막 단계는 기능이 아니라 규칙이었다. 도구를 한 번 써 보는 것과, 다음 글부터 베르톨트가 같은 판단을 반복하는 것은 다르다. 그래서 이미지 규격을 IMAGE_STYLE.md로 빼고, write-post 스킬에 이미지 6단계를 추가했다.

규칙은 일부러 좁게 잡았다.

• 썸네일은 필수 1장: 글의 핵심 은유를 클레이 스타일로 만든다.
• 구조도는 필요할 때만: 흐름·관계 설명에서 빠지면 잃는 게 있을 때 넣는다.
• 인포그래픽도 필요할 때만: 분류·비교·단계가 본문 이해를 실제로 줄여줄 때 넣는다.
• 은유 삽화는 예외: 장식용으로 남발하지 않는다.

남발 방지 기준도 한 문장으로 못박았다.

“이 이미지를 빼면 독자가 잃는 게 있는가.”

이 질문에 답하지 못하면 만들지 않는다. 이미지 파이프라인은 블로그를 화려하게 만들기 위한 장치가 아니라, 텍스트만으로 흐려지는 구조를 더 정확하게 보이게 하는 장치다.

이번 설계의 채점

처음 목표는 “베르톨트가 자기 글에 맞는 이미지를 스스로 만들어 넣게 하자”였다. 이번 글이 그 첫 엔드투엔드 실전이다. 기준별로 보면 10점 만점에 8점 정도다.

• 도구 라우팅: 생성형과 코드 렌더의 경계를 글 안에서 실제로 썼다. 썸네일은 생성형, 구조도와 인포그래픽은 코드로 만들었다.
• Astro 불가침: 빌드 플러그인을 건드리지 않고 정적 PNG만 추가했다.
• 스타일 재현성: 썸네일은 규칙 문서의 스타일 블록을 그대로 따랐다.
• 아쉬운 점: D2 구조도는 아직 가로로 길고 얇다. 내용이 복잡한 글에서는 레이아웃 템플릿을 더 다듬어야 한다.

즉, 이번 작업의 핵심은 “AI가 그림도 그렸다”가 아니다. 어떤 그림은 AI에게 맡기고, 어떤 그림은 절대 맡기지 않을지 분류한 것이다. 블로그 작가에게 손을 달아준다는 건 도구를 많이 쥐여 주는 일이 아니라, 손마다 맡을 일을 갈라 주는 일에 가까웠다.

이번 글이 첫 시험대다. 여기서 보이는 어색함은 다음 규칙 개정의 재료가 된다. 그래도 한 가지는 확인했다. 베르톨트는 이제 글만 쓰는 직원이 아니라, 자기 글에 필요한 이미지를 만들고 검수해서 같이 싣는 직원이 됐다.