Skip to content
←

Split View: 동형암호 컴파일러 HEIR과 비용이라는 조건 — 발표문에 없는 숫자를 댓글이 채운 사례

✨ Learn with Quiz
|

동형암호 컴파일러 HEIR과 비용이라는 조건 — 발표문에 없는 숫자를 댓글이 채운 사례

이 글은 2026-08-15에 Hacker News API와 GeekNews 피드에서 직접 확인한 항목을 바탕으로 합니다. 점수와 순위는 계속 바뀝니다.

무엇이 올라와 있었나

Hacker News API로 확인한 항목입니다. 제목은 Google is making private AI practical with homomorphic encryption, 아이템 번호는 49300314이고 2026-08-15 기준 234점에 댓글 143개입니다. 링크는 Google 보안 블로그의 글입니다.

발표문이 소개하는 것은 HEIR이라는 오픈소스 컴파일러 툴체인이자 개발 플랫폼입니다. 이름 자체가 동형암호용 중간 표현이라는 뜻이고, 학습이 끝난 모델을 암호문 위에서 동작하도록 변환해 준다고 적혀 있습니다.

뉴스는 암호가 아니라 컴파일러입니다

동형암호 자체는 새롭지 않습니다. 암호문 위에서 덧셈과 곱셈을 하고 결과를 암호문으로 돌려주는 방식은 오래전부터 알려져 있었습니다. 그런데 배포 사례가 드문 이유는 수학이 부족해서가 아니었습니다.

실제 장벽은 파라미터 선택입니다. 동형암호에서는 연산을 거듭할수록 잡음이 쌓이고, 그 잡음이 허용치를 넘으면 복호화 결과가 무너집니다. 그래서 회로를 설계할 때 잡음 예산을 계산하고, 어디에서 부트스트래핑을 해서 예산을 되돌릴지 정하고, 여러 값을 하나의 암호문 슬롯에 어떻게 나눠 담을지 결정해야 합니다.

이 결정들은 서로 얽혀 있습니다. 패킹을 바꾸면 필요한 회전 연산이 바뀌고, 그러면 잡음 증가율이 바뀌고, 그러면 부트스트래핑 위치가 바뀝니다. 그리고 하나라도 틀리면 결과가 조용히 망가집니다. 이 작업을 손으로 할 수 있는 사람이 세상에 많지 않았고, 그것이 이 기술이 논문에 머물러 온 실질적 이유였습니다.

발표문이 말하는 HEIR의 의의가 정확히 이 지점입니다. 이 결정들을 컴파일러 패스로 옮긴다는 것이고, 그래서 암호 전문가가 매번 붙지 않아도 된다는 것입니다. 중간 표현을 두는 이유도 여기 있습니다. 여러 백엔드와 여러 암호 방식에 대해 같은 최적화를 재사용하려는 구조입니다.

이것은 익숙한 이야기입니다. 어떤 기술이 널리 쓰이게 되는 계기는 대개 그 기술 자체의 개선이 아니라 그것을 쓰는 데 필요한 전문성을 도구가 흡수한 시점입니다.

발표문이 말하지 않은 숫자

그런데 이 발표문에는 결정적인 빈칸이 있습니다. 오버헤드 수치가 하나도 없습니다.

단일 스레드 CPU에서의 지연 측정을 언급하기는 하는데 구체적인 시간도 배수도 나오지 않습니다. 대신 동형암호에 사소하지 않은 비용 오버헤드가 있다고 인정하면서, 그것이 역량과 프라이버시의 맞바꿈을 비용의 문제로 바꾼다는 취지로 서술합니다.

이 표현은 틀린 말은 아니지만, 비용의 문제라고 말하면서 그 비용이 얼마인지 말하지 않으면 독자는 판단할 수 없습니다.

댓글이 그 빈칸을 채웠습니다

이 항목에서 가장 정보량이 큰 부분은 댓글이었고, 여러 명이 자기 배경을 밝히며 숫자를 제시했습니다.

