금융상품 신용위험 집중도 공시 점검 — 업종·지역·상품유형·그룹 기준으로 노출을 다시 모아 정책 임계와 공시 초안에 맞춰 보는 화면

개발 배경 — 이 앱을 사용해야 하는 이유

금융자산의 신용위험은 한 거래상대방의 장부금액만 봐서는 드러나지 않는 구석이 있습니다. 여러 상대방이 같은 업종에 있거나 같은 나라에 있거나 같은 그룹에 속해 있으면, 한 곳이 흔들릴 때 함께 흔들리는 노출이 한꺼번에 커집니다. IFRS 7 금융상품: 공시(K-IFRS 제1107호)는 이런 신용위험 집중도를 어떻게 식별했는지 설명하고, 집중도를 만드는 공통 특성별로 노출을 공시하도록 요구합니다. 결산 때 회계팀이 받는 질문은 늘 비슷합니다. 어느 업종·지역·상품유형에 노출이 쏠려 있는가, 같은 그룹으로 묶으면 어디가 커지는가, 공시 초안의 금액이 장부에서 다시 모은 금액과 맞는가.

지금 이 세 질문은 고객·공급업체 마스터, 원장 조회 화면 여러 개, 엑셀 집계표로 흩어져 있습니다. 거래상대방이 수십 곳이면 버티지만 그룹 관계가 얽히고 축이 늘면 합산이 사람 손을 탑니다. 어디까지 확인했는지도 남지 않습니다. 이 앱은 거래상대방 한 곳 한 곳을 총장부금액 · 손실충당금 · 부외 노출 · 익스포저 · 단독 비중 · 그룹 합산 비중으로 한 줄에 놓고, 임계를 넘는 곳과 공시 초안이 어긋난 곳만 점검 코드로 가려 줍니다.

개별로는 작아 보여도, 같은 그룹으로 묶으면 커진다

이 사례 데이터에서 다솔산업그룹은 세 거래상대방으로 이루어져 있고 구성원 가운데 가장 큰 곳의 단독 비중은 6.34%입니다. 단독으로 보면 눈에 띄지 않지만 그룹으로 합치면 익스포저 181.9억, 전체의 16.29%로 그룹 임계(15%)를 넘습니다. 표준 화면에는 거래상대방을 그룹으로 묶어 비중을 보여 주는 곳이 없어 보통 엑셀로 합칩니다. 이 앱은 그룹 합산 순위를 따로 두고, 이런 경우에 점검 코드 G01 을 붙여 줍니다. 가람금융그룹처럼 구성원 한 곳 자체가 이미 단독 임계(10%)를 넘는 경우는 C01 입니다.

업종·지역·상품유형은 같은 합계를 세 번 나눠 본 것이다

세 축은 모두 같은 거래상대방 26곳, 같은 익스포저 1,116.5억을 서로 다른 기준으로 나눈 것이라 어느 축으로 합쳐도 총합이 같아야 합니다. 이 사례에서는 금융업 38.31%, 국내 77.51%, 매출채권 54.48%가 각 축의 정책 임계(35% · 60% · 50%)를 넘었습니다. 축을 엑셀에서 세 번 따로 집계하다 보면 한 곳을 빠뜨리거나 두 번 넣는 일이 생깁니다. 이 앱은 세 축의 합이 거래상대방 합과 같은지를 조회할 때마다 다시 확인합니다.

공시 초안은 재계산과 달라지기 쉽다

공시 초안은 결산 막바지에 사람이 채우는 숫자라 장부에서 다시 모은 금액과 어긋나기 쉽습니다. 사례에서는 업종 축의 건설업이 초안 77.5억, 재계산 106.0억으로 28.5억 모자라고, 지역 축의 기타 지역은 초안이 3억 많습니다. 어느 상대방이 빠졌거나 두 번 들어갔는지를 찾는 일이 어렵습니다. 이 앱은 축 항목마다 초안과 재계산의 차이를 나란히 놓고 D01 을 붙입니다.

사용 방법

