a16z: 시각 AI의 미래는 이미지가 아니라 코드다

원문 제목: The Next Frontier of Visual AI Is Code
원문 저자: @stuffyokodraws, a16z
편역: Peggy

편집자 주: 지난 몇 년간 비주얼 AI의 경쟁은 거의 한 가지 질문을 중심으로 전개되었습니다. 누가 더 사실적인 이미지를 생성하고, 누가 더 부드러운 영상을 만드는가. 확산 모델은 텍스트 프롬프트를 이미지, 영상, 사실적인 장면으로 바꾸어 주었고, 외부에서는 '닮았는가', '아름다운가'로 모델의 성능을 평가하는 데 익숙해졌습니다.

하지만 a16z의 이 글은 비주얼 AI의 다음 단계가 단지 더 예쁜 픽셀을 생성하는 것이 아니라, 픽셀 뒤에 있는 코드 아티팩트(code artifact, 계속 편집·테스트·전달 가능한 구조화된 파일)를 생성하는 것일 수 있다고 지적합니다.

이 차이는 기술적으로 보일 수 있지만, 실제로는 AI가 생산 워크플로우에 진정으로 진입할 수 있는지를 결정합니다. 디자이너에게 필요한 것은 단순한 UI 스크린샷이 아니라 HTML/CSS, React 컴포넌트, 레이어, 전달 가능한 파일입니다. 애니메이터에게 필요한 것은 단순한 영상이 아니라 키프레임, 타임 커브, 수정 가능한 모션 파라미터입니다. 3D 아티스트에게 필요한 것은 단순한 렌더링 이미지가 아니라 지오메트리 구조, 재질, 조명, 카메라, 씬 계층 구조입니다.

따라서 이 글은 비주얼 생성을 두 가지 경로로 나눕니다. 픽셀 네이티브 생성(이미지나 영상을 직접 생성)은 사실감, 분위기, 탐색에 적합하고, 코드 네이티브 생성(SVG, Lottie, Blender 스크립트, USD 씬 등 생성)은 편집, 반복, 생산에 더 적합합니다. 후자가 진정으로 중요한 이유는 '코드 → 렌더링 → 검사 → 수정'의 폐루프를 형성할 수 있기 때문입니다. 모델은 더 이상 반복적으로 샘플링을 다시 하는 것이 아니라, 검증 가능한 비주얼 프로그램을 디버깅하는 것입니다.

이것이 바로 저자가 특히 3D를 주목하는 이유이기도 합니다. 의자의 렌더링 이미지는 의자가 아니라 의자의 사진일 뿐이기 때문입니다. 게임, 시뮬레이터, 3D 도구에서 실제로 사용할 수 있는 에셋은 안정적인 지오메트리 구조, 부품 계층, 재질, 기능적 제약 조건을 갖추어야 합니다. 문은 열릴 수 있어야 하고, 서랍은 미끄러질 수 있어야 하며, 바퀴는 회전할 수 있어야 합니다. 즉, 미래 비주얼 AI의 가치는 '보기에 비슷한가'가 아니라 '계속 사용할 수 있는가'에 달려 있습니다.

이 글은 좋은 판단 프레임워크를 제공합니다. 첫 번째 물결의 비주얼 AI는 생성 문제를 해결했고, 다음 물결은 생산 문제를 해결해야 합니다. 비주얼 AI가 최종 출력에서 소스 코드로 나아갈 때, 진정으로 바뀌는 것은 디자인 도구뿐만 아니라 전체 비주얼 콘텐츠 생산 체인입니다.

다음은 원문입니다:

지난 몇 년 동안 비주얼 AI는 대부분 '픽셀'을 기준으로 평가되어 왔습니다. 최종적으로 생성된 이미지나 영상이 좋아 보일수록 모델이 더 강력해 보였습니다.

이는 놀라운 일이 아닙니다. 확산 모델은 먼저 텍스트 프롬프트를 멋진 이미지로 바꾸고, 이후 비디오로, 그리고 점점 더 사실적인 세계로 확장되었습니다. 사람들은 자연스럽게 이를 포토샵이나 카메라와 비교하게 됩니다.

