PostCSS의 성공은 기술적 완성도뿐만 아니라 전략적인 운영 덕분이었습니다. 저자는 오픈소스 프로젝트의 인기는 직접적인 노력의 결과이며, 코드 작성만큼이나 문서화와 홍보에 상당한 시간을 할애해야 한다고 강조합니다. 실제로 Webpack에 PostCSS를 제안하고 README.md의 첫 문장을 다듬는 데 많은 노력을 기울였습니다. 또한, 초기에는 내부 프레임워크로 구상했지만, 개발자들이 새로운 도구 도입을 꺼린다는 점을 파악하고 PostCSS를 최종 사용자에게 노출하여 CSS 툴링 다양성을 추구하는 방향으로 전환했습니다.
기능 설계에 있어서는 플러그인과 내장 기능의 균형이 중요합니다. PostCSS는 기본적으로 아무것도 하지 않아 사용자들이 플러그인 선택에 어려움을 겪었는데, 이는 Lightning CSS나 Vite처럼 기본 기능을 내장하고 필요한 경우에만 플러그인을 사용하도록 하는 ‘설정보다 관례(Convention over configuration)’ 방식의 중요성을 시사합니다. 그럼에도 불구하고 플러그인 아키텍처는 코어의 경량화, 팀 분할, 다양한 실험 및 사내 특정 요구사항 충족에 큰 이점을 제공했습니다.
성능 측면에서는 프로그래밍 언어보다 아키텍처가 훨씬 중요함을 강조합니다. JavaScript로 작성된 PostCSS가 C++로 작성된 Sass보다 4배 빨랐던 사례는 이를 뒷받침합니다. 이는 단순한 언어의 우위가 아니라, 토크나이저-파서 아키텍처 개선과 효율적인 메모리 관리(객체 재사용을 통한 가비지 컬렉터 호출 최소화) 덕분이었습니다. Rust로 작성된 Lightning CSS의 빠른 속도 역시 아키텍처 개선에 기인합니다.
오픈소스 유지보수자의 번아웃 방지 또한 중요한 교훈입니다. 저자는 사용자 오류로 인한 문제가 반복되지 않도록 경고 메시지 추가, 입력 검사, 문서 보완 등의 선제적 조치를 취했습니다. API 오용 방지를 위해 타입과 추가적인 JS 코드 검사를 활용하고, 문서화는 최후의 수단으로 활용하되, 문제 제기자에게 문서 수정을 요청하여 협력을 유도했습니다. 또한, 빠른 답변과 코드 수정 요청을 통해 사용자가 무시당한다는 느낌을 받지 않게 하여 공동 기여를 장려했습니다.
주요 API 변경 시에는 Ruby on Rails에서 영감을 받은 ‘틱-택’ 방식을 사용했습니다. 즉, 첫 메이저 릴리스에서 기능을 Deprecated 처리하고, 다음 메이저 릴리스에서 제거하는 방식입니다. 이는 사용자들에게 충분한 마이그레이션 시간을 제공하며, 단계별 마이그레이션 가이드와 생태계 변화에 대한 Wiki 페이지를 통해 전환을 지원했습니다. 또한, 변경 사항을 사전 공지하고 피드백 채널을 운영하여 잠재적인 문제점을 파악했습니다.
생태계 형성을 위해 모범 사례를 제공하는 것도 중요합니다. PostCSS는 플러그인 보일러플레이트에 입출력 예제를 포함시켜 모든 플러그인이 명확한 예제를 갖도록 유도했습니다. 문서의 예제는 단순한 삽화가 아니라 커뮤니티의 습관을 형성하는 데 중요한 역할을 합니다. 나아가 경쟁 프로젝트인 Sass와 협력하고, CSSTree나 Lightning CSS와 같은 새로운 도구들을 홍보함으로써 오픈소스 생태계의 건강한 발전을 도모했습니다. 개인적으로는 오픈소스에서 경쟁자는 오히려 유지보수 부담을 덜어줄 수 있다고 보았습니다. 마지막으로, PostCSS 개발자들에게 엽서를 보내거나 오프라인 만남을 추진하는 등 인간적인 유대 관계를 형성하는 것이 코드만큼이나 중요하다고 강조합니다. 프로젝트에 고유한 스타일(PostCSS의 연금술 테마)을 부여하는 것도 즐거움을 더하는 요소입니다. 작은 팁으로는 라이브러리에서 빌드 단계를 피하고, 정적 웹사이트에는 React 대신 Astro나 정적 HTML을 사용하는 것을 제안했습니다.