멀티모달 AI 붙일 때 OCR부터 따로 짜지 않게 된 이유

예전엔 이미지 처리 파이프라인을 따로 짰다

문서 이미지나 스크린샷을 다루는 기능을 만들 때 예전 습관이 있었다. 일단 OCR로 글자를 뽑고, 그다음 정규식으로 정리하고, 마지막에 텍스트 모델에 넣는 방식이다. 나도 그 흐름이 익숙해서 계속 그렇게 했다. 근데 최근 멀티모달 모델들을 써보니까, 그 중간 단계가 꼭 필요한 건 아니더라. 특히 표나 UI 캡처, 영수증처럼 문맥이 중요한 이미지는 텍스트만 뽑아서는 손실이 컸다.

한 번은 설정 화면 스크린샷을 분석하는 기능을 붙였는데, OCR 결과만 넘겼을 때보다 이미지 자체를 함께 보는 모델이 훨씬 덜 헷갈렸다. 버튼 위치, 강조 색, 섹션 구조 같은 게 같이 들어오니까 해석이 자연스러웠다. 이건 해보지 않으면 잘 안 와닿는다.

OCR은 여전히 필요하지만, 기본값은 아니게 됐다

물론 OCR이 끝난 건 아니다. 검색 인덱싱이나 대량 문서 처리처럼 텍스트 추출이 핵심인 경우엔 여전히 유용하다. 다만 사용자와 바로 맞닿는 기능, 예를 들어 화면 설명, 문서 요약, 스캔 이미지 질의응답 같은 곳에선 멀티모달 모델 하나로 끝내는 쪽이 구현도 단순했다. 코드가 줄어들고, 예외 처리도 덜 복잡해진다.

특히 표가 섞인 문서에서 차이가 컸다. OCR은 줄바꿈이 조금만 틀어져도 행과 열이 무너지는 경우가 많은데, 멀티모달 모델은 배치 자체를 같이 보니 상대적으로 안정적이었다. 써봤는데 정답률이 드라마틱하게 오르기보다, 엉뚱한 답이 줄었다는 쪽에 더 가깝다. 실무에선 그게 더 반갑다.

설계가 단순해지면 기능 실험도 빨라진다

개발할 때 귀찮은 건 모델 성능보다 파이프라인 유지보수다. OCR 엔진 버전 차이, 언어 설정, 전처리 품질, 후처리 규칙까지 챙기다 보면 기능 하나 붙이는 데 생각보다 손이 많이 간다. 반면 멀티모달 입력을 기본으로 잡으면 프롬프트와 입력 포맷만 조정해도 되는 경우가 많다. 이게 꽤 크다. 실험 속도가 올라가니까 버려야 할 아이디어도 빨리 버릴 수 있다.

대신 비용과 지연시간은 꼭 봐야 한다. 이미지 입력은 텍스트만 다룰 때보다 무거운 편이고, 잘못 쓰면 별 이득 없이 토큰만 늘어난다. 그래서 나는 작은 썸네일이나 일부 영역만 잘라 보내는 식으로 먼저 줄인다. 무작정 크게 넣는 건 생각보다 비효율적이었다.

이제는 먼저 묻는다, 정말 텍스트만 뽑으면 되나

요즘 화면 분석이나 문서 이해 기능을 만들 때는 제일 먼저 이 질문부터 한다. “이걸 굳이 OCR로 한 번 번역해야 하나?” 그냥 이미지로 바로 이해시키는 편이 더 나은 경우가 꽤 많다. 솔직히 기술 스택은 덜 화려해졌는데, 사용성은 오히려 올라갔다. 멀티모달이 대단해 보여서가 아니라, 중간 단계를 덜 만들게 해줘서 좋았다.

---

📎 참고 자료

• OpenAI Images and vision guide
• Gemini image understanding
• Anthropic vision guide