나는 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%로 오른 것일 수도 있음. 이런 변화가 그래프 좌측에 표시되지 않은 기존 증가보다 특별히 더 큰 케이스가 아닐 수도 있음
엔지니어 입장에선 거대 기업이 품질 기준을 정하고 3rd party 소프트웨어의 API 접근을 제한한다는 점이 놀라움. 고객 입장에서는 엄격한 품질 기준과 OS 차원 API 제한으로 보안 검증이 된다는 사실이 반가움
소비자 입장에선, 브라우저가 Apple 심사를 통과해야 하기에 업데이트(버그나 보안 포함)가 느려짐. Mac이나 다른 플랫폼에서는 이런 필요 없음. Apple은 사파리만 쓰지 않는 브라우저는 제대로 동작도 안 하고, Mac이나 다른 OS에서는 이런 환경이 없음. 그리고 EU에서 대체 엔진을 허용하는 척하지만, 실제로는 악의적 준수(malicious compliance)만 늘어나서 사실상 대체 엔진은 이론에 불과함. 결과적으로 소비자 입장에서도 손해임
소비자 입장에선, OS 공식 브라우저로 GitHub이나 Threads 같은 서비스를 쓰는 데조차 문제를 겪고 있음
엔지니어 입장에서 궁금한 건, Apple 브라우저도 자체 기준을 지키는지임. 사파리만 특정 버그를 엄청나게 자주 겪음. 누구나 웹페이지 만들면서 한 번쯤 겪었을 법한 일반적인 버그도 많음
Hacker News 의견