순수 계산의 경계는 시계·설정·난수·저장소 같은 외부 상태를 값으로 바꾸어 함수에 넘기는 곳입니다. 그러면 같은 입력을 다시 계산할 수 있지만, 계산 결과를 DB나 결제 시스템에 적용하는 외부 효과의 중복 안전성까지 자동으로 얻는 것은 아닙니다. 이 노트는 두 경계를 섞지 않고 재현 조건을 추적합니다.
시각·정책 입력 경계와 만료 계산 함수
expiresIn(days)가 내부에서 현재 시각·전역 정책을 읽으면 같은 인자도 결과가 바뀝니다. 효과 경계가 시각과 policy를 읽고 calculateExpiry(now, days, policy)에 값으로 전달하면 계산은 재현하기 쉬워집니다. 입력 객체를 몰래 정렬하거나 로그를 쓰는 것도 호출 밖의 관찰을 바꾸는 효과입니다.
순수 함수는 같은 값 입력에 같은 결과를 내며, 시계·전역 변수·파일처럼 함수 밖의 상태를 몰래 읽거나 바꾸지 않습니다. 그래서 호출을 그 결과값으로 바꿔도 프로그램이 관찰하는 결과가 같다는 참조 투명성으로 설명할 수 있습니다. 로그 함수는 호출 자체가 로그 횟수를 바꾸므로 결과값으로 치환할 수 없고, 순수 함수라는 사실만으로 업무 규칙이 옳아지는 것도 아닙니다. 잘못된 세율도 같은 입력에 일관되게 계산할 수 있습니다.
그림을 글로 읽기
- 시계·설정·저장소 읽기
- 명시적 입력 → 계산 결과·명령
- 현재 version·인가 조건 확인
- DB·네트워크·로그 효과
- 시계·설정·저장소 읽기 → 명시적 입력 → 계산 결과·명령: 값·기준 version
- 명시적 입력 → 계산 결과·명령 → 현재 version·인가 조건 확인: 결정된 명령
- 현재 version·인가 조건 확인 → DB·네트워크·로그 효과: 허용된 적용
계산 전 읽은 가격이 저장 전에 바뀔 수 있어 결과에 기준 version을 연결하고 적용 때 조건부 갱신합니다. 계산을 두 번 해도 안전하다는 사실을 결제를 두 번 보내도 안전하다는 주장으로 확대하지 않습니다.
객체 identity와 가변 입력 값
객체 {price:100, tax:0.1}의 주소로 결과 110을 cache한 뒤 price=200으로 바꾸면 같은 key로 110이 반환될 수 있습니다. 불변 입력 또는 실제 계산에 영향을 주는 값·정책 version을 key로 사용합니다. 같은 값의 새 객체도 재사용할지는 값 동일성 계약으로 정합니다.
| Key 선택 | 이점 | 필요한 전제·비용 |
|---|---|---|
| 객체 identity | 저렴한 lookup | 객체가 변하지 않거나 명시적 무효화 |
| 값 tuple·policy version | 의미가 명확함 | 모든 영향 입력 포함 |
| 깊은 hash | 큰 구조를 작은 key로 | 계산 비용·충돌·정규화·동일성 검사 |
map 순서·NaN·-0·Unicode 정규화 또는 직렬화에서 빠진 필드가 계산 의미를 바꾸는 입력이라면, 단순 JSON 문자열 하나를 모든 경우의 key로 쓰지 않습니다. hash를 사용하더라도 충돌을 값 동일성으로 착각하지 말고 cache size·eviction·보유 참조를 함께 관리합니다. 계산이 전역 환율을 계속 몰래 읽는다면 key에 값을 더하는 것만으로는 순수성 문제를 해결할 수 없습니다.
난수 생성과 명시적 RNG 상태 전달
설명용 작은 생성기를 next=(5*state+1) mod 16, 결과값을 next라고 둡니다. seed 1에서 6→15→12가 나옵니다. 함수는 상태 1을 주면 언제나 (값6, 다음상태6)을 반환하고 다음 계산은 그 상태를 명시적으로 받습니다. 실제 통계 품질·보안에 적합한 생성기라는 뜻은 아닙니다.
여러 작업이 전역 RNG를 함께 쓰는 상태에서 작업 A가 난수 하나를 먼저 소비하면, 작업 B가 받는 다음 값과 전체 결과 순서가 달라집니다. 같은 replay를 얻으려면 seed만 저장하지 말고 알고리즘·version·호출 순서·병렬 분배도 함께 고정해야 합니다. 병렬 실행에서는 안정된 작업 ID별 stream 분리 같은 정책을 정하고, 임의의 스케줄 순서가 공유 RNG를 소비하게 두지 않습니다. 보안 token은 재현 가능한 테스트 seed가 아니라 적합한 암호학적 난수 경로에서 만들어야 합니다.
상태 trace를 위해 now, 정책 version, RNG 상태를 입력 로그에 함께 저장하고 같은 입력을 두 번 계산하십시오. 예상 결과는 계산 결과와 다음 RNG 상태가 같아야 하며, 정책 version만 바꾸면 cache key가 달라져 이전 결과를 재사용하지 않아야 합니다. 저장 성공 뒤 이벤트 실패를 추가로 주입해도 계산의 순수성 시험과 외부 효과의 복구 시험이 서로 섞이지 않아야 합니다.
계산 재현성과 외부 효과 실패의 분리 시험
동일 값 입력·입력 불변·동등한 다른 객체·정책 version 변경·eviction·RNG 상태 재개를 기준 계산과 비교합니다. 효과 단계에서는 저장 성공 후 이벤트 실패·중복 호출·현재 version 충돌을 별도로 검사합니다. 이 노트는 계산 경계 설명이며 이 예시 RNG를 제품에 사용하도록 권하는 것이 아닙니다.