AI 탐구노트

AA : 비전 기반의 토이 프로젝트를 진행하는 크리에이터 소개

42morrow — Thu, 11 Jun 2026 13:55:14 +0900

X 크리에이터 가운데 AA(링크)라는 아이디를 이용하는 분이 있습니다. 현재 2.4만명의 팔로워를 가진 분으로 Javascript, mediapipe 등의 도구를 이용해 재미난 토이 프로젝트를 진행하고 이를 가지고 영상을 제작해서 공개하죠. 제가 이런 '장난감' 만드는 것을 좋아하다보니 자연스레 그분의 포스트를 접하게 되었는데, 이런 것을 좋아하는 다른 분들을 위해 간단히 링크를 기록해 두겠습니다.

그림 : 공개된 장난감 프로젝트 결과물 영상 예시 중 일부

참고자료

사이트) 공식 개인 홈페이지 (FunWithComputerVision.com) (링크) - 32개의 튜토리얼을 볼 수 있습니다. (1회성 유료구독)
사이트) Midisurvivor 게임 (링크) - 미디 연주을 입력기로 서바이벌 게임을 진행

[바이브코딩] 맞고 고스톱 게임 만들어보기

42morrow — Wed, 10 Jun 2026 13:30:38 +0900

바이브코딩을 이용해 온라인에서 단일 HTML로 동작하는 맞고 프로그램을 만들어봤습니다. 단, 맞고 상대는 사람이 아니라 AI(컴퓨터)입니다. 앞서 온라인 빙고나 대전 테트리스 사례처럼 온라인으로 대결하는 것을 만드는 것은 가능한데, 가족 중에 이걸 굳이 둘이서 하려는 사람은 없어서 그냥 혼자서 놀기 위한 것으로 한정 지었습니다. 하지만 대상만 사람으로 바꿔주면 바로 온라인 맞고가 될 수 있겠죠.

사실 많이 복잡할 것 같고 해서 오랜 시행착오를 예상했었습니다. 그런데 의외로... 개발에 소요된 시간은 그리 길지 않았습니다. 요샌 AI가 저보다도 게임을 더 잘 이해하고 있더라구요. 워낙 위키같은 곳에서 게임의 룰을 상세하게 설명하고 있으니 그런 것을 참고한 AI는 확실히 똑똑할테죠. 그래도 진심 살~짝 놀랐습니다.

1.개요 및 목표

목표를 모바일에서 인터넷 연결없이 단독 실행 가능한 맞고 게임 만들기로 잡았습니다. HTML 파일 하나만 있으면 동작할 수 있도록 말이죠. 향후에는 필요에 따라 룰을 바꾸거나 이벤트나 액션을 넣거나 등등을 할 수 있을 겁니다.

2.구현 과정

기술 스택 : HTML + CSS + JavaScript 기반으로 구현되었습니다.
UI 템플릿 : 기존에 다른 게임들 만들 때 사용했던 SKILL.md에 정의한 보일러 플레이트를 그대로 적용했습니다.
게임 룰 정의 : 위키에 잘 설명되어 있습니다. 다만, 지방, 집안마다 다를 수 있어서 공통적으로 많이 사용하는 룰을 따르도록 했는데 대충 멍박, 띠박, 피박, 쓰리고, 폭탄, 똑딱 등등이 그것에 해당됩니다.
화투패 이미지 생성 :
- GPT Image-2를 이용해서 한번에 생성했고,
- 이것을 base64 인코딩을 이용해 HTML 파일 내에 임베딩했습니다.
- 실제 개별 화투패들은 CSS background-position 슬라이싱 방식을 이용해 잘라서 사용합니다.
최종적으로는 단일 HTML(맞고.html) 파일로 저장됩니다.

3.구현 결과물

최종 결과물을 이용한 게임 플레이 영상은 다음과 같습니다.

영상 : 스마트폰 화면에서 맞고 게임을 진행하는 예시

로그인없이 혼자서 심심할 때 내 폰에서 할 수 있도록 한 것이라 상용 게임 대비 UI나 액션 등에서 부족한 점은 많겠지만 그게 중요한 것은 아니죠. 게임을 할 수 있을 정도로 구현이 되었다는 것에 충분히 만족하고 있으니까요. 필요하면 원하는 내용을 추가하거나 기능을 수정해서 사용할 수 있으니 향후에 쓸모가 더 있을 것 같습니다. 다만... 모바일 화면의 크기 때문에 노안이 있는 분들은 좀 힘들 수 있을 것 같습니다. PC 브라우저에서는 전혀 문제가 없는데 스마트폰 화면에서는 흠... (저도 노안인지라...)

MicYou : 안드로이드 스마트폰을 컴퓨터 무선 마이크로 사용해보자

42morrow — Tue, 9 Jun 2026 16:23:57 +0900

노트북에 내장된 마이크를 이용해서 녹음을 하면 음질이 엄청 떨어집니다. 그래서, USB 나 블루투스 타입의 외장 마이크를 많이 사용하게 되죠. 그런데, 외부에 나가서 마이크가 없는 상황이 되면 어떻게 할까? 예전 같으면 맥북이나 노트북에 아이폰에 번들되어 나오던 유선 이어폰 (마이크 포함)을 끼워 사용하면 되었습니다. 생각보다 성능도 괜찮았거든요. 그런데 최근에는 그렇게 사용할만한 간편한 도구가 잘 보이지 않는 것 같습니다. 이럴 때 사용할 수 있는 도구가 MicYou라는 앱입니다. 이번 글에서는 간단한 요약과 코드의 링크만 기록해 두고 가겠습니다.

1.MicYou 개요

MicYou는 안드로이드 스마트폰을 PC용 마이크처럼 사용할 수 있게 해 주는 오픈소스 도구입니다. 스마트폰 앱이 마이크 오디오를 캡처하고, PC 쪽 데스크톱 서버가 이를 받아 Zoom, Discord, OBS 같은 프로그램에서 사용할 수 있도록 하는 구조로 되어 있습니다.

2.MicYou 특징

MicYou의 특징은 다음과 같습니다.

실시간 오디오 처리에 최적화됨
Kotlin Multiplatform 기반으로 설계되어 있음
실시간 디지털 신호처리(DSP) : 노이즈 억제(Noise Supression), 자동 이득 제어(AGC), 잔향제거(Dereverberation) 지원
다양한 연결 방식 지원 : USB (ADB/AOA방식), Wi-Fi 방식 (단 동일 네트워크 연결 필요)
안드로이드 앱 (마이크 역할) + 데스크톱 서버 (수신 음성 신호를 PC쪽 가상 오디오로 처리되도록 하는 역할)
가상 마이크로 입력장치 인식 : VB-Cable(윈도우), BlackHole(macOS), PipeWire(리눅스) 등의 가상 오디오 라우팅 시스템 연동되도록 백엔드 로직이 작성되어 있음
플러그인 아키텍처 : 내부적으로 plugin-api 모듈 지원으로 개발자가 필요한 오디오 효과나 기능을 확장 용이하게 되어 있음
최신 UI 프레임워크 지원 : Jetpack Compose 및 Material 3 Expressive 스타일 도입
GPL-3.0 라이선스 지원

그림 : 안드로이드앱과 데스크톱 앱 화면 (출처 : MicYou 공식 github 저장소)

3.참고자료

코드) MicYou github 저장소 (링크)
문서) MicYou Quick Start (설치 및 사용방법) (링크)

사실 구글 플레이스토어에 들어가면 이렇게 스마트폰을 원격 마이크처럼 사용할 수 있도록 만들어주는 앱이 존재합니다. 예를 들면 'Remote Mic' 같은 것이 있죠. 방식은 'Phone(앱) -> WebStream 또는 Bluetooth 연동(PC)' 방식으로 유사한데, 무료 티어를 일부 제공하는 '유료' 서비스라는 측면이 다릅니다. 아주 중요한 부분이긴 하죠!

그림 : RemoteMic 구글 플레이 소개화면

Sprite Lab : 배경 제거 및 스프라이트시트 슬라이스 도구

42morrow — Mon, 8 Jun 2026 15:34:26 +0900

최근에 장난감 게임을 몇개 바이브코딩으로 만들어보고 있습니다. 그런데 이때 움직임을 표혀하는 부분에서 스프라이트 시트를 생성하고 여기서 이미지의 배경 제거와 슬라이스하는 작업이 필요하게 됩니다. 제 경우엔 슬라이스하는 코드를 만들고, 배경제거를 하는 코드를 이용하거나 removebg 무료 서비스를 이용했습니다.

그런데... 생성형 AI가 만들어 준 시트가 동일한 크기로 생성하라고 지시했음에도 불구하고 약간씩 차이가 나거나 배경 제거가 미흡하거나, 혹은 정렬이 제대로 되지 않거나 하는 문제가 생기는 겁니다.

그러던 중에 Splite Lab이라는 도구를 알게 됐습니다. 공개된 지 며칠되지 않는 따끈한 도구입니다. 아마도 개발하신 분도 저하고 똑같은 불편함을 겪고 해결책을 제시하신 것 같습니다. ^^

GitHub - boona13/sprite-lab

Contribute to boona13/sprite-lab development by creating an account on GitHub.

github.com

Sprite Lab 제공 기능

배경제거
스프라이트시트 슬라이스
스프라이트시트 기반 애니메이션 프리뷰

실제 사용 예

아래는 해당 도구를 설치해서 실행한 예시입니다.

원본은 흰색 배경의 스프라이트 시트 png 이미지입니다. 이미지는 세로는 동일한데 가로폭은 제각각 다릅니다.

그림 : 스프라이트시트 슬라이싱 및 배경 제거 예시

해당 이미지 파일을 불러오면, 자동으로 배경제거하고 개별적으로 슬라이스를 해 줍니다. (아주 잘 맞춰줍니다~) 그리고, 애니메이션에 사용할 프레임을 선택하면 지정한 프레임 레이트의 애니메이션 프리뷰가 보여집니다. (기본은 전부 선택이 된 상태로 보여짐)

슬라이스된 파일을 다운받으면 배경제거된 개별 이미지들이 zip 파일로 묶여 다운로드 됩니다. 배경 제거가 잘 되었는지 확인해보면 아주 깔끔하게 잘 된 것을 볼 수 있습니다. (뒷 배경은 테스트를 위해 일부러 색상을 넣은 것입니다)

한가지 아쉬운 것은 이왕이면 webp나 animated png 등의 파일도 생성해주면 더 좋을 것을 싶습니다. 너무 날로 먹으려는 걸까요? ^^;

Claude Code를 이용한 자동화 팁 관련 글 소개

42morrow — Sun, 7 Jun 2026 10:08:18 +0900

X에 'How to run Claude on autopilot in 14 steps: /loop, Routines, and the full automation stack.'라는 글이 게시되었습니다. Codez라는 분이 올린 글인데 Claude Code를 자동화 도구로 활용하는 팁을 정리한 것이라 다른 분들께도 도움이 될 것 같아 링크를 걸어 봅니다.

Codez (@0xCodez) on X

How to run Claude on autopilot in 14 steps: /loop, Routines, and the full automation stack.

x.com

내용을 요약해 보면

반복 작업을 먼저 /loop 를 이용해 실험해서,
이게 잘 작동하면 Desktop Scheduled Tasks를 이용하고,
장기적이고 안정적인 작업을 필요로 하면 Cloud Routines 으로 만들어 사용하도록 합니다.

단, 이때 유의해야 할 점으로는

반복 지침은 Skills로 정리하고
복잡한 작업은 Dynamic Workflows와 결합하며
권한은 Auto Mode, allow list, audit log로 통제합니다.

자동화를 도구로 활용하는 14단계 로드맵을 상세하게 설명하고 있고, 이를 이용한 실생활 적용 사례, Claude 자동화를 사용할 때 흔히 하는 실수들에 어떤 것들이 있고 어떻게 처리해야 하는지도 잘 설명되어 있습니다.

VideoCUPS : 라벨 없이 비디오 속 장면을 나누고 추적하는 AI 기술

42morrow — Sat, 6 Jun 2026 12:41:32 +0900

요즘 AI는 사진 한 장을 보고 '자동차다', '사람이다'라고 맞히는 수준을 넘어, 이제는 영상 속에서 무엇이 어디에 있는지, 그리고 그 대상이 다음 장면에서 어디로 움직였는지도 알아야 하는 것이 당연하게 여겨지고 있습니다. 예를 들어 자율주행차라면 앞에 있는 자동차, 길을 건너는 사람, 도로와 인도, 건물과 하늘을 모두 구분해야 하는 것처럼 말이죠. 사람에게는 자연스러운 일이지만 AI에게는 꽤 복잡한 일이라고 알려져 있고, 그러다보니 이에 대한 연구가 계속 이어져 왔습니다.

문제는 이런 AI를 학습시키려면 보통 사람이 직접 정답을 붙인 데이터가 많이 필요하다는 점입니다. 특히 비디오는 이미지보다 더 어렵습니다. 한 장면만 표시하면 끝나는 것이 아니라, 같은 사람이 다음 장면에서도 같은 사람인지 계속 이어서 표시해야 하기 때문이죠. 이런 부담을 줄이기 위해 제안된 것이 VideoCUPS라는 방법입니다. 사람의 라벨 없이도 비디오에서 깊이, 움직임, 시각적 특징을 활용해 임시 정답을 만들고, 이를 바탕으로 장면을 나누고 물체를 추적하는 방식입니다.

그림 : VideoCUPS 전체 결과와 처리 흐름

1) 기존 방식의 문제점

비디오 판옵틱 세그멘테이션은 조금 긴 이름이지만, 하는 일은 이렇게 이해하면 됩니다. 영상 속 모든 픽셀에 의미를 붙이고, 사람이나 자동차처럼 따로 구분해야 하는 물체는 시간에 따라 계속 따라가는 기술입니다. 즉 '무엇이 있는지', '어디에 있는지', '같은 물체가 다음 장면에서 어디로 갔는지'를 한 번에 처리합니다.

기존 방식은 대부분 사람이 만든 정답 데이터를 사용했는데, 이는 성능은 좋지만 준비 과정이 너무 오래 걸렸습니다. 도로 영상 하나를 생각해 보면, 자동차, 사람, 도로, 신호등, 건물 같은 것들을 픽셀 단위로 표시해야 하기 때문이죠. (국내에서도 이 방식의 데이터 라벨링 용역 프로젝트가 많았습니다) 그리고, 비디오는 장면이 이어지기 때문에 추적 정보까지 붙여야 합니다. 그래서 연구자들은 사람이 정답을 주지 않아도 AI가 스스로 배울 수 있는 방법을 찾고 있습니다.

2) 접근 방식

VideoCUPS는 '비슷하게 움직이고, 비슷한 거리에 있는 부분은 같은 물체일 가능성이 높다'는 생각에서 시작되었습니다. 예를 들어 길을 걷는 사람의 팔과 다리는 모양이 계속 바뀌지만, 전체적으로는 함께 움직입니다. 자동차도 마찬가지죠. 그러니 영상 속에서 같이 움직이는 픽셀들을 잘 묶으면 물체 후보를 만들 수 있습니다.

이 논문은 여기에 다음의 세 가지 단서를 함께 사용합니다.

움직임 : 픽셀이 어느 방향으로 움직였는지를 봅니다.
깊이 : 카메라에서 얼마나 가까운지 또는 먼지를 추정합니다.
시각 특징 : 색, 형태, 패턴처럼 이미지 안에 담긴 정보를 활용합니다.

이 단서들을 합쳐 사람이 만든 정답 대신 의사라벨(Pseudo label)을 만듭니다. 의사 라벨은 AI가 스스로 만든 임시 정답이라고 보면 됩니다.

3) 모델/기술 아키텍처

그림 : VideoCUPS 의사 라벨 생성 과정

위의 그림에는 VideoCUPS의 흐름이 잘 정리되어 있습니다.

우선 입력 비디오가 들어오면 먼저 두 갈래로 나뉩니다.
- 한쪽에서는 깊이와 움직임을 보고 물체 후보를 찾습니다.
- 다른 한쪽에서는 영상의 시각적 특징을 보고 도로, 건물, 하늘 같은 의미 영역을 나눕니다.
그 다음에는 이 정보를 시간 방향으로 연결합니다. 한 프레임에서 찾은 자동차가 다음 프레임에서도 같은 자동차인지 확인하고, 의미 라벨도 프레임마다 흔들리지 않도록 부드럽게 정리합니다.
마지막으로 물체 정보와 의미 정보를 합쳐 비디오 전체에 대한 판옵틱(Pan-Optic) 의사 라벨을 만듭니다.
이렇게 만들어진 의사 라벨을 이용해 최종 비디오 분할 모델을 학습합니다.

4) 세부 적용 기술

1️⃣ 의사 라벨 생성

VideoCUPS는 사람이 직접 만든 정답 없이 학습해야 합니다. 그래서 먼저 AI가 사용할 수 있는 임시 정답을 만듭니다. 이를 의사 라벨이라고 합니다. 완벽한 정답은 아니지만, 학습을 시작하기에는 충분한 힌트가 됩니다. 이 논문에서는 물체 후보 라벨과 의미 라벨을 따로 만든 뒤, 둘을 합쳐 비디오용 판옵틱 의사 라벨로 정리합니다.

2️⃣ 움직임과 깊이로 물체 찾기

영상에서 어떤 픽셀들이 함께 움직이고, 깊이도 비슷하다면 같은 물체일 가능성이 큽니다. VideoCUPS는 이런 픽셀들을 조금씩 넓혀 가며 하나의 물체 후보로 묶습니다. 쉽게 말해 '가까이 있고 비슷하게 움직이는 부분끼리 모으는 방식'입니다. 이 방법은 자동차처럼 딱딱한 물체뿐 아니라, 걷는 사람처럼 모양이 계속 변하는 물체에도 어느 정도 대응할 수 있습니다.

3️⃣ 의미 라벨 만들기

물체를 찾는 것만으로는 부족합니다. 도로인지, 하늘인지, 건물인지도 알아야 합니다. VideoCUPS는 DINO라는 자기지도 비전 모델의 특징을 사용합니다. 자기지도 학습은 사람이 정답을 주지 않아도 데이터 안의 패턴을 이용해 학습하는 방식입니다. 여기에 k-means라는 군집화 방법을 적용해 비슷한 특징을 가진 픽셀들을 같은 의미 그룹으로 묶습니다.

4️⃣ 시간 방향 추적

비디오는 시간이 흐르기 때문에 같은 물체를 계속 같은 물체로 알아봐야 합니다. VideoCUPS는 이전 프레임과 다음 프레임 사이에서 마스크가 얼마나 겹치는지 확인합니다. 많이 겹치면 같은 물체로 연결합니다. 여기서 IoU라는 기준을 씁니다. IoU는 두 영역이 얼마나 겹치는지 보는 값입니다. 여러 후보를 가장 알맞게 연결할 때는 헝가리안 매칭이라는 짝짓기 방법을 사용합니다.

5️⃣ Video DropLoss

의사 라벨은 사람이 만든 정답이 아니기 때문에 빠지는 물체가 있을 수 있습니다. 그래서 VideoCUPS는 모든 예측을 억지로 정답에 맞추지 않습니다. 의사 라벨과 충분히 겹치는 예측만 학습에 강하게 반영합니다. 반대로 라벨에 없는 물체를 모델이 찾았을 때는 바로 틀렸다고 보지 않습니다. 덕분에 정지한 자동차처럼 의사 라벨에 잘 잡히지 않는 대상도 나중에 배울 여지가 생깁니다.

6️⃣ 자기강화 비디오 Copy-Paste

작은 물체는 영상에서 쉽게 놓칩니다. 그래서 VideoCUPS는 모델이 자신 있게 찾은 물체를 다른 비디오 클립에 붙여 넣는 방식으로 학습 데이터를 늘립니다. 단순히 복사해서 붙이는 것이 아니라 크기나 방향을 바꾸고, 움직이는 경로도 다르게 넣습니다. 이렇게 하면 모델이 작은 물체와 다양한 움직임을 더 자주 보게 됩니다.

7️⃣ 실험 결과 요약

논문에서는 Cityscapes-VPS, KITTI-STEP, Waymo, MOTS 데이터셋에서 실험했습니다. VideoCUPS는 비교 대상으로 만든 여러 비지도 방식보다 전반적으로 더 좋은 성능을 보였습니다. 특히 Cityscapes-VPS에서는 STQ 22.2를 기록해 기존 기준선보다 높았습니다. 또 라벨을 조금만 사용해 추가 학습했을 때도 좋은 출발점이 되었습니다. 즉 완전히 라벨이 없는 상황뿐 아니라, 라벨이 적은 상황에서도 쓸모가 있었다는 뜻입니다.

5) 제약사항

VideoCUPS는 움직임을 중요한 단서로 사용합니다. 그래서 거의 움직이지 않는, 혹은 정지한 물체는 찾기 어려울 수 있습니다.
깊이 추정이 항상 정확한 것은 아닙니다. 단안 비디오, 즉 카메라 하나로 찍은 영상만 사용하기 때문에 거리 정보를 완벽하게 알기는 어렵습니다.
카메라 환경이 바뀌거나 장면이 복잡해지면 성능이 흔들릴 수 있습니다.
물체가 심하게 가려지는 상황에서는 같은 물체를 계속 추적하는 것도 어려울 수 있습니다.

VideoCUPS는 비디오 장면 이해에서 사람이 픽셀 단위로 정답을 붙이지 않아도, 영상 안의 움직임과 깊이, 시각 특징을 활용하면 어느 정도 장면을 나누고 물체를 추적할 수 있다는 것을 보여줍니다.

이 기술은 자율주행, 로봇, 영상 편집 같은 분야에 도움이 될 수 있을 겁니다. 예를 들어 로봇이 주변 사람과 물체를 구분하거나, 영상 편집 도구가 특정 대상을 자동으로 따라가는 곳 등등에서 말이죠. 아직 정지 물체나 복잡한 가려짐 처리 등의 문제가 남아 있지만, 이 부분이 개선된다면 적은 라벨로도 꽤 안정적인 비디오 이해 모델을 만들 수 있을 것입니다.

참고자료

사이트) VideoCUPS 프로젝트 사이트 (링크)
논문) Scene-Centric Unsupervised Video Panoptic Segmentation (링크)
코드) VideoCUPS github 저장소 (링크) - Apache 2.0 라이선스를 따릅니다.

Q&A

Q.VideoCUPS는 무엇을 하는 기술인가요?

비디오 속에서 사람, 자동차, 도로, 건물 같은 영역을 나누고, 움직이는 물체를 시간에 따라 추적하는 기술입니다. 중요한 점은 사람이 만든 정답 라벨 없이도 학습을 시도한다는 것입니다.

Q.왜 움직임과 깊이를 같이 보나요?

비슷한 거리에서 비슷하게 움직이는 부분은 같은 물체일 가능성이 높기 때문입니다. VideoCUPS는 이 단서를 이용해 물체 후보를 만듭니다.

Q.VideoCUPS의 한계는 무엇인가요?

움직임을 많이 활용하기 때문에 정지한 물체는 놓칠 수 있습니다. 또 카메라 하나로 깊이를 추정하기 때문에 장면이 복잡하거나 환경이 바뀌면 성능이 떨어질 수 있습니다.

[바이브코딩] AI로 명상/수면을 위한 사운드 생성해 보기

42morrow — Sat, 30 May 2026 15:09:39 +0900

명상/수면 음악 생성기를 만들어 봤습니다. 꼭 필요해서라기보다는 가능한가 확인해보고 싶은 차원이랄까요. 그래서, 글 내용을 보면 아시겠지만 대충 시도해 보는 수준으로만 접근했습니다. ^^; 오늘은 그 과정을 정리해 봤습니다.

한 때 잠이 안 올 때면 유튜브에서 수면음악 영상을 찾아서 틀어놓고 자곤 했었습니다. 차분하고 조용한 음악을 듣다보면 어느새 잠이 드는데, 문제는 다음 날 아침에 깼을 때까지 계속 그 음악이 흘러나오고 있다는 것이었죠. 저는 잠이 들었지만 제 폰은 밤샘 작업을 하고 있었던 겁니다. 충전 케이블을 연결한 상태이니 다행이지 그렇지 않았다면 둘 다 진즉에 뻗었겠죠. ^^;

이미 유튜브에 그런 영상이 많이 있는 것 같던데?

그렇습니다. Youtube에서 자주 검색되는 한 수면음악의 경우, 놀라운 기록을 가지고 있습니다! 국내에서 올린 영상 같은데 10시간 짜리 영상인데 뷰가 1.2억 뷰. 무슨 유명 연예인의 뮤직비디오 영상도 아닌데 이렇게 높은 시청수를 가진다는 것은 그만큼 우리 주변에도 잠 못 자는 사람들이 많다는 걸 의미하는 것 같습니다. 게다가 그 기회를 아주 잘 잡은 누군가가 있다는 것이기도 하죠.

그림 : 유튜브 '수면음악' 검색 시 보이는 영상 예시

어떤 것을 만들어 볼 건가?

명상/수면 음악 생성기를 통해 구현하려고 하는 것은 주제에 맞는, 원하는 길이의 사운드를 실시간으로 만들고 이를 향유할 수 있도록 하는 것입니다. 하지만, AI 기술의 테스트 목적이 우선이라 정식 서비스를 목표로 하는 것은 아닙니다.

작업 과정은 ?

생성기 제작을 위해 다음과 같이 진행합니다.

Audio 생성 AI 모델 조사/확정 : AI 모델 가운데 주어진 프롬프트에 따라 사운드를 생성해 주는 것이 있는지 찾아보고, 최종 확정합니다.
프롬프트 생성 및 실행 검증 : 각 쟝르 별로 생성 프롬프트를 생성해서 제대로 만들어지는지 확인합니다.
실시간 프롬프트 생성 방식 검토 : 동적으로 사용자가 제시한 주제에 맞는 프롬프트를 실시간으로 생성하고 이를 이용해 사운드를 생성합니다.
코드 개발

1. Audio 생성 AI 모델 조사/확정

목적하는 방식에 적합한 AI 모델이 어떤 것이 있을지 ChatGPT에게 조사 시켰습니다. 대략 다음과 같이 나오는데, 한둘은 예전 글에서도 소개한 적이 있었습니다.

모델	특징	라이선스
Stable Audio Open 1.0	기능 : 44.1kHz 스테레오, 최대 47초 생성. 현실적인 효과음, field recording, ambient soundscape에 적합함	Stability AI Community License. 일정 조건의 상업 사용 가능 범위가 있음
TangoFlux	44.1kHz 스테레오, 최대 30초 생성. A40 기준 약 3.7초로 빠른 편이라 여러 seed를 돌려 좋은 자연음을 고르기 좋음	체크포인트는 비상업 연구용으로 명시
AudioLDM 2	텍스트 프롬프트로 sound effect, speech, music을 만들 수 있고 Diffusers에서 바로 사용 가능음	CC-BY-NC-SA 4.0 계열, 비상업 조건
AudioCraft / AudioGen	Meta의 text-to-sound 모델. 환경음·효과음 쪽에 적합하지만 짧은 사운드 생성 중. AudioCraft는 AudioGen과 MusicGen을 포함함.	코드는 MIT, 모델 가중치는 CC-BY-NC 4.0

사용할 모델의 선택에는 다음과 같은 조건을 적용했습니다.

생성할 수 있는 오디오의 길이가 너무 짧지 않아야 한다.
반복이나 붙이기, 루핑 등을 통해 최소 십수분 정도로 확장을 해야 하므로 너무 짧은 사운드를 만드는 것은 적절하지 않다고 생각했습니다.
라이선스가 상용 사용을 막지 않아야 한다.
생성된 사운드를 이용해 영상을 만들고 유튜브 등에 배포를 했을 때 문제가 없어야 한다고 생각했습니다. 물론 당장 그럴 생각은 없지만 활용을 어떻게 할지는 향후에도 언제든 바뀔 수 있기 때문이죠.

최종 선택지는 Stable Audio Open 1.0 입니다. 다른 것들에 비해 생성 길이가 길고, 라이선스도 현 상황에서는 요구사항에 부합했습니다. (Enterprise License를 구매 해야하는 '조건'(매출 규모, 시청수 등)이라는 것이 저하고는 아주 거리가 먼 수준이라 문제가 되진 않아보였습니다)

2. 프롬프트 생성 및 실행 검증

3개의 장르만 생성해서 진행합니다. (수면 음악에 많이 사용되는 장르라고 하더군요)

Ambient Drift : A slowly evolving dark ambient drone creates a peaceful sleep atmosphere with warm reverberant synthesizer pads and spacious hall reverb. Gentle sustained tones with soft harmonic overtones form a meditative soundscape through slow modulation and deep reverb. A warm analog synthesizer drone gradually shifts in tonal color, creating an ethereal ambient atmosphere for sleep induction. Soft evolving ambient pads with long attack and release create a tranquil, continuous sound with subtle frequency movement and no rhythm.
Rain & Nature Sleep : Steady gentle rainfall falls on a forest canopy at night, with soft raindrops hitting leaves and a very subtle distant stream in the background. ight rain falls peacefully on window glass, accompanied by occasional quiet drips and a cozy indoor ambience. A forest stream flows gently over rocks while soft rain falls on the tree canopy, creating a calm natural nighttime recording. Soft coastal drizzle blends with distant gentle ocean waves and light wind moving through coastal grass, forming a calming natural soundscape.
Delta Wave Sleep : A deep low oscillating sine wave drone with slow 2Hz pulse modulation creates a dark meditative low-frequency sleep sound. A very slow evolving deep bass drone with a 1Hz rhythmic swell creates a hypnotic low-frequency texture for deep sleep. Layered sub-bass harmonic drones with slow 0.5Hz beating frequencies create a resonant meditative sleep atmosphere.A dark low-frequency pad slowly pulses at 2Hz with warm bass overtones, supporting deep relaxation and sleep.

3. 실시간 프롬프트 생성 방식 검토

AI 모델의 유료 API를 이용할 계획은 없으니, Ollama에서 제공되는 모델을 이용하기로 했습니다. 현재 Gemma4가 셋팅되어 있고, 이를 이용해 사용자가 제시하는 주제에 맞는 프롬프트를 생성해 주는 구조를 구현하면 될 것 같았습니다.

4. 코드 개발

1️⃣ 적용 기술

이 프로그램은 AI 기반 수면음악 생성 웹앱이고, 크게 보면 웹 UI → 프롬프트 입력/생성 → Stable Audio로 음원 생성 → 후처리 → WAV 저장/재생의 흐름으로 구성되어 있습니다.

영역	사용 기술	역할
웹 UI	Gradio	브라우저에서 장르, 길이, 볼륨, 리듬감, 프롬프트를 조절하고 음원을 생성/재생/다운로드
AI 음원 생성	diffusers, StableAudioPipeline	Stability AI의 stable-audio-open-1.0 모델을 사용해 텍스트 프롬프트에서 오디오 생성
GPU 연산	PyTorch, CUDA	Stable Audio 모델을 float16으로 CUDA GPU에서 실행
프롬프트 자동 생성	Ollama API, requests	로컬 Ollama 모델에 요청해 Stable Audio용 영어 프롬프트 자동 생성
오디오 처리	NumPy	RMS 정규화, 크로스페이드, 루프 처리, 리듬 레이어 생성, 안정 구간 분석
오디오 저장	soundfile	생성된 오디오를 WAV 파일로 저장
파일/실행 환경	pathlib, os, socket	출력 폴더 관리, 포트 자동 선택, 실행 환경 설정

2️⃣ 생성 음악 후처리

사운드가 생성된 이후 다음과 같은 음 후처리를 적용합니다.

갑작스러운 큰 소리 제거
음량 피크 정리
너무 날카로운 고역 줄이기
저역 웅웅거림 제거
루프 경계 크로스페이드
10분~1시간 길이로 확장

3️⃣ 구현 결과물 테스트

만들어진 도구의 UI는 다음과 같습니다. 최종적으로 개발된 코드는 Gradio 웹 인터페이스 + Stable Audio 생성 모델 + Ollama 프롬프트 보조 + NumPy 기반 오디오 후처리가 결합된 것입니다. UI 측면은 기능 테스트 용으로만 만들다 보니 다듬어지진 않았습니다.

이 도구를 이용해 2분짜리로 만들었는데 흠... 너무 밋밋한 느낌이 들었습니다. 언급한 자연의 소리가 들리긴 하고, 약간은 기존 다른 수면음악과 유사한 느낌이 나긴 하지만 그냥 그것일 뿐. 앞서 소개했던 1.2억뷰 영상에서 소개되는 것에는 저만치 차이가 있더군요. 그래서, 이곳에 올리지 않았습니다. 제대로 하려면 좀 더 다양한 요소들을 추가하도록 프롬프트를 아주 많이 다듬어야 할 것 같습니다.

PAVAS : 물리 법칙을 반영하는 비디오 음향 생성 AI 모델

42morrow — Fri, 29 May 2026 15:41:00 +0900

최근 나오는 생성형 AI는 이미지를 만들고, 영상을 편집하고, 음악까지 만들어 냅니다. 그런데 영상에 맞는 소리를 만드는 일은 생각보다 어렵습니다. 공이 바닥에 튀는 장면을 보면 우리는 자연스럽게 ‘통통’ 하는 짧은 소리를 기대합니다. 망치가 금속을 치면 더 날카롭고 강한 소리가 나야 합니다. 사람은 이런 차이를 쉽게 느끼지만, AI는 장면의 겉모습만 보고 비슷한 소리를 붙이는 데 그치는 경우가 많습니다.

산업적으로도 이 문제는 중요합니다. 영상 작업 후 녹음, 게임 효과음, AR/VR 콘텐츠, 로봇 시뮬레이션에서는 영상과 소리가 시간 싱크만 맞아서는 부족합니다. 물체가 무거운지, 빠르게 움직였는지, 충돌이 강했는지에 따라 소리의 크기와 울림도 달라져야 합니다. PAVAS는 영상 속 물체의 질량과 속도를 추정하고, 그 물리 정보를 소리 생성 모델에 넣어 더 그럴듯한 효과음을 만들도록 설계된 방법으로, 기존 V2A 모델이 주로 겉모습 중심으로 소리를 만드는 것에 집중한 것에 반해, 물리적 단서까지 함께 사용한다는 점이 핵심입니다.

1) 기존 방식의 문제점

기존 Video-to-Audio, 즉 V2A 모델은 영상에 맞는 소리를 생성하는 기술입니다. 예를 들어 사람이 말하는 장면에는 말소리를, 공이 튀는 장면에는 튀는 소리를 붙이는 식입니다. 최근 모델들은 영상과 소리의 시간 동기화, 장면 의미 맞추기에서는 좋은 성과를 보였습니다.

하지만 기존 모델들이 겉모습 중심이라는 것이 문제로 지적됩니다. 망치질 장면을 보고 금속성 소리를 만들 수는 있지만, 망치가 얼마나 빠르게 움직였는지, 물체가 얼마나 무거운지에 따라 소리의 크기나 날카로움이 달라져야 한다는 점은 충분히 반영하지 못하기 때문이죠. 논문에서는 이를 '물리적 접지 부족'으로 설명합니다. 쉽게 말해, 소리가 화면과 의미상 맞아도 물리적으로는 어색할 수 있다는 뜻입니다.

2) 접근 방식

PAVAS의 접근은 단순합니다. 영상에서 '무엇이 움직이는지'를 찾고, 그 물체의 질량과 속도를 추정한 뒤, 이 정보를 소리 생성 모델에 넣습니다. 예를 들어 농구공이 천천히 튀는 장면과 빠르게 바닥에 부딪히는 장면은 같은 농구공 소리라도 강도가 달라야 합니다. PAVAS는 이런 차이를 반영하려고 합니다.

이 논문은 두 가지 핵심 모듈을 사용합니다.

PPE (Physics Parameter Estimator) : 이는 영상에서 움직이는 물체를 찾고 질량과 속도를 추정합니다.
Phy-Adapter : 이는 추정된 물리 정보를 확산 기반 오디오 생성 모델에 안정적으로 넣는 역할을 합니다.

논문은 이 방식이 물리적인 그럴듯함과 청각적인 품질을 함께 개선한다고 보고합니다.

3) 모델/기술 아키텍처

그림 : PAVAS 개념도

PAVAS의 전체 구조는 '영상 입력 → 물리 정보 추정 → 물리 조건 주입 → 오디오 생성' 흐름입니다.

먼저 영상이 들어오면 PPE가 움직이는 물체를 찾습니다. 이때 VLM, 분할 모델, 동적 3D 복원 모델을 함께 사용합니다.
- VLM은 영상과 언어를 함께 이해하는 모델입니다. 예를 들어 ‘공이 튀고 있다’, ‘망치가 못을 치고 있다’처럼 물체와 동작을 파악합니다.
- 분할 모델은 영상에서 해당 물체의 영역을 잘라내고, 동적 3D 복원은 물체가 공간에서 어떻게 움직였는지 추정합니다. 이를 통해 속도를 계산합니다.
그 다음으로 Phy-Adapter가 질량과 속도를 모델이 이해할 수 있는 벡터 형태로 바꿉니다. 이 정보는 비디오, 텍스트, 오디오 조건과 함께 확산 트랜스포머에 들어갑니다.

