요약
Pico CSS 제작자가 v2.1.1을 마지막 버전으로 정하고 유지보수를 끝냈습니다.
Pico CSS는 시맨틱 HTML(태그의 의미에 맞게 짠 HTML)을 위한 작은 CSS 프레임워크입니다. 제작자 루카스 라로슈는 10월 4일 GitHub 공지에서 AI 때문에 이런 프레임워크의 필요가 줄었다며 프로젝트 종료를 알렸습니다.
왜 중요한가
- 제작자가 AI 코드 생성을 오픈소스 프로젝트를 접는 첫 번째 이유로 직접 꼽았습니다.
- 기존 사이트는 당장 옮기지 않아도 되지만, 앞으로 공식 수정이나 새 기능은 기대할 수 없습니다.
핵심 내용
- 저장소는 보관 처리되어 새 이슈와 PR, 릴리스를 더는 받지 않습니다.
- npm, jsDelivr CDN, picocss.com은 계속 유지되므로 기존 사이트는 깨지지 않습니다.
- 제작자는 AI가 필요한 CSS만 담은 가볍고 접근성 좋은 HTML을 만들어 준다고 봤습니다.
- 시대에 맞추려면 Sass를 버리고 OKLCH 색상 등 최신 CSS로 전면 재작성해야 합니다. 제작자는 그것을 다른 프로젝트로 여겼습니다.
- MIT 라이선스라 포크는 자유롭지만, Pico CSS 이름과 로고는 쓸 수 없어 새 이름을 붙여야 합니다.
HN 반응
- AI가 대신한다는 이유를 두고 잘 설계된 명세의 가치를 버리는 태도라는 비판과, AI를 쓰면 Pico 자체가 필요 없으니 납득된다는 의견이 갈렸습니다.
- 재작성 이유로 꼽힌 OKLCH는 색을 다루기 쉽다는 쪽과 직관적이지 않다는 쪽이 맞섰고, Blades와 Nimble 같은 대안도 여럿 거론됐습니다.
대체 왜요? 도대체 왜요? 왜냐고요? 다들 살아남으려면 최신 브라우저 기능을 무조건 받아들여야 한다고 믿는 것 같은데, 정말 지긋지긋해요. 저는 oklch가 싫고, Tailwind가 그걸 유행시킨 것도 싫어요. 인간의 색 지각을 과학적으로 얼마나 정확하게 표현하는지는 관심 없어요. HSL/RGB로 아무 문제 없이 잘 쓰고 있는데, 새로운 색 체계를 이해하고 조정하는 법까지 배워야 한다는 게 너무 귀찮고 짜증 납니다.
이런 반감이 도통 이해가 안 됩니다. oklch는 기준 색에서 새로운 톤을 만들기가 정말 쉽고, 앵커 포지셔닝 같은 기능도 absolute로 배치하는 요소들을 훨씬 쉽게 놓게 해 줍니다. 그러니 그 "최신 브라우저 기능"들은 괜히 일을 복잡하게 만들려고 있는 게 아니라 오히려 그 반대입니다.
제 눈에는 이렇게 보입니다. (1) 새로운 걸 배우기 싫은 마음, (2) 그런 변화가 "살아남기 위한" 것이지 앞으로 유지보수할 사람의 일을 덜어 주려는 게 아니라는 결론에 이르는 논리적 오류, (3) 새로운 것에 대한 두려움( https://en.wikipedia.org/wiki/Neophobia ).
선명하고 쨍한 파랑(#0000FF)을 골라 보라고 하면서 형식이 "Lightness Chroma Hue"이고 유효 범위가 정해져 있다고 알려 준다면, 저는 "0.5 1.0 240"이라고 짐작했을 겁니다. 이 값은 어떤 모니터로도 표현할 수 없는 색인 데다 격차도 엄청나게 큽니다. 게다가 oklch.com 계산기는 스펙상 대체 색이 Dell 로고의 파랑이라고 하는데 전혀 밝지 않은 색이고, 정작 브라우저는 "선명한 보라"로 그려 냅니다.
빨강 120도, 초록 120도, 파랑 120도 이런 식으로 나뉘어 있는 게 아니니 파랑이 240이 아닙니다. 실제로 쨍한 파랑의 색조(hue)는 264입니다. "0-255 RGB" 기준의 쨍한 파랑은 명도(lightness)가 0.452이고, 정말 좋은 모니터에서 최대 채도(chroma)는 0.33쯤 됩니다. 명도는 그래도 대체로 납득이 가죠? 0.5면 완전히 어두운 것과 완전히 날아간 것의 딱 중간이니까요.
"그래, 채도는 0.33이 상한이구나" 하고 넘어가려면 아직 일러요. 채도를 0.40까지 올려도 마젠타(명도 0.74 언저리)나 초록(명도 0.78 언저리)은 여전히 나옵니다. 그러니 색 계열마다 유효한 명도 범위를 따로, 그것도 비선형으로 알아야 합니다. 파랑의 중간값은 빨강의 중간값과 다르고, 초록의 중간값과도 다르니까요.
흑백 휘도 계산이나 서브픽셀, 베이어 필터를 아는 사람이라면 채도가 가장 높은 색은 초록일 거라고 짐작했을 겁니다. 그런데 밝은 마젠타도 막상막하입니다. 그러다 웹 색상 선택기에서 명도 슬라이더를 내리면 채도 채널의 모든 것(특히 정점들)이 극적으로 뒤바뀝니다. 직관이라는 게 소용이 없죠.
OKLCH는 그라데이션을 따라 원하는 속성의 색을 고르기에는 정말 편합니다. 하지만 비선형이라서 기본 색 여러 개를 외우거나, 색상 선택기를 쓰거나, "진짜로" 직관적인 다른 체계에서 변환해 쓰는 수밖에 없습니다. 저는 OKLCH 숫자 세 개를 보고 RGB처럼 결과 색을 예측하지는 못합니다. 물론 RGB도 (OKLCH와는 정반대 이유로) 선형이 아니고, 제가 RGB를 예측할 수 있는 것도 수십 년 경험이 쌓여서일 뿐이라는 점은 인정합니다.
마젠타나 쨍한 초록, 선명한 파랑은 회사 로고 말고는 월드 와이드 웹에서 쓸 곳이 별로 없으니 예외적인 경우라는 건 인정하겠습니다. 그래도 OKLCH 형식이 완전 초보자에게 직관적이라고는 말하지 못하겠네요.
(그리고 조명 회사들이 OKLCH LED를 팔기 시작하기 전까지는 마이크로컨트롤러에 OKLCH 계산을 구현하고 싶지도 않습니다.)
제가 왜 OKLCH가 어려운지를 말로 정리해 주셔서 감사합니다. "그라데이션" 면에서 장점이 있다고는 해도, 사람 입장에서 배우기에는 직관적이지 않더군요. 저는 여전히 HSL을 씁니다. (웹이 HSB를 채택했으면 좋았을 텐데요.)
형, 뭔 소리예요?
기존 해법을 이렇게 급하게 이걸로 갈아치워야 할 근거가 뭔가요? 호환성은 조사해 봤나요? 대체 방안은 제공하나요?
제 눈에는 이렇게 보입니다. 1) 왜 이걸 원하는지 스스로 생각해 보지 않았고, 2) 쉬워진다는 건 잘못된 전제입니다. 현실에서 소프트웨어는 "이제 끝났다" 할 만큼 성숙한 단계에 이르지 않으니까요. 그리고 3) 반짝이는 물건 증후군( https://en.wikipedia.org/wiki/Shiny_object_syndrome )입니다.
두 분, 꽤 날이 선 이 논쟁은 밖에 나가서 결투( https://en.wikipedia.org/wiki/Duel )로 해결하시는 게 좋겠네요.
표준화는 가치가 있습니다.
Tailwind는 아마 싫어할 것 같지만, OKLCH는 그냥 놔두세요. 실제로 괜찮은 물건이에요. (RGB와 HSL은 전혀 괜찮지 않고요.)
어떻게 Oklch를 싫어할 수가 있죠?
Pico와 비슷한 결의 최근 대안/후속/포크 프로젝트들입니다.
Nimble: https://leftium.github.io/nimble.css/demo/pico.html
Sumi.css: https://vladocar.github.io/Sumi.css/docs.html
Blades: https://github.com/anyblades/blades
Oat: https://oat.ink/
Blades CSS는 기반이 된 Pico 포크에서 고친 부분과 핵심 내용을 정리한 전용 페이지도 만들어 뒀습니다. https://blades.dev/css/pico/
저는 pico의 열렬한 팬이었어요! 정말 큰 영감을 받았죠. 그래서 최신이면서도 구형 브라우저와 최대한 호환되는 걸 만들어 보려고 https://github.com/lekoala/actual-css 를 만들었습니다. (popover는 워낙 반가운 기능이라 결국 썼지만요.) 최신 CSS 프레임워크가 꼭 레이어(구형 브라우저에서는 깨집니다)나 앵커 포지셔닝을 써야 하는지는 아직도 잘 모르겠습니다. 가벼운 자바스크립트로 충분하고 오히려 더 나을 때도 있으며, 호환성도 더 좋으니까요.
전부 제 10초 평가에서 탈락이네요. 어설픈 CSS 프레임워크가 이렇게 많다는 게 놀랍습니다.
그럼 https://starter.bryanhogan.com/ 은 어떻게 보세요?
쓸모없네요 - https://ibb.co/h1sRtYKF
제 안드로이드 폰의 크롬에서는 그렇게 안 보이는데요. 제 눈에는 괜찮아 보입니다.
대체 그게 무슨 브라우저예요?
Windows 10 미만에서 돌아가는 마지막 Vivaldi 버전에서도 정확히 똑같이 깨집니다.
"what is this?"로 시작하는 두 번째 가로 띠를 잠깐 보고, 너무 오래 파고들며 시간을 낭비하지 않은 채 추측해 보면, 원인은 제목 하나와 문단 몇 개를 grid 레이아웃으로 배치했기 때문으로 보입니다. 모두 주어진(제한된) 너비를 꽉 채우는 구조인데, 이건 CSS에서 가능한 가장 단순한 레이아웃, 즉 block에 해당하죠. 예전에 grid가 아니라 flexbox로 비슷한 걸 본 적이 있는데, flexbox만 배우고 다른 건 하나도 안 배운 듯한 주니어 개발자가 만든 거였어요.
급한 대로 반쯤 고치려면 .base-layout의 grid-template-columns를 꺼 버리기만 해도 제한된 너비만 빼고 거의 다 해결됩니다.
네, 그래서 그게 무슨 브라우저냐고요?
CSS 프레임워크에서 제일 먼저 눈에 들어와서 "아니다" 싶게 만드는 게 뭔가요?
10초 평가는 어떻게 하시는데요?
이 주장은 결국 "AI가 비슷한 걸 만들어 주는데 뭐하러 만드느냐"는 말입니다. 저는 잘 고민해서 세운 명세에 맞춰 무언가를 만드는 데 큰 가치가 있다고 생각합니다. 이런 인지적 항복 태도는 마음에 들지 않습니다.
Pico CSS를 정말 즐겁게 썼습니다. 그래도 이번 결정은 이해합니다.
Pico CSS를 만들어서 우리와 나눠 준 Lucas Larroche에게 감사드립니다.
AI가 있으면 본인이 말한 "살아남기" 위한 업데이트를 할 수 있었을 텐데요. 지금은 그게 그 어느 때보다 쉬운 일이잖아요. PicoCSS는 브랜드 인지도가 있는데, 이걸 버리면 안 되죠.
"AI가 있으면"에 대한 답은 첫 문장에 나와 있습니다.
> 오늘날에는 AI가 꼭 필요한 CSS만 담은 가볍고 독립적이며 접근성 좋은 HTML을 생성할 수 있어서, 시맨틱 HTML용 미니멀 CSS 프레임워크는 예전만큼 중요하지 않다.
답이 "AI를 쓰라"라면, 그럼 AI로 Pico가 필요 없게 만들면 되지 않겠습니까. 물론 AI를 피하는 우리 같은 사람들을 위해 계속 유지할 수도 있겠지만, 그런 사람은 하루가 다르게 줄고 있고, 어차피 남의 프레임워크를 쓰기보다 직접 만들어 쓰는 경우가 많았을 겁니다. 그러니 저자는 아마 계속할 이유를 못 느꼈고, 그 시간을 다른 데 쓰고 싶었던 거겠죠.
> 버리면 안 되는 브랜드 인지도
그 브랜드 인지도가 저자의 삶에 얼마나 도움이 된다고 보시나요? 아마 자기 작업과 취미에서는 이미 손을 뗀 프로젝트일 텐데, 그걸 계속 유지할 만큼 가치가 있을까요?
그렇게 가치가 크다면 누군가 유지보수를 넘겨받는 계약을 하겠죠. 다만 솔직히 제 프로젝트라면, 남이 "브랜드"를 마음대로 가져다 쓰다가 저한테 남아 있을 가치마저 희석되는 것보다는, 제 것으로 두고 보관(archive)만 해 두는 쪽을 택할 것 같습니다. 포크를 따면 되고, 이미 있는 포크 중 하나로 갈아타도 되니까요.
https://github.com/anyblades/blades 가 같은 정신을 이어 가는 프로젝트인 것 같습니다.
공유해 주셔서 감사합니다! 정신도 같고, 기반 코드도 같습니다.
Blades CSS는 GitHub와 Discord에서 활발히 유지보수하고 있으니, 커뮤니티 여러분의 피드백을 기다립니다.
핵심 내용을 정리한 전용 페이지도 만들어 뒀습니다. https://blades.dev/css/pico/
사이트를 데모 중심으로 꼭 고치셔야 합니다. 홍보를 잘하는 방법은 nimble css 페이지를 보세요. 지금 사이트는 이 라이브러리가 어떻게 동작하고 어떻게 생겼는지, 제게 어떤 쓸모가 있고 제 문제를 어떻게 풀어 주는지 아무것도 알려 주지 않아요. 사이트에 들어왔을 때 제가 실제로 궁금한 건 바로 그런 것들인데요.
저는 GitHub 저장소에서 PicoCSS 작업을 하고 있어요.