테크회사 어썸블로그

AI 시대에 인증 과제를 해결할 차세대 표준 후보, ID-JAG

2026-04-30T13:30:00+09:00

안녕하세요. LY Corporation에서 인증·인가 기반 Athenz의 개발·운영을 담당하고 있는 김정우입니다. 이 글에서는 AI 에이전트가 다양한 서비스와 연동할 때 발생하는 ...

현관문에도 얼굴이 있다: 배송 완료 사진 기반 On-device 오배송 탐지 시스템

2026-04-28T00:00:00+09:00

배송 완료 사진의 임베딩 유사도를 기반으로 오배송을 탐지하는 방법과, On-device 추론을 통해 서비스에 적용한 과정을 소개하는 글입니다.

Claude Code Routines로 DevOps PR 리뷰·의존성 점검 자동화하기

2026-04-29T09:00:00+09:00

Routines는 Claude Code가 정해진 시점이나 이벤트에 따라 Anthropic 클라우드에서 자동으로 작업을 시작하고 결과를 전달하는 기능입니다. 추론이 필요한 반복 작업을 사람 개입 없이 자동으로 처리합니다. 이 글은 Routines의 개념과 동작 방식, n8n과 차이점을 다뤘습니다. 또 DevOps 워크플로용 3가지 실습으로 Routines의 실무 활용법과 운영 시 유의 사항을 살펴봤습니다.

Gemini Embedding 2 등 5월 첫째 주 Google for Developers 위클리 업데이트를 지금 확인하세요!

2026-05-01T18:57:00.002+09:00

개발자 여러분, 안녕하세요!

5월 첫째 주 블로그에 발표된 Google의 주요 개발자 제품별 최신 소식을 살펴보세요.

[주요 개발자 블로그 업데이트]

AI & Machine Learning

Gemini Embedding 2로 개발하기: 에이전틱 멀티모달 RAG와 확장 사례 (Building with Gemini Embedding 2: Agentic multimodal RAG and beyond)
Google DeepMind와 과학기술정보통신부, 국가 AI 파트너십 발표 (국문)
AI 전문가들 ‘Google for Korea 2026’ 모여 Google의 AI 성과 및 비전 공유 (국문)
Google과 Kaggle이 함께하는 'AI Agents 바이브 코딩' 신규 코스 참여하기 (Join the new AI Agents Vibe Coding Course from Google and Kaggle)
일상과 업무의 효율을 높여주는 8가지 Gemini 활용 팁 (8 Gemini tips for organizing your space (and life))

Flutter

CocoaPods 지원 종료 및 Flutter의 Swift Package Manager 기본 전환 안내 (Saying goodbye to CocoaPods: Swift Package Manager is soon the default in Flutter!)
Google Cloud Next에서 발표된 Flutter의 모든 소식 한눈에 확인하기 (That’s a wrap: Everything Flutter at Google Cloud Next)

Firebase

실시간 PostgreSQL: Data Connect에서 SQL Connect까지 (Realtime PostgreSQL: From Data Connect to SQL Connect)
한층 강력해진 Firestore: NoSQL에 검색과 JOIN 기능 도입 (Firestore levels up: Bringing the power of search and JOINs to NoSQL)

* 국문 번역본으로 보시려면 Chrome 창에서 각 영문 링크로 이동한 후 마우스 우측 버튼을 눌러 ‘한국어로 번역'을 선택하시면 됩니다.

* 최신 개발자 문서에 대한 알림을 받아보려면, 여기에서 Google 개발자 프로필을 생성하여 손쉽게 살펴보세요. 다양한 개발자 학습 과정과 커뮤니티 이벤트에 참여하면 여러분의 프로필에 표시할 수 있는 온라인 인증 배지도 함께 드립니다.

Google for Developers

빅테크가 주목하는 민감정보보호: 프론티어 민감정보 보호모델의 한국어 성능 분석

2026-04-29T13:12:00+09:00

빅테크가 주목하는 민감정보 탐지, 왜 지금 중요해졌을까요? 임직원이 AI에 붙여넣는 한 줄이 회사 정보를 외부로 흘려보내는 시대, OpenAI와 NVIDIA의 잇따른 모델 공개가 한국 시장에 던지는 의미를 짚어봅니다.

해커가 알려주는 안전한 비밀번호 조합 완전 정리 (2026년 기준)

2026-04-28T11:18:42+09:00

내가 쓰는 비밀번호, 해킹에 얼마나 걸릴까요? 짧으면 15분, 길면 수억 년이 걸립니다. 2026년 기준 가장 안전한 비밀번호 조합을 확인해 보세요.

