프롤로그 — Objective-C가 떠난 자리, 11년 뒤의 Swift

2014년 WWDC에서 Chris Lattner가 Swift를 발표했을 때, 청중석이 박수보다 한숨에 가까웠던 걸 기억한다. "Objective-C는 30년 짐이었지만 검증된 짐이었다. 새로운 언어를 또 배워야 하나?" 그게 2014년 6월의 반응이었다. 11년이 지난 2026년 5월, 그 질문은 사라졌다. iOS·macOS·watchOS·visionOS·tvOS 코드의 거의 전부가 Swift다. Objective-C는 SDK 내부 API 일부와 historical 코드에 남아 있을 뿐, 새 프로젝트는 처음부터 Swift로 시작한다. 그리고 이제 Swift는 Apple 플랫폼 바깥으로 나가고 있다 — Linux 서버, Android, 임베디드, 그리고 Windows까지.

이 글은 2026년 5월 현재 Swift 생태계의 지도를 한 번에 그린다. 언어(Swift 6.1·6.2 preview), UI(SwiftUI 6·SwiftData), 서버(Vapor 4·Hummingbird 2), 도구(Tuist·Mint·SwiftPM), 코드 품질(swift-syntax·swift-format·SwiftLint·SwiftFormat), 테스트(swift-testing), 새로운 영역(Android Swift WG·Embedded Swift·swift-foundation 재작성), 그리고 한국·일본의 실제 사용처(카카오·라인·메르카리·Cookpad·CyberAgent·ピクシブ)까지. 어떤 도구를 언제 쓰는지, 왜 strict concurrency가 큰 변화인지, 그리고 Swift가 정말 Apple 바깥에서 살아남을 수 있는지.

1장 · 2026년 모던 Swift — Swift 6의 strict concurrency 시대

먼저 한 줄 요약. **2026년 Swift의 핵심은 "데이터 레이스를 컴파일 타임에 잡는다"이다.** Swift 6.0(2024년 9월 출시)가 strict concurrency를 기본값으로 켰고, Swift 6.1(2025년)가 "complete" 모드를 안정화했고, Swift 6.2 preview가 더 매끈한 actor 이행 경험을 약속한다. C++·Rust·Go가 각자의 방식으로 풀던 동시성 안전 문제를, Swift는 actor 모델 + Sendable 프로토콜 + isolated 키워드 + region-based isolation으로 풀었다.

2026년 기준 Swift의 좌표.

| 영역 | 상태 (2026.05) | 대표 도구 |

| --- | --- | --- |

| 언어 | Swift 6.1 stable | swift.org / Xcode 16 |

| 언어 (preview) | Swift 6.2 in Xcode 17 beta | swift.org |

| UI 프레임워크 (Apple) | SwiftUI 6 (iOS 18 / macOS 15) | Apple SDK |

| 데이터 (Apple) | SwiftData GA | Apple SDK |

| 서버 (사실상 표준) | Vapor 4 | vapor.codes |

| 서버 (Apple SSWG 후원) | Hummingbird 2 | hummingbird.codes |

| 패키지 관리 | swift-package-manager | swift.org |

| 프로젝트 생성 | Tuist 4 | tuist.io |

| CLI 도구 설치 | Mint | github.com/yonaskolb/Mint |

| 매크로·AST | swift-syntax | github.com/swiftlang/swift-syntax |

| 포매터 (Apple 공식) | swift-format | github.com/swiftlang/swift-format |

| 포매터 (커뮤니티) | SwiftFormat | github.com/nicklockwood/SwiftFormat |

| 린터 | SwiftLint | github.com/realm/SwiftLint |

| 테스트 (신규) | swift-testing (Swift 6.0+) | swift.org |

| 테스트 (legacy) | XCTest | Apple SDK |

| Android | Android Swift WG (2024.11) | swift.org/android-workgroup |

| 임베디드 | Embedded Swift | swift.org/embedded |

| 표준 라이브러리 재작성 | swift-foundation | github.com/swiftlang/swift-foundation |

핵심 통찰 3개.

첫째, **strict concurrency가 Swift 6의 정체성이다.** Swift 5.5에서 async/await가 들어왔고, 5.7에서 actor 모델이 안정화됐고, 5.10에서 strict concurrency가 opt-in으로 들어왔다. Swift 6.0이 이걸 기본값으로 켜면서, 옛 코드를 컴파일하면 수백·수천 개의 경고가 한꺼번에 쏟아진다. 이게 마이그레이션 부담이 되지만 — 한 번 통과하면 데이터 레이스가 컴파일 타임에 잡힌다는 보장을 얻는다. Apple 내부도 같은 길을 걷고 있고, 외부에서는 Airbnb·Lyft·Uber 같은 대형 iOS 앱이 1-2년 마이그레이션을 진행 중이다.

둘째, **Swift는 점점 Apple 바깥으로 나간다.** Vapor가 2016년부터 서버 Swift를 받쳐 왔지만, 2024년 11월 Android Swift Working Group이 발족하면서 Apple 외부 트랙이 공식화됐다. Embedded Swift는 2024년 WWDC 키노트에 등장하며 16KB 바이너리로 STM32에서 도는 데모를 보여줬다. swift-foundation은 Objective-C 기반 NSFoundation을 순수 Swift로 다시 쓰는 프로젝트로, 2024년부터 본격 가동 중이다.

셋째, **도구 생태계가 분열에서 통합으로 가고 있다.** swift-format(Apple 공식)과 SwiftFormat(Nick Lockwood)이 공존하고, SwiftLint(Realm)가 린터 자리를 지키고 있지만, Apple이 swift-syntax를 표준화하면서 모두가 같은 AST를 쓴다. CocoaPods → Carthage → SwiftPM 이행도 거의 끝났고, 새 프로젝트는 SwiftPM이 default다. Tuist는 SwiftPM과 Xcode 사이를 메우며 모노리포·멀티 타깃에서 자리를 잡았다.

2장 · Swift 6.1 — complete 모드 + raw identifiers

Swift 6.1은 2025년 봄에 출시된 maintenance + feature 릴리스다. 핵심 변화 두 가지.

**첫째, strict concurrency "complete" 모드 안정화.** Swift 6.0이 strict concurrency를 default로 켰지만, "minimal·targeted·complete" 세 단계 중 어디까지 켤지는 프로젝트가 정한다. 6.1에서는 complete 모드 자체의 false positive·diagnostic 품질이 크게 좋아졌다. 특히 `Sendable` 추론이 더 똑똑해져서 옛 코드에서 명시적 `@Sendable` 표기 없이도 안전성을 입증할 수 있는 케이스가 늘었다.

