오답노트

헷갈렸거나 새로 이해한 내용을 한 곳에 누적한다. 각 항목은 날짜 · 핵심 내용 · (있으면) 관련 문서 링크로 구성한다. 최신 항목을 맨 위에 추가한다.

2026-06-04

`any`가 작은 값에선 inline boxing이라 박싱 비용 ≈ 0이지만, dispatch 비용은 항상 있다

처음엔 "any는 항상 힙 박싱이라 느리다"고 단순화했지만 틀린 일반화였다.
Existential container의 value buffer는 보통 3-word(24 byte). 그보다 작은 값(Int, Double 등)은 inline으로 buffer에 직접 담겨 힙 할당이 일어나지 않는다.
그러나 메서드 호출 시 PWT(Protocol Witness Table)를 거치는 간접 호출 비용은 값 크기와 무관하게 항상 발생한다.
그래서 진짜 zero-cost가 되려면 any가 아니라 <T: P> generic + specialization 조합이어야 한다.

관련 문서 · Protocol Oriented Programming

2026-06-04

모듈(Module) = 함께 컴파일되는 코드 단위. SPM 패키지, Framework, Xcode target, main app target이 각각 하나의 모듈.
모듈을 빌드하면 두 결과물이 나온다 — .swiftmodule(시그니처만), .dylib/.o(본문 기계어).
다른 모듈에서 import할 때 컴파일러는 .swiftmodule의 시그니처만 본다. 본문은 이미 컴파일되어 바이너리에 굳어 있다.
그래서 모듈 경계를 넘는 generic 호출은 specialization이 막힌다. 본문 소스가 없으니 T별 전용 함수를 새로 만들 수 없기 때문.
해결: @inlinable로 본문 소스를 .swiftmodule에 노출하거나, @_specialize로 특정 타입용 specialized 버전을 미리 빌드해둔다.
표준 라이브러리의 Array, Dictionary 등은 거의 모든 메서드에 @inlinable이 붙어 있어 zero-cost가 유지된다.

관련 문서 · Protocol Oriented Programming

2026-06-03

async/await로 동시성을 관리하면 completion 핸들러처럼 결과를 직접 호출해 넘길 필요가 없다 → completion 호출을 깜빡하는 "처리 누락"이 사라진다.
모든 분기에서 return을 강제한다. 빠진 경로가 있으면 컴파일 자체가 안 된다.
에러는 throw로 자동 전파되고, 호출부는 try를 반드시 붙여야 한다 → 에러 처리 누락도 컴파일 단계에서 차단된다.

관련 문서 · GCD vs Swift Concurrency · Actor (1)