이 글에서 Claude 특유의 문체가 꽤 선명하게 느껴져서 이제는 좀 피곤하고 거리감이 듦
중요한 제품 출시 글조차 사람이 온전히 신경 쓸 가치가 없다면, 어디서 선을 그어야 할지 모르겠음

글은 필요한 내용을 효과적으로 전달했고, 사람이 읽기 좋게 작성·구조화된 것처럼 보였음
AI로 작성해서 이 훌륭한 오픈소스 소프트웨어 개발에 더 많은 시간을 쓸 수 있었다면, 오히려 좋은 일이라고 봄

무슨 말인지 정확히 알겠음. Claude와 plannotator를 자주 쓰는데, 특정 스타일 가이드를 요청한 뒤 훨씬 나아졌음
“CD 시대 MSDN 레퍼런스와 Raymond Chen 블로그 스타일”을 출발점 프롬프트로 삼았더니 AI가 만든 계획을 소화하는 능력이 크게 올라갔고, 겸손하고 통찰력 있으며 독자를 존중하는 스타일이라 강력 추천함

글을 읽어봤는데 AI가 쓴 것처럼 들리진 않았음
팀 누군가가 사람이 썼다고 나서면 좀 웃길 것 같음

진지하게 묻자면, 왜 그게 중요한가 싶음. 초안을 쓴 뒤 Claude의 문장을 검토하고 게시했을 수도 있음
AI가 업무를 도와줄 때마다 왜 굳이 “잡아내려” 하는지 모르겠고, 이건 F500 회사가 아니라 오픈소스 프로젝트임. 자원도 제한적이고 영어가 모국어가 아닐 수도 있음

오히려 피곤하게 들을 일이 아니라고 봄. 지금처럼 쓰이고 제시되는 방식은 기만과 거짓에 가깝기 때문임
협력의 문화에는 신뢰와 진실이 필요하다고 믿고, AI가 “내가 했다/말했다”고 거짓으로 말하는 글은 원치 않음
예를 들어 이 글이 정말 Claude가 쓴 것이라면, “I said”, “I meant it”처럼 팀의 사람이 직접 말한 것처럼 가장하는 이유가 무엇인지 의문임. 그건 사칭이고 기만적임. 협력과 정직을 지키는 문화라면 “내 인간이 말했다”라고 하거나, 최소한 인간을 대신해 행동하는 AI라고 제대로 표시해야 함

지루한 애플리케이션에서는 사람들이 Mantine 같은 전통적인 UI 라이브러리보다 shadcn의 복사·붙여넣기 방식을 선호하는지 궁금함
복사·붙여넣기 방식은 수정이 쉽지만 새 문제도 생김. 그냥 버전 번호만 올리면 될 일에 이제 업그레이드 AI 에이전트가 필요해지는 식임

“그냥 버전 번호만 올리면 된다”는 말은 지난 몇 년간 Material UI가 만든 골칫거리를 심하게 과소평가함
지루한 앱이 아니라 아주 큰 앱에서, 주요 버전 업데이트마다 API를 크게 뒤엎어서 지루한 마이그레이션이 필요했음. shadcn으로 옮긴 뒤에는 단일 컴포넌트만 업그레이드하고 새 컴포넌트는 자유롭게 추가할 수 있어 쉬워졌음. Material UI에서는 어디서든 새 기능을 쓰려면 전체를 새 API에 맞춰 바꿔야 했지만, shadcn은 선택적으로 가능함

복사·붙여넣기 방식은 전혀 이해하지 못했음. Shadcn은 그냥 유행 냄새가 나고, 직접 복사해 써봐도 뭐가 대단한지 모르겠음
그래도 즐겨 쓰면 되고, AI의 장점 중 하나는 HN이 예전만큼 JavaScript 프레임워크 얘기로 막히지 않는다는 점임

새 프로젝트에서는 점점 벤더링(vendoring) 쪽으로 기울고 있음
기성 UI 라이브러리를 가져오면 단기적으로는 쉽지만, 대개 과하게 복잡하고, 안 쓸 기능까지 구현돼 있으며, 같은 라이브러리를 쓰는 수많은 앱과 차별화하려 할 때 수정이 어렵고, 업그레이드할 때 그 수정들이 미묘하게 깨짐. 가장 좋은 접근은 자기 UI 라이브러리를 만드는 것이라고 봄. 직접 소유하고, 여러 프로젝트에서 재사용하며, 원하면 같은 시각 스타일을 유지하고, 필요한 기능만 추가할 수 있음