비개발자의 AI 협업 도전기 — 생산성 측정하려다 서버까지 띄운 9일

2026-04-29T19:56:02+09:00

"조직이 잘하고 있는지 어떻게 알 수 있을까?" 이 질문에서 출발해 사내 가이드 문서와 AI를 붙들고 직접 측정 도구를 완성하기까지 9일이 걸렸습니다. 그 과정을 기록으로 남깁니다.

사내 생산성 측정에 관한 고민

기술 PM으로 일하면서 조직과 프로젝트의 생산성을 어떻게 측정할지는 늘 풀리지 않는 과제였습니다. 스프린트를 원활하게 진행하는 것 같아도 막상 이를 수치로 보여달라고 하면 난감했습니다. 속도가 빨라지는지, 병목이 어디서 발생하는지, 지난 분기보다 나아지고 있는지 감각적으로는 알 수 있었지만 데이터로 명확히 설명하기는 어려웠습니다.

사내에는 이미 'DevOps board'라는 시스템이 있어 배포 빈도와 리드타임을 포함한 DORA 지표를 제공하고 있습니다. 소프트웨어 딜리버리 흐름을 측정한다는 점에서 제가 찾던 도구에 가까웠습니다. 다만 저는 분석 지표와 상황에 맞추어 조금 더 세분화된 데이터를 들여다보고 싶었습니다.

그래서 먼저 Jira 대시보드를 만들어 리치 필터(rich filter)로 데이터를 추출해 보았습니다. 이슈 완료 수, 스프린트 완료율, 컴포넌트별 작업량 등 여러 수치가 모였지만, 수집한 숫자만으로는 조직의 작업 속도를 한눈에 파악하기 어려웠습니다. 작업이 어디서 얼마나 걸리는지도 보이지 않았습니다. Jira는 업무를 관리하는 도구일 뿐 소프트웨어 딜리버리 흐름 전체를 측정하는 도구는 아니기 때문입니다.

결국 특정 컴포넌트 기준의 분류, 팀 고유의 이슈 타입 정의, 팀 내 업무 흐름을 세밀하게 들여다볼 수 있는 맞춤형 도구가 필요했습니다. 기존 DevOps board를 대체하려는 것이 아니라, 팀의 상황에 맞추어 데이터를 직접 구성해 보고 싶었습니다.

문제는 제가 이를 직접 구현할 기술적 역량이 부족하다는 점이었습니다. 개발자에게 부탁하기에는 작업 규모가 작았고, 백로그에 등록하더라도 언제 진행될지 기약할 수 없었습니다. 그래서 AI의 도움을 받아 직접 만들어 보기로 했습니다.

1단계: HTML 파일 하나로 가설 검증

처음에는 배포, 서버, 인증 과정을 모두 생략하고 HTML 파일 하나로 가볍게 시작했습니다. 브라우저에서 Jira 변경 기록(changelog) CSV 파일을 파싱해 바로 시각화하는 구조였습니다.

AI에게 전달한 첫 프롬프트에는 현재 상황과 맥락을 최대한 자세히 담았습니다.

Jira 이슈별 changelog CSV에는 'Issue Key', 'Status', 'Created' 칼럼이 있어.

각 이슈가 'In Progress'로 처음 전환된 시각과 'Done'으로 전환된 시각의 차이를 일(day) 단위로 계산하고 싶어. 팀별, 이슈 타입별로 집계해서 주차별 트렌드를 보여주는 웹 대시보드를 만들고 싶은데,

구조는 이해하지만 직접 구현은 못 해.

이 프롬프트에는 데이터 형식, 원하는 결과물, 그리고 저의 기술적 한계가 모두 들어가 있습니다.

AI는 곧바로 코드를 작성하는 대신 발생할 수 있는 예외 상황(edge case)을 먼저 짚어 주었습니다.

이슈가 In Progress → Backlog → In Progress로 다시 이동했다가 Done이 되는 경우, 리드타임 기산점을 첫 번째 In Progress로 할지 마지막으로 할지 정의가 필요해요. Done 이후 재오픈 케이스는요?

이 질문을 받기 전까지는 저 역시 이러한 예외 상황을 생각하지 못했습니다. 실제로 확인해 보니 데이터에 해당 사례가 적지 않게 포함되어 있었습니다. 결국 AI와 대화하는 과정 자체가 요구사항 정의 세션이 된 셈입니다.