1. 조회조건 입력 — 기준 연월(6자리, 필수)을 넣습니다. 업종·지역·상품유형·만기일 기간·점검 코드·점검 결과는 선택이며 "전체"는 조건을 걸지 않는다는 뜻입니다.
2. 조회 — 조회 버튼은 조회조건 줄의 오른쪽 끝에 있습니다. 기준 연월 칸에서 Enter 를 눌러도 같은 조회가 실행되고, 처음 열 때는 기준 연월 202412 로 자동 조회합니다.
3. 요약 확인 — 상단 숫자 8개(거래상대방 건수·익스포저 합계·순장부금액 합계·최대 그룹 비중·그룹 집중도 지수·임계 초과 집중 항목 수·그룹 합산 시 초과 후보 수·정합성 대사 차이 건수)를 먼저 봅니다.
4. 탭 이동 — 거래상대방 명세 → 축별 집중도 → 그룹 합산 상위 → 대사 결과 순서로 봅니다.
5. 행 클릭 상세 — 거래상대방 명세에서 행을 누르면 총장부금액에서 익스포저까지 산식 줄과 그룹 합산 비중, 점검 코드가 상세 창으로 열립니다.

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

리포트에서 가장 비싼 질문은 "이 숫자 맞아?" 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 검증용 샘플 데이터 전수로 돌렸습니다. 정합성 대사는 화면 안의 집계끼리 맞추는 것이라 차이가 곧 화면의 오류이고, 장부 점검 대사는 재무상태표와 공시 초안을 맞추는 것이라 차이가 곧 확인할 곳의 수입니다.

정합성 대사 7개는 모두 차이 0 입니다(79건 검사). 장부 점검의 차이 2건은 의도적으로 넣은 예외입니다. 이 밖에 단독 비중이 임계 이상인 1곳(가람은행, C01), 그룹으로 묶으면 임계를 넘는 4곳(가람캐피탈과 다솔산업그룹 소속 3곳, G01), 업종·지역 분류가 비어 있는 1곳(U01)이 점검 코드로 정확히 걸러지는지도 전수로 확인했습니다. 화면 쪽은 별도로 브라우저 자동화로 조회·탭 이동·행 상세·날짜 필터·CSV 내려받기를 돌려 요약 숫자와 표의 합계가 같은지 확인했습니다.

무엇으로 만들었나

앱 정보

실행 화면

실제로 돌아가는 화면 7종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리인지 아래에 적었습니다. 숫자는 모두 같은 검증용 샘플 데이터에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다. 거래상대방 이름은 모두 가상입니다.

처음 열었을 때

조회조건, 요약 숫자 8개, 탭 4개가 한 화면에 세로로 놓입니다. 열자마자 기준 연월 202412 로 조회되어 빈 화면을 먼저 보는 일이 없습니다.

위쪽 안내 띠는 이 화면이 점검용이며 집중도 공시 여부와 범위의 최종 판단은 회사와 감사인이 한다는 취지를 먼저 밝힙니다. 조회조건은 한 줄에 놓이고 조회 버튼은 그 오른쪽 끝에 있습니다. 요약 숫자는 거래상대방 26건, 익스포저 합계 1,116.5억, 순장부금액 합계 1,082.5억, 최대 그룹 비중 18.29%, 그룹 집중도 지수(HHI) 987이며, 임계 초과 집중 항목 5개와 그룹 합산 시 초과 후보 1건, 정합성 대사 차이 0건이 이어집니다. 탭 이름 위의 작은 숫자는 그 탭에 담긴 행 수입니다.

축과 그룹으로 묶어 보기

상대방 한 곳씩 보기 전에 축과 그룹으로 묶은 숫자를 먼저 봅니다. 같은 26곳을 서로 다른 방향으로 나눠 본 표입니다.

금융업 38.31%(임계 35%), 국내 77.51%(임계 60%), 매출채권 54.48%(임계 50%)가 임계 이상이라 "초과"와 점검 필요로 표시됩니다. 건설업과 기타 지역 두 줄은 비중은 임계 아래지만 공시 초안 금액이 재계산 익스포저와 달라(건설업 −28.5억, 기타 지역 +3억) 점검 코드 D01 이 붙습니다. 임계 숫자는 점검용 값이며 기준서가 정한 숫자가 아닙니다.

1위 가람금융그룹(가상)은 비중 18.29%로 그룹 임계 15%를 넘고 구성원 한 곳의 단독 비중도 13.43%라 C01 입니다. 2위 다솔산업그룹(가상)은 16.29%이지만 구성원 최대 단독 비중은 6.34%라 개별로는 눈에 띄지 않던 노출이 합쳐서 임계를 넘는 경우이며 G01 입니다. 누적 비중 열은 상위 몇 개 그룹이 전체의 몇 %를 차지하는지 한눈에 읽게 합니다.