그림 : PAVAS 전체 파이프라인

4) 세부 적용 기술

PPE, 물리 파라미터 추정기 :
PPE는 영상 속에서 실제로 움직이는 물체를 찾고, 그 물체의 질량과 속도를 추정합니다. 단순히 화면에서 위치가 바뀐 것만 보는 것이 아니라, 카메라 흔들림 때문에 움직이는 것처럼 보이는 경우는 제외하려고 합니다. 이 단계가 중요한 이유는 소리의 세기와 길이가 물체의 움직임과 관련이 크기 때문입니다.
VLM 기반 질량 추정 :
질량은 영상만 보고 정확히 알기 어렵습니다. 그래서 PAVAS는 VLM을 사용합니다. VLM은 물체의 종류, 크기, 재질, 동작 맥락을 보고 '농구공은 약 0.6kg 정도', '자전거는 약 9kg 정도'처럼 추정합니다. 완벽한 측정은 아니지만, 소리 생성에 사용할 수 있는 현실적인 단서를 제공합니다.
분할과 3D 복원을 이용한 속도 추정 :
속도는 물체가 프레임 사이에서 얼마나 이동했는지로 계산합니다. 먼저 분할 모델이 물체 영역을 찾고, 동적 3D 복원 모델이 그 영역을 3차원 공간의 점들로 바꿉니다. 그다음 물체의 중심점이 시간에 따라 얼마나 이동했는지 계산해 속도를 얻습니다. 쉽게 말해, 영상 속 물체의 ‘3D 이동 거리’를 재고 초당 이동량으로 바꾸는 방식입니다.
Phy-Adapter :
Phy-Adapter는 질량과 속도를 오디오 생성 모델이 사용할 수 있는 조건으로 바꿉니다. 질량은 대체로 시간에 따라 변하지 않으므로 소리의 전체적인 크기나 울림에 영향을 줍니다. 속도는 프레임마다 달라지므로 충돌 순간의 강도, 짧은 타격음, 날카로운 소리 변화에 영향을 줍니다.
FiLM과 ∆-modulation :
FiLM은 어떤 조건에 따라 특징을 키우거나 줄이는 방식입니다. 여기서는 질량과 속도 정보를 이용해 영상 특징을 조절합니다. ∆-modulation은 물리 조건을 바로 더하지 않고, 기존 조건에 작은 보정값처럼 더합니다. 그래서 모델이 갑자기 흔들리지 않고, 학습하면서 점진적으로 물리 정보를 반영할 수 있습니다.
APCC와 VGG-Impact :
논문은 물리적으로 그럴듯한 소리인지 평가하기 위해 VGG-Impact와 APCC를 제안합니다. VGG-Impact는 농구공 바운스, 망치질, 장작 패기처럼 충돌이 중요한 장면을 모은 평가 세트입니다. APCC는 운동 에너지 변화와 소리의 충격 강도가 얼마나 함께 변하는지 보는 지표입니다. 값이 실제 데이터와 가까울수록 물리적으로 더 자연스럽다고 볼 수 있습니다.

그림 : 생성 스펙트로그램 정성 비교

5) 제약사항

PAVAS는 여러 사전학습 비전 모듈을 사용하며 특히 동적 3D 복원 과정이 계산 비용을 크게 차지합니다. 논문에서도 현재 파이프라인이 실시간 동작을 목표로 한 것은 아니라고 설명합니다.
물체가 가려지거나 빠르게 움직이면 질량·속도 추정이 어려워질 수 있습니다. 다만 PAVAS는 이런 경우를 대비해 occlusion token을 사용합니다. 이는 물체나 속도 정보가 빠진 순간에 넣는 대체 신호입니다. 덕분에 물리 정보가 일부 없어도 모델이 갑자기 실패하지 않고 기본 V2A 생성 경로로 돌아갈 수 있습니다.
PAVAS는 질량과 속도에 초점을 둡니다. 실제 소리는 재질, 표면 상태, 공간 반향, 물체의 탄성 같은 요소에도 영향을 받습니다.

PAVAS가 가지는 의의는 V2A 생성이 단순히 영상에 맞는 소리를 만드는 단계에서 물리적으로 납득되는 소리를 만드는 단계로 이동했다는 점입니다. 기존 모델은 장면의 의미와 시간은 잘 맞출 수 있었지만, 충돌 강도나 물체의 무게감까지 자연스럽게 반영하는 데 한계가 있었습니다. PAVAS는 질량과 속도라는 비교적 직관적인 물리 정보를 넣어 이 문제를 해결하려 했습니다. 즉, 물리 추론과 오디오 생성을 연결했다고 할 수 있죠.

앞으로는 비디오를 기준으로 좀 더 자연스런 사운드를 손쉽게 만들 수 있게 될 것이고 이를 활용한 다양한 사례가 낭로 수 있을 것으로 생각됩니다.

참고자료

사이트) PAVAS 프로젝트 (링크)
논문) PAVAS: Physics-Aware Video-to-Audio Synthesis (링크)

참고로, 본 연구는 포스텍, SONY, 카이스트 연구진이 함께 진행한 것입니다. 아직 코드는 공개되어 있지 않습니다.

Q&A

Q. PAVAS가 기존 Video-to-Audio 모델과 가장 다른 점은 무엇인가?

기존 모델은 주로 영상의 겉모습과 장면 의미를 보고 소리를 생성했습니다. PAVAS는 여기에 물체의 질량과 속도를 추가로 반영합니다. 그래서 같은 충돌 장면이라도 더 무겁고 빠른 물체라면 더 강한 소리가 나도록 유도합니다.

Q. 질량과 속도는 왜 소리 생성에 중요한가?

소리는 물체가 부딪히거나 움직일 때 생기는 에너지 변화와 관련이 있습니다. 무거운 물체가 빠르게 부딪히면 더 큰 충격음이 날 가능성이 큽니다. PAVAS는 이런 물리적 차이를 오디오 생성 과정에 넣어 소리의 크기, 짧은 타격감, 울림을 더 자연스럽게 만들려고 합니다.

Q. PAVAS는 모든 영상에서 완벽하게 작동하는가?

아닙니다. 물체가 가려지거나 움직임이 너무 빠르거나 3D 복원이 어려운 장면에서는 물리 정보 추정이 흔들릴 수 있습니다. 다만 논문은 occlusion token을 사용해 정보가 부족한 상황에서도 모델이 갑자기 실패하지 않도록 설계했습니다.

PiD : 픽셀 확산으로 더 빠르게 만드는 고해상도 이미지 디코딩 기술

42morrow — Thu, 28 May 2026 16:04:56 +0900

이미지 생성 AI는 겉으로 보면 문장을 넣고 이미지를 받는 단순한 도구처럼 보입니다. 하지만 내부에서는 먼저 작고 압축된 공간에서 이미지를 설계한 뒤, 마지막에 다시 사람이 볼 수 있는 픽셀 이미지로 바꾸는 과정을 거칩니다. 이 마지막 변환 과정이 생각보다 중요합니다. 아무리 좋은 구도를 만들었어도, 디코더가 세부 질감이나 작은 글자, 머리카락 같은 부분을 잘 복원하지 못하면 결과물은 흐릿해질 수 있습니다.

최근 생성 AI 산업은 더 큰 해상도와 더 짧은 생성 시간을 동시에 요구받고 있습니다. 광고 이미지, 제품 컷, 영화 콘셉트 아트, 게임 배경처럼 실제 작업에 쓰려면 2K나 4K 수준의 선명도가 필요하죠. 이번 논문은 기존 방식처럼 낮은 해상도로 먼저 복원하고, 다시 업스케일러로 키우는 여러 단계를 거치는 과정을 하나로 합쳐, 더 빠르고 선명하게 이미지를 만드는 방법을 제안합니다. 핵심은 '잠재공간을 바로 고해상도 픽셀로 디코딩'한다는 생각입니다.

1) 기존 방식의 문제점

기존 고해상도 이미지 생성 파이프라인은 보통 두 단계를 거칩니다. 먼저 VAE 디코더가 잠재표현을 낮은 해상도 이미지로 바꾸고, 그다음 초해상도 모델이 이미지를 크게 키웁니다. 그러다보니 다음과 같은 문제가 발생합니다.

VAE 디코더가 '새로운 디테일을 그리는 모델'이라기보다 '압축된 정보를 복원하는 모델'에 가깝기 때문에 작은 글자, 피부 질감, 나뭇잎, 머리카락 같은 고주파 디테일이 약해질 수 있습니다.
낮은 해상도 디코딩, 초해상도 확산 모델, 다시 고해상도 디코딩 같은 단계가 이어지면 시간이 늘고 메모리도 많이 쓰게 되어 작업 비용이 증가됩니다.

논문에서는 이런 문제 때문에 다단계 방식 대신, 잠재표현에서 바로 고해상도 픽셀 이미지를 생성하는 PiD를 제안합니다. PiD는 512×512에 해당하는 잠재표현을 2048×2048 이미지로 1초 이내에 디코딩하고, GB200 GPU에서는 약 210ms까지 줄였다고 보고합니다.

2) 접근 방식

PiD는 'Pixel diffusion Decoder'의 약자입니다. 말 그대로 픽셀 공간에서 작동하는 확산 디코더입니다. 기존 디코더처럼 잠재표현을 단순히 복원하지 않고, 잠재표현을 조건으로 삼아 고해상도 이미지를 직접 생성합니다. 여기서 잠재표현은 전체 구도와 의미를 알려주는 설계도 역할을 하고, 픽셀 확산 모델은 표면 질감과 세부 묘사를 채우는 화가 역할을 합니다.

그림 : PiD의 전체 아이디어 (상) 및 성능/속도 비교 (하)

이 방식의 핵심은 디코딩과 업스케일링을 분리하지 않는 것입니다. PiD는 4배 또는 8배 확대 결과를 하나의 생성 과정에서 만듭니다. 또한 노이즈가 조금 남아 있는 잠재표현도 처리할 수 있게 훈련되어, 원래의 잠재 확산 모델을 끝까지 돌리지 않고 중간에 멈춘 뒤 PiD가 나머지를 고해상도 이미지로 완성할 수 있습니다.

3) 모델/기술 아키텍처

PiD의 큰 구조는 세 부분으로 볼 수 있습니다.

고해상도 픽셀 이미지를 직접 다루는 PixelDiT 기반 확산 모델입니다.
낮은 해상도의 잠재표현을 모델 내부 토큰 형태로 바꿔 넣어주는 경량 어댑터입니다.
잠재표현이 얼마나 깨끗한지에 따라 참고 강도를 조절하는 sigma-aware gate입니다.

그림 : 모델 아키텍처

위의 아키텍처에서 보면, PiD는 '흐릿한 고해상도 캔버스'와 '작은 설계도'(잠재표현정보)를 동시에 봅니다. 캔버스는 점점 노이즈가 제거되며 이미지가 되고, 설계도는 인물 위치, 사물 형태, 장면 의미를 알려줍니다. sigma-aware gate는 '이 설계도를 얼마나 믿을지'를 조절합니다. 그래서 완전히 깨끗한 잠재표현뿐 아니라, 아직 일부 노이즈가 남은 중간 잠재표현도 처리할 수 있습니다.

4) 세부 적용 기술

1️⃣ 조건부 픽셀 확산 디코딩

PiD는 잠재표현을 바로 고해상도 픽셀 이미지로 바꿉니다. 기존 방식은 '잠재표현 → 저해상도 이미지 → 초해상도 이미지' 순서였지만, PiD는 '잠재표현 → 고해상도 이미지'로 바로 갑니다. 조건부라는 말은 모델이 텍스트와 잠재표현을 참고해 이미지를 만든다는 뜻입니다.

2️⃣ PixelDiT 기반 고해상도 픽셀 생성 prior

prior는 모델이 이미 학습해 둔 '그럴듯한 이미지에 대한 감각'을 의미합니다. PiD는 PixelDiT라는 픽셀 공간 확산 트랜스포머를 기반으로 사용합니다. 덕분에 단순 복원보다 더 자연스러운 질감, 선명한 경계, 작은 패턴을 만들 수 있습니다.

3️⃣ Noisy latent conditioning

훈련 중 PiD는 깨끗한 잠재표현만 보지 않으며 일부러 노이즈가 섞인 잠재표현도 보여줍니다. 이렇게 하면 모델이 잠재표현을 너무 맹신하지 않고, 부족한 세부 정보를 스스로 생성하는 능력을 갖게 됩니다. 또 실제 추론 때 잠재 확산 모델을 중간에 멈춰도 PiD가 그 상태를 받아 처리할 수 있습니다.

4️⃣ Sigma-aware gate

sigma는 노이즈의 양을 뜻합니다. sigma-aware gate는 잠재표현에 노이즈가 많으면 적게 믿고, 깨끗하면 더 많이 믿도록 조절하는 장치입니다. 초보자에게 비유하면, 흐릿한 지도는 참고만 하고, 선명한 지도는 더 믿는 방식입니다.

5️⃣ Latent projection and injection

낮은 해상도의 잠재표현은 그대로 PixelDiT에 넣을 수 없습니다. 그래서 PiD는 잠재표현을 크기에 맞게 조정하고, 합성곱 블록으로 특징을 뽑은 뒤, 트랜스포머가 읽을 수 있는 토큰으로 바꿉니다. 그런 다음 여러 DiT 블록 사이에 이 정보를 주입합니다. 쉽게 말해, 작은 설계도를 모델 내부의 여러 작업 단계에 나눠 전달하는 방식입니다.

그림 : 잠재표현 조건 삽입

6️⃣ Rectified Flow 학습

Rectified Flow는 노이즈 이미지를 깨끗한 이미지로 바꾸는 방향을 학습하는 방법입니다. 확산 모델이 여러 번 조금씩 노이즈를 줄이는 것과 비슷하지만, 여기서는 '어느 방향으로 이동하면 깨끗한 이미지에 가까워지는지'를 예측합니다. PiD는 이 방식으로 고해상도 픽셀 공간의 변화 방향을 배웁니다.

7️⃣ DMD2 기반 4-step distillation

PiD는 처음에는 여러 단계로 동작하는 teacher 모델을 학습한 뒤, DMD2로 4단계 student 모델로 줄입니다. distillation은 큰 모델이나 느린 과정을 작은 모델 또는 빠른 과정으로 압축하는 기술이라고 생각하시면 됩니다.

그림 : DMD2 증류 과정 설명

8️⃣ LDM early termination

기존 잠재 확산 모델은 모든 denoising step을 끝까지 수행합니다. PiD는 중간 단계의 잠재표현도 받을 수 있기 때문에, 기본 LDM을 조금 일찍 멈출 수 있습니다. 이렇게 하면 전체 생성 시간이 줄어듭니다. 다만 너무 일찍 멈추면 장면 구조가 덜 잡혀 품질이 떨어질 수 있습니다.

9️⃣ VAE latent와 RAE semantic latent 모두 지원

PiD는 FLUX, SD3 같은 VAE 잠재표현뿐 아니라 DINOv2, SigLIP 기반 RAE 잠재표현에도 적용됩니다. RAE 계열은 의미 정보는 강하지만 세부 질감이 부족할 수 있는데, PiD는 이 부족한 부분을 픽셀 확산 모델의 생성 능력으로 보완합니다.

6) 제약사항

훈련 비용이 큽니다. 2K 모델 학습에는 대규모 H100 GPU가 사용되며, 4K 확장에는 GB200 GPU 여러 대가 필요합니다. 실제 서비스에 적용하려면 학습 비용과 운영 비용을 따져야 합니다.
PiD는 생성 능력이 강한 만큼 원본 잠재표현에 없던 디테일을 상상할 수 있습니다. 이는 장점이지만, 문서 복원이나 의료 영상처럼 원본과 정확히 일치해야 하는 작업에서는 조심해야 합니다.
early termination은 항상 좋은 것이 아닙니다. 너무 일찍 멈추면 잠재표현의 의미 구조가 덜 만들어져 이미지 품질이 떨어질 수 있습니다. 반대로 끝까지 돌리면 PiD가 세부 질감을 새로 만들 여지가 줄고, 전체 시간도 늘어납니다.
4K 디코딩은 가능하지만 메모리 부담이 사라지는 것은 아닙니다.

PiD의 의의는 디코더를 단순한 복원 장치에서 생성 장치로 바꿨다는 점입니다. 기존 VAE 디코더는 압축된 정보를 되돌리는 데 초점이 있었지만, PiD는 잠재표현을 바탕으로 고해상도 픽셀 이미지를 직접 합성합니다. 그래서 디코딩과 업스케일링을 하나의 과정으로 묶고, 속도와 품질을 함께 개선하려고 합니다.

실생활 적용 측면에서보면, 고해상도 결과가 필요한 이미지 작업에서 후처리 시간을 줄일 수 있다는 장점이 있을 것입니다.

참고자료

사이트) PiD 프로젝트 사이트 (링크) - Overview of PiD 영상을 참고하세요.
논문) PiD: Fast and High-Resolution Latent Decoding with Pixel Diffusion (링크)
코드) NVDIAdml PiD github 저장소 (링크)

Q&A

Q. PiD는 기존 VAE 디코더와 무엇이 다른가요?

PiD는 잠재표현을 단순히 복원하지 않고, 픽셀 확산 모델을 이용해 고해상도 이미지를 직접 생성합니다. 그래서 디코딩과 업스케일링을 한 번에 처리합니다.

Q. sigma-aware gate는 왜 필요한가요?

잠재표현이 깨끗하면 더 많이 참고하고, 노이즈가 많으면 덜 참고하기 위해 필요합니다. 흐릿한 설계도를 그대로 믿으면 결과가 흔들릴 수 있기 때문입니다.

Q. PiD가 항상 원본에 더 충실한가요?

항상 그렇지는 않습니다. PiD는 더 선명하고 자연스러운 디테일을 만들 수 있지만, 때로는 원래 잠재표현에 없는 디테일을 추가할 수 있습니다. 그래서 정확한 복원이 중요한 작업에서는 검증이 필요합니다.

Bonsai Image 4B : 1비트/삼진 가중치 처리로 온디바이스에서 이미지를 생성하는 모델

42morrow — Wed, 27 May 2026 15:27:35 +0900

이미지 생성 AI는 이제 낯선 기술이 아닙니다. 몇 줄의 문장을 넣으면 그림, 제품 시안, 배경 이미지, 콘셉트 아트를 만들 수 있습니다. 하지만 실제로 이 기술을 노트북이나 스마트폰에서 바로 쓰려면 다른 문제가 생깁니다. 모델이 너무 크고, 메모리를 많이 쓰며, 이미지를 한 장 만들 때도 여러 번 계산을 반복해야 합니다.

최근 AI 산업의 흐름은 '더 큰 모델'만이 아니라 '어디서 실행할 수 있는가'로 옮겨가고 있습니다. 서버에 모든 것을 맡기면 편하지만, 비용·속도·개인정보 문제가 남습니다. 그래서 기기 안에서 직접 돌아가는 온디바이스 AI가 중요해졌습니다. 이 논문은 그 흐름에서 이미지 생성 모델을 아주 작은 비트 표현으로 줄이면서도, 품질을 꽤 유지할 수 있는 방법을 보여줍니다.

1) 기존 방식의 문제점

확산 모델은 이미지를 한 번에 만들지 않고, 처음에는 노이즈에 가까운 상태에서 시작해서 여러 번의 노이즈 제거 단계를 거쳐 점점 이미지답게 만듭니다. 문제는 이 과정에서 같은 큰 모델을 반복해서 불러와 계산한다는 점입니다. 그렇기 때문에 확산 모델을 볼 대는 품질 외에도 한 단계당 걸리는 시간과 이미지 한 장당 시간을 함께 봐야 합니다.

기존 FLUX.2 Klein 4B의 FP16 확산 트랜스포머는 7.75GB인데 반해, Bonsai Image 4B는 이를 1비트 버전 0.93GB, 삼진 버전 1.21GB로 줄였습니다. 각각 8.3배, 6.4배 수준의 모델 크기 감소를 보인 것입니다.

2) 접근 방식

이 논문의 핵심은 모델 구조를 바꾸지 않고, 가중치 표현 방식을 바꾼다는 점입니다. Bonsai Image 4B는 FLUX.2 Klein 4B의 기본 확산 트랜스포머 구조, 샘플러, 텍스트 조건 처리 경로를 유지합니다. 대신 계산량이 큰 행렬 가중치를 1비트 또는 삼진 값으로 표현합니다.

1비트 Bonsai는 가중치를 {-1, +1} 두 값으로만 표현합니다. 삼진 Bonsai는 {-1, 0, +1} 세 값으로 표현합니다. 여기에 128개 가중치마다 FP16 스케일 값(해당 묶음의 값들을 어느 정도 크기로 볼 것인가를 알려주는 보정 계수)을 붙입니다.

3) 모델/기술 아키텍처

Bonsai Image 4B의 전체 파이프라인은 텍스트 인코더, 확산 트랜스포머, VAE 디코더로 구성됩니다.

텍스트 인코더는 Qwen3-4B를 HQQ INT4로 압축해 사용하고,
VAE는 안정적인 이미지 복원을 위해 FP16으로 유지합니다.
DiT (Diffusion Transformer)는 약 4B 파라미터와 25개 블록으로 구성되며, 5개의 더블 스트림 블록과 20개의 싱글 스트림 블록을 사용합니다.

그림 : Bonsai Image 4B의 아키텍처 개요

위의 그림을 보면, 사용자가 텍스트 프롬프트를 넣으면 텍스트 인코더가 이를 조건 정보로 바꾸고, 확산 트랜스포머가 노이즈 잠재 표현을 단계적으로 이미지에 가까운 형태로 만듭니다. 마지막으로 VAE 디코더가 이 잠재 표현을 실제 이미지로 복원하는 과정을 볼 수 있습니다.

그림 : 블록 내부 구조 (더블 스트림 블록 (좌), 싱글 스트림 블록 (우))

위의 그림은 블록의 내부 구조를 보여줍니다.

더블 스트림 블록(좌) : 이미지 토큰과 텍스트 토큰을 따로 다루다가 주의(attention) 연산에서 함께 봅니다. (joint attention)
싱글 스트림 블록(우) : 두 토큰을 합쳐서 attention과 MLP를 병렬로 처리합니다.
Q/K/V 투영, 출력 투영, MLP처럼 큰 행렬 곱이 필요한 부분은 1비트 또는 삼진 표현을 쓰고, 정규화나 작은 보조 투영은 FP16으로 남깁니다.

4) 세부 적용 기술

1비트 가중치 표현 :
1비트 Bonsai Image 4B는 각 가중치를 {-1, +1} 중 하나로 저장합니다. 여기에 128개 가중치마다 FP16 스케일을 두는데, 이를 통해 베이스가 되는 FLUX.2 Klein 4B의 FP16 트랜스포머는 7.75GB이지만 1비트 Bonsai는 0.93GB로 줄어 약 8.3배가 작아집니다.
삼진 가중치 표현 :
삼진 Bonsai Image 4B는 {-1, 0, +1} 세 값을 사용합니다. 0이 추가되면 어떤 연결은 사실상 끄는 효과를 낼 수 있는데 이는 모델의 표현력을 높이고, 극단적인 압축에서도 이미지 품질과 프롬프트 충실도를 더 잘 보존하도록 합니다. 삼진 Bonsai는 FLUX.2 Klein 4B 대비 평균 94.4%의 벤치마크 점수를 유지했습니다.
중요한 부분은 FP16으로 유지 :
전체를 저비트로 바꾸지 않고, 품질에 민감한 일부 projection, embedding, normalization, modulation 관련 부분은 FP16으로 남김으로써 품질 저하를 완하하고 있습니다.
런타임 최적화와 메가커널 :
Bonsai Image 4B는 가중치만 줄인 것이 아닙니다. 실행 과정에서도 메모리 사용을 줄입니다.
- Qwen3-4B 텍스트 인코더를 HQQ INT4 방식으로 압축하고, 프롬프트를 처리한 뒤 메모리에서 내립니다.(메모리 오프로드)
- 해상도 때문에 VAE가 부담될 때는 타일 방식으로 나눠 디코딩합니다.
- Apple Silicon에서는 LayerNorm, RoPE, QKV projection을 하나의 Metal 커널로 묶는 klein_fast 메가커널을 사용합니다. (여러 연산을 한군대서 이어서 처리하는 방식으로 데이터 이동과 메모리 사용을 줄임)
저비트 GEMM 커널 :
압축된 가중치를 실행할 때 다시 FP16으로 풀지 않고, CUDA에서는 Gemlite, Apple Silicon에서는 MLX 저비트 커널을 사용을 사용해 1비트/2비트 형태를 직접 읽어 계산합니다.

이런 기술들을 적용한 덕분에 Bonsai의 두 버전은 기기 안에서 실행되며, 512×512 이미지는 두 모델 모두 9.4초, 1024×1024 이미지는 1비트가 32.6초, 삼진이 34.0초에 생성됩니다. (기기에 따라 수치는 다름) 기존 MFLUX FP16 파이프라인의 134.91초와 비교하면 약 5.6배 빠른 결과를 보입니다.

5) 제약사항

저비트 표현은 원본 FP16 모델과 완전히 같은 결과를 내는 것이 목표가 아니기 때문에, 평가 기준을 '비트 단위 동일성'이 아니라, 배포 환경에서 비슷한 동작을 유지하는지로 봐야 합니다.
작은 글자, 세밀한 물체, 고주파 텍스처, 물체 개수, 특이한 조명, 강한 색감, 복잡한 프롬프트 조건에서는 품질 저하가 생길 수 있습니다.
현재 일반 하드웨어는 완전한 네이티브 1비트/삼진 연산 경로를 표준으로 제공하지 않습니다. CUDA와 Apple Silicon에서 실용적인 저비트 커널을 사용하지만, 앞으로 네이티브 커널이 좋아지면 지연 시간과 에너지 효율 개선 여지가 더 있다고 설명합니다.
트랜스포머가 작아질수록 VAE 같은 다른 부분이 병목이 됩니다. VAE는 이미지를 복원하는 품질과 직접 연결되기 때문에 공격적으로 압축하기 어렵고, 고해상도에서는 활성화 메모리 부담이 커질 수 있습니다.

Bonsai Image 4B의 기술적 의의는 이미지 생성 AI의 중심부인 확산 트랜스포머를 1비트와 삼진 표현으로 줄이면서도, 기존 4B급 모델의 동작을 상당 부분 유지했다는 점입니다. 모델 구조를 새로 설계하거나 더 작은 학생 모델로 바꾸는 대신, 같은 구조를 더 가벼운 표현으로 실행하려 했다는 점이 중요합니다.

실생활에서는 API나 AI 서비스 유료 구독없이 로컬 PC나 심지어 개인 모바일폰에서 제법 큰 사이즈의 이미지를 직접 이미지를 생성할 수 있다는 장점을 제공합니다.

참고자료

백서) 1-bit and Ternary Bonsai Image 4B (링크)
블로그) Introducing 1-bit and Ternary Bonsai Image 4B: Image Generation for Local Devices (링크)
데모) Hugging Face Space Demo (링크)

Q&A

Q. Bonsai Image 4B는 기존 이미지 생성 모델을 새로 만든 것인가요?

아닙니다. FLUX.2 Klein 4B의 구조를 유지하면서, 핵심 가중치 표현을 1비트 또는 삼진 값으로 바꾼 배포 방식에 가깝습니다.

Q. 1비트와 삼진 모델 중 어떤 것이 더 좋은가요?

목표에 따라 다릅니다. 1비트는 크기와 메모리 절감에 더 유리하고, 삼진은 조금 더 크지만 이미지 품질과 프롬프트 충실도를 더 잘 유지합니다.

Q. 이 기술이 중요한 이유는 무엇인가요?

큰 이미지 생성 모델을 서버가 아닌 개인 기기에서 실행할 가능성을 높이기 때문입니다. 이는 속도, 비용, 개인정보 보호 측면에서 의미가 있습니다.

Understand Anything : 레거시 코드베이스를 ‘읽는 것’에서 ‘이해하는 것’으로

42morrow — Tue, 26 May 2026 15:27:08 +0900

새로운 개발자가 팀에 합류했을 때 가장 먼저 마주하는 장벽은 코드 그 자체입니다. 특히 수십만 라인 규모의 레거시 코드베이스라면 문제는 더 커집니다. 물론 기존 코드 전체를 다 떠맡아 개발하거나 유지보수해야 하는 역할을 맡진 않겠죠. 하지만, 역할을 부여받게 되면 들여다보긴 해야 할텐데, 어디서부터 읽어야 할지 알기 어렵고, grep 검색과 파일 간 이동만으로는 시스템의 전체 흐름을 파악하기 어려울 겁니다. 기존 문서는 이미 오래전에 실제 코드와 달라졌을 수 있고, 핵심 설계 의도를 알고 있던 엔지니어가 팀을 떠난 경우에는 남은 코드만 보고 맥락을 추측해야 하죠.

최근에는 AI 코딩 도구가 이런 문제를 어느 정도 완화해 주고 있지만, 단순히 몇 개의 파일을 LLM에게 넘겨주는 방식만으로는 한계가 있습니다. AI 에이전트 역시 전체 시스템 지도 없이 코드를 읽으면, 의존성이나 비즈니스 흐름을 놓친 채 부분적인 답변을 내놓을 가능성이 높습니다. 이런 문제의식에서 등장한 도구가 Understand Anything입니다.

Understand Anything은 코드베이스, 지식 베이스, 문서를 탐색·검색·질문 가능한 인터랙티브 지식 그래프로 변환하는 오픈소스 프로젝트입니다. GitHub 저장소 기준으로 Claude Code, Codex, Cursor, Copilot, Gemini CLI 등 다양한 AI 개발 워크플로우와의 연동을 지원한다고 소개되어 있습니다.

코드베이스를 지식 그래프로 바꾸는 도구

Understand Anything의 핵심은 '코드를 시각적 지식 그래프로 바꾼다'는 점입니다. 저장소를 분석하면 파일, 함수, 클래스, 의존성 관계를 추출하고, 이를 json 파일 형태의 그래프로 저장합니다. 이후 명령을 통해 웹 기반 인터랙티브 대시보드에서 코드 구조를 탐색할 수 있습니다.

이 그래프는 단순한 파일 트리나 import 관계도와 다릅니다. 각 노드는 클릭과 검색이 가능하며, 노드를 선택하면 해당 요소의 설명, 관계, 가이드 투어 등을 함께 확인할 수 있습니다. 다시 말해 '이 파일이 어디에 있는가?'를 넘어서 '이 파일이 시스템 안에서 어떤 역할을 하는가?'를 파악하는 데 초점을 둡니다.

그림 : 프로젝트 개요 화면 예시 (출처 : understand-anything 공식 사이트)

구조뿐 아니라 의미까지 분석한다

기존 IDE의 코드 그래프나 소스 분석 도구는 보통 구조적 관계를 보여주는 데 강합니다. 예를 들어 어떤 파일이 어떤 파일을 import 하는지, 어떤 클래스가 어떤 클래스를 상속하는지, 어떤 함수가 어디서 호출되는지 등을 보여주는 것이죠. 하지만 실제 개발자가 궁금한 것은 거기서 한 걸음 더 나아갑니다. 이 모듈은 왜 필요하며, 결제 흐름은 어디서 시작해서 어디서 끝나고, 이 코드를 수정하면 어떤 기능에 영향을 줄 수 있는가 등등과 같이 말입니다.

Understand Anything은 이 지점에서 정적 분석과 LLM을 결합합니다.

Tree-sitter : import, export, 함수·클래스 정의, 호출 위치, 상속 같은 구조적 사실을 추출
LLM : 코드의 요약, 태그, 아키텍처 레이어, 비즈니스 도메인 매핑, 가이드 투어 같은 의미적 정보를 생성

즉, 결정적으로 분석할 수 있는 부분은 정적 분석으로 안정적으로 처리하고, 코드의 의도나 업무 흐름처럼 문맥이 필요한 부분은 LLM이 보완하는 구조입니다.

멀티 에이전트 파이프라인

Understand Anything은 단일 LLM 호출로 전체 코드를 요약하는 방식이 아니라, 여러 전문 에이전트를 조합한 파이프라인을 사용합니다.

/understand 명령 : 다음과 같은 에이전트들을 조율
- project-scanner : 파일 탐색과 언어·프레임워크 감지를 담당
- file-analyzer : 함수/클래스/import를 추출
- architecture-analyzer : 아키텍처 레이어를 식별
- tour-builder : 학습용 투어를 생성
- graph-reviewer : 그래프 무결성을 검증
/understand-domain 명령 : 비즈니스 도메인과 프로세스 단계를 추출하는 domain-analyzer 사용

이 구조는 코드베이스를 단순히 요약하는 것이 아니라, 여러 관점에서 분해한 뒤 다시 연결하는 방식에 가깝습니다. 파일 단위 이해, 아키텍처 레이어 이해, 도메인 흐름 이해, 변경 영향 분석을 서로 연결할 수 있다는 점이 특징입니다.

주요 기능 정리

Understand Anything의 대표 기능은 크게 다섯 가지로 정리할 수 있습니다.

구조 그래프 탐색 : 파일, 함수, 클래스가 노드가 되고, 의존성과 호출 관계가 엣지로 표현됩니다. 대시보드에서 줌인/줌아웃을 하며 전체 아키텍처를 한눈에 볼 수 있습니다.
비즈니스 로직 이해 : 도메인 뷰를 사용하면 코드가 실제 비즈니스 프로세스와 어떻게 연결되는지 확인할 수 있습니다. 예를 들어 Payments, Auth, User Management 같은 기능이 어떤 흐름과 단계로 구성되는지 파악하는 데 유용합니다.
가이드 투어 : 의존성 순서에 따라 자동 생성되는 아키텍처 워크스루를 제공해, 처음 보는 코드베이스를 어떤 순서로 읽어야 하는지 안내합니다.
퍼지 검색과 시맨틱 검색 : 단순 파일명 검색뿐 아니라 '인증을 처리하는 부분은?' 같은 의미 기반 질문으로 관련 노드를 찾을 수 있습니다.
변경 영향 분석 : /understand-diff 명령을 통해 현재 변경 사항이 시스템의 어떤 부분에 영향을 줄 수 있는지 사전에 확인할 수 있습니다. 이는 리팩토링, PR 리뷰, 장애 예방 관점에서 특히 유용합니다.

개발 워크플로우에서의 활용 사례

온보딩 : 새 팀원이 기존 문서를 처음부터 끝까지 읽는 대신, 지식 그래프를 통해 시스템 구조와 주요 흐름을 먼저 파악할 수 있습니다. 팀에서 .understand-anything/ 그래프 파일을 커밋해 공유하면, 다른 팀원은 전체 분석 파이프라인을 다시 돌리지 않고도 그래프를 활용할 수 있습니다.
AI 에이전트의 컨텍스트 강화 : 도메인, 흐름, 의존성, 아키텍처 레이어가 구조화된 지도를 제공합니다. 이 지도는 AI가 코드베이스를 더 넓은 맥락에서 이해하도록 돕습니다.
리팩토링 및 영향도 분석 : 대규모 시스템에서는 작은 수정 하나가 예상치 못한 기능에 영향을 줄 수 있습니다. 특히 결제, 인증, 권한, 외부 API 연동처럼 여러 모듈이 얽힌 영역에서는 수정 전 영향 범위를 보는 것이 중요합니다. Understand Anything의 diff impact 기능은 이런 사전 점검에 적합합니다.

설치와 사용 흐름

Claude Code에서는 플러그인 마켓플레이스를 통해 설치할 수 있습니다.

/plugin marketplace add Lum1104/Understand-Anything
/plugin install understand-anything

이후 프로젝트 루트에서 다음 명령을 실행합니다.

/understand

분석이 끝나면 다음 명령으로 대시보드를 열 수 있습니다.

/understand-dashboard

한국어 설명과 UI를 원한다면 다음처럼 언어 옵션을 사용할 수 있습니다.

/understand --language ko

그리고, Claude Code 외에도 Cursor, VS Code + GitHub Copilot, Copilot CLI, Codex, OpenCode, OpenClaw, Antigravity, Gemini CLI, Vibe CLI, Hermes, Cline, KIMI CLI 등 다양한 플랫폼을 지원한다고 안내되어 있습니다.

기존 도구와의 차별점

Understand Anything의 차별점은 단순히 '그래프를 그린다'가 아니며, 중요한 것은 그래프가 학습용 지도로 설계되어 있다는 점입니다.

