[2026.03.20 주간 개발 트렌드] Next.js 16.2와 Spring Boot M3, 작은 AI 모델

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# 이번주는 빌드와 검색, 생성의 기반이 달라졌다

이번주에는 Vite 8 정식 버전과 Gemini Embedding 2 공개 프리뷰, Sora API의 기능 확장 소식이 나왔다. 프론트엔드의 빌드 도구와 AI 서비스의 검색·생성 계층에서 각각 변화가 생긴 주다.

개발 속도가 빨라지고 처리할 수 있는 입력이 늘어나는것은 반갑다. 다만 지금 프로젝트에 연결하려면 무엇이 달라지는지와 어떤 결과를 비교해야하는지를 따로 알아야한다.

3월 9일부터 13일까지의 내용을 세가지로 나눠보았다.

| 분야 | 소식 | 실제로 살펴볼 부분 |
| --- | --- | --- |
| Frontend | Vite 8 정식 출시 | Rolldown 전환과 플러그인·출력 검증 |
| AI·검색 | Gemini Embedding 2 Preview | 여러 매체의 공통 검색과 인덱스 설계 |
| AI·영상 | Sora API 확장 | 긴 영상과 재사용 참조, 비동기 작업 관리 |

공통점은 기존 도구에 옵션 하나만 추가하는 수준보다 처리 파이프라인을 다시 살펴보게 만든다는것이다. 이번주에는 그 연결을 중심으로 정리해보려고 한다.

# 1. Frontend — Vite 8은 Rolldown을 통합 번들러로 채택했다

