차입 구조 다차원 분석 — 대주 · 통화 · 만기 구간으로 보는 차입 잔액과 계획 대비 차이 점검

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

자금 회의의 질문은 늘 비슷합니다. 차입 잔액이 어느 대주와 어느 통화에 쌓여 있나, 상환이 어느 달에 몰리나, 계획과 얼마나 달라졌고 왜 달라졌나. 지금은 이 세 답이 표준 현금 포지션 화면 · 은행 명세 · 엑셀 차입 대장에 흩어져 있어 회의 전날 숫자를 맞추는 일이 먼저 생깁니다. 이 앱은 세 답을 한 화면에 모아, 기초 잔액에서 기말 잔액까지의 흐름과 계획 대비 차이를 같은 표 위에서 확인하게 합니다. 관련 기준서의 요구사항(IAS 7 현금흐름표(K-IFRS 제1007호)의 재무활동 현금흐름, IAS 21 환율변동효과(K-IFRS 제1021호), IFRS 7 금융상품: 공시(K-IFRS 제1107호)의 유동성 위험)을 점검하는 자리에서 보는 숫자를 한곳에 두는 것이 목적입니다.

핵심 포인트 일곱 가지

사례로 보는 효과

샘플 데이터(2026년 1월~9월, 가상 약정 20건)에서 계획 순증감은 −37.36억원, 실적 순증감은 −16.47억원으로 +20.89억원의 차이가 났습니다. 요인으로 나누자 금액 차이 +13.50억원이 가장 컸고, 계획 미실현 +4.10억원, 계획 외 발생 +3.00억원, 환율 +0.29억원이 뒤를 이었습니다. 요인 합과 총차이의 검산은 0원이었습니다. 대주로 묶어 보면 한빛은행 +11.88억원, 미래은행 +11.15억원, 해든은행 −5.12억원이 눈에 띄어 어느 대주부터 점검할지 정할 수 있습니다. 같은 데이터로 대사식 11종을 전수 돌린 결과는 검사 1,383건에 차이 0건이었습니다(#sec-cds 의 검증 결과 표). 위 숫자는 모두 가상의 샘플 값이며 운영 데이터의 효과를 보장하지 않습니다.

도입하면 달라지는 것

• 회의 전날 표를 맞추는 시간이 줄고, “어느 숫자가 맞나” 대신 “어느 대주와 어느 만기를 점검할까”를 이야기하게 됩니다.
• 차이의 이유가 요인별로 나뉘어 있어 담당자가 바뀌어도 같은 방식으로 설명할 수 있습니다.
• 변동 사유가 행에 남아 다음 회의에서 같은 설명을 반복하지 않습니다.
• 단기 상환 비중이나 월 상환액이 한도에 닿으면 알림이 올라와 점검 시점을 놓치지 않습니다.
• 표준 화면과 숫자를 맞춰 보는 지점이 정해져 있어 대사 방법이 사람마다 달라지지 않습니다.

이런 회사에 맞습니다

은행 여러 곳과 시장성 차입(회사채 · 유동화)을 함께 쓰고, 원화 외에 달러 · 유로 · 엔 차입이 섞여 있어 대주 · 통화 · 만기 구간으로 잔액을 나눠 보아야 하는 회사입니다. 자금팀이 차입 대장을 엑셀로 관리하며 월 단위로 계획과 비교하고, 회계팀이 기말 잔액과 환산 효과를 따로 대사하는 조직이면 효과가 큽니다. 차입 약정이 몇 건 안 되고 통화가 하나뿐이라면 표준 화면만으로도 충분할 수 있습니다.

실행 화면

사용 방법

1. 조회 조건 입력 — 회사(선택) · 기간(필수) · 비교 기준 · 금액 단위를 정합니다. 기간의 시작이 끝보다 늦으면 안내가 나옵니다.
2. 조회 버튼과 Enter 키 — 조회 조건 영역 안 입력 필드의 가장 오른쪽에 있는 “조회”를 누르거나 입력 필드에서 Enter 를 누릅니다. 조회하면 조건 영역이 자동으로 접힙니다.
3. 요약 확인 — 표 위 KPI 에서 실행 · 상환 · 순증감 · 계획 대비 차이 · 기말 잔액 · 12개월 내 상환 예정을 봅니다.
4. 축 이동 — 차원 칩을 끌어다 놓거나 칩 메뉴(행으로 보내기 · 열로 보내기 · 축에서 빼기)로 옮깁니다.
5. 칸 클릭 상세 — 표의 값을 누르면 원천 라인이 열립니다. 행을 선택해 변동 사유를 남길 수 있습니다.
6. 내보내기 — “CSV”로 현재 표를, “보고서 PPTX”로 해설과 표를 내려받습니다.

무엇으로 만들었나

아래 화면은 모두 샘플 데이터로 실제 브라우저에서 찍은 것입니다. 그림을 누르면 크게 볼 수 있습니다.

처음 열었을 때

조회 조건부터 표와 차트까지 한 화면에 세로로 쌓입니다. 조회 전에도 틀이 먼저 서 있어 무엇을 고르면 무엇이 채워지는지 보입니다.

조회 조건에는 기간이 기본으로 들어 있고 회사는 비어 있습니다(전체 회사). 값이 비어 있어도 틀이 서 있어서 처음 여는 사람도 구성을 먼저 파악합니다. 필수는 기간 하나입니다.

조회를 누르면 KPI 가 먼저 채워지고 표와 오른쪽 차트가 함께 나옵니다. 기본 측정값은 기말 잔액과 단기 상환 비중이며 단위는 백만원입니다. 조회하면 조건 영역은 접혀 표가 넓어집니다.

차원 칩을 끌어다 칸 사이에 놓으면 그 자리에서 표가 다시 묶입니다. 칩을 눌러 나오는 메뉴로도 옮길 수 있어 마우스가 불편해도 같은 일을 할 수 있습니다. 행 축은 3단계까지입니다.

다시 조회하지 않고 바로 표가 바뀝니다. 큐브는 이미 브라우저에 있고 축 이동은 그 행들을 다시 묶는 일이기 때문입니다. 합계는 어떤 배치에서도 같습니다.

경영 요약 — 보는 사람에 따라 달라지는 첫 줄

같은 큐브의 같은 숫자라도 먼저 보아야 할 지표는 자리마다 다릅니다. “보는 사람”을 바꾸면 KPI 와 기본 배치가 바뀝니다.

경영 관점은 차입 총잔액과 계획 대비 차이를 앞에 둡니다. 숫자 옆의 방향 색은 차입이 늘거나 단기 비중이 높아지는 쪽을 점검 우선(빨강)으로 칠합니다. 좋고 나쁨의 판정이 아니라 점검 순서입니다.

재무 관점은 회사별 · 만기 구간별 기말 잔액과 12개월 내 상환 예정 비중을 앞에 둡니다. 비중이 45% 이상이면 감시 규칙에도 걸립니다(임계값은 가정값).

자금 관점은 대주와 통화별 잔액, 실행 지연 · 상환 앞당김, 환산 효과를 앞에 둡니다. 외화 차입 비중을 확인할 때 이 관점이 편합니다.

회계 관점은 기초 + 증감 + 환산 효과 = 기말 롤포워드와 롤포워드 차이를 앞에 둡니다. 차이가 0이 아니면 해당 칸에서 바로 원천 라인으로 내려갑니다.

축 전환과 범위 — 리포트를 더 만드는 대신 축을 바꾼다

조건에서 범위를 좁히고 축으로 각도를 바꾸고 표와 차트의 너비까지 그 자리에서 나눕니다.

1단계 값이 하위 열을 묶어 보여 줍니다. 서버를 다시 부르지 않습니다. 열 조합이 너무 많아지면 표로 읽히지 않으므로 상한을 두고 안내합니다.

같은 차원 안에서는 또는, 차원끼리는 그리고로 묶입니다. 값 목록이 이름과 함께 열려 코드를 외우지 않아도 됩니다. 필터가 걸린 차원은 표시로 남습니다.

행을 접고 펴면 차트도 따라 바뀝니다. 표와 같은 값을 쓰므로 표와 차트의 숫자가 다를 수 없습니다.

칸에서 원천 문서까지 — 숫자를 의심할 때 내려가는 길

표의 숫자가 어디서 나왔는지 같은 화면에서 확인합니다.

표의 값을 누르면 열립니다. 원천 합계가 칸의 값과 같으면 “표의 값과 일치”, 다르면 차이 금액을 보여 줍니다. 계산항목 칸은 구성 값의 원천 합계로 맞춰 봅니다.

외화 금액에는 통화 코드를 함께 두고 환율은 소수 자릿수를 고정했습니다. 표준 화면으로 확인하려면 이 전표 번호를 계정 원장 화면(FBL3N)에서 찾으면 됩니다.

가장 상환이 몰린 달과 계획과 가장 어긋난 달이 한눈에 보입니다. 이 표의 합계도 큐브와 같은 값입니다.

계산항목 — 롤포워드를 표 안에서

계산항목은 토큰 식으로 정의되어 있고 원천값과 이름이 겹치지 않도록 원천값에는 표시를 붙였습니다. 롤포워드 차이가 0이 아니면 점검 대상입니다.

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

비교 기준을 계획으로 두고 조회하면 같은 표가 차이 표로 바뀝니다.

금액 기준과 비율 기준을 넘는 칸만 색으로 강조해 점검할 칸을 줄여 줍니다. 기준값은 화면에서 바꿀 수 있습니다.

사유는 조회 범위와 행 경로를 키로 저장되어 다음에 같은 범위를 열면 따라옵니다. 단정적인 판단 대신 점검 메모를 남기는 용도입니다.

검산 줄은 계획 + 요인 합 − 실적이 0임을 매번 보여 줍니다. 환율 요인은 반올림 차이를 흡수해 합이 정확히 맞도록 했습니다.

해설과 보고서

숫자는 서비스가 계산하고 문장은 규칙으로 만든 초안입니다.

대주나 통화 같은 묶음 기준을 바꾸면 해설도 바뀝니다. 문장은 점검 필요 · 확인 필요 표현만 쓰며 원인을 단정하지 않습니다.

서버에 파일을 남기지 않고 내려받습니다. 내용은 해설과 같은 근거 숫자입니다.

에이전트 — 한도를 지켜 보는 점검

감시 규칙 4개를 하루 한 번 점검합니다. 같은 날 두 번째 실행은 안내와 함께 막힙니다. 걸린 항목은 읽음 처리할 수 있고 활동 기록에 실행 이력이 남습니다.

보기 저장과 복원

기본 보기로 정하면 다음에 그 모양으로 시작하고, 자동 조회를 켜 두면 열자마자 조회합니다. 기본 배치로 되돌리는 버튼이 함께 있습니다.

좁은 화면과 한계

좁은 화면에서는 표를 가로로 밀어 보고 차트는 표 아래로 내려갑니다. 표의 행이 250개를 넘으면 그리지 않고 행 축을 줄이거나 필터를 걸라는 안내를 보여 줍니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 큐브(CubeSet)와 필요하면 계획(PlanSet)을 한 번 읽습니다. 이후 축 이동 · 측정값 · 값 필터는 브라우저의 피벗 계산이 처리합니다. 칸을 눌렀을 때만 원천 라인을, 차이 모드에서만 요인분해를 서비스에 다시 요청합니다. 쓰기는 변동 사유 · 보기 저장 · 에이전트 실행 세 곳뿐입니다.

점검 판단 기준

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조건 영역은 접힌 상태로 시작하고, 표는 가로 스크롤로 보며, 차트는 표 아래에 놓입니다. 기능은 같습니다.

파일 구성

Component.js · manifest.json · index.html
controller/  화면 흐름
view/        메인 화면 + 대화상자 8개
model/       피벗 · 차트 · 서식 · 보기 저장 · PPT 만들기
odata/       OData 서비스 선언 · 서비스 로직 · 계산 모듈 · 샘플 JSON
i18n/ · css/

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회와 점검 관점을 더해 확장합니다. 표준을 대체하지 않으며 표준에 남겨 둘 일(감사 · 공시 · 세무 신고 대응)은 그대로 표준에 둡니다.

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

T-code 별 연계 지점

운영으로 전환할 때 기존 표준 리포트를 없앨 필요는 없습니다. 표준 리포트는 그대로 두고 이 화면은 같은 숫자를 다른 축으로 확인하는 데 씁니다.

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

표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 정해진 보고서를 안정적으로 배포하는 데 강합니다. 이 화면은 그 앞 단계, 즉 축을 바꿔 가며 숫자를 점검하고 요인으로 나누어 보는 자리에 둡니다. 어떤 Fiori 앱이 같은 범위를 이미 제공하는지는 사용 중인 릴리스에서 확인이 필요합니다.

분석 지표 정의

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

CDS 구성 — 최대한 자세히

화면이 읽는 OData 서비스를 운영 원천으로 바꿀 때의 CDS 구성입니다. 아래는 구성 스케치이며, 확인하지 못한 표준 뷰와 필드는 “확인 필요”로 표시했습니다.

뷰 레이어 구성

① 약정 매핑 테이블

이 테이블에서 약정이 어느 대주 · 상품 · 금리 유형 · 만기 구간에 속하는지가 결정됩니다. 분류가 바뀔 때 코드를 고치지 않고 이 테이블만 고치므로, 운영에서 가장 먼저 합의해야 하는 자리입니다.

@EndUserText.label: '차입 약정 매핑 — 약정 · 대주 · 상품 · 금리 유형 · 만기 구간'
@AbapCatalog.enhancement.category: #NOT_EXTENSIBLE
@AbapCatalog.tableCategory: #TRANSPARENT
@AbapCatalog.deliveryClass: #C
@AbapCatalog.dataMaintenance: #ALLOWED
define table zdebt_loanmap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key loan_no    : abap.char(10) not null;      " 약정 번호
  bank_id        : abap.char(6);                " 대주(은행 · 시장)
  prod_type      : abap.char(3);                " FAC / WCL / TRF / BND / ABS / LSE
  rate_type      : abap.char(3);                " FIX / CDL / SOF
  mat_bucket     : abap.char(2);                " M1 ~ M4 (계약 만기 구간)
  gl_account     : saknr;                       " 차입금 계정
}

