8건의 계약, 하나의 매출 보고서: 한 필드도 다시 입력하지 않고고객 청구서를 일괄 처리하는 방법

중견 컨설팅 회사가 8건의 활성 계약(월 정액제 2건, 시간제 3건, 고정 요금 마일스톤 2건, 혼합 요금제 1건)을 운영할 때, 매 청구 주기마다 약 20~30개의 고객 청구서 PDF가 생성됩니다. 각 PDF는 시간제는 Harvest, 정액제는 FreshBooks, 고정 요금 프로젝트는 맞춤형 Word 템플릿, 링크로 결제하는 혼합 요금 고객은 Stripe 영수증 등 서로 다른 도구로 만들어집니다. 월말이 되면 재무 담당자가 각 PDF를 열어 고객사, 프로젝트 코드, 청구 기간, 수수료 소계, 경비, 세금, 합계 등 10~14개 필드를 찾아 매출 스프레드시트에 다시 입력합니다. 청구서 25건을 각 4분씩 처리하면 거의 2시간이 걸리지만, 일괄 추출 작업은 2분도 안 걸립니다.

컨설팅 회사 고객 청구서가 계약별 내역과 함께 월간 매출 보고서 스프레드시트로 일괄 처리된 모습

핵심 요약

  1. 8개 계약의 25개 고객 송장을 필드별로 다시 입력하는 데 약 2시간이 걸리지만, 타이핑은 전체 과정에서 가장 저렴한 부분입니다.
  2. 개별 추출의 진짜 문제는 25개의 분리된 스프레드시트로 인해 계약 간 분석이 구조적으로 불가능해진다는 점입니다. 고객 집중도, 청구 모델별 마진, 컨설턴트 생산성 등은 누군가 수동으로 25개 파일을 병합하기 전까지는 파악할 수 없습니다.
  3. ImageToTable.ai로 한 번의 일괄 추출을 통해 25개의 PDF를 2분 안에 단일 스프레드시트로 변환할 수 있으며, 수동 병합에 몇 시간 걸리던 분석이 이제는 SUMIFS 수식 하나로 해결됩니다.

청구 주기가 만드는 배치 — 처리 여부와 관계없이

대부분의 산업에서 배치 처리는 선택 사항입니다. 일주일치 송장을 모아 한 번에 처리하는 것이 더 효율적이기 때문입니다. 컨설팅에서는 청구 주기가 자동으로 배치를 만듭니다. 1일, 15일, 또는 월말 마지막 영업일 중 언제 청구하든, 모든 고객 송장이 같은 마감일에 몰립니다. 배치는 당신이 만들기로 결정하는 것이 아니라, 달력이 강제로 처리하게 만드는 것입니다.

문제는 대부분의 컨설팅 회사가 이 자연스러운 배치를 개별 작업의 연속으로 처리한다는 점입니다: PDF 열기, 필드 읽기, Excel에 입력하기, PDF 닫기, 다음 PDF 열기. 25번의 반복. 송장당 접근 방식은 관리 가능해 보입니다 — 송장당 4분은 빠르게 느껴지지만, 숨은 비용은 마지막 PDF를 닫은 후에 발생합니다.

배치 문제는 "25개 송장을 입력하는 데 100분이 걸린다"는 것이 아닙니다. "25번의 개별 처리 주기가 25번의 불일치 기회를 만들고, 이후에 따르는 통합 및 검증 작업이 입력 자체보다 훨씬 더 많은 시간을 소모한다"는 것입니다.

컨설팅 회사가 배치 추출 데이터를 활용하는 수익 추적 시스템(고객 수익성, 청구 모델 경제성, 컨설턴트 생산성을 드러내는 차원 구조 포함)을 구축하는 방법에 대한 자세한 내용은 고객 송장 데이터를 프로젝트 수익 추적 스프레드시트로 추출하기 가이드를 참조하세요. 이 문서의 추출 워크플로는 차원 추적기가 사용할 원시 데이터 행을 생성합니다.

송장별 처리가 다중 계약 회사에서 망가뜨리는 것

인보이스를 하나씩 처리하는 방식이 유혹적인 이유는 점진적으로 느껴지기 때문입니다. 즉, 클라이언트 업무 사이의 틈새에 끼워 넣을 수 있다는 점입니다. 하지만 다중 계약 컨설팅 회사는 아무리 각각의 추출 속도가 빨라도 단일 인보이스 처리로는 해결되지 않는 세 가지 구조적 문제에 직면합니다.

