SAP 수출 가격 실현 다차원 분석 — 가격표에서 순매출까지, 할인과 리베이트가 어디서 새는지 계획과 견줘 본다

도입 포인트 — 이 앱을 사용해야 하는 이유

수출 담당자가 매달 받는 질문은 비슷합니다. 가격표대로 팔렸나, 어디서 얼마나 깎였나, 계획과 다른 이유가 무엇인가. 지금은 청구 문서 조회, 조건 레코드 조회, 리베이트 협약 조회, 그리고 엑셀로 세 답이 흩어져 있어 한 번 묻는 데 여러 화면을 오가야 합니다. 이 화면은 세 답을 한 화면에 붙여 순매출이 가격표에서 어떻게 줄어들었는지 차원별로 보여 줍니다.

모든 숫자는 가상의 샘플 값입니다. 청구 라인 3,480줄을 차원 조합 487칸의 큐브로 묶어 두고, 국가 · 고객 · 채널 · 가격 구분 · 인코텀즈 · 제품그룹 같은 11개 차원을 끌어다 놓으며 돌려 봅니다. 대상 영역은 수출 가격과 매출이며 특정 회계 기준서에 묶이지 않는 업무 분석 화면입니다.

핵심 포인트 여덟 가지

사례로 보는 효과

샘플 범위(2026년 1월~9월)에서 순매출은 계획 289억 7,800만 원보다 약 7억 원 적은 282억 7,800만 원이었습니다. 일곱 요인으로 가르면 가장 큰 몫은 물량(−8억 2,400만 원)입니다. 국가별로 보면 중국 −5억 2,400만 원이 대부분이며, 중국 고객 가운데 계획에만 있고 5월 이후 거래가 없는 OEM 거래처가 이 몫을 만듭니다. 한편 7월부터 거래가 시작된 베트남 신규 고객은 계획에 없던 매출 +2억 3,200만 원으로 잡혔습니다.

가격 쪽 이야기도 보입니다. 미국은 판촉 할인이 넓어져 즉시 할인 요인이 −4,200만 원이고, 일본은 가격표를 4.5퍼센트 올려 가격표 요인이 +1억 700만 원이지만 엔 약세로 환율 요인 −1억 6,200만 원이 이를 지웁니다. 중국은 리베이트가 계획을 넘어 −6,300만 원입니다. 청구 금액 합계만 보면 이 네 가지 이야기가 한 숫자 안에 섞여 보이지 않습니다. 일곱 요인의 합은 총차이 −6억 9,966만 원과 정확히 같았고, 대사 점검 2,958건에서 차이는 0건이었습니다.

도입하면 달라지는 것

• 월 마감 가격 점검이 표 한 장으로 끝납니다. 청구 문서 · 조건 레코드 · 리베이트 자료를 엑셀로 모으던 단계가 사라집니다.
• 회의의 주제가 달라집니다. 어느 숫자가 맞느냐가 아니라 어느 국가의 어느 할인을 손볼지를 이야기합니다.
• 다음 달로 이어지는 기록이 남습니다. 변동 사유와 저장한 구성이 따라와 같은 설명을 반복하지 않습니다.
• 놓치는 날이 줄어듭니다. 에이전트가 규칙에 걸린 고객과 국가를 받을 사람별로 올려 둡니다.

이런 회사에 맞습니다

수출 비중이 높고 여러 통화로 청구하며, 거래처마다 할인과 리베이트 조건이 달라 가격표대로 팔렸는지 가늠하기 어려운 회사에 맞습니다. 영업 · 수출 관리 · 재무 · 가격 정책 담당이 같은 숫자를 서로 다른 화면에서 맞춰 보는 조직이라면 가장 먼저 효과가 보입니다.

실행 화면

사용 방법

