*이 글은 이전에 게시된 기사의 영문 버전입니다.

안녕하세요, Toss Tech 독자 여러분. Toss Payments의 기술 총괄(Head of Technology) 하태호입니다.

레거시 개편 시리즈(Legacy Overhaul Series)를 시작한 이후, 항상 따라다니는 질문이 하나 있었습니다.

"20년 된 레거시 시스템을 개편하면서 가장 큰 도전 과제는 무엇이었나요?"

대부분의 사람들은 어떤 깊이 있는 기술적 문제에 대한 이야기를 기대합니다.

네, 실제로 그 과정에서 수많은 힘든 순간들이 있었습니다. 하지만 엔지니어들은 모든 도전 과제에 진정한 깊이와 헌신을 보여주었고, 그것이 불가능을 가능하게 만들었습니다.

하지만 진짜 도전 과제는 다른 것이었습니다. 수만 명의 가맹점(merchants)을 모든 단계에서 함께 유지하면서 보안 표준을 높이는 것이었습니다.

오늘 저는 보안 프로토콜을 업데이트해 온 수년간의 여정과, 그 여정이 궁극적으로 우리를 어디로 이끌었는지, 즉 양자 내성 암호(Post-Quantum Cryptography)의 도입에 대해 공유하고자 합니다.

오래된 습관 깨기

미션 크리티컬(mission-critical)한 결제 서비스를 오랫동안 운영하다 보면, 팀 전체에 암묵적인 규칙이 자리 잡기 마련입니다.

"고장 나지 않았다면 고치지 마라. 다운타임(downtime)을 감당할 여유가 없다."

이는 안정성을 보장하기 위해 구축된 보수적인 원칙입니다. 하지만 모든 것에 동일하게 적용되지는 않습니다. 작고 되돌릴 수 있는 변경 사항은 항상 구현됩니다. 하지만 변경 사항이 광범위하고 되돌리기 어려울 때는 다른 본능이 작동합니다. "지금 정말 이걸 건드려야 할까?"

사실, 보안 프로토콜은 그러한 본능이 가장 강력하게 작용하는 영역입니다. TLS 버전을 업그레이드하고, 취약한 암호 제품군(cipher suites)을 제거하며, 새로운 암호화 방식(encryption schemes)을 도입하는 것은 분명히 옳은 결정입니다. 하지만 그중 무엇이라도 건드리면 수만 명의 가맹점이 직접적인 영향을 받습니다. 그리고 무언가 잘못되면 문제 해결(troubleshooting)이 결코 간단하지 않습니다. 이것이 바로 주저함이 생기는 정확한 이유입니다.

우리가 직면한 상황이 어떤 것인지 감을 잡으실 수 있도록 한 가지 예를 들어보겠습니다. Toss Payments는 수십 년 동안 우리의 PG (Payment Gateway) 시스템과 연동해 온 가맹점들과 여전히 협력하고 있습니다. 연동된 지 오래되었을수록, 해당 가맹점의 서버 스택 (Server Stack)이 구식 기술로 구동되고 있을 가능성이 높습니다. 웹 브라우저는 스스로 조용히 업데이트되며 최신 보안 표준을 유지하지만, 우리의 API를 호출하는 클라이언트들은 대부분 서버 사이드 (Server-side) 프로그램입니다. 노후화된 인프라에서 실행되는 소프트웨어에 현대적인 보안 정책을 적용하는 것은 생각보다 훨씬 더 어려운 일입니다.

또한, 이 사실을 알리는 것 자체가 또 다른 도전 과제입니다. 보안은 대부분의 개발자들에게 강점인 분야가 아니며, 우리가 잘 작성된 기술 문서를 제공하더라도 가맹점들이 요구 사항을 완전히 이해하고 실행에 옮기기까지는 종종 오랜 시간이 걸리곤 합니다. 우리의 가맹점 중 상당수는 전담 개발 팀 없이 운영되는 1인 소유의 소규모 사업체이며, 기술적 전문 용어로 가득 찬 보안 업그레이드 요청에 대응해 달라고 요청하는 것은 진정으로 큰 부담이 됩니다.

PG 시스템은 SDK 및 API 연동을 통해 수만 개의 가맹점과 연결되어 있습니다. 모든 접점, 모든 API 호출, 모든 결제창, 모든 서버 통신은 하나의 보안 경계 (Security Boundary)를 나타냅니다. 보안 스택이 아무리 고도화되어 있더라도, 단 몇 명의 가맹점이라도 여전히 레거시 (Legacy) 환경에서 구동되고 있다면, 그 연결은 절반만 보호되고 있는 셈입니다.