25개의 개별 출력 파일. 각 인보이스를 개별적으로 처리하면 각각의 스프레드시트가 생성됩니다. 4가지 청구 모델에 걸쳐 8개의 계약을 운영하는 회사는 월말에 25개의 Excel 파일을 보유하게 되며, 각 파일은 동일한 열 이름과 다른 데이터를 가지고 있습니다. 누군가(보통 방금 2시간 동안 추출한 바로 그 사람)가 이제 각 파일을 열고 행을 복사하여 마스터 수익 추적기에 붙여넣습니다. 25개 파일의 경우 복사-붙여넣기-확인 주기에 30~45분이 더 소요됩니다. 그리고 붙여넣기 오류가 없다고 가정할 때의 이야기입니다. 한 열 왼쪽으로 이동된 행, 옆에 있는 아이콘과 똑같이 보여서 건너뛴 파일, 파일 17이 이미 붙여넣어졌는지 기억나지 않아 중복된 행 등이 발생할 수 있습니다.

인보이스별 열 불일치. 인보이스 하나씩 추출 열을 정의하면, 19번째 인보이스는 필연적으로 4번째와 약간 다른 열 집합을 갖게 됩니다. 데이터가 변경되었기 때문이 아니라, 90분 동안 화면을 본 후에는 "서비스 기간 시작일"과 "인보이스 날짜"의 차이가 더 이상 명확해 보이지 않기 때문입니다. 배치가 끝날 무렵에는 파일 간에 열이 일치하지 않으며, 통합 단계는 행 병합 작업 위에 열 매핑 작업이 추가됩니다. 혼합 청구 모델을 사용하는 다중 계약 회사는 특히 취약합니다. 시간제 인보이스에는 컨설턴트 이름과 청구 가능 시간이 자연스럽게 표시되지만, 정액 인보이스에는 그렇지 않습니다. 그리고 인보이스별 처리기는 종종 정액 파일에 해당 열을 포함하는 것을 잊어버려 통합 보기에 공백이 생깁니다.

교차 분석은 통합 전까지 보이지 않습니다. 개별 송장을 처리하면 모든 파일이 병합될 때까지 전체 그림을 볼 수 없습니다. 오후 4시에 작업을 마치고 마지막 행을 붙여넣은 후에야 혼합 요율 계약의 수익이 42,000달러이고 예상 제공 비용이 41,000달러임을 알게 됩니다. 이는 세 개의 개별 송장을 각각 볼 때는 드러나지 않았던 간신히 손익분기점을 넘는 마진입니다. 이를 발견했을 때는 파트너와의 월간 수익 통화가 30분 남았습니다.

개별 송장 처리가 실패하는 이유는 각 추출이 느리기 때문이 아닙니다. 그 뒤에 따르는 통합, 검증, 분석 단계(개별 송장을 처리할 때 자동화할 수 없는 단계)가 절약했다고 생각한 시간을 소모하기 때문입니다.

열을 한 번 정의하고 모든 계약에서 추출

대안은 워크플로를 역전시킵니다. 먼저 출력 스키마를 정의한 다음, 청구 모델이나 발행 플랫폼에 관계없이 모든 고객 송장을 단일 배치 추출에 입력합니다. 이를 가능하게 하는 메커니즘은 열 이름 추출입니다. 원하는 필드 이름을 열 머리글로 입력하면 AI가 각 문서에서 해당 값을 찾습니다. 값이 페이지의 어디에 위치하는지가 아니라 의미를 이해하기 때문입니다. FreshBooks PDF의 왼쪽 상단 주소 블록에 있는 고객 이름과 사용자 정의 Word 템플릿 상단에 굵게 중앙 정렬된 고객 이름은 모두 추출 엔진에게 "고객 이름"입니다. 위치는 중요하지 않습니다.

열 머리글을 한 번만 정의하세요. 여러 계약을 운영하는 컨설팅 회사의 경우 월간 수익 보고서의 최소 필수 세트는 다음과 같습니다.

  1. 고객명
  2. 프로젝트 코드
  3. 청구서 번호
  4. 청구일자
  5. 서비스 기간 (시작/종료)
  6. 과금 모델 (시간제 / 정액제 / 고정비 / 혼합)
  7. 수수료 소계
  8. 경비
  9. 세금
  10. 총 합계
  11. 결제 상태

