원가가 올랐다는데 어느 자재 때문일까? 마진 원인을 끝까지 쪼개는 방법

월 마감 회의에서 자주 나오는 질문이 있습니다. "이번 달 매출총이익이 줄었다는데, 원가가 오른 건가요? 그렇다면 어느 자재 때문인가요?" 손익계산서는 "매출원가가 늘었다"까지는 알려 주지만, 그 아래 어떤 차이가 어떤 자재와 원가센터에서 생겼는지는 따로 찾아야 합니다. 이 글은 저희가 테스트 환경의 손익 데이터로 마진 드라이버 트리를 직접 설계하고 확장하며 확인한 원칙을 정리합니다. 테스트 데이터의 수치는 실제 기업 환경을 대표하지 않으므로, 데이터 상태를 나타내는 수치는 싣지 않고 실제로 나타난 패턴과 점검 방법만 정리합니다.

같은 "매출총이익"인데 숫자가 다르다

연재 1회에서 AI를 위한 데이터 플랫폼의 두 번째 층을 의미 층이라고 불렀습니다. 숫자가 무엇을 뜻하는지 정의해 두는 층입니다. 마진 분석에서 이 층이 가장 먼저 부딪히는 문제는 의외로 단순합니다. 매출총이익을 어떻게 정의하느냐입니다.

어느 정의가 맞느냐는 회사마다 다릅니다. 문제는 정의가 다르면 숫자의 방향까지 달라질 수 있다는 점입니다. 저희가 같은 데이터로 정의만 바꿔 계산해 보니, 표준 정의로는 손실이던 매출총이익이 원가차이와 정산을 포함하자 이익으로 부호가 뒤집혔습니다. 원가 정산분의 비중이 크면 "원가차이만 포함인가, 정산까지 포함인가"라는 질문 하나에 결론이 갈립니다.

사람이 보는 보고서라면 각주 하나로 넘어갈 수 있는 차이지만, AI 에이전트에게는 치명적입니다. 정의를 명시하지 않은 질문에 에이전트가 어떤 정의로 답할지 정해져 있지 않으면, 같은 질문에 날마다 다른 답이 나올 수 있습니다. 그래서 첫 번째 원칙은 이렇습니다.

• 매출총이익의 정의를 여러 개 두되, 회사의 정본 하나를 "기본값"으로 표시한다.

• 정의마다 어떤 손익 항목(레벨)이 들어가는지를 데이터로 선언해 둔다.

드라이버 트리는 세 층으로 그린다

정의가 정해지면 그 아래를 쪼갤 차례입니다. 저희는 수익성 분석(CO-PA) 손익 라인을 세 층으로 나눴습니다.

• Level 0 — 지표: 매출총이익(정의별)

• Level 1 — 손익 항목: 매출, 매출차감, 매출원가, 원가차이, 원가 정산, 원가요소 미지정 매출원가, 재고 손실 등

• Level 2 — 원인 유형: 매출원가 4종(일반 매출원가, 재공품 정산, 원재료, 반제품), 원가차이 5종(실제원가 정산차이 두 종류, 생산오더 차이, 구매가격차이, 액티비티 평가차이), 그리고 원가 정산·원가요소 미지정·재고 손실 각 1종 — 모두 12가지

Level 2의 재료는 SAP가 이미 상당 부분 준비해 둡니다. S/4HANA는 생산오더를 정산할 때 원가차이를 차이 유형별로 서로 다른 계정에 나눠 전기할 수 있고(variance split), 머티리얼 레저의 실제원가 계산은 가격차이를 정산 단계별로 구분합니다. 드라이버 트리를 설계하는 일은 결국 "어떤 계정이 어떤 원인 유형에 속하는가"를 빠짐없이 매핑하는 일입니다.

처음 만든 팩트 그래프에는 매출원가 가지 4종만 들어 있었습니다. 원가차이 5종을 추가하면 끝날 것 같았지만, 실측해 보니 12가지를 모두 채우려면 원가 정산·원가요소 미지정·재고 손실까지 함께 넣어야 했습니다. 항목을 정할 때는 이름이 아니라 실제 데이터에 존재하는 유형을 먼저 세어 보는 것이 빠릅니다.

직접 확장하며 확인한 것 ① 원가차이는 판매제품에 붙지 않는다

가장 중요한 발견은 차원(축)에 관한 것이었습니다. 매출과 매출원가 라인에는 판매제품과 고객이 잘 붙어 있지만, 원가차이 라인은 사정이 다릅니다. 원가차이는 생산오더와 자재 단위로 계산되어 전기되기 때문에, 차원마다 채워지는 양상이 달라집니다.

