제미나이 옴니 1.1 플래시, 앞 10초를 보고 잇는다

effidev·2026년 8월 28일

AI로 만든 영상을 이어 붙이면 인물의 얼굴이 슬쩍 바뀌거나 배경이 딴 곳이 되는 일이 잦았습니다. 이유가 오늘 공개됐습니다. 모델이 앞 영상의 마지막 1초만 보고 다음 장면을 그렸기 때문입니다.

현지 시각 8월 27일, 구글이 제미나이 옴니 1.1 플래시(Gemini Omni 1.1 Flash)를 공개했습니다. 구글 딥마인드의 제품 매니저 두 사람(Anish Nangia, Alisa Fortin)이 쓴 공식 발표문의 표현을 그대로 옮기면, 이번 모델은 앞선 문맥을 최대 10초까지 분석합니다. 발표문은 이것을 “마지막 1초만 참고하던 이전 모델에서의 도약(a leap from previous models that only referenced the final second)“이라고 적었습니다.

이 글은 이런 분을 위해 썼습니다.

AI로 영상을 만들어 보고 싶은데 몇 초짜리 짧은 클립만 나와서 쓸 데가 없다고 느낀 분. 그리고 몇 번 돌려 보다가 “이거 한 번 뽑을 때마다 얼마씩 나가는 거지?” 하고 멈칫한 분입니다.

결론부터 말하면 이번 업데이트의 핵심은 화질이 아니라 작업 순서입니다. 비싼 결과물을 여러 번 뽑아 보고 고르던 방식에서, 싼 초안을 여러 개 뽑아 고른 다음 마지막 하나만 크게 올리는 방식으로 바뀝니다. 아래에서 구글 공식 발표문과 제미나이 API 요금 문서에 실제로 적힌 수치만으로 그 이유를 따라가겠습니다. 구글이 밝히지 않은 값은 추정하지 않고 비워 두겠습니다.

왜 이어 붙인 영상은 딴 사람이 됐나

먼저 용어 하나만 풀고 가겠습니다. 장면 이어 붙이기(scene extension) 는 이미 만들어 둔 영상의 끝에서부터 다음 장면을 계속 만들어 내는 기능입니다. 8초짜리 클립 하나로 이야기를 못 하니까, 그 뒤를 이어서 더 만드는 것이죠.

문제는 “무엇을 보고 이어 붙이느냐”였습니다.

이전 모델들은 앞 영상의 마지막 1초만 참고했습니다. 1초라는 건 사실상 마지막 장면 한 컷입니다. 인물이 어떤 옷을 입고 있었는지, 카메라가 어느 방향으로 움직이던 중이었는지, 조명이 어디서 들어오고 있었는지 같은 정보가 그 한 컷에 다 담기지는 않습니다.

그래서 이어 붙인 뒷부분이 앞부분과 미묘하게 다른 영상이 됐습니다. 사람 눈에는 “얼굴이 좀 바뀌었네”, “아까 그 방이 아닌데” 정도로 보이는 그 어긋남입니다.

이번 제미나이 옴니 1.1 플래시는 앞의 10초를 봅니다. 1초에서 10초면 열 배입니다. 발표문은 그 결과를 “시각적 일관성과 서사 준수(visual consistency and narrative adherence)의 개선”이라고 적었습니다.

여기서 중요한 건 숫자 자체가 아니라 그 숫자가 무엇을 가능하게 하느냐입니다. 카메라가 천천히 뒤로 빠지는 중이었다면, 1초짜리 컷만 봐서는 “빠지는 중”이라는 사실 자체를 알 수 없습니다. 움직임은 시간이 있어야 보이니까요.

오늘 바뀐 것 다섯 가지

발표문이 새로 소개한 항목은 다섯 개입니다. 먼저 표로 줄을 세워 두겠습니다.

