개발자라면 알아야 할 암호학

암호화는 라이브러리가 알아서 해주는데, 개발자가 암호학까지 알아야 할까요? 보안 기능을 직접 구현하는 일은 피해야 하지만, 어떤 알고리즘과 설정을 사용할지는 결국 개발자가 결정해야 합니다. 비밀번호를 저장할 때 SHA-256과 bcrypt 중 무엇을 선택할지, AES는 어떤 모드로 사용할지, JWT의 서명 알고리즘은 어떻게 고를지처럼 실무에서는 암호학 지식이 필요한 순간을 자주 마주하게 됩니다.

이번 에피소드에서는 먼저 링크드인과 어도비의 대규모 정보 유출, OpenSSL의 Heartbleed 버그를 살펴봅니다. 잘 알려진 회사와 널리 쓰이는 라이브러리도 기본적인 원칙을 지키지 않거나 취약점을 제때 발견하지 못하면 큰 사고를 겪을 수 있습니다. 이 사례들을 통해 라이브러리를 사용한다는 사실만으로 보안이 저절로 보장되는 것은 아니며, 개발자가 도구의 용도와 한계를 이해해야 하는 이유를 이야기합니다.

이어서 암호학의 큰 그림을 단방향 암호화와 양방향 암호화로 나누어 정리합니다. 원래 값으로 되돌릴 수 없는 해시는 어떤 특징을 가지는지, MD5의 충돌 문제는 무엇인지, SHA-256 같은 빠른 해시 함수가 파일의 무결성을 확인할 때는 유용하지만 비밀번호 저장에는 적합하지 않은 이유를 알아봅니다. 레인보우 테이블 공격을 막는 솔트의 역할과, 의도적으로 느리게 설계된 bcrypt와 Argon2id가 비밀번호를 더 안전하게 지켜주는 원리도 함께 살펴봅니다.

복호화가 가능한 양방향 암호화에서는 하나의 키를 사용하는 대칭키와 공개키·개인키 한 쌍을 사용하는 비대칭키의 차이를 다룹니다. AES와 RSA는 각각 어떤 장단점이 있는지, AES의 ECB·CBC·GCM 모드는 무엇이 다른지, 빠르지만 키를 안전하게 전달하기 어려운 대칭키의 문제를 비대칭키가 어떻게 보완하는지 이야기합니다.

마지막으로 우리가 매일 사용하는 HTTPS 안에서 여러 암호화 기술이 어떻게 맞물려 작동하는지 따라가 봅니다. 브라우저가 서버의 인증서를 확인하고, 안전하게 키를 교환한 뒤, 대칭키로 실제 데이터를 주고받기까지의 흐름을 살펴보며 TLS가 제공하는 암호화·인증·무결성을 이해해 봅니다.

암호화 알고리즘을 직접 구현하면 왜 위험한지, 비밀키를 코드에 하드코딩하거나 저장소에 올리면 어떤 문제가 생기는지, 오래되거나 약한 알고리즘을 선택했을 때 어떤 위험이 따르는지도 짚어봅니다. 암호학이 보안 전문가만의 영역처럼 멀게 느껴졌다면, 이번 에피소드와 함께 개발자가 꼭 알아야 할 만큼의 큰 그림부터 잡아보세요.

📚 함께 읽으면 좋은 글

• 암호학적 해시: https://daleseo.com/cryptographic-hash/
• 대칭키 암호화: https://daleseo.com/symmetric-encryption/
• 비대칭키 암호화: https://daleseo.com/asymmetric-encryption/
• TLS 핸드셰이크: https://daleseo.com/tls/
• HTTPS란 무엇인가: https://daleseo.com/https/