프라이버시 보존 기계학습으로 석사 논문을 쓰고 있다는 댓글은 동형암호를 비롯한 이 계열 기법들이 추론 작업에서 대략 1,000배 수준의 오버헤드를 갖는다고 적었고, 그래서 상업적으로 성립하기 어렵다고 했습니다. 다른 댓글도 1,000배가 넘는 자원 사용을 언급했습니다. 또 다른 댓글은 기본 연산조차 수천 배 복잡한 것으로 알고 있다며 그 사이에 큰 진전이 있었는지 물었습니다.

이 분야로 논문을 두 편 냈다는 댓글은 대형 업체들이 쓸 만한 도구를 내놓는 것은 반갑지만 상업적 실용성까지는 아직 멀다고 정리했습니다. 20년 전 이 분야를 조사했다는 댓글은 당시 결론이 암호문 팽창이 가장 큰 병목이라는 것이었다고 회고했습니다. 이 지적은 지금도 유효한데, 연산 시간만 보고 저장과 전송 비용을 빠뜨리는 경우가 많기 때문입니다.

그렇다면 어디에 적용되는가

발표문에 실린 네 가지 시연 사례를 위 숫자와 겹쳐 보면 적용 조건이 선명해집니다. 사례는 딥러닝 추천 시스템, 신용카드 부정 거래 탐지, Kitsune 기반 네트워크 침입 탐지, 그리고 오디오 프라이버시를 위한 호출어 탐지입니다.

이 넷의 공통점이 있습니다.

  • 모델이 작습니다. 부정 거래 탐지나 호출어 탐지는 파라미터가 큰 모델이 아닙니다. 1,000배 오버헤드는 원래 비용이 작을 때만 감당됩니다.
  • 입력이 작고 출력이 더 작습니다. 대개 특징 벡터가 들어가고 점수 하나 또는 레이블 하나가 나옵니다. 암호문 팽창의 영향이 제한됩니다.
  • 연산 깊이가 얕습니다. 층이 얕으면 잡음이 덜 쌓이고 부트스트래핑을 적게 하거나 아예 피할 수 있습니다.
  • 데이터가 민감하고 지연에 여유가 있습니다. 몇백 밀리초가 몇 초가 되어도 서비스가 성립하는 종류입니다.

여기서 뒤집으면 적용되지 않는 곳도 바로 나옵니다. 대형 언어 모델 추론은 이 네 조건을 전부 어깁니다. 모델이 크고, 입력과 출력이 길고, 층이 깊고, 사용자가 응답을 기다립니다. 이 발표문을 읽고 프롬프트를 암호화한 채로 모델을 돌릴 수 있게 됐다고 이해하면 안 됩니다. 발표문도 그런 주장을 하지 않습니다.

어떻게 적용하나

지금 이 기술을 검토할 만한 상황인지 판단하는 기준은 단순합니다. 여러분의 워크로드에서 서버가 평문을 보지 못하게 만드는 것의 가치가 1,000배의 계산 비용보다 큰가.

이 질문이 참이 되는 경우는 생각보다 있습니다. 여러 기관이 데이터를 합쳐야 하는데 규제 때문에 원본을 넘길 수 없는 경우, 서비스 제공자가 데이터를 볼 수 없다는 것 자체가 제품의 판매 조건인 경우, 감사 대상이라 접근 자체를 기술적으로 차단해야 하는 경우입니다. 이런 자리에서는 오버헤드가 협상 가능한 항목이 됩니다.

그리고 검토한다면 순서가 있습니다. 먼저 더 싼 대안을 배제해야 합니다. 기기 내부에서 추론하기, 서버에 보내기 전에 특징만 추출하기, 신뢰 실행 환경 쓰기, 차등 프라이버시로 집계만 공개하기가 모두 훨씬 쌉니다. 댓글에서도 가장 사적인 추론은 자기 하드웨어에서 도는 것이라는 지적이 나왔는데, 이것은 비아냥이 아니라 실제로 첫 번째로 검토할 선택지입니다. 이 갈래는 기기 내 AI와 엣지 추론의 프라이버시에서 다뤘습니다.

