은행·예치처 집중도 다차원 분석 — 은행 쏠림과 한도 이용률, 계획 차이를 한 화면에서 점검하는 자금 리포트

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

자금 회의의 질문은 늘 비슷합니다. 우리 돈이 어느 은행에 얼마나 몰려 있나, 그 은행의 한도는 얼마나 남았나, 계획한 배분과 무엇이 달라졌나. 지금 이 세 답은 은행별 잔액 조회, 한도 관리 엑셀, 월말 계획표에 흩어져 있어서 회의 전에 사람이 붙여야 합니다. 이 앱은 세 답을 한 화면에 붙여, 예치 현황을 다시 만드는 손일을 줄이고 “어느 숫자가 맞나” 하는 확인 시간을 줄입니다.

관련 기준서는 두지 않았고 대상 영역은 자금입니다. 화면은 분류·집계·대사를 돕는 점검 도구이며, 한도와 신용등급은 검증용 샘플 데이터의 가정값입니다.

핵심 포인트 여덟 가지

사례로 보는 효과

검증용 샘플 데이터(가상 은행 8곳, 2026년 9월 말 기준)에서 기말 예치 잔액은 24,459.26억 원이고, 가장 큰 은행의 비중은 38.3%, 집중도 지수(비중 제곱의 합)는 2,128입니다. 그 은행의 한도 이용률은 101.85%로 가정한 한도를 넘어 점검 필요로 표시됩니다. 같은 은행의 예치 잔액은 계획 10,213.97억 원보다 843.74억 원 적은 9,370.23억 원인데, 요인분해로 가르면 계획 초과 +618.63억, 계획 미달 −1,378.85억, 환율 +58.49억, 계획 외 예치 +524.53억, 미예치 −666.54억이 나오고, 합은 차이와 정확히 같습니다(검산 0). 큐브와 원천 라인의 대사 54건, 은행×기간 셀 480건은 차이가 0건입니다.

도입하면 달라지는 것

• 예치 현황 보고 준비 — 비중·한도·계획 차이가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 회의의 주제 — “어느 숫자가 맞나”보다 “어느 은행으로 얼마를 옮길까”를 이야기합니다.
• 다음 달로 이어지는 기록 — 사유와 보기 배열이 남아 같은 설명을 다시 하지 않습니다.
• 놓치는 날이 없는 점검 — 아무도 화면을 열지 않아도 감시 규칙에 걸린 항목이 대기함에 올라옵니다.

이런 회사에 맞습니다

여러 은행에 예금·MMF·환매조건부채권으로 자금을 나눠 두고, 법인 여러 곳과 외화 계좌를 함께 운영하며, 은행별 한도와 신용등급군을 관리하는 자금 조직에 맞습니다. 은행 수가 수 곳 이상이고 통화가 둘 이상이며, 월 단위로 계획 대비 예치 현황을 보고하는 회사라면 효과가 커집니다.

실행 화면

사용 방법

1. 조회조건 입력 — 예치 법인(선택, 비우면 전체), 기간(부터·까지, 필수), 비교 기준(계획 버전)을 고릅니다. 기본값은 전체 법인, 2026년 01월~09월, 계획(P0)과 비교입니다.
2. 조회 — 조건 오른쪽 위의 [조회] 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 조회 직후 조건 영역은 한 줄 요약으로 접힙니다.
3. 요약 확인 — 표 위 KPI 다섯 개(기말 예치 잔액, 최대 은행 비중, 한도 이용률, 보통 등급군 비중, 계획 대비 차이)를 먼저 봅니다.
4. 보는 사람과 축 이동 — 경영·재무·자금·회계 순서로 눌러 역할별 배열을 보고, 차원 보관함의 차원을 끌어 행 축·열 축에 놓습니다.
5. 칸·행 클릭 — 칸을 누르면 원천 라인이 열리고, 계획 차이를 켠 상태에서 행을 고르면 요인분해 워터폴이 나옵니다.
6. 내려받기 — [CSV]로 현재 표를, 원천 라인 창의 [CSV]로 그 칸의 라인을, 해설 창의 [보고서 PPTX]로 검토 자료를 받습니다.

