Hacker News 의견

• CF가 실제로 제품을 개선하려고 노력하는 것은 좋은 일임. 그러나 너무 빠른 속도로 변화가 일어나서 따라가기가 어렵고, 출시가 완성도를 앞서는 경우도 많음. 예를 들어 R2 Data Catalog에는 여전히 Iceberg v3 지원이 부족하고, Wrangler도 불과 몇 달 만에 크게 바뀌었으며, Pages는 곧 사라질 것 같아서 Workers Assets로의 마이그레이션이 굉장히 번거로움. Wrangler 3에서 잘 되던 설정이 Wrangler 4에는 제대로 적용되지 않았고, Wrangler 5에서는 또 새로운 인터랙션 모델이 나올 느낌임

  • "Pages가 사라질 것 같다"는 말에 대해, 실제로 CF에서는 Workers가 Pages와 동일한 수준이 될 때까지 Pages를 없애지 않는다고 커뮤니티 포스트에서 언급했음 관련 포스트 공식적으로 Pages가 폐지된다는 내용을 찾기 어렵고, pages.cloudflare.com과 developer.cloudflare.com/pages 모두 활발히 운영 중임. Reddit의 한 게시글은 Pages 마이그레이션을 암시하지만, 해당 링크에서도 공식적인 중단 언급이 없음 나머지 의견에는 공감하며, 특히 그 부분 때문에 놀랐음 Reddit 참고 링크

  • Wrangler 3의 설정이 Wrangler 4에서도 그대로 동작하지 않는다는 말에는 동의할 수 없음. Wrangler 4에서 설정 형식에는 아무런 변화가 없었고, 메이저 버전 증가의 이유는 99.99%의 사용자에겐 영향이 없었음. 관련 변경 내역은 여기에서 확인 가능함. 단순 메이저 버전 업만으로도 불편함이 커서 자체적으로 반대 의견도 냈었으나, 극히 드문 예외 케이스 때문에 팀에서는 신중을 기했음. 앞으로는 이런 이슈를 메이저 버전 업 없이 관리할 수 있는 방법(예: esbuild 버전의 병행 지원 등)을 개발할 것임. 런타임 측면에서는 특히 하위 호환성을 엄청나게 신경 씀 하위 호환성 관련 블로그 Pages는 사라지는 것이 아니며, Workers Assets는 Pages의 더 유연한 구현 버전임. 추가 기능이 필요 없다면 굳이 이전하지 않아도 되고, 나중에는 자동 마이그레이션도 진행될 예정임

  • 중요한 프로젝트나 몇 년간 유지될 시스템을 만들 때는 '따분한 기술(boring tech)'을 사용하는 것이 좋음을 다시 한번 상기시킴

  • "Pages가 사라질 것 같다"는 근거를 어디서 봤는지 궁금함. 본인은 여러 프로젝트에 Pages를 잘 쓰고 있음

  • 흥미로운 사실은 이 논란이 Cloudflare가 Vercel보다 빠르다는 주장에서 시작되었다는 점임. 이후 제대로 알고 있는 누군가가 벤치마크를 진행해 실제로는 반대 결과가 나왔고, 결과적으로 Cloudflare가 성능을 높이기 위해 실제 개선 작업을 진행함

• 기사에서 경쟁을 비난하기보다는 개선점을 찾아내고 강조하는 태도가 정말 마음에 들었음. OpenNext 구현에도 발전이 있어서, 다른 공급업체에서도 재활용할 수 있다는 점이 인상적임

• NextJS를 Vercel에서 호스팅하다가 Astro/React를 Cloudflare로 이전 중임. 놀라운 점은, “엣지”에서 모든 요청마다 웹앱을 렌더링하는 상황에서도 응답 시간이 100-200ms 정도로, 거의 정적 페이지와 비교해도 손색없는 속도를 보인다는 것임. 최근 몇 주간 Cloudflare Worker의 개선도 확실히 체감했는데, 콜드 스타트가 거의 사라지고 응답 속도도 훨씬 안정적임 포팅 중인 웹앱 링크

  • 안녕하세요! 엣지 환경에서 데이터베이스와 어떻게 연결하고 계신지 궁금함. Cloudflare의 데이터베이스를 사용 중이신지요? 애플리케이션과 데이터베이스 간 왕복 횟수가 많아져서 엣지 호스팅 시 오히려 성능 저하를 경험한 바 있음. 한 번 직접 사용해보고 싶었음

• 규모가 크지 않은 유튜버가 올린 영상이 이런 방식으로 효과적으로 퍼져나가, Cloudflare 측에서 실제 의미 있는 개선과 플랫폼 이슈 해결로 이어진 점이 신기함

• 너무 잘 짜여진 PR임. 이 포스트를 준비한 분들께 칭찬을 보냄

  • 오래된 cf 고객으로서 이야기하자면, cf는 블로그나 오픈소스 글쓰기도 멋지지만 인프라 회사 중 서비스 지원 면에서 최고임. 팀원(kenton 포함)들이 Discord에서 직접 사용자를 도와주거나 피드백을 수용하는 경우가 많고, 버그나 이슈도 실제 담당 엔지니어와 바로 소통할 수 있음. 실제로 본인이 제안한 PR이나 피처 요청도 별다른 절차 없이 빠르게 반영된 적 있음. 타 대형 기업 대비 매우 저렴한 요금제로도 훨씬 더 나은 지원을 받고 있음

  • 고마움! 이 PR과 포스트는 Workers 팀 엔지니어들이 100% 주도적으로 기획, 제작한 것임(나도 참여함)

• 이 포스트의 작성 방식, 정보 분해, 공개적 논의 모두가 정말 마음에 듦. Cloudflare workers 팀에 대한 신뢰도가 올라감

• 내 생각엔 SvelteKit이 엄청 빠르고, Next.js는 상대적으로 매우 느림

  • 그럴듯한 결론임

  • SvelteKit, Astro, TanStack 같은 실용적인 프레임워크가 곧 NextJS의 복잡함을 대체했으면 하는 바람임

• 이런 사례가 경쟁과 독립적인 벤치마크가 필요한 이유임. 성능이 부족한 서비스도 개선을 위해 노력하게 만듦

  • 그런 노력도, 제품을 소중하게 생각해야만 효과가 있음

  • 이미 독립적인 벤치마크는 존재함

• Cloudflare가 결과를 겸허히 받아들이고, 건설적으로 개선한 점이 인상적임

• 내용에 초점을 맞추고, 비난하지 않은 멋진 글임.하지만 Cloudflare가 기존에 generation 크기 등을 사전에 더 잘 모니터링하고 조정하지 않았다는 점은 의외였음. JVM 성능 튜닝에서는 generation size 세팅이 기본인 경험이 있었음

  • 우리는 뭔가를 고칠 때마다 항상 투명성을 우선함, 심지어 다소 바보처럼 보일 수 있더라도 말임. 앞으로는 이 부분 로깅과 추적도 더 강화할 예정임. 일반적으로 GC가 최대한 스스로 자동으로 환경에 적응해야 한다고 생각함. 즉, 사용자가 파라미터를 일일이 맞추는 과정이 많다면 GC 작성자 측면에서 패배나 다름없다고 느껴짐. 이번에는 제대로 동작하지 않던 튜닝을 <i>제거</i>하고, V8이 자체적으로 young gen size를 더 잘 결정하도록 허용하는 방향임