원가차이는 "어떤 제품을 팔았나"보다 "어떤 자재를 만들고 샀나, 어느 원가센터에서 생겼나"에 붙는 숫자입니다. 기존 팩트를 판매제품 기준으로만 연결해 두면, 원가차이 라인은 그래프 안에서 고립되어 "어느 자재 때문인가"라는 질문에 답할 수 없습니다.

그래서 팩트에 자재 연결과 원가센터 연결을 새로 추가했습니다. 원가센터는 이미 마스터 그래프에 노드로 있었기 때문에 팩트 쪽에 엣지만 놓으면 됐고, 확장 후 원가센터 엣지 가운데 마스터에 없는 노드를 가리키는 고아는 0건이었습니다. 빈 문자열 코드가 깨진 노드로 만들어지지 않도록 추출 단계에서 걸러 둔 것이 효과를 봤습니다. 이 구조는 지식그래프 글에서 말한 "금액은 SQL로, 관계는 그래프로"의 연장선입니다. 자재에서 BOM과 공급사로 이어지는 관계가 이미 그래프에 있으니, 원가차이에서 공급사까지 한 번에 따라갈 수 있게 됩니다.

직접 확장하며 확인한 것 ② 분류에는 구멍이 있다

계정을 원인 유형에 매핑하고 나서 전수 검사를 해 보니 빈틈이 보였습니다.

• 원가차이 라인 일부가 Level 2 미분류였습니다. 표준원가 가격차이, 외부 제품 평가손실, 일부 액티비티 가격차이 계정이 어느 유형에도 속하지 않았습니다.

• 차변·대변 쌍이 갈라져 있었습니다. 대부분의 차이 유형은 차변과 대변 두 계정이 함께 분류됐는데, 구매가격차이는 대변 계정만 분류되고 차변 계정이 빠져 있었습니다. 이런 결함은 합계만 보면 드러나지 않습니다. 한쪽만 들어가면 금액이 그럴듯하게 나오기 때문입니다.

• 매출원가 쪽에도 미분류 라인이 있었습니다.

교훈은 분명합니다. 매핑표는 한 번 만들고 끝나는 문서가 아니라 검사 대상입니다. "Level 1에는 있는데 Level 2가 비어 있는 라인"과 "쌍을 이루는 계정 중 한쪽만 분류된 경우"를 정기 점검 항목으로 두어야 합니다.

직접 확장하며 확인한 것 ③ 합계 하나가 전체를 덮는다

팩트 범위를 넓히자 새로운 위험이 생겼습니다. 저희 테스트 환경에서는 재고 손실 항목 하나에 비정상적으로 큰 금액이 들어 있었습니다. 운영 환경에서도 특정 항목에 큰 금액이 몰리는 일은 있을 수 있고, 그 항목을 넣은 채로 필터 없이 전체를 합하면 매출총이익이 사실상 그 한 항목의 값이 됩니다. 확장 전에는 "그래프 전체 합 = 매출총이익"이 검산 기준이었는데, 확장 후에는 그 기준이 성립하지 않게 된 것입니다.

저희가 택한 방법은 질의 쪽에 레벨 목록을 적어 두는 대신 Level 1 노드마다 "이 항목이 매출총이익에 들어가는가"를 표시해 두고, 질의가 그 표시로 필터하게 하는 것이었습니다. 정의가 바뀌면 질의를 고칠 필요 없이 그래프의 표시만 바꾸면 됩니다. 합격 기준은 두 가지로 잡았습니다.

1. Level 2 12가지를 모두 순회할 수 있을 것

2. 표시로 필터했을 때 매출총이익이 확장 전 기준선과 소수점까지 같을 것

확장 후 팩트 그래프는 크게 늘었지만 두 기준을 모두 통과했습니다. 필터 없는 대조군 합계가 기준선과 크게 어긋나는 것도 함께 확인해, 표시 필터가 선택이 아니라 필수라는 점을 숫자로 남겼습니다.

직접 확장하며 확인한 것 ④ 축이 열려도 분석 가치는 따로 따져야 한다

원가센터 축을 열고 원가센터별 원가차이를 집계했더니, 원가센터가 붙은 원가차이 라인 대부분이 더미 원가센터 한 곳에 몰려 있었습니다.

테스트 환경의 특성이지만, 운영 환경에서도 임시·더미 마스터에 실제 전기가 쌓이는 일은 드물지 않습니다. 기술적으로 축이 열렸다는 것과 그 축으로 분석할 가치가 있다는 것은 별개입니다. 저희는 이 현상을 "더미·테스트 마스터에 실제 전기"라는 정합성 규칙 후보로 따로 분리했습니다. 정합성 규칙은 다음 회차의 주제입니다.

