디자이너가 아닌 내가 AI로 쇼핑몰 템플릿을 만든 방법 (1)
AI 로 쇼핑몰 템플릿을 만들 때 가장 먼저 한 일은 규격 고정이었다. 왜 그것이 통했는지 — 오차가 쌓이지 않기 때문이다.
이 글은 무엇인가
나는 디자이너가 아니다. 그런데 AI로 쇼핑몰 템플릿을 뽑아냈고, 생각보다 결과가 좋았다. 잘 나온 이유는 내 감각이 좋아서가 아니라, 순서를 지켰기 때문이다. 이 글은 그 순서에 대한 기록이다. 따라 하는 매뉴얼이 아니라, "이렇게 생각하면 된다"는 사고법에 가깝다.
시작은 실망에서였다
AI한테 "쇼핑몰 상세페이지 템플릿 만들어줘"라고 던지면 어떻게 될까. 매번 다른 게 나온다. 색도 다르고, 구성도 다르고, 어제 좋았던 톤이 오늘은 안 나온다. 결과물을 붙여 쓸 수가 없다. 예쁜 그림 한 장은 나오는데, 일관된 시스템은 안 나온다.
문제는 AI가 아니었다. 내가 아무 제약 없이 던진 게 문제였다. 빈 종이에 "알아서 잘 그려줘"라고 하면, 사람이라도 매번 다르게 그린다. AI는 더 그렇다.
핵심은 하나였다 — 규격을 먼저 고정한다
방향을 바꿨다. 만들라고 하기 전에, 뭘 지켜야 하는지부터 정해서 보여줬다. 이걸 나는 "규격을 고정한다"고 부른다.
순서로 옮기면 이렇다.
1. 규격을 먼저 설명하고, 화면을 캡처해서 보여준다
말로만 설명하지 않았다. 실제 관리자 화면을 캡처해서 "이 틀 안에서 놀아야 한다"를 시각적으로 못 박았다.
왜 이 순서인가. 규격 없이 만들게 하면 AI가 매번 다른 기준으로 만든다. 기준을 눈으로 보여주면, 생성할 수 있는 범위가 좁아진다. 좁아진다는 건 나쁜 게 아니다. 일관성은 자유를 줄일 때 생긴다.
2. 프롬프트를 내가 쓰지 않고, AI에게 쓰게 한다
여기가 반전이었다. 나는 이미지 생성 프롬프트를 직접 쓰지 않았다. 규격을 이해한 AI에게 "이 규격에 맞는 이미지를 생성할 프롬프트를 네가 써라"고 시켰다.
왜 이 순서인가. 규격을 이해한 상태에서 프롬프트를 쓰면, 내가 놓친 디테일까지 반영된다. 내가 프롬프트를 쓰면 내 지식이 상한선이 되지만, 규격을 문 AI가 쓰면 그 이상이 나온다. 나는 프롬프트를 쓰는 사람이 아니라, 프롬프트를 쓸 조건을 만드는 사람이 됐다.
3. 생성은 다른 도구에 맡긴다
그렇게 나온 프롬프트를 이미지 생성 도구로 넘겨 실제 이미지를 만들었다. 프롬프트를 만드는 일과 이미지를 만드는 일을 다른 도구로 분리했다.
왜 이 순서인가. 한 도구에 다 시키면 어디서 틀어졌는지 모른다. 단계를 나누면 문제가 생겼을 때 어느 칸에서 틀어졌는지 보인다. 그리고 각 도구가 제일 잘하는 일만 하게 된다.
4. 다시 가져와 실제 템플릿으로 구현한다
생성된 결과물을 다시 가져와 실제 쓸 수 있는 템플릿으로 마감했다. 여기서 규격이 한 번 더 일한다. 앞에서 고정한 틀이 있으니, 구현 단계에서도 어긋나지 않는다.
왜 이게 잘 됐나 — 오차가 쌓이지 않아서다
돌아보면 잘 된 이유는 단순하다. 각 단계가 앞 단계의 제약을 물려받았다.
규격이 프롬프트를 제약하고, 프롬프트가 이미지를 제약하고, 이미지가 구현을 제약한다. 앞에서 틀을 조여놨으니 뒤로 갈수록 벗어날 여지가 줄어든다. 보통은 "한 번에 잘 만들어줘"라고 던져서 실패하는데, 나는 제약을 단계별로 전달하는 체인을 만든 셈이다.
한 문장으로 줄이면 이렇다.
AI에게 자유를 주면 매번 다른 게 나오고, 제약을 주면 같은 게 나온다. 좋은 결과물은 좋은 프롬프트가 아니라 좋은 제약에서 나온다.
정리
- AI에게 아무 제약 없이 던지면 일관성이 안 나온다
- 만들라고 하기 전에 규격을 먼저 고정하고, 화면으로 보여준다
- 프롬프트는 내가 쓰는 게 아니라, 규격을 이해한 AI에게 쓰게 한다
- 단계를 나누면 오차가 쌓이지 않고, 어디서 틀어졌는지 보인다
- 결국 핵심은 제약 설계다
다음 글에서는, 이 파이프라인 하나를 어떻게 여러 개로 동시에 돌려 하룻밤에 여러 템플릿을 뽑아냈는지를 다룬다.