**둘째, raw identifiers.** 백틱으로 감싼 식별자에 공백·특수문자를 쓸 수 있게 됐다. 테스트 함수 이름을 자연어로 쓰고 싶을 때 결정적이다.

@Test func `사용자가 로그인하면 토큰이 발급된다`() async throws {

let user = User(email: "test@example.com")

let token = try await login(user)

#expect(!token.isEmpty)

}

// 일반 함수도 가능

func `compute checksum for v2 protocol`(_ data: Data) -> UInt32 {

// ...

}

이 기능은 swift-testing과 짝을 이뤄 한국어·일본어 테스트 이름을 자연스럽게 쓸 수 있게 한다. 카카오·라인 같은 회사의 iOS 팀에서 도입 가능성이 높은 이유다.

Swift 6.1의 다른 작은 변화들.

- **`@MainActor` 추론 강화** — UIView/UIViewController 서브클래스는 자동으로 `@MainActor`로 추론된다.

- **`nonisolated(unsafe)` 명시화** — 위험을 인지하고 격리를 끄는 escape hatch가 명시적으로 들어왔다.

- **typed throws GA** — `func foo() throws(MyError)` 형태. Rust의 `Result` 같은 타입 안전 에러 전파가 가능하다.

- **package manager noncopyable types 지원** — `~Copyable` 제네릭이 SPM 패키지 인터페이스에 정식 노출된다.

// typed throws

enum NetworkError: Error {

case timeout

case unauthorized

}

func fetch(_ url: URL) async throws(NetworkError) -> Data {

// ...

}

// 호출 측은 정확히 NetworkError만 catch

do {

let data = try await fetch(url)

} catch .timeout {

// ...

} catch .unauthorized {

// ...

}

typed throws는 Java의 checked exception을 떠올리게 하지만 — Swift의 구현은 더 가볍다. 그냥 generic이다. `throws` 자체가 `throws(any Error)`의 sugar로 모델링된다.

3장 · Swift 6.2 preview — concurrency 개선

Swift 6.2는 2026년 가을 GA를 목표로 preview 단계다. Xcode 17 beta에 포함돼 있다. 핵심 방향 하나 — **strict concurrency를 더 "기본값"답게 만든다.**

6.0/6.1에서 가장 자주 나오는 불만은 — "단순한 코드가 갑자기 데이터 레이스 경고를 받는다"였다. 6.2는 그 마찰 지점을 깎는다.

**1) `@MainActor` 기본 추론 확장.** UI 코드 외에도 SwiftUI View, ViewModel 패턴, Combine publisher가 자동으로 `@MainActor`로 추론된다. 새 프로젝트는 거의 `@MainActor` 코드만 쓰게 되고, 명시적으로 `nonisolated`나 다른 actor 격리를 표시했을 때만 worker 컨텍스트로 빠진다.

**2) Sendable 자동 추론 강화.** struct·enum이 모든 저장 프로퍼티가 Sendable이면 자동으로 Sendable이 된다. 이미 6.1에서 시작된 변화지만 6.2에서는 cross-module 추론까지 확장된다.

**3) `async let`·TaskGroup 진단 개선.** 가장 자주 틀리는 부분이 "값을 캡처해서 task에 넘기는데 그 값이 Sendable이 아닐 때"다. 6.2는 어떤 변수가 어떤 task로 escape하는지 더 정확히 추적하고, 수정 제안(fix-it)도 더 친절하다.

**4) `Span` / `RawSpan` 타입.** Rust의 `&[T]`·`&str`과 비슷한 borrowed view 타입. ArraySlice보다 가볍고, 안전한 zero-copy 데이터 접근을 가능하게 한다.

// Swift 6.2 preview

extension Array {

func sumFirstHalf() -> Element where Element: Numeric {

let half: Span<Element> = self.span.prefix(self.count / 2)

return half.reduce(0, +)

}

}

**5) C++ interop 안정화.** Swift ↔ C++ bidirectional interop이 6.2에서 한 단계 더 안정화된다. 의존성 그래프, 템플릿 인스턴스화, RAII 매핑이 매끈해진다. 이건 단순한 도구 개선이 아니라 — Swift를 "기존 C++ 코드베이스에 점진적으로 도입할 수 있는 언어"로 만드는 작업이다.

6.2의 슬로건은 "strict concurrency가 더 이상 보이지 않게(invisible)"이다. 잘 작성된 코드라면 사용자는 거의 격리 어노테이션을 안 쓰고도 안전한 코드를 짤 수 있어야 한다는 게 목표다.

4장 · SwiftUI 6 (iOS 18) — Mesh gradient / scroll position / View Transition

SwiftUI 6은 iOS 18 / macOS 15 / visionOS 2와 함께 2024년 가을에 출시됐고, 2025년 내내 안정화 패치가 이어졌다. 가장 눈에 띄는 신기능 세 가지.

**1) Mesh gradient.** 2D 메시 격자에 색을 배치하고 그 사이를 보간하는 그래디언트다. linear/radial보다 표현력이 훨씬 좋고, Sketch·Figma에서만 보던 부드러운 색 전이를 SwiftUI에서 native로 그릴 수 있다.

struct MeshDemo: View {

var body: some View {

MeshGradient(

width: 3,

height: 3,

points: [

.init(0, 0), .init(0.5, 0), .init(1, 0),

.init(0, 0.5), .init(0.5, 0.5), .init(1, 0.5),

.init(0, 1), .init(0.5, 1), .init(1, 1),

],

colors: [

.red, .purple, .blue,

.orange, .white, .cyan,

.yellow, .green, .mint,

]

)

.ignoresSafeArea()

}

}

**2) Scroll position binding.** `ScrollView`의 스크롤 위치를 `@State`로 양방향 바인딩한다. 옛 iOS의 `contentOffset` 같은 명령형 API를 안 쓰고도 "특정 셀로 이동" / "지금 어디 스크롤됐는지" 추적이 선언적으로 된다.

struct ScrollDemo: View {

@State private var scrollPosition = ScrollPosition(idType: Int.self)

var body: some View {

ScrollView {

LazyVStack {

ForEach(0..<100, id: \.self) { i in

Text("Row \(i)")

.id(i)

}

}

.scrollTargetLayout()

}

.scrollPosition($scrollPosition)

.safeAreaInset(edge: .top) {

Button("Top") { scrollPosition.scrollTo(id: 0) }

}

}

}

**3) View Transition.** Hero animation이라고 부르던 화면 간 공유 요소 전이가 selector 없이 매끈하게 들어왔다. `matchedTransitionSource` + `navigationTransition`을 짝지어 쓰면 NavigationStack 이동에서도 자연스럽게 작동한다.

