AES-256 암호화 vs SHA-256 해시 차이점과 복호화 원리

2026년 7월 23일

텍스트 암호화 도구에서 비밀번호와 원문을 입력하고 AES-GCM 256비트로 암호화된 Base64 결과 화면

어떤 문자열을 해시(Hash)로 바꾸면 그 결과에서 원문으로 다시 돌아가는 길은 수학적으로 영원히 닫힙니다. 해시는 일종의 '디지털 지문'이라서, "입력한 값과 저장된 값이 일치하는가"만 대조할 수 있을 뿐 원문을 복원할 수 없습니다. 반면 암호화(Encryption)는 비밀번호(Key)만 알고 있으면 언제든 암호문을 원문 그대로 되돌릴 수 있는 양방향 변환입니다.

이 둘의 차이를 명확히 알지 못하면 "데이터를 암호화해서 저장해 뒀는데 나중에 복호화가 안 된다"거나, "비밀번호를 복호화 가능한 상태로 저장해 유출 사고를 겪는" 치명적인 보안 사고가 발생합니다.

핵심 요약 ① 해시(SHA-256 등)는 단방향 요약 함수로 복호화가 절대 불가능하며, 비밀번호 일치 여부 검증용입니다. ② 암호화(AES-256-GCM 등)는 비밀번호와 키를 이용해 암호문을 만들고 나중에 원문으로 되돌리는 양방향 보안 기술입니다. ③ 동일한 문장과 비밀번호로 암호화해도 매번 결과 문자열이 다른 이유는 무작위 초기화 벡터(IV)와 솔트(Salt)가 매번 새로 생성되기 때문입니다.

해시와 암호화는 방향부터 다릅니다

해시 함수는 입력 데이터의 길이에 상관없이 항상 고정된 길이(SHA-256 기준 64자리 16진수)의 해시값을 출력합니다. 이 해시값으로부터 원본 텍스트를 역산하는 수식은 존재하지 않습니다. 그래서 데이터베이스에 회원 비밀번호를 저장하거나 파일의 위변조 여부를 체크할 때 사용합니다.

반면 암호화는 원본 데이터를 특정한 암호키(Key)와 수학적 치환·치밀화 알고리즘으로 뒤섞어 놓은 상태입니다. 올바른 키를 입력하면 암호화의 역과정을 거쳐 100% 원본 텍스트가 복원됩니다.

따라서 상대방에게 비밀 텍스트를 전달하고 상대방이 이를 읽어야 하는 상황이라면 무조건 **대칭키 암호화(AES)**를 사용해야 합니다.

"AES-GCM 256비트"가 실제로 뜻하는 것

AES (Advanced Encryption Standard): 미국 국립표준기술원(NIST)이 제정한 전 세계 표준 대칭키 블록 암호화 알고리즘입니다.
256비트 키 길이: 암호화에 쓰이는 키의 길이가 256비트(2^256가지 경우의 수)라는 뜻으로, 현재 인류의 모든 슈퍼컴퓨터를 총동원해도 무차별 대입(Brute-force)으로 키를 푸는 것은 불가능합니다.
GCM (Galois/Counter Mode): 기밀성(Encryption)뿐만 아니라 데이터가 중간에 1바이트라도 위변조되지 않았는지 검증하는 무결성 인증 태그(Auth Tag)를 동시에 생성하는 최고 등급의 운영 모드입니다.

텍스트 암호화(AES)

무료 · 100% 브라우저 로컬 암호화 · 서버 전송 없는 완벽한 보안 AES-256-GCM

📖 개발자와 실무자가 겪는 현실적인 암호화 참사 사연

사연 1: 고객 SMS 인증번호를 해시(SHA-256)로 저장했다가 문자 발송에 실패한 신입 개발자

이커머스 백엔드 개발자 A씨는 보안이 중요하다고 하여 고객에게 발송할 6자리 임시 비밀번호를 DB에 SHA-256 해시로 변환하여 저장했습니다. 그러나 문자 발송 모듈에서 "저장된 해시값에서 원래 6자리 숫자를 복호화할 수 없다"는 사실을 뒤늦게 깨닫고 모든 가입 고객의 인증이 마비되는 사태를 겪었습니다. 해시와 암호화의 개념을 혼동하여 발생한 대표적인 사고입니다.

사연 2: 사내 서버 접속 계정을 슬랙/카카오톡으로 평문 공유했다가 보안 감사에 걸린 팀장

인프라 팀장 B씨는 급한 마음에 AWS 루트 비밀번호와 DB 접속 정보를 메신저로 팀원에게 전송했습니다. 사내 보안 정기 감사에서 "기밀 정보가 메신저 서버에 평문으로 영구 보관되어 있다"며 엄중 경고를 받았습니다. 이후 클라이언트 사이드 AES 암호화 도구로 암호화한 뒤 암호문만 메신저로 보내고, 비밀번호는 구두로 전달하는 보안 프로세스를 정착시켰습니다.

