두 개의 MCP 서버가 Claude Code를 iOS 빌드 시스템으로 바꿨습니다

저는 Claude Code로 11개의 iOS 앱을 개발합니다. Git 안전을 지키는 hooks, 코드 품질을 강제하는 규칙, 그리고 팀의 패턴을 인코딩한 에이전트 정의가 있습니다. 하지만 어제까지만 해도 빌드 에러가 발생할 때마다 터미널 출력을 복사하고, 다시 붙여넣고, 에이전트가 맥락을 이해하길 바라야 했습니다. 시뮬레이터 관리는 원시 xcrun simctl 명령어로 처리했습니다. 테스트 결과는 구조화되지 않은 텍스트 덩어리로 전달되었습니다.

claude mcp add 명령어 두 개가 이 모든 것을 바꿨습니다.

요약

XcodeBuildMCP(76개 도구, 오픈 소스)는 빌드, 테스트, 시뮬레이터, 실제 기기 배포, LLDB 디버깅을 처리합니다 — Xcode를 실행하지 않고도 가능합니다. Apple의 네이티브 Xcode MCP(20개 도구, Xcode 26.3에 포함)는 실행 중인 Xcode 프로세스에 연결되어 파일 작업, 실시간 진단, 문서 검색, Swift REPL, SwiftUI 미리보기를 제공합니다. 이 둘을 합치면 Claude Code가 iOS 개발 도구 체인에 대한 완전한 프로그래밍 접근 권한을 갖게 됩니다 — 로그 파싱 대신 구조화된 JSON, 셸 명령어 대신 도구 호출. 설정은 2분도 걸리지 않습니다.

문제점

Claude Code는 Swift를 읽고 쓰는 데 뛰어납니다. SwiftUI 패턴, SwiftData 관계, Swift 6 동시성을 이해합니다. 하지만 빌드 시스템에 대해서는 완전히 눈이 먼 상태였습니다.

빌드가 실패하면 에이전트는 다음을 수행해야 했습니다:

1. Bash를 통해 xcodebuild 실행
2. 수천 줄의 비구조화된 출력 파싱
3. 노이즈 속에서 실제 에러를 찾기를 기대
4. 어떤 파일의 어떤 줄이 실패를 일으켰는지 추측

테스트를 실행하고 싶을 때는:

1. 에이전트가 기억에 의존해 전체 xcodebuild test 명령어를 구성
2. xcresult 번들(또는 더 흔하게는 원시 stdout)을 파싱
3. 어떤 테스트가 통과했고 어떤 테스트가 실패했는지 파악 시도

이것은 개발자에게 열쇠 구멍을 통해 컴파일러 출력을 읽으면서 코드를 작성하라고 요구하는 것과 같습니다. 정보는 기술적으로 거기에 있었지만, 인터페이스가 잘못된 것이었습니다.

해결책: 두 개의 상호 보완적인 MCP 서버

XcodeBuildMCP (커뮤니티, 오픈 소스)

XcodeBuildMCP는 xcodebuild 및 관련 도구를 76개의 구조화된 MCP 도구로 래핑합니다. 에이전트가 xcode_build를 호출하면 3,000줄짜리 빌드 로그가 아닌, 분류된 에러, 경고, 파일 위치가 포함된 JSON을 돌려받습니다.

주요 도구:

설치:

claude mcp add XcodeBuildMCP \
  -s user \
  -e XCODEBUILDMCP_SENTRY_DISABLED=true \
  -- npx -y xcodebuildmcp@latest mcp

-s user 플래그는 전역 설정입니다 — 프로젝트별 설정 없이 모든 프로젝트에서 사용할 수 있습니다. 환경 변수는 텔레메트리를 비활성화합니다(기본값은 Sentry에 크래시 리포트를 전송하지만, 저는 옵트아웃을 선호합니다).¹

Apple Xcode MCP (네이티브, Xcode 26.3에 포함)

Apple은 Xcode 26.3에서 xcrun mcpbridge를 통해 자체 MCP 서버를 출시했습니다. XPC를 통해 Xcode 프로세스에 직접 연결되는 20개의 도구를 제공합니다:

설치:

claude mcp add --transport stdio xcode -s user -- xcrun mcpbridge

Xcode 26.3 이상이 필요합니다(현재 Release Candidate, 곧 출시 예정).

왜 두 개 모두 필요한가?

빌드와 테스트에서 겹치는 부분이 있지만, 아키텍처가 다릅니다:

• XcodeBuildMCP는 xcodebuild CLI를 통해 독립적으로 작동합니다 — Xcode 프로세스가 필요하지 않습니다. 시뮬레이터, 실제 기기, LLDB 디버깅, UI 자동화, 프로젝트 스캐폴딩을 포함하는 76개의 도구를 추가합니다. 헤드리스 워크플로우와 CI에 가까운 개발에 이상적입니다.
• Apple Xcode MCP는 실행 중인 Xcode 인스턴스가 필요하며 XPC를 통해 통신합니다. Xcode 프로젝트 컨텍스트 내에서의 파일 작업, 실시간 코드 진단(빌드 출력만이 아닌), WWDC 세션을 포함한 네이티브 문서 검색을 제공합니다.

저는 두 가지 모두 사용합니다: XcodeBuildMCP는 빌드-테스트-디버그 사이클에(Xcode를 열지 않아도 작동), Apple의 MCP는 문서 검색, Swift REPL 검증, 또는 SwiftUI 미리보기 렌더링이 필요할 때 사용합니다.

실제 테스트

Water 앱(SwiftUI + Metal 유체 시뮬레이션 + HealthKit)에서 다음 프롬프트를 사용하여 전체 상태 점검을 실행했습니다:

Use the XcodeBuildMCP and Apple Xcode MCP tools to do a full
health check of this project:

1. List available simulators and boot an iPhone 16 Pro
2. Build the project for that simulator
3. Run existing tests and report pass/fail results
4. Search Apple docs for "HealthKit water intake"
5. Use the Swift REPL to verify HKQuantityType(.dietaryWater)

결과

시뮬레이터 설정은 list_sims, session_set_defaults, boot_sim을 사용했습니다. 에이전트는 iOS 26 런타임에 iPhone 16 Pro가 존재하지 않는다는 것을 발견하고(해당 모델이 단종됨), 자동으로 iPhone 17 Pro로 전환했습니다. 이것이 바로 하드코딩된 xcodebuild 명령어에서는 실패하는 종류의 적응적 행동입니다.

빌드는 처음에 실패했습니다 — 새 Xcode 설치에서 Metal Toolchain이 다운로드되지 않은 상태였습니다. 에이전트는 구조화된 에러 출력에서 이를 감지하고 xcodebuild -downloadComponent MetalToolchain을 실행하여 해결했습니다. 이후 빌드는 3개의 경고와 함께 성공했습니다:

HomeView.swift:132    UIScreen.main deprecated in iOS 26.0
LogWaterIntent.swift:61   Result of try? is unused

구조화된 출력 덕분에 이러한 경고가 정확한 파일:줄 참조와 함께 분류된 경고로 돌아왔으며, 로그 속에 묻히지 않았습니다.

테스트는 실패했습니다 — 하지만 실패 내용은 유용한 정보를 담고 있었습니다. 구조화된 출력은 5개의 테스트 메서드가 이전 커밋에서 제거한 injectTapRipple(atNormalizedX:) 메서드를 참조하고 있다는 것을 보여주었습니다. 에이전트는 정확한 커밋(7657068 — "remove tap ripple interaction entirely")을 식별하고 어떤 테스트를 업데이트해야 하는지 나열했습니다. 모호함이 전혀 없었습니다.

문서 검색과 Swift REPL은 HKQuantityType(.dietaryWater)가 유효하며 식별자 HKQuantityTypeIdentifierDietaryWater를 반환한다는 것을 확인했습니다.

결과 표

전체 상태 점검이 자율적으로 실행되었습니다. Xcode를 열지 않았고, 에러 메시지를 복사하지 않았고, xcodebuild 명령어를 구성하지 않았습니다.

에이전트 교육

MCP 서버를 설치하는 것만으로는 충분하지 않습니다. 에이전트가 도구의 존재를 알고 원시 셸 명령어보다 언제 이를 선호해야 하는지 알아야 합니다. 저는 ios-developer 에이전트 정의를 업데이트하여 명시적인 가이드를 포함했습니다:

## Build & Test Tools (XcodeBuildMCP)

Prefer MCP tools over raw xcodebuild commands:

- **Build**: Use `build_sim` / `build_device` for structured errors
- **Test**: Use `test_sim` / `test_device` for pass/fail results
- **Simulators**: Use `list_sims`, `boot_sim`, `open_sim`
- **Debug**: Use `debug_attach_sim`, `debug_stack`, `debug_variables`

## Apple Xcode MCP (mcpbridge)