그 대안들이 모두 성립하지 않을 때, 즉 계산은 반드시 서버에서 해야 하고 서버는 절대 내용을 보면 안 될 때, 그때가 동형암호가 유일한 답이 되는 자리입니다.

누구에게는 해당 없는가

일반적인 웹 서비스에서 저장 데이터 암호화와 전송 구간 암호화를 하고 있는 조직이라면 이 기술은 지금 필요하지 않습니다. 그 두 가지는 서버가 데이터를 볼 수 있다는 전제 위에서 다른 위협을 막는 것이고, 대부분의 규제 요구는 거기서 충족됩니다.

성능이 제품의 핵심인 서비스도 해당이 없습니다. 1,000배는 튜닝으로 메울 수 있는 격차가 아닙니다.

암호 이행 계획을 세우는 팀이라면 이것과 양자 내성 암호로의 전환은 별개의 작업이라는 점을 분명히 해야 합니다. 후자는 기한이 있는 마이그레이션이고 전자는 아직 선택적 역량입니다. 그 구분은 양자 내성 암호 전환에서 다룬 내용과 함께 보면 좋습니다.

정리

이 발표에서 실제로 진전된 것은 암호 성능이 아니라 접근성입니다. 컴파일러가 전문가의 판단을 흡수하면 그 기술을 쓸 수 있는 사람의 수가 늘어나고, 그것이 채택의 실제 조건인 경우가 많습니다. 다만 비용의 문제라고 말하면서 비용을 적지 않은 발표문은 절반만 알려 준 것이고, 그 나머지 절반은 이 항목의 댓글에 있었습니다. 판단에 필요한 숫자가 발표문에 없을 때 토론이 왜 가치 있는지를 보여 주는 사례이기도 합니다.

원문과 관련 글

적용 조건 네 가지와 검토 순서는 발표문과 댓글에서 확인한 내용을 바탕으로 제가 정리한 것입니다.

The HEIR Homomorphic Encryption Compiler and the Condition Called Cost — When the Comments Supply the Number the Announcement Omits

This post is based on items I read directly from the Hacker News API and the GeekNews feed on 2026-08-15. Scores and rankings keep moving.

What was up there

An item read from the Hacker News API. The title is Google is making private AI practical with homomorphic encryption, the item number is 49300314, and as of 2026-08-15 it stood at 234 points with 143 comments. The link points to a post on the Google security blog.

What the announcement introduces is HEIR, an open source compiler toolchain and development platform. The name itself stands for a homomorphic encryption intermediate representation, and it converts pre-trained models to operate on ciphertext.

The news is the compiler, not the cryptography

Homomorphic encryption is not new. Adding and multiplying over ciphertext and getting ciphertext back has been known for a long time. Deployments are rare, but not for want of mathematics.

The real barrier is parameter selection. In homomorphic encryption, noise accumulates as operations pile up, and once it passes a limit the decrypted result collapses. So designing a circuit means computing a noise budget, deciding where to bootstrap to reset that budget, and deciding how to pack multiple values into ciphertext slots.

These decisions are entangled. Change the packing and the required rotations change, which changes the noise growth rate, which changes where bootstrapping has to go. And if any one of them is wrong, the result breaks silently. Not many people in the world can do this by hand, and that has been the practical reason this technology stayed in papers.

What the announcement claims for HEIR sits exactly there: it moves those decisions into compiler passes, so a cryptographer does not have to be attached to every project. That is also why there is an intermediate representation — the structure lets the same optimizations be reused across several backends and several schemes.

This is a familiar story. What makes a technology widely used is usually not an improvement in the technology itself but the moment tooling absorbs the expertise required to use it.

The number the announcement does not give

But there is a decisive blank in this announcement: there is not a single overhead figure.