무엇으로 만들었나

화면은 실제 브라우저에서 검증용 샘플 데이터로 찍었습니다. 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다.

처음 열었을 때

조회 직후에는 기말 예치 잔액과 최대 은행 비중, 한도 이용률, 보통 등급군 비중, 계획 대비 차이가 KPI로 먼저 보이고, 아래에 차원 보관함과 행·열 축, 표, 차트가 놓입니다.

조회를 누르면 은행 8곳의 기말 예치 잔액이 분기별로 나옵니다. 합계 24,459.26억 원은 마지막 기간(2026년 9월) 기준입니다. 한도와 신용등급은 가정값이므로 KPI 아래에도 그렇게 적습니다.

차원 보관함에서 차원을 끌어 행 축이나 열 축에 놓습니다. 행은 최대 세 단계, 열은 두 단계까지 쌓이고, 바꿔도 서버를 다시 부르지 않습니다. 열 축에 측정값을 놓으면 한 표에서 잔액과 비중을 함께 봅니다.

경영 요약 — 보는 사람에 따라 달라지는 배열

같은 큐브를 보는 사람별 기본 배열로 열어 줍니다. 경영은 은행 비중, 재무는 한도, 자금은 통화·변동, 회계는 등급군을 먼저 봅니다.

경영은 은행별 예치 비중을 분기별로 봅니다. 최대 은행 비중 38.3%가 KPI에서 주황색으로 표시되어 점검 대상임을 먼저 알려 줍니다. 비중의 합은 언제나 100%입니다.

재무는 은행별 잔액, 약정 한도 배정액, 한도 이용률을 나란히 봅니다. 가상 시중은행 A의 이용률 101.85%처럼 한도를 넘는 행이 바로 드러납니다. 한도는 가정값입니다.

자금은 은행·통화별 잔액과 순 변동, 비중을 봅니다. 통화마다 환율을 곱한 원화 환산 잔액만 더하므로 외화와 원화가 섞여도 합계가 맞습니다.

회계는 신용등급군별 예치액과 보통 등급군 비중을 봅니다. 등급은 가정값이며, 차이가 있으면 원천 라인과 맞는지 점검이 필요합니다.

축 전환과 범위

차원을 끌어 놓거나 값 필터로 범위를 좁혀도 표·차트·KPI가 함께 바뀌고 합계는 일관됩니다.

열 축에 분기와 측정값을 겹쳐 놓은 예입니다. 어떻게 짜도 합계 24,459.26억 원은 같습니다. 열이 너무 많아지면 상한 안내가 나옵니다.

값 필터에서 은행 두 곳만 고르면 표와 차트, KPI가 그 범위로 바뀝니다. 필터 요약 줄에 어떤 조건이 걸려 있는지 남습니다. 필터 범위의 합계는 원천 라인 합계와 같습니다.

칸에서 원천 라인까지

표의 숫자를 의심할 때 다른 화면을 열지 않고 그 칸의 원천 라인을 바로 엽니다.

칸을 누르면 그 칸을 만든 원천 라인(가상 시중은행 C, 2026년 1분기 89건)이 열립니다. 원천 합계 2,992.28억 원이 표의 값과 일치하면 초록 표시가 나옵니다. [CSV]로 그 라인만 내려받습니다.

행 축을 분기·기간으로 바꾸면 기간별 잔액, 한도, 순 변동, 이자 수익을 봅니다. 잔액과 한도는 기간 끝 값, 변동과 이자는 합계라서 분기 합계의 의미가 다릅니다.

계산 항목 — 비중과 한도 이용률

예치 비중과 한도 이용률은 큐브의 측정값에서 계산하는 항목이라 어떤 축으로 접어도 같은 식으로 다시 계산됩니다.