이것이 바로 보안 프로토콜을 개선하는 것이 Toss Payments 혼자만의 힘으로는 결코 해결할 수 없는 문제였던 이유입니다. 이는 우리와 가맹점 모두에게 부담이며, 그렇기에 자꾸만 뒤로 미루기 너무나 쉽습니다.

그럼에도 불구하고 우리가 변화해야 했던 이유

하지만 보안은 "지금은 괜찮으니까 괜찮다"라는 논리가 통하지 않는 유일한 분야 중 하나입니다. 그리고 지금 우리는, 우리가 당연하게 여겨왔던 암호화의 근간 자체가 균열되기 시작하는 지점에 서 있습니다.

그리고 바로 이 지점에서 양자 컴퓨터 (Quantum Computer)가 등장합니다.

아마 여러분도 뉴스에서 이 용어를 접해본 적이 있을 것입니다. 양자 컴퓨터 (Quantum Computer)는 우리가 오늘날 사용하는 컴퓨터와 근본적으로 다른 계산 논리 (Computational Logic)로 작동합니다. 일반적인 컴퓨터는 0과 1의 조합을 한 번에 하나씩 순차적으로 처리합니다. 반면, 양자 컴퓨터는 양자 역학 (Quantum Mechanics)의 원리를 사용하여 동시에 수많은 가능성을 탐색합니다. 기존 컴퓨터가 해결하는 데 수만 년이 걸릴 문제들이 양자 컴퓨터에 의해 단 몇 시간 만에 풀릴 것으로 예상됩니다.

그러한 종류의 계산 능력은 우리가 오늘날 의존하고 있는 암호화 시스템 (Encryption Systems)에 근본적인 위협을 가합니다.

오늘날의 암호화가 깨질 수 있는 이유

은행 앱, 결제 창, 그리고 HTTPS에서 우리가 매일 사용하는 암호화는 대부분 RSA 및 ECDSA와 같은 공개 키 알고리즘 (Public-key Algorithms)을 기반으로 작동합니다. 이 알고리즘들이 안전하다고 간주되는 이유는 사실 매우 간단합니다. 이들은 한 가지 핵심적인 가정에 의존합니다. 즉, 매우 큰 수를 소인수 분해 (Factoring)하거나, 타원 곡선 (Elliptic Curve) 상의 특정 값을 찾기 위해 역산하는 것이 기존 컴퓨터로는 계산적으로 불가능 (Computationally Infeasible)하다는 것입니다. 수학적인 답은 존재하지만, 현대의 컴퓨터가 그 답을 찾는 데는 상상할 수 없을 정도로 긴 시간이 걸립니다. 그래서 우리는 이를 "실질적으로 안전함"으로 취급해 왔습니다.

하지만 문제는, 양자 컴퓨터에서 바로 이러한 문제들을 해결할 수 있는 알고리즘이 존재한다는 사실이 이미 수학적으로 증명되었다는 점입니다. 충분히 강력한 양자 컴퓨터가 구축되는 순간, 한때 해독하는 데 천문학적인 시간이 필요했던 자물쇠였던 RSA와 ECDSA는 손쉽게 열 수 있는 자물쇠가 되어버립니다. 이는 단순히 기술적 지형의 변화가 아닙니다. 지난 수십 년 동안 구축된 디지털 보안의 근간 자체를 흔드는 사건입니다.

Q-Day와 "지금 수집하고, 나중에 해독하라 (Harvest Now, Decrypt Later)"

IBM, Google, IonQ 및 기타 주요 기업들은 2030년을 주요 목표로 삼고 실용적인 양자 컴퓨터를 만들기 위해 활발히 노력하고 있습니다. 보안 전문가들은 오늘날의 암호화가 무너지는 순간을 "Q-Day"라고 부릅니다.

멀게 느껴질 수도 있지만, 위협은 이미 시작되었습니다. 실제로 가장 잘 알려진 공격 시나리오는 "지금 수집하고, 나중에 해독하라 (Harvest Now, Decrypt Later)"라고 불립니다.

이 공격은 다음과 같이 작동합니다. 누군가가 오늘 암호화된 통신 내용을 조용히 가로채어 저장해 두었다가, 양자 컴퓨터를 사용할 수 있게 되면 모든 데이터를 일괄적으로 해독하는 방식입니다. 결제 데이터는 가치가 수년간 유지되기 때문에 주요 표적이 됩니다. 2026년 현재 전송 중인 데이터가 2033년에는 무방비로 노출된 채 놓여 있을 수 있습니다.