설계 원칙 정리

도구는 어디까지 해 주나 (2026년 11월 기준)

드라이버 트리라는 개념 자체는 새롭지 않습니다. SAP Analytics Cloud의 밸류 드라이버 트리는 가격·수량 같은 드라이버를 바꿔 매출총이익까지의 파급을 시뮬레이션하는 계획 기능이며, 계획·분석 모델에서 동작하고 라이브 모델에서는 쓸 수 없습니다. 이 글의 드라이버 트리는 방향이 반대입니다. "바꾸면 어떻게 되나"가 아니라 "이미 일어난 차이가 어디서 왔나"를 실적 데이터에서 거슬러 올라가는 용도입니다.

실적 쪽 재료로는 S/4HANA의 원가차이 계정 분할과 머티리얼 레저가 출발점이 되고, 관계를 담는 엔진으로는 SAP HANA Cloud의 지식그래프 엔진(RDF·SPARQL)을 썼습니다. 이 엔진은 HANA Cloud에 내장되어 있어 별도 라이선스 비용이 없다고 안내되어 있습니다. 그 위에서 AI 에이전트가 질문을 받으면, Joule Agent와 MCP 글에서 설명한 것처럼 금액 집계는 서버에서 하고 에이전트는 트리를 따라 다음에 어디를 볼지 결정합니다.

어느 도구를 쓰든 계정과 원인 유형의 매핑, 정의의 기본값, 원가차이 전용 축은 회사가 직접 정해야 합니다. 이 부분이 비어 있으면 AI는 그럴듯하지만 근거를 댈 수 없는 답을 내놓습니다.

시작 전 체크리스트

• 회사의 매출총이익 정본 정의 — 원가차이 포함 여부, 원가 정산 포함 여부

• 원가차이 계정 분할(variance split) 설정 여부와 차이 유형별 계정 목록

• 계정 → Level 1 → Level 2 매핑표와 미분류 라인 비율(건수·금액)

• 차변·대변 쌍 계정이 같은 유형으로 분류되어 있는지

• 원가차이 라인의 자재·원가센터 채움률

• 금액이 지나치게 큰 항목(재고 손실 등)과 검산 기준선

• 더미·임시 마스터에 전기된 금액 비중

마진 드라이버 트리는 의미 층의 대표 사례입니다. 데이터 프로덕트 글에서 원천을 고를 때 채움률을 금액으로 확인하자고 했던 이유가 여기서 드러납니다. 축이 비어 있으면 트리는 중간에서 끊깁니다.

다음 회차에서는 관계 층으로 올라가, AI 도입 전에 ERP 데이터를 점검하는 정합성 진단 규칙을 다룹니다.

마진 분석 고도화, ASPN과 함께 점검하세요

ASPN은 SAP ERP 구축·운영 경험을 바탕으로 관리회계 데이터를 분석과 AI에 쓸 수 있는 형태로 만드는 일을 다루고 있습니다. 이 글의 내용도 저희가 테스트 환경에서 직접 설계하고 검증하며 확인한 것입니다.

• 제공 중 — S/4HANA 관리회계·수익성 분석(CO-PA) 구축과 운영, Datasphere·SAP Analytics Cloud 기반 손익 분석 환경 구축

• 실증 경험·검토 단계 — 손익 지식그래프 위의 마진 드라이버 트리, AI 에이전트를 통한 원가차이 원인 추적

"원가가 왜 올랐나"에 매번 수작업으로 답하고 있다면, 현재 계정 체계와 원가차이 데이터를 기준으로 어디까지 자동으로 쪼갤 수 있는지 함께 점검해 드립니다.

참고

• SAP PRESS Blog, How to Configure Variance Split in SAP S/4HANA

• SAP PRESS Blog, Account-Based CO-PA in SAP S/4HANA: How Margin Analysis Works in the Universal Journal

• SAP PRESS Blog, How to Split Cost of Goods Sold (COGS) with SAP S/4HANA Finance

• SAP Learning, Simulating Data with Value Driver Trees (SAP Analytics Cloud)

• SAP Learning, Multi Model — SAP HANA Cloud Knowledge Graph Engine

글쓴이 Data&AI — ASPN BAC사업부에서 SAP BDC·Datasphere, 지식그래프, Joule·MCP 기반 AI Agent 구축을 다룹니다. 직접 구성하고 검증하며 얻은 실무 경험을 정리해 공유합니다.