기존 소스 그래프 도구 : 소스 코드의 구조를 보여줍니다. 어떤 파일이 어떤 파일에 의존하는지, 어떤 함수가 어디서 호출되는지 알 수 있습니다. 하지만 그 구조가 실제 제품 기능이나 비즈니스 흐름에서 어떤 의미를 갖는지는 개발자가 따로 해석해야 합니다.
Understand Anything : 파일 단위의 관계를 넘어, 시스템 동작 흐름을 보여주려 합니다. 예를 들어 Payments라는 기능을 검색했을 때 관련 코드 조각과 연결 관계를 찾고, 진입점부터 유효성 검사, 핵심 로직, DB 접근, 외부 API 호출, 에러 처리까지 이어지는 흐름을 따라가도록 도와주는 방식입니다.

이런 접근은 특히 시각적으로 학습하는 개발자에게 유용합니다. 검색창에 질문을 던지고 답변만 받는 방식은 빠르지만, 전체 구조를 머릿속에 남기기 어렵습니다. 반면 그래프 기반 탐색은 시스템의 큰 그림을 먼저 잡고, 필요한 부분으로 점차 들어가는 학습 방식을 가능하게 합니다.

사용 시 고려할 점

Understand Anything은 전체 구조와 흐름을 빠르게 파악하게 해주는 보조 도구에 가까우므로 최종적으로 중요한 로직을 수정하거나 장애 가능성을 판단해야 할 때는 개발자가 직접 코드를 읽고 검증해야 합니다.
LLM 기반 멀티 에이전트 분석을 사용하기 때문에 대규모 프로젝트에서는 토큰 비용과 실행 시간이 문제가 될 수 있습니다.

Understand Anything은 레거시 코드베이스 이해 문제를 '검색'이 아니라 '구조화된 지식 지도'의 문제로 접근하는 도구입니다. 정적 분석으로 코드의 확실한 구조를 잡고, LLM으로 의미와 도메인 흐름을 보완한 뒤, 이를 대시보드와 지식 그래프로 시각화합니다.

특히 새 팀원 온보딩, 대규모 리팩토링 전 영향도 분석, AI 코딩 에이전트의 컨텍스트 보강, 오래된 문서 대신 살아 있는 코드 기반 문서화가 필요한 팀에 유용할 수 있습니다.

[바이브코딩] 단일HTML로 실시간 대전 테트리스 만들어보기

42morrow — Mon, 25 May 2026 20:59:03 +0900

온라인 빙고로 대전 게임을 만들어보니 생각보다 괜찮은 것 같습니다. 그래서, 내친김에 예전에 만들어둔 테트리스 게임을 대전 형태로 바꿔봤습니다. 첫 시도를 테트리스로 정한 것은 어렸을 때 해봤던 '결전 테트리스'라는 게임이 떠올랐기 때문입니다. 테트리스 자체의 재미에 서로에게 공격을 가하는 대전 게임의 재미까지 더해지면 더 좋을 것 같았습니다.

이번 글에서는 게임을 만들기 위해 정리했던 사항들을 요약해서 기록해 두겠습니다.

게임 개요

단일 HTML로 구동되는 대전 테트리스 게임
1인용 테트리스 게임을 기반으로 온라인 2인용 대전 테트리스로 확장함
참고로 1인용 테트리스 게임에서 사용한 보일러 플레이트를 그대로 적용하되 상단 버튼은 제외

구현 기능

기본 테트리스 기능에 다음과 같은 몇 가지 기능이 추가되어야 했습니다.

로비 (대전상대 목록) : 대전상대 목록 표시 및 대전 신청/수락
Next 블록 뷰어 : 넥스트 블록 보기를 5개로 확장
공격 기능 : 라인 삭제 시 상대방에 가비지 라인 추가 (클리어수 -1 줄)
공격 아이템 : 가비지 3줄 공격, 상대 공격 아이템 제거, 블록들에 랜덤한 구멍 뚫기 등. (라인 삭제 시 랜덤하게 생성함)
실시간 조작 반영 : 한쪽 플레이어의 조작 결과를 상대방에 실시간 반영되도록 함

기술 요소

기본적으로 단일 HTML로 구동하여야 하기 때문에 로그인, 실시간 전송은 로컬 서버가 아닌 클라우드에서 제공하는 서비스를 사용하거나 직접 피어단끼리 연결하는 방식을 채택해야 했습니다. 그래서 다음과 같은 기술이 사용되었습니다.

HTML5 기반 (HTML + Javascript + CSS)
Firebase : 사용자 로그인, 로비 (로그인된 플레이어 목록 표시), 신청/수락 실시간 반영에 적용
WebRTC : 플레이어의 실시간 조작을 상대방에 반영하기 위해 적용

게임 진행

이렇게 해서 구현된 대전 테트리스 게임입니다. 게임은 가로화면 전체로 표시됩니다. 게임의 진행 순서는 다음과 같습니다.

플레이어 A와 B가 로그인합니다. 둘은 로비로 들어가고 화면에는 상대방 플레이어들의 목록이 표시됩니다.
플레이어 B가 대전 신청을 하고 플레이어 A가 수락을 하면 게임이 3초 카운트 뒤 시작됩니다.
게임 화면은
- 신청한 쪽이 왼쪽, 상대가 오른쪽으로 배치되고
- Next 5개의 블록이 표시되며
- 테트리스 게임의 동작은 아래스왑(빨리 내리기), 터치(방향회전), 좌우스왑(좌우이동)을 이용합니다.
게임이 끝나면 승패를 보이고 재대전하거나 로비로 나갈 수 있습니다.

UI가 화려하거나 하지 않고 보낸 공격이 반영되는 속도가 약간의 딜레이를 포함하고 있어서 재미가 반감될까 걱정했는데, 가족들끼리 해 보니 생각보다 승부욕을 고무시킬 정도로 재미있었습니다. 이미 많들어 둔 게임들에 대전 기능을 추가할만한 것들이 있는지 알아보고 적용해 봐야겠습니다. ^^

[바이브코딩] 온라인 빙고 게임 만들기

42morrow — Fri, 22 May 2026 14:56:27 +0900

아이와 함께 놀기 위해 바이브코딩으로 온라인 빙고 게임을 만들어 봤습니다. 처음에는 종이에 손으로 그려서 만들었는데 막상 해 보니 불편한 점이 많았습니다. 집 바깥에서 늘 종이와 필기구를 가지고 다닐 수도 없고, 주제를 정해서 하면 단어를 생각해내는데 시간이 많이 걸리기도 하고, 서로 이기려다보니 자신만 아는 단어들을 사용해서 서로의 빙고판에 겹치는 것이 없는 경우도 많이 생기더군요. 이건 뭐 전투 빙고도 아니고... 그래서, 폰으로 접속해서 손쉽게 할 수 있도록 만들어 봤습니다.

1. 개요

온라인으로 접속해서 최소 2사람 이상이 참여하는 대전하는 형태의 빙고 게임입니다.
게임은 주제를 정하고 그 주제에 맞는 단어들을 이용합니다.
주로 폰에서 하게 될 것이므로 모바일에 맞춰 최적화되도록 합니다.

2. 구현 요구사항

단일 HTML 게임으로 생성합니다.
기존 만들어둔 Template에 맞춰 진행합니다. (보일러플레이트 생성을 위한 SKILL.md를 이용함)
~~복수의 게임방 관리가 필요합니다. (사용자가 열려 있는 빙고방을 선택해서 진행할 수 있음)~~
-> 초기에는 이렇게 만들어서 사용했는데, 사용해보니 사용자가 가족 한 두사람이 함께 하는 게임이라 거의 불필요한 UI가 되어 단순화하기로 했습니다.

그림 : 게임방 목록두고 참여하도록 했던 초기 방식 예시

~~단어 리스트를 타이핑하고 이것을 자동으로 배치하도록 합니다.~~
-> 이 방식을 적용해서 해 보니, 플레이어가 어떤 단어들을 사용할지 생각하는 과정에 시간이 많이 걸려 바로바로 게임이 진행되지 못했습니다. 온라인 빙고 게임들이 대부분 숫자를 가지고 하는 이유가 이런 이유가 아닐까 싶었습니다.

그림 : 시도해봤던 방식 (이후 폐기)

사용 가능한 단어는 단어목록 형태로 미리 제공되며, 배치는 수동/자동을 둘 다 지원합니다.
- 자동인 경우, 랜덤하게 배치할 수 있도록 하고
- 수동인 경우, 드래그 혹은 선택 후 클릭해서 배치되도록 합니다.
대전 상대는 로그인 되어 있는 플레이어 목록에서 선택할 수 있도록 합니다.
한쪽에서 선택하면 실시간으로 상대쪽에 표시되고, 빙고판정과 최종 승리/패패 판정이 자동화되어야 합니다.
승리/패배 판정 후 플레이어들의 빙고판 현황을 보여주는 기능도 포함합니다.

3. 게임 구성

빙고 게임에서 필요한 것은 빙고판, 빙고판에 사용할 단어 목록들, 대전상대 초대, 그리고 상대의 선택에 따른 즉각적인 반응이라고 생각했습니다. 그러면서도 단일 HTML에서 처리하고 싶었죠. 그래서, 각각을 다음과 같이 접근했습니다.

빙고판 : 5x5 (기본값)으로 하고 5개의 빙고를 먼저 완성하는 쪽이 이기는 것으로 함
단어 목록 : 총 7개의 카테고리로 나눴습니다. 주로 아이들이 잘 알거나 많이 사용하는 단어들이 있는 것인데, 주된 사용층에 따라 손쉽게 추가, 변경할 수 있습니다.
대전상대 초대 : 처음에는 한명이 생성 후 게임방 접속 링크를 생성하는 방식으로 했는데, 실제 해 보니 카톡이나 메시지로 보내고 하는 작업이 생각보다 성가셨습니다. 그래서, 로그인 되어 있는 플레이어 목록을 보여주고 그 가운데 선택해서 직접 초대하는 방식으로 변경했습니다.
상대 수에 대한 실시간 반응 : 온라인 대전의 특성 상 상대방에게 즉각적으로 수 반영을 해야 했습니다. 그래서, 이벤트 처리를 할 수 있도록 Firebase라는 실시간 DB를 이용합니다. (사용 후 즉각 삭제 형태면 비용 발생핮지 않습니다)

4. 적용 기술

적용된 기술을 요약하면 CDN 기반 Firebase + 순수 JavaScript + 반응형 CSS라고 할 수 있습니다.

세부적으로는 다음과 같습니다.

HTML/CSS/Vanilla JavaScript
- 순수 DOM 조작으로 화면 전환, 모달, 빙고판 렌더링을 처리하고,
- CSS 변수, Flex/Grid, 미디어 쿼리, 100dvh, safe-area-inset 등을 사용해 모바일 대응 UI를 구성했습니다.
Firebase
- Firebase 모듈 CDN을 직접 import 하고,
- Realtime Database로 방, 참가자, 빙고판, 선택된 단어, 초대, 접속 상태를 실시간 동기화합니다.
- Anonymous Auth로 사용자별 UID를 만들고,
- browserSessionPersistence를 써서 탭별 익명 세션 충돌을 줄이도록 되어 있습니다.
브라우저 API : 다음과 같은 API를 사용합니다.
- localStorage : 사용자 ID와 최대 인원 설정 저장
- Pointer Events : 빙고판 셀 드래그 앤 드롭 교환 기능
- Web Audio API : 단어 선택/승리 효과음 생성
실시간 게임 로직
- 방 생성/참가/퇴장, 자동 시작, 턴 계산, 단어 선택, 빙고 줄 계산, 승리 판정이 클라이언트 JS에 구현되어 있고,
- Firebase onValue 구독과 runTransaction을 사용해 실시간 반영과 중복 선택 방지를 처리합니다.

5. 게임 동작

최종적으로 개발 완료된 코드로 진행한 실제 게임에서의 동작 과정은 다음과 같습니다. 플레이어 A, B가 있다고 할 경우, 다음과 같이 말이죠.

그림 : 온라인 빙고 대전 절차

먼저 플레이어 A와 B가 로그인합니다.
플레이어 A는 카테고리를 선정하고 먼저 자신의 빙고판을 완성 (랜덤 배치 선택 가능) 후 상대를 초대합니다.
플레이어 B는 초대에 수락하고, 자신의 빙고판을 완성합니다.
두 플레이어의 빙고판이 완성되면 게임이 시작됩니다.

Firebase의 기능을 이용하니 단일 HTML만으로 제법 온라인 게임 같은 구색을 갖출 수 있었습니다. 이번 빙고게임 같이 복잡하지 않고 많은 리소스가 필요치 않은 경우라면 충분히 활용해볼만한 방식아라 생각됩니다. 다음엔 또 어디에 이 방식을 적용해볼까요? ^^

LTX2.3 + ComfyUI + VRAM 8GB = 로컬에서 멋진 신세계, 아니 멋진 영상!

42morrow — Thu, 21 May 2026 16:44:03 +0900

우연히 ComfyUI를 이용해 최신 LTX2.3 모델(양자화 버전)으로 영상을 생성하는 유튜브 채널을 보게 되었습니다. 그것도 8GB VRAM을 가진 저사양GPU에서 동작시킨 결과라고 하는 겁니다. 오호...

영상 : LTX2.3 + ComfyU

SeeDance 2.0, VEO 4 등 이미 훌륭한 영상 생성 모델은 공개된 것이 많이 나와 있는터라 그닥 놀랍지 않았지만, 저사양 GPU를 이용한 로컬 영상 생성은 먼 나라 얘기로 생각하고 있던 터였습니다. 그러다보니 로컬이 아닌 클라우드 기반으로 무료 서비스로 제공되는 Kanana나 Grok을 이용해 이미지 기반의 짧은 영상을 생성만 해 봤습니다. 하지만, 세부적인 조작이 불가능해서 그닥 활용할만 곳을 생각하지 못했습니다. 그랬는데 이제는 이제야 한번 발을 담궈볼 수 있겠구나 싶은 생각이 들었습니다.

저사양의 개인용 GPU에서 영상 생성을 손쉽게 할 수 있는 방법이 소개되었습니다. 그것도 생각보다 훌륭한 품질의 AI 모델이 사용되어 볼만한 영상이 생성됩니다.

진행한 절차는 다음과 같습니다.

ComfyUI 최신 버전을 설치합니다. (혹은 업데이트)
- ComfyUI 설치 가이드 (링크)
LTX2.3 8GB 버전 workflow를 다운로드합니다.
- 다운로드 (링크)
ComfyUI를 이용해 해당 workflow 로드합니다.
- 누락되었다고 표시되는 Custom 노드를 ComfyUI Manager를 이용해 설치해 줍니다.
- Workflow 상에 명시된 모델들을 다운로드합니다. (수동이지만 쉽게 할 수 있도록 버튼 등이 준비되어 있습니다)
사용할 초기 이미지 생성합니다.
- 제 경우, 퀴즈 게임을 소개하는 아나운서 이미지를 GPT-Image2를 이용해 생성했습니다.
- Workflow에서는 기본 1:1 영상을 생성하고 있습니다. 그래서, 같이 맞출려고 1:1 비율로 crop 했습니다.
멘트로 사용할 audio 파일 생성하기
- 예전에 게임 영상을 만들 때 사용했던 음성 파일을 이용해봤습니다.
- wav, mp3 등 포맷은 편한 걸로 하면 됩니다.
Workflow 실행하기
- 입력으로는 초기 이미지 (아나운서) + 멘트 음성 파일이 사용되었습니다.
- 이렇게 하면 해당 이미지를 이용하고 멘트 음성 파일에 맞춰 립싱크가 된 최종 영상이 생성됩니다.

기본 설정에서 위의 내용을 적용하기 위해서 설정값 변경은 다음과 같이 합니다. (노드 별 설정값입니다)

LoadAudio = 생성한 대사 음성 파일
TrimAudioDuration.start_index = 0
Seconds = 음성 길이
Audio to Video Mode = True
Text To Video Mode = False
FPS = 24
DenoLTXSequencer.strength_1 = 0.8 ~ 1.0
Prompt = speaking naturally, synchronized with the audio, realistic lip movement

아래 화면에서는 Workflow의 노드가 작아서 제대로 보이지 않지만 위의 설정값이 적용되었다 생각하시면 됩니다.

그림 : ComfyUI Workflow를 이용한 영상 생성 예시

대략 RTX3090에서 30~40초 가량 걸린 것 같습니다. ComfyUI에서 해당 모델을 로딩하면 VRAM 사용량은 16GB 정도로 잡힙니다. 소개 영상에서는 8GB 정도가 사용된다고 했는데 더 잡아먹고 있습니다. 다운받을 때 버전이 Text to Video 기본과 Audio 립싱크까지 추가된 버전이 나눠져 있었는데 후자를 선택해서 그런지도 모르겠습니다. 그게 아니면 GPU에 따라서 용량이 남았다 싶으면 더 잡는 것일지도... ^^;

이런 과정을 거쳐 만들어진 영상은 다음과 같습니다. 오호... 이런 수준으로 나온다면 유튜브 영상 만들 때 충분히 활용할 수 있을 것 같습니다.

영상 : 생성된 최종 영상 (모두 AI입니다)

여튼 로컬 컴퓨터에서 5~8초 가량의 영상을 1분 이내에, 고퀄리티로 만들어낼 수 있다는 것은 그저 놀라운 일입니다. 참고로 제 경우 512x512로 나오는 Preview만 생성해서 이를 파일로 저장했습니다. 업스케일된 영상 저장도 지원하는데 그건 하지 않았습니다.

PhotoGIMP : GIMP + 패치 = Photoshop 처럼 사용하기

42morrow — Wed, 20 May 2026 12:40:27 +0900

PhotoGIMP라는 것이 소개되었습니다. GIMP라는 오픈소스 무료 이미지 편집기에 패치를 통해 마치 Photoshop과 동일한 툴바, 패널배치, 키보드 단축키를 지원하도록 만든 일종의 wrapper입니다. 실제 Photoshop이냐구요? 아니죠. GIMP입니다!

하지만, 실제 제공하는 기능이 비슷하더라도 사람들은 익숙한 UI, UX에 끌리게 되어 있고 이는 사용하던 툴에 고정되게 하는 효과로 이어집니다. 이번에 PhotoGIMP를 만든 브라질 개발자도 이런 측면을 생각했겠죠.

그림 : GIMP에 패치가 적용된 예시

포토샵은 Adobe의 가격 정책에 따라 연간 대략 40만원 정도의 구독비용이 듭니다. 완전히 동일한 기능을 제공하진 않더라도 주로 기본 기능 위주로 많이 사용하는 사람들의 경우에는 효용 대비로는 무시못할 비용이 되겠죠. PhotoGIMP는 이런 점을 파고 들었습니다.

로그인도 필요없고 Window, Mac, Linux에서 다 작동합니다. 이 점도 유용할 것 같습니다. 예를 들어 Photoshop이 Windows 장비에 설치되어 있지만, 현재 사용하는 Mac에서는 이를 이용할 수 없는 경우나 예를 들어 예전에 라이선스를 구입해서 설치를 했는데 이후에 잃어버려서 다시 설치가 불가능하다거나 이런 문제가 생기지는 않는다는 거죠. 주변에 이런 분을 가끔 봅니다. 오래된 윈도우 노트북을 그것 때문에 폐기하지 못한다는 아픔을 얘기하시는 분을 말이죠.

게다가 패치 크기가 정말 작습니다. 수 MB 수준이라 부담도 없고, GIMP가 설치된 폴더에 덮어쓰기 하는 방식으로 적용할 수 있습니다.

제 경우, GIMP도 가끔씩 사용하고 있고, Photoshop은 오래전에 사용해봐서 현재는 UI가 어떻게 바뀌었는지도 잘 모릅니다. 그래서 사실 의미가 없을 수도 있죠. 하지만, Photoshop을 현재도 사용하고 계신 분, 혹은 회사에서는 업무용으로 주로 사용하는데 집에서도 비슷하게 작업을 하고 싶을 때... 흠... 그래도 PhotoGIMP를 사용하는 경우는 없을래나? -_-;

여튼 오픈소스 이미지 도구에 Photoshop 감성을 넣어서 사용하고 싶으신 분은 한번쯤 시도해 보시기 바랍니다.

참고자료

코드) PhotoGIMP github 저장소 (링크)
GPL-3.0 라이선스라 개인적으로 사용하는 데는 전혀~ 문제없습니다.

Map3D를 이용해 주변을 3D로 변환해보기

42morrow — Tue, 19 May 2026 14:20:14 +0900

Map3d는 OpenStreetMap의 건물·도로 데이터를 가져와 Three.js/React-Three-Fiber로 3D 도시 지도를 만들고, 이를 GLB 파일로 내보낼 수 있게 해주는 웹 기반 3D 지도 생성 도구입니다.

X에서 영상으로 데모를 보여주길래 크게 기대하지는 않고 서울 중심부를 한번 시도해봤습니다. (실제로는 지방의 외곽지역도 해 봤습니다.)

1. 사이트 열기

Map3d 사이트 (링크) 를 브라우저에서 엽니다. 그런 뒤 지도에서 줌/이동을 이용해서 3D로 변환해보고자 하는 지역을 선택합니다. 저는 우리나라 흥인지문(동대문) 근처를 선택했습니다.

Next Step을 클릭합니다. 이렇게 되면 선택한 지역 내에 있는 건물 정보들을 가져오는 단계로 넘어갑니다. 중간에 Next Step 눌러라 하는 썰렁한 화면이 나올텐데 바로 Next Step을 또 눌러서 넘어가면 됩니다. (기다리지 마세요)

위의 그림은 건물 정보들을 가져와서 프로세싱하는 작업을 보여줍니다. 지정된 영역 내의 수많은 건물 정보가 이런 식으로 불러와 집니다. 화면에는 흥인지문, 밀리오레 등이 보이네요... 다시 Next Step을 클릭합니다.

가져온 정보를 이용해 지정한 공간의 3D 화면이 구성됩니다. 가운데 있는 건물이 흥인지문입니다. 대충 봐도 아시겠죠? 당연히 줌, 회전 등과 함께 개별 건물들을 클릭해 어떤 건물인지 건물 정보도 확인할 수 있습니다.

또한 상단 메뉴에 있는 Car mode를 선택하면 만들어진 공간 속을 자동차로 다녀볼 수 있습니다. 이때 방향키는 A(좌), D(우), 전진(W), 후진(S)를 이용하면 됩니다.

그리고, Export GLB 기능을 이용해 파일로 내보내기를 할 수 있습니다. GLB 파일 포맷은 3D 모델, 재질, 텍스처, 애니메이션 등을 한 파일에 묶은 웹·게임 친화적 3D 포맷으로 Blender, Unity, Unreal Engine 등과 같은 곳에서 사용가능하고 웹에서는 Three.js나 웹뷰어 등에서 활용할 수 있습니다.

참고자료

코드) Map3D github 저장소 (링크)

Supertonic 3 : Edge TTS 강자가 돌아왔다

42morrow — Mon, 18 May 2026 12:43:41 +0900

예전에 다국어 채팅봇을 만들 때 사용해봤던 Supertonic은 상당한 충격을 줬었습니다. 가벼운 Edge 디바이스에서도, 모바일에서도 잘 동작하는 멋진 녀석이었죠. 하지만 당시에는 5개의 언어 밖에 지원을 하지 않아서 용도 상 맞지 않는 것 같아서 접었었습니다.

그러던 Supertonic이 3버전에서는 31개의 언어를 지원하면서 다시 등장했습니다. 여전히 성능, 속도 좋고 가볍게 잘 돌아갑니다. 흠... TTS에서 무겁고 정밀한 용도가 아니라면 이 솔루션의 경쟁자가 있을까 싶기도 합니다.

1. 개요

Supertonic 3는 Supertone이 공개한 경량 Text-to-Speech(TTS) 모델입니다.
텍스트를 입력하면 음성으로 합성하는 모델이며, 핵심 목적은 로컬 기기에서 빠르게 음성을 생성하는 것입니다.
클라우드 API 호출 없이 ONNX Runtime 기반으로 사용자의 기기에서 직접 실행할 수 있습니다.
Hugging Face 기준으로 태스크는 Text-to-Speech, 태그는 speech-synthesis, tts, multilingual, on-device로 분류되어 있습니다.

2. 핵심 특징

온디바이스 실행 : 로컬 환경에서 음성 합성 지원. GPU/CPU 둘 다 지원
31개 언어 지원 : 31개 언어 지원 (한국어 ko, 영어 en, 일본어 ja, 독일어 de, 스페인어 es 등과 같이 언어코드 형태 지원)
읽기 안정성 개선 : 짧은 문장이나 긴 문장에서 발생할 수 있는 반복 읽기, 건너뛰기 문제 개선
화자 유사도 개선 : 기존 버전 대비 동일 언어군에서 화자 음색 유지 능력 향상
표현 태그 지원 : <laugh>, <breath>, <sigh> 같은 간단한 표현 태그 지원 (단순 낭독형 TTS를 넘어, 웃음·숨소리·한숨 같은 표현을 일부 제어할 수 있음)

3. 기술적 특징

ONNX 기반 공개 모델 : ONNX Runtime으로 실행되도록 설계됨. (PyTorch 모델을 직접 무겁게 구동하는 방식보다 배포와 실행이 단순할 수 있음)
약 99M 파라미터 규모 : 공개 ONNX 자산 기준 약 99M 파라미터 규모 (모델 가중치 사이즈가 대략 400MB 수준으로, 다운로드 크기, 초기 로딩 시간, 로컬 실행 측면에서 유리함)
CPU 실행 친화적 : 모바일, 브라우저, 엣지 디바이스, 로컬 앱에 적합

4. 장점

가볍다 : 약 99M 파라미터 규모라 대형 TTS 모델보다 부담이 적습니다.
로컬 실행 가능 : 음성 합성을 위해 외부 서버에 텍스트를 보내지 않아도 됩니다.
다국어 지원 : 한국어를 포함한 31개 언어를 지원합니다.
GPU 의존도가 낮다 : CPU 기반 실행을 전제로 하고 있어 일반 PC나 엣지 환경에서도 적용 가능성이 있습니다.
앱 내장형 TTS에 적합 : 브라우저, 로컬 앱, 교육 앱, 챗봇, 번역 앱, 안내 방송 시스템 등에 넣기 좋은 구조입니다.
다양한 CLI 방식 지원 : 배치 추론(다수 언어를 한번에), 고품질 추론(노이즈 제거), 장문추론(긴 텍스트 쪼개서 처리 후 병합) 등등

5.제약사항

라이선스가 약간 애매합니다. 모델의 경우 OpenRAIL-M, 샘플 코드는 MIT License로 안내되어 있습니다.
OpenRAIL-M : 모델 사용, 수정, 배포, 파생 모델 생성, 호스팅/API 제공이 가능하지만 조건을 지켜야 한답니다. 하지만, 상업적 사용 자체를 전면적으로 금지하는 라이선스는 아닌 것 같습니다.
- 재배포 시 라이선스 고지 의무
- 사용 제한 조항 : 불법 목적, 미성년자 위해, 허위정보 유포, 개인정보 악용, 괴롭힘·명예훼손, 동의 없는 사칭·딥페이크, 차별적 사용, 의료 조언, 사법·수사·이민 판단 목적 등에는 사용할 수 없음
- 파생 모델에도 같은 사용 제한을 유지
- 출력물에 대한 책임은 사용자에게 있음
- 상표 사용이나 공식 보증을 암시하면 안 됨

6.사용 방법

설치는 Pypi를 이용해 진해합니다.

pip install supertonic

공개된 코드를 보면 아래와 같이 아주 심플합니다. 자동으로 모델 가중치는 다운로드 되며 언어 별 음성 파일을 다운 받는 방법 등은 github 저장소를 참고하면 됩니다. (python 쪽 설명은 이쪽으로)

from supertonic import TTS

tts = TTS(auto_download=True)
style = tts.get_voice_style(voice_name="M1")

text = "A gentle breeze moved through the open window while everyone listened to the story."
wav, duration = tts.synthesize(text, voice_style=style, lang="en")

tts.save_audio(wav, "output.wav")

Supertonic 3는 31개 언어를 지원하는 경량 온디바이스 TTS 모델로, GPU 없이도 로컬에서 빠르게 음성을 합성할 수 있도록 설계된 실용형 오픈웨이트 음성 합성 모델입니다. 얼마 전 소개한 Open Notebook에서 TTS 영역을 담당할 수 있게 수정하면 OpenAI의 tts를 사용하지 않아도 될 것 같아 시도해 볼만 할 것 같습니다. 아무쪼록 좋은 활용처를 발굴해서 잘 활용해 보시길...

[바이브코딩] 루빅스 큐브 만들기

42morrow — Sun, 17 May 2026 13:36:40 +0900

이번에는 남녀노소 누구나 좋아하는 퍼즐 놀이인 루빅스큐브를 웹 게임으로 만들어 봤습니다.

루빅스큐브를 떠올리면...

사실 저는 게임 쪽에는 소질이 없습니다. 어려서부터 자주 하지도 않았을 뿐더러, 어쩌다 하더라도 퍼즐을 붙잡고 오랫동안 고민한 적이 없었죠. 몇 번 시도해보다가 막히면 흠... 이건 내가 가지고 놀 장난감이 아닌가보다 하며 얼른 포기하고 다른 놀이를 찾았으니까요. 그래서, 실제로 몇 년 전까지만해도 루빅스큐브는 한개의 면을 맞추거나 혹은 어쩌다 우연히 두개의 면까지 맞추는 것이 다였습니다. 애초부터 6면을 맞추는 것을 목표에 두지 않았었죠.

왜 안 돼? 한번 해 보자!

그러다... 어느 날은 현타가 온 겁니다.

'이게 뭐라고 내가 한번도 성공을 하지 못하고 포기해야 하는거지?'

원리를 이해하기 힘들면 아예 방식을 외워서라도 해 보자 싶더군요. 그래서, 루빅스큐브를 설명하는 유튜브 영상들을 보면서 공식을 조사했습니다. 공식은 하나가 아니라 다양했습니다. 그 가운데 초보가 따라하기 쉬운 것을 하나 골랐고 그 내용을 정리했습니다. 참고로 이 공식은 프로가 사용하는 최단의 수는 아닙니다.

3x3x3 큐브의 공식 예시

상단 흰색 십자 맞추기 - 공식 없이 맞춤
옆면들 가운데 2줄 맞추기 - 내반올시내:오 (12-9에 두고.12-6시는 두번)
흰색 십자 아래로 보내기
옆면 ㅜ 자 만들기 - 올돌내 (윗면 색, 측면 색 맞추고, 좌우주의)
ㅜ자 밑에 채우기 - 돌올 돌내 돌돌 올돌내 (측면상단 흰색 + 측면색 2개 맞추고 , 좌우주의)
윗면 노란색 + 자 맞추기 - 시시시(앞우위) 내반반(오위앞)
+자 밑 3층 맞추기 -내돌 올돌 내돌돌 올돌:왼(9-6시 가운데 1자 맞춤)
윗면 다 맞추기 (U자 앞시,우올 반내시:앞좌앞)
옆면 다 맞추기 - 쩜 (윗면 우측 상단) 기준으로

전문가들은 방향과 위치에 각각의 기호를 두고 하던데, 저는 입으로 중얼거리면서 했기 때문에 제가 편한 방식으로 작성했기 때문에 그냥 봐선 잘 모를 수도 있습니다. 어찌됐건 대략 20번 정도 따라해가며 시행착오 끝에 공식대로 움직여 첫번째 성공을 맛봤고, 그 뒤부터는 대략 1.5분~2분 정도에 3x3x3 큐브는 맞출 수 있게 되었습니다. 처음 성공했을 때의 그 짜릿함이란... ^^;

루빅스큐브를 온라인 게임으로 만들어보면?

한동안 잊고 있다가 최근 바이브코딩으로 이것저것을 만들어보면서, 루빅스큐브도 추가하면 좋겠다 싶은 생각이 들었습니다. 스마트폰에서 손쉽게 가지고 놀 수 있는 루빅스큐브 게임으로 말이죠.

안드로이드 앱스토어를 찾아보면 루빅스큐브 앱이 많이 있습니다. 대부분 광고가 있거나 유료. 그냥 웹에서 손쉽게 할 수 있도록 하는 용도인데... 게다가 정답을 생성하는 Solver도 필요없이 그냥 동작하도록만 하면 되는데 굳이... 하는 생각이 들었습니다. 그래서 단일 HTML로 동작하는 것을 만들어 봤습니다.

사용된 기술 스택

단일 HTML로 구현
Three.js (3D 렌더링) + Vite
터치 이벤트 (모바일용) 지원
게임 포털을 위한 보일러 플레이트 템플릿 적용

역시나 시행착오들...

3D 큐브의 기본을 생성하고 회전하는 것 등은 바이브코딩으로 생각보다 쉽게 해결되었습니다. 그런데, 큐브 면의 회전 방향과 방식에서 제법 많은 시행착오가 있었습니다. 이런 식으로 동작해야 한다는 지침이 제대로 작성되지 않은 것인지 대부분의 방향에서는 문제가 없는데 특정 상황에서 계속 회전 방향이 반대로 나왔고, 지시수정을 고쳐가며 해 봤지만 계속 해결되지 않아서 고생을 했습니다.

문제는 뷰에서 루빅스 큐브 전체를 회전시키는 기능을 구현하면서 PerspectiveCamera 객체를 이용했는데, 이 때문인지 큐브 면 회전, 큐브 전체 회전 등에서 꼬인 부분이 있었던 모양이었습니다. 그래서, 회전 알고리즘 설계를 다시 진행하도록 한 후에 문제가 해결되었습니다.

최종 결과물

이렇게 해서 나온 결과물은 다음과 같습니다. 상용 솔루션에는 못 따라가겠지만 혼자서 즐기는 용도로는 괜찮은 것 같습니다. 하지만, 8번 이후의 공식은 물리 큐브를 가지고 할 때 손 전체로 기억했던 것을 손가락으로 하려니 계속해서 실수를 하는 바람에 그 이상으로 진행을 못하고 있습니다.

실제 큐브를 다루는 영상입니다. 화면 캡처를 위해 마우스로 하고 있는데 역시 서투네요. ^^;

Gaussian Splat을 이용해 현실감있는 FPS 게임을 만든다?

42morrow — Sat, 16 May 2026 15:09:58 +0900

Gaussian Splatting은 현실 공간을 사진처럼 생생한 3D 배경으로 만들 수 있는 기술입니다. 최근 이 기술에 충돌 처리, NPC 이동, 조명 보정, 게임 로직 등을 추가해 실제로 플레이 가능한 웹 기반 3D 게임으로 확장하는 기술이 소개되었습니다.

Turning a Gaussian Splat Into a Videogame | PlayCanvas Blog

How I turned a photogrammetric 3D Gaussian Splat scene into a playable browser FPS - with collision, pre-baked lighting, navmesh-driven NPCs and behavior-tree AI, all in PlayCanvas.

blog.playcanvas.com

이번 글에서는 그 내용을 간단히 소개하겠습니다.

1. 개요

위에 링크된 PlayCanvas의 블로그 글은 Gaussian Splatting을 이용해 만든 실제 같은 폐건물 3D 실내 공간에서 FPS 게임을 구현한 사례를 소개하고 있습니다. 실제 공간을 3D로 스캔한 데이터를 게임처럼 움직일 수 있는 공간으로 바꾸는 방법이 적용된 것인데, 앞서 설명한 것과 같이 사용된 핵심 기술은 Gaussian Splatting입니다.

그림 : 실제 건물의 Gaussian Splat을 FPS 게임에 적용한 예시

2. 왜 그냥 게임으로 쓸 수 없을까?

그런데 이상한 부분이 있습니다. Gaussian Splat으로 생성한 공간으로 바로 게임을 만들면 되지 않을까 싶은데 그건 얘기가 다른 모양입니다. Gaussian Splat으로 만든 3D 공간은 보기에는 매우 사실적이지만 게임에 바로 사용하기에는 다음과 같은 제약사항이 있기 때문이라고 합니다.

벽이나 바닥을 실제 물체로 인식하지 못함
캐릭터가 바닥 위를 걷지 못함
총알이 벽에 부딪히지 않음
NPC가 어디로 이동해야 하는지 알 수 없음
일반 3D 캐릭터나 무기가 배경과 어색하게 보일 수 있음

Gaussian Splat은 보기에는 멋진 3D 공간이지만, 게임 엔진 입장에서는 아직 실제로 상호작용할 수 있는 게임 맵은 아니게 됩니다. 물리법칙이 적용되지 않기 때문인 것이죠.

3. 핵심 접근 방법 = Gaussian Splat + 게임 기능 요소 추가

그래서 이를 해결하는 방법으로 택한 것이 Gaussian Splat 위에 게임에 필요한 기능을 하나씩 추가하는 것입니다.

시각적 배경 : Gaussian Splat을 사용해 실제 공간처럼 보이는 배경을 만듭니다.
충돌 처리 : 캐릭터가 벽을 통과하지 않고 바닥 위를 걸을 수 있도록 충돌용 3D 구조를 따로 만듭니다.
NPC 이동 : NPC가 이동 가능한 길을 알 수 있도록 내비메시를 만듭니다.
조명 보정 : 캐릭터, 무기, 아이템이 배경과 따로 노는 느낌이 들지 않도록 주변 밝기에 맞게 보정합니다.
게임 로직 : FPS 캐릭터 조작, 총격, NPC AI, 아이템 등을 추가해 실제 게임처럼 동작하게 만듭니다.

