2025년 8월 08일·6분
레너드 애들먼과 RSA: 인터넷이 신뢰를 배우게 된 방법
레너드 애들먼은 RSA의 공동 창시자 중 한 명으로 HTTPS, 온라인 뱅킹, 서명된 업데이트를 가능하게 한 공개키 시스템 발전에 기여했습니다. RSA가 어떻게 작동하는지와 왜 중요한지 알아보세요.
레너드 애들먼은 RSA의 공동 창시자 중 한 명으로 HTTPS, 온라인 뱅킹, 서명된 업데이트를 가능하게 한 공개키 시스템 발전에 기여했습니다. RSA가 어떻게 작동하는지와 왜 중요한지 알아보세요.
사람들이 웹사이트나 온라인 서비스를 “신뢰한다”고 말할 때, 보통 세 가지 실용적 의미를 갖습니다:
RSA는 이런 약속들을 인터넷 규모로 가능하게 만든 덕분에 유명해졌습니다.
이름을 들어본 적이 없더라도 RSA의 영향을 이미 느꼈을 수 있습니다. RSA는 다음과 밀접하게 연결됩니다:
공통점은 매번 모든 서버나 소프트웨어 제공자와 미리 비밀을 합의하지 않고도 신뢰를 할 수 있게 해준다는 점입니다.
이 글은 설명을 단순하게 유지합니다: 복잡한 수학 없이, 컴퓨터 과학 배경이 없어도 이해할 수 있게 “왜 작동하는가” 관점에 초점을 맞춥니다.
RSA는 한 개의 공유 비밀 대신 공개키(공개해도 되는 키)와 개인키(비밀로 지켜야 할 키)를 사용하는 접근을 대중화했습니다. 이 분리는 전혀 만나본 적 없는 사람이나 시스템 간에도 기밀성과 신원 증명을 가능하게 만듭니다.
레너드 애들먼은 RSA의 ‘A’로, 론 리베스트와 아디 샤미르와 함께했습니다. 리베스트와 샤미르는 핵심 구성으로 자주 언급되지만, 애들먼의 기여는 시스템을 단순히 기발하게 만드는 것을 넘어서—사람들이 분석하고 테스트하며 신뢰할 수 있는 실용적 알고리즘으로 다듬는 데 필수적이었습니다.
애들먼의 큰 역할 중 하나는 아이디어를 압박 검증하는 것이었습니다. 암호학에서 어떤 방식이 그럴듯하다고 가치있는 것이 아니라, 치밀한 공격과 검토를 견뎌낼 때 가치가 있습니다. 애들먼은 가정들을 검증하고 발표 방식을 다듬었으며, 왜 RSA가 깨기 어려운지에 대한 초기 프레임을 강화하는 데 기여했습니다.
동시에 그는 “이게 작동할지 모른다”는 수준에서 “다른 연구자들이 평가할 수 있는 암호체계”로 바꾸는 데 도움을 주었습니다. 설계를 충분히 이해하기 쉽게 만드는 그 명료함이 채택에 결정적이었습니다.
RSA 이전에는 보통 양쪽이 이미 같은 비밀키를 공유하고 있다는 전제 하에 안전한 통신이 이뤄졌습니다. 그 방법은 닫힌 그룹에서는 통하지만, 처음 만나는 사람들(예: 쇼핑객과 웹사이트)이 안전하게 통신해야 하는 경우에는 확장성이 떨어집니다.
RSA는 실용적인 공개키 암호체계를 대중화해서 한 키는 다른 사람들에게 공개하고, 다른 키는 비밀로 유지하는 방식으로 이야기를 바꿨습니다.
RSA의 영향은 단일 알고리즘을 넘어섭니다. RSA는 두 가지 인터넷 필수 요소를 대규모로 실현 가능하게 만들었습니다:
이 아이디어들이 HTTPS, 온라인 뱅킹, 서명된 소프트웨어 업데이트가 예외가 아닌 일상적 기대가 되는 기반을 마련했습니다.
RSA 이전에는 안전한 통신이 주로 공유 비밀 암호화를 의미했습니다: 양쪽이 미리 같은 비밀키를 가지고 있어야 했습니다. 소규모 그룹에서는 통하지만, 수백만 사용자가 쓰는 공용 서비스에는 확장되지 않습니다.
각 고객이 은행과 통신하기 위해 고유한 비밀키를 필요로 한다면, 은행은 엄청난 수의 비밀을 생성, 전달, 저장, 교체, 보호해야 합니다. 가장 어려운 것은 수학이 아니라 조정입니다.
비밀키를 안전하게 어떻게 전달하나요? 우편은 느리고 위험합니다. 전화로 알려주면 도청이나 사회공학에 노출될 수 있습니다. 인터넷으로 전송하면 그 채널을 보호하려는 목적이 무색해집니다.
당신과 온라인 상점처럼 처음 만나는 두 사람이 안전하게 결제하고 싶다고 상상해 보세요. 공유 비밀 암호화라면 사전에 둘 다 알고 있는 비밀키가 필요하지만, 그런 게 없습니다.
RSA의 돌파구는 비밀을 미리 공유하지 않아도 안전한 통신을 가능하게 한 것입니다. 대신 한 키(공개키)를 누구나 사용하도록 공개하고, 다른 키(개인키)는 오직 소유자만 비밀로 유지합니다.
암호화를 할 수 있다 해도 누구에게 암호화하는지 알아야 합니다. 그렇지 않으면 공격자가 은행이나 상점을 사칭해 자신들의 키를 쓰게 만들고 모든 통신을 읽거나 바꿀 수 있습니다.
그래서 안전한 인터넷 통신은 두 가지 속성을 필요로 합니다:
RSA는 이 둘을 가능하게 하여 대규모 인터넷 신뢰의 기반을 놓았습니다.
공개키 암호화는 단순한 아이디어지만 큰 결과를 낳습니다: 사전에 비밀을 합의하지 않아도 누군가를 위해 무언가를 잠글 수 있습니다. 이것이 RSA가 실용화하는 핵심 변화입니다.
공개키를 당신이 기꺼이 나눠줄 수 있는 자물쇠로 생각하세요. 다른 사람들이 그것으로 당신에게 보낼 메시지를 보호할 수 있고(암호화), 서명 시스템에서는 당신이 보냈다는 것을 확인할 수 있습니다.
개인키는 혼자만 가지고 있어야 하는 열쇠입니다. 공개키로 잠근 것을 여는 열쇠이고, 또한 오직 당신만 만들 수 있는 서명을 생성하는 데 사용됩니다.
공개키와 개인키는 키 쌍을 이루며 수학적으로 연결되어 있지만 서로 교환 가능하지 않습니다. 공개키를 아는 것이 개인키를 실용적으로 유도하지 못하는 것이 안전의 핵심입니다.
암호화는 기밀성에 관한 것입니다. 누군가가 당신의 공개키로 메시지를 암호화하면, 오직 당신의 개인키만 그것을 복호화할 수 있습니다.
디지털 서명은 신뢰와 무결성에 관한 것입니다. 당신이 개인키로 무언가에 서명하면, 공개키를 가진 누구나 다음 두 가지를 확인할 수 있습니다:
보안은 마법이 아니라 풀기 어려운 수학 문제에 의존합니다. 한 방향으로는 쉽게 계산되지만 역으로는 현재 컴퓨터로 풀기 매우 어려운 문제들이 있어서 공개키를 공유해도 개인키는 안전하게 유지됩니다.
RSA는 단순한 비대칭성 위에 세워졌습니다: 어떤 전진 연산은 쉽지만, 특별한 비밀이 없으면 그 연산을 역으로 돌리기는 극히 어렵습니다.
RSA를 수학적 자물쇠로 생각하세요. 누구나 공개키로 메시지를 잠글 수 있지만, 오직 개인키를 가진 사람만 잠금을 열 수 있습니다.
이것이 가능한 이유는 두 키 사이의 신중히 선택된 관계입니다. 키는 함께 생성되고 관련되어 있지만, 공개키만으로 개인키를 현실적으로 유도할 수 없습니다.
고수준에서 RSA는 큰 소수들을 곱하는 것은 쉽고, 그 결과를 다시 어떤 소수들이 곱해져 만들어졌는지를 찾는 것은(팩토링) 매우 어렵다는 사실에 의존합니다.
작은 수에서는 팩토링이 빠르지만 실제 RSA 키 크기(수천 비트)에서는 알려진 최선의 방법들도 비현실적인 시간과 연산을 필요로 합니다. 이 역으로 풀기 어려운 성질이 공격자가 개인키를 재구성하지 못하게 합니다.
RSA는 보통 큰 파일이나 긴 메시지를 직접 암호화하는 데 쓰이지 않습니다. 대신 무작위로 생성한 세션 키 같은 작은 비밀을 보호하는 데 사용되고, 그 세션 키가 실제 데이터 암호화(대칭 암호화)를 빠르게 처리합니다.
RSA는 암호화와 디지털 서명이라는 두 가지 관련 있지만 다른 작업을 수행할 수 있어 유명합니다. 이 둘을 혼동하는 것이 흔한 오해의 원인입니다.
암호화는 주로 기밀성을, 디지털 서명은 무결성 + 진위성을 목표로 합니다.
RSA 암호화에서는 누군가가 당신의 공개키로 무언가를 잠급니다. 오직 당신의 개인키만 그것을 열 수 있습니다.
실무에서는 RSA가 보통 세션 키 같은 작은 비밀을 보호하는 데 사용되고, 그 세션 키가 대용량 데이터를 효율적으로 암호화합니다.
RSA 서명에서는 방향이 바뀝니다: 발신자가 개인키로 서명을 만들고, 공개키를 가진 누구나 다음을 검증할 수 있습니다:
디지털 서명은 일상적 ‘승인’ 순간에 등장합니다:
암호화는 비밀을 지키고, 서명은 신뢰를 지킵니다.
브라우저의 자물쇠는 한 가지 아이디어를 축약한 것입니다: 이 웹사이트와의 연결은 암호화되고(대부분) 인증되었다는 뜻입니다. 이는 공용 Wi‑Fi 같은 네트워크 상의 다른 사람이 브라우저와 사이트 간 주고받는 내용을 읽거나 조용히 변경하지 못한다는 의미입니다.
그러나 자물쇠가 사이트가 모든 면에서 "안전하다"는 뜻은 아닙니다. 자물쇠는 상점이 정직한지, 다운로드가 악성인지, 당신이 정확한 도메인을 입력했는지 알려주지 못합니다. 또한 사이트가 서버에서 도달한 이후 데이터를 어떻게 처리하는지도 보장하지 않습니다.
HTTPS 사이트를 방문하면 브라우저와 서버는 TLS 핸드셰이크라는 설정 대화를 수행합니다:
과거에는 RSA가 세션 키 교환에 자주 사용되었는데(브라우저가 서버의 RSA 공개키로 비밀을 암호화), 현대 TLS 구성에서는 RSA가 주로 **인증(서명)**에 쓰이고 실제 키 합의는 다른 방법으로 이루어지는 경우가 많습니다.
RSA는 설정 중 작은 데이터를 보호하는 데는 훌륭하지만 대량 데이터 암호화에는 느립니다. 그래서 핸드셰이크 이후 HTTPS는 실제 페이지 로드, 로그인, 은행 거래 등에는 빠른 대칭 암호 알고리즘으로 전환합니다.
온라인 뱅킹의 약속은 간단합니다: 로그인하고 잔액을 확인하며 돈을 옮기는 동안 누군가 당신의 자격 증명을 알거나 제출한 내용을 조용히 변경하지 못해야 합니다.
뱅킹 세션은 동시에 세 가지를 보호해야 합니다:
HTTPS가 없으면 동일한 Wi‑Fi에 있는 사람, 손상된 라우터, 악의적 네트워크 운영자는 트래픽을 염탐하거나 변조할 수 있습니다.
HTTPS(TLS)를 통해 브라우저와 은행 서버 간 연결은 암호화되고 무결성 검사가 됩니다. 실무적으로 이는:
RSA의 역사적 역할은 불신한 네트워크상에서 처음 접촉할 때 보안을 수립하는 문제를 해결한 점에서 결정적이었습니다.
잘못된 대상을 암호화하면 소용이 없습니다. 온라인 뱅킹은 브라우저가 진짜 은행과 통신하고 있음을 확인할 수 있어야만 작동합니다. 그렇지 않으면 중간자 공격이나 사칭 사이트에 속을 수 있습니다.
은행은 여전히 다중요소 인증(MFA), 기기 검사, 사기 모니터링을 도입합니다. 이는 자격 증명이 도난당했을 때 피해를 줄이지만 HTTPS를 대신하지는 않습니다. 이러한 수단들은 이미 개인 정보가 보호되고 변조 저항성이 확보된 연결 위에 얹어질 때 가장 효과적입니다.
소프트웨어 업데이트는 기술적 문제이기 이전에 신뢰의 문제입니다. 앱 자체가 안전하게 작성되었더라도 공격자는 전달 단계(미러 서버, 네트워크, 다운로드 페이지)를 노려 정품 설치 파일을 바꿀 수 있습니다. 다운로드한 것을 신뢰할 수 있는 방법이 없다면 “업데이트 있음”은 쉬운 침투 경로가 됩니다.
업데이트가 단순히 다운로드 링크로 제공될 때, 미러가 침해되거나 네트워크가 가로채지거나 사용자가 유사 사이트로 유도되면 공격자는 동일한 이름의 다른 파일을 제공할 수 있습니다. 사용자는 정상적으로 설치하고, 피해는 "조용하게" 일어납니다: 악성코드가 번들되거나 백도어가 추가되거나 보안 설정이 약화되는 식입니다.
코드 서명은 공개키 암호화(RSA 포함)를 사용해 설치 파일이나 업데이트 패키지에 디지털 서명을 붙입니다.
발행자는 개인키로 소프트웨어에 서명하고, 당신의 기기(또는 운영체제)는 발행자의 공개키(종종 인증서 체인을 통해 전달됨)로 그 서명을 검증합니다. 단 한 바이트라도 변경되면 검증이 실패합니다. 이는 신뢰를 “어디서 다운로드했나”에서 “누가 만들었고 무결한가”로 옮겨 줍니다.
현대의 앱 전달 파이프라인에서는 설치 파일을 넘어서 API 호출, 빌드 산출물, 배포 롤아웃까지 같은 아이디어가 확장됩니다. 예를 들어 Koder.ai(채팅 인터페이스로 웹/백엔드/모바일 앱을 배포하는 분위기 코딩 플랫폼) 같은 플랫폼도 HTTPS/TLS로 전송을 보호하고, 커스텀 도메인에 대한 인증서 처리를 신중히 하며, 변경 시 롤백 가능한 스냅샷 워크플로를 통해 리스크를 줄이는 등 같은 기반에 의존합니다.
서명된 업데이트는 눈에 띄지 않는 변조 기회를 줄입니다. 문제가 있을 때 사용자에게 명확한 경고를 주고 자동 업데이트 시스템은 변경된 파일을 실행 전에 거부할 수 있습니다. 소프트웨어 자체에 버그가 없다는 보장은 아니지만, 사칭과 공급망 변조에 대한 강력한 방어책입니다.
더 깊이 알고 싶다면 서명, 인증서, 검증이 어떻게 맞물리는지 /blog/code-signing-basics를 참조하세요.
RSA가 공개키를 준다면 자연스러운 질문이 생깁니다: 이 공개키는 누구의 것인가?
인증서가 인터넷의 답입니다. 인증서는 공개키를 웹사이트 이름(example.com), 조직, 소프트웨어 배포자 같은 신원에 연결하는 작은 서명된 데이터 파일입니다. 키의 신분증 카드처럼 “이 키는 이 이름에 속한다”를 말하며 소유자, 공개키 자체, 유효 기간 같은 세부를 포함합니다.
인증서는 다른 누군가의 서명이 있기 때문에 중요합니다. 그 “누군가”가 보통 **인증기관(CA)**입니다.
CA는 특정 증명을 확인한 뒤(도메인 제어에서 기업 확인까지 범위가 다양함) 인증서에 서명합니다. 브라우저나 운영체제는 신뢰된 CA 목록을 내장하고 있습니다. HTTPS로 사이트를 방문할 때 장치는 그 목록을 사용해 인증서의 주장 수용 여부를 결정합니다.
이 시스템이 완벽한 것은 아닙니다: CA가 실수하거나 공격자에게 속을 수 있습니다. 그러나 글로벌 규모에서 실용적 신뢰 사슬을 만들어 냈습니다.
인증서는 의도적으로 만료됩니다. 짧은 수명은 키가 도난당했을 때 피해를 제한하고 정기적 관리를 장려합니다.
인증서는 또한 만료 전에 폐기(리보크) 될 수 있습니다. 예: 개인키가 유출되었거나 인증서가 잘못 발급된 경우, “이 인증서를 더 이상 믿지 마라”는 신호를 보내는 방법입니다. 장치들이 폐기 상태를 확인하는 방식은 다양하고 신뢰성도 다르기 때문에 키 위생은 여전히 중요합니다.
개인키는 비공개로 유지하세요: 안전한 키 저장소에 보관하고 접근을 제한하며 불필요하게 시스템 간 복사하지 마세요.
사고 발생 시나 계획된 업그레이드, 정책 요구에 따라 키를 교체하고 만료일을 추적하여 갱신이 막판 일이 되지 않게 하세요.
RSA는 근간이 되는 아이디어이지만 만능 방패는 아닙니다. 현실 세계의 많은 침해는 누군가가 “RSA를 깼다”가 아니라 RSA 주위 시스템이 실패해서 일어납니다.
자주 반복되는 패턴 몇 가지:
RSA의 안전성은 충분히 크고 진정으로 예측 불가능한 키 생성에 달려 있습니다. 좋은 난수가 필수입니다: 만약 키 생성이 약한 난수원을 사용하면 공격자가 가능한 키를 재현하거나 축소할 수 있습니다. 또한 키 길이는 중요합니다. 계산 능력과 수학 기법의 발전은 작은 키의 안전마진을 점차 줄입니다.
RSA 연산은 현대 대칭 암호보다 무겁습니다. 그래서 많은 프로토콜은 RSA를 선택적으로 사용합니다—보통 인증이나 임시 비밀 교환에만 사용하고 대량 데이터 암호화는 대칭 알고리즘으로 전환합니다.
보안은 다층 방어가 최선입니다: 개인키를 하드웨어에 보관하고, 인증서 발급을 모니터링하며, 시스템을 패치하고, 피싱 저항 인증을 사용하며, 안전한 키 교체 설계를 하세요. RSA는 사슬의 하나일 뿐, 전체는 아닙니다.
RSA는 인터넷에서 가장 널리 지원되는 암호 도구 중 하나입니다. 어떤 서비스가 이제 RSA를 “선호”하지 않더라도 호환성을 위해 RSA를 유지하는 경우가 많습니다: 오래된 장비, 장기간 운영되는 엔터프라이즈 시스템, 오랜 기간 구축된 인증서 인프라 등.
암호학이 진화하는 이유는 다른 보안 기술과 같습니다:
TLS와 현대 애플리케이션에서는 다음 대안들을 자주 볼 수 있습니다:
요약하면: RSA는 암호화와 서명 둘 다 할 수 있지만, 최신 시스템은 보통 서명에 최적화된 방법과 키 교환에 최적화된 방법을 분리해 사용합니다.
아니요. RSA는 여전히 광범위하게 지원되고 많은 상황에서 유효한 선택입니다. 특히 호환성이 중요하거나 기존 인증서·키 관리 관행이 RSA 중심으로 구축된 환경에서는 그렇습니다. "최선의" 옵션은 장치 지원, 성능 요구, 규정 준수, 키 저장 및 교체 방식 같은 요소에 따라 달라집니다.
다음 단계로 이러한 선택이 실제 HTTPS 연결에서 어떻게 드러나는지 보려면 /blog/ssl-tls-explained를 참고하세요.
RSA는 공개키 암호화를 가능하게 하여 인터넷 규모의 신뢰를 실용적으로 만든 기술입니다. 이로써 다음을 지원할 수 있었습니다:
이 빌딩블록들은 HTTPS, 온라인 뱅킹, 서명된 소프트웨어 업데이트의 핵심입니다.
레너드 애들먼은 RSA를 단순한 기발한 아이디어에서 다른 사람들이 분석하고 신뢰할 수 있는 암호체계로 만드는 역할을 했습니다. 실무적으로는 가정들을 검증하고, 발표 방식을 다듬으며, 현실적인 공격 모델에서 RSA가 깨지기 어려운 이유를 설득력 있게 정리하는 데 기여했습니다.
공개키는 공유해도 되는 정보입니다. 다른 사람이 당신에게 보낼 데이터를 보호하거나(암호화) 당신이 만든 서명의 진위를 검증하는 데 씁니다.
개인키는 비밀로 지켜야 합니다. 공개키로 암호화된 내용을 복호화하거나(암호화 용도일 때) 당신만 만들 수 있는 서명을 생성하는 데 사용됩니다.
개인키가 유출되면 사용 방식에 따라 공격자가 당신을 사칭하거나 보호된 비밀을 복호화할 수 있습니다.
RSA의 보안은 고수준에서 단방향 수학 문제에 의존합니다: 큰 소수들을 곱하는 것은 쉽지만, 그 결과인 큰 수를 다시 소수들로 분해(팩토링) 하는 것은 현실적인 크기에서 매우 어렵습니다.
공개키와 개인키는 수학적으로 연결되어 있지만, 공개키만으로 개인키를 실용적으로 찾아내지 못하도록 설계되어 있습니다.
두 가지 다른 신뢰 목표를 해결합니다:
간단한 규칙: 암호화는 비밀을 지키고, 서명은 누가 보냈는지와 변경 여부를 증명합니다.
단순화된 HTTPS/TLS 흐름에서:
RSA는 **인증(서명)**에 쓰일 수 있고, 역사적으로는 세션 비밀을 보호하는 데 직접 사용되기도 했습니다.
아니요. 자물쇠는 주로 연결이 암호화되어 있고 보통 인증되었다는 의미일 뿐입니다.
자물쇠는 다음을 보장하지 않습니다:
HTTPS는 필수적인 전송 보호층이지 전체 신뢰 판정이 아닙니다.
인증서는 공개키를 신원(예: 도메인 이름)과 연결해 줍니다. 브라우저는 인증서에 서명한 **인증기관(CA)**을 신뢰 목록으로 갖고 있어서, 방문하는 사이트의 인증서를 이 목록과 대조해 신뢰 여부를 결정합니다.
서비스를 배포할 때는:
서명된 업데이트는 기기가 두 가지를 검증하게 합니다:
이는 미러 서버가 손상되거나 네트워크가 가로채지는 경우에 설치 파일을 교체당하는 "패키지 교체" 공격을 막아 줍니다. 자세한 내용은 /blog/code-signing-basics를 참고하세요.
실무에서 RSA 관련 사고는 대개 운영 문제에서 옵니다, 수학적 취약점 때문이 아닙니다. 자주 보이는 실수들:
실용적 조치: 개인키는 하드웨어 기반 저장소에 보관하고, 만료를 추적하며, 키 교체와 모니터링 절차를 두세요.