15. 비용·성능·전력 주장에 필요한 조건 — 분자·분모·이용률·시간·품질·SLO

이 장의 핵심 질문

• "더 싸다·더 빠르다·전력을 덜 쓴다"는 주장은 무엇이 명시돼야 검증 가능한가?
• 두 정량 주장이 직접 비교 가능한지를 어떻게 판정하는가?
• 왜 분모가 다르면 아무리 그럴듯한 순위도 무의미한가?

앞 장과의 연결 — 앞의 모든 묶음에서 🔬 증거 읽기가 반복해 "분자·분모·조건을 붙여라"고 했다. 이 장은 그 판정을 정식 절차로 만든다. 01장의 세 축(capacity/latency/traffic), 05장의 total/activated, 10장의 goodput·SLO, 14장의 전력이 모두 여기서 "분모"로 소환된다. 이 장은 17장 브리프의 조건표를 준비한다.

먼저: 정량 주장은 왜 그 자체로 불완전한가

"우리 시스템은 40% 싸다"는 문장은 정보가 아니라 미완성 문장이다. 무엇이 40% 싼가? 무엇 대비? 어떤 조건에서? 이 빈칸이 채워지지 않으면 검증도 비교도 불가능하다.

일상 비유: "이 차가 더 연비가 좋다"는 말은 (a) 무엇을 재는지(연비=거리/연료), (b) 무엇 대비(어떤 차와), (c) 어떤 조건(시내? 고속? 적재? 속도?)이 없으면 판단할 수 없다. 정량 주장은 항상 이 세 요소를 요구한다.

이 장은 그 요소를 여섯 개로 구체화한다: 분자, 분모, 이용률, 시간, 품질, SLO.

여섯 개의 필수 조건

정량 주장(비용·성능·전력)을 만나면 아래 여섯을 채운다. 하나라도 비면 그 주장은 미완성이다.

1) 분자(numerator) — 무엇을 세는가

"싸다·빠르다·적다"의 대상. 요청 수? 토큰 수? 달러? 와트? 실패율? 분자가 불명확하면 나머지가 무의미하다.

2) 분모(denominator) — 무엇당인가

가장 자주 누락되고 가장 치명적인 요소. 무엇당 값인가?

• 비용: 요청당? 토큰당? device당? 시간당? ("토큰당 $"과 "요청당 $"은 완전히 다르다 — 긴 응답일수록 요청당 비용이 커진다.)
• 성능: 단일 요청 latency? 초당 총 토큰? device당 처리량? (01장의 세 축이 곧 분모다.)
• 전력: 토큰당 줄(J)? 요청당 Wh? perf/W?

📌 핵심 — 분모가 다르면 비교 불가 — "토큰당 비용"과 "요청당 비용"을 나란히 순위 매기는 것은 무의미하다. 분모가 다른 두 수치는 애초에 같은 표에 놓을 수 없다. 이것이 이 안내서 전체의 비교 가능성 판정의 핵심이다.

3) 이용률(utilization) — 얼마나 채운 상태에서

같은 하드웨어라도 얼마나 바쁜 상태에서 잰 값인가. 이용률 10%일 때의 "device당 처리량"과 90%일 때의 값은 다르다. 특히:

• 낮은 이용률에서 잰 latency는 좋아 보이지만 실운영(높은 부하)과 다르다.
• 포화(saturation, 10장) 근처에서 잰 throughput은 높아 보이지만 tail이 터져 goodput이 아니다.
• 비용 주장은 이용률에 극도로 민감하다: device가 놀면 "device당 비용"이 치솟는다.

4) 시간(time) — 어느 시간축의 값인가

• 순간 vs 지속 — 순간 최대 처리량과 지속 가능한 처리량은 다르다.
• 워밍업 포함 여부 — 콜드 스타트·캐시 워밍업(12장) 전후가 다르다.
• 측정 구간 — 짧은 벤치 구간의 값이 장기 운영을 대표하는가.

5) 품질(quality) — 무엇을 포기했는가

성능·비용 이득이 품질을 내주고 얻은 것은 아닌가. 특히:

• 양자화(선수 ①②, 08장 KV 양자화) — 저정밀으로 속도·메모리를 얻으면 품질이 얼마나 바뀌었나. 품질 저하를 숨긴 속도 주장은 과장이다.
• speculative decoding·근사 기법 — 수용률(acceptance rate)·정확도 영향은?
• 품질을 고정하지 않은 성능 비교는 "더 나쁜 답을 더 빨리"일 수 있다.