1. 회사코드와 기간, 계획 기준을 확인합니다. 기본값이 채워져 있습니다.
2. 오른쪽 끝의 조회 단추를 누르거나 입력칸에서 Enter 를 누릅니다.
3. 핵심 숫자 줄에서 순매출 · 가격표 · 실현율 · 순단가를 계획과 견줍니다.
4. 보드의 차원 단추를 행 또는 열로 끌어다 놓거나, 단추를 눌러 메뉴에서 옮깁니다.
5. 차원 단추 줄에서 값을 여러 개 골라 범위를 좁힙니다.
6. 숫자 칸을 누르면 원천 청구 라인이 열립니다. 위쪽 줄에서 칸 값과 라인 합계의 일치를 확인합니다.
7. 계획 대비를 켜 차이와 요인 분해를 보고, 차이가 큰 행에 사유를 남깁니다.
8. AI 분석 · AI 에이전트 · 기간별 요약 · CSV 로 내보내고, 자주 쓰는 구성은 레이아웃으로 저장합니다.

무엇으로 만들었나

처음 열었을 때 — 비어 있는 보드와 조회 결과

회사코드와 기간을 확인하고 조회하면 한 화면에 조건 · 핵심 숫자 · 보드 · 피벗 · 차트가 함께 뜹니다.

조회 전에는 표가 비어 있습니다. 회사코드는 1000, 기간은 2026년 1월부터 9월, 계획 기준은 판매 계획 버전으로 채워져 있습니다. 입력칸에서 Enter 를 눌러도 조회됩니다.

가운데 숫자 줄은 순매출 28,278백만원, 계획 28,978백만원(97.6퍼센트), 가격 실현율 89.7퍼센트입니다. 기본 배치는 행에 지역 › 국가, 아래 표 오른쪽에 같은 값을 그린 차트가 붙습니다.

경영 요약 — 역할마다 보는 숫자가 다르다

역할 단추를 바꾸면 같은 큐브에서 그 역할이 먼저 볼 숫자와 축 배치로 바뀝니다.

기본 역할입니다. 행은 국가, 항목은 순매출 · 가격표 · 실현율 · 순단가이며 계획 대비 비율이 숫자 아래에 붙습니다.

외화는 합치지 않고 통화별로 나뉘어 보입니다. 엔과 유로의 약세가 어느 통화에서 나는지 바로 확인합니다.

미국 고객의 판촉 할인과 베트남 신규 고객이 이 역할에서 가장 먼저 눈에 들어옵니다.

가격표 단가가 어느 제품그룹에서 움직였는지, 그것이 실현율에 얼마나 반영됐는지 읽습니다.

축 전환과 범위 — 끌어다 놓고, 접고, 좁힌다

보드의 차원 단추를 칸 사이로 끌어다 놓으면 표와 차트가 서버 호출 없이 바로 다시 묶입니다.

끌어다 놓는 동안 서버 호출은 0건입니다. 단추를 누르면 메뉴가 열려 행으로 · 열로 · 사용 안 함과 앞뒤 순서 이동을 고를 수 있어, 끌기가 어려운 환경에서도 쓸 수 있습니다.

합계 행은 항상 맨 위에 있고, 펼친 행의 합이 위 단계 값과 같습니다.

접어도 한 줄 요약에 현재 범위가 남아 있어 무엇을 보고 있는지 잃지 않습니다.

국가 · 고객 · 통화 같은 차원마다 값과 건수가 보입니다.

값을 여러 개 고르고 적용하면 선택한 값의 합만 남습니다.

범위가 좁혀진 차원 단추는 강조 색으로 바뀌고 괄호 안에 고른 개수가 보입니다.

열에 차원을 올리면 분석 항목 가운데 첫 항목만 열에 펼쳐 보인다는 안내가 뜹니다.

칸에서 원천 청구 라인까지

숫자를 누르면 그 칸의 조건이 그대로 질의가 되어 원천 라인이 열립니다.

전체 합계 행의 직접 판매 칸은 원천 441줄이며 칸 값 1,479와 원천 합계 1,479가 일치합니다. 만든 질의 문장도 함께 보여 줍니다.

총판 칸 4,336은 원천 273줄의 합과 같습니다.

OEM 칸 363은 원천 72줄의 합과 같습니다.

월마감 때는 이 표로 달마다 움직임을 먼저 훑습니다.

계산항목 — 가격표에서 순매출까지의 단계

