RSA vs ECDSA, 무엇을 선택해야 할까? (JWT 실무 가이드)

보안 기술을 적용할 때, 특히 비대칭키를 선택해야 할 때마다 매번 고민이 된다. 나중에 다시 찾아볼 수 있도록, RSA와 ECDSA의 실무적 차이와 선택 기준을 정리해둔다.

복잡한 수학적 이론보다는, 실제 개발 환경에서 "어떤 상황에서 무엇을 우선적으로 고려해야 하는지"에 집중하여 기록한다.

1. 비대칭키의 기본 개념

대칭키는 열쇠 하나로 잠그고 열고 다 한다. (그래서 키가 유출되면 매우 위험하다) 비대칭키는 공개키(자물쇠)랑 비밀키(열쇠)가 따로 있다.

• 공개키: 남들한테 다 뿌려도 된다. "이걸로 잠가서 나한테 보내" 용도.
• 비밀키: 나만 갖고 있어야 한다. "이걸로 내가 열어볼게" 용도.

근데 반대로도 된다. 비밀키로 잠그고(서명), 공개키로 여는(검증) 방식. 이게 바로 전자서명이다.

2. ECDSA: 암호화가 아닌 서명 알고리즘

여기서 가장 많이 하는 오해가 있다. "ECDSA가 RSA보다 최신 기술이니 암호화 성능도 더 좋지 않을까?"라고 생각하기 쉽다.

하지만 ECDSA는 암호화 알고리즘이 아니다. 이름을 자세히 보면 Elliptic Curve Digital Signature Algorithm, 즉 "서명(Signature)" 알고리즘임을 알 수 있다.

데이터 암호화가 필요하다면 ECIES(Elliptic Curve Integrated Encryption Scheme) 등을 사용해야 하며, ECDSA 키로 암호화를 시도하면 정상적으로 동작하지 않는다.

정리:

• 키 교환이 필요하다면? → ECDH
• 서명(로그인 토큰)이 필요하다면? → ECDSA
• 데이터 암호화가 필요하다면? → AES (키 교환은 RSA나 ECDH로)

3. RSA와 ECDSA 비교

결론부터 말하자면, 새로운 프로젝트라면 ECDSA를 쓰는 것이 좋다.

RSA는 키가 너무 커서 JWT 토큰에 넣으면 토큰 길이가 매우 길어진다. 모바일 게임 환경에서는 패킷 사이즈 최적화가 중요하다. 보안 강도는 유지하면서 키 크기가 훨씬 작은 ECDSA가 효율적이다.

4. JWT의 본질: 서명된 데이터

다시 강조하지만 JWT는 자체적으로 암호화 기능을 제공하지 않는다. "서명된 증명서"에 가깝다. Base64로 인코딩된 거라 eyJ... 이거 복사해서 디코딩 사이트 넣으면 다 보인다.

# 터미널에 쳐봐라. 다 나옴.
echo "eyJ1c2VySWQiOjEyM30" | base64 -d
# 결과: {"userId":123}

따라서 JWT 페이로드에는 비밀번호나 주민등록번호 같은 민감한 개인정보를 포함해서는 안 된다. "아무도 못 보겠지?"라고 생각하는 순간, 심각한 개인정보 유출 사고로 이어질 수 있다.

5. JWT의 보안 범위

보안 범위를 명확히 이해해야 취약점을 예방할 수 있다.

수호 가능한 영역 (무결성)

• 내용물을 누가 몰래 고쳤는지 (변조)
• 이게 진짜 우리 서버가 발급한 건지 (출처)

수호 불가능한 영역 (기밀성)

• 남들이 내용 훔쳐보는 것 (다 보임)
• 토큰 자체를 훔쳐가는 것 (탈취)

토큰이 탈취되면 서버 입장에서는 이를 막을 방법이 마땅치 않다. 해커가 해당 토큰으로 정상적인 유저 행세를 할 경우, 서버는 이를 신뢰할 수밖에 없기 때문이다. 그래서 HTTPS가 필수적이며, 만료 시간(Expire Time)을 짧게 설정하여 피해를 최소화해야 한다.

6. 실무에서 저지르는 실수 TOP 3

1. alg: none 공격

헤더에 {"alg": "none"} 이라고 보내면 서명 검증을 건너뛰는 취약한 설정이 있을 수 있다. 서버 코드에서 "ES256 알고리즘만 허용"하도록 명시적으로 설정하는 것이 좋다.

2. 취약한 비밀키 사용

HS256(대칭키) 사용 시 비밀키를 secret123 같이 단순하게 설정하면 무차별 대입 공격에 취약해진다. 최소 32바이트 이상의 랜덤 문자열을 생성하여 사용하는 것이 안전하다.

3. 만료 시간을 설정하지 않음

exp 클레임 안 넣으면 그 토큰은 영구적으로 유효한 토큰이 된다. 해커가 취득하게 되면 서비스 종료 시까지 악용될 위험이 있어, 만료 시간을 설정하는 것이 중요하다.

나중에 설계 시 참고할 수 있도록 상황별 기준을 요약해둔다.

1. 신규 프로젝트 → ECDSA(ES256)
2. 레거시 호환성 필요 → RSA(RS256)
3. 내부 서버 간 통신 → HMAC(HS256)

마지막으로, JWT에는 민감한 정보를 담지 말고, 반드시 HTTPS를 사용하여 통신 구간을 보호해야 한다. 이것은 보안을 위한 최소한의 안전장치다.

보안은 "강력한 알고리즘" 하나로 해결되는 것이 아니라, "빈틈없는 설계"가 핵심임을 기억하자.