예치 비중, 한도 이용률, 한도 여유, 운용 수익률이 열로 붙습니다. 가상 시중은행 A는 비중 38.31%, 이용률 101.85%, 한도 여유 −170.23억 원입니다. 비중은 전체 잔액 대비라 행을 접어도 같은 식입니다.

신용등급군 축으로 바꾸면 최상위 등급군 예치액과 보통 등급군 비중이 나옵니다. 보통 등급군 비중은 6.03%이고 기준 5%를 넘어 정보로 표시됩니다. 등급은 가정값입니다.

계획 대비 차이 — 같은 표가 점검 자료가 된다

비교 기준만 켜면 같은 표가 실적·계획·차이·차이율이 나란한 점검표가 되고, 행을 고르면 요인분해 워터폴과 변동 사유가 이어집니다.

계획 차이를 켜면 비중의 실적·계획·차이·차이율이 나란히 놓입니다. 금액 3,000백만 원과 비율 5%를 모두 넘는 칸만 색을 칠해 과도한 알림을 줄입니다. 기준값은 조회조건 아래에서 바꿉니다.

잔액 기준으로 보면 합계는 실적 24,459.26억 원, 계획 25,849.83억 원, 차이 −1,390.56억 원입니다. 은행 A는 −843.74억 원으로 가장 크게 줄었습니다. 행을 누르면 요인분해가 이어집니다.

은행 A를 고르면 계획 10,213.97억 원에서 실적 9,370.23억 원까지의 차이를 여섯 요인으로 가르는 워터폴이 나옵니다. 계획 미달 −1,378.85억, 미예치 −666.54억은 줄이는 쪽이고 계획 초과 +618.63억, 계획 외 예치 +524.53억은 늘리는 쪽입니다. 표 아래 검산 줄은 계획 + 요인 합 − 실적 = 0을 보여 줍니다.

차이가 난 행에 구분과 사유를 적습니다. 사유는 조회 범위와 행 경로에 묶여 저장되어 축을 바꿔도 따라오고, 적힌 행에는 연필 표시가 붙습니다. 해설은 이미 사유가 적힌 행을 건너뜁니다.

AI 분석과 보고서

해설은 현재 범위를 읽어 요약과 핵심 발견을 쓰되 숫자는 서비스가 계산한 값만 씁니다.

해설은 현재 범위를 읽어 요약과 핵심 발견을 씁니다. 금액과 비율은 서비스가 계산하고 문장은 규칙으로 만든 초안이며, 기본은 규칙 기반이고 모델 연결은 설정으로 켭니다. 점검 필요 항목은 근거 숫자를 확인하라고 안내합니다.

해설에 쓴 숫자는 근거 표로 펼쳐 볼 수 있습니다. 묶음별 계획·실적·차이가 원 단위로 나옵니다. [보고서 PPTX]를 누르면 현재 범위의 표와 차트를 담은 PowerPoint가 브라우저에서 만들어집니다.

AI 에이전트

화면을 열지 않아도 점검이 돌도록 감시 규칙과 대기함, 활동 기록을 둡니다.

감시 규칙은 단일 은행 비중 상한 35%, 한도 이용률 90%, 보통 등급군 비중 5%, 계획 차이 1,000억 원 네 가지가 기본입니다. 규칙마다 받을 역할이 있어 같은 결과도 받는 사람의 눈으로 다시 적습니다. 임계값은 규칙 목록에서 바꿉니다.

지금 실행하면 규칙에 걸린 항목이 대기함에 올라옵니다. 같은 날 두 번째 실행은 서버가 막고 안내 문구가 나옵니다. 화면을 연 지 20분이 지나면 화면 타이머가 한 번 더 확인합니다.

실행할 때마다 시각, 호출 주체(사람·화면 타이머·배치), 걸린 건수가 기록으로 남습니다. 걸린 것이 없어도 기록은 남습니다. 운영에서는 배치(SM36 또는 cron)가 같은 함수를 부릅니다.

