터미널은 256색 팔레트를 자동 생성해야 한다

• 256색 팔레트를 사용자의 base16 테마에서 자동 생성하도록 제안하는 글로, 터미널의 색상 일관성과 가독성을 개선하는 방안 제시
• 기존 base16 테마는 단순하지만 색상 수가 제한되고, truecolor는 설정 복잡성과 호환성 문제가 있음
• 기본 256색 팔레트는 밝기 불균형, 테마 불일치, 잘못된 보간 등으로 인해 시각적 품질이 낮음
• LAB 색공간 보간을 이용해 base16 색상에서 확장 팔레트를 생성하면, 일관된 밝기와 대비를 유지하면서도 풍부한 색 표현 가능
• 여러 주요 터미널(예: Ghostty, iTerm2, SwiftTerm)이 이미 구현 중이며, 표준화된 자동 팔레트 생성 기능이 터미널 생태계 전반의 품질 향상으로 이어질 가능성 있음

---

256색 팔레트 개요

• 256색 팔레트는 16개의 기본색, 216색 큐브, 24단계 그레이스케일로 구성
  • 기본 16색은 검정, 흰색, 원색 및 밝은 변형 포함
  • 216색 큐브는 RGB 각 채널에 6단계(0~5)를 사용하여 계산: 16 + (36 * R) + (6 * G) + B
  • 그레이스케일은 흑백 사이 24단계로 구성: 232 + S (S는 0~23)
• 이 구조는 24비트 RGB의 단순화 버전으로, 색상 수를 줄이면서도 표현력을 확보

기존 256색 팔레트의 문제점

• Base16 테마와의 불일치로 인해 색상 충돌 발생
  • 기본 팔레트는 대부분의 base16 테마와 조화되지 않음
• 잘못된 색상 보간으로 인해 어두운 배경에서 가독성 저하
  • 기본 팔레트의 첫 번째 음영이 실제보다 밝게 계산되어 대비가 약화됨
• 불균일한 대비 문제
  • 완전 채도의 색을 사용해 밝기 균형이 맞지 않으며, 같은 단계에서도 파란색이 녹색보다 어둡게 보임

팔레트 생성 방식

• 해결책은 사용자의 base16 색상에서 256색 팔레트를 자동 생성하는 것
  • base16의 8개 기본색을 216색 큐브의 8개 꼭짓점에 매핑
  • 배경색과 전경색을 이용해 삼선형 보간(trilinear interpolation) 으로 큐브 생성
  • LAB 색공간을 사용해 색상 간 시각적 밝기 일관성 유지
• 그레이스케일은 배경에서 전경으로의 단순 보간으로 생성
• Python 예시 코드에서는 rgb_to_lab, lab_to_rgb, lerp_lab 함수를 사용해 변환 수행

구현 및 적용 현황

• 제안된 코드는 퍼블릭 도메인으로 공개되어 자유롭게 수정·활용 가능
• Ghostty, iTerm2, SwiftTerm 등 주요 터미널에서 이미 구현 완료
• kitty, Wezterm, Tabby, Windows Terminal 등에서도 적용 요청 또는 개발 진행 중
• 일부 개발자는 OKLAB/OKLCH 색공간 사용을 제안했으며, 프로젝트는 Ghostty의 결정에 따라 표준 색공간을 통일할 예정
• Python 스크립트를 통해 직접 팔레트를 적용하거나, 터미널 설정 파일을 자동 생성 가능

결론 및 제안

• 기본 256색 팔레트는 가독성 저하와 테마 불일치로 인해 프로그램 개발자들이 기피
• 터미널이 base16 테마 기반으로 256색 팔레트를 자동 생성하면 다음과 같은 이점 확보
  • 설정 파일 없이도 넓은 색상 범위 사용 가능
  • 라이트/다크 모드 전환 시 개발자 개입 불필요
  • 광범위한 터미널 호환성 유지
• 제안자는 이 기능이 기본 활성(opt-out) 되어야 하며, 장기적으로는 표준 기능으로 자리잡아야 함을 강조

[GN⁺]

Hacker News 의견들

• 256색 팔레트의 좋은 점은 16~255번 색상이 고정되어 있음
  그래서 예를 들어 146번이 항상 ‘은은한 보라색’이라는 확신을 가질 수 있음
  이는 다양한 터미널 에뮬레이터에서 일관된 색상 경험을 제공하려는 색상 테마 개발자에게 매우 유용함
  만약 256색 팔레트가 변동 가능한 16색 팔레트에서 생성된다면, 146번이 기대한 색이 아닐 수도 있음
  16~255번 영역이 0~15번처럼 불안정해지는 건 잘못된 방향이라 생각함

  • 16색만 사용하는 게 제한적이긴 하지만, CLI/TUI 개발자가 그 범위를 벗어나 임의의 색상 테마를 만드는 건 불편함
    시각 장애인이나 색약자, 흰색 배경을 선호하는 사람 등에게 가독성이 떨어짐
    결국 사용자는 터미널 기본 색상뿐 아니라 각 앱의 색상 설정까지 따로 해야 함
    터미널은 예쁜 UI가 아니라 효율성 때문에 쓰는 것임. 예쁜 걸 원하면 웹 프론트를 만들면 됨
  • 터미널의 색상은 스타일이 아닌 의미 중심(semantic) 으로 써야 함
    우리는 ‘일관된 경험’을 원하지 않음. 색상은 절제해서, 사용자 설정을 존중하며 써야 함
  • 146번이 ‘은은한 보라색’이라는 걸 알아도, 배경색을 모르면 의미가 없음
    배경이 보라색일 수도 있고, 흰색 배경에 보라색 글자일 수도 있음
    즉, 앱이 내 터미널의 색 구성을 모른다면 그 색을 쓰지 말아야 함
  • 이 기능은 사실 색상 테마 개발자가 아니라, 자신만의 팔레트를 직접 만드는 사용자에게 더 맞는 기능임
    나는 기본 base16 테마를 쓰고, 제3자가 만든 테마와 일치하길 기대하지 않음
    터미널 단위와 앱 단위의 색상 접근 차이는 철학적 문제에 가깝다고 생각함
  • iTerm2 같은 터미널은 이미 최소 대비(Minimum Contrast) 기능을 제공하지만, 이게 색을 심하게 왜곡하기도 함