표에서 “발표문에 이전 사양 언급 없음”이라고 적은 칸이 셋입니다. 구글은 이 세 가지에 대해 “이전에는 어땠다”를 쓰지 않았습니다. 그래서 이 글에서도 추정하지 않겠습니다.

10초 단위로, 40초까지라는 뜻

이어 붙이기에는 두 개의 숫자가 붙습니다. 10초 단위로 늘리고, 누적 총 길이 40초까지입니다.

읽는 방식은 이렇습니다. 한 번 이어 붙일 때마다 10초가 붙고, 그렇게 네 번까지 하면 40초에서 멈춥니다.

40초가 짧다고 느끼실 수도 있습니다. 그런데 세로형 짧은 영상 한 편이 보통 15초에서 60초 사이입니다. 40초면 한 편을 통으로 채울 수 있는 길이입니다. 8초짜리 클립을 다섯 개 만들어 편집기에서 붙이던 것과, 모델이 앞 10초를 보면서 이어 그린 40초는 결과물이 다릅니다. 앞엣것은 이어 붙인 티가 나고, 뒤엣것은 한 번에 찍은 것처럼 이어지는 걸 노립니다.

발표문에 실린 실제 프롬프트 예시를 보면 무엇을 노리는지가 더 분명합니다. 한 예시는 이렇게 이어집니다.

Prompt 1: 카메라가 살짝 패닝하면 그가 곱슬머리 남자와 이야기하고 있었다는 게 드러난다, 남자의 등이 보이고, 그가 “나도 보여”라고 말한다, 극적인 음악

Prompt 2: 카메라가 천천히 빠지고, 잊힌 먼지투성이 지하 묘지

Prompt 3: 카메라가 천천히 빠지고, 책장과 책들이 먼지 낀 허공에 무중력으로 떠 있는 거대한 도서관

세 문장이 각각 별개의 영상이 아니라 한 장면의 연속이라는 게 핵심입니다. 카메라가 계속 뒤로 빠지면서 공간이 바뀝니다. 앞의 10초를 보지 않으면 “빠지는 중”이라는 상태를 이어받을 수 없습니다.

이어 붙이기 프롬프트는 이렇게 쓰더라

발표문에 실린 예시들을 모아 놓고 보면 문장을 쓰는 방식에 일정한 버릇이 있습니다. 이건 사양이 아니라 구글이 시연에 쓴 실제 프롬프트라, 따라 써 보기에 좋은 본보기입니다.

첫 번째 버릇은 “Continue the video(영상을 이어서)“로 문장을 연다는 것입니다. 다음 예시가 그렇습니다.

영상을 이어서. 영화적인 광학 돌리 줌 촬영을 실행한다. 카메라는 앞으로 나아가면서 동시에 줌 아웃해, 인물의 얼어붙은 놀란 표정이 정확히 같은 크기로 유지되게 한다. 배경의 긴 석주 회랑이 강한 원근 왜곡과 함께 극적으로 늘어나고 깊어진다. 깔끔한 구조, 끊김 없는 연속 촬영.

두 번째 버릇은 카메라 움직임을 동작 이름으로 부른다는 것입니다. 돌리 줌, 스냅 줌, 360도 궤도 회전 같은 촬영 용어가 그대로 프롬프트에 들어갑니다. “멋있게 찍어 줘”가 아니라 “카메라가 인물의 크게 뜬 눈으로 빠르게 기계적인 스냅 줌을 한다”처럼 씁니다.

세 번째 버릇은 끊김 없음을 매번 명시한다는 것입니다. “one continuous shot, no jump cuts(연속 촬영, 컷 전환 없음)”, “flawless continuity(완벽한 연속성)”, “seamless video(매끄러운 영상)” 같은 구절이 예시마다 붙어 있습니다. 이어 붙이기 기능을 쓰면서도 연속성을 말로 한 번 더 못 박는 셈입니다.

네 번째 버릇은 대사를 따옴표로 직접 준다는 것입니다.

파란 스웨터를 입은 남자가 답한다: “당신 아버지도 배를 타셨나요?”

