iOYES

[SE-0532] Optional noncopyable improvements and generalizations

GREEN.1229 — Sat, 18 Jul 2026 21:33:05 +0900

안녕하세요. 그린입니다
이번 포스팅에서는 SE-0532 — Optional noncopyable 개선 및 일반화에 대해 정리해보겠습니다

Intro

Proposal: SE-0532

Author: Alejandro Alonso

Review Manager: John McCall

Status: Accepted

Implementation: swiftlang/swift#88505

Motivation

Swift 6.0에서 표준 라이브러리 일부가 noncopyable 값을 저장할 수 있도록 일반화된 이후(SE-0437), noncopyable optional을 다루는 일은 꽤 번거로웠습니다.
optional 내부 값을 살짝 들여다보고 싶은 것뿐인데, borrow만 하고 싶을 때도 마땅한 방법이 없었거든요.

아래 코드를 볼까요?

if let payload = optional {
  
}

foo(optional) // error: use after consume!

다행히 noncopyable switch를 쓰면 optional의 내용을 borrow하도록 제어 흐름을 만들 수 있습니다.

switch optional {
case .some(let wrapped):
  // wrapped는 borrow된 상태

default:
  break
}

foo(optional) // ok

하지만 if let이나 guard let에 익숙한 사람이라면 이 switch 문이 그리 직관적이진 않죠

값을 consume하지 않고 mutate만 하고 싶은 경우도 마찬가지예요.

단순한 프로퍼티 변경이나 mutating 메서드 호출 정도는 ?. 체이닝으로 충분하지만, payload를 조건부로 inout 함수에 넘기고 싶다면 이렇게 써야 합니다.

if someStruct.x != nil {
  foo(&someStruct.x!)
}

혹은 switch로 consume한 뒤 다시 초기화하는, 더 장황하고 직관적이지 않은 방식을 써야 하죠.

func foo(_: inout NoncopyableString) {}

func bar(_ x: inout NoncopyableString?) {
  switch consume x {
  case .some(var string):
    foo(&string)
    x = consume string

  default:
    x = nil
  }
}

여기에 더해 map, flatMap, unsafelyUnwrapped 같은 Optional API들도 noncopyable 래핑 타입에는 지원되지 않아서, 이런 코드를 매번 switch 문으로 직접 풀어써야 했습니다.

Proposed Solution

Optional에 새로운 프로퍼티 두 개, ref와 mutableRef를 추가합니다.

이 프로퍼티들은 내부 payload가 있으면 그 참조를, 없으면 nil을 돌려줍니다.

func bar(_ x: borrowing SomeNoncopyable) {
  ...
}

if let payload = optional.ref {
  bar(payload.value) // 'bar'는 'borrowing Wrapped'를 전달받음
}

foo(optional) // ok

func baz(_ x: inout SomeNoncopyable) {
  ...
}

if var payload = optional.mutableRef {
  baz(&payload.value) // 'baz'가 payload를 그 자리에서 mutate 가능!
}

foo(optional) // ok

이 두 프로퍼티 덕분에 optional의 소유권을 가져오지 않고도 내부 값에 조건부로 접근하는 관용적인 방법이 생겼습니다.

더불어 아래 세 메서드도 noncopyable / nonescapable 래핑 타입을 지원하도록 일반화됩니다.

map
flatMap
unsafelyUnwrapped

let optAtomicInt: Optional<Atomic> = ...
let optInt: Optional = optAtomicInt.map {
  $0.load(ordering: .relaxed)
}

let optInlineArray: Optional<[0 of Atomic]> = []
let optInt2: Optional = optInlineArray.flatMap {
  $0.isEmpty ? nil : $0[0].load(ordering: .relaxed)
}

let optMutex: Optional<Mutex> = ...
let mutex: Mutex = optMutex.unsafelyUnwrapped
optMutex?.withLock { ... } // error: use of 'optMutex' after consume

마지막으로 Optional.put()이라는 편의 API도 추가돼요!

아래처럼 !로 강제 언래핑하던 패턴을 생각해볼게요.

struct Cache: ~Copyable {
  var opt: UniqueArray?
}

var cache = Cache()
var items: UniqueArray = fooBar()
cache.opt = items

let newItem = await retrieveNewItem()
cache.opt!.append(newItem)

이미 값이 있다는 걸 알고 있는 상황이라 !가 사실 불필요하고, inline되지 않는 함수를 거치는 경우엔 컴파일러가 최적화해서 없애주지도 못해요.

put()은 새 값을 넣어주면서 그 payload에 대한 direct mutable reference를 바로 돌려줍니다.

struct Cache: ~Copyable {
  var opt: UniqueArray?
}

var cache = Cache()
let items: UniqueArray = fooBar()
var itemsRef = cache.opt.put(items)

let newItem = await retrieveNewItem()
itemsRef.value.append(newItem)

Detailed Design

ref와 mutableRef

extension Optional where Wrapped: ~Copyable & ~Escapable {
  /// optional 안에 payload가 있으면 그에 대한 borrow된 참조를 반환합니다.
  public var ref: Ref? {
    @lifetime(borrow self)
    get
  }
}

extension Optional where Wrapped: ~Copyable {
  /// optional 안에 payload가 있으면 그에 대한 mutable 참조를 반환합니다.
  public var mutableRef: MutableRef? {
    @lifetime(&self)
    mutating get
  }
}

개념적으로 이 프로퍼티들은 optional과 그 payload의 소유권을 옮기는 역할을 해요.

ref를 호출하려면 최소한 borrowing Optional<T>, 즉 Ref<Optional<T>>가 있어야 하는데, 이 ref는 그 Ref<Optional<T>>를 받아 Optional<Ref<T>>로 만들어줍니다.

참조를 optional 내부로 옮겨서, 우리가 mutate하거나 consume하거나 독점적으로 접근할 수 있는 owned 값을 돌려받는 셈이죠.

mutableRef도 마찬가지로 최소 inout Optional<T>를 받아 owned Optional<MutableRef<T>> 값으로 바꿔줍니다.

put()

extension Optional where Wrapped: ~Copyable {
  /// optional의 값을 새 값으로 설정하면서, optional 안에 새로 들어간
  /// payload에 대한 mutable 참조를 반환합니다.
  ///
  /// 이미 값이 있었다면 그 값은 destroy됩니다.
  @lifetime(&self)
  public mutating func put(_ new: consuming Wrapped) -> MutableRef
}

unsafelyUnwrapped 일반화

extension Optional where Wrapped: ~Copyable & ~Escapable {
  public var unsafelyUnwrapped: Wrapped {
    consuming get
  }
}

map(), flatMap() 일반화

extension Optional where Wrapped: ~Copyable & ~Escapable {
  @lifetime(copy self)
  public consuming func map(
    _ transform: (consuming Wrapped) throws(E) -> Result
  ) throws(E) -> Result?

  @lifetime(copy self)
  public consuming func flatMap(
    _ transform: (consuming Wrapped) throws(E) -> Result?
  ) throws(E) -> Result?
}

사실 SE-0437 당시에는 이 일반화를 급하게 적용 하고 싶지 않았다고해요.

noncopyable 값을 다루는 map / flatMap에는 사실 세 가지 형태가 있을 수 있거든요.

optional 전체를 consume해서 owned 값을 클로저에 넘기거나, borrow해서 참조를 넘기거나, mutate해서 inout 참조를 넘기거나. 셋 다 유용하지만, 전부 map이라는 이름으로 오버로드하기엔 규칙상 구분할 방법이 없었죠.

그래서 이번 제안은 이 일반화를 기본적으로 항상 consuming으로 동작하게 만들고, 대신 ref() / mutableRef()로 owned optional 값을 먼저 만들어서 나머지 두 형태를 구현할 수 있게 했습니다.

func foo(x: consuming Optional<UniqueArray>) -> Optional {
  x.map {
    $0[0]
  }
}

func bar(x: borrowing Optional<Atomic>) -> Optional {
  x.ref.map { // ok!
    $0.value.load(ordering: .relaxed) &+ 1
  }
}

func baz(x: inout Optional<UniqueArray>) -> Optional {
  x.mutableRef.map {
    // map 하면서 array를 그 자리에서 업데이트
    $0.value.append(123)
    return $0.value.count
  }
}

Source Compatibility

Optional.ref, Optional.mutableRef, Optional.put()은 새로 추가되는 메서드라 소스 호환성 문제가 없습니다.

map / flatMap의 새 오버로드는 기존 함수보다 덜 특수화된 오버로드예요.

기존에 Optional.map을 쓰던 코드는 모두 Copyable wrapped 값을 다루고 있었을 테니, 더 특수화된 기존 Wrapped: Copyable 오버로드로 그대로 resolve됩니다.

flatMap도 마찬가지고요.

그래서 이 일반화된 함수들로 인한 소스 호환성 문제는 없을 것으로 예상합니다.

unsafelyUnwrapped는 순수한 일반화라 소스 호환성 문제를 일으키지 않습니다.

ABI Compatibility

Optional에 추가되는 새 메서드들은 표준 라이브러리의 새 API지만 별도 ABI를 필요로 하지 않아요.

map, flatMap, unsafelyUnwrapped의 일반화 역시 새로운 ABI를 추가하거나 기존 ABI를 깨뜨리지 않습니다.

Implications on Adoption

Optional.ref, Optional.mutableRef, Optional.put()은 Ref와 MutableRef와 동일한 availability를 가집니다.

나머지 일반화 부분들은 항상 사용 가능한 것으로 표시됩니다.

Future Directions

Borrow와 inout 바인딩

앞으로 borrow/inout 바인딩을 지원하기로 한다면, 컴파일러가 optional에 대해 if borrow / if inout 패턴을 인식해서 조건부로 scope된 접근을 제공하게 할 수도 있어요.

if borrow x = optional {
  
}

foo(optional) // ok

만약 이 방향이 ref / mutableRef 방식보다 낫다고 판단되면, map, flatMap, unsafelyUnwrapped를 일반화하는 방식도 다시 고민해야 해요.

더 이상 항상 consuming일 수 없으니까요.

consumingMap, borrowingMap, mutatingMap 등을 따로 만드는 방법도 있지만, API가 계속 늘어나는 건 그리 썩 괜찮은 해법은 아니라고 하네요

Optional: Equatable / Hashable 일반화

SE-0499가 Equatable, Hashable 같은 프로토콜을 noncopyable / nonescapable conformer까지 지원하도록 일반화한 만큼, Optional의 이 conformance들도 suppressed wrapped 타입을 지원하도록 일반화하는 게 당연해 보입니다.

다만 특정 conformance가 어느 시점에 일반화됐는지 표현할 방법이 없어서, 오래된 ABI 안정 OS에서 실수로 제네릭 ==나 hash(into:)를 호출해 payload를 copy해버리는 상황은 막아야 해요.

Ref / MutableRef 자동 역참조

제안된 예시들에서 ref / mutableRef로 map을 쓸 때 .value 프로퍼티를 명시적으로 접근해야 했죠.

앞으로 Ref와 MutableRef에 자동 역참조 기능을 추가해서, 아래처럼 더 편하게 쓸 수 있게 할 수도 있습니다.

func bar(x: borrowing Optional<Atomic>) -> Optional {
  x.ref.map { // ok!
    // '.value.'가 더 이상 필요 없음
    $0.load(ordering: .relaxed) &+ 1
  }
}

Alternatives Considered

Optional 바인딩의 기본 소유권 방식 변경

이 제안의 동기에서는 ref, mutableRef 같은 프로퍼티가 borrowing 버전의 제어 흐름을 위해 필요하다고 설명했어요.

대신 if let 같은 optional 바인딩의 기본 소유권 방식을 borrowing으로 바꾸는 방법도 있었습니다.

하지만 이건 optional 바인딩이 consuming이라고 가정하는 기존 코드에 대해 source-breaking 변경이 됩니다.

