HMAC과 디지털 서명의 차이: 웹훅에서 각각 무엇을 증명하나요?
HMAC은 송신자가 공유 시크릿을 가졌음을 증명합니다. 디지털 서명은 개인 키로 만들고 공개 키로 확인하며, 부인 방지까지 더합니다.

HMAC과 디지털 서명은 둘 다 수신자가 메시지가 바뀌지 않았고 키를 가진 쪽에서 왔는지 확인하게 해 주지만, 쓰는 키가 다릅니다. HMAC은 양쪽이 함께 가진 공유 시크릿 하나를 쓰므로, 어느 쪽이든 그 값을 만들었을 수 있습니다. 디지털 서명은 서명자만 가진 개인 키로 만들고, 누구나 가질 수 있는 공개 키로 확인합니다. 그래서 HMAC은 인증과 무결성을 제공하지만 부인 방지는 제공하지 않고, 디지털 서명은 셋 다 제공합니다.
정의는 RFC 2104, RFC 4949, RFC 7518, RFC 7519, 그리고 NIST 용어집의 메시지 인증 코드와 디지털 서명 항목에서 인용했습니다. Sume 관련 내용은 Run 웹훅 (영문)과 웹훅 검증 문서에서 가져왔습니다. 모두 2026-09-28에 확인했습니다.
HMAC 서명이란 무엇인가요?
HMAC은 암호 해시 함수와 비밀 키로 만드는 메시지 인증 코드(MAC)입니다. HMAC을 정의한 RFC 2104는 MAC을 비밀 키에 기반한 무결성 검사로 설명하며, 보통 그 키를 공유하는 두 당사자 사이에서 쓰인다고 말합니다. 송신자는 키로 메시지의 HMAC을 계산해 함께 보내고, 수신자는 다시 계산해 비교합니다. RFC 7518은 HMAC을 만든 쪽이 키를 보유했음을 입증하는 데 HMAC을 쓸 수 있다고 설명합니다.
양쪽이 같은 키를 가지므로, 어느 쪽이든 그 태그를 만들었을 수 있습니다. NIST 용어집은 그 결과를 이렇게 요약합니다. MAC은 인증과 무결성 보호를 제공하지만 부인 방지 보호는 제공하지 않습니다.
HMAC은 디지털 서명과 어떻게 다른가요?
누가 어떤 키를 가지느냐가 다릅니다. 비교를 위해 일반 해시도 표에 넣었습니다.
HMAC과 SHA-256은 무엇이 다른가요?
SHA-256은 해시 함수입니다. 키 없이 임의 길이의 입력을 고정 길이 값으로 바꾸므로, 누구나 어떤 메시지의 해시든 계산할 수 있습니다. 메시지 옆에 붙여 보낸 해시는 우발적인 변경은 잡아내지만, 메시지를 바꾼 공격자는 해시를 다시 계산하기만 하면 됩니다. HMAC-SHA256은 해시 함수로 SHA-256을 쓰는 HMAC이므로, 결과가 메시지뿐 아니라 비밀 키에도 좌우됩니다. RFC 7518은 이를 SHA-256을 쓰는 HMAC인 HS256으로 나열합니다.
웹훅은 왜 디지털 서명 대신 HMAC을 쓰나요?
웹훅에는 송신자 하나와 수신자 하나가 있고, 서명을 확인해야 하는 쪽은 수신자뿐입니다. 공유 시크릿은 이 구조에 잘 맞습니다. 검사에는 해시 함수와 키만 있으면 되고, 설득해야 할 제삼자가 없으니 부인 방지로 얻는 것도 적습니다. 대신 양쪽이 모두 시크릿을 가지므로, 양쪽 모두에서 시크릿을 지키고 교체해야 합니다.
Sume 웹훅이 이렇게 동작합니다. 전달마다 워크스페이스별로 파생된 시크릿을 키로 계산한 <timestamp>.<raw_body>의 HMAC-SHA256이 hex로 인코딩되어 x-sume-webhook-signature 헤더에 sume-v1=<hex_signature> 형태로 실립니다. 공유 시크릿 관리의 수고를 덜어 주는 기능도 두 가지 있습니다. 지문 헤더를 쓰면 시크릿을 보내지 않고도 양쪽이 같은 시크릿을 가졌는지 확인할 수 있고, 교체 후 24시간 동안 Sume가 이전 시크릿과 새 시크릿 모두로 서명하므로 원하는 일정에 맞춰 다시 배포할 수 있습니다. 검증기는 Sume 영상 실행용 서명된 웹훅에서 다룹니다.
JWT는 HMAC으로 서명하나요, 디지털 서명을 쓰나요?
둘 다 가능합니다. RFC 7519는 JWT의 클레임을 디지털 서명하거나 MAC으로 무결성을 보호할 수 있다고 말하며, RFC 7518은 두 종류의 alg 값을 모두 나열합니다. HS256은 공유 키와 함께 SHA-256을 쓰는 HMAC입니다. RS256(SHA-256을 쓰는 RSASSA-PKCS1-v1_5)과 ES256(P-256과 SHA-256을 쓰는 ECDSA)은 디지털 서명으로, 개인 키로 만들고 짝이 되는 공개 키로 검증합니다. 그러니 HMAC과 JWT를 비교하는 것은 서명 방식과 그 방식을 쓸 수 있는 토큰 형식을 비교하는 셈입니다.
RFC 7518은 타이밍 공격을 막기 위해 HMAC을 상수 시간으로 비교하도록 요구하기도 합니다. 웹훅 검증기가 따르는 것과 같은 규칙입니다. 나머지 규칙은 웹훅 보안 모범 사례에 정리되어 있습니다.
출처
관련 글
개발자 카테고리의 다른 글
- AI 이미지 생성은 얼마나 걸리나요?
Sume에서는 대부분의 AI 이미지가 API가 요청을 열어 두는 30초 안에 완성됩니다. 무엇이 시간을 늘리는지, 느린 이미지와 멈춘 이미지를 어떻게 구분하는지 알아보세요.
- MCP 서버 테스트 방법: Inspector, Postman, curl
MCP 서버는 MCP Inspector로 테스트합니다. 연결하고, 로그인하거나 인증 헤더를 넣고, 도구 목록을 본 뒤 읽기 전용 도구를 호출하세요. Postman과 curl로도 됩니다.
- POST는 멱등한가요? 아니요, PUT과 DELETE는 멱등합니다
아니요, HTTP는 GET, HEAD, OPTIONS, TRACE, PUT, DELETE를 멱등하다고 정의하지만 POST와 PATCH는 아닙니다. 멱등성 키가 있으면 POST 재시도가 안전합니다.
- 로컬 vs 원격 MCP 서버 차이: stdio와 Streamable HTTP
로컬 MCP 서버는 여러분의 컴퓨터에서 실행되어 stdio로 통신하고, 원격 MCP 서버는 다른 곳에서 실행되며 Streamable HTTP로 URL에 접속합니다. 고르는 방법을 정리합니다.
작성자 Sume