보기 저장과 복원

짜 둔 배열을 이름 붙여 저장하면 다음에 열 때 그 배열로 시작합니다.

현재 행·열·측정값 배열에 이름을 붙여 저장합니다. 기본 보기로 지정하면 다음에 열 때 그 배열로 시작하고, 자동 조회를 켜면 열자마자 조회합니다. 저장 내용은 창 아래에 요약으로 보입니다.

저장한 보기를 목록으로 보고 기본값을 바꾸거나 지웁니다. 보기는 서비스에 저장되므로 다른 브라우저에서도 같은 배열이 열립니다.

좁은 화면과 한계

창이 좁으면 차트를 감추지 않고 표 아래로 내려 같은 리포트를 봅니다.

창이 좁으면 차트를 감추지 않고 표 아래로 내려 같은 리포트를 봅니다. 휴대폰에서도 요약과 표, 차트가 모두 보입니다. 열이 많은 표는 가로로 밀어 봅니다.

화면 뒤에서 일어나는 일

조회를 누르면 서비스가 큐브와 계획 큐브를 읽어 오고, 이후 행·열을 바꾸는 일은 브라우저의 큐브 엔진이 처리합니다. 칸을 누르면 그 칸의 조건으로 원천 라인을 읽고, 계획 차이 모드에서 행을 고르면 요인분해 함수를 부릅니다. 사유·보기·에이전트 기록은 서비스에 쓰입니다.

판정 규칙 — 조건 → 결과 → 조치

처리 단계와 대사식

1. 원천 라인을 읽어 외화 금액을 월말 환율로 원화 환산합니다.
2. 기간·법인·은행·상품·통화·등급·만기·목적·지역 단위로 큐브를 만듭니다. 잔액과 한도는 기간 끝 값, 이자와 변동은 합계입니다.
3. 대사식 ① 큐브 합계 = 원천 라인 합계.
4. 행·열로 접고 계산 항목(비중 = 잔액 ÷ 전체 잔액, 이용률 = 잔액 ÷ 한도)을 계산합니다.
5. 대사식 ② 표의 칸 값 = 그 칸의 원천 라인 합계.
6. 대사식 ③ 계획 + 요인 합 − 실적 = 0.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

창이 좁으면 차트가 표 아래로 내려오고, 조회조건과 KPI는 위아래로 쌓입니다. 표는 가로로 밀 수 있어 열이 많아도 잘리지 않습니다.

파일 구성

index.html · Component.js · manifest.json
view/        화면 구성(조회조건, 피벗, 원천 라인·해설·에이전트 창)
controller/  화면 동작
model/       큐브 엔진 · 차트 · 보고서(PPTX) 만들기
odata/       서비스 선언과 계산 모듈, 검증용 데이터
media/       소개 영상
readme.html  앱 설명서

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 관련 기준서는 두지 않았고 대상 영역은 자금입니다.

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

T-code 별 연계 지점

운영 전환 후에도 기존 표준 조회를 없애지 않습니다. 법정·감사·공시 대응이 필요한 숫자는 표준에 남기고, 이 앱은 분석과 점검용으로 함께 둡니다.

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

표준 CDS 분석 쿼리나 Fiori 분석 앱, Analysis for Office 같은 도구와 경쟁하지 않습니다. 같은 CDS 큐브 위에 올려 쓰는 점검 화면이며, 앱 이름이 확인되지 않은 표준 Fiori 앱은 여기에 적지 않았습니다(확인 필요). 차원을 끌어다 놓는 자유도와 사유 기록, 감시 규칙이 이 화면의 자리입니다.

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

분석 지표 정의표

CDS 구성

샘플 화면은 검증용 데이터를 읽지만, 운영에서는 은행 계좌와 전표 원천 위에 CDS 뷰를 쌓아 같은 서비스 계약으로 연결합니다. 아래는 스케치이며, 대상 시스템의 필드와 표준 뷰 이름은 확인이 필요합니다.

