이름 조회에 NFC 키를 기본으로 써도 될까요?

나누는 방식엔 동의해요. 조회는 정규화된 키만 받고, 제출된 원문은 그 옆에 같이 들고 가면 돼요.

그런데 여기서 값이 없다는 건 어떤 뜻인가요? 폼에서 이름을 비워 둘 수 있다면 null은 입력하지 않았다는 뜻이어야 해요. 아직 정규화를 안 했다는 뜻까지 겸하면 안 돼요. 호출자 둘을 보면 차이가 보여요. 저장된 이름 화면은 제출한 그대로의 철자가 필요해요. 검색 호출자는 파생된 키가 필요해요. 두 계정이 같은 키를 가질 수 있다면 검색은 여러 결과를 돌려주거나 다른 식별자를 요구해야 해요. 물음표 없는 Kotlin String은 값이 있다는 것만 약속해요. NFC인지, 누구 이름인지는 말해 주지 않아요.

이름을 입력해요. 제출해요. 그 자리에서 normalize("NFC")가 돌고 두 버전이 함께 넘어가요. 그러니 저장된 이름이 '아직 정규화 안 됨' 상태로 머무는 일이 없고, hollis 님의 null도 딱 한 가지 뜻만 지켜요.

조회가 비동기라면 나중에 나오는 일치 목록은 그 자체로 별개의 결과예요. 이름의 새로운 의미가 아니에요. 그리고 그 목록에 계정이 둘 이상 들어갈 수 있게 되는 순간, 검색 호출자는 소유 확인이 아니라 고르는 화면이 돼요. 계정 식별자가 제값을 하는 건 바로 그때예요.

Swift에서 "e\u{301}" == "\u{E9}"는 true인데, 저는 그게 좀 재밌어요. String의 동등성이 정규 등가(canonical equivalence) 기준이고 해시도 그걸 따르기 때문에, [String: Account]는 이미 두 표기를 키 하나로 취급해요. 문제가 해결된 것처럼 들리고, 일부는 실제로 해결돼요.

그런데 저장된 문자열은 여전히 들어온 그대로고, 그 키가 데이터베이스나 다른 언어로 넘어가는 순간 다시 코드 단위로 비교돼요. 그래서 저는 그래도 NFC 키를 명시적으로 만들어서 원문 옆에 저장할 거예요.