@Namespace var ns

NavigationLink(value: photo) {

Image(photo.thumb)

.matchedTransitionSource(id: photo.id, in: ns)

}

.navigationDestination(for: Photo.self) { photo in

PhotoDetail(photo: photo)

.navigationTransition(.zoom(sourceID: photo.id, in: ns))

}

**4) 그 외 작은 것들.**

- `@Entry` 매크로 — Environment 키를 한 줄로 정의.

- `TabView` rewrite — sidebar 적응, fluid customization.

- `Charts` 개선 — 3D chart, vector-based annotation.

- `Subview` API — 자식 뷰를 인덱싱하는 새로운 방식, ForEach 외에 일반 view tree에도 적용 가능.

iOS 18.4 이후로 `Translation` framework가 SwiftUI와 통합돼, 화면 안 텍스트를 device-local로 번역하는 view modifier도 들어왔다. Apple Intelligence 의존성이라 모든 기기에서 도는 건 아니지만 — 한국어·일본어를 다루는 앱에서는 매력적이다.

5장 · SwiftData — Core Data 후속

Core Data는 2005년 macOS 10.4 Tiger와 함께 등장한 Apple의 ORM이다. 안정적이지만 — Objective-C 시대의 API라 NSManagedObject·NSFetchRequest 같은 옛날 패턴이 가득하다. SwiftData는 같은 자리를 노리는 Swift-native 후속이고, 2023년 iOS 17에서 발표돼 2024-2025년에 본격 안정화됐다. 2026년 5월 현재 신규 프로젝트의 default는 SwiftData다.

SwiftData의 핵심 — **`@Model` 매크로로 클래스를 정의하면 자동으로 persistent class가 된다.**

@Model

final class Note {

var title: String

var body: String

var createdAt: Date

@Relationship(deleteRule: .cascade) var tags: [Tag]

init(title: String, body: String, tags: [Tag] = []) {

self.title = title

self.body = body

self.createdAt = .now

self.tags = tags

}

}

@Model

final class Tag {

@Attribute(.unique) var name: String

init(name: String) { self.name = name }

}

SwiftUI에서 쓸 때는 `@Query`로 read하고 `modelContext.insert()`로 write한다.

struct NoteList: View {

@Query(sort: \Note.createdAt, order: .reverse) var notes: [Note]

@Environment(\.modelContext) var modelContext

var body: some View {

List(notes) { note in

VStack(alignment: .leading) {

Text(note.title).font(.headline)

Text(note.body).lineLimit(2)

}

}

.toolbar {

Button("Add") {

modelContext.insert(Note(title: "New", body: ""))

}

}

}

}

뒤에서는 여전히 Core Data가 돌고 있다. SwiftData는 Core Data 위의 Swift-native layer일 뿐이라 — Core Data 기반 앱의 점진적 마이그레이션이 가능하다. iCloud 동기화(CloudKit)도 그대로 작동한다.

SwiftData의 한계 — 2025년까지 가장 자주 들리던 불만은 "performance"였다. 큰 dataset(10만+ row)에서 `@Query`가 main thread에서 평가되며 UI를 막거나, undo manager가 의도치 않게 모든 변경을 stack에 쌓는 문제 등이 있었다. iOS 18.x 패치를 거치며 많이 좋아졌지만 — 대규모 catalog 앱이라면 여전히 Core Data 직접 사용을 고려한다.

다른 옵션도 있다.

- **GRDB.swift** — SQLite 위의 Swift-native ORM. Core Data 의존성 없이 가벼움.

- **Realm** — MongoDB 인수 이후 안정적이지만 신규 채택은 줄어드는 추세.

- **Supabase Swift SDK** — 백엔드까지 같이 가는 경우.

- **Drizzle ORM (서버 Swift 측)** — 서버에서 Postgres 다룰 때.

iOS 앱에서 작은 데이터(10MB 미만, 1만 row 미만)면 SwiftData가 default 선택지다. 그 위로 가면 GRDB를 본다.

6장 · Vapor 4 — 서버 Swift 표준

서버 사이드 Swift의 사실상 표준은 **Vapor 4**다. 2016년 첫 버전 출시, 2020년 Vapor 4가 async/await를 받아들였고, 2026년 5월 현재 4.x 메이저 안에서 계속 진화 중이다.

Vapor의 매력은 — **Express/Koa·Fastify·NestJS와 닮은 익숙한 라우팅 + Swift의 타입 안전성**이다.

struct TodoController: RouteCollection {

func boot(routes: RoutesBuilder) throws {

let todos = routes.grouped("todos")

todos.get(use: index)

todos.post(use: create)

todos.group(":todoID") { todo in

todo.get(use: show)

todo.delete(use: delete)

}

}

func index(req: Request) async throws -> [Todo] {

try await Todo.query(on: req.db).all()

}

func create(req: Request) async throws -> Todo {

let todo = try req.content.decode(Todo.self)

try await todo.save(on: req.db)

return todo

}

func show(req: Request) async throws -> Todo {

guard let todo = try await Todo.find(req.parameters.get("todoID"), on: req.db) else {

throw Abort(.notFound)

}

return todo

}

func delete(req: Request) async throws -> HTTPStatus {

guard let todo = try await Todo.find(req.parameters.get("todoID"), on: req.db) else {

throw Abort(.notFound)

}

try await todo.delete(on: req.db)

return .noContent

}

}

Vapor의 구성 요소.

- **routing** — async-first 핸들러, parameter binding.

- **Fluent ORM** — Postgres·MySQL·SQLite·MongoDB 드라이버.

- **Leaf** — 템플릿 엔진 (server-rendered HTML).

- **JWT** — 인증/인가.

- **Queues** — 백그라운드 job, Redis 기반.

- **WebSocketKit** — 양방향 통신.

- **OpenAPIKit / openapi-generator-swift** — OpenAPI 코드 생성.

production 사례 — Vapor는 Kodeco(구 Ray Wenderlich), Transeo, Emerge Tools 같은 곳에서 production을 돌리고, Apple도 일부 internal tooling을 Vapor로 짠다고 알려져 있다. 트래픽 규모는 Node/Go 정도는 아니지만 — Swift를 클라이언트와 서버 양쪽에서 쓰고 싶은 팀에게는 강력한 선택지다.

7장 · Hummingbird 2 (Apple 후원) — Swift Server Workgroup

**Hummingbird**는 Adam Fowler가 만든 alternative 서버 프레임워크다. 1.x 시절에는 "lightweight Vapor"로 불렸는데 — 2024년 2.0이 나오면서 Apple의 Swift Server Workgroup(SSWG)이 후원하는 표준 후보로 위상이 올라갔다.

