▲

Swift 채택 중단 – Ladybird 브라우저의 Swift 6.0 지원 이슈 종료

 (github.com/LadybirdBrowser)
1P by GN⁺ 24시간전 | ★ favorite | 댓글 1개
  • Ladybird 브라우저 프로젝트는 Swift 6.0 지원을 실험 단계에서 정식으로 전환하는 과정에서 발생한 문제 목록을 정리했으나, 이후 Swift 채택을 더 이상 추진하지 않기로 결정함
  • 주요 장애 요인은 Swift와 C++ 상호운용성(Interop) 관련 ABI 불일치, 헤더 순환 의존성, 특정 타입 반환 불가 등으로, 여러 항목이 Swift 6.0.0 이후 수정되었음
  • CMake 빌드 시스템에서도 Swift + Ninja 환경에서의 배포 타깃 불일치, install_name 처리 오류, 비호환 컴파일 옵션 등 문제가 보고됨
  • Ladybird 자체 코드에서도 AK 및 LibGfx 모듈의 modulemap 구성, Swift 프론트엔드 크래시, 타입 네임스페이스 충돌 등 다수의 빌드 불안정성이 확인됨
  • 이러한 누적된 기술적 제약으로 인해 Swift 통합이 중단되었으며, 이는 C++ 중심의 개발 유지 결정으로 이어짐

Swift 관련 문제

  • Swift 6.0 지원을 실험 단계에서 벗어나기 위해 해결해야 할 언어 및 ABI 수준의 버그가 다수 존재
    • LLVM 버전 불일치로 인해 Swift 오픈소스 빌드 시 어설션 실패 발생
    • Optional<CxxValueType> 반환 시 컴파일러와 브리징 헤더 간 ABI 불일치 문제
    • Ubuntu 22.04 환경에서 <execution> 헤더 포함 시 libstdc++ 모듈 순환 의존성 발생
    • swift::Optional<swift::String> 반환 불가, <chrono> 헤더 불러오기 실패 등 C++23 호환성 문제 포함
  • 일부 문제는 Swift 6.0.0 이후 릴리스에서 수정되었으나, 일부는 main 브랜치에서만 해결되어 안정 버전에는 미반영
  • 여러 항목에서 “워크어라운드(우회 빌드 방법) ”가 제시되었으나, 완전한 해결책은 아님

CMake 관련 문제

  • Swift와 Ninja 빌드 조합 시 CMAKE_OSX_DEPLOYMENT_TARGET 미적용으로 경고 다수 발생
    • 수동으로 CMAKE_Swift_COMPILER_TARGET 설정 필요
  • CMP0157 정책 활성화 시 install_name 디렉터리 설정이 무시되어 수동 수정 필요
    • 관련 수정이 CMake 3.29, 3.30에 백포트 예정
  • Swift 컴파일러가 이해하지 못하는 링크 옵션이 외부 종속성에서 전달되는 문제 존재

Ladybird 프로젝트 내부 문제

  • AK 및 LibGfx 모듈의 clang module map 구성 시 시스템 헤더 충돌 발생
    • <math.h> 포함 시 모듈 인식 오류로 빌드 실패
  • Swift 프론트엔드가 AK 컨테이너 테스트 중 디버그 빌드에서 크래시
    • 릴리스 모드 빌드로만 회피 가능
  • String 타입 네임스페이스 충돌로 Swift 프론트엔드 비정상 종료
    • AK.String 또는 Swift.String으로 명시적 지정 필요
  • Swift Testing 모듈 사용 시 컴파일러 프론트엔드 크래시, AK::StringView의 CxxSequenceType 불인식 문제 존재

추가 개선 항목

  • Swift에서 C++ 함수가 Optional<CxxType>을 반환할 때 애플리케이션 크래시 발생
    • 임시 해결책으로 0 또는 1 크기의 배열 반환 사용
  • SourceKit-LSP 및 vscode-swift가 루트 수준 compile_commands.json을 요구
    • 심볼릭 링크 생성으로 해결 가능
  • Linux 환경에서 <swift/bridging> 경로를 수동 추가해야 하는 불편 존재

미해결 질문

  • Swift로 C++의 view 타입이나 byte slice를 복사 없이 전달하는 방법 불명확
  • Swift가 AK::Optional, AK::HashMap 등 자체 타입을 std:: 타입과 동등하게 인식하지 못함
  • Swift 가비지 컬렉터와 Ladybird의 메모리 관리 통합 방식도 미정 상태

