사진을 프롬프트가 아니라 생성 메타데이터로 쓰기

Place2Page의 랜딩페이지는 사진을 많이 넣는다고 바로 좋아지지 않았다. 처음에는 프롬프트에 "사진을 잘 활용하라"는 규칙을 더 넣으려 했지만, 실제 결과를 보니 문제는 문구가 아니라 데이터 경로였다. 사진을 먼저 분석해 photo_intelligence라는 구조화된 metadata로 넘기자 최종 HTML 모델은 사진을 asset 목록이 아니라 hero 후보, gallery evidence, brand color, alt text의 근거로 쓸 수 있었다.

요약

• 문제: Hallmark combined prompt 이후에도 최종 HTML 모델은 사진의 역할, 색감, alt text를 내부 추론에 의존했다.
• 판단: 프롬프트를 더 길게 쓰는 대신, 사진을 먼저 분석해 generation payload에 명시적인 visual metadata로 넣었다.
• 결과: 자동 점수는 기존 variant와 같았지만, 사람 눈으로는 사진 배치와 색감 사용이 더 의도적으로 보였고 debug 화면에서도 원인을 추적할 수 있었다.
• 배운 점: 멀티모달 기능은 "이미지를 같이 넣기"가 아니라 "이미지 이해 결과를 제품 파이프라인의 안정적인 입력으로 만드는 일"에 가깝다.

이전 단계의 한계

앞선 Hallmark combined 실험은 효과가 있었다. structure, anti-slop copy, responsive hardening을 합치니 baseline보다 정보 흐름과 visual rhythm이 좋아졌다. 그래도 사진은 여전히 text prompt 바깥에 있었다.

예를 들어 음식점 사진 세트가 있을 때 모델은 이런 판단을 해야 한다.

• 어떤 사진이 hero에 적합한가
• 어떤 사진이 menu/detail evidence인가
• 어떤 사진은 text overlay 배경으로 쓰면 가독성이 깨지는가
• 어떤 색을 brand accent로 써도 자연스러운가
• alt text를 어떻게 사실적으로 써야 하는가

이 판단을 최종 HTML 모델에게 한 번에 맡기면 결과는 자주 애매해졌다. 사진은 들어갔지만, 사진을 이해해서 쓴 것 같지는 않은 상태였다.

이 결과도 publish는 가능했다. 하지만 중요한 결정이 모델 내부 추론에 숨어 있었다. 내가 바꿔야 한다고 본 지점은 prompt wording이 아니라 data path였다.

질문을 바꿨다

처음 질문은 "사진을 더 잘 쓰라고 prompt를 고칠까?"였다. 중간에 질문을 바꿨다.

사진을 먼저 분석해서 최종 HTML 모델이 쓸 수 있는 구조화된 visual metadata로 넘기면 어떨까?

새 payload의 핵심은 photo_intelligence였다. 실제 payload는 더 길지만, 모델에게 넘긴 판단 단위는 대략 이런 모양이다.

{
  "analysis_status": "complete",
  "analyzed_photo_count": 8,
  "brand_key_color": {
    "hex": "#FF4500",
    "source": "photo_analysis"
  },
  "photos": [
    {
      "alt_text": "Interior of the restaurant with blue chairs...",
      "visible_subjects": ["restaurant bar", "dining table", "pendant lights"],
      "dominant_colors": [
        { "hex": "#005680", "role": "accent" },
        { "hex": "#B5845E", "role": "surface" }
      ],
      "suggested_roles": ["hero", "gallery"],
      "placement_hint": "Use as the opening atmosphere image."
    }
  ]
}

이 metadata는 모델에게 세 가지를 알려준다. 무엇이 보이는지, 어디에 쓰면 좋은지, 어떤 색과 분위기를 style에 반영할 수 있는지다. 멀티모달 입력을 제품 기능으로 만들려면 이 중간층이 필요했다.

결과에서 본 차이

음식점 결과에서는 interior photo가 hero와 atmosphere의 중심이 됐고, 음식 사진은 menu/detail 영역으로 내려갔다. orange accent도 무작위 장식이 아니라 open-fire cooking과 음식 사진에서 나온 visual cue로 쓸 수 있었다.

