국가 배출계수와 국제 DB, 무엇이 다를까? 목적과 적용 기준 정리

배출계수의 목적과 범위

배출계수를 찾다 보면 같은 전력, 연료, 원재료에도 서로 다른 숫자가 나타납니다. 차이는 단순히 ‘국가 계수’와 ‘해외 계수’라는 구분에서만 생기지 않습니다. 각 자료가 만들어진 목적, 적용 지역, 기술 조건, 시스템경계와 기준연도가 다르기 때문입니다.

한국에서는 온실가스종합정보센터(GIR)가 승인 국가 온실가스 배출·흡수계수를 공표하고 있습니다. 국내 법정 보고가 필요한 경우에는 관련 제도의 최신 산정·보고 기준에서 어떤 계수와 방법을 요구하는지 먼저 확인해야 합니다.

국가 계수와 국제 DB

IPCC EFDB는 국가 온실가스 인벤토리 산정을 지원하는 배출계수와 파라미터를 검색할 수 있는 데이터베이스입니다. 영국 정부의 Greenhouse Gas Reporting Conversion Factors는 연료, 전력, 차량, 출장, 화물운송 등 조직의 활동자료를 온실가스 배출량으로 환산하는 데 활용되는 계수를 제공합니다.

Ecoinvent와 같은 LCI 데이터베이스는 원료 채취, 에너지 생산, 중간재 제조, 운송, 폐기 등 제품과 공정의 전과정을 분석하는 데 활용됩니다. EXIOBASE와 같은 EEIO 데이터는 경제 지출과 산업별 환경부하를 연결해 지출 기반 Scope 3 산정이나 초기 스크리닝에 활용할 수 있습니다.

시스템경계와 대표성

두 계수가 모두 kg CO2e/kWh 또는 kg CO2e/kg로 표시된다고 해서 같은 범위를 의미하는 것은 아닙니다. 발전소의 직접 배출만 포함한 전력 계수와 연료의 생산·수송까지 포함한 전과정 전력 계수는 같은 단위라도 계산에 포함되는 배출 범위가 다릅니다.

철강처럼 같은 품목도 고로와 전기로, 재활용 원료 비율, 생산 지역의 전력 믹스와 생산 연도에 따라 배출계수가 달라질 수 있습니다. 계수를 비교할 때는 지역, 기준연도, 기술·공정, 생애주기 단계, 배분 방식·시스템 모델, GWP와 포함 가스를 함께 확인해야 합니다.

산정 목적별 적용 기준

국내 법정 보고에서는 관련 제도가 지정한 공식 계수와 방법을 우선합니다. 해외 사업장의 규제·공시 목적 산정에서도 해당 국가의 공식 계수와 현지 기준을 먼저 확인하는 것이 기본입니다. 글로벌 Scope 3에서는 카테고리와 확보 가능한 활동자료에 따라 공급사 데이터, LCI DB, 운송·에너지 Conversion Factors, EEIO 데이터 등을 활용할 수 있습니다.

제품 PCF나 LCA에서는 기능 단위와 시스템경계에 맞는 LCI 데이터가 필요합니다. 특히 CBAM 내재배출량은 EU 제도에서 정한 별도 산정 규칙을 따르므로 일반적인 LCI DB나 PCF 결과를 그대로 CBAM 신고값으로 간주해서는 안 됩니다.

사내 배출계수 라이브러리

여러 출처의 계수를 함께 사용하는 기업이라면 ‘국내 도시가스-Scope 1-법정 보고’, ‘항공여행-Scope 3 출장’, ‘알루미늄-cradle-to-gate-PCF’처럼 사용 범위를 태그로 관리하면 담당자가 바뀌어도 같은 판단을 재현하기 쉽습니다.

계수값만 저장하기보다 원문 출처, 버전, 접근일, 단위, 지역, 기준연도, 시스템경계, GWP 기준과 라이선스 같은 메타데이터를 함께 관리하는 것이 중요합니다. 상용 LCI DB는 데이터의 외부 제공이나 재배포에 제한이 있을 수 있으므로 사내 시스템에 연결할 때도 사용 조건을 확인해야 합니다.

API 검색과 버전 관리

계수 출처가 많아지면 API나 사내 데이터 계층을 이용해 활동 유형, 품목·연료명, 국가·지역, 기준연도, 단위, 시스템경계와 데이터 출처 같은 조건으로 후보를 검색할 수 있습니다. 이때 사용자가 입력한 용어와 DB의 표준명이 다를 수 있으므로 유사어와 산업·품목 분류를 어떻게 매핑할지도 함께 정해야 합니다.

검색 결과를 계산에 적용할 때는 계수 ID와 데이터 버전, 조회일과 적용 단위를 함께 저장하는 편이 좋습니다. 최신 계수로 자동 치환하기만 하면 과거 산정 결과를 다시 계산했을 때 값이 달라질 수 있으므로, 검증이나 비교가 필요한 결과에는 사용한 버전을 고정해 재현할 수 있어야 합니다.

API가 제공하는 필드와 버전 방식은 서비스마다 다릅니다. 따라서 특정 API의 구조를 그대로 표준으로 간주하기보다 필요한 메타데이터와 검색 조건, 버전 정책을 먼저 정하고 이를 사내 산정 기준과 연결하는 방식이 적절합니다.