오늘 안전하다고 해서 내일도 반드시 안전한 것은 아닙니다. 잠재적인 취약점을 오늘 해결하지 않고 방치하는 것은 내일의 실질적인 위협을 무시하는 것과 같습니다.

4년간의 보안 프로토콜 고도화

Toss Payments는 2022년부터 단계별로 보안 프로토콜을 업그레이드해 왔습니다. 모든 것을 한꺼번에 개편하는 대신, 4년에 걸쳐 업그레이드를 구현하며 단계적으로 접근했습니다.

• 2022년: PG 업계 최초 HTTP/3 구현
• 2022년–2025년: 취약한 TLS 암호 제품군 (Cipher Suites) 제거
• 2022년–2025년: TLS 1.3 완전 도입
• 2026년 4월: 양자 내성 암호 (Post-Quantum Cryptography, PQC) 구현

단순한 기술적 업그레이드 목록처럼 보일 수 있지만, 결코 그렇지 않습니다. 이 네 가지 항목 뒤에는 끊임없는 긴장감이 있었습니다. 가맹점이 적응하는 데 필요한 시간을 존중하면서도, 보안에 있어서는 절대 타협하지 않는 것이었습니다. 모든 단계는 새로운 보안 기술을 빠르게 도입하려는 추진력과, 작은 실수라도 발생할 경우 가맹점의 결제 중단으로 이어질 수 있다는 책임감 사이에서 줄타기를 하는 과정이었습니다.

각 단계가 무엇을 의미하는지, 그리고 왜 이러한 순서로 접근했는지 살펴보겠습니다.

HTTP/3 구현 (2022년): 가장 쉽고 명확한 단계부터 시작

여정은 HTTP/3 도입과 함께 시작되었습니다. HTTP/3는 웹에서 데이터를 전송하기 위한 최신 프로토콜입니다. 네트워크 상태가 좋지 않은 환경에서도 더 빠르고 안정적으로 작동하도록 설계되었습니다. 더 중요한 점은, HTTP/3는 TLS 1.3 사용을 의무화하도록 설계되었다는 것입니다. 즉, HTTP/3를 활성화하는 것만으로도 최신 보안 프로토콜이 자동으로 적용된다는 의미입니다.

2022년, Toss Payments는 PG 업계 최초로 HTTP/3를 도입했습니다. 이를 통해 더 빠른 결제창 응답 시간을 제공함과 동시에 보안성도 높였습니다. 가맹점 입장에서 가장 좋았던 점은 별도의 추가 작업이 필요 없었다는 것입니다. 구매자가 사용하는 웹 브라우저(Chrome, Safari, Edge 등)가 자동으로 최신 프로토콜을 선택하기 때문에, 가맹점은 아무것도 할 필요가 없었습니다. 업그레이드는 기존의 Toss Payments 연동을 통해 자동으로 적용되었습니다.

HTTP/3는 가맹점에게 아무것도 요구하지 않았기에, 이 여정을 위한 올바른 첫걸음이 되었습니다. 이는 이후에 이어질 더 까다로운 작업을 위한 토대를 마련했습니다.

취약한 TLS 암호 스위트(Cipher Suites) 제거 (2022–2025): 가장 길었던 3년

이 두 번째 단계는 네 단계 중 가장 길고 어려웠습니다. 왜 그렇게 복잡했는지 이해하기 위해 암호 스위트(Cipher Suite)가 무엇인지 살펴보겠습니다.

암호 스위트란 무엇일까요? 암호 스위트는 서버와 클라이언트가 암호화된 연결을 통해 통신할 때 암호화 방식을 결정하기 위해 사용되는 암호 알고리즘의 집합입니다. 여러 종류의 서로 다른 자물쇠를 준비해 두고, 양측이 모두 가지고 있는 것 중 가장 강력한 것을 선택하는 과정이라고 생각하면 됩니다. 하지만 시간이 흐르면서 이러한 자물쇠 중 일부에서 결함이 발견될 수 있으며, 이는 한때 안전하다고 여겨졌던 알고리즘이 전문가들에 의해 뚫릴 수 있음을 의미합니다. 이런 일은 정기적으로 발생하며, 이 시점에 해당 암호 스위트는 취약한 조합으로 분류되어 반드시 제거되어야 합니다.