Mantine은 훌륭함. 빠르게 거의 뭐든 만들 수 있고, 이후 확장하거나 테마와 개별 컴포넌트를 완전히 커스터마이즈할 수 있음
학습 곡선은 있지만 거대한 수준은 아니라고 봄

많은 시스템에서 실제로는 “그냥 버전 번호만 올리기”가 거의 아님. 컴포넌트 라이브러리가 정확히 원하는 일을 해줄 때만 그렇게 가능함
실제로는 필요한 동작을 컴포넌트가 완전히 제공하지 않는 경우가 많고, 사람들은 컴포넌트에 추가 CSS를 자주 덧붙임. 대안이 몇 시간짜리 작업이라면 CSS 두 줄은 매우 유혹적이지만, 그 두 줄도 컴포넌트 라이브러리의 새 기능마다 검증해야 함. 이런 CSS 땜질이 많아지면 업그레이드는 하나의 프로젝트가 됨

이런 인기 UI 툴킷들이 div를 과도하게 렌더링하는 게 거슬림
Base UI를 보니 거의 모든 컴포넌트가 “요소를 렌더링한다”는 식인데, 아코디언에는 details/summary처럼 같은 일을 할 수 있는 네이티브 요소가 있음. 네이티브 웹 전도사는 아니고 웹 API, 특히 HTML에도 잘못된 점이 많다고 보지만, div 남용도 잘못임

마이그레이션 작업이 codemod에서 LLM으로 옮겨가는 흐름이 흥미로움
codemod가 더 결정적이긴 해도, 그 시대가 끝나가고 있는지 궁금함

LLM을 활용해 결정적 codemod를 만들면 어떨까 싶음
그런 다음 codemod를 실행하고 다른 결정적 안전장치를 붙여 반복하면서, 결과를 다시 LLM에 넣어 codemod를 개선할 수 있음

원문 글의 프레이밍은 위험한 사고방식임. codemod 자체는 있어도 되고 없어도 됨
원하는 것은 LLM용 skill 파일이 아니라 사람을 위한 문서여야 함. 사람을 위한 마이그레이션 가이드를 쓰면 됨. 결국 skill 파일과 문서는 같은 것이어야 한다는 사실을 깨닫는 데 시간이 좀 걸릴 것임

여기서 codemod가 무엇을 뜻하는지 궁금함

둘은 완벽하게 보완한다고 생각하고 앞으로도 그럴 것임
부드러운 규칙에는 AGENTS.md 파일을 계속 쓰고, 강한 규칙에는 커스텀 린터 규칙을 쓰는데, 이게 두 세계의 장점을 모두 가져가는 방식이라고 봄

shad-CN을 쓰고 싶지만 매번 결국 Mantine으로 돌아가게 됨
어떤 컨텍스트를 연결해야 하는지 기억하는 것보다 훨씬 빠름

이 변화가 사용자에게 번들 크기 감소 같은 더 나은 결과를 주는지 궁금함
아니면 Shadcn 유지보수자들의 삶의 질을 높이는 변화에 가까운가 싶음

Angular에서 shadcn/ui에 해당하는 것은 무엇인지 궁금함
PrimeNG가 최근 라이선스를 바꿔서 새 프로젝트에 맞는 대안을 찾는 중임

같은 상황임. 직장에서 여러 앱에 PrimeNG를 써왔고, 적절한 대체재를 찾기 전까지는 Angular 21에 묶이게 될 듯함
다만 한 그룹이 PrimeNG를 포크했고 유지보수할 계획이라고 함. 새 이름은 아직 미정임 https://github.com/openng-org/open-prime

Shadcn과 비슷한 시스템이 Svelte, Angular, Nunchucks 같은 여러 스택에서 직접 쓸 수 있게 아직 제공되지 않는 데 대한 대응으로 Lily Design System을 만들고 있음
전부 무료 오픈소스이고, 피드백이나 제안을 보내주면 Lily에 쉽게 추가할 수 있음 https://lilydesignsystem.github.io