MLOps에서 추론 API, 그리고 SolarBox까지 — 업스테이지 Document AI의 성장기

업스테이지 Document AI 팀은 “Easy-to-apply AI”를 만들겠다는 목표로 시작했습니다.
처음에는 고객이 쉽게 AI를 도입할 수 있도록 MLOps 플랫폼을 구축했지만,
너무 많은 기능을 담으려다 오히려 복잡해졌습니다.

이후 "핵심에 집중하자"는 원칙 아래,
문서 추론만을 담당하는 단순한 API로 다시 시작했고,
거기에 필요한 기능들을 하나씩 붙여나가며 제품을 다듬었습니다.

지금은 SolarBox를 통해 고객사 맞춤형 AI 솔루션을
쉽고 빠르게 패키징·배포·운영할 수 있는 시스템을 만들고 있습니다.

한 명의 고객에서 시작해, 100 → 1,000을 넘어 그 이상을 향해 나아가는 과정에서
팀의 성장과 기술의 진화가 함께하는 여정을 이어가고 있습니다.

1. The journey of Document AI
Oct 2025
© 2025 Upstage Co., Ltd.

업스테이지 문수영

2. Who am I?
알파고 보고 딥러닝에 관심이 생겨
썽킴의 모두의 딥러닝으로 코딩
입문했다가..
발효학과에서 맥주도 만들고
미각과 감각뉴런도 연구하고..
뇌과학과 가서 초파리 뇌
연구하다가

3. 업스테이지 정착 ??????

4. 시작하기 전에
현재 서빙하고 있는 대표적인 Document AI 제품들이
어떤 것이 있는지 알아보자

5. Document Parse
현재 서빙 중인 대표적인 Document AI 서비스
Make your documents LLM-ready

6. Document Parse
현재 서빙 중인 대표적인 Document AI 서비스
Page limit 1000 Checkboxes Multi-page tables
Nested tables Rotated docs Forms

7. Key Information Extraction
현재 서빙 중인 대표적인 Document AI 서비스
Document input Extracted output

8. Key Information Extraction
현재 서빙 중인 대표적인 Document AI 서비스
Traditional OCR models Universal Information Extract
Invoice
Quote
Enrollment
form
Invoice
Quote
Enrollment
form
Universal
Extraction
Model
A single LLM-powered agentic pipeline to extract
any information from all your document types.

9. 無에서 시작하다
1
10
첫 Doc AI 제품
Less is more
100스케일 업업업!
????Beyond
목차

10. 1
첫 Doc AI 제품

11. OCR Pack
Easy-to-apply AI
고객들이 AI를 쉽게 도입할 수 있으면 좋겠다
쉬운 MLOps 플랫폼
OCR 전문가들 있으니 우선 잘 하는 것부터
시작해서 문서 AI 쪽으로 가볼까?
문서 정보 추출 모델

12. OCR Pack의 기본 컨셉
Data flywheel을 쉽게 경험할 수 있는 제품을 만들자!
점점 좋아지는 모델 → 서비스 사용자
증가 → 더 많은 데이터 → 점점 더
좋아지는 모델 ..
고객사 서비스 과정에서 수집되는
데이터를 이용하여 자체 유지보수가
가능하도록 all-in-one package 제공

13. 데이터 저장소, 어노테이션
툴, 데이터 버저닝 툴
…
모델 저장소, fine-tuning & eval
모듈 …
모델 파이프라인 배포 & 모니터링 툴
…
OCR Pack의 기본 컨셉
Data flywheel을 쉽게 경험할 수 있는 제품을 만드는 것은 쉽지 않다!

14. 처음엔 화면 없이 API랑 CLI만 먼저 개발
각자 서비스 1~2개씩 맡아 아키텍쳐
그려보고 한판에 모아보기

15. 바쁜 와중에 나름 20% Project로 각자 스터디 하고 발표도 진행

16. 전사 데모 준비를 위해 크런치 모드 합숙
개발팀
디자인팀

17. 그 끝에 완성한 수 많은 화면과 기능들

19. 그리고 첫 고객이 생기다 ??????

20. 고객 요구사항 반영하면서 제품 완성도 업 ☝
문서 분류 후 문서 타입에 맞게 정보 추출을 할 수 있는 워크플로우 개발
Traditional OCR models
Document
classification
API

All
Document
…
Invoice
Quote
Enrollment
form

21. 고객 요구사항 반영하면서 제품 완성도 업 ☝
데이터 스토리지 화면 로드 성능 98% 개선
문서 분류 후 문서 타입에 맞게 정보 추출을 할 수 있는 워크플로우 개발

22. 고객 요구사항 반영하면서 제품 완성도 업 ☝
추론 스루풋 약 20배 개선하여 하루 2만건 → 한시간 2만건 처리
고객 대만족
라벨링 툴 고도화
문서 분류 후 문서 타입에 맞게 정보 추출을 할 수 있는 워크플로우 개발
배치 스케줄러 & 비동기 추론 기능 구현
…
데이터 스토리지 화면 로드 성능 98% 개선

23. 팀의 전반적인 역량도 업 ☝
-고객 목소리를 들으며 어떤 것이 앞으로 재사용 가능하고 우리 제품의 코어
기능으로 챙겨갈 수 있을지 판단 하고 집중할 수 있음.
-당시 customer facing engineer가 없다보니 개발팀이 직접 온프레미스 AI
엔터프라이즈 과제의 처음부터 끝(제안서 - 유지보수)을 경험 해볼 수 있었음.
-frontend/backend heavy 작업, k8s, 모델 학습/서빙 파이프라인과 친해지는 등
full stack AI software engineer 역량

24. 하지만, 제품 방향과 확장성에 대한 고민

25. 베이스 모델 성능이 너무 좋아서 OCR Pack의 핵심 키워드인 Data
Flywheel이 무의미할 정도가 됨
제품이 크고 복잡 해서 고객이 이해하기 어렵다. 우리도 개발/유지보수하기 힘들고 설치도
오래 걸림
제품을 좀 더 심플하게 만들어서
대량의 문서를 강건하게 처리할 수 있는 추론 서비스를 만드는 것 어떨까?
…
사용자는 간단한 추론 기능만을 원하 기도 함

26. 10
Less is more

27. 완성된 그림을 수정하는 것 보다
흰 도화지에서 시작해 그림을 그려나가는 편이 쉽다

28. OCR Pack 서빙 파트를 독립적으로
이식하고 앞단에 인증과 과금 로직을
붙여서 빠르게 SaaS화 성공
모델 추론 API만으로도 잘 팔리지에 대한 검증

29. 라벨링스페이스
데이터 스토리지
배포
학습
평가
데모리소스 모니터링
추론
문서 타입별
프로젝트
관리
데이터셋 관리
모델셋 관리
가장 핵심 기능인 모델 서빙 파트를 제대로 만들어 보는 것으로부터 시작

30. 라벨링스페이스
데이터 스토리지
배포
학습
평가
데모리소스 모니터링
문서 타입별
프로젝트
관리
데이터셋 관리
모델셋 관리
추론
가장 핵심 기능인 모델 서빙 파트를 제대로 만들어 보는 것으로부터 시작
(a.k.a 서빙팩)

31. 단순히 문서 파일을 인풋으로 넣어주면 추론 결과를 반환해주는 추론 API
문서
추론 엔드포인트
(/document-digitization,
/information-extraction …)
추론
결과

32. 단순화시킨 서빙팩의 모습
-멀티페이지 처리 지원
-다양한 문서 포맷 지원 (JPEG, PNG, BMP, PDF, TIFF,
HEIC, DOCX, PPTX, XLSX, HWP, HWPX)
-최소한의 GPU 자원으로 최대한의 추론 쓰루풋
-SaaS에서도 OCR Pack을 서빙팩으로 교체

33. 기능을 대부분 빼고 추론 기능만 집중하니


오히려 고객이 더 증가

34. 하지만 온프레미스 엔터프라이즈 제품으로 성장하기에는
추론만으로는 기능이 부족하다고 판단


운영을 위한 툴들 추가

35. 지표
●모델별 총 요청 / 성공 /
실패 수
●페이지 당 추론 시간
●CPU / Memory / GPU
utilization
모니터링 툴
운영을 위한 툴들

36. 어드민 툴
운영을 위한 툴들
기능
●모델, 엔드포인트
생성/조회/재시작 등
●GPU의 모델 할당 맵

37. 라이선스
스토리지
온프레미스 엔터프라이즈 제품으로 성장
어드민 툴
모니터링
툴
데모 툴
인증/권한 관리
서빙팩

38. 늘어난 고객사들
and more …

39. 엔터프라이즈 사업을 위한 새로운 팀도 구성
Enterprise Business Solution (EBS) 팀
-고객사와 파트너사들과 직접
소통하고 제품 딜리버리

-고객과 가장 맞닿아 있어서 고객의
문제를 좀 더 직접적 으로 해결해주는
팀

-Enterprise 팀이 챙겨주시는 덕분에
Document AI 개발팀은 제품의
코어에 더 집중할 수 있게 됨

40. 하지만

41. 여전히 개선이 필요했던 제품 딜리버리 과정
Enterprise Business Solution (EBS) 팀
-OCR Pack 대비 제품에 들어갈
솔루션은 확 줄었고 최소한의 것들만
구성한다고 해도 여전히 챙겨야할
것들이 많음

-서빙팩, 모델들, 운영툴들,
데이터베이스, 오브젝트 스토리지 등

42. 딜리버리 과정 예시
“Document Parse 제품 패키지 원해요. 데모 툴도 포함되면 좋겠어요.”
고객
EBS 팀원
“음 그렇다면 필요한게 …”
✔ Document Parse에 필요한
모델들

✔ 서빙 엔진과 필요한 오픈소스
(inference-server, redis)

✔ 데모 툴 (docai-viewer)

43. 노션에서 document-parse에
필요한 모델들의 경로 확인 후
NAS에서 아티팩트들을 압축해서
준비
Github repo에 올라가 있는
Dockerfile로
docai-viewer를 직접
빌드해서 도커 이미지를 챙김
51 2
도커 허브에서 redis
등 필요한 오픈소스
pull
4
inference-server
이미지를 하버에서
pull
3
딜리버리 과정 예시

44. container 실행
각 노드에
설치
REST API로 모델,
엔드포인트 등
리소스 생성
고객사에 어떤 모델들
딜리버리 했는지 기록
6
7
8
9
딜리버리 과정 예시 (고객사 환경)

45. -모델팀, 플랫폼 개발팀, 앱 개발팀 각각 제품을 전달해주는 방식이 다름

-고객사별로 나가야할 제품을 패키징하고 설치하는 과정이 너무 번거롭고
관리가 안됨

-오픈소스 같은 경우 어떤 고객사에 어떤 버전이 나갔는지 관리가 되질 않음
문제점

46. -파편화 되어 있는 제품들 을 표준
카탈로그로 관리 하자

-카탈로그들을 쉽게 패키징할 수 있게
하자

-패키지를 쉽게 다운로드할 수 있고 쉽게
설치 가능하게 하자
솔라박스

47. 솔라박스 패키징 및 전달
41종의 제품 컴포넌트에 대해서
100여개의 리비전 포함

48. -고객사 환경에 맞게
conifguration.yaml 파일 하나만 잘
작성해두면

-operate, deploy 스크립트로 간편하게
모든 카탈로그를 한번에 띄울 수 있음
솔라박스

49. 딜리버리 과정 개선 후 예시
“Document Parse 제품 패키지 원해요. 데모 툴도 포함되면 좋겠어요.”
고객
EBS 팀원
“음 그렇다면 필요한게 …”
✔ Document Parse에 필요한
모델들

✔ 서빙 엔진과 필요한 오픈소스
(inference-server, redis)

✔ 데모 툴 (docai-viewer)

50. 클릭 몇 번으로
필요한 카탈로그들
패키징
고객사별 솔라박스 패키지 버전 기록이 남음
1
딜리버리 과정 개선 후 예시

51. 수동으로 리소스를 하나하나
생성해줄 필요 없음
configuration.yaml
파일 작성
솔라박스 operate & deploy
스크립트로 간편 실행
2
3
딜리버리 과정 개선 후 예시 (고객사 환경)

52. -솔루션 딜리버리 스텝을 9번 → 3번으로 줄여 운영 효율화

-고객사에 나가는 오픈소스들의 버전 관리도 가능해짐

