TUI

텍스트 기반 사용자 인터페이스(Text-based User Interface). CLI와는 다르다. 문자를 의미의 표현 뿐 아니라 레이아웃의 표현에도 이용하는, 일종의 그래픽 사용자 인터페이스이다. 쉽게 말해 CLI와 GUI의 중간 성격을 가진 인터페이스라고 보면 된다.

중간 성격이라고 했는데, 사실 CLI의 장점 대부분을 가져오면서 GUI의 꼭 필요한 장점들만 골라다 만든 인터페이스라고 보면 되겠다. TUI가 대두된 초창기 때라면 몰라도 지금 컴퓨팅 환경에서 보통 GUI에 비해 TUI가 압도적으로 가벼운 것은 물론이다. 그 가벼움은 컴퓨터에 가해지는 연산량 자체는 물론[1], 네트워크 환경에서도 통용되는 이야기라 지금도 원격 접속을 통한 작업을 할 땐 vim/Emacs에다 (GNU)screen/tmux 조합의 TUI 환경에서 작업한다. 트래픽이 압도적으로 적어서 웬만한 네트워크 환경에서 쾌적하게 작업할 수 있다.[2] 물론 이건 CLI의 장점인데, 그러면서도 GUI처럼 레이아웃을 통하여 일목요연하고 직관적인 방식으로 정보를 보여줄 수 있다. 위의 vim 스크린샷을 보면 이해가 될 것이다. 특히 TUI라고 발전이 안 된 건 절대 아니라서 더 이상 흰색 문자 혹은 녹색 문자 일변도가 아닌 맨 위 vim 스크린샷처럼 알록달록한 색상을 지원하고 이를 통해 작업의 효율을 더 높일 수 있다. 거기다 원격접속한 시스템과 밀착성도 좋다.[3]

이렇게 말하면 GUI보다 훨씬 좋아 보이겠지만 TUI에 명백한 한계가 존재한다는 건 이미 다들 짐작하고 있을 것이다. 아무리 그래도 완전한 그래픽 환경과는 영 거리가 멀다는 것이다. GUI의 꼭 필요한 장점들만 골랐다고 했는데, 그게 코딩이나 고급 시스템 관리 같은 것에 꼭 필요한 장점이고, 완전한 (즉 도트 단위까지 다루는) 그래픽 환경은 당연히 불필요하기 때문이다. 이 환경에서 당연히 사진이나 그림, 동영상 같은 멀티미디어는 꿈도 못 꾼다.[4][5] 당연히 게임이나 웹 서핑도 굉장히 제한적이다. 단적인 예로 아래의 w3m을 생각해 보자. 물론 포토샵 같은 그래픽 작업은 말할 것도 없을 것이다. 다만 이렇게 한계로 제시한 것들은 사실 TUI가 필요할 만한 영역과 애초부터 거리가 멀다. 반대로 TUI의 강점들은 사실 단일 클라이언트 상의 멀티미디어 환경에서 신경쓸 만한 사항이 아니다. 즉 서로 잘 커버하는 영역이 다르고 어느 한 쪽이 반대 쪽 영역까지 다 커버하는 게 힘들거나 그럴 필요가 없을 뿐이다.[6] 따라서 어느 한 쪽이 우월하다느니 논하는 건 별 의미 없다.

TUI의 단점을 더 꼽자면, CLI와 GUI의 중간 성격이라는 게 TUI 프로그램 개발에도 적용된다는 것이다. GUI 프로그램을 짜는 것보단 덜 난감하겠지만 CLI 프로그램보다 더 복잡한 건 당연한 일이겠다. 물론 TUI 짤 때나 GUI 짤 때나 애초부터 사용자의 편의성을 고려하면 고려할 수록 프로그래밍 하기가 어려워진다는 사실이 똑같이 적용되는 것일 뿐이겠지만. 단점이라기보단 약간 여담이겠지만 사용하는 터미널 에뮬레이터를 많이 탈 수 있다. 사실 터미널 에뮬레이터도 굉장히 많으며 이들이 지원하는 것도 제각각이다. xterm(-color256)이 사실 상 표준이긴 한데 색상을 지원하지 않는 에뮬레이터를 쓰게 되면 최신의 TUI 환경이 보여주는 강점들 상당수가 희석될 것이다. 게다가 색상을 지원하는 에뮬레이터들도 색상 셋(set)이 제각각인 것이 나름 문제일 수도 있다. 예를 들어 iTerm2에서 이쁘게 설정한 색상 설정을 다른 에뮬레이터에서 돌리면 더러운(...) 색상으로 표현될 수도 있다.

레이아웃의 표현에 사람이 읽을 수 있는 문자를 이용하기도 하지만, Extended ASCII에 이미 레이아웃의 표현을 위한 블록, 선 등이 준비되어 있다. ASCII Table 요즘에는 유니코드를 이용하긴 하지만 대신에 아예 터미널 에뮬레이터에서 사용되는 폰트 자체를 바꿔서 레이아웃에 필요한 문자들을 마련할 수 있다. Powerline font를 zsh과[7] vim, tmux에서 쓰는 것이 대표적으로, 적절한 색상 세팅과 더불어 상당히 미려한 환경을 제공해 준다.


유니코드 이전에는 영문 이외의 언어셋에서는 깨져 나오는 일이 많았다. 다른 언어셋에서는 자국어 표현을 위해 이 영역을 사용하기 때문. 당장 1990년대에 한글 DOS에서 Mdir을 구동시키면 선이 모두 이상한 문자쳐컴컴컴컴컴컴캑로 깨져 나왔는데, 완성형 코드가 아스키 코드의 이 영역을 사용하여 2바이트로 확장하여 사용하는 구조였기 때문에 충돌이 일어나는 것이다. 유니코드가 일반화된 지금은 아예 다른 영역을 사용하기 때문에 이런 일은 거의 없다.

CLI에서는 줄 또는 문자열을 한 버퍼의 단위로 이용한다. 따라서 화면상에 표시할 때 줄 또는 문자열의 추가가 매우 효율적이다. 반면 TUI에서는 화면 전체를 한 버퍼의 단위로 이용한다. 버퍼의 용량이 매우 큰 대신 버퍼의 좌표와 화면의 실제 좌표를 1대 1로 대응시킬 수 있다. 사용자 측면에서 가장 큰 차이점은 상하좌우 방향키를 모두 사용할 수 있다는 점이다.

CLI에서는 문자를 오로지 의미의 표현에만 이용한다. 즉, 화면의 모든 문자는 의미를 가지고 있다.

대표적인 CLI 프로그램

반면, TUI는 문자를 내용으로서의 의미 뿐 아니라 화면 위 레이아웃의 표현에도 이용한다. 즉, 문자를 이용한 그래픽 사용자 인터페이스라고도 할 수 있다.

대표적인 TUI 프로그램