# 사라지는 폴란드어 Ś의 기묘한 사례 (2015) > Clean Markdown view of GeekNews topic #30946. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30946](https://news.hada.io/topic?id=30946) - GeekNews Markdown: [https://news.hada.io/topic/30946.md](https://news.hada.io/topic/30946.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-30T07:49:38+09:00 - Updated: 2026-06-30T07:49:38+09:00 - Original source: [aresluna.org](https://aresluna.org/the-curious-case-of-the-disappearing-polish-s/) - Points: 1 - Comments: 1 ## Topic Body - Medium 웹 편집기에서 폴란드어 대문자 **Ś**만 입력되지 않던 버그는 입력 관습, PC 수입 환경, 저장 단축키 습관, Windows의 Right Alt 처리 방식이 겹치며 발생함 - 폴란드어는 라틴 알파벳에 9개 발음 구별 문자를 더해 쓰며, 초기 PC 환경에서는 전용 키보드 대신 **Alt+라틴 문자** 조합을 쓰는 “programmer’s layout”이 사실상 표준이 됨 - Windows가 Right Alt를 내부적으로 **Ctrl+Alt**처럼 매핑하면서, Ś 입력에 쓰이는 Right Alt+S가 시스템 관점에서는 Ctrl+Alt+S처럼 보이게 됨 - Medium은 브라우저 저장 대화상자를 막으려고 Ctrl+S를 가로채 `preventDefault()`를 호출했지만, Alt 여부를 확인하지 않아 **문자 입력 자체**를 막아버림 - 수정은 Ctrl+S 차단 조건에 `!e.altKey`를 더하는 작은 변경이었고, 영어 26자 중심의 컴퓨팅 관습이 다른 언어 사용자에게 예외와 마찰을 만들 수 있음을 보여줌 --- ### Medium에서 사라진 Ś - 한 사용자가 Medium에서 폴란드어 글을 쓰기 시작했을 때 다른 글자는 입력되지만 **Ś**만 입력되지 않는다고 보고함 - Medium은 특정 언어를 특별 취급하지 않았고, 폴란드어 32개 문자 중 왜 이 글자 하나만 문제가 되는지 처음에는 이상해 보였음 - 원인은 단일 기능의 결함이 아니라, 수십 년에 걸친 **입력 방식과 운영체제 처리 방식**이 겹친 결과였음 ### 폴란드어와 추가 문자 - 폴란드어는 러시아어 다음으로 많이 쓰이는 슬라브어이며, 우크라이나어보다 앞섬 - 러시아어·우크라이나어와 달리 폴란드어는 영어/라틴 알파벳을 기반으로 하되 몇 가지 문자를 추가함 - 원래 폴란드어 단어에는 Q, V, X가 없지만, 라틴어와 차용어를 위해 유지됨 - 대신 라틴 문자를 바탕으로 한 **9개 발음 구별 문자**를 추가로 사용함 - 20세기 초 타자기는 이 추가 문자를 수용해야 했고, 일부 문자는 별도 키를 얻었지만 나머지는 숫자 키와 공유됨 - 대문자는 라틴 문자 입력 뒤 백스페이스로 돌아가 악센트를 덧입히는 방식으로 “시뮬레이션”되기도 함 - 추가 글자 공간을 마련하기 위해 세미콜론과 괄호 같은 문장부호가 희생되기도 함 ### 공산권 폴란드의 PC 환경과 programmer’s layout - 1980년대 폴란드의 초기 개인용 컴퓨터 환경은 **가처분 소득 부족**과 서구 컴퓨터의 상업적 수입 금지라는 제약을 안고 있었음 - 서구에서 들어온 컴퓨터는 원래 설명서, 번역되지 않은 소프트웨어, 미국식 키보드를 그대로 갖춘 경우가 많았음 - 프랑스와 독일 같은 국가는 타자기 배열을 반영한 맞춤 키보드를 받았지만, 폴란드는 미국식 키보드에서 9개 추가 문자를 입력할 방법을 찾아야 했음 - Ctrl은 이미 단축키로 널리 쓰였고 Alt는 상대적으로 덜 쓰였기 때문에, **Alt 조합**이 사실상 표준으로 자리 잡음 - 8개 발음 구별 문자는 대응하는 라틴 문자에 배정됨 - 나머지 하나는 가까운 위치의 키에 배정됨 - 기존 배열은 “typist’s layout”, 새 방식은 “programmer’s layout”으로 불림 - 초기 PC 사용자가 주로 프로그래머였기 때문일 수도 있음 - 프로그래밍에서 자주 쓰는 문장부호를 그대로 보존했기 때문일 수도 있음 - programmer’s layout은 왼쪽 Alt 하나로 가까운 키를 같은 손으로 눌러야 해 **인체공학적으로 불편**했지만, 하드웨어 개조나 스티커 없이 이해하기 쉬웠기 때문에 정착함 - 이후 전용 typist’s keyboard가 등장했지만 거의 아무도 바꾸지 않았고, 덜 이상적인 QWERTY가 널리 자리 잡은 상황과 비슷한 흐름을 보임 ### Ctrl+S 습관과 웹 편집기의 충돌 - 자동 저장이 일반화되기 전에는 문서를 직접 저장하는 습관이 중요했음 - 1980~1990년대의 저장 작업은 느리고, 디스크 같은 매체를 조금씩 닳게 하며, 때로는 CPU를 강하게 점유해 다른 일을 하기 어렵게 만들었음 - 사용자는 글을 쓰다가 숨을 돌릴 때마다 **Command+S** 또는 **Ctrl+S**를 누르는 습관을 익힘 - 어떤 사람은 문단마다 눌렀음 - 어떤 사람은 문장마다, 나중에는 몇 단어마다 눌렀음 - 웹 기반 편집기에서 이 습관은 브라우저의 현재 웹페이지 HTML 저장 대화상자를 띄우는 문제로 이어짐 - Medium도 과거에 이를 막기 위해 편집기 코드에서 Ctrl+S 또는 Command+S를 감지해 저장을 호출하고 기본 동작을 막았음 ```js if ((e.metaKey || e.ctrlKey) && e.keyCode === goog.events.KeyCodes.S) { this._editors.save() e.preventDefault() } ``` - 이 코드는 Mac의 `metaKey` 또는 Windows/Linux의 `ctrlKey`와 S가 함께 눌리면 편집기 저장을 실행하고, 브라우저 저장 대화상자를 막음 - 문제는 일부 환경에서 폴란드어 Ś 입력이 단순한 Alt+S처럼 보이지 않았다는 점임 ### Windows의 Right Alt 처리 방식 - Windows 3.x와 Windows 95는 메뉴 항목과 대화상자 컨트롤을 **Alt+밑줄 문자**로 빠르게 접근할 수 있게 했음 - 폴란드에서는 Alt가 이미 발음 구별 문자 입력에 쓰이고 있었기 때문에 Windows 단축키와 충돌함 - 키보드가 발전하면서 스페이스바 오른쪽에 보조 Alt 키가 생겼고, 왼쪽 Alt는 Windows 단축키에, 오른쪽 Alt는 폴란드어 입력에 쓰는 방식이 가능해짐 - 하지만 Right Alt 기능은 Alt 키가 하나뿐인 오래된 키보드에서도 가능해야 했기 때문에, Microsoft는 Windows 내부에서 Right Alt를 드물게 쓰이는 **Ctrl+Alt 동시 입력** 조합으로 매핑함 - 이 결정 때문에 폴란드어 Ś 입력에 쓰이는 Right Alt+S는 시스템 관점에서 Ctrl+Alt+S처럼 보이게 됨 - Medium의 Ctrl+S 차단 코드는 Alt가 함께 눌렸는지 확인하지 않았고, 결과적으로 Ś 입력을 저장 단축키 차단 처리처럼 가로막음 ### 수정: Alt가 눌렸을 때는 Ctrl+S로 보지 않기 - 원인이 파악된 뒤 수정은 간단했음 - Ctrl+S를 무조건 막는 대신, Ctrl이 눌렸더라도 Alt가 눌리지 않았을 때만 막도록 조건을 바꿈 ```js if ((e.metaKey || (e.ctrlKey && !e.altKey)) && e.keyCode === goog.events.KeyCodes.S) { this._editors.save() e.preventDefault() } ``` - 변경 후 Right Alt+S 입력은 Ctrl+S 저장 차단 조건에 걸리지 않음 - Medium은 이 버그를 수정했고, 해당 조건문에는 이후 사람이 이해할 수 있도록 많은 주석이 붙게 됨 ### 작은 조건문 뒤의 더 큰 문제 - 폴란드에서는 1989년에 공산주의가 무너졌고, 이제 컴퓨터는 개인과 회사 모두 합법적으로 수입할 수 있음 - 현재 폴란드에서 구매하는 Windows와 Mac은 폴란드어를 완전히 지원하고 운영체제도 현지화되어 있음 - 그럼에도 시스템 설정에는 여전히 programmer’s layout이 있으며, 두 배열 중 가장 흔히 쓰이는 쪽으로 남아 있음 - 이 작은 버그는 미국식 컴퓨팅 관습이 영어의 **26개 비강세 문자**를 중심으로 발전해 온 현실과 연결됨 - 폴란드어는 QWERTY의 파생 배열 사이를 옮겨 다니며 타협해야 했고, 영어와 더 멀리 떨어진 문자 체계를 쓰는 언어들은 더 불리한 조건에 놓일 수 있음 ## Comments ### Comment 60759 - Author: neo - Created: 2026-06-30T07:49:39+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48706814) - 폴란드어가 라틴 문자를 쓰고, 추가 음가만 작은 슬라브식 변형으로 표현한 덕분에 폴란드가 **서방 지향**으로 맞추기 훨씬 쉬웠다고 봄 평균적인 폴란드인은 우크라이나인이나 러시아인보다 서쪽 이웃들과 문화적으로 훨씬 가깝고, 아마 요리만 예외일 수 있음 - 카자흐스탄도 러시아보다 유럽 쪽에 더 맞추려고 **키릴 문자에서 라틴 문자로 전환**하기로 했음 [https://www.bbc.com/worklife/article/20180424-the-cost-of-ch...]() 먼 미래에 우크라이나도 같은 길을 갈지 궁금함 - 라틴 문자 채택 자체가 **비잔틴권이 아니라 라틴권 왕국들**과 맞추려는 서방 지향 선택이었고, 정교회가 아니라 가톨릭을 받아들인 것과도 연결됨 - 대략 정리하면, 10세기에 Mieszko가 체코 공주 Doubravka/Dobrawa와 결혼하면서 기독교가 폴란드에 들어온 것처럼, Jan Hus가 체코어를 정리하려던 노력에서 나온 **체코 문자**, 즉 라틴 문자도 받아들였음 학자들은 비슷한 시기에 폴란드어가 별도 언어로 발전하기 시작했다고 보고, 13세기까지는 남쪽 이웃들과 큰 문제 없이 의사소통할 수 있었음 15~16세기에 폴란드어 정서법이 형성됐고, Stanisław Zaborowski와 Jan Kochanowski는 당시 폴란드어 음운을 더 정확히 반영하려고 글자를 도입하려 했는데 제안한 알파벳은 꽤 길었음 분할 점령기에는 폴란드어와 문화를 없애려는 강한 **러시아화**가 있었고 키릴 문자 도입 시도도 있었지만 결국 실패했으며, 당시 문학은 애국심과 조국애를 주제로 한 작품이 많았음 1936년 언어 개혁으로 오늘날 아는 형태에 가까워졌고, 공산주의 시기에는 체코어·슬로바키아어의 vykání처럼 공적 언어에서 2인칭 복수가 도입됐지만 부자연스럽고 정치색이 강해 오래가지 못했음 폴란드어에는 방언이 있지만, 2차대전 이후 이주로 차이가 흐려지면서 **표준 폴란드어**도 그 시기에 굳어졌고, 오늘날에는 영어 차용어가 많아져 hater가 hejter처럼 자연화되기도 함 - **가톨릭**이라는 점도 도움이 됨 - 폴란드 요리는 **독일 요리**와 매우 비슷함 이 말은 많은 폴란드인을 꽤 화나게 할 것임 - 진짜 문제는 브라우저가 **키 조합을 확인하는 간단한 방법**을 노출하지 않고, 개발자들도 직접 만들지 않는다는 데 있음 많은 사이트에서 의도한 키 조합이 alt나 shift 같은 추가 보조키가 붙어도 같이 실행됨 여기 나온 코드도 Windows에서 더 큰 문제만 고칠 뿐, alt+cmd+s는 여전히 막힘 브라우저가 keydown/up/press 이벤트에 "CTRL+S", "CTRL+ALT+S" 같은 키 조합 코드를 담은 속성을 노출하자는 제안이 필요함 그러면 개발자는 키 코드와 보조키를 직접 확인하는 대신 그 속성으로 분기할 수 있음 웹 개발자들도 자기 코드 안에서 이런 속성을 직접 만들어 보조키를 직접 검사하는 대신 비교하면 좋겠음. 원글 같은 버그도 막고 쓰기도 훨씬 편해짐 - 이 버그는 사용자가 Control S를 눌러 저장 대화상자가 뜨는 문제를 고치려던 개발자가 **근본적이고 버그 나기 쉬운 동작**을 건드리면서 생긴 것임 개발자들이 더 쉽게 개입할 수 있는 선택지를 더 많이 갖게 되면 얼마나 큰 피해를 낼지 상상해 보라 키를 가로채야 한다면 이미 저수준 API가 있으니 거기서 끝내는 편이 낫다 한편 HTML에는 바로 가기 키를 지정할 수 있는 **accesskey 속성**이 있음: [https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...]() - 새 **Copilot 365**도 딱 이럼. "Ć"를 입력하려고 할 때마다 Copilot이 튀어나와서 앱을 계속 닫아야 함 - 이런 사소한 일 하나하나가 새로운 **Linux 사용자**를 만들어냄 전환한 뒤로는 한 번도 뒤돌아보지 않았음 SteamOS에서 작성함 - MSFT의 바보들이 자기네 API도 모르는 게 당연함 [https://devblogs.microsoft.com/oldnewthing/20040329-00/?p=40...]() - 학교에서 시험 보는 중에 같은 일을 겪었음. 헝가리어 키보드에서 &를 입력하려 했는데, 그것도 물론 **altgr+c**였음 - 예전에 alt+c가 "ć" 대신 **ATI Catalyst Control Center**를 실행하던 걸 기억함? - 제일 좋은 점은 묻지도 않고 자동으로 설치된다는 것임 고마워요 Microsoft. 품질 보증이 잘 돌아가는 걸 보니 좋네요 - 재미있는 사실: 유니코드 **정준 분해 정규화**를 적용하면 폴란드어 글자 9개 중 8개(ż, ó, ć, ę, ś, ą, ź, ń)는 기본 글자 + 결합 발음 구별 기호로 분해되지만, **ł**은 그대로 남음 그래서 sqlite의 unicode61 remove_diacritics 토크나이저로는 폴란드어 텍스트를 전체 텍스트 검색용으로 정규화할 수 없음 - 면접 과제로 코드를 쓰다가 그걸 발견한 기억이 있음. 이유는 단순한데, Mac에서 쓰는 ABC International 같은 여러 입력 시스템에서는 ł 입력이 두 글자 순서로 되어 있어도 실제로는 l을 가로지르는 선에 해당하는 **결합 문자**가 없기 때문임 확실하진 않지만 sqlite의 remove_diacritics는 내가 직접 구현했던 방식처럼 NCD로 변환한 뒤 문자열에서 결합 문자를 제거하는 식일 것 같음 ħ나 ø처럼 분해되지 않는 다른 특수 사례도 비슷하게 동작할 것으로 예상함 - 폴란드어 사용자가 “ł”로 검색할 때 “l”도 같이 나오길 기대할까? - > Polish is the second most-used Slavic language, right after Russian and just before Ukrainian 우크라이나어에 관해서는 정확히 맞는 말은 아님. 우크라이나의 공식 언어이긴 하지만 현실에서는 모든 우크라이나인이 실제로 **우크라이나어**를 말하는 건 아니라고 해야 함 - 2019년으로 시계를 되돌려도 우크라이나어를 쓰는 사람은 충분히 많음 Lviv = 250만 Vinnytsia = 150만 Ivano-Frankivsk = 130만 Khmelnytskyi = 120만 Rivne = 110만 Ternopil = 100만 Volyn = 100만 Chernivtsi = 80만 Zakarpattia = 80만(헝가리계는 뺐음) 이러면 우크라이나어 사용자가 압도적인 **서우크라이나인 1,120만 명**이고, 나머지 지역을 완전히 무시해도 체코어 화자 수보다 많음. 게다가 나머지 지역도 완전히 러시아어권이 아니었고 지금은 더더욱 아님 - 그 “조정”은 우크라이나어보다 화자가 많아서 러시아어와 폴란드어 뒤의 3위가 될 다른 **슬라브어**를 제시하지 않았으니, 순위에는 아무 변화가 없음 - 안타깝게도 Medium만 그런 게 아니라 여러 Windows 앱도 마찬가지임. 예를 들어 **Active Presenter**에서는 글자 하나, 아마 Ó를 입력하면 화면 녹화가 멈춰서 폴란드어로 타이핑하는 장면을 녹화할 수 없는 상황이 많아짐 다른 앱들도 비슷하게 Alt + Ctrl + 글자 조합을 바로 가기로 배정해서 키보드 레이아웃 드라이버를 어떻게든 덮어쓰는 듯함 - 2026년인데도 갑자기 Mac용 **Edge**에서 대문자 Ś를 입력할 수 없게 됐음. 25년쯤 과거로 돌아간 느낌임 - 나도 **Teams**에서 같은 걸 봤음. 둘 다 MS 앱이라 그런 건가? - **nvidia overlay**에는 Alt+Z 바로 가기가 있는데, 왼쪽 Alt와 오른쪽 Alt 모두에서 동작해서 폴란드어 사용자는 오버레이를 열거나 키를 다시 지정하지 않으면 “ż”를 입력할 수 없어 꽤 짜증남 Nvidia 제발 고쳐줘 - 요약하면 이렇다: > Ctrl S를 무턱대고 탐욕스럽게 막는 대신, Alt 키가 눌리지 않았을 때만 Ctrl S를 막으면 됐음 폴란드어 S의 키보드 바로 가기가 Ctrl alt s였고, 저장 동작을 개선하려고 Ctrl s를 막으면서 **ctrl alt s**까지 같이 막아버린 것임 - 아님. 바로 가기는 **alt+s**였고 사람들이 실제로 누른 것도 그거였음 Windows에서는 이미 Alt 조합을 쓰고 있었기 때문에 오른쪽 Alt+s가 됐고, 오른쪽 Alt는 Windows 자체에서 쓰지 않았지만 별도 오른쪽 Alt 코드 대신 Windows가 그 키를 ctrl+alt 조합으로 다시 써버렸음 요약하려면 최소한 가장 중요한 세부사항은 맞춰야 함. 사람들은 Alt만 눌렀는데 Windows가 “이제 ctrl+alt를 누르는 중”이라고 바꿔서, alt+s가 ctrl+s처럼 보이고 이벤트를 가로채 죽일 때 아무도 확인하지 않는 Alt가 붙게 된 것임