하지만 진짜 문제는 가맹점의 서버에 있습니다. 일부 가맹점은 최신 암호 스위트를 지원하지 않는 오래된 레거시(Legacy) 서버를 운영하고 있으며, 공교롭게도

우리가 찾아낸 해답은 단계적 제거(Phased removal)와 개별 지원이었습니다. 우리는 먼저 각 가맹점이 어떤 암호 스위트(Cipher suite)를 사용하고 있는지 조사했고, 취약한 조합을 사용하는 가맹점에는 제거하기 6개월에서 1년 전부터 미리 통지하기 시작했습니다. 기술 지원 문서를 준비하고, 각 가맹점의 환경에 따른 업데이트 방법에 대해 구체적인 가이드를 제공했으며, 필요한 경우 직접적인 기술 컨설팅을 제공했습니다. 충분한 유예 기간을 거친 후에야 우리는 해당 암호 스위트들을 실제로 제거했습니다.

이 세 번째 단계의 최전선에는 TAM (Technical Account Manager) 팀이 있었습니다. TAM 팀은 각 가맹점에 연락하여 기술 상태를 점검하고, 보안에 익숙하지 않은 상점 주인들에게 상황을 쉬운 용어로 설명했으며, 심지어 가맹점의 기술 팀과 함께 구체적인 설정 값을 하나하나 짚어가며 안내했습니다. 이는 단순히 엔지니어링 노력만으로는 달성할 수 없었을 것입니다. TAM 팀은 3년 넘게 가맹점의 최전선에서 묵묵히 이 작업을 수행했고, 덕분에 결제 서비스가 중단되는 일 없이 취약한 조합들을 하나씩 제거할 수 있었습니다.

TLS 1.3의 전체 배포 (2022–2025): 더 강력한 채널, 조용히 설정된 기본값

TLS는 인터넷 통신 암호화를 담당하는 핵심 프로토콜입니다. 버전이 올라갈수록 더 안전하고 빨라집니다. 현재 업계에서 "안전"하다고 간주하는 기준은 TLS 1.2 이상이며, Toss Payments 역시 동일한 기준을 바탕으로 운영되고 있습니다.

그렇다고 해서 TLS 1.2가 기준이라고 해서 1.3 도입을 미룰 이유는 없습니다. 사실 가장 좋은 결정은 두 버전을 모두 지원하는 것입니다. TLS 1.2와 1.3은 모두 하나의 엔드포인트(Endpoint)에서 서비스될 수 있으며, TLS 1.3을 지원하는 모든 클라이언트는 자동으로 이 더 안전한 채널을 기본값으로 사용하게 됩니다. 오래된 클라이언트는 이전처럼 TLS 1.2를 계속 사용할 수 있으므로, 우리는 가맹점에게 어떠한 변화도 강요하지 않으면서 전체적인 보안 표준을 높일 수 있었습니다.

2022년부터 우리는 엔드포인트(endpoint)별로 TLS 1.3을 활성화하기 시작했으며, 2025년까지 모든 엔드포인트에 TLS 1.3을 완전히 배포했습니다. 최신 환경을 운영하는 가맹점(Merchants)과 구매자들은 별도의 조치 없이도 자동으로 더 강력한 보안 채널로 업그레이드되었습니다.

수년에 걸쳐 암호 스위트(cipher suites)를 제거하고 TLS 1.3을 구현하면서, 우리는 한 가지 명확한 교훈을 얻었습니다. 수만 명의 가맹점에 걸쳐 보안 표준을 한꺼번에 높이는 것은 예상보다 훨씬 더 복잡한 과정이라는 점입니다. 병목 현상은 서버 자체에 기술을 적용하는 것이 아니라, 가맹점의 전환을 돕고 그들이 각자의 속도에 맞춰 전환하기를 기다리는 데 소요되는 시간이었습니다. 이를 통해 우리는 가맹점들이 전환할 수 있는 충분한 시간을 제공하기 위해 보안 프로토콜 개선을 가능한 한 일찍 시작해야 한다는 점을 배웠습니다.

양자 내성 암호 (PQC) 구현 (2026): 지금 구축하는 미래

우리가 얻은 교훈은 또 다른 질문을 불러일으켰습니다. "PQC(Post-quantum Cryptography)를 미리 구현해야 할까?"

"보안을 개선할 또 다른 기회가 있다면, 훨씬 더 일찍 시작하자."