헬게스버(Helgesver)라는 닉네임을 쓰는 연구자는 macOS 15.6 환경에서 AI 에이전트(Claude)의 agent-desktop 기능을 이용해 텍스트 에디터(TextEdit)에 'well fuck this shit, damn it.'을 삽입하고 개별 키 입력으로도 시험하는 실험을 진행했습니다. 그러나 시스템 내부의 VulgarWordUsage.db 파일에는 새로운 행이 추가되지 않았고, 파일의 마지막 수정 시각도 변하지 않았습니다 1. 이는 macOS가 비속어를 무조건 차단하기 때문이 아닙니다. 이 시스템이 기록하는 것은 사용자가 욕설을 '친' 사건 자체가 아니라, 키보드가 욕설을 다른 말(예: 'ducking')로 바꾸려 '했을 때' 사용자가 이를 거절하고 원래 단어를 유지한 순간이기 때문입니다 1.

macOS는 단어 자체를 금지 목록으로 처리하는 대신, 앱과 수신자라는 맥락을 파악해 자동 수정의 개입 정도를 조절합니다. 친구와의 메신저 대화에서는 자연스럽게 허용되던 표현이 상사에게 보내는 메일에서는 수정 대상이 될 수 있습니다. 이러한 차이가 어떻게 발생하며, 시스템이 어떤 기준으로 사용자의 의도를 학습하는지 그 구조를 자세히 살펴봅니다.

입력을 금지하는 것이 아닌 '추천'을 조절하는 사전

입력을 금지하는 것이 아닌 '추천'을 조절하는 사전

macOS의 키보드 자동 수정 로직을 이해하려면 시스템이 단어를 분류하는 사전(Lexicon)과 사용자가 단어를 사용할 때마다 쌓이는 학습 데이터베이스를 명확히 구분해야 합니다. 헬게스버는 비공개 시스템 프레임워크인 Lexicon.framework를 분석하여 애플이 내부적으로 단어에 부여하는 플래그를 추출했습니다. 조사 결과, 미국 영어(en_US) 사전 항목 199,019개 중 4,271개가 비속어와 관련된 플래그로 분류되어 있었습니다 1. 애플이 공식 문서에서 이 분류를 명시하지 않았기 때문에, 이 이름들은 단어들의 실제 사용 맥락과 시스템 코드 내의 인접한 열거형을 역추론하여 붙인 결과입니다 1. 이 분류는 크게 세 단계로 나뉩니다.

  1. vulgar (욕설 및 성적 속어): 'fuck', 'shit', 'crap' 등 1,050개 단어로 구성됩니다. 가장 직접적인 욕설들이 여기에 속합니다 1.
  2. offensive (집단 멸칭): 특정 인종이나 사회 집단을 겨냥한 모욕적인 표현 663개입니다. 'asshole'이나 'Oriental' 등이 포함됩니다 1.
  3. sensitive (민감 표현): 'damn', 'abortion', 'gun', 'suicide' 등 약물, 정치, 질병, 신체 기능 등 일상 대화에서 선제적인 추천을 피할 만한 표현 2,558개입니다 1.

흥미로운 점은 이 플래그들이 사용자의 입력을 강제로 차단(검열)하는 데 쓰이지 않는다는 사실입니다. 사용자가 단어를 직접 쳐서 입력하면 시스템은 이를 그대로 받아들입니다. 조사자는 이 분류 체계가 키보드 QuickType(예측 입력) 막대에서 해당 단어를 미리 제안하지 않도록 억제하는 용도로 쓰이는 것으로 보인다고 설명합니다 1. 즉, 사용자가 먼저 입력하여 불러오지 않는 한, 키보드가 먼저 욕설을 제안하지 않도록 관리하는 셈입니다. 이 외에도 11개의 주제별 비트마스크(배설, 정치, 종교 등)가 별도로 존재하여 단어의 성격을 더욱 세분화합니다 1.

같은 'fuck'이라도 맥락이 다르면 별개의 기록으로

같은 'fuck'이라도 맥락이 다르면 별개의 기록으로

사전 플래그가 키보드의 '선제적 추천 억제'를 담당한다면, 사용자가 의도적으로 비속어를 사용할 때의 자동 수정을 관장하는 것은 별도의 로컬 데이터베이스입니다. ~/Library/Keyboard/VulgarWordUsage.db가 바로 그 파일로, 사용자가 언제, 어디서, 어떤 맥락에서 비속어를 유지했는지를 학습합니다 1.

이 데이터베이스의 기록 방식은 단순히 '욕설 사용'이라는 사실만 저장하지 않습니다. vword_usage 테이블의 고유 인덱스는 다음 네 가지 요소의 조합으로 구성됩니다 1.

  • 앱 식별자: 메시지(Messages) 앱, 메일(Mail) 앱 등 프로그램을 구분합니다.
  • 수신자 식별자: 대화 상대방의 고유 식별자를 기록합니다.
  • 비속어 자체: 사용된 단어의 종류를 저장합니다.
  • 발음 표기 형태: 단어를 읽는 형태(주로 일본어 등 읽기 형태가 중요한 언어에서 중요)입니다.