그림 : 가져온 Gaussian Splat에 충돌 컴포넌트(메시)와 강체 컴포넌트를 적용한 결과

쉽게 비유하면 Gaussian Splat은 실제 장소를 찍어 만든 아름다운 3D 무대인데, 무대만 있다고 게임이 되는 것은 아니기 때문에

다음 요소들을 추가해 3D 스캔 공간을 실제 게임 맵으로 바꾸는 과정이 필요합니다.

사람이 걸어 다닐 수 있는 바닥
막혀 있는 벽
적 캐릭터가 이동할 수 있는 길
총알이 부딪히는 구조
캐릭터와 배경이 자연스럽게 어울리는 조명
플레이어 조작과 게임 규칙

즉, Gaussian Splat으로 생성된 공간은 겉보기 화면인 것이고, 실제 게임을 위한 공간이 뒤에 숨어 있는 셈입니다. 그러다보니 그냥 지나가거나 하는 장면이 아닌 문을 열거나 벽을 부수거나 하는 복잡한 상호작용의 경우에는 별도로 구현을 해야 한다는 제약사항도 있습니다.

4. 이렇게 하면 어떤 장점이 있는가?

어찌보면 이렇게 하는 것이 이중 작업이 필요한 것이라 더 힘들 것 같은데 싶기도 하지만, 다음과 같은 장점들이 떠오릅니다.

첫째, 실제 공간을 이용하므로 현실공간의 느낌을 그대로 살릴 수 있고,
둘째, Gaussian Splat을 AI를 이용해 생성하는 것은 3D 모델링과 렌더링 작업에 비하면 훨씬 공수/비용이 적게 드는 작업이며,
세째, 숨은 공간에 대한 디테일한 처리(정밀 모델링이나 렌더링 등등)를 줄일 수 있다는 장점이 있음

5. 참고자료

블로그) 가우시안 스플랫을 비디오 게임으로 만들기 (링크)
영상) 게임 영상 (링크)
데모) FPS 게임 (링크)

Gaussian Splatting 기술은 부동산이나 전시, 교육, 가상 투어, 체험형 콘텐츠 등의 영역에서 많이 사용되는 것으로 알려져 있습니다. 그런데 이렇게 FPS 게임 같은 것에도 적용 가능하다는 생각을 못했었는데 실제 그렇게 만들어진 결과물 영상을 보고 감탄할 수 밖에 없었습니다. 앞으로도 이렇게 상식을 깨는 새로운 시도들이 많이많이 나와줬으면 좋겠습니다. 제 뇌세포가 긴장을 많이 할 수 있도록 말이죠. ^^;

Open Notebook : 내 자료를 바탕으로 생각하고 정리하는 오픈소스 노트북

42morrow — Thu, 14 May 2026 16:23:37 +0900

AI로 문서를 읽고, 요약하고, 질문까지 주고받는 도구는 이제 꽤 많습니다. 그중 잘 알려진 것으로는 구글의 NotebookLM이 있죠. 처음 이 도구에 대한 소개 영상을 접했을 때의 충격을 아직 잊지 못합니다. 논문 PDF 파일을 로딩 후 실제 전문가 두 사람이 대화하며 내용에 대해 논의하는 것 같은 팟캐스트가 생성되는 것을 이전에는 상상도 못했었던 일이었으니까요.

제 경우, ChatGPT를 주로 사용 중이라 구글 쪽 AI 도구에 대한 경험이 별로 없습니다. 이중으로 구독료를 내는 여유를 부릴 필요를 아직 느끼진 못했거든요. 하지만, 늘 NotebookLM 같은 서비스가 오픈소스로 나오면 좋겠다는 생각은 하고 있었습니다. 실제 그 이후 유사 서비스가 하나둘씩 소개되어 왔고 그런 것들 중 최근 공개된 것이 Open Notebook입니다. 흠... 이젠 내 컴퓨터에서 실제로 테스트를 해 볼 수 있겠군 싶은 단계까지 왔다 싶어 정리해 봅니다.

1.개요

Open Notebook은 '내 자료를 기반으로 AI와 대화하는 연구/학습용 노트북'이라는 점에서는 Google의 NotebookLM과 비슷하지만, 방향은 조금 다른 점이 있습니다. 빅테크 플랫폼 업체가 제공하는 서비스를 이용하는 것이 아니라, 솔루션이 제공하는 오픈소스, 자체호스팅, 멀티 모델 선택, REST API 연동을 통해 내가 구축하고 이를 이용한 개인적인 지식창고를 구성할 수 있는 작업 플랫폼이라고 할 수 있거든요.

Open Notebook은 여러 자료를 한 노트북 안에 모아 두고, 그 자료를 바탕으로 AI와 대화하거나 검색하고, 노트를 만들고, 오디오 콘텐츠까지 생성할 수 있는 도구입니다. 공식 사용자 가이드는 소스 추가, 노트 작성, 채팅, 팟캐스트 생성, 검색, 변환, 인용, API 설정을 핵심 사용 흐름으로 제시합니다. 즉, '문서 몇 개 넣고 질문하는 앱'을 넘어, 자료 수집 → 이해 → 정리 → 재가공까지 한 번에 다룰 수 있는 구조를 가지고 있습니다.

2.핵심 기능

자료 수집 : PDF, 웹 링크, 오디오, 비디오, 텍스트 등 다양한 형태의 자료를 노트북에 넣을 수 있습니다.
자료 기반 채팅 : 업로드한 자료를 문맥으로 삼아 질문하고, 어떤 소스를 AI에 보여줄지 컨텍스트를 조절할 수 있습니다.
노트 정리 : 수동 노트 작성, AI 응답 저장, 태그/이름 기반 정리가 가능합니다.
검색 : 텍스트 검색과 벡터 검색을 모두 지원하고, Ask 기능으로 종합 답변도 받을 수 있습니다.
변환 작업 : 여러 문서에 같은 템플릿을 적용해 요약, 인사이트 추출 같은 작업을 반복 처리할 수 있습니다.
오디오/팟캐스트 생성 : 연구 내용을 듣기 쉬운 오디오 대화 형식으로 바꿀 수 있습니다. 이게 제일 해 보고 싶었던 기능입니다. ^^;
기타 : 영어, 포르투갈어, 중국어(간체 및 번체), 일본어, 러시아어, 벵골어 지원

3.특징 및 특장점

Open Notebook의 철학은 '내 데이터는 내가 가진다'는 철학입니다. ('내가 인프라가 없지 데이터가 없나~' 하는 ) 기본적으로 사용자 데이터와 연구 자료가 기본적으로 사용자 통제 아래 있어야 하며, 자체 호스팅에 배포하는 것이 목표라는 것이죠. 또한 특정 클라우드에 강하게 묶이지 않도록 하고, 로컬 Ollama 모델도 지원합니다. 이런 점 때문에 민감한 문서, 사내 자료, 개인 연구 자료를 다룰 때 매력적입니다.

또 하나의 장점은 모델 선택의 자유입니다. 공식 문서에는 Open Notebook이 17개 이상 AI provider를 지원한다고 되어 있고, 설정 UI에서 자격 증명을 넣고 연결 테스트, 모델 탐색, 모델 등록까지 진행할 수 있다고 소개하고 있습니다. 즉, OpenAI만 쓰는 것이 아니라 Anthropic, Google, Ollama, OpenAI-compatible 엔드포인트 등으로 유연하게 바꿔 쓸 수 있습니다. 비용이나 품질, 프라이버시 요구에 따라 선택지를 가져갈 수 있다는 뜻입니다.

개발자 관점에서는 REST API 제공도 강점입니다. 공식 API 문서는 기본 백엔드 주소와 Swagger UI까지 안내하고 있어, 단순 사용 앱이 아니라 다른 서비스와 연동 가능한 시스템으로도 볼 수 있습니다.

4.Google NotebookLM와 비교

얼핏보면 겉모습은 비슷합니다. 둘 다 자료를 모아 놓고, 그 자료를 바탕으로 AI가 답하고 요약하는 구조니까요. 하지만, 몇 가지 차이가 있습니다.

Open Notebook은 오픈소스·자체호스팅·모델 선택 자유, 커스터마이징 지원 등이 강점입니다.
NotebookLM은 설치 없이 바로 쓰는 관리형 서비스로서의 편의성과 Google 생태계 연동이 강점입니다.
Open Notebook은 인프라 자체를 사용자가 통제할 수 있다는 점이 강점입니다.
NotebookLM은 구글 공식 안내에 따르면 업로드한 소스는 공유하지 않는 한 비공개이며, 업로드한 데이터로 모델을 학습하지 않는다고 명시되어 있긴 하지만 혹시나 하는 불안감을 주는 것은 어쩔 수 없는 것 같습니다.아무래도 관리형 보안 모델의 한계랄까요.

5.사용방법

기본적인 시스템 요구사항은 다음과 같습니다.

Docker Engine 구동
4GB 이상의 RAM
2GB 가량의 디스크 여유 공간 (많을수록 좋음)
OpenAI, Anthropic, Gemini, OpenRouter 등의 API Key (테스트는 Gemini 무료 제공 Key로 진행하면 됨)
또는 Ollama 환경 구성 (이를 위한 시스템 요구사항은 별도)

1) Docker Desktop 설치 (링크)

2) Open Notebook을 위한 Docker Compose 파일(docker-compose.yml) 생성

다음과 같은 파일을 생성합니다. 추가로 아래는

기본 제공되는 내용과는 달리 docker가 동작하는 호스트 장비의 Ollama 서비스를 이용하는 방식으로 설정했습니다.
즉, 기본 내용에서 ollama: 부분을 삭제하고 extra_hosts를 추가하는 방식으로 설정된 것입니다.
docker의 brdige 네트워크를 고정 IP로 설정합니다. (방화벽 허용도 이에 맞춥니다)

services:
  surrealdb:
    image: surrealdb/surrealdb:v2
    command: start --log info --user root --pass root rocksdb:/mydata/mydatabase.db
    user: root
    ports:
      - "8000:8000"
    volumes:
      - ./surreal_data:/mydata
    environment:
      - SURREAL_EXPERIMENTAL_GRAPHQL=true
    restart: always
    pull_policy: always

  open_notebook:
    image: lfnovo/open_notebook:v1-latest
    ports:
      - "8502:8502"
      - "5055:5055"
    environment:
      - OPEN_NOTEBOOK_ENCRYPTION_KEY=키값
      - SURREAL_URL=ws://surrealdb:8000/rpc
      - SURREAL_USER=root
      - SURREAL_PASSWORD=root
      - SURREAL_NAMESPACE=open_notebook
      - SURREAL_DATABASE=open_notebook

      # 브라우저가 붙을 Open Notebook API 주소
      # 같은 PC에서 접속하면 localhost로 두면 됩니다.
      - API_URL=http://localhost:5055

      # 호스트에서 이미 실행 중인 Ollama 사용
      - OLLAMA_BASE_URL=http://host.docker.internal:11434
      - OLLAMA_API_BASE=http://host.docker.internal:11434

    extra_hosts:
      - "host.docker.internal:host-gateway"

    volumes:
      - ./notebook_data:/app/data
    depends_on:
      - surrealdb
    restart: always
    pull_policy: always


networks:
  default:
    ipam:
      config:
        - subnet: 172.19.0.0/16

3) 로컬 Ollama 서비스 작동 확인

Docker Container에서 연결할 ollama 서비스가가 제대로 동작하고 있는지 확인합니다.

$ ollama ps
NAME              ID              SIZE     PROCESSOR    CONTEXT    UNTIL   
qwen3.5:latest    6488c96fa5fa    10 GB    100% GPU     32768      Forever

주의) ollama가 기본은 localhost(127.0.0.1)에서 동작하도록 되어 있을 겁니다. 그러면 docker container에서 host의 ollama 접속이 안 될 수 있습니다. 그러므로, 호스트 쪽의 ollama를 localhost only가 아닌 전체 접속 가능으로 변경하는 작업이 필요할 수 있습니다. 그럴 경우 아래와 같이 진행합니다.

# ollama 서비스 스크립트 수정
$ sudo systemctl edit ollama.service

# 아래 내용 추가
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

4) Docker 서비스 시작

Docker Container 서비스를 시작합니다. docker 이미지 다운로드가 이뤄지고 나서, 모든 것이 정상적으로 설정되어 있다면 아래와 같이 올라올 겁니다.

# docker 컨테이너 실행
# 이미 돌고 있다면 docker compose down 후 실행
$ docker compose up -d
...
[+] up 0/2
[+] up 2/3urrealdb/surrealdb:v2         Pulling                                                                          2.0s 
 ✔ Image surrealdb/surrealdb:v2         Pulled                                                                           2.1s 
[+] up 5/5fnovo/open_notebook:v1-latest Pulled                                                                           2.0s 
 ✔ Image surrealdb/surrealdb:v2           Pulled                                                                         2.1s 
 ✔ Image lfnovo/open_notebook:v1-latest   Pulled                                                                         2.0s  ✔ Network opennotebook_default           Created                                                                        0.3s 
 ✔ Container opennotebook-surrealdb-1     Created                                                                        0.0s 
 ✔ Container opennotebook-open_notebook-1 Created 

# docker 컨테이너 프로세스 확인
$ docker compose ps 
NAME                           IMAGE                            COMMAND                   SERVICE         CREATED         STATUS         PORTS
opennotebook-open_notebook-1   lfnovo/open_notebook:v1-latest   "/usr/bin/supervisor…"   open_notebook   8 seconds ago   Up 7 seconds   0.0.0.0:5055->5055/tcp, [::]:5055->5055/tcp, 0.0.0.0:8502->8502/tcp, [::]:8502->8502/tcp
opennotebook-surrealdb-1       surrealdb/surrealdb:v2           "/surreal start --lo…"   surrealdb       8 seconds ago   Up 7 seconds   0.0.0.0:8000->8000/tcp, [::]:8000->8000/tcp


# REST API 동작 여부 재확인
$ curl http://localhost:5055/health
{"status":"healthy"}

5) 테스트

브라우저에서 localhost:8502로 접속합니다. 로딩 시 모델 불러오는데 시간이 소요되므로 접속은 20초 정도 후에 진행합니다.

이제 기본 설정 작업은 모두 끝났습니다.

1️⃣ AI 모델 설정

화면이 열리면 설정에서 Models를 눌러 특정 모델을 이용하도록 설정할 수도 있습니다. 제 경우엔 디폴트로 qwen3.5:latest를 지정했습니다. Embedding Model도 등록해야 합니다. 그래서 nomic-embed-text:latest를 설정했습니다.

제 경우 설정값은 다음과 같습니다. 모두 ollama에서 돌아갑니다.)

Chat Model (필수) : Qwen3.5:latest
Embedding Model (필수) : nomic-embed-text:latest
Transformation Model (필수) : Qwen3.5:latest
Tools Model : Qwen3.5:latest
Large Context Model : Qwen3.5:latest

텍스트 처리하는 것은 Ollama의 Qwen3.5:latest를 이용하고 Podcast 생성에는 TTS, STT가 필요해서 추가로 OpenAI API Key도 등록했습니다. (여기서는 TTS에 tts-1, STT에 Whisper-1을 설정) API로 거의 사용해 본 적이 없어서 이 모델이 적당한 것인지 잘은 모릅니다만... 일단 생성이 되는지 체크하는 용도이니 괜찮을 것 같습니다.

2️⃣ Nodebook 생성 및 테스트

이제 Source에 논문 PDF 파일을 추가하고 이를 로드해 질의/답변을 진행해 봅니다. 예전에 소개했던 XSKILL 관련 논문 내용입니다. Notebook에서 하는 Chat은 ChatGPT 의 채팅 창에서 하는 작업과 크게 다르지 않아 보입니다. 다만, 사용할 수 있는 소스가 URL, Text, 문서 등등 다양하며 이를 한번에 처리할 수 있다는 것이 차이점 같습니다.

3️⃣ Podcast 생성

Podcast를 생성해 보겠습니다. Meta가 최근 공개한 SAPIENS2 라는 모델의 논문을 이용해서 2명의 기술 전문가가 대담하는 방식으로 진행해 봅니다.

그림 : Podcast 생성 작업 화면 예시

생성을 클릭했는데 화면에는 작업이 Queue 되었다. 그리고 시작되었다는 알림메시지만 보이고 목록에 추가되지 않는 겁니다. 흠... 뭔가 잘못됐나 싶었는데 Ctrl+Shift+R 로 리프레시 하니까 목록이 나왔고 Processing 중이라고 표시됩니다. 그리곤 열심히 GPU 팬 돌아가는 소리가 들렸습니다.

그림 : Podcast 생성 작업 목록 (우), nvitop으로 확인한 GPU 사용률 (좌)

Podcast 생성이 완료되면 다음과 같이 나옵니다. 유료 NotebookLM에서 생성하는 것처럼 괜찮은 수준으로 나옵니다. 물론 말하는 억양 등을 고려하면 좀 더 하이레벨의 TTS 모델을 적용해야겠지만 말이죠.

그림 : Podcast 생성 작업이 완료된 예시

생성된 podcast에 대한 개요, 아웃라인, 스크립트도 확인할 수 있습니다. 아래와 같이. 꽤 괜찮죠?

그림 : Podcast 작업 개요, Outline, transcription

그런데... 생성할 때 기본 Instruction만 적용했더니 영어 대화 파일로 생성되었습니다. Profile에서 언어를 한국어로 설정했도 말입니다. 그래서 다음과 같이 생성 시 지시어에서 한국어를 사용하도록 명시했습니다. 그랬더니 제대로 나오네요. 같은 파일, 같은 내용일텐데 한국어 버전은 약 12분, 영어는 19분 길이의 음성이 생성되었습니다.

Please ensure that all dialogue and the host's script are written exclusively in Korean. 
Minimize the use of English words and converse in natural, colloquial Korean.

그림 : 한글 명시적 생성 지시어가 적용된 결과물

참고자료

공식 소개글 (링크)
공식 Getting Started 문서 (링크)
Ollama를 이용하는 경우, 설정 방법 (링크)

Open Notebook은 NotebookLM 같은 경험을, 더 많이 통제하고 더 깊게 커스터마이즈하고 싶은 사람에게 잘 맞는 도구라 생각됩니다. 반대로 설치나 운영 부담 없이 바로 쓰고 싶다면 NotebookLM 쪽이 더 편할 수 있습니다. 물론 비용은 약간 들겠지만 말이죠. 결국 선택 기준은 기능 수보다도 통제권을 중시하느냐, 관리형 편의성을 중시하느냐에 가깝습니다.

NotebookLM을 잘 활용하는 조직이나 인재가 있다면 회사 내에서 이 시스템을 구축해두고 사람들이 쉽게 접근할 수 있도록 개방해 두는 것도 좋을 것 같습니다.

오늘부터 저도 가끔씩 이걸 활용하면 실생활에 어떤 효용이 있을지 점검 테스트를 진행해 볼까 합니다. ^^

[우분투] UFW 방화벽에서 규칙 삭제하는 방법

42morrow — Wed, 13 May 2026 14:51:30 +0900

UFW를 이용해 방화벽 설정이 되어 있는 경우, 설정된 값을 한번에 여러개 삭제할 때 사용하는 방법입니다.

1) 현재 설정된 값 보기

sudo ufw status numbered
[ 1] 11434/tcp                   ALLOW IN    Anywhere
[ 2] 8000/tcp                    ALLOW IN    Anywhere
[ 3] 5055/tcp                    ALLOW IN    Anywhere
[ 4] 8502/tcp                    ALLOW IN    Anywhere

2) 번호를 이용한 목록 삭제

삭제 시 번호가 뒤로 밀리므로 큰 번호부터 삭제하는 것이 편합니다.

sudo ufw delete 4
sudo ufw delete 3
sudo ufw delete 2
sudo ufw delete 1

3) 특정 대역으로 열어둔 규칙 삭제

특정 대역으로 열어둔 룰의 경우는 다음과 같이 처리합니다.

sudo ufw delete allow proto tcp from 172.19.0.0/16 to any port 11434

4) 여러 개의 룰을 한번에 삭제

다음과 같이 쉘 스크립트를 for 문으로 돌립니다.

for p in 11434 8000 5055 8502; do
  sudo ufw delete allow ${p}/tcp
done

5.전체 룰을 다 삭제하고 다시 시작

하나씩 지우는 것도 귀찮다... 그럴 경우에는 다음과 같이 한번에 초기화합니다. (단... 이런 경우는 그래도 주의하세요!)

sudo ufw reset

ByteDance의 Gauth : 주제만 제시하면 인터랙티브 교육 자료 생성해 주는 서비스

42morrow — Tue, 12 May 2026 11:14:10 +0900

ByteDance에서 제공하는 교육 카테고리에 속하는 Gauth라는 서비스가 소개되었습니다. 주제 내용만 제시하면 그와 관련된 인터랙티브한 비주얼 자료를 생성해 주는데 소개된 영상 (링크)을 보면 너무 훌륭해서 충격을 받았습니다.

그림 : 생성된 예시 자료 영상의 한 장면

그래도 소개 영상이니 체리피킹을 했겠지싶어, 서비스 사이트에 들어가서 'Korean War'라는 키워드를 입력해서 생성해 봤습니다. 전쟁 당시의 지도나 전개 과정에 대한 설명 등이 생성되는 것을 볼 수 있었습니다. 그래... 정적인 이미지와 내용 생성 정도네... 하고 넘어가려 했는데...

혹시나 하는 마음에 이미지 상의 특정 부분 (예: '인천 상륙작전' 부분)을 클릭해 봤더니 더 자세한 내용의 그림이 일목요연하게 생성되는 것을 볼 수 있었습니다. 오호.... 이미지 맵 상에서 특정 부분을 키워드 삼아 위키처럼 링크를 거는 방식으로 세부적으로 들어가는 것으로 보입니다. 클릭을 하면 해당 내용을 이용해 다시 상세한 페이지를 만드는데 영상에서는 정적인 이미지만 아니라 영상(애니메이션)을 생성해서 보여주기도 합니다.

38선 부분을 클릭하면 다음과 같이 나오구요. 우와...

그림 : 38선을 클릭하면 보여지는 장면

최근 전해지는 소식들을 보면 이렇게 고객의 최초이자 마지막 접점이 AI가 되어, 요구사항을 대응해 주는 트렌드가 이미 디자인이나 앱 시장에서는 주가 되고 있는 것 같습니다.

AI로 동작하는 운영체제가 나올거라는 얘기도 있고, 앱스토어가 의미가 없어질 것이란 얘기도 있습니다. 앱 대신 개별 앱이 해오던 작업을 AI가 바로 수행하고 결과를 전달할 수 있게 되고 있으니 말입니다. 디자인 영역에서는 디자이너가 디자인 전문 도구를 이용해 결과물을 만들어내던 과정을 AI가 요구사항만 듣고 직접 만들어 주는 것으로 대체되고 있다는 것은 이미 오래전부터 알려진 일이기도 합니다.

이렇게 AI가 교육 자료를 고품질로 뚝딱 만들어줄 수 있게 되면, 앞으로 교육 시장은 어떻게 변하게 될까 궁금해집니다. 교사 입장에서는 교육 자료를 미리 만드는 수고를 많이 덜 수 있을 겁니다. 하지만, 이런 시청각 교육자료를 만들어 제공하던 사업자들은 살아남기 위해 다른 대안을 마련해야 하는 위기를 맞게 되겠죠. 어느 영역이건 안전해 보이는 곳을 찾긴 어렵습니다. 흠... 다들 건승하시길...

SSA : 긴 문서를 통째로 넣어도 빠르게 답하는 AI 기술

42morrow — Fri, 8 May 2026 13:05:29 +0900

SubQ라는 곳에서 SSA (Subquadratic Sparse Attention)라는 기술을 이용한 모델을 소개했습니다. (링크)

SubQ 글의 핵심은 '긴 문서를 통째로 넣는 것보다, 그 긴 문서 안에서 정말 필요한 부분을 빠르고 정확하게 찾아 쓰는 것이 더 중요하다'는 것입니다. 이 글은 SubQ가 만든 SSA라는 attention 방식이 긴 컨텍스트를 실제 서비스에서 더 싸고 빠르게 쓸 수 있게 만든다고 설명합니다.

1. 왜 긴 컨텍스트가 어려운가?

일반적인 AI 모델의 attention은 입력된 모든 토큰이 서로를 전부 비교합니다.

쉽게 말하면, 문서가 10쪽이면 서로 비교할 양이 적지만, 문서가 1,000쪽이면 모든 문장끼리 계속 비교해야 해서 비용이 폭발적으로 늘어나게 됩니다. 글에서는 이를 quadratic cost, 즉 입력 길이가 2배가 되면 계산량은 대략 4배가 되는 문제로 설명합니다. 특히 코드베이스, 계약서, 연구자료, 기업 문서처럼 정보가 여러 곳에 흩어져 있는 작업에서는 이 문제가 당연히 더 커지게 됩니다.

2. 기존 해결 방식의 한계

기존 방식들이 긴 문맥 문제를 완전히 해결하지 못한다고 보며, 이런 방식들을 '긴 문백을 잘 다루는 모델'이 아니라 '긴 문맥 문제를 피해가기 위한 보조도구'에 가깝게 판단합니다.

방식	설명	한계
RAG	문서를 조각내서 관련 부분만 검색	위치, 문서 구조, 앞뒤 맥락이 손실될 수 있음
요약	긴 내용을 짧게 압축	중요한 세부 조건이 빠질 수 있음
에이전트 분할	큰 작업을 여러 작은 호출로 나눔	단계마다 오류가 누적될 수 있음
Sparse Attention	일부 위치만 보게 함	고정 패턴이면 중요한 정보를 놓칠 수 있음
State Space / Recurrent 계열	정보를 압축 상태로 전달	오래전의 정확한 세부 정보를 다시 꺼내기 어려울 수 있음

3. SSA는 무엇인가?

SSA (Subquadratic Sparse Attention 또는 Subquadratic Selective Attention)는 모든 토큰을 전부 비교하지 않고, 현재 답변에 중요해 보이는 위치만 골라서 attention을 계산하는 방식입니다. 즉, dense attention은 '전부 다 훑어보기' 방식이고, SSA는 '필요한 곳을 골라 보기' 방식이라고 보면 됩니다.

중요한 점은 SSA가 단순히 위치 기준으로 띄엄띄엄 보는 것이 아니라, 내용을 보고 어디를 볼지 선택한다는 점입니다. 그래서 중요한 정보가 문서 앞쪽, 중간, 끝쪽 어디에 있어도 선택될 수 있다고 설명합니다.

4. SSA의 장점

글에서 말하는 SSA의 장점은 크게 세 가지입니다.

계산량과 메모리 사용이 선형적으로 증가
입력이 길어져도 dense attention처럼 비용이 급격히 폭발하지 않도록 설계되었다고 합니다.
내용 기반 선택
위치가 아니라 의미를 보고 어디를 참고할지 고릅니다.
긴 문서 속 특정 정보 검색에 강함
단순 요약이나 압축 방식이 아니라, 오래전에 나온 구체적인 정보도 다시 찾아 쓸 수 있도록 설계되었다고 합니다.

5. 성능 결과 요약

글에서 제시한 주요 수치는 다음과 같습니다.

항목	결과
128K 토큰 입력 처리	FlashAttention-2 대비 7.2배 빠름
256K 토큰	13.2배 빠름
512K 토큰	23.0배 빠름
1M 토큰	52.2배 빠름
1M 토큰 attention FLOP 감소	표준 attention 대비 62.5배 감소
RULER @ 128K	SSA/SubQ 95.0%
MRCR v2	SSA/SubQ 65.9%
SWE-Bench Verified	SSA/SubQ 81.8%

이 글은 특히 1M 토큰에서 52.2배 prefill 속도 향상을 강조합니다. (prefill은 긴 입력을 모델이 처음 읽고 처리하는 단계) 긴 문서를 넣었을 때 답변이 시작되기 전까지 걸리는 시간이 크게 줄어드는 효과라고 보면 됩니다.

6. '긴 컨텍스트'의 진짜 의미

어떤 모델이 '100만 토큰을 넣을 수 있다'고 해서 반드시 그 안의 정보를 잘 이해하고 활용한다는 뜻은 아닙니다. 글에서는 명목상 컨텍스트와 기능적 켄텍스트로 나누고 있는데, SSA는 후자로 SubQ는 SSA가 단순히 긴 입력을 받는 수준을 넘어, 긴 입력 안에서 관련 증거를 찾아 연결하는 데 초점을 둔다고 설명합니다.

일반 dense attention은 마치 도서관의 모든 책, 모든 페이지, 모든 문장을 서로 비교하면서 답을 찾는 방식과 같고, SSA는 질문을 보고, 관련 있어 보이는 책장과 페이지를 빠르게 골라서 그 부분만 정밀하게 읽는 방식에 가깝다고 할 수 있습니다.

SSA는 긴 문서를 전부 무식하게 비교하지 않고, 내용상 중요한 부분만 골라 attention을 계산해서 긴 컨텍스트를 더 빠르고 저렴하게 쓰려는 attention 구조입니다. 이 글의 핵심 주장은 '긴 입력을 받을 수 있는 모델'보다 긴 입력 안에서 필요한 정보를 실제로 찾아 추론할 수 있는 모델이 중요하다는 것입니다.

아직은 모든 사람에게 완전히 공개된 것은 아니어서 검증이 많이 되진 않은 것 같습니다. (2026.5.6 기준으로 Early Access가 제공됨) 그런데, X 포스트에 소개된 것처럼 100만 토큰 기준으로 사용 비용이 Opus의 1/10 수준이 된다면 생각보다 파장은 커지지 않을까 싶습니다.

XSKILL : 멀티모달 에이전트가 경험과 스킬로 계속 배우는 방법

42morrow — Thu, 7 May 2026 16:26:30 +0900

요즘 인공지능은 단순히 질문에 답하는 수준을 넘어, 이미지를 보고 도구를 사용하며 문제를 해결하는 방향으로 발전하고 있습니다. 예를 들어 사진 속 작은 물체를 확대하고, 이미지를 회전하고, 웹 검색까지 연결해 답을 찾는 식입니다. 이런 AI를 보통 '멀티모달 에이전트'라고 부릅니다. 여기서 멀티모달은 텍스트, 이미지, 웹 정보처럼 여러 종류의 정보를 함께 다룬다는 뜻입니다.

하지만 이런 에이전트도 아직 사람처럼 자연스럽게 배우지는 못합니다. 같은 실수를 반복하거나, 쉬운 문제에 도구를 너무 많이 쓰고, 어려운 문제에서는 필요한 도구 조합을 놓치기도 합니다. XSKILL에서는 이런 문제를 해결하기 위해, AI가 과거 풀이 과정에서 '경험'과 '스킬'을 따로 저장하고, 다음 문제를 풀 때 다시 꺼내 쓰는 방식을 제안합니다. 모델을 다시 학습시키지 않고도 성능을 높이는 방식이라는 점이 특징입니다.

1) 기존 방식의 문제점

기존 멀티모달 에이전트는 도구를 사용할 수는 있지만, 도구를 '잘' 쓰는 데 한계가 있습니다. 쉬운 문제에서도 불필요하게 여러 단계를 거치거나, 반대로 복잡한 문제에서는 충분히 탐색하지 못합니다.

또 다른 문제는 도구 조합이 유연하지 않다는 점입니다. 예를 들어 이미지가 거꾸로 되어 있으면 먼저 회전해야 하고, 물체가 작으면 잘라서 확대해야 합니다. 하지만 기존 방식은 이런 판단을 매번 새로 해야 하므로 실수를 반복하기 쉽습니다.

용어 설명

에이전트 : 목표를 달성하기 위해 스스로 판단하고 도구를 사용하는 AI 시스템
도구 오케스트레이션 : 여러 도구를 알맞은 순서로 조합해 쓰는 방식
파라미터 업데이트 없음 : AI 모델 자체를 다시 훈련하지 않는다는 뜻

2) 접근 방식

XSKILL은 과거 문제 풀이 기록에서 두 종류의 지식을 뽑아냅니다. 하나는 '경험'이고, 다른 하나는 '스킬'입니다. 논문에서는 이 두 지식을 함께 쓰면, 에이전트가 더 안정적으로 도구를 쓰고 새로운 문제에도 더 잘 대응한다고 설명합니다.

경험 : 특정 상황에서 어떤 행동이 좋았는지 알려주는 짧은 조언. (예) '이미지가 어두우면 먼저 밝기를 조정하라' 같은 형태
스킬 : 더 큰 단위의 절차. (예) '작은 물체 식별 문제에서는 이미지 자르기 → 확대 → 이미지 검색'처럼 여러 단계를 묶은 작업 흐름

그림 : XSKILL 적용 전후의 멀티모달 추론 과정 비교

위의 그림에서는, 일반 에이전트는 이미지가 뒤집혀 있거나 물체가 작다는 점을 놓쳐 실패할 수 있지만, SKILL은 과거 경험을 떠올려 이미지를 회전하고, 필요한 부분을 자른 뒤 검색하는 계획을 세우는 차이를 보여주고 있습니다.

3) 모델/기술 아키텍처

논문의 핵심 구조는 두 단계로 나뉩니다. (아래 그림 참고)

축적 단계 :
에이전트가 같은 문제를 여러 방식으로 풀어 보고, 성공한 풀이와 실패한 풀이를 비교합니다. 이 과정에서 어떤 행동이 도움이 됐고, 어떤 행동이 실패를 불렀는지 정리합니다.
추론 단계 :
새로운 문제가 들어오면 XSKILL은 문제를 작은 하위 작업으로 나누고, 관련 경험과 스킬을 찾아옵니다. 그다음 현재 이미지와 질문에 맞게 내용을 고쳐 에이전트에게 참고 자료로 넣어 줍니다.

그림 : XSKILL 전체 프레임워크 구조

위 그림은 XSKILL의 전체 구조를 보여줍니다. 왼쪽은 경험과 스킬을 쌓는 단계이고, 오른쪽은 새 문제를 풀 때 관련 지식을 검색하고, 현재의 이미지에 맞게 수정한 뒤 에이전트에게 제공하는 단계입니다.

4) 세부 적용 기술

1️⃣ 경험과 스킬의 분리

'경험'과 '스킬'를 분리합니다.
이 둘을 분리한 이유는 역할이 다르기 때문입니다. 경험은 순간 판단에 강하고, 스킬은 전체 계획에 강합니다.

2️⃣ 시각 기반 요약

기존 방식은 주로 텍스트 로그만 보는데 반해, XSKILL은 이미지 상태까지 함께 봅니다.
(예) 단순히 '회전 도구를 사용했다'가 아니라, '이미지가 거꾸로 보여서 회전 도구를 사용했다'고 저장합니다.
이렇게 해야 다음에 비슷한 이미지가 나왔을 때 같은 지식을 다시 찾기 쉽습니다.

3️⃣ 여러 풀이 비교

같은 문제를 여러 번 풀게 한 뒤 성공과 실패를 비교합니다.
성공한 풀이에서 반복되는 행동은 스킬 후보가 됩니다.
실패한 풀이에서 반복되는 실수는 경험으로 저장됩니다.
(예) '원본 이미지를 그대로 검색해서 실패했다면, 먼저 물체 영역을 잘라 검색하라'는 조언(경험)을 만들 수 있습니다.

4️⃣ 지식 정리와 중복 제거

XSKILL은 의미가 비슷한 경험을 합치고, 너무 구체적인 내용은 줄임으로써, 다른 문제에 재사용하기 좋게 합니다.
경험이 계속 쌓이면 비슷한 내용이 많아질 수 있기 때문입니다.
(예) '빨간색 작은 마스코트'처럼 특정 사례에만 맞는 표현은 '작은 물체'처럼 넓게 바꿉니다.

5️⃣ 문제 분해 후 검색

새 문제가 들어오면 질문 전체로만 검색하지 않고 먼저 문제를 작은 하위 작업으로 나눕니다.
(예) '이미지 품질 확인', '작은 물체 식별', '웹 검색 필요 여부 판단' 등
각 하위 작업에 맞는 경험을 따로 찾기 때문에 중요한 조언을 놓칠 가능성이 줄어듭니다.

6️⃣ 현재 상황에 맞게 다시 쓰기

저장된 경험은 그대로 쓰지 않고, 현재 이미지와 질문에 맞게 다시 표현합니다.
(예) 일반 경험이 '방향이 이상하면 회전하라'라면, 현재 문제에서는 '이 이미지는 거꾸로 보이므로 180도 회전한 뒤 분석하라'처럼 바뀌도록 합니다.

7️⃣ 프롬프트 주입

