터미널에 색이 너무 많다 — CLI 도구의 컬러 남용 문제를 생각해보자

화려한 터미널, 정말 읽기 쉬운가

최근 CLI 도구들의 출력을 보면 정말 다채롭습니다. ls 대신 exa나 eza를 쓰면 파일 타입별로 아이콘과 색상이 달라지고, git diff는 추가/삭제를 초록/빨강으로 표시하며, 빌드 도구들은 경고는 노랑, 에러는 빨강, 성공은 초록으로 칠합니다. 언제부턴가 터미널은 단색의 텍스트 인터페이스에서 무지개빛 화면으로 바뀌었습니다. 웹 개발자 Keith Cirkel이 제기한 문제는 바로 이것입니다. 우리가 터미널에서 색을 "너무 많이" 쓰고 있지 않은가 하는 것이죠.

이것은 단순한 미학적 취향의 문제가 아닙니다. 색상의 과도한 사용은 접근성(Accessibility) 문제를 야기하고, 때로는 정보 전달을 오히려 방해하며, 색각 이상을 가진 사용자에게는 도구 자체를 사용하기 어렵게 만들 수 있습니다.

색상이 정보를 해치는 순간

색상은 본래 정보 계층을 만드는 데 유용한 도구입니다. 에러는 빨간색, 경고는 노란색이라는 관습은 터미널을 처음 쓰는 사람도 직관적으로 이해할 수 있습니다. 문제는 이 유용한 도구가 지나치게 남용될 때 시작됩니다.

예를 들어 현대적인 linter의 출력을 생각해 보세요. 파일명은 하늘색, 줄 번호는 회색, 규칙 이름은 보라색, 에러 메시지는 빨간색, 컨텍스트 코드는 흰색... 한 줄의 에러 메시지에 다섯 가지 색상이 쓰입니다. 각각의 색이 개별적으로는 의미가 있을 수 있지만, 전체적으로 보면 "모든 것이 강조되면 아무것도 강조되지 않는" 상태가 됩니다. 이것은 디자인에서 말하는 시각적 위계(Visual Hierarchy)의 파괴입니다.

Keith Cirkel은 이 문제를 구체적으로 분석합니다. 많은 CLI 도구들이 색상을 사용할 때 실제 정보 전달 목적보다는 "보기 좋게 만들기" 위한 장식적 목적으로 사용한다는 것입니다. 파일 목록에서 .js 파일은 노란색, .ts 파일은 파란색, .json 파일은 초록색으로 표시하는 것이 정말 실용적인 정보인가요? 대부분의 경우 파일 확장자를 읽는 것으로 충분합니다. 색상이 추가적인 정보 가치를 제공하지 않으면서 시각적 복잡도만 높이는 셈입니다.

접근성이라는 현실적 문제

색각 이상(Color Vision Deficiency)은 생각보다 흔합니다. 남성의 약 8%, 여성의 약 0.5%가 어떤 형태로든 색각 이상을 가지고 있습니다. 개발자 팀이 10명이면 그 중 한 명 정도는 빨간색과 초록색을 구분하기 어려울 수 있다는 뜻입니다. git diff의 빨강-초록 표시가 이 개발자에게는 사실상 무의미한 정보가 됩니다.

터미널의 색상 문제를 더 복잡하게 만드는 것은 환경 의존성입니다. 같은 ANSI 컬러 코드라도 터미널 에뮬레이터(iTerm2, Windows Terminal, Alacritty 등)마다 실제로 렌더링되는 색이 다릅니다. 또한 사용자의 터미널 테마(다크 모드, 라이트 모드, Solarized 등)에 따라 텍스트의 가독성이 극적으로 달라집니다. 어두운 배경에서 잘 보이는 밝은 파란색 텍스트가 밝은 배경에서는 거의 읽히지 않을 수 있습니다. CLI 도구 개발자가 자신의 환경에서 아름답게 보이는 색상을 선택해도, 사용자의 환경에서는 전혀 다르게 보일 수 있는 것입니다.

더 나은 접근 방법은 무엇인가

이 문제에 대한 업계의 인식이 서서히 높아지고 있습니다. NO_COLOR(no-color.org)라는 이니셔티브는 CLI 도구들이 환경 변수 NO_COLOR를 인식하여 색상 출력을 비활성화할 수 있도록 하는 표준을 제안하고 있습니다. 이미 수백 개의 도구가 이 표준을 지원하고 있으며, 색상 출력에 민감한 사용자에게 간단한 해결책을 제공합니다.

하지만 근본적인 해결은 도구 개발자의 설계 철학에서 출발해야 합니다. 색상 사용에 대한 몇 가지 원칙을 생각해 볼 수 있습니다. 첫째, 색상은 유일한 정보 전달 수단이 되어서는 안 됩니다. 에러를 빨간색으로 표시하되, "error:"라는 텍스트 레이블도 함께 제공해야 합니다. 둘째, 장식적 색상 사용을 최소화해야 합니다. 색상이 실제로 사용자의 작업 흐름에 정보를 추가하는지 자문해 보는 것이 좋습니다. 셋째, 16색 팔레트(기본 ANSI 색상)를 우선 사용하고, 256색이나 True Color는 정말 필요한 경우에만 사용하는 것이 호환성 측면에서 유리합니다.

한국 개발자에게 주는 시사점

이 주제는 CLI 도구를 만드는 개발자뿐 아니라, 모든 개발자에게 유의미합니다. 우리가 만드는 소프트웨어의 출력이 색상에 의존하고 있지 않은지 점검해 볼 필요가 있습니다. CI/CD 파이프라인의 로그 출력, 사내 개발 도구의 콘솔 메시지, 혹은 단순히 디버깅 로그의 색상 처리까지 — 색상은 편의 기능이지 필수 정보 채널이 아닙니다.

실무 팁으로, 자신이 만드는 CLI 도구가 있다면 NO_COLOR 환경 변수 지원을 추가하는 것은 몇 줄의 코드로 가능합니다. Node.js의 chalk 라이브러리나 Python의 rich 라이브러리 등 대부분의 현대적 터미널 출력 라이브러리는 이미 이를 지원하거나 쉽게 설정할 수 있습니다. 또한 터미널 출력을 설계할 때 흑백 모드에서 먼저 정보 전달이 완전한지 확인하고, 그 위에 색상을 "보너스"로 얹는 접근이 좋습니다.