iOS 27의 Foundation Models 이미지 입력

iOS 26은 앱에 텍스트를 읽고 텍스트를 쓰는 온디바이스 대규모 언어 모델을 안겨주었습니다. iOS 27은 바로 그 모델에 눈을 달아줍니다. WWDC26에서 Apple은 온디바이스 시스템 언어 모델이 “Vision 기능까지 갖추게 되어, 완전히 새로운 범주의 애플리케이션이 열린다”라고 밝혔습니다¹. 그리고 그 기능에 다다르는 방식은 다소 맥이 빠질 만큼 단순합니다. 이미지를 텍스트 옆에 첨부로 프롬프트에 넣고 질문하면 됩니다. 별도의 Vision 파이프라인도, 모델 교체도, 새로운 세션 타입도 필요 없습니다. 예전에는 문자열을 실어 나르던 프롬프트가 이제 그림까지 실어 나르고, 모델은 둘 모두에 대해 답합니다.

이 작은 표면적이 왜 핵심인지 짚어보겠습니다. 이미지 입력은 Foundation Models에 덧붙인 사이드카 같은 API가 아닙니다. Apple은 이를 “기존 프롬프트 빌더의 자연스러운 확장”이라고 설명합니다¹. 즉, iOS 26에서 이미 익힌 모든 개념(세션, 가이드 생성, Tool 프로토콜)이 프롬프트가 멀티모달이 되는 순간에도 그대로 작동한다는 뜻입니다⁴. 아직 LanguageModelSession을 접해보지 않았다면 Foundation Models 프레임워크 해설부터 보고 다시 돌아오세요.

TL;DR

• iOS 27 온디바이스 모델은 이미지 입력을 받습니다. 이미지 첨부를 텍스트와 함께 프롬프트에 삽입하면, 모델이 이미지에 관한 질문에 답합니다¹².
• 이미지 첨부는 다양한 타입에서 만들 수 있습니다. UIImage, NSImage, CGImage, Core Image 타입, CoreVideo 픽셀 버퍼, 그리고 파일 URL입니다¹.
• 모델은 어떤 크기와 종횡비의 이미지든 지원하므로, 특정 형태에 맞추어 자르거나 패딩할 필요가 없습니다. 다만 이미지가 클수록 더 많은 토큰을 소비하고 지연도 커집니다¹.
• Foundation Models는 LLM에 이미지에 대한 폭넓은 다재다능함을 부여하고, Vision 프레임워크는 고정되고 빠르며 정교하게 튜닝된 분석을 제공합니다. Apple의 권고는 둘 중 하나를 고르는 것이 아니라 도구 호출을 통해 둘을 결합하라는 것입니다².
• Private Cloud Compute 서버 모델도 이미지 입력을 지원하며, 32K 컨텍스트 윈도(온디바이스의 4K 대비)를 갖추고 있습니다. 그래서 텍스트에 더해 여러 이미지를 실은 멀티모달 프롬프트에도 여유가 생깁니다³.

무엇이 바뀌었나: 프롬프트가 그림을 품었다

세션 241에서 Apple의 설명은 정확합니다. 온디바이스 모델은 “더 똑똑해졌고, 논리와 도구 호출에 더 능합니다.” 그리고 그 지능 위에 이제 Vision이 더해집니다¹. 데모에서는 종이접기 사진에 관해 모델에게 묻습니다. “이미지 첨부를 텍스트와 함께 프롬프트에 삽입하기만 하면 됩니다. 이제 모델은 이미지에 관한 질문에 답할 수 있습니다”¹. 순서가 중요합니다. 텍스트와 이미지는 같은 프롬프트 안에 있고, 모델은 프롬프트 전체를 읽으며, 답은 둘 모두를 바탕으로 추론됩니다.

소스 타입의 집합이 충분히 넓어서, 직접 무언가를 변환해야 하는 경우는 드뭅니다. Apple은 여섯 가지를 나열합니다. 이미지 첨부는 “UIImage, NSImage, CGImage, Core Image 타입, CoreVideo 픽셀 버퍼, 그리고 파일 URL을 포함한 다양한 타입에서 만들 수 있습니다”¹. PhotosPicker에서 바로 나온 UIImage, 이미 렌더링한 CGImage, 카메라에서 CVPixelBuffer로 가져온 프레임, URL로 가리키는 디스크 위의 파일 모두가 유효한 입력이 됩니다. 트랜스크립트는 입력 타입을 거명하지만 첨부 이니셜라이저의 정확한 시그니처까지는 적시하지 않습니다. 그러니 타입 목록을 계약으로 보고, iOS 27 SDK에 들어가면 호출 지점은 Xcode 자동완성에 맡기세요.