• 나는 Streamdown이라는 스트리밍 마크다운 렌더러를 만들었음
  HSV 기반으로 기준 색상 하나만 정하면, 나머지는 그 색의 배수로 자동 조정됨
  예를 들어 어두운 요소는 채도를 낮추고, 심볼은 더 생생하게 만드는 식임
  설정에서 HSV를 살짝만 바꿔도 전체 톤이 자연스럽게 변하므로, 일일이 색을 손보지 않아도 됨
  예시 코드도 있음

• 16색 기본 팔레트만으로도 문제가 있음
  ‘black’, ‘white’, ‘bright black’, ‘bright white’가 실제로는 명암 대비를 의미해야 하는데, 이름이 색상으로 되어 있음
  나는 이를 ‘배경과 거의 안 보이는 색’, ‘대비가 큰 색’, ‘보이지만 약한 색’, ‘가장 대비가 큰 색’으로 이해함
  색 이름이 아니라 대비 중심으로 정의되었으면 좋겠음

  • 올바른 방법은 터미널 색을 건드리지 않고 프로그램에서 다른 색을 쓰도록 설정하는 것임
    터미널의 전경·배경색은 16색 표준과 독립적이라 더 복잡함
  • 색상 설정을 제공하지 않는다면, bold·reverse·standout 같은 속성만 사용하는 게 낫고
    배경을 모를 때는 검정·흰색을 피해야 함. 256색을 쓸 땐 사용자 설정 가능한 테마 엔진을 써야 함

• 이 기능은 모든 터미널에 추가되어야 한다고 생각함
  24비트 컬러로 확장하면 더 좋을 듯함. 단, 옵션으로 제공되어야 함
  예를 들어 Solarized 테마를 터미널과 에디터 모두에서 쓰면, 색 변환이 중복 적용될 수 있음

  • 16색 팔레트에서 LUT(룩업 테이블) 을 만들어 24비트 색 공간으로 매핑하는 것도 가능함
    앱이 직접 설정을 덮어쓰지 않고, 환경 변수로 제어할 수 있게 하면 더 유연할 것임

• 나는 tinted-theming/base24를 발견하고 사용 중임
  tinted shell을 이용해 색상 테마를 손쉽게 전환할 수 있음. 꽤 괜찮은 임시 해결책이었음

• cargo/rustc에서도 색상 부족 문제가 있음
  기본 의미 색상만 쓰면 남는 게 마젠타, 검정, 흰색뿐인데, 이건 테마에 따라 위험함

  • 빨강과 초록을 제외하면 CLI 도구는 색상에 크게 의존하지 말고, 텍스트 마커를 지원하는 게 낫다고 생각함

• 그냥 24비트 true color 모드를 쓰면 팔레트가 필요 없음
  termstandard/colors 기준으로, 대부분의 현대 터미널이 이를 지원함

  • 하지만 원문에서도 true color에 대한 명확한 반대 의견이 있었음
  • urxvt는 여전히 완전한 true color를 지원하지 않음
  • 모든 색을 완전히 제어할 수 없기 때문에, 결국 가정이 필요함. 그게 핵심임
  • 이 논의의 요점은 true color가 아니라, 256색 기반의 사용자 설정 가능한 테마를 쓰자는 것임
  • 기술이 발전하면 48비트 이상의 지각 기반 색상 표준도 가능할 것임
    심지어 물리적 한계(하이젠베르크 불확정성, 양자 노이즈 등)를 고려하면 6000비트/픽셀 수준의 데이터가 필요함
    이런 상상은 카르다셰프 척도나 고대의 우주 시간 개념처럼, 기술 진보의 방향을 보여주는 흥미로운 사고 실험임

• 모든 사용자가 기본 색상 설정을 제대로 해두는 건 아님
  어떤 터미널은 전부 초록빛이거나 주황빛일 수도 있음
  기본 색상의 채도를 전체 팔레트에 적용하는 방식이 그나마 나을 수도 있음

• 나는 색맹이라 색상 테마에서 고생이 많았음
  그래서 AI 모델을 이용해 가독성 높은 색상 조합을 자동 생성함
  원래 좋아하던 테마를 기반으로 대비를 높여주니 훨씬 보기 편해졌음
  이런 접근이 다른 사람들에게도 도움이 될 수 있을 것 같음

  • 나는 색맹이 아니지만, 비슷한 문제를 겪음
    앱마다 색상 사용이 달라서, 어떤 테마는 일부 CLI에서는 잘 보이지만 다른 곳에서는 너무 흐림
    결국 앱마다 색상 테마를 따로 조정해야 하는 불편함이 있음

• 나는 protanomaly(적색 약시) 가 있어서 ametameric을 사용 중임
  이 기능과 함께 쓰면 더 나은 결과를 얻을 수 있을 것 같음