그런 다음 PDF 25개를 한 번에 업로드하세요. 추출 엔진이 병렬로 처리하여 각 문서를 읽고 모든 열에 데이터를 채웁니다. 각 행이 하나의 고객 청구서를 나타내는 25개 행의 스프레드시트를 다운로드하며, 모든 행에 동일한 열이 적용됩니다. 통합 단계나 열 정렬이 필요 없습니다. "정액제 고객의 청구서 파일이 12번이었나 14번이었나?" 고민할 필요도 없습니다.

가장 다양한 청구서 형식(기계 생성 PDF부터 스캔본까지)을 처리하는 추출 메커니즘에 대한 자세한 내용은 모든 청구서 레이아웃에서 특정 필드 추출하기에 대한 설명을 참조하세요. 이 문서에서는 열 이름 추출이 다양한 문서 구조에서 의미를 읽어내는 방식을 다룹니다.

JPG/PNG/PDF AI 추출

파일은 안전하게 처리되며 저장되지 않습니다.

청구 모델 파편화: 송장마다 다른 의미의 절반 컬럼

컨설팅 송장을 일괄 처리할 때 가장 큰 문제는 모든 송장에 동일한 필드가 포함되지 않는다는 점입니다. 이는 모든 계약이 동일한 방식으로 청구되지 않기 때문입니다. Harvest의 시간 및 자재 송장에는 컨설턴트 이름, 청구 가능 시간, 시간당 요금이 표시됩니다. FreshBooks의 리테이너 송장에는 시간과 요금 없이 고정 월 사용료만 표시됩니다. 맞춤 Word 템플릿의 고정 요금 마일스톤 송장에는 계약 금액의 백분율과 인도물 설명이 표시되며, 역시 시간과 요금은 없습니다.

청구 모델에만 의미 있는 열을 정의하면, 해당 모델을 사용하지 않는 모든 인보이스에 대해 일괄 추출 시 빈 셀이 생성됩니다. 이는 오류가 아니라 정직한 기록입니다. 12,000달러 리테이너 인보이스에 '청구 가능 시간' 열이 비어 있는 것은 해당 리테이너가 시간 단위로 책정되지 않았음을 정확히 반영합니다. 대안인 열 자체를 생략하면 수익 보고서에서 청구 모델 간 마진을 비교하는 기능이 사라지며, 이는 여러 프로젝트를 운영하는 회사에 가장 중요한 분석입니다.

필요한 모든 필드의 합집합을 정의하되, 교집합은 정의하지 마십시오. 네 가지 청구 모델에 걸쳐 8개 프로젝트에 대한 일괄 추출 수익 보고서에는 다음과 같은 교차 모델 열이 필요합니다.

기재 대상미기재 대상
청구 가능 시간시간제, 혼합형정액제, 고정 요금제 — 올바름, 해당 모델은 인보이스별 시간을 추적하지 않음
시간당 요금시간제, 혼합형정액제, 고정 요금제 — 요금은 계약에 명시되며 인보이스에는 별도 표기되지 않음
컨설턴트 이름시간제, 혼합형 (상이)정액제 — 관계는 회사 대 고객이며, 인보이스에 개인 이름이 기재되지 않음
경비 (전가 비용)전 모델 — 해당 시상환 비용이 없는 인보이스 — 올바름, 해당 비용이 없음
수수료 소계 (세전, 경비 제외)전 모델해당 없음 — 모든 인보이스에는 수수료 항목이 포함됨 (총액에 포함되어 있더라도)

일괄 추출된 수익 보고서의 빈 셀은 추출 실패가 아닙니다. 이는 청구 모델 차이로 인한 구조적 결과이며, 모든 인보이스를 수수료 수익과 통과 비용이 혼합된 단일 "합계" 열로 축소하는 것보다 덜 오해의 소지가 있습니다.

수수료 수익 분리: 인보이스 도구가 절대 출력하지 않는 열이 수익 보고서에 필요한 이유