사연 3: ECB 모드로 암호화했다가 암호문의 패턴이 그대로 노출된 참사

보안 지식이 부족했던 C씨는 AES-ECB 모드로 이미지를 암호화했습니다. 하지만 ECB 모드는 동일한 평문 블록이 항상 동일한 암호문 블록으로 변환되므로, 암호화된 이미지에서도 원본 이미지의 윤곽선(유명한 ECB 펭귄 현상)이 육안으로 선명히 드러나 기밀이 유출되었습니다. 무작위 IV를 적용하는 CBC나 GCM 모드의 필요성을 뼈저리게 체감한 사례입니다.

🔬 핵심 기술 메커니즘 — PBKDF2 키 파생과 AES-GCM 파이프라인

웹 브라우저의 Web Crypto API가 사용자의 비밀번호로부터 256비트 키를 만들고 데이터를 암호화하는 수학적 단계를 분석합니다.

1. PBKDF2 (Password-Based Key Derivation Function 2)

사람이 입력하는 비밀번호(예: 'MySecretPass123!')는 암호학적으로 충분한 엔트로피를 갖지 못합니다:

솔트 (Salt, 16바이트): 암호화할 때마다 128비트 암호학적 난수(CSPRNG)를 새로 생성합니다.
반복 해싱 (Iteration Count, 100,000회 이상): 솔트와 비밀번호를 SHA-256으로 10만 번 반복 해싱하여 레인보우 테이블 공격과 무차별 대입을 무력화하고 256비트 마스터 키를 도출합니다.

2. AES-GCM 암호화 및 인증 태그 생성

초기화 벡터 (IV / Nonce, 12바이트): 매 암호화마다 고유한 96비트 난수를 생성하여 같은 원문이라도 암호문이 매번 100% 다르게 나옵니다.
갈루아 필드(Galois Field) 기반 GHASH: 데이터 암호화와 동시에 128비트 인증 태그(Authentication Tag)를 계산하여 암호문 변조 시 복호화 단계에서 즉각 에러(Ciphertext Tampered)를 발생시킵니다.

📊 해시(Hash) vs 암호화(Encryption) vs 인코딩(Encoding) 비교

비교 항목	단방향 해시 (Hash)	대칭키 암호화 (AES)	인코딩 (Base64/URL)
변환 방향	단방향 (복호화 불가)	양방향 (복호화 가능)	양방향 (누구나 복원 가능)
비밀번호/키 필요 여부	❌ 불필요	⭕ 비밀키 필수	❌ 불필요
주요 목적	데이터 무결성 검증, 비밀번호 저장	민감한 기밀 정보의 보안 전송·저장	시스템 간 데이터 호환성 및 전송
대표 알고리즘	SHA-256, SHA-512, bcrypt, Argon2	AES-256-GCM, AES-CBC, ChaCha20	Base64, Hex, URL Encoding
출력 예시	고정 길이 64자 (SHA-256)	가변 길이 암호문 + IV + Salt	원문 대비 33% 증가한 문자열

⚠️ 암호화 도구 사용 시 흔히 하는 5가지 실수

비밀번호 분실: 복호화 키는 서버 어디에도 저장되지 않으므로 비밀번호를 잊어버리면 그 누구도 데이터를 되살릴 수 없습니다.
Base64 인코딩을 암호화로 착각: Base64는 단순 문자열 포맷팅일 뿐이며 복호화 툴에 넣으면 0.1초 만에 풀리는 평문입니다.
취약한 짧은 비밀번호 사용: 1234, password 같은 쉬운 단어는 사전 공격(Dictionary Attack)에 즉시 뚫립니다.
고정된 IV(초기화 벡터) 재사용: GCM 모드에서 동일한 키와 IV를 재사용하면 암호문 간의 XOR 연산으로 원문이 노출됩니다.
서버로 평문 전송하는 불안한 사이트 이용: 원문을 웹 서버로 전송해 암호화해 주는 사이트는 중간 탈취 및 로그 기록 위험이 큽니다.

💡 안전한 텍스트 암호화 5단계 실전 워크플로우