하지만 그래픽 디자인, UI 디자인, 3D 모델링 등 많은 시각 관련 작업에서 사용자가 진정으로 필요로 하는 최종 표현은 단순히 최종적으로 보여지는 픽셀만이 아닙니다. 그들이 필요로 하는 것은 피드백과 새로운 아이디어에 따라 지속적으로 반복할 수 있는 산출물입니다. 디자이너는 단순히 목업(mockup)만 필요한 것이 아니라 레이어, 컴포넌트, 전달 파일이 필요합니다. 애니메이터는 단순히 비디오만 필요한 것이 아니라 타임 커브, 키프레임, 편집 가능한 모션 궤적이 필요합니다. 3D 아티스트는 단순히 렌더링 이미지만 필요한 것이 아니라 지오메트리 구조, 재질, 조명, 카메라, 씬 구조가 필요합니다.

오늘날 가장 흥미로운 비주얼 AI 도구들은 더 이상 최종 출력을 직접 생성하려 하지 않습니다. 이제는 최종 출력 뒤에 숨겨진 소스 코드를 생성하기 시작했습니다. 이러한 변화는 픽셀 네이티브 모델이 따라잡기 어려운 편집 가능성, 반복 능력, 피드백 루프를 가능하게 하고 있습니다.

비주얼 생성을 위한 두 가지 기술 스택

비주얼 생성은 크게 두 가지 방식으로 이해할 수 있습니다.

첫 번째는 픽셀 네이티브 생성입니다. 이러한 시스템은 일반적으로 이미지나 비디오를 직접 생성하며, 주로 잠재 공간에서 이루어집니다. 텍스처, 분위기, 조명, 사실감에 강점을 가지고 있습니다. 영화 같은 장면, 멋진 무드보드(moodboard), 또는 사진처럼 사실적인 이미지를 생성하는 것이 목표라면 확산 모델이 여전히 주류 방법입니다.

두 번째는 코드 네이티브 생성입니다. 이러한 시스템은 다른 엔진이 실행하거나 렌더링할 수 있는 표현 형태를 생성합니다. 모델은 최종 픽셀을 직접 생성하는 것이 아니라, 픽셀을 생성할 수 있는 프로그램을 생성합니다.

이 프로그램은 SVG 파일, HTML/CSS 레이아웃, React 컴포넌트, Lottie JSON 파일, Blender 스크립트, USD 씬 그래프, 셰이더(shader), 또는 게임 엔진 씬이 될 수 있습니다. 최종 시각적 출력은 여전히 픽셀이지만, 진정한 '진실의 원천'은 구조화된 표현입니다.

이 차이는 중요합니다. 왜냐하면 프로덕션 워크플로우는 '생성 후에 일어나는 일'을 매우 중요하게 여기기 때문입니다. 생성된 이미지는 출력물로 사용될 수 있지만, 생성된 비주얼 프로그램은 산출물로 사용될 수 있습니다. 편집, 재사용, 개선, 버전 관리가 가능하며, 소프트웨어 기술 스택에 통합되어 제약 조건에 따라 검증될 수 있습니다. 다양한 조건에서 반복적으로 렌더링될 수 있으며, 디자이너, 엔지니어, 에이전트 간에 전달될 수 있습니다.

저는 중요한 전환이 이미 일어나고 있다고 생각합니다. 일부 시각적 문제에 대해, 우리는 시각적 생성 작업을 인코딩 작업으로 재정의하고, 경계가 명확하고 검증 가능한 인코딩 문제를 해결함으로써 매우 효율적인 개선을 얻을 수 있을 것입니다.

코드는 시각적 문제를 해결하기 좋은 매개체다

시각적 코드 생성의 가치를 이해하는 가장 쉬운 방법은 첫 번째 초안 이후에 어떤 일이 일어나는지 보는 것입니다.

모델이 로고를 생성한다고 가정해 보겠습니다. 출력이 래스터 이미지이고 곡선 하나가 잘못되었다면, 사용자는 마스킹, 부분 재생성, 재생성, 또는 수동으로 다시 그려야 합니다. 하지만 출력이 SVG라면, 사용자는 경로, 기본 도형, 그라데이션, 선 또는 텍스트 요소를 직접 편집할 수 있습니다. 이것은 이미 디자이너가 Quiver에서 로고를 디자인하는 방식입니다.

UI 디자인 분야에서 출력이 스크린샷이라면, 그것은 더 많은 영감 참고 자료에 불과합니다. 하지만 출력이 HTML/CSS 또는 React라면, 디자이너는 DOM을 검사하고, 실제 컴포넌트를 교체하며, 반응형 상태를 테스트하고, 접근성을 확인한 후 애플리케이션에 연결할 수 있습니다.

