의사난수와 진짜 난수의 차이란 - 어떻게 구별하는지 정리
· 小村 豪 · 의사난수, 진성난수, RNG, CSPRNG, 보안
난수 이야기는, 꽤 다른 것이 모두 랜덤이라는 한마디로 불리기 때문에 바로 이야기가 어긋납니다. Math.random() 같은 계산으로 만드는 수열도, 열잡음이나 클록 지터 같은 물리 현상에서 얻는 수열도, 겉모습만으로는 어느 쪽이나 나름대로 흩어져 보이기 때문입니다.
다만, 실무에서는 이 차이를 모호하게 둔 채로는 다음 판단을 틀리기 쉬워집니다.
- 시뮬레이션에서 재현하고 싶은데 매번 결과가 흔들린다
- 비밀번호 재발급 토큰을 예측하기 쉬운 난수로 만들어 버린다
- 통계 검정에 통과한 것만으로 「진짜 난수다」라고 생각해 버린다
- 반대로
의사라는 말만 듣고 전부 위험하다고 오해한다
이 글에서는 의사난수란 무엇인가, 진짜 난수란 무엇인가, 어떻게 구별하는가를 실무에서 판단하기 쉬운 형태로 정리합니다. 특히 출력의 겉모습이 아니라 생성기의 구성을 보는 것을 주안점으로 합니다.
본문의 내용은 2026년 4월 시점에서 확인할 수 있는 NIST, IETF, OS, 언어 공식 자료를 전제로 정리했습니다.
1. 먼저 결론(한마디로)
먼저, 꽤 거칠지만 실무에서 도움이 되는 식으로 말하면 이렇습니다.
- 의사난수는 내부 상태와 알고리즘에서 결정론적으로 만드는 수열입니다
- 진짜 난수는 열잡음이나 지터 같은 물리 현상을 엔트로피 소스로 가진 수열입니다
- 다만, 실무에서 쓰는 안전한 난수 API 중 많은 것들은 물리 난수를 그대로 돌려주는 것이 아니라, 엔트로피 소스로 seed 한
DRBG / CSPRNG를 돌려줍니다 - 따라서
겉모습이 랜덤인지만으로는 구별할 수 없습니다. 봐야 할 것은 생성기의 구성, seed가 들어가는 방식, reseed, health test입니다 - 시뮬레이션이나 재현 시험에서는 의사난수의 재현성이 무기가 됩니다
- 키, 토큰, nonce 같은 보안 용도에서는 OS나 언어가 제공하는 안전한 난수 API를 쓰는 것이 기본입니다
요컨대, 우선 다음 3가지를 나누어 생각하면 벗어나기 어렵습니다.
- 그것은
보통의 PRNG에 대한 이야기인가 - 그것은
암호학적 PRNG / CSPRNG / DRBG에 대한 이야기인가 - 그것은
물리 엔트로피 소스를 가진 NRBG / TRNG에 대한 이야기인가
2. 이 글에서 말하는 「의사난수」와 「진짜 난수」
이 이야기에서는 단순히 난수라고 하면 대상이 너무 넓어집니다. 그래서 먼저 의미를 고정합니다.
- 의사난수(PRNG): seed와 내부 상태에서 결정론적인 절차로 수열을 생성하는 것. 같은 조건이면 같은 열이 나옵니다
- 암호학적 의사난수(CSPRNG / DRBG): 의사난수의 일종이지만 예측 곤란성을 중시한 것입니다. NIST SP 800-90A는 이 deterministic random bit generator를 정의하고 있습니다
- 진짜 난수: 일상어로는
진성난수나물리난수를 가리키는 경우가 많습니다. NIST에서는NRBG(non-deterministic random bit generator)가 가까운 표현이며, 엔트로피 소스를 항상 참조하고 정상 시에는 full entropy의 출력을 가지는 것으로 설명되어 있습니다
여기서 중요한 것은, 의사난수와 위험한 난수가 동의어가 아니라는 점입니다.
예를 들어, 선형 합동법이나 단순한 xorshift 같은 고속 PRNG와 CTR_DRBG나 HMAC_DRBG 같은 CSPRNG는 모두 결정론적이지만, 보안상의 의미는 꽤 다릅니다.
3. 먼저 한 장으로 정리
3.1. 관계도
우선, 개념의 위치 관계를 한 장으로 보는 것이 빠릅니다.
flowchart LR
NOISE["물리 현상<br/>열잡음·지터 등"] --> ENT["엔트로피 소스"]
ENT --> SEED["seed / reseed"]
SEED --> DRBG["DRBG / CSPRNG<br/>고속으로 난수를 전개"]
DRBG --> API["OS / 라이브러리가 돌려주는 난수"]
STATE["내부 상태 + 수식"] --> PRNG["보통의 PRNG"]
PRNG --> OUT["겉모습은 랜덤한 수열"]
여기서 중요한 것은, 앱이 받는 안전한 난수 API의 출력은 오른쪽의 보통의 PRNG와도, 왼쪽의 생 물리 노이즈와도 조금 다르다는 점입니다.
많은 구현은 왼쪽의 엔트로피 소스를 사용해 seed / reseed 하고, 그 위에서 DRBG / CSPRNG로 고속으로 전개한 값을 돌려줍니다. NIST SP 800-90B와 800-90C는 바로 이 entropy source + deterministic generator 구성을 정리한 문서입니다.
3.2. 용어의 최단 정리
| 종류 | 무엇으로 만드나 | 같은 조건에서 재현 | 무엇을 강하게 요구하나 | 적합한 용도 |
|---|---|---|---|---|
| 보통의 PRNG | 수식과 내부 상태 | 가능 | 속도, 재현성 | 시뮬레이션, 게임, 테스트 |
| CSPRNG / DRBG | 암호 알고리즘 + seed | 가능 | 예측 곤란성 | 키, 토큰, nonce, 세션 ID |
| 진짜 난수 / NRBG | 물리 엔트로피 소스 | 기본적으로 불가 | 물리적 불확정성, 엔트로피 | seed 공급, 인증 장치, 감사가 무거운 추첨 |
가장 짧게 외우자면 이렇습니다.
- 보통의 PRNG는
재현할 수 있는 난수 - CSPRNG는
재현은 할 수 있지만 밖에서는 예측하기 어렵게 만든 난수 - 진짜 난수는
물리 현상에서 엔트로피를 꺼내는 난수
4. 의사난수란 무엇인가
4.1. 한마디로 말하면
의사난수는 내부 상태를 갱신하면서 난수다운 것처럼 보이는 수열을 계산으로 만드는 것입니다.
같은 seed를 넣고 같은 알고리즘으로 같은 횟수만큼 뽑아내면, 같은 값 열이 나옵니다. 이것은 결점처럼 보이기 쉽지만, 시뮬레이션·테스트·디버깅에서는 오히려 큰 장점입니다.
재현할 수 있기에, 이 seed에서 버그가 난다, 어제의 결과를 다시 비교하고 싶다와 같은 운용이 가능합니다.
4.2. 보통의 PRNG와 CSPRNG는 나누어 생각한다
여기가 가장 오해받기 쉬운 곳입니다. 의사난수 = 가짜 = 써서는 안 된다가 아닙니다.
NIST SP 800-90A는 해시 함수나 블록 암호를 기반으로 한 deterministic random bit generator를 정의하고 있습니다. 즉, 암호 용도로 쓰이는 난수의 핵심도 상당 부분 결정론적인 생성기입니다.
차이는 단순한 난수다움이 아니라, 공격자 시점에서의 예측 곤란성에 있습니다.
- 보통의 PRNG
- 빠르다
- 재현하기 쉽다
- 내부 상태나 seed가 새면 예측되기 쉽다
- CSPRNG / DRBG
- 이것도 결정론적
- 다만, 내부 상태를 모른다는 전제에서, 출력을 예측하기 어렵도록 설계된다
- 보안 용도에서는 이쪽을 쓴다
따라서 의사난수인가 아닌가만으로 안전성을 판단하면 거의 벗어납니다. 봐야 할 것은 어느 의사난수인가입니다.
5. 진짜 난수란 무엇인가
5.1. 한마디로 말하면
진짜 난수는 열잡음, 발진기의 지터, 애벌런치 노이즈, 양자 현상 같은 물리적 불확정성에서 엔트로피를 꺼내는 것입니다.
일상어로는 진성난수나 물리난수라고 불립니다. NIST의 용어에서는 NRBG가 가깝고, 항상 엔트로피 소스에 접근하며, 정상 작동 중이라면 full entropy의 출력을 가지는 생성기라는 위치에 놓입니다.
5.2. 물리 난수도 그대로 쓴다고는 한정하지 않는다
여기도 중요합니다. 진짜 난수라고 해서, 생 측정값을 그대로 앱에 넘기는 것은 아닙니다.
물리 소스에는 다음과 같은 실무상의 어려움이 있습니다.
- 편향이 있다
- 온도, 전원, 고장, 노화의 영향을 받는다
- 생 출력 속도는 그다지 높지 않을 수 있다
- 헬스 체크가 없으면, 망가져 있어도 알아채기 어렵다
이 때문에 NIST SP 800-90B에서는 엔트로피 소스의 설계 원칙, min-entropy의 사고방식, validation test, health testing이 중시됩니다. 그리고 구현 전체로는 NIST SP 800-90C처럼 entropy source + DRBG 구성으로 쓰이는 경우가 많습니다.
요컨대 진짜 난수는 raw의 신비로운 무언가가 아니라, 물리 소스, 평가, 감시, 후처리까지 포함해서 다루는 것입니다.
6. 무엇이 다른가
난수의 차이는 단순히 랜덤하게 보이는가만으로는 정리할 수 없습니다. 최소한 다음 4축으로 보면 이해하기 쉽습니다.
6.1. 생성원
- 의사난수: 알고리즘과 내부 상태
- 진짜 난수: 물리 엔트로피 소스
여기가 가장 본질적인 차이입니다.
6.2. 재현성
- 의사난수: 같은 seed이면 재현할 수 있다
- 진짜 난수: 같은 조건으로 다시 뽑아도 같은 값 열이 되기 어렵다
재현성은 테스트에서는 강점, 추첨에서는 약점이 될 수 있습니다.
6.3. 예측 가능성
- 보통의 PRNG: seed나 내부 상태가 읽히면 다음이 꽤 보인다
- CSPRNG: 내부 상태가 지켜지는 전제에서, 미리 읽히지 않도록 설계된다
- 진짜 난수: 물리 소스가 건전하면 예측하기 어렵지만, 센서 불량이나 설계 미비는 별개의 문제
보안에서는 이 축이 가장 중요합니다. 겉보기의 흩어짐보다, 다음을 맞힐 수 있는지가 중요합니다.
6.4. 속도와 운용
- 의사난수: 고속, 안정, 구현하기 쉽다
- 진짜 난수: 엔트로피 수집이나 감시가 필요하고, 속도나 구현 비용에 제약이 있다
이 때문에 본격 시스템에서는 진짜 난수만 또는 의사난수만의 이분법이 아니라, 물리 엔트로피로 seed를 넣은 CSPRNG가 가장 현실적입니다.
7. 어떻게 구별하는가
7.1. 출력만으로는 원칙적으로 구별할 수 없다
가장 중요한 답은 이것입니다. 유한 개의 출력 열만 보고 이것은 진짜 난수다라고 단언할 수는 없습니다.
이유는 간단한데, 지금 관측한 유한 길이의 열과 완전히 같은 열을 돌려주는 결정론적 프로그램은 언제든 만들 수 있기 때문입니다. 극단적으로 말하면, 그 열을 배열이나 ROM에 심어 순서대로 돌려주면 그만입니다.
그러므로 겉모습이 자연스럽기 때문에 진짜라고 말할 수 없습니다. NIST SP 800-22에서도 통계 검정은 어디까지나 첫걸음이며, 그것만으로 생성기의 타당성을 절대적으로 증명하는 것은 아니라고 되어 있습니다.
반대로 말하면, 잘 만든 CSPRNG는 출력만 봐서는 꽤 구별하기 어렵게 만들어집니다. 여기서 구별할 수 없다는 것은 오히려 설계 목표 쪽입니다.
7.2. 우선 봐야 할 것은 생성기의 설계
구별할 때는 출력의 겉모습보다 다음을 확인하는 편이 본질적입니다.
- 생성 알고리즘은 무엇인가
- 단순한 PRNG인가, DRBG / CSPRNG인가
- seed는 어디에서 오는가
- 고정 seed, 시각, PID 정도인가
- OS의 엔트로피 소스에서 오는가
- reseed 하는가
- 기동 시에 한 번만 seed 하고 끝인가
- 운용 중에도 다시 투입되는가
- 엔트로피 소스의 검증이 있는가
- min-entropy의 평가
- health test
- 고장 검지
- 어느 API를 쓰고 있는가
- 자체 구현인가
- OS / 언어의 표준 API인가
이 관점에서 보면 꽤 많은 경우를 구별할 수 있습니다.
seed를 고정하면 매번 같은 열이 나온다→ 의사난수물리 엔트로피 소스가 있고, validation / health test를 전제로 한다→ 진짜 난수원을 가진 설계OS의 secure RNG API를 부르고 있다→ 대부분물리 엔트로피 + CSPRNG의 하이브리드
7.3. 다음으로, 통계 검정으로 명백한 결함을 찾는다
통계 검정은 불필요하지 않습니다. 오히려 중요합니다. 다만 역할은 증명이 아니라 결함 검출에 가깝습니다.
대표적으로는 다음과 같은 관점을 봅니다.
- 0과 1의 편향
- run의 편향
- 주기성
- 상관
- 근사 엔트로피
- 선형 복잡도
NIST SP 800-22나, 국내(일본)에서는 CRYPTREC의 난수 검정 미니멈 세트가 자주 참조됩니다. 이들은 그 열에 노골적인 편향이나 구조가 없는지를 조사하는 데 유효합니다.
다만 여기서 합격해도 진짜 난수라고는 할 수 없습니다. 잘 만들어진 CSPRNG도 보통 통과할 수 있고, 반대로 물리 난수원이어도 센서의 편향이나 고장으로 떨어지는 경우가 있습니다.
검정의 위치는 대략 이렇습니다.
- 통과함: 일단 노골적인 결함은 보이기 어렵다
- 떨어짐: 뭔가 이상할 가능성이 높다
- 그러니 진짜라고 증명할 수 있다: 거기까지는 말할 수 없다
7.4. 보안 용도에서는 공격자 관점으로 본다
비밀번호 재발급 토큰, 세션 ID, nonce, 키 생성 같은 용도에서는, 물음이 진짜인가 아닌가만으로는 부족합니다.
정말로 봐야 할 것은 공격자가 다음 값을 예측할 수 있는지 입니다.
예를 들어,
- 현재 시각만으로 seed 하고 있다
- 프로세스 ID나 연번을 섞었을 뿐이다
- 자체 구현에서 seed의 품질을 평가하지 않았다
random계열 API를 보안 용도에 전용하고 있다
이 근처는 겉보기가 그럴듯하다만으로는 막을 수 없습니다.
IPA도 보안 관련 API나 기존 라이브러리를 파악하여, 안이한 자체 구현을 피하라고 권장하고 있습니다. Python에서도 secrets 모듈을 random보다 우선해서 쓰도록 명기되어 있습니다. Java에서는 SecureRandom이 그 위치입니다.
결국 보안에서는 의사난수인가 진짜인가보다, 안전한 seed / entropy와 안전한 API를 쓰고 있는가 쪽이 더 중요합니다.
8. 용도별로 무엇을 써야 할까
| 용도 | 적합한 것 | 이유 |
|---|---|---|
| 시뮬레이션, Monte Carlo, 게임 로직 | 보통의 PRNG | 빠르고, seed로 재현할 수 있다 |
| 테스트 재현, 버그 재현 | 보통의 PRNG | 같은 입력을 재현할 수 있다 |
| 키, 토큰, nonce, 세션 ID | CSPRNG / OS의 secure RNG API | 예측 곤란성이 필요 |
| seed 공급, 감사나 설명 책임이 무거운 추첨 | 물리 난수원을 가진 설계, 또는 감사 가능한 구조 | 물리 엔트로피나 증적이 중요 |
일반 앱 개발에서 안전한 난수가 필요 |
OS / 언어 표준의 secure RNG | 자체 구현보다 벗어나기 어렵다 |
구현 수준에서는 다음과 같이 고르면 무난합니다.
- Windows 네이티브:
BCryptGenRandom - .NET:
System.Security.Cryptography.RandomNumberGenerator - Linux:
getrandom() - Python:
secrets - Java:
SecureRandom
Windows의 BCryptGenRandom은 Microsoft Learn에서 NIST SP800-90의 CTR_DRBG를 준수하는 기본 프로바이더로 설명되어 있습니다. Linux의 getrandom()도 난수 바이트를 cryptographic purposes에 쓸 수 있다고 문서화되어 있습니다. .NET의 RandomNumberGenerator, Python의 secrets, Java의 SecureRandom 모두 암호 용도를 의식한 API입니다.
9. 자주 있는 오해
9.1. 통계 검정에 통과하면 진짜 난수이다
아닙니다. 그것으로 말할 수 있는 것은 노골적인 편향이 보이기 어렵다 정도입니다.
9.2. 진짜 난수라면 항상 안전하다
아닙니다. 물리 소스의 고장, 편향, 구현 미비, health test의 결여로 품질은 무너집니다.
9.3. 의사난수는 전부 위험하다
아닙니다. CSPRNG / DRBG는 오히려 실무의 안전한 난수 API의 핵심입니다.
9.4. 보안 용도에서는 raw의 물리 난수만을 직접 써야 한다
꼭 그렇지도 않습니다. 실제로는 물리 엔트로피 소스 + CSPRNG의 조합이 일반적입니다.
9.5. random이나 Math.random()도 충분히 흩어지니까 token에 쓸 수 있다
용도가 다릅니다. 겉모습의 흩어짐과 공격자로부터의 예측 곤란성은 별개입니다.
10. 실무에서 망설일 때의 판단표
망설이면 다음 순서로 생각하면 빠릅니다.
- 같은 결과를 재현하고 싶은가
- 예 → 보통의 PRNG
- 아니오 → 다음으로
- 공격자에게 예측되면 곤란한가
- 예 → OS / 언어 표준의 secure RNG
- 아니오 → 품질 요건과 속도로 고른다
- 난수원 자체에 설명 책임이나 감사가 필요한가
- 예 → 물리 난수원이나 인증된 서비스를 검토
- 자체 구현하고 싶은가
- 그 마음은 이해합니다만, 난수는 벗어나기 쉬우므로, 우선 표준 API를 씁니다
이 순서로 보면, 의사인가 진짜인가라는 이분법만으로 고민하기보다 훨씬 빨리 방향이 정해집니다.
11. 정리
의사난수와 진짜 난수의 차이를 가장 거칠지만 실무에서 도움이 되는 형태로 말하면 이렇습니다.
- 의사난수는 계산으로 만든다
- 진짜 난수는 물리 현상에서 엔트로피를 꺼낸다
- 하지만 실무의 안전한 난수 API는 그 중간에 있는
entropy source + CSPRNG가 주역
즉, 봐야 할 것은 겉모습이 아니라 구성입니다.
- 출력만으로 진짜인지 아닌지를 단언할 수는 없다
- 통계 검정은 결함 검출에는 도움이 되지만, 증명은 되지 않는다
- 보안에서는
예측할 수 있는가가 본진이다 - 재현성이 필요하면 PRNG, 예측 곤란성이 필요하면 OS / 언어 표준의 secure RNG를 쓴다
이 순서로 잡으면 의사난수는 가짜인가라는 거친 대립에서 빠져나올 수 있습니다.
12. 참고 자료
-
NIST SP 800-90A Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators
deterministic random bit generator의 기본 문서입니다. -
NIST SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation
entropy source, validation, health testing의 사고방식을 정리하고 있습니다. -
NIST SP 800-90C: Recommendation for Random Bit Generator (RBG) Constructions
entropy source + DRBG의 구성을 정리하고 있습니다. -
NIST SP 800-22 Rev. 1a: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications
통계 검정의 위치를 설명하고 있습니다. 검정은 첫걸음이며 증명이 아니라는 점이 중요합니다. -
NIST Glossary: Non-deterministic Random Bit Generator (NRBG)
true random에 가까운 NIST 용어 확인에 쓸 수 있습니다. -
RFC 4086: Randomness Requirements for Security
보안 용도에서의 난수와 entropy source의 주의점을 정리하고 있습니다. -
Microsoft Learn: BCryptGenRandom function
Windows의 secure RNG API와 기본 프로바이더의CTR_DRBG에 대해 설명하고 있습니다. -
Linux man page: getrandom(2)
Linux에서cryptographic purposes에 쓸 수 있는 난수 API입니다. -
Microsoft Learn: RandomNumberGenerator 클래스
.NET의 암호 강도가 높은 RNG API입니다. -
Python documentation: secrets — Generate secure random numbers for managing secrets
Python에서 보안 용도의 난수를 다루는 기본입니다. -
Oracle Java Documentation: SecureRandom
Java의 secure RNG와 seed / entropy의 사고방식이 정리되어 있습니다. -
IPA: 제3장 3. 깨기 어려운 암호 기술과 의사난수의 사용
seed의 중요성, 검정, API 이용의 주의점이 일본어로 정리되어 있습니다.
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.
자동 업데이트 기능의 보안 기본 - 나쁜 패턴과 베스트 프랙티스
자동 업데이트를 신뢰 경계로 다루는 사고방식을 정리합니다. HTTPS만으로 부족한 이유, signed metadata와 클라이언트 측 검증, 키 분리, fail-closed와 rollback, MSIX·ClickOnce 등 Windows의 기존 ...
해시 값의 문자열 표현으로부터 해시 방식을 판정하는 방법 - 길이·문자 집합·접두사로 후보를 좁히는 실무 절차
해시 문자열의 방식을 가릴 때는 길이만 보지 말고 접두사·구분자·문자 집합·길이·문맥 순으로 좁히면 정확합니다. $argon2id$나 $2b$, {SHA} 같은 저장 형식은 거의 특정할 수 있지만 단순 16진은 후보군까지만 좁혀집니다.
Windows에서 DLL 이름 해결의 메커니즘 - 검색 순서, Known DLLs, API set, SxS를 실무용으로 정리
Windows의 DLL 이름 해결을 검색 순서 암기에서 멈추지 않고, DLL redirection·API set·SxS manifest·Known DLLs 같은 전단 규칙, SetDefaultDllDirectories와 LoadLibraryEx의...
Windows의 관리자 특권이 필요해지는 것은 언제인가 - UAC, 보호 영역, 설계상의 구분 방법
Windows에서 관리자 권한이 필요한지는 사용자 직함이 아닌 앱이 건드리는 경계로 정해진다는 관점에서, UAC 동작과 보호 영역, per-user 대 per-machine, 매니페스트와 분리 모델까지 정리하여 불필요한 승격을 줄이는 설계 판단 ...
Windows 앱에서 「관리자 권한이 필요한 처리만」을 분리하는 구체적인 방법
Windows 앱에서 UI는 asInvoker로 두고 관리자 처리만 helper EXE로 분리하는 broker 설계를 runas 기동, 명명 파이프 ACL, 클라이언트 PID 검증, 고정 operation allowlist까지 .NET 8 코드로...
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용에 관한 KomuraSoft LLC 기사를 모은 토픽 허브입니다.
저자 프로필
기사 저자의 프로필 페이지입니다.
Go Komura
합동회사 코무라소프트 대표
Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.
공개 링크