It mentions latency measurements on a single-threaded CPU, yet no concrete time and no multiplier appears. Instead it acknowledges that homomorphic encryption carries a nontrivial cost overhead, framing that as shifting the capability-versus-privacy trade-off into a question of cost.

That framing is not wrong, but calling something a question of cost without saying what the cost is leaves the reader unable to judge.

The comments filled that blank

The most information-dense part of this item was the comments, where several people stated their background and supplied numbers.

A commenter writing a master's thesis on privacy-preserving machine learning wrote that homomorphic encryption and related techniques carry roughly a thousandfold overhead on inference tasks, and are therefore hard to justify commercially. Another comment cited resource usage of more than a thousand times. A third said their understanding was that even basic operations were thousands of times more complex, and asked whether there had been a major advance since.

A commenter who has published two papers in the area summed it up as welcome that large players are producing usable tooling, but still far from commercial viability. Someone who researched the field twenty years ago recalled that their conclusion then was that ciphertext expansion was the biggest bottleneck. That point still holds, because people often look only at compute time and leave out storage and transfer cost.

So where does it apply?

Overlaying the four demonstrations in the announcement with those numbers makes the conditions sharp. The cases are a deep learning recommendation system, credit card fraud detection, network intrusion detection based on Kitsune, and hotword detection for audio privacy.

They share four properties.

  • The models are small. Fraud detection and hotword detection are not large-parameter models. A thousandfold overhead is only survivable when the base cost is small.
  • Inputs are small and outputs smaller. Typically a feature vector goes in and one score or one label comes out. The impact of ciphertext expansion is bounded.
  • The computation is shallow. Fewer layers means less accumulated noise, so bootstrapping can be reduced or avoided entirely.
  • The data is sensitive and the latency budget is loose. These are services that still work when a few hundred milliseconds become a few seconds.

Inverting that gives where it does not apply immediately. Large language model inference violates all four: the model is big, inputs and outputs are long, the network is deep, and a user is waiting. Do not read this announcement as meaning you can now run a model on an encrypted prompt. The announcement makes no such claim.

How to apply this

The test for whether this is worth evaluating now is simple: in your workload, is the value of keeping the server from seeing plaintext greater than a thousandfold compute cost?

That is true more often than you might think. Several institutions that must combine data but cannot hand over originals due to regulation; a product where the provider's inability to see the data is itself the selling condition; an audited context where access must be technically blocked rather than merely prohibited. In those places, overhead becomes a negotiable line item.

And if you do evaluate, there is an order. First, rule out the cheaper alternatives. Inference on the device, extracting only features before sending to the server, a trusted execution environment, differential privacy releasing aggregates only — all are far cheaper. One comment noted that the most private inference is the one running on your own hardware; that is not a snipe, it is genuinely the first option to consider. This thread is covered in on-device AI and privacy in edge inference.

When none of those hold — when the computation must happen on a server and the server must never see the contents — that is the seat where homomorphic encryption is the only answer.

Who this does not apply to

If you run an ordinary web service with encryption at rest and in transit, you do not need this now. Those two defend against different threats on the premise that the server can see the data, and most regulatory requirements are satisfied there.

Services where performance is the core of the product are also out. A thousandfold is not a gap you close with tuning.

If you are planning a cryptographic roadmap, be clear that this and the migration to post-quantum cryptography are separate work. The latter is a migration with a deadline; the former is still an optional capability. That distinction pairs well with migrating to post-quantum cryptography.

Summary

What actually advanced in this announcement is not cryptographic performance but accessibility. When a compiler absorbs an expert's judgment, the number of people who can use the technology grows, and that is frequently the real condition for adoption. But an announcement that calls something a question of cost while omitting the cost has told you only half, and the other half was in this item's comments. It is also a case study in why discussion is worth reading when the number you need to decide is missing from the source.

Sources and related reading

The four applicability conditions and the evaluation order are my own, built on the announcement and the comments.