▲

“알파벳 순서”라면 정말 “알파벳 순서”를 말하는 거야

 (sebastiano.tronto.net)
1P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 사진 파일을 알파벳순으로 정렬하려 했으나 운영체제와 파일 관리자의 정렬 결과가 다름
  • 리눅스 ls에서는 정상적으로 정렬되지만, Windows, Google Drive, KDE Dolphin 등 대부분의 GUI 파일 매니저는 숫자를 포함한 파일명을 수치적으로 해석하는 “자연 정렬(natural sort)” 을 적용함
  • 이로 인해 file-10.txt가 file-9.txt보다 앞에 오는 등, 전통적인 문자열 정렬과 다른 결과가 발생함
  • 실제 문제의 원인은 두 휴대폰이 다른 파일명 규칙을 사용해, 하나는 초 뒤에 밀리초를 바로 붙이고 다른 하나는 언더스코어로 구분한 탓에 정렬 기준이 달라진 것
  • 결국 해결책은 파일명 규칙을 통일하거나 각 파일 관리자의 숨겨진 설정을 수정하는 것뿐이며, 글쓴이는 “컴퓨터가 사용자의 지시보다 추측을 우선하는 시대”를 아쉬워함

배경 및 문제 상황

  • 글쓴이는 아버지와 하이킹을 하면서 각자의 Android폰으로 사진을 찍은 뒤, 모든 사진을 하나의 폴더에 저장함
  • 사진 파일명의 규칙은 IMG_YYYYMMDD_HHmmss 혹은 그 뒤에 추가 숫자와 .jpg가 옴
  • 이런 파일명은 연월일과 시간 순서로 되어 있으니, 파일을 알파벳순(사전순)으로 정렬하면 촬영 시간순으로 정렬될 것으로 생각함
  • Windows PC, Google Drive, KDE Dolphin 등을 사용할 때, 동일한 규칙의 파일들이 순서대로 정렬되지 않음
    • 예: 아버지 폰으로 찍힌 5:54 사진이 9:20 사진보다 먼저 나오고, 12:11 사진 이후에 위치함 등 제대로 정렬되지 않는 문제 발생
  • Gnome, 스마트폰의 다른 파일 관리자 등도 결과가 동일함
  • 리눅스 ls 명령에서는 올바른 순서를 유지해 혼란 가중

원인 분석

  • 처음에는 두 폰 중 하나가 언더바(_) 대신 특이 문자를 썼을 것이라 생각했으나, Linux 명령어 ls로 확인하니 정상 정렬됨
  • 다양한 Linux 배포판, OpenBSD 서버에서도 ls는 올바르게 알파벳순 정렬함
  • 이에 반해 다수의 GUI 파일 관리자(Windows, Google Drive, KDE Dolphin 등)은 파일명에 숫자가 있을 경우 진짜 숫자 크기로 비교함
    • 알파벳 순서 대신 자연 정렬(natural sorting) 을 기본 적용
  • 자연 정렬은 문자열 속 숫자를 단순한 문자값이 아닌 숫자값으로 비교
    • 예: file-9.txt < file-10.txt → 사람이 기대하는 순서
    • 그러나 전통적 정렬은 1 < 9라서 file-10.txt가 앞섬
  • 하지만 요즘 파일 관리자는 "숫자부"가 있으면 그 부분을 숫자의 실제 값으로 해석해 9가 10보다 앞서 오도록 강제로 정렬함
    • 파일명을 만든 사용자가 의도한 순서와 달라질 수 있음

실제 문제의 원인 및 해결법

  • 아버지의 폰은 밀리초 숫자를 초 뒤에 바로 붙이고, 본인 폰은 언더바로 구분해서 표기함
    • 아버지 폰: 초 뒤에 바로 밀리초를 붙임 → 숫자가 커져 뒤로 밀림
    • 본인 폰: 언더스코어로 구분 → 별도 문자열로 처리됨
  • 해결법: 둘 중 한 쪽의 파일명을 일관된 패턴으로 재정렬하면 문제 해결됨
  • KDE Dolphin의 경우 옵션에서 순수 알파벳순 정렬을 선택할 수 있으나, 설정이 숨겨져 있어서 번거로움
  • 여러 프로그램마다 기능이 다르므로 매번 별도 설정 필요할 수 있음

