Seedance 2.0 fast가 실존 인물 사진을 거절했다 — 우회 말고 Real Human Asset 등록이 정도

📡 이 글은 BytePlus Seedance 2.0 fast 모델을 API로 직접 호출해서 영상을 만드는 사용자를 위한 글입니다. base64 이미지를 보내고 거절을 받는 시나리오는 API 통합에서 발생합니다. ModelArk 콘솔은 인물 사진 업로드 시 자체 UI가 face asset 등록을 안내하므로 본문 시나리오를 만날 일이 없습니다.

인물 사진을 넣었더니 API가 거절한다

우리 아이를 주인공으로 한 가족 영상에 아이 사진을 reference image로 넣으려고 base64 인코딩해서 BytePlus Seedance API에 보냈더니, 첫 호출부터 단호하게 거절됩니다.

InputImageSensitiveContentDetected.PrivacyInformation:
input image may contain real person

처음엔 이상했습니다. "내가 직접 찍은 우리 아이 사진이고, 본인과 가족 동의도 다 받은 건데 왜 거절?" 한국에서 가족 영상 만든다는 입장에서 보면 과하게 보수적으로 느껴지죠. 더 이상한 건 같은 아이의 다른 사진은 통과한다는 사실이었습니다. 어떤 사진은 통과, 어떤 사진은 거절 — 일관되지 않습니다.

이 동작은 우연이 아니라 BytePlus의 의도된 글로벌 안전장치였습니다. base64로 들어온 임의의 이미지에서 얼굴이 일정 prominence 이상으로 인식되면 자동 거절하는 정책이고, 미성년자 한정도 아닌 모든 인물에 적용되는 정책입니다. BytePlus 입장에선 무단 합성·딥페이크·초상권 분쟁을 한 번에 방어해야 하니 그렇게 짤 만한 일이긴 합니다.

우회는 도박이다

가장 먼저 떠오르는 건 우회입니다. 얼굴을 blur, gaussian noise를 살짝, 컬러를 약간 시프트, EXIF 메타데이터 제거 — 이 모든 트릭이 인터넷에 흩어져 있습니다. 실제로 해 보면 어떤 사진은 통과하고 어떤 사진은 거절합니다. 같은 보정을 두 사진에 똑같이 적용해도 결과가 다릅니다. 모델이 단순한 얼굴 detection 점수만 보는 게 아니라 prominence, 각도, lighting, 표정 등의 종합 score로 판단하기 때문이죠.

우회의 진짜 문제는 이겁니다.

• 50/50 도박이라 production cycle에 들어갈 수가 없습니다. 영상 한 편이 30개 클립인데 그 중 절반이 무작위로 거절된다면 일정 자체가 안 됩니다.
• 우회에 성공해도 Seedance 입장에선 "이상한 합성" 이미지를 받는 거라, 얼굴 인식 일관성이 떨어집니다. 두 클립에서 같은 인물이 다른 사람처럼 보일 수 있죠.
• 정책적으로도 우회하는 행동은 결국 그 안전장치에 반하는 행동입니다. 본인 동의를 받은 합법적 사용자가 우회할 필요는 없습니다.

정도(正道) — Real Human Asset 등록

다행히 BytePlus가 이 시나리오를 위해 공식 우회로를 만들어 뒀습니다. Real Human Asset Library 라는 이름의 인물 자산 등록 시스템입니다. 본인(또는 보호자)이 동의 + face liveness check를 거쳐 자산 그룹을 만들면 그 인물 전용 URI가 발급되고, 그 URI를 base64 대신 reference로 전달하면 됩니다.

data:image/jpeg;base64,/9j/4AAQSkZJRgABAQ...    ← 거절될 수 있음
asset://asset-<account>-<group-id>-<asset-id>    ← 통과

이 URI를 한 번 받고 나면, 처음에 base64로 거절됐던 사진까지도 이 URI로 등록해 두면 그대로 reference로 쓸 수 있습니다. 즉 "어떤 사진은 통과/어떤 건 거절"이라는 비결정성이 사라집니다. 본인 verify + 법적 동의 + face matcher consistency가 우회 트릭을 대체합니다.

face asset과 환경 base64를 한 호출에서 mix

여기서 더 흥미로운 부분이 있습니다. face asset URI와 일반 base64 이미지를 같은 content array 안에 섞어서 보낼 수 있다는 점입니다.

다이어그램은 두 형식이 같은 호출 안에서 어떻게 공존하는지를 보여줍니다. 인물 정체성은 한 번 등록해 두고 영상 전반에 걸쳐 재사용하는 persistent 자산이고, 배경·소품은 클립마다 다르게 들어가는 ephemeral 자산입니다. 두 layer를 한 layer로 뭉뚱그리지 않고 분리해서 다루는 게 production-grade 패턴입니다.

코드로 보면 — 같은 인터페이스로 두 형식 다루기

이 분리를 코드에 자연스럽게 녹이려면, 클립 입력을 다음처럼 받는 게 좋습니다.

# 사용자가 클립별로 reference를 지정할 때
clip.image_paths = (
    Path("references/son_room_bg.jpg"),             # 환경 — base64로 자동 인코딩
    "asset://asset-account-k26nj-...-son-face",     # 인물 — URI 그대로 전달
)

def to_content_items(image_paths: tuple[Path | str, ...]) -> list[dict]:
    """Path는 base64 인코딩, str(asset://)은 그대로."""
    items = []
    for p in image_paths:
        if isinstance(p, Path):
            with p.open("rb") as fh:
                b64 = base64.b64encode(fh.read()).decode("ascii")
            url = f"data:image/jpeg;base64,{b64}"
        else:  # 이미 asset://... 형태
            url = p
        items.append({
            "type": "image_url",
            "image_url": {"url": url},
            "role": "reference_image",
        })
    return items

핵심은 image_paths: tuple[Path | str, ...] 타입입니다. Path는 즉석 base64로 인코딩하고, 이미 asset:// 형태로 들어온 문자열은 그대로 전달합니다. 사용자(또는 클립 정의 yaml) 입장에선 "인물이면 URI, 환경이면 파일 경로"라고 직관적으로 적기만 하면 되고, API에 보내는 변환은 함수 하나가 알아서 처리해 줍니다. 미래에 또 다른 형식(예: 영상 reference URL)이 추가돼도 분기 한 줄 추가로 끝납니다.

결과 — 정도가 시스템을 깔끔하게 만든다

face asset 등록을 production cycle에 포함한 뒤 일어난 변화는 단순합니다.

• 거절 사이클이 거의 사라졌습니다. 등록된 인물 사진은 face matcher 일관성 검증만 통과하면 그 다음 호출부터는 더 이상 contents filter에 걸리지 않습니다.
• 두 클립 사이 얼굴 일관성이 올라갔습니다. 매 호출 다른 base64 사진을 reference로 쓰던 시절에 비해, 같은 자산 그룹의 사진들을 쓰는 지금이 인물의 동일성이 훨씬 잘 유지됩니다.
• 법적 책임선이 명확해졌습니다. 본인·보호자 동의가 BytePlus 측 시스템에 기록돼 있으니 우회로 만든 영상과는 권한 출처가 다릅니다.

새 AI 영상 시스템을 설계할 때 처음에 던질 질문 하나가 있다면 이겁니다 — "이 시스템이 실존 인물을 다루는가?" 다룬다면, 우회로 시간을 쓰지 말고 첫 주에 인물 자산 등록 워크플로우부터 만드는 게 가장 짧은 길입니다. 가족 영상이든, 추억 기록 영상이든, 미래의 어떤 인물 콘텐츠든 동일하게 적용되는 원칙입니다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.