Optional.borrow()와 Optional.mutate() 메서드

이전 리비전에서는 ref, mutableRef 대신 borrow(), mutate()라는 메서드 이름을 제안했었어요. 하지만 InlineArray나 UniqueArray 같은 타입의 span, mutableSpan 프로퍼티와 결을 맞추고 싶어서 최종적으로는 프로퍼티 형태가 더 선호됐습니다.

Conclusion

noncopyable optional을 다루는 게 이번 제안으로 한결 편해질 것 같아요

지금까지는 내부 값을 살짝 들여다보기만 해도 consume 에러를 피하려고 switch 문을 직접 작성해야 했는데, ref / mutableRef 덕분에 if let처럼 자연스럽게 접근할 수 있게 됐습니다.

put()도 강제 언래핑을 줄여주는 실용적인 추가고요.

map, flatMap, unsafelyUnwrapped까지 일반화되면서, noncopyable 타입을 다루는 코드가 Copyable 타입을 다룰 때와 비슷한 느낌으로 작성할 수 있을 것 같습니다

References

swift-evolution/proposals/0532-optional-noncopyable-improvements.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

What's new in SwiftData (feat. WWDC 2026)

GREEN.1229 — Sun, 12 Jul 2026 18:36:37 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 WWDC 2026에서 나온 SwiftData 부분에서 업데이트 사항들에 대해 살펴보고 정리해보겠습니다

Sectioning your fetches

먼저 SwiftData에서 섹션별로 데이터를 가져오는 방법을 보겠습니다.

이제는 이렇게 쿼리에서 옵션을 주어 그룹별로 묶을 수 있어요.

각 섹션에선 ID 속성이 있고 이걸 활용하게 됩니다.

Using custom types

모델에 커스텀 타입을 저장하는 기능 향상을 살펴볼께요.

SwiftData는 로드될 때 모델에 대한 스키마를 자동으로 생성합니다.

스키마는 모델 클래스와 엔티티간 매핑을 정의하죠.

대부분의 타입에선 이게 자동으로 작동해요.

그렇지만 모델 매크로로 어노테이션 되지 않은 클래스는 자동으로 검사할 수 없기에 SwiftData는 스키마 생성에 실패합니다

만약 그렇다고 구현체에 접근할 수 없을 수 있잖아요?

그런 경우 이렇게 어트리뷰트 codable을 사용하여 주면 해결됩니다.

이 속성은 SwiftData에 타입의 인코딩된 표현을 저장하도록 알려주는 역할을 합니다.

타입에 대한 스키마를 추론하는 대신에요.

다만 염두해둬야할게 있는데, codable 속성의 내용은 SwiftData에 불투명합니다.

이는 Predicate에서 결과를 필터링하는데 사용할 수 없음을 나타내요.

또는 정렬도 사용할 수 없어요.

또한 codable 형태가 변경되면 속성을 추가하거나 제거하는 경우 마이그레이션이 트리거되지 않아요.

이 점을 주의해야 합니다!

Codable 속성 사용은 SwiftData가 기본적으로 지원하지 않는 타입을 저장하는 탈출구라고 생각하면 좋습니다.

직접 정의했다면 왠만해선 Codable 사용을 금해야 합니다.

Observing data stores

스토어를 모니터링하고 데이터 변경 시 알림 받는 방법을 살펴볼께요.

SwiftUI에서는 이렇게 데이터가 변경되면 뷰가 쿼리의 새로운 결과를 반영해 다시 렌더링합니다.

만약 SwiftUI가 아닌 부분은 어떨까요?

이걸 위해 이번 2027 릴리즈에선 ResultsObserver를 도입했습니다.

SwiftUI 쿼리처럼 데이터 가져오고 관찰하고 반영시키는 Swift Observation을 사용해요.

이런식으로 사용될 수 있습니다.

withContinuousObservation은 ObservationTracking 토큰을 반환합니다.

이 토큰이 관찰의 수명을 정의하죠.

여기서 더 나아가 이번 업데이트에서는 히스토리 관찰도 지원해줍니다.

데이터 스토어가 저장될 때마다 SwiftData는 히스토리 트랜잭션을 기록합니다.

여기에는 변경된 내용에 대한 정보가 포함됩니다.

그리고 변경이 어디서 왔는지 조차도 포함되죠.

히스토리에서 트랜잭션을 고유하게 식별하는 토큰도 있습니다.

ModelContext.fetchHistory() 이 API와 토큰을 함께 사용할 수 있어요.

HistoryObserver는 스토어의 변경 사항에 쉽게 반응할 수 있게 해줍니다.

지속적 히스토리 관찰과 새로운 트랜잭션 추가 시 코드가 반응하도록 해주죠.

특정 종류의 변경만 관찰하고 대응하고 싶다면 물론 HistoryObserver를 사용해 모델 타입과 트랜잭션 작성자로 필터링할 수 있어요.

외부 서버와 같은 다른 시스템과 연동 시 효과적이죠.

외부와 연동하는 예시를 볼까요?

이렇게 간단히 코드로 나타내서 사용할 수 있습니다.

References

SwiftData의 새로운 기능 - WWDC26 - 비디오 - Apple Developer

SwiftData의 최신 개선 사항을 확인하세요. Codable을 사용하여 맞춤형 및 타사 유형을 유지하는 방법과 가져온 데이터를 SwiftUI 앱의 섹션으로 그룹화하는 방법을 안내합니다. 또한 ModelResultsObserver와

developer.apple.com

느즈막히 올려보는 쿠팡에서의 회고 (feat. 또다른 시작)

GREEN.1229 — Mon, 6 Jul 2026 13:39:50 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 사실 기술적인 부분보다 회고를 하나 해볼까 합니다.

제가 근 1년 6개월 정도 근무했던 쿠팡을 떠나게 되었는데, 사실 쿠팡 입사 직후와 3개월쯤 되었을때 각각 쿠팡 이직기라던지 쿠팡에서의 일상 회고를 해보려 했는데, 일과 개인적인 바쁨에 치여 결국 쿠팡을 나올때 이렇게 회고를 올려보네요

그래서, 이번 회고는 역시나 무근본 무형식으로 그냥 두서없이 한번 적어보려고 합니다

쿠팡 입사

25년 2월에 쿠팡으로 이직을 하게 됩니다.

왜 이직했는지 그냥 지금와서 간단히 정리해보면, 정말 글로벌 서비스를 하는것과 글로벌 회사에서 일하는것을 경험해보고 싶었어요.

이전까지는 iOS 개발자 1인으로 내 할일을 다하는것에 초점이였다면 앞으로의 성장을 생각했을때 그걸 넘어서 정말 일을 잘하는 사람이 되고 싶었어요.

개발에 국한된게 아니라 일을 잘하는 사람이요.

그랬을때 좀 더 큰 대규모의 서비스를 경험해보면서 다국가 인종과 일하는 경험 이 두가지가 쿠팡을 지원하고 입사를 하게된 가장 큰 이유였습니다

그래서 쿠팡에서 쿠팡이츠라는 O2O 배달 앱 서비스의 시니어 iOS 엔지니어로 근무를 하게 됩니다.

그럼 쿠팡에서의 1년 6개월을 돌이켜봤을때 어떤것을 해왔고 어떤걸 배웠는지 한번 정리해볼까해요.

Life in Coupang

우선 일은 굉장히 굉장히 하드워킹이긴 했습니다.

그렇다고 밤낮이 없는 삶, 원양어선 그런건 아니였어요.

그냥 주어진 시간에 정말 1초도 쉬지 않고 일하면 다 끝날 수 있는 그런 정도..?

제가 맡은 TF는 주로 Ads TF였습니다.

배달 앱의 특성 상 배달이나 플랫폼 수수료 같은걸로는 정부 규제도 있고 단가가 그렇게 크지 않아 사실상 사업적인 부분에서 큰 이익이 되지 않는다고 생각해요.

그렇기에 또 다른 비지니스적인 부분을 고려할때 광고를 무시할 수 없습니다.

점포나 메뉴 광고가 주인데 어떤 부분에 배치하거나 어떤 시간대에 어떤걸 배치하면 이 점포를 가장 극대화되어서 CPC나 CPS를 올릴 수 있을지 같이 고민하고 여러 실험을 해보는 그런 TF입니다.

광고라는 도메인이 익숙치도 않고 처음 해보는거였지만 그만큼 재밌었어요.

직접적으로 주간으로 광고를 통해 얼마나 많은 매출에 기여했는지 확연하게 눈에 보일 수 있었기에 더 동기부여가 되었습니다.

또한, 광고 TF말고도 두루 경험해봤던것도 큰 기억으로 남아요.

핵심인 음식 배달과 요즘 밀고 있는 쇼핑(마트나 편의점, 꽃집 등등 - 푸드가 아닌 모든것) 그리고 고객들의 VOC나 편의성을 개선하기 위한 CRM TF 등 한 팀에 정말 다양한 TF가 로테이션으로 돌아가며 일을 하게 되는데 이 모든것의 비지니스 태스크를 한번씩은 해본것 같습니다.

그러다보니 자연스레 다양한 코드들을 보게되고 깊게 이해하게 되었어요.

이렇게 거시적으로 볼 수 있는 비지니스적인 일은 어떻게 했는지에 대해 간단히 회고를 해본다면 이제는 팀에 대한 회고를 해볼까해요.

사실상 가장 많이 짧다면 짧은 시간에 성장할 수 있게 된 원동력이 바로 소속된 iOS 팀이였습니다.

솔직하게 지금까지 나름 다양한 회사도 다녀보고 여러 동아리도 해보고 컨퍼런스도 다녀보면서 교류해봤지만 개발자 개개인의 역량으로는 쿠팡이 가장 월등하다고 느꼈어요.

쿠팡의 채용 과정이 정말 복잡하고 난이도가 큰 편이라 더 그런지는 몰라도 개발자의 능력은 어느 회사보다도 뛰어나다고 확신할 수 있습니다.

그렇기에 같이 부딪히며 토론하고 때론 설전도 벌이면서 일을 하면서 성장한것 같아요

쿠팡에서 일하기 전까지의 저를 돌이켜보면 iOS 개발 맡은거 능히 해낼 수 있는 개발자라고 말할 수 있다면, 여기서 배운건 그건 당연히 해야되는거고 그거 말고도 너가 더 뭘할 수 있는데?에 대한 푸시가 많고 그걸 잘 끌어올려줄 매니저와 팀원들이 존재했습니다.

너가 1인분 하는건 당연히 시니어 개발자가 아니라 주니어 개발자여도 당연히 해야되는거고, 그걸 넘어서 시니어 개발자라면 팀에 어떤 영향을 미칠 수 있는지 고민하고 iOS 뿐만 아니라 더 스펙트럼을 넓혀서 안드로이드, 웹을 포함한 프론트 그리고 백엔드까지 비지니스 스펙을 받으면 고려해서 테크적인 리드를 할 줄 알아야 하며 그런 부분을 하드 트레이닝을 많이 했던것 같아요.

그래서 일감이 주어지면 항상 어떻게 개발해야하지? 라는 생각보다 이게 정말 괜찮은 실험인지 이 실험을 성공시키기 위해서 각 파트에서 어떤 노력을 기울이면 좋을지 그리고 그게 제일 효과적인 방법일지를 고민하게 저의 일을 접근하는 방식 자체가 많이 변화한것 같아요.

그전에는 iOS 앱 개발 부분에서만 고민했다면 이제는 백엔드와의 트레이드오프도 생각해보고 좀 더 크로스 플랫폼에서 일하기 적절한 방법과 그리고 기능 개발 대비 어느정도 인력 코스트가 들어가는지 그런것들까지 고민하고 제안을 하게 되는 개발자로 성장했어요.

그리고 그건 제가 원하지 않아도 쿠팡에서 일을 하면 자연스럽게 요구되는 역량이고 그렇게 변하게 만들어주더라구요