- **Documentation**: Use `DocumentationSearch` for Apple docs
- **Swift REPL**: Use `ExecuteSnippet` for API verification
- **Previews**: Use `RenderPreview` for headless SwiftUI rendering

Prefer these over WebSearch for Apple API questions
and over Bash `swift` for REPL tasks.

이 가이드 없이는 에이전트가 때때로 Bash를 통한 xcodebuild로 되돌아가거나, 네이티브 검색 대신 WebSearch로 Apple 문서를 검색합니다. 에이전트 정의가 이 격차를 메워줍니다.²

실제로 달라지는 점

MCP 이전에는 Claude Code와의 iOS 워크플로우가 이렇했습니다:

1. Claude로 코드 작성
2. Xcode에서 수동으로 빌드(또는 터미널에서 xcodebuild로)
3. 에러를 복사하여 Claude에 다시 전달
4. 반복

MCP 이후에는:

1. 원하는 것을 설명
2. Claude가 코드를 작성하고, 빌드하고, 에러를 읽고, 수정하고, 테스트를 실행하고, API 동작을 검증
3. 최종 결과를 검토

이전에는 제가 직접 참여해야 했던 빌드-에러-수정 루프가 이제 자율적으로 실행됩니다. 에이전트는 원시 텍스트에서 무엇이 잘못되었는지 추측하는 것이 아니라 — 정확히 무엇이, 어디서, 왜 실패했는지 알려주는 구조화된 데이터를 읽습니다.

이것은 AI 도구 전반에서 계속 보이는 패턴입니다: 돌파구는 AI를 더 똑똑하게 만드는 것이 아니라, 개발자가 이미 사용하는 도구에 대한 구조화된 접근 권한을 부여하는 것입니다. MCP는 이를 가능하게 하는 프로토콜입니다 — hooks가 Claude Code에 결정론적 가드레일을 부여한 것처럼, MCP는 결정론적 도구 인터페이스를 부여합니다. Xcode는 MCP를 통해 자신을 노출하는 최초의 개발 도구가 아니며 마지막도 아닐 것입니다.³

설정 체크리스트

iOS 프로젝트에서 Claude Code를 실행하는 모든 분을 위해:

1. XcodeBuildMCP 설치 (Xcode 26.3 이상 필요): bash claude mcp add XcodeBuildMCP -s user \ -e XCODEBUILDMCP_SENTRY_DISABLED=true \ -- npx -y xcodebuildmcp@latest mcp

2. Apple Xcode MCP 설치 (Xcode 26.3 이상 필요): bash claude mcp add --transport stdio xcode \ -s user -- xcrun mcpbridge

3. 두 서버의 연결 확인: bash claude mcp list # XcodeBuildMCP: ... - Connected # xcode: xcrun mcpbridge - Connected

4. 에이전트 정의를 업데이트하여 새로운 도구를 참조하세요(그렇지 않으면 에이전트가 때때로 셸 명령어로 되돌아갑니다).

5. 새 Claude Code 세션을 시작하세요 — 세션 도중에 등록된 MCP 도구는 재시작 전까지 도구 검색에 나타나지 않습니다.

이것이 전부입니다. 명령어 두 개로 전체 iOS 빌드 시스템에 접근할 수 있습니다.

FAQ

Xcode가 여전히 설치되어 있어야 하나요?

네. 두 MCP 서버 모두 Xcode의 도구 체인(xcodebuild, xcrun, simctl)을 감싸는 래퍼입니다. Xcode가 설치되고 설정되어 있어야 합니다. MCP 서버는 Claude Code가 이러한 도구에 구조화된 방식으로 접근할 수 있게 해줍니다 — 도구 자체를 대체하는 것은 아닙니다.

XcodeBuildMCP는 SwiftPM 전용 프로젝트에서도 작동하나요?

네. XcodeBuildMCP는 .xcodeproj/.xcworkspace와 Swift Package Manager 프로젝트를 모두 지원합니다. discover_projs를 사용하여 사용 가능한 프로젝트 유형을 찾은 다음, 적절한 scheme으로 build_sim 또는 build_device를 사용하세요.

CI/CD 파이프라인은 어떻게 되나요?

MCP 서버는 Claude Code와 함께 로컬에서 실행됩니다. CI/CD에서는 xcodebuild를 직접 사용하거나 Fastlane 같은 도구를 계속 사용합니다. MCP 접근 방식은 AI 에이전트가 코드-빌드-테스트 사이클 동안 구조화된 피드백이 필요한 대화형 개발 루프에 특화되어 있습니다.