CKKS vs. GL 벤치마크: 38분에서 12.67초로

한눈에 보기 (TL;DR)

• 암호문×암호문 행렬 곱(CCMM)은 암호화된 AI 추론의 핵심 연산이자 주요 병목 중 하나다. 이 연산을 두고 국제 공개 챌린지 FHERMA 행렬 곱 부문 1위 CKKS 구현(OpenFHE 기반)과 GL 스킴 상용 구현(DESILO FHE 라이브러리)을 같은 기계에서 비교했다. 과제는 64×64 실수 행렬 곱 256쌍이다.
• CPU 한 코어에서 GL은 CKKS 구현보다 최대 약 229배 빨랐다. 레벨을 높인 설정(레벨 16)에서 256쌍 처리에 CKKS 구현은 약 6시간 58분, GL은 109.44초가 걸렸다. 최소 레벨 설정에서는 약 38분 5초 대 12.67초로 약 180배 차이다. CKKS 시간은 1쌍 처리 시간의 10회 평균을 256배로 환산했다.
• 행렬 곱 한 번에 CKKS는 레벨 2개를, GL은 1개를 소모한다. 레벨은 동형암호 암호문의 배터리 잔량에 해당한다. 회로가 깊을수록 이 차이는 가장 비싼 연산인 부트스트래핑 횟수의 차이로 누적된다.
• GL의 우위는 세 가지 조건에서 더 커진다. 행렬 곱이 많고 회로가 깊은 대형 AI 모델, 작은 행렬 여러 개를 한 번에 곱하는 구조, 그리고 GPU를 쓸 수 있는 환경이다.

목차

1. 암호문끼리의 행렬 곱이 중요한 이유
2. 비교 대상: FHERMA 1위 CKKS 구현
3. 측정 조건
4. 레벨 소모
5. 배치 처리
6. 결과 ①: 최소 레벨 설정
7. 결과 ②: 고레벨 설정
8. 정리

FAQ · 참고 자료 · 부록(실험 설정 상세)

---

1. 암호문끼리의 행렬 곱이 중요한 이유

AI 모델이 하는 연산의 대부분은 행렬 곱이다. 데이터를 암호화한 채로 AI를 돌리려면 이 행렬 곱도 암호문 위에서 해야 한다.

암호문 위의 행렬 곱은 두 종류다. 한쪽만 암호문인 경우와 양쪽 모두 암호문인 경우다. 모델 가중치처럼 한쪽이 평문이면 비용이 비교적 낮다. 양쪽이 모두 암호문이면 비용이 크게 늘어난다. 이 글에서는 양쪽이 모두 암호문인 행렬 곱을 CCMM(Ciphertext-Ciphertext Matrix Multiplication)이라고 부른다.

CCMM은 피할 수 없다. 트랜스포머의 어텐션은 질의 행렬 Q와 키 행렬의 전치 Kᵀ를 곱하는데, 둘 다 사용자의 입력에서 나오므로 입력을 암호화하면 둘 다 암호문이 된다. 대형 언어 모델은 층마다 이 곱셈을 반복한다. 그래서 암호화된 AI 추론을 실제로 쓸 만한 속도로 돌릴 수 있는지는 CCMM이 얼마나 빠른지에 달려 있다.

「GL 스킴 깊이 알기」에서는 GL이 이 문제를 스킴 설계 차원에서 어떻게 푸는지를 논문의 수치로 소개했다. 이번 글은 그다음 단계로, 제3자가 만든 공개 챌린지 우승 CKKS 구현과 GL을 같은 문제, 같은 기계에서 직접 비교한 결과다.

2. 비교 대상: FHERMA 1위 CKKS 구현

FHERMA(페르마)는 Fair Math와 OpenFHE 팀이 함께 운영하는 국제 동형암호 챌린지 플랫폼이다. 참가자들이 같은 문제를 놓고 구현 성능을 겨루고, 우승 솔루션은 오픈소스 라이브러리에 편입돼 공개된다. IBM 연구진이 문제를 출제하기도 했다.