그리고 팀적으로도 매주 테크 미팅을 통해 서로 기술을 공유하고 새로 맡은 비지니스 일감이 있다면 항상 먼저 테크 디자인을 한 후 공유해서 더 나은 방향이 있는지를 모바일 팀 자체적으로 더 체크를 합니다.

이렇게 꼼꼼하고 다양한 의견을 듣다보면 자연스럽게 시야도 넓어지게 되더라구요.

쿠팡에서는 이렇게 정말 많은 미팅과 룰과 일이 존재해요.

그러다보니 눈코 뜰 새가 없는건 사실이지만 어떻게 보면 가장 이상적인 시스템이라곤 생각이 되더라구요.

그 시스템에서 번아웃이 안오고 버티는게 힘든것 뿐이지만 회사적인 측면으로만 보면 합리적이고 비지니스가 성장할 수 있는 시스템이란 생각이 많이 듭니다.

그리고 또 많이 성장했던 부분은 바로 영어일것 같아요.

사실 영어를 잘하지 못했고 지금도 그렇지만 하나 달라진건 자신감인것 같아요.

회사에선 공식적으로 한국어로 일하는것 자체가 없어요.

공용 언어가 영어이기에 슬랙, 위키 등등 모든것이 영어죠.

그리고 미팅도 통역이 제공되는 경우도 있지만 기본이 영어입니다.

그러다보니 사실 살려면 해야됐었어요.

저도 처음에 입사해서 "아 이거 일보다 커뮤니케이션이 영어라 따라갈 수 있나?" 싶었어요.

그래서 슬랙도 그렇고 번역기에 번역하고 하고 싶은 말도 번역해서 떠듬떠듬 치고 그랬죠.

그런데 이게 일상에 녹아드니 별다른 영어 공부를 하지 않아도 자연스럽게 익숙해지기 마련이더라구요.

그 전에는 예를 들어 "이거 확인해주실 수 있나요?" 라는걸 영어로 말해야된다 생각하면 머릿속에서 문법부터 생각하고 완성한 다음 이게 진짜 맞나 고민하고 그런것들때문에 영어가 입 밖으로 더 안나왔던것 같아요.

그런데 이제는 일단 문법이 다 맞지 않고 그렇더라도 이 바쁜 일상에서 우선 커뮤니케이션이 우선이고 먼저 말해야된다는 압박이 있다보니 자연스레 "Could you check this?"와 같이 나오게 되더라구요.

물론 더 좋은 표현도 있고 하겠지만 배운 한가지가 자신감이라 했잖아요?

이 자신감은 확실히 익힌것 같아요.

이제 말로 표현하고 문장으로 쓰는게 내가 틀렸다 하더라도 두렵지가 않게 되었습니다.

그리고 앞서 계속 말했지만 팀원들 정말 훌륭하고 귀중한 팀원들 그리고 타 팀의 교류하는 사람들 모두 좋은 인프라를 쌓을 수 있어 감사했어요.

일이 빡센만큼 전우애가 더 많이 생기게 되는 쿠팡이였어요.

나간다니 이런 것까지 해주는 팀원들인데 어떻게 잊을 수 있을까 싶어요.

그래서 정리해보면 쿠팡에서 생활하면서 성장한 부분은 이렇습니다.

1️⃣ 기술적인 견고함과 더 넓게 바라볼 수 있는 시야

2️⃣ 개인 혼자만이 아니라 팀 전체에 영향을 미칠 수 있는 사고

3️⃣ 영어 의사소통

4️⃣ 정말 비지니스적으로 어떤것들이 도움되는지에 대한 고민

이 외에도 서버 드리븐적인 설계, 대쉬보드들을 구축해서 모니터링을 강화하는 방법, 장애 대응, AI 오너로써 팀을 이끌어본 경험 등등 기술적으로나 팀에 영향을 주는 부분으로나 정말 다양한 포인트들이 있지만 그거까지 쓰면 한도 끝도 없을것 같아 우선 쿠팡에서의 라이프는 간략하게 이정도로 마칠까 합니다.

그럼 가장 중요한 포인트인데 왜 쿠팡을 떠나는지에 대해 간단히 정리하고 마쳐보려고 해요.

Why am I leaving Coupang?

당연히 이직이 쉬운 선택도 아니고 또 새로운 도전을 하는것은 더더욱 쉬운 선택이 아닙니다.

그리고 그런 결정을 하기까지에는 정말 큰것부터 정말 사소한것까지 많은 복합적인 부분이 상호작용 할거에요.

여기선 몇가지 핵심적인 이유를 전해볼까해요.

우선, 쿠팡이 다니기에 좋지 않은 회사다 라는것은 전혀 아닙니다.

일이 힘들 순 있지만 그거때문에 이직하는건 도피라고 생각해요.

어딜가나 힘든건 있기 마련이고 일이 바쁘다고 나가는건 근로자의 덕목이 아니라 생각하기 때문이죠.

1️⃣ 더 넓은 글로벌 서비스

가장 큰것중 하나는 바로 이 항목이에요.

쿠팡이츠를 개발하면서 현재는 한국과 일본을 타겟으로 서비스하고 있는데, 일본을 고려해서 글로벌한 서비스를 구축하고 운영하다 보니 정말 더 많은 나라들 나아가서 대륙들을 타겟으로 하는 더 큰 글로벌 서비스들이 궁금해졌어요.

그리고 글로벌 서비스를 해보니 재미가 있더라구요.

같은 앱이지만 각 문화 환경에 따라 원하는 화면과 폰트 배치들이 다르다는것도 세삼 느끼게 되면서 뭔가 리전을 바꿀때마다 여행하는 느낌이 들었어요.

직간접적으로 그 나라를 체험해보는거죠.

그래서 이를 충족하는 서비스를 해보고 싶다는 생각이 컸습니다.

2️⃣ 컨텐츠 플랫폼에 대한 니즈

그리고 저는 사실 개발자를 처음 해올때부터 사용자들이 몰두할 수 있는 컨텐츠 플랫폼을 해보고 싶었어요.

지금까지는 주로 커머스, O2O와 같은 사용자들이 앱에 들어와서 빠르게 확인하고 구매하고 나가는 그런 동선으로 비지니스를 이끄는 서비스였어요.

그러다보니 한 화면에서 애니메이션이나 더 심미적인 부분보다는 탐색 플로우나 결제 플로우에서 로직과 빠른 구매가 더 중요해지더라구요.

그래서 한편으로는 그런 부분들을 많이 다룰 수 없었어요.

여담이지만 저는 KWDC 2023에서 SwiftUI 애니메이션 관련 세션을 발표할 정도로 심미적인것과 사용자의 더 아름다운 경험을 구현하는걸 원하고 좋아하는 개발자에요.

그래서 그런 부분을 채울 수 있는 컨텐츠 플랫폼 서비스를 꼭 해보고 싶었어요.

그럼 왜 여태까지 그런거 안했냐? 라고 한다면 안한게 아니라 못했던거라고 할 수 있어요

사실 알려진 컨텐츠 플랫폼 앱이 몇개 되지도 않지만 제가 원한다고 내일부터 그 회사에 들어가서 해볼 수 있는건 아니잖아요..?

무튼 그래서 컨텐츠 플랫폼을 향한 저의 개발자로서의 니즈가 이직의 큰 몫을 했습니다.

3️⃣ 거리

마지막으로 누군가한테 사소할 수도 있지만 저한테 큰 부분이였던건 회사와의 거리였어요.

사실 쿠팡에 입사한것도 처음엔 하이브리드로 재택이 존재했기에 공고나 계약도 그렇게 진행되었어요.

그래서 선릉까지 출퇴근하는게 매일이 아니니 부담스럽지 않고 현실적으로 가능했죠.

그런데 작년부터 풀출근으로 근무제도가 변경되면서 이는 적지 않은 부담으로 다가왔어요.

(물론 모든 쿠팡 부서가 그런건 아니고 근무제도는 조직장에 따라 모두 부바부입니다.)

그러다보니 출퇴근 하는데 드는 시간, 체력소모, 비용 그런것들까지 트레이드 오프 되는것을 생각해볼때 쿠팡이 큰 메리트가 되지 않는단 생각이 문득 들더라구요.

그래서 사소할 수 있지만 저한텐 어떻게 보면 심리적으로 가장 큰 부분이였어요.

이런 대표적인 이유 + 말하진 않았지만 더 많은 이유들이 상호작용하여 이직을 결심하게 되었습니다.

(혹시 말하지 않았지만 더 많인 이유들이 궁금하시다면 연락주세요 ㅋㅋㅋ)

그래서 이번엔 어딜 가는데?

이번에는 1과 2그리고 3번의 이직 이유들을 충족할 수 있는 곳으로 가게되었어요.

네이버웹툰에서 글로벌 웹툰 iOS 앱 개발에 기여하게 되었습니다.

아직 출근전이고 이 글이 나가는 시점에서 한 주 후 첫출근을 하게 될 예정이라 떨리네요 ☺️

인터뷰들을 진행하며 제가 더 다른 성장하고 싶은 포인트와 해소하고 싶은 포인트들을 네이버 웹툰에서 더 다양하게 해볼 수 있을것 같아 많은 기대가 됩니다!

아 그리고 현재 쿠팡에서 해당 제 포지션의 채용이 열려있어요!

관심 있으시거나 궁금한 부분이 있으신 분은 언제든 편하게 연락주시면 제가 아는선에서 알려드리고 도와드릴께요

제가 장담하건데 꼭 다녀봐야할 회사라고 생각합니다.

Sr Mobile Engineer (Eats iOS)

쿠팡이츠(Coupang Eats)는 쿠팡의 음식 배달 서비스이자,대한민국에서 빠르게 성장하고 있는 배달 서비스입니다. 2019년 국내 배달 업계에 혜성처럼 등장한 쿠팡이츠는 2024년 ‘무제한 무료배달’로

www.coupang.jobs

또 어떤 재밌는 일들이 벌어지고 경험하게 될지 모르겠지만, 언젠가 또 좋은 회고로 찾아오도록 하겠습니다

What's new in SwiftUI (feat. WWDC 2026)

GREEN.1229 — Mon, 29 Jun 2026 11:29:03 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 WWDC 2026에서 소개된 What's new in SwiftUI 세션을 정리해보겠습니다

뭔가 오랜만에 SwiftUI를 공부하고 정리하는것 같아 재밌을것 같아요

Refreshed look and feel

리퀴드 글래스 기능이 나온건 벌써 좀 되었지만, 여전히 강조하고 개선시키고 있습니다.

appearsActive 환경값을 통해 창이 비활성화 일때 불투명도를 조절할 수 있어요.

또한, 이제 macOS나 iPadOS에서 메뉴바가 정말 심플해졌는데요.

원한다면 labelStyle을 통해 타이틀과 아이콘이 같이 나오도록도 설정할 수 있죠.

그리고 어쩌면 폴더블을 예상케하는 기능도 생겨났어요.

iOS 27에서는 프리뷰를 통해 앱이 대화형 크기 조정에 어떻게 반응하는지 볼 수 있어요.

이렇게 늘리고 줄여서 이상이 없는지 바로 확인할 수 있죠.

이는 추후 출시된다는 소문이 많은 폴더블에 대한 대응을 미리 해놔라 라는 의미로도 들려지네요

이 반응형은 SwiftUI로 앱을 구성하면 자동으로 따라오지만 만약 UIKit과 SwiftUI 모두 사용한다면 고려해야할 몇가지가 있습니다.

1️⃣ 스크린 지오메트리 확인

2️⃣ 디바이스 대신 사이즈 클래스 이용하기

3️⃣ 화면 회전과 같은 방향에 대해 체크

이에 대해 더 자세히 알아보려면, 아래 세션을 참고하세요!

Modernize your UIKit app - WWDC26 - Videos - Apple Developer

