DAC 플랜트는 홀로 운영되지 않는다. 포집한 CO2는 파이프라인이나 트럭 적재장을 거쳐 저장 운영자에게 넘어간다. 플랜트가 쓰는 전기와 열은 전력망이나 전용 공급자에게서 오며, 이것이 순제거량의 상당 부분을 좌우한다. 검증된 톤수는 구매자의 장부와 지속가능성 보고서에 들어가고, 모이면 공개 통계가 된다. 제2장부터 제6장까지는 WIA 데이터 모델 안쪽의 레코드와 프로토콜을 다루었다. 이 장은 그 바깥 경계, 곧 시설이 통제하지 못하는 시스템과 레코드를 주고받는 지점을 다룬다.
PHASE-4-INTEGRATION은 통합 영역을 여섯 가지로 나눈다. 저장, 에너지, 등록부, MRV, 공개 데이터, 기업 영역이다. 등록부와 MRV 통합은 제6장에서 다루었으므로, 이 장에서는 나머지 네 영역을 살펴본 뒤 이들을 하나로 묶는 참조 구현과 모든 인터페이스에 공통으로 적용되는 보안 통제를 설명한다. 이 장 전체를 관통하는 원칙은 하나다. 외부 당사자와 주고받는 모든 교환은, 검증기관이 나중에 시설 자체 데이터와 맞춰 볼 수 있는 레코드를 남겨야 한다. CO2나 에너지를 움직이면서 이런 레코드를 남기지 않는 통합은 제3장에서 쌓은 증거 사슬을 끊는다.
+---------------------------+
재생에너지·전력망 --->| 에너지 조정 |<--- 예보, 수요반응 이벤트
운영자 | (스케줄러, IEEE 2030.5) | (7.3절)
+-------------+-------------+
| 설정값, 부하 감축
v
+------------------+ 원격측정 +-------------------------+ 레코드 +------------------+
| DAC 시설 |-------------->| WIA 데이터 플랫폼 |------------>| MRV / 검증기관 |
| (모듈, 계량기, | MQTT / WSS | 수집기, 검증기, | 패키지 | (제6장) |
| 인수인계 계량기)| | 시계열 DB, API, | +------------------+
+--------+---------+ | 증거 저장소 |
| CO2 제품 +---+---------+-------+---+ 내보내기 +------------------+
v | | +--------------->| 기업·보고 |
+------------------+ /injection/* | | | 시스템 (7.4절) |
| 파이프라인 운영자|<------------------+ | +------------------+
| (ISO 27913 범위) | 요청/일정/ | 공개 데이터,
+--------+---------+ 상태/확정 | 파트너 피드
v v
+------------------+ 예약/실행/ +------------------+
| 저장 부지 | 모니터링/ | 공개·연구 |
| (지중 또는 | 검증 | 이용자 |
| 광물화) |-------------------->| (7.5절) |
+------------------+ 플랫폼으로 +------------------+예시에 관해 먼저 밝혀 둔다. 명세는 파트너 API를 실존하는 운영자 이름과 api.wia.org, open-data.wia.org 같은 호스트를 기준으로 서술한다. 이 책은 그중 어느 것도 실제 운영 중인 서비스로 제시하지 않는다. 아래 예시는 example.com 호스트, dac-example-reykjanes-01·site-example-basalt-01 같은 가상 식별자, 계산하기 쉬운 예시 수치를 사용한다.
CO2가 압축기를 떠나는 순간, 시설은 자신에게 필요한 증거를 더 이상 직접 갖고 있지 않다. 제거 주장에서 인정되는 양은 플랜트에서 나간 양이 아니라 저장 운영자가 확인한 양이기 때문이다(제1장). 따라서 운송·저장 파트너와의 통합은 두 가지 일을 해야 한다. 하나는 용량, 일정, 압력 한계 같은 물리적 물류를 조율하는 일이다. 다른 하나는 파트너의 측정값을 시설의 증거 사슬로 다시 가져와 검증기관이 대사(對査)할 수 있게 하는 일이다.
PHASE-4 §3.1은 파이프라인 운영자를 상대로 하는 네 가지 작업을 정의한다. POST /injection/request는 수송 용량을 요청하고, POST /injection/schedule은 인도 시간대를 확정하며, GET /injection/status/{id}는 진행 상황을 조회하고, POST /injection/confirm은 CO2 인도 완료를 기록한다. 명세는 CO2 포집·수송·저장 분야의 파이프라인 수송 시스템 표준인 ISO 27913을 인용한다. 다만 ISO 27913은 파이프라인의 설계와 운영을 다룰 뿐 데이터 교환은 다루지 않는다. 네 가지 작업은 그 표준에 따라 운영되는 파이프라인 위에 WIA가 따로 얹은 인터페이스다.
가장 중요한 것은 confirm 호출인데, 명세의 예시는 이 부분을 비워 두었다. "인도됨"이라고만 적힌 확인은 증거가 되지 못한다. 아래 예시는 인수인계 계량기의 식별자, 시작·종료 지시값, 교정 기록 참조를 추가했다. 이렇게 하면 인도량을 지시값에서 다시 계산할 수 있고, 교정된 계기와도 연결할 수 있다.
POST https://pipeline.example.com/api/v1/injection/request
{
"facilityId": "dac-example-reykjanes-01",
"amount": 10.0,
"unit": "t",
"targetDate": "2026-03-02",
"destinationSite": "site-example-basalt-01",
"co2Quality": { "purity": 98.5, "waterPpm": 40 }
}
200 OK
{
"requestId": "pipe-req-0142",
"status": "approved",
"scheduledDate": "2026-03-02T08:00:00Z",
"pipelineSegment": "segment-example-sw-01"
}
POST https://pipeline.example.com/api/v1/injection/confirm
{
"requestId": "pipe-req-0142",
"deliveredAmount": 9.97,
"unit": "t",
"meter": {
"meterId": "ct-meter-02",
"readingStart": 18214.52,
"readingEnd": 18224.49,
"calibrationRef": "cal-2026-01-ct-meter-02"
},
"deliveryWindow": {
"start": "2026-03-02T08:00:00Z",
"end": "2026-03-02T15:10:00Z"
}
}눈여겨볼 점이 세 가지 있다. 첫째, deliveredAmount는 readingEnd − readingStart와 같아야 한다. 제2장에서 specificEnergy를 에너지와 포집 질량으로 대조했듯이 검증기는 이 값도 확인해야 한다. 둘째, 인도량(9.97 t)은 요청량(10.0 t)과 다르다. 이는 정상이며, 저장 이벤트에는 요청량이 아니라 반드시 계량값을 써야 한다. 셋째, 확정 메시지에는 저장 이벤트가 참조할 수 있는 requestId가 들어 있다. 검증기관은 이 참조를 따라 저장 이벤트에서 특정 인도 건으로 거슬러 올라간다.
명세는 거래성 호출과 별도로, 시설과 파이프라인 운영자가 공유할 운전 데이터를 열거한다. 유량(t/h), 압력(bar), 온도(°C), CO2 순도(%), 누적 계량 톤수다. 전송 방식은 MQTT나 WebSocket을 이용한 실시간 스트리밍과 REST API를 이용한 시간별 요약 두 가지를 허용하며, 어느 쪽이든 TLS 1.3과 상호 인증을 요구한다.
어느 방식을 고를지는 누가 그 데이터로 행동하느냐에 달려 있다. 파이프라인 운영자가 시설의 유량과 압력을 제어에 쓴다면, 예컨대 관내 저장량(line pack)을 관리하거나 과압을 막는 데 쓴다면, 스트림만이 충분히 빠르다. 이 경우에는 MQTT가 더 자연스럽다. MQTT는 작은 원격측정 메시지를 대량으로 보내도록 설계된 발행/구독 프로토콜이고, 전달 보장 수준을 제공한다. 데이터를 대사와 정산에만 쓴다면 시간별 REST 요약이 보안과 감사 면에서 더 단순하다. 두 방식을 함께 쓰는 배치도 많다. 운영에는 스트림을 쓰고, 서명된 시간별 요약을 기준 레코드로 삼는 식이다.
topic: wia/dac/dac-example-reykjanes-01/transfer/ct-meter-02
qos: 1 (at least once; the receiver de-duplicates on seq)
{
"seq": 88121,
"timestamp": "2026-03-02T09:15:00Z",
"flowRate": { "value": 1.42, "unit": "t/h" },
"pressure": { "value": 14.8, "unit": "bar" },
"temperature": { "value": 21.6, "unit": "Cel" },
"co2Purity": { "value": 98.4, "unit": "%" },
"cumulative": { "value": 18215.97, "unit": "t" },
"qc": "good"
}이 메시지의 모든 양은 단위를 명시한 객체로 표현되어 있고, 온도 단위는 UCUM 표기(Cel)를 따른다. 제2장의 단위 권고를 적용한 것이다. 명세의 목록에는 t/h, bar, °C, %가 섞여 있어서, 상대가 MPa나 켈빈을 가정하면 오류 없이 조용히 틀린 값이 들어간다. seq 필드는 MQTT의 "최소 1회 전달" 특성에 대응한다. 같은 메시지가 두 번 올 수 있으므로 수신 측은 이미 저장한 순번을 버린다. qc 플래그는 제5장의 good / suspect / bad / missing 어휘를 그대로 써서, 파트너 데이터의 품질도 시설 자체 데이터와 같은 용어로 기록되게 한다.
PHASE-4 §3.2는 저장 부지를 상대로 하는 두 번째 API를 정의한다. POST /injection/reserve, POST /injection/execute, GET /injection/monitoring/{id}, GET /verification/{id}다. 여기서는 CO2 지중 저장에 관한 ISO 표준인 ISO 27914를 인용하는데, 이 표준은 부지 선정, 특성 평가, 주입, 모니터링, 폐쇄를 다룬다. 파이프라인 API와 저장 부지 API는 둘 다 /injection 아래 경로를 쓰지만, 기본 URL이 서로 다른 별개의 상대방이다. 클라이언트 라이브러리는 두 API를 별도 네임스페이스로 분리해서 status 호출이 엉뚱한 상대에게 가는 일이 없게 해야 한다.
모니터링 엔드포인트는 저장 이벤트의 영구성 주장을 최신 상태로 유지하는 데 필요한 데이터를 돌려준다. 허용 한계 대비 주입 압력, 지진 관측, 지하수 화학 성분이다. 명세의 예시는 이 값들을 실존하는 부지 이름에 연결해 두었다. 아래 예시는 가상 부지를 쓰고 linkedStorageEvent 필드를 추가해서, 모니터링 흐름이 따로 떠돌지 않고 제3장의 저장 이벤트에 붙도록 했다.
{
"injectionId": "inj-example-2026-03-0007",
"siteId": "site-example-basalt-01",
"linkedStorageEvent": "storage-example-reykjanes-01-20260302-001",
"monitoring": {
"wellheadPressure": { "current": 18.0, "limit": 25.0, "unit": "bar" },
"seismic": { "eventsSinceLastReport": 0, "lastSurvey": "2026-02-15" },
"groundwater": { "pH": 7.9, "lastSample": "2026-02-27" }
},
"status": "stable",
"observedAt": "2026-03-02T16:00:00Z"
}압력 한계, 조사 일자, pH는 자리표시 값이다. 실제 한계는 부지의 인허가 조건과 모니터링 계획에서 나오며, 이 책은 그 어느 것도 지침으로 제시하지 않는다. 데이터 모델에서 중요한 것은 형식이다. 모니터링 스냅숏은 저마다 해당 저장 이벤트를 지목하고, 관측 시각을 UTC로 담고, 상태를 보고한다. 상태가 stable이 아니면 시설 쪽에도 레코드를 만들어야 한다. 나중에 크레딧 톤수를 줄여야 할 수도 있기 때문이다.
| 파트너 작업 | 방향 | 생성되는 WIA 레코드·필드 | 검증기가 수행할 확인 |
|---|---|---|---|
/injection/request, /injection/schedule (파이프라인) | 시설 → 파이프라인 | 시설과 목표 부지를 참조하는 이송 계획 | 목표 부지가 시설의 저장 구성에 존재하는지 |
/injection/confirm (파이프라인) | 파이프라인 ↔ 시설 | 인수인계 기록. 저장 이벤트 amount의 원천 | 인도량 = 종료 − 시작 지시값, 해당 일자에 계량기 교정이 유효한지 |
/injection/reserve, /injection/execute (부지) | 시설 → 부지 | 저장 이벤트의 injectionData(온도, 압력, 주입률, 지속 시간) | 주입률 × 지속 시간 ≈ 수량 (제3장) |
/injection/monitoring/{id} (부지) | 부지 → 시설 | 저장 이벤트에 연결된 모니터링 스냅숏 | 스냅숏 시각이 모니터링 계획의 일정을 따르는지, 허용 범위를 넘는 공백이 없는지 |
/verification/{id} (부지) | 부지 → 시설 | 저장 검증 인증서. 이벤트를 verified로 전환 | 인증서 수량 ≤ 인도량, 발급자가 기록상 저장 부지인지 |
아이슬란드에서 선도적으로 시도된 현무암 광물화는 명세에서 별도 절(§3.3, 실존 운영자를 기준으로 서술)로 다룬다. 데이터 교환은 세 단계로 나뉘며, 이 단계 구조는 어느 광물화 파트너에게나 그대로 적용된다.
통합에서 가장 까다로운 문제는 마지막 단계에서 생긴다. CO2가 안정된 탄산염이 되었다는 증거는 해당 톤수가 플랜트를 떠나고 한참 뒤에야 도착한다. 따라서 제3장의 저장 이벤트에는 오랫동안 열려 있으면서도 그동안 감사가 가능한 상태가 필요하다. 아래 상태 전이는 광물화 경로를 위한 제안으로, 저장 이벤트 엔드포인트가 이미 반환하는 pending-verification 상태를 확장한 것이다.
저장 이벤트 상태 (광물화 경로)
submitted
| 부지가 수령과 용해 데이터를 확인
v
injected ----------------------------> anomaly-reported
| 부지 모니터링 계획에 따른 | (조사 진행, 수량이
| 모니터링 마일스톤 수신 | 줄어들 수 있음)
v v
pending-verification <---------------------+
| 부지가 검증 인증서를 발급
v
verified (이때부터 크레딧 요청 가능)여기서 두 가지 설계 규칙이 나온다. 첫째, 크레딧 요청(제6장)은 저장 이벤트가 verified에 도달하기 전에는 그 이벤트를 참조하면 안 된다. 사용하는 등록부 방법론이 중간 증거에 기초한 발행을 명시적으로 허용한다면 예외지만, 그때도 크레딧 레코드에 어떤 증거에 기댔는지 적어야 한다. 둘째, 크레딧이 이미 발행된 뒤에도 anomaly-reported로 전이할 수 있어야 한다. 제3장의 증거 사슬은 레코드를 덮어쓰지 않고 연결하는 방식에 기대고 있다. 뒤늦게 불리한 결과가 나오면 원래 레코드를 슬그머니 고치는 대신, 연결된 새 레코드를 만들어 등록부의 반전(reversal) 또는 버퍼 절차를 시작할 수 있게 해야 한다.
에너지는 제1장 순제거량 공식에서 가장 크게 변하는 항목이며, 운영자가 시간 단위로 바꿀 수 있는 유일한 항목이다. 그래서 에너지 통합은 때로 충돌하는 두 목표를 함께 좇는다. 포집 톤당 귀속 배출을 낮추는 것, 그리고 유연한 부하로서 전력망에 응답하는 것이다.
PHASE-4 §4.1은 24시간 예보(일사량, 풍속, 지열 가용량, 전력망 탄소 집약도)를 받아 optimizeDACSchedule이라는 함수로 시간대마다 작업을 배정하는 스케줄러를 설명한다. 논리는 단순하다. 재생에너지 비중이 80 %를 넘으면 전 모듈을 재생하고, 50~80 %면 흡착을 돌리고, 50 % 미만이면 대기한다.
기본 발상은 타당하다. 고체 흡착제 플랜트에서 재생은 흡착제를 가열하므로(제1장에서 전형적인 TVSA 온도 범위를 80~120 °C로 소개했다) 대개 시간당 에너지가 흡착보다 훨씬 많이 든다. 그러니 재생을 깨끗한 전력이 공급되는 시간대로 옮기는 편이 흡착을 옮기는 것보다 에너지 항목을 더 크게 줄인다. 그러나 이 예시는 시간대마다 독립적으로 선택하는데, DAC 모듈은 상태 기계다(제5장). 모듈은 CO2를 충분히 흡착한 뒤에야 재생할 수 있다. 제5장은 그 기준을 포화도 85 %로 예시했다. 반대로 한번 포화되면 재생하기 전까지는 더 포집하지 못한다. 포화된 모듈이 하나도 없는데 깨끗한 시간대라고 재생을 지시하는 스케줄은 실행할 수 없다. 재생에너지가 적은 기간이 길 때 포화된 모듈을 계속 대기시키는 스케줄은 아무 기록 없이 포집을 포기하는 셈이다.
예시에는 약점이 두 가지 더 있다. 하나는 신호로 "재생에너지 비율"을 쓴다는 점이다. 순제거량 계산에 필요한 것은 실제 소비한 전력의 배출계수이며, gCO2e/kWh 단위의 전력망 탄소 집약도가 더 직접적인 입력이다. 명세도 이미 이 값을 예보 항목으로 열거하고 있다. 다른 하나는 흔적이 남지 않는다는 점이다. 모듈이 왜 대기했는지 기록하지 않으므로, 검증기관은 스케줄링 결정과 고장을 구분할 수 없다. 아래의 모듈별 계획기는 세 가지 문제를 모두 다룬다. 임계값은 운영자가 정하는 설정값이며 규범 값이 아니다.
// 예시 스케줄러. 임계값은 설정값이며 규범 값이 아니다.
function planHour(hour, module, cfg) {
const clean = hour.gridIntensity <= cfg.lowIntensity; // gCO2e/kWh
const saturated = module.saturation >= cfg.regenTrigger; // 예: 0.85
if (hour.drEvent && hour.drEvent.accepted) {
return { op: module.state === 'regeneration' ? 'hold-warm' : 'idle',
reason: 'demand-response:' + hour.drEvent.eventId };
}
if (saturated && clean) {
return { op: 'regeneration', reason: 'saturated-and-clean-window' };
}
if (saturated && hour.hoursToNextCleanWindow > cfg.maxWaitHours) {
return { op: 'regeneration', reason: 'wait-limit-exceeded' };
}
if (saturated) {
return { op: 'idle', reason: 'waiting-for-clean-window' }; // 팬 정지
}
return { op: 'adsorption', reason: 'capacity-available' };
}reason 문자열은 장식이 아니다. 해당 시간대 운영 레코드의 상태 블록에 그대로 복사해야 한다. 그러면 제6장의 검증 패키지에서 대기 시간이 의도된 선택이었음을 보일 수 있고, 시설 가동률 수치에서도 계획된 대기와 고장을 나눌 수 있다. maxWaitHours 방어 조건도 중요하다. 이것이 없으면 탄소 집약도가 높은 기간이 길어질 때 포화된 모듈이 한없이 대기한다. 이를 받아들이는 운영자도 있겠지만 최소 처리량이 필요한 운영자도 있다. 그 절충은 숨겨진 코드가 아니라 설정에 드러나 있어야 한다.
명세는 전력망 쪽 표준으로 스마트 에너지 프로파일 응용 프로토콜인 IEEE 2030.5를 인용한다. IEEE 2030.5는 여러 기능 가운데 수요반응과 부하 제어를 위한 자원을 정의한다. 명세는 DAC 플랜트가 제공할 수 있는 능력으로 5분 이내 부하 감축, 최대 24시간 부하 이전, 주파수 조정을 위한 부하 조절 세 가지를 든다. 실제 플랜트가 이 중 얼마를 제공할 수 있는지는 기술에 따라 다르다. 흡착 중인 모듈의 팬은 빠르게 멈출 수 있다. 반면 가열이 절반쯤 진행된 재생 단계는 보온 상태로 유지하거나 끝까지 마쳐야 할 수도 있다. 위 계획기가 곧바로 대기로 넘어가지 않고 hold-warm 상태를 두는 이유다.
명세의 수요반응 이벤트 예시에는 JSON 파서가 알려 주지 않는 결함이 있다. 한 객체 안에 unit이라는 이름의 멤버가 두 개 있다.
{
"requestedReduction": 500,
"unit": "kW",
"duration": 2,
"compensation": 50,
"unit": "$/MWh"
}unit이 첫 번째를 덮어쓴다RFC 8259는 JSON 객체 안의 이름이 고유해야 한다(SHOULD)고만 정하고, 중복 시 동작은 구현에 맡긴다. 대부분의 파서는 마지막 값을 남기므로 requestedReduction의 단위가 결국 달러/메가와트시로 읽힌다. duration에는 단위가 아예 없다. 해결책은 원격측정 메시지와 마찬가지로 각 수량을 단위를 품은 객체로 만들고, 지속 시간을 ISO 8601 형식으로 쓰는 것이다. 아래의 수정본은 응답 기한을 추가하고, 플랜트가 포집에 미친 영향을 보고하도록 했다. 이렇게 하면 부하 감축 이벤트가 시설 레코드에서 생산량 손실을 설명하는 근거로 남는다.
POST https://dr.example.com/grid/demand-response/event
{
"eventId": "dr-example-20260302-001",
"type": "load-reduction",
"facilityId": "dac-example-reykjanes-01",
"requestedReduction": { "value": 400, "unit": "kW" },
"start": "2026-03-02T17:00:00Z",
"duration": "PT2H",
"responseDeadline": "PT5M",
"compensation": { "amount": 40, "currency": "EUR", "per": "MWh" }
}
200 OK
{
"eventId": "dr-example-20260302-001",
"status": "accepted",
"committedReduction": { "value": 380, "unit": "kW" },
"modules": ["module-01", "module-03", "module-05"],
"impact": {
"deferredRegenerations": 3,
"estimatedCaptureDeferred": { "value": 0.6, "unit": "t" }
}
}보상 금액은 명세의 50 $/MWh와 마찬가지로 예시다. 실제 요금과 프로그램은 시장마다 다르다. 응답에는 부하를 줄인 모듈 목록과 그 결과 미뤄진 포집량이 담긴다. 이런 프로그램에 참여하는 시설은 수락한 이벤트마다 영향받은 시간대와 연결된 별도 레코드로 저장해야 한다. 계획기의 reason 필드와 같은 이유에서다.
어떤 스케줄링 전략을 쓰든 에너지 통합은 결국 기간마다 검증기관이 받아들일 숫자 하나를 내놓아야 한다. 플랜트가 사용한 에너지에서 나온 배출량이다. 이를 위해서는 에너지원별 계량 소비량, 에너지원·시간 구간별 배출계수, 그리고 적용한 회계 방법에 대한 명시가 필요하다. 시간별 배출계수를 시간별 소비량에 곱한 결과는 연평균 배출계수를 쓴 결과와 다르다. 재생에너지 인증서 같은 계약 수단도 방법론마다 달리 취급한다. 데이터 모델은 미리 계산한 "친환경" 플래그 하나만 저장하지 말고, 소비량과 배출계수를 분리해 두고 배출계수의 출처와 시점을 기록한 뒤, 둘을 어떻게 결합할지는 등록부 방법론이 정하게 해야 한다.
제거 크레딧 구매자 대부분은 DAC 시설의 API를 직접 호출하지 않는다. 탄소회계 플랫폼이나 지속가능성 보고 절차를 거쳐 데이터를 받는다. PHASE-4 §8.1은 특정 상용 벤더의 API로 바로 전송하는 함수를 예로 드는데, 그 엔드포인트는 해당 벤더가 공개한 것이 아니므로 따라 써서는 안 된다. 같은 예시는 verificationStandard를 ISO 27916으로 적었다. ISO 27916은 원유회수증진(EOR)을 통한 CO2 저장을 다루는 표준이며, DAC 전반의 검증 표준이 아니다.
더 나은 설계는 벤더 중립 내보내기다. WIA 플랫폼은 잘 정의된 제거 레코드 하나를 발행하고, 얇은 어댑터가 이를 각 대상 시스템의 가져오기 형식으로 변환한다. 이 레코드에는 어떤 종류의 제거인지, 수량을 어떤 기준으로 산출했는지(총포집량이 아닌 순제거량), 그 뒤에 어떤 증거가 있는지(검증 보고서, 크레딧 일련번호, 폐기 상태)가 담겨야 한다. 온실가스 선언의 검증은 ISO 14064-3이 다루므로 검증 표준 필드에는 이것을 적는다. 등록부 방법론은 별도 필드로 둔다.
{
"exportId": "exp-example-2025-017",
"schema": "wia-dac-removal-export/1.0",
"reportingEntity": "org-example-buyer",
"activity": {
"category": "carbon-removal",
"method": "direct-air-capture",
"storageMethod": "mineralization",
"quantity": { "value": 250, "unit": "t CO2" },
"basis": "net-removal"
},
"period": { "start": "2025-01-01", "end": "2025-12-31" },
"evidence": {
"facilityId": "dac-example-reykjanes-01",
"verificationReportId": "verify-example-reykjanes-01-2025",
"creditSerials": ["EXAMPLE-SERIAL-0101 … EXAMPLE-SERIAL-0350"],
"retirement": {
"status": "retired",
"beneficiary": "org-example-buyer",
"retiredAt": "2026-04-20T10:00:00Z"
},
"methodology": "registry methodology reference (text)",
"verificationStandard": "ISO 14064-3"
},
"mappings": {
"csv": "removals.csv#row=17",
"xbrl": "concept name from the filer's chosen taxonomy"
}
}이 내보내기를 기업의 주장에 안전하게 쓸 수 있게 해 주는 것은 retirement 블록이다. 기업은 단지 보유한 크레딧이 아니라, 자기 명의로 또는 자기를 위해 폐기된 제거량을 보고해야 한다. 내보내기에는 크레딧 일련번호 범위도 남아 있으므로, 감사인은 내보내기를 믿지 않고도 등록부에서 폐기 여부를 직접 확인할 수 있다.
명세가 거론하는 보고 프레임워크(GRI, CDP, TCFD, SASB)에 대해 내보내기가 할 일은 공시 항목을 채우는 것이 아니라 일관된 수치를 공급하는 것이다. GRI 305는 배출에 관한 GRI 주제별 표준이고, CDP는 질의서를 통해 데이터를 수집한다. TCFD 권고안은 현재 IFRS 재단의 ISSB 기준에 반영되어 있으며, SASB 기준도 IFRS 재단이 관리한다. 어느 경우든 제거량을 어디에 기재할지는 보고 기업이 정한다. 대부분의 프레임워크는 제거량을 총배출량에서 차감하지 말고 따로 보고하도록 요구한다. 명세가 제시한 네 가지 내보내기 형식은 각기 다른 이용자를 위한 것이다.
투명성은 제1장의 여섯 원칙 가운데 첫째다. PHASE-4 §7은 이를 세 가지 경로로 구현한다. 인증 없는 공개 데이터 API, 웹페이지에 삽입하는 대시보드 위젯, 신청 기반 연구 접근 프로그램이다. PHASE-1-FOUNDATION §7.2는 여기에 원칙을 더한다. 공개(public), 파트너(partner), 비공개(private)의 계층형 접근 모델, 그리고 개별 시설을 보호하기 위한 집계와 익명화다.
명세의 공개 데이터 예시는 2025년 전 세계 통계를 반환한다. 시설 수, 용량, 포집 톤수, 평균 효율, 국가별 내역이 들어 있지만 모두 지어낸 수치이므로 인용하면 안 된다. 응답의 구조는 쓸모가 있지만, 발행자에게 필요한 두 가지가 빠져 있다. 방법에 대한 설명과 소집단 보호다. 어떤 국가에 DAC 시설이 하나뿐이면 그 나라의 "집계"는 곧 그 시설의 데이터이므로, 집계만으로는 아무것도 보호하지 못한다. 아래 응답은 시설 수가 최솟값에 못 미치는 셀을 가리고 그 사실을 밝힌다. 기준값 3은 예시이며 실제 값은 데이터 거버넌스 정책이 정한다.
GET https://open-data.example.com/dac/v1/statistics?year=2026&groupBy=country
200 OK
{
"year": 2026,
"generatedAt": "2027-02-01T00:00:00Z",
"method": {
"source": "verified storage events only",
"minFacilitiesPerCell": 3,
"suppressedCells": 2
},
"rows": [
{ "country": "XA", "facilities": 4, "verifiedStored": { "value": 1200, "unit": "t" } },
{ "country": "XB", "facilities": null, "verifiedStored": null,
"suppressed": "fewer-than-3-facilities" }
]
}"source": "verified storage events only"에도 주목하자. 공개 통계는 총포집량을 세는지, 저장된 톤수를 세는지, 검증된 순제거량을 세는지 밝혀야 한다. 이 셋을 섞으면 어떤 수치와도 비교할 수 없는 표제 숫자가 나온다. 여기서 쓴 국가 코드는 ISO 3166-1의 사용자 지정 범위에 속하므로 실제 국가로 오인될 일이 없다.
위젯을 쓰면 시설이나 파트너가 자기 사이트에 실시간 수치를 넣을 수 있다. 명세는 실제로 운영되지 않는 widgets.wia.org 호스트에서 위젯을 불러온다. 아래 예시는 예시용 호스트를 쓰고 하위 리소스 무결성(SRI)을 추가해서, 스크립트 호스트가 침해되더라도 위젯을 삽입한 모든 페이지에 코드가 주입되지 않게 했다.
<div id="dac-widget"></div>
<script src="https://widgets.example.com/dac/v1/widget.js"
integrity="sha384-(hash of the published file)"
crossorigin="anonymous"></script>
<script>
DACWidget.init({
container: '#dac-widget',
facilityId: 'dac-example-reykjanes-01',
metrics: ['capture-rate', 'energy', 'verified-stored'],
refreshInterval: 60 // seconds; public tier only
});
</script>위젯은 공개 계층의 데이터만 읽는다. 포집률과 검증된 누계는 보여 주되, 파트너 계층이 보호하는 흡착제 단위나 풍량 수준의 세부 정보는 보여 주지 않아야 한다.
연구자는 제안서 제출, 데이터 이용 계약, 자격증명 발급, 익명화된 상세 데이터 접근이라는 네 단계를 거쳐 공개 계층보다 많은 데이터를 얻는다. 상세 데이터에는 분 단위 운전 데이터, 흡착제 성능, 에너지 전략, 환경 조건과의 상관관계가 포함된다. 그런데 이 가운데 일부는 기반 문서가 보호해야 한다고 명시한 바로 그 정보다. 흡착제 조성은 영업비밀로 지목되어 있고, 시간에 따른 흡착제 성능만으로도 경쟁자가 조성을 짐작할 수 있다. 따라서 계층 경계는 정책 문서가 아니라 스키마에 들어가야 한다. 표 7-2가 그 예다.
| 레코드 그룹 | 공개 | 파트너(계약 기반) | 비공개 |
|---|---|---|---|
| 시설 식별 정보, 위치, 기술 계열, 신고 용량 | 시설이 동의한 경우 공개 | 예 | 예 |
| 기간별 검증 저장량·크레딧 톤수 | 예(필요 시 집계) | 예 | 예 |
| 시간별 포집·에너지 레코드 | 요약만 | 예, 연구용은 익명화 | 예 |
| 흡착제 레코드(유형, 용량, 열화) | 아니요 | 유형 계열만, 또는 NDA 하에서 | 예 |
| 흡착제 조성, 공급 계약 조건 | 아니요 | 아니요 | 예, 암호화 |
| 직원 식별자가 포함된 정비 기록 | 아니요 | 가명 처리 | 예 |
운전 시계열을 익명화하는 일은 시설 이름을 지우는 것보다 어렵다. 용량과 위치가 알려진 포집 프로파일은 흔히 원천 시설로 되짚어 갈 수 있다. 연구용 추출본은 거칠게 가공해야 한다. 타임스탬프를 이동시키고, 정확한 수치 대신 용량 구간을 쓰고, 위치는 지역 단위보다 세밀하게 밝히지 않는다. 그리고 공개 전에 데이터 이용 계약에 비추어 검토해야 한다.
명세가 소프트웨어 아키텍처를 규정하지는 않지만, 요구사항을 모아 보면 하나의 구조가 나온다. PHASE-1-FOUNDATION §5는 시계열 데이터베이스(예로 InfluxDB와 TimescaleDB를 든다), 일일 증분·주간 전체 백업, 지리적 복제, 99.9 % 가용성 목표, 모든 API 호출의 감사 로깅을 요구한다. 이 책은 출발점으로 아래 다섯 단계 파이프라인을 제안한다.
| 항목 | 명세 출처 | 권장 실무 |
|---|---|---|
| 시계열 데이터베이스 | FOUNDATION §5.3.1 | 보존 정책과 연속 집계를 지원하는 엔진이면 무엇이든 가능하다. 원시 테이블과 집계 테이블은 보존 정책을 따로 둔다. |
| 백업 | FOUNDATION §5.3.1 | 일일 증분, 주간 전체. 복원 시험을 정기적으로 수행하고 결과를 레코드로 남긴다. |
| 복제 | FOUNDATION §5.3.1 | 최소한 증거 저장소는 두 번째 리전에 둔다. 복제본에도 같은 접근 계층을 적용한다. |
| 가용성 | FOUNDATION §5.2.2, §7.1.3 | 예시 목표 99.9 %는 연간 약 8.8시간의 중단을 허용한다. 그보다 긴 중단은 엣지 버퍼가 감당해 측정값 유실이 없게 한다. |
| 실시간 지연 | FOUNDATION §5.2.2 | 예시 목표는 측정에서 API까지 5초 미만이다. p95로 측정해 보고한다(Annex E의 오류 예산 노트). |
| 속도 제한 | PHASE-4 §9.2 | 예시 계층은 공개·인증·파트너 클라이언트에 대해 시간당 100 / 1,000 / 10,000 요청이다. 실제 한도는 배치마다 정한다. |
| 감사 로깅 | PHASE-4 §9.3 | 모든 API 호출을 목록 7-10의 필드로 기록하고, 애플리케이션 로그가 아니라 증거 저장소에 보관한다. |
가용성 수치에는 한마디 덧붙여 둘 필요가 있다. API 중단과 데이터 공백은 서로 다른 장애다. API에 대한 99.9 % 목표는 합리적이다. 그러나 데이터 공백은 되돌릴 수 없다. 인수인계 계량값이 한 시간 비면 다시 만들어 낼 수 없고, 검증기관은 대개 이를 보수적으로 처리한다. DAC 배치에서 가장 중요한 가용성 구성 요소가 중앙 클러스터가 아니라 엣지 버퍼인 까닭이다.
이 장의 모든 인터페이스는 조직의 경계를 넘나들고, 그중 몇몇은 크레딧을 거쳐 돈이 되는 데이터를 옮긴다. PHASE-4 §9는 네 가지 인증 방식(위임용 OAuth 2.0, 기계 간 통신용 API 키, 고보안 연결용 mTLS, 무상태 토큰용 JWT)과 속도 제한, 감사 로깅을 제시한다. 이들을 함께 적용할 때는 다음 규칙을 따르는 것이 좋다.
read:facility, write:capture)는 파트너에게도 자연스럽게 확장된다. 저장 부지에는 자기 부지 이벤트에 한정된 write:storage(표 4-1)만 준다. 파이프라인 운영자는 인도를 확정할 수는 있어도 저장 이벤트를 만들 수는 없다. 보고 어댑터는 검증·폐기된 레코드를 읽기만 한다.{
"seq": 5530127,
"timestamp": "2026-03-02T16:04:11.284Z",
"clientId": "svc-storage-sync",
"subject": "mtls:CN=site-example-basalt-01",
"scope": "write:storage",
"method": "POST",
"endpoint": "/storage/events",
"requestDigest": "sha256:(digest of canonical request body)",
"responseStatus": 201,
"resourceId": "storage-example-reykjanes-01-20260302-001",
"sourceIp": "203.0.113.24",
"prevHash": "sha256:(hash of entry 5530126)",
"entryHash": "sha256:(hash of this entry without entryHash)"
}이 항목은 요청 본문 대신 본문의 다이제스트를 저장한다. 그래서 로그가 작게 유지되고, 개인정보나 영업상 민감한 내용이 로그에 들어가지 않는다. 출발지 IP는 문서용 주소 대역을 썼다.
개인정보. DAC 데이터는 대부분 기계에 관한 것이지만 전부 그렇지는 않다. 정비 기록, 점검표 서명, 출입 카드, 당직 명부는 직원을 식별하며, 연구용 추출본에도 간접적으로 들어갈 수 있다. 명세는 직원 데이터에 대해 GDPR과 CCPA를 들고, API 인터페이스 문서는 K-PIPA(한국 개인정보 보호법) 등을 추가한다. 실무 규칙은 이렇다. 역할이나 가명 ID로 충분한 곳에서는 운영·증거 레코드에 개인 식별자를 넣지 않는다. 대응표는 비공개 계층에 둔다. 현장마다 어떤 개인정보 법제가 적용되는지 배치 정책에 명시한다. 증거 레코드는 영구 보존되므로, 거기에 한번 적힌 개인 식별자도 사실상 영구히 남는다.
verified를 기다린다.unit 키가 중복되어 있으므로 구조를 바꿔야 한다.제8장에서는 이렇게 만든 통합을 증명하는 일로 넘어간다. 적합성 등급, 서명 매니페스트, 그리고 감사인이 요구할 증거 패키지를 다룬다.