카메라가 한 번의 연속 동작으로 뒤로 빠지고 그가 이야기를 이어 간다: “그분은 이 항구에 영혼이 있다고 하셨죠. 그리고 배들은 우리의 일부라고.” 음악이 고조된다.

대사를 요약해서 넘기는 게 아니라 말할 문장을 그대로 적습니다. 음악의 흐름(“음악이 고조된다”)도 문장으로 지시합니다.

정리하면 이어 붙이기 프롬프트는 “이어서” + 카메라 동작 이름 + 끊김 없음 명시 + 실제 대사의 조합입니다. 장면을 새로 설명하려 들지 말고, 앞 장면에서 무엇이 계속되어야 하는지를 쓰는 게 요령입니다.

첫 프레임과 마지막 프레임을 못 박는다

두 번째 기능은 시작 프레임과 끝 프레임을 지정하는 것입니다. 이미지 두 장을 주면 모델이 그 사이를 영상으로 채웁니다.

이게 왜 쓸모 있는지는 실무를 생각하면 바로 나옵니다. AI 영상의 가장 큰 불편은 “결과가 어디로 튈지 모른다”는 것입니다. 프롬프트를 아무리 자세히 써도 마지막에 카메라가 어디에 가 있을지는 뽑아 봐야 압니다.

시작과 끝을 못 박으면 그 불확실성이 사라집니다. 발표문은 이 기능이 “복잡한 카메라 궤도 이동, 줌 전환, 매끄럽게 반복되는 클립”에 알맞다고 적었습니다. 끝 프레임을 시작 프레임과 같게 주면 무한 반복되는 영상이 되는 셈입니다.

360p 초안이라는 새 습관

세 번째가 이번 업데이트에서 실제로 지갑에 영향을 주는 항목입니다.

360p 미리보기를 만들 수 있게 됐습니다. 발표문의 문장을 그대로 옮기면, 옴니 1.1의 표준 해상도인 720p와 견줘 최대 60% 빠르고 값은 3분의 1입니다.

여기 별표가 하나 붙어 있습니다. 발표문 자체가 각주로 “최대 60% 빠르다는 것은 360p와 720p의 시스템 처리량(system throughput) 기준”이라고 밝혀 뒀습니다. 즉 항상 60%가 아니라 조건이 좋을 때의 상한값입니다. 이런 각주는 원문에 있는 그대로 옮기는 게 맞습니다.

작업 방식이 어떻게 바뀌는지를 그림으로 그려 보면 이렇습니다.

지금까지: 720p로 뽑는다 → 마음에 안 든다 → 720p로 또 뽑는다 → 또 안 든다 → 720p로 또 뽑는다. 버린 것도 다 720p 값을 냈습니다.

앞으로: 360p로 서너 개 뽑는다 → 그중 하나를 고른다 → 그것만 720p나 4K로 올린다. 버린 것들은 3분의 1 값만 냈습니다.

발표문도 이 방식을 “드래프트 룸(Draft Room)“이라는 이름으로 예시에 넣었습니다. 360p로 서너 개 변형을 만들되 한 번에 한 가지만 바꿔 가며 나란히 비교하는 구성입니다.

한 번에 한 가지만 바꾸라는 조언은 사소해 보이지만 중요합니다. 프롬프트를 세 군데 동시에 고치면 결과가 나아졌을 때 무엇 때문에 나아졌는지를 알 수 없습니다.

값을 직접 계산해 보자

이제 실제 숫자를 보겠습니다. 제미나이 API 공식 요금 문서에 적힌 값입니다.

영상은 토큰으로 값이 매겨집니다. 여기서 토큰은 모델이 세는 단위라고만 알아 두시면 됩니다. 글자를 세듯 영상도 잘게 세는데, 요금 문서가 그 환산 비율을 적어 뒀습니다.

720p 영상 1초당 5,792 토큰으로 계산한다. 표준 요금 기준으로 이는 초당 약 $0.10에 해당한다.

