벤치마크에는 기기, 워크로드, 방법, 불확실성이 필요합니다. 빨라 보이는 숫자 하나만으로는 충분하지 않습니다.
Android에서 ML-KEM-768이 배터리를 얼마나 소모하는지 모든 경우에 적용할 수 있는 비율을 근거 있게 제시할 수는 없습니다. 비용은 구현 방식, 휴대전화, 세션 설정, 키 갱신 빈도, 네트워크 동작에 따라 달라집니다. 데스크톱에서 암호 연산 벤치마크가 빠르다는 사실만으로 모바일 메신저 전체의 배터리 사용 시간을 입증할 수는 없습니다.
이 글에서는 표준을 통해 계산할 수 있는 사항과 측정이 필요한 사항을 설명합니다. 이 글을 위해 Livara의 Android 배터리 벤치마크를 수행하지 않았습니다. 아래 절차는 테스트 계획이며, 측정 결과를 제시하는 것이 아닙니다.
표준으로 알 수 있는 것
ML-KEM은 키 캡슐화 메커니즘입니다. 프로토콜이 대칭 암호화에 사용할 수 있는 공유 비밀값을 설정하도록 돕습니다. FIPS 203에 따르면 ML-KEM-768의 캡슐화 키는 1,184바이트이고 암호문은 1,088바이트입니다. 이 두 객체의 합계는 2,272바이트입니다.
이 합계는 메시징 핸드셰이크 전체의 크기가 아니며, 네트워크에서 추가로 발생하는 비용과 반드시 같은 것도 아닙니다. 인증서, 서명, 기존 암호 방식의 키 자료, 프레이밍, 인코딩, 캐시된 키, 재전송에 따라 실제로 전송되는 바이트 수가 달라질 수 있습니다. “768”은 매개변수 집합의 식별자이지, 공유 비밀값의 길이가 768비트라는 뜻이 아닙니다. 이 집합은 NIST 보안 범주 3을 목표로 합니다.
| 항목 | 알고리즘으로 정해지는가, 측정해야 하는가? |
|---|---|
| 캡슐화 키와 암호문의 길이 | 선택한 ML-KEM 매개변수 집합으로 정해짐 |
| 키 생성, 캡슐화, 역캡슐화 시간 | 실제 구현과 기기에서 측정 |
| 전체 세션 설정에 사용된 바이트 수 | 프레이밍과 재시도를 포함한 프로토콜 측정 |
| 종단 간 전송 지연 | 앱과 네트워크를 함께 측정 |
| 워크로드별 에너지 소모 | 조건을 통제한 기기 수준 실험으로 측정 |
세션마다 한 번만 비용이 발생할까?
반드시 그렇지는 않습니다. 프로토콜은 초기 설정 때 KEM을 사용하고, 주기적인 양자 내성 키 업데이트 때 다시 사용할 수 있습니다. 그룹 구성원 변경, 새 기기, 세션 실패, 복구로 추가 작업이 발생할 수도 있습니다. 올바른 측정 단위는 프로토콜 이벤트입니다. 모든 대화에서 KEM 연산이 정확히 한 번만 수행된다고 가정해서는 안 됩니다.
Livara가 공개한 LVR1 아키텍처는 일반적인 메시지 체인 단계와 함께 주기적인 ML-KEM 에포크가 있음을 설명합니다. 따라서 유용한 벤치마크는 정상 상태의 메시징과 키 갱신 이벤트를 모두 다뤄야 합니다. 양자 내성 연산이 다시는 발생하지 않는다고 주장해서는 안 됩니다.
저장된 암호문의 바이트 수만으로도 에너지 소모를 거의 알 수 없습니다. 패킷이 하나 더 생기는 경우와 이미 진행 중인 전송에 몇 바이트가 추가되는 경우는 무선 통신 동작에 서로 다른 영향을 줄 수 있습니다.
재현 가능한 Android 측정 계획
1. 환경 기록하기
휴대전화 모델, Android 빌드, 앱 버전, 암호 라이브러리 버전, 빌드 모드, 배터리 상태, 온도 상태를 기록합니다. 네트워크 유형과 신호 상태도 기록합니다. 벤치마크 보고서에 비공개 계정 데이터나 패킷 내용을 공개하지 마세요.
2. 암호 기본 연산 테스트와 앱 테스트 구분하기
기본 연산 테스트는 키 생성, 캡슐화 또는 역캡슐화를 개별적으로 측정합니다. 앱 전체 테스트는 세션 생성, 메시지 전송, 연결 중단 후 복구를 측정합니다. 두 결과가 모두 있으면 각각 보고하고, 한쪽을 다른 쪽의 결과로 표시하지 마세요.
여러 차례 반복하고 가장 빠른 실행만 고르는 대신 중앙값과 높은 백분위수 등 결과의 분포를 보고합니다. 워밍업, 런타임 컴파일, 발열에 따른 성능 제한이 결과에 영향을 줄 수 있습니다.
3. 현실적인 워크로드 정의하기
- 새 일대일 메시지 세션을 설정합니다.
- 이미 설정된 세션에서 개수와 크기가 고정된 메시지를 전송합니다.
- 문서에 명시된 키 갱신 경계를 넘는 동작을 테스트합니다.
- 지원되는 경우 테스트 그룹에 구성원을 추가하거나 제거합니다.
- 동일한 조건에서 동일한 첨부 파일을 전송합니다.
- 일정 시간 앱을 유휴 상태로 두고 백그라운드 동작을 별도로 측정합니다.
합성 콘텐츠와 소유자가 동의한 테스트 계정을 사용합니다. 그룹 테스트에서는 구성원 수를 밝혀야 합니다. 두 명으로 이루어진 그룹의 결과를 별다른 설명 없이 대규모 그룹에 적용할 수는 없습니다.
4. 시간과 함께 에너지 측정하기
Android Studio의 Power Profiler는 지원되는 하드웨어에서 활동과 전력 레일 측정값의 상관관계를 보여 줄 수 있습니다. Google은 이러한 값이 기기 수준의 측정이므로 다른 활동이 측정 잡음을 유발한다고 경고합니다. 지원되는 측정 방법은 기기마다 다릅니다.
화면 밝기, 백그라운드 작업, 네트워크 조건, 테스트 시간을 통제합니다. 같은 워크로드를 반복하고 같은 조건끼리 비교합니다. 사용하는 방법으로 암호 연산의 기여분을 분리할 수 없다면, 배터리 소모 전체를 ML-KEM 탓으로 돌리지 말고 그 한계를 명시하세요.
측정 환경을 나타낸 그림이며, 기록된 벤치마크 결과가 아닙니다.
유용한 결과 표에는 무엇이 들어가야 할까?
| 결과 항목 | 기록할 정보의 예 |
|---|---|
| 워크로드 | 새 세션, 설정된 세션의 메시징 또는 키 갱신 |
| 환경 | 정확한 기기, 앱 빌드, 네트워크 |
| 시행 | 횟수와 워밍업 실행의 처리 방식 |
| 시간 | 중앙값, 변동, 단위 |
| 트래픽 | 측정된 바이트 수와 재전송 조건 |
| 에너지 | 방법, 측정 구간, 불확실성 |
| 한계 | 테스트에서 분리하지 못했거나 다루지 않은 사항 |
측정하지 않은 셀은 비워 두거나 “측정하지 않음”으로 표시합니다. 상대적인 비중을 임의로 만들어 넣은 설명용 에너지 막대그래프는 증거가 아닙니다.
사진과 동영상은 어떨까?
대용량 첨부 파일은 일반적으로 콘텐츠 블록마다 ML-KEM을 사용하는 대신 대칭 암호화를 사용합니다. 키 설정은 여전히 초기 설정에 영향을 줄 수 있으며, 파일 처리, 저장소, 네트워크 전송, 재시도 로직은 전체 작업에 영향을 줍니다. 각 부분의 상대적인 기여도는 실제 워크로드에서 측정해야 합니다. “절대 체감할 수 없다”는 말은 타당한 보편적 주장이 아닙니다.
자주 묻는 질문
ML-KEM-768은 항상 P-256보다 느릴까?
모든 라이브러리와 하드웨어에 적용되는 보편적인 비교 결과는 없습니다. 같은 조건에서 같은 연산을 비교한 다음, 전체 하이브리드 프로토콜을 별도로 측정하세요.
APK 체크섬이 성능 측정 결과를 검증할까?
신뢰할 수 있는 기준값과 비교하면 테스트에 사용한 정확한 파일을 식별할 수 있습니다. 하지만 테스트 방법, 구현의 안전성, 에너지 측정의 타당성을 검증하지는 않습니다.
배터리를 아끼려면 암호화를 꺼야 할까?
근거 없는 성능 주장을 이유로 필요한 보안 요건을 포기하지 마세요. 먼저 실제 배터리 소모 원인을 파악하고, 지원되는 설정이나 업데이트를 사용하세요.
