Skip to content
Park Hyoin
Go back

Claude Vision — 이미지를 어떻게 넣는가, 그리고 어느 모델로 받는가

Edit page

오늘은 짧게. Claude API의 Vision 기능을 처음 만져봤다.

Table of contents

Open Table of contents

이미지를 넣는 두 가지 방식

1) base64 인코딩으로 본문에 직접 첨부

이미지 파일을 base64 문자열로 변환해서 image 블록에 담아 보낸다. 이미지가 외부에 호스팅되지 않아도 된다는 장점. 로컬 파일을 바로 모델에 보낼 때 적합.

2) URL로 참조

이미지가 인터넷에 공개돼 있으면 URL만 넘기면 된다. 메시지 페이로드가 가볍고, 같은 이미지를 여러 번 쓸 때 효율적.

두 방식 모두 결과 품질엔 차이가 없는 인상이었다. 상황에 맞춰 고르면 되는 옵션이지, 우열은 아니다.

텍스트보다 비싸다 — input token

이미지를 넣으면 같은 질문이라도 input 토큰이 훨씬 많이 든다. 일반 텍스트 프롬프트와 비교하면 체감이 분명히 컸다. 이미지 한 장이 토큰으로 환산되면서 비용이 늘기 때문.

→ 결국 “Vision을 쓸 가치가 있는 작업인가” 를 매번 의식해야 한다. 텍스트로 풀 수 있는 일은 텍스트로 푸는 게 정답.

한계 — 작은 텍스트와 복잡한 다이어그램

Vision이 만능은 아니다. 다음 경우에 자주 놓친다.

  • 작은 텍스트 (스크린샷의 작은 글씨, 라벨, 캡션 등)
  • 복잡한 다이어그램 (선이 많이 겹치거나 컴포넌트가 빽빽한 그림)

이런 케이스를 다룰 때는 이미지를 잘라서 부분별로 보내거나, OCR 같은 별도 도구를 함께 쓰는 보완이 필요해 보인다.

정확도가 필요하면 더 큰 모델로

이전 예제들은 모두 Haiku(가장 작고 빠른 모델)로 진행했었다. 그런데 오늘 한 실험 중 — 손으로 그린 와이어프레임을 HTML 코드로 변환하는 작업 — 에서는 모델을 Sonnet으로 바꿔서 진행했다.

이유는 단순했다. 와이어프레임을 정확히 읽어내고 거기에서 의도(레이아웃 / 컴포넌트 분리)를 추론해서 코드로 옮기는 작업은 단순 식별보다 한 단계 더 어려운 작업이라, 더 큰 모델의 추론 능력이 필요했다.

정확도가 필요한 작업에는 큰 모델, 빠르고 가벼운 분류·태깅에는 작은 모델.

이 분기 기준을 직접 체감하니, 모델 선택은 단순히 “가장 좋은 모델 쓰자” 가 아니라 작업 난이도에 맞춰 고르는 일 이라는 게 명확해졌다.

정리

  • 이미지 첨부: base64 / URL 두 방식, 상황 따라 선택.
  • input 토큰 비용은 텍스트보다 비싸다 — Vision이 정말 필요한 작업에만 쓰자.
  • 작은 텍스트·복잡한 다이어그램 인식은 약함. 보완책 필요.
  • 정확도가 필요한 작업은 더 큰 모델로 (Haiku → Sonnet → Opus).

더 공부해볼 것

1. 이미지의 토큰 계산 방식

  • 한 장이 정확히 몇 토큰으로 환산되는가 (이미지 크기와의 관계)
  • 큰 이미지를 줄여서 보내면 비용 절감 vs 인식 정확도 손실의 트레이드오프
  • 참고: Anthropic Vision 문서

2. 모델별 Vision 성능 비교

  • Haiku / Sonnet / Opus 가 같은 이미지로 같은 질문을 받을 때 정확도·지연·비용 비교
  • “와이어프레임 → HTML” 같은 추론형 vs “이 이미지에 고양이가 있나” 같은 단순 식별형에서 모델 선택이 어떻게 갈리는가

3. 실서비스에 끼울 자리

  • 내 1인 앱에 Vision을 끼울 수 있을 곳: 사용자가 업로드한 이미지로 자동 태깅, 영수증 OCR 보조, 손글씨 메모 → 텍스트 변환 등
  • 비용 통제: 캐싱, 미리 사이즈 줄이기, 명확히 인식 실패한 케이스만 사용자에게 재업로드 유도

4. OCR과의 조합

  • 작은 텍스트 인식 한계를 OCR로 보완하는 패턴
  • 어떤 작업은 OCR로만, 어떤 작업은 Vision으로만, 어떤 작업은 두 결과를 합쳐서

회고

Vision의 가장 큰 인상은 “이미지를 본다” 자체보다 “이미지에서 의도를 읽고 추론한다” 쪽이었다. 와이어프레임이 그냥 선과 박스 그림인데, 그걸 보고 “여기는 헤더, 여기는 콘텐츠, 여기는 푸터” 로 해석해서 HTML로 옮기는 흐름은 단순 OCR과는 결이 다르다.

그리고 이번에 처음으로 모델을 의식적으로 바꾼 경험을 했다. 그동안은 “Haiku 빠르고 싸니까” 정도였는데, 작업에 따라 정확도가 필요하면 모델을 바꾸는 판단을 직접 해보니 LLM을 다루는 감각이 한 칸 더 자란 느낌.


Edit page