Apple A20 Pro 발표 — iPhone 첫 2나노 칩, 개발자가 봐야 할 3가지

매년 9월이면 나오는 A 시리즈 칩 발표를 나는 습관처럼 흘려듣는 편이었다. "몇 % 빨라졌다"는 문장은 벤치마크 그래프 한 장으로 끝나기 마련이니까. 그런데 이번 A20 Pro는 조금 결이 다르다. 숫자 중에 메모리 대역폭 +50%가 섞여 있어서다. 온디바이스로 LLM을 돌려본 사람이라면 이 한 줄에 눈이 멈춘다. 온디바이스 추론은 대부분 연산이 아니라 메모리에서 막히거든요. 그래서 이번엔 발표를 진지하게 읽었다.

무엇이 발표됐나 — 사실부터 정리

9월 9일 가을 이벤트에서 Apple은 iPhone 18 Pro·Pro Max와 함께 새 SoC인 A20 Pro를 공개했다. 공개된 핵심은 세 가지다. (1) iPhone 칩 최초의 2나노 공정, (2) A19 Pro 대비 50% 높은 메모리 대역폭, (3) 32코어 뉴럴 엔진. 나머지 세부 성능 수치는 실기기 벤치마크가 나와봐야 확정되겠지만, 이 세 항목만으로도 애플이 어디에 베팅했는지는 분명하다 — 온디바이스 AI다.

주의할 점 하나. "50% 빨라졌다"가 아니라 "메모리 대역폭이 50% 늘었다"는 것이다. 이 둘은 전혀 다른 얘기다. CPU/GPU 클럭이나 IPC 향상은 별개 항목이고, 아직 실측 전이다. 그래서 이 글에서 나는 발표된 세 숫자만 사실로 다루고, 나머지는 "일반적으로 이런 공정·구조에서 기대되는 특성" 수준으로만 이야기한다. 지어낸 벤치마크는 없다.

2나노 공정이 개발자에게 왜 의미 있나

결론부터. 2나노 전환의 실질적 이득은 "더 빠르다"보다 "같은 성능을 더 적은 전력으로, 또는 같은 전력에서 더 많은 트랜지스터로"다. 즉 성능/와트(perf-per-watt)와 집적도의 게임이다. 스마트폰처럼 전력·발열 예산이 빡빡한 기기에서는 이게 곧 지속 성능(sustained performance)으로 이어진다.

왜 개발자가 이걸 신경 써야 하나? 온디바이스 AI 워크로드는 짧고 굵게 튀는 게 아니라 수 초~수십 초 동안 칩을 계속 태우는 형태가 많기 때문이다. 이미지 생성, 로컬 LLM 응답, 실시간 음성 처리 — 전부 지속 부하다. 여기서 발열로 클럭이 떨어지는(thermal throttling) 순간, 피크 성능 숫자는 무의미해진다. 공정 미세화로 전력 효율이 좋아지면 스로틀링 전까지 버티는 시간이 늘어나고, 이건 벤치마크 첫 1초가 아니라 실제 사용자 경험에서 티가 난다.

2나노급 공정은 업계 전반에서 기존 핀펫(FinFET) 대신 나노시트/게이트올어라운드(GAA) 트랜지스터 구조로 넘어가는 세대로 알려져 있다. 핵심은 게이트가 채널을 사방에서 감싸 누설 전류를 줄이고 저전압에서 스위칭 효율을 높인다는 것. 세부 구현은 파운드리 영역이라 앱 개발자가 직접 만질 일은 없지만, "왜 같은 클럭에서 배터리가 덜 닳는가"의 배경으로 알아두면 된다.

메모리 대역폭 +50% — 온디바이스 LLM의 진짜 병목을 건드렸다

이번 발표에서 개발자가 가장 주목해야 할 숫자다. 온디바이스 LLM 추론, 특히 토큰을 하나씩 생성하는 디코딩 단계는 연산이 아니라 메모리 대역폭에 묶인다(memory-bound). 토큰 하나를 만들 때마다 모델 가중치 상당 부분을 메모리에서 읽어와야 하기 때문이다. 그래서 로컬 LLM의 초당 토큰 수(tokens/sec)는 FLOPS보다 메모리 대역폭에 훨씬 민감하다.

