TUI
덤프버전 :
분류
독일의 저가 항공사에 대한 내용은 TUI fly 독일 문서 참고하십시오.1. 개요[편집]
텍스트 기반 사용자 인터페이스(Text-based User Interface). CLI와는 다르다. 문자를 의미의 표현 뿐 아니라 레이아웃의 표현에도 이용하는, 일종의 그래픽 사용자 인터페이스이다. 쉽게 말해 CLI와 GUI의 중간 성격을 가진 인터페이스라고 보면 된다.
중간 성격이라고 했는데, 사실 CLI의 장점 대부분을 가져오면서 GUI의 꼭 필요한 장점들만 골라다 만든 인터페이스라고 보면 되겠다. TUI가 대두된 초창기 때라면 몰라도 지금 컴퓨팅 환경에서 보통 GUI에 비해 TUI가 압도적으로 가벼운 것은 물론이다. 그 가벼움은 컴퓨터에 가해지는 연산량 자체는 물론[1]트래픽이 압도적으로 적어서 웬만한 네트워크 환경에서 쾌적하게 작업할 수 있다.[2] 물론 이건 CLI의 장점인데, 그러면서도 GUI처럼 레이아웃을 통하여 일목요연하고 직관적인 방식으로 정보를 보여줄 수 있다.
이렇게 말하면 GUI보다 훨씬 좋아 보이겠지만 TUI에 명백한 한계가 존재한다는 건 이미 다들 짐작하고 있을 것이다. 아무리 그래도 완전한 그래픽 환경과는 영 거리가 멀다는 것이다. GUI의 꼭 필요한 장점들만 골랐다고 했는데, 그게 코딩이나 고급 시스템 관리 같은 것에 꼭 필요한 장점이고, 완전한 (즉 도트 단위까지 다루는) 그래픽 환경은 당연히 불필요하기 때문이다. 이 환경에서 당연히 사진이나 그림, 동영상 같은 멀티미디어는 꿈도 못 꾼다.[3][4] 당연히 게임이나 웹 서핑도 굉장히 제한적이다. 단적인 예로 아래의 w3m을 생각해 보자. 물론 포토샵 같은 그래픽 작업은 말할 것도 없을 것이다. 다만 이렇게 한계로 제시한 것들은 사실 TUI가 필요할 만한 영역과 애초부터 거리가 멀다. 반대로 TUI의 강점들은 사실 단일 클라이언트 상의 멀티미디어 환경에서 신경쓸 만한 사항이 아니다. 즉 서로 잘 커버하는 영역이 다르고 어느 한 쪽이 반대 쪽 영역까지 다 커버하는 게 힘들거나 그럴 필요가 없을 뿐이다.[5] 따라서 어느 한 쪽이 우월하다느니 논하는 건 별 의미 없다.
TUI의 단점을 더 꼽자면, CLI와 GUI의 중간 성격이라는 게 TUI 프로그램 개발에도 적용된다는 것이다. GUI 프로그램을 짜는 것보단 덜 난감하겠지만 CLI 프로그램보다 더 복잡한 건 당연한 일이겠다. 물론 TUI 짤 때나 GUI 짤 때나 애초부터 사용자의 편의성을 고려하면 고려할 수록 프로그래밍 하기가 어려워진다는 사실이 똑같이 적용되는 것일 뿐이겠지만. 단점이라기보단 약간 여담이겠지만 사용하는 터미널 에뮬레이터를 많이 탈 수 있다. 사실 터미널 에뮬레이터도 굉장히 많으며 이들이 지원하는 것도 제각각이다. xterm(-color256)이 사실 상 표준이긴 한데 색상을 지원하지 않는 에뮬레이터를 쓰게 되면 최신의 TUI 환경이 보여주는 강점들 상당수가 희석될 것이다. 게다가 색상을 지원하는 에뮬레이터들도 색상 셋(set)이 제각각인 것이 나름 문제일 수도 있다. 예를 들어 iTerm2에서 이쁘게 설정한 색상 설정을 다른 에뮬레이터에서 돌리면 더러운(...) 색상으로 표현될 수도 있다.
레이아웃의 표현에 사람이 읽을 수 있는 문자를 이용하기도 하지만, Extended ASCII에 이미 레이아웃의 표현을 위한 블록, 선 등이 준비되어 있다. ASCII Table 요즘에는 유니코드를 이용하긴 하지만 대신에 아예 터미널 에뮬레이터에서 사용되는 폰트 자체를 바꿔서 레이아웃에 필요한 문자들을 마련할 수 있다. Powerline font를 zsh과[6], tmux에서 쓰는 것이 대표적으로, 적절한 색상 세팅과 더불어 상당히 미려한 환경을 제공해 준다. 또한, Nerd Fonts를 통해 아이콘 구현도 가능하다. 이쪽은 Powerline Font의 기능도 포함되어 있어서 Powerline Font만 쓰고 싶을 때도 사용 가능하다.
유니코드 이전에는 영문 이외의 언어셋에서는 깨져 나오는 일이 많았다. 다른 언어셋에서는 자국어 표현을 위해 이 영역을 사용하기 때문. 당장 1990년대에 한글 DOS에서 Mdir을 구동시키면 선이 모두 이상한 문자로 깨져 나왔는데[7], 완성형 코드가 아스키 코드의 이 영역을 사용하여 2바이트로 확장하여 사용하는 구조였기 때문에 충돌이 일어나는 것이다. 유니코드가 일반화된 지금은 아예 다른 영역을 사용하기 때문에 이런 일은 거의 없다.
2. 관련 항목[편집]
이 문서의 내용 중 전체 또는 일부는 2023-11-04 02:34:45에 나무위키 TUI 문서에서 가져왔습니다.[1] 이게 현대에도 은근히 중요한 게, 특히 다수의 사용자가 단일 노드(node)에 접속하여 작업하는 상황에선 이러한 가벼움이 중요해질 것이다. 100명이 동시 접속해서 작업을 하는데, 모두 TUI을 쓰는 상황과 모두 GUI를 쓰는 상황을 (그것도 그래픽 인터페이스의 렌더링까지 죄다 서버가 도맡는 상황을) 생각해 보자. (다만 이건 너무 극단적인 비교이다. 아래 주석에서 FTP를 활용한 예로 들었듯이 GUI를 활용하는 개발을 생각할 수 있다.) 연구 환경이라든가 서버 호스팅 같은 곳에서 많이 일어나는 상황이다.[2] 반대의 예를 들어 윈도우즈 원격 접속을 한 경우를 생각해 보자. 아무리 네트워크 환경이 좋아도 버벅거린다는 느낌이 든다.[3] iTerm2 같은 일부 터미널에서는 그림을 출력해 주기도 하지만 이건 TUI의 범주 바깥이고 터미널 에뮬레이터 자체의 독자적인 기능일 뿐이다.[4] ImageMagick 같은 걸로 간단하고도 일괄적인 이미지 조작 작업을 할 수 있긴 하다.그래 봤자 제한적인 건 분명하고 무엇보다 결과물은 당연히 GUI에서 봐야겠지만.[5] 다만 GUI는 지속적으로 TUI가 할 수 있는 것들을 많이 가져오고 있는 중이다. 사실 터미널에서 원격접속으로 코딩하는 것 말고도 로컬에서 적당한 GUI 코드 편집기를 통해 코딩 작업을 한 다음 이걸 FTP로 보낼 수도 있다. vim/Emacs가 워낙 강력해서 이들이 여전히 널리 쓰이고 있긴 하지만.[6] 단, powerline font를 전혀 안 쓴 테마들도 많다.[7] 단일 괘선은 旼컴컴컴컴컴커, 쳐컴컴컴컴컴켁, 읕컴컴컴컴컴켸 등의 방식으로 깨지고, 이중 괘선은 袴袴袴袴袴敲, 훤袴袴袴袴袴暠 등의 방식으로 깨졌다. 특히 완성형의 0xC9(╔ )에는 한글 한자 모두 배당되어 있지 않던 공백 영역이었다. 그래서 0xC9CD의 처리는 바이오스마다 달라서 그야말로 개판 5분전이었다. 유니코드 문자 는 윈도우에서 0xC9CD를 아무런 변환 없이 복붙했을 때 나온다.