AI 영향 보고서(Impact Receipt)는 무엇을 포함해야 할까?

파트 3 — 출처(provenance), 불확실성(uncertainty), 그리고 의미 있는 환경 데이터 설계를 위한 고려 사항.

영향 보고서 시리즈 (The Impact Receipt Series) — 파트 3

많은 AI API는 요청에 사용된 토큰 수와 소요 시간을 보고할 수 있습니다.

하지만 만약 그들이 환경 영향 수치도 반환한다면 어떨까요?

그 숫자가 충분할까요?

전혀 그렇지 않습니다.

방법론 없이 제시된 탄소 추정치는 해석하기 어렵습니다. 측정 경계가 없는 물 사용량 수치는 오해를 불러일으킬 수 있습니다. 실제 실행 위치와의 명확한 연결고리가 없는 지역 이름은 우리가 생각하는 것보다 적은 정보를 제공할 수 있습니다.

AI 영향 보고서(AI Impact Receipt)가 유용하려면 단순히 숫자를 넘어설 무언가가 필요합니다.

바로 맥락(context), 출처(provenance), 그리고 불확실성에 대한 정직한 설명입니다.

첫째, 영향 보고서란 무엇인가?

이전 파트 2 기사에서 저는 모델링된 환경 추정치를 포함하는 프로토타입 보고서 계약을 탐구했습니다.

그 이전의 프로토타입은 가능한 응답 구조를 보여주었을 뿐, 실제 추론(per-inference) 측정치를 확립한 것은 아니었습니다.

이제 더 어려운 설계 질문이 남아 있습니다:

개발자에게 보고서를 진정으로 유용하게 만들 정보는 무엇일까요?

1. 요청 식별 및 모델

보고서는 요청을 식별하고, 요청된 모델과 실제로 실행한 모델을 구분해야 합니다.

가능한 필드는 다음과 같습니다:

• 요청 ID (Request ID)
• 요청된 모델 (Requested model)
• 실행된 모델 (Executed model), 검증 가능한 경우
• 제공자 (Provider)
• 타임스탬프 (Timestamp)

호출자(caller)가 제공하는 모델 이름이 특정 공급자가 요청을 실행했다는 증거는 아닙니다.

보고서는 이 구분을 명확히 해야 합니다.

2. 토큰 및 지연 시간

개발자는 요청과 관련된 컴퓨팅 작업량과 성능을 이해할 필요가 있습니다.

유용한 필드에는 다음이 포함될 수 있습니다:

• 입력 토큰 (Input tokens)
• 출력 토큰 (Output tokens)
• 총 토큰 (Total tokens)
• 종단 간 지연 시간 (End-to-end latency)
• 제공자가 보고한 사용량 대 추정된 사용량

이러한 값들 역시 출처(provenance)가 필요합니다.

토큰 예산(token budget)이 실제 토큰 소비량과 같지는 않습니다. 로컬에서 측정된 응답 시간은 반드시 제공업체 처리 시간과 같은 것은 아닙니다.

3. 비용 (Cost)

비용은 팀이 평가할 수 있는 첫 번째 인프라 트레이드오프(trade-off)인 경우가 많습니다.

유용한 영수증(receipt)은 다음을 구분할 수 있어야 합니다:

• 예상 요청 비용 (Estimated request cost)
• 제공업체 보고 또는 청구된 비용 (Provider-reported or billed cost), 사용 가능한 경우
• 통화 (Currency)
• 가격 책정 출처 (Pricing source)
• 가격 버전 또는 유효 날짜 (Pricing version or effective date)

공개 토큰 가격을 기반으로 계산된 비용은 검증된 청구 기록(verified billing record)으로 표시되어서는 안 됩니다.

4. 에너지 (Energy)

에너지는 측정 문제가 특히 어려워지는 부분입니다.

정확히 무엇을 측정하는 것일까요?

가속기(accelerator)? 서버? 네트워킹? 냉각(Cooling)? 공유 인프라 할당량인가요?

제안된 영수증에는 에너지 값, 그 단위, 시스템 경계(system boundary), 그리고 증거 분류(evidence classification)가 포함될 수 있습니다.

개별 요청에 대해 에너지를 신뢰성 있게 결정할 수 없다면, 영수증에 그렇게 명시해야 합니다.

사용 불가(Unavailable)는 유효한 기술적 답변입니다.

5. 탄소 (Carbon)

탄소 수치는 단순한 에너지 추정치를 넘어섭니다.

전기 배출 계수(electricity emissions factor)와 회계 방법(accounting method)에도 의존합니다.

유용한 영수증은 다음을 설명해야 합니다:

• 에너지 기반 (Energy basis)
• 탄소 집약도 출처 (Carbon intensity source)
• 지리적 및 시간적 가정 (Geographic and temporal assumptions)
• 회계 방법 (Accounting method)
• 결과가 측정된 것인지, 모델링된 것인지, 추정된 것인지 여부

두 가지 계산은 어느 쪽도 요청의 배출량을 직접 측정한 것이 아님에도 불구하고 다른 답변을 산출할 수 있습니다.