Discover the latest updates to UIKit. Learn how to update your iPhone app layouts to work great when resized with iPhone Mirroring and on...

developer.apple.com

탭뷰에서도 새로운 기능이 생겼습니다.

이렇게 우측에 특별한 탭 배치를 하고 싶다면 prominent role 속성을 주어 그걸 표현해낼 수 있어요.

이 탭 메뉴는 아래처럼 디바이스 사이즈에 따라 자동으로 크기가 변하거나, 항목의 갯수가 줄어들거나 늘어나게 표현될 수 있습니다.

이때 줄어들어서 숨겨진 메뉴들은 더보기 버튼을 통해 오버플로우 메뉴로 확인할 수 있죠.

또한, 이렇게 ToolbarItemGroup에서 undo, redo가 기본적으로 숨겨져있는데 만약 가시성있게 주고 싶다면 visibilityPriority를 high로 속성을 지정해주면 됩니다.

물론 이것도 이번 iOS 27에서 나온 기능이죠.

반대로, 오버플로우 메뉴로 숨기려면 ToolbarOverFlowMenu로 지정하면 됩니다.

마지막으로, 절대 숨기지 않고 항상 표현해주고 싶은 메뉴가 있다면 이렇게 placement 속성에 tobBarPinned를 사용하면 되죠.

컨텐츠가 많아서 스크롤 시 네비게이션 바를 숨기고 싶다면 toolbarMinimizeBehavior 뷰 모디파이어를 이제는 사용하여 원하는것을 구현할 수 있습니다.

Document-based apps

지금까지 SwiftUI는 문서 기반 앱을 지원해왔습니다.

이번 릴리즈에선 이걸 기반으로 더 확장된 새로운 API를 가져왔어요.

Document creation context

이제 이렇게 문서를 생성할때 빈 문서 혹은 사진으로 바로 문서를 만들 수 있어요.

이걸 가능하게 하는 코드들이 들어가서 구성할 수 있습니다.

이렇게 DocumentGroupLaunchScene에서 버튼을 두개 blank, photo로 구성합니다.

그 후 DocumentGroup 구성으로 context를 넘겨주는것이죠.

그러면 blank, photo 컨텍스트가 넘어가 만약 photo라면 자동으로 바로 사진 선택창을 띄우게 되는것입니다.

Performance

문서 기반 앱은 잦은 업데이트가 있고 또한 그에 따라 UI 업데이트도 잦을 수 있죠.

성능은 어떻게 최적화 시켰을까요?

우선은 가장 기본적으로 Obervable 매크로를 이용합니다.

이를 통해 업데이트 되어야 할 친구들만 업데이트 쳐서 성능을 어느정도 보장해주죠.

그치만, 가장 중요한건 읽기/쓰기 성능이죠.

여기서 새로운 API가 등장합니다.

성능 향상을 위해 우선 WritableDocument 프로토콜을 채택합니다.

이는 세가지의 준수사항을 가지고 있어요.

1️⃣ writableContentTypes: 문서의 타입을 나타냅니다. 여기서는 커스텀한 스티커문서 타입을 지정해줬어요.

2️⃣ snapshot: 쓰기 스냅샷을 지원해줍니다. 커스텀한 PageSnapshot 객체를 만들어 사용할 수 있죠.

3️⃣ writer: DocumentWriter 프로토콜을 준수하며 지정된 형식으로 문서를 디스크에 쓰는 방법입니다. 요청된 컨텐츠 형식을 지정해요.

DocumentWriter 프로토콜에는 snapshot의 개념이 존재합니다.

여기서 준수할 사항은 write죠.

write 메서드는 nonisolated이자 비동기입니다.

즉, 비용이 많이 드는 쓰기 작업 자체를 백그라운드에서 수행하게 하죠.

그리고, snapshot을 통해 업데이트가 필요한 부분만을 쓰죠.

이런 최적화에도 불구하고 당연히 쓰기 작업은 오래걸릴 수도 있습니다.

이때 progress인자로 주어지는 Subprogress API를 사용해 진행 사항을 알 수 있습니다.

그 다음 ReadableDocument도 있어요.

둘은 쌍둥이라고 볼 수 있을 정도로 완벽하게 대칭됩니다.

당연하겠죠?

이 두가지를 활용하여 문서 읽기/쓰기 성능을 향상시켰습니다.

First-class support for URL access

페이지를 이미지로 저장할 수도 있어야겠죠?

앱이 없는 사람도 충분히 있으니까요.

Document API writer를 활용하면 충분히 다른 형식으로도 저장이 가능합니다.

우선, writableContentTypes에 png도 넣어줍니다.

이미지로 저장을 위해서요.

그리고 Writer 구현체에서 contentType이 png일때 하나의 이미지로 합쳐지도록 코드를 추가해줘요.

이렇게 해주면 손쉽게 이미지로 문서를 저장할 수 있습니다

Presentation and interaction

화면에 보이는 요소와 인터랙션에 대한 개선들이 있습니다.

reorderable과 reorderContainer를 이용한다면 리스트에 있는 요소들의 순서를 내 마음대로 변경할 수 있어요.

이 Reorderable API는 List만이 아니라 모든 컨테이너에서도 동일하게 적용하고 동작할 수 있습니다.

이제 SwiftUI는 List뿐만 아니라 모든 뷰에서 스와이프 동작을 지원합니다.

swipeActionsContatiner를 붙이고 그 안에서 아이템 섹션에는 원하는 swipeActions를 구성해주면 됩니다.

또한 만약 항목을 제거하고싶다, 이 예시에서는 스티커를 제거하고 싶다? 라면 이렇게 할 수 있습니다.

우선 요렇게 contextMenu를 통해 삭제 버튼을 배치하고 stickerToDelete 변수에 저장되도록 해줍니다.

그리고 이렇게 이번 API에서 업데이트된 confirmationDiaglog를 통해 삭제 다이얼로그를 구성하고 삭제나 다른 동작을 할 수 있어요.

이건 alert 모디파이어로도 대체할 수 있습니다.

이 밖에도 무수한 업데이트 사항들이 있어요ㅎㅎ

Data flow and performance

이제 데이터 흐름과 성능 주요 개선 사항들에 대해 살펴볼께요.

잘 알고 있는, AsyncImage는 온라인의 이미지를 나타내는데 용이하고 나타날때 그려줬죠.

그리고, 지금까지는 이미지를 메모리에 유지하지 않았어요.

즉, 캐싱이 없었죠.

그렇기에 다시 위로 스크롤하면 다시 그려줬습니다.

이제 iOS 27부터는 AsyncImage가 표준 HTTP 캐싱을 지원해줍니다

즉, 기본적으로 이미지 캐싱이 되는거죠!!

별다른 코드 변경없이도 자동으로 적용됩니다.

물론, cachePolicy 파라미터가 생겨 원하는 캐시 정책을 설정할 수도 있습니다.

아니면, 이렇게 아예 커스텀한 캐시 정책을 추가할 수도 있어요.

앱 데이터를 저장하는 좋은 방법은 Observable 클래스를 이용하는것이죠.

이전까지는 이 코드에서 만약 상위 뷰가 업데이트되어서 StickerStoreView가 초기화되면 StickerStore의 새 인스턴스가 만들어졌어요.

하지만 원래 인스턴스가 여전히 State 변수에 저장되어 있었습니다.

그렇기에, 새 인스턴스는 그냥 버려졌죠.

이 기존 방식은 매번 초기화될때마다 새 인스턴스를 버리고 낭비하는 아주 안좋은 성능이였습니다.

이제는 State 프로퍼티를 사용하여 초기화되고 저장되는 클래스가 lazy하게 되었습니다.

즉, 한번만 초기화된다는 소리죠

이를 가능하게 하는건, @State Dynamic Property에서 @State Macro로 변환되었기에 가능합니다.

이제는 이후 초기화에서는 새 클래스 인스턴스를 만들지 않게 됩니다.

더 좋은 소식은, 이 변환은 하위 호환도 백포팅 되어서 iOS 17도 적용이 자연스레 되었다는 점입니다!

다만 이제는 이 변경으로 인해 이전 버전에서 이렇게 사용하고 있던 코드들이 초기화 관련 에러를 뱉을 수 있게 됩니다.

즉, 선언 시 할당하지 않아야 합니다.

그리고 어쩌면 가장 많이 개발자들을 괴롭히고 마주칠 수 있는 부분인데요.

뷰에 많은 중첩된 표현이 있다면 이렇게 컴파일러가 오류를 냅니다.

즉, 주어진 해당 시간안에 컴파일러가 타입 체킹을 하기 어렵다는 투정이죠.

이런일이 발생하는 근본적인 원인은 컴파일러가 해당 컴포넌트를 그릴때 어떤 조건으로 그릴지 모르기에 다 시도해봐야되는거죠.

이렇게 선택지가 많고 중첩되면 더 복잡해질 수 밖에 없죠.

이렇게 복잡한걸 생성 유형에 제약을 받지 않고 컨텐츠를 그저 조합하기만 한다면 얼마나 좋을까요?

이게 바로 이번 릴리즈에서 이룬것입니다.

가장 일반적인 빌더 집합이 이제 단일 이니셜라이저를 공유해 단 하나의 명확한 경로만 남깁니다.

ContentBuilder가 나타났기에 가능한 일입니다.

여러 다른 빌더 유형이 하나로 통합되었어요.

단일 빌더를 위해서요!

이는 기존 ViewBuilder의 진화로 모든 타겟 버전에서 사용할 수 있습니다

그리고 이제는 AI 시대니까..

이 명령어 한줄로 Swift나 SwiftUI 관한 애플의 스킬을 익스포트 받을 수 있습니다.

Conclusion

개인적으로 엄청 많은 변화는 없다고 느껴지는데 알짜인 변화들이 있어 보여요.

AsyncImage도 이미지 캐싱이 되지 않아 쓰는 선택지에서 배제되었었는데 이제는 지원해준다니 감개무량하네요!

또한, SwiftUI View 성능이 정말 항상 불만이였는데, 특히 컴파일러 뷰 타입 체크 성능 관련해서...

이것 또한 개선되었다니 큰 업데이트라고 생각됩니다!

이게 다 소개처럼 잘 작동하고 정말 체감이 되는거라면 Xcode 27로 업데이트 하지 않을 이유가 없네요ㅎㅎ

References

SwiftUI의 새로운 기능 - WWDC26 - 비디오 - Apple Developer

SwiftUI에 추가된 최신 기능을 살펴보고, 이러한 기능이 앱을 어떻게 향상할 수 있는지 알아보세요. 고성능 앱 빌드를 위한 직접 디스크 접근과 스냅샷 기반 비교 기능을 갖춘 새로운 Document 프로

developer.apple.com

What's new in Swift (feat. WWDC 2026)

GREEN.1229 — Mon, 22 Jun 2026 14:00:01 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 얼마전 진행되었던 WWDC 2026에 대해 이제 하나씩 정리해보고자 합니다

첫번째 시작은 What's new in Swift에요.

WWDC 2026에서 소개된 Swift 변화에 대한 핵심적인 것들을 세션을 보며 정리해보겠습니다

특히 Swift 6.3과 Swift 6.4 기반에서 변화된 정리 내용이 주입니다.

Swift의 새로운 기능 - WWDC26 - 비디오 - Apple Developer

Swift 관련 업데이트를 확인해 보세요. 일상적인 인체공학, 향상된 동시성, 더 안전한 고성능 코드를 위한 업데이트 등 언어 관련 최신 혁신 기술을 알아보세요. Embedded Swift의 워크플로와 언어 상

developer.apple.com

우선 개선사항들부터 살펴볼까요?

Improvements

옵셔널 타입

이전에는 some이나 any와 옵셔널을 같이 사용할때는 이렇게 괄호로 묶어야 됐어요.