정리된 경험과 스킬은 에이전트의 시스템 프롬프트에 참고 자료로 들어갑니다.
단, 강제로 따르게 하는 규칙은 아니며 에이전트가 상황에 맞게 참고하되, 필요하면 다른 방법도 선택할 수 있습니다.

5) 제약사항

XSKILL은 강한 기반 모델에서는 효과가 컸지만, 일부 오픈소스 모델에서는 평균 성능이 떨어지는 경우도 있었습니다.
논문은 약한 모델이 외부 지식을 제대로 활용하지 못하면 오히려 기존 도구 사용 방식이 흔들릴 수 있다고 설명합니다.
지식이 계속 쌓이는 구조이므로, 잘못된 경험이나 편향된 판단도 함께 저장될 수 있습니다.
그래서 사람이 경험과 스킬 저장소를 검토하고, 불필요하거나 위험한 지식을 정리하는 과정이 필요합니다.

XSKILL의 의의는 AI 모델을 다시 훈련하지 않고도, 과거 문제 풀이에서 배운 내용을 다음 문제에 활용하게 만든 데 있습니다. 특히 이미지, 도구, 웹 검색이 함께 필요한 상황에서 '무엇을 먼저 해야 하는지'를 더 잘 판단하게 돕습니다.

실생활에서는 상품 이미지 분석, 의료 영상 보조, 문서 이미지 검색, 웹 기반 조사 업무, 시각 자료 검증 같은 분야에 활용될 수 있습니다. 예를 들어 작은 로고나 물체를 찾아야 할 때, AI가 무작정 답하지 않고, 먼저 이미지를 자르고 확대하고 검색하는 절차를 선택할 수 있습니다. 다만 이 경우, 저장된 경험의 품질 관리가 중요합니다. 이 부분이 개선되면 XSKILL 같은 방식은 더 안전하고 투명한 에이전트 시스템으로 발전할 수 있습니다. 사람이 지식을 확인하고 수정할 수 있다는 점도 장점입니다.

참고자료

사이트) XSKILL 프로젝트 (링크)
논문) XSKILL: Continual Learning from Experience and Skills in Multimodal Agents (링크)
코드) XSKILL github 저장소 (링크)

Q&A

Q. XSKILL은 모델을 다시 학습시키는 방법인가요?

아닙니다. 모델의 파라미터를 바꾸지 않습니다. 대신 과거 풀이에서 얻은 경험과 스킬을 외부 저장소에 쌓고, 새 문제를 풀 때 참고합니다.

Q. 경험과 스킬은 어떻게 다른가요?

경험은 특정 상황에서의 짧은 행동 조언입니다. 스킬은 여러 단계를 포함한 작업 절차입니다. 비유로 표현하면 경험은 '팁' 같은 것이고, 스킬은 '작업 매뉴얼'에 가깝습니다.

Q. 왜 이미지 기반으로 지식을 저장해야 하나요?
멀티모달 문제에서는 이미지 상태가 판단의 핵심이 되는 경우가 많습니다. 이미지가 어둡거나, 뒤집혔거나, 물체가 작다는 정보는 텍스트 로그만으로는 충분히 잡아내기 어렵습니다.

거리만 보던 LiDAR의 진화, Ouster 컬러 LiDAR 등장

42morrow — Wed, 6 May 2026 17:31:01 +0900

정확히 어떤 방식으로 되는 것인지는 모르겠지만, 세계 최초의 네이티브 컬러 LiDAR가 공개되었습니다. LiDAR를 피상적으로만 알던 터라 하도 신기해서 그 소식을 간단히 정리해 보도록 하겠습니다.

네이티브 컬러 LiDAR, 어떤 제품인가?

Ouster의 네이티브 컬러 LiDAR는 거리만 측정하던 기존 LiDAR를 넘어, 색과 3D 정보를 센서 단계에서 동시에 확보해 더 풍부한 장면 이해를 가능하게 하려는 차세대 센서입니다.

소개된 제품은 REV8 OS 계열이며, 색 정보를 카메라 후처리로 덧씌우는 방식이 아니라 센서/실리콘 단계에서 3D와 색을 함께 얻는 방식이라고 합니다. 즉, 기존의 LiDAR가 거리 정보만 보는 것이었다면 공개된 제품은 거기에 색 정보까지 센서 자체에서 함께 얻는 차세대 3D 센서인 셈입니다. 영상을 보면 카메라 영상에 LiDAR 센서에서 수집한 정보를 입혀둔 듯한 결과물이 보입니다.

그림 : 센서를 통해 수집된 정보 예시

핵심은 색과 3D를 소프트웨어로 나중에 억지로 붙이는 방식이 아니라, 센서 실리콘 단계에서 함께 처리한다는 것입니다. '3D와 컬러가 실리콘에서 융합'된다고 설명한 것과 같은 맥락인데, 각 Point가 처음부터 색을 가진 상태로 생성되어 낮은 지연, 정확한 시공간 정렬, 북잡한 카메라-라이다 보정 부담 감소 등을 기대할 수 있다고 합니다.

제품의 사양은 어떻게 되나?

Ouster의 차세대 L4/L4 Max 실리콘이 기반이 됩니다.

공식 발표에 의하면 아키텍처는 다음을 지원합니다.

128채널 L4와 256채널 L4 Max로 나뉘며,
42.9GMACs 처리 성능, 초당 최대 20조개의 광자 감지,
40KHz 측정률, 최대 1040만 포인트/초, 오프칩 대역폭 22.4Gbps
360도 모든 방향으로 최대 500m 거리에서 45° 시야각으로 고정의 감지를 제공하는 플래그십 OS1 Max를 256채널로 도입
색 표현도 48bit 컬러 깊이, 116 dB 다이나믹 레인지, 1~200만 lux까지 조도 환경 지원

그림 : Ouster에서 공개한 REV8

주로 어떤 곳이 사용될까?

Ouster에서 언급한 활용 분야는 로보틱스와 드론, 창고/산업자동화, 보안, 교통, 스마트 인프라, 자동차 등등의 영역이 될 것 같습니다. 자동차만 하더라도 테슬라의 일론 머스크는 카메라 정보와 라이다정보가 서로 다른 응답을 줄 경우, 이것으로 인한 문제점이 더 클 수 있다며 과감히 LiDAR, 레이더 등을 차량에서 제외하기도 했습니다. 흠... 이번 제품의 등장으로 혹시나 다시 라이다를 검토하게 되는 건 아닌가 모르겠습니다. -_-;

참고자료

제품 릴리즈 뉴스 (링크)

HY-MT1.5 : 로컬 장비에서 사용 가능한 400M 크기의 고품질 번역 모델

42morrow — Sun, 3 May 2026 22:45:05 +0900

최근 AI의 활용 부분에서 가장 생활과 밀접한 영역 가운데 하나가 번역입니다. 검색, 고객 상담, 해외 쇼핑, 게임, 영상 자막, 문서 업무까지 거의 모든 디지털 경험의 바닥에 번역이 깔려 있으니까요. 게다가 생성형 AI가 널리 쓰이면서 사람들은 이제 문장만 단순히 번역하는 것보다 상황을 이해하고 자연스럽게 바꾸는 번역을 기대하게 되었습니다. 같은 단어라도 맥락에 따라 뜻이 달라지고, 표나 태그 같은 형식도 그대로 살려야 하며, 특정 업계 용어도 일관되게 맞춰야 하기 때문입니다.

하지만 현실은 조금 다릅니다. 성능이 아주 좋은 대형 모델은 비용이 크고 응답도 무거워서, 모바일 기기나 대량 처리 환경에 바로 쓰기 어렵습니다. 반대로 가벼운 모델은 빠르고 저렴하지만 번역 품질이 떨어지는 경우가 많습니다. 즉, '잘 번역하는 모델'과 '현장에서 쓰기 좋은 모델' 사이에 아직 넘기 어려운 간격이 있습니다. 이 간격을 줄이는 일이 최근 AI 번역 산업에서 중요한 과제가 되고 있죠.

이번에 소개할 텐센트의 HY-MT1.5는 1.8B와 7B 규모의 번역 모델로, 단순히 모델을 키우는 대신 학습 단계를 잘게 나누고, 큰 모델의 강점을 작은 모델로 옮기며, 실제 업무에서 필요한 기능까지 함께 넣었습니다.

그림 : HY-MT1.5와 주요 번역 모델의 벤치마크 성능 비교

1) 기존 방식의 문제점

기존 번역 시스템들에는 다음과 같은 두가지 문제점들이 있었습니다.

번역 품질과 효율의 충돌 :
성능이 좋은 폐쇄형 대형 모델은 번역 품질이 높지만, 비용과 추론 부담이 커서 엣지 기기나 대량 번역 환경에 쓰기 어렵습니다. 반대로 가벼운 오픈소스 모델은 빠르고 배포가 쉽지만, 번역 품질이 충분히 따라오지 못하는 경우가 많습니다.
맞춤형 번역 지원의 부족 :
많은 시스템이 여전히 일반 문장 번역에 머물러 있습니다. 그런데 실제 현장에서는 용어를 지정해야 하고, 긴 문서 안에서 앞뒤 맥락을 유지해야 하며, 표/목록/태그 같은 형식도 깨지지 않아야 합니다. 논문은 이런 요구를 'context-aware translation', 'format preservation', 'terminology intervention' 같은 기능으로 정리하며, 기존 시스템이 이 부분을 충분히 다루지 못했다고 설명합니다.

2) 접근 방식

논문에서의 접근 방법은, 한마디로 말해 '번역 모델을 한 번에 만드는 대신, 여러 단계로 길러낸다'입니다. HY-MT1.5는 '일반 사전학습 + 번역 중심 사전학습 → SFT를 적용하고 → 강화학습과 증류'를 이어 붙이는 다단계 파이프라인을 사용합니다.

또 하나 중요한 점은 큰 모델과 작은 모델을 따로 보지 않았다는 것입니다. 논문에서 7B 모델은 먼저 강한 교사 모델 역할을 하고, 1.8B 모델은 그 출력을 따라 배우는 학생 모델 역할을 합니다. 즉, 작은 모델을 억지로 혼자 잘하게 만들기보다, 큰 모델의 번역 감각을 전달받게 한 것입니다. 이 방식 덕분에 1.8B 모델도 훨씬 큰 오픈소스 모델이나 상용 번역 API와 비교해 매우 경쟁력 있는 성능을 냈습니다.

3) 모델/기술 아키텍처

그림 : HY-MT1.5의 다단계 학습 파이프라인

위의 그림을 보면 전체 구조가 한눈에 들어옵니다. 시작점은 HY-1.8B-Base와 HY-7B-Base입니다. 여기서 1단계는 MT-oriented Pretraining, 2단계는 SFT, 3단계는 RL, 4단계는 Strong-to-Weak On-Policy Distillation, 5단계는 다시 RL입니다. 쉽게 말하면 7B 모델은 먼저 충분히 강한 번역 모델로 만든 뒤, 그 능력을 1.8B 모델에 옮기고 마지막으로 다시 다듬는 흐름입니다. 작은 모델을 곧바로 학습시키는 것이 아니라, '큰 모델로 먼저 정답 감각을 만든 다음 작은 모델에 전수한다'는 점이 핵심입니다.

그림 : HY-MT1.5와 주요 번역 모델의 벤치마크 성능 비교

위의 그림은 앞서 설명한 단계 별 방식 설계가 왜 중요한지 보여줍니다. 모델 크기가 커질수록 보통 번역 품질이 좋아지지만, HY-MT1.5는 같은 크기대의 다른 오픈소스 모델보다 더 높은 위치에 찍혀 있습니다. 즉, 단순히 파라미터 수가 많아서 잘하는 것이 아니라, 같은 크기에서도 더 효율적으로 성능을 뽑아낸 것입니다. 초보자 관점에서 보면 '더 큰 엔진'보다 '더 정교한 튜닝'에 가까운 그림입니다.

4) 세부 적용 기술

1️⃣ MT 중심 사전학습과 SFT

고품질 다국어 단일 언어 데이터와 병렬 말뭉치(같은 내용을 여러 언어로 짝지어 둔 데이터)를 함께 사용함
CPT로 다국어 지식과 번역 기초 능력을 확장 후 SFT로 번역 지시를 잘 따르도록 학습함
문법, 어휘, 표현 습관, 지시 이행 능력을 함께 다지는 기본기 단계임

2️⃣ 세부 기준을 둔 강화학습

번역 품질을 한 개 점수가 아니라 여러 기준(정확성, 유창성, 일관성, 문화적 적절성, 가독성)으로 나눠 평가하고 각 기준 점수를 종합해 보상으로 사용함
GRPO를 적용해 여러 후보 번역 중 상대적으로 더 나은 출력을 학습
의미 전달뿐 아니라 자연스럽고 읽기 쉬운 번역을 유도함

3️⃣ Strong-to-Weak On-Policy Distillation

큰 모델의 지식을 작은 모델로 옮기는 증류 기법을 사용함
- HY-MT1.5-7B를 교사 모델, HY-MT1.5-1.8B를 학생 모델로 둠
- 학생 모델이 단순 정답 문장뿐 아니라 큰 모델의 출력 방식까지 따라 배우게 함
- 작은 모델의 성능 한계를 줄이는 핵심 단계임
33개 언어, 약 100만 개 단일언어 샘플로 학습함

4️⃣ 실제 업무에 가까운 맞춤형 번역 기능

단순 문장 번역을 넘어 실무 환경에 맞춘 활용성을 높임
- 용어 지정 번역 지원 : 지정한 전문 용어나 고유명사를 일관되게 번역함
- 문맥 기반 번역 지원 : 앞뒤 상황을 반영해 단어 뜻을 더 정확히 해석함
- 형식 보존 번역 지원 : 태그, 구조, 문서 형식을 유지한 채 번역함

5️⃣ 양자화와 배포 최적화

양자화로 모델의 메모리 사용량과 연산량을 줄임
- FP8은 원본과 비슷한 품질을 유지하면서 경량화에 성공함
- Int4는 더 가볍지만 성능 저하가 비교적 큼
더 낮은 비트 환경에서는 QAT와 offset 기법을 활용해 성능 저하를 줄이려 함
연구 목표가 성능뿐 아니라 실제 배포 가능성까지 포함함을 보여줌

6️⃣ 성능과 속도의 균형

전체적으로 '작지만 강한 번역 모델'이라는 점을 보여줌
- HY-MT1.5-1.8B는 평균 응답 시간 약 0.18초로 매우 빠름.
  1.8B 모델은 작은 크기 대비 매우 높은 번역 성능을 달성함
- HY-MT1.5-7B는 약 0.45초로 더 무겁지만 품질이 더 높음
  7B 모델은 일부 벤치마크에서 초대형 모델과 경쟁하거나 이를 넘어섬

5) 제약사항

1.8B 모델은 효율적이지만 역시나 7B 모델보다 전반적으로 성능이 떨어집니다.
초저비트 양자화는 배포에는 유리하지만 정확도 저하가 클 수 있습니다.
언어 범위와 도메인 특화, 극단적 경량화는 더 진행될 필요가 있습니다.

6) Hy-MT-1.5-1.8B 모델을 이용한 테스트 진행

아쉽게도 Hy-MT1.5-1.8B-1.25bit.gguf (440MB 수준)으로는 돌려보질 못하고 tencent/HY-MT1.5-1.8B (FP16 기반, 현재 실행 가능, 4GB)를 이용해서 만들어 봤습니다. 문맥 기반의 번역을 지원해서 그런지 번역 품질이 꽤 괜찮은 것 같습니다.

HY-MT1.5 논문의 의미는 단순히 '번역 점수가 높다'에 있지 않습니다. 이 연구는 작은 모델도 학습 전략을 잘 설계하면 훨씬 큰 모델에 가까운 성능을 낼 수 있다는 점을 보여줍니다. 특히 번역 중심 사전학습, 세부 기준 기반 강화학습, 큰 모델에서 작은 모델로의 온폴리시 증류를 하나의 흐름으로 묶었다는 점이 기술적으로 중요합니다. 번역 AI를 만드는 방식이 '크게 만들기'에서 '정교하게 길러내기'로 이동하고 있다는 신호로도 읽힙니다.

실생활 측면에서도 효용이 분명합니다. 빠른 응답이 필요한 메신저 번역, 고객센터, 모바일 번역, 문서 자동화, 다국어 콘텐츠 운영 같은 환경에서는 품질만큼 속도와 배포성이 중요합니다. HY-MT1.5는 그 균형을 현실적인 수준으로 끌어왔습니다.

참고자료

논문) HY-MT1.5 Technical Report (링크)
코드) HY-MI1.5-1.8B github 저장소 (링크)
모델카드) Hugging Face 모델 카드 (링크)
- 현재 제일 작은 버전으로 1.8B-1.25bit-GGUF (440MB 수준)까지 있습니다. 이는 llama-cpp-python이 STQ 커널 포함 버전이 릴리즈되면 사용할 수 있을 것 같습니다. (대신 이를 테스트 할 수 있는 Android 용 데모 apk는 제공됩니다)
데모) Android 데모 apk 다운로드 (링크)

용어 정리

SFT(Supervised Fine-Tuning) : 좋은 예시 데이터를 보여주며 원하는 답변 방식을 가르치는 방식으로, 번역 실력 자체와 지시문을 따르는 능력을 함께 끌어올리려는 설계
MT (Machine Translation) : 사람이 직접 번역하지 않아도, AI나 컴퓨터가 한 언어를 다른 언어로 바꾸는 기술
MT-oriented Pretraining : 기계번역 중심 사전학습. 일반 언어 능력만 키우는 것이 아니라, 번역에 더 잘 맞도록 학습 방향을 조정하는 단계
CPT (Continuous Pretraining) : 이미 기본 학습이 끝난 모델에 추가 데이터를 더 넣어 계속 학습시키는 방식
GRPO (Group Relative Policy Optimization) : 여러 개의 후보 답변을 한 묶음으로 보고, 그 안에서 상대적으로 더 좋은 답을 고르는 방식으로 학습
On-Policy Distillation : 큰 모델의 지식을 작은 모델로 옮기는 방식

Q&A

Q. 왜 HY-MT1.5-1.8B가 작은데도 성능이 좋은가요?

큰 모델을 먼저 강하게 만든 뒤, 그 지식을 작은 모델에 옮기는 온폴리시 증류를 썼기 때문입니다. 여기에 번역 중심 사전학습, SFT, 강화학습까지 단계적으로 붙여서 작은 모델의 약점을 보완했습니다.

Q. 이 모델은 일반 번역기와 무엇이 다른가요?

단순 문장 번역만 하는 것이 아니라, 용어를 지정해 번역할 수 있고, 앞뒤 문맥을 반영할 수 있으며, 태그나 형식을 보존한 채 번역할 수 있습니다. 그래서 실제 문서 업무나 콘텐츠 번역에 더 잘 맞습니다.

Q. 양자화는 왜 중요한가요?

양자화는 모델을 더 가볍게 만들어 모바일이나 엣지 기기에서도 돌릴 수 있게 해 줍니다. 이 논문에서는 FP8은 품질 손실이 작았고, Int4는 더 가볍지만 정확도 하락이 컸습니다. 즉, 배포성과 품질 사이의 균형을 맞추는 기술입니다.

[바이브코딩] 스틱맨(일명 졸라맨) 댄스 만들기

42morrow — Thu, 30 Apr 2026 14:09:50 +0900

유튜브 영상을 보다가 나루토 댄스라는 것을 추는 쇼츠를 보게됐습니다. 알고리즘을 타고 저한테 온 영상은 베트남 인플루언서의 댄스였고, 그 외에도 수많은 챌린지 영상들이 있었습니다. 나루토를 종이 만화로만 봐서 애니메이션에 나오는 동작을 모르던터라 영상을 통해 만화 장면을 떠올리는 것보다는 그저 리드미컬하고 유연한 몸동작의 재미난 댄스로만 봤습니다.

그런데 순간... 저런 춤을 추는 스틱맨(일명 졸라맨)이 있다면 어떨까 하는 생각이 들었습니다. 머리는 커다랗고 둥근 원, 팔과 다리, 허리는 하나의 선으로 된 초간단 인간 형상으로 하되, 관절 위치와 움직임만 잘 인식하면 될 것 같았거든요. 게다가 어쩐지 무게감을 확 덜고 재미난 것만 강조할 수도 있겠다 싶기도 하구요.

스틱맨 (졸라맨) 애니메이션 생성기가 없나?

찾아보니 유튜브에는 비슷한 시도를 한 사례가 제법 있었습니다. 그런데 한결같이 자세 예측을 통한 뻣뻣한 움직임에, 정말 작대기 인간 (졸라맨과는 좀 다른...)이 주로 쓰이더군요. 모름지기 춤은 그루브와 유연함이 생명인데... 그래서 또 뒤져봤죠. 이런 요구사항을 반영한 프로젝트가 있는지. 역시 있었습니다!

GitHub - madeindjs/stickman: generate animated SVG Stickman

generate animated SVG Stickman. Contribute to madeindjs/stickman development by creating an account on GitHub.

github.com

이 프로젝트는 스틱맨을 생성한 후, 이를 프레임별로 관절 등을 움직이는 방식으로 애니메이션을 만들 수 있는 에디터입니다. 문제는 이 도구가 수작업으로 동작을 지정하도록 되어 있다는 것이었죠. 짧은 동작 애니메이션은 이걸 이용해 만들 수 있을지라도 긴 영상은 어려워 보였습니다. 초당 10 프레임이라고 할 경우, 30초면 300 프레임을 개별적으로 편집해야 하니 흠... 노가다는 사절인데...

AI의 자세예측 (Pose Estimation) 기술을 추가 접목하다

그래서, 기존 원본 코드에 아래 기능을 추가하기로 했습니다.

자세 예측 (Pose Estimation) :
AI 모델을 이용한 영상에서의 자세예측 기술을 사용합니다. Mediapipe 로 했는데, Yolo Pose 등 최신 모델들을 사용하면 정확도가 더 높아질 겁니다. 테스트 수준으로 진행하는거라 저는 Javascript로 동작하는 Mediapipe를 이용해 움직임을 예측하도록 했습니다. (모바일 웹앱으로 캡처하기 위해)
Json 기반 동작 데이터 저장 :
위에 소개한 에디터에서 앞서 캡처를 통해 수집한 모션 데이터를 import 하는 기능을 추가했습니다. 이렇게 한 후 원본에서 제공하는 타임라인 상의 프레임 별 표시, 개별 편집 기능을 그대로 사용하도록 말이죠.
파일 저장 :
편집이 완료되면 (추가적인 수정없이 그대로 사용하거나) 그것을 이미지(svg) 또는 영상(webm)으로 저장하도록 합니다. 배경색을 지정하거나 투명 배경, 배경 이미지를 설정할 수 있습니다.

구현 결과물 : 스틱맨 애니메이션 편집기 수정본

원본 코드에 위에 언급한 기능을 추가로 덧붙인 결과물은 다음과 같습니다.

그림 ; 공개된 원본 코드에 자동생성, Import/Export를 추가

구현 결과물 : 스틱맨 애니메이션 영상 (원본 vs 적용본)

원본 댄스 영상은 다음과 같습니다.

원본 영상 : 유튜브 쇼츠로 공개된 하이디라오 나루토 댄스 (링크)

참고로 다른 챌린지 버전들보단 이 분이 제일 잘 하시는 것 같습니다. 어휴... 표정에서 풍기는 저 자신감이란...

참고) 원본 영상에서 사람의 움직임을 추출해서 처음부터 정해진 크기의 스틱맨에 매핑하는 것이라 영상 속 댄서와 스틱맨의 크기가 동일하지 않습니다.

PackUV : 4D 볼류메트릭 비디오를 위한 혁신적인 가우시안 UV 맵 압축 기술

42morrow — Wed, 29 Apr 2026 16:18:48 +0900

혹시 메타의 퀘스트 헤드셋을 쓰고 콘서트 현장 한가운데 서 있는 것처럼 느끼거나, 스포츠 경기를 원하는 각도에서 자유롭게 감상하는 경험을 상상해본 적 있으신가요? 이런 것을 몰입형 미디어라고 하고 이것의 핵심 기술이 바로 볼류메트릭 비디오(Volumetric Video) 입니다. 일반 영상이 2D 평면에 세상을 담는다면, 볼류메트릭 비디오는 공간과 시간을 모두 담아내는 4D 경험을 제공하는 것이라고 할 수 있죠.

문제는 이 기술이 현실에서 쓰기엔 아직 너무 무겁고 불편하다는 것입니다. PackUV는 바로 이 문제를 해결하는 방법으로, 3D 가우시안 속성을 2D UV 지도 형태로 압축해 기존 영상 인프라와 완벽하게 호환되는 새로운 4D 표현 방식을 제안합니다.

1. 기존 방식의 문제점

볼류메트릭 비디오를 만들고 저장하고 스트리밍하는 일은 현재도 극도로 어렵습니다. 비유하자면, 사진 한 장이 아니라 입체 조각상 수십만 개를 매 프레임마다 기록하는 것이나 다름없으니까요.

최근 가장 각광받는 방법은 3D Gaussian Splatting (3DGS) 이라는 기술인데, 수십만~수백만 개의 작은 타원형 덩어리(가우시안 프리미티브)로 3D 장면을 표현합니다. 품질은 뛰어나지만 4D 영상(시간이 흐르는 3D 장면)에 적용하면 다음과 같은 심각한 한계가 드러납니다.

첫째, 몇 초짜리 짧은 시퀀스를 넘어가면 메모리가 폭발적으로 늘어납니다.
둘째, 사람이 갑자기 장면에 들어오거나(disocclusion) 빠르게 움직이는 상황에서 시간적 일관성이 무너집니다.
셋째, 가장 현실적인 문제로 결과물이 HEVC나 FFV1 같은 표준 비디오 코덱과 호환이 전혀 되지 않습니다.
즉, 기존 유튜브, 넷플릭스 같은 스트리밍 인프라에 그냥 올릴 수가 없다는 뜻이죠.

2. 접근 방식

PackUV의 핵심 아이디어는 다음과 같은 질문에서 나왔습니다.

"3D 가우시안 속성들을 2D 이미지처럼 저장하면 기존 비디오 코덱을 그대로 쓸 수 있지 않을까?"

연구진은 이를 위해 다음의 세 가지를 함께 제안합니다.

PackUV : 가우시안의 모든 속성(위치, 크기, 회전, 색상, 불투명도)을 UV 좌표 공간에 다층 2D 이미지로 정렬해 저장하는 새로운 표현 형식입니다.
PackUV-GS : 실제 멀티뷰 영상에서 PackUV를 직접 최적화하는 학습 방법으로, 광학 흐름(optical flow) 기반 키프레이밍과 가우시안 레이블링 전략을 통해 긴 시퀀스에서도 시간적 일관성을 유지합니다.
PackUV-2B : 이 연구를 위해 직접 구축한 사상 최대 규모의 멀티뷰 4D 데이터셋으로, 50개 이상의 동기화된 카메라로 100개 시퀀스, 무려 20억(2B) 프레임을 담고 있습니다.

3. 모델/기술 아키텍처

전체 파이프라인은 크게 두 단계로 이루어집니다.

저장 구조(PackUV Atlas) 단계 : 가우시안 속성들을 UV 맵에 배치할 때 단순히 레이어를 균일하게 쌓는 게 아니라 피라미드 구조를 씁니다. 깊은 레이어일수록 불투명도가 낮은 가우시안이 들어가므로 실제로 담기는 데이터가 희박해진다는 점을 이용한 것이죠. 이 여러 레이어를 최종적으로 쿼드트리(quadtree) 방식으로 하나의 단일 텍스처 아틀라스로 합쳐 88.5%의 픽셀 활용 효율을 달성합니다.
학습 방법(PackUV-GS Fitting) 단계 : 기존처럼 3DGS를 먼저 최적화한 뒤 UV로 변환하는 것이 아니라, 처음부터 UV 공간 안에서 직접 가우시안 파라미터를 최적화합니다. 광학 흐름을 분석해 움직이는 가우시안과 정적인 가우시안을 구분하고, 정적인 부분은 그래디언트를 0으로 고정해 계산 효율을 높입니다.

그림 : PackUV 전체 개요

위의 그림은 PackUV의 개요인데, 단 하나의 표현으로 모든 가우시안 속성을 담으면서 표준 비디오 코덱과 100% 호환됨을 강조하고 있습니다.

왼쪽 상단(파란색) : 멀티뷰 RGB 영상으로부터 PackUV-GS가 가우시안 속성을 직접 UV 공간에 피팅하는 과정
오른쪽 상단(노란색) : 피팅된 결과를 하나의 PackUV.mp4 아틀라스로 압축하는 과정
하단(빨간색) : 아틀라스에서 임의 시점의 볼류메트릭 비디오를 렌더링하는 결과

4. 세부 적용 기술

피라미드 UV 매핑 (Pyramid UV Mapping) :
모든 레이어를 동일한 해상도로 저장하면 메모리 낭비가 심합니다. 불투명도 순으로 정렬했을 때 깊은 레이어에는 실제로 데이터가 거의 없다는 관찰에서 출발해, 레이어가 깊어질수록 해상도를 절반씩 줄여가는 기하급수적 다운샘플링을 적용합니다. 이렇게 해도 품질 손실이 미미합니다.

그림 : UV 맵 구조와 PackUV-GS 파이프라인

UV 아틀라스 패킹 (UV Atlas Packing) :
여러 해상도의 레이어를 쿼드트리 방식의 재귀적 분할로 하나의 이미지에 합칩니다. 레이어 0은 오른쪽 전체 영역을, 그 이후 레이어들은 왼쪽 영역을 번갈아 분할해 채워가는 방식이죠. 최종적으로 88.5%의 픽셀 활용 효율을 달성하는데, 이는 단순 격자 배치(60%)나 피라미드 배치(75%)보다 훨씬 뛰어납니다.
광학 흐름 기반 키프레이밍 (Optical Flow-based Keyframing) :
긴 영상을 구간별로 나눠 학습할 때, 어디서 구간을 나눌지 자동으로 결정하는 방법입니다. RAFT 모델을 이용해 프레임 간 광학 흐름의 크기를 계산하고, 크게 움직임이 발생한 시점을 키프레임으로 설정합니다. 각 키프레임의 가우시안은 이전 키프레임 결과에서 초기화되므로 시간적 연속성이 자연스럽게 보존됩니다.
공분산 인식 가우시안 레이블링 (Covariance-Aware Gaussian Labeling) :
단순히 가우시안의 중심 위치만 보는 게 아니라 각 가우시안의 2D 공분산(타원 모양과 크기)을 함께 고려해 광학 흐름 마스크와 겹치는지 판단합니다. 마할라노비스 거리를 기준으로 동적 가우시안 여부를 판별하고, 정적으로 판단된 가우시안은 역전파 시 그래디언트를 0으로 고정(gradient freezing)합니다. 이 과정은 CUDA 커널로 병렬 가속됩니다.
저정밀도 최적화 (Low Precision Optimization, LPO) :
학습이 끝난 뒤에 양자화를 적용하는 기존 방법과 달리, 학습 중에 이미 8비트 정밀도로 최적화를 진행합니다. 순전파 시에는 양자화된 파라미터를 쓰고, 역전파 시에는 직선 추정기(straight-through estimator)를 통해 FP32 마스터 웨이트를 업데이트합니다. 이 덕분에 학습 자체가 양자화 오차를 보상하면서, 별도의 후처리 없이 8비트 이미지로 바로 저장하고 HEVC/FFV1 같은 표준 코덱으로 인코딩할 수 있습니다.

5. 제약사항

광학 흐름 추정이 부정확할 경우 가우시안이 늘어지는 아티팩트(dragged Gaussian artifacts)가 발생할 수 있습니다.
UV 투영이 여전히 넓은 공간 배열을 요구하기 때문에, 실제 세계의 세밀한 디테일을 담으려면 여전히 큰 해상도가 필요합니다.
현재의 UV 매핑이 최적이라는 보장이 없으며, 더 효율적인 매핑 방식을 탐구할 여지가 있습니다.
또한 현재 구현이 AR/VR 디바이스에 직접 배포되는 형태로는 아직 최적화되지 않았습니다.

PackUV는 4D 볼류메트릭 비디오 분야에서 꽤 의미 있는 전환점을 만들어냈습니다. 가장 인상적인 점은 기술적 성능 향상뿐만 아니라 실용성의 문을 열었다는 것이죠. 기존 비디오 인프라와의 완벽한 호환성, 30분짜리 긴 시퀀스에서도 일관된 품질 유지, 그리고 기존 대비 훨씬 작은 용량(30프레임 기준 경쟁 방법 대비 최대 수십 배 작음)은 실제 서비스 적용 가능성을 크게 높입니다.

참고자료

사이트) PackUV 프로젝트 페이지 (링크)
논문) PackUV: Packed Gaussian UV Maps for 4D Volumetric Video (링크)
영상) PackUV 프로젝트 영상 (링크)

용어 해설

UV 매핑 : 3D 물체 표면을 2D 평면으로 펼치는 기법입니다. 마치 지구본을 평면 지도로 펼치는 것과 같죠. U와 V는 2D 좌표축의 이름입니다.
가우시안 스플래팅(Gaussian Splatting) : 수많은 타원형 반투명 덩어리(가우시안)로 3D 장면을 표현하고 렌더링하는 기술입니다. 실시간 렌더링 품질이 뛰어나 최근 3D 재구성 분야의 주류 방법이 됐습니다.
광학 흐름(Optical Flow) : 두 연속 프레임 사이에서 각 픽셀이 얼마나, 어느 방향으로 움직였는지를 나타내는 벡터 필드입니다. 동작 감지에 핵심적으로 쓰이죠.
PSNR/SSIM/LPIPS : 이미지 품질을 측정하는 지표들입니다. PSNR은 높을수록, LPIPS는 낮을수록 좋습니다.
Disocclusion : 가려져 있던 물체가 새로 시야에 들어오는 현상입니다. 예를 들어 사람이 기둥 뒤에서 걸어 나오면 이전에 없던 정보가 생겨나죠. 기존 방법들이 특히 취약한 상황입니다.
HEVC/FFV1 : 현재 가장 널리 쓰이는 표준 비디오 코덱들입니다. HEVC(H.265)는 손실 압축에, FFV1은 무손실 압축에 많이 사용됩니다.

Q&A

Q. PackUV는 기존 UVGS와 어떻게 다른가요?

UVGS는 이미 최적화된 3DGS를 사후에(post-hoc) UV 맵으로 변환합니다. 이 변환 과정에서 가우시안 중심 위치만 UV 좌표로 매핑하기 때문에 많은 정보 손실이 발생하죠. 특히 복잡한 실제 장면에서 48개 레이어, 1K 해상도를 써도 눈에 띄는 아티팩트가 생깁니다.

반면에 PackUV는 이와 달리 처음부터 UV 공간 안에서 직접 가우시안 파라미터를 학습하기 때문에 변환 손실이 없고, 시간적 일관성도 자연스럽게 학습됩니다.

Q. 표준 비디오 코덱(FFV1, HEVC)으로 인코딩하면 품질 손실이 없나요?

FFV1 무손실 코덱을 사용하는 경우 완벽한 비트 단위 복원이 가능합니다. 이것이 가능한 이유는 PackUV-GS가 학습 중에 이미 8비트 정밀도로 최적화(LPO)를 수행하기 때문입니다. 모든 속성이 표준 8비트 이미지 채널 형식으로 저장되므로 추가 후처리 없이 바로 코덱에 입력할 수 있습니다. HEVC 같은 손실 코덱을 쓸 경우엔 일부 품질 저하가 생기지만, 이를 비트레이트와 품질 간의 트레이드오프로 제어할 수 있습니다.

MegaStyle : 대규모 스타일 데이터셋으로 더 안정적인 이미지 스타일 변환 만들기

42morrow — Tue, 28 Apr 2026 14:16:47 +0900

이미지 생성 AI는 이제 단순히 대상을 그리는 수준을 넘어, 특정 화풍과 질감까지 반영하는 방향으로 발전하고 있습니다. 사용자는 '고양이'를 원하는 것이 아니라 '수채화 느낌의 고양이', '3D 클레이 스타일의 고양이', '만화풍 고양이'처럼 구체적인 스타일을 원합니다.

AI를 이용해 이미지의 스타일을 바꾸는 것은 GAN 기술이 소개된 몇 년전부터 소개된 바 있습니다. 하지만 AI가 스타일을 정확히 배우는 일은 쉽지 않은 것이 같은 작가의 그림이라도 작품마다 색감, 붓질, 구도가 다를 수 있고, 기존 스타일 변환 모델은 참고 이미지의 색만 따라 하거나 물체까지 복사하는 문제 등 다양한 제약사항들을 가지고 있었습니다. 이번 논문은 이런 문제들에 대한 해결책으로 '같은 스타일이지만 다른 내용'을 가진 대규모 데이터셋 MegaStyle-1.4M을 제안하고 있습니다.

그림 : MegaStyle-1.4M 데이터셋과 MegaStyle-FLUX 결과 예시

1) 기존 방식의 문제점