단계 보기로 바꾸면 가격표 → 할인 → 리베이트 → 순매출을 계산 순서대로 펼칩니다.

실현율 · 할인율 · 리베이트율 · 가격표 단가 · 순단가는 합산하지 않고 큐브 합계에서 다시 계산한 값입니다.

기준 대비 차이 — 같은 표가 계획 대비 리포트가 된다

계획 대비를 켜면 칸마다 계획과 차이가 붙고 차트는 요인 분해로 바뀝니다.

색은 금액 부호가 아니라 순매출에 준 영향으로 칠하며, 한도를 넘는 칸만 입힙니다.

아래 검산 줄이 요인 합계와 총차이를 견주고 오차를 적습니다. 이 범위에서는 합계 −469, 총차이 −469, 오차 0.00 입니다.

사유는 조회 범위와 행 경로를 키로 저장됩니다.

저장한 사유는 같은 범위를 다시 조회해도 그대로 따라옵니다.

AI 분석 — 숫자는 서비스가, 설명은 AI 가

규칙으로 찾은 발견 사항을 근거 표와 함께 보여 주고 검토 자료를 내려받게 합니다.

발견 사항은 중국 · 일본 · 베트남 · 네덜란드처럼 점검 필요 대상을 가리키고 원인을 단정하지 않습니다.

AI 에이전트 — 규칙이 곧 받을 사람

다섯 규칙으로 점검하고, 걸린 것을 받을 사람의 눈으로 다시 적어 받은 보고함에 올립니다.

역할 필터로 CEO · CFO · 영업 · 가격 책임자별 보고만 골라 봅니다.

규칙 목록에서 임계값과 사용 여부를 고칠 수 있습니다.

두 번째 실행은 새 보고를 만들지 않습니다.

자동 실행을 켜 두면 주기마다 같은 서비스를 두드립니다.

레이아웃 저장과 복원

자주 쓰는 구성은 이름을 붙여 저장해 두고 기본값과 자동 조회로 지정합니다.

기본값으로 지정하면 자동 조회 여부를 함께 고릅니다.

같은 이름은 거절되고 안내가 뜹니다.

좁은 화면과 한계

창이 좁으면 차트를 감추지 않고 표 아래로 내립니다.

표는 가로로 밀어 보고, 조회 조건은 접을 수 있습니다.

화면 뒤에서 일어나는 일

계산은 서비스와 브라우저가 나눠 맡습니다. 서비스는 큐브와 계획을 필터로 읽어 주고 요인 분해 · 규칙 점검을 수행하며, 브라우저는 읽어 온 큐브를 다시 묶습니다.

점검 규칙 — 판정 조건 · 결과 상태 · 사용자 조치

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

창이 좁아지면 차트를 숨기지 않고 표 아래로 내립니다. 표는 가로로 밀어 보고, 조회 조건과 보드는 접어 둘 수 있습니다. 표시 행 수가 한도를 넘으면 안내 문구가 먼저 뜹니다.

파일 구성

view/          화면과 대화상자
controller/    화면 동작과 역할 구성
model/         큐브 재집계 · SVG 차트 · 레이아웃 · 검토 자료 생성
odata/         서비스 정의 · 계산 모듈 · 샘플 데이터
i18n/          화면 문구
css/           보조 스타일
media/         소개 영상

SAP 표준 기능 확장 포인트 — 표준 T-code 와 어떻게 연계되는지

표준으로 되는 것과 안 되는 것

T-code 별 연계 지점

운영으로 옮겨도 기존 표준 리포트를 없앨 필요는 없습니다. 법정 · 감사 · 세무 신고 대응은 표준 거래에 남기고, 이 화면은 가격 점검 관점의 분석을 맡습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다.

S/4HANA 분석 스택과의 자리

표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 정해진 보고서를 만들 때 좋은 선택입니다. 이 화면은 그 앞에서 축을 끌어다 놓으며 가설을 세우는 자리를 맡고, 보고서로 굳어질 만한 조합은 표준 분석 도구로 옮길 수 있습니다. 어떤 표준 분석 앱이 가격 · 리베이트 분석을 직접 지원하는지는 시스템 구성에 따라 달라 확인 필요입니다.

