AI로 영상 속 움직임을 만들 때, Flyingcar는 왜 여러 번 다시 고쳤을까요?

핵심 요약 (TL;DR)

Flyingcar.pet 제작자는 자동차 영상의 움직임을 Claude로 재현하다가, 간단할 줄 알았던 작업이 여러 날의 수정으로 이어졌다고 밝혔습니다. 한국 시간 10월 20일 공개된 제작 후기입니다.[1] 이 사례에서 배울 점은 완성 속도가 아니라, 눈에 보이는 차이를 수정 조건으로 바꾸는 과정입니다.

처음 요청에는 무엇이 빠져 있었을까요?

제작자는 영상을 보고 three.js로 최대한 비슷한 시뮬레이션을 만들라고 요청했다고 합니다. 그러나 어두운 화면 속 차량을 구분하는 단계부터 도움이 필요했고, 사람이 차종과 대략적인 크기를 알려 줬습니다. 이후에도 이동 방향, 프레임별 위치, 차체의 기울기를 차례로 바로잡았다고 설명합니다.[1]

‘영상처럼 만들어 주세요’는 출발점으로는 자연스럽지만, 무엇이 같아야 하는지까지 정해 주지는 않습니다. 같은 화면을 두고도 한쪽은 이동 경로를, 다른 쪽은 전체 분위기를 완료 기준으로 삼을 수 있습니다. 처음부터 모든 조건을 알 필요는 없어도, 결과를 본 뒤 차이를 이름 붙이는 일은 남습니다.

닮은 움직임과 같은 원리는 어떻게 다를까요?

후기에서 흥미로운 대목은 추진 장치입니다. 제작자는 모양이 비슷해진 뒤에도 비행 중 장치가 작동하지 않거나, 영상에서 확인하지 못한 방향의 장치를 사용한 점을 발견했다고 합니다. 이후 사용할 장치를 제한하고, 미리 정한 경로를 따라가는 방식에서 계속 상태를 조정하는 방식으로 바꾸었다고 설명합니다.[1]

이는 제작자의 작업 기록이지, 물리 모델의 정확성을 독립적으로 검증한 결과는 아닙니다. 원문도 질량과 공기 저항, 추진 장치의 위치와 성능이 추정값이며 실제 제조사의 자료가 아니라고 밝힙니다.[1] 화면이 닮았다는 사실을 실제 차량의 성능 증명으로 읽어서는 안 됩니다.

첫 웹앱의 오류 수정에는 어떻게 가져올까요?

같은 원칙을 더 작은 화면에 적용해 보세요. 예를 들어 물건을 끌어 놓는 연습 앱이라면 ‘부드럽게 움직이게 해 주세요’보다, 누른 위치에서 시작하는지, 손을 놓으면 멈추는지, 화면 밖으로 나가지 않는지를 나누어 적을 수 있습니다. 다음은 원작의 프롬프트가 아닌 실습용 제안입니다.

“물건 하나를 끌어 놓는 화면을 만들어 주세요. 누른 지점과 물건 사이의 거리를 유지하고, 손을 놓으면 멈추게 해 주세요. 창 크기가 달라져도 물건이 화면 밖으로 사라지지 않는지 확인해 주세요.”

오류가 보이면 기대한 장면과 실제 장면을 따로 기록하세요. 수정 후에는 같은 행동을 반복하고, 이전에 잘되던 동작도 다시 확인합니다. 한 번에 ‘더 자연스럽게’ 고치는 것보다 어느 차이를 없앴는지 설명할 수 있는 수정이 다음 요청의 기준이 됩니다.

공개 전에 무엇을 구분해서 남겨야 할까요?

이번 조사에서는 제작자의 후기와 공개 저장소를 확인했습니다.[1][2] 실제 서비스와 별도 제작 블로그는 접근 제한으로 열리지 않아, 시뮬레이션을 직접 조작하거나 계산을 검산하지는 못했습니다. 공개 소스가 있다는 사실과 실행 검증을 마쳤다는 사실은 구분해야 합니다.

여러분의 첫 앱도 확인한 동작, 아직 시험하지 않은 환경, 임의로 정한 값을 짧게 나누어 적어 보세요. 완벽하다는 선언보다 다음 사람이 어디부터 확인하면 되는지 알려 주는 기록이 더 유용합니다.

FAQ: 코딩을 전혀 모르는 사람의 사례인가요?

원문만으로 제작자의 개발 경험을 확정할 수 없습니다. AI를 활용했다는 자기보고를 비개발자 성공 사례로 넓혀 쓰지는 않았습니다.

FAQ: 원작을 그대로 따라 만드는 것이 좋을까요?

첫 실습이라면 물체 하나의 이동처럼 범위를 줄여 보세요. 복잡한 물리 계산보다 기대한 행동과 실제 결과를 비교하는 경험부터 권합니다.

출처
[1] https://news.ycombinator.com/item?id=50157876
[2] https://github.com/closetheloop-dev/flying-car
관찰: 2026-10-20 KST