이것이 바로 시각적 코드 생성이 test-time compute(테스트 시간 계산)에 특히 적합한 이유이기도 합니다. 픽셀 기반 생성에서 추론 계산을 늘리는 것은 일반적으로 더 많은 출력을 샘플링하는 것을 의미합니다. 20개의 이미지를 생성하고 가장 좋은 것을 고르고, 아마도 다시 시도하는 것입니다. 물론 효과적이지만, 매번 시도는 본질적으로 주사위를 다시 던지는 것과 같습니다. 모델이 피드백에 응답할 수는 있지만, 이 피드백은 일반적으로 전체적이고 정확하지 않습니다.

기술적으로 확산 모델도 test-time compute의 혜택을 받을 수 있습니다. 예를 들어, 《Inference-time Scaling of Diffusion Models through Classical Search》는 추론 단계의 검색이 계획, 강화 학습 및 이미지 생성에서 확산 모델의 성능을 향상시킬 수 있음을 보여줍니다. 하지만 여기서의 루프 메커니즘은 다릅니다. 확산 모델에서 시스템은 일반적으로 잠재적 궤적 또는 최종 샘플 사이를 검색합니다. 보상 신호는 모델에게 어떤 출력이 다른 것보다 낫다고 알려줄 수 있지만, 피드백을 소스 코드 수준의 특정 수정 사항에 명확하게 매핑할 수는 없습니다.

코드 기반 생성은 더 정확한 루프를 만듭니다: 코드 → 렌더링 → 검사 → 수정.

모델이 결과물을 생성하고, 이를 렌더링한 후, 문제가 있는 부분을 관찰하고 소스 파일을 수정합니다. 간격이 잘못되면 CSS를 수정하고, 로고 곡선이 어긋나면 SVG 경로를 편집하며, 애니메이션 속도가 너무 느리면 시간 매개변수를 조정합니다. 핵심은 매 반복마다 렌더링된 출력뿐만 아니라 기본 결과물 자체를 개선한다는 점입니다. 이것이 바로 시각적 코드 생성이 더 많은 토큰 생성과 test-time compute의 혜택을 자연스럽게 받을 수 있는 이유입니다. 모델은 단순히 더 많은 이미지를 샘플링하는 것이 아니라, 폐쇄 루프의 검증 가능한 환경에서 시각적 프로그램을 디버깅하는 것입니다.

코드 중심의 시각 생성 기술 스택

위 예시 뒤에는 다음과 같은 기술 스택이 있습니다: 인코딩 모델 + 기호 표현 + 렌더러 또는 엔진.

인코딩 모델은 결과물의 작성자이자 편집자입니다. HTML, SVG, Lottie JSON, Blender 스크립트, USD 씬 또는 맞춤형 3D 에셋 프로그램을 작성합니다.

기호 표현은 사실의 출처입니다. 이것이 바로 결과물에 편집 가능성이 있는 이유입니다. UI에는 DOM 노드, 레이아웃 규칙 및 컴포넌트가 있습니다. Lottie 애니메이션에는 레이어, 벡터 모양, 시간 곡선, 키프레임 및 모션 파라미터가 있습니다. 3D 에셋에는 기하학적 구조, 재질, 관절, 제약 조건 및 계층 관계가 있습니다.

렌더러 또는 엔진은 이러한 구조를 픽셀로 변환합니다. 브라우저는 HTML/CSS를 렌더링하고, SVG 렌더러는 벡터 그래픽을 렌더링하며, Lottie 플레이어는 애니메이션을 렌더링하고, Blender 또는 게임 엔진은 3D 씬을 렌더링하며, 시뮬레이터는 관절이 있는 에셋이 실제로 움직이거나 상호작용할 수 있는지 검증합니다.

OmniLottie는 기호 표현이 왜 중요한지 보여주는 좋은 예입니다. Lottie는 경량의 JSON 기반 애니메이션 형식으로, 애니메이션을 평평한 비디오 조각으로 표현하는 대신 편집 가능한 벡터 모양, 레이어, 키프레임 및 시간 파라미터로 움직임을 나타냅니다. OmniLottie는 원시 Lottie JSON을 모델이 이해하기 더 쉬운 명령 시퀀스로 변환하여 모델이 Lottie 애니메이션을 더 안정적으로 생성하고 편집할 수 있도록 제안합니다. 이 논문의 핵심은 완전한 Agent 루프를 구축하는 것이 아니라 Lottie를 모델 생성에 더 적합하게 만드는 데 있습니다. 즉, 원시 Lottie JSON을 간결한 명령 및 파라미터 시퀀스로 변환합니다. 이 작업은 Lottie 자체가 이미 편집 가능한 애니메이션 형식이기 때문에 매우 중요합니다. 움직임이 모양, 레이어, 시간 및 애니메이션 파라미터로 표현되면 피드백을 소스 파일 수준의 수정에 매핑할 수 있습니다. 객체가 너무 느리게 움직이면 시간을 조정하고, 경로가 잘못되었으면 벡터를 수정하며, 변형에 오차가 있으면 모양 시퀀스를 업데이트합니다.