뷰 레이어 구성

① 매핑 테이블 — 은행을 등급군과 지역에 묶기

어느 은행이 어느 등급군과 지역에 속하는지는 데이터에서 나오지 않는 기준입니다. 운영에서 가장 먼저 정해야 하고 화면의 등급군 비중이 여기서 결정됩니다. 등급 원천(외부 평가 사용 여부)은 회사가 정합니다.

" ─── ZBKC_GRADEMAP : 은행 → 신용등급군·지역 매핑 (DDIC 테이블 스케치)
" 이름 : 은행 등급군 매핑   역할 : 은행 그룹, 등급군, 지역의 기준
" 나눈 이유 : 등급·지역 기준이 바뀌어도 뷰를 고치지 않도록 테이블로 둔다
@EndUserText.label : '은행 등급군 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zbkc_grademap {
  key mandt   : mandt not null;
  key bukrs   : bukrs not null;
  key hbkid   : hbkid not null;
  bank_group  : abap.char(4);
  grade       : abap.char(1);   " A / B / C — 회사 기준으로 정함
  region      : abap.char(2);   " KR / AS / EU / AM
  valid_from  : abap.dats;
}

② 기준 뷰 — 은행 계좌 기준

하우스뱅크와 계좌를 읽어 매핑을 붙입니다. 이 뷰에서 은행·계좌의 키가 정해지므로 하위 뷰는 모두 이 키를 따릅니다.

" ─── ZI_BankAccountBase : 은행 계좌 기준 (확인 필요: 대상 시스템의 T012K 필드)
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '은행 계좌 기준'
define view entity ZI_BankAccountBase
  as select from t012k as acc
  left outer join zbkc_grademap as map
    on  map.bukrs = acc.bukrs
    and map.hbkid = acc.hbkid
{
  key acc.bukrs   as CompanyCode,
  key acc.hbkid   as HouseBank,
  key acc.hktid   as AccountId,
      acc.waers   as AccountCurrency,
      acc.hkont   as GLAccount,
      map.bank_group as BankGroup,
      map.grade      as GradeGroup,
      map.region     as Region
}

③ 차원 뷰 — 보관함이 읽는 목록

차원 보관함과 값 필터가 읽는 목록입니다. 이름과 정렬 순서를 한 곳에서 관리해 화면 어디서나 같은 이름이 나옵니다.

" ─── ZI_BankDimension : 은행 차원 (이름·정렬)
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'HouseBank'
define view entity ZI_BankDimension
  as select distinct from ZI_BankAccountBase
{
  key CompanyCode,
  key HouseBank,
      @Semantics.text: true
      BankGroup as BankName,
      GradeGroup,
      Region
}

④ 큐브 뷰 — 기간별 예치 잔액 집계

월말 잔액을 원화로 환산해 기간·법인·은행·상품·통화·등급별로 모읍니다. 잔액은 기간 끝 값이라 기간 끝 필터를 걸고, 변동과 이자는 합계로 둡니다. 통화는 환산 시점과 환율 유형을 먼저 정해야 합니다.

" ─── ZI_BankDepositCube : 실적 큐브 (원천 전표는 대상 시스템에서 확인 필요)
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
define view entity ZI_BankDepositCube
  as select from ZI_BankDepositLine as ln   " 월말 잔액 라인 뷰
  association [0..1] to ZI_BankDimension as _Bank
     on _Bank.HouseBank = $projection.HouseBank
{
  key ln.PostingPeriod,
  key ln.CompanyCode,
  key ln.HouseBank,
  key ln.ProductType,
  key ln.TransactionCurrency,
  key ln.GradeGroup,
      @Semantics.amount.currencyCode: 'ReportCurrency'
      sum( case ln.IsPeriodEnd when 'X' then ln.AmountInReportCurrency else 0 end ) as Balance,
      @Semantics.amount.currencyCode: 'ReportCurrency'
      sum( ln.NetChange )       as NetChange,
      @Semantics.amount.currencyCode: 'ReportCurrency'
      sum( ln.InterestIncome )  as InterestIncome,
      cast( 'KRW' as waers )    as ReportCurrency,
      _Bank
}
group by ln.PostingPeriod, ln.CompanyCode, ln.HouseBank, ln.ProductType,
         ln.TransactionCurrency, ln.GradeGroup