확장 포인트 — 운영에서 실제로 손대는 자리

분석 지표 정의

CDS 구성 — 최대한 자세히

뷰 레이어 구성

① 조건 유형 매핑 테이블 — 가격표 · 즉시 할인 · 리베이트를 가르는 기준

청구 문서의 가격 요소는 조건 유형 코드로 들어옵니다. 어느 코드가 가격표이고 어느 코드가 할인이나 리베이트인지는 회사마다 다르므로, 코드를 뷰에 박지 않고 매핑 테이블 한 곳에 둡니다. 조건 유형이 바뀌어도 이 표만 고치면 됩니다.

" ───────────────────────────────────────────────────────────────
" ZEXP_PRCMAP  : 조건 유형 → 가격 단계 매핑 (고객사가 직접 관리)
" 역할         : 청구 가격 요소를 LIST(가격표) / DISC(즉시 할인) / REB(리베이트) 로 분류
" 이렇게 나눈 이유 : 조건 유형 코드를 뷰에 박으면 가격 절차가 바뀔 때마다 이송이 필요하다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '수출 가격 단계 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zexp_prcmap {
  key client    : abap.clnt not null;
  key kschl     : abap.char(4) not null;   " 조건 유형 (예: 기준 가격 · 고객 할인 · 리베이트 — 확인 필요)
  stage         : abap.char(4) not null;   " LIST · DISC · REB
  sign          : abap.char(1) not null;   " 부호 규칙: + 가격표, - 차감
}

② 원천 라인 뷰 — 청구 문서 품목을 한 줄로 모은다

청구 문서 품목에 가격 단계를 붙여 한 줄에 가격표 · 할인 · 리베이트가 나란히 놓이게 합니다. 칸을 눌렀을 때 내려가는 원천 라인이 바로 이 뷰입니다. 표준 청구 품목 뷰를 그대로 이어받고, 가격 요소 뷰의 이름은 시스템에 따라 달라 확인 필요입니다.

" ───────────────────────────────────────────────────────────────
" ZI_ExpPriceItem : 수출 청구 품목 + 가격 단계 금액
" 역할            : 칸 → 원천 라인 드릴스루의 바닥. 큐브는 이 뷰를 집계한다
" 이렇게 나눈 이유 : 큐브와 원천이 같은 뷰에서 나와야 칸 값 = 라인 합계가 구조적으로 성립한다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수출 가격 원천 라인'
define view entity ZI_ExpPriceItem
  as select from I_BillingDocumentItem as Item
    inner join   I_BillingDocument     as Hdr on Hdr.BillingDocument = Item.BillingDocument
{
  key Item.BillingDocument,
  key Item.BillingDocumentItem,
      Hdr.BillingDocumentDate                       as PostDate,
      Hdr.SoldToParty                               as Customer,
      Hdr.TransactionCurrency                       as Currency,
      Item.Material,
      Item.BillingQuantity                          as Qty,
      Item.BillingQuantityUnit                      as QtyUnit,
      Item.NetAmount                                as NetFc,
      Hdr.AccountingExchangeRate                    as FxRate,
      substring( Hdr.BillingDocumentDate, 1, 6 )    as Period,
      Hdr.DistributionChannel                       as Channel,
      Hdr.IncotermsClassification                   as Incoterms,
      Item.ProductGroup                             as ProdGroup,
      _Prc.PriceType,                               -- 가격 구분(표준 · 계약 · 판촉): 조건 레코드에서 읽음 — 확인 필요
      _Prc.ListAmt,                                 -- 가격 요소를 ZEXP_PRCMAP 으로 분류해 합산
      _Prc.DiscAmt,
      _Prc.RebateAmt
      -- association _Prc 는 청구 가격 요소 뷰(이름 확인 필요)를 조건 유형 매핑으로 묶은 뷰
}

③ 차원 뷰 — 고객에서 국가 · 지역 · 채널을 읽는다

