영화 한 편을 떠올려 보자. 주인공이 거실에 있다가 세탁실로 갔다가, 한참 뒤 다시 거실로 돌아온다. 돌아온 거실은 아까 그 거실이어야 한다. 소파 위치도, 창문 방향도, 테이블 위에 놓인 물건도 그대로여야 한다. 사람 감독에게는 당연한 이 일이, 각본을 받아 장면을 한 조각씩 만들어 내는 AI에게는 의외로 어렵다.
ATAS(Any Time, Any Space)는 이 문제를 새 영상 모델을 만들어 푸는 대신, 기존 영상 생성기에 두 종류의 '기억'을 붙여서 푼다. 하나는 방의 공간 구조를 담는 장면 기억, 다른 하나는 거기서 벌어진 사건을 담는 사건 기억이다. 그리고 생성기가 새로 만든 장면을 곧바로 믿지 않고, 검증을 통과한 것만 이 기억에 집어넣는다. 저자들은 영상 생성기 네 종에서 샷(긴 영상을 나눈 한 조각) 사이의 일관성 지표가 모두 좋아졌고, 각 생성기에서 가장 높은 종합 점수를 받았다고 보고한다.
사람에게 쉬운 일이 왜 AI에게 어려울까. 지금까지의 시스템은 샷 사이의 연속성을 주로 세 가지로 유지해 왔다. 직전 프레임 몇 장을 넘겨주거나, 텍스트 요약을 전달하거나, 참고 이미지를 검색해 붙이는 방식이다. 바로 이어지는 샷끼리는 이걸로 충분하다.
문제는 '비연속' 요청이다. 중간에 다른 장면이 여럿 끼어든 뒤 아까 그 방으로 돌아가거나, 아까 그 사건을 다시 꺼내 달라는 요청에는 이 단서들이 무력하다. 직전 프레임은 방금 전 세탁실을 담고 있을 뿐, 세 샷 전 거실의 배치를 같은 기준 좌표 위에 들고 있지 않기 때문이다. 논문은 이를 '지속되는 세계 상태(world state, 샷이 바뀌어도 유지되는 장면·사건의 공통 기록)'가 없어서 생기는 문제로 본다. 이 상태를 유지하려면 두 가지가 필요하다. 첫째, 과거 관측을 공간과 시간 양쪽으로 다시 꺼낼 수 있게 저장해야 한다. 둘째, 생성물의 오류를 무턱대고 받아들이면 안 된다. 생성된 장면의 시각적·기하학적 오류가 그대로 상태에 들어가면, 한 번 어긋난 방이 그 뒤 모든 복귀 샷을 오염시킨다.
이 문제를 두고 세 갈래의 시도가 있었다. 첫째, 긴 영상 생성 자체를 늘리는 쪽은 한 번에 더 긴 맥락을 보거나 카메라·모션을 제약하지만, 여러 클립의 관측을 어떻게 저장하고 다시 꺼낼지는 정하지 않는다. 둘째, 에이전트형 영상 시스템(각본을 받아 여러 번에 걸쳐 스스로 다음 샷을 정해 만드는 AI)은 각본 분석·샷 계획·심사를 붙이지만, 샷 사이에 남기는 것이 대개 프롬프트나 참고 이미지 같은 '편집용 맥락'이라 공유 좌표계나 사건-시각 색인이 없다. 셋째, 명시적 기억 쪽은 점구름이나 3D 표현으로 공간을 기억하지만, 생성한 관측을 '미래 상태로 받아들일지 말지' 판정하는 단계가 없다. ATAS의 차별점은 둘이다. 공간 기억과 사건 기억을 나누고, 관측을 기억에 넣기 전에 검증한다.
ATAS의 설계를 한 문장으로 줄이면, 영상 제작을 '보이는 결과물'과 '기억에 남길 증거'로 분리한 것이다. 기억은 두 종류로 나뉜다.
장면 기억(scene memory)은 방의 공간 구조를 공유 좌표계(모든 관측을 같은 기준 축 위에 맞춰 두는 것)에 저장한다. 거실을 처음 찍은 장면이 들어오면 그게 그 방의 좌표 기준이 되고, 이후 받아들여진 장면들은 이 기준에 맞춰 정렬돼 정적 점구름(공간을 수많은 점의 좌표로 표현한 것)으로 합쳐진다. 이때 움직이는 영역은 빼고 고정된 구조만 남긴다. 나중에 그 거실로 돌아가는 요청이 오면, 저장된 좌표를 요청받은 위치와 카메라 각도에서 다시 그려 참조 이미지로 생성기에 넣어 준다. 집의 뼈대를 3D로 기억해 두고 어느 방향에서든 다시 꺼내 그려 주는 설계도 보관함에 가깝다.
사건 기억(event memory)은 움직이는 장면을 따로 둔다. '어느 장면의, 어떤 사건이, 언제'인지로 색인을 달아, 그 사건을 장면 좌표계에 등록한 프레임별 증거(RGB-D·마스크·동적 점구름)와 출처·시간 같은 메타데이터로 보관한다. 뒤에서 '아까 그 사건을, 그 시간 구간을' 다시 꺼내 달라는 요청이 오면 색인으로 바로 찾아 꺼내고, 맞는 기록이 없으면 비어 있는 결과를 돌려준다. 여기서 중요한 건, 이 기억이 '누가 어떻게 움직였다'는 식의 정리된 결론이 아니라 그때의 관측을 장면 좌표계 위 프레임별 증거로 보존한다는 점이다. 원본 영상을 통째로 보관하는 것과는 다르다.
전체 흐름은 이렇다. 각본을 받으면 '월드 상태 컴파일러'가 긴 각본을 생성기가 한 번에 만들 수 있는 영상 길이에 맞춰 작은 샷 요청으로 쪼갠다(복잡한 각본을 계속 더 작은 단위로 나누는 방식이다). 각 요청에는 무엇을 찍을지, 어느 장면인지, 그 방 안 어디쯤에서 어떤 카메라로 볼지, 어느 시간 구간인지, 그리고 사건이라면 어떤 사건인지가 담긴다. 이 요청으로 두 기억을 조회해 맥락을 만들고, 그 맥락을 조건으로 생성기가 짧은 클립을 만든다.
생성된 클립은 곧바로 기억에 들어가지 않는다. 먼저 '후보 관측'이 되어 두 가지 판정을 따로 받는다. 하나는 영상 심사 — 이 클립을 최종 영상에 쓸 만한가. 다른 하나는 등록 — 재구성한 결과가 장면 좌표계에 제대로 맞아떨어지는가. 상태 업데이트는 이 둘을 통과하고 출처·장면 범위·이전 상태 버전까지 맞을 때만 이뤄진다. '최종 영상에 쓸 만한가'와 '기억에 넣을 만큼 믿을 만한가'는 다른 질문이다. 영상으로는 괜찮지만 좌표 정렬에 실패한 클립은 최종 영상에는 남되, 뒤 샷의 조건으로는 쓰이지 않는다. 어긋난 관측이 세계 상태로 흘러들어 다음 샷을 오염시키는 길을 이 분리가 끊는다.
평가는 표준 벤치마크, 지속성 과제, 통제 분석으로 짜였다. 독자 입장에서는 세 질문으로 묶어 보는 게 빠르다. 같은 방으로 돌아오는가, 같은 사건을 재현하는가, 비용은 얼마나 드는가. 비교 대상은 생성기 네 종(MiniMax-H3·Wan 2.7·HappyHorse 1.0·Wan 3.0)과 에이전트 다섯 종(I2V Extension·VGoT·Mora·MovieAgent·ReCA)이며, 각 생성기 블록 안에서 같은 조건으로만 비교한다.
표준 벤치마크(VBench·ST-Bench·ViStory 등 공개 평가 도구)로 재면, ATAS는 MiniMax-H3·Wan 3.0·HappyHorse 1.0에서 보고된 모든 종합 점수를 이끌었다. 예를 들어 Wan 3.0에서 종합 평균 0.734로 2위 ReCA(0.648)를 앞선다. Wan 2.7에서는 VBench 한 항목에서 ReCA(0.854)에 근소하게 뒤졌지만(ATAS 0.846), 종합 평균(0.656 대 0.612)은 가장 높았다. 오픈소스든 상용이든 같은 패턴이 나왔다. 저자들은 이 이득이 특정 생성기가 좋아서가 아니라 샷을 가로지르는 지속 상태에서 온다고 본다.
방법은 이렇다. 생성한 복귀 장면을 실제 목표 이미지와, 두 화면에 공통으로 보이는 영역만 떼어 비교한다. 지표는 PSNR_C·SSIM_C(높을수록 좋은 화질 유사도)와 LPIPS_C(낮을수록 좋은 지각 거리)다. 비교 대상에는 에이전트 방식뿐 아니라 3D로 장면을 다시 그리는 방법(FlexWorld·ViewCrafter)도 들어간다. 결과는 ATAS가 PSNR_C 15.968, SSIM_C 0.385, LPIPS_C 0.284로 비교 대상들을 앞섰다.
영상과 글을 함께 이해하는 AI(비전-언어 모델)에게 원본 사건 프레임, 사건 설명·구간, 요청 카메라, 생성 클립을 주고 다섯 축으로 채점시킨다. 같은 영상을 똑같이 복제했는지가 아니라 '그 사건이 그 카메라에서 되살아나는가'를 본다. 그래서 동기화된 타깃 영상은 쓰지 않는다.
| 축 | ATAS | 비고 |
|---|---|---|
| 사건 정체성 | 0.750 | 선두 |
| 시간 순서 | 0.688 | 선두 |
| 시점 구현 | 0.650 | 선두 |
| 캐릭터/사물 일관성 | 0.917 | ReCA와 동률 |
| 동작/상태 보존 | 0.688 | ReCA 0.700에 근소 열세 |
이 표의 마지막 줄이 핵심을 가른다. 남은 어려움은 그 사건을 '찾아오는' 데 있지 않고, 동작과 상태를 '똑같이 재현하는' 데 있다. 이 둘은 서로 다른 일이다. 하나는 올바른 과거 증거를 찾아 생성기에 건네주는 일이고, 다른 하나는 생성기가 그 증거대로 움직임을 실제로 그려 내는 일이다. ATAS가 맡는 건 앞의 일이다. 뒤의 일은 생성기 자신의 역량에 달려 있어, 올바른 증거가 손에 있어도 생성기가 같은 동작을 충실히 그려 내지 못하면 이 점수는 뒤처진다.
저장하는 증거 양을 바꿔 가며 메모리 비용을, 그리고 여섯 가지 메모리 설정에 걸쳐 실행 시간·재시도·처리량을 잰다.
| 지표 | 기억 없음 | 지속 기억 |
|---|---|---|
| 샷당 재시도 | 1.00 | 0.54 |
| 재시도 반영 납품 시간 | 359초 | 339초 |
| 이야기당 실행 시간 | 51.9분 | 64.9분 |
| 처리량 | 7.28샷/시간 | 6.21샷/시간 |
| 샷당 메모리 오버헤드 | — | 98초 |
정리하면 교환이다. 기억을 쌓고 검증하는 값을 치르는 대신, 틀린 상태가 뒤로 번져 생기는 헛된 재생성을 줄인다. 총 연산량 자체는 늘어난다.
검증 게이트의 효과는 두 가지로 나눠 봐야 한다. 하나는 당장 보이는 효과다. 기억을 많이 쌓을수록 영상 심사 거절률이 52.6%(기억 없음)에서 36.8%(전체 상태)로 꾸준히 내려갔고, 중간 설정들도 모두 같은 방향이라 이 개선이 최종 구성에서만 생긴 것은 아니다. 다른 하나는 여러 샷에 걸친 효과로, 한 번 어긋난 관측이 뒤 샷으로 번지며 오류가 쌓이는 것을 막는 쪽이다. 여기까지는 확인된 결과다. 다만 구성 요소를 다 넣은 마지막 단계에서 점수가 크게 오르지 않은 것을 두고, 저자들은 검증이 새 정보를 더한다기보다 이미 가진 역량을 지켜 준다는 뜻으로 읽는다. 이 대목은 측정값이 아니라 저자들의 해석이다.
| 추가한 요소 | 변화 |
|---|---|
| 프레임 히스토리 | 기억 없음 대비 세 지표 모두 상승 |
| 정적 장면 증거 | LPIPS_C 0.030 하락(개선) |
| 장면 갱신 | C-Top10 0.041 상승 |
| 사건 기억 | 재포착 점수 크게 상승, 공간 변화는 작음 |
| 재귀적 컴파일 | 사건 점수 0.508 → 0.711 |
저자들이 인정한 한계가 있다. 사건 재포착에서 동작·상태의 정확한 재현은 ReCA에 근소하게 밀렸다. 사람 평가에서는 여섯 기준 모두 평균 1위였지만 기준별 편차가 컸다.
| 기준 | 평균 |
|---|---|
| 각본 충실도 | 4.40 |
| 캐릭터 일관성 | 4.22 |
| 시각적 매력 | 4.10 |
| 서사 일관성 | 3.77 |
| 배경 일관성 | 3.62 |
사람은 샷이 각본에 충실한지, 캐릭터가 이어지는지는 또렷이 느끼지만, 환경 전체의 일관성과 이야기 전체의 흐름은 아직 덜 풀렸다고 느낀다. 효율에서 총 연산량이 늘어난다는 점도 저자들은 숨기지 않는다.
아직 답하지 못한 질문도 있다. 이 방식은 '첫 관측이 좌표계를 올바로 세운다'는 전제에 기대는데, 첫 등록이 기울어지면 그 뒤 정렬이 전부 그 기준에 묶인다. 장면 기억이 고정된 구조만 남기고 움직이는 영역을 빼는 설계도, 가구가 옮겨지거나 조명이 바뀌어 '정적이라 믿었던 것'이 달라지는 이야기에서 어떻게 동작하는지는 확인되지 않았다. 비교가 생성기 네 종·에이전트 다섯 종·3D 방법 몇 가지로 한정된다는 점도, 다른 환경으로의 일반화를 가늠할 때 염두에 둘 지점이다.
이 논문은 영상 연구지만, AI PM 에이전트를 다루는 우리에게 쓸모 있는 건 영상 기술이 아니라 '상태 업데이트 규칙'이다.
장면을 하나 그려 보자. AI 프로젝트 매니저가 여러 날, 여러 세션에 걸쳐 한 프로젝트의 상태를 쌓는다. 어제 회의에서 '결제는 기존 상점 체인을 재사용한다'로 정해졌는데, 오늘 에이전트가 만든 요약에는 '결제는 토스 PG 신규 신청으로 진행'이라는 문장이 섞여 들어간다. 그럴듯하지만 틀렸다. 흔한 설계라면 이 요약이 그대로 프로젝트 메모리에 들어가고, 다음 주 회의 준비 때 그 오염된 상태를 다시 읽어 같은 오류를 재생산한다. ATAS가 영상에서 막으려던 바로 그 전파다.
ATAS의 처방을 옮기면 두 갈래가 된다. 첫째, 산출물 납품과 상태 등록을 분리한다. 요약 속 '결제=신규 신청'이라는 오류는 보고서 단계에서 바로잡아 내보낸다. 동시에 그 결정이 프로젝트의 지속 상태에 사실로 등록되려면, 원문 회의 기록과의 대조·출처·이전 상태 버전과의 정합을 따로 거치게 한다. 보고서를 고쳐 내보내는 일과, 그 내용을 장기 기억에 사실로 박는 일은 다른 판정이다. 둘째, 상태를 '정리된 결론'이 아니라 '언제·어디서·무엇이 나왔는지 색인된, 출처가 붙은 증거'로 보관한다. 그래야 나중에 '그 결정 언제 어느 회의에서 나왔지'를 채널(공간)과 날짜(시간)로 되짚고, 결정의 출처를 보존할 수 있다.
검증 게이트를 다는 값이 공짜가 아니라는 점도 함께 봐야 한다. ATAS에서 그랬듯 처리 오버헤드가 붙고 총 작업량이 늘 수 있다. 그 대신 틀린 상태가 뒤로 번져 생기는 재작업이 줄어든다. 다만 이 교환이 우리 업무에서 실제로 이득인지는, 재작업 감소분과 추가 비용을 직접 재 봐야 답할 수 있는 질문으로 남겨 둔다.
무엇부터 할지 하나만 고른다면, 지금 에이전트의 산출물이 '납품'과 '기억 등록'을 같은 한 번의 판정으로 처리하고 있지 않은지부터 확인하라. 둘이 붙어 있다면, 거기가 오염이 번지는 첫 길목이다.
비교에서 같은 블록 안의 방법들은 같은 생성기·프롬프트·길이 예산·평가 프로토콜을 공유하고, ATAS는 이 인터페이스를 비교 전반에서 고정해 둔다. 특정 생성기에 유리한 세팅이 아니라, 네 생성기 모두에서 같은 개선 패턴이 나왔다는 점이 근거다.
아니다. ATAS는 생성기 위에 얹는 틀이라 생성기를 다시 학습시키지 않는다. 각본을 샷 요청으로 쪼개고, 기억에서 증거를 조회해 조건으로 주고, 생성된 클립을 검증해 기억을 갱신하는 규칙만 바깥에서 돌린다.