컨설팅 수익 보고에서 가장 흔한 분석 오류는 인보이스의 총액을 수익으로 간주하는 것입니다. 85,000달러 인보이스가 컨설팅 수수료 55,000달러와 여행비, 하청업체 비용, 소프트웨어 라이선스 비용 등 상환 가능 비용 30,000달러로 구성된 경우, 수익은 85,000달러가 아닌 55,000달러입니다. 이 차이가 중요한 이유는, 회사가 월 수익 85,000달러를 보고하고 전달 비용으로 58,000달러를 예산 책정하면 32% 마진을 올린다고 생각하지만, 실제 수수료 구성 요소의 마진은 5%에 불과하기 때문입니다.

인보이스 도구는 이 문제를 해결해 주지 않습니다. FreshBooks, QuickBooks, Harvest, Xero 모두 수수료 수익과 경유 비용을 페이지 하단 하나의 숫자로 합산한 PDF를 생성합니다. 분리는 인보이스 플랫폼이 아닌 수익 추적기에서 이루어집니다.

일괄 추출은 계산된 열로 이를 처리합니다. 이 열은 문서에서 값을 추출할 뿐만 아니라 추출 중에 값을 계산합니다. 깔끔한 수수료 수익 수치가 필요한 수익 보고서의 경우 다음을 정의합니다.

  • 수익 수수료 = 수수료 소계(송장에 있는 경우) 또는 총액 − 경비 통과 − 세금
  • 예상 마진 = 수익 수수료 − (청구 가능 시간 × 부하 시간당 비용) — 실제 수익을 창출하는 업무를 파악할 수 있는 방향성 마진 지표

AI가 각 송장을 읽고 수수료 구성 요소와 경비 통과 금액을 식별한 후 페이지의 실제 숫자를 기준으로 송장별로 계산을 수행합니다. 다운로드된 스프레드시트에는 Fee Revenue 열이 있으며, 모든 행은 상환 가능 비용을 제외한 컨설팅 수익을 반영하고, 수수료 소계 필드가 없는 송장을 가진 Stripe 수령 클라이언트의 행도 올바른 파생 숫자를 생성합니다.

계산된 열이 다양한 문서 유형에서 조건부 논리 및 고정 매개변수 참조를 포함한 다단계 계산을 처리하는 방법에 대한 자세한 설명은 문서 추출의 계산된 열 소개를 참조하세요.

배치 출력에서 월간 수익 보고서로

배치 추출 후 다운로드하는 스프레드시트는 최종 결과물이 아닙니다. 이는 원시 데이터 계층입니다. 25개 행을 관리 파트너가 실행할 수 있는 수익 보고서로 전환하려면 배치 출력이 가능하게 하고 송장별 처리가 비실용적으로 만드는 세 가지 분석 단계가 필요합니다.

첫 번째 단계: 클라이언트별 수익. 각 클라이언트의 모든 송장에 대해 SUMIFS(FeeRevenue, ClientName, "Acme Corp")를 적용합니다. 이는 청구 플랫폼이 이미 제공하는 최상위 숫자를 표면화하지만, 플랫폼이 제공하지 않는 클라이언트 집중 위험도 드러냅니다. 두 클라이언트가 수수료 수익의 63%를 차지한다면, 회사의 재정적 안정성은 두 관계의 건전성에 달려 있습니다. 배치 출력은 모든 송장이 하나의 스프레드시트에 있기 때문에 하나의 수식으로 이를 확인할 수 있게 합니다.

2차: 청구 모델별 수익 분석. SUMIFS(FeeRevenue, BillingModel, "Hourly")SUMIFS(FeeRevenue, BillingModel, "Retainer"). 수수료 수익의 70%를 리테이너에서 창출하는 회사는 현금 흐름이 예측 가능하지만, 고객 수요가 정액 요금을 초과할 경우 마진이 낮아져 가격을 낮게 책정하고 있을 수 있습니다. 반면, 수익의 70%를 시간제 청구에서 얻는 회사는 현금 흐름이 변동적이지만 구조적으로 마진을 보호합니다. 일괄 출력은 청구 모델 열이 청구 구조를 데이터 필드로 포착하기 때문에 이러한 비교를 가능하게 합니다. 이는 재무 관리자의 머릿속에만 있는 메모가 아닙니다.

