Ladybird가 web-platform-tests에서 Apple 90% 임계값을 통과함

Hacker News 의견

• 나는 web-platform-tests에 깊게 참여한 경험자로서, 테스트 통과율을 어떤 지표로 삼는 건 조심할 필요가 있음. 이건 Ladybird의 성취를 폄하하려는 게 아니고, Ladybird의 빠른 발전이 정말 놀랍고, web-platform-tests가 이 팀에 도움이 된다면 그 자체로 좋은 일임. 새롭게 등장하는 Ladybird, Servo, Flow 같은 웹 플랫폼 구현은 매우 반가움. 다만, web-platform-tests는 본래 엔지니어링 도구로서 최적화됐지, 객관적인 메트릭으로 설계된 게 아님. 예를 들어 전체 테스트 개수 중 디코딩 관련 테스트 비율이 지나치게 높음. 그 이유는 브라우저 개발에서 난이도가 높아서가 아니라 생성이 쉽기 때문임. 또한, 우리는 유용한 테스트를 자유롭게 기여할 수 있도록, 기술적∙사회적 장벽을 낮추려고 함. 이건 좋은 지표 만들기에는 맞지 않지만, 좋은 엔지니어링 리소스에는 잘 맞음. Interop Project는 다른 방식의 트레이드오프와 선택적 테스트 집합을 통해 이 문제를 일정 부분 해결하지만, 현재 시스템은 이미 거의 완전한 웹브라우저 엔진을 구현한 곳들만을 타겟으로 설계됨
  • 트윗에서 이 지표가 Apple이 Ladybird 팀에게 강요한 임의의 기준임을 언급함. Ladybird의 월간 업데이트에서는 인코딩 테스트가 지나치게 통과율을 높이기 때문에 제외한 통과 테스트 수도 공개함
  • 선별된 테스트 하위 집합을 메트릭으로 삼는 것은 불가능한가 궁금함
  • 그렇다면 Apple에 직접 이야기할 필요 있음. 이런 기준을 만든 주체가 Apple임
  • 왜 이런 점을 여기서 언급하는지 모르겠음. 이건 Ladybird 메트릭이 아니라 Apple이 iOS에 요구하기 때문임
• Ladybird 브라우저가 조만간 실사용 가능한 단계가 된다는 게 정말 굉장히 멋짐. 몇 년은 더 걸릴 거라고 생각했는데 이렇게 경쟁력을 갖추기까지 빠를 줄 몰랐음
  • 직접 써보지는 않았지만, 월간 요약 영상은 몇 개 봤음. 테스트를 통과하는 것과 일상적으로 빠르게 쓰기에 충분한 속도를 갖는 것은 완전히 별개의 문제임. Ladybird가 지금은 그렇게 빠른 것 같진 않음. 그래도 팀 전체의 개발적인 성과가 대단함
  • "완성도 90%에 90%의 시간이 들고, 나머지 10%에도 또 90%가 든다"는 말이 Ladybird에도 적용되는지 궁금함. 만약 사실이라도, 전체적으로 꽤 괜찮은 개발 기간이라고 생각함
  • 너무 기대만 하지 말길 권장함. 9월 개발보고서를 보니 아직도 고쳐야 할 부분이 굉장히 많음. 엄청난 진전임은 분명하지만 Ladybird가 완성되려면 앞으로도 몇 년은 더 걸릴 전망임
  • 3년 전엔 Ladybird에 대해 회의적인 입장이었음. 그런데 첫째로 상근 엔지니어가 8명으로 늘었고(예상 못 했던 부분임), 둘째로 실제로 3년이 지남. 그래서 지금은 훨씬 더 낙관적임. 물론 Chrome과 경쟁하려면 아직 한참 멀었고, 기존 엔진을 포크하지 않고 직접 만드는 가치에 대해선 여전히 의문이 남음
  • 전에는 완전히 새 브라우저 엔진을 만드는 일은 몇십 년이 걸린다고 생각했지만, Ladybird 팀 같은 전념 하는 사람들이 뭔가 해내는 걸 보고 놀라움
• 관련된 트윗에서 Ladybird가 iOS에서 대체 브라우저 엔진으로 고려되기 위한 중요한 이정표라고 언급함
  • 그래서 기사 제목에 Apple이 들어간 맥락이 이해됨
  • 하지만 최소한 EU 내에서만 이야기이고, 그 밖에선 Apple이 아무리 좋은 엔진이어도 허락 안 할 것임
