"CO2가 뭔지는 알겠는데, Scope 3 Category 7이 뭐냐고요?"

탄소 관리 플랫폼을 개발하면서 가장 힘들었던 건 코드가 아니라 도메인이었다. t_scope3_category7_5_entity.py라는 파일명을 보고 "이게 대체 뭘 관리하는 테이블이지?"라는 질문에서 시작된 도메인 학습기를 공유한다.

1. "Scope가 뭔데?" - 탄소 배출의 3가지 층위

탄소 배출량을 이야기할 때 가장 먼저 마주치는 개념이 GHG Protocol의 Scope 1/2/3이다.

쉽게 비유하면 이렇다:

Scope 비유 실제 예시
Scope 1 내가 직접 피운 담배 공장 보일러, 사업용 차량 연료
Scope 2 내가 쓴 전기를 만들 때 나온 매연 구매 전력, 구매 열/증기
Scope 3 내가 시킨 택배를 배송할 때 나온 매연 출장, 통근, 원재료 운송, 제품 사용...

여기서 충격적인 사실: 대부분의 기업에서 Scope 3이 전체 배출량의 70-90%를 차지한다.

그런데 Scope 3은 무려 15개 카테고리로 나뉜다. Category 1(구매한 제품)부터 Category 15(투자)까지. 우리 프로젝트의 엔티티 파일이 160개가 넘는 이유가 여기에 있었다.

t_scope3_category1_2_entity.py   # 구매 제품/서비스 (서브카테고리 2)
t_scope3_category7_5_entity.py   # 직원 통근 (서브카테고리 5)
t_scope3_category14_entity.py    # 프랜차이즈

Category 7의 정체? **직원 통근(Employee Commuting)**이었다. 직원이 자가용으로 출퇴근할 때 나오는 CO2도 회사 배출량에 포함된다니, 처음 알았을 때 꽤 놀랐다.

2. 일본 회계연도의 함정

개발 초기에 가장 많이 발생한 버그 중 하나: 날짜 처리 오류

일본 회계연도는 4월 1일 ~ 3월 31일이다. 즉, FY2025는 2025년 4월부터 2026년 3월까지다.

# 이렇게 하면 안 된다
fiscal_year = datetime.now().year  # 2026년 1월인데 FY2025에 해당

# 이렇게 해야 한다
def get_fiscal_year(date):
    return date.year if date.month >= 4 else date.year - 1

데이터를 월별로 집계할 때, "12월 데이터"가 어느 회계연도에 속하는지 헷갈리면 리포트 전체가 틀어진다. 탄소 배출 보고는 회계연도 단위로 이루어지기 때문에, 이 실수 하나로 감사(Audit)에서 지적받을 수 있다.

3. 배출계수: 곱셈 하나로 CO2가 나온다

탄소 배출량 계산의 핵심은 놀라울 정도로 단순하다:

CO2 배출량 = 활동량 x 배출계수

예를 들어:

  • 도시가스 10,000 m3 사용 x 2.23 kg-CO2/m3 = 22.3 톤 CO2
  • 전력 500,000 kWh 사용 x 0.441 kg-CO2/kWh = 220.5 톤 CO2

이 "배출계수"(Emission Factor)는 일본 환경성이 매년 갱신하여 공표한다. 우리 시스템에서는 M_emission_factor_by_scope1_and_2 테이블에 에너지원별 계수가 저장되어 있다.

여기서 재미있는 점: 같은 전력이라도 전력회사마다 배출계수가 다르다. 재생에너지 비율이 높은 전력회사의 전기를 쓰면 CO2가 줄어드는 것이다. 이걸 Market-based 방식이라 하고, 전국 평균을 쓰는 건 Location-based 방식이라 한다.

4. 2026년, 탄소 관리의 빅뱅

지금 이 도메인에서 일하는 것은 꽤 운이 좋은 타이밍이다. 2026년에 세 가지 대형 이벤트가 동시에 터졌다:

GX-ETS 의무화 (2026년 4월~)

일본 정부가 드디어 탄소 배출권 거래제를 의무화했다. 연간 10만 톤 이상 배출하는 기업 300-400곳이 대상. 이 기업들은 이제 배출량을 정확히 측정하고, 보고하고, 검증받아야 한다 (MRV: Measurement, Reporting, Verification).

"대충 Excel로 관리하던 시대"에서 "시스템으로 정밀 관리하는 시대"로의 전환. 우리 같은 탄소 관리 SaaS 입장에서는 황금기의 시작이다.

EU CBAM 본격 시행 (2026년 1월~)

EU가 수입품에 "탄소 관세"를 매기기 시작했다. 철강, 알루미늄, 시멘트 등을 EU로 수출하는 일본 기업은 제품 안에 얼마나 CO2가 들어있는지(내재 배출량)를 계산해서 보고해야 한다.

이게 왜 중요하냐면, 일본은 EU에 연간 약 2.85억 유로의 CBAM 비용을 내게 될 전망이기 때문이다.

SSBJ 공시 카운트다운 (2027년 3월~)