Hummingbird 2의 매력 세 가지.

**1) 의존성이 적다.** Vapor가 Fluent·Leaf·JWT 등 풀스택을 묶어 제공한다면, Hummingbird는 라우터 + middleware + HTTP 처리만 한다. ORM·템플릿·인증은 별도 패키지로 조립한다. Express vs NestJS 관계와 비슷하다.

**2) Swift Concurrency native.** 처음부터 async/await + structured concurrency 기반으로 설계됐다. SwiftNIO 위에서 동작하지만 — NIO의 EventLoopFuture를 직접 노출하지 않는다.

**3) AWS Lambda 친화적.** 콜드 스타트가 빠르고 binary size가 작다. swift-aws-lambda-runtime과 잘 어울려 — Swift on Lambda 시나리오에서 Hummingbird가 점점 default가 되어가고 있다.

let router = Router()

router.get("/") { _, _ in

"Hello, Hummingbird 2"

}

router.get("/users/:id") { req, ctx in

let id = try ctx.parameters.require("id", as: Int.self)

return User.fetch(id: id)

}

let app = Application(

router: router,

configuration: .init(address: .hostname("0.0.0.0", port: 8080))

)

try await app.runService()

Vapor vs Hummingbird 결정 가이드.

| 항목 | Vapor 4 | Hummingbird 2 |

| --- | --- | --- |

| 포지셔닝 | 풀스택 프레임워크 | 마이크로 라우터 |

| ORM | Fluent 번들 | GRDB·기타 별도 |

| async/await | 후방 호환성 안에서 | native 설계 |

| Lambda | 가능하지만 크다 | 콜드 스타트 빠름 |

| 학습 곡선 | 낮음 (Express-like) | 낮음 (더 작음) |

| 커뮤니티 | 큼 (오래됨) | 성장 중 |

| Apple 후원 | 비공식 | SSWG 공식 |

큰 모놀리스나 server-rendered HTML 앱이면 Vapor. 마이크로서비스·Lambda·minimal binary가 필요하면 Hummingbird. SSR 없이 API-only면 둘 다 잘 한다.

8장 · Tuist + Mint + swift-package-manager — 빌드 / 도구

**SwiftPM(swift-package-manager)** 은 Apple 공식 패키지 매니저다. CocoaPods·Carthage의 시대는 거의 끝났고, 2026년 새 프로젝트는 SwiftPM이 default다. `Package.swift`로 의존성을 선언하고, Xcode·CLI 양쪽이 이해한다.

// swift-tools-version: 6.1

let package = Package(

name: "MyLib",

platforms: [.iOS(.v17), .macOS(.v14)],

products: [

.library(name: "MyLib", targets: ["MyLib"]),

],

dependencies: [

.package(url: "https://github.com/apple/swift-collections.git", from: "1.1.0"),

],

targets: [

.target(name: "MyLib", dependencies: [

.product(name: "Collections", package: "swift-collections"),

]),

.testTarget(name: "MyLibTests", dependencies: ["MyLib"]),

]

)

**한계** — SwiftPM은 단순한 라이브러리 패키지에는 좋지만, iOS 앱처럼 storyboard·xcassets·info.plist·scheme이 복잡하게 얽힌 프로젝트에서는 부족하다. 그래서 등장한 게 Tuist.

**Tuist**는 `Project.swift`(SwiftPM이 아닌, Tuist 전용 DSL)로 Xcode 프로젝트를 생성한다. 큰 모노리포에서 모듈을 잘게 나누고, 모듈 간 의존 그래프를 코드로 표현하고, 캐시·증분 빌드까지 받쳐 준다.

// Project.swift

let project = Project(

name: "MyApp",

targets: [

.target(

name: "MyApp",

destinations: .iOS,

product: .app,

bundleId: "com.example.MyApp",

infoPlist: .extendingDefault(with: [

"CFBundleShortVersionString": "1.0.0",

]),

sources: ["Sources/**"],

resources: ["Resources/**"],

dependencies: [

.target(name: "Core"),

.target(name: "Network"),

]

),

.target(name: "Core", destinations: .iOS, product: .framework, bundleId: "com.example.Core", sources: ["Modules/Core/**"]),

.target(name: "Network", destinations: .iOS, product: .framework, bundleId: "com.example.Network", sources: ["Modules/Network/**"], dependencies: [.target(name: "Core")]),

]

)

Tuist는 카카오·라인·메르카리처럼 모듈 수가 100개를 넘는 모노리포에서 자리를 굳혔다. `tuist generate`로 Xcode 프로젝트를 만들고, `tuist build`로 캐시된 증분 빌드를 돌린다. 2024년 Tuist Cloud(이후 Tuist 자체로 통합)가 등장하며 빌드 캐시를 팀 단위로 공유하는 기능도 들어왔다.

**Mint**는 Swift로 작성된 CLI 도구를 설치하는 도구다. SwiftLint·SwiftFormat·swiftgen·xcodegen·Sourcery 같은 도구를 Homebrew 대신 Mint로 깔면 — 팀 전체가 같은 버전을 쓰도록 `Mintfile`로 못 박을 수 있다.

Mintfile 예

realm/SwiftLint@0.59.1

nicklockwood/SwiftFormat@0.55.0

yonaskolb/XcodeGen@2.42.0

설치

mint bootstrap

실행

mint run swiftlint

큰 팀에서는 SwiftPM(라이브러리) + Tuist(프로젝트 생성) + Mint(CLI 도구) 세 가지를 같이 쓰는 게 표준 조합이 됐다.

9장 · swift-syntax / swift-format / SwiftLint / SwiftFormat

이 네 도구는 모두 "Swift 소스 코드를 다룬다"는 점에서 같은 가족이다.

**swift-syntax** — Apple이 만든 공식 AST 라이브러리. swift 컴파일러가 쓰는 같은 lexer/parser를 노출한다. 매크로(`@Macro`, Swift 5.9+)를 짤 때 필수다. ResultBuilder·Codable 같은 컴파일러 기능을 사용자 코드로 확장할 수 있게 한다.

**swift-format** — Apple 공식 포매터. Google의 swift-format을 Apple이 인수해 swiftlang/ 조직 아래로 옮겼다. 정해진 스타일 가이드(주로 Apple style)를 따르고, 옵션이 많지 않다. swift-syntax 기반.

**SwiftFormat** — Nick Lockwood가 만든 커뮤니티 포매터. 옵션이 매우 많고 — 100개 이상의 rule을 켜고 끌 수 있다. 옛 코드베이스를 점진적으로 정리할 때 유리하다.