큐브가 국가와 지역을 매번 조인하지 않도록 고객 단위 차원 뷰를 따로 둡니다. 차원이 늘면 이 뷰에 필드만 더하면 됩니다.

" ───────────────────────────────────────────────────────────────
" ZI_ExpPriceCustomerDim : 고객 → 국가 · 지역 · 판매 채널
" 역할                   : 큐브의 차원 키를 한 곳에서 해석
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '수출 가격 고객 차원'
@ObjectModel.dataCategory : #DIMENSION
define view entity ZI_ExpPriceCustomerDim
  as select from I_Customer as Cust
{
  key Cust.Customer,
      Cust.Country                         as Country,
      Cust.Region                          as Region,
      Cust.CustomerAccountGroup            as CustomerGroup
}

④ 큐브 뷰 — 차원 조합별로 묶어 두는 집계

화면은 이 뷰를 조회할 때 한 번 읽습니다. 순매출은 가격표 − 할인 − 리베이트로 구성하고, 외화는 통화별 열로 따로 둡니다. 합산하지 않는 값(실현율 · 단가)은 큐브에 두지 않고 쿼리에서 다시 계산합니다.

" ───────────────────────────────────────────────────────────────
" ZI_ExpPriceCube : 월 · 고객 · 채널 · 가격 구분 · 인코텀즈 · 제품그룹 단위 집계
" 이렇게 나눈 이유 : 원천 3,480줄 → 487칸처럼 화면이 읽는 줄 수를 줄이는 층
" ───────────────────────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수출 가격 큐브'
define view entity ZI_ExpPriceCube
  as select from ZI_ExpPriceItem as I
    association [1] to ZI_ExpPriceCustomerDim as _Cust on _Cust.Customer = I.Customer
{
  key I.Period,
  key I.Customer,
  key I.Channel,
  key I.PriceType,
  key I.Incoterms,
  key I.ProdGroup,
      _Cust.Country,
      @Semantics.currencyCode : true
      cast( 'KRW' as waers_curc )                          as KrwCurrency,
      @Aggregation.default : #SUM
      @Semantics.amount.currencyCode : 'KrwCurrency'
      sum( I.ListAmt )                                     as ListAmt,
      @Aggregation.default : #SUM
      @Semantics.amount.currencyCode : 'KrwCurrency'
      sum( I.DiscAmt )                                     as Disc,
      @Aggregation.default : #SUM
      @Semantics.amount.currencyCode : 'KrwCurrency'
      sum( I.RebateAmt )                                   as Rebate,
      @Aggregation.default : #SUM
      @Semantics.amount.currencyCode : 'KrwCurrency'
      sum( I.ListAmt - I.DiscAmt - I.RebateAmt )           as Sales
}
group by I.Period, I.Customer, I.Channel, I.PriceType, I.Incoterms, I.ProdGroup, _Cust.Country

⑤ 계획 큐브 — 같은 차원으로 계획을 얹는다

계획은 버전 필드를 하나 더 가진 같은 모양의 큐브입니다. 차원이 같아야 칸마다 계획과 차이를 붙일 수 있고, 계획에만 있고 실적에 없는 칸이 계획 대비 분석에서 빠지지 않습니다. 계획 원천 테이블 이름은 고객사 구성에 따라 달라 확인 필요입니다.

" ───────────────────────────────────────────────────────────────
" ZI_ExpPricePlan : 판매 계획 큐브 (버전별)
" 이렇게 나눈 이유 : 계획 외 매출 · 계획만 있는 칸을 가르려면 두 큐브의 키가 같아야 한다
" ───────────────────────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수출 가격 계획 큐브'
define view entity ZI_ExpPricePlan
  as select from zexp_plan as P          " 계획 테이블 — 고객사 구성에 따라 확인 필요
{
  key P.version,
  key P.period,
  key P.customer,
  key P.channel,
  key P.price_type  as PriceType,
  key P.incoterms,
  key P.prod_group  as ProdGroup,
      @Aggregation.default : #SUM  sum( P.list_amt )  as ListAmt,
      @Aggregation.default : #SUM  sum( P.disc_amt )  as Disc,
      @Aggregation.default : #SUM  sum( P.rebate_amt ) as Rebate,
      @Aggregation.default : #SUM  sum( P.sales_amt ) as Sales
}
group by P.version, P.period, P.customer, P.channel, P.price_type, P.incoterms, P.prod_group

