HMAC 생성기

이 도구는 무엇인가요?

HMAC은 Hash-based Message Authentication Code의 약자입니다. 비밀 키와 메시지, 그리고 SHA-256 같은 표준 해시 함수를 결합해 고정 길이의 다이제스트를 만듭니다. 같은 키와 메시지를 가진 사람이라면 누구나 정확히 같은 HMAC을 계산할 수 있지만, 키가 없다면 해시 알고리즘을 알고 있더라도 메시지에 대한 유효한 HMAC을 만들어내는 것은 계산적으로 불가능합니다.

이것이 일반 해시와의 핵심 차이입니다: 일반 해시(MD5, SHA-256 등)는 메시지만을 입력으로 받으므로 누구나 계산할 수 있고, 누가 만들었는지에 대해서는 아무것도 증명하지 못합니다. HMAC은 메시지*와* 비밀 키를 함께 받으므로, 유효한 HMAC은 발신자가 그 비밀 키를 가지고 있었음을 증명합니다 — 단순한 무결성 검사가 아니라 인증 메커니즘입니다.

HMAC은 NIST의 FIPS 198-1에서 공식 표준화되었고, 인터넷 프로토콜용으로는 IETF RFC 2104에 정의되어 있습니다. 이 도구는 브라우저 네이티브 Web Crypto API(`crypto.subtle.sign`을 HMAC 알고리즘으로 호출)로 HMAC을 계산하므로, 직접 구현한 자바스크립트 코드가 아니라 RFC 2104를 올바르게 구현한 엔진을 사용합니다.

왜 사용해야 할까요?

• Stripe 웹훅 엔드포인트가 서명 불일치로 요청을 거부했고, 페이로드와 시크릿에서 HMAC-SHA256을 직접 다시 계산해 어디가 틀렸는지 찾아야 합니다.
• 내부 API 연동 문서를 작성 중인데 외부 팀에게 보여줄 정확한 HMAC 예시가 필요하지만, 예시 하나 때문에 백엔드 스크립트를 실행하고 싶지는 않습니다.
• 방금 작성한 Node.js나 Python HMAC 코드가 예상과 다른 결과를 내서, 어디가 버그인지 찾기 위해 다른 구현체의 독립적인 참조값이 필요합니다.
• GitHub 웹훅 연동을 디버깅 중인데, 받은 X-Hub-Signature-256 헤더가 원본 페이로드와 웹훅 시크릿으로 계산한 HMAC과 일치하는지 확인해야 합니다.
• 장애 대응 중 실제 운영 시크릿으로 즉시 HMAC을 생성해야 하는데, 그 시크릿을 어떤 제3자 서버로도 보내고 싶지 않습니다.
• 100% 로컬 처리: 비밀 키와 메시지가 브라우저를 벗어나지 않으므로 실제 비밀 값을 테스트해도 안전합니다.

사용 방법

1. "Secret Key" 필드에 비밀 키를 입력하세요.
2. "Message" 필드에 인증하려는 메시지를 입력하세요.
3. HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, HMAC-SHA512 결과가 즉시 생성됩니다(대상 시스템이 대문자를 기대한다면 "Uppercase output"을 체크하세요).
4. 필요한 HMAC 옆의 "Copy"를 클릭해 복사하세요.

예시

입력

Secret Key: key
Message: The quick brown fox jumps over the lazy dog

결과

HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

이는 공개적으로 알려진 표준 테스트 벡터입니다: 키 "key"와 이 메시지 그대로라면 올바르게 구현된 모든 시스템에서 HMAC-SHA256과 HMAC-SHA1은 항상 이 값을 만들어내므로, 이 도구의 출력을 독립적으로 검증할 수 있습니다.

HMAC vs 일반 해시: 키가 필요한 순간

핵심 질문은 이것입니다: 이 다이제스트를 누가 만들었는지 증명해야 하는가, 아니면 내용이 변경되지 않았음만 확인하면 되는가? 다운로드한 파일이 배포자가 공개한 값과 일치하는지 확인하거나 레코드를 중복 제거하는 것처럼 공개 체크섬으로 충분하다면 일반 해시로 되고, 누구나 키 없이 확인할 수 있습니다. 반면 그 다이제스트가 특정 비밀을 가진 사람만이 만들어낼 수 있음을 증명해야 한다면 — API 호출자를 인증하거나 웹훅 발신자를 신뢰해야 한다면 — HMAC이 필요합니다. 일반 해시는 비밀을 전혀 모르는 공격자에게도 실제 발신자와 동일하게 유효한 다이제스트를 위조할 능력을 주기 때문입니다.

→ 다중 알고리즘 해시 생성기 · JWT 디코더 · MD5 생성기

네 가지 HMAC 알고리즘 비교

네 알고리즘 모두 RFC 2104의 동일한 HMAC 구조를 사용하며, 차이는 기반 해시 함수와 그에 따른 출력 길이뿐입니다.

흔한 활용 사례

• 공유 비밀로 나가는 API 요청에 서명해 서버가 호출자의 신원을 검증할 수 있게 합니다.
• 들어오는 웹훅 페이로드를 검증합니다(Stripe-Signature, GitHub X-Hub-Signature-256 등의 헤더는 모두 HMAC-SHA256을 사용합니다).
• HS256/HS384/HS512로 서명된 JWT의 서명 부분을 생성하고 검증합니다.
• 서버 측 또는 클라이언트 측 HMAC 구현을 배포하기 전에 기대한 출력과 일치하는지 테스트합니다.

HMAC을 직접 구현할 때 흔히 저지르는 실수

"내 HMAC이 안 맞는다"는 문제의 대부분은 알고리즘을 잘못 골라서가 아니라, 계산 전에 키와 메시지를 준비하는 과정의 사소한 디테일에서 비롯됩니다.

• 키가 양쪽에서 동일한 인코딩으로 처리되는지 확인하세요 — 일반 UTF-8 문자열과 디코딩된 hex/base64 문자열은 겉보기엔 비슷해 보여도 완전히 다른 HMAC을 만들어냅니다.
• 웹훅 검증 시에는 항상 JSON 객체로 파싱되기 전의 원본 페이로드(raw body)로 HMAC을 계산하세요 — 많은 백엔드 프레임워크가 요청 본문을 자동으로 파싱하는데, 다시 문자열로 변환한 객체로 계산하면 키 순서나 공백이 발신자가 실제로 보낸 원본 본문과 달라질 수 있습니다.
• 실제 프로덕션 코드에서 HMAC을 검증할 때는 항상 일반 `===` 대신 상수 시간(constant-time) 비교를 사용해 타이밍 공격을 방지하세요 — 이 도구는 디버깅 중 생성 및 육안 비교용일 뿐, 프로덕션 검증 로직을 대체하지 않습니다.

자주 묻는 질문