일본판 ISSB인 SSBJ 기준에 따라, 시가총액 3조 엔 이상 기업부터 Scope 1/2/3 전체 공시가 의무화된다. 69개 기업이 2027년 3월 결산부터 적용. 이후 1조 엔 이상(179사), 5,000억 엔 이상(294사)으로 확대.

공급망의 모든 기업에 "탄소 데이터 좀 보내주세요"라는 요청이 쏟아지게 된다. 이른바 Scope-down Pressure.

5. AI가 탄소 관리를 바꾸는 방법

여기서 개발자로서 가장 흥미로운 부분이 나온다.

기존 탄소 관리: "Excel에서 배출계수 찾아서 곱하기"
AI 탄소 관리: "이번 분기 배출량이 왜 늘었어?"라고 물으면 AI가 원인을 분석해준다

우리가 만든 MCP(Model Context Protocol) 서버가 바로 이 역할을 한다:

사용자: "지난달 서울 공장 Scope 1만 보여줘"
Carbon Copilot: 지난달 서울 공장 Scope 1 배출량은 45.2 t-CO2입니다.
              전월 대비 12% 증가했으며, 주 원인은 보일러 가동 시간 증가입니다.

              추천 조치:
              1. 보일러 예열 시간 단축 (-3.5 t-CO2 예상)
              2. 야간 보일러 자동 정지 설정 (-2.1 t-CO2 예상)

대시보드를 뒤적거리며 필터를 걸고 그래프를 해석하는 대신, 질문 하나로 인사이트를 얻는다. 이건 단순히 UX 개선이 아니라, 탄소 관리의 접근 문턱을 낮추는 것이다.

지금 경쟁 구도에서 AI 기능은 "있으면 좋은 것"이 아니라 테이블 스테이크가 되어가고 있다. 문서 자동 추출(OCR), 배출계수 자동 매칭, 이상치 탐지, 보고서 자동 생성 등.

6. 숫자로 보는 시장 기회

개발자가 "이 도메인이 앞으로도 괜찮을까?"를 판단하는 데 도움이 될 수치들:

지표 수치
글로벌 탄소관리 SW 시장 (2025) 161억 USD
글로벌 탄소관리 SW 시장 (2030 전망) 325억 USD (CAGR 15%)
일본 기후테크 시장 (2025) 17억 USD
일본 기후테크 시장 (2030 전망) 41억 USD (CAGR 18.5%)
APAC 지역 성장률 16.9% CAGR (글로벌 최고)
일본 GX 관민 투자 150조 엔+ (10년간)
SBTi 인증 기업 수 (2026.01) 10,000개 (글로벌 시가총액 40%)

15% CAGR이면, 매년 시장이 15%씩 커진다는 뜻이다. 이런 성장률의 시장에서 일하는 건 드문 기회다.

7. 개발하면서 배운 도메인 팁

마지막으로, 탄소 관리 도메인에서 개발할 때 알아두면 좋은 실전 팁들:

1. t-CO2e의 "e"를 빼먹지 마라

CO2와 CO2e(CO2 equivalent)는 다르다. CO2e는 메탄, 아산화질소 등 모든 온실가스를 CO2로 환산한 값이다. 리포트에 단위를 잘못 쓰면 큰일.

2. "원단위"라는 마법의 지표

매출이 늘면 배출량도 늘 수밖에 없다. 그래서 원단위(배출원단위, Emission Intensity)가 중요하다. "매출 1억 엔당 CO2 몇 톤"으로 효율을 측정한다.

원단위 = 총 배출량 / 매출액(또는 생산량)

3. 1차 데이터 vs 2차 데이터

  • 1차 데이터: 실제 계측한 값 (전력 미터기 수치 등)
  • 2차 데이터: 산업 평균 추정치 (통계 DB의 배출계수)

규제가 강화될수록 "2차 데이터로 대충 계산"이 허용되지 않는다. 1차 데이터 수집 자동화가 다음 큰 기술 과제.

4. 감축 시책은 ROI로 판단한다

"LED 교체"와 "태양광 설치" 중 뭘 먼저 해야 할까? 답은 t-CO2 감축량 / 투자비용, 즉 감축 ROI다. AI가 자동으로 시책을 제안하고 ROI를 산출하는 기능이 차별화 포인트가 된다.

마무리

탄소 배출 관리는 더 이상 "환경부서만의 일"이 아니다. 2026년을 기점으로 법적 의무가 되었고, 공급망 전체로 확산되고 있다.

개발자로서 이 도메인에 들어와보니, 기술적으로도 흥미로운 도전이 많았다. 160개 넘는 엔티티 모델 설계, 15개 Scope 3 카테고리의 복잡한 계산 로직, AI 기반 자연어 질의, 실시간 이상치 탐지... "환경"이라는 단어에서 연상되는 지루함과는 거리가 먼, 꽤 재미있는 영역이다.

무엇보다, 만드는 것이 세상에 도움이 되는 프로덕트라는 점. 그게 이 도메인에서 일하는 가장 큰 동기다.

이 글은 EcoNiPass 프로젝트의 도메인 지식 가이드를 작성하면서 정리한 내용을 바탕으로 했습니다.
상세한 도메인 가이드: docs/DOMAIN_KNOWLEDGE_GUIDE.md