물론 초기에는 버그도 있었습니다. Jira CSV의 타임스탬프가 UTC 기준이라 KST로 변환해 날짜를 계산해야 했고, 내보내기 설정에 따라 이슈 타입 필드명이 달라지는 문제도 있었습니다. 이럴 때는 문제를 말로 설명하기보다 실제 CSV 헤더와 샘플 데이터 일부를 AI에게 그대로 보여주는 편이 훨씬 효과적이었습니다.

이렇게 해서 대시보드 화면에 리드타임 수치가 나타났습니다. 하지만 그 숫자를 보면서 새로운 의문이 생겼습니다. 이 수치가 좋은 편인지 나쁜 편인지는 어떻게 알 수 있을까요?

2단계: DORA 지표를 통한 기준 마련

리드타임을 측정하는 것과 그 수치의 의미를 파악하는 것은 별개의 문제였습니다. 그래서 소프트웨어 딜리버리 성과를 측정하는 프레임워크인 DORA 지표를 참고했습니다. DORA 지표는 수많은 팀과 프로젝트의 데이터를 분석해 도출한 네 가지 핵심 지표로 구성됩니다.

배포 빈도
변경 리드타임
변경 실패율
서비스 복구 시간

여러 연구를 통해 이 네 가지 지표가 팀의 딜리버리 역량을 가장 잘 설명한다는 사실이 검증되었습니다.

제가 측정한 Jira 리드타임은 이 중 '변경 리드타임'에 해당했습니다. 작업 시작부터 실제 배포까지 걸리는 시간입니다. 나머지 지표를 확인하려면 추가 데이터가 필요했습니다. 배포 빈도는 배포 이벤트 로그에서, 변경 실패율과 복구 시간은 PR(Pull Request) 및 이슈 데이터에서 얻을 수 있었습니다.

결국 Jira 데이터만으로는 전체 딜리버리 흐름의 절반만 볼 수 있었습니다. 나머지 절반을 채우려면 사내 GitHub 데이터를 연동해야 했습니다.

3단계: AI를 활용한 서버 구축과 가이드 문서

GitHub API를 주기적으로 호출하고 이를 Jira 데이터와 결합하려면 단순한 브라우저용 HTML 환경으로는 부족했습니다. 별도의 서버가 필요해진 것입니다.

사실 이 시점에서 진행을 포기할까 고민도 했습니다. Dockerfile을 한 번도 작성해 본 적 없는 비개발자가 컨테이너 기반 배포를 직접 해낼 수 있을지 확신이 서지 않았기 때문입니다.

일단 사내 공통 컨테이너 플랫폼인 'N3R'의 가이드 문서부터 찾아보았습니다. 하지만 낯선 용어가 많아 문서 첫 페이지부터 막막했습니다. 그래서 접근 방식을 바꿨습니다. 가이드 문서를 혼자 끙끙대며 읽는 대신, 그 내용을 AI에게 전달하고 함께 해석해 나가기 시작한 것입니다.

이 가이드에 이렇게 나와 있는데, 파이썬 FastAPI 앱에 적용하면 Dockerfile을 어떻게 써야 해? [가이드 해당 섹션 붙여넣기]

가이드 문서에는 사내 환경과 표준 규칙이 담겨 있습니다. AI는 그 내용을 제 상황에 맞게 구체화해 주었습니다. 둘 중 어느 한쪽만으로는 해결이 어려웠지만, 가이드 문서와 AI를 교차로 활용함으로써 무사히 서버를 띄울 수 있었습니다.

4단계: 스케줄러 설정과 데이터 누락 문제 해결

서버를 구축했다고 해서 데이터가 저절로 모이는 것은 아닙니다. Jira와 GitHub API를 주기적으로 호출해 줄 스케줄러가 필요했습니다. 다행히 사내에는 이미 Self-Hosted Runner 환경과 관련 설정 가이드 문서가 마련되어 있었습니다.

돌이켜보면 9일 중 가장 많은 시간을 이 구간에서 소요했습니다. Runner 환경 변수 설정, 인증 토큰 발급, API 페이지네이션(pagination) 처리 등 예상치 못한 문제가 꼬리를 물고 나타났기 때문입니다.

그중에서도 가장 애를 먹었던 부분은 API 페이지네이션이었습니다. 조회할 이슈가 1,000개를 넘어가면 API 응답이 중간에 잘리는데, 초기에 AI가 작성한 코드에는 이 예외 처리가 누락되어 있었습니다. 오류 메시지조차 없이 데이터만 조용히 누락되고 있었고, 나중에 직접 숫자를 대조하며 검증하다가 우연히 발견했습니다.