⑥ 분석 쿼리 — 화면이 부르는 소비 뷰

필터 · 기본 배치 · 항목 이름을 여기서 정합니다. 조회 기간과 회사코드는 필수 파라미터로 받아 대용량에서도 한 번에 전부 읽지 않게 합니다.

" ───────────────────────────────────────────────────────────────
" ZC_ExpPriceQuery : 소비 뷰 (OData 로 노출되는 분석 쿼리)
" ───────────────────────────────────────────────────────────────
@Analytics.query : true
@EndUserText.label : '수출 가격 실현 분석'
@Metadata.allowExtensions : true
define view entity ZC_ExpPriceQuery
  with parameters
    P_FromPeriod : abap.char(7),
    P_ToPeriod   : abap.char(7)
  as select from ZI_ExpPriceCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #RANGE, mandatory : true }
  key Period,
  @AnalyticsDetails.query.axis : #ROWS
  Country,
  @AnalyticsDetails.query.axis : #COLUMNS
  Channel,
  @UI.lineItem : [{ position : 10 }]
  Sales,
  @UI.lineItem : [{ position : 20 }]
  ListAmt,
  Disc,
  Rebate
}
where Period >= $parameters.P_FromPeriod and Period <= $parameters.P_ToPeriod

⑦ 접근 제어 — 회사코드와 고객 그룹으로 걸러 낸다

권한은 집계 단계에 겁니다. 드릴스루에만 걸면 합계에서 뺄셈으로 남의 숫자가 드러납니다. 권한 객체 이름과 필드는 고객사 권한 설계에 따라 확인 필요입니다.

" ───────────────────────────────────────────────────────────────
" ZC_ExpPriceQuery 의 DCL
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '수출 가격 분석 접근 제어'
@MappingRole : true
define role ZC_ExpPriceQuery {
  grant select on ZC_ExpPriceQuery
    where ( Country ) = aspect pfcg_auth( ZEXP_CTRY, ZEXP_CTRY, actvt = '03' );
}

⑧ 서비스 정의와 바인딩 — 화면이 연결되는 문

서비스 정의로 노출할 뷰를 정하고 바인딩으로 OData V2 를 게시합니다. 화면 쪽에서는 서비스 주소만 바꾸면 샘플에서 운영으로 옮겨 갑니다.

" ───────────────────────────────────────────────────────────────
" ZUI_ExpPrice : 서비스 정의 + OData V2 바인딩
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '수출 가격 실현 분석 서비스'
define service ZUI_ExpPrice {
  expose ZC_ExpPriceQuery as PriceCube;
  expose ZI_ExpPriceItem  as PriceItem;
}
" 서비스 바인딩 ZUI_ExpPrice_O2 : 바인딩 유형 OData V2 - UI, 게시 후 서비스 활성화(확인 필요)

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

숫자를 믿을 수 있는가 — 검증 결과

의도적 예외는 없습니다. 화면 쪽은 실제 브라우저로 끌어다 놓기 · 드릴스루 12칸 · 계획 대비 · 에이전트 두 번 실행 · 레이아웃 저장을 돌려 확인했습니다.

운영 데이터로 갈 때

청구 라인이 수천만 건이면 큐브 집계를 데이터베이스에서 끝내야 합니다. 조회 기간과 회사코드를 필수 파라미터로 받고, 큐브 뷰에서 월 · 고객 · 제품그룹까지 미리 묶고, 원천 라인은 칸을 눌렀을 때만 500줄 단위로 읽습니다. 응답 시간 목표는 큐브 조회 몇 초 이내처럼 운영 단계에서 합의해 정해야 하며, 구체적인 수치는 확인 필요입니다.

자주 묻는 질문

화면에서 가장 많이 나오는 질문을 네 묶음으로 정리했습니다. 모든 숫자는 가상의 샘플 값입니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영