1단계 (원문 텍스트 및 비밀번호 입력): 암호화할 기밀 메모와 이를 잠글 강력한 비밀번호(영문+숫자+특수문자 10자 이상)를 입력합니다.
2단계 (실시간 브라우저 로컬 암호화): Web Crypto API가 PBKDF2와 AES-256-GCM을 로컬 메모리에서 즉시 실행합니다.
3단계 (암호문 문자열 복사): Salt, IV, 암호문이 안전하게 패키징된 Base64 암호문을 복사합니다.
4단계 (메신저나 이메일로 암호문 전송): 카카오톡, 슬랙, 이메일에 암호문을 붙여넣어 수신자에게 전송합니다.
5단계 (비밀번호 별도 채널 공유 및 복호화): 수신자에게 비밀번호를 다른 채널(통화, 대면 등)로 알려주고 복호화 탭에서 원문을 열람합니다.

🔍 보안 엔지니어가 공개하는 비밀 팁 7선

카카오톡/슬랙 2채널 전송 원칙: 암호문은 메신저로 보내더라도 비밀번호는 전화 통화나 문자로 따로 전달해야 완벽한 기밀성이 유지됩니다.
클라이언트 사이드 Zero-Knowledge 검증: F12 개발자 도구의 Network 탭을 열어 텍스트가 외부 서버로 한 바이트도 나가지 않는지 확인합니다.
비밀번호 관리자(1Password, Bitwarden) 활용: 암호화에 사용할 비밀번호는 난수 생성기로 16자 이상 생성하여 안전하게 보관합니다.
복호화 실패 에러 시 공백 체크: 암호문을 복사할 때 앞뒤에 의도치 않은 공백이나 줄바꿈이 들어갔는지 점검합니다.
개인정보 메모(주민번호, 계좌번호) 영구 보관: 클라우드 메모장에 올리기 전에 AES-256으로 암호화하여 저장하면 해킹당해도 안전합니다.
SHA-256 해시 비교로 파일 변조 여부 체크: 다운로드한 설치 파일의 SHA-256 해시값을 공식 웹사이트 해시와 대조하여 악성코드 감염을 예방합니다.
비밀번호 해싱에는 bcrypt/Argon2 권장: 웹 서버 개발 시 회원 비밀번호 저장에는 일반 SHA-256보다 연산 부하가 큰 bcrypt나 Argon2id를 적용해야 안전합니다.

🎯 최종 결정 트리: 어떤 보안 기법을 적용해야 할까?

시나리오 A (메신저로 보안 계정/비밀번호를 상대방에게 보내야 함) ➔ AES-256-GCM 텍스트 암호화
시나리오 B (웹사이트 회원가입 시 사용자 비밀번호 DB 저장) ➔ Argon2id 또는 bcrypt 단방향 해싱 (Salt 필수)
시나리오 C (다운로드한 파일이 깨지거나 위변조되지 않았는지 검증) ➔ SHA-256 / MD5 체크섬 해시 대조
시나리오 D (바이너리 이미지/PDF 파일을 JSON API로 전송) ➔ Base64 인코딩 (보안 목적 아님)

📑 암호학 & 보안 핵심 용어 치트시트

AES-256-GCM: 전 세계 정부 및 금융권 표준 256비트 대칭키 암호화 및 갈루아 무결성 인증 모드.
SHA-256 (Secure Hash Algorithm 256): 어떤 길이의 입력도 256비트(32바이트) 지문으로 요약하는 단방향 해시 함수.
Salt (솔트): 동일한 비밀번호도 서로 다른 해시/암호문이 나오도록 덧붙이는 무작위 난수 데이터.
IV (Initialization Vector, 초기화 벡터): 블록 암호화 시 첫 번째 블록에 혼합되는 고유한 1회용 난수.
Web Crypto API: 최신 웹 브라우저가 기본 내장한 고성능 하드웨어 가속 암호화 표준 인터페이스.

자주 묻는 질문

암호화한 비밀번호를 잊어버렸는데 복구해 주실 수 있나요?

불가능합니다. 본 도구는 서버에 어떤 데이터나 비밀번호도 보관하지 않으며, AES-256 암호화의 수학적 특성상 올바른 비밀번호 없이는 미국 국방부나 슈퍼컴퓨터로도 복호화가 불가능합니다.

같은 글과 같은 비밀번호로 암호화했는데 왜 결과가 매번 달라지나요?

정상적인 보안 동작입니다. 암호화할 때마다 브라우저가 매번 새로운 무작위 솔트(Salt)와 초기화 벡터(IV)를 생성하여 섞어 넣기 때문에 암호문이 매번 다르게 생성되며, 이를 통해 패턴 분석 공격을 원천 차단합니다.

브라우저에서 암호화할 때 회사 기밀이 웹 서버로 전송되나요?

전혀 전송되지 않습니다. 모든 암호화와 복호화 연산은 사용자의 컴퓨터 브라우저 내부 CPU/메모리에서 100% 오프라인 상태로 실행되므로 사내 보안 문서나 개인정보도 안전하게 처리하실 수 있습니다.