아주 거칠게 어림하면 이렇다. 메모리 대역폭이 병목인 상황에서 "초당 생성 토큰 수 ≈ 메모리 대역폭 ÷ (토큰당 읽어야 하는 바이트)"에 가깝게 움직인다. 대역폭이 1.5배가 되면 같은 모델의 생성 속도도 그 근처까지 올라갈 여지가 생긴다는 뜻이다. 물론 캐시·양자화·배치 구성에 따라 달라지지만, 방향성은 분명하다 — 대역폭을 키운 건 "로컬에서 더 큰 모델을, 더 실용적인 속도로" 돌리라는 신호다.

실무 팁 하나. 대역폭이 늘었다고 무작정 큰 모델을 올리면 안 된다. 진짜 제약은 여전히 메모리 용량과 전력이다. 대역폭은 "얼마나 빨리 읽느냐"고 용량은 "얼마나 담느냐"라 별개다. 나는 온디바이스 모델을 고를 때 항상 4비트/3비트 양자화부터 검토한다. 가중치를 절반 이하로 줄이면 읽어야 할 바이트가 줄어 대역폭 병목까지 같이 완화되니까. 대역폭 상향과 양자화는 같이 갈 때 효과가 크다.

32코어 뉴럴 엔진 — NPU가 커졌다는 게 앱에 주는 것

뉴럴 엔진(ANE, Apple Neural Engine)은 애플의 NPU다. 행렬 곱셈 위주의 신경망 추론을 CPU/GPU보다 전력 효율 좋게 처리하는 전용 블록이다. 코어 수가 32개로 커졌다는 건 곧 병렬 추론 처리량(throughput)의 여유가 늘었다는 뜻이다. 단, 코어가 2배라고 처리량이 산술적으로 2배는 아니다. 실제로는 대역폭·전력·모델 구조가 함께 좌우한다.

개발자가 ANE를 직접 프로그래밍하지는 못한다. 접근은 항상 Core ML을 통한다. 모델을 Core ML로 변환해 올리면, 런타임이 연산자별로 ANE / GPU / CPU 중 어디서 돌릴지 스케줄링한다. 그래서 "ANE가 커졌다"의 혜택을 받으려면 내 모델의 연산이 ANE가 잘 소화하는 형태여야 한다. 여기서 문서에 잘 안 나오는 함정이 있다 — 모든 연산자가 ANE에서 도는 게 아니다. 지원 안 되는 연산이 중간에 끼면 GPU/CPU로 폴백되고, 그 경계에서 데이터 이동 비용이 붙는다.

실전 1 — 어느 유닛에서 돌릴지 지정하고 확인하기

Core ML에서 실행 유닛은 MLModelConfiguration.computeUnits로 힌트를 준다. 기본값 .all은 런타임이 알아서 배분하고, ANE를 최대한 태우고 싶으면 .cpuAndNeuralEngine을 쓴다. 다만 "지정"이지 "강제"가 아니다 — 지원 안 되는 연산은 여전히 폴백된다.

// Swift — Core ML 모델을 로드하며 실행 유닛 힌트 지정
import CoreML

let config = MLModelConfiguration()
// .all           : CPU/GPU/ANE 자동 배분 (기본값)
// .cpuAndNeuralEngine : ANE 우선 (온디바이스 LLM/트랜스포머에 유리)
// .cpuOnly       : 디버깅/재현성 확인용
config.computeUnits = .cpuAndNeuralEngine

let model = try MyTextModel(configuration: config)
let output = try model.prediction(input: input)

여기서 끝내면 안 된다. 실제로 ANE가 돌았는지는 코드로는 안 보인다. Xcode의 Instruments에서 Core ML 템플릿으로 프로파일링하면 연산별 실행 유닛과 폴백 지점이 타임라인으로 뜬다. 새 칩에 최적화한다면서 이 확인을 건너뛰면, 대역폭이 50% 늘어도 내 앱은 GPU 폴백 구간에서 그대로 새는 경우가 생긴다.