비교 대상은 이 플랫폼의 암호화 행렬 곱 챌린지 우승 구현이다. 오스트리아 그라츠공대(TU Graz) 연구자가 작성했고, 널리 쓰이는 오픈소스 동형암호 라이브러리 OpenFHE 위에서 동작한다. 원본 코드는 FHERMA의 챌린지 저장소(github.com/Fherma-challenges/matrix-mult)에 공개되어 있고, 챌린지 결과는 FHERMA 챌린지 페이지에서 확인할 수 있다(열람에는 로그인이 필요하다).

이번 측정은 이 저장소의 제출 코드를 썼다. 행렬 곱 알고리즘은 그대로 두고, 마스크 평문을 만드는 준비 작업만 측정 구간 밖으로 옮겼다. 반복 실행과 시간 측정은 별도의 벤치마크 드라이버로 했다(부록 참고). 링 차원은 제출본과 같은 2¹⁵이고, OpenFHE의 128비트 보안 기준(HEStd_128_classic)을 켠 상태로 실행했다. GL 쪽도 같은 링 차원과 같은 보안 수준에 맞췄다.

3. 측정 조건

측정은 두 가지 조건에서 했다. 하나는 CKKS에 필요한 최소 시작 레벨인 2에 두 구현을 맞춘 설정(6장), 다른 하나는 두 구현을 레벨 16에서 시작해 깊은 연산 파이프라인의 중간 지점을 흉내 낸 설정(7장)이다.

4. 레벨 소모

결과를 읽기 전에 알아둘 배경이 두 가지 있다. 첫째는 레벨이다.

동형암호 암호문에는 레벨(level)이 있다. BGV, BFV, CKKS, GL 등에서 쓰는 표준 용어로, 곱셈을 더 이어갈 수 있는 여유를 나타낸다. 「완전동형암호(FHE) 깊이 알기」에서 설명한 노이즈 예산과 관련이 있지만 같은 개념은 아니다. 이번에 비교한 CKKS와 GL 구현에서는 곱셈을 할 때마다 레벨이 줄고, 다 떨어지면 부트스트래핑으로 다시 채워야 한다. 배터리 잔량에 비유할 수 있다. 부트스트래핑은 동형암호에서 가장 비싼 연산이다.

행렬 곱 한 번에 소모되는 레벨은 스킴마다 다르다. CKKS 기반 우승 구현은 마스킹용 평문 곱 한 단계와 암호문 곱 한 단계가 필요한 알고리즘 구조 때문에 행렬 곱 한 번에 레벨 2개를 소모한다(우승자가 발표한 논문에도 곱셈 깊이 2로 명시돼 있다). GL은 행렬 곱이 스킴의 기본 연산이므로 1개만 소모한다.

이 차이는 세 가지 결과로 이어진다.

• 다른 연산을 빼고 행렬 곱만 이어서 한다면, 같은 레벨로 두 배 많은 행렬 곱을 할 수 있다.
• 부트스트래핑 사이에 더 많은 행렬 곱을 할 수 있다. 실제로 부트스트래핑이 얼마나 줄어드는지는 다른 연산의 레벨 소모와 회로 구성에 따라 달라진다.
• 더 작은 파라미터로 같은 일을 시작할 수 있다.

트랜스포머 추론처럼 행렬 곱이 층층이 쌓이는 회로일수록 이 차이가 커진다.

5. 배치 처리

둘째는 한 번에 처리할 수 있는 행렬 곱의 개수다.

이번에 사용한 CKKS 참조 구현은 한 번의 실행에서 행렬 곱 한 쌍을 처리한다. 그래서 256쌍의 처리 시간은 한 쌍의 측정 시간에 256을 곱해 환산했다. CKKS에서도 여러 행렬을 한 암호문에 넣어 함께 처리하는 방법이 있지만, 이번 참조 구현은 그렇게 작성되어 있지 않다. GL 암호문은 「GL 스킴 깊이 알기」에서 본 것처럼 처음부터 배치×행×열의 3차원 구조여서, (256, 64, 64) 텐서 하나로 256쌍의 행렬 곱을 한 번의 배치 연산으로 처리한다.

이 배치 구조는 AI 워크로드의 형태와 맞는다. 트랜스포머의 멀티헤드 어텐션은 배치와 헤드마다 행렬 곱을 따로 수행한다. BERT-base와 BERT-large의 헤드 차원은 64여서, 입력 길이가 64이면 Q와 Kᵀ의 곱이 64×64 행렬 곱이 된다. (256, 64, 64) 과제는 이런 배치 연산을 단순화한 예다.