점검 코드로 좁히고 한 곳씩 열어 보기

후보를 가린 뒤 상세 창에서 산식 줄까지 내려갑니다.

조회조건의 점검 코드 칸에서 G01 을 고르고 조회 버튼을 누르거나 기준 연월 칸에서 Enter 를 누른 결과입니다. 거래상대방 명세 탭 이름 위의 숫자가 26에서 4로 줄어듭니다. 개별 비중은 10% 미만인데 같은 그룹 합산으로는 15% 이상인 상대방이 어디인지 가리는 첫 단계로 쓰고, "전체"로 되돌리려면 초기화 버튼을 누릅니다.

예시 E005 는 총장부금액 72억에서 손실충당금 1.2억을 빼 순장부금액 70.8억을 구하고, 미사용 약정 등 부외 노출 0을 더해 익스포저 70.8억이 됩니다. 단독 비중은 6.34%이지만 소속 그룹 합산 익스포저 181.9억, 그룹 합산 비중 16.29%가 함께 보이고 점검 코드는 G01 입니다. 산식 줄의 합이 익스포저와 같은지 그 자리에서 확인합니다.

대사와 기간 조회

숫자의 신뢰와 조회 조건의 동작을 확인하는 화면입니다.

정합성 대사는 모두 차이 0입니다. 장부 점검 대사 중 재무상태표 금융자산 대사와 상품유형 축 초안 대사는 차이가 없고, 업종 축 초안 대사(최대 차이 28.5억)와 지역 축 초안 대사(최대 차이 3억)가 각각 1건씩 차이로 나옵니다. 이 두 건은 일부러 넣은 예외이며, 화면 오류와 섞이지 않도록 정합성 대사와 따로 둡니다.

날짜는 서버가 이해하는 날짜 형식으로 변환해 필터로 보내므로 화면 표시 형식과 상관없이 같은 결과가 나옵니다. 요약 숫자 가운데 그룹·축 기반 4개는 조회조건과 관계없이 기준 연월 전체를 기준으로 하기 때문에 이 조회에서도 값이 바뀌지 않습니다. 기간 조건은 거래상대방 명세에만 적용됩니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 조회조건이 필터로 만들어져 서비스에 전달되고, 서비스는 거래상대방별로 순장부금액과 익스포저를 구한 뒤 단독 비중과 소속 그룹 합산 비중, 점검 코드를 붙여 돌려줍니다. 축별·그룹별 집계와 대사는 그 결과를 묶어 만듭니다. 판정은 아래 순서로 하나만 표시합니다.

같은 행에 여러 조건이 겹치면 표의 위에서부터 순서대로 하나만 표시합니다(축 항목은 D01 이 우선). 결과 문구는 "점검 필요"와 "확인 필요"로만 쓰고 확정적인 판단 문구는 쓰지 않습니다. 처리 순서는 이렇습니다.

1. 익스포저 — 순장부금액 = 총장부금액 − 손실충당금, 익스포저 = 순장부금액 + 부외 노출.
2. 단독 비중 — 거래상대방 익스포저 ÷ 총 익스포저 × 100.
3. 그룹 합산 — 같은 그룹 코드의 익스포저를 더하고 총 익스포저로 나눕니다.
4. 축별 집계 — 업종·지역·상품유형 코드별 합과 비중, 정책 임계와 공시 초안 비교.
5. 집중도 지수 — 그룹 비중(%)을 제곱해 더한 값(HHI).
6. 대사 — 정합성 7개와 장부 점검 4개.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건 줄과 요약 숫자는 줄바꿈으로 아래로 흘러내리고, 표는 폭이 모자라면 가로로 스크롤됩니다. 상세 창도 화면 폭에 맞춰 줄어듭니다. 요약 숫자와 탭 이름의 행 수만 먼저 훑는 용도로는 좁은 화면으로도 충분하고, 건별 확인은 넓은 화면을 권합니다.

파일 구성

index.html            앱 진입점
readme.html           설명서
Component.js · manifest.json
controller/           BaseController.js · Main.controller.js
view/                 Main.view.xml · DetailDialog.fragment.xml
model/                formatter.js · ErrorHandler.js
css/ · i18n/          style.css · i18n_ko.properties
odata/                OData 서비스 정의 · 서비스 구현 · 데이터
media/                intro.mp4 · intro_poster.jpg

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 법정 공시와 감사 대응을 대신하지 않으며, 표준에서 원천을 확인하러 가는 길을 짧게 만드는 데 목적이 있습니다.

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