이 과정을 거치며 제가 AI에게 질문하는 방식도 달라졌습니다. 초반에는 "이거 어떻게 해요?"에 가까웠다면, 나중에는 가이드 내용, 현재 설정 파일, 오류 메시지를 함께 붙여 "이 값을 내 상황에 어떻게 적용하면 돼?"라고 물었습니다. 상황과 맥락을 자세히 전달할수록 AI의 답변은 훨씬 정확해졌습니다.

5단계: 사내 스토리지 연동과 사람의 역할

수집한 데이터를 저장하고 필요할 때 화면에 제공하려면 스토리지가 필요했습니다. 사내에서 제공하는 Redis 기반 스토리지인 nBase-ARC를 활용하기로 하고 관련 가이드 문서를 참고했습니다.

AI는 보편적인 Redis 사용법은 훌륭하게 알려 주었습니다. 하지만 사내의 특수한 네트워크 정책, 고유한 TTL 설정 방식, 접근 권한 신청 프로세스 같은 내부 정보는 알지 못했습니다. 이런 부분에서는 사내 가이드 문서와 사내 AI 기반 문의 채널 ASK가 도움이 되었습니다.

널리 공개된 기술 스택을 다룰 때 AI는 탁월한 조력자입니다. 하지만 사내 특화 환경, 내부 정책, 조직 고유의 관행은 AI가 파악할 수 없는 영역입니다. 이 영역은 결국 사람이, 문서가, 동료가 채워야 합니다.

완성된 대시보드의 효과

이제 Jira와 GitHub 데이터는 매일 자동으로 수집됩니다. 대시보드에 접속하면 조직과 프로젝트의 전반적인 딜리버리 흐름을 한눈에 확인하고 다음과 같은 것들을 쉽게 파악할 수 있습니다.

리드타임이 유독 길어지는 구간
특정 이슈 타입에서 반복되는 병목 현상
스프린트 후반부에 배포 이벤트가 몰리는 패턴

'요즘 왠지 개발 속도가 느려진 것 같다'는 막연한 느낌을 이제는 데이터를 근거로 설명할 수 있게 되었습니다.

물론 이 대시보드가 완벽한 측정 도구는 아닙니다. DORA 지표를 온전히 구현한 것도 아닙니다. 하지만 측정 도구가 아예 없었을 때와 비교하면 확실한 차이가 있습니다. 가장 큰 변화는 조직 회고 시간의 논의 수준이 달라졌다는 점입니다. 막연한 감이 아니라 실제 데이터를 보면서 이야기하게 되었습니다.

프로젝트를 진행하며 배운 점

기획의 재발견: AI는 마법사가 아니라 정밀한 조각가다

AI는 사용자가 원하는 바를 구현하는 데 탁월한 능력을 보여줍니다. 하지만 그 전제는 사용자 스스로 '무엇을 원하는지'를 명확히 알고 있어야 한다는 것입니다.

작업을 하면서 특히 효과적이라고 느낀 소통 방식은 다음 세 가지였습니다.

실제 데이터를 예시로 보여주기
발생 가능한 예외 상황을 미리 정의하기
기대한 결과와 실제 결과의 차이를 명확히 짚어 주기

이 세 가지 요건이 충족될 때 AI는 가장 정확한 결과물을 내놓았습니다. 결국 기획이란 필요한 기능을 나열하는 작업이 아니라, AI가 올바르게 이해하고 작업할 수 있도록 꼼꼼한 설계도를 그리는 과정이었습니다. 얼마나 명확하고 구체적으로 지시하느냐가 최종 결과물의 품질을 결정했습니다.

인프라의 벽: 가이드와 AI, 둘 다 필요했다

서버를 구축하는 과정에서는 사내 가이드 문서와 AI를 함께 활용해야 했습니다. 가이드 문서는 사내 환경을 정확히 설명해 주었지만 제 프로젝트 상황에 딱 맞는 답을 주지는 못했습니다. 반대로 AI는 기술적 원리를 잘 설명해 주었지만 사내 환경의 특수성은 알지 못했습니다.

따라서 이 둘을 교차해서 쓰는 것이 가장 효율적이었습니다. 가이드 문서의 내용을 AI에게 알려 주고 그 의미를 함께 해석하는 방식입니다. 가이드 문서가 '무엇을' 해야 하는지 알려주면, AI가 '어떻게' 해야 하는지 구체화했습니다.