6. 결과 ①: 최소 레벨 설정

먼저 CKKS에 필요한 최소 시작 레벨인 2에 두 구현을 맞춘 설정이다. CKKS가 행렬 곱 한 번에 레벨 2개를 쓰기 때문이다. GL은 그중 1개만 쓴다.

256쌍 기준으로 2,285.31초 대 12.67초, 쌍당으로는 8.93초 대 약 0.05초(GL은 256쌍 일괄 처리 시간을 256으로 나눈 값)로, 같은 CPU 한 코어에서 약 180배 차이다.

CKKS의 2,285.31초는 1쌍 처리 시간의 10회 평균에 256을 곱한 환산치다. 표의 수치는 소수점 둘째 자리로 반올림했고, 환산치와 배율은 반올림 전 실측값으로 계산했다. 참조 구현은 한 번에 한 쌍만 처리하므로 256쌍은 256번의 독립 실행으로 계산했다. 실제로 256쌍을 연속 처리할 때 생길 수 있는 캐시·메모리 효과는 반영하지 않았다. 여러 쌍을 한 암호문에 묶어 처리하도록 CKKS 구현을 새로 짜면 이 환산치보다 빨라질 수 있다.

7. 결과 ②: 고레벨 설정

두 번째 측정은 두 구현을 레벨 16에서 시작한 설정이다. 신경망 추론처럼 깊은 회로의 중간에서는 남은 연산을 위해 암호문이 높은 레벨을 유지해야 하고, 레벨이 높을수록 연산 한 번의 비용이 커진다. 이 설정은 그런 상황을 흉내 낸 것이다.

절대치만 보면 GL의 109.44초가 CKKS의 98.04초보다 크지만, 98.04초는 1쌍, 109.44초는 256쌍의 시간이다. 256쌍 기준으로 맞추면 25,097.97초 대 109.44초, 쌍당으로는 98.04초 대 약 0.43초(GL은 일괄 처리 시간을 256으로 나눈 값)로 약 229배다.

최소 레벨 설정의 180배보다 격차가 더 벌어졌다. 이번 측정에서는 레벨을 높였을 때 CKKS 쪽 시간이 더 크게 늘었다(CKKS 약 11배, GL 약 8.6배).

8. 정리

이번 측정에서 FHERMA 우승 CKKS 구현과 GL의 차이는 같은 조건, CPU 한 코어에서 약 180배였고, 레벨을 높인 설정에서는 약 229배로 더 벌어졌다.

이 격차는 다음 조건이 겹칠수록 커진다.

1. 행렬 곱이 연산의 대부분인 워크로드. AI 추론과 학습이 여기에 해당한다.
2. 작은 행렬 여러 개를 동시에 곱하는 구조. 멀티헤드 어텐션과 배치 서빙이 대표적이고, GL의 3차원 암호문이 이 형태를 그대로 담는다.
3. 깊은 회로. 행렬 곱의 레벨 소모가 적은 만큼 부트스트래핑이 덜 필요하다.
4. GPU를 쓸 수 있는 환경. 연산이 평문 행렬 곱으로 환원되는 GL은 GPU 가속을 그대로 받는다(이번 측정은 CPU 단일 코어 기준이다).

이유는 스킴 설계에 있다. GL은 행렬을 배치까지 포함한 3차원 자료형으로 갖고, 암호화된 행렬 곱을 평문 행렬 곱으로 환원하며, 그 곱에 레벨을 하나만 쓴다. 디사일로는 이를 상용 라이브러리로 구현하고 GPU 백엔드를 제공한다.

THOR가 기존 CKKS 위에서 알고리즘을 바꿔 암호화된 BERT 추론 시간을 줄였다면, GL은 스킴 자체를 바꿔 행렬 곱의 비용을 낮춘다.

---

자주 묻는 질문 (FAQ)

Q1. 이 결과는 GL이 CKKS를 대체한다는 뜻인가?