T-code 별 연계 지점

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

이 화면은 분석용 CDS 뷰 위에서 도는 점검 화면의 자리에 놓입니다. 원장과 마스터를 읽는 기준 뷰, 상대방별 익스포저 뷰, 축별·그룹별 집계 뷰, 점검 쿼리 뷰가 쌓이고 화면은 마지막 쿼리를 서비스로 읽습니다. 표준 분석 앱을 대체하기보다 공시 초안을 점검하는 한 가지 일에 맞춘 좁은 화면입니다.

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

정책 임계(상대방 10% · 그룹 15% · 업종 35% · 지역 60% · 상품유형 50%)는 테이블 값이고, 업종·국가·상품유형 변환은 매핑 테이블이며, 그룹 키는 마스터 필드나 회사 그룹표입니다. 이 세 곳이 회사마다 달라지는 자리이고 화면 코드는 그대로 둡니다.

요구사항 매핑

CDS 구성

앱의 서비스 구현은 검증용 샘플 데이터 위에서 돌고, 운영 시스템에서는 아래 CDS 뷰가 같은 모양의 데이터를 내려보내는 것을 전제로 합니다. 뷰는 기준(정책·변환) → 차원(상대방별 익스포저) → 큐브(축별·그룹별 집계) → 점검 쿼리 → 권한 → 서비스 순서로 쌓습니다. 표준 CDS 뷰 이름은 확인한 것만 쓰고, 확인하지 못한 곳은 원천 테이블 기준으로 적었습니다.

뷰 레이어 구성

① 축별 정책 임계 테이블 (ZCRCONC_POLICY)

임계는 코드가 아니라 데이터로 둡니다. 여기서 정해진 값이 화면의 "정책 임계" 열과 C01 판정의 유일한 근거이며, 값을 정하는 일은 회계팀·리스크 담당·감사인의 몫입니다. 화면에 있는 숫자는 샘플 값입니다.

@EndUserText.label : '신용위험 집중도 정책 임계'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcrconc_policy {
  " ─── 이름 : ZCRCONC_POLICY
  " ─── 역할 : 구분(CPT 상대방 / GRP 그룹 / IND 업종 / REG 지역 / INS 상품유형)별 정책 임계(%)
  " ─── 이렇게 나눈 이유 : 임계가 바뀔 때 뷰 코드를 건드리지 않고 이 테이블 행만 고치기 위해
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key axis       : abap.char(3) not null;
  thresh_pct     : abap.dec(7,2);
  valid_from     : abap.dats;
}

② 상대방별 익스포저 (ZI_CrCptyExposure)

원장 금융자산을 상대방별로 한 번만 합산하는 층입니다. 마스터의 업종·국가·그룹 키는 회사 분류표로 변환해야 하고, 미사용 약정 같은 부외 노출은 회사가 관리하는 약정 대장에서 오므로 그 연결은 확인 필요입니다. 금융자산 계정 범위는 회사 계정체계에 맞춰 조정합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: '신용위험 익스포저 거래상대방 집계'
define view entity ZI_CrCptyExposure
  as select from ZI_CrFinAssetLedger as L        -- 금융자산 원장(ACDOCA 기반) 뷰, 확인 필요
  association [0..1] to kna1 as _Cust on _Cust.kunnr = L.Customer
  association [0..1] to zcrconc_map as _Map on _Map.brsch = _Cust.brsch
{
  key L.CompanyCode,
  key L.FiscalYear,
  key L.Counterparty,
      _Map.industry_key                            as IndustryKey,
      _Cust.land1                                  as Country,
      _Cust.konzs                                  as GroupKey,
      @Semantics.amount.currencyCode: 'Currency'
      sum( L.GrossCarrying )                       as GrossCarrying,
      @Semantics.amount.currencyCode: 'Currency'
      sum( L.LossAllowance )                       as LossAllowance,
      @Semantics.amount.currencyCode: 'Currency'
      sum( L.GrossCarrying - L.LossAllowance )     as NetCarrying,
      L.Currency
}
group by L.CompanyCode, L.FiscalYear, L.Counterparty,
         _Map.industry_key, _Cust.land1, _Cust.konzs, L.Currency

③ 축별 집중도 (ZC_CrAxisConc)