**SwiftLint** — Realm이 만든 린터. JonAS·Mac·iOS 표준 코딩 컨벤션을 강제한다. 포매터는 아니다(자동 수정도 일부 있지만 주 목적은 검사다). 200+ rule, custom rule 정의 가능.

차이를 한 표로.

| 도구 | 역할 | 옵션 | Apple 공식 | 자동 수정 |

| --- | --- | --- | --- | --- |

| swift-syntax | AST 라이브러리 | n/a | O | n/a |

| swift-format | 포매터 | 적음 | O | O |

| SwiftFormat | 포매터 | 많음 | X | O |

| SwiftLint | 린터 | 많음 | X | 부분 |

실무 조합 가이드.

- **신규 프로젝트** — swift-format(Apple style 따르기) + SwiftLint(검사).

- **레거시 프로젝트** — SwiftFormat(옵션으로 옛 스타일 유지) + SwiftLint.

- **매크로/메타프로그래밍** — swift-syntax 직접.

SwiftLint config 예.

disabled_rules:

- trailing_whitespace

opt_in_rules:

- empty_count

- missing_docs

included:

- Sources

excluded:

- Tests/Resources

- .build

line_length:

warning: 120

error: 200

identifier_name:

min_length: 2

excluded:

- id

- i

- x

- y

custom_rules:

no_print:

name: "No print()"

regex: "print\\("

message: "Use Logger instead of print()"

severity: error

CI에서는 SwiftLint를 `--strict`로 돌리고, swift-format 또는 SwiftFormat을 `--lint`로 돌려서 PR에서 막는 게 표준이다.

10장 · swift-testing (Swift 6.0 신규) — XCTest 대체

XCTest는 Objective-C 시대 유산이다. `func test...` 네이밍, `XCTAssertEqual()` 헬퍼, 인스턴스 시기 라이프사이클 — 모두 OOP-first 디자인이다. **swift-testing**은 Swift 6.0(2024년 9월)과 함께 정식 출시된 새로운 테스트 프레임워크로, Swift macro 시스템을 적극 활용한다.

기본 비교.

// XCTest (옛날)

final class CalculatorTests: XCTestCase {

func testAddition() {

let result = Calculator.add(2, 3)

XCTAssertEqual(result, 5)

}

func testDivision() throws {

let result = try Calculator.divide(10, 2)

XCTAssertEqual(result, 5)

}

}

// swift-testing (Swift 6.0+)

@Test func addition() {

let result = Calculator.add(2, 3)

#expect(result == 5)

}

@Test func division() throws {

let result = try Calculator.divide(10, 2)

#expect(result == 5)

}

차이가 한눈에 들어온다. `XCTAssertEqual(a, b)`처럼 헬퍼별로 다른 함수를 외울 필요가 없고, `#expect(...)`는 매크로라서 실패했을 때 표현식 전체를 자동으로 분해해 보여준다 — Rust의 `assert!`나 Catch2의 `REQUIRE`와 비슷한 발상이다.

매개변수화(parameterized) 테스트.

@Test(arguments: [(2, 3, 5), (10, -3, 7), (0, 0, 0)])

func addition(a: Int, b: Int, expected: Int) {

#expect(Calculator.add(a, b) == expected)

}

조건부 실행.

@Test(.enabled(if: ProcessInfo.processInfo.environment["CI"] == nil))

func localOnlyTest() {

// 로컬 머신에서만 실행

}

비동기 테스트는 그냥 `async`를 붙이면 된다.

@Test func fetchesUser() async throws {

let user = try await api.fetchUser(id: 1)

#expect(user.name == "Alice")

}

XCTest와의 공존 — swift-testing은 XCTest와 같은 binary에서 같이 돈다. `import Testing`과 `import XCTest`를 같은 타깃에 섞어 쓸 수 있다. 그래서 전체를 한 번에 마이그레이션할 필요가 없고 — 새 테스트만 swift-testing으로 짜고 옛 테스트는 그대로 둘 수 있다.

XCTest는 사라지지 않는다. UI 테스트(`XCUIApplication`)와 성능 테스트(`measure { }`)는 여전히 XCTest 영역이다. swift-testing은 unit/integration 테스트를 노린다.

11장 · Android Swift Working Group (2024.11) — Swift on Android

2024년 11월 swift.org에 짧지만 결정적인 글이 올라왔다 — **"Android Swift Working Group이 발족했다."** Apple, Google(Android 측), 그리고 커뮤니티가 함께 Android에서 Swift를 1급 시민으로 만든다는 선언이었다.

배경. 이전에도 Swift on Android 시도는 있었다. Readdle 같은 회사가 사내에서 Swift로 Android 앱을 짜는 데 성공했고, scade.io 같은 상용 도구가 있었고, swift-corelibs-foundation이 Android target을 부분 지원했다. 그러나 모두 비공식·실험적이었고, 표준 라이브러리 일부가 빠지거나, NDK 통합이 불완전하거나, App Store가 아니라 Play Store에 올리는 길에서 막혔다.

Android Swift WG의 목표(2024.11 발족 시점 공개된 내용).

1. **공식 toolchain** — swift.org에서 Android target binary를 정식 배포.

2. **표준 라이브러리 호환성** — Foundation·Network·Concurrency 모두 Android에서 동작.

3. **JNI bridge** — Swift ↔ Kotlin/Java 상호 호출.

4. **Android-specific 라이브러리** — Activity·Intent 같은 핵심 Android API에 Swift native 바인딩.

5. **빌드 통합** — Gradle 안에서 Swift 모듈을 빌드하는 표준.

2026년 5월 현재 진행 상황 — WG 발족 후 1년 반이 지났고, 실험적 toolchain이 배포되어 hello world 수준은 잘 도는 상태다. Foundation·Concurrency는 대부분 작동한다. 진짜 production 앱을 짤 수 있는 단계는 아직 아니지만 — 2027년쯤이면 Kotlin Multiplatform과 경쟁할 수 있는 옵션이 될 가능성이 있다.

기대치 — Swift on Android는 "Android 앱을 Swift로만 짜자"가 아니라 "iOS 코드의 비즈니스 로직을 Android에서 재사용하자"가 더 현실적인 시나리오다. UI는 SwiftUI(iOS) + Compose(Android)로 따로 짜고, 모델·네트워크·도메인 로직만 Swift로 공유하는 그림이다.

대안 — Kotlin Multiplatform이 이미 같은 일을 하고 있고, JetBrains 후원으로 더 성숙하다. Compose Multiplatform이 iOS까지 지원하며 영역을 넓히고 있다. Swift on Android가 자리잡으려면 KMP보다 더 좋은 무언가를 제공해야 한다 — 그게 뭔지는 2027년쯤 분명해질 것이다.

