붙여넣은 문장이 검색되지 않을 때: 보이지 않는 공백과 문자 찾기

화면의 한 글자와 저장된 문자 단위는 다릅니다.

완성형 한글 가는 하나의 코드 포인트로 저장할 수 있고, 초성·중성을 조합한 문자열도 화면에서는 비슷하게 보일 수 있습니다. 이모지 한 묶음 안에는 여러 문자와 연결 문자가 들어갑니다. 보이지 않는 문자라는 이유만으로 쓸모없는 글자라고 판단할 수 없는 이유입니다. 먼저 비교 목적이 표시·검색·식별자·원문 보존 중 무엇인지 정합니다.

제목의 시각적 길이를 검토할 때와 파일의 바이트 동일성을 확인할 때는 기준이 다릅니다. 이번 예제는 코드 포인트 목록을 출력하며 글자 묶음의 개수나 실제 폰트의 표시 폭을 측정하지 않습니다. 사람이 보는 모양을 코드 포인트 수 하나로 점수화하면 이모지나 결합문자에서 잘못된 결론을 내리기 쉽습니다.

일반 공백·줄바꿈 금지 공백·제로폭 공백을 나눴습니다.

첫 문자열은 AI와 검수 사이에 U+0020 일반 공백을 넣었습니다. 둘째는 U+00A0 줄바꿈 금지 공백을, 셋째는 U+200B 제로폭 공백을 넣었습니다. 화면을 보지 않아도 결과 JSON의 codepoints와 names에서 어느 위치에 어떤 문자가 있는지 알 수 있습니다. 코드의 flags는 정한 후보 문자만 표시합니다.

일반 공백과 줄바꿈 금지 공백을 가진 두 문자열의 직접 비교는 거짓이었습니다. 보이는 글자만 보고 같은 제목이라고 단정하면 이런 차이를 놓칠 수 있습니다. 그러나 줄바꿈 금지 공백은 숫자와 단위를 떨어뜨리지 않는 등 의도적으로 쓰일 수 있습니다. 발견은 삭제 지시가 아니라 사용 목적을 확인할 신호입니다.

NFC는 조합 차이를 줄이지만 모든 숨은 문자를 없애지 않습니다.

넷째 입력은 한글 자모 조합이고 다섯째는 완성형 가입니다. NFC를 적용한 뒤 두 값은 같았습니다. 반면 제로폭 공백을 가진 AI 문자열에는 NFC 이후에도 U+200B가 남았습니다. 정규화 함수가 문자열 청소기라는 생각으로 호출하면 기대한 결과가 나오지 않을 수 있습니다.

NFC는 정준 동등성에 관한 규칙이고, 공백을 모두 바꾸거나 제어 문자를 전부 삭제하는 정책이 아닙니다. 원문과 정규화 값을 나란히 두면 “같다”고 판정한 근거를 설명할 수 있습니다. 이미 원본을 덮어썼다면 어느 문자가 있었는지 복원하기 어려워집니다. 비교용 키를 새로 만들어 사용하고 입력 자체는 보존하는 방식을 우선 고려합니다.

호환 정규화는 편리하지만 더 많은 표현 차이를 바꿉니다.

NFKC는 정준 정규화와 달리 호환되는 표현도 다룰 수 있습니다. 일부 너비나 서식 차이를 검색용으로 줄이는 데 도움이 될 수 있지만 원문의 구분이 중요한 이름·코드·수학 표기에서는 손실이 될 수 있습니다. 모든 식별자를 NFKC로 바꾼 뒤 같은 값으로 합치는 작업은 별도 규칙과 검토가 필요합니다.

실행 결과에는 nfc와 nfkc를 모두 기록했지만 코드가 더 좋아 보이는 값을 자동 선택하지는 않습니다. 목적이 다른 두 열입니다. 실제로 검색어를 정규화할지, 표시값은 유지할지, 충돌하는 두 원문을 어떻게 다룰지 업무 계약으로 정해야 합니다. 정규화 후 값이 같아졌다고 두 사용자가 같은 사람이라는 결론을 만들 수는 없습니다.

입력별 결과를 편집 판단에 연결하기

다음 표의 결과는 제공 실행 파일에서 확인한 값이며, 해석과 다음 확인은 그 결과를 이용하는 편집 예시입니다. 추가 시험을 수행한 결과로 세지 않습니다.

이모지 연결 문자를 지우면 다른 문자열을 만들 수 있습니다.

여섯째 입력은 가족을 나타내는 이모지 묶음이며 U+200D ZERO WIDTH JOINER가 들어 있습니다. 보이지 않는 문자를 모두 삭제하는 정규식은 이 연결까지 없앨 수 있습니다. 이번 후보 표시는 U+200D를 자동 제거 대상으로 넣지 않았고 어떤 입력도 삭제하거나 저장하지 않았습니다.

문자열을 다룰 때는 “zero width”라는 이름만으로 역할을 합치지 마세요. 공백 후보, 방향 제어, 결합, 선택자 등 쓰임이 다를 수 있습니다. 문서 편집 중에 들어온 불필요한 문자와 언어·표시에 필요한 문자를 구분해야 합니다. 실제 렌더링은 운영체제·폰트·프로그램에 따라 다르므로 코드 포인트 출력만으로 보이는 모양까지 검증했다고 쓰지 않습니다.

차이가 난 위치는 인덱스 기준도 함께 설명합니다.

결과 flags의 숫자는 Python 문자열을 순회한 코드 포인트 위치이며 0부터 셉니다. 자바스크립트의 UTF-16 인덱스나 사용자가 화면에서 세는 글자 위치와 항상 같지는 않습니다. 파일의 바이트 오프셋도 아닙니다. 숫자만 알려 주면 편집자가 다른 곳을 지울 수 있으므로 주변 문맥과 코드 포인트 이름을 함께 보여 줍니다.