3차: 컨설턴트당 수익 생산성. SUMIFS(FeeRevenue, Consultant, "Sarah Chen") / COUNT(Months). 연간 수수료 수익 280,000달러에 연봉 110,000달러를 부담하는 컨설턴트의 생산성은 2.54배로, 건전한 전문 서비스 회사가 목표로 하는 3배 기준에 미치지 못합니다. 일괄 출력은 컨설턴트 이름, 수수료 수익, 송장 날짜가 동일한 테이블의 구조화된 열로 존재하기 때문에 이 계산을 가능하게 합니다. 송장별 접근 방식은 이 데이터를 25개 파일로 분산시켜 파일 간 집계를 수동 작업으로 만듭니다.

분석수식송장별 처리 시 놓치는 부분
고객 수익=SUMIFS(FeeRevenue, ClientName, "Client A")25개 파일에 걸친 단일 고객 합계는 수동 합산이 필요해 대규모에서 오류 발생 가능
청구 모델 구성=SUMIFS(FeeRevenue, BillingModel, "Hourly") / SUM(FeeRevenue)데이터가 분산되면 청구 모델 비율이 보이지 않음; 통합 후에야 패턴이 드러남
컨설턴트 생산성=SUMIFS(FeeRevenue, Consultant, "Name") / MONTHS_BETWEEN(First, Last)여러 프로젝트에 걸친 컨설턴트 시간과 수익의 파일 간 집계는 송장별 처리가 강제하는 수동 작업 그 자체
고객 집중도=LARGE(ClientRevenue, 1) / SUM(FeeRevenue)집중 리스크는 고객 간 패턴 — 각 송장을 개별 처리할 때는 보이지 않음

이러한 각 분석은 일괄 추출된 스프레드시트의 단일 수식입니다. 각각은 송장을 개별적으로 처리할 때 20분이 소요되는 수동 작업입니다. 이 20분 작업의 합계에 컨설팅 회사가 매월 필요로 하는 보고서 수를 곱하면, 송장당 처리 비용이 절약되는 것처럼 보이는 타이핑 시간보다 훨씬 더 많이 드는 이유입니다.

월간 리듬 설정: 일괄 작업을 습관화하기

일괄 작업은 25개의 송장을 처리하는 데 약 15분의 인간의 주의가 필요합니다. PDF를 모으는 데 5분, 열을 정의하거나 지난달의 저장된 사전 설정을 사용하는 데 2분, 출력의 정확성을 확인하는 데 8분이 소요됩니다. 매월 이 작업을 수행하면 열 스키마가 저장되고, 파일 명명 규칙이 설정되며, 출력이 이미 수식이 작성된 마스터 수익 추적기에 직접 공급됩니다.

월간 리듬은 건별 처리의 가장 큰 숨은 비용인 맥락 전환 세금을 방지합니다. 고객 미팅 사이에 개별 송장을 처리할 때마다 정신적 맥락을 다시 불러와야 합니다. 이 고객은 누구인지, 어떤 계약인지, 어떤 청구 모델인지, 어떤 열 세트인지. 한 주기에 한 번 일괄 처리하면 정신적 맥락은 한 번 로드된 후 유지됩니다. 인지되는 노력의 차이는 25번의 중단과 한 번의 집중 세션 사이의 차이입니다.

발생주의 회계가 요구되는 수익 임계값(IRS 기준 C법인 500만 달러)에 근접한 컨설팅 회사의 경우, 일괄 워크플로는 건별 처리로는 해결할 수 없는 규정 준수 문제를 해결합니다: 기간별 수익 인식. 발생주의 규칙에 따라 수익은 현금이 도착할 때가 아니라 발생했을 때 기록됩니다. 1월 1일에 분기별 자문 서비스에 대해 청구된 리테이너는 1월에 하나의 PDF를 생성하지만, 수익 인식은 1월, 2월, 3월에 걸쳐 분할됩니다. 일괄 출력의 서비스 기간 시작/종료 열은 이 분할을 세 개의 개별 송장 파일에 분산되는 수동 할당 작업이 아닌 공식으로 만듭니다.

자주 묻는 질문

일부 고객에게는 QuickBooks에서, 다른 고객에게는 Harvest에서 송장을 발행합니다. 일괄 처리가 다른 플랫폼의 송장을 처리할 수 있나요?