이는 연산자 우선순위 규칙 관련해서 필수였습니다.

이제는 아래와 같이 컴파일러가 똑디하게 판단해주기에 묶지 않아도 되게 되었습니다.

Swift 6.4부터요.

Concurrency

이제 이 컨커런시 관련하여 오류를 무시하면 경고가 나타납니다.

그래서 이제는 이렇게 작업 내 오류를 처리하거나,

이렇게 작업을 저장해두었다가 나중에 처리하던가 해야 합니다.

이제 defer block에서 async 함수를 호출하던 제한도 사라졌습니다.

@Unchecked Sendable을 사용하던 클래스는 weak var 프로퍼티 때문이였을텐데요.

이제 weak let으로 설정한다면 @Unchecked를 붙이지 않아도 됩니다.

그리고 만약 타입이 Sendable일 필요가 없다면, 새로운 tilde Sendable 구문으로 명시적으로 나타낼 수 있어요.

서브 클래스가 Sendable이 되는것도 막지 않습니다.

Access level

internal과 private을 같는 등의 서로 다른 접근 레벨 프로퍼티를 가진 구조체는 이제 두번째 멤버와이즈 이니셜라이저를 가지게 되어 다른 프로젝트에서도 사용이 가능하게 됩니다.

anyAppleOS

이제 각 macOS, iOS 이렇게 다 나열할 필요없이 27 버전부터는 통일되었기에 이렇게 anyAppleOS로 통합해서 사용할 수 있습니다.

가용성을 한번에 통합해서 주기에 편리하죠.

물론 이렇게 통합하고 하나를 예외로 두는 설정도 가능합니다.

@diagnose

이렇게 디프리케이트된 API들은 경고가 뜨기 마련이죠.

이제는 이 경고를 나타나지 않게 할 수 있습니다.

요런식으로요!

다른 부분에선 영향을 주지 않고 해당 선언된 부분에서만 경고를 끌 수 있어요.

추가로 인자로, StrictMemorySafety를 주어 보안이 중요한 메서드에서 unsafe API를 사용했는지 감시할 수도 있고,

ErrorInFutureSwiftVersion을 주어 특정 경고를 에러로 처리하는것도 가능합니다.

Module Selectors

Swift 6.3에서는 두 모듈에 동일한 이름의 API 있을때도 더 잘 처리하도록 해줍니다.

같은 파일에 이렇게 두 모듈을 모두 임포트했다고 가정합니다.

Swift는 원래 어떤걸 원하는지 몰라 에러를 내뱉어요.

그래서 우리는 Rocket.SaturnV 이렇게 더 명확한 경로를 주어 사용했죠.

그런데 만약 이렇게 Rocket 모듈안에 Rocket 타입이 있다면?

Swift는 모듈 이름보다 타입 이름을 더 우선시합니다.

그래서 protocol에서 SaturnV를 찾게 되는것이죠.

없으면 당연히 에러가 나겠죠?

그래서 Swift 6.3에서는 더블 콜론 문법을 도입했습니다.

이렇게 ::으로 경로를 지정하게 되면 모듈을 보게 됩니다.

모듈 셀렉터라고 불러요.

이건 이렇게 메서드나 프로퍼티에서도 사용이 가능합니다.

많이 유용할것 같아요

예를들어 SwiftUI에서 View 타입이 있는데, 모듈 이름도 View로 짓거나 하고 싶을 수도 있기에 이럴때 선택지가 없었는데 매우 도움이 될것 같습니다.

이제는 Swift 언어에 대한 개선 혹은 신규 사항들을 살펴봤으니, 다음으로 라이브러리에 대한 새로운 사항들을 살펴볼까요?

Libraries

Standard Library

이제 Task 취소 쉴드 기능을 사용할 수 있어요.

쉴드 내부에선 작업 취소 확인이 항상 false로 반환됩니다.

이미 시작한 작업을 완료하거나 롤백하는데 중요시 생각해야 합니다.

해당 mapKeyedValues가 생겼어요.

이걸 활용하면 키와 이전 값 모두 매핑 클로저에 전달해 새 값을 계산할 수 있죠.

플랫폼 마다 파일 경로를 나타내는것이 다를 수 있죠.

올바르게 처리하기 까다로울 수 있습니다.

이제는 Swift System의 타입을 기반으로 표준 라이브러리에 새로운 filepath 타입을 추가해 더욱 적절히 사용할 수 있게 되었습니다.

Testing

Swift 6.4의 테스팅은 테스트 동작에 대한 더 많은 제어권을 제공합니다.

Issue.record를 통해 치명적이지 않은 이슈들은 그냥 워닝으로만으로 설정할 수 도 있죠.

CI 워크플로우를 방해하지 않게 됩니다.

그리고 Test.cancel API가 생겨서 테스트를 동적으로 취소할 수도 있어요.

Swift test 명령어에 테스트를 반복하는 새로운 기능도 생겼습니다.

Swift Test로 사용되는것들도 상호운용성 덕에 XCTest에서도 동일하게 사용할 수 있습니다.

Subprocess

지난해 Subprocess 패키지를 애플이 발표했어요.

쉽게 서브프로세스를 실행 시키기 위한 API를 포함한 패키지죠.

올해 Subprocess 1.0을 출시합니다.

피드백을 중점으로 여러 사항들이 개선되었습니다.

특히 크로스 플랫폼 지원도 강력해졌어요.

예시로, 서브프로세스를 실행하기 위해 run 메서드를 호출할 때 표준 출력과 표준 오류 스트림을 AsyncBufferSequence로 실행 객체에 포함할 수 있어요.

이 모델은 각 스트림이 단 한번만 생성됨을 보장합니다.

strings() 메서드로 서브 프로세스를 라인 바이 라인으로 쉽게 읽을 수 있도록 보장해줍니다.

Foundation

ProgressManager라는게 Foundation 라이브러리 내에 생겼습니다.

진행 상황 보고를 위한 새 타입이죠.

Swift Concurrency로 설계되고 구조화되었습니다.

또한, Foundation에서 Data 부분도 더 개선되어 빨라졌습니다.

Data와 NSData의 브릿징도 감소되었고 NSURL과 CFURL도 Swift에서 통합되었어요.

이런 큰 Foundation을 개선할 수 있는건 Swift의 언어 상호운용성 덕분에 가능하죠.

언어의 경계를 넘어 의미있는 크로스 플랫폼의 언어로 진화하고 있죠.

Full-stack Swift

Interoperability

Swift는 정말 어떤 분야도 막힐게 없는 풀스택 언어가 되었습니다.

특히 Swift 6.4에서는 언어 상호 운용성을 더 극대화 했습니다.

크로스 플랫폼 IDE 지원을 개선하고 더 쉽고 안전하게 웹이나 임베디드 기기와 같은 다른 환경에 Swift 코드를 가져갈 수 있게 합니다.

Swift 6.4는 Swift로 작성된걸 C에 노출할 수 있게 합니다. (반대는 이미 가능했어요.)

이렇게 @c를 통해 사용할 수 있죠.

@c와 @implementation 어노테이션을 사용하면 별도 C 선언 없이도 C 함수 구현이 가능합니다.

원래 헤더 파일에 이미 선언되어 있었으니까요.

만약 원래 C 헤더에 선언되어 있지 않았던거라면 @c만으로 충분하고 @implementation을 사용하지 않아야 합니다.

이렇듯 Swift의 상호 운용성은 다른 언어로 작성된 코드 베이스에 Swift를 도입하는데 핵심입니다.

Swift-Java는 Swift와 Java 사이 상호 운용성을 가능케 하는 패키지입니다.

Java에서 async와 throwing Swift 함수 호출을 할 수 있게 지원해줍니다.

그 외 Java 클래스를 Swift 프로토콜에 적합하게 만드는것도 가능하고요.

즉 이제, Java, Kotlin 환경에서 Swift 함수를 호출하는것이 자연스러워진것입니다

Editor Support

VSCode용 Swift 익스텐션 최신 버전이 Swiftly와 새로운 통합을 추가합니다.

에디터에서 바로 swift.org의 툴체인을 쉽게 받아볼 수 있어요.

이제 어떤 에디터든 정확한 툴체인을 받아 볼 수 있죠.

Wasm

오픈 소스 툴체인으로 Web Assembly로 컴파일 할 수 있습니다.

Swift의 Wasm 지원은 동일한 언어로 네이티브 앱을 작성하고 BE, FE 모두 작성할 수 있는것이죠.

Embedded

더 제한된 환경에서도 Swift의 편의성을 활용할 수 있습니다.

임베디드 Swift는 이제 existential 타입을 지원합니다.

프로토콜을 준수하는 여러 타입을 사용할 수 있게 된거죠.

Swift 6.4는 필요한 모든 메타 데이터를 DWARF 디버그 정보에 저장합니다.

임베디드 Swift 코어 덤프 디버깅 경험에 도움을 주죠.

이제 Swift 성능을 극대화하는 방법들을 들어볼까요?

Performance ergonomics

Optimizer controls

Swift 컴파일러의 optimizer는 코드를 더 빠르게 만들기 위해 수십 가지 기법을 적용합니다.

그치만 잘못 적용하면 오히려 역효과가 날 수도 있죠.

예를들어, 컴파일러가 수행하는 가장 최적화중 하나는 인라이닝입니다.

함수 호출 코드 위치를 대체하고 특정 위치에 맞게 최적화하는거죠.

만약 역효과가 난다면 더 빨라지진 않고 바이너리만 크게 만들 수 있죠.

그래서 이게 효과적일지를 판단하기 위해 함수와 호출 위치를 분석해요.

때론 잘못 판단할 수도 있기에 강제로 적용하는게 필요할 수 있습니다.

Swift 6.4에서 @inline(always) 기능이 생겼습니다.

기존에는 @inline(never) 속성만 있었고 대부분 이게 권장되었었는데 이제는 명시적으로 필요할 수 있다는걸 의미하는거죠.

그래서 이걸 사용할 때 웬만하면 final 키워드와 같이 사용하는걸 권장합니다.

또 다른 최적화는 특수화입니다.

이렇게 제네릭 오버헤드를 없애고 추가 최적화를 가능하게 해줍니다.

하지만 때론 라이브러리에서 컴파일러가 함수를 어떻게 사용할 지 모를 수 있기에, 이를 직접 제어하기 위해 @specialized 어노테이션을 붙여 사용할 수 있습니다.

Ownership enhancements

가장 큰 성능 향상을 이룬 개선을 살펴보겠습니다.

바로 소유권 시스템입니다.

Swift의 성능 문제는 대부분 복사 때문에 코스트가 발생하죠.

이런식은 다들 너무 잘 알거기에 긴 설명이 필요 없습니다.

복사로 인해 성능 저하를 해결하는 방법은 특정 상황에서 복사가 필요없다는걸 인식해야 해요.

이렇게 복사를 피해 데이터를 객체에 넣어 그 객체를 다른 컴포넌트에 전달하는 방식으로도 할 수 있죠.

대부분의 경우는 해결할 수 있지만 모든 경우는 아니에요.

객체에 참조 카운트가 있어 전달하면 참조 카운트가 변경되기에 그렇죠.

그래서 요즘 방식은 Borrow를 이용하는 겁니다.

컴포넌트 2가 저장소 자체를 빌리는 동안은 컴포넌트 모두 읽기만 가능하고 쓸 순 없어요.

컴포넌트 2가 먼저 끝내야 컴포넌트 1이 제어권을 가지게 됩니다.

Mutate도 있는데, 다른 컴포넌트가 저장소에 접근하는것 자체도 완전 차단됩니다.

이렇게 연관 타입도 이제 복사 불가능, 이스케피이 불가능 등을 지정할 수 있어요.

복사 없이 for문 안에서 반복이 가능합니다.

Sequence처럼 Iterable은 이터레이터를 생성해 for문이 요소를 가져오도록 합니다.