새로운 아이디어의 실현은 도구의 발전에서 비롯되지만, 그것이 지속 가능하게 유지하는 힘은 안정적인 인프라에서 나옵니다. 그리고 비개발자조차 그 인프라에 접근해 활용할 수 있도록 길을 열어 주는 것은 결국 잘 작성된 가이드 문서입니다.

토큰의 무게: AI는 공짜가 아니다

AI를 활용하면서 토큰(비용)이 유독 많이 소모되는 구간이 있었습니다. 대체로 다음과 같은 상황이었습니다.

AI가 매번 코드 전체를 새로 읽게 했던 초반
대화 맥락을 정리하지 않고 질문을 무분별하게 이어 갔던 중반
분석 탭에서 AI API를 3번 순차 호출하던 구조

해법은 '역할 분리'였습니다. 데이터 파싱이나 집계 같은 단순 계산은 JavaScript 코드가 직접 처리하도록 하고, AI에게는 최종적으로 요약된 수치만 전달해 의미 해석을 맡기는 구조로 바꿨습니다. 그러자 토큰 사용량이 눈에 띄게 줄었고 응답 속도도 훨씬 빨라졌습니다.

어떤 기능을 구현하기 전에는 "이 작업을 반드시 AI가 처리해야 하는가?"를 먼저 자문해 볼 필요가 있습니다. 명확한 규칙으로 처리할 수 있는 작업은 코드로 해결하고, AI는 문맥 판단이나 해석이 필요한 영역에만 제한적으로 활용하는 편이 효율적입니다.

AI의 한계: 오류가 없다고 올바른 것은 아니다

가장 많은 시간을 낭비하게 만든 것은 역설적이게도 AI가 확신에 차서 작성해 준 코드였습니다. 앞서 언급한 API 페이지네이션 코드는 겉보기에는 아무런 오류 없이 매끄럽게 동작했습니다. 하지만 이슈가 1,000개를 넘어가는 순간부터 데이터가 시스템 내부에서 조용히 누락되고 있었습니다. 출력된 수치를 꼼꼼히 검증해 보지 않았다면 끝까지 몰랐을 문제였습니다.

따라서 AI가 만들어 준 코드는 오류 없이 실행되는지 확인하는 선에서 그쳐서는 안 됩니다. 도출된 결과가 실제로 정확한지 정합성을 검증하는 단계가 반드시 필요합니다. 샘플 데이터로 직접 계산한 값과 AI의 결과물을 대조해 보는 과정은 번거롭지만 생략할 수 없습니다.

생태계의 제언: '데이터 민주주의'를 위한 조건

비개발자인 제가 이 프로젝트를 무사히 마칠 수 있었던 것은 AI의 능력 덕분만은 아니었습니다. 든든한 사내 가이드 문서가 뒷받침되었기에 가능한 일이었습니다. 가이드 문서가 없었다면 아무리 훌륭한 AI라도 사내 환경에 맞는 결과물을 만들어내기 어려웠을 것입니다.

회사에는 방대한 데이터와 훌륭한 인프라가 있습니다. 하지만 권한은 열려 있어도 이를 실제로 활용할 수 있는 사람은 극소수인, 이른바 '접근은 가능하지만 접근할 수 있는 사람은 없는' 상태에 머무는 경우가 많습니다.

API 사용 가이드를 조금 더 체계적으로 다듬고, 자주 쓰이는 템플릿 코드를 사내에 공유하고, 보안 가이드라인을 명확히 제시해 주는 것만으로도 수많은 사내 맞춤형 도구가 새롭게 만들어질 수 있습니다. 비개발자가 AI와 협업해 가치 있는 무언가를 만들어 내는 진정한 전제 조건은 결국 '친절하고 정확한 가이드 문서'입니다. AI는 사용자가 그 가이드를 조금 더 쉽게 소화하고 자기 상황에 적용할 수 있도록 돕는 훌륭한 조력자일 뿐입니다.

마치며

불과 9일 전의 저는 스스로 서버를 구축할 수 있을 거라고는 생각도 못 했습니다. 그런데 결국 Dockerfile을 작성하고, 컨테이너를 빌드해 배포하고, API를 주기적으로 호출하는 스케줄러를 구성했으며, Redis에 데이터를 읽고 쓰는 경험까지 했습니다. 코드는 대부분 AI가 작성해 주었지만, '무엇을 만들 것인지', '어떤 구조로 설계할 것인지', '최종 결과물이 올바른지'를 판단하는 몫은 온전히 제게 있었습니다.

