대부분의 "앱에 AI 업스케일링 추가하기" 튜토리얼은 모두 동일한 방식을 취합니다. 컴포넌트나 라우트 핸들러(route handler)에 fetch()를 넣고, 결과를 await한 뒤, 렌더링하는 식이죠. 데모에서는 잘 작동합니다. 하지만 실제 사용자가 사진을 업로드하면, 요청이 8초 동안 멈춰 있고, 서버리스 함수(serverless function)는 타임아웃(timeout)이 발생하며, 아무것도 캐싱(cache)되지 않았기 때문에 페이지를 로드할 때마다 동일한 이미지가 계속해서 다시 업스케일링됩니다.

문제는 모델이 아닙니다. 바로 _호출을 어디에 두느냐_입니다.

업스케일링은 생성적 작업(generative job)입니다. 느리고, 비결정론적(non-deterministic)이며, 이미지당 비용이 발생합니다. 이러한 특성은 앱의 나머지 부분이 수행하는 CRUD 호출과는 전혀 다르며, 요청 경로(request path)에 있어서는 안 됩니다. 이 포스트는 파이프라인의 형태, 즉 단계가 어디에 위치해야 하는지, 어떻게 캐싱하는지, 그리고 어떻게 우아하게 실패(fail gracefully)하는지에 대해 다룹니다. 업스케일러 자체는 교체 가능하므로, 실제 API 호출은 어떤 제공업체로든 지정할 수 있는 하나의 함수 뒤에 두겠습니다.

짧은 답변: 요청 경로에서 제외하세요

전체 파이프라인을 한 줄로 요약하면 다음과 같습니다:

업로드 → 입력값 해싱(hash) → 캐시 확인 → 캐시 미스(miss) 시 비동기(async) 업스케일 작업 대기열(enqueue)에 추가 → 결과 저장 → next/image가 완성된 파일 제공.

사용자의 요청은 모델을 기다리지 않습니다. 사용자는 업로드하고, 작업 ID(job ID) 또는 원본 이미지를 돌려받으며, 업스케일된 버전은 준비되었을 때 나타납니다. 동일한 입력은 항상 동일한 출력으로 매핑되므로, 각 고유한 이미지는 정확히 한 번만 업스케일링됩니다.

이 방식이 작동하게 만드는 세 가지 속성이 있으며, 이는 모든 무거운 생성적 단계에 적용하고자 하는 세 가지 속성과 동일합니다:

• 비동기 (Async): 업스케일은 HTTP 핸들러가 아닌 백그라운드 작업(background job)에서 실행됩니다.
• 멱등성 (Idempotent): 입력값의 콘텐츠 해시(content hash)가 캐시 키(cache key)가 되므로, 재시도나 중복 업로드는 비용이 들지 않습니다.
• 폴백 우선 (Fallback-first): 업스케일 결과가 없거나 실패한 경우, 원본을 제공합니다. 모델이 느리다고 해서 500 에러가 발생하지는 않습니다.

1단계: 입력을 해싱하여 업스케일링을 한 번만 수행하기

캐시 키(cache key)는 파일 바이트(file bytes)와 스케일 인자(scale factor)를 해싱한 값입니다. 재시도(retry), 재업로드(re-upload), 또는 동일한 이미지를 가진 두 사용자로부터 온 것이든 상관없이, 동일한 사진을 4배(4x)로 업스케일링하면 항상 동일한 키로 결정됩니다.

// lib/upscale-key.ts
import { createHash } from "node:crypto";

...

이 16진수 문자열(hex string)이 저장 경로(upscaled/{key}.webp)이자 캐시 조회(cache lookup) 기준이 됩니다. 시작할 때 데이터베이스 행(database row)이 필요하지는 않습니다. 오브젝트 스토리지(object storage) 목록 확인만으로 충분합니다.

2단계: 업스케일 호출을 하나의 함수 뒤로 숨기기

이것은 파이프라인 내에서 유일한 벤더 특정(vendor-specific) 코드이므로, 제공업체(provider)를 변경할 때 교체해야 할 유일한 부분입니다. 함수 시그니처(signature)는 단순하게 유지하세요: 바이트(bytes)를 입력받아 바이트(bytes)를 반환하는 방식입니다.

// lib/upscale.ts
// 사용하는 서비스에 따라 본문(body)을 교체하세요. 정확한 엔드포인트(endpoint), 인증(auth), 그리고 요청 형태(request shape)는 해당 서비스의 문서를 참조하세요. 블로그에 나온 숫자를 그대로 복사하지 마세요.
...

제가 여기서 실제 엔드포인트나 "전형적인 지연 시간(latency) X ms" 같은 정보를 의도적으로 제공하지 않는 이유는, 제가 모든 제공업체의 API를 벤치마킹(benchmark)하지 않았기 때문이며, 지어낸 숫자는 아예 없는 것보다 못하기 때문입니다. 중요한 것은 형태(shape)입니다: 실패할 수 있는 하나의 비동기(async) 함수이며, 파이프라인의 나머지 부분이 이 함수가 빠를 것이라고 가정하지 않도록 래핑(wrapped)되어 있어야 합니다.

3단계: 업로드 핸들러는 대기하지 않고 큐에 넣기

라우트 핸들러(route handler)는 비용이 적게 드는 동기적(synchronous) 작업(해싱, 캐시 확인, 작업 시작)을 수행하고 즉시 반환합니다. 모델을 await 하지 않습니다.

