이미지는 현대 웹 애플리케이션에서 흔한 입력 유형이 되고 있습니다.

사용자는 스크린샷, 제품 사진, 문서, 차트, 인터페이스 목업(interface mockups), 에러 메시지를 업로드한 후, 애플리케이션이 추출된 텍스트, 요약, 구조화된 데이터(structured data), 대체 텍스트(alt text) 또는 질문에 대한 답변과 같이 유용한 결과물을 반환하기를 기대합니다.

처음에는 이것이 간단한 워크플로우처럼 보입니다:

1. 이미지 업로드.
2. 비전 모델(vision model)로 전송.
3. 응답 표시.

이러한 접근 방식은 프로토타입에는 작동하지만, 실제 사용자가 예측 불가능한 파일을 업로드하기 시작하면 신뢰할 수 없게 됩니다.

Describe Image를 구축하면서, 저는 모델 호출이 시스템의 일부분일 뿐이라는 것을 깨달았습니다. 입력 검증(Input validation), 전처리(preprocessing), 출력 구조(output structure), 에러 복구(error recovery), 개인정보 보호(privacy), 그리고 사용자 경험(user experience)이 똑같이 중요했습니다.

이 글에서는 프로덕션 환경에 적합한 이미지-구조화 텍스트 파이프라인을 어떻게 설계할 것인지 설명합니다.

1. 모델을 선택하기 전에 출력을 정의하라

첫 번째 실수는 모든 이미지 작업을 "이 이미지를 설명해줘"로 취급하는 것입니다.

사용자마다 완전히 다른 출력이 필요할 수 있습니다:

• 스크린샷으로부터의 OCR 텍스트
• 접근성을 위한 대체 텍스트 (alt text)
• 상세한 장면 설명
• 제품 속성 (Product attributes)
• 구조화된 행으로 변환된 표
• 이미지로부터 재구성된 프롬프트
• 인터페이스 또는 다이어그램의 요약
• 이미지에 대한 질문에 대한 답변

애플리케이션은 모델로 무엇인가를 보내기 전에 요청된 작업(task)을 식별해야 합니다.

유용한 내부 작업 정의는 다음과 같을 수 있습니다:

type ImageTask =
  | "ocr"
  | "alt_text"
...

이렇게 하면 각 작업에 대해 서로 다른 프롬프트(prompt), 응답 스키마(response schema), 토큰 제한(token limit) 및 검증 전략(validation strategy)을 사용하는 것이 가능해집니다.

일반적인 프롬프트는 대개 일반적인 출력을 생성합니다. 작업별로 특화된 파이프라인은 애플리케이션에서 실제로 사용할 수 있는 출력을 생성합니다.

2. 처리하기 전에 파일을 검증하라

브라우저가 제공하는 파일 이름이나 확장자를 신뢰하지 마십시오.

사용자는 어떤 파일이든 .png로 이름을 변경할 수 있으며, 일부 이미지 형식은 예상치 못하게 큰 차원(dimensions)이나 메타데이터(metadata)를 포함할 수 있습니다.

최소한 다음 사항들을 검증해야 합니다:

• MIME 타입 (MIME type)
• 파일 시그니처 (File signature)
• 파일 크기 (File size)
• 이미지 너비 및 높이 (Image width and height)
• 픽셀 수 (Pixel count)
• 애니메이션 상태 (Animation status)
• 업로드된 파일 수 (Number of uploaded files)

예시:

const MAX_FILE_SIZE = 10 * 1024 * 1024;
const MAX_PIXELS = 25_000_000;

...

정확한 제한 수치는 애플리케이션에 따라 다르지만, 프론트엔드(frontend)에서 이미 유사한 검사를 수행하더라도 검증은 반드시 서버(server)에서 이루어져야 합니다.

프론트엔드 검증은 사용성을 향상시키고, 서버 검증은 시스템을 보호합니다.

3. 모델 추론 전 이미지를 정규화하라

사용자는 다양한 출처로부터 이미지를 업로드합니다:

• 모바일 스크린샷 (Mobile screenshots)
• 카메라 사진 (Camera photos)
• 투명한 PNG 파일 (Transparent PNG files)
• 매우 넓은 웹페이지 (Very wide webpages)
• 스캔된 문서 (Scanned documents)
• 회전된 이미지 (Rotated images)
• 넓은 빈 여백을 포함하는 이미지 (Images containing large empty margins)

모든 원본 파일을 모델에 직접 전달하면 비용이 증가하고 일관성이 떨어질 수 있습니다.

정규화(normalization) 단계는 다음과 같은 역할을 할 수 있습니다:

• EXIF 방향(orientation) 교정
• 지원되지 않는 형식 변환
• 매우 큰 이미지 크기 조정 (Resize)
• 불필요한 메타데이터 제거
• 필요한 경우 투명도 평탄화 (Flatten transparency)
• 더 작은 미리보기 생성
• 원본 종횡비(aspect ratio) 유지

작업이 OCR인 경우 과도한 압축은 피해야 합니다. 크기 조정 후에는 작은 글자가 읽을 수 없게 될 수 있습니다.

일반적인 이미지 묘사(description)의 경우, 더 작은 정규화된 이미지만으로도 충분할 수 있습니다. 스크린샷과 문서의 경우, 파일 크기보다 텍스트 가독성을 우선시해야 합니다.

이는 전처리(preprocessing) 또한 작업 유형에 따라 달라져야 함을 의미합니다.

