메뉴
NavigationStack 문제(응답 없음, 예기치 않은 pop, 크래시), build 실패(SPM resolution, "No such module", build가 멈추는 경우), 또는 메모리 문제(retain cycle, leak, deinit이 호출되지 않는 경우)를 디버깅할 때 사용합니다. iOS/macOS를 위한 체계적인 진단 워크플로우입니다.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
TCA(The Composable Architecture)로 Feature를 구축하거나 reducer 구조화, state 관리, effect·navigation 처리, TCA feature 테스트를 할 때 사용합니다. @Reducer, Store, Effect, TestStore, reducer 조합 패턴을 다룹니다.
iOS 17+ SwiftUI patterns를 구현할 때 사용합니다: @Observable/@Bindable, MVVM architecture, NavigationStack, lazy loading, UIKit interop, accessibility (VoiceOver), 비동기 작업(.task/.refreshable), 또는 ObservableObject/@StateObject에서 마이그레이션하는 경우.
구현한 화면의 스크린샷·UI hierarchy를 Zeplin 시안 스펙과 항목별로 대조해 PASS/DIFF를 보고합니다.
SwiftUI 코드를 리뷰·정리하거나 soft-deprecated API를 점검할 때 사용합니다. view 구조 분리, dataflow/environment 검토, ForEach identity, localization, deprecation 마이그레이션을 다룹니다. (신규 구현 패턴은 swiftui-patterns 스킬 사용)
device 또는 simulator에서 스크린샷, UI hierarchy, 터치 interaction을 통해 iOS 앱 동작을 확인합니다.
async/await 코드를 작성하거나, strict concurrency를 활성화하거나, Sendable 오류를 수정하거나, completion handler로부터 마이그레이션하거나, actor로 공유 상태를 관리하거나, 동시성을 위해 Task/TaskGroup을 사용할 때 사용합니다.
| name | swift-diagnostics |
| description | NavigationStack 문제(응답 없음, 예기치 않은 pop, 크래시), build 실패(SPM resolution, "No such module", build가 멈추는 경우), 또는 메모리 문제(retain cycle, leak, deinit이 호출되지 않는 경우)를 디버깅할 때 사용합니다. iOS/macOS를 위한 체계적인 진단 워크플로우입니다. |
iOS/macOS 개발을 위한 체계적인 디버깅 워크플로우입니다. 이 pattern들은 구조화된 진단 접근 방식을 따라 몇 시간이 아닌 몇 분 안에 근본 원인을 파악하는 데 도움이 됩니다.
내용이 필요할 가능성이 조금이라도 있다면 항상 참조 파일을 로드하세요. pattern을 놓치거나 실수를 하는 것보다 context를 확보하는 것이 낫습니다.
| 참조 | 로드 시점 |
|---|---|
| Navigation | NavigationStack이 응답하지 않음, 예기치 않은 pop, 딥링크 실패 |
| Build Issues | SPM resolution, "No such module", 의존성 충돌 |
| Memory | Retain cycle, 메모리 증가, deinit이 호출되지 않음 |
| Build Performance | 느린 build, Derived Data 문제, Xcode 행(hang) |
| Xcode Debugging | LLDB 명령어, breakpoint, view debugging |
"미스터리한" 문제의 80%는 예측 가능한 pattern에서 비롯됩니다.
체계적으로 진단하세요. 절대 추측하지 마세요.
필수 선행 확인을 건너뛰기 — 진단(clean build, Simulator 재시작, Xcode 재시작)을 실행하기 전에 곧바로 코드 수정으로 뛰어들면 헛수고를 하게 됩니다. 항상 필수 확인부터 시작하세요.
한 번에 여러 가지를 변경하기 — "DerivedData도 삭제하고 Simulator도 재시작하고 Xcode도 종료해보자"는 식으로 하면 실제로 어떤 수정이 효과가 있었는지 구분할 수 없습니다. 한 번에 하나의 변수만 변경하세요.
원인을 안다고 가정하기 — "NavigationStack이 작동을 멈췄으니 내 reducer 문제일 것이다" — 실제로는 오래된 DerivedData가 원인이었습니다. 진단 트리는 이러한 가정을 방지합니다. 트리를 따르고, 추측하지 마세요.
메모리 기본 사항을 놓치기 — deinit이 호출되지 않는 것은 retain cycle이지만, 초보자들은 흔히 architecture를 탓합니다. 리팩터링 전에 Instruments로 leak을 확인하세요. 직관이 아니라 데이터입니다.
문제를 격리하지 않기 — 전체 앱으로 테스트하면 진단이 복잡해집니다. 문제가 되는 기능만 담은 최소한의 재현 가능한 예제를 만드세요. 격리를 통해 근본 원인이 드러납니다.