이 기술 스택은 인코딩 Agent가 출력 품질을 향상시키기 위해 사용할 수 있는 test-time compute 루프에 해당합니다. '코드 → 렌더링 → 검사 → 수정'의 각 루프에서 모델은 새로운 샘플을 생성하는 것이 아니라 렌더러가 제공하는 피드백을 활용하여 기본 결과물을 개선합니다. CSS 규칙을 수정하고, SVG 경로를 조정하며, 애니메이션 시간을 수정하거나 3D 제약 조건을 업데이트한 다음 다시 렌더링하고 계속 개선할 수 있습니다.

이로 인해 루프가 수렴 가능성을 가지게 됩니다. 픽셀 기반 생성에서는 재시도할 때마다 새로운 출력이 나오는 경우가 많습니다. 반면 코드 기반 생성에서는 재시도할 때마다 소스 아티팩트 자체를 개선할 수 있습니다. 모델은 단순히 더 많은 이미지나 비디오를 샘플링하는 것이 아니라, 폐쇄 루프의 렌더링 가능한 환경에서 시각적 프로그램을 디버깅합니다.

시장 지도: 런타임을 중심으로 형성되는 진입점

시각적 코드 생성 시장은 '런타임', 즉 아티팩트가 렌더링되거나 실행되는 곳을 중심으로 조직되고 있습니다. 코드 기반 시각적 생성에서 모델은 상징적 아티팩트를 생성하며, 이 아티팩트는 브라우저, SVG 렌더러, Lottie 플레이어, Blender, 게임 엔진 또는 시뮬레이터와 같은 특정 환경에서 실행됩니다.

각 런타임은 고유한 소스 표현, 피드백 루프 및 프로덕션 워크플로를 가지므로 서로 다른 진입점을 형성합니다.

오늘날 가장 명확한 응용 분야는 2D 디자인, 특히 UI 디자인과 그래픽 디자인입니다. 하지만 시각적 코드 생성은 디자인 도구에 국한되지 않습니다. 시각적 아티팩트 뒤에 생성, 렌더링, 검사 및 최적화할 수 있는 기본 표현이 존재하는 한 어디에서나 나타날 수 있습니다.

3D가 다음 중요한 프론티어인 이유

제품 디자인과 2D 디자인이 오늘날 가장 직관적인 사용 사례이지만, 3D 아티팩트는 '일관성 문제를 코딩 문제로 재정의'하는 이 접근 방식에서 가장 큰 혜택을 볼 수 있습니다.

2D 디자인은 때로는 단순히 올바르게 보이는 것만으로도 유용할 수 있습니다. 하지만 3D 자산은 그렇지 않습니다. 의자의 렌더링 이미지는 의자가 아니라 의자의 사진일 뿐입니다. 이 자산이 게임, 시뮬레이터 또는 3D 편집 도구에서 실제로 사용 가능하려면 올바른 기하학적 구조, 재질, 부품 계층 및 씬 컨텍스트를 포함한 일관된 기본 3D 표현을 가져야 합니다.

이것이 바로 3D가 시각적 코드 생성에 자연스럽게 적합한 이유입니다. 그 가치는 단순히 특정 각도에서 3D처럼 보이는 것을 생성하는 것이 아니라, 다양한 시점, 편집 및 상호작용에서도 일관되게 유지되는 3D 구조를 생성하는 데 있습니다. 이를 위해서는 반복 루프가 필요합니다: 객체를 제안하고, 렌더링하고, 기하학적 구조와 부품이 합리적인지 검사한 후, 기본 표현을 수정하는 것입니다. 하지만 이 루프는 에이전트가 올바른 도구와 컨텍스트를 가질 때만 효과적입니다. 단순히 Blender를 계속 실행하면서 무언가 더 나아 보일 때까지 기다리는 것만으로는 충분하지 않습니다. 에이전트는 카메라 시점을 전환하고, 씬 상태를 쿼리하고, 객체를 분리하고, 목표와 비교하고, 이전 시도를 기억하며, 시각적 차이를 소스 파일 수준의 수정으로 변환할 수 있어야 합니다. 바로 이러한 능력들이 test-time compute가 수렴할 기회를 가지게 하는 요소입니다.

