수십 개 앱의 라이브 스토어 문구가 실제 앱 기능과 맞는지 자동으로 검사하는 관문을 만들었습니다. "iPad를 지원한다"는 주장이 있으면 실제로 iPad 빌드가 되는지 대조하는 식입니다.
영어로 테스트했을 땐 잘 잡혔습니다. 다국어 로케일을 넣자마자 일본어와 폴란드어 문구가 통째로 검사망을 빠져나갔습니다.
당신의 검사 규칙은 몇 개 언어에서 검증됐습니까?
단어 경계가 원인이었습니다
\b 때문입니다. 파이썬의 단어 경계는 유니코드 기준으로 "무엇이 단어 문자인가"를 판단하는데, 기본 설정에서는 한자·가나·한글도 전부 단어 문자로 취급합니다.
"・iPad最適化UI" → "ipad" 뒤에 한자가 붙어서 경계가 안 생김
"・Apple Watchアプリ" → 마찬가지
"Układ … dla iPada" → 폴란드어 곡용 어미가 붙어 "ipada"가 한 단어영어 문구는 대부분 단어 뒤에 공백이나 마침표가 옵니다. 우연히 잘 잡혔던 것뿐이지, 경계 로직 자체가 다국어를 고려한 적이 없었습니다.
고친 형태는 경계를 ASCII 영숫자로만 제한하는 겁니다.
def T(*terms):
return "|".join(rf"(?<![a-z0-9]){t}(?![a-z0-9])" for t in terms)
T("ipad[a-z]*")
# "iPada"(곡용), "iPadOS"는 잡고 "flipada" 같은 부분 문자열은 안 잡음여기서 선택이 갈립니다
이걸 고치고 나면 다음 문제가 옵니다. 문구가 "지원한다"가 아니라 "지원하지 않는다"일 때입니다.
한국어·일본어·터키어·힌디어에서는 부정어가 대상어 뒤에 옵니다. "HealthKit 미사용", "HealthKit非連携" 처럼요. 매치 지점 앞쪽만 보고 부정을 찾는 로직은 이 언어들을 전부 놓칩니다.
당신이라면 매치 앞뒤를 다 뒤지겠습니까, 아니면 문장 전체에서 부정어를 찾겠습니까?
둘 다 함정이 있습니다. 여러 글자짜리 부정어는 문장 조각 전체에서 찾아야 하지만, 한자 부정어(不·未·非)는 한 글자라 전체 검색을 하면 엉뚱한 단어에 걸립니다. 그래서 한 글자 부정어는 매치 주변 몇 글자로 창을 좁혀야 했습니다.
나머지 두 함정
- 번역되는 단어는 각 언어 토큰을 직접 나열해야 합니다. "complication" 같은 기능명은 언어마다 완전히 다른 단어로 번역돼서, 원어 하나만 찾는 정규식으로는 절대 안 잡힙니다. 여기도 함정이 있습니다 — 번체 중국어의 특정 단어는 "위젯"과 "그냥 도구"라는 두 뜻을 다 갖고 있어서, 기계적으로 매칭하면 오탐이 납니다.
- 연락처는 먼저 지워야 합니다. 문구 안에 개인 이메일 주소 하나가 남아 있으면, 그 이메일이 들어간 모든 로케일이 "클라우드 동기화 기능이 있다"는 식의 엉뚱한 오탐으로 잡혔습니다. 이메일·URL 같은 식별자를 먼저 걸러내지 않으면 검사 결과 자체가 오염됩니다.
자가진단
- 정규식에
\b가 있습니까? 그걸 한자나 한글이 붙은 문자열로 테스트해봤습니까? - 부정문 탐지가 대상어 앞쪽만 보고 있지 않습니까?
- 검사 대상 텍스트에서 이메일·URL을 먼저 제거하고 있습니까?
솔직한 부분
이 관문을 다국어로 돌린 뒤, 실제로 여러 앱·여러 로케일에서 "만든 적 없는 기능"을 파는 문구가 잡혔습니다. 그중 일부는 스토어 문구 세 문장이 거짓이었던 사건과 같은 계보입니다.
불편한 부분은 이겁니다. 정규식을 영어로만 검증하고 넘어갔다면 그 결함들은 계속 안 보이는 채로 남았을 겁니다. 관문이 있었다는 사실은 아무것도 보장하지 않았습니다 — 관문이 초록불이었던 이유가 "문제가 없어서"가 아니라 "못 읽어서"였으니까요.
당신 코드에서 \b가 들어간 정규식 하나를 골라, 한자나 한글이 붙은 입력을 한 줄 넣어보세요.