하지만, 시퀀스하곤 달리 요소들을 배치로 가져옵니다.

또한, borrow, mutate라는 새로운 접근제어자가 생겼어요.

borrow는 공유 저장소에 대한 읽기 전용으로 동작합니다.

복사 없이요.

mutate는 수정도 가능합니다.

위에 우리가 살펴봤던것과 동일해요

또한 성능을 위한 대체 API들도 나왔으니 적극 활용해보면 좋을것 같아요.

Ref와 MutableRef 타입을 통해 저장소에 접근도 제어할 수 있어요.

이전에는 이런식으로 활용되었죠.

inout을 통해서 말이죠.

이제는 MutableRef를 사용하여 보다 간단하게 표현할 수 있습니다.

Conclustion

이렇게 이번 WWDC 2026에서 소개된 Swift 파트를 살펴봤습니다

그렇게 큰 변경이나 그런건 없어보여요.

틈틈히 Swift 6.3, Swift 6.4 릴리즈에 대한것들을 정리하고 살펴본적이 있어서 그런지 리캡 느낌이였습니다.

그래도 성능 부분에서 어떻게 언어적으로 잘 쓸 수 있는지에 대해 고민해보게 되고, 크로스 플랫폼 언어로 진화됨에 따라 앞으로는 더욱 포지션 별, 플랫폼 별 구분이 사라지는데 제약이 없을것 같다고 느껴지네요.

References

Swift의 새로운 기능 - WWDC26 - 비디오 - Apple Developer

developer.apple.com

[SE-0531] Literal Expressions

GREEN.1229 — Sun, 21 Jun 2026 05:47:30 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0531 — Literal Expressions에 대해 정리해보겠습니다

Intro

Proposal: SE-0531
Authors: Artem Chikin, Doug Gregor
Review Manager: Ben Cohen
Status: Active Review (May 18...29, 2026)

Motivation

Swift에는 정수 리터럴 값만 허용하는 세 가지 문법 컨텍스트가 있습니다.

generic value arguments(SE-0452), @section 변수(SE-0492), enum raw value.

지금까지는 개발자가 직접 값을 계산해서 bare literal로 손수 옮겨 적어야 했어요.

이 과정에서 값이 의미하는 바가 사라지고, 코드 전반에 "매직 넘버"가 퍼지게 됩니다.

@section과 컴파일타임 초기화

@section은 페이지 크기, 레지스터 오프셋처럼 다른 상수로부터 값이 파생되는 시스템/임베디드 환경을 겨냥한 어트리뷰트입니다.

하지만 지금은 연산자나 변수 참조를 전혀 허용하지 않아요.

@section("__DATA,config") let pageSize = 4096
@section("__DATA,config") let bufferSize = 65536
@section("__DATA,config") let c = 1 + 1  // ❌ error: operators not allowed

4096이 4 × 1024라는 사실도, bufferSize가 16 × pageSize라는 관계도 코드만 봐서는 전혀 알 수 없었어요.

Enum raw value

Swift 1.0부터 enum raw value는 순수 리터럴만 허용했습니다. bit-flag enum처럼 shift 표현이 자연스러운 경우조차 표현할 방법이 없었어요.

enum Permissions: Int {
  case read = 1
  case write = 2
  case execute = 4
}
// 1 << 0, 1 << 1, 1 << 2 라고 쓰는 게 훨씬 의도가 명확한데도 불가능했어요

정수 제네릭 인자

SE-0452가 도입한 정수 제네릭 파라미터도 마찬가지로 bare integer literal만 허용합니다.

let schemaRowSize = 32

// 원하는 것: InlineArray<(2 * schemaRowSize), UInt8>
let buffer: InlineArray<64, UInt8>  // 64 == 2 * 32 이길 바랄 뿐...

세 가지 컨텍스트 모두 같은 근본적인 제약을 공유합니다.

개발자가 사람 계산기 역할을 해야 했고, 그 값이 왜 그 숫자인지에 대한 의도는 사라져버렸어요

Proposed Solution

이 제안은 Literal Expression(리터럴 표현식)을 도입합니다.

표준 라이브러리 정수 타입의 리터럴, 산술/비트 연산자, 그리고 컴파일타임에 알려진 다른 정수 변수 참조로 구성된 표현식이에요.

이 표현식은 컴파일 타임에 단일 리터럴 값으로 상수 폴딩됩니다.

// @section — 연산과 변수 참조 모두 가능
@section("__DATA,config") let pageSize = 4 * 1024
@section("__DATA,config") let bufferSize = 16 * pageSize

// enum raw value — shift 표현이 가능
enum Permissions: Int {
  case read    = 1 << 0
  case write   = 1 << 1
  case execute = 1 << 2
}

// 정수 제네릭 — 괄호로 감싼 표현식 허용
let schemaRowSize = 32
let buffer: InlineArray<(2 * schemaRowSize), UInt8>

중요한 점은, literal expression을 사용해 컴파일된 모듈은 개발자가 직접 미리 계산한 리터럴을 쓴 모듈과 완전히 동일한 산출물을 만들어낸다는 거예요.

Detailed Design

Literal Expression의 문법

literal-expression → integer-literal
literal-expression → unary-operator literal-expression
literal-expression → literal-expression binary-operator literal-expression
literal-expression → '(' literal-expression ')'
literal-expression → identifier

지원하는 연산자: 산술(+ - * / %), wrapping(&+ &- &*), 비트(& | ^), shift(<< >>), masking shift(&<< &>>), 단항(+ - ~).

일반 산술 연산자는 오버플로우를 컴파일 타임에 진단하고, wrapping 연산자는 결과를 타입의 비트 너비로 silent하게 모듈러 처리합니다.

let a = 4 * 1024                  // ✅ 산술
let b = 1 << 12                   // ✅ 비트 시프트
let c = (0xFF & mask) | base      // ✅ 비트 연산 + 괄호
let d = -1                        // ✅ 단항 부정
let w: UInt8 = 250 &+ 10          // ✅ wrapping 덧셈, 4로 폴딩
let e = Int.max / 2               // ❌ 프로퍼티 접근 불가
let f = a +% b                    // ❌ 사용자 정의 연산자 불가

연산자 lookup은 Swift의 일반 name lookup 규칙을 그대로 따릅니다. 만

약 lookup이 사용자 정의 오버로드로 해석되면, 표준 라이브러리 오버로드가 스코프에 같이 있더라도 전체 표현식이 거부됩니다.

Literal Expression 내 변수 참조

literal expression은 다른 변수를 이름으로 참조할 수 있습니다.

단, 그 변수가 let 바인딩이고, 기본 초기화 값 자체도 literal expression이어야 해요.

let pageSize = 4 * 1024
let bufferSize = 16 * pageSize             // ✅ pageSize 참조

import CSystem
let systemBuffer = 4 * SYSTEM_PAGE_SIZE    // ✅ C 상수

var mutableSize = 4096
let derived = 2 * mutableSize              // ❌ var는 참조 불가

let computed: Int = { 4096 }()             // ❌ 초기화식이 literal expression이 아님
let derived2 = 2 * computed

주의할 점 — public, package, open 접근 수준의 변수는 literal expression에서 참조할 수 없습니다.

폴딩이 일어나면 해당 변수의 초기화식이 모듈의 ABI 표면에 노출되는 셈인데, 이는 이 제안의 "ABI 변경 없음" 원칙과 충돌하기 때문이에요.

@section 변수 초기화식

@section("__TEXT,config") let pageSize = 4 * 1024
@section("__TEXT,config") let bufferSize = 16 * pageSize
@section("__TEXT,config") let systemPage = PAGE_SIZE    // C 상수

원본 표현식은 진단과 IDE 인덱싱을 위해 AST에 보존되지만, .swiftinterface 파일에는 출력되지 않습니다.

Enum raw value

enum Permissions: UInt8 {
  case read    = 1 << 0    // 1
  case write   = 1 << 1    // 2
  case execute = 1 << 2    // 4
}

enum Example: Int {
  case a = 2 + 2    // 4
  case b            // 5
}

정수 제네릭 인자

generic-argument → type
generic-argument → '-'? integer-literal
generic-argument → '(' literal-expression ')'   // 새로 추가된 형태

제네릭 인자 위치에서는 <, >, , 토큰이 구분자 역할을 하기 때문에, literal expression은 반드시 괄호로 감싸야 합니다.

let schemaRowSize = 32
let buffer: InlineArray<(2 * schemaRowSize), UInt8>    // ✅
let flags: InlineArray<(1 << 4), Bool>                 // ✅
let small: InlineArray<5, Int>                         // ✅ 기존처럼 괄호 없이도 동작

폴딩된 값이 곧 타입 동일성을 결정합니다.

InlineArray<(2 + 3), Int>와 InlineArray<5, Int>는 동일한 타입이에요.

컴파일타임 진단

let x: UInt8 = 100 * 3    // ❌ error: integer overflow
let y = 10 / 0           // ❌ error: division by zero
let z = 10 % 0           // ❌ error: division by zero

@section("__TEXT,data") let a = abs(-1)    // ❌ error: not supported in a literal expression

Source Compatibility

이번 변경은 세 가지 표현식 컨텍스트를 확장할 뿐, 다른 곳에서 받아들여지던 표현식 형태를 제거하거나 바꾸지 않습니다.

흥미로운 케이스 하나는 제네릭 인자 목록의 모호성 해소입니다.

컴파일러는 괄호 안의 내용을 먼저 타입 표현식(튜플)으로 해석을 시도하고, 실패할 때만 literal expression으로 해석합니다.

예를 들어 Foo<(a < b, c > .d)>(x) 같은 코드는 기존의 체이닝 비교 연산으로 폴백되어 의미가 바뀌지 않습니다.

ABI Compatibility

literal expression은 컴파일러 프론트엔드 내에서 완전히 폴딩되며, 코드 생성·런타임·심볼 맹글링에 변화가 없습니다.
정수 제네릭 인자의 경우 폴딩된 값이 모듈 인터페이스에 타입의 일부로 나타납니다 (예: InlineArray<5, Int>).
@section 변수와 enum raw value는 원본 표현식도, 폴딩된 상수도 모듈 인터페이스에 나타나지 않습니다.

Implications on Adoption

이 기능은 LiteralExpressions 실험적 기능 플래그로 게이팅되어 있습니다.

폴딩이 컴파일 타임에 일어나고 생성되는 코드가 직접 작성한 리터럴과 동일하기 때문에, 최소 배포 타겟 제약이 없습니다.

Future Directions

괄호 제약 완화 — 제네릭 인자 위치에서 >, ==, , 를 stop 토큰으로 처리해 InlineArray<2 + 3, Int>처럼 괄호 없이도 파싱 가능하게 만드는 방향
부동소수점 literal expression — Float, Double에 대한 산술 연산 지원
문자열 literal expression — 컴파일타임 문자열 연결 및 보간
비교 연산자 및 표준 함수 지원 확대 — ==, min(), max() 등, 나아가 컴파일타임 Bool을 활용한 삼항 연산자 및 if/else 표현식
컴파일타임 프로그래밍 — SE-0359와 연계해 사용자 정의 순수 함수, 풍부한 데이터 타입까지 포괄하는 일반적인 컴파일타임 프로그래밍 모델로의 확장

Alternatives Considered

참조되는 모든 변수에 명시적 어노테이션 요구

@const 같은 명시적 어노테이션을 요구하는 방식도 고려되었습니다.

하지만 SE-0359 리뷰에서 이런 어노테이션의 "전염성(virality)"이 핵심 우려로 지적된 바 있어요.

literal expression의 경우 어노테이션이 컴파일러가 이미 알고 있는 정보 이상을 제공하지 않기 때문에, 추론만으로 충분하다고 판단해 채택하지 않았습니다.

"Constant Expression" 대신 "Literal Expression" 용어 사용