실전 2 — 기기 성능에 따라 온디바이스 기능을 나누기

A20 Pro가 나왔다고 모든 사용자가 그 칩을 쓰는 건 아니다. 앱은 여전히 수년 전 기기에서도 돌아야 한다. 그래서 온디바이스 AI 기능은 기기 능력에 따라 등급을 나누는(capability gating) 게 정석이다. 큰 모델은 최신·고성능 기기에, 경량 모델이나 서버 폴백은 구형 기기에 배분한다. 칩 모델명을 하드코딩하기보다, 가용 메모리나 성능 티어로 판단하는 편이 유지보수에 낫다.

// Swift — 기기 능력에 따라 온디바이스 모델 등급 선택
import Foundation

enum ModelTier { case large, compact, serverFallback }

func pickModelTier() -> ModelTier {
    // 물리 메모리는 대략적 성능 티어의 프록시로 쓸 수 있다
    let ramGB = Double(ProcessInfo.processInfo.physicalMemory) / 1_073_741_824

    // 저전력 모드에선 무거운 온디바이스 추론을 피한다
    if ProcessInfo.processInfo.isLowPowerModeEnabled {
        return .compact
    }
    switch ramGB {
    case 12...:  return .large          // 넉넉한 최신 Pro 기기
    case 8..<12: return .compact        // 중상위 기기
    default:     return .serverFallback // 구형/저사양
    }
}

실전 3 — 온디바이스 우선, 실패 시 서버 폴백

온디바이스 AI의 매력은 지연·프라이버시·오프라인이지만, 모든 요청을 로컬로 처리할 수는 없다. 실무 패턴은 "로컬로 먼저 시도, 능력 밖이면 서버로"다. 아래는 개념적 폴백 구조다. 핵심은 로컬 실패를 예외로 두지 말고 정상 경로로 설계하는 것.

// Swift(개념 예시) — 온디바이스 우선, 실패 시 서버 폴백
func generate(prompt: String) async throws -> String {
    let tier = pickModelTier()

    if tier != .serverFallback {
        do {
            // 온디바이스 추론 (Core ML / 온디바이스 언어모델 등)
            return try await onDeviceLLM.respond(to: prompt)
        } catch OnDeviceError.contextTooLong,
                OnDeviceError.unsupportedTask {
            // 로컬이 감당 못 하는 요청만 서버로 넘긴다
        }
    }
    return try await serverLLM.respond(to: prompt)   // 서버 폴백
}

A20 Pro처럼 대역폭·NPU가 커진 기기일수록 이 폴백에서 서버로 넘어가는 비율이 줄어든다. 그게 곧 서버 비용 절감이자 지연 감소다. 앱 관점에서 새 칩의 실이익은 "로컬이 처리할 수 있는 요청의 범위가 넓어진다"로 요약된다.

A19 Pro vs A20 Pro — 발표 기준 비교

아래는 이번에 발표된 항목만 정리한 비교다. 클럭·GPU 코어 수 등 미확정 항목은 넣지 않았다. 실측 벤치마크가 나오면 채워질 칸이 더 있겠지만, 지금 확실한 것만 본다.

지금 개발자가 준비할 것

새 칩 발표 때마다 앱을 갈아엎을 필요는 없다. 하지만 온디바이스 AI를 쓰거나 쓸 계획이라면 지금 점검해두면 좋은 것들이 있다.

• Core ML 프로파일링부터: 내 모델이 실제로 ANE에서 도는지, 폴백 구간은 어딘지 Instruments로 확인. 새 칩 이득의 전제 조건이다.
• 양자화 재검토: 대역폭이 늘어도 4비트/3비트 양자화는 여전히 유효하다. 대역폭 상향과 곱해져 체감 속도가 더 붙는다.
• 능력 기반 게이팅: 칩 모델명 하드코딩 대신 메모리·저전력 모드 기준으로 기능 등급을 나눠 신·구 기기 모두 커버.
• 지속 성능 테스트: 첫 1초가 아니라 30초·1분 지속 부하에서의 스로틀링 거동을 측정. 2나노의 이득은 여기서 드러난다.
• 서버 폴백 경로 유지: 온디바이스가 넓어져도 폴백은 남겨둔다. 구형 기기와 능력 밖 요청을 위해.

