터미널에서 대부분의 작업을 처리하는 개발자라면 한 번쯤 GUI와 TUI(터미널 사용자 인터페이스) 중 무엇이 더 나은가라는 논쟁을 접해봤을 것이다. 최근 해커뉴스에서는 "이제 TUI를 그만 만들고 GUI에 집중하자"는 취지의 글이 프런트페이지에 오르며 활발한 토론이 벌어졌다. 이에 대한 반론으로 한 개발자가 자신의 블로그에 정리한 글은, 흔히 오가는 논쟁의 한 축을 정면으로 반박한다. 바로 "TUI가 키보드로 조작되기 때문에 더 낫다"는 주장이다.
글쓴이는 GUI와 TUI 각각에 나름의 가치가 있다는 점을 인정하는 것에서 출발한다. 이론적으로 GUI 애플리케이션 프레임워크가 제공하는 기능은 TUI가 할 수 있는 일의 상위 집합에 해당하므로 GUI가 선호될 여지가 있다. 동시에 그는 자신을 터미널을 무겁게 사용하는 사람이라고 밝히며, 터미널 안에 머문 채로 모든 필요를 충족시켜 주는 TUI에 대한 애정도 감추지 않는다. 어느 한쪽을 무조건 옹호하는 대신, 잘못된 근거로 결론이 내려지는 상황을 문제 삼는 것이다.
키보드 조작은 TUI의 전유물이 아니다
핵심 논지는 이렇다. 무작위로 GUI 하나와 TUI 하나를 골랐을 때 후자가 완전히 키보드로 조작될 확률이 더 높은 것은 사실이다. 그러나 이 통계적 경향이 곧 "TUI를 개발하는 편이 낫다"는 결론으로 이어지지는 않는다. 그것이 드러내는 것은 오히려 상당수 GUI 애플리케이션에서 키보드 내비게이션이 부실하게 구현되어 있다는 현실일 뿐이다. GUI가 원리적으로 키보드 조작을 배제하는 것은 전혀 아니기 때문이다.
실제로 여러 GUI 프레임워크의 애플리케이션 가이드라인은 개발자에게 애플리케이션의 전체 기능을 아우르는 키보드 내비게이션을 제공하라고 명시적으로 권장한다. 글쓴이는 그 예로 GNOME 휴먼 인터페이스 가이드라인을 든다. 이 문서는 포인팅 장치로 수행할 수 있는 모든 동작은 키보드로도 수행 가능해야 하며, 사용자 인터페이스의 모든 부분을 키보드만으로 이동하고 상호작용할 수 있어야 한다고 규정한다. 다시 말해 완전한 키보드 조작은 GUI 설계 원칙에 이미 포함되어 있는 요구사항이지, TUI만이 달성할 수 있는 특성이 아니다.
구현하지 않았을 뿐, 못 하는 것이 아니다
사용자 입장에서 이 차이는 선택의 유인이 된다. 마우스에 손을 옮기지 않고도 직관적이고 예측 가능하게 화면을 오갈 수 있다면, 같은 기능을 제공하는 다른 애플리케이션 대신 그 프로그램을 고를 이유가 생긴다. 글쓴이는 개발자의 관점에서도 이를 강조한다. 자신의 첫 GUI 애플리케이션인 Klisi를 만들면서 사용 가능한 모든 동작을 대상으로 키보드 단축키를 구현하는 데 시간을 들였다고 밝힌다. 그의 결론은 명료하다. 대부분의 경우 키보드 내비게이션 구현은 그리 어렵지 않으며, 그것은 실현 가능성의 문제가 아니라 개발자의 의지의 문제라는 것이다.
이 글이 한국의 실무자에게 주는 시사점은 프레임워크 선택 논쟁을 넘어선다. 우리는 종종 어떤 도구의 장점을 그 도구가 속한 범주 전체의 본질적 우위로 착각한다. TUI가 키보드 친화적인 경향이 있다는 관찰과, TUI라는 형식이 키보드 친화성을 보장한다는 주장은 전혀 다른 명제다. 전자는 관측된 경향이고 후자는 인과의 오해다. 데스크톱 애플리케이션을 만드는 팀이라면, 툴킷의 한계 탓으로 돌리기 전에 접근성 지침을 얼마나 충실히 따랐는지를 먼저 점검해 볼 필요가 있다.
다만 글의 주장에는 스스로 인정하는 한계도 있다. 저자는 각주를 통해 마우스로 얻어지는 정밀한 조작이 일부 작업에서는 여전히 선호되거나 심지어 필수라는 점을 명시한다. 즉 "완전한 키보드 조작 지원"은 마우스를 배제하자는 뜻이 아니라, 키보드만으로도 모든 기능에 도달할 수 있는 경로를 함께 보장하자는 뜻이다. 또한 GUI냐 TUI냐를 가르는 더 설득력 있는 기준으로는 이식성의 용이함 같은 요소가 따로 있으며, 키보드 조작 여부는 그 저울을 기울이는 근거가 되지 못한다고 선을 긋는다.
결국 이 글은 특정 UI 형식을 옹호하기보다, 사용자 경험을 형식의 문제로 미루지 말라는 요청에 가깝다. 키보드만으로 전체 기능을 다룰 수 있게 만드는 일은 GUI에서도 충분히 가능하고, 그것을 갖춘 애플리케이션은 더 나은 경험을 제공한다. 도구의 범주 뒤에 숨는 대신 자신이 만드는 소프트웨어의 완성도를 스스로 책임지라는 것이, 개발자 모자를 쓴 글쓴이가 남긴 실질적인 메시지다.