⑤ 계획 큐브 — 같은 차원에 계획 버전

계획 큐브는 실적 큐브와 키가 같아야 칸마다 차이를 낼 수 있습니다. 계획 원천(유동성 예측 계획 등)과 버전, 범주는 도입 때 합의합니다.

" ─── ZI_BankDepositPlan : 계획 큐브 (버전 포함, 원천은 확인 필요)
@Analytics.dataCategory: #CUBE
define view entity ZI_BankDepositPlan
  as select from ZI_BankDepositPlanLine as pl
{
  key pl.PlanVersion,
  key pl.PostingPeriod,
  key pl.CompanyCode,
  key pl.HouseBank,
  key pl.ProductType,
  key pl.TransactionCurrency,
  key pl.GradeGroup,
      @Semantics.amount.currencyCode: 'ReportCurrency'
      sum( pl.PlannedBalance ) as PlannedBalance,
      cast( 'KRW' as waers )   as ReportCurrency
}
group by pl.PlanVersion, pl.PostingPeriod, pl.CompanyCode, pl.HouseBank,
         pl.ProductType, pl.TransactionCurrency, pl.GradeGroup

⑥ 분석 쿼리 — 화면이 읽는 모양

화면이 읽는 측정값과 필터만 드러내는 소비 뷰입니다. 비중과 이용률은 계산 항목이라 쿼리에서 정의하지 않고 화면이 같은 식으로 계산합니다.

" ─── ZC_BankConcentrationQuery : 소비 뷰
@Analytics.query: true
@EndUserText.label: '은행 예치 집중도'
define view entity ZC_BankConcentrationQuery
  as select from ZI_BankDepositCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #RANGE, multipleSelections: true }
  key HouseBank,
  @AnalyticsDetails.query.axis: #COLUMNS
  key PostingPeriod,
  @Consumption.filter.mandatory: true
  key CompanyCode,
  @AnalyticsDetails.query.axis: #COLUMNS
  Balance,
  NetChange,
  InterestIncome
}

⑦ 권한(DCL)과 서비스 정의

권한은 집계 단계에서 걸어야 합니다. 드릴스루에만 걸면 합계 뺄셈으로 다른 법인 숫자가 새어 나갑니다.

" ─── DCL : 회사코드 권한
@EndUserText.label: '은행 예치 집중도 권한'
@MappingRole: true
define role ZC_BankConcentrationQuery {
  grant select on ZC_BankConcentrationQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

" ─── 서비스 정의(스케치) — 바인딩은 OData V2 로 게시
define service ZUI_BankConcentration {
  expose ZC_BankConcentrationQuery as BankConcentration;
  expose ZI_BankDimension          as BankDimension;
}

운영 시점에 해야 할 일

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

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

계약 검증으로 서비스의 엔티티셋 14개와 함수 3개가 선언과 일치하고, 날짜 조건 필터와 쓰기도 동작함을 확인했습니다.

운영 데이터로 갈 때

예치 라인이 수천만 건이면 집계는 큐브 뷰에서 미리 하고 화면은 기간·법인 필터를 필수로 받아야 합니다. 원천 라인 창은 칸 단위로만 열고 건수 상한을 둡니다. 인덱스는 기간·법인·은행에 먼저 걸고, 응답 시간 기준을 정해 상한을 조정합니다.

자주 묻는 질문 — 도입 전에 많이 묻는 것

숫자와 산식, 화면과 조작, 분석 기능, 도입과 운영 순서로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영