네. 추출은 각 PDF의 텍스트가 무엇을 의미하는지 읽으며, 텍스트가 어디에 위치해 있는지나 어떤 플랫폼에서 생성되었는지는 읽지 않습니다. QuickBooks 송장의 "고객 이름" 필드는 Harvest 송장의 "고객 이름" 필드와 다른 위치에 나타나지만, AI는 위치가 아닌 의미적으로 읽기 때문에 둘 다 고객 이름임을 이해합니다. 동일한 배치에 두 파일 유형을 모두 업로드하면 출력이 동일하게 채워집니다.

특정 형식의 송장을 요구하는 고객(예: 필수 필드가 있는 정부 기관)은 어떻게 처리하나요?

만약 법정 양식에 표준 컨설팅 인보이스에 없는 추가 필드(계약 번호, 구매 주문 참조 번호, 비용 코드 내역)가 포함되어 있다면, 배치 스키마에 해당 열을 추가하세요. 추출 엔진은 해당 필드가 있을 때 채우고, 없을 때는 비워둡니다. 배치는 청구 모델이 다른 경우와 마찬가지로 인보이스 간 필드 적용 범위가 불균일한 경우에도 동일하게 처리합니다. 빈 셀은 추출 실패가 아닌 문서의 현실을 반영합니다.

배치 워크플로우는 스캔본, 사진, 팩스 PDF 등 이미지 기반 인보이스에도 작동하나요?

네. 기본 AI는 스캔 문서와 이미지 파일을 기계 생성 PDF와 비슷한 정확도(인쇄 텍스트 기준 최대 99%)로 읽습니다. 고압축 JPEG, 팩스 품질 스캔, 배경 잡음이 있는 문서는 정확도가 낮아지지만 대부분의 필드에서 수동 입력 단계를 없앱니다. 실질적인 기준은 다음과 같습니다. 사람이 인보이스를 읽을 수 있다면 추출도 읽을 수 있습니다. 스캔본을 사람이 읽을 수 없을 정도라면 오류가 발생할 것으로 예상하세요. 사람이 다시 입력하려고 할 때와 마찬가지입니다.

해외 고객을 위한 다중 통화 인보이스는 어떻게 처리하나요?

원래 통화의 금액을 "총액(EUR)"이라는 하나의 열로 추출한 다음, 인보이스 날짜 또는 결제 날짜의 환율을 사용하여 USD로 변환하는 계산 열을 추가하세요. 분기별 또는 연간 수익 보고의 경우, IRS는 재무부의 분기 평균 환율 또는 OANDA나 XE.com의 일일 환율을 허용합니다. 이중 열 접근 방식은 단일 통화 회계 소프트웨어가 종종 하나의 변환된 숫자로 축소하여 원래 인보이스와의 조정을 어렵게 만드는 감사 추적을 보존합니다.

저희 회사는 8건 이상의 계약을 처리하고 있습니다. 배치 워크플로우가 15건, 20건 또는 그 이상으로 확장되나요?

추출 시간은 송장 개수가 아닌 전체 페이지 수에 비례합니다. 1페이지짜리 송장 25개를 처리하는 시간과 50개를 처리하는 시간은 거의 동일합니다. 차이는 선형적인 인력 증가가 아닌 미미한 연산 차이일 뿐입니다. 사람이 확인하는 단계는 송장 개수에 따라 증가합니다. 50개 중 10개를 샘플링하는 것이 25개 중 5개를 샘플링하는 것보다 오래 걸리지만, 배치가 커질수록 확인 시간 대비 추출량 비율은 줄어듭니다. 배치 워크플로는 규모가 커질수록 비효율적이지 않고 오히려 더 효율적입니다.

추출에서 인텔리전스로

배치 추출된 수익 보고서는 컨설팅 회사가 스스로에게 던질 수 있는 질문을 바꿉니다. 송장별 처리는 "이번 달에 충분히 청구했는가?"라는 질문에 답합니다. 이는 청구 도구가 이미 답하는 질문입니다. 모든 계약이 하나의 스프레드시트에 담긴 배치 추출 보고서는 "어떤 고객, 청구 모델, 컨설턴트가 우리 마진을 창출했는가?"라는 질문에 답합니다. 이 질문에는 송장 간, 계약 간 데이터가 필요합니다. 바로 송장별 처리가 조각내고 배치 처리가 통합하는 데이터 구조입니다.

배치는 추출을 더 빠르게 만들지 않습니다. 분석을 가능하게 만듭니다.

📮 contact email: [email protected]