이러한 (앱, 수신자, 단어, 발음) 4중 키 구조 덕분에, 같은 'fuck'을 입력하더라도 메시지 앱에서 특정 '친구'에게 보낸 것과 메일 앱에서 '상사'에게 보낸 것은 시스템 내부에서 별개의 항목으로 구분될 수 있습니다 1.

시스템 내부에는 set_current_app_id, set_current_recipient_ids 같은 함수가 존재하여 현재 사용자가 입력 중인 맥락을 파악합니다 1. 자동 수정의 후보를 평가하는 단계에서는 every_vulgar_word_is_allowlisted라는 함수를 통해 해당 (앱+수신자) 맥락에서 비속어를 허용할지 판단합니다 1. 한번 "허용된 맥락"으로 학습되면, 시스템은 사용자의 입력을 강제로 수정하지 않으며 'ducking'과 같은 모호한 대체 표현이 우선적으로 제시되지 않습니다 1.

왜 욕설을 입력했는데 학습되지 않았을까?

사용자들은 보통 욕설을 입력할 때마다 시스템이 이를 학습한다고 생각하기 쉽습니다. 하지만 앞서 언급한 헬게스버의 실험 결과(철자가 정확한 문장 입력 시 데이터베이스 변화 없음)는 기록의 트리거가 '단어 입력'이 아님을 명확히 보여줍니다 1.

실제 데이터베이스 기록은 다음 두 조건이 동시에 충족될 때만 발생합니다 1.

  1. 자동 수정의 개입: 시스템(AppleSpell)이 사용자가 친 비속어를 'ducking' 같은 대체 표현으로 바꾸려는 수정 제안을 제시했을 때.
  2. 사용자의 거절: 사용자가 그 제안을 무시하고 원래의 욕설을 유지했을 때.

실험에서 입력한 'well fuck this shit, damn it.' 문장은 모든 단어의 철자가 정확했습니다. 철자에 오류가 없으므로 시스템은 수정 제안(오타 교정이나 자동 완성 제안)을 할 이유가 없었고, 결과적으로 사용자가 거절할 제안 자체가 발생하지 않았습니다 1. 제안이 없었으니 increment_usage_count 함수가 호출되지 않았고, 데이터베이스에는 아무런 변화가 없었던 것입니다 1.

즉, macOS는 사용자가 '자동 수정의 간섭을 이겨내고 욕설을 지켰을 때' 비로소 "이 사용자는 이 맥락(예: 친구와의 채팅)에서 이 단어를 고집한다"라고 학습합니다. 애플은 2023년 6월 WWDC에서 iOS 17의 자동 수정이 사용자가 가장 자주 쓰는 단어, 욕설을 포함해 학습한다는 계획을 발표한 바 있습니다(TechCrunch) 2. macOS의 VulgarWordUsage.db가 앱과 수신자 단위로 이력을 분리하는 구조와는 직접적인 선후 관계가 출처에 명시되지 않지만, 두 시스템 모두 '사용자가 고집하는 단어를 존중한다'는 같은 방향성을 공유합니다.

조용히 꺼져버릴 수 있는 기능

조용히 꺼져버릴 수 있는 기능

이런 정교한 학습 구조가 모든 Mac에서 항상 작동하는 것은 아닙니다. macOS 환경에서는 이 기능이 조용히 무력화될 수 있습니다.

가장 대표적인 원인은 데이터베이스 파일의 부재입니다. VulgarWordUsage.db가 저장되어야 할 ~/Library/Keyboard 폴더가 일부 macOS 설치 환경에서는 기본 생성되지 않은 채 설치될 수 있습니다 1. SQLite 데이터베이스 엔진은 데이터베이스 파일이 없으면 이를 새로 생성하지만, 상위 폴더가 존재하지 않으면 생성에 실패합니다 1. 이때 시스템은 no such file or directory 오류를 내부적으로 기록하지만, 사용자에게 별도의 오류 팝업을 띄우지 않고 기능을 비활성화한 채 정상 동작을 이어갑니다 1.

따라서 사용자가 욕설을 사용해도 키보드가 고집스럽게 다른 단어를 제안하거나, 맥락과 무관하게 항상 수정한다면 폴더 부재로 인한 데이터베이스 생성 실패가 원인일 수 있습니다. 이를 해결하려면 사용자가 직접 ~/Library/Keyboard 폴더를 만들고 시스템 자동 수정 서비스(AppleSpell)를 재시작해야 합니다 1.

macOS가 같은 욕설을 수신자와 앱에 따라 다르게 취급하는 것은 사전 플래그에 의한 추천 제어와, (앱, 수신자) 단위로 분리된 사용자 거절 이력이 겹쳐 작동하기 때문입니다. 다만 이 판단 기준은 사용자의 '수정 거절' 행동에만 의존하며, 데이터베이스 생성 조건이 충족되지 않을 경우 맥락 인식이 불가능할 수 있다는 점까지 함께 고려해야 합니다. 이 시스템은 '검열'보다는 '맥락에 맞는 자동 완성의 억제'에 더 가까운 정교한 개인화 도구인 셈입니다.

참고자료

  1. ↩
  2. ↩