업종·지역·상품유형 세 축을 한 뷰에서 만듭니다. 세 축의 합이 상대방 합과 같아야 한다는 정합성 대사가 이 뷰를 기준으로 돌아갑니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '축별 신용위험 집중도'
define view entity ZC_CrAxisConc
  as select from ZI_CrCptyExposure as X
  inner join zcrconc_policy as P
    on P.bukrs = X.CompanyCode and P.axis = 'IND'
{
  key X.CompanyCode,
  key X.FiscalYear,
  key 'IND'                                        as Axis,
  key X.IndustryKey                                as AxisKey,
      count( distinct X.Counterparty )             as Cnt,
      sum( X.NetCarrying )                         as Exposure,
      P.thresh_pct                                 as ThreshPct
}
group by X.CompanyCode, X.FiscalYear, X.IndustryKey, P.thresh_pct
-- 지역(REG)·상품유형(INS) 축은 같은 모양의 뷰를 UNION 으로 합친다.
-- 비중은 쿼리 뷰에서 총 익스포저 대비로 구한다.

④ 그룹별 집중도 (ZC_CrGroupConc)

같은 그룹 코드의 익스포저를 더하고, 구성원 중 가장 큰 단독 비중을 함께 가져와 C01 과 G01 을 가릅니다. 그룹 키가 비어 있는 상대방은 자기 자신을 한 그룹으로 취급하는 규칙도 이 층에 둡니다.

@EndUserText.label: '그룹별 신용위험 집중도'
define view entity ZC_CrGroupConc
  as select from ZI_CrCptyExposure
{
  key CompanyCode,
  key FiscalYear,
  key coalesce( GroupKey, Counterparty )           as GroupKey,
      count( distinct Counterparty )               as MemberCnt,
      sum( NetCarrying )                           as GroupExposure,
      max( NetCarrying )                           as MaxMemberExposure
}
group by CompanyCode, FiscalYear, coalesce( GroupKey, Counterparty )

⑤ 점검 쿼리 (ZC_CrConcCheckQuery)

점검 코드 판정을 이 뷰에 모읍니다. 판정 순서는 화면 설명의 표와 같습니다.

@EndUserText.label: '신용위험 집중도 점검 쿼리'
@Analytics.query: true
define view entity ZC_CrConcCheckQuery
  as select from ZC_CrGroupConc as G
{
  key G.CompanyCode,
  key G.FiscalYear,
  key G.GroupKey,
      G.GroupExposure,
      cast( G.GroupExposure * 100 / $session.total_exposure as abap.dec(7,2) ) as Share,
      case
        when G.MaxMemberExposure * 100 / $session.total_exposure >= 10 then 'C01'
        when G.GroupExposure      * 100 / $session.total_exposure >= 15 then 'G01'
        else 'I00'
      end                                          as CheckCode
}
-- $session.total_exposure 는 설명용 표기이다. 실제로는 총 익스포저를 구하는 뷰를 조인한다.

⑥ 접근 제어 (DCL)

회사코드 권한을 점검 쿼리에 겁니다. 권한 기준은 도입 전에 보안 담당과 정합니다.

@EndUserText.label: '신용위험 집중도 접근 제어'
@MappingRole: true
define role ZC_CrConcCheckQuery {
  grant select on ZC_CrConcCheckQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의 (ZUI_CrConc)

화면이 읽는 뷰만 서비스로 내보냅니다. 서비스 바인딩은 OData V2 로 게시합니다.

@EndUserText.label: '신용위험 집중도 서비스'
define service ZUI_CrConc {
  expose ZC_CrConcCheckQuery as ExpSet;
  expose ZC_CrAxisConc       as ConcSet;
  expose ZC_CrGroupConc      as TopSet;
}

운영 시점에 해야 할 일

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

운영 데이터로 갈 때

거래상대방 수는 수십~수만 곳까지 다양하고, 부담은 원장 합계에서 옵니다. 원장 합산은 기간·회사코드·계정 범위를 필수 조건으로 걸어 서버 안에서 끝내고, 상대방별 합계만 내려보냅니다. 축별·그룹별 집계는 서버에서 끝내므로 화면에는 상대방 수만큼의 행과 소수의 집계 행만 올라옵니다. 응답 시간 기준은 운영 데이터로 측정해 정해야 하므로 확인 필요입니다.

자주 묻는 질문

도입 검토 자리에서 자주 나오는 질문 28개를 주제별로 정리했습니다.

숫자와 판정

화면과 조작

표준과의 관계·데이터

도입과 운영