아, 이 사소한 불편함들...
개발자들만 아는 '최적화 오류'에 대한 공감대 형성하기
일상 속의 불편함도 결국은 최적화라는 관점으로 보면 흥미로운 패턴이 발견된다.
정말이지, 가끔 우리가 겪는 사소한 짜증들이 사실은 '논리적 결함'에서 기인한다는 걸 깨달을 때가 있다.
예를 들어, 온라인 쇼핑몰에서 배송지 주소를 입력할 때 말이다.
주소 입력창이 A라는 필드에 동 이름을 넣으면, 그 정보를 기반으로 B라는 필드에 'OO동'이라는 이름이 자동으로 추천되거나 완성되어야 하는 게 상식 아닌가?
그런데도 불구하고, 마치 내가 그 정보를 기억 못 할 것처럼 빈칸으로 남겨두고, 심지어는 동일한 동 이름을 다른 필드에서 또다시 수동으로 타이핑하게 만드는 경험을 해본 사람 분명 있을 거다.
이게 단순히 '게으른 설계'라고 치부하기엔 너무 체계적이고, 어느 정도의 '의도적 비효율'처럼 느껴지기도 한다.
마치 이 시스템을 만든 사람이 '사용자는 이 정도의 수고를 감수할 수 있을 거다'라는 일종의 비현실적인 사용자 페르소나를 상정하고 설계한 것 같아서, 그 설계 의도 자체에 대해 깊은 회의감이 든다.
우리는 이미 충분히 많은 정보를 습득하고 처리할 수 있는 능력을 갖춘 존재들인데, 왜 시스템은 가장 단순한 '정보의 재활용'이나 '상태 유지(State Management)'라는 가장 기본적인 프로그래밍 개념조차 제대로 적용하지 못하는 걸까?
이런 경험들이 쌓이다 보면, 일상생활 자체가 하나의 거대한 '버그 리포트'를 작성하는 기분이 들 때도 있다.
이런 '작은 비효율'들에 대한 집단적 공감대라든지, 혹은 '이게 왜 이렇게 되어있지?'라는 무언의 질문들이 IT를 좋아하는 사람들 사이에서는 하나의 일종의 문화 코드가 되어버린 것 같다.
예를 들어, 어떤 프로그램에서 특정 기능을 사용하기 위해 A 메뉴에서 클릭하고, 다시 설정 창으로 이동해서 B 옵션을 끄고, 그 다음 C 메뉴로 가서 다시 활성화해야만 돌아가던 식의 복잡한 플로우가 있다고 가정해보자.
정상적인 사용자 경험(UX) 관점에서는 '이건 하나의 스위치로 해결되어야 하는 것 아니냐?'라는 질문이 바로 튀어나온다.
우리는 직관적인 인터페이스, 즉 '사용자의 생각의 흐름'을 시스템이 미리 예측하고 가장 짧은 경로로 안내해주기를 원한다.
그런데 현실은 그렇지 않다.
가장 최신 기술로 만들어진 제품일수록, 그 안에 내재된 '과도한 안전장치'나 '과도한 사용자 검증 단계'들이 오히려 사용자에게는 가장 큰 장벽이 되는 역설적인 상황을 자주 목격한다.
'혹시 실수할까 봐'라는 미명 하에 추가되는 팝업창이나, '이 기능을 사용하려면 반드시 이 사전 절차를 거쳐야 합니다'라는 안내 문구들은, 사실은 시스템의 설계자가 자신의 불안감이나 복잡한 내부 로직을 사용자에게까지 전가하고 있는 건 아닌가 하는 생각을 하게 만든다.
이처럼 일상 속의 모든 사소한 불편함 뒤에는, 우리가 당연하게 받아들이는 '규칙'이라는 것이 사실은 누군가가 만든 '임시방편적인 최적화의 실패작'일 수 있다는 지적인 쾌감을 느끼는 것이 아마도 IT 덕후들의 은밀한 즐거움이 아닐까 싶다.
우리가 겪는 사소한 짜증들은 결국 시스템 설계의 논리적 결함을 발견하는 즐거운 과정이다.
일상 속 불편함의 본질은 '최적화되지 못한 논리적 과정'을 발견하는 지적 유희에 있다.