본문 바로가기
IT/JAVA&SpringBoot

Java 암호화 핵심 요약: AES, RSA, SHA, BCrypt, JWT 완벽 비교 분석

by twofootdog 2026. 3. 27.
반응형

Java 기반의 백엔드 시스템을 개발하거나 보안 아키텍처를 설계하다 보면 반드시 마주치는 개념이 있습니다. 바로 데이터 암호화입니다.

로그인 비밀번호를 데이터베이스에 저장할 때, 외부 API와 중요 데이터를 주고받을 때, 혹은 JWT 기반의 사용자 인증을 구현할 때 우리는 각기 다른 보안 알고리즘을 선택해야 합니다. 하지만 AES, RSA, SHA, BCrypt 등 비슷한 듯 다른 암호화 용어들 때문에 "어떤 상황에서 무엇을 써야 할지" 혼란스러울 때가 많습니다.

패스워드를 RSA로 암호화하거나, 대용량 파일을 처리할 때 속도가 느린 비대칭키를 잘못 사용하는 등의 실수는 실무에서 치명적인 성능 저하나 보안 취약점으로 이어질 수 있습니다.

이번 포스팅에서는 Java 환경을 기준으로 가장 널리 사용되는 4가지 핵심 암호화 방식(AES, RSA, SHA, BCrypt)의 차이점을 '양방향'과 '단방향', 그리고 '대칭키'와 '비대칭키'라는 명확한 기준을 통해 알기 쉽게 완벽히 정리해 보겠습니다. 

그리고  위 암호화 방식에 추가로 JWT(JSON Web Token)가 이 암호화 방식들과 어떻게 연결되는지까지 정리해 보았습니다.

 

 


1. AES (양방향 대칭키 암호화)

데이터를 암호화하고 복호화할 때 동일한 하나의 비밀키를 사용하는 방식

  • 특징: 처리 속도가 매우 빠르고 대용량 데이터를 암호화하는 데 적합. 자물쇠를 잠그는 열쇠와 푸는 열쇠가 같기 때문에, 이 키가 외부에 유출되지 않도록 서버 깊숙한 곳에 안전하게 보관 필요(소스 파일이 아닌 서버에 별도 보관 or KMS 암호화 or .env 파일로 보관 등)
  • 최신 권장 사항: 과거에는 AES/CBC/PKCS5Padding을 많이 사용했지만, JDK 25를 비롯한 최신 환경에서는 데이터의 암호화뿐만 아니라 데이터가 변조되지 않았음(무결성)까지 동시에 검증해 주는 AES/GCM/NoPadding (Galois/Counter Mode) 사용이 강력한 표준임. 키 길이는 AES-256이 기본
  • 사용 예: 데이터베이스에 저장되는 개인정보(전화번호, 이메일, 주소 등), 대용량 파일 암호화.

 


2. RSA (양방향 비대칭키 암호화)

공개키(Public Key)개인키(Private Key)라는 한 쌍의 키를 사용. 목적에 따라 암호화에 사용하는 키가 달라지는 것이 가장 큰 특징.  AES보다 수학적 연산이 복잡해 속도가 훨씬 느림

 

  • 목적 A: 데이터 보호 (기밀성)
    • 방식: 누구나 알 수 있는 공개키로 암호화해서 보내면, 오직 개인키를 가진 서버만 복호화해서 읽을 수 있음.
    • 사용 예: 클라이언트가 서버로 대칭키(AES 키)를 안전하게 넘겨줄 때(Key Exchange).
  • 목적 B: 신원 증명 (전자서명 / 인증)
    • 방식: 서버가 자신만 가진 개인키로 암호화(서명)해서 보내면, 누구나 공개키로 복호화(검증)해 볼 수 있음. 검증에 성공하면 "이 데이터는 무조건 그 서버가 만든 게 맞다"라고 확신할 수 있음.
    • 사용 예: 공인인증서, JWT의 토큰 서명 생성 및 검증.

 

  • 최신 권장 사항: 속도 문제 때문에 RSA로 대용량 데이터를 직접 암호화하지 않고 대신 'AES 키'를 안전하게 전달(Key Exchange)할 때 사용하거나, 데이터의 출처를 증명하는 전자서명(Digital Signature)에 주로 사용. JDK 25에서는 보안 강도를 위해 최소 2048-bit 이상(권장 3072-bit 또는 4096-bit)의 키 길이를 사용해야 함
  • 사용 예: HTTPS/TLS 통신 접속 초기 단계(인증서 교환), 공인인증서(전자서명), JWT의 서명 생성/검증.
  • 요약
    목적 암호화에 쓰는 키 복호화에 쓰는 키 비고
    데이터 보호 (기밀성) 공개키 (Public Key) 개인키 (Private Key) 나만 읽을 수 있게 남들이 잠가서 보냄
    신원 증명 (전자서명) 개인키 (Private Key) 공개키 (Public Key) 내가 썼음을 증명하기 위해 내가 잠가서 보냄

