처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.07.31 46

링크에도 전자서명을? 피싱을 원천 차단하려는 '신뢰 가능한 URL' 아이디어

Hacker News 원문 보기
링크에도 전자서명을? 피싱을 원천 차단하려는 '신뢰 가능한 URL' 아이디어

링크 하나 클릭하는 게 왜 이렇게 불안할까요

우리가 하루에도 수십 번씩 하는 일이 바로 링크 클릭인데요. 곰곰이 생각해보면 URL이라는 건 그냥 문자열일 뿐이에요. 누구나 비슷하게 생긴 도메인을 등록할 수 있고, 알파벳 소문자 o를 숫자 0으로 바꾸는 식으로 사람 눈을 속이는 것도 전혀 어렵지 않거든요. 그래서 피싱 공격의 대부분이 '진짜처럼 보이는 가짜 링크'를 클릭하는 순간부터 시작돼요. 이 오래된 문제를 암호학적 서명(cryptographic signature)으로 풀어보자는 접근이 소개돼서, 오늘은 이 아이디어를 차근차근 뜯어보려고 해요.

HTTPS가 있는데 뭐가 부족하냐면요

'주소창에 자물쇠 아이콘 있으면 안전한 거 아니야?'라고 생각하실 수 있는데요. HTTPS가 보장해주는 건 두 가지예요. '지금 접속한 서버가 이 도메인의 주인이 맞다'는 것과 '오가는 내용이 도청·변조되지 않는다'는 것까지죠. 그런데 정작 제일 중요한 질문, 그러니까 '이 도메인이 내가 아는 그 회사가 맞나?'에는 답을 못 해줘요. 피싱 사이트도 무료 인증서를 발급받아서 멀쩡하게 자물쇠 아이콘을 달 수 있거든요. 결국 사용자가 클릭하기 전 단계, 즉 링크 그 자체를 신뢰할 방법이 지금 웹에는 없다는 게 구조적인 구멍이에요.

그래서 나온 아이디어: URL 자체에 서명을 넣자

핵심 아이디어는 이래요. 링크를 발행하는 쪽, 예를 들어 은행이나 쇼핑몰이 자기만 가진 개인키로 URL에 전자서명을 하고, 그 서명값을 URL의 쿼리 파라미터 같은 형태로 함께 붙여서 배포하는 거예요. 받는 쪽인 브라우저나 메일 앱, 메신저는 발행자의 공개키로 서명을 검증하고요. 서명이 유효하면 '이 링크는 진짜 그 기관이 만든 게 맞다'는 표시를 사용자에게 보여줄 수 있는 거죠. 전자서명이 뭐냐면, 개인키를 가진 사람만 만들 수 있고 공개키를 가진 누구나 진위를 확인할 수 있는, 일종의 위조 불가능한 도장이라고 생각하시면 돼요. 여기에 만료 시각이나 용도 같은 정보를 서명 대상에 포함시키면, 오래된 링크를 긁어다 재활용하는 공격도 자연스럽게 막을 수 있고요. 관건은 공개키를 어떻게 배포하느냐인데, 이메일 위조 방지 기술인 DKIM이 그러듯 도메인의 DNS 레코드에 공개키를 올려두는 방식이 가장 자연스러운 후보로 꼽혀요. 도메인 소유자만 DNS를 수정할 수 있으니, 키의 출처 증명까지 한 번에 해결되거든요.

사실 비슷한 개념이 이미 곳곳에 있어요

이 아이디어가 완전히 무에서 나온 건 아니에요. AWS S3의 presigned URL은 HMAC 서명으로 '이 링크를 가진 사람만 정해진 시간 동안 파일에 접근 가능'이라는 규칙을 구현하고 있고요. 이메일 세계의 DKIM은 메일에 발신 도메인의 서명을 붙여서 발신자 위조를 막아요. 앱 설치 파일에 붙는 코드 사이닝도 결국 같은 원리죠. 다만 이것들은 각각 접근 제어, 이메일, 실행 파일이라는 좁은 영역에 갇혀 있었는데, 이번 아이디어는 이걸 '웹의 링크 일반'으로 확장하자는 거라 차원이 달라요. 물론 넘어야 할 산도 커요. 브라우저와 메신저가 검증 로직을 지원해줘야 생태계가 돌아가고, 검증 결과를 사용자에게 어떻게 보여줄지도 어려운 문제거든요. 과거 EV 인증서의 초록색 주소창이 결국 사용자들에게 외면받고 사라진 전례를 보면, 기술보다 UX가 더 큰 숙제일 수도 있어요.

한국 개발자에게 특히 와닿는 이유

한국은 스미싱, 그러니까 문자 메시지로 오는 피싱 링크 피해가 유독 큰 나라잖아요. 택배 사칭, 부고장 사칭 문자에 당하는 사례가 끊이지 않는데, 통신사나 메신저 단에서 서명된 링크에만 '인증됨' 배지를 달아주는 구조가 자리 잡으면 체감 효과가 상당할 거예요. 그리고 이 원리는 당장 실무에서도 써먹을 수 있어요. 비밀번호 재설정 메일이나 로그인 매직 링크를 만들 때, 토큰을 그냥 랜덤 문자열로 두지 말고 만료 시각과 용도를 담아 HMAC이나 JWT로 서명해서 발급하는 것부터가 정확히 같은 원리의 실천이거든요. 서버가 서명을 검증하는 순간, 링크 변조와 재사용 공격을 한 번에 걸러낼 수 있어요.

정리하면

'URL은 믿을 수 없는 문자열'이라는 웹의 오래된 전제를 전자서명으로 뒤집어보자는 시도예요. 여러분 생각은 어떠세요? 이런 방식이 표준으로 자리 잡으려면 브라우저 벤더가 먼저 움직여야 할까요, 아니면 카카오톡 같은 메신저 플랫폼이 먼저 도입하는 게 더 현실적일까요?


🔗 출처: Hacker News

이 뉴스가 유용했나요?

TTJ 코딩클래스 정규반

월급 외 수입,
코딩으로 만들 수 있습니다

17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.

144+실전 강의
17개수익 모델
4.9수강생 평점
정규반 자세히 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.