function getResizeStrategy(task: ImageTask) {
  if (task === "ocr" || task === "structured_extraction") {
    return {
...

4. OCR과 시각적 추론을 분리하라

OCR과 시각적 이해(visual understanding)는 서로 관련되어 있지만, 동일한 작업은 아닙니다.

OCR은 다음 질문에 답합니다:

어떤 텍스트가 보이는가?

시각적 추론(Visual reasoning)은 다음 질문에 답합니다:

이 이미지는 무엇을 의미하는가?

대시보드 스크린샷을 예로 들어보겠습니다. OCR은 다음과 같은 정보를 추출할 수 있습니다:

• 매출 (Revenue)
• 12,430
• 전환율 (Conversion rate)
• 3.8%

하지만 사용자는 다음과 같은 더 높은 수준의 결과가 필요할 수 있습니다:

매출 (Revenue)은 증가했으나 전환율 (Conversion rate)은 비교적 안정적으로 유지되었습니다.

복잡한 애플리케이션의 경우, 2단계 파이프라인 (two-stage pipeline)이 종종 더 신뢰할 수 있습니다:

이미지 (Image)
  ↓
텍스트 및 시각적 요소 추출 (Text and visual element extraction)
...

중간 표현 (Intermediate representation)은 다음과 같을 수 있습니다:

{
  "visibleText": [
    "Revenue",
...

이러한 구조는 하나의 긴 단락보다 검증 (validate), 저장 (store), 변환 (transform) 및 재사용 (reuse)하기가 더 쉽습니다.

5. 구조화된 출력 (Structured output) 요구하기

자유 형식 (Free-form)의 모델 응답은 애플리케이션 내부에서 사용하기 어렵습니다.

응답이 사람에게는 올바르게 보일지라도 다음과 같은 이유로 프론트엔드 (frontend)를 망가뜨릴 수 있습니다:

• 필드가 누락됨
• 숫자가 문자열 (string)로 반환됨
• JSON 앞에 추가적인 설명이 나타남
• 모델이 속성 이름 (property name)을 변경함
• 응답을 마크다운 펜스 (Markdown fences)가 감싸고 있음

스키마 (schema)를 정의하고 모든 모델 응답을 검증 (validate)하세요.

Zod 사용 예시:

import { z } from "zod";

const ImageAnalysisSchema = z.object({
...

그 다음 모델 결과를 파싱 (parse)합니다:

function parseAnalysis(input: unknown): ImageAnalysis {
  const result = ImageAnalysisSchema.safeParse(input);

...

스키마 검증 (Schema validation)은 선택적인 개선 사항으로 취급해서는 안 됩니다. 이는 예측 불가능한 모델과 결정론적인 (deterministic) 애플리케이션 사이의 경계의 일부입니다.

6. 가시적인 사실과 추론을 구분하기

모델은 때때로 누락된 정보를 그럴듯한 가정 (assumptions)으로 채우기도 합니다.

이러한 동작은 창의적인 글쓰기 중에는 유용할 수 있지만, 제품, 문서, 인터페이스 또는 기술적 스크린샷을 분석할 때는 위험합니다.

프롬프트 (prompt)는 다음과 같은 항목을 명확하게 분리해야 합니다:

• 직접적으로 보이는 정보 (Directly visible information)
• 합리적인 해석 (Reasonable interpretation)
• 확인할 수 없는 정보 (Information that cannot be confirmed)

제품 분석의 경우, 응답은 다음과 같이 사용할 수 있습니다:

{
  "visibleAttributes": {
    "color": "black",
...

이를 통해 애플리케이션이 추측을 검증된 사양 (specifications)으로 제시하는 것을 방지할 수 있습니다.

또한 이는 이커머스 (ecommerce), 접근성 (accessibility) 및 연구 워크플로 (research workflows)에서 결과의 신뢰도를 높여줍니다.

7. 실패 유형에 따른 재시도(retries) 설계

실패한 요청이 항상 동일한 의미를 갖는 것은 아닙니다.

발생 가능한 실패 유형은 다음과 같습니다:

• 잘못된 업로드 (Invalid upload)
• 지원되지 않는 형식 (Unsupported format)
• 스토리지 실패 (Storage failure)
• 모델 타임아웃 (Model timeout)
• 속도 제한 (Rate limit)
• 잘못된 구조화된 출력 (Invalid structured output)
• 모더레이션 거부 (Moderation rejection)
• 네트워크 중단 (Network interruption)
• 사용자 취소 (User cancellation)

모든 오류를 자동으로 재시도하지 마십시오.

간단한 분류는 다음과 같을 수 있습니다:

type ProcessingError =
  | "INVALID_INPUT"
  | "UNSUPPORTED_FORMAT"
...

권장되는 동작:

• 잘못된 입력 (Invalid input): 재시도하지 않음
• 지원되지 않는 형식 (Unsupported format): 재시도하지 않음
• 모델 타임아웃 (Model timeout): 백오프 (backoff)를 적용하여 재시도
• 속도 제한 (Rate limit): 제공된 지연 시간 이후에 재시도
• 잘못된 출력 (Invalid output): 더 엄격한 수정 프롬프트 (repair prompt)와 함께 한 번 재시도
• 스토리지 실패 (Storage failure): 모델 결과를 보존하고 스토리지를 별도로 재시도
• 알 수 없는 실패 (Unknown failure): 이벤트를 로그에 기록하고 사용자에게 안전한 메시지 제공

전체 파이프라인을 재시도하면 중복 비용이 발생하거나 중복 처리 작업이 생성될 수 있습니다. 가능한 경우 각 단계는 독립적으로 복구 가능해야 합니다.

8. 상태를 명시적으로 저장하기

오랜 시간이 걸리는 이미지 분석은 명시적인 처리 상태 (processing states)를 사용해야 합니다.

예를 들어:

type TaskStatus =
  | "created"
  | "uploading"
...

작업 레코드 (task record)에는 다음이 포함될 수 있습니다:

interface AnalysisTask {
  id: string;
  userId: string;
...

이는 다음 작업에 도움이 됩니다:

• 프론트엔드 폴링 (Frontend polling)
• 웹훅 처리 (Webhook handling)
• 서버 재시작 후 복구 (Recovery after server restarts)
• 고객 지원 (Customer support)
• 사용량 계정 관리 (Usage accounting)
• 실패한 작업 디버깅 (Debugging failed jobs)

success: true 또는 success: false만 사용하는 것은 피하십시오. 운영 환경의 시스템은 보통 어디에서 실패가 발생했는지 알아야 합니다.

9. 사용자 개인정보 보호

사용자가 인지하지 못하더라도 이미지에는 민감한 정보가 포함될 수 있습니다.

스크린샷에는 다음과 같은 정보가 노출될 수 있습니다:

• 이메일 주소 (Email addresses)
• 인증 토큰 (Authentication tokens)
• 개인 메시지 (Private messages)
• 고객 정보 (Customer information)
• 내부 대시보드 (Internal dashboards)
• 소스 코드 (Source code)
• 결제 세부 정보 (Payment details)

애플리케이션은 다음을 정의해야 합니다:

• 원본 업로드 파일의 보관 기간
• 업로드된 파일의 모델 학습 (Model training) 사용 여부
• 이미지를 전달받는 외부 프로세서 (External processors)
• 임시 파일의 삭제 시점
• 사용자가 결과를 수동으로 삭제할 수 있는지 여부
• 로그에 추출된 텍스트가 포함되는지 여부

기본적으로 모델의 전체 입력 (Inputs) 및 출력 (Outputs)을 로그에 남기는 것을 피하십시오. 모든 OCR 결과를 저장하는 디버깅 시스템은 의도치 않게 민감한 사용자 콘텐츠의 데이터베이스가 될 수 있습니다.

대신 요청 ID (Request IDs), 타이밍 정보, 오류 범주, 그리고 안전한 메타데이터 (Metadata)를 저장하십시오.

10. 모델 지연 시간 (Latency)뿐만 아니라 작업 품질을 측정하십시오

사용자가 결과를 수동으로 다시 작성해야 한다면, 모델의 응답 속도가 빠르더라도 유용하지 않습니다.

유용한 제품 지표 (Product metrics)에는 다음이 포함됩니다:

• 스키마 검증 (Schema validation) 성공률
• 평균 처리 시간
• 재시도율 (Retry rate)
• 사용자 복사 또는 다운로드율
• 재생성률 (Regeneration rate)
• 빈 OCR 결과의 비율
• 사용자 보고 수정률
• 완료된 작업당 비용

작업마다 서로 다른 품질 지표를 가져야 합니다.

OCR의 경우, 문자 정확도 (Character accuracy)가 중요합니다.

대체 텍스트 (Alt text)의 경우, 간결함과 관련성이 중요합니다.

제품 분석의 경우, 눈에 보이는 사실적 정확도 (Factual accuracy)가 중요합니다.

시각적 질의응답 (Visual question answering)의 경우, 답변이 일반적인 설명을 제공하기보다 실제 질문에 답변해야 합니다.

11. 인터페이스를 작업 중심 (Task-oriented)으로 유지하십시오

모든 모델 파라미터 (Parameter)를 사용자에게 노출하지 마십시오.

대부분의 사용자는 다음을 선택하고 싶어 하지 않습니다:

• 온도 (Temperature)
• 토큰 제한 (Token limit)
• 상세 수준 (Detail level)
• 모델 버전
• 샘플링 전략 (Sampling strategy)

그들은 다음과 같은 결과물을 선택하고 싶어 합니다:

• 텍스트 추출
• 대체 텍스트 생성
• 이 이미지 설명하기
• 이 제품 분석하기
• 프롬프트 생성
• 질문하기

백엔드 (Backend)에서 해당 의도를 기술적인 모델 설정으로 변환할 수 있습니다.

작업 중심의 인터페이스는 이해하기 더 쉬우며, 사용자 워크플로 (Workflow)를 변경하지 않고도 내부 구현을 개선하는 것을 가능하게 합니다.

최종 아키텍처 (Final architecture)

신뢰할 수 있는 이미지 분석 애플리케이션은 다음과 같은 단계로 구성될 수 있습니다:

업로드 (Upload)
  ↓
파일 검증 (File validation)
...

각 단계는 명확한 입력 (input), 출력 (output), 제한 사항 (limits), 그리고 실패 처리 (failure handling)를 갖추어야 합니다.

가장 큰 교훈은 프로덕션 환경에서의 이미지 이해 (image understanding)가 단순히 모델만의 문제가 아니라는 점입니다.

모델은 결과를 생성하지만, 이를 둘러싼 애플리케이션이 해당 결과가 안전한지, 구조화되었는지, 복구 가능한지, 그리고 유용한지를 결정합니다.

공개 사항: 이 기사는 구조 및 영어 편집을 위해 AI의 도움을 받아 작성되었습니다. 기술적 내용은 출판 전 검토 및 편집 과정을 거쳤습니다.