12장 · swift-foundation 재작성 (오픈소스) + Embedded Swift

**swift-foundation**은 Foundation 프레임워크(NSString·NSDate·URLSession·JSONSerialization 등)를 Objective-C 의존성 없이 순수 Swift로 다시 쓰는 프로젝트다. github.com/swiftlang/swift-foundation에서 개발된다.

왜 다시 쓰나. 옛 Foundation은 두 버전이 있었다. Apple Darwin에서는 Objective-C 기반 NSFoundation을, Linux에서는 swift-corelibs-foundation(C 기반)을 썼다. 같은 API를 약속하지만 동작이 미묘하게 달랐다 — date formatting, URL parsing, JSON encoding 모두 OS마다 달랐고, 버그가 한쪽에만 있는 일이 잦았다.

swift-foundation의 약속 — **모든 OS에서 같은 코드가 돌고, 같은 동작을 한다.** Darwin도 점진적으로 swift-foundation으로 갈아탄다. 2024-2025년에 Calendar·Date·JSONEncoder·URL 같은 핵심 타입이 마이그레이션됐고, 2026년에는 URLSession·FileManager가 마이그레이션 중이다.

영향 — Linux/Server Swift에서 가장 크다. 이전에는 macOS에서 잘 돌던 코드가 Linux에서 뜬금없이 깨졌는데, swift-foundation 이후로는 그런 일이 거의 없어진다. Embedded Swift, Android Swift에서도 같은 Foundation을 쓸 수 있다는 게 큰 변화다.

**Embedded Swift**는 2024년 WWDC 키노트에 등장한 새 모드다. 일반 Swift는 ARC·동적 dispatch·exception 처리·Foundation 의존성이 무거워서 임베디드 마이크로컨트롤러(STM32, ESP32)에 올리기 어려웠다. Embedded Swift는 Swift 언어의 일부 기능을 빼서 그런 환경에서 동작하는 작은 바이너리를 만든다.

빠지는 것들.

- **standard library의 일부** — Foundation 거의 전체, Combine, Concurrency runtime의 일부.

- **동적 기능** — runtime metadata reflection (Mirror), JSONDecoder의 모든 동적 디코딩.

- **예외** — `throws`는 가능하지만 runtime exception unwinding 없음.

남는 것들.

- **언어 기본** — struct·enum·class·generic·protocol.

- **소유권 시스템** — `~Copyable`, `~Escapable`.

- **Concurrency 일부** — async/await의 lightweight version (`embedded` 모드).

- **C interop** — 그대로 작동.

용도 — 마이크로컨트롤러 펌웨어, IoT 디바이스, 일부 driver/kernel 모듈. Apple은 SecureEnclave 같은 일부 내부 컴포넌트를 Embedded Swift로 재작성하고 있다고 알려져 있다. 외부에서는 ESP32 보드에서 Embedded Swift를 돌리는 데모와 raspberry pi pico 예제가 swift-embedded-examples에 있다.

// Embedded Swift 예 — Raspberry Pi Pico LED 깜빡이기

@main struct App {

static func main() {

let led = GPIO(pin: 25, direction: .output)

while true {

led.high()

sleep(milliseconds: 500)

led.low()

sleep(milliseconds: 500)

}

}

}

Rust on embedded(embedded-hal·esp-rs)와의 경쟁이 시작됐다. Rust는 5-6년 먼저 출발했지만 — Apple의 무게가 실린 Embedded Swift가 어디까지 갈지 흥미로운 시기다.

13장 · Concurrency — actors / async / await / Sendable

Swift Concurrency는 5.5(2021)에 시작해 5.7(actor)·5.9(macros)·6.0(strict)·6.1(complete)을 거치며 단계적으로 완성됐다. 핵심 개념 네 가지.

**1) async/await.** 비동기 코드를 동기처럼 짠다. Promise/Future가 명시적으로 노출되지 않는다.

func fetchUser(id: Int) async throws -> User {

let (data, _) = try await URLSession.shared.data(from: url)

return try JSONDecoder().decode(User.self, from: data)

}

// 호출

let user = try await fetchUser(id: 1)

**2) actor.** 상태를 가진 객체. 내부 데이터에 대한 접근이 직렬화돼 데이터 레이스를 막는다.

actor Counter {

private var count = 0

func increment() { count += 1 }

func value() -> Int { count }

}

let counter = Counter()

await counter.increment() // actor 외부에서는 await 필수

let v = await counter.value()

**3) Sendable.** "여러 thread에서 안전하게 공유할 수 있는 타입"이라는 marker protocol. 컴파일러가 이 표시를 보고 actor 경계를 넘는 값 전달을 검사한다.

struct UserInfo: Sendable {

let id: Int

let name: String // String은 자동으로 Sendable

}

class MutableBox {

var value: Int = 0 // class에 mutable property → Sendable 불가능

}

// MutableBox는 Sendable 아님 → actor 경계 넘어 보내면 컴파일 오류

**4) Strict Concurrency.** Sendable 검사를 어디까지 강하게 할지 결정하는 컴파일러 모드. Swift 6.0부터 "complete"가 default가 됐고, 6.1에서 false positive가 크게 줄었다.

Package.swift에서 켜는 법

.target(

name: "MyLib",

swiftSettings: [

.enableExperimentalFeature("StrictConcurrency"),

]

)

**`@MainActor`.** UI 코드는 모두 main thread에서 돌아야 한다는 약속을 컴파일러가 강제한다.

@MainActor

class ViewModel: ObservableObject {

@Published var users: [User] = []

func load() async {

let result = try? await api.fetchUsers() // worker actor에서 돔

self.users = result ?? [] // main actor로 hop

}

}

여기서 `api.fetchUsers()`는 `@MainActor`가 아닌 다른 actor 컨텍스트에서 돌고, 결과를 받아 `self.users`에 쓸 때 자동으로 main thread로 hop한다. C++/Java에서는 사람이 직접 `dispatch_async(main_queue, ^{...})` 같은 걸 써야 했지만 — Swift는 컴파일러가 자동으로 처리한다.

**region-based isolation** (Swift 6.0+). 단일 인스턴스가 한 task에서 다른 task로 "보내질" 수 있도록 허용하는 새로운 방식. 옛날에는 `Sendable`이어야만 actor 경계를 넘었는데, region isolation은 "이 값이 지금 한 곳에서만 쓰이고 있다는 걸 증명할 수 있으면" 넘게 해 준다.

func process() async {

let data = NonSendableData()

await someActor.use(data) // Swift 5.x에서는 오류, Swift 6.x region isolation으로 허용

// 단, 이 시점 이후로 data를 다시 쓰면 컴파일 오류

}

