Swift 관련 글이나 릴리스 노트를 읽다 보면 SE-0296, SE-0345 같은 코드가 자꾸 등장합니다. async/await를 소개하는 글엔 SE-0296이, if let name 축약 문법 얘기엔 SE-0345가 붙어 있죠. 이 번호의 정체가 뭘까요.
정답부터 말하면, Swift에 들어온 모든 언어 변경의 등기부 번호입니다. Swift는 문법 하나를 추가할 때도 공개 절차를 거치는데, 그 절차가 Swift Evolution이고 SE 번호는 그 절차를 통과한 제안서의 일련번호예요. 애플이라는 회사의 폐쇄적 이미지와 정반대로, Swift라는 언어의 진화는 전부 공개된 장부 위에서 이뤄집니다.
Swift 철학 시리즈 4편입니다. 앞의 세 편이 Swift가 지키는 가치(안전·성능·표현력, 점진적 공개, 값 타입)를 다뤘다면, 이번 편은 그 가치를 지키는 제도를 다룹니다. 철학은 선언만으로 유지되지 않고, 절차가 있어야 유지되거든요.
Swift Evolution이란 — 언어 변경의 공개 재판정
2015년 12월, 애플은 Swift를 오픈소스로 공개하면서 언어의 미래를 결정하는 절차도 함께 공개했습니다. GitHub의 swift-evolution 저장소와 Swift 포럼(forums.swift.org)이 그 무대입니다.
핵심 규칙은 하나입니다. Swift의 문법이나 표준 라이브러리를 바꾸려면, 누구든 예외 없이 제안서를 쓰고 공개 리뷰를 통과해야 한다는 것. 애플 엔지니어도, 크리스 래트너 본인도 이 절차를 우회할 수 없습니다. 실제로 초창기 애플이 낸 제안이 커뮤니티 반대로 기각된 사례가 있고, 반대로 외부 개발자가 낸 제안이 언어에 들어간 사례는 셀 수 없이 많습니다.
이 절차가 지키는 게 뭘까요. 앞선 세 편에서 다룬 철학입니다. 새 기능이 “안전을 해치지 않는가”, “progressive disclosure를 깨지 않는가”, “기존 코드와 일관되는가”를 제안자 혼자가 아니라 커뮤니티 전체가 검증하는 구조예요. 언어의 일관성이 한 사람의 취향이 아니라 절차의 산출물이 되는 겁니다.
제안서의 일생 — 아이디어에서 문법이 되기까지
문법 하나가 언어에 들어오는 여정을 단계별로 따라가 보겠습니다.
1단계, 피치(Pitch). 포럼의 Evolution > Pitches 게시판에 아이디어를 올립니다. 형식 제약은 느슨하고 목적은 온도 체크예요. “이런 문제가 있고 이렇게 풀고 싶다”에 대해 커뮤니티가 대안을 제시하고 허점을 찌릅니다. 대부분의 아이디어가 이 단계에서 걸러지거나 형태가 크게 바뀝니다.
2단계, 제안서(Proposal) 작성. 피치에서 살아남으면 정식 제안서를 씁니다. 템플릿이 정해져 있는데, 목차만 봐도 이 절차의 성격이 드러나요. 동기(Motivation), 상세 설계(Detailed design), 소스 호환성(Source compatibility), ABI(Application Binary Interface) 안정성 영향, 그리고 고려했지만 채택하지 않은 대안(Alternatives considered)까지 써야 합니다. “왜 이 설계인가”만이 아니라 “왜 다른 설계가 아닌가”까지 요구하는 거죠.
3단계, 구현 첨부. 요즘 Evolution의 관례에서 중요한 부분인데, 제안서에는 동작하는 구현이 함께 요구됩니다. 말로만 하는 제안이 아니라 컴파일러에 실제로 붙여본 코드가 있어야 리뷰가 시작돼요. 설계의 실현 가능성을 종이 위 논쟁이 아니라 코드로 증명하는 겁니다.
4단계, 공개 리뷰(Review). 리뷰 매니저가 배정되고, 보통 1~2주간 포럼에서 공개 리뷰가 열립니다. 리뷰 공지에는 답해야 할 질문까지 명시돼요. 이 변경이 Swift에 충분히 중요한 문제를 푸는가, Swift의 방향(feel and direction)에 맞는가, 다른 언어의 유사 기능과 비교해 어떤가.
5단계, 판정. 리뷰가 끝나면 Language Steering Group(언어 운영 그룹)이 결론을 냅니다. 결과는 승인(Accepted), 수정 후 재심(Returned for revision), 기각(Rejected) 중 하나고, 판정문에는 반드시 이유가 붙습니다. 승인되면 SE 번호가 확정되고, 구현이 특정 Swift 버전에 실려 출시됩니다.
실제 사례로 보는 절차의 무게
절차가 실제로 어떻게 작동했는지, 유명한 사례 몇 개를 보겠습니다.
SE-0296 async/await. Swift 동시성의 출발점이 된 제안입니다. 크리스 래트너가 2017년에 쓴 동시성 선언문(Concurrency Manifesto)에서 방향이 제시됐고, 실제 제안·리뷰·승인을 거쳐 Swift 5.5에 실리기까지 몇 년이 걸렸습니다. 그 사이 actor(SE-0306), 구조적 동시성(SE-0304) 같은 형제 제안들과 묶여서 하나의 로드맵으로 심사됐어요. 큰 기능은 제안 하나가 아니라 제안 무리로 들어온다는 좋은 예입니다.
SE-0345 if let 축약. if let name = name 대신 if let name으로 쓰는 문법입니다. 기능 자체는 작지만 피치 단계에서 if let name? 같은 대안 표기를 두고 긴 논쟁이 있었습니다. 최종 판정문은 간결함과 명료함의 균형을 근거로 현재 문법을 택했다고 밝혔죠. 사소해 보이는 문법 하나에도 이 정도 논증이 쌓입니다.
기각 사례도 기록으로 남습니다. 함수 인자의 self 접두어를 강제하자는 초기 제안(SE-0009)은 리뷰 끝에 기각됐는데, 기각 이유가 지금도 저장소에 남아 있어요. 커뮤니티는 “명시성이 늘어나는 이득보다 코드 소음이 커지는 손해가 크다”고 판단했습니다. 기각의 이유가 기록된다는 건, 같은 논쟁을 반복하지 않아도 된다는 뜻이기도 합니다.
이 사례들에서 보이는 패턴이 있습니다. Evolution 절차는 “무엇이 들어왔나”만큼 “무엇이 왜 안 들어왔나”를 남깁니다. 언어 설계의 판례법이 쌓이는 거예요.
누가 결정하나 — 거버넌스 구조
절차의 마지막 관문인 판정은 누가 내릴까요.
Swift 프로젝트의 최상위에는 Core Team이 있고, 언어 변경의 실질 판정은 Language Steering Group이 맡습니다. 애플 엔지니어와 외부 커뮤니티 멤버가 섞여 있고 리뷰 기간의 포럼 여론을 참고하되 다수결로 정하지는 않습니다. 공식 문서의 표현을 빌리면 리뷰는 투표가 아니라 논증의 수집이에요. 목소리 큰 쪽이 아니라 근거가 탄탄한 쪽이 이기는 구조를 지향합니다.
애플의 영향력이 큰 건 사실입니다. 컴파일러 개발 인력 대부분이 애플 소속이고, 애플 플랫폼의 필요(SwiftUI를 위한 resultBuilder 같은)가 제안의 동력이 된 경우도 많아요. 하지만 그 애플조차 절차 밖에서 문법을 바꿀 수는 없다는 것, 그리고 모든 논의가 검색 가능한 공개 기록으로 남는다는 것이 이 제도의 핵심 가치입니다. 참고로 서버 사이드 Swift, 임베디드 Swift처럼 애플 플랫폼 밖 생태계가 커지면서 거버넌스도 워킹그룹 체제로 점점 분화되고 있습니다.
개발자에게 실질적으로 좋은 점
Evolution 절차를 알아두면 Swift 개발자로서 얻는 실익이 분명합니다.
첫째, 최고 품질의 학습 자료가 공짜입니다. 새 문법이 이해 안 될 때 최선의 문서는 블로그가 아니라 제안서 원문입니다. 제안서에는 그 기능이 풀려는 문제(Motivation)와 설계 근거, 검토된 대안까지 적혀 있어서 “어떻게 쓰나”를 넘어 “왜 이렇게 생겼나”를 알 수 있어요. swift.org/swift-evolution 대시보드에서 SE 번호로 바로 찾을 수 있습니다.
둘째, 언어의 미래를 미리 봅니다. 포럼의 피치 게시판은 1~2년 뒤 Swift의 예고편입니다. 지금 뜨거운 스레드가 다음 WWDC의 새 문법이 되는 일이 반복돼 왔어요.
셋째, 참여의 문이 실제로 열려 있습니다. 리뷰 스레드에 사용 경험을 남기는 것만으로도 판정문에 인용될 수 있습니다. 한국어 사용자로서 문자열 처리나 포매팅 관련 제안에 실사용 피드백을 남기는 건 생각보다 값진 기여예요.
넷째, 팀의 기술 결정에도 참고가 됩니다. 어떤 기능이 “실험(experimental feature flag)” 단계인지, 정식 승인됐는지, upcoming feature로 예약됐는지를 구분할 수 있으면, 프로덕션 코드에 언제 들여올지 판단할 근거가 생깁니다.
정리
- SE-XXXX는 Swift Evolution 절차를 통과한 언어 변경 제안서의 번호입니다. Swift의 모든 문법 변경은 이 공개 절차를 거칩니다.
- 여정은 피치 → 제안서 작성(대안 검토 포함) → 구현 첨부 → 공개 리뷰 → Language Steering Group 판정 순입니다.
- 애플도 절차를 우회할 수 없고, 승인과 기각의 이유가 전부 공개 기록으로 남아 언어 설계의 판례가 됩니다.
- 새 문법이 궁금하면 제안서 원문이 최고의 자료고, 피치 게시판은 Swift의 미래 예고편입니다.
이것으로 Swift 철학 시리즈 4편이 마무리됐습니다. 가치(안전·성능·표현력), 학습 곡선(점진적 공개), 데이터 모델(값 타입), 그리고 제도(Evolution)까지 봤으니, 다음부터는 기초 문법을 깊게 파는 시리즈로 넘어갑니다. 첫 주제는 Swift에서 가장 자주 만나는 물음표, 옵셔널의 정체입니다.