일반인들이 자유 소프트웨어를 두려워하는 이유
(danieldelaney.net)- 자유 소프트웨어의 복잡한 사용자 인터페이스(UI) 가 일반 사용자에게 진입 장벽으로 작용함
- 동영상 변환처럼 단순한 작업도 Handbrake 같은 도구의 전문가 중심 UI 때문에 일반인은 사용을 포기함
- 저자는 이를 해결하기 위해 Magicbrake라는 단일 버튼 인터페이스의 간단한 프런트엔드를 제작, ‘이상한 영상 파일을 정상적인 MP4로 변환’ 하는 기능만 제공함
- 복잡한 기능을 숨기고 대다수 사용자가 실제로 필요한 20% 기능만 노출하면 생산성과 만족도가 높아짐
- 자유 소프트웨어 생태계가 일반 사용자 친화적 설계를 채택해야 도구의 활용 범위가 넓어질 수 있음
자유 소프트웨어와 일반 사용자의 간극
- 일반 사용자는 비디오 변환, 업로드, 재생 같은 기본 작업에서도 포맷 문제로 어려움을 겪음
- QuickTime이나 Facebook에서 재생되지 않는 형식은 모두 ‘이상한’ 것으로 인식됨
- Handbrake는 강력하지만 전문 사용자 중심의 UI로 인해 일반 사용자가 불쾌감과 혼란을 느낌
- 이러한 문제는 FOSS(Free and Open Source Software) 전반에 만연하며, 결과적으로 일반 사용자는 사용을 포기하거나 전문가에게 도움을 요청하게 됨
Magicbrake 사례
-
Magicbrake는 Handbrake의 복잡한 기능을 숨기고, ‘이상한 비디오를 정상적인 MP4로 변환’ 하는 단일 기능만 수행
- 변환 결과는 대부분의 환경에서 작동하는 작은 MP4 파일
- 인터페이스에는 버튼 하나만 존재
- 이 접근은 빠르고 단순한 해결책으로, 복잡한 기능을 필요로 하지 않는 사용자에게 적합함
단순화에 대한 반론과 대응
- 일부는 “왜 Handbrake를 덜 강력하게 만들었느냐”, “다른 포맷이 필요하면?”, “특수 기능은?” 등의 의문을 제기
- 이에 대한 답변은 명확함: 고급 기능이 필요한 사람은 Handbrake를 그대로 사용하면 되고, 그렇지 않은 사람은 단순한 도구를 쓰면 됨
- 이는 TV 리모컨의 불필요한 버튼을 테이프로 가리는 것과 유사한 개념으로, 필요 시 기능은 여전히 존재하지만 기본 사용에는 방해되지 않음
단순한 UI의 가치
- 세상에는 일반인이 설정하기 어려운 미디어 서버, 기초 작업에도 학습이 필요한 오디오 편집기, 초보자를 배제하는 네트워크 모니터링 도구 등이 많음
- 이러한 도구들은 기능은 훌륭하지만 ‘모든 기능을 한 UI에 담으려는 설계’ 때문에 일반 사용자가 접근하지 못함
- 80%의 사용자는 20%의 기능만 필요하므로, 나머지를 숨기면 더 생산적이고 만족스러운 경험을 제공할 수 있음
개발자에게의 제안
- 일반 사용자를 위한 단순한 인터페이스 설계는 하루 저녁이면 가능한 일로, 실질적 가치가 큼
- 복잡한 기능을 모두 드러내는 대신, 필요한 기능만 노출하는 설계 철학이 자유 소프트웨어의 접근성을 높임
- 저자는 개발자들에게 이런 단순화된 도구를 더 많이 만들 것을 권장함
뭐만 하면 "man/readme/docs 부터 읽어라" 라는 대답이 나오는데
사실 UX에서 중요한 것은 그냥 써도 바로 사용법을 알 수 있는 것이거든요
뭐 돈 받고 하는 일이 아니니까 넘어가는 거지만 비개발자 사용자의 입장에서 생각해보면 사용 경험이 좋지 않은 것은 사실이죠
Hacker News 의견
-
좋은 글이지만 논리가 잘못되었다고 생각함
단일한 간결한 인터페이스를 만드는 건 결코 쉬운 일이 아님
특정 사용 사례에 맞춘 UI 구현은 어렵지 않지만, 그 ‘정확한 사용 사례’를 정의하고, 거기에 “이것만 조금 더 추가해 주세요”라는 요구를 막는 게 진짜 어려움
이런 단순함은 바람직하지만 불안정한 상태임- 개발자 세계는 비개발자용 좋은 인터페이스 설계의 어려움을 직관적으로 이해하지 못함
코드의 복잡성은 눈에 보이지만, UI의 복잡성은 보이지 않음
버튼과 입력창은 단순해 보이지만, 그 언어로 문제를 푸는 건 매우 복잡함
실패는 명확하지만 성공은 모호하고 사용자마다 다름
좋은 인터페이스는 많은 부분이 ‘암시적’으로 전달되며, 그게 가장 어려운 부분임 - 일반 사용자들이 “이 버튼이 X를 하게 해줄 수 있나요?”처럼 엉뚱한 요청을 자주 함
버튼이 본래 기능 Y와 거의 관련이 없어도, 그 버튼이 꼭 그 일을 해야 한다고 고집함
이런 식의 ‘조금만 바꿔주세요’ 요청이 쌓이면서 UI가 점점 복잡해지고 결국 무너짐 - 오픈소스 기여자들은 대부분 파워 유저라서 자신의 워크플로우가 잘 작동하는지에만 집중함
일반 사용자 80%의 사용성을 위해 자기 편의를 희생하려 하지 않음 - 이런 UI/UX 붕괴를 막는 방법으로 ‘feature freezing’을 제안함
기능 세트를 미리 정하고 이후엔 버그 수정과 효율 개선에 집중함
새 기능은 엄격한 검토를 거쳐야 추가 가능함
빠르게 변하는 소프트웨어엔 어렵지만, 대부분의 안정된 분야엔 효과적일 것이라 생각함 - 단기적으로는 사용자가 ChatGPT 같은 AI에게 “내 영상이 폰에서 재생되게 해줘”라고 묻고 단계별 안내를 받는 식으로 해결할 것 같음
장기적으로는 앱 자체가 AI를 통합해, 사용자가 원하는 UI를 자동 생성하는 방향으로 발전할 수도 있음
- 개발자 세계는 비개발자용 좋은 인터페이스 설계의 어려움을 직관적으로 이해하지 못함
-
이런 문제는 결국 익숙함의 문제라고 생각함
내 아내는 기술에 익숙하지 않지만 리눅스 사용자임
새 사업을 시작하며 Windows를 써야 했는데, 너무 불편해서 다시 리눅스로 돌아가길 원했음
나도 Mac vs PC에서 비슷한 경험을 함
Mac을 강제로 써야 했을 때 생산성이 10% 수준으로 떨어졌고, 너무 힘들었음
결국 사람은 자신이 익숙한 환경에서 가장 잘 일함- 중학생 때 가족 컴퓨터가 고장 나서 Ubuntu를 설치했는데, 엄마는 금방 적응했음
결국 ‘그냥 컴퓨터’일 뿐이었음 - 나도 Mac을 회사에서 받았지만 거의 쓰지 않음
다행히 VPN과 필요한 앱들이 Linux + 웹 인터페이스로 다 가능함 - 리눅스 데스크탑 보급 논의에서 익숙함의 중요성이 과소평가됨
상용 OS와 거의 동일한 UI를 제공하고, 터미널을 열 필요 없는 안정적인 배포판이 필요함
“비슷한 정도”가 아니라 세부적인 완성도가 중요함
- 중학생 때 가족 컴퓨터가 고장 나서 Ubuntu를 설치했는데, 엄마는 금방 적응했음
-
오픈소스 UI는 처음엔 낯설고 복잡하게 느껴짐
개발자 중심으로 만들어져 일반 사용자의 ‘놀라지 않게 해줘’ 원칙이 지켜지지 않음
하지만 꾸준히 쓰다 보면 새로운 철학에 익숙해지고 성공적으로 사용할 수 있음
나도 Firefox, LibreOffice, Avidemux, Virt-manager를 잘 쓰고 있음- 요즘은 Firefox와 Chrome의 차이가 거의 없다고 느낌
문제는 디자이너 인력 부족임
FOSS는 여유 있는 개발자들이 주로 참여하지만, 예술가나 디자이너는 상대적으로 적음
그래서 기본적인 수준의 UI만 제공되는 경우가 많음
- 요즘은 Firefox와 Chrome의 차이가 거의 없다고 느낌
-
무료 오디오 편집기 Audacity의 UX 문제는 디자이너가 이미 인지하고 있음
“모드”와 “Audacity says no” 문제를 해결하려는 UX 리디자인 영상을 올렸음
앞으로 개선될 예정이며, 오픈소스에서 좋은 UX는 여전히 부족하지만 변화 중임- UX는 가장 큰 부채임
처음엔 자기 쓰려고 만든 앱인데, 나중에 사람들이 “기능은 좋은데 UX가 별로”라고 함
반대로 UX를 개선하면 “기능이 부족하다”고 함
결국 모두를 만족시키려다 끝없는 리디자인 지옥에 빠짐
테마 엔진 같은 걸 만들다 프로젝트가 무너지는 경우도 많음 - 새 Audacity의 문제는 새 버전 자체가 아니라 기존 버전을 대체한다는 점임
만약 이름만 바꿔서 새로 냈다면 아무도 불평하지 않았을 것임
- UX는 가장 큰 부채임
-
이 문제의 해결책은 OS 수준의 표준화에 있다고 생각함
OS가 UI와 워크플로우를 일관되게 제공해야 함
예를 들어 “Handbrake” 대신 “Video Converter”라는 기본 앱이 있고,
“페이스북에서 재생되게 변환해줘” 같은 명령을 이해해 자동 설정을 적용하는 식임
앱 브랜드는 최소화하고, 사용자가 테마와 폰트를 완전히 제어할 수 있어야 함
GUI 기능과 연결되는 표준 쉘 언어도 필요함 -
사람들은 결국 기능을 원함
복잡한 UI라도 배우면 원하는 걸 할 수 있다면 감수함
단순한 옵션만 있는 소프트웨어는 시장이 작음
영상 포맷을 이해하지 못하는 사용자는 결국 웹사이트에서 “convert x to y”를 검색해 해결함
전문 툴을 쓸 정도면 이미 전문 사용자 영역임- 하지만 “복잡한 소프트웨어”가 꼭 필요한 건 아님
“파일을 여기 드롭하고 Fix It 누르기” 같은 단순 UI도 가능함
그게 바로 원글이 말한 요점이라고 생각함
- 하지만 “복잡한 소프트웨어”가 꼭 필요한 건 아님
-
오픈소스가 복잡한 이유는 여러 가지임
- 개발자가 자기 필요에 맞춰 만듦
- 옵션을 추가하는 비용이 낮음
- 사용자 조사를 하지 않음
- 설치할 수 있는 사람 자체가 이미 파워 유저임
- 예를 들어 Sonobus는 일반 사용자에게도 좋은 평가를 받음
하지만 대부분의 FOSS는 기술 문해력이 필요한 구조임
복잡한 소프트웨어를 배우는 게 오히려 장기적으로 효율적임 -
미니멀한 인터페이스를 유지하려면 많은 시간과 에너지가 필요함
오픈소스 개발자는 한정된 시간 안에 그걸 우선순위로 두기 어려움
-
Handbrake가 어렵다면 ffmpeg는 보여주지도 말라는 농담이 있음
나도 처음 Handbrake를 썼을 때 ffmpeg보다 훨씬 편하다고 느꼈음- ffmpeg는 대부분의 경우 구글에서 “ffmpeg로 X 하는 법”을 검색하면 바로 복사해 붙이는 명령어를 얻을 수 있음
반면 GUI 툴은 영상을 봐야 배움 - 단순 변환만 원한다면 ffmpeg는 가장 간단한 UI임
ffmpeg -i input.avi output.mp4한 줄이면 끝임 - 명령줄에 익숙한 사람에게는 ffmpeg가 Handbrake보다 단순함
Handbrake는 모든 옵션을 보여주지만 ffmpeg는 필요한 것만 입력함
익숙해지면 매우 정확한 제어가 가능함
“입력, 출력만 입력하면 끝”이라는 단순함이 오히려 매력임 - 나도 여전히 ffmpeg 변환 명령을 찾을 때 LLM 검색을 자주 씀
완벽하진 않지만 나보다 낫다고 느낌 - Handbrake는 오히려 프리셋 기반 워크플로우 덕분에 단순하다고 생각함
그래서 원글의 예시로는 조금 이상하다고 느낌
- ffmpeg는 대부분의 경우 구글에서 “ffmpeg로 X 하는 법”을 검색하면 바로 복사해 붙이는 명령어를 얻을 수 있음
-
나 같은 사람은 복잡한 인터페이스를 선호함
똑똑하다고 가정해주길 바람
자주 쓰는 툴일수록 복잡하더라도 빠르게 작업할 수 있는 게 좋음 -
문제는 모두가 서로 다른 20% 기능을 원한다는 점임
좋은 UI/UX는 테스터–디자이너–개발자–사용자 간의 긴밀한 피드백 루프가 필요함
FOSS는 그럴 자원이 부족함- 사실 80%의 일반 사용자는 비슷한 20% 기능만 원함
하지만 FOSS의 평균 사용자는 상위 1% 파워 유저라서 그걸 이해하지 못함
그래서 일반 사용자 중심으로 바꾸려 하면 커뮤니티의 반발을 삼 - FOSS는 애초에 “고객”을 위한 게 아닌 경우가 많음
개발자가 자기 필요로 만드는 거라, 사용자 만족이 목표가 아닐 수도 있음
그건 실패가 아니라 단순히 다른 목적임 - Handbrake 같은 경우 대부분은 단순히 영상 크기 줄이기만 원함
고급 기능은 일부만 사용함
그래서 기본 UI + 고급 모드로 나누는 게 현실적임 - FOSS의 피드백 루프는 자기 강화적임
이미 그 UI에 익숙한 사용자만 테스트하므로, “변경하지 말자”는 의견이 많음
반면 대형 기업은 새로운 사용자 대상으로 유료 사용자 테스트를 진행할 수 있음
그래서 UX 개선이 더 빠름 - FOSS 커뮤니티의 99%는 개발자임
UI/UX 전문가에게 기여를 요청하면 대부분 이해받지 못함
- 사실 80%의 일반 사용자는 비슷한 20% 기능만 원함
UI/UX의 복잡성이라고 표현할 수도 있지만,
자유든 상용이든 요즘 만들어지는 소프트웨어들은, 통과하는 딱 1가지의 경우만 통과하게 만들고 그 외의 경험들은 어떻게 되든 그다지 신경쓰지 않는 게 문제라고 생각합니다.
이를테면 toml이나 yaml configuration을 편집할때도 반드시 되어야 할 것 같은데 안될때가 있습니다. 이게 인코딩 문제인지 indentation문제인지, 아니면 특정 flag가 있을 때는 쓰지 못하는 기능인지 아닌지 이런 내용이 보통 제대로 문서화되어있지 않습니다. 사용자는 오만가지 케이스를 일일이 시도해보다가 어렵게 정답을 찾곤 합니다.
UI에서는 더 심각합니다. 흔히 password reset할때 경험하는 일이 밈처럼 퍼져 있듯이, 화면에 100가지의 필드가 있으면 상호간의 연관성이 어떤지, 어떻게 바꾸는 게 최적인지 "해 보지 않고서는 알 수 없습니다".
이건 UI/UX의 문제이기도 하지만 숨겨진 "전문성"의 문제이기도 합니다. 일종의 단계형 러닝커브가 준비되어 있지 않은 상태에서 전문성이 있는 사람이면 바로 정답을 기입할 수 있는 문제가, 초심자에게는 시험이나 관문처럼 수많은 거절을 경험하게 하는 역할을 하는 것이지요.
비슷한 맥락에서 CLI 보다 GUI 가 편하긴한듯 yt-dlp 도 yt-dlg 로 GUI 사용 중. ffmpeg 도 자주 쓰는 명령어 메모해두고 쓰는 중인데 GUI 만들수도 있겠군요
저는 개인적으로 비슷한 생각을 많이 해 봐서 꽤 공감이 가네요. WinXP~7 시절의 그림판, 메모장, 미디어 플레이어처럼 "그냥 슥 열어서 대충 쓰면 되는" 애플리케이션을 리눅스에서 찾아보려 했을 때, 5~6개씩 깔아 보고서야 맘에 드는 걸 찾으면 다행이었거든요.
스크린 샷 찍어서 오리기만 하면 되는데 Gimp를 쓸 순 없고, 뭐뭐 시도해봤는지 기억은 안 나지만 gtk 앱 중에 찾질 못해서 Kolourpaint로 결국 결론을 봤고요, 메모장은 Gedit이나 Kate, Mousepad, Leafpad, Xed 등등, 이보다 가벼운 걸 찾으려면 아예 사용자와 친해지기를 포기한 xedit, nano, vim 같은 걸 찾아야 되죠. 미디어 플레이어는 mpv, VLC, mplayer같은 거 생각만 해도 깝깝해지려 하네요.