C/C++의 전통을 따라 "constant expression"이라는 용어를 쓰는 방법도 있었지만, 스코프와 과대 약속의 위험이라는 두 가지 이유로 "literal expression"을 선택했습니다.

Swift가 향후 더 큰 컴파일타임 개념을 도입할 때를 위해 "constant expression"이라는 이름을 아껴두는 것이 합리적이라고 판단했습니다.

Conclusion

지금까지 @section, enum raw value, 정수 제네릭 인자는 모두 "사람이 직접 계산해서 bare literal로 옮겨 적어야 하는" 동일한 제약을 공유하고 있었어요

Literal Expression은 이 세 컨텍스트에 산술·비트·단항 연산과 변수 참조를 허용함으로써, 코드에 값의 의도를 직접 드러낼 수 있게 해줍니다.

그러면서도 컴파일 타임에 완전히 폴딩되기 때문에 ABI나 런타임에는 전혀 영향이 없다는 점이 인상적이에요.

매직 넘버 대신 16 * pageSize, 1 << 2처럼 의미가 드러나는 코드를 쓸 수 있게 되는, 작지만 가독성 측면에서 정말 실용적인 변화라고 생각합니다

References

swift-evolution/proposals/0531-literal-expressions.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

[SE-0530] Async Result Support

GREEN.1229 — Sun, 7 Jun 2026 15:09:13 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0530 — Result 타입의 async 이니셜라이저 추가에 대해 정리해보겠습니다

Intro

Proposal: SE-0530
Authors: Konrad 'ktoso' Malawski, Matt Massicotte
Review Manager: Doug Gregor
Status: Implemented (Swift 6.4)

Motivation

Swift의 Result 타입은 throwing 코드를 다룰 때 굉장히 유용한 도구입니다.

기존의 Result.init(catching:)은 throwing 클로저를 Result 인스턴스로 변환해주는 편리한 이니셜라이저예요.

// 기존: 동기 버전은 있음
let result = Result { try syncWork() }

그런데 async 버전이 없었어요. 비동기 작업에서 동일한 패턴을 쓰려면 매번 직접 구현해야 했거든요.

// 지금까지의 불편한 방식 — 코드베이스마다 중복 구현
let result: Result<Data, any Error>
do {
  result = .success(try await asyncWork())
} catch {
  result = .failure(error)
}

어렵진 않지만, 유용성 때문에 많은 코드베이스에서 수동으로 중복 구현되고 있었거든요. 표준 라이브러리가 제공해야 마땅한 패턴이에요!

Proposed Solution

Result.init(catching:)의 async 오버로드를 추가합니다.

이를 통해 아래처럼 간결하게 쓸 수 있게 됩니다.

let result = await Result {
  try await asyncWork()
}

Detailed Design

제안하는 API 변경 사항은 다음과 같습니다.

extension Result where Success: ~Copyable {
  /// Creates a new result by evaluating a throwing closure,
  /// capturing the returned value as a success,
  /// or any thrown error as a failure.
  ///
  /// - Parameter body: A potentially throwing asynchronous closure to evaluate.
  @_alwaysEmitIntoClient
  public nonisolated(nonsending) init(
    catching body: nonisolated(nonsending) () async throws(Failure) -> Success
  ) async {
    do {
      self = .success(try await body())
    } catch {
      self = .failure(error)
    }
  }
}

주요 포인트를 살펴볼게요~!

Success: ~Copyable — noncopyable 타입도 Success로 사용할 수 있습니다.
throws(Failure) — SE-0413의 typed throws를 활용해 Failure 타입을 정확하게 표현합니다.
nonisolated(nonsending) — actor isolation 없이 호출 가능하며, 클로저의 반환값을 안전하게 전달합니다.
@_alwaysEmitIntoClient — 이니셜라이저가 클라이언트 바이너리에 직접 인라인되어 backdeployment가 가능합니다.

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로, 기존 코드에 영향을 주지 않습니다.
@_alwaysEmitIntoClient로 표시되어 이전 Swift 버전으로의 backdeployment가 가능합니다.

Conclusion

아주 작은 변경이지만, 비동기 코드에서 Result를 다루는 패턴이 훨씬 간결해집니다

많은 코드베이스에서 반복적으로 직접 구현해왔던 보일러플레이트를 표준 라이브러리가 흡수해주는 변경이에요.

Result { try await asyncWork() } — 동기 버전과 완전히 동일한 패턴으로 async 작업을 처리할 수 있게 되어, 코드의 일관성도 높아질 것 같습니다

References

swift-evolution/proposals/0530-async-result-support.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

[SE-0528] Continuation — Safe and Performant Async Continuations

GREEN.1229 — Sat, 30 May 2026 11:19:40 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0528 — 안전하고 성능 좋은 Async Continuation, Continuation 타입 도입에 대해 정리해보겠습니다

Intro

Proposal: SE-0528
Authors: Fabian Fett, Konrad Malawski
Review Manager: Joe Groff
Status: Accepted with revisions

Motivation

Continuation은 콜백 기반 API를 Swift Structured Concurrency로 연결하는 핵심 메커니즘입니다.

그런데 현재 개발자는 두 가지 옵션 중 하나를 골라야 하는 불편한 선택을 강요받고 있어요.

UnsafeContinuation — 오버헤드는 없지만, 두 번 resume하면 undefined behavior, resume을 빠뜨리면 조용히 task가 영원히 leak됩니다
CheckedContinuation — 런타임 bookkeeping으로 실수를 감지하지만, allocation과 atomic 연산 오버헤드가 발생합니다.

Continuation은 정확히 한 번만 resume해야 하는 "use-exactly-once" 값입니다.

이건 move-only 타입이 강제할 수 있는 계약이에요. 타입 시스템이 이 문제를 해결해야 합니다!

Proposed Solution

Continuation<Success: ~Copyable, Failure: Error>, 즉 ~Copyable struct를 도입합니다. 세 가지 메커니즘으로 올바른 사용을 강제합니다.

Move-only semantics (~Copyable) — continuation을 복사할 수 없으므로, 두 곳에서 resume하는 것이 불가능합니다.
consuming 메서드 — 모든 resume 메서드는 self를 consume해 두 번째 호출은 컴파일 에러가 됩니다.
deinit 트랩 + discard self — resume 없이 continuation이 drop되면 fatalError. 정상 resume 시엔 discard self로 deinit을 억제해 오버헤드가 없어요.

Double-resume — 컴파일 에러로 해결!

actor LegacyBridge {
  func complete(with value: String) {
    if let continuation {
      continuation.resume(returning: value) // ✅ consumes continuation
      continuation.resume(returning: value) // ❌ compile error:
                                            // 'continuation' used after consuming use
    }
  }
}

Missing-resume — 런타임 트랩으로 포착!

actor LegacyBridge {
  func cancel() {
    // Bug: resume 없이 continuation을 지워버림
    self.continuation = nil //   runtime trap: "This continuation was dropped."
  }
}

Detailed Design

Continuation 타입 정의

@frozen
public struct Continuation<Success: ~Copyable, Failure: Error>: ~Copyable, Sendable {

  deinit {
    fatalError("The continuation was dropped without resuming.")
  }

  @inlinable
  public consuming func resume(returning value: consuming sending Success) { ... }

  @inlinable
  public consuming func resume(throwing error: Failure) { ... }
}

Sendable — 다른 task/thread에서 resume할 수 있도록 isolation boundary를 넘을 수 있습니다.
consuming — 각 resume 메서드가 self를 consume해 이후 사용이 불가능해집니다.
sending Success — non-Sendable 값을 async task에 안전하게 전달할 수 있습니다.
consuming Success — noncopyable 타입도 값으로 전달할 수 있습니다.
discard self — 정상 resume 시 deinit을 억제해 오버헤드가 없습니다.

withContinuation — of: 와 throwing: 파라미터

// Before: 클로저 파라미터에 타입 어노테이션 필요
let data = await withCheckedContinuation { (continuation: UnsafeContinuation<Data, Never>) in
  bridge.store(continuation)
}

// After: 호출부에서 타입이 명확하게 보임
let data = await withContinuation(of: Data.self) { continuation in
  bridge.store(continuation)
}

throwing: 파라미터는 SE-0413(typed throws)를 활용해 세 가지 경우를 하나의 함수로 통합합니다.

// Non-throwing
let data = await withContinuation(of: Data.self) { continuation in ... }

// Typed throwing
let data = try await withContinuation(of: Data.self, throwing: NetworkError.self) { continuation in ... }

// Untyped throwing
let data = try await withContinuation(of: Data.self, throwing: (any Error).self) { continuation in ... }

CheckedContinuation으로 변환하기

콜백이 여러 개인 경우처럼 noncopyable Continuation을 사용할 수 없는 경우엔 CheckedContinuation으로 변환해 사용할 수 있습니다.

try await withContinuation(of: Int.self, throwing: (any Error).self) { c in
  let checked = CheckedContinuation(c)
  someLib.onSuccess { checked.resume(returning: $0) } // ✅
  someLib.onFailure  { checked.resume(throwing: $0)  } // ✅
}

이 때문에 CheckedContinuation과 UnsafeContinuation은 deprecated되지 않고 계속 유지됩니다.

동작 비교표

시나리오	UnsafeContinuation	CheckedContinuation	Continuation
정상 resume	✅ 동작	✅ 동작	✅ 동작
Double resume	⚠️ Undefined Behavior	Runtime trap	❌ 컴파일 에러
Missing resume	Silent hang	⚠️ Runtime warning	Runtime trap
런타임 오버헤드	없음	allocation + atomic	없음

Implications on Adoption

Before	After
withCheckedContinuation { … }	withContinuation(of: T.self) { … }
withCheckedThrowingContinuation { … }	withContinuation(of: T.self, throwing: (any Error).self) { … }
CheckedContinuation<T, E>	Continuation<T, E>

단, Continuation은 ~Copyable이기 때문에, 클로저 캡처처럼 continuation을 암묵적으로 복사하는 패턴은 컴파일 에러가 됩니다.

이 경우엔 기존 Checked/UnsafeContinuation을 사용해야 합니다.

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로, 기존 코드에 영향을 주지 않습니다.
withContinuation과 Continuation이라는 이름은 기존 표준 라이브러리 API와 충돌하지 않습니다.
ABI 변경도 없습니다.

Future Directions

~Discardable 프로토콜 도입

현재는 continuation이 drop될 때 런타임 트랩에 의존하고 있지만, ~Copyable 타입을 위한 새로운 모드인 ~Discardable을 도입해 "반드시 명시적으로 consume해야 함"을 컴파일러가 강제하게 할 수 있어요.

이렇게 되면 런타임 트랩마저 컴파일 에러로 격상될 수 있습니다.

Conclusion

드디어 오버헤드 없이 안전한 Continuation이 생겼습니다

기존에는 안전성(CheckedContinuation)과 성능(UnsafeContinuation) 사이에서 트레이드오프를 강요받았는데, move-only 타입의 강점을 활용해 double-resume은 컴파일 에러로, missing-resume은 런타임 트랩으로 잡아주면서 오버헤드는 UnsafeContinuation과 동일하게 유지됩니다.

Swift 타입 시스템의 힘으로 콜백 브리징의 고질적인 버그 두 가지를 완전히 해결한 우아한 변경이라고 생각합니다

References

swift-evolution/proposals/0528-noncopyable-continuation.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

[SE-0522] Source-Level Control Over Compiler Warnings

GREEN.1229 — Sat, 23 May 2026 08:45:27 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0522 — 소스 레벨에서의 컴파일러 경고 제어에 대해 정리해보겠습니다

Intro

Proposal: SE-0522
Authors: Artem Chikin, Doug Gregor, Holly Borla
Review Manager: Tony Allevato
Status: Accepted

Motivation

SE-0443에서는 커맨드라인 플래그로 컴파일러 경고를 제어할 수 있게 되었습니다.