개인적으로는 발표 스펙에 흥분하기보다, 실기기와 벤치마크가 풀리는 몇 주를 기다렸다가 내 워크로드로 직접 재보는 편이다. "메모리 대역폭 +50%"가 내 앱의 tokens/sec에 실제로 얼마나 반영되는지는, 결국 내 모델·내 양자화·내 프롬프트 길이로 재봐야 안다. 발표는 방향이고, 숫자는 내 손으로 확인하는 것.

자주 묻는 질문

A20 Pro는 언제, 어떤 기기에 탑재되나요?

2026년 9월 9일 Apple 가을 이벤트에서 공개됐고, iPhone 18 Pro와 iPhone 18 Pro Max에 탑재됩니다. 애플 iPhone 칩으로는 최초로 2나노(2nm) 공정을 적용한 제품입니다.

메모리 대역폭이 50% 늘면 온디바이스 LLM 속도도 50% 빨라지나요?

그럴 여지가 있지만 정확히 비례하지는 않습니다. 온디바이스 LLM의 토큰 생성(디코딩) 단계는 메모리 대역폭에 크게 묶여 있어 대역폭 향상의 수혜가 큰 워크로드입니다. 다만 실제 tokens/sec는 양자화, 캐시, 컨텍스트 길이, 전력·발열 제약에 함께 좌우되므로 실측이 필요합니다.

32코어 뉴럴 엔진을 쓰려면 코드를 어떻게 바꿔야 하나요?

뉴럴 엔진(ANE)은 직접 프로그래밍하지 않고 Core ML을 통해 사용합니다. 모델을 Core ML로 변환해 올리면 런타임이 연산을 ANE/GPU/CPU에 배분합니다. 새 코어의 이득을 보려면 모델 연산이 ANE에서 잘 도는지 Instruments로 확인하고 폴백 구간을 줄이는 게 핵심입니다.

2나노 공정의 실질적 이득은 결국 무엇인가요?

주로 전력 효율과 집적도입니다. 같은 성능을 더 적은 전력으로 내거나, 같은 전력에서 더 많은 트랜지스터를 넣을 수 있습니다. 스마트폰에서는 이게 지속 성능(스로틀링 전까지 버티는 시간)과 배터리로 이어져, 오래 도는 온디바이스 AI 작업에서 특히 체감됩니다.

구형 iPhone 사용자를 위해 앱은 어떻게 대응해야 하나요?

온디바이스 기능을 능력 기준으로 등급화하세요. 큰 모델은 고성능 기기에, 경량 모델이나 서버 폴백은 구형 기기에 배분하는 구조가 안전합니다. 칩 모델명 하드코딩보다 가용 메모리·저전력 모드 같은 능력 지표로 분기하면 새 칩이 나와도 코드를 덜 고칩니다.

이번 발표에 CPU/GPU 성능 수치는 없었나요?

이 글에서 확정 사실로 다루는 건 공개된 세 항목(2나노, 메모리 대역폭 +50%, 32코어 뉴럴 엔진)입니다. 세부 CPU/GPU 성능은 실기기 벤치마크가 나와야 신뢰할 수 있으므로, 지어낸 수치 대신 실측을 기다리는 것을 권합니다.

서버 대신 온디바이스로 옮기면 비용이 정말 줄어드나요?

요청 중 로컬에서 처리되는 비율이 늘수록 서버 추론 비용과 왕복 지연이 줄어듭니다. A20 Pro처럼 대역폭·NPU가 커진 기기에서는 로컬이 감당하는 요청 범위가 넓어져 서버로 넘기는 폴백 비율이 낮아지는 효과가 있습니다. 다만 온디바이스 우선·서버 폴백 구조를 함께 유지해야 구형 기기까지 커버됩니다.