6) SLO — 어떤 약속을 지키며

10장의 핵심: throughput은 SLO를 붙여야 goodput이 된다. "초당 N개"가 어떤 tail SLO(p99 TTFT·TPOT)를 지키며 나온 값인가. SLO 없는 처리량 주장은 유효 처리량이 아니다.

flowchart TB
    CLAIM["정량 주장<br/>'더 싸다/빠르다/적다'"]
    CLAIM --> N["① 분자<br/>무엇을 세는가"]
    CLAIM --> D["② 분모<br/>무엇당인가 ⚠️"]
    CLAIM --> U["③ 이용률<br/>얼마나 바쁜가"]
    CLAIM --> T["④ 시간<br/>순간/지속·워밍업"]
    CLAIM --> Q["⑤ 품질<br/>무엇을 포기했나"]
    CLAIM --> S["⑥ SLO<br/>어떤 약속 지키며"]

    N --> CHECK{"여섯 개<br/>모두 채워졌나?"}
    D --> CHECK
    U --> CHECK
    T --> CHECK
    Q --> CHECK
    S --> CHECK
    CHECK -->|"하나라도 빔"| INCOMPLETE["미완성 주장<br/>→ 검증·비교 불가"]
    CHECK -->|"모두 채움"| OK["검증 가능<br/>→ 비교 가능성 판정으로"]

    classDef claim fill:#fff3c4,stroke:#d4a017,color:#000
    classDef factor fill:#cfe2ff,stroke:#2563eb,color:#000
    classDef denom fill:#e9d8fd,stroke:#7c3aed,color:#000
    classDef bad fill:#ffd6d6,stroke:#dc2626,color:#000
    classDef good fill:#d1f0d1,stroke:#16a34a,color:#000
    class CLAIM claim
    class N,U,T,Q,S factor
    class D denom
    class INCOMPLETE bad
    class OK good

비교 가능성 판정 절차

두 정량 주장이 직접 비교 가능한지를 판정하는 절차. 순위를 매기기 전에 반드시 거친다.

1. 여섯 조건을 각각 채운다 — 두 주장 모두에 대해 분자·분모·이용률·시간·품질·SLO를 적는다. 빈칸이 있으면 그 주장은 아직 비교 대상이 아니다(먼저 채우거나 unknown 표시).
2. 분모를 맞춘다 — 두 주장의 분모가 같은가? 다르면(토큰당 vs 요청당 등) 비교 불가. 여기서 대부분의 잘못된 비교가 걸러진다.
3. 조건을 맞춘다 — 이용률·시간·품질·SLO가 같은 범위인가? 다르면 비교하려면 조건을 통제해야 한다(같은 SLO·같은 워크로드로 재측정하거나, 차이를 명시).
4. 판정 — 모두 맞으면 비교 가능. 하나라도 안 맞으면 "직접 비교 불가"라고 명시하고, 왜 불가한지(어느 요소가 다른지)를 적는다.

⚠️ 경계 혼동 주의 — "대략 비슷하니 비교하자"의 유혹 — 조건이 조금 다를 때 "그래도 대충 비교되지 않나"는 흔한 유혹이다. 하지만 분모나 SLO가 다르면 "대충"도 불가능하다. 예를 들어 SLO가 느슨한 시스템의 throughput과 엄격한 시스템의 goodput을 비교하면, 느슨한 쪽이 항상 유리하게 보인다. 조건이 다르면 순위 자체가 의미를 잃는다. "비교 불가"는 무능이 아니라 정직이다.

자주 걸리는 함정들

앞 장들에서 예고한 함정을 여섯 조건으로 재정리한다.

🔬 증거 읽기 — 이 장이 앞의 모든 🔬를 통합한다 — 앞 장의 증거 읽기 박스들은 모두 이 여섯 조건의 부분집합이었다. 이제 어떤 정량 주장을 만나든 같은 체크리스트를 돌린다: 분자·분모·이용률·시간·품질·SLO. 부록의 "비용·성능·전력 주장 감사 체크리스트"가 이 절차를 표로 제공한다.

계산은 최소로, 조건은 최대로

