해커 뉴스에서 1,100포인트. 프로그래밍 언어의 포인트 릴리스 하나에.

새로운 프레임워크도 아니다. 화려한 인수 소식도 아니다. 6.2에서 6.3으로의 버전 업데이트 하나에, 댓글 섹션은 마치 치료가 효과를 보고 있다는 소식을 드디어 전해 들은 자조 모임처럼 읽힌다.

Swift 6.3이 이번 주 출시되었고, 그 반응은 Apple의 엄격한 동시성 모델이 수년간 Swift 5 패턴을 써오던 수천 명의 개발자에게 마이그레이션 경로를 얼마나 심각하게 망가뜨렸는지를 여실히 보여준다. Swift.org 블로그에 따르면, 이번 릴리스는 팀들의 발목을 잡아온 바로 그 마찰 지점들을 정확히 겨냥한다: 점진적 도입, 개선된 진단 메시지, 그리고 액터와 Sendable에 대한 보다 합리적인 방향.

지난 이틀간 모든 댓글 스레드를 읽고, iOS 개발자들과 이야기를 나누고, 마이그레이션 도구를 직접 테스트해 보았다. 중요한 것들만 정리했다.

Swift 6.0의 동시성 단속이 자기 개발자들을 어떻게 등 돌리게 했는가

Swift 6.0은 엄격한 동시성 검사를 기본값으로 도입했다. 이론적으로는 올바른 판단이었다. 데이터 경합은 실질적인 비용, 실질적인 다운타임, 실질적인 사용자 신뢰 손실을 초래하는 버그 범주다. 프로덕션에서 새벽 3시에 터지게 내버려두는 대신, 컴파일러가 빌드 타임에 잡아내겠다는 것이었다.

실제로는, 도시의 모든 식당에 내일까지 새로운 위생 점검을 통과하라고 통보하는 것과 같았다. 아직 아무도 유창하게 구사하지 못하는 방언으로 작성된 기준서를 들이밀면서.

"목적지가 문제가 아니었습니다," 10년 이상의 Swift 경력을 가진 한 iOS 개발자가 말했다. "문제는 Apple이 길이 없는 지도를 건네줬다는 겁니다. 하나의 타입에 Sendable 어노테이션을 달면, 갑자기 다른 40개 파일이 컴파일되지 않았어요. 에러 메시지는 암호 같았고요. 수정 방법은 명확하지 않았습니다. 예전에는 그냥 되던 것에 하루 종일을 쏟아야 했어요."

이는 실제로 공개적으로 벌어진 상황과 일치한다. 주요 오픈소스 라이브러리들은 Swift 6 도입을 미뤘다. 팀들은 프로젝트를 Swift 5 언어 모드에 고정시켰다. 해커 뉴스 토론에는 엄격한 동시성 검사를 그냥 꺼버리고 기다렸다고 솔직히 인정하는 개발자들이 넘쳐난다.

세분화된 마이그레이션, 명확해진 에러, 그리고 조용해진 컴파일러

Swift.org 블로그의 릴리스 노트에 따르면, 세 가지 변화가 있으며 각각은 가장 거센 불만에 직접 대응한다.

첫째, 점진적 마이그레이션이 실용적으로 변했다. Swift 6.3은 동시성 경고와 에러에 대한 더 세밀한 제어를 도입했다. 이전 릴리스의 특징이었던 전부 아니면 전무 방식의 스위치 대신, 이제 팀들은 모듈 단위로, 파일 단위로 엄격한 검사를 도입할 수 있다. 특정 타겟만 전체 검사 대상으로 지정하고 나머지는 경고 모드로 유지할 수 있다.

둘째, 진단 메시지가 극적으로 개선되었다. 컴파일러가 이제 무엇이 잘못되었는지뿐 아니라 왜 잘못되었는지, 그리고 예상되는 수정 방법이 무엇인지까지 설명한다. 해커 뉴스 스레드에서 여러 개발자가 새로운 "수정 제안" 어노테이션을 개발 편의성 측면에서 가장 큰 단일 개선 사항으로 특별히 꼽았다.

셋째, Sendable 관련 이야기가 단순해졌다. 액터 경계를 넘나들 수 있는 것에 대한 규칙이 다듬어졌다. 거짓 양성이 줄었다. 안전성은 높이지 않으면서 노이즈만 추가하는 어노테이션을 컴파일러가 요구하는 경우가 줄었다.

이해 불가능한 3,000개의 에러에서 조치 가능한 400개의 경고로

6.0 마이그레이션에 데인 적 있는 중견 앱 스튜디오의 시니어 엔지니어에게 물었다. 그녀는 "Apple이 개발자 경험을 제대로 정비할 때까지" Swift 6을 아예 건너뛰라고 팀에 권고하는 사내 메모를 작성한 바 있었다.

"어제 6.3을 우리 코드베이스에 테스트하기 시작했어요," 그녀가 말했다. "약 20만 줄의 Swift 코드가 있습니다. 6.0에서 엄격한 동시성을 활성화하면 3,000개 이상의 에러가 쏟아졌어요. 이해 불가능한 것들이었죠. 6.3에서, 같은 코드베이스로, 경고 모드에서 약 400개의 경고를 받았습니다. 대부분 실제로 컴파일되는 수정 제안이 달려 있었고요. 이건 완전히 다른 차원의 이야기입니다."

App Store에 두 개의 앱을 출시하는 1인 인디 개발자는 더 직설적으로 말했다: "6.0은 Apple 동시성 팀에 속해 있지 않은 것에 대한 처벌 같았습니다. 6.3은 쿠퍼티노 밖의 누군가가 실제로 써보는 걸 관찰한 것 같은 느낌이에요."