fitness studio에서는 다른 신호가 필요했다. 음식점처럼 warm/orange cue를 밀어붙이면 이상하다. 이 케이스에서는 움직임, 수업, 밝은 공간감이 더 중요했고, 결과도 흰색, 검정, 파란색 accent 쪽으로 유도됐다.

workshop 케이스에서는 craft detail 사진이 gallery/proof/detail 역할을 했다. 한 장의 사진 분석 실패는 partial로 기록했지만 generation은 계속 진행했다.

이 실패 허용 정책도 중요했다. Photo intelligence는 품질을 올리는 입력이지, 랜딩페이지 생성을 막는 hard dependency가 아니다.

Debug payload와 generation payload를 나눴다

구현에서 가장 조심한 부분은 운영자가 보는 payload와 모델에게 주는 payload를 분리하는 일이었다.

Debug payload에는 실패까지 넓게 남겼다. enabled/disabled/skipped/failed/partial/complete 상태, model, photo count, failed count, per-photo error, raw-ish summary, brand color rationale이 필요했다. 운영자는 나중에 "왜 이 사진이 hero가 됐지?", "왜 이 색을 썼지?", "왜 사진 분석이 빠졌지?"를 봐야 한다.

Generation payload는 더 작게 만들었다. 최종 모델에게는 alt text, visible subjects, dominant colors, suggested roles, placement hint, brand key color처럼 생성에 직접 필요한 값만 넘겼다. 실패 noise나 내부 상태를 많이 넘기면 HTML 생성 품질이 오히려 흔들릴 수 있기 때문이다.

이 구분이 없으면 AI 기능은 금방 블랙박스가 된다. 결과가 좋아 보여도 왜 좋아졌는지 모르고, 실패해도 어디서 실패했는지 모른다.

승격 기준

실험 결과는 자동 점수만 보면 애매했다.

여기서 "photo-intelligence가 자동 평가에서 이겼다"고 말하지 않았다. 숫자는 동률이었다.

대신 승격 기준을 다르게 봤다.

• 기존 quality guardrail을 깨지 않았다.
• 사람 눈으로 볼 때 사진과 색감 사용이 더 의도적으로 보였다.
• prompt 문구 추가보다 runtime data path 개선이 더 지속 가능했다.
• debug log와 운영 화면에서 분석 결과를 확인할 수 있었다.
• 실패해도 generation이 계속되는 fallback boundary가 있었다.

그래서 code deploy와 smoke test 후 production runtime default로 승격했고 이전 combined profile은 rollback target으로 남겼다.

검증

이 작업에서 검증한 것은 "사진을 쓰니 무조건 예쁘다"가 아니었다. 더 좁게 봤다.

• 사진 분석이 성공/partial/failed 상태로 남는가
• generation payload가 내부 debug noise 없이 필요한 metadata만 받는가
• 사진 분석 실패가 generation 전체 실패로 번지지 않는가
• 자동 quality guardrail을 깨지 않는가
• 사람 눈으로 봤을 때 사진 역할과 색감 사용이 더 설명 가능한가

좋은 AI 결과물은 한 번의 model call에서 나오지 않는다. 입력을 분석하고, 구조화하고, 필터링하고, 기록하고, 운영 화면에 보여주고, 승격 기준까지 정하는 전체 pipeline에서 나온다.

다음에는 이렇게 판단한다

• 멀티모달 품질 문제가 보이면 먼저 "이미지를 넣었는가"보다 "이미지 이해 결과가 어떤 구조로 전달되는가"를 본다.
• 자동 점수가 동률이면 사람 눈으로 보이는 의도성, debug 가능성, fallback boundary를 같이 본다.
• 모델에게 모든 사진 판단을 맡기지 않는다. hero 후보, detail evidence, alt text, dominant color처럼 제품이 원하는 판단 단위를 먼저 정의한다.
• 실패할 수 있는 AI 보조 기능은 hard dependency로 두지 않는다. 실패 상태는 기록하되, core generation은 가능한 한 계속 진행시킨다.
• 공개 글로 남길 때는 실제 장소명, 내부 profile/run id, 운영 URL을 그대로 노출하지 않는다.