이 안내서는 개념·식 위주다(계산 최소). 하지만 정량 주장을 검증하려면 최소한의 산술이 필요할 때가 있다. 핵심은 계산 자체보다 계산에 넣은 입력·가정을 남기는 것이다.

예를 들어 "토큰당 비용"을 따진다면, 개념적으로:

토큰당 비용 ≈ (device 시간당 비용) / (device당 초당 goodput 토큰) / 3600
             ↑ 이용률·시간에 의존        ↑ SLO·워크로드·이용률에 의존

이 식을 쓸 때 중요한 것은 정확한 숫자가 아니라, 각 항이 어떤 조건(이용률·SLO·워크로드)에 의존하는지를 명시하는 것이다. 분모(초당 goodput 토큰)가 이용률·SLO에 의존하므로, 이 조건이 다르면 "토큰당 비용"도 비교 불가다. (이 식은 예시 구조이며, 실제 배포의 정확한 비용 모델은 그 배포의 조건에 달렸다 — 조건 의존.)

⚖️ 절충 — 정밀한 숫자 vs 조건의 투명성 — 정량 검증에서 정밀한 최종 숫자보다 입력·가정의 투명성이 더 중요하다. 조건이 불투명한 정밀 숫자는 정밀한 오해를 낳는다. "이 가정 하에서 대략 이 범위"가, 조건 없는 "정확히 X"보다 정직하고 유용하다.

이 장에서 배운 것

• 정량 주장(비용·성능·전력)은 여섯 조건이 채워져야 완성된다: 분자·분모·이용률·시간·품질·SLO.
• 분모가 가장 자주 누락되고 가장 치명적이다. 토큰당/요청당/device당은 다른 것이며, 분모가 다르면 비교 불가.
• 비교 가능성 판정: 여섯 조건을 채우고 → 분모를 맞추고 → 조건(이용률·시간·품질·SLO)을 맞추고 → 판정. 하나라도 안 맞으면 "직접 비교 불가"를 명시한다.
• 앞 장의 함정들(total/activated, SLO 없는 throughput, 포화 측정, KV 전송 제외, 양자화 품질 은폐, tail 누락, 벤더 배수, 칩 순위)은 모두 여섯 조건의 위반이다.
• 계산은 최소로, 입력·가정의 투명성은 최대로. 조건 없는 정밀 숫자는 정밀한 오해를 낳는다.

🔎 이 장의 '지지하지 않는 결론' + 'unknown으로 남겨야 할 것'

• 지지하지 않는 결론 — "조건이 조금 달라도 대충 비교하면 된다"는 지지되지 않는다. 분모·SLO가 다르면 순위 자체가 의미를 잃는다.
• unknown으로 남길 것 — 여섯 조건 중 채울 수 없는 것은 unknown으로 남기고, 그 상태로는 비교하지 않는다. 특정 배포의 실제 비용·전력·이용률은 그 조건 없이는 옮기지 않는다.

✍️ 확인 문제

1. "시스템 A는 토큰당 $0.001, 시스템 B는 요청당 $0.05"라는 두 주장을 나란히 "A가 싸다"고 순위 매길 수 있는가? 어느 조건이 다른지, 왜 비교 불가인지, 비교하려면 무엇을 통제해야 하는지 답하라.

1. (종합 유형) 어떤 자료가 "우리 최적화로 처리량 2배, 비용 절반"이라 주장한다. 이 주장에 대해 여섯 조건(분자·분모·이용률·시간·품질·SLO)을 각각 질문 형태로 채워라. 특히 어떤 조건이 빠졌을 때 이 "2배·절반"이 과장일 수 있는가?

1. (품질 유형) "양자화로 처리량을 50% 높였다"는 주장에서 반드시 함께 물어야 할 조건은 무엇인가? 품질을 고정하지 않은 성능 비교가 왜 "더 나쁜 답을 더 빨리"일 수 있는지 설명하라.

다음 장에서는 1차 자료(배포 사례 등)에서 시스템 구성도를 재구성하는 실습을 한다. data/control path·trust boundary·failure domain을 표시하고, explicit·inferred·unknown을 색으로 구분한 두 수준 구성도가 초점이다.
다음 → 16. 1차 자료에서 시스템 구성도 재구성하기 — 두 수준, explicit·inferred·unknown