대시보드의 숫자를 보며 종종 생각합니다. '우리 조직과 프로젝트는 잘 나아가고 있나?' 예전에는 막연했던 그 질문에, 이제는 데이터를 근거로 조금은 명확한 답을 할 수 있게 되었습니다.

동료에게서 "이거 어떻게 만드셨어요?"라는 질문을 받을 때마다 저는 이렇게 답하곤 합니다.

"AI한테 말로 시켰어요. 그런데 뭘 시킬지는 제가 알아야 했어요."

이 글을 통해 전하고 싶은 메시지는 단 하나입니다. AI를 잘 활용하는 조직은 성능 좋은 AI 도구를 선별하는 데 그치지 않고, AI가 역량을 제대로 발휘할 수 있는 밑바탕 환경을 먼저 탄탄하게 갖춘 조직입니다.

데이터를 같은 기준으로 관리하려는 조직적 합의
누구나 안전하게 접근하여 실험할 수 있는 열린 인프라
비개발자도 천천히 따라갈 수 있도록 작성된 가이드 문서

이 세 가지가 바로 AI 시대에 필요한 인프라입니다.

Why We Adopted Post-Quantum Cryptography a Decade Before Quantum Computers Arrive

2026-04-27T17:46:00+09:00

*This is the English version of a previously published article.

Hello, Toss Tech readers. I'm Tae-ho Ha, Head of Technology at Toss Payments.

Ever since we started the Legacy Overhaul Series, one question has followed us everywhere:

"What was the biggest challenge in overhauling a 20-year-old legacy system?"

Most people expect a story about some deep technical problem.

And yes, there were plenty of tough moments along the way. But the engineers brought real depth and commitment to every challenge, and that's what made the impossible possible.

The real challenge, though, was something else: raising our security standards while keeping tens of thousands of merchants on board every step of the way.

Today, I'd like to share our years-long journey of updating the security protocol, and where it ultimately led us: the adoption of Post-Quantum Cryptography.

Breaking Old Habits

When you've been running a mission-critical payment service for a long time, an unspoken rule tends to take hold across the team:

"If it ain't broke, don't fix it. We can't afford downtime."

It's a conservative principle built to ensure stability. But it doesn't apply the same to everything. Small, reversible changes are implemented all the time. But when a change is far-reaching and hard to undo, a different instinct kicks in: "Do we really need to touch this right now?"

In fact, security protocols are where that instinct hits strongest. Upgrading the TLS version, removing weak cipher suites, introducing new encryption schemes are all obviously the right calls. But touch any of it, and tens of thousands of merchants are directly affected. And when something goes wrong, troubleshooting is never straightforward. This is exactly where the reluctance comes from.

Here's an example to give you a sense of what we're up against. Toss Payments still works with merchants who have been integrated with our PG system for decades. The older the integration, the more likely their server stack is running on outdated technology. Web browsers silently update themselves and stay current with the latest security standards, but the clients calling our API are mostly server-side programs. Applying modern security policies to software running on aging infrastructure is a lot harder than it sounds.

And getting the word out is its own challenge. Security isn't most developers' strong suit, and even when we provided well-written technical documents, it often took merchants a long time to fully understand what was being asked of them and act on it. Many of our merchants are small businesses run by a single owner with no dedicated dev team, and asking them to respond to a security upgrade request filled with technical jargon is genuinely a big ask.

A PG system is connected to tens of thousands of merchants through SDKs and API integrations. Every touchpoint, every API call, every payment window, every server communication, represents a security boundary. No matter how advanced your security stack is, if even a handful of merchants are still running on legacy environments, those connections are only half-protected.

That's why improving our security protocols was never something Toss Payments could solve on its own. It's a burden for us and for our merchants alike, which makes it all too easy to keep putting it off.

Why We Had to Change Anyway

But security is one area where "it's fine for now, so it's fine" just doesn't hold up. And right now, we're at a point where the very foundations of encryption we've taken for granted are starting to crack.

And this is where quantum computers come in.

You've probably come across the term in the news at some point. Quantum computers work on fundamentally different computational logic than the computers we use today. A regular computer processes combinations of 0s and 1s sequentially, one at a time. A quantum computer, by contrast, uses the principles of quantum mechanics to explore many possibilities simultaneously. Problems that would take a conventional computer tens of thousands of years to solve are expected to be crackable by a quantum computer in a matter of hours.

That kind of computational power poses a fundamental threat to the encryption systems that we rely on today.

Why Today's Encryption Can Be Broken