맞서 싸울 필요가 없는 제약이 하나 있습니다. 바로 형태입니다. “모델은 어떤 크기와 종횡비의 이미지든 지원하므로, 특정 형태에 맞추어 자르거나 패딩할 필요가 없습니다”¹. 세로로 긴 영수증, 가로로 넓은 파노라마, 정사각형 썸네일 모두 그대로 받아들여집니다. 비용은 토큰 예산을 가진 어떤 모델에서든 예상되는 그것입니다. “임의의 이미지 크기가 허용되지만, 이미지가 클수록 더 많은 토큰을 소비하고 지연도 커진다는 점을 유념하세요”¹. 이미지는 공짜 컨텍스트가 아닙니다. 텍스트와 같은 예산에서 지출합니다. 이것이 멀티모달이 강제하는 첫 번째 설계 결정이며, 컨텍스트 크기(아래에서 다룸)가 핵심 변수가 되는 이유이기도 합니다.

이미지 입력은 기존 프롬프트 빌더 위에서 돌아가므로, iOS 26의 장치는 그대로 살아 있습니다. 가이드 생성은 여전히 출력을 @Generable 타입으로 빚어냅니다. Tool 프로토콜은 여전히 모델이 여러분의 코드를 호출하게 합니다. 스트리밍은 여전히 스트리밍됩니다. 모델은 감각 하나를 얻은 것이지, 새로운 프로그래밍 모델을 얻은 것이 아닙니다.

이미지 이해와의 연계: Foundation Models와 Vision은 경쟁 상대가 아니다

세션 237 “이미지 이해의 새로운 기능”은 이미지를 분석하는 두 가지 방식 사이에 Apple이 선을 긋는 자리이며, 그 구분은 무엇을 만들지 결정하는 데 있어 두 강연을 통틀어 가장 유용한 부분입니다. 도입부가 그 점을 드러냅니다. 발표자의 일정표가 사라지고, 그녀는 포스트잇을 촬영한 뒤 “대규모 언어 모델에 일정표를 생성”해 달라고 요청합니다. “이는 Foundation Models 프레임워크로 꽤 쉽게 할 수 있습니다. 고맙게도 올해 Foundation Models는 이미지 입력을 지원합니다”². 이것이 멀티모달의 서술적 측면을 향한 홍보의 전부입니다. 이미지에 캡션 달기, 방 사진에서 인테리어 개선안 제안하기, 냉장고 사진에서 레시피 생성하기. LLM이 빛나는 지점에 대한 발표자의 결론은 이렇습니다. “모델은 서술적인 작업을 잘 해내는 경향이 있습니다”².

이어서 솔직한 비교가 나옵니다. “Foundation Models 프레임워크는 대규모 언어 모델을 활용하며, 이는 무엇이든 거의 요청하는 대로 해줍니다. 그에 비해 Vision 같은 전통적인 이미지 처리 프레임워크는 고정된 컴퓨터 비전 API 집합을 사용합니다. Vision API는 특정 작업에 맞게 정교하게 튜닝되어 있고, 그 작업을 정말 잘 해냅니다. 그리고 Vision은 빠릅니다. 흔히 동영상 프레임을 실시간으로 분석할 만큼 빠릅니다”². 이를 라우팅 규칙으로 읽으세요. 정지 이미지에 대한 제약 없는 질문이고, 언어로 답을 받고 싶다면? Foundation Models입니다. 동영상 프레임 속도에서의 특정하고 잘 정의된 작업(얼굴 검출, 자세, 돌출도, 분할)이라면? Vision입니다. LLM은 생각하는 만능가이고, Vision API는 달리는 전문가입니다.

Apple의 결론은 둘 중 하나를 고를 필요가 없다는 것입니다. “이미지를 분석할 때 Vision과 Foundation Models 중 반드시 하나를 골라야 하는 것은 아닙니다. 도구 호출을 사용해 Vision의 전문성을 Foundation Model의 다재다능함과 함께 활용하는 방법이 있습니다”². iOS 27의 도구 호출은 이제 이미지 인수를 지원합니다. 모델이 스스로 무언가를 식별하지 못할 때(강연은 식물 식별을 예로 듭니다), 모델은 도구를 호출하고 “이미지 전체를 인수로 넘기는 대신, 이미지에 대한 참조를 넘깁니다”². 그 참조, 즉 ImageReference는 “현재 채팅 세션에 있는 기존 이미지에 대한 참조여야 합니다”². 도구는 이것을 세션 기록을 통해 첨부로 되살려 분석할 준비를 마칩니다. 제어 루프와 내장된 OCRTool 및 BarcodeReaderTool은 자매 글인 iOS 27의 도구 호출 제어의 주제입니다. 여기서의 요점은 더 좁습니다. 이미지 입력과 이미지 인수 도구는 같은 멀티모달 스택의 두 층이며, 서로 결합됩니다.

