AI가 생성한 티가 나지 않는 데이팅 사진 만들기 (모델보다 네거티브 프롬프트가 더 중요합니다)

저는 이미 실제 얼굴을 순수 확산(pure diffusion) 대신 flux-pulid로 유지하는 AI 헤드샷 도구를 구축한 이유에 대해 글을 썼습니다. fal.ai의 flux-pulid와 같은 신원 보존(identity-preservation) 모델이 얼굴 인식이 가능한지 여부를 유지하는 데 있어 LoRA 파인튜닝보다 우수하다는 점을 보여주었습니다. 동일한 모델로 AI 데이팅 사진을 만들면서, 저는 또 다른 더 어려운 문제에 직면했습니다: _피부_가 인식 가능하게 유지하는 것입니다. 신원 보존 생성은

두 단계 모두에 걸쳐 사용된 네거티브 프롬프트(negative prompt)가 'AI 느낌' 문제를 해결하는 데 가장 많은 역할을 합니다: waxy skin, plastic skin, airbrushed, over-smooth skin, poreless skin, beauty filter, oversaturated 같은 키워드가 흔히 예상되는 deformed, extra fingers, blurry와 나란히 배치되어 있습니다. 튜토리얼에서 찾을 수 있는 대부분의 네거티브 프롬프트 목록은 구조적 실패 모드(extra limbs, wrong eye count)까지만 다룹니다. 왜냐하면 이들은 명백하게 깨진 출력물이기 때문입니다. 피부 질감 관련 용어들이 존재하는 이유는 구조적으로 올바른 얼굴이 플라스틱 같은 피부를 가질 때가 포토리얼리즘 사용 사례에서 논란의 여지 없이 더 흔한 실패 모드이며, 특히 데이팅 사진 제품에서는 전환율을 실제로 떨어뜨리는 요인이기 때문입니다.

아키텍처: 호출당 하나의 스타일로 설계

이 기능을 구현하는 Cloudflare Pages Function은 모든 스타일의 전체 배치(full batch)를 한 번의 요청으로 생성하지 않습니다. 대신, 호출당 하나의 스타일만 생성하며 브라우저가 클라이언트 측에서 스타일을 반복합니다. 이것은 코드의 우연한 결과가 아니라 Cloudflare Functions의 CPU/벽 시간 제한에 따른 직접적인 결과입니다: flux-pulid 생성과 업스케일(upscale) 패스를 1.5초 간격으로 최대 60회까지 폴링할 경우, 너무 오래 실행되어 네 가지 스타일을 하나의 요청으로 묶으면 전체 배치가 타임아웃될 위험이 있고 사용자는 아무것도 받지 못하게 됩니다. 따라서 스타일별로 분리하면 느린 스타일이 실패하거나 타임아웃되더라도 나머지 세 개는 영향을 받지 않습니다.

서명된 권한(signed grant)을 이용한 결제 게이트 생성, 데이터베이스 불필요

이 플로우에는 주문 테이블(order table)이 없습니다. 결제 과정은 HMAC 서명된 권한(grant, 페이로드 + 시그니처)을 생성하며 (이는 이미 Functions 런타임에서 사용 가능한 Web Crypto crypto.subtle API로 검증됩니다), 여기에 유료 등급과 만료 타임스탬프가 포함됩니다. 생성 엔드포인트는 fal에 접근하기 전에 서명과 만료일을 확인합니다. 따라서 결제가 이루어지지 않거나, fal API 호출이 발생하지 않으므로 실패하거나 위조된 요청은 비용을 전혀 발생시키지 않습니다. 등급(Tier)은 어떤 스타일 프리셋이 잠금 해제되는지와 각 스타일별로 몇 장의 이미지가 생성될 수 있는지(tier.count / tier.styles.length, 등급에 관계없이 스타일당 최대 12장으로 제한)를 모두 결정합니다.

포토리얼(스타일화되지 않은) 생성 제품을 구축하는 사람에게 해주고 싶은 조언

• 모델의 기본 실패 모드를 '눈에 띄게 망가진' 것이 아니라, '기술적으로는 정확하지만 명백히 합성된' 것으로 가정하여 네거티브 프롬프트를 작성하세요. 데이팅/헤드샷/인물 사진 사용 사례에서 결정적인 부분은 해부학적 구조가 아니라 피부 질감입니다.
• 마무리(finishing)/업스케일 단계가 텍스처 문제를 수정하기 위한 것이라면, creativity는 낮게, resemblance는 높게 조정하세요. 이미지를 재해석하는 것이 아니라 텍스처를 수정하도록 해야 합니다.
• 하드한 함수 시간 제한이 있는 플랫폼에서 장시간 실행되는 생성 작업을 가장 작은 합리적인 단위(여기서는: 하나의 스타일)로 분할하세요. 이는 단순히 사용자 경험(UX)의 문제가 아니라 복원력 경계(resilience boundary)입니다.

실습 도구: https://dating-photos.pages.dev/

만약 유용하다면 네거티브 프롬프트 목록이나 CF Functions 시간 제한 우회 방법에 대해 더 깊이 논의할 준비가 되어 있습니다. 댓글을 남겨주세요.