아니다. CKKS는 실수 연산을 처음 실용화한 4세대 동형암호의 표준이고, 원소별 연산 등 여러 작업에서 여전히 좋은 선택이다. 이번 비교가 보여주는 것은 행렬 곱이라는 특정 연산에서 GL의 행렬 연산 구조와 배치 처리 방식이 큰 성능 차이로 나타났다는 점이다. 대규모 행렬 연산이 반복되는 워크로드에 GL이라는 선택지를 더하는 것이 목표이며, DESILO FHE 라이브러리는 CKKS와 GL을 모두 지원한다.

Q2. 왜 하필 챌린지 우승 구현과 비교했는가?

자체 제작한 약한 비교 대상과 비교했다는 오해를 피하기 위해서다. FHERMA 우승 구현은 공개 경쟁을 거친 CKKS 행렬 곱 구현이고, 알고리즘과 코드가 GitHub에 공개되어 있어(Fherma-challenges/matrix-mult) 누구나 확인할 수 있다.

Q3. 두 스킴의 보안 수준은 같은가?

같다. 두 설정 모두 링 차원 2¹⁵에서 128비트 보안 수준으로 맞췄고, CKKS 쪽은 OpenFHE의 HEStd_128_classic 기준을 켠 상태로 실행했다. 파라미터 상세는 부록에 있다.

---

참고 자료

• FHERMA 암호화 행렬 곱 챌린지 페이지(결과 열람은 로그인 필요): https://fherma.io/kernels/matrix-multiplication/challenges/matrix-multiplication-2024
• 우승 CKKS 구현(이번 측정에 사용한 코드) 저장소: https://github.com/Fherma-challenges/matrix-mult
• Aikata, Sujoy Sinha Roy, "Secure and Efficient Outsourced Matrix Multiplication with Homomorphic Encryption," IACR ePrint 2024/1730 (우승 구현 해설 논문, 곱셈 깊이 2 명시): https://eprint.iacr.org/2024/1730
• Craig Gentry, Yongwoo Lee, "Fully Homomorphic Encryption for Matrix Arithmetic," CRYPTO 2026 (IACR ePrint 2025/1935): https://eprint.iacr.org/2025/1935
• Eric Crockett, Craig Gentry, Hyojun Kim, Yeongmin Lee, Yongwoo Lee, "Efficient Bootstrapping in Fully Homomorphic Encryption for Matrix Arithmetic," CRYPTO 2026 (IACR ePrint 2026/956): https://eprint.iacr.org/2026/956
• 관련 글: GL 스킴 깊이 알기: 행렬을 위해 처음부터 다시 설계한 동형암호
• 관련 글: THOR 깊이 알기: 암호문 위에서 LLM을 추론하는 기술

부록: 실험 설정 상세

참조 CKKS 구현은 FHERMA 우승 제출본(github.com/Fherma-challenges/matrix-mult)의 행렬 곱 알고리즘을 그대로 사용했고, 마스크 평문 생성·인코딩만 연산 함수 밖으로 옮겼다. 반복 실행과 시간 측정은 별도의 벤치마크 드라이버로 했으며, 마스크 평문 생성·인코딩·암호화·키 생성을 모두 타이머 밖에서 끝낸 뒤 행렬 곱 구간만 측정했다. Fair Math는 우승 솔루션을 Apache-2.0 라이선스로 공개하고 있다(fairmath/components).

CKKS 측 파라미터는 다음과 같다.

• 링 차원 2¹⁵, 배치 크기 2·64·64
• 스케일링 모듈러스 40비트, 첫 모듈러스 40비트
• 보안 수준 플래그: HEStd_128_classic (두 설정 모두)
• 곱셈 깊이: 2 (최소 레벨 설정) / 16 (고레벨 설정)
• 키 스위칭 HYBRID, 스케일링 기법 FLEXIBLEAUTO, 특수 소수 2개
• 단일 코어, steady_clock 벽시계 시간 10회 평균

GL 측은 DESILO FHE 라이브러리 1.16(공개 버전)의 GLEngine을 shape=(256, 64, 64)로 생성해 암호문 간 matrix_multiply 시간을 측정했고, 링 차원과 보안 수준은 CKKS 측과 같게 맞췄다.

측정은 디사일로 라이브러리 팀의 이영민이 수행했다.