민감한 원문을 점검할 때는 차이가 난 부분을 그대로 공개하지 않습니다. 필요한 구조만 새로 만든 최소 예제로 줄이고, 원본은 권한이 있는 환경에 남깁니다. “눈에 안 보인다”는 특성 때문에 스크린샷만으로 공유하기 어려운 경우가 많으므로 U+ 표기와 이스케이프를 사용하되 그것이 실제 원문 글자와 다른 표시 방식임을 밝혀야 합니다.

검색 실패의 원인이 문자 차이인지 먼저 좁혀 봅니다.

복사한 제목이 검색되지 않으면 검색어와 원문을 각각 코드 포인트로 확인합니다. 그다음 대소문자·정규화·공백 종류를 비교하고, 검색 도구가 어떤 분석기를 쓰는지 확인합니다. 실제 검색 시스템은 토큰화·불용어·색인 지연의 영향도 받으므로 문자열 차이 하나가 모든 검색 실패를 설명하지는 않습니다.

비교 결과가 다를 때도 바로 일괄 수정하지 않습니다. 제목의 일반 문장에는 공백 교체가 적절할 수 있지만 계정 ID나 파일명에는 충돌을 만들 수 있습니다. 먼저 사본의 몇 사례에서 예상한 검색과 원문 보존이 함께 되는지 확인합니다. 원본에 무엇을 바꿨는지와 그 이유를 로그로 남기면 다시 붙여 넣는 경로에서 같은 문자가 들어오는지도 찾기 쉽습니다.

원문을 수정해야 한다면 변경표를 만들 수 있습니다. 행에는 파일 또는 문장 ID, 원시 코드 포인트, 제안 변환, 이유, 충돌 여부, 검토자를 둡니다. 두 파일 이름이 NFC 뒤 같아진다면 한 파일을 다른 파일로 덮어쓰지 않고 충돌 그룹으로 분리합니다. 검색어 비교에는 적절한 규칙이 저장 경로의 동일성 비교에서는 위험할 수 있으므로 사용 위치를 함께 적어야 합니다.

일괄 삭제 대신 후보 표시와 사람 확인을 기본으로 둡니다.

실제 도구를 만든다면 후보 문자의 위치·이름·주변 문자열·정규화 결과를 보여 주고 적용할 변환을 별도로 선택하게 합니다. 원문 자체를 수정하는 버튼과 읽기 전용 비교를 구분해야 합니다. 특히 대량 파일을 바꿀 때는 정규화 뒤 동일해지는 이름을 먼저 찾아 덮어쓰기 위험을 막아야 합니다.

이번 실험은 표본 문자열 여섯 개의 출력만 확인했습니다. 특정 편집기나 데이터베이스에서 실제 저장·검색을 실행한 결과가 아니고 모든 Unicode 제어 문자를 검사하지도 않습니다. 목록에 없다는 사실은 “문자 문제가 없다”는 보장이 아닙니다. 다른 의심 문자는 Unicode 자료와 사용하는 시스템의 규칙을 확인한 뒤 검사 범위를 넓혀야 합니다.

다운로드 결과에서 먼저 확인할 세 칸

코드 포인트 목록은 내부 구성을, 이름 목록은 문자의 역할을 찾는 실마리를, NFC·NFKC 값은 선택한 규칙의 결과를 보여 줍니다. assert는 일반 공백과 NBSP가 다르다는 점, 자모와 완성형이 NFC 뒤 같다는 점, 제로폭 공백이 NFC 뒤 남는 점을 검사했습니다. 그래픽 화면이나 사용자 실험은 수행하지 않았습니다.

보이지 않는 차이를 눈에 보이는 진단 정보로 바꾸는 것이 이 예제의 목적입니다. 삭제할 대상을 많이 찾았다고 좋은 도구가 되는 것은 아닙니다. 원문을 지키면서 어떤 기준으로 비교했는지 설명할 수 있어야 합니다. 입력 경로와 저장 규칙을 고치면 수동 청소를 반복하는 일도 줄일 수 있지만 그 업무 효과는 이번 작은 문자열 실험에서 측정하지 않았습니다.

다른 시스템으로 보낸 뒤에만 문제가 생긴다면 입력 직후, 저장 직전, 내보낸 뒤의 값을 각각 비교합니다. 한 번의 정규화로 끝내지 말고 어느 변환 단계에서 문자가 바뀌었는지 찾습니다. 문자 코드가 같다면 검색 분석기·색인 시점·정렬 규칙 같은 다른 원인을 조사해야 합니다. 이 예제의 assert가 통과했다는 사실이 그 시스템의 검색 원인을 확정하지는 않습니다.

이 글의 입력·실행 자료

합성 자료의 실제 검증일은 2026-10-15입니다. 글의 예약 발행일과 구분합니다. 코드의 fixtureCreatedOn은 예제 작성일이고 executedAt은 재실행할 때의 실제 UTC 시각입니다. Python 3 표준 라이브러리를 사용합니다. 실제 고객정보나 새 Gemini 응답을 입력하지 않았습니다.

• 입력과 검사 코드(Python)
• 실제 실행 결과(JSON)

python3 invisible-unicode-copy-audit-lab.py

확인한 공식 원문

2026-10-15에 열어 확인했습니다. 제공 예제의 규칙과 공식 문서의 일반 기능 설명을 구분해 읽습니다.

• Unicode 정규화
• Unicode 문자분절
• MDN normalize

함께 대조할 기존 기록

• 한글·이모지 길이 계산 기준
• 정규화 뒤 파일 이름 충돌 확인