3월 12일 [Vite 8](https://vite.dev/blog/announcing-vite8)이 정식 출시됐다. 개발과 빌드에서 esbuild와 Rollup을 함께 사용하던 구조에서 Rust 기반 Rolldown을 통합한 구조로 넘어갔다.

Vite는 최대 10~30배 빠른 빌드 성능을 소개했다. 이 수치를 모든 프로젝트의 전체 CI 시간이 같은 비율로 줄어든다는 의미로 읽으면 안되겠다. 발표된 번들러 성능과 우리의 설치·검사·배포 과정은 비교 범위가 다르다.

## 두 처리 경로를 맞추는 부담이 줄어드는 방향이다

개발 서버에서는 잘 동작하는데 production build에서 문제가 생기는 경험을 생각해보자. 처리 경로가 다르면 모듈 해석과 변환, 플러그인의 동작 차이가 원인이 될 수 있다.

하나의 번들러 기반으로 정리하는 방향은 이런 차이를 줄일 여지를 만든다. 다만 모든 개발·배포 환경의 결과가 자동으로 같아진다는 뜻은 아니다.

환경 변수와 서버 전용 코드, 브라우저 전용 API, 배포 서버의 경로는 여전히 다를 수 있다. 번들러를 통합해도 애플리케이션이 두 환경을 다르게 사용하는 부분은 확인해야한다.

```text
비교할 실행 경로
개발 서버 → 화면과 HMR
production build → 생성 파일 → 실제 배포 환경
```

특히 빌드가 성공했다는 사실과 생성한 파일이 의도대로 실행된다는 사실을 나눠보자. 코드 분할과 동적 import, 정적 자산 경로는 결과물을 실제로 열어봐야 확인하기 쉽다.

## 플러그인은 이름보다 하는 일을 확인하자

기존 플러그인과의 호환성은 이번 전환에서 중요한 부분이다. 그래도 프로젝트에 연결한 모든 플러그인이 똑같은 조건으로 동작한다고 가정하지는 않는게 좋겠다.

플러그인이 소스 변환만 하는지, 모듈 경로를 바꾸는지, 번들 결과를 수정하는지 나눠보면 확인할 범위가 보인다. 플러그인이 직접 만든 가상 모듈도 점검 대상이다.

예를 들어 SVG를 컴포넌트로 바꾸는 도구와 빌드 결과를 업로드하는 도구는 실패할때 나타나는 증상이 다르다. 하나는 화면 렌더링에 영향을 주고 다른 하나는 배포 산출물의 후처리에 영향을 줄 수 있다.

처음부터 설정을 전부 다시 쓰기보다 현재 구성으로 빌드한 결과를 비교하면 좋겠다. 불필요하게 많은 변경을 같이 하면 Rolldown 전환 때문인지 설정 정리 때문인지 구분하기 어렵다.

## 빌드 속도는 단계별로 측정하면 설명하기 쉽다

CI의 전체 시간에는 의존성 설치와 타입 검사, 테스트와 번들링, 업로드가 함께 들어간다. 번들링이 빨라져도 다른 단계가 대부분의 시간을 쓰면 전체 차이는 작게 보일 수 있다.

```text
전체 CI 시간
환경 준비 + 설치 + 타입 검사 + 테스트 + 번들링 + 배포
```

따라서 같은 머신과 캐시 조건에서 단계별 시간을 남기면 좋겠다. 캐시가 없는 첫 빌드와 캐시가 있는 반복 빌드를 섞으면 결과를 잘못 해석할 수 있다.

평균뿐 아니라 실패율과 편차도 함께 보고싶다. 빠른 빌드가 가끔씩 큰 메모리를 사용하거나 특정 환경에서 실패한다면 운영 기준에서는 추가 검토가 필요하기 때문이다.

또한 생성된 청크 크기와 초기 로딩, 실제 사용자 흐름도 비교해야한다. 개발자의 빌드 대기 시간이 줄어든것과 사용자의 다운로드가 줄어든것은 서로 다른 성능 지표다.

# 2. Frontend — 업그레이드의 끝은 생성된 앱의 확인이다

Vite 8의 Node 요구 사항은 20.19 이상 또는 22.12 이상 등으로 안내됐다. 로컬에서만 새 버전을 설치하고 CI는 다른 런타임을 사용한다면 같은 결과를 기대하기 어렵다.

실제 도입에서는 package.json과 잠금 파일 외에도 CI 이미지와 개발 컨테이너의 런타임을 함께 확인해야겠다. 설치되는 버전을 기록해야 나중에 같은 조건을 재현할 수 있다.

## 결과물을 비교할 작은 사례를 정해두자

모든 페이지를 수동으로 확인하기 어렵다면 프로젝트에서 서로 다른 빌드 특성을 사용하는 경로를 골라볼 수 있다. 첫 화면만 열어보고 끝내는것보다 확인 범위를 설명하기 쉽다.

| 경로 | 확인할 내용 |
| --- | --- |
| 초기 진입 화면 | 자산 로딩과 콘솔 오류 |
| 동적 import 화면 | 청크 요청과 이동 후 렌더링 |
| 폰트·이미지·CSS | 경로와 표시 결과 |
| SSR을 쓰는 경로 | 서버 실행과 브라우저 연결 |
| 에러 추적 | 소스맵과 실제 오류 위치 |

소스맵 파일이 생성된것과 오류 수집 서비스에서 원본 위치를 찾을 수 있는것도 다르다. 배포와 업로드 절차가 연결되는지 확인해야한다.

정적 자산의 파일명이 바뀌는 경우에는 이전 배포의 HTML과 새 자산이 섞이는 상황도 고려할 수 있다. 번들러의 결과와 CDN·캐시 정책은 같이 사용하는 구성이다.

업그레이드 결과에는 속도 숫자만 남기기보다 어떤 화면과 배포 경로를 확인했는지 적으면 좋겠다. 그래야 다음 업데이트에서도 같은 기준을 사용할 수 있다.

# 3. AI·검색 — Gemini Embedding 2는 여러 매체를 같은 공간에 표현한다

3월 10일 [Gemini Embedding 2](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-embedding-2/)가 Gemini API와 Vertex AI의 공개 프리뷰로 나왔다. 텍스트와 이미지, 동영상과 오디오, 문서를 하나의 임베딩 공간에 표현하는 모델이다.

텍스트만 검색하던 시스템에서 이미지나 음성을 포함한 자료를 의미로 찾는 구성을 생각해볼 수 있다. 이번주 기준은 Public Preview이므로 정식 제공 상태와 구분해야한다.

## 자료를 모두 텍스트로 바꾸는 방식 외의 선택지다

기존 검색 파이프라인에서는 이미지의 설명을 만들고 오디오를 전사한 뒤 그 텍스트를 검색하는 방식을 사용할 수 있다. 이때 원본에 있던 시각·청각 정보가 설명문에 충분히 남는지가 중요하다.

멀티모달 임베딩은 원본 매체의 정보를 함께 표현하는 선택지를 제공한다. 다만 어떤 구성이 우리 자료에 더 적합한지는 실제 검색 질문으로 비교해야한다.

예를 들어 “빨간 경고등이 켜진 장면”을 찾는 질문과 “장비 고장의 원인을 설명한 부분”을 찾는 질문은 다르다. 앞의 질문은 화면 정보가 중요하고 뒤의 질문은 대화 내용과 문맥이 중요할 수 있다.

```text
멀티모달 검색의 연결
원본 자료 → 구간·페이지 분리 → 임베딩 → 검색
                                    ↓
                         원본 위치와 근거 반환
```

공통 공간을 사용하더라도 검색 결과를 사용자에게 보여줄 위치 정보는 따로 필요하다. 영상의 어느 시점인지, PDF의 어느 페이지인지 알아야 결과를 실제로 확인할 수 있다.

## 인덱스에는 벡터 외의 정보도 필요하다

검색 결과에 비슷한 벡터만 있으면 자료를 어떻게 열어야하는지 알기 어렵다. 원본 ID와 버전, 페이지나 시간 구간, 접근 범위를 연결해둬야한다.

문서가 수정되면 기존 벡터가 어느 버전의 내용을 표현하는지도 중요해진다. 오래된 결과와 최신 자료를 섞으면 답변이 서로 다른 근거를 동시에 사용할 수 있다.

접근 권한 역시 별도 정보다. 의미가 비슷하다는 이유로 해당 사용자가 읽을 수 없는 자료까지 결과에 포함하면 안된다. 검색 필터와 원본 접근 검사를 같이 설계해야겠다.

여러 매체를 한 인덱스에 넣는다고 모든 자료를 같은 크기로 자를 필요도 없다. 영상의 시간 구간과 문서의 문단·페이지는 정보를 보존하는 단위가 다를 수 있다.

예를 들어 설명이 다음 페이지까지 이어지는 표와 한 장에 완결된 그림은 필요한 문맥이 다르다. 잘라낸 조각만으로 의미를 이해할 수 있는지부터 확인하면 좋겠다.

## 차원과 모델 변경은 저장소 설계와 연결된다

Embedding 2는 출력 차원을 선택할 수 있고 기본 차원은 3072로 안내됐다. 차원을 줄이면 저장과 검색 비용을 조절할 여지가 있지만 검색 품질도 실제 질문으로 비교해야한다.

기존 임베딩 모델과 새 모델의 벡터를 그대로 섞어도 되는지는 별도로 확인해야한다. 차원 수가 같다는 사실만으로 표현 공간까지 같다고 판단할 수는 없다.

모델과 차원을 함께 기록하고, 재임베딩과 인덱스 전환 절차를 준비하면 비교하기 쉽다. 새 검색 결과가 좋지 않을때 기존 경로와 대조할 수 있어야하기 때문이다.

운영 자료 전체를 바로 바꾸기보다는 대표 자료와 질문 묶음으로 시작해보고 싶다. 텍스트에서 이미지, 이미지에서 영상처럼 실제 서비스가 필요한 검색 방향을 포함하는것이다.

## 저장량은 차원과 조각 수를 함께 계산하자

벡터를 32비트 실수로 저장한다고 가정하면 원시 값의 크기는 `조각 수 × 차원 수 × 4바이트`로 대략 계산할 수 있다. 100만 조각과 3072차원이라면 벡터 값만 약 12.3GB다.

이 값에는 인덱스와 메타데이터, 원본 자료와 복제본이 포함되지 않는다. 실제 DB 용량의 예측값으로 그대로 사용하기보다 기본 비용을 이해하는 출발점으로 보면 되겠다.

문서를 더 잘게 나누면 검색 단위는 세밀해지지만 조각 수가 늘어난다. 차원만 줄이거나 조각 크기만 바꾸는 결정을 따로 하기보다 검색 품질과 저장량을 같은 자료에서 비교해야한다. 결과를 반환할때 앞뒤 문맥을 다시 붙이는 비용도 함께 생각하면 좋겠다.

# 4. 검색 품질은 답변의 자연스러움과 나눠서 평가하자

RAG에서는 최종 답변이 자연스러워도 검색된 근거가 잘못됐을 수 있다. 생성 모델이 빈 부분을 그럴듯하게 채우면 검색 계층의 문제를 놓치기 쉽다.

따라서 먼저 필요한 자료를 찾았는지 확인하고, 그다음 모델이 해당 자료를 정확히 사용했는지 보면 좋겠다. 검색과 답변을 하나의 점수로만 평가하면 원인을 좁히기 어렵다.

## 비슷하지만 정답이 아닌 자료를 넣어보자

정답 자료가 눈에 띄게 다른 작은 데이터셋에서는 검색이 쉬워보일 수 있다. 실제 환경에는 제목과 표현은 비슷하지만 버전이나 대상이 다른 문서가 많다.

예를 들어 같은 제품의 이전 매뉴얼과 최신 매뉴얼, 같은 장소를 다른 시간에 촬영한 영상처럼 구분이 필요한 사례를 포함해보자. 의미의 유사성과 질문에 필요한 정확성을 함께 보게 된다.

| 질문 유형 | 확인할 결과 |
| --- | --- |
| 특정 장면 찾기 | 맞는 영상과 시간 구간 |
| 문서의 수치 찾기 | 맞는 버전과 페이지, 표의 값 |
| 음성 내용 찾기 | 관련 발언과 앞뒤 문맥 |
| 이미지로 자료 찾기 | 유사한 외형과 실제 대상의 일치 |
| 권한이 다른 자료 | 접근 가능한 결과만 반환하는지 |

모든 질문에 결과를 반드시 반환하도록 만들 필요도 없다. 관련 자료가 없는 경우를 평가에 넣어야 검색 임계값과 답변의 보류 기준을 정할 수 있다.

답변에는 가능한한 원본 위치를 연결하면 좋겠다. 사용자가 근거를 열어 확인할 수 있어야 모델의 설명과 실제 자료가 맞는지 판단할 수 있기 때문이다.

# 5. AI·영상 — Sora API는 긴 생성과 반복 작업의 범위를 넓혔다

3월 12일 Sora API에 재사용 가능한 캐릭터 참조와 영상 확장, 최대 20초 생성, `sora-2-pro`의 1080p 출력과 Batch API 지원이 추가됐다. 구체적인 사용 범위는 [영상 생성 문서](https://developers.openai.com/api/docs/guides/video-generation)에서 확인할 수 있다.

영상 한편을 생성하는 호출에서 여러 장면을 반복하고 결과를 관리하는 파이프라인으로 생각할 부분이 늘어난것이다. 모델별 출력 조건도 구분해야한다.

## 참조 재사용과 장면의 연속성을 나눠보자

같은 캐릭터 참조를 재사용하면 여러 결과에서 일관성을 유지하는데 도움이 될 수 있다. 그렇다고 모든 장면의 자세와 구도, 시간 흐름까지 자동으로 같아지는것은 아니다.

원하는 시퀀스가 있다면 장면별로 유지할 요소와 바꿀 요소를 적어두면 좋겠다. 의상과 배경, 카메라 움직임과 행동을 구분해서 비교하는것이다.

영상 확장도 앞 장면과의 연결을 확인해야한다. 마지막 프레임의 외형만 비슷한지, 물체의 움직임과 위치가 자연스럽게 이어지는지, 음향과 분위기가 맞는지 볼 수 있다.

길이가 늘어나면 결과를 확인하는 시간도 함께 늘어난다. 첫 프레임과 썸네일만 보고 판단하면 중간의 왜곡이나 의도와 다른 행동을 놓칠 수 있겠다.

## 생성 요청과 결과 파일의 상태를 따로 관리하자

영상 생성은 요청을 보낸 뒤 결과를 기다리는 작업이다. 사용자에게는 아직 대기중인지, 처리중인지, 완료됐는지와 실패했는지를 구분해 보여주는 편이 좋다.

```text
영상 작업의 상태
요청 접수 → 대기 → 생성중 → 완료 → 결과 저장·검토
                         └→ 실패와 재시도 판단
```

요청이 느리다고 무조건 다시 보내면 중복 생성이 생길 수 있다. 작업 ID와 입력 조건을 보관하고 이미 진행중인 요청인지 확인할 수 있어야한다.

완료된 결과를 받아오는 단계도 따로 실패할 수 있다. 생성이 끝난것과 우리 저장소에 파일을 보관한것을 같은 상태로 취급하지 않으면 복구할 위치가 명확해진다.

Batch는 즉시 결과를 보여줘야하는 화면과 다른 사용 방식으로 볼 수 있다. 오프라인 렌더링 큐처럼 결과를 기다릴 수 있는 작업인지 먼저 구분하면 좋겠다.

## 해상도를 올릴때는 전체 전달 비용을 보자

1080p 출력을 사용할 수 있다고 모든 영상에 최고 해상도가 필요한것은 아니다. 사용자가 볼 화면과 재생 크기, 저장과 전송 비용을 함께 생각해야한다.

초안 검토와 최종 납품의 요구도 다르다. 먼저 짧은 시안으로 구도와 내용을 확인한 뒤 최종 결과의 조건을 정하는 방식도 고려할 수 있다.

개발자 입장에서는 모델 호출 시간 외에 다운로드와 저장, 변환과 재생까지 전체 과정을 봐야겠다. 생성 API가 성공해도 사용자 화면에서 재생할 수 없다면 서비스의 작업은 끝나지 않은것이다.

# 6. 이번주에는 파이프라인마다 비교 기준을 남기자

Vite와 임베딩, 영상 API는 모두 속도와 처리 범위를 넓히지만 같은 기준으로 도입 여부를 판단하기는 어렵다. 빌드는 출력의 호환성, 검색은 근거의 정확성, 영상은 결과의 품질과 작업 상태가 중요하다.

도입 전에 작은 기준 사례를 남겨두면 변화의 효과를 설명하기 쉽다. 현재 빌드의 시간과 산출물, 검색의 질문과 정답 자료, 영상의 요청과 검토 조건을 묶어두는것이다.

변경 후에는 결과가 좋아졌는지뿐 아니라 무엇이 달라졌는지 살펴보자. 속도와 품질, 비용과 운영 복잡도는 서로 다른 방향으로 움직일 수 있다.

개인적으로는 각 도구의 새 기능을 전부 사용하는것보다 지금 서비스에서 가장 큰 병목 하나를 정하고 비교해보고 싶다. 도구가 제공하는 선택지와 우리가 해결해야할 문제가 연결되어야하기 때문이다.

# 마무리

이번주는 Vite의 Rust 기반 통합 번들러, 여러 매체를 연결하는 임베딩, 영상 생성 API의 확장이 눈에 띄었다. 개발 도구와 AI 기능 모두 처리 파이프라인의 범위가 넓어지고 있다.

Vite는 실제 빌드와 배포 결과를 비교하고, Embedding 2는 Preview 상태에서 대표 검색 질문으로 시험해보면 좋겠다. Sora는 생성 결과와 함께 비동기 작업의 상태를 관리하는 구조까지 살펴봐야겠다.

새로운 기능이 생겼을때 무엇을 할 수 있는지 생각하는것도 좋지만, 결과를 어떻게 확인할지 먼저 정해두면 도입 판단이 더 쉬워지는것같다. 이번주에는 그 기준을 작은 사례부터 만들어봐야겠다..


[2026.03.13 주간 개발 트렌드] Vite 8과 멀티모달 임베딩, Sora API

독자의 메모