기존 스타일 변환 방식은 스타일과 내용을 잘 분리하지 못했습니다.
참고 이미지의 화풍만 가져와야 하는데, 참고 이미지 안의 물체나 구도까지 따라 하는 일이 생겼습니다.
논문에서는 이를 'content leakage'라고 설명합니다.
기존 데이터셋은 같은 스타일로 묶인 이미지들 사이에서도 실제 스타일 차이가 컸습니다. 일부 데이터는 기존 스타일 변환 모델로 생성했는데, 색감만 비슷하거나 이미지 품질이 떨어지는 문제가 있었습니다.

2) 접근 방식

MegaStyle의 핵심 아이디어는 텍스트-이미지 생성 모델의 스타일 재현 능력을 데이터셋 구축에 활용하는 것입니다. 같은 스타일 설명을 주고 내용만 바꾸면, 생성 모델은 비교적 일관된 화풍의 이미지를 만들 수 있습니다.

논문에서는 다음과 같이 진행합니다.

이미지에서 '콘텐츠 프롬프트'와 '스타일 프롬프트'를 따로 뽑습니다.
- 콘텐츠 프롬프트는 물체와 관계만 담고,
- 스타일 프롬프트는 색, 조명, 질감, 붓질 같은 시각적 특징만 담습니다.
이 둘을 조합해 Qwen-Image로 이미지를 생성합니다.

3) 모델/기술 아키텍처

논문의 결과물은 크게 세 가지입니다.

MegaStyle-1.4M
- 약 140만 장 규모의 스타일 이미지 데이터셋
- 같은 스타일 안에서는 일관성을 유지하고, 전체적으로는 다양한 스타일을 포함

그림 : MegaStyle 데이터 구축 파이프라인

MegaStyle-Encoder
- 두 이미지의 스타일이 얼마나 비슷한지 측정하는 모델
- 색 뿐 아니라 질감, 붓질, 조명 같은 특징을 더 잘 비교
MegaStyle-FLUX
- 참고 스타일 이미지와 텍스트 프롬프트를 함께 사용해 새 이미지를 생성하는 스타일 변환 모델
- FLUX 기반으로 구성됨

그림 : MegaStyle-FLUX 아키텍처

4) 세부 적용 기술

1️⃣ 텍스트-이미지 스타일 매핑

같은 스타일 문장을 입력하면 비슷한 화풍의 이미지를 반복 생성하는 능력을 활용합니다.
- 예 : '클레이 3D 스타일'을 고정하고 자동차, 로봇, 새 등 내용만 바꿔 생성합니다.
- 이 방식은 같은 스타일 안의 일관성을 확보하는 데 유리합니다.

그림 : 스타일 재현 예시

2️⃣ 콘텐츠와 스타일 분리

콘텐츠와 스타일 프롬프트를 분리합니다.
- 콘텐츠 프롬프트 : 무엇이 있는지 설명
- 스타일 프롬프트 : 어떤 느낌인지 설명
두 정보를 분리하면 모델이 참고 이미지의 물체를 베끼는 문제를 줄일 수 있습니다.

3️⃣ VLM 기반 프롬프트 생성

Qwen3-VL 같은 비전-언어 모델을 사용해 이미지에서 설명문을 추출합니다.
- 스타일 설명에서는 물체 정보를 제외하고, 색·빛·질감·붓질 중심으로 설명하게 합니다.
- 콘텐츠 설명에서는 스타일 관련 표현을 제외합니다.

4️⃣ 균형 샘플링

수집한 프롬프트에서 중복을 제거합니다.
비슷한 프롬프트끼리 묶은 뒤, 각 그룹에서 균형 있게 샘플을 뽑습니다.
최종적으로 17만 개 스타일 프롬프트와 40만 개 콘텐츠 프롬프트를 구성했습니다.

5️⃣ MegaStyle-1.4M 생성

하나의 스타일 프롬프트에 여러 콘텐츠 프롬프트를 조합합니다.
Qwen-Image로 이미지를 생성해 '같은 스타일, 다른 내용'의 이미지 쌍을 만듭니다.
이를 통해 약 140만 장 규모의 데이터셋을 구축했습니다.

6️⃣ Style-Supervised Contrastive Learning

MegaStyle-Encoder 학습에 사용된 방법입니다.
같은 스타일 이미지는 가깝게, 다른 스타일 이미지는 멀게 배치하도록 학습합니다.
덕분에 스타일 유사도를 더 정확하게 측정할 수 있습니다.

7️⃣ MegaStyle-FLUX

참고 스타일 이미지를 시각 토큰으로 변환합니다.
텍스트 프롬프트, 노이즈 이미지 토큰, 스타일 토큰을 함께 Diffusion Transformer에 넣습니다.
모델은 텍스트의 내용은 유지하면서 참고 이미지의 스타일을 반영합니다.

그림 : (좌) 서로 다른 데이터셋으로 학습한 결과 비교 (우) MegaStyle-FLUX와 StyleShot 기반 모델 비교

5) 제약사항

VLM이 스타일을 설명할 때 일부 표현이 모호할 수 있다고 언급합니다. 예를 들어 질감, 붓질, 예술 매체 같은 요소는 더 구체적인 설명 지시가 필요합니다.
MegaStyle은 Qwen-Image의 생성 능력에 의존합니다. 생성 모델이 특정 스타일을 잘못 이해하면 데이터셋에도 그 오류가 들어갈 수 있습니다.

MegaStyle은 스타일 변환 문제를 데이터 관점에서 해결하려는 접근입니다. 좋은 모델을 만들기 전에, 먼저 좋은 스타일 학습용 데이터를 만들자는 방향입니다. 이 방식은 디자인, 게임, 웹툰, 광고 이미지 제작에 활용될 수 있습니다. 예를 들어 같은 브랜드 스타일로 여러 제품 이미지를 만들거나, 같은 화풍으로 다양한 캐릭터와 배경을 생성하는 데 도움이 됩니다.

제약사항인 스타일 설명의 모호성이 개선되면, 모델은 색감뿐 아니라 질감, 붓질, 조명 같은 세밀한 스타일 차이까지 더 안정적으로 반영할 수 있습니다.

참고자료

사이트) MegaStyle 프로젝트 (링크)
논문) MegaStyle: Constructing Diverse and Scalable Style Dataset via Consistent Text-to-Image Style Mapping (링크)
사이트) MegaStyle 모델카드 (링크)
코드) MegaStyle github 저장소 (링크) - 텐센트의 MegaStyle 라이선스

용어정리

content leakage : 스타일만 가져와야 하는데 참고 이미지의 내용까지 함께 복사되는 현상
Contrastive Learning : 비슷한 데이터는 가깝게, 다른 데이터는 멀게 학습하는 방식
Diffusion Transformer : 노이즈에서 이미지를 점점 복원하는 확산 모델에 Transformer 구조를 결합한 방식
VLM : 이미지를 보고 텍스트로 설명할 수 있는 인공지능 모델

Q&A

Q. MegaStyle은 기존 스타일 변환 데이터셋과 무엇이 다른가요?

기존 데이터셋은 같은 스타일이라고 묶인 이미지 사이에서도 실제 스타일이 다를 수 있었습니다. MegaStyle은 같은 스타일 설명에 여러 콘텐츠를 조합해 이미지를 생성하므로, 같은 스타일 안의 일관성을 더 잘 유지합니다.

Q. 왜 스타일과 콘텐츠를 분리해서 설명하나요?

스타일 변환에서는 '무엇을 그리는지'와 '어떤 느낌으로 그리는지'가 섞이면 문제가 생깁니다. 참고 이미지의 화풍만 가져와야 하는데 물체나 구도까지 복사할 수 있습니다. 그래서 콘텐츠 프롬프트와 스타일 프롬프트를 분리합니다.

Q. MegaStyle-FLUX는 어떤 점에서 좋은가요?

텍스트가 지정한 내용을 유지하면서 참고 이미지의 스타일을 비교적 안정적으로 반영합니다. 논문 실험에서는 기존 방식보다 사람 평가에서 스타일 일치도와 텍스트 일치도 모두 높게 평가되었습니다.

Volt : 3D 장면 이해를 위한 Volume Transformer

42morrow — Sat, 25 Apr 2026 15:25:10 +0900

AI 모델은 요즘 Transformer를 중심으로 발전하고 있습니다. Transformer는 데이터 안에서 서로 관련 있는 부분을 찾아내는 구조입인데, 문장에서는 단어 관계를 보고, 이미지에서는 작은 그림 조각의 관계를 봅니다.

이 논문은 같은 방식을 3D 공간에 적용합니다. 방, 도로, 물체가 있는 3D 장면을 작은 정육면체 조각으로 나누고, 그 조각들을 Transformer가 읽도록 만듭니다. 이 모델을 'Volt'라고 부릅니다. 핵심은 복잡한 3D 전용 구조를 줄이고, 기본 Transformer로도 3D 장면을 잘 이해할 수 있음을 보였다는 것입니다.

1) 기존 방식의 문제점

3D 데이터의 다루기 어려움
- 이미지는 가로와 세로가 정해진 2D 격자 vs 3D 포인트 클라우드는 점들이 불규칙하게 흩어져 있는 것으로 정보가 적을 수도 있습니다.
  예) 방을 스캔하면 벽은 촘촘하지만 유리나 얇은 물체는 점이 적을 수 있음
기존 모델들은 3D 전용 구조를 주로 사용
- 대표적으로 3D U-Net, sparse convolution, Point Transformer 계열이 있는데
- 이들은 3D 공간의 특성을 잘 반영하지만, 구조가 복잡해집니다.
확장성이 낮음
- 기존 방식은 가까운 주변 정보 위주로 처리하는 경우가 많으며 -> 멀리 떨어진 물체 관계를 보려면 여러 단계의 구조가 필요합니다.
- 게다가 Transformer 전용 하드웨어나 소프트웨어 최적화의 이점을 충분히 받기 어렵습니다.

2) 접근 방식

접근 방식 개요
- 3D 장면을 작은 정육면체 조각으로 나눈 뒤
- 각 조각을 하나의 '토큰'으로 생성
- 이 토큰들을 일반 Transformer Encoder에 입력
- 전체 장면의 토큰이 서로를 한 번에 볼 수 있도록 'global self-attention'을 사용합니다.
풀어서 말하면 이미지를 작은 패치로 나눠 Vision Transformer가 처리하듯, 3D 공간도 작은 부피 패치로 나눠 Transformer가 처리하게 만든 것입니다. 논문은 이를 'Volume Transformer', 즉 Volt라고 부릅니다.
다만 그냥 학습하면 3D 데이터셋은 이미지 데이터셋보다 작아, 기본형 Transformer는 자유도가 커서 데이터가 적으면 쉽게 외우기 때문에, 이를 막기 위해 강한 데이터 증강, 정규화, CNN 교사 모델의 지식 증류를 함께 사용했습니다.

그림 : Volt의 추론 속도와 메모리 효율 비교 (전체 장면을 한번에 보면서도 빠르고 가볍다)

self-attention : 각 토큰이 다른 토큰들과 얼마나 관련 있는지 계산하는 방법입니다.
global self-attention : 가까운 곳만 보는 것이 아니라 전체 장면의 모든 토큰 관계를 보는 방식입니다.

3) 모델/기술 아키텍처

그림 : Volt의 전체 아키텍처 (3D 공간 → 작은 조각 → Transformer 분석 → 물체별 색칠)

위의 그림은 Volt의 아키텍처를 보여주고 있습니다.

입력 3D 장면 : 방 안이나 도로 주변의 포인트 클라우드를 입력으로 받음
voxelization : 3D 공간을 작은 격자로 바꿈 (너무 많은 점을 그대로 쓰면 계산량이 크기 때문)
patchification : voxel을 다시 작은 정육면체 패치 (실내 10cm, 실외 라이다 데이터는 25cm 크기)로 묶음
linear tokenizer : 각 3D 패치를 하나의 벡터, 즉 토큰으로 바꿈
Transformer Encoder : 모든 토큰이 서로 관계를 계산함 (3D RoPE라는 위치 정보 방식을 사용)
lightweight decoder : Transformer가 만든 토큰 특징을 다시 voxel 해상도로 올리고, 이후 각 점이 벽인지, 의자인지, 도로인지 등을 예측

4) 세부 적용 기술

1️⃣ 3D 패치 토큰화

점 하나하나를 모두 넣으면 계산이 너무 많기 때문에 여러 점을 작은 공간 조각(Patch)으로 묶습니다.
이 조각 하나가 Transformer의 입력이 되며 덕분에 계산량을 줄일 수 있습니다.

2️⃣ 전체 장면을 보는 Transformer (global self-attention)

global self-attention : Volt는 부분만 보지 않고 장면 전체의 토큰을 함께 봅니다.
예) 방 전체를 한눈에 보며 물체 관계를 파악하는 방식입니다.

3️⃣ 3D 위치 정보

Transformer는 위치를 스스로 알지 못하기 때문에 각 조각이 어디에 있는지 알려줘야 합니다.
Volt는 '3D RoPE'라는 위치 표현을 사용하며, x, y, z 방향의 위치 관계를 attention 계산에 넣습니다.

4️⃣ 가벼운 복원 구조

Transformer는 패치 단위로 이해하는데 반해 결과는 점 단위로 예측해야 합니다.
그래서 패치 정보를 다시 촘촘한 공간 정보로 되돌리는 작업을 진행하게 되는데 이때 경량 디코더 구조를 사용했습니다.

5️⃣ 학습 방법 개선

Volt를 그냥 학습하면 데이터를 외워버리는 문제가 생길 수 있기 때문에 이를 방지하기 위해 다음과 같은 방법을 사용합니다.
- 3D 데이터 증강 : 장면을 자르거나 섞어 다양한 예시를 생성
- 정규화 : 모델이 훈련 데이터를 그대로 외우지 않도록 함
- 지식 증류 : 기존 CNN 모델의 예측을 참고해 학습
- 여러 데이터셋 학습 : 더 많은 실내외 3D 데이터를 함께 사용

그림 : Volt 학습 방법의 효과 분석 (보조기법 추가 시 성능이 더 좋아짐)

그림 : 데이터가 늘어날 때의 성능 변화 (Volt는 데이터가 많아질수록 기존 3D 전용모델보다 성능 향상이 큼)

5) 제약사항

데이터가 적으면 성능이 불안정함
- 기본형 Transformer는 강한 3D 전용 규칙이 적음 -> 적은 데이터에서는 shortcut learning이 발생할 수 있음
  - shortcut learning : 모델이 본질적인 구조가 아니라 쉬운 단서만 외워 성능을 내는 현상
학습 recipe가 중요
- 강한 증강, 정규화, 지식 증류가 없으면 Volt의 장점이 잘 드러나지 않을 수 있음.
- 그러므로 구조는 단순하지만 학습 설계는 신중해야 합니다.
패치 크기 선택이 중요
- 작은 패치는 더 정확하지만 느리고, 큰 패치는 빠르지만 작은 물체를 놓칠 수 있음.
- 논문에서는 5×5×5 패치가 정확도와 속도 사이의 균형으로 판단
3D 데이터 규모 자체가 아직 제한적
- 이미지나 언어 분야처럼 대규모 사전학습 데이터가 충분하지 않음

Volt는 3D 장면을 작은 공간 조각으로 나눈 뒤 Transformer로 처리하는 모델입니다. 복잡한 3D 전용 구조를 줄였다는 점이 핵심적인 부분으로 데이터 증강, 정규화, 지식 증류, 다중 데이터셋 학습을 결합하면 최신 3D 모델과 경쟁하거나 더 좋은 성능을 냅니다.

이 논문의 기술적 의의는 3D 인식 분야를 Transformer 생태계와 더 가깝게 연결했다는 것입니다. 향후 이미지, 언어, 3D를 함께 다루는 멀티모달 모델로 확장하기 좋을 것으로 기대됩니다. 동시에 실제 활용 측면에서도 로봇이 실내 공간을 이해하거나 자율주행 차량이 주변 물체와 도로 구조를 파악하는 것, AR, VR, 디지털 트윈 같은 3D 공간 서비스에도 적용될 수 있을 겁니다.

참고자료

사이트) Volt 프로젝트 (링크)
논문) Volume Transformer: Revisiting Vanilla Transformers for 3D Scene Understandin (링크)
코드) Volt github 저장소 (링크)

Q&A

Q. Volt는 기존 3D 모델과 무엇이 다른가요?

기존 모델은 3D 전용 구조와 지역 연산을 많이 사용합니다. Volt는 3D 장면을 작은 부피 패치로 나눈 뒤, 거의 기본형 Transformer Encoder로 전체 장면 관계를 처리합니다.

Q. global self-attention은 3D에서 너무 느리지 않나요?

그럴 수 있지만, Volt는 점 하나하나가 아니라 패치 단위 토큰을 사용합니다. 또 FlashAttention을 활용해 계산과 메모리 부담을 줄였습니다. 논문에서는 PTv3보다 빠르고 메모리도 적게 쓰는 결과를 보였습니다.

Q. Volt의 가장 큰 한계는 무엇인가요?

데이터가 적으면 과적합이 생기기 쉽습니다. 그래서 강한 데이터 증강, 정규화, CNN teacher 기반 지식 증류가 필요합니다. 더 큰 3D 데이터가 확보되면 이 한계는 줄어들 가능성이 있습니다.

Vision Banana : 이미지 생성 모델의 숨은 시각 이해 능력

42morrow — Fri, 24 Apr 2026 17:08:03 +0900

이미지 생성 AI는 이제 단순히 예쁜 그림을 만드는 도구를 넘어섰습니다. 사용자가 '고양이가 창밖을 보는 장면'이라고 말하면, 모델은 고양이의 모습 뿐 아니라 창문, 빛, 배경, 시선의 방향까지 함께 구성합니다. 겉으로는 이미지를 그리는 일처럼 보이지만, 사실 그 안에는 사물의 모양, 위치나 관계를 이해하는 능력이 숨어 있습니다.

최근 인공지능 산업에서는 하나의 모델이 여러 일을 처리하는 방향이 강해지고 있습니다. 언어 모델이 글쓰기, 번역, 추론, 코딩을 모두 다루는 것처럼, 시각 AI도 생성과 분석을 따로 나누지 않으려는 흐름이 생기고 있습니다. 이 논문은 바로 그 흐름을 보여줍니다. 이미지 생성 모델을 조금만 조정하면, 물체를 나누고, 깊이를 추정하고, 표면 방향까지 파악할 수 있다는 점을 실험으로 보입니다.

1) 기존 방식의 문제점

기존 컴퓨터 비전 모델은 보통 작업별로 따로 만들어졌습니다. 예를 들어 이미지에서 사람과 자동차를 구분하는 모델, 물체의 깊이를 추정하는 모델, 표면의 방향을 계산하는 모델이 각각 따로 필요했습니다. 이 방식은 성능을 높이기에는 좋지만, 모델이 특정 작업에만 강해지는 문제가 있습니다.

또 다른 문제는 학습 방식입니다. 세그멘테이션처럼 픽셀 단위로 정답을 만들어야 하는 작업은 사람이 직접 표시한 데이터가 많이 필요합니다. 깊이 추정이나 표면 법선 추정도 특수한 센서나 시뮬레이션 데이터가 필요합니다. 즉, 좋은 모델을 만들려면 많은 비용과 시간이 듭니다.

논문은 이 문제를 다른 방향에서 접근합니다. 즉, '이미지를 잘 생성하는 모델이라면 이미 세상을 어느 정도 이해하고 있지 않을까?'라는 질문을 던지는 것이죠. 그리고 이 질문을 검증하기 위해 Nano Banana Pro라는 이미지 생성 모델을 기반으로 Vision Banana를 만들었습니다.

2) 접근 방식

논문의 핵심 접근은 시각 이해 문제의 답을 모두 'RGB 이미지'로 바꾸는 것입니다. RGB 이미지는 우리가 흔히 보는 빨강, 초록, 파랑 채널로 이루어진 이미지입니다. 예를 들어 도로는 파란색, 사람은 빨간색, 배경은 노란색으로 칠하게 하면, 세그멘테이션 결과를 하나의 이미지처럼 표현할 수 있습니다.

이렇게 하면 이미지 생성 모델에게 '이 사진에서 자동차는 노란색, 사람은 초록색으로 표시한 세그멘테이션 이미지를 만들어라'라고 지시할 수 있습니다. 모델은 원래 이미지를 생성하던 방식 그대로 답을 이미지로 출력합니다. 다만 그 이미지는 보기 위한 그림이 아니라, 다시 컴퓨터 비전 결과로 해석할 수 있는 그림입니다.

논문은 이를 위해 Nano Banana Pro에 아주 적은 양의 비전 작업 데이터를 섞어 instruction-tuning을 수행했습니다. instruction-tuning은 모델이 사용자의 지시를 더 잘 따르도록 추가 학습하는 과정입니다. 중요한 점은 전체 모델을 새로 만들거나 작업별 전용 구조를 붙인 것이 아니라, 기존 이미지 생성 모델의 능력을 크게 유지한 채 시각 이해 능력을 끌어냈다는 점입니다.

3) 모델/기술 아키텍처

Vision Banana의 구조는 '생성 모델을 비전 문제 풀이 모델처럼 쓰는 구조'로 볼 수 있습니다. 입력은 일반 이미지와 텍스트 지시문입니다. 출력은 세그멘테이션 마스크, 깊이 지도, 표면 법선 지도처럼 보이는 RGB 이미지입니다.

그림 : Vision Banana의 전체 작동 흐름

논문 2쪽의 Figure 1은 이 흐름을 잘 보여줍니다. 사용자가 '이 이미지의 깊이 추정 시각화를 생성하라' 또는 '이 물체를 특정 색으로 분리하라'고 요청하면, Vision Banana는 색으로 표현된 결과 이미지를 만듭니다. 이후 이 색상 값을 다시 숫자나 마스크로 변환해 평가합니다.

이 구조의 장점은 하나의 모델이 여러 작업을 처리할 수 있다는 점입니다. 세그멘테이션을 할 때도, 깊이를 추정할 때도, 표면 방향을 계산할 때도 모델 구조는 그대로입니다. 바뀌는 것은 프롬프트와 색상 규칙 뿐!입니다.

4) 세부 적용 기술

1️⃣ RGB 이미지로 비전 문제를 표현하기

Vision Banana는 모든 비전 작업의 출력을 RGB 이미지로 바꿉니다. 세그멘테이션에서는 각 물체나 클래스에 색을 부여합니다. 예를 들어 고양이는 빨간색, 배경은 노란색처럼 표현합니다. 그러면 생성된 이미지를 다시 읽어 각 픽셀이 어떤 클래스인지 알 수 있습니다.

이 방식은 초보자에게 색칠 공부처럼 생각하면 쉽습니다. 원본 사진 위에서 각 물체를 정해진 색으로 칠한 뒤, 그 색을 보고 컴퓨터가 다시 물체의 위치를 알아내는 방식입니다.

2️⃣ 지시문 기반 세그멘테이션

그림 : 색상 지시를 따르는 의미론적 세그멘테이션

위의 그림은 Vision Banana가 다양한 프롬프트 스타일을 이해해 세그멘테이션 결과를 만드는 모습을 보여줍니다. 어떤 경우에는 'cat은 red, background는 yellow'처럼 자연어로 지시하고, 어떤 경우에는 RGB 값이나 JSON 형태로 색상 규칙을 줍니다. 모델은 이런 서로 다른 표현을 이해하고 결과 이미지를 생성합니다.

흥미로운 점은 고정된 클래스만 다루지 않는다는 것입니다. '고양이 수염', '벽의 패턴', '초승달 모양 크루아상'처럼 더 세밀한 표현도 이해합니다. 이는 단순히 픽셀을 분류하는 것을 넘어, 언어와 시각을 함께 해석한다는 뜻입니다.

3️⃣ 인스턴스 세그멘테이션

인스턴스 세그멘테이션은 같은 종류의 물체도 개별적으로 구분하는 작업입니다. 예를 들어 사진에 공이 10개 있다면, '공'이라는 하나의 클래스가 아니라 공 하나하나를 다른 색으로 표시해야 합니다.

그림 : 같은 종류의 물체를 각각 구분하는 인스턴스 세그멘테이션

위의 그림은 마늘 조각, 고기 조각, 가격표, 공 등을 각각 다른 색으로 나누는 예시를 보여줍니다. 이 작업은 이미지마다 물체 개수가 다르고, 미리 색을 정해두기 어렵기 때문에 작업 자체가 어렵습니다. 그럼에도 불구하고 Vision Banana는 한 번에 한 클래스씩 요청 받고, 해당 클래스 안의 개별 물체들을 서로 다른 색으로 칠합니다.

4️⃣ 자연어 표현 이해

Vision Banana는 단순한 물체 이름 뿐만 아니라 설명형 문장도 처리합니다.

그림 : 자연어 설명을 이해하는 지시 기반 세그멘테이션

제공된 예시 이미지에서는 '분홍색 티셔츠를 입은 남자', '몸을 펴는 고양이', '게임 컨트롤러로 쓰이는 토스터', '중국어와 영어로 적힌 셰프 이름' 같은 복잡한 표현을 이해합니다.

즉, 이미지 생성 모델은 단순히 픽셀 패턴을 외운 것이 아니라, 사물의 의미와 관계를 어느 정도 내부적으로 학습했다는 것입니다. 그래서 새로운 지시에도 비교적 자연스럽게 반응합니다.

5️⃣ 깊이 추정

깊이 추정은 한 장의 사진만 보고 각 물체가 카메라에서 얼마나 떨어져 있는지 예측하는 작업입니다. 사람은 사진 속 크기, 가려짐, 원근감으로 거리를 짐작할 수 있습니다. Vision Banana도 비슷하게 이미지 속 단서를 이용합니다.

그림 : 깊이 값을 RGB 색상으로 바꾸는 변환 방식

논문에서는 깊이 값을 RGB 색상으로 바꾸는 특별한 변환 방식을 사용합니다. 가까운 곳과 먼 곳의 차이를 색으로 표현하고, 나중에 이 색을 다시 실제 거리 값으로 되돌립니다.

실험 결과, Vision Banana는 Depth Anything 3 같은 깊이 추정 전문 모델과 비교해 여러 벤치마크에서 비슷하거나 더 좋은 성능을 보였습니다. 특히 렌즈 초점거리처럼 카메라의 기하학적 정보인 카메라 내부 파라미터 없이도 깊이를 추정했다고 하는 점이 중요한 지점입니다.

6️⃣ 표면 법선 추정

표면 법선 추정은 물체 표면이 어느 방향을 보고 있는지 예측하는 작업입니다. 예를 들어 벽은 앞을 향하고, 바닥은 위쪽을 향하며, 곡면 물체는 위치마다 방향이 달라집니다. 이 정보는 3D 복원, 로봇, 증강현실에서 중요합니다.

그림 ; 표면 법선 추정 결과 비교

Vision Banana는 표면 방향을 RGB 색으로 표현합니다. 왼쪽을 향하면 붉은 계열, 위쪽을 향하면 초록 계열, 카메라를 향하면 푸른 계열로 나타내는 식입니다. 위 그림은 Vision Banana가 기존 전문 모델인 Lotus-2보다 더 세밀한 표면 디테일을 표현하는 예시를 보여줍니다.

5) 제약사항

계산 비용 : Vision Banana는 강력한 이미지 생성 모델을 기반으로 하므로, 가벼운 전문 모델보다 실행 비용이 클 수 있습니다. 실제 서비스에 적용하려면 속도와 비용을 줄이는 최적화가 필요합니다.
평가 범위 : 논문은 주로 단일 이미지 입력을 다룹니다. 여러 시점의 이미지나 동영상까지 확장하면 더 많은 가능성이 있지만, 아직 본격적으로 검증된 것은 아닙니다.
특정 작업에서의 성능 차이 : 예를 들어 인스턴스 세그멘테이션에서는 일부 전문 모델보다 약간 낮은 결과가 나왔습니다. 하나의 범용 모델이 모든 작업에서 항상 최고라는 뜻은 아닙니다.

이미지를 잘 생성하는 모델은 단지 그림을 그리는 모델이 아닐 수 있습니다. 그 안에는 물체, 공간, 거리, 표면 방향, 언어적 지시를 이해하는 능력이 함께 들어 있을 수 있습니다. 논문에서는 이 지점을 실험을 통해 보여주고 있습니다.

시각 이해 문제를 RGB 이미지 생성 문제로 바꾸면, 하나의 이미지 생성 모델이 세그멘테이션, 깊이 추정, 표면 법선 추정까지 처리할 수 있습니다. 이는 언어 모델이 텍스트 생성이라는 하나의 인터페이스로 번역, 요약, 추론을 처리하는 흐름과 닮아 있습니다.

실생활 적용 가능성도 큽니다. 자율주행차는 도로와 사람을 구분하고 거리를 알아야 합니다. 로봇은 물체의 위치와 표면 방향을 이해해야 합니다. 증강현실 기기는 현실 공간의 깊이와 구조를 파악해야 합니다. Vision Banana 같은 접근이 더 가볍고 빠르게 개선된다면, 생성 AI가 시각 인식 기술의 기반이 될 수 있습니다.

참고자료

사이트) Vision Banana 프로젝트 (링크)
논문) Image Generators are Generalist Vision Learners (링크)

Q&A

Q. Vision Banana는 그냥 이미지를 예쁘게 생성하는 모델인가요?

아닙니다. 이미지를 생성하는 능력을 이용해 세그멘테이션, 깊이 추정, 표면 법선 추정 같은 시각 이해 작업도 수행합니다.

Q. 왜 결과를 RGB 이미지로 표현하나요?

이미지 생성 모델은 RGB 이미지를 만드는 데 익숙하기 때문입니다. 그래서 정답을 색으로 표현하면 기존 생성 방식을 그대로 사용하면서도 컴퓨터 비전 결과로 다시 변환할 수 있습니다.

Q. 이 방식이 기존 전문 모델을 완전히 대체하나요?

아직은 아닙니다. 여러 작업에서 강한 성능을 보였지만, 계산 비용이 크고 일부 작업에서는 전문 모델이 더 나을 수 있습니다. 다만 하나의 모델로 여러 시각 작업을 처리할 수 있다는 점에서 중요한 방향을 보여줍니다.

[바이브코딩] 디지털 렌티큘러 사이니지 만들어보기

42morrow — Wed, 22 Apr 2026 16:06:28 +0900

렌티큘러 사이니지를 만들어 봤습니다. 우연히 쇼핑몰 광고판에 적용된 것을 봤는데 이런 것을 만들면 재미나겠다 싶어서였죠. 일단 타겟은 모바일용입니다. 대부분의 사이니지는 화면이 큰데 그런 경우에는 스마트폰을 이용하되 그 화면을 캐스팅하는 방식이면 비슷하게 사용할 수 있겠다 싶었습니다. 실제 세로로 돌린 전자칠판에 적용해 봤더니 제법 그럴 듯하게 나오는 것을 확인했죠.

이번 글에서는 렌티큘러가 무엇인지 알아보고 이 기술을 응용해서 간단한 사이니지를 만드는 과정을 정리해 보겠습니다.

1.렌티큘러란?

렌티큘러는 아주 가는 원통형 렌즈 배열을 이용해, 보는 각도에 따라 서로 다른 이미지가 보이게 만드는 시각 표현 기술입니다. 대표적으로 입체감이 느껴지는 3D 효과, 각도에 따라 그림이 바뀌는 플립 효과, 움직여 보이는 애니메이션 효과를 만들 수 있습니다. 핵심 원리는 여러 이미지를 가늘게 분할한 뒤 서로 교차 배열하고, 그 위에 렌티큘러 렌즈를 정밀하게 맞춰 각 시야각에서 다른 정보가 눈에 들어오도록 하는 것입니다.

쉽게 말하면, 일반 인쇄물이 '한 장의 고정된 그림'을 보여준다면, 렌티큘러는 한 장 안에 여러 장의 이미지를 숨겨 두었다가 보는 위치에 따라 꺼내 보여주는 기술이라고 볼 수 있습니다. 그래서 홍보물, 패키지, 카드, 포스터처럼 짧은 순간에 시선을 끌어야 하는 매체에 특히 잘 맞습니다.

2.기술

렌티큘러 구현에는 보통 다음 기술들이 함께 들어갑니다.

렌즈 설계 기술 : 미세한 원통형 렌즈의 간격, 두께, 방향이 맞아야 원하는 시야 분리가 가능합니다.
인터레이싱(interlacing) 기술 : 여러 이미지를 잘게 분할해 하나의 합성 이미지로 정렬하는 과정인데, 이 정렬 오차가 크면 잔상이나 고스팅이 생깁니다.
정밀 인쇄 및 정합(registration) 기술 : 인쇄된 이미지와 렌즈 위치가 정확히 맞아야 효과가 또렷하게 보입니다.

당연히 여기서 의문이 들 수 있습니다. 원통형 렌즈 배열, 3D 효과... 이걸 2D 화면에서 구현해야 한다고? 하며 말입니다. 그래서, 이번 구현에는 물리 세계에서와는 다른 필요한 기술들이 사용됩니다.

디지털 디스플레이 쪽에서는 렌티큘러가 오토스테레오스코픽(안경 없는 3D) 기술의 한 방식으로도 쓰입니다. 이 경우 화면 앞의 광학층이 왼쪽 눈과 오른쪽 눈에 서로 다른 영상을 보내 깊이감을 만들며, 본질적으로는 인쇄형 렌티큘러와 비슷하게 '시야를 분리해서 다른 영상을 전달한다'는 원리를 사용합니다.

3.렌티큘러 응용 기술

렌티큘러는 단순한 3D 인쇄를 넘어서 여러 방식으로 응용됩니다. 예를 들면 다음과 같이 말이죠.

플립 효과 : 보는 방향에 따라 A 이미지가 B 이미지로 바뀌어 보이는 방식
모션/애니메이션 효과 : 연속된 프레임을 넣어 짧게 움직이는 것처럼 보이게 만듦
모프 효과 : 한 대상이 다른 형태로 변화하는 듯한 인상을 줌. 줌 효과는 특정 부분이 튀어나오거나 확대되는 느낌을 강조할 때 쓰임.

이 기술은 실제로 광고 포스터, 패키지, POP, 카드, 앨범 커버, 전시 그래픽, 교육용 시각 자료 등에 폭넓게 활용됩니다. 최근에는 대형 광고물이나 디지털 디스플레이와 결합해, 오프라인 공간에서 강한 주목성을 만드는 방식으로도 확장되고 있습니다. 즉, 렌티큘러는 '인쇄 특수효과'에 머무르지 않고, 브랜드 경험을 강화하는 시각 커뮤니케이션 기술로 응용 범위가 넓어지고 있습니다. 하지만, 아날로그 방식인 경우가 대부분이었습니다.

4.렌티큘러 사이니지란?

렌티큘러 사이니지는 렌티큘러 기술을 간판, 광고판, 전시물, 매장 내 안내물, 쇼윈도 디스플레이 같은 사이니지 매체에 적용한 것을 말합니다. 정적인 평면 광고보다 더 눈에 띄고, 보는 각도에 따라 화면이 바뀌거나 입체적으로 보여서 보행자나 방문자의 시선을 끌기에 유리합니다. 특히 매장, 박람회, 옥외광고, 브랜드 프로모션처럼 '짧은 순간에 주목을 확보해야 하는 환경'에서 강점이 있습니다. 실제로 그렇게 시선이 끌린 사람 중에 저도 있었습니다. ^^;

요즘은 이 개념이 인쇄형 사이니지를 넘어 안경 없는 3D 디지털 사이니지로도 확장되고 있습니다. 삼성의 최근 Spatial Signage 소개처럼, 디스플레이와 광학 부품을 결합해 각 눈에 다른 영상을 보내는 방식은 렌티큘러 카드와 유사한 원리를 디지털 화면에 적용한 사례로 볼 수 있습니다. 따라서 오늘날 '렌티큘러 사이니지'는 좁게는 렌티큘러 인쇄 광고물을, 넓게는 광학 시야 분리를 활용한 3D 사이니지 전반을 가리키는 표현으로 쓰이기도 합니다.

5.렌티큘러 사이니지 만들기

1) 기본 구조

