HMAC 생성기

메시지와 비밀키를 입력하면 HMAC 값을 16진수로 실시간 계산합니다.

메시지와 비밀키는 UTF-8 바이트 기준으로 계산하며, 결과는 16진수 소문자로 표시됩니다.
비밀키를 비우면 빈 키로 HMAC을 계산합니다.

HMAC 생성기 사용법

위 입력창에 메시지와 비밀키를 입력하고 원하는 해시 알고리즘(SHA-1, SHA-256, SHA-384, SHA-512)을 고르면, HMAC 값이 16진수 소문자로 실시간 계산됩니다. "복사" 버튼으로 결과를 클립보드에 담을 수 있습니다. API 요청 서명 검증, 웹훅(Webhook) 페이로드 검증, 토큰 무결성 확인 등에 활용할 수 있습니다.

HMAC이란?

HMAC(Hash-based Message Authentication Code)은 해시 함수와 비밀키를 결합해 만드는 메시지 인증 코드입니다. 일반 해시는 메시지만으로 값을 만들지만, HMAC은 비밀키를 함께 섞어 계산하므로 같은 키를 가진 쪽만 동일한 값을 재현할 수 있습니다. 덕분에 메시지가 도중에 변조되지 않았다는 무결성과 정당한 발신자가 보냈다는 인증을 동시에 보장합니다. GitHub·Stripe 등 많은 서비스가 웹훅 서명에 HMAC-SHA256을 사용합니다.

키 인코딩과 출력 형식

같은 메시지와 같은 키를 넣어도 키를 어떤 형식으로 해석하느냐에 따라 결과가 달라집니다. 그래서 이 도구는 키 인코딩을 세 가지로 나눠 두었습니다.

  • UTF-8 (텍스트) — 입력한 글자를 그대로 바이트로 사용합니다. 대부분의 웹훅 서명이 이 방식입니다.
  • Hex — 16진수 문자열을 바이트로 해석합니다. 공백은 무시하며 자릿수가 홀수이거나 16진수가 아닌 문자가 있으면 계산에 실패합니다.
  • Base64 — Base64 문자열을 바이트로 해석합니다. URL 안전 표기의 하이픈과 밑줄도 알아서 표준 문자로 바꿔 처리합니다.

출력 형식은 Hex(16진수 소문자)와 Base64 중에서 고를 수 있습니다. 알고리즘은 SHA-1, SHA-256, SHA-384, SHA-512를 지원하며 결과 길이는 각각 40자, 64자, 96자, 128자(16진수 기준)입니다. 선택한 알고리즘과 인코딩 설정은 다음 방문 때도 유지되지만, 메시지와 비밀키는 저장하지 않아 새로고침하면 비워집니다.

실무 활용 예시

  • 웹훅 서명 검증 — 깃허브는 요청 본문 전체에 HMAC-SHA256을 적용한 16진수 값을 서명 헤더로 보냅니다. 같은 비밀키로 다시 계산해 값이 같은지 비교하면 위조된 요청을 걸러낼 수 있습니다.
  • API 요청 서명 — 메서드·경로·타임스탬프·본문을 정해진 순서로 이어 붙인 문자열에 HMAC을 적용해 보내는 방식이 많습니다. 타임스탬프를 함께 서명하면 같은 요청을 다시 보내는 재전송 공격을 막을 수 있습니다.
  • 결제·알림 콜백 검증 — 외부 서비스가 보내는 콜백이 정말 그 서비스에서 온 것인지 확인할 때 씁니다.
  • 디버깅 — 서버가 만든 서명과 이 도구의 결과를 나란히 놓고 비교하면 어느 단계에서 어긋났는지 빠르게 찾을 수 있습니다.

자주 하는 실수와 주의점

  • 서명 대상은 받은 원문 그대로여야 합니다. JSON을 파싱했다가 다시 문자열로 만들면 공백이나 키 순서가 달라져 값이 어긋납니다.
  • 메시지 끝의 줄바꿈이나 공백 하나로도 결과가 완전히 달라집니다. 붙여넣을 때 눈에 보이지 않는 문자가 섞이지 않았는지 확인하세요.
  • 키를 텍스트로 해석해야 하는데 Hex나 Base64로 두면 전혀 다른 값이 나옵니다. 문서에 적힌 키 형식을 먼저 확인하세요.
  • 서명을 비교할 때는 일반 문자열 비교 대신 언어별 타이밍 안전 비교 함수를 쓰는 편이 안전합니다.
  • HMAC은 되돌릴 수 없습니다. 암호화가 아니므로 값에서 원본 메시지나 키를 복원할 수 없습니다.
  • 새 설계에는 SHA-256 이상을 권장합니다. SHA-1은 기존 시스템 호환이 필요할 때만 선택하세요.

자주 묻는 질문

메시지와 비밀키가 서버로 전송되나요?

아니요. 모든 HMAC 계산은 브라우저의 Web Crypto API로 사용자 기기 안에서만 이루어지며, 입력한 메시지와 비밀키는 어떤 서버로도 전송·저장되지 않습니다.

HMAC과 일반 해시의 차이는 무엇인가요?

일반 해시는 메시지만으로 값을 만들어 누구나 같은 값을 만들 수 있습니다. HMAC은 비밀키를 함께 사용하므로 키를 아는 쪽만 동일한 값을 만들 수 있어, 메시지가 변조되지 않았고 정당한 발신자가 보냈는지를 함께 검증할 수 있습니다.

같은 입력인데 다른 사이트와 결과가 다릅니다.

먼저 키 인코딩을 확인하세요. 같은 키라도 UTF-8 텍스트로 보느냐 Hex나 Base64로 보느냐에 따라 값이 완전히 달라집니다. 출력 형식(Hex 또는 Base64)과 메시지 끝의 줄바꿈·공백도 함께 확인해 보세요.

어떤 알고리즘을 골라야 하나요?

대부분의 경우 HMAC-SHA256이 표준이며 보안과 호환성의 균형이 좋습니다. 더 긴 다이제스트가 필요하면 SHA-384·SHA-512를, 레거시 시스템 호환이 필요할 때만 SHA-1을 사용하세요. SHA-1 자체의 충돌 약점은 HMAC 구조에서 영향이 작지만 신규 설계에는 SHA-256 이상을 권장합니다.

HMAC 값을 다시 원문으로 되돌릴 수 있나요?

없습니다. HMAC은 암호화가 아니라 단방향 인증 코드이므로 결과에서 메시지나 비밀키를 복원할 수 없습니다. 검증할 때는 같은 키로 다시 계산해 값이 일치하는지 비교합니다.

웹훅 서명은 어떻게 검증하나요?

서비스가 보낸 요청 본문을 파싱하지 말고 받은 원문 그대로 메시지 칸에 넣고, 발급받은 비밀키와 지정된 알고리즘으로 값을 계산해 서명 헤더와 비교하세요. 본문을 다시 직렬화하면 공백이나 키 순서가 달라져 값이 어긋납니다.

비밀키를 비워 두면 어떻게 되나요?

길이가 0인 키로 HMAC을 계산합니다. 계산 자체는 정상적으로 되지만 누구나 같은 값을 만들 수 있으므로 인증 용도로는 의미가 없습니다. 실제로는 충분히 길고 무작위한 키를 사용하세요.