지급 장부는 그대로.
데이터 입력 단계에 추출 기능만 더하세요.
Venmo, PayPal, Zelle, Cash App을 사용하는 대부분의 소상공인은 이미 잘 작동하는 지급 스프레드시트를 가지고 있습니다. 열에는 레이블이 붙어 있고, SUM 수식은 월별로 합계를 정확히 계산하며, 조건부 서식은 연체된 청구서를 강조 표시합니다. 이 모든 것은 문제가 없습니다. 문제는 — 매주 2~3시간을 소모하게 만드는 — 단 한 단계입니다. 네 가지 앱에서 각각의 결제 확인 스크린샷을 열고, 금액, 날짜, 송금인을 다음 빈 행에 다시 입력하는 작업입니다. 스프레드시트를 다시 만들 필요는 없습니다. 데이터 입력 단계만 바꾸면 됩니다.
핵심 요약
- 매주 2~3시간이 아무도 보지 않는 단계에 사라집니다. 네 개의 다른 앱에서 결제 스크린샷을 열고, 이미 화면에 있는 내용을 다시 입력하는 작업입니다.
- 결제당 30초의 습관이 실제로 연간 1,260달러의 비용을 초래합니다. 숫자를 하나 잘못 입력하면 앱과 은행 명세서를 뒤지는 데 20분이 더 추가됩니다.
- 수동 입력을 ImageToTable.ai 사이드바 추출로 바꾸는 것만으로 스프레드시트의 다른 모든 것은 그대로입니다. SUM 수식은 여전히 합계를 내고, 피벗 테이블은 여전히 결제 수단별로 그룹화하며, 조건부 서식은 "입금됨" 행을 여전히 초록색으로 표시합니다.
이미 잘 작동하는 스프레드시트
프리랜서 디자인, 과외, 개인 트레이닝, 수리 서비스, 조경 등 소규모 서비스 업종을 운영한다면, 아마 직접 결제 추적 시스템을 만들어 사용하고 있을 겁니다. 구글 시트에 날짜, 고객명, 금액, 결제 수단, 그리고 메모 칸이 있는 표를 만들어 쓰고 있죠. 월별로 시트를 나누거나, 결제 수단별로 그룹화한 피벗 테이블이 있는 단일 원장을 사용할 수도 있습니다. 일요일 오후에 설정해두고 2년 동안 꽤 잘 써왔을 겁니다.
이 스프레드시트는 교체해야 할 문제가 아닙니다. 이미 내 수입에 대한 사고방식과 일치하는 작동 중인 시스템입니다. 금액 열 맨 아래의 SUM은 이번 달 수입을 알려주고, '대기 중' 결제를 위해 설정한 FILTER 보기는 후속 문자를 보내기 전에 확인하는 도구입니다. 이러한 구조는 어떤 정보가 중요하고 어떻게 정리할지에 대한 여러분의 결정을 반영합니다. 이를 다른 사람의 템플릿으로 대체한다면 그 모든 결정을 잃게 되고, 시간도 없는 상태에서 새로운 것을 배워야 합니다.
마찰은 정확히 한 곳에 있습니다: 새 결제 기록을 시트에 입력하는 과정입니다. 고객이 Venmo로 결제하면 확인 화면을 캡처합니다. 저녁에 스프레드시트를 열고 맨 아래로 스크롤한 다음 날짜, 금액, 고객명, 결제 수단을 입력합니다. 아침에 받은 PayPal 결제도 똑같이 하고, 어제 받은 Zelle 결제도, 거의 잊을 뻔한 Cash App 결제도 마찬가지입니다. 입력 하나에 30초 정도 걸립니다. 50번 입력하면 2시간 30분을 돈을 벌거나 쉬는 데 쓰지 못한 셈입니다.
스프레드시트가 병목이 아닙니다. 병목은 스크린샷과 셀 사이의 단계입니다. 그리고 그 단계는 생각보다 좁습니다.
여전히 수동인 한 단계
결제 스크린샷에서 스프레드시트 셀로 복사-붙여넣기하는 작업은 겉보기엔 간단해 보입니다. 그래서 대부분의 소상공인들이 대안을 찾기 전까지 수개월, 심지어 수년간 이 방식을 참고 견딥니다. 건당 30초라는 사소한 마찰처럼 느껴지고, 사소한 마찰은 쉽게 합리화되기 마련입니다. 하지만 그 수학은 조용히 누적됩니다.
월 50건의 결제를 3~4개 앱에서 처리하는 사업체는 단순 데이터 입력에만 대략 2~3시간을 소비합니다. 검토나 조정이 아니라, 화면에서 숫자를 읽고 셀에 입력하는 작업만으로 말이죠. 1년이면 24~36시간입니다. 보수적인 시간당 35달러로 계산하면, 이 '사소한 마찰'의 연간 비용은 840~1,260달러에 달합니다. 게다가 잘못 입력된 금액(452달러 대신 425달러)으로 인해 여러 앱과 은행 명세서를 뒤져 추가로 20분을 소비해야 하는 오류 수정 시간은 아직 포함되지 않았습니다.
다중 앱 정산 문제에 대한 분석에서 자세히 설명했듯이, 근본 원인은 사용자 실수나 규율 부족이 아닙니다. 구조적인 문제입니다. P2P 결제 앱은 자금을 이동시키기 위해 만들어졌지, 회계 기록을 생성하기 위해 만들어진 것이 아닙니다. 이 앱들의 확인 화면은 존재하는 유일한 완전한 거래 기록이며, 이미지 파일 안에 갇혀 있습니다. 데이터는 눈에 보이지만, 사람이 다시 입력하기 전까지는 어떤 소프트웨어도 접근할 수 없습니다.
바로 이런 유형의 문제에서 AI 추출이 판도를 바꿉니다. 전체 정산 프로세스(수수료, 결제 시점, 부분 결제는 여전히 사람의 판단이 필요함)를 자동화하는 것이 아니라, 처음부터 수동으로 처리되어서는 안 됐던 부분, 즉 이미 화면에 존재하는 숫자를 읽어서 다른 곳에 복사하는 작업을 제거하는 것입니다.
기존 워크플로우에 추출 기능 통합하기
삽입 지점이 좁습니다. 스프레드시트, 회계 소프트웨어, 결제 앱을 대체하는 것이 아닙니다. "스크린샷이 존재함"과 "시트에 행이 나타남" 사이에 한 단계를 추가하는 것입니다. 그 단계는 Google Sheets 애드온을 통한 AI 기반 데이터 추출이며, 그 전후의 어떤 것도 건드리지 않고 수동 입력 단계를 대체합니다.
다음은 전후 워크플로입니다:
| 단계 | 변경 전 | 변경 후 |
|---|---|---|
| 1 | 고객이 Venmo/PayPal/Zelle/Cash App으로 결제 | 고객이 Venmo/PayPal/Zelle/Cash App으로 결제 (변경 없음) |
| 2 | 확인 화면 스크린샷 저장 | 확인 화면 스크린샷 저장 (변경 없음) |
| 3 | 스프레드시트 열기, 맨 아래로 스크롤, 수동 입력: 날짜, 금액, 결제자, 방법 | Sheets에서 사이드바 열기, 스크린샷 업로드, AI가 필드 추출, 추가 버튼 클릭 |
| 4 | 수식, 차트, 월별 요약 자동 업데이트 | 수식, 차트, 월별 요약 자동 업데이트 (변경 없음) |
변경되는 단계는 3단계뿐입니다. SUM 수식은 B열의 숫자가 사람이 입력했든 AI가 추출했든 알지 못하며 신경 쓰지 않습니다. Venmo, PayPal, Zelle 등 결제 수단별로 그룹화한 피벗 테이블도 동일하게 작동합니다. 셀 값을 읽을 뿐, 그 출처는 중요하지 않습니다. Status 열이 "입금됨"일 때 행을 초록색으로 바꾸는 조건부 서식 규칙도 깨지지 않습니다. 추출 단계가 기존 열 아래에 행을 추가하는 방식으로 수동 입력과 동일하게 시트에 데이터를 공급하기 때문에 하위 프로세스는 전혀 영향을 받지 않습니다.
이것이 워크플로 통합의 핵심 원칙입니다. 가능한 가장 좁은 삽입 지점을 찾아 그 부분만 변경하는 것입니다. 변경 범위가 넓을수록 마찰이 커집니다. 소규모 사업자에게 Google Sheets 원장을 버리고 QuickBooks Online을 도입하라고 말하는 것은 넓은 변경입니다. 새 로그인, 새 인터페이스, 새 사고방식, 새 월 비용이 따릅니다. 반면, 모든 것을 그대로 유지하고 입력 단계를 업로드 단계로 바꾸라고 말하는 것은 좁은 변경입니다. 이미 열려 있는 사이드바에 버튼 하나만 추가하면 됩니다.
Google Sheets 애드온은 이 삽입 지점을 최대한 얇게 만듭니다. 이미 스프레드시트 안에 있습니다. 사이드바는 같은 브라우저 탭의 오른쪽 가장자리에서 슬라이드되어 나옵니다. 다른 애플리케이션으로 전환하거나, 별도 대시보드에 로그인하거나, 파일을 내보내고 다시 가져올 필요가 없습니다. 스크린샷을 사이드바로 끌어다 놓고 열 매핑(날짜 → 날짜, 금액 → 금액, 지불인 → 고객)을 확인하면 추출된 데이터가 시트에 나타납니다. 애드온은 API 키로 실행되며 웹사이트 계정과 동기화되어 생성한 템플릿, 정의한 열 규칙, 사용량 제한이 모두 유지됩니다.
파일은 안전하게 처리되며 저장되지 않습니다.
추출 자체는 사용자 정의 열 추출을 사용합니다. Date, Amount, Payer, Method, Fee 등 원하는 열 헤더를 정의하면, AI가 업로드한 모든 스크린샷에서 해당 값을 찾아냅니다. 어떤 결제 앱에서 생성되었든 상관없습니다. Venmo 확인 화면은 PayPal 거래 내역 페이지와 전혀 다르게 생겼습니다. 은행 앱 내 Zelle의 레이아웃은 Cash App의 거래 내역 화면과 다릅니다. 하지만 AI는 각 스크린샷을 읽을 때 템플릿에 픽셀을 매칭하는 것이 아니라, 금액이 어떻게 생겼는지, 날짜 형식이 어떤지, 이름이 어떻게 보이는지 이해합니다. 열 이름을 한 번만 정의하면 됩니다. AI는 모든 앱의 모든 스크린샷에서 값을 매핑하여 일관된 행 집합을 만듭니다.
처음부터 파이프라인을 설정하는 방법에 대한 자세한 가이드는 스크린샷 데이터를 Google Sheets로 직접 보내기에 대한 설명을 참조하세요. 이 글은 다른 점에 초점을 맞춥니다: 이미 구축한 스프레드시트에 해당 파이프라인을 다시 만들 필요 없이 통합하는 방법입니다.
수집 레이어 추가: 고객이 결제 스크린샷을 제출하도록 하기
지금까지 설명한 모든 것은 단일 사용자 워크플로우를 다룹니다: 스크린샷을 찍고, 업로드하고, 데이터를 얻습니다. 그러나 많은 소규모 비즈니스의 경우 스크린샷은 사용자로부터 시작되지 않습니다. 지불하는 사람으로부터 시작됩니다.
조경 고객이 문자 메시지로 은행 송금 확인 사진을 보냅니다. 과외 학생의 학부모가 Venmo 결제 스크린샷을 이메일로 보냅니다. 케이터링 고객이 Cash App 영수증을 전달합니다. 이러한 스크린샷은 메시지, 이메일, WhatsApp으로 도착합니다. 그리고 여러분이 중개자가 되어 이미지를 자신에게 전달하고, 폴더에 저장한 다음, 스프레드시트 워크플로우를 통해 하나씩 처리합니다. 추출 단계는 자동화되었습니다. 수집 단계는 그렇지 않습니다.
이것이 바로 컬렉션 링크 — 파일을 처리 대기열로 직접 전송하는 공유 가능한 업로드 페이지 — 가 대부분의 결제 추적 워크플로우에 없는 계층을 추가하는 이유입니다. 링크를 생성하고(/c/xxxx처럼 보입니다), 고객과 공유하면 고객이 자신의 브라우저에서 엽니다. 짧은 인증 코드를 입력하고 — 회원가입, 로그인, 앱 다운로드 없이 — 결제 스크린샷을 업로드합니다. 파일은 귀하가 직접 업로드한 스크린샷과 함께 계정의 처리 대기열에 나타납니다. 모든 것을 한 번에, 같은 스프레드시트에, 같은 열 매핑으로 추출합니다.
워크플로우가 이렇게 바뀝니다:
고객: 결제 → 스크린샷 → 이미지를 문자/이메일로 전송
귀하: 이미지를 폴더에 저장 → 스프레드시트 열기 → 사이드바 열기 → 이미지 업로드 → 추출 → 추가
이렇게 바뀝니다:
고객: 결제 → 스크린샷 → 컬렉션 링크 열기 → 코드 입력 → 업로드 → 완료
귀하: 스프레드시트 열기 → 사이드바 열기 → 대기 중인 모든 스크린샷 일괄 처리 → 추가
귀하는 수집 단계에서 완전히 제외됩니다. 자리에 있든 없든 스크린샷은 대기열에 쌓이며, 추출 단계는 귀하가 처리할 준비가 되었을 때 진행됩니다 — 매일, 매주, 또는 월말이 될 수도 있습니다. 동일한 패턴이 다른 문서 수집 워크플로에도 적용됩니다: 직원 경비 영수증 수집도 같은 원리로 작동합니다 — 링크를 보내고, 문서를 받고, 일괄 추출합니다.
Collection Link가 지불 추적에 특히 유용한 이유는 소규모 비즈니스가 지불 확인을 수령하는 구조적 격차를 해소하기 때문입니다. 고객이 Zelle로 결제하면 확인 화면은 고객의 휴대폰에만 존재합니다 — 송금 금액, 타임스탬프, 확인 번호가 표시됩니다. 귀하는 자금이 1-2 영업일 후에 은행 계좌에 도착할 때까지 해당 확인을 전혀 보지 못할 수 있으며, 그때도 은행 설명란에는 ZELLE PMT FROM J CONSULT 0605 REF# 8832714와 같은 문자열이 표시될 수 있습니다 — 이는 특정 송장과 일치하는지 확인하기 위해 사람이 직접 해석해야 하는 문자열입니다. Collection Link를 사용하면 고객이 결제하는 순간, 즉 해당 확인 화면이 아직 고객 화면에 남아 있을 때 제출할 수 있습니다. 귀하의 원장은 은행에 최종 반영되는 날이 아닌, 결제가 전송된 당일에 업데이트됩니다.
회계 소프트웨어를 대체하지 않고 연동하는 방법
재무 워크플로에 새 도구를 추가할 때 가장 흔한 반대 의견 중 하나는 "하지만 저는 이미 QuickBooks를 사용하고 있어요"입니다. 또는 Xero, Wave를 사용한다는 의견도 있습니다. 수동으로 동기화를 유지해야 하는 병렬 시스템을 원하는 사람은 아무도 없기 때문에 이는 타당한 우려입니다. 그러나 Google Sheets를 통한 추출은 병렬 시스템이 아닙니다. 이는 피드(feeder) 계층입니다.
일종의 전처리 단계라고 생각하면 됩니다. 결제 스크린샷이 도착하면(본인 또는 클라이언트가 수집 링크를 통해 보낸 것), AI가 이를 추출하여 Google Sheets 원장에 입력합니다. 일관된 열로 구성되며, 결제 수단별로 분류되고, 스크린샷에 보이는 수수료는 따로 분리됩니다. 이 원장은 모든 앱의 모든 결제를 한곳에 모아, 은행 이체가 정산될 때까지 기다리지 않고 거래가 발생할 때마다 업데이트되는 단일 진실 공급원입니다. 월말에는 시트를 CSV로 내보내 QuickBooks나 Xero로 가져옵니다. 또는 북키퍼와 시트를 직접 공유합니다. 아니면 은행 명세서와 대조하는 조정 참고 자료로 사용합니다.
가치는 Google Sheets가 회계 소프트웨어를 대체하는 데 있는 것이 아닙니다. Sheets가 결제 이벤트와 회계 입력 사이의 간극을 메우는 데 있습니다. P2P 앱의 경우 은행 피드가 이 간극을 커버할 수 없고, 개별 플랫폼의 CSV 내보내기는 일관성이 부족하여 연결하기 어렵습니다. 데이터가 회계 소프트웨어에 도달할 때쯤이면 이미 정리, 분류, 매칭이 완료되어 있습니다. 회계 소프트웨어는 재무제표 작성, 세금 부채 계산, 보고서 생성 등 본연의 역할에 집중합니다. 스크린샷을 읽도록 설계된 적이 없습니다. 그 부분은 상위 단계에서 처리됩니다.
고객 수금과 함께 공급업체 결제를 관리하는 비즈니스의 경우, 동일한 추출 계층이 양방향으로 작동합니다: 공급업체 송장도 동일한 애드온과 열 매핑 방식을 사용하여 AP 원장에 입력할 수 있습니다. 스프레드시트는 범용 수집 지점이 됩니다. 고객 결제가 들어오고, 공급업체 송장이 나가며, 회계 소프트웨어는 양방향에서 깨끗한 데이터셋을 받습니다.
볼륨이 증가하면 달라지는 점
위에서 설명한 단일 스크린샷 방식은 하루에 몇 건의 결제를 처리할 때 적합합니다. 일주일 치 또는 한 달 치를 일괄 처리할 때는 수동 입력보다 추출의 이점이 더 커집니다. 47개의 스크린샷을 하나씩 여는 대신 사이드바 업로드 대화상자에서 한 번에 모두 선택합니다. AI가 Venmo 확인, PayPal 거래 페이지, Zelle 은행 스크린샷 등 전체 세트를 처리하여 하나의 통합 테이블을 출력합니다. 행은 추출 순서대로 이미 정렬되어 있으며, 원하는 원장 순서에 맞게 구성할 수 있습니다.
일괄 조정에 대한 자세한 내용은 결제 스크린샷을 단일 원장으로 일괄 조정하는 방법을 참조하세요. 워크플로 통합의 핵심은 일괄 모드에 단일 스크린샷 추출을 위해 이미 구성한 설정 외에 추가 설정이 필요하지 않다는 점입니다. 동일한 열 매핑, 동일한 스프레드시트, 동일한 추가 위치입니다. 볼륨이 워크플로를 변경하지 않으며, 한 번에 업로드로 드래그하는 파일 수만 변경됩니다.
주간 스크린샷 수집
결제가 들어올 때마다 스크린샷을 찍으세요. 수집 링크를 사용하면 고객이 직접 제출하며, 스크린샷이 자동으로 대기열에 쌓입니다.
스프레드시트와 애드온 사이드바 열기
사이드바가 Google Sheets 내에서 열립니다. 수식, 차트, 피벗 테이블이 포함된 기존 원장은 메인 화면에 그대로 유지됩니다.
한 번에 업로드 및 추출
모든 스크린샷을 사이드바에 한 번에 드래그하세요. AI가 Venmo, PayPal, Zelle, Cash App을 처리하여 정의된 열에 맞춰 일관된 행을 출력합니다.
시트에 추가, 검토, 완료
추가를 클릭하면 기존 열 아래에 행이 추가됩니다. 수식은 자동으로 다시 계산되며, 피벗 테이블도 새로고침됩니다. 하위 데이터에는 영향이 없습니다.
여러 플랫폼에서 상당한 양의 결제를 처리하는 경우 전체 결제 스크린샷-Sheets 파이프라인 가이드에서 설정을 더 자세히 다룹니다. 또한 결제 워크플로에 Venmo, PayPal, Zelle 간 결제 추적이 포함된 경우 다중 플랫폼 결제 스크린샷 추적 가이드를 참조하세요.
자주 묻는 질문
변경하고 싶지 않은 특정 구조의 스프레드시트에서도 작동하나요?
네. 추출 시 정의한 열 순서대로 기존 시트의 맨 아래에 행이 추가됩니다. 날짜 열이 A, 금액이 C, 고객이 F라면 추출된 데이터는 해당 열만 채우고 나머지는 그대로 둡니다. 부가기능은 스프레드시트 구조를 변경하지 않고 행만 추가합니다. 수식, 조건부 서식, 보호된 범위, 데이터 유효성 검사 규칙 모두 그대로 유지됩니다. 스프레드시트는 직접 입력한 데이터와 AI가 추출한 데이터를 구분하지 못합니다.
AI가 총액에서 수수료를 별도로 추출할 수 있나요?
스크린샷에 수수료가 표시된 경우 — 예를 들어 PayPal 거래 내역 페이지에 총액과 수수료가 별도 항목으로 표시될 때 — AI가 이를 금액과 수수료 열로 각각 추출할 수 있습니다. 계산 열도 사용 가능합니다. 순액 (금액 − 수수료) 같은 열을 정의하면 AI가 추출 시 순액을 계산합니다. 모든 결제 스크린샷에 수수료가 표시되는 것은 아닙니다(Zelle은 비즈니스 수수료가 없고, Venmo 확인 화면에는 1.9% + $0.10 공제액이 항목별로 표시되지 않을 수 있음). 따라서 수수료 추적은 사용하는 플랫폼과 캡처하는 화면에 따라 달라집니다.
고객이 링크 사용을 원하지 않으면 이메일로 스크린샷을 보내도 되나요?
네. 수집 링크는 필수가 아닌 옵션입니다. 고객이 문자나 이메일로 결제 확인서를 보내는 것을 선호한다면, 해당 이미지를 저장한 후 부가기능 사이드바에서 직접 업로드할 수 있습니다. 추출 과정은 동일하며, 업로드 단계를 누가 수행하는지만 다릅니다. 수집 링크는 메시지에서 처리 폴더로 스크린샷을 전달하는 중간 단계를 없애고자 할 때 가장 유용합니다. 추출 과정에 대한 자세한 내용은 결제 스크린샷에서 데이터 추출하는 방법을 참조하세요.
부분 결제나 분할 결제도 처리할 수 있나요?
AI는 스크린샷에 보이는 값만 추출할 수 있습니다. 고객이 $500 청구서에 대해 $250의 부분 결제를 보내고 Venmo 메모에 "청구서 #1042 부분 결제"라고 적으면, AI는 금액 열에 $250을, 메모 열에 "청구서 #1042 부분 결제"를 추출합니다. AI가 할 수 없는 것 — 그리고 어떤 추출 도구도 할 수 없는 것 — 은 청구서 총액이 $500임을 알고 잔액을 계산하는 것입니다. 이를 위해서는 청구서 기록을 상호 참조해야 하며, 이는 스프레드시트에서 간단한 수식(=청구서총액−SUMIF)으로 처리하는 것이 가장 좋은 조정 작업입니다.
고객 이름과 금액이 포함된 결제 스크린샷을 업로드해도 안전한가요?
ImageToTable.ai는 암호화된 연결(HTTPS)을 통해 파일을 처리하고, 처리 후 업로드된 파일을 저장하지 않으며, 모델 학습에 데이터를 사용하지 않습니다. 보안 모델은 클라우드 회계 플랫폼에 은행 명세서를 업로드하는 것과 유사합니다. 데이터는 처리를 위해 전송된 후 폐기됩니다. 수집 링크에는 인증 코드가 포함되어 있어 링크와 코드를 모두 공유한 사람만 파일을 업로드할 수 있습니다. 민감한 재무 정보를 업로드하기 전에 제공업체의 데이터 처리 정책을 검토하세요.
회계사의 업무 흐름에 어떻게 맞춰 사용하나요?
대부분의 회계사는 월말에 구글 시트나 CSV 내보내기를 받는 것을 선호합니다. 현재 회계사가 결제 수단별 수입 스프레드시트를 보내달라고 요청한다면, 추출 워크플로는 정확히 그 형식으로 일관되게 정리된 데이터를 생성합니다. 모든 플랫폼의 모든 결제 내역이 한곳에 모입니다. 구글 시트를 직접 공유하거나(보기 전용), 엑셀 파일로 내보내거나, CSV로 다운로드할 수 있습니다. 회계사가 이미 수용하는 형식은 변하지 않으며, 보내는 데이터의 정확성과 완전성은 향상됩니다. 카메라 롤에서 데이터가 사라질 일이 없기 때문입니다.
결제 추적의 어려움은 스프레드시트가 아니라, 스크린샷을 보고 내용을 직접 입력하는 단계에 있었습니다. 이 단계는 대부분의 사업주가 생각하는 것보다 더 많은 시간을 소모합니다. 어려워서가 아니라, 매주, 모든 플랫폼의 모든 결제에 대해 반복되기 때문입니다. 이 단계를 없애기 위해 새로운 회계 시스템이나 워크플로, 혹은 자금 관리 방식을 바꿀 필요는 없습니다. 단 하나의 입력 지점에서 데이터 입력 방식을 다른 방식으로 교체하고, 나머지는 그대로 두면 됩니다.
신용카드 필요 없음. 파일은 안전하게 처리되며 저장되지 않습니다.