이 local-blog 프로젝트의 작업 창구는 Web ChatGPT의 Chat 모드다. 내가 글의 주제를 정해 요청하면 ChatGPT가 로컬 프로젝트의 파일을 수정하고, 테스트와 빌드를 거쳐 실제 사이트에 게시하는 흐름을 목표로 하고 있다.
여기에 한 가지 바람이 더 있었다. 글에 이미지가 필요하다면 ChatGPT가 스스로 이미지를 만들고, 그 이미지를 본문에 첨부한 뒤 게시까지 끝내는 것이다.
ChatGPT는 이미지 자체를 만들 수 있다. 문제는 이미지 생성 능력이 아니라, 현재 이 작업 환경에서 이미지를 만든 직후 같은 응답으로 로컬 작업을 계속 이어갈 수 없다는 점이었다.
기대했던 흐름
처음 생각했던 자동화는 단순했다.
- 글을 작성한다.
- 본문에 이미지가 필요한 위치를 판단한다.
- ChatGPT의 이미지 생성 기능으로 그림을 만든다.
- 생성된 파일을
local-blog의 미디어 저장소에 넣는다. - 본문에 이미지를 첨부한다.
- 빌드하고 실제 사이트에 배포한다.
사람이 중간에 파일을 내려받아 옮기거나 다시 명령할 필요 없이, 한 번의 요청으로 끝나는 흐름이다.
하지만 실제로 테스트해 보니 3번과 4번 사이에 경계가 있었다.
막히는 지점은 이미지 파일이 아니라 응답의 경계다
현재 이 프로젝트에서 ChatGPT가 이미지 생성 도구를 호출하면 이미지는 정상적으로 만들어진다. 여러 이미지가 필요한 요청이라면 이미지 생성 자체를 한 번의 요청으로 묶는 것도 가능하다.
문제는 이미지 생성이 끝난 그 응답에서 후속 로컬 도구 작업을 다시 이어갈 수 없다는 것이다.
local-blog에서 실제 게시물이 되려면 생성된 그림 뒤에 해야 할 일이 꽤 많다. 파일을 로컬 작업공간으로 가져오고, 미디어 파이프라인에 등록하고, WebP와 AVIF 같은 최적화 자산을 만들고, CDN에 배포하고, 본문의 Markdown에 URL을 넣고, 사이트를 빌드한 뒤 다시 배포해야 한다.
즉 원하는 흐름은 다음과 같다.
이미지 생성 → 파일 확보 → media:add → CDN 배포 → 본문 첨부 → 사이트 빌드 → 게시
하지만 현재 Web ChatGPT Chat 모드에서는 이미지 생성 응답이 끝나는 지점에서 이 연속 실행이 끊긴다. 다음 사용자 메시지에서 “계속 진행해 줘”라고 하면 후속 작업을 할 수 있지만, 그러면 이미 한 번의 요청으로 자동 게시한다는 목표에서는 벗어난다.
따라서 “ChatGPT가 이미지를 만들 수 없어서” 이 기능을 쓰지 못하는 것이 아니다. 이미지를 만든 뒤 같은 실행 흐름으로 돌아오는 연결 고리가 없기 때문이다.
별도의 GPT를 이미지 담당으로 두면 해결될까
이미지 생성 전담 Custom GPT나 별도의 에이전트를 두고, 글을 쓰는 도중 필요할 때 호출한 뒤 결과 이미지만 돌려받는 구조도 생각해 볼 수 있다.
그 구조가 가능하려면 현재 작업 중인 ChatGPT가 다른 GPT를 내부의 하위 작업자처럼 호출하고, 생성 결과 파일을 받아온 뒤 원래 작업을 계속 실행할 수 있어야 한다. 하지만 지금 이 프로젝트가 사용하는 Chat 흐름은 그런 식의 내부 하위 작업 호출 구조가 아니다.
결국 역할을 분리하는 것만으로는 해결되지 않는다. 핵심은 여전히 생성된 이미지 결과를 현재 게시 작업의 다음 단계로 자동 전달할 수 있느냐다.
코드로 만드는 이미지는 왜 가능한가
반면 SVG 같은 이미지를 코드로 직접 만드는 방식은 성격이 다르다.
ChatGPT가 SVG 코드를 작성하는 것은 일반적인 파일 수정 작업이다. 그 SVG를 로컬에서 PNG로 렌더링하는 것도 같은 로컬 도구 체인에서 실행할 수 있다. 따라서 이미지가 만들어진 뒤 응답이 강제로 끝나지 않고, 곧바로 기존 미디어 파이프라인으로 넘길 수 있다.
실제로 이 글에 들어간 두 장의 그림도 그렇게 만들었다.
SVG 코드 작성 → PNG 렌더링 → media:add → WebP/AVIF 생성 → CDN 배포 → Markdown 삽입
이 과정은 ChatGPT 이미지 생성 기능을 한 번도 호출하지 않았다. 별도의 유료 이미지 API도 사용하지 않았다. 그래서 이미지 두 장을 만든 뒤에도 작업이 끊기지 않았고, 그대로 이 글의 작성과 게시 단계까지 이어갈 수 있었다.
물론 코드 이미지에는 한계가 있다
코드로 만든 이미지가 생성형 이미지 모델을 완전히 대체할 수 있는 것은 아니다.
실제 사진처럼 자연스러운 서울 골목, 음식 사진, 사람의 표정, 복잡한 풍경이나 감성적인 일러스트는 생성형 이미지 모델이 훨씬 잘한다. SVG 코드 방식은 그런 장면에서 표현력의 한계가 분명하다.
대신 구조도, 흐름도, 비교도, 타임라인, 체크리스트, 통계 그래픽, 설명용 인포그래픽처럼 정보를 정확하게 전달하는 그림에는 꽤 잘 맞는다. 색상과 여백, 글꼴, 카드 모양 같은 규칙을 정해 두면 블로그 전체에서 일관된 시각 스타일을 유지하는 것도 가능하다.
무엇보다 이 프로젝트에는 중요한 조건이 있다. 운영 비용이 없어야 한다. 코드로 만드는 이미지는 별도의 유료 API 호출이 필요하지 않으므로 이 조건에도 맞는다.
현재 local-blog의 현실적인 선택
그래서 지금은 이미지의 성격에 따라 접근을 나누는 것이 가장 현실적이라고 생각한다.
사진이나 정교한 생성형 일러스트가 꼭 필요한 글이라면 ChatGPT의 이미지 생성 기능을 사용할 수는 있지만, 생성 뒤 한 번 더 대화를 이어서 파일 등록과 게시를 진행해야 한다. 반대로 설명용 그림이나 인포그래픽이라면 코드로 직접 만들어 이미지 생성부터 첨부와 배포까지 한 번의 작업 흐름으로 끝낼 수 있다.
이번 글은 그 두 번째 방식이 실제로 작동하는지 확인하는 테스트이기도 하다. 위의 두 이미지는 코드로 만들어졌고, local-blog의 기존 미디어 최적화와 CDN 배포 과정을 거쳐 본문에 들어왔다.
결론은 단순하다. 현재의 문제는 이미지 생성 능력이 아니라 워크플로의 연속성이다. 그 경계가 사라지는 날에는 생성형 이미지도 자연스럽게 자동 게시 흐름에 넣을 수 있을 것이다. 그전까지는 코드 생성 이미지가 무료이면서도 끊기지 않는 꽤 유용한 보조 수단이 될 수 있다.