왜 나는 Gmail용 PGP 암호화 레이어를 만들었고 Chrome 확장 프로그램을 오픈소스화했는가
Source: Dev.to
나는 작년에 Gmail을 통해 계약서를 보냈다. 특별한 건 없었다 — 단지 프리랜서 계약서에 고객의 직접 입금을 위한 은행 정보가 포함돼 있었다. 보내기 버튼을 눌렀고, 하루 일과를 이어갔다.
3주가 지난 뒤, 그 고객은 우리 계약서에 적힌 정확한 금액을 언급하는 피싱 이메일을 받았다. 누군가 이를 스크랩해 갔다. 아마도 해킹된 인박스에서, 혹은 서버 침해에서, 혹은 전혀 다른 곳에서였을 수도 있다. 핵심은: 그 이메일이 구글 서버에 평문 그대로 전 기간 동안 저장돼 있었다.
그때 나는 Gmail의 “암호화”가 내가 생각하던 의미와 다르다는 가정을 멈추게 되었다.
Gmail이 실제로 암호화하는 것 (그리고 하지 않는 것)
대부분의 개발자들이 파고들어 보기 전까지는 깨닫지 못하는 점이 있습니다.
- Gmail은 TLS — 전송 계층 보안을 사용합니다. 이메일은 서버 간 이동 중에 암호화됩니다. 브라우저에 보이는 작은 자물쇠 아이콘? 바로 TLS가 제 역할을 하고 있다는 뜻입니다.
- 이메일이 Google 서버에 도착하면 Google이 읽을 수 있는 형식으로 저장됩니다. 시스템은 스팸을 검사하고, Smart Reply가 내용을 읽어 답장을 제안하며, (과거에는) 이메일 내용에 기반해 광고가 타깃팅되었습니다 (Google은 중단했다고 하지만 인프라가 완전히 사라진 것은 아닙니다).
TLS는 전송 중에 중간자 공격으로부터 이메일을 보호합니다. 그러나 Google 서버가 침해되거나, 정부 소환장이 발부되거나, 악의적인 직원이 엿볼 경우에는 전혀 도움이 되지 않습니다.
TLS encryption (in transit):
You ──[encrypted]──> Google Server ──[encrypted]──> Recipient
│
[plaintext]
Google can read it here.
End‑to‑end encryption (PGP):
You ──[encrypted]──> Google Server ──[encrypted]──> Recipient
│
[still encrypted]
Nobody reads it. Not even Google.“전송 중 암호화”와 “실제로 사적인” 사이의 그 차이가 저를 계속 괴롭혔습니다.
So I Built GmailKrypt
GmailKrypt은 Chrome 확장 프로그램으로, PGP 암호화를 Gmail 인터페이스에 바로 적용합니다. 별도의 앱이 필요 없고, 터미널에 복사‑붙여넣기 할 일도 없습니다. 평소처럼 이메일을 작성하고 Encrypt 버튼을 클릭하면 바로 전송됩니다.
전체 기능은 OpenPGP.js 위에서 동작합니다 — 1991년 Phil Zimmermann이 PGP를 발표한 이후로 통신을 보호해 온 동일한 표준입니다. 이제는 명령줄을 건드릴 필요가 전혀 없습니다.
How It Actually Works in Practice
- 확장 프로그램을 설치합니다. 사용자를 위해 공개키와 개인키 한 쌍을 생성합니다.
- 개인키는 Chrome 로컬 스토리지에만 보관됩니다. 서버(내 서버도, Google 서버도, 다른 누구도)로 전송되지 않습니다.
- 암호화된 이메일을 보내고 싶을 때:
- Gmail에서 평소처럼 이메일을 작성합니다.
- 툴바에 있는 GmailKrypt 암호화 버튼을 클릭합니다.
- 확장 프로그램이 수신자의 공개키를 사용해 메시지 본문을 암호화합니다.
- Gmail은 마치 무작위 문자열처럼 보이는 블록을 전송합니다.
Example of the encrypted payload
-----BEGIN PGP MESSAGE-----
hQEMA7Vj8+t5rZ7aAQf+N2M7j8K2vF9xD3nE1yP4mR6sQ
8tA5bC7dF0gH3iK6lN9oR2sU5vX8yB1cE4fG7hJ0kL3mO
6pS9tW2xA5zC8dF1gI4jL7nQ0rU3vY6aD9eH2iK5lN8oR1
=x7Fp
-----END PGP MESSAGE-----수신자가 GmailKrypt을 설치했으면, 확장 프로그램이 PGP 블록을 감지하고 자동으로 복호화합니다. Thunderbird, GPG Suite, Kleopatra 등 다른 PGP 도구를 사용하더라도 동일하게 동작합니다. 이것이 오픈 표준의 장점입니다.
아키텍처 (기술 애호가를 위해)
- Zero‑knowledge design. 확장 프로그램은 개인 키를 저장하기 위해
chrome.storage.local을 사용합니다. 이 키들은 Chrome 확장 보안 모델에 의해 샌드박스됩니다. - API server (
api.gmailkrypt.com). 라이선스와 Stripe 구독을 처리합니다 — 키에 절대 접근하지 않으며, 메시지 내용도 보지 않고, 저장해서는 안 되는 어떤 것도 저장하지 않습니다. - Content‑script injection. GmailKrypt은 Gmail의 DOM에 주입되어 암호화/복호화 툴바를 추가합니다. 작성 창 이벤트를 감지하고 전송 전 메시지 본문을 가로챕니다. 모든 암호화 작업은 OpenPGP.js를 통해 클라이언트 측에서 이루어집니다.
- Key exchange. PGP는 강력하지만 과거에는 설정이 번거로웠습니다. GmailKrypt은 버튼 하나 클릭으로 공개 키를 이메일에 첨부할 수 있게 합니다. 수신자는 이를 가져와 자신의 키를 다시 보내면 설정이 완료됩니다. 첫 번째 교환은 약 30 초 정도 걸립니다.
// Simplified flow
const { privateKey, publicKey } = await openpgp.generateKey({
type: 'ecc',
curve: 'curve25519',
userIDs: [{ email: 'you@gmail.com' }]
});
// Encrypt
const encrypted = await openpgp.encrypt({
message: await openpgp.createMessage({ text: emailBody }),
encryptionKeys: recipientPublicKey,
signingKeys: privateKey // also signs it
});디지털 서명은 PGP와 함께 무료로 제공됩니다. 모든 암호화된 이메일은 서명도 포함하므로, 수신자는 실제로 당신에게서 온 것이며 전송 중에 변조되지 않았음을 검증할 수 있습니다. 인증, 무결성, 부인 방지 — 모두 한 번의 작업으로 이루어집니다.
실제로 이건 누구를 위한 건가요?
- 프리랜서와 계약자들이 이메일로 은행 정보를 포함한 청구서를 보내는 경우.
- 변호사들은 변호인‑의뢰인 특권이 필요하지만, 사무실이 Google Workspace를 사용하기 때문에 계속 Gmail을 사용합니다.
- 언론인들이 소스와 소통할 때 — 스노든이 글렌 그린월드와 PGP를 사용한 이유가 있습니다.
- 의료 전문가들은 표준 Gmail을 통해 환자 정보를 이메일로 보낼 때마다 기술적으로 HIPAA를 위반합니다.
- 개발자들은 보안에 대해 말한 것을 실천하고 싶어합니다.
- 누구든지 비밀번호, 신용카드 번호, 혹은 사회보장번호 등을 이메일로 보낸 적이 있고 “아마도 그렇게 하면 안 될 것 같다”는 작은 불편함을 느낀 사람.
Google Workspace 방 안의 코끼리
Google은 Workspace 고객을 위해 S/MIME 암호화라는 기능을 제공하지만, 기업 수준의 관리자 설정, PKI 인프라가 필요하고, 여전히 모든 Gmail 계정에서 작동하는 클라이언트‑사이드 PGP 솔루션만큼 사용자 친화적이지 않습니다.
TL;DR
- Gmail은 TLS를 사용해 전송 중에 암호화하지만, 메시지는 평문으로 저장합니다.
- 종단 간 암호화(PGP)는 Google, 해커, 그리고 데이터를 가로채는 모든 사람에게 내용을 읽을 수 없게 합니다.
- GmailKrypt는 제로‑지식 Chrome 확장 프로그램, 오픈‑소스 코드, 그리고 기존 Gmail UI에 자연스럽게 맞는 워크플로우를 통해 Gmail에 PGP를 도입합니다.
Gmail을 통해 보내는 데이터의 기밀성이 중요하다면 GmailKrypt를 사용해 보세요. 소스 코드는 GitHub에 있으며, 확장 프로그램은 Chrome 웹 스토어에서 무료로 설치할 수 있습니다. 즐거운 암호화 되세요!
Workspace Enterprise 고객을 위한
표준 Workspace보다 비용이 크게 더 많이 들며, IT admin이 인증서를 관리해야 하고, 두 조직 모두 S/MIME을 올바르게 설정한 사용자 간에만 작동합니다.
For the other 1.8 billion Gmail users?
Nothing.
그것은 실수가 아닙니다. 구글의 비즈니스 모델은 근본적으로 종단 간 암호화와 충돌합니다. 구글이 여러분의 이메일을 읽을 수 없으면 Smart Compose를 구동할 수 없고, 스팸을 효과적으로 필터링할 수 없으며, 광고 생태계를 움직이는 프로필을 만들 수도 없습니다. 저는 이것이 악의적이라고 말하는 것이 아니라, 무료 제품의 현실일 뿐이라고 말하는 겁니다.
GmailKrypt는 모든 것을 우회합니다
It works with free Gmail, Google Workspace, any plan. You’re adding encryption on top of Gmail, not asking Google to provide it.
무료 티어, 프로 티어, 허튼소리 없음
- Free tier – 하루에 5회 암호화 (대부분 사용자의 요구를 충족).
- Pro tier – $4.99 / 월 무제한 (변호사, 기자, 보안 팀 등에게 이상적).
가격 책정에 대해 오래 고민했습니다. 학생이나 활동가가 비용을 지불하지 않고도 사용할 수 있을 만큼 접근성을 높이면서도, 제가 지속적으로 유지 관리할 수 있을 만큼 지속 가능하도록 하고 싶었습니다. 하루에 5번의 무료 암호화가 적절한 균형이라고 생각했습니다.
사용해보고, 깨보고, 뭐가 문제인지 알려줘
- Chrome 웹 스토어에서 GmailKrypt를 다운로드하거나 gmailkrypt.com 랜딩 페이지를 방문하세요.
- 설치 전에 소스 코드를 읽는 타입이라면(그렇게 해야 합니다), 이 확장 프로그램은 모든 암호화 작업을 완전히 클라이언트‑사이드에서 수행합니다. 네트워크 호출은 프로 기능을 위한 라이선스 API에만 이루어집니다.
제가 진심으로 궁금한 점은 이 커뮤니티의 의견입니다:
- 2026년에도 PGP 이메일 암호화가 여전히 유효할까요?
- 실제로 사용하게 만들 UX 개선점이 있을까요?
- 아키텍처에서 제가 눈치 못 챈 명백한 문제가 있을까요?
댓글을 남겨 주세요. 모두 읽어봅니다.