곱셈이 맞는지 직접 해 보겠습니다. 5,792 × ($17.50 ÷ 1,000,000) = 약 $0.1014입니다. 문서가 말한 “약 $0.10”과 맞습니다.

이제 내 단위로 바꿔 보겠습니다.

• 8초짜리 클립 하나 = 약 $0.81
• 40초를 꽉 채운 한 편 = 약 $4.06
• 360p 초안 40초 = 그 3분의 1이니 약 $1.35

숫자를 이렇게 놓고 보면 앞 절의 이야기가 왜 돈 이야기였는지가 분명해집니다. 40초짜리 하나를 만들려고 720p로 다섯 번 시도하면 약 $20이 나갑니다. 360p로 다섯 번 뽑아 고른 뒤 마지막 하나만 720p로 올리면 약 $10.8입니다. 절반 가까이 차이가 납니다.

영상뿐 아니라 이미지나 텍스트도 토큰으로 값이 매겨지는 방식은 같습니다. 이미지 쪽이 어떻게 세어지는지는 이미지가 토큰으로 바뀌는 규칙을 따라간 글에 자세히 적어 뒀습니다. 계산 감각을 잡아 두면 어느 모델을 만나도 요금표를 읽을 수 있습니다.

Veo 3.1과 나란히 놓으면

같은 요금 문서에 구글의 다른 영상 모델인 Veo 3.1도 실려 있습니다. 나란히 놓아 보겠습니다.

720p 한 줄만 보면 제미나이 옴니 1.1 플래시(약 $0.10)는 Veo 3.1 Standard($0.40)의 4분의 1이고, Veo 3.1 Fast($0.10)와는 같은 값입니다. 그리고 Veo 3.1 Lite($0.05)가 가장 쌉니다.

그러니 “새 모델이 제일 싸다”는 정리는 사실이 아닙니다. 정확히 말하면 같은 720p 기준으로 Veo 3.1의 중간 등급과 나란한 값에, 이어 붙이기·프레임 지정·360p 초안 같은 조작 수단이 붙은 것입니다.

주의할 점이 하나 더 있습니다. 요금 문서는 Veo 3.1 값에 대해 “오디오 포함 가격(기본값)“이라고 명시합니다. 옴니 1.1 플래시 쪽에는 오디오 포함 여부를 따로 나눈 표기가 없습니다. 발표문에 실린 예시 프롬프트에는 인물의 대사와 음악이 들어가지만, 요금이 오디오 유무로 갈리는지는 문서에 적혀 있지 않습니다. 적혀 있지 않은 것은 적혀 있지 않다고 적어 두겠습니다.

모델별 요금이 어떤 경로를 타느냐에 따라 또 달라지는 사례는 같은 모델이 중개 서비스에서 반값이던 이야기에 정리해 뒀습니다.

3초짜리 참고 영상이 하는 일

네 번째 기능은 입력 쪽입니다. 프롬프트를 쓸 때 최대 3초짜리 영상을 참고 자료로 함께 넣을 수 있습니다.

글로 설명하기 어려운 것들이 있습니다. 어떤 춤 동작인지, 어떤 식으로 카메라가 흔들리는지 같은 것들이죠. 그런 건 짧은 영상 하나를 보여 주는 게 문장 열 줄보다 정확합니다.

발표문의 예시가 이 기능의 용도를 잘 보여 줍니다. 춤추는 사람이 나오는 영상 세 개와 캐릭터 이미지 세 개를 주고, 각 캐릭터가 각 영상의 춤을 추게 하는 프롬프트입니다. 개 캐릭터는 첫 번째 영상의 고전 무용을, 문어 캐릭터는 다른 영상의 힙합을 추는 식입니다.

동작은 영상에서 가져오고 외모는 이미지에서 가져오는 셈입니다.

구글이 예시로 든 앱 세 개