단일 HTML로 HTML + CSS + JavaScript(module)를 함께 넣은 형태
Canvas 기반 렌더링 : 실제 렌티큘러 효과 표현은 HTML5 Canvas 2D API 로 구현합니다. 메인 캔버스에 직접 그리는 방식이며, 두 장의 이미지를 잘게 나눈 세로 스트립 단위로 번갈아 그려서 시점 변화에 따라 화면이 달라지는 것처럼 보이게 합니다.
오프스크린 캔버스 활용 : 원본 이미지를 바로 계속 그리지 않고, 별도의 Offscreen용 canvas 역할을 하는 보조 canvas 2개를 만들어 미리 이미지 크기를 맞춰 놓고 사용합니다.
렌티큘러 표현 로직 : 화면을 일정 폭(stripWidth)의 세로 조각으로 나눈 뒤, 각 조각 안에서 이미지1과 이미지2의 비율을 조정해 그리는 방식입니다. 이 비율이 currentRatio 값에 따라 변하면서, 관찰 위치에 따라 다른 영상이 보이는 듯한 렌티큘러/시차 전환 효과를 모사합니다.
MediaPipe 얼굴 인식 : 사용자의 위치를 알아내기 위해 MediaPipe Tasks Vision의 FaceDetector를 CDN에서 불러와 사용합니다. 얼굴의 바운딩 박스를 검출하고, 그 중심 X 좌표를 이용해 사용자가 화면의 왼쪽에 있는지 오른쪽에 있는지를 추정합니다.
브라우저 카메라 접근 : navigator.mediaDevices.getUserMedia()를 사용해 전면 카메라 영상 스트림을 가져옵니다. 숨겨진 <video> 요소에 영상을 넣고, 이 영상을 MediaPipe가 분석하는 입력으로 사용합니다. 즉, 비디오 입력은 분석용, 캔버스는 출력용으로 분리되어 있습니다.
사용자 이미지 업로드 : 기본 이미지 2장 외에도 사용자가 직접 이미지를 선택할 수 있도록 <input type="file" multiple> 과 FileReader를 사용했습니다. 업로드된 두 이미지는 Data URL로 읽어서 즉시 렌티큘러 효과용 이미지로 교체됩니다.

2) 최종 결과물

구현된 결과물을 이용해 테스트 영상을 찍은 것입니다. 모바일에서 동작시켜 앞에서 살짝씩 움직임을 줘가며 변화하는 장면을 영상으로 저장한 것이죠.

사용하는 방식은 상단 이미지 선택 버튼을 클릭해서 적용할 사진(혹은 이미지)을 선택하면 끝입니다. 그런 뒤에는 스마트폰의 카메라가 사용자의 움직임을 추적해서 보는 각도에 따라 보여주는 화면을 달리하는 방식으로 구동됩니다.

Data Poisoning Attack : LLM이 의외로 소량의 악성 데이터에 무너질 수 있다

42morrow — Tue, 21 Apr 2026 14:39:22 +0900

최근 인공지능, 특히 대형 언어 모델(LLM)은 빠르게 발전하고 있습니다. 많은 기업과 서비스에서 활용되면서, 모델을 더 똑똑하게 만드는 것이 중요한 과제가 되었습니다. 그런데 이 과정에서 한 가지 간과하기 쉬운 문제가 있습니다. 바로 ‘데이터의 신뢰성’입니다. LLM은 인터넷에서 수집한 방대한 데이터를 기반으로 학습하는데, 이 데이터가 항상 안전하다고 보장할 수는 없습니다.

그리고 여기서 등장하는 개념이 바로 ’데이터 중독 공격(Data Poisoning)’입니다. 이는 학습 데이터에 일부러 잘못된 정보를 섞어서 모델의 행동을 조작하는 공격입니다. 겉으로는 정상적으로 보이지만, 특정 조건에서는 이상한 행동을 하도록 만드는 것이 특징입니다. 예를 들어 특정 단어가 나오면 갑자기 이상한 답변을 하게 만드는 식입니다.

이 글에서는 이러한 공격이 얼마나 위험한지, 그리고 기존 생각과 달리 얼마나 적은 양의 데이터로도 가능한지를 설명합니다.

1) 기존 방식의 문제점

기존 연구에서는 공격자가 전체 데이터의 일정 비율(예: 0.1%)을 조작해야 공격이 성공한다고 가정했습니다. 하지만 LLM은 데이터 규모가 매우 크기 때문에, 이 방식은 현실적으로 어렵다고 여겨졌습니다. 예를 들어 수십억 개의 데이터 중 0.1%만 조작하려 해도 엄청난 양이 필요합니다. 그래서 많은 사람들이 ‘모델이 커질수록 공격은 어려워진다’고 생각했습니다.

하지만 이 논문은 이 가정이 틀렸다고 말합니다!

2) 접근 방식

연구진은 새로운 질문을 던집니다.

‘정말 데이터 비율이 중요할까? 아니면 단순한 개수만 중요할까?’

이를 확인하기 위해 다양한 크기의 모델(600M~13B 파라미터)을 직접 학습시키고, 동일한 개수의 악성 데이터(예: 250개)를 넣어 실험했습니다. 결과는 놀랍게도, 데이터가 20배 이상 많아져도, 공격 성공률은 거의 동일했습니다. 즉, 데이터 비율이 아니라 '절대 개수'가 중요하다는 것입니다.

3) 모델/기술 아키텍처

이 논문은 기본적으로 트랜스포머 기반 LLM 구조를 사용하며, 핵심 구조 흐름은 다음과 같습니다.

대량의 텍스트 데이터 입력
일부 데이터에 '트리거(trigger, 특정조건)' 삽입
예) 특정 단어가 나오면 이상한 답변 생성
트리거 이후 특정 이상 행동 학습

그림 : 사전학습 단계(좌)와 파인튜닝 단계(우)에서의 백도어 공격 개요

4) 세부 적용 기술

백도어 공격 (Backdoor Attack) :
특정 조건에서만 이상 행동을 하도록 만드는 방식으로 평소에는 정상 작동하기 때문에 발견이 어렵습니다.
예) 특정 문장이 포함되면 이상한 답 출력
트리거 기반 학습 :
모델이 특정 '신호'를 기억하도록 학습합니다. 즉, 숨겨진 스위치처럼 작동하도록 합니다, 후최면 암시같은...
- 트리거 등장 → 공격 행동 실행
- 트리거 없음 → 정상 동작
퍼플렉시티(perplexity) 기반 평가 :
퍼플렉시티는 모델이 문장을 얼마나 잘 이해하는지를 나타내는 지표입니다.
이 값이 높을수록 이상한 문장이 생성되기 때문에 논문에서는 트리거 입력 시 퍼플렉시티가 급증하면 공격 성공으로 판단합니다.
데이터 스케일 실험 :
모델 크기와 데이터 양을 크게 늘려도 결과가 유지되는지 확인했습니다.
- 실험 조건 : 600M → 13B 모델까지 실험, 데이터 20배 증가
- 결과 : 동일한 250개 악성 데이터로 모두 공격 성공
- 데이터 비율이 아니라 '악성 데이터 개수'가 더 중요하다는 것을 보여줌.

그림 : 모델 크기와 상관없이 유지되는 공격 성공률

파인튜닝 공격 확장 :
사전학습뿐 아니라 파인튜닝에서도 동일 현상이 발생합니다. 즉, 학습단계 어디서든 위험하다는 얘기입니다.
- 적은 수의 악성 데이터를 사용하더라도 모델 전체 행동 변화 발생

5) 제약사항

추가적인 정상 학습을 계속하면 공격 효과가 약해질 수 있음
실제 서비스 환경에서 공격이 얼마나 오래 유지되는지는 추가 연구 필요
더 복잡한 공격(예: 행동 조작)은 아직 제한적으로 연구됨

이 논문은 ‘모델이 커질수록 안전해지는 것이 아니라, 오히려 더 위험해질 수 있다’ 는 중요한 사실을 말해 줍니다. 그 이유는 간단합니다.

공격자는 여전히 적은 수의 데이터만 넣으면 되지만, 데이터가 많아질수록 숨기기가 더 쉬워지기 때문입니다.

우리가 믿고 사용하는 GPT, Gemini, Qwen, Llama 등의 다양한 AI 모델에는, 이미 이런 시한폭탄을 내재되어 있을지도 모릅니다. 그게 모델을 개발한 기업에서 의도했건 그렇지 않고 외부에서 의도했건 말이죠. 최근 AI가 컴퓨터를 직접 조작할 수 있는 Agentic AI가 대세로 바뀌고 있죠. 만약에 만약에 후최면 암시처럼 누군가가 '이젠 마무리하자'와 같은 트리커 키워드를 이용해 지구의 종말을 가져올 핵폭탄 발사 버튼을 동작케 할 수도 있을지도 모릅니다.

이 연구는 앞으로 LLM 개발에서 반드시 고려해야 할 방향을 제시합니다.

데이터 검증 강화 필요
학습 과정에서 이상 탐지 기술 필요
백도어 제거 기술 연구 필요

참고자료

논문) POISONING ATTACKS ON LLMS REQUIRE A NEAR-CONSTANT NUMBER OF POISON SAMPLES (링크)

Q&A

Q. 왜 적은 데이터로도 공격이 가능한가요?

A. LLM은 패턴을 빠르게 학습하기 때문에, 특정 트리거와 행동이 강하게 연결되면 적은 데이터로도 기억됩니다.

Q. 모델이 클수록 왜 더 위험한가요?

A. 데이터가 많아질수록 공격 데이터가 더 잘 숨겨지고, 모델은 적은 샘플에서도 학습을 잘 하기 때문입니다.

Q. 이런 공격을 막을 방법은 없나요?

A. 데이터 필터링, 이상 행동 탐지, 추가 학습 등이 있지만 아직 완벽한 해결책은 없습니다.

[바이브코딩] 기제사에 쓰이는 축문/지방 자동생성기

42morrow — Mon, 20 Apr 2026 16:37:39 +0900

집에서 기제사를 지낼 때 준비해야 하는 것으로 지방, 축문 같은 것이 있습니다.

연배가 있는 분들 중에 본인이 제주인 사람들은 한번씩은 이것들을 써봤을 것입니다. 최근에는 한글로 된 것을 이용하는 경우도 있다고 들었는데 저는 아직은 경험해 보진 못했습니다.

지방의 경우, 날짜와는 무관하게 정형화된 문구를 쓰기 때문에 문제가 되진 않습니다. 그런데 축문의 경우에는 음력으로 기제사 날의 간지를 계산해야 하기 때문에 항상 간지달력을 찾아봐야 하는 번거로움이 있습니다.

그래서, 이번 글에서는 기제사에 사용되는 지방, 축문 생성 앱을 만들고 그 과정을 간단히 정리해봤습니다.

참고) 어린 시절 기억을 되살려보면, 간지달력은 예전에는 새마을금고 같은 곳에서 매년 나눠주던 것들이 제일 좋았습니다. 달력으로 쓰다가 다 쓰면 뒷면에 낙서를 하거나 접어서 뭔가를 만들곤 했었죠. 최근에는 간지달력 웹이나 앱을 이용하는 경우가 대부분일 겁니다.

1.개요

한국 전통 제례(기제사·차례)에서 쓰는 두 가지 문서를 자동으로 생성하는 단일 HTML 앱으로 생성합니다.

지방(紙榜) : 제사 대상자의 신위를 적은 위패 대용으로 사용되는 것
축문(祝文) : 제사 중 낭독하는 고유문(告由文)

2.기술 스택

순수 HTML/CSS/JS 로 단일 HTML 파일로 구현
만세력 라이브러리를 import 해서 사용 (연결되지 않을 경우, 간지를 빈칸으로 처리)
참고) 만세력 라이브러리는 음력↔양력 변환, 간지 계산을 위한 라이브러리 (링크)

3.지방/축문 관련 사항

표기 방식 : 한자 정통형 / 한글 음독형 / 완전 한글형 중 선택 사용
지방 구조
- 남성 : 顯　考 + 직위(學生/處士/관직) + 府君 + 神位
- 여성 : `府君` 대신 본관성씨(예: `金海金氏`)를 사용하도록 함
축문 구조
- 維 | 歲次+간지+년월삭일 | 제주+敢昭告于 | 대상자 | 歲序遷易 | 諱日復臨…昊天罔極 | 謹以…尙 | 饗
- `顯` 뒤에 전각 공백 (`　` U+3000) 1자 삽입 (한자 정통형 스타일에만 적용)
- 제주 역할(孝子 등) 뒤에도 전각 공백 삽입 후 이름 표기
- 대상은 1위(한분), 2위(합설) 둘 다 지원
- 한자 정통형 스타일의 `顯` 뒤에는 반드시 `　`(U+3000) 포함
  - 아버지 : `顯　考`, 어머니 : `顯　妣`
  - 할아버지 : `顯　祖考`, 할머니 : `顯　祖妣`
  - 증조 : `顯　曾祖考/妣`, 고조 : `顯　高祖考/妣`
- 제주 호칭 : `효자·효녀·손·장손·현손·고손` — `WRITER_ROLES` 객체에서 관리

4.기타사항

웹폰트 : 조선궁서체 (CDN 웹폰트, 링크)를 사용
설정 내보내기/가져오기 : 날짜, 계산 결과만 제외하고 나머지 설정만 json으로 저장
인쇄 및 미리보기 지원

5.유의사항

축문의 경우, 문구나 쓰는 방식 등이 집안이나 지방에 따라 다른 경우가 많다고 합니다.
여기서 보인 것은 표준이 아니라 그런 다양한 경우 중 많이 사용되는 한 예시라고 이해해 주세요.

6.최종 결과물

위의 기준으로 생성된 결과물은 다음과 같습니다. 아래는 2026년 1월 1일 기준으로 생성해서 축문 부분만 펼쳐서 보인 것입니다. 만세력이 적용되어 별도로 간지를 찾아볼 필요가 없다는 점이 마음에 듭니다. ^^

앤스로픽의 Mythos, 엔비디아의 Ising, 알리바바의 HappyHorse-1.0

42morrow — Thu, 16 Apr 2026 10:26:06 +0900

최근에는 장난감 만드는데 시간을 보내고 있어서 글 쓰는 것을 살짝 소홀히 하고 있습니다. 그래서, 오늘은 간단히 최근 회자되고 있는 AI 관련 중요 소식만 요약 정리해 봤습니다.

1. 앤스로픽의 미토스(Mythos)

1) 어떤 기술인가

미토스는 앤스로픽이 일반 공개 대신 제한된 연구 프리뷰 형태로 다루는 최전선 모델.
코딩·데이터 생성·에이전트형 작업에 많이 사용됨.
주요 운영체제, 주요 웹브라우저의 제로데이 취약점을 찾아내고, 그 취약점을 실제 익스플로잇으로 연결할 수 있음.
실제, 테스트 과정에서 27년 된 OpenBSD 버그 등 다수의 취약점을 찾아냈다고 함.

2) 이 때문에 발생한 미국 정부의 움직임이 있었다고 하던데?

미국 상무부 산하 Center for AI Standards and Innovation이 미토스의 해킹 역량을 시험 진행 (by 로이터)
(트럼프 대통령의 앤스로픽 협업 금지 방침이 있는 상황이었음)
3개의 의회 위원회 관계자들도 미토스의 사이버 기능 관련 브리핑을 요청하거나 진행 (by 폴리티코)
미토스 관련 경고 이후 미 재무장관과 연준 의장이 은행 CEO들과 긴급 회의를 열었고, 트럼프 대통령도 은행 시스템 내 AI 위험을 인정하면서 정부 안전장치, 이른바 '킬 스위치' 필요성에 동의했다고 전해짐.

3) 파급효과

사이버보안의 방어 체계가 AI 전제로 재편
- 앤스로픽은 미토스 때문에 생길 위험을 방어 쪽으로 먼저 돌리겠다며 Project Glasswing을 만듦
- AWS, Apple, Cisco, CrowdStrike, Google, Microsoft, NVIDIA, JPMorganChase 등과 함께 핵심 소프트웨어 보안을 강화하기로 함.
- 고위험 AI 모델의 배포 방식이 달라질 가능성
  - 미토스는 일반 공개가 아니라 제한적 접근으로 운영되고 있음.
  - 정부·금융권도 '생산성 도구'가 아니라 '국가 기반시설 리스크 요인'으로 보기 시작함
  - 즉, 앞으로는 강한 사이버 역량을 가진 모델일수록 공개형보다 통제형 배포가 늘어날 가능성이 높아짐.

2. 엔비디아 아이징(Ising)

1) 어떤 기술인가

아이징은 엔비디아가 발표한 양자컴퓨팅 전용 오픈 AI 모델 계열.
즉 양자 하드웨어를 실제로 더 안정적으로 운용하기 위한 운영·제어용 AI
- Ising Calibration : 양자 프로세서(QPU)의 보정 작업을 자동화하는 비전-언어 모델
- Ising Decoding : 양자 오류 정정을 위한 3D CNN 계열 모델
이 모델군이 양자 오류 정정의 디코딩 단계에서 최대 2.5배 빠른 성능과 최대 3배 높은 정확도를 제공했다고 함.
Calibration 쪽은 자사 QCalEval 벤치마크에서 Gemini 3.1 Pro, Claude Opus 4.6, GPT 5.4보다 높은 점수를 획득.

2) 발표 이후 시장의 파장

엔비디아가 양자 생태계의 소프트웨어/AI 층까지 본격 지원한다는 신호로 받아들여짐 -> 양자컴퓨팅 상용화 가속 신호
Investopedia와 MarketWatch에 따르면, 아이징 발표 뒤 IonQ, Rigetti, D-Wave 같은 양자 관련 종목들이 두 자릿수 상승률을 보이며 급등했고, 엔비디아 주가도 함께 상승함

3) 예상되는 파급효과

양자컴퓨팅의 병목이 하드웨어 단독 문제가 아니라, 보정·오류정정·운영 자동화 문제라는 인식이 더 강해짐
젠슨 황의 “AI가 양자기계의 운영체제(control plane)가 된다”고 표현한 것이 같은 맥락
향후 양자 분야의 경쟁력은 큐비트 수만이 아니라 AI 기반 제어 소프트웨어, 그리고 GPU-양자 하이브리드 스택의 완성도에서 갈릴 가능성이 커짐

3. 알리바바의 영상 생성 모델 해피호스(HappyHorse-1.0)

1) 어떤 모델인가

알리바바가 자사 ATH(Token Hub) 혁신 조직에서 개발했다고 확인한 영상 생성 모델
현재는 내부 테스트 중이고, 회사 측은 API를 곧 공개할 계획이라고 밝힘
Artificial Analysis의 블라인드 선호도 기반 비디오 리더보드에서 빠르게 상위권, 사실상 1위권으로 올라섰음. (기존 Seedance 2.0을 넘어섬)

2) 기존 최신 모델과의 차별점

가장 큰 차별점은 성능. Artificial Analysis 기준으로 해피호스는

Text-to-Video with audio에서 1위(1224)로 Seedance 2.0 720p(1221)를 근소하게 앞섰고,
Text-to-Video without audio에서도 1위(1359)
Image-to-Video without audio에서도 1위(1398)
Image-to-Video with audio에서는 Seedance 2.0 720p가 1위(1175), 해피호스가 2위(1166)
즉, 해피호스는 전체 부문 절대 우위라기보다는 특히 무음 기준 화질·선호도와 T2V 영역에서 강한 모델

TTC(Test-Time Correction) : 재학습 없이 긴 영상을 안정적으로 생성하는 기술

42morrow — Tue, 14 Apr 2026 16:12:53 +0900

짧은 영상은 이제 꽤 자연스럽게 만들어집니다. 하지만 영상 길이가 길어지면 이야기가 달라집니다. 처음에는 사람 얼굴이 잘 나오다가도, 몇 초 뒤에는 표정이 흐트러지거나 배경이 슬쩍 바뀌고, 움직임도 어색해집니다. 한 장면씩 이어 붙이며 만드는 방식은 빠르고 효율적이지만, 앞에서 생긴 작은 오차가 뒤로 갈수록 커지는 문제가 있습니다. 이번 논문에서는 바로 이 지점을 다루고 있습니다. '어떻게 하면 이미 학습된 빠른 영상 생성 모델을 다시 훈련하지 않고도 더 오래, 더 안정적으로 작동하게 만들 수 있을까'라는 질문에서 출발하는거죠.

이 문제는 최근 인공지능 산업 흐름과도 맞닿아 있습니다. 요즘은 무조건 큰 모델을 다시 학습시키기보다, 이미 만들어진 모델을 실제 사용 시점에서 더 똑똑하게 쓰는 방법이 중요해지고 있습니다. 비용과 시간은 줄이면서 품질은 높여야 하기 때문입니다. 이 논문은 그런 흐름 속에서 'Test-Time Correction', 즉 생성하는 도중에 살짝 바로잡는 방식을 제안합니다. 핵심은 처음 장면을 기준점처럼 삼아, 영상이 너무 멀리 벗어나지 않도록 중간중간 경로를 수정하는 것입니다. 복잡한 재학습 없이 긴 영상의 일관성을 높인다는 점에서 실용성이 큽니다.

그림 : 영상 생성 결과 비교 (CausVid와 Self-Forcing에 TTC 적용 시)

1. 기존 방식의 문제점

현재 빠른 영상 생성에 많이 쓰이는 방식은 자기회귀(Autoregressive) 방식입니다. 쉽게 말하면, 영상을 앞 프레임부터 차례로 만들어 나가는 방식이에요. 각 프레임(또는 청크)은 이전에 생성된 프레임을 조건으로 삼아 다음 프레임을 예측하는거죠.

문제는 이 조건이 완벽하지 않다는 점입니다. 처음에 아주 작은 오차가 생기면, 그 오차가 다음 프레임의 입력이 되고, 또 그 오차가 그 다음 프레임으로 전달되어 결과적으로 구르는 눈덩이가 커지듯 오차도 커지게 됩니다. 마치 전화를 여러 사람을 거쳐 전달하면 내용이 변하는 것처럼요. 이걸 시간적 드리프트(Temporal Drift)라고 부릅니다.

이 문제를 해결하려는 기존 시도들은 크게 두 갈래였습니다.

재학습 기반 방법 :
Rolling Forcing, LongLive, Self-Forcing++ 같은 방법들은 모델을 추가로 파인튜닝하거나 특수한 메커니즘을 도입해 긴 영상에서의 일관성을 유지합니다. 성능은 좋지만, 상당한 계산 자원이 필요하고 새 모델마다 다시 학습해야 한다는 단점이 있죠.
테스트 시점 최적화(Test-Time Optimization, TTO) :
모델을 바꾸지 않고, 추론 시점에 보조 목표(리워드)를 정해서 잠깐 최적화를 수행하는 방식입니다. 이미지나 짧은 영상엔 효과적이지만, 긴 영상에 적용하면 두 가지 문제가 생깁니다.
- 리워드 설계의 어려움 : 긴 영상의 시간적 일관성을 하나의 목표 함수로 잡기가 매우 어렵습니다. 픽셀 수준 복원 손실을 쓰면 동작이 사라지고, 의미론적 유사도를 쓰면 프레임 단위 교정 신호가 부족합니다.
- 최적화 붕괴(Optimization Collapse): 증류(distillation)된 모델은 파라미터에 매우 민감합니다. TTO를 적용하면 아주 작은 그래디언트 업데이트에도 모델이 엉뚱한 방향으로 무너져버립니다.

논문의 장난감 실험(Toy Experiment)에서도 이 두 가지 TTO 방식을 실제로 테스트해 확인했습니다. 복원 손실 방식은 나중 프레임이 첫 프레임을 그대로 복사하는 문제가 생겼고, 의미론적 방식은 드리프트를 제대로 막지 못했다고 합니다.

2. 접근 방식

논문에서는 '파라미터를 건드리지 말고, 샘플링 경로 자체를 교정하는' 방식을 제안합니다.

Diffusion 모델은 순수한 노이즈에서 시작해서 조금씩 노이즈를 걷어내며 이미지를 만들어가죠. 증류된 few-step 모델은 이 과정을 4~8단계로 줄였는데, 각 단계 사이에 다시 노이즈를 주입(re-noise)합니다. 이 때문에 중간 상태는 고정된 값이 아니라 여전히 유연하게 수정될 수 있습니다.

TTC는 이 점에 착안했습니다. 샘플링이 진행되는 도중, 특정 스텝에서 잠깐 첫 프레임을 기준점으로 삼아 교정을 수행하고, 그 교정된 결과를 다시 현재 노이즈 수준으로 되돌려 자연스럽게 다음 스텝으로 이어지게 합니다. 모델 파라미터는 전혀 건드리지 않고요.

그림 : 샘플링 경로 비교와 TTC의 위치 (일반생성 경로 vs sink기반 vs TTC 적용 방식)

3. 모델/기술 아키텍처

TTC의 전체 파이프라인은 Figure 6에 잘 나타나 있습니다. 기본적으로 기존 자기회귀 확산 모델 위에 희소한 교정 스텝(sparse correction steps) 을 삽입하는 구조입니다.

청크 단위로 영상을 생성할 때, 각 청크의 샘플링 경로 중 일부 스텝에서 다음 두 단계가 추가됩니다.

Phase A (참조 기반 교정) : 현재 예측값에 노이즈를 주입해 다음 노이즈 레벨로 이동한 뒤, 진화하는 컨텍스트 대신 첫 프레임(S₀)만을 조건으로 디노이징을 수행합니다. 이렇게 하면 첫 프레임의 시각적 특성에 맞게 교정된 예측값을 얻을 수 있습니다.
Phase B (재노이징 & 재디노이징) : 교정된 예측값에 다시 노이즈를 주입해 현재 노이즈 레벨로 돌려놓은 뒤, 이번엔 원래의 진화하는 컨텍스트(Sₜ)로 최종 디노이징을 수행합니다. 이렇게 하면 교정의 효과가 기존 샘플링 흐름에 자연스럽게 흡수됩니다.

이 구조의 핵심은 교정이 경로 위에서(on-path) 이루어진다는 점입니다. 잠재 변수를 직접 교체하는 게 아니라, 노이즈-디노이즈 전환 안에 녹아드는 방식이죠.

그림 : TTC 전체 파이프라인

4. 세부 적용 기술

1️⃣ 초기 프레임 앵커링

가장 중요한 기술은 첫 프레임을 안정적인 기준으로 삼는 것입니다. 논문에서는 첫 프레임이 영상 정체성을 가장 잘 보존한다고 봅니다. 인물의 생김새, 배경 분위기, 색감 같은 핵심 정보가 여기에 담겨 있기 때문입니다. 그래서 뒤쪽 조각이 흔들리기 시작할 때, 이 첫 프레임을 참조해 다시 정렬합니다.

2️⃣ 교정 타이밍의 선택 (Correction Timing)

생성 초반의 높은 노이즈 단계에서는 면의 전체 구조(레이아웃, 공간 관계)가 결정되고, 후반의 낮은 노이즈 단계는 세부적인 외형(텍스처, 색감)이 정제됩니다. 따라서 초반에 건드리면 카메라 구도나 장면 배치 자체가 흔들릴 수 있습니다.
TTC는 구조가 이미 안정화된 이후, 즉 외형 정제 단계에서만 교정을 적용합니다. 이렇게 하면 구조적 변형 없이 외형만 첫 프레임에 맞게 조율할 수 있습니다.

2️⃣ 경로 기반 교정 vs. 단일 지점 교정 (Pathwise vs. Single-point)

처음엔 특정 디노이징 스텝에서 잠재 변수를 교정된 값으로 직접 교체하는 단순한 방법(Single-point Correction)을 떠올릴 수 있을 겁니다. 그런데 이 방식을 쓰면 청크 경계에서 깜빡임(flickering)과 시각적 불연속성이 심각하게 발생합니다.

그래서, TTC의 경로 기반 방법은 교정된 상태를 다시 노이징해서 경로에 통합합니다. 수정된 결과를 모델이 받아들일 수 있는 자연스러운 형태로 바꾸는 과정인 셈인데, 이를 통해 전환이 훨씬 부드럽게(결과가 덜 튀고, 경계도 부드럽게) 진행됩니다.

3️⃣ Sink 기반 방법과의 차이

LongLive 등 일부 방법은 '싱크 프레임'을 전체 디노이징 과정에 지속적으로 조건으로 사용합니다. 이 방법은 모델이 항상 싱크 프레임을 참조하도록 강제하기 때문에, 생성된 영상이 그 프레임 근처에 멈추는 경향이 있습니다. 동작이 줄어들고 영상이 정적으로 변하는 부작용이 생기죠.

반면에 TTC는 구조 안정화 이후에만 교정을 적용하고 경로에 자연스럽게 녹여내기 때문에, 동적 특성을 잘 유지합니다.

5. 제약사항

속도 저하 : TTC를 적용하면 각 청크마다 교정 스텝이 추가되므로 추론 속도가 다소 감소합니다.
짧은 영상에 대한 효과 미미 : 5초 이하의 짧은 영상에서는 오류 누적 자체가 크지 않아 TTC의 개선 효과도 상대적으로 작습니다.
첫 프레임 품질 의존성 : 교정의 기준점이 첫 프레임이기 때문에, 첫 프레임 자체가 품질이 낮거나 프롬프트와 맞지 않으면 교정 효과가 제한됩니다.
기반 모델 제약 : 현재 실험은 Wan2.1-T2V-1.3B 기반의 CausVid, Self-Forcing 두 모델에서만 검증되었습니다. 다른 아키텍처로의 일반화 범위는 추가 검증이 필요합니다.
하이퍼파라미터 설정 : 어느 노이즈 레벨에서 교정을 적용할지(correction indices)는 모델과 생성 설정에 따라 조정이 필요할 수 있습니다.

TTC는 '재학습 없이도 긴 영상 생성의 안정성을 높일 수 있다'는 것을 보여준 의미 있는 연구입니다. 핵심 아이디어는 Diffusion 모델의 확률적 샘플링 경로 자체가 교정 가능한 유연성을 내포하고 있다는 통찰에서 출발했습니다. 첫 프레임을 닻(anchor)으로 삼아 경로 위에서 조용히 교정을 수행함으로써, 30초짜리 영상도 처음과 끝이 일관되게 유지될 수 있습니다.

물론 속도 저하라는 트레이드오프가 존재하고, 아직 두 모델 위에서만 검증되었다는 한계도 있습니다. 하지만 추가 학습이 전혀 필요 없다는 점에서, 다양한 자기회귀 영상 생성 모델에 쉽게 붙여 쓸 수 있는 플러그인 방식의 솔루션으로서 실용 가치가 높습니다. 앞으로 영상 생성 모델이 더 긴 시퀀스를 다루게 될수록 이런 추론 시점 안정화 기법의 중요성은 점점 커질 거예요.

참고자료

사이트) Pathwise_TTC 프로젝트 및 데모 (링크)
논문) Pathwise Test-Time Correction for Autoregressive Long Video Generation (링크)
코드) Pathwise_TTC github 저장소 (링크) - 코드가 올라와 있진 않습니다.

용어 해설

자기회귀(Autoregressive) 생성 : 이전 출력을 다음 입력으로 사용하며 순차적으로 데이터를 생성하는 방식. 언어 모델이 단어를 하나씩 예측하는 방식과 동일한 원리임
Diffusion 모델 : 순수 노이즈에서 출발해 점진적으로 노이즈를 제거하며 데이터를 생성하는 생성 모델. 현재 이미지·영상 생성 분야의 주류 방법
증류(Distillation) / Step Distillation : 수십~수백 단계가 필요한 Diffusion 모델을 4~8단계만으로도 비슷한 품질을 내도록 압축하는 기술
잠재 변수(Latent Variable) : 모델이 내부적으로 다루는 압축된 표현. 픽셀 공간 대신 이 공간에서 연산이 이루어짐
테스트 시점 최적화(TTO) : 추론 단계에서 보조 목표를 두고 모델 파라미터를 일시적으로 최적화하는 방법
LoRA (Low-Rank Adaptation) : 대형 모델을 효율적으로 파인튜닝할 수 있는 기법
VBench : 영상 생성 모델 평가에 쓰이는 표준 벤치마크. 주제 일관성, 배경 일관성, 동적 정도, 움직임 부드러움, 이미지 품질, 미적 품질 등을 측정함
JEPA (Joint-Embedding Predictive Architecture) : 비지도 학습 기반 시각 표현 모델. 이 논문에서는 생성된 영상의 장기적 의미 일관성을 평가하는 데 활용됨
t-LPIPS: 시간적으로 인접한 프레임 간 지각적 차이를 측정하는 지표. 청크 경계에서의 깜빡임 정도를 나타냄

Q&A

Q. TTC는 어떤 영상 생성 모델에도 적용할 수 있나요?

원칙적으로는 few-step 확률적 샘플링을 사용하는 자기회귀 Diffusion 모델이라면 적용 가능합니다. TTC가 활용하는 건 파라미터가 아닌 샘플링 경로의 유연성이기 때문이죠. 다만 결정론적 ODE 기반 샘플러를 사용하는 모델은 중간 상태가 고정되어 있어 교정의 여지가 없습니다. 논문은 CausVid와 Self-Forcing에서만 검증했으므로, 다른 아키텍처에서의 효과는 추가 확인이 필요합니다.

Q. 첫 프레임만 기준으로 삼으면 영상이 지나치게 첫 프레임에 고착되지 않나요?

좋은 질문입니다. 이 우려가 바로 'Sink 붕괴(Sink Collapse)' 문제입니다. TTC는 이를 두 가지 방식으로 해결합니다.

구조가 이미 결정된 이후(낮은 노이즈 레벨)에만 교정을 적용해 레이아웃 변화를 방지합니다.
교정 이후 반드시 재노이징 → 원래 컨텍스트(Sₜ)로 재디노이징하는 과정을 거쳐, 교정이 영상의 동적 흐름을 과도하게 억제하지 않도록 합니다.

실험에서도 TTC가 Sink 기반 방법보다 동적 정도(Dynamic Degree)를 더 잘 유지함을 확인했습니다.

Q. 기존 Test-Time Optimization(TTO)과 TTC의 가장 근본적인 차이는 무엇인가요?

TTO는 파라미터 공간에서의 최적화입니다. 보조 목표를 정하고 역전파를 통해 모델 가중치(또는 LoRA 어댑터)를 업데이트하죠.

반면 TTC는 샘플링 공간에서의 개입입니다. 파라미터는 전혀 건드리지 않고, 생성 도중 중간 잠재 상태를 첫 프레임 조건으로 교정한 뒤 다시 경로에 통합합니다. 증류된 모델은 파라미터 변화에 극도로 민감해서 TTO가 쉽게 붕괴하지만, 상태 공간 개입에는 훨씬 안정적으로 반응한다는 것이 TTC의 핵심 근거입니다.

MatAnyone 2 : 학습된 품질 평가기(MQE)로 비디오 매팅을 스케일업하다

42morrow — Mon, 13 Apr 2026 18:13:18 +0900

영화나 유튜브 영상에서 사람만 깔끔하게 배경에서 분리해내는 기술, 한 번쯤 보셨으리라 생각됩니다. 크로마키처럼 초록 배경 없이도 사람의 머리카락 한 올 한 올까지 자연스럽게 추출하는 것, 마치 사진에서 불필요한 배경제거를 하거나 최근 스마트폰 갤러리 기능에 추가된 이미지 추출하기 기능과 같은 것이지만, 이는 실제로는 생각보다 어려운 문제입니다. 이 기술을 비디오 매팅(Video Matting)이라고 하죠.

이전 버전인 MatAnyone(2025년 CVPR에서 발표)이 이 분야에서 좋은 성과를 거뒀지만, 여전히 경계선이 뭉툭하거나 머리카락 표현이 부정확한 문제가 남아 있었습니다. 최근엔 후속 연구로 MatAnyone 2가 공개되었는데, '학습된 품질 평가기(MQE)'라는 핵심 아이디어를 도입한 기술이 소개되었습니다.

그림 : MatAnyone vs MatAnyone 2 vs GVM 비교

1. 기존 방식의 문제점

비디오 매팅 모델을 잘 훈련시키려면 고품질의 학습 데이터가 필요합니다. 문제는 실제 영상에서 사람의 알파 매트(alpha matte, 전경과 배경을 구분하는 투명도 맵)를 손으로 직접 주석 달기가 극도로 어렵다는 점입니다. 그래서 기존 연구들은 두 가지 방향으로 이 문제를 우회해왔습니다.

합성 데이터(synthetic data) 활용
배경을 따로 촬영한 전경 영상을 임의의 배경에 합성(RGBA 블렌딩)하는 방식인데, 조명이 불일치하거나 경계가 부자연스러운 영상이 많아서 실제 영상과 큰 차이(도메인 갭)가 생깁니다. 기존 최대 규모 데이터셋인 VM800도 826개 시퀀스에 불과해, SAM 2에 쓰인 영상 분할 데이터셋보다 약 60배나 작습니다.
세그멘테이션 데이터 활용
분할(segmentation) 데이터는 매팅 데이터보다 훨씬 풍부하기 때문에, 최근 많은 모델들이 분할 지식을 함께 학습시켰습니다. 그런데 여기에도 함정이 있었죠. 세그멘테이션은 '이 픽셀은 사람이다, 또는 아니다'처럼 0 또는 1로 딱 떨어지는 경계를 학습하기 때문에, 머리카락처럼 반투명하고 섬세한 경계 영역에는 제대로 된 지도를 제공하지 못했습니다. 결과적으로 출력 결과가 분할 마스크처럼 뭉툭해지는 이른바 '세그멘테이션 같은 매트(segmentation-like mattes)' 문제가 발생했습니다.

2. 접근 방식

MatAnyone 2의 핵심 아이디어는 하나의 질문에서 시작합니다.