이 이슈는 Swift 6.0 통합을 위한 기술적 장애를 체계적으로 기록한 문서였으나, 이후 Ladybird 팀이 Swift 채택을 중단하면서 “Swift 6.0 Blockers” 이슈는 종료됨.

▲
GN⁺ 24시간전  [-]
Hacker News 의견들

  • Swift 제거 커밋에는 약간의 추가 설명이 있음
    “오랫동안 **진전이 없었으므로 Swift 도입을 포기하고 코드베이스에서 제거함”이라는 메시지가 포함되어 있음
    관련 커밋은 여기에서 볼 수 있음

    • 여기에 더 자세한 맥락이 이슈 #933에 정리되어 있음

  • 나는 2021년에 Swift를 처음 써봤는데, 10년 넘게 C#/.NET을 하다가 와서 놀랐음
    C#도 복잡하다고 생각했는데 Swift는 그보다 훨씬 복잡한 언어였음
    특히 백엔드 API나 데이터 접근 계층을 만들 때는 참고할 자료가 거의 없었음
    Swift는 대부분 Apple 플랫폼용으로 지식이 쌓여 있어서, 그 밖의 영역에서는 거의 개척자가 되어야 하는 느낌이었음

    • 최근 몇 년간 Python이나 Go 같은 단순한 언어들이 “복잡성은 나쁘다”는 주장을 강화했지만, 언어의 표현력이 높으면 오히려 유지보수에 도움이 된다고 생각함
      Larry Wall이 말했듯, 도구의 복잡도는 문제의 복잡도에 맞춰야 함 (Raku 언급)
    • 나는 2018년쯤 Objective-C에서 Swift로 넘어왔는데, 처음엔 개선된 느낌이었음
      하지만 “struct는 값 전달, class는 참조 전달” 같은 규칙과 “하나의 진실된 소스 유지” 원칙이 충돌해서 개발이 지루하고 느려지는 경험을 했음
      Swift의 모순된 베스트 프랙티스 때문에 진전이 없었고, 결국 많은 조언들이 믿을 게 못 된다는 걸 깨달았음
    • M1 맥북에서 Vapor 템플릿을 컴파일할 때마다 노트북이 과열되는 문제도 있었음
    • 나도 비슷했음. Rust처럼 금방 익힐 줄 알았는데 전혀 아니었음
      문법 설탕이 너무 많고, 같은 일을 하는 방법이 수십 가지라서 매번 언어 레퍼런스를 찾아봐야 했음
    • 그래서 결국 C#/.NET으로 다시 돌아갔는지 궁금함

  • 언어가 무엇이든, Ladybird가 나중에 사용자 친화적인 JavaScript 구현에 집중하길 바람
    JS가 사용자 활동 추적이나 붙여넣기 차단, 과도한 디바이스 정보 수집에 악용되는 건 문제임
    Tor처럼 사용자 간 표준화된 스푸핑 값을 보고하도록 하면 프라이버시 보호에 도움이 될 것 같음

    • 하지만 이런 방식은 많은 웹사이트에서 봇 탐지로 오인되어 접속이 막힐 수 있음
      토글 옵션으로 제공하는 건 괜찮지만 기본값으로 두면 채택이 어려울 것 같음
    • 웹 표준을 무시하고 독자적으로 동작하는 브라우저는 개인적으로는 절대 쓰고 싶지 않음

  • Swift 제거가 흥미로움. 이유가 명확히 설명되지 않았는데 궁금함
    Linux에서 돌아가기만 하면 나중에 테스트해볼 생각임

    • 내가 보기엔 빌드 충돌이 반복돼서 포기한 듯함
      Swift가 여러 C++ 버전 라이브러리를 동시에 임포트하지 못하거나, 연산자 버전 충돌이 생기는 문제였음
      Swift는 좋은 언어지만, 이미 큰 프로젝트에 나중에 추가하기엔 너무 복잡했을 것 같음

  • 왜 Ladybird가 Swift를 시도했는지 궁금함. Rust가 더 나은 C++ 상호운용성을 갖고 있지 않나 생각함
    Swift의 GC도 브라우저 성능엔 불리할 것 같음

    • Andreas Kling이 트위터에서 “Swift vs Rust 중 Swift가 객체지향 지원과 C++ 연동에서 더 낫다”고 언급했음
      링크1, 링크2
    • Rust가 게임 개발에서 불편한 이유와 비슷함. borrow checker가 순환 참조 구조와 잘 맞지 않음
      우회 방법은 있지만 생산성이 떨어짐
    • Swift는 실제로 C++ interop 문서에 나와 있듯 상호운용성이 꽤 좋음
      다만 Ladybird에는 충분하지 않았던 듯함
    • Andreas Kling은 Rust가 객체지향 기능이 부족해서 GUI 개발에 불리하다고 말했음
      예전엔 SerenityOS에서 Jakt라는 언어를 만들기도 했지만, 결국 C++로 돌아온 듯함
    • Rust가 DOM 계층 구조나 OOP 문제로 거절된 적이 있었던 걸로 기억함
      관련 과거 논의는 이 글에 있음

  • Swift는 Apple에 너무 의존적인 언어라 놀랍지 않음
    C++의 안전한 부분만 잘 쓰면 충분하고, 실제로 대부분의 브라우저가 C++로 작성되어 있음

    • 하지만 모든 브라우저가 C++에 갇혀 있는 상태일 뿐임
      Chromium과 Firefox는 점진적으로 더 안전한 언어로 교체 중이고, 새 브라우저를 C++로 다시 쓰는 건 과거의 실수를 반복하는 셈임
      C++ 사용은 1998년 KHTML 시절의 유산임
    • “현대적 메모리 안전 C++ 서브셋”이란 게 구체적으로 뭔지 모르겠음
      string_view 같은 최신 STL 기능을 포함하나? 여전히 완전한 메모리 안전과는 거리가 있음
    • Rust는 Mozilla에서 개발된 걸로 알고 있는데, Mozilla 자체가 Rust로 작성된 건지 궁금함
    • 어쨌든 Swift는 고성능이 필요한 영역에서는 C++을 이기기 어려움
      일부 벤치마크를 제외하면 실제 프로그램에서는 거의 항상 느림

  • Swift 제거라니 아쉬움. 그럼 자체 언어 Jakt가 다시 후보에 오르는 건가 궁금함

    • Ladybird는 SerenityOS에서 이미 분리됐고, Jakt는 그들의 언어가 아님
      새로운 언어를 도입할 가능성은 낮다고 봄
    • 개인적으로는 프로젝트가 너무 방향을 자주 바꾸는 게 걱정임
      외부 후원으로 운영되는 프로젝트가 이런 식이면 장기적으로 지속되기 어려움
    • 왜 Rust를 안 쓰는지 답답함. 혹시 C++ 집착 때문인가 싶음

  • Swift는 결국 Apple의 장난감 언어에 불과하다고 생각함
    Apple이 그 이상으로 성장하도록 두지 않을 것임

  • Ladybird의 Mac UI는 AppKit 위에 얇게 얹은 레이어임
    Swift가 아니라 Objective-C++로 작성되어 있음
    소스 코드 참고

    • 내가 그 코드를 처음 작성한 사람임
      Swift 도입 훨씬 전, SerenityOS 시절에 만든 거라 Objective-C++을 쓴 건 단지 익숙한 언어였기 때문임

  • 예전에 Swift로 전환한다고 했을 때 비판했었음
    Swift는 설계가 엉성하고, 컴파일 속도도 느리며, 시스템 언어로 성장할 가능성이 낮다고 봤음
    전문가도 없었으니 이번 결정은 잘한 일이라 생각함

    • Swift는 오픈소스처럼 보여도 실제로는 Apple이 모든 결정권을 쥐고 있음
      Concurrency나 Swift Testing 같은 기능도 Apple의 필요에 따라 밀어붙인 사례임
      크로스플랫폼 작업은 대부분 소규모 팀이 따로 진행 중임
    • Swift의 문제는 인정하지만, “전문가가 없었다”는 건 과장임
      Chris Lattner를 제외하더라도 Swift 리드들은 C++ 커뮤니티에서 인정받은 인물들이었음
    • Swift의 핵심은 언어 자체보다 표준 ABI임
      Rust 진영이 C와 함께 Swift ABI도 FFI로 지원하면 좋겠음
    • 그렇다면 어떤 언어를 추천하는지 궁금함
    • Go도 비슷한가? 요즘 가장 합의된 선택지가 뭔지 알고 싶음
답변달기