Private Cloud Compute의 멀티모달: 같은 프롬프트, 더 넓은 방

세션 319는 멀티모달 이야기의 양쪽 절반을 한꺼번에 확인하며 시작합니다. 온디바이스 모델은 “이제 이미지 입력을 지원하고, 지시 따르기에 더 능하며, 커스텀 도구 호출도 개선되었습니다”³. 그리고 더 무거운 경우를 위해 Private Cloud Compute에 새로운 서버 모델이 있습니다. 멀티모달과 PCC가 같은 대화에 속하는 이유는 컨텍스트 크기입니다. Apple은 수치를 분명히 밝힙니다. “온디바이스 모델은 4k를 제공하고, PCC로는 32K를 얻습니다”³. 이미지는 그 예산에서 토큰을 지출합니다¹. 그래서 텍스트에 더해 여러 이미지를 실은 프롬프트는 바로 4K를 압박하면서 32K에는 넉넉히 들어맞는 종류의 페이로드입니다.

요약기 데모가 그 들어맞음을 구체적으로 보여줍니다. “여기 PCC 모델로 기사를 요약하는 앱이 있습니다. markdown 파일을 선택할 수 있고, 우리는 텍스트와 이미지를 가져와 LanguageModelSession에 넣어 요약을 생성합니다. 이는 PCC가 제공하는 큰 컨텍스트 크기와 아주 잘 맞습니다”³. 텍스트와 이미지, 하나의 세션, 하나의 프롬프트. 온디바이스에서 서버로 옮겨가는 비용은 한 줄입니다. Apple은 “단 한 줄의 코드만 바꾸면 PCC의 새로운 서버 모델로 전환할 수 있다”라고 보여줍니다³. “Foundation Models 프레임워크는 어떤 모델과 대화하든 통일된 Swift API를 제공”하기 때문입니다³. Generable을 통한 가이드 생성과 도구 호출은 “온디바이스 모델에서와 마찬가지로 PCC 모델에서도 똑같이 작동합니다”³.

PCC는 추론을 더합니다. 온디바이스에는 없는 것입니다. 그리고 추론에는 멀티모달과 관련된 비용이 따릅니다. “추론은 모델이 생성하는 추가 텍스트입니다. 그러므로 토큰을 사용합니다. 이는 컨텍스트 크기 한도에 산입됩니다”³. 깊은 추론과 하나의 프롬프트 안의 풀 해상도 이미지 여러 장을 짝지으면, 32K 예산을 양쪽 끝에서 지출하게 됩니다. 더 깊은 세부 사항(세 가지 추론 수준, quotaUsage와 isLimitReached를 통한 일일 한도 처리, 개발자 사이트에서 신청하는 엔타이틀먼트)은 Private Cloud Compute 심층 해설에 속합니다. 멀티모달의 핵심은, 같은 이미지를 품은 프롬프트가 두 모델 모두에서 실행되며, 프롬프트가 기기의 용량을 넘어설 때를 위해 서버 모델이 존재한다는 것입니다.

이미지 입력 도입하기

위의 계약에서 도출되는 짧은 체크리스트입니다.

온디바이스로 시작하고, 측정하고, 그다음에 결정한다. Apple 자신의 조언은 모델을 “분위기가 아니라 데이터에 근거해” 고르라는 것이며³, “특히 올해 업데이트된 모델에서는, 특정 작업에서 온디바이스 모델이 얼마나 잘 작동하는지에 놀랄 수 있다”라고 일러둡니다³. 캡션이나 “이게 무슨 물체야”라는 질의는 PCC가 전혀 필요 없을 수도 있습니다. 프롬프트가 여러 이미지를 싣거나, 4K 온디바이스 윈도를 넘는 긴 텍스트를 실을 때 서버 모델로 손을 뻗으세요³.

파이프라인에 가장 저렴한 소스 타입을 고른다. 모델에는 UIImage, NSImage, CGImage, Core Image 타입, CVPixelBuffer, 또는 파일 URL을 건넬 수 있습니다¹. 프레임이 이미 카메라에서 온 픽셀 버퍼로, 혹은 디스크 위의 파일로 존재한다면, UIImage를 거쳐 왕복하지 말고 직접 넘기세요.