많은 자산에서 시각적 일관성은 기본적인 요구사항에 불과합니다. 객체는 올바른 부품 의미론과 기능적 제약 조건도 갖춰야 합니다. 문은 열려야 하고, 경첩은 회전해야 하며, 서랍은 미끄러져야 하고, 바퀴는 돌아가야 합니다. 즉, 출력물은 단지 그럴듯한 형태를 가져야 할 뿐만 아니라, 그것이 나타내는 대상처럼 작동해야 합니다.

이것이 바로 VIGA와 Articraft3D 같은 프로젝트가 주목받는 이유입니다. 올해에는 상업 프로젝트와 오픈소스 프로젝트를 포함해 더 많은 관련 작업이 등장할 것으로 예상됩니다. VIGA는 Blender를 렌더링 및 피드백 환경으로 사용하여 시각적 재구성을 '코드-렌더링-검사' 루프로 전환합니다. 하지만 VIGA는 단순히 원시 Blender를 Agent 루프에 노출시키지 않습니다. Agent에게 관찰 및 수정을 위한 의미론적 도구를 제공하고, 과거 시도에 대한 기억을 유지하여 더 나은 관점에서 객체를 검사하고, 문제를 진단하며, 목표 지향적인 수정을 가능하게 합니다. Articraft3D는 자산 구조를 더 직접적으로 처리합니다. 관절이 있는 3D 생성을 부품, 기하학 구조, 관절 및 테스트를 정의하는 프로그램을 작성하는 것으로 정의합니다.

미래 영향과 미해결 문제

시각적 코드 생성이 실제로 성립한다면, 최종적으로 승리하는 제품은 단지 더 아름다운 출력물을 생성하는 데 그치지 않을 것입니다. 전체 루프를 장악할 것입니다: 제품을 생성하고, 렌더링하며, 문제점을 검사하고, 소스 파일을 수정하는 것입니다.

이로 인해 몇 가지 영향이 발생합니다.

첫째, 렌더러가 피드백 환경이 될 것입니다. 브라우저, SVG 렌더러, Lottie 플레이어, Blender, 게임 엔진 및 시뮬레이터는 오늘날 코딩 Agent가 샌드박스와 가상 머신을 활용하는 것처럼 Agent가 작업을 테스트하고 개선하는 환경이 될 것입니다.

둘째, 반복 컨텍스트의 품질이 그 어느 때보다 중요해질 것입니다. Agent가 시각적 코드 버전의 'Ralph 루프'에 진입하려면 중간 표현이 다음 작업을 안내할 수 있을 만큼 정밀해야 합니다. 모델은 단순히 '무언가가 이상해 보인다'는 것뿐만 아니라, 소스 파일의 어느 부분을 수정해야 하는지, 그리고 그 이유를 알아야 합니다. 구조, 렌더링 또는 피드백의 작은 오류는 여러 번의 반복을 통해 빠르게 누적될 수 있습니다.

셋째, 미래는 혼합형이 될 가능성이 높습니다. 픽셀 네이티브 모델은 사실감, 텍스처 및 탐색에 여전히 가장 뛰어납니다. 코드 네이티브 시스템은 구조, 반복 및 생산에 더 적합합니다. 가장 유용한 워크플로는 이 둘을 결합할 것입니다.

물론, 많은 미해결 문제가 남아 있습니다. 각 분야에서 최종적으로 어떤 표현 방식이 채택될까요? 이전 세대의 도구를 계속 사용하는 대신 엔진과 렌더러를 새로 만들어야 할까요? 시각적 취향은 어느 정도까지 제약, 테스트 및 피드백 루프로 포착될 수 있을까요?

하지만 방향은 이미 명확합니다: 비주얼 AI가 출력물에서 코드 제품으로 나아가고 있습니다. 첫 번째 물결은 이미지 생성을 더 쉽게 만들었고, 다음 물결은 편집 가능하고, 테스트 가능하며, 전달 가능하고, 개선 가능한 비주얼 제품을 생성하는 것을 더 쉽게 만들 것입니다.

[원문 링크]

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia