핵심 요약:
- 문서 추출 API는 PDF, 스캔본 또는 이메일에서 라벨링된 필드, 테이블 및 품목을 제공합니다. OCR은 문자를 제공하고 의미 파악은 여러분에게 맡깁니다.
- 템플릿 기반 추출과 AI 기반 추출은 다른 제품입니다. 템플릿은 공급업체가 총액의 위치를 이동하면 작동하지 않지만, AI 추출은 본 적 없는 레이아웃도 읽어냅니다.
- 자체 문서에 대한 필드 수준의 정확도로 공급업체를 평가하세요. 데이터시트의 숫자는 그들의 문서에서 측정한 것입니다.
- Parseur는 개발자 API와 운영팀이 실행할 수 있는 웹 앱을 함께 제공하므로 아무도 검토 도구를 구축할 필요가 없습니다.
- Parseur는 EU에 호스팅되어 있으며, 데이터는 유럽 연합 내에서 처리 및 저장되고 AI 모델 학습에 절대 사용되지 않습니다.
문서 추출 API는 PDF, 스캔 이미지 또는 이메일과 같은 파일을 가져와서 JSON 또는 CSV와 같은 구조화된 데이터로 반환하는 서비스입니다. 일반 텍스트를 반환하고 의미를 찾도록 남겨두는 원시 OCR과 달리, 문서 추출 API는 주요-값 쌍, 테이블, 품목 및 라벨 필드와 같은 구조를 식별하고 보존합니다.
세 가지 유사한 도구와 혼동되곤 합니다. 퍼블릭 데이터 API는 다른 사람이 이미 조립한 데이터 세트를 제공합니다. 웹 스크래핑 API는 웹 페이지에 있는 내용을 가져옵니다. OCR 엔진은 문자를 가져오지만 구조는 없습니다. 문서 추출 API는 여러분의 문서, 즉 이미 수신함에 있는 문서에 대해 작동하여 시스템이 조치를 취할 수 있는 데이터로 변환합니다. 일부 벤더는 동일한 기능을 문서 이해(document understanding) API라는 이름으로 판매하거나 문서 추출 SDK로 제공합니다. 이름은 달라도 역할은 같습니다. 아직 어떤 문제가 있는지 파악 중이신가요? 문서 파싱과 웹 스크래핑을 나란히 비교해 보았습니다.
Research and Markets에 따르면, 문서 추출 API를 포함하는 인텔리전트 문서 처리 시장은 약 30억 1천만 달러 규모로 평가되며 연평균 31.7% 성장할 것으로 예상됩니다. 이 수치는 실제로 송장, 명세서 및 양식의 수량이며 모든 문서는 무언가에 의해 읽혀야 합니다. 많은 회사에서 그 '무언가'는 여전히 보조 모니터와 숫자 키패드를 사용하는 사람입니다.
빠른 예시:
- PDF 송장 → 헤더 필드와 품목 배열을 갖춘 JSON
- 온보딩 양식 → 라벨링된 주요-값 쌍 (이름, 주소, 서명)
- 은행 명세서 → CSV로 내보낸 거래 테이블
동일한 라벨을 사용하는 다섯 가지 유형의 공급업체
"문서 추출 API"를 검색하면 동일한 카테고리를 공유하지만 그 외에는 거의 공통점이 없는 10여 개의 공급업체를 찾을 수 있습니다. 그들은 각기 다른 5가지 목적을 위해 구축되었기 때문에 실제로는 서로 경쟁하지 않습니다. 모든 공급업체는 자체 데모에서 성공할 것이므로, 어떤 유형에 속하는지가 단순한 홍보보다 더 중요합니다. 단 한 번의 통화를 예약하기 전에 여러분이 어떤 유형에 속하는지 파악하세요.
| 공급업체 유형 | 예시 | 구축 목적 | 직접 구축해야 할 항목 |
|---|---|---|---|
| 클라우드 빌딩 블록 | Google Document AI, Azure Document Intelligence, AWS Textract | 이미 해당 클라우드로 표준화했고 여러 서비스 중 하나로 추출을 원하는 팀 | 데이터 수집, 검토 화면, 예외 처리, 재시도, ERP 포스팅 |
| AP 자동화 플랫폼 | Rossum, Nanonets | 단순한 필드가 아니라 인보이스 워크플로우 전체를 원하는 재무팀 | 워크플로우가 귀사의 것과 충분히 가깝다면 구축할 항목이 거의 없음 |
| 개발자 중심 파싱 API | Mindee, Veryfi, Parseur | 워크플로우를 소유하고 있으며 깔끔한 JSON 결과를 원하는 엔지니어 | 벤더에 따라 다름. Parseur는 검토 앱을 함께 제공 |
| AI 네이티브 문서 파서 | LlamaParse, Reducto | 비즈니스 필드보다 충실한 구조가 더 필요한 RAG 및 에이전트 파이프라인 | 필드 매핑, 검증 등 워크플로우와 관련된 모든 것 |
| 엔터프라이즈 IDP 제품군 | ABBYY, Hyperscience, UiPath | 규제를 받고 대량 작업을 하며 사람의 검토와 레거시 시스템이 있는 환경 | 구축할 항목이 거의 없음. 작업은 구성 및 배포로 이동됨 |
이 표에 대한 두 가지 주의 사항이 있습니다. 첫째, 행이 흐릿합니다: 몇몇 공급업체는 두 곳에 모두 속합니다. 둘째, Parseur는 이것이 바로 구축 목적이기 때문에 세 번째 행에 있습니다. 이메일과 운영 문서를 구조화된 JSON으로 변환하고 운영팀이 실제로 실행할 수 있는 앱을 함께 제공합니다. 여러분의 문서가 엔지니어링 도면이라면 4번째 행이 저희보다 더 적합하며, 이 사실을 트라이얼 기간이 아닌 지금 알려드리고자 합니다.
템플릿 기반 vs AI 기반 추출 (확장 가능한 것은 단 하나뿐)
템플릿 기반 추출은 페이지의 위치를 통해 필드를 찾습니다. AI 기반 추출은 의미를 통해 찾습니다. 이것이 가장 큰 차이점이며, 여러분이 얼마나 많은 작업을 감수해야 할지 결정합니다.
템플릿은 이렇게 말합니다: 송장 번호는 위에서 40mm, 왼쪽에서 120mm에 위치해 있다. 빠르고 결정론적이며 멋집니다. 이는 공급업체가 송장 디자인을 변경하는 아침까지 유지되며, 그 시점이 되면 잘못된 값을 반환하거나 아무것도 반환하지 않고, 누군가 티켓을 열게 됩니다. 200개의 공급업체, 200개의 템플릿, 그리고 이를 이해하는 단 한 명의 엔지니어.
AI 기반 추출은 사람이 하는 것처럼 문서를 읽습니다. "결제 금액"이라는 줄 아래, 오른쪽 하단에 통화 형식으로 표시되어 있고 그 위에 있는 합계와 동일하기 때문에 총액을 찾습니다. 그것을 이동하고, 스타일을 바꾸고, 전체 송장을 독일어로 번역해도 여전히 찾을 수 있습니다.
Parseur는 두 개의 AI 엔진을 실행하며 템플릿은 사용하지 않습니다: 이메일과 텍스트 문서를 위한 텍스트 AI 엔진, PDF, 스캔 및 이미지를 위한 비전 AI 엔진. 원하는 필드를 설명하면 추출이 레이아웃별이 아닌 문서별로 조정되므로, 설정하는 데 몇 주간의 템플릿 작성이 아니라 단 몇 분의 필드 정의면 충분합니다.
트레이드오프는 실재합니다. AI 추출은 템플릿이 결정론적인 반면 확률적입니다. 이것이 신뢰도 점수가 존재하는 이유이며, 아래의 평가 섹션이 정확도 주장보다 예외 처리에 더 많은 시간을 할애하는 이유입니다.
문서 추출 API의 작동 원리, 5단계
세부 사항은 벤더마다 다르지만 문서 추출 파이프라인은 어디서나 같은 형태를 갖습니다.
이것이 더 이상 선택 사항이 아닌 이유: 바로 볼륨(데이터의 양) 때문입니다. Dream Factory는 널리 인용되는 예측을 언급하며 전 세계 데이터가 2025년까지 175제타바이트에 달할 것이라고 했습니다. 이 날짜는 이미 지났으며 데이터베이스 행이 아닌 문서로 도착하는 데이터의 비율은 줄어들지 않았습니다. 수작업 데이터 입력으로는 이 규모를 감당할 수 없습니다. 수많은 템플릿도 마찬가지입니다.
1단계: 데이터 수집 (Ingestion)
벤더가 어떻게 부르든 이것은 문서 수집 API입니다: HTTP를 통한 업로드, 이메일 포워딩, 또는 다른 시스템으로부터의 웹훅. 이메일은 생각보다 더 중요합니다. 비즈니스 문서의 상당수는 파일 선택기를 거치지 않고, 여러분의 포털에 대해 들어본 적도 없는 공급업체로부터 첨부 파일로 도착합니다.
2단계: AI OCR 및 레이아웃 분석
AI OCR은 이미지와 스캔된 콘텐츠를 기계가 읽을 수 있는 텍스트로 변환합니다. 그런 다음 레이아웃 분석은 읽기 순서, 텍스트 블록, 줄, 단어 및 각각이 페이지의 어디에 위치하는지 파악합니다. 이것이 최신 엔진과 2010년 엔진을 구분하는 단계입니다: 단순히 문자가 아닌 구조적 맵을 생성합니다.
3단계: 파싱 (Parsing)
- 주요-값 쌍: "송장 번호: 12345" 와 같이 값과 일치하는 라벨입니다.
- 테이블 및 품목: 병합된 셀, 스팬(span) 및 페이지 나누기를 넘어 계속되는 테이블을 포함하여 행과 셀이 재구성됩니다.
- 분류: 어떤 필드를 찾을지 결정하기 전에 문서가 무엇인지 파악합니다.
4단계: 후처리
날짜, 통화 및 공급업체 이름이 일관된 형식으로 정규화됩니다. 결과는 JSON 스키마 또는 Pydantic 모델과 대조하여 검증되므로 잘못된 형식의 페이로드가 ERP에 도달하지 않습니다.
5단계: 전송 (Delivery)
API는 작은 파일의 경우 결과를 동기적으로 반환하고, 더 큰 파일의 경우 웹훅 콜백을 통해 비동기적으로 반환합니다. 대량의 작업을 안정적으로 유지하는 것은 재시도(retries)와 멱등성(idempotency)입니다. 조용한 금요일 밤에 문제가 발생한 후가 아니라 서명하기 전에 이 두 가지에 대해 문의하세요.
JSON을 보여주세요
공급업체 페이지는 실제 형태를 한 번도 보여주지 않고 "구조화된 출력"에 대해 이야기합니다. 다음은 공급업체 송장이 반환되어야 하는 형태이며, 모든 공급업체가 맞춰야 할 가치가 있는 형태입니다:
{
"document_type": "invoice",
"supplier": { "name": "", "tax_id": "", "supplier_id": "" },
"invoice": {
"invoice_number": "",
"invoice_date": "",
"due_date": "",
"currency": "",
"po_number": ""
},
"amounts": { "subtotal": 0, "tax": 0, "freight": 0, "total": 0 },
"line_items": [
{
"description": "",
"sku": "",
"quantity": 0,
"unit_price": 0,
"line_total": 0
}
],
"confidence": { "invoice_number": 0.98, "total": 0.99, "line_items": 0.91 }
}
이 중 두 가지가 대부분의 역할을 수행합니다. line_items는 텍스트 덩어리가 아니라 배열(array)이며, 이를 통해 2방향(two-way) 및 3방향(three-way) 매칭이 가능해집니다. confidence는 필드 단위로 제공되며, 사람이 확인해야 할지 여부를 자동으로 결정할 수 있게 해줍니다.
데모를 믿지 않고 문서 추출 API를 선택하는 방법