정답(ground truth) 알파 매트 없이도, 예측된 매트의 품질을 픽셀 단위로 평가할 수 있을까?

이 질문에 답하기 위해 연구팀은 Matting Quality Evaluator(MQE)라는 학습 기반 품질 평가 모듈을 만들었습니다. MQE는 두 가지 역할을 수행합니다.

온라인 가이던스(Online Guidance) : 모델 훈련 중에 실시간으로 각 픽셀의 오류 여부를 평가해서 잘못된 영역을 억제하는 손실 함수로 활용합니다.
오프라인 선택(Offline Selection) : 대규모 실제 영상에 자동으로 알파 매트 주석을 달아 새로운 데이터셋 VMReal을 구축하는 데 활용합니다.

이 두 가지 역할을 통해, 기존에 불가능하다고 여겨졌던 대규모 실사 비디오 매팅 데이터셋 구축을 현실화했습니다.

3. 모델/기술 아키텍처

전체 시스템은 크게 세 가지 구성요소로 이루어져 있습니다.

MQE 네트워크
영상 프레임(Irgb), 예측된 알파 매트(α̂), 세그멘테이션 마스크(Mseg)를 입력으로 받아, 각 픽셀을 '신뢰 가능(1)' 또는 '오류(0)'로 분류한 이진 평가 맵(Meval)을 출력합니다. 인코더로는 DINOv3의 사전학습 가중치를 활용하고, 디코더로는 DPT 구조를 사용합니다. 이는 Depth Anything 모델의 설계 철학을 참고한 것이라고 합니다.

그림 : MQE 네트워크 입출력 구조

이중 분기 주석 파이프라인(Dual-branch Annotation Pipeline)
VMReal 데이터셋을 만들기 위한 자동화 시스템입니다. 비디오 매팅 모델(BV 브랜치)과 이미지 매팅 모델(BI 브랜치)을 병렬로 돌린 후, MQE가 둘의 결과를 픽셀 단위로 심사해서 각 영역에서 더 신뢰할 수 있는 쪽을 선택·융합합니다.
레퍼런스 프레임 전략(Reference-frame Strategy)
긴 영상에서 등장 인물의 외형이 크게 변할 때(예: 팔이 새로 등장하거나 옷이 바뀔 때) 이를 잘 처리하기 위해, 현재 로컬 윈도우 밖의 먼 과거 프레임을 메모리에 추가 제공하는 훈련 전략입니다.

그림 : MatAnyone과 MatAnyone 2의 훈련 파이프라인 비교

4. 세부 적용 기술

1️⃣ MQE 학습 방법

MQE 자체를 훈련시키기 위해서는 '이 예측이 얼마나 잘못됐는지'를 나타내는 정답 이진 맵이 필요합니다. 연구팀은 P3M-10k라는 이미지 매팅 데이터셋의 인간 주석 알파 맵을 활용해서, 임의의 예측값과 정답 사이의 불일치 정도를 MAD와 Grad 지표의 가중 합산으로 계산하고, 이를 임계값 기준으로 이진화해서 의사(pseudo) 정답 맵을 생성했습니다. 신뢰 픽셀이 오류 픽셀보다 훨씬 많아 클래스 불균형 문제가 심각하므로, 어려운 오류 픽셀에 더 집중하도록 Focal Loss를 사용했습니다.

그림 : MQE가 잡아내는 두 가지 오류 유형 (a:경계 영역의 세밀도 오류, b:중심 영역의 의미론적 오류)

2️⃣ 온라인 품질 가이던스 손실(Leval)

MQE가 출력한 오류 확률 맵의 L1 노름을 손실 함수로 사용합니다. 모델이 오류 확률을 낮추는 방향으로 학습되므로, 정답 알파 맵 없이도 경계 영역을 개선하는 효과적인 지도 신호가 됩니다.

3️⃣ 이중 분기 융합

BV(비디오 매팅 브랜치, 예: MatAnyone)는 시간적 일관성이 뛰어나지만 경계가 뭉툭하고, BI(이미지 매팅 브랜치, 예: MattePro + SAM 2)는 경계가 날카롭지만 시간적 일관성이 부족합니다. MQE는 BV가 실패한 곳(Meval_V=0)이면서 BI가 성공한 곳(Meval_I=1)을 가우시안 블러로 부드럽게 마스킹해서 두 결과를 자연스럽게 병합합니다.

그림 : 이중 분기 자동 주석 파이프라인

4️⃣ 레퍼런스 프레임 드롭아웃 증강

레퍼런스 프레임의 RGB와 알파 맵에서 경계 영역 중 0~3개, 비경계 영역 중 0~1개의 패치(크기 50~100픽셀)를 무작위로 마스킹합니다. 이렇게 하면 모델이 이전에 보지 못한 영역이 새로 등장하는 상황을 더 잘 학습할 수 있게 됩니다.

5. 제약사항

현재 VMReal 구축 파이프라인은 현존하는 최고 성능의 이미지·비디오 매팅 모델의 성능에 의존합니다. 즉, 베이스 모델들이 실패하는 경우(예: 매우 복잡한 배경, 극단적인 조명)에는 자동 주석 품질도 한계가 생길 수 있습니다. 연구팀은 향후 개선된 매팅 모델이 더 나은 데이터를 만들고, 그 데이터로 더 나은 모델을 훈련하는 '데이터-모델 선순환 플라이휠' 구조를 미래 연구 방향으로 제시했습니다.
SA-V 데이터셋의 영상들은 경계 세부 정보가 제한적이어서 이미지 매팅 분기의 이점을 충분히 활용하기 어렵고, MQE가 이미지 매팅 데이터(P3M-10k)만으로 학습되기 때문에 비디오 특유의 시간적 오류를 평가하는 데는 아직 한계가 있습니다.
8개 A800 GPU로 훈련되는 만큼 실험 재현에 상당한 연산 자원이 필요하다는 점도 현실적인 제약입니다.

MatAnyone 2는 '좋은 데이터가 없으면 만들면 된다'는 발상을 학습된 품질 평가기(MQE)로 실현한 연구입니다. 정답 알파 맵 없이도 픽셀 단위 품질을 평가하는 MQE 덕분에, 기존보다 35배 큰 실사 비디오 매팅 데이터셋 VMReal(2만 8천 클립, 240만 프레임)을 자동으로 구축할 수 있었습니다. 그리고 이 데이터로 훈련된 MatAnyone 2는 합성·실사 벤치마크 모두에서 모든 지표 1위를 달성했습니다.

특히 인상적인 점은 확산 모델(GVM)이나 프레임별 마스크를 요구하는 모델(MaGGIe)보다 훨씬 단순한 CNN 기반 구조로도 더 나은 결과를 낸다는 것입니다. 데이터의 질과 양이 모델 구조 복잡도를 뛰어넘을 수 있다는 것을 잘 보여주는 사례라고 할 수 있죠. 비디오 편집, 가상 배경, 시각 효과 분야에 실질적으로 기여할 수 있는 연구입니다.

참고자료

사이트) MatAnyone 2 프로젝트 페이지 (링크)
논문) MatAnyone 2: Scaling Video Matting via a Learned Quality Evaluator (링크)

용어 해설

알파 매트(Alpha Matte) : 각 픽셀이 전경(사람)에 속하는 정도를 0~1 사이 값으로 표현한 투명도 맵입니다. 0이면 완전 배경, 1이면 완전 전경, 중간값은 머리카락처럼 반투명한 영역입니다.
세그멘테이션(Segmentation) : 이미지를 의미 단위로 구분하는 기술로, 각 픽셀을 특정 클래스(사람, 배경 등)에 딱 떨어지게 분류합니다. 매팅과 달리 중간값(반투명)을 표현하지 못합니다.
DINOv3 : Meta와 Inria가 개발한 자기지도 학습 기반 비전 인코더로, 정답 레이블 없이 이미지의 풍부한 특징을 추출합니다. 여기서는 MQE의 고품질 특징 추출기로 활용됩니다.
DPT(Dense Prediction Transformer) : 비전 트랜스포머를 밀집 예측(픽셀 단위 출력)에 활용하기 위한 디코더 구조입니다.
Focal Loss : 클래스 불균형 상황에서 쉬운 샘플보다 어려운 샘플에 더 높은 가중치를 부여하는 손실 함수입니다.
dtSSD : 연속 프레임 간 알파 맵의 변화량 차이를 측정하는 시간적 일관성 지표입니다. 값이 낮을수록 깜빡임이 적습니다.

Q&A

Q. MQE가 정답 알파 맵 없이도 경계를 잘 평가할 수 있는 이유는 무엇인가요?

MQE는 세그멘테이션 마스크를 보조 입력으로 함께 받습니다. 덕분에 중심 영역(코어 영역)에서는 세그멘테이션 마스크의 전경/배경 정보를 그대로 참고하고, 경계 영역에서는 DINOv3의 풍부한 특징을 활용해 머리카락 같은 세밀한 디테일의 품질을 판단합니다. 또한 P3M-10k 데이터셋의 실제 정답 알파 맵으로 사전 훈련됐기 때문에, 실제로 어떤 예측이 잘못됐는지를 구분하는 능력을 체계적으로 습득했습니다.

Q. VMReal 데이터셋은 기존 합성 데이터셋과 어떻게 다른가요?

기존 VM800, VideoMatte240K 등은 전경 영상을 별도로 촬영한 후 임의의 배경에 합성한 것입니다. 이 경우 조명과 그림자가 맞지 않아 실제 영상과의 도메인 차이(gap)가 큽니다. VMReal은 유튜브, 영상 플랫폼, SA-V 데이터셋 등에서 수집한 실제 영상에 MQE 기반 자동 주석 파이프라인으로 알파 맵을 달았습니다. 다양한 조명(역광 포함), 움직임, 다인원 장면을 포함한 실사 데이터이기 때문에 모델 일반화 능력을 크게 향상시킵니다.

Q. 레퍼런스 프레임 전략을 쓰면 메모리가 더 필요하지 않나요?

좋은 질문입니다. 일반적으로 긴 시퀀스를 한 번에 학습하면 메모리 사용량이 급증하는 문제가 있습니다. MatAnyone 2는 훈련 시퀀스 길이를 그대로 8프레임으로 유지하되, 그 로컬 윈도우 외부에서 별도의 레퍼런스 프레임 1~2개를 메모리 뱅크에 추가하는 방식을 씁니다. 레퍼런스 프레임은 순전파(forward pass)에만 사용되고 그래디언트 계산 범위에 포함되지 않으므로, 실질적인 추가 메모리 비용 없이 장거리 시간적 맥락을 모델에 제공할 수 있습니다.

Figure 1 — MatAnyone vs MatAnyone 2 vs GVM 비교: 같은 입력 영상에 대한 세 모델의 결과를 나란히 보여줍니다. MatAnyone은 경계가 딱딱하고 역광 장면에 약한 반면, GVM(확산 모델 기반)은 머리카락 경계가 흐릿합니다. MatAnyone 2는 두 약점을 동시에 극복해 세밀하고 자연스러운 경계를 만들어냅니다.

Figure 2 — MatAnyone과 MatAnyone 2의 훈련 파이프라인 비교: 왼쪽(a)은 합성 매팅 데이터와 세그멘테이션 데이터를 혼합 훈련하며 약한 경계 손실을 쓰는 기존 방식, 오른쪽(b)은 VMReal 실사 데이터와 MQE 기반 평가 맵, 레퍼런스 프레임 전략을 함께 사용하는 새 방식을 보여줍니다.

Figure 3 — MQE 네트워크 입출력 구조: 영상 프레임, 예측 알파, 세그멘테이션 마스크를 입력으로 받아 DINOv3 인코더와 DPT 디코더를 거쳐 픽셀 단위 이진 평가 맵(신뢰/오류)을 출력하는 MQE의 구조도입니다.

Figure 4 — MQE가 잡아내는 두 가지 오류 유형: (a) 경계 영역의 세밀도 오류(머리카락이 세그멘테이션처럼 뭉툭하게 표현된 경우)와 (b) 중심 영역의 의미론적 오류(전경/배경이 잘못 분류된 경우)를 정답 없이도 정확히 식별하는 MQE의 성능을 보여줍니다.

Figure 5 — 이중 분기 자동 주석 파이프라인: 비디오 매팅 분기(BV)와 이미지 매팅 분기(BI)가 각각 알파 맵을 생성하고, MQE가 각각의 신뢰 영역을 평가해서 두 결과를 가우시안 블렌딩으로 융합하는 VMReal 구축 파이프라인 전체 흐름도입니다.

Figure 6 — 실사 영상 정성 비교: 바람에 날리는 머리카락(1행), 어두운 조명(2~3행) 등 어려운 실사 조건에서 RVM, GVM, MatAnyone, MatAnyone 2의 결과를 비교합니다. MatAnyone 2가 세부 묘사와 의미론적 정확성 모두에서 우수합니다.

Figure 7 — 레퍼런스 프레임 전략의 효과: 긴 영상에서 팔이 새로 등장하는 장면에서 MatAnyone은 해당 부분을 인식하지 못하는 반면, 레퍼런스 프레임 전략으로 훈련된 MatAnyone 2는 정확히 잡아내는 것을 보여줍니다.

Figure 8 — VMReal 데이터셋 샘플: 클로즈업 인물, 동적인 머리카락, 저조도 환경 등 다양하고 어려운 실사 영상과 그에 대응하는 고품질 알파 맵 및 평가 맵 예시를 보여줍니다.

Figure 9 — 이중 분기 주석 파이프라인의 프레임별 동작: 비디오 분기(BV)는 머리카락 경계가 약하지만 시간적으로 안정적이고, 이미지 분기(BI)는 경계가 날카롭지만 프레임 간 의미가 불안정한 상호 보완적 특성을 시각적으로 보여주며, 두 결과를 융합한 최종 매트의 우수성을 설명합니다.

Figure 10 — MQE 예측값과 정답 불일치 점수의 상관관계: 패치 단위로 집계한 MQE 예측값과 실제 오류 정도 간의 피어슨 상관계수가 0.87로 매우 높음을 산점도로 보여주며, 낮은 불일치 구간에서는 선형에 가깝고 높은 불일치 구간에서는 포화(saturation)되는 경향을 확인할 수 있습니다.

Figure 11, 12 — 추가 정성 비교 및 장편 영상 강인성: 다양한 실사 어려운 장면에서의 추가 비교와, 긴 영상에서 새로운 신체 부위나 손에 든 물체가 등장할 때 MatAnyone 2가 이를 성공적으로 처리하는 모습을 보여줍니다.

Google의 Gemma4 출시

42morrow — Sat, 11 Apr 2026 11:48:32 +0900

구글에서 Gemma4를 공개한 지 제법 시간이 지났습니다. 이미 다른 곳에서 소개를 많이 했기에 이글에서는 요약만 하고 넘어가겠습니다. 제 경우, 로컬에서는 모자라는 GPU 메모리 때문에 Gemma3를 주로 활용해 왔었기에 Gemma4는 앞으로도 쭉 쓰게 될 모델일 것 같습니다. 향후에 좋거나 나쁜 것이 두드러지면 그 내용도 이 글 끝머리에 업데이트하겠습니다.

1.Gemma4 모델 개요

Gemma 4는 Google DeepMind가 공개한 오픈 웨이트(open-weight) 모델 패밀리입니다. 하나가 아니라는 소리죠. 공식 문서 기준으로 Apache 2.0 라이선스를 사용하며, 상업적 활용도 허용됩니다. 또한 텍스트뿐 아니라 이미지 입력을 전 모델이 지원하고, 소형 모델(E2B, E4B)은 오디오 입력도 지원합니다. 긴 문맥 처리도 강화되어 소형 모델은 128K, 중대형 모델은 256K 컨텍스트 윈도우를 제공합니다.

공식 설명에서 Gemma 4는 단순 챗봇용이 아니라, 추론(reasoning), 코드 생성, 함수 호출(function calling), 에이전트형 워크플로우, 멀티모달 이해를 염두에 두고 설계된 모델군으로 소개됩니다. 구글은 이를 '가장 지능적인 오픈 모델'이라고 표현하고 있습니다.

2.모델 별 특징

Gemma 4는 크게 4개 크기로 나뉩니다: E2B, E4B, 26B A4B, 31B입니다. 공식 릴리스 페이지에도 이 4종이 함께 공개된 것으로 기록돼 있습니다.

종류	설명
E2B	- 실효 파라미터 기준 2.3B, 임베딩 포함 시 약 5.1B - 128K 컨텍스트 - 텍스트·이미지·오디오 지원 - 모바일·엣지 기기 지향 모델로, 온디바이스 실행에 초점을 둔 경량형임
E4B	- 실효 파라미터 기준 4.5B, 임베딩 포함 시 약 8B - 128K 컨텍스트 - 텍스트·이미지·오디오 지원 - E2B보다 더 높은 성능을 주면서도 여전히 엣지/로컬 실행 용으로 적합 스마트폰, Raspberry Pi, Jetson Nano 같은 환경에서의 사용 목적으로 고려.
26B A4B	- 총 25.2B 파라미터의 MoE(Mixture-of-Experts) 구조 - 추론 시 활성화되는 파라미터는 약 3.8B - 256K 컨텍스트 - 텍스트·이미지 지원 - 총 규모는 크지만, 실제 추론 비용은 더 작게 가져가려는 설계를 따릅니다.
31B Dense	- 30.7B Dense 모델 - 256K 컨텍스트 - 텍스트·이미지 지원 - Gemma 4 계열 중 최고급 성능 포지션이며, 추론·코딩·멀티모달 작업 전반에서 가장 강한 축으로 소개됨.

추가로, E2B/E4B의 E는 effective parameters, 26B A4B의 A는 active parameters를 뜻합니다. 즉, Gemma 4는 단순히 큰 모델 하나가 아니라, 모바일용 경량 모델부터 워크스테이션용 고성능 모델까지 한 패밀리로 구성된 점이 특징입니다.

3.대략적인 평가는 어떤가?

전체적으로는 성능 대비 크기와 라이선스가 인상적이라는 평가가 우세합니다. 공식 모델 카드 기준으로 31B 모델은 AIME 2026 89.2%, LiveCodeBench v6 80.0%, GPQA Diamond 84.3%를 기록했고, 26B A4B도 이에 근접한 수치를 보입니다. 소형 모델인 E4B와 E2B도 크기에 비해 꽤 강한 편으로 제시됩니다.

구글 공식 블로그는 공개 당시 31B가 오픈 모델 중 3위, 26B A4B가 6위라고 소개했고, '자기보다 훨씬 큰 모델과 경쟁한다'는 메시지를 내세웠습니다. Hugging Face 측도 사전 테스트에서 기본 성능이 매우 좋아 파인튜닝 예시를 찾기 어려울 정도였다고 평가했습니다.

다만 외부 해석을 보면, 평가는 대체로 좋지만 경쟁도 매우 치열하다는 점도 함께 언급됩니다. VentureBeat는 Gemma 4의 강점을 단순 벤치마크 1개가 아니라 추론 + 멀티모달 + 함수 호출 + 긴 컨텍스트 + Apache 2.0 라이선스의 조합이라고 봤고, 동시에 Qwen, GLM, Kimi 계열과의 경쟁이 빠르게 진행 중이라고 짚었습니다. 즉, 지금 분위기는 상당히 강한 공개 모델이 나왔다에 가깝지만, 절대 독주라는 느낌보다는 상위권 경쟁자 등장에 더 가깝습니다.

정리하면 대략 이런 톤 정도랄까요?

장점 : 성능 대비 크기 효율이 좋고, 멀티모달·에이전트 활용성이 높으며, Apache 2.0이라 활용 장벽이 낮음.
관전 포인트 : 실제 현업 체감 성능, 추론 속도, 툴체인 최적화는 앞으로 더 검증될 부분임.

4.어디서 구할 수 있는가?

현재 Gemma4는 Hugging Face나 Ollama 모델 허브 등에서 접할 수 있습니다.

Hugging Face 컬렉션 : base/instruction-tuned 모델들을 한 번에 확인 가능 (링크)
Ollama Model Hub (링크)
GitHub / Gemma Cookbook : 예제와 활용 가이드 확인 가능. 모델 카드에서 GitHub 링크를 직접 연결하고 있음 (링크)

5.참고사항

vLLM도 지원한다고 되어 있지만 현재시점(2026.4.10)에 공개된 vLLM 0.19 버전과는 약간 궁합이 맞지 않나 봅니다. github release 상에는 지원하는 것으로 되어 있지만 Pypi에 올라온 패키지를 바로 사용할 경우, 오류가 발생합니다. 그래서, 이를 지원하는 전용 Docker 컨테이너가 공개되어 있으니 이를 사용하라고 가이드하고 있습니다.

Demystifying Video Reasoning : 비디오 생성 모델 생각을 한다?

42morrow — Fri, 10 Apr 2026 14:00:06 +0900

AI가 그림을 그리고 영상을 만드는 시대가 됐죠. Sora, Kling, Veo 같은 영상 생성 모델들이 불과 몇 년 사이에 놀라운 수준의 영상을 뚝딱 만들어냅니다. (최근엔 카카오톡 카카나에도 이미지로 영상을 생성하는 기능이 추가됐길래 고양이 사진으로 영상을 만들어 스마트폰 배경 영상으로 설정해 두고 매일 들여다보고 있습니다. ^^;)

그런데 최근 연구자들이 이 모델들을 들여다보다가 예상치 못한 발견을 했습니다. 영상 생성 모델이 단순히 멋진 영상을 만드는 것을 넘어서, 논리적인 추론(Reasoning)을 하고 있다는 것이었죠.

그렇다면 그 추론이 모델 내부에서 어떻게 일어나는 걸까요? 2026년 3월 SenseTime, 난양공대, UC버클리, UC샌디에이고, 카네기멜론 대학의 공동 연구팀이 기존의 통념을 뒤집는 새로운 메커니즘을 발견하고 공개한 논문, 'Demystifying Video Reasoning' 은 바로 그것에 대한 해답을 제시합니다.

1. 기존 방식의 문제점

이전 연구들은 비디오 모델의 추론이 Chain-of-Frames(CoF), 즉 '프레임의 연쇄' 방식으로 일어난다고 설명했습니다. 쉽게 말하면, '첫 번째 프레임에서 뭔가 판단하고 → 두 번째 프레임에서 그걸 이어받아 → 세 번째 프레임에서 결론을 낸다'는 식의 순차적이고 시간적인 추론이라는 거죠. 즉, 마치 만화책처럼, 칸(프레임)을 하나씩 넘기면서 이야기가 전개된다고 본 것입니다.

그런데 이런 설명에 대해 연구팀은 과연? 이라며 의문을 품었고, 실험을 통해 이 가설이 전체적인 그림을 설명하지 못한다는 것을 보여줬습니다.

2. 접근 방식

연구팀은 VBVR-Wan2.2라는 최신 비디오 추론 모델을 주요 분석 대상으로 삼아 두 가지 핵심 실험을 수행했습니다.

중간 잠재 상태 시각화 : 영상 생성 과정의 각 디노이징 스텝(denoising step)에서 모델이 '지금 무엇을 생각하고 있는지'를 이미지로 뽑아 확인했습니다.
노이즈 교란 실험 : 특정 프레임에 노이즈를 주입했을 때와, 특정 디노이징 스텝 전체에 노이즈를 주입했을 때 성능이 얼마나 떨어지는지 비교했습니다.

3. 모델/기술 아키텍처

논문에서 분석한 모델은 Diffusion Transformer(DiT) 기반의 비디오 생성 모델입니다.

비디오 생성 모델은 작동 원리상, 순수한 노이즈(잡음)에서 출발하여 단계적으로 잡음을 제거(denoising)해가면서 최종 영상을 완성합니다. 각 단계에서 모델은 '지금 이 노이즈에서 깨끗한 영상이 어떤 모습일지'를 예측하는 것이죠. 이 과정에서 Transformer 구조가 사용되는데, 특이한 점은 양방향 어텐션(bidirectional attention) 을 통해 매 스텝마다 모든 프레임을 동시에 처리한다는 겁니다. 시간 순서대로 한 프레임씩 처리하는 게 아니라, 전체 영상을 한꺼번에 보면서 추론한다는 것이죠. 이것이 CoF 가설을 반박하는 구조적 근거가 됩니다.

그림 : Chain-of-Steps: 미로 탈출 예시

4. 세부 적용 기술

1️⃣ Chain-of-Steps(CoS): 핵심 발견

논문의 가장 중요한 발견입니다. 연구팀은 추론이 프레임 축이 아닌 디노이징 스텝 축을 따라 일어난다는 것을 발견하고 이를 Chain-of-Steps(CoS) 라고 명명했습니다. 미로 찾기 문제를 예로 들면, 초기 디노이징 스텝에서는 여러 가능한 경로가 동시에 그려지고(탐색), 중간 스텝에서 잘못된 경로들이 지워지며(가지치기), 최종 스텝에서 올바른 경로 하나가 남는(수렴) 방식입니다.

CoS는 두 가지 탐색 방식으로 나타납니다.

다중 경로 탐색(Multi-Path Exploration) : 복잡한 논리 과제에서 여러 가능성을 동시에 시각적으로 그려놓고 점차 하나로 좁혀가는 방식
중첩 기반 탐색(Superposition-based Exploration) : 여러 상태를 동시에 겹쳐서 표현하다가 점차 하나의 명확한 상태로 확정하는 방식

그림 : 디노이징 과정에서 나타나는 두 가지 탐색 패턴 (다중 경로 탐색(상단)과 중첩 기반 탐색(하단))

2️⃣ 세 가지 창발적 추론 행동

LLM(대형 언어 모델)에서 관찰된 것과 놀랍도록 유사한 행동이 비디오 모델에서도 발견됐습니다.

작업 기억(Working Memory) : 중요한 정보를 생성 과정 전체에 걸쳐 유지하는 능력입니다. 예를 들어, 물체가 화면 밖으로 나갔다가 다시 돌아올 때 원래 위치를 기억하거나, 다른 물체에 가려진 물체의 상태를 계속 추적하는 것이죠.
자기 수정 및 향상(Self-Correction and Enhancement) : 초기 스텝에서 잘못된 답을 생성했다가 이후 스텝에서 스스로 고치는 능력입니다. LLM의 'slow thinking'이나 내부 역추적과 기능적으로 동일합니다.
행동 전 인식(Perception before Action) : 초기 스텝에서 먼저 '무엇이, 어디에 있는지'를 파악한 뒤, 이후 스텝에서 비로소 '어떻게 조작할지'를 결정하는 두 단계 패턴입니다.

그림 : 창발적 추론 행동 - 기억과 자기 수정 행동 예시

3️⃣ DiT 내부의 레이어별 기능 분화

단일 디노이징 스텝 안에서도 레이어에 따라 역할이 나뉜다는 것이 밝혀졌습니다.

초기 레이어(0~9) : 배경과 전경을 구분하는 등 전반적인 시각 구조를 파악하고,
중간 레이어(10~29 특히 20~29) : 실제 추론과 의미적 판단을 수행하며,
후기 레이어 : 다음 스텝을 위한 잠재 표현을 최종 정리합니다.

레이어 스와핑 실험을 통해 21번 레이어의 표현만 바꿔도 모델의 최종 판단이 완전히 뒤집힌다는 인과적 증거도 제시됐죠.

그림 : 레이어 전문화 - (상) 토큰 활성화 히트맵 (하) 레이어 스와핑 실험

4️⃣ 학습이 필요없는 앙상블(Training-Free Ensemble)

이론적 발견을 실용적으로 활용한 방법론입니다. 동일한 모델을 서로 다른 랜덤 시드로 세 번 실행하여, 첫 번째 디노이징 스텝에서 중간 레이어(20~29)의 잠재 표현을 평균 냅니다. 이렇게 하면 각 실행에서의 편향이 상쇄되고 더 안정적인 추론 출발점이 만들어집니다. 추가 학습 없이도 VBVR-Bench에서 성능이 0.685에서 0.716으로 약 2% 절대적 향상을 달성했습니다.

5. 제약사항

프레임 수가 17개 이하로 줄어들면 성능이 눈에 띄게 하락합니다. 추론이 스텝 축에서 일어나더라도 프레임이 '작업 공간' 역할을 하기 때문입니다.
4-step 증류 모델에서는 노이즈 스케줄러가 초기 스텝의 잠재 탐색 단계를 너무 빠르게 압축해버려 추론 신호가 관찰하기 어려워지고 VBVR-Bench 성능이 0.685에서 0.605로 크게 하락했습니다.
앙상블 방법의 2% 향상은 유의미하지만, 인간 수준(0.974)과는 아직 큰 격차가 있습니다.
분석 대상이 VBVR-Wan2.2 중심이어서 다른 아키텍처로의 일반화 여부는 추가 검증이 필요합니다.
앙상블을 위해 동일 모델을 세 번 실행해야 하므로 추론 비용이 3배 증가한다는 실용적 제약도 있습니다.

이 논문은 비디오 생성 모델의 추론 메커니즘에 대한 우리의 이해를 근본적으로 바꿔놓습니다. 추론이 시간의 흐름(프레임) 위에서 펼쳐지는 게 아니라, 생성 과정(디노이징 스텝) 위에서 펼쳐진다는 Chain-of-Steps 발견은 상당히 놀랍습니다.

특히 작업 기억, 자기 수정, 행동 전 인식이라는 세 가지 행동이 언어 모델에서 관찰된 것과 유사하게 나타난다는 점은, 비디오 모델이 단순한 영상 생성기가 아니라 일종의 '공간-시간적 사고 기계'로서의 가능성을 보여줍니다.

생물학적 뇌와의 유사성도 흥미롭습니다. 쥐가 먹이를 찾기 전 해마에서 여러 경로를 미리 시뮬레이션하는 것처럼, 비디오 모델도 초기 스텝에서 여러 해답을 동시에 탐색한 뒤 점차 수렴하는 방식으로 추론한다는 것은 지능의 보편적인 패턴일 수 있습니다. 비디오 생성 모델이 차세대 AI 추론의 새로운 기반이 될 수 있다는 가능성을 연 연구라 할 수 있겠습니다.

참고자료

사이트) Demystifying Video Reasoning 프로젝트 (링크)
논문) Demystifying Video Reasoning (링크)

용어 정리

디노이징 스텝(Denoising Step) : 순수 노이즈에서 깨끗한 이미지/영상으로 변환하는 반복 과정의 각 단계. 보통 수십~수백 번 반복됩니다.
잠재 공간(Latent Space) : 모델이 내부적으로 데이터를 표현하는 압축된 고차원 공간. 실제 픽셀이 아닌 추상적인 특징 벡터들의 공간입니다.
Flow Matching : 노이즈에서 데이터로 이어지는 연속적인 경로(흐름)를 학습하는 확산 모델 학습 방식.
행동 전 인식(Perception before Action) : 초기 스텝에서 먼저 '무엇이, 어디에 있는지'를 파악한 뒤, 이후 스텝에서 비로소 '어떻게 조작할지'를 결정하는 두 단계 패턴입니다.CKA(Centered Kernel Alignment) : 두 신경망 표현이 얼마나 유사한지 측정하는 지표. 값이 1에 가까울수록 표현이 완전히 달라졌음을 의미합니다.
LoRA(Low-Rank Adaptation) : 대형 모델을 효율적으로 파인튜닝하기 위한 경량 어댑터 기법.

Q&A

Q. CoS(Chain-of-Steps)와 기존 CoF(Chain-of-Frames)의 차이가 실제로 그렇게 중요한가요?

매우 중요합니다. 만약 추론이 CoF 방식으로 일어난다면, 추론 성능을 높이려면 더 많은 프레임을 만들거나 프레임 간 인과 관계를 더 정교하게 설계해야 합니다. 반면 CoS가 맞다면, 디노이징 스텝 수와 각 스텝의 품질을 최적화하는 방향이 훨씬 효과적입니다. 실제로 이 논문에서 제안한 학습이 필요치 않은 앙상블이 '중간 레이어의 첫 번째 스텝'을 타겟으로 삼아 성능을 올린 것이 바로 이러한 이해에서 나온 것입니다.

Q. 비디오 모델이 이런 추론 능력을 갖추게 된 이유는 무엇인가요?

논문은 이를 명시적으로 학습시킨 것이 아니라 창발(emergent) 현상으로 봅니다. 대규모 데이터로 학습하는 과정에서 자연스럽게 발생한 능력이라는 것이죠.

특히 양방향 어텐션으로 전체 프레임을 동시에 처리하는 구조가 이런 추론에 유리한 것으로 보이며, 이는 LLM에서 체인-오브-소트(CoT)가 창발한 것과 유사한 맥락입니다. 게다가 테슬라의 자율주행이 대규모 데이터를 이용한 End-to-End 방식으로 변경된 것도 이와 관련될 수 있지 않을까 싶습니다.

Q. 학습 불필요 앙상블(Training-Free Ensemble)의 2% 향상이 실용적으로 의미 있는 수치인가요?

절대적 수치로 2%는 작아 보일 수 있지만, 이미 강력한 베이스라인(0.685) 위에서 추가 학습 없이 달성한 것이라 충분히 의미 있습니다. 특히 이 방법은 어떤 학습 데이터도, 파라미터 수정도 필요 없이 추론 시점에서만 적용 가능하기 때문에 실용적입니다. 다만 모델을 3번 실행해야 하는 비용은 실제 배포 환경에서 고려해야 할 트레이드오프라고 할 수 있습니다.

크롬 원격 디버깅 - 스마트폰 크롬을 위한 개발자 도구 사용하기

42morrow — Wed, 8 Apr 2026 15:45:49 +0900

바이브코딩으로 만든 코드 대부분은 PC에서 테스트를 할 수 있습니다. 크롬 개발자 도구에서 디바이스 설정을 이용하면 비슷하게 레이아웃이 맞는지, 기능은 동작하는지를 대략 확인할 수 있기 때문이죠.

그런데, 마이크, 스피커, 카메라 등을 테스트하려면 결국은 스마트폰에서 해당 페이지를 열어서 테스트 하는 수 밖에 없습니다. 그런데, 이때 문제는 모바일에서 사용하는 크롬은 개발자도구 화면을 제공하지 않는다는 것이죠. 현재 모바일 크롬에서 어떤 코드가 실행되고 있는지, 네트워크로 오가는 데이터는 어떤 것인지 확인할 수 없다는 것은 Javascript나 HTML 기반 앱의 테스트에 많은 제약이 생긴다는 얘기가 됩니다.

다행히 이럴 때 사용할 수 있는 방법이 있는데, 그것이 크롬 브라우저 원격 디버깅입니다.

이번 글에서는 원격 디버깅을 사용하는 방식만 간단히 정리해두고 가겠습니다.

1.크롬 원격 디버깅

크롬 원격 디버깅이란, 안드로이드 기기에서 실행 중인 웹페이지나 웹뷰를 데스크톱 크롬 개발자 도구로 디버깅하는 기능을 의미합니다.

2.설정 절차

1) 스마트폰에서

개발자 옵션을 활성화합니다.
- [설정] > [휴대전화 정보] > [소프트웨어 정보]로 이동
- '빌드 번호' 연속 7번 클릭해 '개발자 옵션' 활성화
- [설정] > [개발자 옵션] 메뉴가 보임
USB 디버깅 옵션을 활성화합니다.
- [설정] > [개발자 옵션] > [빠른 설정 개발자 타일] 이동
- 'USB 디버깅' 활성화

2) PC와 스마트폰을 USB로 연결

스마트폰 쪽에서, 연결된 PC와의 USB 디버깅 허용 여부 승인
주의) USB 데이터 전송 가능 케이블이어야 함. 전원 전용 케이블이 아닌지 반드시 확인할 것!

3.디버깅 진행

1) PC 브라우저에서 inspect 실행

PC 크롬 브라우저에서 chrome://inspect 열기
연결된 안드로이드 기기 목록 확인 (아래는 갤럭시폰이라 SM-로 시작)
모바일 폰 크롬 브라우저에 열려 있는 페이지 목록 표시됨
디버깅하고자 하는 페이지에서 'inspect' 클릭

화면의 왼쪽은 스마트폰 화면, 오른쪽은 익숙한 크롬의 개발자 도구 화면이 보입니다. 이제 원격 디버깅을 즐기면 됩니다.

4.유의사항

inspect에서 디바이스에 'Pending authentication' 메시지가 표시되는 경우, 다음을 체크해야 합니다.
- USB 케이블이 데이터 전송이 가능한 것인지 (충전 전용인 경우는 불가!)
- 터미널에서 adb devices 실행해보기 -> 간혹 daemon 안 올라가 있는 경우 때문에 확인 차 진행. 정상이라면 연결된 디바이스(스마트폰) ID가 보여야 함

$ adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
R58------	device

- USB 디버깅 비활성화 후 다시 활성화
- 인증 수락 (디바이스 쪽 화면에서 숨겨져 있을지 모르는 인증 팝업 창 찾아 수락 진행)
- USB 디버깅 권한 취소 후 재연결 (사실 여기까지는 안 갈 듯)