발표문은 “개발자가 이걸로 무엇을 만들 수 있는지”를 보여 주는 예시를 셋 실었습니다. 기능 목록보다 이쪽이 쓸모를 가늠하기 좋습니다.

첫째, 전환 만들기 앱. 시작 프레임과 끝 프레임을 떨어뜨려 넣으면 그 사이의 전환을 만들어 줍니다. 미리 준비된 프리셋으로 고르거나 프롬프트 칸에 직접 쓸 수 있습니다. 발표문은 이 앱이 가능한 이유를 옴니의 “전체 문맥 추론(full-context reasoning)” 덕이라고 적었는데, 그 결과를 “진짜처럼 읽히는 카메라 움직임”이라고 표현했습니다.

둘째, 집 안을 훑는 앱. 카메라가 방들을 지나며 호를 그리고, 밀고 들어갔다가, 뒤로 빠집니다. 부동산 매물 영상을 떠올리시면 됩니다. 이 예시에서 눈여겨볼 문장은 기능 설명이 아니라 제약입니다. 발표문은 이 앱이 “존재하지 않는 가구나 디테일을 더하지 않는다“고 적었습니다. AI로 만든 공간 영상이 실물과 달라지면 그건 기능이 아니라 사고이기 때문입니다.

셋째, 드래프트 룸. 앞에서 한 번 언급한 그 예시입니다. 창작자는 원래 마음에 드는 하나를 고르기까지 여러 개를 만들어 봅니다. 드래프트 룸은 그 탐색을 싸고 구조적으로 만듭니다. 360p로 서너 개 변형을 만들되 한 번에 한 가지만 바꿔 가며 나란히 놓고 비교하는 구성입니다.

세 예시의 공통점이 있습니다. 셋 다 “더 예쁜 영상”이 아니라 통제를 파는 앱입니다. 어디서 시작해 어디서 끝날지, 무엇을 더하지 않을지, 무엇을 싸게 여러 번 시도할지가 전부 통제의 문제입니다.

어디서 쓸 수 있나

발표문이 밝힌 사용 경로는 두 갈래입니다.

개발자 쪽은 구글 AI 스튜디오(Google AI Studio)의 제미나이 API와 제미나이 엔터프라이즈 에이전트 플랫폼 API입니다.

일반 사용자 쪽은 구글 AI Plus·Pro·Ultra 구독자가 구글 플로우(Flow)와 제미나이 앱에서 쓸 수 있습니다.

여기서 초심자에게 중요한 건 요금표에 적힌 “무료 등급 없음”입니다. API로 직접 호출하면 첫 초부터 값이 붙습니다. 그래서 처음 써 보는 분이라면 API보다 구독에 포함된 경로(플로우·제미나이 앱)로 감을 잡은 뒤에 API로 넘어가는 쪽이 안전합니다.

코드 한 조각이 말해 주는 구조

발표문에 파이썬 예제가 한 조각 실려 있습니다. 이어 붙이기를 어떻게 부르는지 보여 주는 코드입니다.

from google import genai

client = genai.Client()
interaction = client.interactions.create(
    model="gemini-omni-1.1-flash",
    previous_interaction_id=previous_video_interaction.id,
    input=[
        {"type": "text", "text": "Continue the scene."}
    ],
    response_format={
        "resolution": "360p",
    },
)

코드를 못 읽어도 괜찮습니다. 눈에 담을 건 세 줄입니다.

모델 이름은 gemini-omni-1.1-flash입니다. 문서를 찾을 때 쓸 정확한 문자열입니다.

previous_interaction_id는 앞 영상을 가리키는 표입니다. 영상 파일을 다시 올리는 게 아니라 “아까 그거 이어서”라고 지목하는 방식입니다. 앞 10초를 참고한다는 말이 어떻게 구현되는지가 여기서 드러납니다.