The encryption we use every day, in banking apps, payment windows, and HTTPs, mostly runs on public-key algorithms like RSA and ECDSA. The reason these algorithms are considered secure is actually pretty simple. They rely on one core assumption: factoring a very large number, or working backwards to find a specific value on an elliptic curve, is computationally infeasible for a conventional computer. The math has an answer, but it would take modern computers an extraordinarily long time to find it. So we've treated them as "practically secure."

However, the problem is that algorithms capable of solving these exact problems on a quantum computer have already been mathematically proven to exist. The moment a sufficiently powerful quantum computer is built, RSA and ECDSA, locks that once required an astronomical amount of time to crack, become locks that can be opened with ease. This isn't just a shift in the technology landscape. It's an event that shakes the very foundation of digital security built up over the past several decades.

Q-Day and "Harvest Now, Decrypt Later"

IBM, Google, IonQ, and other major players are actively working toward practical quantum computers, with 2030 as a key target. Security experts refer to the moment when today's encryption breaks down as "Q-Day."

It might feel like a distant future, but the threat has already begun. In fact, the most well-known attack scenario is called "Harvest Now, Decrypt Later."

The attack works like this: someone quietly intercepts and stores encrypted communications today, then decrypts everything in bulk once quantum computers become available. Payment data is a prime target, since it stays valuable for years. Data that's in transit today in 2026 could be sitting exposed in 2033.

What's secure today isn't necessarily secure tomorrow. Leaving a potential vulnerability unaddressed today is the same as ignoring a live threat tomorrow.

Four Years of Security Protocol Advancement

Toss Payments has worked on upgrading the security protocol in phases since 2022. Instead of overhauling everything at once, we approached it step-by-step, implementing upgrades over the course of four years.

What may look like a simple list of technical upgrades is anything but. Behind each of these four bullet points was a constant tension: respecting the time merchants need to adapt, but never compromising on security. Every step was a tightrope walk between the drive to adopt new security technologies quickly and the weight of knowing that any misstep could lead to a disruption in payments for merchants.

Let's look at what each phase means, and why we approached it in this order.

Implementing HTTP/3 (2022): Starting with the Easiest, Obvious Step

The journey began with the adoption of HTTP/3. HTTP/3 is the latest protocol for transferring data over the web. It's designed to be faster and more stable even in poor network conditions. More importantly, HTTP/3 is designed to mandate the use of TLS 1.3. Meaning, the latest security protocol applies automatically simply by enabling HTTP/3.

In 2022, Toss Payments adopted HTTP/3, making it the first in the PG industry to do so. It served faster payment window response times and elevated security as well. The best part for merchants was that no additional work was needed on their end. As web browsers (Chrome, Safari, Edge etc.) used by buyers automatically opt for the latest protocols, merchants didn't have to do anything. The upgrade would apply itself through their existing Toss Payments integration.

HTTP/3 required nothing from merchants, making it the right first step for this journey. It laid the groundwork for the more demanding work that would follow.

Removing Weak TLS Cipher Suites (2022–2025): The Longest 3 Years

This second phase was the longest and most difficult out of the four. Let's look at what a cipher suite is to understand why it was so complex.

What is a cipher suite? A cipher suite is a set of cryptographic algorithms used to decide an encryption method when the server and client communicate over an encrypted connection. Think of it as preparing several different types of locks, and choosing the strongest one that both sides have. But as time passes, flaws may be found in some of these locks, which means that algorithms once deemed secure can become breachable by experts. This happens regularly, at which point the corresponding cipher suite is classified as a weak combination and must be removed.

The real problem, however, lies in the merchant's server. Some merchants run old legacy servers that don't support the latest cipher suites, and happen to only support the "weak combinations."

There were two obvious options we could choose:

Neither option was acceptable. So we carved out our own third path.

The answer we found was phased removal + individual support. We first looked into which cipher suite each merchant was using, and began notifying the merchants with weak combinations six months to a year ahead of the removal. We prepared technical support documentation, provided specific guidance on how to update based on each merchant's environment, and offered direct technical consultations where needed. Only after a sufficient grace period did we actually remove the corresponding cipher suites.

At the forefront of this third phase was the TAM (Technical Account Manager) Team. The team reached out to each merchant to assess their technical status, explain the situation in plain terms for store owners unfamiliar with security, and even walk the merchants with tech teams through specific configuration settings. This would not have been achievable with just engineering efforts alone. The TAM team quietly kept up this work at the front lines with merchants for over three years, allowing us to remove weak combinations one by one without ever bringing payments to a stop.

Full Rollout of TLS 1.3 (2022–2025): A Stronger Channel, Silently Set as Default

