네이티브 앱은 빌드해서 시뮬레이터에 띄워 직접 만져봐야 한다. Codex가 XcodeBuildMCP 검증 루프로 '픽셀보다 텍스트 먼저' 원칙 아래 iOS 앱 제작·시뮬레이터 디버깅·Liquid Glass 마이그레이션·App Intents·Mac 셸·Logger 텔레메트리를 어떻게 해내는지 실제 사례로 풀어봅니다. Codex Use Cases 특집 4편.
1편 아키텍처, 2편 엔지니어, 3편 프론트엔드에 이어, 이번엔 애플 네이티브 — iOS와 macOS의 세계입니다.
3편에서 프론트엔드의 난제가 "코드는 맞는데 화면이 안 맞아"였다면, 네이티브엔 한 겹 더 두꺼운 벽이 있습니다.
웹은 그래도 브라우저에 URL만 치면 떴습니다. 네이티브는? Xcode 프로젝트를 빌드하고, 시뮬레이터를 부팅하고, 앱을 설치해서, 손가락으로 직접 탭해봐야 맞는지 압니다. 게다가 그 과정 대부분이 Xcode라는 GUI 안에 갇혀 있죠.
오랫동안 AI 코딩 도구가 네이티브 앞에서 작아졌던 이유입니다. 코드는 그럴듯하게 짜도, 그게 실제 기기에서 어떻게 보이고 동작하는지 확인할 길이 없었으니까요. 2026년의 Codex가 이 벽을 어떻게 넘는지 — 그 핵심 메커니즘부터 봅시다.
이 시리즈 (총 6편) · 1. Codex의 탄생 · 2. 엔지니어를 위한 Codex · 3. 디자이너·프론트엔드 · 4. (현재 글) iOS·macOS · 5. Knowledge Work · 6. Computer Use & 자동화
3편의 비주얼 피드백 루프를 기억하시나요? 네이티브에도 그에 대응하는 루프가 있습니다. 다만 무대가 브라우저가 아니라 iOS 시뮬레이터이고, 도구가 Playwright가 아니라 XcodeBuildMCP입니다.
XcodeBuildMCP는 xcodebuild(빌드)와 xcrun simctl(시뮬레이터 제어)을 감싼 MCP 서버입니다. (MCP가 "에이전트의 USB 포트"라는 건 1편에서 다뤘죠.) 이걸 통해 Codex는 Xcode GUI를 열지 않고도 터미널만으로 앱을 빌드하고, 시뮬레이터에 띄우고, 화면을 조작하고, 검증합니다.
여기서 Part 4 전체를 관통하는 핵심 통찰 하나가 나옵니다.
픽셀보다 텍스트 먼저. Codex는 화면을 탭하기 전에 스크린샷 대신 접근성 트리(accessibility tree)를 텍스트로 읽습니다.
왜일까요? 비용 때문입니다.
게다가 접근성 트리로 "로그인 버튼"이라는 라벨을 보고 탭하면, 좌표로 탭할 때와 달리 레이아웃이 바뀌어도 안 깨지고, 덤으로 접근성(a11y) 누락도 드러납니다. 스크린샷은 정말 "눈으로 봐야 할 때"만 아껴 씁니다. 아래에서 이 루프를 직접 돌려보세요.
이 "텍스트 먼저, 그림은 확인용" 원칙이 네이티브 작업 전반에 깔려 있습니다. 이제 각 use case로 들어갑니다.
가장 기본. Build for iOS는 SwiftUI 앱을 iPhone·iPad용으로 스캐폴딩하고 빌드·디버깅합니다. 전 과정이 CLI 우선이라, Codex가 Xcode GUI에 갇히지 않습니다.
재밌는 디테일 하나. 새 앱을 만들 때 Codex에게 "빌드해서 실행하는 스크립트"까지 함께 만들라고 시킵니다. 그래야 매번 같은 방식으로 빌드·실행·검증을 반복할 수 있거든요. 그리고 공식 시작 프롬프트는 Codex에게 자기가 한 일을 정확히 보고하게 합니다.
기존 저장소라면 XcodeBuildMCP로 타깃을 나열하고, scheme을 골라 빌드하고, 시뮬레이터에 띄워 스크린샷을 찍습니다. 변경할 때마다 작은 검증 루프가 돕니다. SwiftUI·Swift 동시성·성능 같은 스킬이 함께 붙어 전문성을 보탭니다. 사람이 Xcode에서 ⌘R을 누르고 눈으로 확인하던 일을, 루프가 대신하는 셈입니다.
네이티브 검증 루프가 가장 빛나는 순간이 Debug in iOS Simulator입니다. "로그인 후 가끔 화면이 하얗게 떠요" 같은 막연한 리포트를 재현되고 검증된 수정으로 바꿉니다.
핵심은 "고쳤다"가 아니라 "같은 경로를 다시 밟아 확인했다"입니다. 추측이 아니라 증거로 닫는 거죠. 이건 2편 엔지니어 편의 "테스트로 검증", 3편의 "스크린샷으로 검증"과 같은 정신 — 네이티브에서는 시뮬레이터 구동 + 로그 + 스크린샷이 그 증거가 됩니다.
이제 2025~2026년 애플 생태계에서 가장 큰 화두, Liquid Glass입니다. iOS Liquid Glass use case는 기존 SwiftUI 앱을 여기에 맞춰 옮깁니다.
Liquid Glass는 애플이 2025년 6월 WWDC에서 발표하고 iOS 26·macOS Tahoe 26 등에 도입한 새 디자인 언어입니다. 뒤 콘텐츠를 굴절·반사하는 반투명 "유리" 재질로, 툴바·사이드바·시트·버튼을 다시 칠합니다. 직접 토글해 차이를 느껴보세요.
예전엔 개발자들이 .ultraThinMaterial에 테두리·그림자·하이라이트를 손으로 쌓아 "유리처럼" 흉내 냈습니다. iOS 26은 이걸 네이티브 모디파이어로 대체합니다.
// iOS 26 Liquid Glass — 예시 (API 시그니처는 버전에 따라 다를 수 있음)
import SwiftUI
struct GlassCard: View {
var body: some View {
if #available(iOS 26, *) {
content
.glassEffect(in: .rect(cornerRadius: 20)) // 네이티브 유리
} else {
content
.background(.ultraThinMaterial) // 구버전 폴백
}
}
}
관련 API로 여러 유리 요소를 묶는 GlassEffectContainer, 전환 시 모핑을 위한 glassEffectID + @Namespace, 버튼용 .buttonStyle(.glass)/.glassProminent 등이 있습니다.
왜 이게 Codex에 딱 맞는 작업일까요? 세 가지가 한꺼번에 필요하기 때문입니다.
if #available(iOS 26, *)로 구버전 폴백을 남긴다.좋은 앱 기능이 앱 안에만 갇혀 있으면 아깝습니다. Add iOS App Intents는 앱의 액션을 Siri·단축어(Shortcuts)·Spotlight 같은 시스템 표면에 노출합니다.
개념적으로 App Intents는 "앱의 액션과 데이터를 시스템에 내보내는 구조적 계약"입니다. 세 가지 부품으로 이뤄집니다.
| 부품 | 역할 | 비유 |
|---|---|---|
AppIntent + perform() | 실행 가능한 *액션* 하나 (예: "글 작성") | 시스템이 부를 수 있는 *버튼* |
AppEntity + EntityQuery | 시스템이 *해석·라우팅할 객체* (예: 특정 목록·계정) | 액션이 다루는 *명사* |
AppShortcutsProvider | 발견 가능한 *문구·제목* 제공 | "헤이 시리, ○○해줘"의 *대사집* |
작업 흐름은 이렇습니다: 가장 가치 높은 액션을 추린다 → 시스템이 라우팅해야 하는 데이터만 entity로 정의한다(앱의 모델 전체를 복제하지 말 것) → 전용 App Intents 타깃을 만든다 → 런타임에서 라우팅을 검증한다. 예를 들어 콘텐츠 앱이라면 "글 작성", "타임라인 필터(파라미터로 목록 entity)", "특정 탭으로 딥링크" 같은 인텐트를 노출하는 식이죠.
포인트는 절제입니다. 앱의 모든 데이터를 entity로 만들면 복잡도만 폭발합니다. 시스템이 실제로 "골라서 연결"해야 하는 것만 노출하는 게 핵심입니다.
이제 데스크톱으로. Build for macOS와 Build a Mac App Shell은 Mac다운 앱을 만듭니다. 여기서 가장 흔한 실수가 "iOS 패턴을 그대로 가져오는 것"입니다. Codex는 scene 모델부터 다르게 잡습니다.
| scene 타입 | 언제 |
|---|---|
WindowGroup | 여러 창을 띄우는 문서형 앱 |
Window | 단일 보조 창 |
Settings | 환경설정 창 |
MenuBarExtra | 메뉴바 상주 앱 |
대표적인 Mac 셸은 3-pane 구조 — 사이드바, 디테일, 인스펙터입니다. 핵심 API는 다음과 같습니다.
// Mac 3-pane 셸 — 예시
NavigationSplitView {
SidebarView(selection: $selection) // 사이드바
} detail: {
DetailView(item: selection) // 디테일
}
.inspector(isPresented: $showInspector) { // 인스펙터(보조 메타데이터)
InspectorView(item: selection)
}
상태도 Mac답게 나눕니다: 창 UI 상태는 @SceneStorage, 사용자 환경설정은 @AppStorage, 선택은 부모가 소유하는 명시적 바인딩으로. 그리고 액션은 iOS의 화면 버튼이 아니라 commands/CommandMenu로 키보드 우선 설계합니다. AppKit이 꼭 필요할 때만 NSViewRepresentable로 다리를 놓고요.
네이티브에서 "이 동작이 진짜 일어났나?"를 추측하지 않으려면 증거가 필요합니다. macOS에서 그 증거가 os.Logger(통합 로깅)입니다. Mac Telemetry use case는 기능을 계측하고 검증합니다.
os.Logger는 애플의 구조적·저오버헤드 통합 로깅 시스템입니다. 쓰는 법은 간단합니다.
import OSLog
let logger = Logger(
subsystem: Bundle.main.bundleIdentifier ?? "SampleApp", // 보통 번들 ID
category: "Sidebar" // 기능 단위
)
logger.info("선택한 항목: \(id, privacy: .public)") // 민감정보는 .private
subsystem은 앱(번들 ID), category는 기능을 가리킵니다. .info는 안정적인 고신호 이벤트, .debug는 임시 잡음(끝나면 제거). 그리고 privacy: 보간으로 비밀번호·개인정보가 새지 않게 합니다.
검증 루프가 핵심입니다 — 한 기능을 계측하고 → 실행하고 → log stream으로 필터링해 이벤트 타임라인을 읽습니다.
이게 macOS판 검증 루프입니다. "상태가 바뀌었겠지" 추측하는 대신, Codex가 이벤트 타임라인을 읽고 → 패치하고 → 같은 흐름을 다시 돌려 확인합니다. 시뮬레이터 스크린샷이 "눈으로 보는 증거"라면, 로그는 "읽는 증거"인 셈이죠.
마지막으로 두 가지를 묶습니다. 먼저 Refactor SwiftUI Screens — 비대해진 화면을 동작·레이아웃을 바꾸지 않고 작은 서브뷰로 쪼갭니다.
body에서 빼서 메서드로 옮길 것."@State/@Environment/.task를 뷰모델보다 먼저 쓰고, 거대한 계산 프로퍼티 대신 진짜 서브뷰로 추출합니다. 그리고 매 추출 후 빌드 체크 + SwiftUI 프리뷰 + 전후 스크린샷으로 검증하죠. 한 방에 다시 쓰는 게 아니라 작게 쪼개 검증하는 것 — 2편 리팩토링과 같은 정신입니다.
크로스플랫폼도 잠깐. Build React Native Apps with Expo는 아이디어를 Expo 앱으로 빠르게 만듭니다. Expo Router(파일 기반 라우팅)로 시작해, 처음엔 Expo Go(npx expo start)에서 바로 돌려보고, 커스텀 네이티브 코드나 배포가 필요해질 때만 dev client·EAS 빌드로 넘어갑니다. 네이티브 프로비저닝을 미뤄 앱 로직에 먼저 집중하는 거죠. (단, 이건 Swift가 아니라 JS/TS — 위의 Xcode 루프와는 별개입니다.)
iOS와 macOS의 작업들을 따라왔습니다. 다시 보면 시리즈 전체의 주제가 네이티브에서 다시 한번 변주됩니다.
웹이든 네이티브든, Codex의 일하는 방식은 같습니다 — 추측하지 않고 증거로 닫는 것. 다만 증거의 모양이 다를 뿐입니다. 백엔드는 테스트, 프론트엔드는 스크린샷, 네이티브는 시뮬레이터 구동 + 접근성 트리 + 로그. 그리고 여기서도 사람은 "무엇이 맞는 동작·디자인인가"를 정하고, Codex는 그 기준에 맞을 때까지 빌드하고 만져보고 확인합니다.
네이티브 개발의 하루 — iOS 앱 제작, 시뮬레이터 디버깅, Liquid Glass 마이그레이션, App Intents, Mac 셸, Logger 텔레메트리, SwiftUI 리팩토링 — 를 Codex와 함께 따라가 봤습니다. 핵심은 "빌드해서 직접 만져봐야 아는" 네이티브의 벽을 검증 루프 + 픽셀보다 텍스트 먼저로 넘는다는 것이었습니다.
**다음 편(5화) — 「Knowledge Work: 파이낸스·오퍼레이션·세일즈」**에서는 코드를 완전히 떠납니다. Codex가 개발자가 아닌 사람들의 일을 어떻게 돕는지 봅니다.
시리즈 인덱스
- Codex의 탄생 — 역사 · 벤치마크 · 아키텍처
- 엔지니어를 위한 Codex — 이해 · 검토 · 이전
- 디자이너·프론트엔드 — 비주얼 루프 · Figma · Spark
- (현재 글) iOS·macOS 네이티브 개발 — 검증 루프 · Liquid Glass · App Intents
- Knowledge Work — 파이낸스 · 오퍼레이션 · 세일즈
- Computer Use & 자동화
이 글은 코어닷투데이의 "Codex Use Cases 특집" 시리즈 4편입니다. 사실관계는 2026년 5월 기준이며, 모델·API 시그니처·도구 이름은 빠르게 바뀔 수 있습니다(특히 XcodeBuildMCP 도구명과 Liquid Glass API는 예시로 보세요). 예시 프롬프트는 OpenAI의 Codex use-cases 문서를 참고했습니다.