이게 strict concurrency의 false positive를 줄여 주는 가장 큰 개선이다.

14장 · Observation + Macros — iOS 17+ 신기능

**Observation 프레임워크**는 iOS 17(2023)에 들어온 신규 reactive 시스템이다. 이전의 `@Published`/Combine 기반 `ObservableObject` 패턴을 더 가볍게 대체한다.

옛 방식 (Combine ObservableObject).

class UserStore: ObservableObject {

@Published var users: [User] = []

@Published var isLoading = false

}

struct UserList: View {

@StateObject var store = UserStore()

var body: some View {

if store.isLoading { ProgressView() }

else { List(store.users) { Text($0.name) } }

}

}

새 방식 (Observation).

@Observable

class UserStore {

var users: [User] = []

var isLoading = false

}

struct UserList: View {

@State var store = UserStore()

var body: some View {

if store.isLoading { ProgressView() }

else { List(store.users) { Text($0.name) } }

}

}

차이.

- `@Published` 필요 없음 — Observation이 매크로로 자동 처리.

- `ObservableObject` 채택 필요 없음.

- `@StateObject` → `@State`로 단순화.

- **세밀한 invalidation** — 옛날에는 어떤 published property가 바뀌어도 전체 view가 다시 그려졌지만, Observation은 실제로 view가 읽은 property만 추적해서 그것만 invalidate한다. 성능 큰 개선.

뒤에서 `@Observable` 매크로가 클래스 안에 KeyPath 기반 tracking 코드를 자동 생성한다. swift-syntax 위에 짜인 macro이고, 사용자가 직접 확장할 수도 있다.

**Macros (Swift 5.9+)**. 매크로는 컴파일 타임에 코드를 생성하는 메커니즘이다. C macro와 다르게 — 텍스트 치환이 아니라 AST 변환이다. swift-syntax가 노출하는 AST를 받아서, 새 AST를 반환하는 함수다.

매크로의 두 가지.

**1) Freestanding macro** — `#stringify`처럼 호출.

let (result, code) = #stringify(2 + 3)

// 컴파일 후: (5, "2 + 3")

**2) Attached macro** — `@AddCompletionHandler`처럼 선언에 붙여.

@AddAsync

func fetch(completion: @escaping (Result<Data, Error>) -> Void) {

// ...

}

// 매크로가 다음을 자동 생성:

// func fetch() async throws -> Data { ... }

표준 라이브러리·SDK가 매크로를 적극 활용한다.

- `@Observable` — 위에서 본 것.

- `@Model` (SwiftData) — persistent class 생성.

- `#expect` (swift-testing) — assertion 매크로.

- `@Entry` (SwiftUI 6) — Environment 키 정의.

- `#Predicate` (SwiftData/Foundation) — type-safe query.

사용자 매크로 짜기 예 (간략).

public struct StringifyMacro: ExpressionMacro {

public static func expansion(

of node: some FreestandingMacroExpansionSyntax,

in context: some MacroExpansionContext

) -> ExprSyntax {

guard let argument = node.argumentList.first?.expression else {

fatalError("compiler bug: the macro does not have any arguments")

}

return "(\(argument), \(literal: argument.description))"

}

}

매크로는 별도 타깃 (`.macro(...)`)에 정의되고, compiler plugin으로 빌드된다. 일반 코드와 분리돼 있어 compile time 안정성을 보장한다.

매크로의 한계 — 컴파일 시간이 늘어난다(swift-syntax 의존성이 무겁다). 그래서 자주 쓰는 매크로는 미리 컴파일된 binary로 제공되는 추세다.

15장 · 한국 / 일본 — 카카오, 라인, 메르카리, Cookpad, ピクシブ

Swift는 한국·일본 iOS 팀의 default 언어다. 누가 어떻게 쓰는지 — 공개된 컨퍼런스 발표·블로그·채용 공고를 종합한다.

**한국**.

- **카카오** — iOS 앱(카카오톡·카카오뱅크·카카오맵·카카오웹툰)은 거의 모두 Swift. 카카오톡은 모듈이 100개를 훌쩍 넘는 대규모 모노리포라 Tuist 도입 사례로도 알려져 있다. RxSwift → Combine → Swift Concurrency 이행을 단계적으로 진행 중. 사내 컨퍼런스 "if(kakao)"에서 SwiftUI·SwiftData 도입 후기를 매년 발표.

- **라인** — 일본 본사 발 라인 앱이 Swift 기반. 한국 라인플러스도 Swift 표준. swift-testing 도입을 빨리 시도한 팀 중 하나로 알려져 있다.

- **토스 (Toss)** — 모든 iOS는 Swift. Tuist + 모듈화 + Combine + SwiftUI 일부 도입. 디자인 시스템과 컴포넌트 라이브러리를 SwiftPM 패키지로 사내 배포.

- **쿠팡** — iOS 앱 Swift. 옛 ObjC 코드도 일부 남아 있는 마이그레이션 사례.

- **당근 (Karrot)** — Swift + SwiftUI 적극 도입. 사내 RFC로 SwiftData 도입 검토 발표.

- **네이버** — 네이버 앱·네이버지도·웹툰·V LIVE 등 iOS는 Swift. 사내 라이브러리들을 SwiftPM 패키지로 정리하는 작업이 알려져 있다.

**일본**.

- **メルカリ (Mercari)** — iOS 앱 Swift, 마이크로서비스 일부는 Vapor·Hummingbird로 검토. 사내에서 swift-testing 마이그레이션 가이드 공개.

- **クックパッド (Cookpad)** — iOS 앱 Swift. iOSDC Japan에서 SwiftUI 도입 사례 발표.

- **CyberAgent (ABEMA, AmebaTV)** — ABEMA iOS는 Swift + SwiftUI. 사내 다수 iOS 앱이 Tuist 사용. 사이버에이전트의 iOS 엔지니어 다수가 swift.org·iOSDC에 적극 기여.

- **ピクシブ (pixiv)** — iOS 앱 Swift. pixivFANBOX·pixivSketch·BOOTH 등 자매 앱들도 Swift.

- **DeNA** — 사내 모든 iOS 앱이 Swift. 사내 swift toolchain 미러를 운영.

- **Yahoo! Japan (LY Corporation)** — Yahoo!·Yahoo!ニュース·Yahoo!乗換 등이 Swift.

공통 패턴.

- **CocoaPods → SwiftPM** 마이그레이션이 거의 끝났다.

- **Combine → Swift Concurrency** 이행 중. 새 코드는 async/await first.

- **UIKit + SwiftUI 하이브리드** — 새 화면은 SwiftUI, 옛 화면은 UIKit. 점진적 마이그레이션.