② 차원 뷰 — 약정

약정 번호를 키로 대주 · 상품 · 금리 유형 · 만기 구간을 차원으로 내보냅니다. 큐브와 쿼리가 모두 이 뷰를 거치므로 차원 이름이 한곳에서 정해집니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '차입 약정 차원'
@ObjectModel.usageType: { serviceQuality: #A, sizeCategory: #S, dataClass: #CUSTOMIZING }
@Analytics.dataCategory: #DIMENSION
define view entity ZI_DebtLoan
  as select from zdebt_loanmap as m
  association [0..1] to I_CompanyCode as _Company on _Company.CompanyCode = $projection.CompanyCode
{
  @ObjectModel.text.element: ['LoanText']
  key m.loan_no    as Loan,
  key m.bukrs      as CompanyCode,
      m.bank_id    as Bank,
      m.prod_type  as Product,
      m.rate_type  as RateType,
      m.mat_bucket as MaturityBucket,
      m.gl_account as GLAccount,
      _Company
}

③ 원천 라인 뷰 — 차입금 전표

표준 전표 라인 뷰에 약정 차원을 붙이고 증가 · 감소 방향을 한 번만 정합니다. 드릴스루가 합계를 맞추려면 방향 판정이 큐브와 같아야 하므로 이 뷰 하나에서만 부호를 정합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '차입 원천 라인'
@ObjectModel.usageType: { serviceQuality: #C, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZI_DebtItem
  as select from I_JournalEntryItem as j
  inner join     ZI_DebtLoan        as l on  l.CompanyCode = j.CompanyCode
                                         and l.GLAccount   = j.GLAccount
{
  key j.CompanyCode,
  key j.FiscalYear,
  key j.AccountingDocument,
  key j.LedgerGLLineItem,
      j.PostingDate,
      j.TransactionCurrency,
      l.Loan,
      l.Bank,
      l.Product,
      l.RateType,
      l.MaturityBucket,
      @Semantics.amount.currencyCode: 'TransactionCurrency'
      j.AmountInTransactionCurrency,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      j.AmountInCompanyCodeCurrency,
      j.CompanyCodeCurrency,
      // 차입 증가는 +, 상환은 − : 대변 잔액 계정이므로 부호를 한 번만 뒤집는다
      case j.DebitCreditCode when 'H' then 'I' else 'E' end as Direction
}

④ 큐브 — 실적 월 집계

기간 · 약정 · 통화 단위로 순증감을 합산합니다. 통화별 합산을 유지하는 이유는 환산 효과를 따로 보기 위해서입니다. 화면의 큐브 합계 = 원천 라인 합계 대사가 이 뷰에서 성립합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '차입 큐브 — 기간 × 약정 × 통화 월 집계'
@Analytics.dataCategory: #CUBE
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XL, dataClass: #MIXED }
define view entity ZI_DebtCube
  as select from ZI_DebtItem
  association [1..1] to ZI_DebtLoan as _Loan
    on _Loan.Loan = $projection.Loan and _Loan.CompanyCode = $projection.CompanyCode
{
  key CompanyCode,
  key left(cast(PostingDate as abap.char(8)), 6)  as Period,
  key Loan,
  key TransactionCurrency                          as Currency,
      Bank,
      Product,
      RateType,
      MaturityBucket,
      @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
      @DefaultAggregation: #SUM
      sum(case Direction when 'I' then AmountInCompanyCodeCurrency
                         else - AmountInCompanyCodeCurrency end)  as NetFlow,
      CompanyCodeCurrency,
      @DefaultAggregation: #SUM
      count( * )                                                  as LineCount,
      _Loan
}
group by CompanyCode, left(cast(PostingDate as abap.char(8)), 6),
         Loan, TransactionCurrency, Bank, Product, RateType, MaturityBucket, CompanyCodeCurrency

⑤ 큐브 — 계획 월 집계

계획 버전별 월 계획 금액을 같은 차원으로 내보냅니다. 계획 원천은 운영 환경에 따라 다르므로 확인 필요입니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '차입 계획 큐브 — 계획 버전별 월 집계'
@Analytics.dataCategory: #CUBE
define view entity ZI_DebtPlanCube
  as select from fclm_plan_item as p       // 자금 계획 항목 — 운영 원천은 확인 필요
{
  key p.bukrs                          as CompanyCode,
  key p.plan_version                   as Version,
  key left(cast(p.plan_date as abap.char(8)), 6) as Period,
  key p.loan_no                        as Loan,
      p.currency                       as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      @DefaultAggregation: #SUM
      p.plan_amount                    as PlanNetFlow
}

⑥ 쿼리 — 다차원 분석

행 · 열 · 자유 축과 필터를 정해 분석 앱에서 바로 열리게 합니다. 기간은 필수 구간 필터, 대주는 다중 선택으로 두어 화면의 조회 조건과 같은 모양을 맞췄습니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '차입 구조 다차원 분석 쿼리'
@Analytics.query: true
@UI.headerInfo: { typeName: '차입', typeNamePlural: '차입 구조' }
define view entity ZC_DebtStructureQuery
  as select from ZI_DebtCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true, mandatory: false }
  Bank,
  @AnalyticsDetails.query.axis: #ROWS
  Product,
  @AnalyticsDetails.query.axis: #COLUMNS
  @Consumption.filter: { selectionType: #INTERVAL, mandatory: true }
  Period,
  @AnalyticsDetails.query.axis: #FREE
  Currency,
  @AnalyticsDetails.query.axis: #FREE
  MaturityBucket,
  @Semantics.amount.currencyCode: 'CompanyCodeCurrency'
  @AnalyticsDetails.query.axis: #COLUMNS
  NetFlow,
  CompanyCodeCurrency
}

⑦ 권한 — 회사코드

집계 뷰에 권한을 걸지 않고 드릴스루에만 걸면 뺄셈으로 합계가 새어 나갑니다. 쿼리 단계에 걸어 보이는 범위가 합계에도 똑같이 적용되게 합니다.

@EndUserText.label: '차입 구조 조회 권한 — 회사코드 · 대주'
@MappingRole: true
define role ZC_DebtStructureQuery {
  grant select on ZC_DebtStructureQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

쿼리와 약정 차원을 노출합니다. 바인딩을 OData V2 로 게시하면 화면의 manifest 서비스 주소만 바꾸면 됩니다.

@EndUserText.label: '차입 구조 분석 서비스'
define service ZUI_DebtStructure {
  expose ZC_DebtStructureQuery as DebtStructure;
  expose ZI_DebtLoan           as Loan;
}

// Service Binding : OData V2 - UI 로 게시. 화면의 manifest 서비스 주소만 이 바인딩 주소로 바꾼다.

운영 시점에 해야 할 일

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

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

의도적 예외는 0건입니다. 샘플 데이터 기준의 결과이며 운영 데이터에서는 다시 확인해야 합니다.

운영 데이터로 갈 때

차입 전표는 수가 많지 않아 큐브는 월 단위 집계로 충분하지만, 전표가 수천만 건인 환경에서는 집계를 데이터베이스 안에서 끝내고 기간을 필수 조건으로 받아야 합니다. 화면은 큐브를 한 번 읽어 브라우저에서 계산하므로 큐브 행 수에 상한(화면에서 표 행 250개)을 두었고, 원천 라인은 칸을 눌렀을 때만 읽습니다. 인덱스는 회사코드 · 전기일 · 약정 순으로 두고, 응답 시간 목표는 조회 3초 · 칸 상세 2초 안팎으로 잡는 것을 권합니다(가정값).

자주 묻는 질문 — 최대한 자세히

도입 전에 가장 자주 나오는 질문을 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영