TLS is the key protocol responsible for internet communications encryption. With each version, it gets safer and faster. The current industry baseline for what is considered "safe" is TLS 1.2 or above, and Toss Payments operates on that same baseline.

That said, the 1.2 baseline is no reason to hold off on 1.3. In fact, the best call is to actually support both versions. Both TLS 1.2 and 1.3 can be served from one endpoint, and any client that supports TLS 1.3 will automatically default to this safer channel. Old clients can continue using TLS 1.2 as before, meaning we raised the overall security standard without forcing any changes on our merchants.

Starting in 2022, we began enabling TLS 1.3 endpoint by endpoint and by 2025, TLS 1.3 was fully rolled out for all endpoints. Merchants and buyers running the latest environments were automatically upgraded to a stronger security channel without any action required on their end.

After years of removing cipher suites and implementing TLS 1.3, there was one clear lesson learned. Raising the security standard across tens of thousands of merchants at once is far more involved than one might expect. The bottleneck wasn't applying the technology to servers itself, but the time spent helping merchants transition and waiting for them to do so at their own pace. That taught us that we need to start security protocol improvements as early as possible, to give merchants enough time to make the switch.

Implementing Post-quantum Cryptography (PQC) (2026): A Future Built Now

The lesson we learned sparked another question: "Do we need to implement PQC in advance?"

"If there's another opportunity for security improvement, let's start even earlier."

That was the answer we found from our three years of experience. And as if on cue, the next opportunity arrived in the form of post-quantum cryptography. Quantum computers have yet to be commercialized, but as with the "Harvest Now, Decrypt Later" attacks mentioned earlier, the threats are already there. Preparing for the threats that lie a decade ahead means starting preparations today.

Toss Payments began laying the groundwork for PQC implementation in 2025 and completed the full rollout in April 2026. It was the final step of the four-year security protocol modernization effort, and at the same time, the first step toward the decade ahead.

As with TLS 1.3, clients that support stronger security communications default to the latest, safest channel.

Nothing changes for the merchants. No configurations or updates are needed. It minimizes the pressure for merchants while serving the highest level of security by default.

It Was Built Together

Getting this architecture stably into production was never something a single team could pull off alone. It took multiple teams working in sync, each bringing their piece to the table.

Toss Payments shares the vision behind the government's "National Post-Quantum Cryptography Transition Master Plan (양자내성암호 전환 마스터플랜)." Thanks to the outstanding collaboration across these three teams, we've completed a proactive technical proof-of-concept to help secure the private payments ecosystem. This is especially meaningful because it means we've already validated interoperability and established security guidelines at the private sector level, well ahead of the national transition target set for 2035.

Why Look Ten Years Ahead?

If you've made it this far, you most likely have one question on your mind: "Quantum computers aren't in the market yet, so why the rush?"

The answer to that question lies in our four-year journey itself.

Keeping Every Merchant on Board

Toss Payments serves not only web browsers that buyers use, but also API integrations with merchants that have been built up for decades. The server environments merchants use to call this API are more varied than one might expect, and many are legacy systems that cannot be easily updated. The three-year process of streamlining cipher suites and adopting TLS 1.3 made that abundantly clear.

Getting Ahead on Security Buys Merchants' Time

That's the conclusion we arrived at from four years of experience.

When security issues are addressed only as they become urgent, merchants are left with no choice but to hear, "you need to update immediately." That disrupts the merchants' development roadmaps and puts the entire payments ecosystem at risk. But when we look a decade ahead and start preparing now, the story changes completely.

What the 4-year Journey Taught Us

Let's take a look at the past 4 years.

Proactive adoption of HTTP/3 → Phase out of weak Cipher Suites → Full TLS 1.3 rollout → Adoption of post-quantum cryptography

Each stage was never just a technical upgrade. It was the Infrastructure, Server Platform, and TAM team working together, quietly laying the groundwork today for a safer decade ahead. All to serve the tens of thousands of merchants and the tens of millions of consumers behind them.

Just as we declared with the launch of the Legacy Overhaul Series, we are challenging the assumption that payments are "inherently inconvenient and complex." We want to challenge the convention once again. But this time, in the area of security: a world where the highest level of security is already the default, without merchants ever having to think about it, that's the world we're working to create.

New threats will come. They always do. When that day arrives, we will be ready. For PGs, that work is already underway in the form of communication security.

On April 3, 2026, Toss Payments became the first company in Korea's financial & IT industry to implement NIST-standard post-quantum cryptography (PQC) in a payment service. (Related article)