- **Tuist 도입** — 모듈 수가 50개 넘는 팀은 거의 다.

- **XCTest → swift-testing** — 2025-2026년 마이그레이션 시작.

한국·일본 모두 iOS 엔지니어 채용에서 "Swift Concurrency 경험", "SwiftUI 실전 경험", "모듈화/Tuist 경험"이 점점 필수 키워드가 되고 있다.

16장 · 누가 Swift를 골라야 하나 — iOS / Apple 생태계 / 서버 / 임베디드

도메인별 추천.

**iOS / macOS / visionOS / watchOS / tvOS 앱.**

- 거의 default. Swift + SwiftUI 또는 Swift + UIKit. 새 프로젝트는 SwiftUI first.

- 거대한 옛 ObjC 코드베이스가 있으면 점진적 마이그레이션. Apple 자체도 같은 길.

- Flutter·React Native·Kotlin Multiplatform이 대안이지만 — 진짜로 native 경험과 최신 OS API가 필요하면 Swift가 default.

**서버.**

- **Vapor** — 풀스택 웹 앱, server-rendered HTML 필요, Express 같은 익숙한 경험 원함.

- **Hummingbird** — 마이크로서비스, AWS Lambda, 최소 의존성 원함.

- Swift는 Go·Rust·Node 만큼 서버 표준이 아니다. **언제 굳이 Swift를 서버에 쓸까** — iOS 팀과 모델·도메인 로직을 공유하고 싶을 때. 같은 회사가 iOS·서버를 둘 다 Swift로 가져가면 코드 재사용과 채용 풀이 합쳐진다.

**Linux / 컨테이너.**

- Vapor 또는 Hummingbird로 컨테이너화된 마이크로서비스 가능. Distroless 베이스 이미지로 50-100MB 정도.

- Go·Rust보다 binary size가 크지만 — Swift도 stripped binary는 작아진다.

**Android.**

- 2026년 시점에는 production 권장 아님. Kotlin Multiplatform이 더 안정적.

- iOS 비즈니스 로직을 Android에서 재사용하는 게 목표면 — Android Swift WG 진행을 지켜보다 2027년 이후 재평가.

**임베디드 / IoT.**

- Embedded Swift는 ESP32·STM32·Raspberry Pi Pico에서 실험적으로 잘 돈다.

- production이면 Rust(embedded-hal) 또는 C가 여전히 default.

- Swift를 쓸 만한 시나리오 — Apple 액세서리 펌웨어, AirTag류 디바이스. 그 외에는 시간이 더 필요하다.

**머신러닝 / 데이터.**

- Python이 default. Swift는 Core ML 위에서 모델을 호출할 때만.

- Swift for TensorFlow는 종료됐다. 다시 부활할 가능성 낮음.

**스크립팅 / CLI.**

- swift-argument-parser로 CLI를 잘 짤 수 있다.

- 다만 시작 시간이 Python·Node보다 느리고, single-binary distribution은 SwiftPM build 후 stripped binary로 가능.

- macOS dev 도구에는 좋은 선택. cross-platform CLI에는 Go·Rust가 여전히 우세.

**그래서 Swift를 골라야 할 결정적 이유들.**

1. **iOS·macOS 앱을 만든다** — 의심의 여지 없이 default.

2. **Apple 플랫폼에 깊게 들어간다** — visionOS·watchOS·tvOS는 Swift만 사실상 가능.

3. **strict concurrency를 진지하게 쓰고 싶다** — Rust 같은 안전성을 GC·라이프타임 부담 없이 얻는다.

4. **타입 안전한 SwiftUI declarative UI를 사랑한다** — Compose보다 더 익숙하고 API가 깔끔하다는 평이 있다.

5. **iOS 팀이 서버 코드도 짜기를 원한다** — Vapor/Hummingbird로 사내 표준화.

**Swift를 안 골라야 할 이유.**

1. **Windows 데스크톱이 주력이다** — Windows에서도 Swift가 돌지만 1급 시민은 아니다.

2. **cross-platform mobile만 짠다** — Flutter·React Native·Kotlin Multiplatform이 더 성숙하다.

3. **서버 도메인 표준이 다른 언어다** — 팀이 이미 Go·Node·Java에 능숙하면 굳이 옮길 이유 적다.

4. **머신러닝/데이터** — Python.

5. **시스템 프로그래밍에 최강 안전성 필요** — Rust.

2026년의 Swift는 — Apple 플랫폼에서는 default고, 서버에서는 자기만의 자리를 만들고 있고, Android·임베디드에서는 아직 약속을 지키는 중이다. 다음 1-2년이 Apple 바깥에서의 Swift 운명을 결정할 시기다.

참고 / References

- swift.org 공식 — https://www.swift.org/

- Swift 6 발표 — https://www.swift.org/blog/announcing-swift-6/

- Swift 6.1 release — https://www.swift.org/blog/swift-6.1-released/

- Android Swift Working Group — https://www.swift.org/blog/swift-on-android-workgroup/

- Embedded Swift — https://www.swift.org/blog/embedded-swift-examples/

- swift-foundation — https://github.com/swiftlang/swift-foundation

- swift-syntax — https://github.com/swiftlang/swift-syntax

- swift-format — https://github.com/swiftlang/swift-format

- swift-testing — https://github.com/swiftlang/swift-testing

- swift-package-manager — https://github.com/swiftlang/swift-package-manager

- SwiftLint — https://github.com/realm/SwiftLint

- SwiftFormat — https://github.com/nicklockwood/SwiftFormat

- Tuist — https://tuist.io/

- Mint — https://github.com/yonaskolb/Mint

- Vapor — https://vapor.codes/

- Hummingbird — https://hummingbird.codes/

- Swift Server Workgroup — https://www.swift.org/sswg/

- SwiftUI documentation — https://developer.apple.com/documentation/swiftui

- SwiftData documentation — https://developer.apple.com/documentation/swiftdata

- Observation framework — https://developer.apple.com/documentation/observation

- Macros proposal (SE-0382) — https://github.com/swiftlang/swift-evolution/blob/main/proposals/0382-expression-macros.md

- Strict Concurrency proposal (SE-0337) — https://github.com/swiftlang/swift-evolution/blob/main/proposals/0337-async-await-sendable-migration.md

- iOSDC Japan — https://iosdc.jp/

- if(kakao) 컨퍼런스 — https://if.kakao.com/

- Cookpad iOS 발표 — https://techlife.cookpad.com/

- メルカリエンジニアリングブログ — https://engineering.mercari.com/

- pixiv 開発者ブログ — https://devpixiv.hatenablog.com/