-엔터프라이즈 포탈로 고객사별 패키지 버전관리가 가능해졌고 표준화된 매뉴얼 도
확인할 수 있음.
솔라박스 효과
?????? Solar Box로 고객사에 나갈 제품 패키징/버전 관리/설치를 쉽게하여 차차 파트너사에
이관이 쉬운 방향으로 발전. 엔터프라이즈 솔루션 대량 생산 확장성 확보 +1
매뉴얼

53. 한편, SaaS에서도 Document AI가 잘 팔리기 시작

54. RAG 급부상과 함께 Document Parse 모델이 Product Market Fit이 맞으면서
콘솔 유입량이 증가 ??????

55. 100
스케일 업업업!

56. 사용량 증가와 함께 더 탄탄한 제품으로 거듭나기

57. 사용량이 많아지니 보이는 문제 1
문서 처리도 하는 중
malformed 파일에 대한
핸들링이 제대로 안되어 있어
서비스 패닉이 발생하기도 함.
그때마다 코드 픽스 필요.

58. 사용량이 많아지니 보이는 문제 2
문서 처리도 하는 중
트래픽이 많은 시간대에 원인 불명의
segfault로 서버가 간헐적으로
다운되는 현상 발생

59. - DocMate 크래시가 나도 코어는 안전

- 유연한 아키텍처 지원: 마이크로서비스 아키텍처 뿐만 아니라 플러그인 아키텍처도 지원.
온프레미스 환경에서 추가적인 컨테이너 관리 및 운영 복잡성을 최소화하기 위함.

- 언어 제약 해소: 문서 처리 라이브러리의 성숙도 측면에서 이점이 있는 파이썬을 사용할 수
있는 기반 마련 (Go 기반 라이브러리는 일부 문서에서 실패 빈도↑)
해결 과정 1) 문서 처리 컴포넌트 격리

60. 해결 과정 2) 근본적으로 문제가 되는 부분을 찾아서 해결
- Go 라이브러리 내부 이슈에 대한 원인
파악도 위와 비슷하게, 서빙팩 코드, Go
wrapper, C 라이브러리 를 Cursor 한
창으로 열고, 에러 관련 부분들을 하나의
컨텍스트로 제공하여 원인을 쉽게 분석 &
해결
맨 왼쪽이 실패 pdf. 오른쪽 2개가 정상 pdf.
- malformed pdf 문서가 들어오는 경우,
Cursor AI chat에 문제가 되는 파일,
서빙팩 코드, 에러 로그 를 하나의
컨텍스트로 제공하여 원인을 쉽게 분석 &
해결

61. 이 외에도 다양하게 개선
-SaaS와 서빙 레이어를 포함하는 eW?e 테스트를 구축하여 배포 안정성을 확보
-인프라를 쿠버네티스 클러스터로 전환하여 오토 스케일링과 자동 복구 기능
적용으로 GPU 리소스 사용 효율화 & 장애 대응 및 온콜 부담 감소
-비동기 추론 개발로 요청당 페이지 제약을 100 → 1000으로 10배 늘릴 수 있었음
-시스템 Observability를 높이기 위해 애플리케이션 성능 모니터링 툴 SigNoz와
에러 추적 툴 Sentry를 도입
…

62. 더 탄탄해진 제품과 함께 콘솔 사용량 증가 ??????
엔터프라이즈 고객도 증가 ??????

63. 우리의 다음 스텝

64. ???
Beyond

65. 무엇을 해야할까요?
100 → 1,000

66. 1. 글로벌 스케일 의 SaaS/On-premise로 확장 → 미국, 일본 진출하여 고객들,
파트너사들 만나고 있음. Console도 미국 리전 런칭 준비중.
하고 있는 노력들
2. 채널 다양화 → AWS, Azure, Snowflake 등 마켓플레이스 등록으로 매출
내고 있음.

W?. AI Space 등 다양한 application 개발 및 고도화

4. 이 밖에 풀어야 할 재밌는 문제들 이 많이 남아있음 (서비스 사용자 격리,
비동기 추론 API 개선, 라이선스 기능 및 모델 암호화 고도화, 마켓플레이스 등록
등 각종 프로세스 자동화 등)

67. 1,000을 넘어 10,000 그 이상까지 ??????
또 어떤 것들을 해볼 수 있을까요?
함께 고민하고 성장할
동료를 구합니다 ??????

68. 감사합니다.