해커 뉴스 스레드의 반응도 이와 같다. 수백 포인트를 받은 최다 추천 댓글은 이렇다: "이것이 Swift 6.0이 됐어야 할 릴리스다."

컴파일 타임 정확성의 비용에 대한 사례 연구

이 이야기는 Apple 생태계를 넘어서 중요하다. 언어 진화가 어떻게 잘못될 수 있는지, 그리고 어떻게 회복할 수 있는지를 보여주는 사례 연구이기 때문이다.

Rust도 빌림 검사기(borrow checker)와 함께 비슷한 과정을 겪었다. 초기 경험은 가혹했다. 컴파일러가 코드를 끊임없이 거부했고, 개발자들은 그 이유를 항상 이해할 수 있는 것도 아니었다. 수년에 걸쳐 진단 메시지가 개선되고, 패턴이 정립되고, 커뮤니티가 집단 지식을 축적했다. 오늘날 빌림 검사기는 Rust의 진입 장벽이 아니라 왕관의 보석이다.

Swift의 동시성 이야기는 같은 길을 걷고 있다. 다만 더 빠르게, 그리고 언어와 그 언어가 실행되는 플랫폼 모두를 통제하는 기업 후원자와 함께. 이것은 양날의 검이다. Apple은 새로운 App Store 기능에 동시성 준수를 요구함으로써 도입을 강제할 수 있다. 너무 세게 밀어붙이면 하룻밤 사이에 전체 생태계를 망가뜨릴 수도 있다.

"여기서의 교훈은 Swift에 국한된 것이 아닙니다," 한 프로그래밍 언어 연구자가 말했다. "정확성의 비용에 관한 이야기입니다. 컴파일 타임에 특정 범주의 버그를 제거하려는 모든 언어는 같은 트레이드오프에 직면합니다: 내일의 사용자를 보호하기 위해 오늘의 개발자에게 얼마만큼의 고통을 부과할 것인가? Swift 6.0은 그 비율을 잘못 잡았습니다. 6.3은 교정처럼 보입니다."

모두의 상처가 아문 것은 아니다

모두가 납득한 것은 아니다. 토론에서 반복되는 주제 중 하나는 Apple이 이 궤도를 유지할 것인지, 아니면 다음 WWDC에서 또 한 차례의 호환성 파괴 변경을 들고 올 것인지에 대한 회의론이다.

"2009년부터 iOS 앱을 만들어 왔습니다," 한 댓글 작성자가 썼다. "네 번의 대규모 Swift 마이그레이션을 견뎌냈죠. 매번 '이번이 마지막 큰 변경'이라고 합니다. 제 CI 파이프라인이 믿을 때 저도 믿겠습니다."

라이브러리 호환성에 대한 정당한 우려도 있다. 당신의 코드가 Swift 6.3의 엄격 모드에서 깔끔하게 컴파일되더라도, 의존성은 그렇지 않을 수 있다. Swift 패키지 생태계는 Rust의 crates 생태계가 대체로 피한 방식으로 언어 버전별로 파편화되어 있다.

인기 있는 오픈소스 네트워킹 라이브러리의 메인테이너에게 마이그레이션 일정을 물었더니, 그녀는 한숨을 쉬었다. "엄격한 동시성을 도입하고 싶어요. 사용자들도 제가 도입하길 원하고요. 하지만 일부 기업 고객이 머물러 있는 Swift 5.9까지 지원해야 합니다. 제가 추가하는 모든 Sendable 어노테이션은 단순한 정확성 결정이 아니라 호환성 결정입니다."

이번 릴리스로 할 일, 그리고 기다려야 할 것

마이그레이션을 미뤄왔다면, 6.3은 테스트해 볼 릴리스다. 전환을 확정할 릴리스가 아니다. 테스트해 볼 릴리스다.

메인 타겟에 경고 전용 모드를 활성화하라. 컴파일러가 뭐라고 하는지 읽어라. 경고가 이해할 수 있고 수정 제안이 합리적으로 보인다면, 답을 얻은 것이다. 출력이 여전히 노이즈 벽이라면, 잃은 것은 아무것도 없다.

오픈소스 Swift 패키지를 유지보수하고 있다면, 지금이 동시성 브랜치를 시작할 때다. Apple이 강제해서가 아니라, 도입이 영웅적 노력을 요하지 않는 수준으로 도구가 드디어 문턱을 넘었기 때문이다.

그리고 2026년에 새 프로젝트를 위해 Swift를 검토 중이라면, 동시성 모델은 이제 그 언어에 반하는 논거가 아니라 찬성하는 논거다. 컴파일 타임 데이터 경합 안전성은 진정으로 가치 있다. 단지 그것을 사용 가능하게 만드는 데 고통스러운 세 번의 릴리스가 걸렸을 뿐이다.

아무도 필요로 하고 싶지 않았던 릴리스

Swift 6.3이 흥미진진한 이유는 무언가를 추가해서가 아니다. 무언가를 수리했기 때문이다. 프로그래밍 언어의 세계에서, 그런 종류의 릴리스가 화려한 것들보다 더 중요할 때가 많다.

해커 뉴스의 그 1,100포인트는 새로운 기능을 축하하는 것이 아니다. Swift 커뮤니티의 상당 부분을 2년간 제자리에 얼어붙게 만든 마이그레이션 세금의 종료를 축하하는 것이다.

때로는 언어 팀이 할 수 있는 최선의 일이 경청하는 것이다. Apple이 드디어 그렇게 한 것 같다.