글쓴이의 결론

  • “알파벳 순서”를 지정했음에도, 소프트웨어가 사용자의 의도를 추측해 다른 정렬을 적용하는 것을 비판
  • 과거처럼 컴퓨터가 지시된 대로만 동작하던 단순한 방식이 그리움
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • Microsoft, Google, KDE가 채택한 정렬 방식이 더 직관적이고 흔하게 사용되는 케이스를 커버한다고 생각함, 작성자의 상황은 극히 드물다고 판단함, 대부분의 사람들은 “10”이 “9” 다음에 오기를 바라는 상황이 훨씬 많다고 느껴짐, 데스크탑 환경은 정렬을 “알파벳순”이 아닌 “이름순”으로 표기하므로 오해가 없음, 컴퓨터가 의도를 읽으려 하는 게 싫긴 하나 자동저장 같은 기능처럼 그런 게 실생활에서 유용함, 진짜 알파벳 순 정렬 옵션도 있으면 좋겠지만 기본값은 보편적인 경우가 직관적임이 맞음

    • 나 역시 “10”이 알파벳 순서상 “9”보다 먼저 온다는 걸 충분히 이해할 수준의 스마트함은 있음, 하지만 파일 매니저에서는 “9” 다음에 “10”이 오길 원함, 한 자릿수 숫자 앞에 0을 붙이는 것도 싫고, 나중에 세 자리가 필요한 경우 다시 이름을 바꾸는 것 또한 번거로움, 오디오북 파일을 챕터별로 나누고 모든 플레이어가 올바로 정렬하지 못할 것을 염두에 두어 “Chapter 01.mp3” 혹은 “Chapter 001.mp3” 포맷을 씀, 자동화 스크립트도 만들었지만 그래도 보기 안 예쁘고 불필요한 작업임, 모든 기기가 숫자를 제대로 인식해주면 정말 더 좋겠음
    • 나는 동의하지 않음, 문자로 숫자를 표현하는 유일하고 보편적인 방법이 있다면 납득할 수 있을 것임, 하지만 숫자 입력 방식에 변형이 많아 “의도 읽기” 기능이 일부 경우에만 적절히 작동한다고 봄, 소수점·천 단위 구분자·과학적 표기법 등은 복잡한 예외 사항이 있어서, 요구조건을 따져보면 신뢰성 있는 방식으로 구현하기 힘듦을 알게 됨
    • 사람들이 0을 미리 붙이는 게 자연스럽고 익숙하다는 주장이 현실적이지 않다고 느낌, 예를 들어 버전 5.9.17에서 5.10.0으로 바뀔 때, 이전 폴더명을 모두 5.09.17로 다시 바꾸는 이는 없음, 오늘날 표준 정렬 방식은 모호하지 않고 직관적인데, 엄격한 문자순 정렬은 사용자인터페이스에는 적합하지 않음
    • 문제는 이런 변화가 오래된 “멍청한” 알파벳순 정렬과 달라서 사람들에게 놀람과 혼란을 준다는 것임, 대다수가 원하는 “스마트한” 방식과 “엄격한 알파벳순”을 별도의 옵션으로 나눠서 제공했으면 더 좋았을 것임, 단순명확하게 옵션을 고를 수 있게 하면 비전문가도 경험이 혼란스럽지 않음
    • “10”이 “9”보다 먼저 오길 원하는 경우가 더 흔하다고 했지만, 아마 그 반대를 말하려던 듯함, 그리고 “이름순” 정렬 공식 이름은 “Natural sort order”임을 참고로 알려줌

  • 이 주제는 “Worse is better” 논쟁을 떠올리게 됨, 작성자가 요구하는 ANSI/Unicode 기반 단순 정렬 방식은 오히려 소수의 개발자만 필요로 하는 기능임, 실제로는 99%의 GUI 사용자가 직관적 정렬을 원함, 주 사용자를 파악하는 것이 제품 설계에 아주 큰 영향을 줌, 더 나은 기능은 제품에 어울릴 수 있지만, 시스템에는 성장과 진화를 위한 간단함이 더 어울릴 수도 있음

    • 개발자의 마음속 모델은 혼합숫자가 들어간 이름을 순수하게 나이브하게 처리하는 방식임, 반면 일반 사용자는 10이 9 뒤에 오는 걸 자연스럽게 생각함, 개발자만의 사고방식을 모두에게 강요하면 곤란함
    • “더 안 좋은” 방식이 필요하다 주장하는 사람에게 대소문자 정렬 방식은 어떻게 생각하는지 궁금함, 진짜대로 ASCII/Unicode 코드포인트 순서를 따를지, 아니면 하나의 문자로 정규화해서 대소문자 같이 묶을지
    • “타겟 유저층”이라는 핑계로 옵션 추가를 안 하는 것은 설득력 없음, 양쪽 방식을 모두 제공하는 건 어렵지 않은 일임, 고급 모드에 넣어서라도 다양한 요구를 수용하는 소프트웨어가 진짜 더 좋은 프로그램임, 80/20 법칙처럼 일부만이 쓰는 기능도 필요함, 완벽한 사용자 비전에 맞춘다는 명분으로 당연한 기능도 누락되는 현실에 지침을 느낌

  • 해시값으로 이름 붙인 파일을 찾을 때 자동 정렬이 제일 불편함, 윈도우에서는 레지스트리로 바로 끄는 몇 안 되는 옵션임, 과거 컴퓨터가 시키는 대로만 동작할 때가 그립다는 생각을 자주 함, 요즘은 “사용자 마음을 읽는 것”이 아니라 “생각까지 바꾸려고 드는 것” 같아 꺼려짐, 오픈소스도 포함해서 “유저가 틀렸다”는 독단적 마인드에 불만임

    • 이 문제는 단순한 해시가 아니라 중간에 의미 없는 숫자가 끼어있는 여러 식별자에서도 더 혼란을 야기함, 유저ID, 유닉스 타임 등 숫자 덩어리를 가진 파일을 찾아야 할 때, abcd89764237과 abcd683426834가 눈에 띄게 위치가 이상해서 한참 찾고서야 이유를 알게 되는 불편함

  • 모든 사람이 평균적인 사용자의 니즈를 안다고 주장하면서, 왜 정작 컴퓨터가 파일 이름 자체를 원하는 대로 자동으로 바꾸게 하자는 의견은 없냐는 의문이 듦, 아스키 정렬을 강제하지 않을 거면 확장자를 포함한 파일명에도 얽매일 필요가 없음, 실제로 유저는 jpg, png 확장자가 중요하지 않고 대소문자 구분도 신경을 안 씀, 윈도우 계열에서만 오래된 호환성 때문에 확장자를 사용한 적이 많았음, "컴퓨터식 파일이름"은 강요하면서 왜 "컴퓨터식 정렬"만 고집스럽게 깨는지 의아함, 유저가 뭘 원하는지 알 수 없으니 단정 짓지 말아야 함

  • 나는 대부분 지금 기사에서 설명한 버전 기반 정렬이 더 좋다고 느낌, 알파벳순 정렬로 표시하는 게 버그처럼 느껴질 정도임, 정렬의 개념이 아니라 라벨링이 문제라고 봄

    • 실제로는 “알파벳순”이라고 설명하지 않음, 작성자가 “이름순”을 “알파벳순”이라고 오해한 것임
    • 설명된 동작은 유용하지만, 사용자에게 미리 알리거나 옵션을 선택하게 하는 게 정답임
    • 리눅스의 sort 명령어도 현재는 버전 정렬(sort -V)을 지원함, 내부 동작은 잘 모르겠지만 대부분 상황에서 잘 작동함, 무엇보다 쉽게 on/off가 가능함
    • 기사에서 언급한 정렬 방식은 “lexical”인데 사람들이 “lexical”과 “alphabetic” 차이를 평균적으로 모름

  • 파일을 “알파벳순”으로 정렬하라고 명령하는 것이 아니라 “이름순” 정렬을 요구하는 것이니, 해석은 OS마다 다를 수 있음, 대부분 사용자 입장에서 더 적합한 해석을 논리와 데이터에 따라 선택했다 생각함, 아마 미래엔 숫자 그룹에 0이 있으면 원래 알파벳순을 사용하는 등의 규칙이 추가되거나, 사용자 선택 옵션이 생길지도 모름

    • 숫자 앞에 0이 있으면 8진수로 간주하고 뒤 숫자가 0~7일 때만 동작한다면 직관적일 것 같음
    • 하지만 이런 해석 변화가 10~20년 전부터 바뀐거라, 예전에는 파일매니저마다 “이름순”이 곧 “알파벳/사전순”이었음

  • macOS Foundation에서는 Finder 정렬에 사용되는 NSString.localizedStandardCompare()를 공식적으로 제공함, Windows도 StrCompareLogical을 제공함, 즉 이름순(즉 자연정렬) 기준을 각 플랫폼에서 공식화하고 있음

    • ls 명령과 다를 줄 알았기에 흥미로웠고, 이제는 이 방식이 더 낫다고 생각하게 됨, 사진 앱에는 일반적으로 타임스탬프로 정렬하고, 파일이 정말 이름순 정렬이 필요하다면 생성일로 정렬하거나 아예 파일명을 직접 정규화할 것임

  • Unicode 보고서에서 언어별로 문맥에 따라 정렬 방식이 달라짐을 명확히 언급함, 예: "A-10"을 숫자를 인식하지 않고 알파벳순으로 정렬하면 “A-10”이 “A-2”보다 앞에 옴, 복잡하지만 파일 브라우저들이 이런 이유로 자연정렬 방식을 택한 게 맞다고 생각함

    • 근데 -10이 -2보다 작은 거니까 순서가 바뀌지 않을까 하는 의문 제기

  • “foo9”가 “foo10”보다 앞에 오게 정렬하는 게 “natural sort”임, 최근에 파이썬 2줄짜리 코드로 자연정렬 방법을 알게 되어 매우 만족함, 관련 스택오버플로우 코드 추천

    • sort(1) 명령에서도 자연정렬(-V)를 지원함, 이미지 파일을 만들고 ls | sort -V로 정렬하면 제대로 동작함, du -sh * 결과도 sort -h 옵션으로 정렬 가능함

  • “Image-1.jpg, Image-11.jpg, Image-2.jpg” 식으로 섞이는 정렬 방식이 그립지 않음, 자연정렬이 어색했던 기억도 있지만, 윈도우에서 숫자값으로 정렬하게 바뀌고 정말 편했음, 파일이 자연스럽게 정렬되어 상당히 만족했음

    • 하지만 사람에 따라 이 순서가 기대한 모습이니 본인에게 달렸다는 의견도 있음
답변달기