이미지 해상도를 품질 다이얼이 아니라 예산 손잡이로 다룬다. 어떤 크기와 종횡비든 합법이므로¹, 형태를 위한 과도한 자르기는 자제하세요. 다만 이미지가 클수록 토큰과 지연 비용이 더 들기 때문에¹, 작업(이 표지판 읽기, 이건 무슨 방인지)이 모든 픽셀을 필요로 하지 않는다면 48메가픽셀 사진은 프롬프트에 들어가기 전에 축소하세요.

반사가 아니라 작업으로 분기한다. 서술적이고 제약 없으며 언어가 출력되는 작업은 Foundation Models로, 고정되고 빠르며 실시간인 컴퓨터 비전 작업은 Vision으로 보내세요. 둘 다 필요하면 Foundation Models 도구 안에서 Vision을 호출하세요². 두 프레임워크는 상호 보완적인 층이며, 이미지 인수 도구는 둘을 잇는 이음매입니다.

가용성 확인을 유지한다. 이미지 입력은 같은 모델 위에서 돌아가고, 그 모델은 “Apple Intelligence 기기에서만 사용할 수 있습니다”³. 가용성 API를 확인하고, Apple Intelligence가 없는 곳에서는 우아하게 강등하세요³.

FAQ

iOS 27에서 Foundation Models 모델에 이미지를 보내려면 어떻게 하나요?

기존 프롬프트 빌더를 사용해 이미지 첨부를 텍스트와 함께 프롬프트에 삽입한 뒤, 모델에 응답을 요청하면 됩니다. Apple은 이 API를 “기존 프롬프트 빌더의 자연스러운 확장”이라고 설명합니다. 세션을 만들고, “이미지 첨부를 텍스트와 함께 프롬프트에 삽입하기만 하면” “모델이 이미지에 관한 질문에 답할 수 있습니다”¹. 별도의 Vision 파이프라인도, 새로운 세션 타입도 관여하지 않습니다.

Foundation Models에는 어떤 이미지 타입을 넘길 수 있나요?

이미지 첨부는 UIImage, NSImage, CGImage, Core Image 타입, CoreVideo 픽셀 버퍼, 그리고 파일 URL에서 만들 수 있습니다¹. 트랜스크립트는 이 소스 타입들을 열거하지만 모든 이니셜라이저 시그니처를 명시하지는 않습니다. 그러니 정확한 호출 지점은 iOS 27 SDK가 제공하게 두세요.

보내기 전에 이미지를 리사이즈하거나 잘라야 하나요?

아니요. “모델은 어떤 크기와 종횡비의 이미지든 지원하므로, 특정 형태에 맞추어 자르거나 패딩할 필요가 없습니다”¹. 트레이드오프는 합법성이 아니라 비용입니다. “이미지가 클수록 더 많은 토큰을 소비하고 지연도 커집니다”¹. 그러니 작업이 풀 해상도를 필요로 하지 않는다면, 아주 큰 사진을 축소하는 것은 예산상의 결정입니다.

이미지에 대해 Foundation Models 대신 Vision을 써야 하는 때는 언제인가요?

고정되고 잘 정의되었으며 속도가 중요한 작업에는 Vision을 쓰세요. Apple은 Vision이 “고정된 컴퓨터 비전 API 집합을 사용”하고 “특정 작업에 맞게 정교하게 튜닝되어 있으며” “흔히 동영상 프레임을 실시간으로 분석할 만큼 빠르다”라고 언급하는 반면, Foundation Models는 “무엇이든 거의 요청하는 대로 해주고” 서술적인 작업에 뛰어나다고 합니다². 둘 다 원할 때는, 도구 호출을 통해 Foundation Models 세션에서 Vision 기반 도구를 호출하세요².

이미지 입력이 Private Cloud Compute 서버 모델에서도 작동하나요?

네. Apple은 온디바이스 모델이 “이제 이미지 입력을 지원한다”라고 확인하며³, PCC 데모는 문서의 “텍스트와 이미지”를 요약을 위해 LanguageModelSession에 넣습니다³. 같은 통일된 Swift API가 두 모델 모두에서 돌아가므로, 같은 이미지를 품은 프롬프트가 한 줄 변경으로 온디바이스에서도 서버에서도 작동합니다. PCC의 32K 컨텍스트(온디바이스의 4K 대비)는 다중 이미지 프롬프트에 더 많은 여지를 줍니다³.

Apple Ecosystem 클러스터 전체: Foundation Models 프레임워크 해설, 온디바이스 LLM, iOS 27의 도구 호출 제어, 그리고 Private Cloud Compute 심층 해설. 허브는 Apple Ecosystem 시리즈입니다. AI 에이전트를 곁들인 iOS의 더 넓은 맥락은 iOS 에이전트 개발 가이드를 참고하세요.