모든 공급업체는 자체 데모에서 성공합니다. 모든 공급업체가 거기에 포함될 문서를 골랐기 때문입니다. 프로덕션 환경을 예측하는 유일한 평가는 여러분의 문서로 실행하는 평가뿐입니다.
1. 누구와 이야기하기 전에 테스트 세트 구축하기
지난 3개월 동안의 실제 문서 200~500개를 수신함의 실제 비율에 맞게 가중치를 두어 추출합니다:
- ~70% 일반적인 공급업체 형식
- ~20% 분기에 한 번 보는 롱테일 공급업체
- ~10% 오류를 일으키는 문서: 상태가 나쁜 스캔본, 손글씨 메모, 다중 페이지 테이블, 크레딧, 외화, 하나의 송장에 두 개의 PO가 있는 경우
모든 후보에게 동일한 세트를 실행하세요. 절대로 공급업체가 샘플을 선택하게 두지 마세요.
2. 문서가 아닌 필드에 점수 매기기
문서 단위의 정확도는 비용을 발생시키는 오류를 숨깁니다. 각 필드를 개별적으로 채점하고 실수가 얼마나 큰 피해를 주는지에 따라 가중치를 두세요:
| 필드 | 중요한 이유 |
|---|---|
| 송장 번호, 공급업체 ID | 이들이 없으면 중복 감지 및 매칭이 실패합니다. |
| 총액, 세금, 통화 | 이 부분이 틀리면 결제가 잘못됩니다. |
| PO 번호 | 2방향 및 3방향 매칭을 위한 기준점입니다. |
| 품목 수량 및 단가 | 대부분의 엔진이 실제로 실패하는 부분입니다. |
| 날짜 | 고치기는 쉽지만 놓치면 비용이 많이 듭니다. |
3. 추적해야 할 수치는 STP (Straight-Through Processing)
도착부터 포스팅까지 사람의 개입 없이 처리되는 문서 수를 세어 보세요. 한 달에 5,000개의 문서일 때, 90%와 96% STP 사이의 격차는 누군가가 직접 열어봐야 할 300개의 문서입니다. 이것은 단순한 지표가 아니라 직무 설명서입니다.
4. 품목은 오류가 발생하는 곳입니다
헤더 필드는 쉽습니다. 최종 후보에 오른 모든 엔진은 송장 번호를 찾을 것입니다. 단일 수치를 믿기 전에 다중 페이지 테이블, 반복되는 헤더, 줄 바꿈 된 설명, 운임 및 할인 행, 품목별 세금, 마이너스 크레딧 및 혼합 단위를 테스트해 보세요.
5. 예외 처리는 누가 하는지 물어보세요
파일 크기 제한, 비동기 처리, 웹훅 재시도, 멱등성, 속도 제한(rate limits), SDK 커버리지 및 신뢰도가 낮은 필드는 어떻게 되는지 확인하세요. 그런 다음 누가 예외를 검토하는지 물어보세요. 대답이 "당사 엔지니어가, 직접 구축한 도구에서"라면, 데이터시트에 적힌 가격이 실제 가격이 아닙니다. 이 목록에 대한 Parseur 자체의 수치는 API 문서에 있으며, 마지막 질문에 대한 대답은 여러분의 스프린트가 아니라 제공되는 웹 앱입니다.
문서 추출 API의 실제 비용
가격 책정 구조는 마케팅에서 제안하는 것보다 더 다양하며 구조 자체가 요금률보다 더 중요합니다.
- 페이지당: 짧은 문서에서는 가장 저렴하지만 긴 문서에서는 매우 비쌉니다. 40페이지짜리 계약서는 동일한 단일 필드 세트를 추출하는 1페이지짜리 영수증의 40배 비용이 듭니다.
- 문서당: 파일당 예측이 가능하지만, 맞춤형 모델, 필기 인식 또는 쿼리 기반 추출과 같은 프리미엄 기능은 종종 추가 요금이 청구됩니다.
- 볼륨에 따른 구독: 문서 허용량에 대한 월 정액 요금으로, 페이지 수는 상관없습니다.
Parseur는 세 번째 방식을 사용합니다. 긴 PDF와 짧은 이메일은 비용이 동일하므로, 문서 구성이 일정하지 않아도 요금을 예측 가능하게 유지합니다. 현재 등급은 요금제 페이지에 있습니다.
아무도 언급하지 않는 비용은 API를 둘러싼 엔지니어링 비용입니다: 후처리 로직, 검토 인터페이스, 재시도 처리, 추출 변형에 대한 모니터링. 이 비용은 보통 API 비용보다 크며, Parseur의 웹 앱이 삭제하기 위해 존재하는 부분이기도 합니다.
Parseur API를 사용하여 PDF를 JSON으로 파싱하기