• 독립적이고 비기업 프로젝트인 Ladybird가 이렇게 빨리 성장한 게 정말 인상 깊음
  • "non-corpo"라는 표현은 이해하지만, 실은 Ladybird 조직 자체는 법인임. 관련 서류 참고
  • 브라우저가 얼마나 많은 일들을 하는지 생각하면 이 정도 프로젝트는 진짜 엄청남. 훌륭한 html/css 렌더러랑 JS 엔진을 만드는 것만도 이미 대단한데, 한 번 생태계에 들어가는 순간 앞으로의 변화에도 계속 발맞춰야 함. Chrome은 새로운 제안에 저항도 가능한데 작은 브라우저들은 거의 따라가기 급급한 느낌임
  • Ladybird가 진짜 비기업적인지 의문임. 일부 기업 후원이 있었던 걸로 기억함. 그런 점에선 Firefox를 가진 비영리 Gecko보다 더 낫다고 말할 수는 없을 듯함
  • Ladybird가 이 속도를 꾸준히 유지한다면 2027년 말쯤엔 진짜 쟁쟁한 경쟁자가 될 거라 기대함. 다만 개인적으로는 다음으로 가장 많은 기능을 가진 Servo 엔진에도 이렇게 집중된 노력이 필요하다고 생각함. FF/Mozilla는 크게 관심 없어 보이니, 별도의 브라우저 프로젝트가 꼭 필요함
  • 테스트 통과를 안전하게 한다는 건 완전히 다른 문제임. 이건 적합성(conformance) 테스트지, 보안 테스트와는 다른 이야기임. 그래도 엄청나게 인상적임
• 마지막 10%가 얼마나 어려울지 궁금함. 일반적인 소프트웨어 프로젝트라면, 마지막 10% 달성에 90% 이상의 추가 노력이 들 것임
  • 그리고 마지막 1%는 계속 바뀌고 완전히 끝나는 법이 없을 것임. 90%는 Apple 기준임. 하지만 일반 사용자들이 요구하는 수준은 무엇인지 궁금함
  • 브라우저는 역사적으로 가장 크고 어려운 프로젝트였음. 왜 이게 쉬워지리라 기대하지 못하겠음. 만약 segfault 발견에 2만 달러 현상금이 걸리면 진짜 완성 단계 아닐까 생각함
• Ladybird를 직접 빌드하고 실행해 봤음. 놀랍게도 이미 상당수 웹사이트가 잘 열림. 다만 Youtube는 아직 안 되고, Vimeo나 Reddit 댓글 창에서는 크래시가 발생함. 그래도 굉장히 고무적인 결과임. 빌드에 HDD 용량 약 6GB 필요함
• 그래프에 큰 도약이 보임! 어떤 변화가 이런 향상을 만들었는지 궁금함
  • Twitter 스레드에서 실제로 Andreas에게 누군가 질문했는데, CSS Typed Object Model API 스펙을 합친 게 원인임
  • 이 Pull Request에서 CSS 관련 테스트 약 6400개가 추가로 통과됐음. 그래도 그래프에서 보이는 스파이크의 전부를 설명하진 못할 것 같고, 확실히 도움이 됨. PR 상세 정보
  • 그래프에 축이 없어서 실제로 큰 도약인지 알 수 없음. 예를 들어 89%에서 90.2%로 오른 것일 수도 있음. 이런 변화가 그래프 좌측에 표시되지 않은 기존 증가보다 특별히 더 큰 케이스가 아닐 수도 있음
• Ladybird gtk 관련 개발은 어떻게 되고 있는지 궁금함
• Ladybird에서는 어떤 JS 엔진을 쓰는지 궁금함
  • 자체 엔진 LibJS를 사용함 LibJS 깃허브
  • 모든 소스 코드는 오리지널임
• 엔지니어 입장에선 거대 기업이 품질 기준을 정하고 3rd party 소프트웨어의 API 접근을 제한한다는 점이 놀라움. 고객 입장에서는 엄격한 품질 기준과 OS 차원 API 제한으로 보안 검증이 된다는 사실이 반가움
  • 소비자 입장에선, 브라우저가 Apple 심사를 통과해야 하기에 업데이트(버그나 보안 포함)가 느려짐. Mac이나 다른 플랫폼에서는 이런 필요 없음. Apple은 사파리만 쓰지 않는 브라우저는 제대로 동작도 안 하고, Mac이나 다른 OS에서는 이런 환경이 없음. 그리고 EU에서 대체 엔진을 허용하는 척하지만, 실제로는 악의적 준수(malicious compliance)만 늘어나서 사실상 대체 엔진은 이론에 불과함. 결과적으로 소비자 입장에서도 손해임
  • 소비자 입장에선, OS 공식 브라우저로 GitHub이나 Threads 같은 서비스를 쓰는 데조차 문제를 겪고 있음
  • 엔지니어 입장에서 궁금한 건, Apple 브라우저도 자체 기준을 지키는지임. 사파리만 특정 버그를 엄청나게 자주 겪음. 누구나 웹페이지 만들면서 한 번쯤 겪었을 법한 일반적인 버그도 많음
  • 고장난 브라우저를 쓰지 않는다는 선택을 할 수 있는지 의문임
  • 이건 놀랄 일이 아니라, 반경쟁적이고 불공정한 방식으로 컨트롤을 유지하려는 거라고 생각함