// app/api/images/route.ts
import { NextResponse } from "next/server";
import { upscaleKey } from "@/lib/upscale-key";
...

클라이언트는 즉시 url을 렌더링합니다. 캐시 미스(miss)가 발생하면 원본 이미지를 보여줍니다. 눈에 보이기에 괜찮으며, 단지 아직 선명해지기 전일 뿐입니다. 작업이 완료되면 GET /api/images/{key}를 폴링(polling)하거나 이미 사용 중인 실시간 채널을 통해 업스케일된 버전으로 교체됩니다.

백그라운드 워커(background worker)는 실제로 느린 호출이 발생하는 곳입니다:

// worker/upscale-job.ts
import { upscaleImage } from "@/lib/upscale";
import { putUpscaled, markFailed } from "@/lib/store";
...

만약 작업(job)에서 오류가 발생하더라도, 아무도 에러 페이지를 보지 못합니다. 원래 이미지는 여전히 제공되는 폴백(fallback)으로 남아 있으며, 단지 선명해진 이미지를 받지 못했을 뿐입니다. 로그를 통해 그 이유를 확인할 수 있습니다.

4단계: next/image가 전달(delivery)을 담당하게 하세요

업스케일된 파일이 스토리지에 저장되면, 그것은 일반적인 이미지입니다. 전달 방식을 직접 구현(hand-roll)하지 마세요. next/image는 이미 반응형 크기 조절(responsive sizing), 지연 로딩(lazy loading), 그리고 포맷 협상(format negotiation)을 수행합니다:

import Image from "next/image";

export function Photo({ src, alt }: { src: string; alt: string }) {
...

업스케일링은 더 크고 깨끗한 소스(source)를 제공하며, next/image는 이를 레이아웃에 필요한 크기로 다시 축소합니다. 4배(4x)로 업스케일링한 뒤 400px 썸네일을 제공하는 것은 비용 낭비이므로, 이미지가 실제로 표시되는 최대 크기에 맞춰 스케일 인자(scale factor)를 설정하세요.

랜딩 페이지에서는 알려주지 않는 부분: 업스케일링은 디테일을 만들어냅니다

이것은 설계를 통해 고려해야 할 주의사항입니다. AI 업스케일러는 손실된 디테일을 '복구(recover)'하는 것이 아닙니다. 작은 이미지에는 복구할 손실된 디테일 자체가 존재하지 않습니다. 정보가 그곳에 없기 때문입니다. 초해상도(Super-resolution) 모델은 학습된 데이터를 바탕으로 '그럴듯한(plausible)' 새로운 픽셀을 생성합니다. 이것이 바로 환각된 디테일(hallucinated detail)이며, 업스케일된 얼굴이 미묘하게 어색해 보이거나 업스케일된 로고의 글자 형태가 임의로 만들어져 나오는 이유입니다.

실질적인 결과: 전송할 데이터를 필터링(gate)하세요. 업스케일링 (Upscaling)은 이미 어느 정도 괜찮지만 약간 흐릿한 이미지에서 빛을 발합니다. 반면, 아주 작은 썸네일이나 JPEG 압축이 심하게 된 입력값에서는 어려움을 겪으며, 잘못된 내용을 자신 있게 만들어내곤 합니다. 작업을 큐에 넣기(enqueue) 전에 저렴한 비용으로 크기나 형식을 확인하는 것만으로도 비용과 품질 저하를 모두 방지할 수 있습니다:

// lib/should-upscale.ts
export function shouldUpscale(bytes: number, width: number): boolean {
  const tooSmall = width < 256;          // 신호가 충분하지 않음; 허구의 내용을 만들어낼 것임
...

어떤 업스케일러를 사용할 것인가?

위의 파이프라인은 특정 벤더에 종속되지 않습니다 (vendor-neutral). 이미지를 입력받아 더 큰 이미지를 반환하는 것이라면 무엇이든 upscaleImage() 단계에 들어갈 수 있습니다. 프로토타이핑을 위해 저는 Imagvio의 AI 이미지 업스케일러를 사용해 왔으며, 이는 JPG/PNG/WEBP에 대해 2배/4배(최대 8배까지 광고함) 업스케일링을 수행합니다.

솔직히 말씀드리면: 이는 OpenAI나 Google의 제품이 아닌 독립적인 제3자 도구이며, 저는 이를 활용해 서비스를 구축하는 사람입니다. 따라서 무료 티어(free tier)는 운영 환경의 SLA(Service Level Agreement)가 아닌 평가용으로 간주하십시오. 파이프라인의 엔드 투 엔드 (end-to-end) 작동을 확인하고 실제 이미지의 출력 품질을 육안으로 확인하는 용도로는 적합합니다. 실제 운영 트래픽을 보낼 때는 해당 서비스의 약관을 확인하고, 이 포스트가 아닌 제공업체의 문서를 통해 요청 세부 사항을 확인하십시오.

무엇을 측정해야 하는가 (블로그 포스트의 수치를 맹신하는 대신)

저는 지연 시간 (latency) 수치를 인용하지 않겠습니다. 왜냐하면 이는 제공업체, 확대 배율 (scale factor), 입력 크기, 그리고 날짜에 따라 달라지기 때문입니다. 여러분의 이미지로 직접 측정해 보십시오:

• 각 배율별 이미지당 지연 시간 (Per-image latency). upscaleImage()를 직접 측정하십시오. 이는 사용자에게