6. 물 (Water)

물은 자체 필드와 방법론이 필요합니다.

탄소로부터 단순한 변환으로 취급되어서는 안 됩니다.

영수증은 직접 냉각수(direct cooling water), 전기 생산용 물(electricity-generation water), 소비량 대 인출량(consumption versus withdrawal) 등을 구분해야 할 수도 있으며, 추정치에 사용된 경계도 명시해야 합니다.

입력값이 누락된 경우, 정확한 밀리리터 수치를 표시하는 것이 명확함보다 혼란을 더 야기할 수 있습니다.

7. 위치 및 그리드 정보 (Location and grid information)

위치는 중요하지만, 알려진 것을 과장하기 쉽습니다.

제공자 리전 레이블이 요청의 모든 부분이 처리된 정확한 물리적 위치를 반드시 확립하는 것은 아닙니다.

따라서 그리드 강도 정보는 출처, 타임스탬프, 지리적 해상도 및 가정을 포함해야 합니다.

영수증은 증거가 뒷받침하는 것보다 더 많은 위치 확실성을 암시해서는 안 됩니다.

8. 방법론 및 불확실성

이 부분이 가장 중요할 수 있습니다.

모든 환경 값에는 증거 레이블이 있어야 합니다:

측정됨 (Measured): 정의된 측정 프로세스를 기반으로 하며, 명시된 경계가 있어야 합니다.

모델링됨 (Modeled): 명시적인 모델과 가정을 사용하여 계산됩니다.

추정됨 (Estimated): 사용 가능한 입력 또는 대리 정보로부터 근사화됩니다.

사용 불가 (Unavailable): 방어할 수 있는 값을 보고하기에 증거가 불충분합니다.

이 범주들은 문서화된 정의를 필요로 합니다. 마케팅 배지가 되어서는 안 됩니다.

성숙한 영수증 디자인은 또한 방법론 버전, 입력 출처, 신선도 및 의미 있게 특성화될 수 있는 불확실성을 식별해야 합니다.

가능한 영수증 구조

다음 JSON은 CarbonLayer의 현재 API 또는 Playground에서 나오는 결과물이 아니라 개념적 스키마 예시입니다.

{
  "receiptVersion": "proposal-0.1",
  "request": {
...

많은 값이 null인 것을 주목하세요.

이것은 의도된 것입니다.

신뢰할 수 있는 스키마는 정밀도를 발명하지 않고 누락된 증거를 나타낼 수 있도록 해야 합니다.

CarbonLayer의 현재 위치

CarbonLayer의 공개 API 프로토타입은 시뮬레이션된 영수증을 반환합니다.

별도의 비용 및 지연 시간 Playground는 모델 기반 시뮬레이션을 통해 비용과 지연 시간을 탐색합니다. 또한 제공자 자격 증명이 구성되면 단일 요청 모드를 가지고 있어 직접적인 제공자 호출을 한 번 수행할 수 있습니다. 이 호출은 프로덕션 라우팅이 아닙니다.

실제 추론당 환경 영향 데이터는 여전히 사용할 수 없습니다.

위의 스키마는 논의를 위한 방향이지, 이러한 필드가 이미 구현되었다는 주장은 아닙니다.

더 큰 과제: 영수증을 비교 가능하게 만들기

만약 두 공급자가 내일 환경 영수증을 반환한다고 해도, 그 수치가 비교 가능할까요?

그들의 경계(boundaries), 출처(sources), 정의(definitions), 그리고 방법론(methods)을 이해한다면 말입니다.

그렇지 않다면, 한 공급자는 가속기 에너지(accelerator energy)를 보고할 수도 있고 다른 공급자는 더 광범위한 시설 간접비(facility overhead)를 포함할 수도 있습니다. 둘 다 그 결과를 '추론당 에너지(energy per inference)'라고 명명할 수 있지만, 실제로는 서로 다른 것을 설명하고 있는 것입니다.

이것이 제가 생각하기에 다음 질문은 단순히 어떤 필드를 추가해야 하는지가 아니라는 이유입니다.

그것은 업계가 이 필드들이 무엇을 의미하는지에 대해 합의할 수 있느냐 여부입니다.

시리즈의 다음 내용: AI 영향 영수증은 표준화될 수 있을까?

파트 4에서는 일반적인 사양(specification)이 무엇을 요구할지, 어떤 정의들에 대한 합의가 필요한지, 그리고 개발자들이 어떻게 유용한 계약(contract)을 만드는 데 도움을 줄 수 있는지 탐구할 예정입니다.

왜냐하면 목표는 단순히 영수증을 생성하는 것이 아니기 때문입니다.

그것은 그 영수증이 이해 가능하고, 검사 가능하며, 궁극적으로 상호 운용(interoperable)될 수 있도록 만드는 것입니다.

개발자 질문: 만약 Impact Receipt API를 설계한다면, 어떤 필드를 반드시 포함하도록 주장하시겠습니까? 그리고 더 많은 증거 없이는 신뢰하기를 거부하는 필드는 무엇입니까?

CarbonLayer 살펴보기: https://carbonlayer.polsia.io