response_format의 resolution이 해상도 손잡이입니다. 초안을 만들 때 여기에 "360p"를 넣고, 마음에 들면 같은 자리를 바꿔 크게 뽑는 흐름입니다. 별도의 도구로 옮겨 가는 게 아니라 값 하나를 바꾸는 것이라, 앞에서 말한 “초안 먼저” 습관을 코드에 붙이기가 쉽습니다.

호출을 어느 경로로 보내고 얼마나 쓰는지를 한곳에서 재고 막는 방법은 AI 요금을 게이트웨이에서 통제한 글에 정리해 뒀습니다. 영상은 단가가 텍스트보다 훨씬 높아서 상한선을 미리 걸어 두는 편이 낫습니다.

구글이 이번에 말하지 않은 것

발표문과 요금 문서를 훑고 나면 비어 있는 칸도 눈에 들어옵니다. 확인되지 않은 것을 확인된 것처럼 쓰지 않기 위해 적어 둡니다.

360p와 4K의 개별 요금이 없습니다. 요금 문서는 720p 기준 환산(1초당 5,792 토큰)만 제시합니다. 360p가 3분의 1이라는 건 발표문의 서술이고, 4K 환산 비율은 어느 쪽에도 없습니다.

속도의 실측값이 없습니다. “최대 60% 빠르다”에는 시스템 처리량 기준이라는 각주가 붙어 있을 뿐, 40초 한 편이 몇 분 만에 나오는지는 적혀 있지 않습니다.

품질 비교 점수가 없습니다. 이전 옴니와 견줘 얼마나 나아졌는지를 재는 벤치마크 수치가 발표문에 없습니다. “시각적 일관성이 개선됐다”는 서술과 예시 영상이 근거의 전부입니다.

오디오 요금 구분이 없습니다. 앞에서 적은 대로입니다.

속도 제한(rate limit) 도 이번 발표문에는 없습니다.

오늘 처음이라면 이 순서로

정리 삼아, 오늘 처음 만져 보는 분을 위한 순서를 적어 두겠습니다.

1. 구독 경로부터 열어 본다. 구글 AI Plus·Pro·Ultra를 쓰고 있다면 플로우나 제미나이 앱에서 먼저 감을 잡으세요. API는 무료 등급이 없어서 실수 한 번이 그대로 값이 됩니다.

2. 첫 8초를 만든다. 이야기 전체를 한 번에 프롬프트로 쓰려 하지 마세요. 첫 장면만 만듭니다.

3. 이어 붙이기는 10초씩, 네 번까지. 붙일 때마다 “무엇이 이어져야 하는지”를 문장으로 씁니다. 예시 프롬프트들이 전부 “카메라가 계속 빠진다” 같은 움직임의 연속을 지시하고 있다는 점을 참고하세요.

4. 초안은 360p로만. 이게 이번 업데이트의 실질입니다. 720p로 여러 번 뽑는 습관이 남아 있으면 새 기능을 쓰면서 옛날 값을 내게 됩니다.

5. 한 번에 한 군데만 고친다. 드래프트 룸 예시가 강조한 방식입니다.

6. 마지막 하나만 올린다. 고른 뒤에 1080p나 4K로 업스케일합니다.

정리 — 문장 하나로

이번 발표를 한 문장으로 줄이면 이렇습니다.

앞 1초만 보던 모델이 10초를 보게 됐고, 그 덕에 40초짜리 한 편이 가능해졌으며, 그 과정에서 버리는 시도들의 값이 3분의 1로 내려갔다.

화질이 좋아졌다는 이야기가 아닙니다. 여러 번 시도해 보는 일이 싸졌다는 이야기입니다. AI로 무언가를 만드는 일에서 비용의 대부분은 완성본이 아니라 버린 것들에 있으니까요.

참고한 자료

• Google, “Gemini Omni 1.1 Flash lets you build with more control” (2026년 8월 27일) — https://blog.google/innovation-and-ai/technology/developers-tools/build-with-gemini-omni-1-1-flash/
• Google, Gemini API 요금 문서 — https://ai.google.dev/gemini-api/docs/pricing