예를 들어 -Werror DeprecatedDeclaration을 사용하면 Deprecated 경고를 에러로 격상시킬 수 있죠.

하지만 이 방식은 모듈 전체에 적용되는 블런트한 수단이에요.

특정 선언에서만 예외를 두고 싶은 경우에는 대응할 방법이 없었습니다.

// 모듈 전체에 -Werror DeprecatedDeclaration 적용 중
func bridgeToLegacySystem() {
  oldAPI() //   error: 'oldAPI()' is deprecated [#Deprecated]
}
// 이 함수만 warning으로 낮추고 싶어도 방법이 없었어요

마이그레이션 중인 코드베이스, 레거시 호환성 유지, strict 언어 모드의 점진적 도입 등 현실에서 "딱 이 선언만 예외"가 필요한 순간은 생각보다 많거든요!

Proposed Solution

새로운 선언 어트리뷰트 @diagnose를 도입합니다.

어노테이션된 선언의 렉시컬 스코프 내에서 특정 diagnostic group의 경고 동작을 error, warning, ignored 세 가지 중 하나로 제어할 수 있어요.

기본 문법

@diagnose(group-identifier, as: error | warning | ignored)
@diagnose(group-identifier, as: behavior, reason: "이유")

동작 예시

// 모듈 전체: -Werror DeprecatedDeclaration 적용 중

func normalFunction() {
  oldAPI() //   error
}

@diagnose(DeprecatedDeclaration, as: warning,
           reason: "Must maintain compatibility until end of release cycle")
func bridgeToLegacySystem() {
  oldAPI() //   warning: 'oldAPI()' is deprecated [#Deprecated]
}

ignored로 지정하면 해당 스코프에서 완전히 경고를 억제할 수 있어요.

@diagnose(UnsafeImportedAPI, as: warning)
struct LegacyFormatReader {
  func read(_ data: UnsafeRawPointer, _ count: Int) -> Header {
    c_read_bundle(data, count) //   warning
  }

  @diagnose(UnsafeImportedAPI, as: ignored, reason: "input is validated upstream")
  func readTrustedInput(_ data: UnsafeRawPointer, _ count: Int) -> Header {
    c_read_bundle(data, count) // 진단 없음
  }
}

서브그룹에도 개별적으로 적용이 가능합니다.

// UnsafeImportedOwnership은 UnsafeImportedAPI의 서브그룹
// 모듈 전체: -Werror UnsafeImportedAPI

@diagnose(UnsafeImportedOwnership, as: warning)
func createSession(_ ctx: OpaquePointer) -> Session {
  let session = c_create_session(ctx)
  //   warning: cannot infer ownership ... [#UnsafeImportedOwnership]

  c_bind_session(session, nil)
  //   error: call to imported function ... [#UnsafeImportedAPI]
}

Detailed Design

적용 가능한 선언 종류

@diagnose는 func, struct, class, enum, actor, protocol, extension, init, deinit, subscript, macro, typealias, associatedtype, get/set, willSet/didSet, import, enum case 등 대부분의 선언에 적용할 수 있습니다.

@diagnose(DiagGroupID, as: ignored)
import bar

@diagnose(DiagGroupID, as: ignored, reason: "Proposal Example")
func foo() { ... }

struct Foo {
  var property: Int {
    @diagnose(DiagGroupID, as: ignored)
    get { ... }
    @diagnose(DiagGroupID, as: ignored)
    set { ... }
  }
}

여러 @diagnose 어트리뷰트 — 순서가 중요합니다!

동일한 선언에 여러 @diagnose를 적용할 경우 마지막(렉시컬 순서상 가장 아래)에 있는 어트리뷰트가 우선합니다.

@diagnose(DiagGroupID, as: error)
@diagnose(DiagGroupID, as: warning) // 이 쪽이 최종 적용됨
public func foo() { ... }

Swift 어트리뷰트는 일반적으로 순서 무관하지만, @diagnose는 SE-0443의 커맨드라인 플래그 동작과 일관성을 맞추기 위해 순서가 중요합니다!

-suppress-warnings와의 관계

-suppress-warnings 플래그가 적용된 상태에서는 @diagnose가 완전히 무시됩니다.

as: error를 지정해도 에러로 격상되지 않아요.

이는 SE-0480에서 SwiftPM이 외부 패키지 의존성 빌드 시 경고 관련 플래그를 -suppress-warnings로 대체하는 방식과의 일관성을 위한 것입니다.

매크로와의 상호작용

@diagnose가 적용된 스코프 내에서 매크로가 코드를 생성하면, 그 생성된 코드에도 어트리뷰트의 효과가 적용됩니다.

또한 매크로 작성자가 매크로 확장 코드 안에 직접 @diagnose를 생성할 수도 있어요.

// 매크로 확장 결과물에 @diagnose가 포함될 수 있어요
@diagnose(DeprecatedDeclaration, as: error)
public func endpoint() -> UserProvidedType {
  //   error: 'UserProvidedType' is deprecated [#DeprecatedDeclaration]
}

단, 어트리뷰트가 적용된 선언에 peer 매크로가 붙어 있는 경우, @diagnose의 효과는 peer로 생성된 독립 선언에는 전파되지 않습니다.

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로 기존 소스 호환성에 영향이 없습니다.
ABI에도 영향이 없으며, 텍스트 모듈 인터페이스에도 방출되지 않습니다.
배포 제약 없이 자유롭게 도입하거나 제거할 수 있습니다.

Alternatives Considered

Region-based #pragma 스타일 지시문

Clang 등 C계열 컴파일러처럼 임의 코드 영역에 #pragma clang diagnostic push/pop을 사용하는 방식도 고려되었어요.

하지만 Swift는 메타데이터와 동작을 선언에 귀속시키는 방식을 선호하고, 영역의 끝을 수동으로 관리해야 한다는 점이 복잡한 버그로 이어질 수 있어 채택되지 않았습니다.

매크로 생성 코드에서 @diagnose 금지하기

모든 경고 제어가 개발자 소스 코드에서 명시적으로 보이도록 매크로 확장에서 @diagnose 생성을 금지하는 방법도 고려되었지만, 매크로 작성자가 자신이 생성하는 코드에 대한 진단 정책을 표현할 수 없게 되므로 허용하는 방향으로 결정되었습니다.

-suppress-warnings 하에서도 as: error 적용하기

무조건적인 소스 레벨 에러 격상을 위해 -suppress-warnings 하에서도 as: error를 적용하는 방법도 고려되었지만, SE-0443 및 SE-0480과의 일관성 유지를 위해 채택되지 않았습니다.

Future Directions

로컬 렉시컬 스코프 제어 — do {} 블록처럼 선언이 아닌 임의 스코프에도 적용하는 방향
클로저 표현식 — 특정 클로저 body의 경고 동작 제어
파일 스코프 제어 — using @diagnose(...) 형태의 파일 범위 제어
서드파티 툴 통합 — @diagnose(rule, from: SwiftLint, as: ignored) 같은 형태로 린터 등과의 통합

Conclusion

커맨드라인 플래그로만 가능했던 경고 제어를 소스 레벨의 선언 단위로 세밀하게 다룰 수 있게 해주는 실용적인 변경입니다

마이그레이션 중인 코드베이스, 레거시 호환성 유지, strict 언어 모드의 점진적 도입 등 현실적인 시나리오에서 개발자가 예외의 의도를 코드에 명확하게 문서화할 수 있게 됩니다.

Swift가 더 엄격한 언어 모드와 정적 분석을 강화해가는 흐름 속에서, @diagnose는 그 여정을 훨씬 유연하게 해줄 도구라고 생각합니다

References

swift-evolution/proposals/0522-source-warning-control.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com

[SE-0523] Hashable conformance for UnownedTaskExecutor

GREEN.1229 — Fri, 15 May 2026 03:53:25 +0900

안녕하세요. 그린입니다

이번 포스팅에서는 SE-0523 — UnownedTaskExecutor의 Hashable 채택에 대해 정리해보겠습니다

Intro

Proposal: SE-0523
Authors: Fabian Fett, Konrad Malawski
Review Manager: John McCall
Status: Implemented (Swift 6.4)

Motivation

SE-0417에서 도입된 task executor preferences는 현재 실행 중인 task의 unownedTaskExecutor를 노출해, 성능에 민감한 코드가 executor 기반으로 스케줄링 결정을 내릴 수 있게 해줍니다.

UnownedTaskExecutor는 이미 Equatable을 채택하고 있어요.
그런데 Hashable이 없다 보니, executor를 기준으로 리소스를 인덱싱해야 하는 경우에 불편함이 생겼습니다.

대표적인 사례가 커넥션 풀링입니다.
ConnectionPool이 여러 executor에 걸쳐 커넥션을 관리할 때, task의 executor에 이미 연결된 커넥션을 우선적으로 반환하면 불필요한 컨텍스트 스위치를 줄일 수 있거든요

Hashable이 없으면 executor를 찾기 위해 매번 선형 탐색을 해야 합니다

Before — O(n) 선형 탐색

// Today: O(n) linear search
func pickConnection(preferring executor: UnownedTaskExecutor) -> Connection {
    for (e, connection) in executorConnectionList {
        if e == executor { return connection }
    }
    return executorConnectionList.first!.connection
}

After — O(1) 딕셔너리 조회

// With Hashable: O(1) dictionary lookup
func pickConnection(preferring executor: UnownedTaskExecutor) -> Connection {
    if let connection = connectionsByExecutor[executor] {
        return connection
    }
    return connectionsByExecutor.values.first!
}

이 패턴은 커넥션 풀링뿐만 아니라 executor identity를 기준으로 리소스, 캐시, 스케줄링 메타데이터를 인덱싱하는 모든 시스템에 적용될 수 있습니다.

Detailed Design

UnownedTaskExecutor는 Builtin.Executor 값을 감싸는 struct입니다.
이미 기저 executor 참조의 identity를 기반으로 Equatable 채택이 되어 있어요.

Hashable 채택도 동일한 identity 값을 해싱하므로, 기존 equality 시맨틱과 일관성을 완전히 유지합니다.

extension UnownedTaskExecutor: Hashable {}

API 변경은 이것이 전부입니다. 딱 한 줄이에요

Source Compatibility / ABI

이번 변경은 순수 additive 변경으로, 기존 코드는 변경 없이 그대로 컴파일됩니다.
Equatable을 채택한 타입에 Hashable을 추가하는 것은 소스 호환성을 깨지 않습니다.
프로토콜 채택 추가는 additive ABI 변경이며, 기존 ABI 서피스를 수정하지 않습니다.

Alternatives Considered

아무것도 하지 않기

아무것도 하지 않으면, 개발자가 직접 Hashable 채택을 구현해야 합니다.

extension UnownedTaskExecutor: Hashable {
  @inlinable
  public func hash(into hasher: inout Hasher) {
    let (ident, impl) = unsafeBitCast(self, to: (Int, Int).self)
    hasher.combine(ident)
    hasher.combine(impl)
  }
}

unsafeBitCast를 직접 사용해야 한다는 점에서 불필요하게 위험하고 번거롭습니다. 표준 라이브러리 차원에서 제공하는 것이 당연히 올바른 방향이라고 생각합니다.

Conclusion

아주 작은 변경이지만, 굉장히 자연스러운 확장입니다

Equatable을 채택하고 있는 타입이라면 Hashable도 당연히 지원해야 한다는 Swift의 설계 철학에 맞게, UnownedTaskExecutor도 이제 딕셔너리 키와 Set으로 자유롭게 활용할 수 있게 됩니다!

executor 기반으로 리소스를 관리하는 코드를 작성하고 계신 분들께 특히 반가운 소식일 것 같습니다

References

swift-evolution/proposals/0523-hashable-unownedtask-executor.md at main · swiftlang/swift-evolution

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. - swiftlang/swift-evolution

github.com