content-addressed identity

"같은 오디오, 같은 설정은 같은 구매야. 돈은 한 번 들어야 해."

두 호출을 '같다' 고 만드는 건 뭐야?

지난 레슨의 예약 ledger 는 두 호출이 같은 호출임을 알아볼 수 있어야만 이중 지출을 막아. 그래서 유료 호출의 identity 는 진짜 신경 써서 골라야 해. 뻔한 선택지는 뭐가 잘못될까?

파일명 — 오디오가 그대로인데 파일이 이름 바뀌거나 옮겨질 수 있고, 다른 두 파일이 이름을 공유할 수 있어. 파일명은 콘텐츠가 아냐.
랜덤 request id — 시도마다 새로 생성돼서, 동일 호출의 재시도가 새 id 를 받아 완전히 새것처럼 보여. 그건 방지가 아니라 이중 결제를 보장해.
타임스탬프 — 매번 달라; 랜덤 id 랑 같은 실패.

이것들 하나하나가 같은 오디오를 두 번 결제하게 놔둬. identity 는 실제로 비용이랑 결과를 결정하는 것에서 와야 해: 콘텐츠.

identity 는 콘텐츠 + config 의 hash 야

Recall 의 유료 호출 identity 는 hash 한 쌍이야: 보내는 정확한 오디오 chunk 의 SHA-256, 그리고 정확한 provider 설정의 SHA-256. 동일 설정 아래 동일 오디오 바이트는 동일 hash 를 내고, 그게 같은 identity 를 내 — 그래서 재시도가 이미 존재하는 ledger 행에 착지하고, 완료된 걸 찾고, 다시 결제하는 대신 저장된 응답을 재사용해. identity 당 한 번 결제, 이름이나 시계가 아니라 콘텐츠로 보장.

왜 config 도 identity 의 일부야? 같은 오디오를 다른 model 이나 다른 설정으로 전사하면 진짜 다른 호출이니까 — 다른 증거를 내고 정당하게 다시 돈이 들어. config hash 를 key 에 접어 넣으면 '같은 오디오, 같은 config' 는 하나의 유료 identity 고, '같은 오디오, 새 config' 는 올바르게 새것이야. identity 는 출력을 결정하는 걸 정확히 담아: 바이트랑 설정, 그 외엔 아무것도.

content-addressing, 이제 돈을 위해

content-addressing 은 트랙 3 에서 만났어, release 의 content hash 가 요약을 stale 로 감지하게 한 데서. 이건 같은 아이디어를 지출에 겨눈 거야. identity 가 콘텐츠에서 파생되면, '이미 했나?' 가 추측이 아니라 조회가 돼: 입력을 hash 하고, ledger 를 확인하면, 완료된 작업을 찾거나 못 찾거나 둘 중 하나야. 사람이 붙인 라벨이나 시계가 낸 것 대신 콘텐츠로 이름 짓는 게 '두 번 결제 안 함' 을 희망 섞인 관례에서 기계적 보장으로 바꿔.

Code

콘텐츠 + config 에서 identity, ledger 대조·python

import hashlib

def paid_identity(audio_chunk: bytes, config: dict) -> tuple[str, str]:
    chunk_hash = hashlib.sha256(audio_chunk).hexdigest()
    config_hash = hashlib.sha256(canonical_json(config)).hexdigest()
    return (chunk_hash, config_hash)   # 유료 호출 key

def reserve(audio_chunk, config):
    key = paid_identity(audio_chunk, config)
    existing = ledger.find(key)
    if existing and existing.status == 'completed':
        return existing.response      # 이미 결제됨 — 재사용, POST 안 함
    return ledger.create_reservation(key)  # 새 identity — 예약

# 같은 바이트 + 같은 config -> 같은 key -> 최대 한 번 결제
# 같은 바이트 + 새 config  -> 새 key  -> 정당하게 새 호출

Exercise

네 일에서 실수로 두 번 돌 수 있는 비싸거나 부작용 있는 작업을 찾아 — 유료 API 호출, 무거운 계산, 이메일. 물어: 지금 그 identity 가 뭐야? 파일명, 랜덤 id, 타임스탬프면, 결과랑 비용을 실제로 결정하는 입력을 나열해. 그 입력에서 content-addressed key 를 설계하고, '이미 했나?' 체크가 그걸 어떻게 쓸지 설명해.

Hint

key 를 두 사고 실험으로 테스트해: (1) 같은 진짜 작업이 재시도되면, key 가 그대로라 재시도가 no-op 이야? (2) 진짜 다른 입력이 결과나 가격을 바꾸면, key 가 바뀌어 올바르게 새 작업으로 다뤄져? 좋은 identity 는 둘 다 yes — 보통 비용 결정 입력 전부를 hash 하고 그 외엔 아무것도 안 하는 거야.