업로드부터 웹훅까지, 전체 PDF 추출 API 경로의 5단계입니다.
기본 URL: https://api.parseur.com/
1. 인증
Parseur 계정의 API 섹션에서 API 키를 찾고 모든 요청의 Authorization 헤더에 전송하세요:
Authorization: <YOUR_API_KEY>
자세한 내용은 인증 가이드에 있습니다.
2. 메일박스 찾기 또는 생성하기
메일박스는 문서를 보관하고 추출하려는 필드를 담는 컨테이너입니다. 앱에서 생성한 다음 메일박스 목록을 조회하여 ID를 얻으세요:
curl -X GET "https://api.parseur.com/parser" \
-H "Authorization: <YOUR_API_KEY>" \
--compressed
메일박스 ID는 앱의 메일박스 URL에도 표시되며, create-mailbox 응답의 id 필드에도 표시됩니다.
3. 문서 업로드
cURL:
curl -X POST "https://api.parseur.com/parser/<MAILBOX_ID>/upload" \
-H "Authorization: <YOUR_API_KEY>" \
-F "file=@./invoice.pdf" \
--compressed
Python:
import requests
url = "https://api.parseur.com/parser/<MAILBOX_ID>/upload"
headers = {"Authorization": "<YOUR_API_KEY>"}
files = {"file": open("invoice.pdf", "rb")}
response = requests.post(url, headers=headers, files=files)
print(response.json())
Node.js:
import fetch from "node-fetch"
import fs from "fs"
const url = "https://api.parseur.com/parser/<MAILBOX_ID>/upload"
const headers = { Authorization: "<YOUR_API_KEY>" }
const formData = new FormData()
formData.append("file", fs.createReadStream("./invoice.pdf"))
const response = await fetch(url, { method: "POST", headers, body: formData })
console.log(await response.json())
문서는 업로드 대신 이메일 전달을 통해서도 도착할 수 있습니다. 두 경로 모두 이메일 및 문서 업로드를 참조하세요.
4. 데이터 돌려받기
메일박스에 웹훅을 구성하면 처리가 완료되는 순간 파싱된 JSON이 엔드포인트에 도착합니다. 프로덕션 환경에서는 이것이 올바른 기본값입니다: 폴링 없음, cron 없음, 확인 사이에 손실되는 문서 없음.
웹훅을 사용할 수 없는 경우의 대안:
- 자동화 플랫폼: Zapier, Make, n8n 또는 Power Automate.
- 폴링: 파싱된 JSON을 위한
GET /document/{id}. - 내보내기: 메일박스에서 CSV, JSON 또는 Excel 다운로드.
5. 검증 및 튜닝
Parseur 대시보드는 문서와 웹훅 로그를 보여주어 무엇이 추출되고 무엇이 전송되었는지 정확히 볼 수 있게 해줍니다. 필드가 잘못되어 돌아오면 코드베이스에서 패치하는 대신 이곳에서 수정하세요.
Parseur가 추출하는 것과 아직 추출할 수 없는 것
Parseur는 '소프트웨어가 읽기 전에 문서를 준비할 필요가 없어야 한다'는 하나의 아이디어를 중심으로 구축된 문서 추출 API입니다. 2016년부터 1억 개 이상의 문서를 처리해 왔습니다.
- 주요-값 쌍 및 폼: 이름, 주소, 총액, 송장 번호 및 참조 ID를 라벨 필드로 추출.
- 테이블 및 품목: 송장 품목, 은행 명세서 거래 내역, 선적 매니페스트 (여러 페이지에 걸쳐 있는 테이블 포함). 작동 방식은 AI 테이블 추출에서 다룹니다.
- 스캔 및 사진: 비전 AI 엔진은 디지털 PDF뿐만 아니라 스캔 및 촬영된 문서를 직접 읽습니다.
- 이메일 및 첨부 파일: Parseur의 전문 분야. 이메일 자체도 문서이며, 거기에 첨부된 모든 것도 문서입니다.
- 레이아웃 요소: 필요한 곳의 제목, 단락 및 선택 마크.
아직 어려운 부분: 밀집된 손글씨와 서명. 이러한 영역은 전체 카테고리에서 아직 해결되지 않았으며, 이를 가능하다고 주장하는 모든 벤더에게는 벤치마크를 요구해야 합니다.
대부분의 문서 추출 소프트웨어는 API에서 멈추고 나머지는 여러분에게 맡깁니다. Parseur는 양쪽을 모두 제공합니다: 개발자 측을 위한 API와, 티켓을 제출하거나 스프린트를 기다리지 않고도 운영 팀이 필드를 정의하고, 문서를 검토하며, 결과를 수정할 수 있는 웹 앱.
팀들이 Parseur를 사용하는 분야
- 매입 채무 (Accounts Payable) - 송장, 영수증, 구매 주문서를 구조화된 JSON으로 변환한 다음 ERP로 바로 전송.
- 금융 운영 (Financial Operations) - 은행 명세서 및 거래 보고서를 대조를 위해 CSV 또는 JSON으로 변환.
- 운영 및 물류 (Operations and Logistics) - 포장 명세서, 선하 증권, 배송 증명서.
- 이메일 자동화 - 메시지와 첨부 파일을 수집, 추출하고 웹훅으로 전송.
보안, GDPR 및 EU 데이터 레지던시
Parseur는 EU에 호스팅되어 있습니다: 고객 데이터는 유럽 연합 내에서 처리 및 저장되며, 호스팅 데이터 센터는 ISO 27001 인증을 받았습니다. 이는 데이터 레지던시 약속이며, 일반적인 GDPR 준수 배지보다 다르고 더 강력한 것입니다.
Parseur는 EU GDPR, UK GDPR, 캘리포니아 CCPA/CPRA 및 싱가포르 PDPA와 일치합니다. 고객 문서는 Parseur의 AI 모델을 학습하는 데 절대 재사용되지 않으며 판매되지도 않습니다. 보존 기간은 구성 가능하므로 설정한 기간에 문서를 자동으로 삭제할 수 있습니다. SOC 2 Type II 및 HIPAA 규정 준수 프로그램이 진행 중이며, 이는 현재 두 가지 모두 아직 인증되지 않았음을 의미합니다.
레지던시가 절대적인 요구 사항인 경우 추론(inference), 임시 캐시, 백업 및 문서 내용을 포함하는 로그 등 네 가지 특정 작업이 어디서 일어나는지 묻지 않고 "EU 호스팅"을 받아들이지 마세요. 미국 추론 엔드포인트 앞에 있는 EU 데이터베이스는 EU 데이터 레지던시가 아니며 흔하게 볼 수 있는 형태입니다. 모델 학습과 관련하여 동일한 테스트를 진행한 내용은 무학습 주장을 검증하는 12가지 질문을 참조하세요.
문서 추출 API와 LLM: 절대로 원본 PDF를 넘기지 마세요
언어 모델(LLM)은 추론에는 탁월하지만 PDF를 읽는 데는 신뢰할 수 없습니다. 스캔한 송장을 입력하면 페이지에 없는 총액을 뻔뻔하게 반환할 것입니다. 문서 추출 API는 기준 정보(ground truth)를 생성합니다. 모델은 그 위에서 작동합니다.
효과적인 역할 분담: API가 송장 번호, 날짜, 총액 및 품목을 신뢰도 점수와 함께 추출하면, 모델은 모델이 잘하는 일, 즉 "01/03/25"를 2025-03-01로 변환하고 문서 유형을 태그 지정하며 내부 분류 체계에 필드를 매핑하는 작업을 수행합니다. 스키마 검증은 이 두 가지 모두의 아래에 위치하며, 어느 쪽도 단독으로 발견하지 못하는 오류를 잡아냅니다.
AI 에이전트에게도 동일한 규율이 필요합니다. 에이전트는 제공받은 데이터만큼만 우수하며, 환각(hallucinated)으로 생성된 품목은 실제 결제가 따르는 실제 구매 주문서가 됩니다. 더 넓은 관점에서 볼 때, 이 페이지를 뒷받침하는 핵심 기사는 문서 추출 API에 대한 완전한 가이드입니다.
이제 벤더들을 테스트해 보세요
가장 좋은 문서 추출 API는 기능 목록이 가장 긴 것이 아니라, 가장 엉망인 10%의 문서에서 사람의 개입 없이 살아남는 API입니다. 테스트 세트를 구축하고, 오류 시 비용이 발생하는 필드를 채점하며, 반대쪽 끝에서 사람의 손을 거치지 않고 나오는 문서가 몇 개인지 세어보세요. 원하는 순서대로 저희를 상대로도 테스트해 보세요.
그 외의 다른 모든 것은 단순한 데이터시트에 불과합니다.
마지막 업데이트