3. SHA (단방향 해시 함수)

데이터를 암호화한다기보다는, 원본 데이터의 '고유한 지문(Hash)'을 만들어내는 방식. 복호화가 절대 불가능함

  • 특징: 원본 데이터가 한 글자라도 달라지면 완전히 다른 결과값이 나옴. 원본을 알 수는 없지만, 입력된 값이 원본과 일치하는지 비교할 수 있음.
  • 최신 권장 사항: 취약점이 발견된 MD5나 SHA-1은 완전히 퇴출. 최소 SHA-256을 사용해야 하며, 보안이 더 중요한 경우 SHA-512 또는 최신 해시 표준인 SHA-3 (SHA3-256 등)를 MessageDigest 클래스를 통해 사용하는 것이 좋음(참고로 단순 사용자 비밀번호 저장을 위해서는 SHA 단독 사용보다 BCryptArgon2 같은 전용 알고리즘 사용이 권장됨)
  • 사용 예: 파일 위변조(무결성) 검증, 블록체인, 단순 비밀번호 단방향 저장.

 


4. BCrypt (비밀번호 전용 단방향 해시)

SHA와 같은 단방향 해시지만, 오직 '비밀번호를 안전하게 저장하기 위해' 해커의 공격을 방어하도록 특화된 알고리즘임

  • 특징:
    • 자동 Salt 부여: 똑같은 비밀번호라도 저장될 때마다 임의의 문자열(Salt)을 섞어 매번 다른 결과값을 만듦
    • 키 스트레칭(의도적 지연): 해시 연산을 수천 번 반복하게 만들어 속도를 일부러 늦추기 때문에 일반 사용자의 로그인(1회)에는 지장이 없지만, 초당 수억 번씩 암호를 대입해 보는 해커의 공격은 완벽하게 차단할 수 있음.
  • 사용 예: 데이터베이스의 사용자 비밀번호 안전 저장 (Spring Security의 BCryptPasswordEncoder 등 활용)

 


5. JWT (JSON Web Token)

JWT 자체는 '암호화 방식'이 아님. JWT는 정보를 JSON 형태로 안전하게 전달하기 위한 '웹 표준 포맷'이며, 기본적으로 그 안의 내용(Payload)은 누구나 읽을 수 있게 단순 인코딩(Base64Url) 되어 있음.

다만, 이 정보가 "서버가 발급한 진짜 토큰이 맞는지", "중간에 누군가 내용을 조작하지 않았는지" 확인하기 위해 앞서 배운 암호화 기술들을 섞어서 서명(Signature)을 추가 함.

JWT는 서명 방식에 따라 크게 두 가지로 나뉨

  1. HS256 (HMAC + SHA-256) 방식 -> 대칭키(비슷한 개념) 사용:
    • 서버가 가진 단 하나의 비밀키를 사용하여 서명을 만들고 검증
    • 성능이 빠르고 구현이 쉽지만, 여러 서버(MSA 환경)에서 서명을 검증하려면 모든 서버가 같은 비밀키를 공유해야 한다는 위험성이 있음.
  2. RS256 (RSA + SHA-256) 방식 -> 비대칭키(RSA) 사용:
    • 인증 서버는 개인키(Private Key)로 서명을 생성
    • 다른 리소스 서버들이나 클라이언트는 공개된 공개키(Public Key)를 이용해 "이 토큰이 진짜 인증 서버에서 만든 게 맞는지" 서명만 검증합니다.
    • 키를 안전하게 분리할 수 있어 현대적인 MSA(마이크로서비스 아키텍처)나 대규모 시스템에서 가장 널리 쓰이는 방식입니다.

 


6. 요약 비교

구분 목적 핵심 원리 및 키(Key) 사용 주로 쓰이는 곳
AES 데이터 기밀성 유지 대칭키: 1개의 비밀키로 잠그고 풂 개인정보 보관, 내부 데이터 통신
RSA 신원 증명 및 키 교환 비대칭키: 개인키(서명/복호화) + 공개키(검증/암호화) HTTPS 통신, JWT (RS256) 서명
SHA 데이터 무결성 검증 단방향 해시: 키 없음, 매우 빠른 지문 생성 파일 위변조 검증
BCrypt 비밀번호 보호 단방향 해시: 키 없음, Salt + 의도적 속도 지연 사용자 비밀번호 DB 저장
JWT 인증 정보 전달 토큰 포맷: HS256(비밀키) 또는 RS256(비대칭키)로 서명 웹/앱 로그인 인증 및 권한 부여

 


7. 참고자료

 

 

 

 

반응형

댓글