동작을 바꾸지 않고 화면 하나 리팩터링하기

이 사용 사례는 SwiftUI 파일이 거대한 화면 하나로 커져 사소한 수정조차 위험하게 느껴질 때를 위한 것입니다. 목표는 기능을 다시 설계하거나 새 아키텍처를 만들어 내는 것이 아닙니다. Codex에 동작과 레이아웃을 유지하면서 화면을 명시적인 데이터 플로우를 갖춘 작은 서브뷰로 나누도록 요청하면 다음 변경 사항을 더 쉽게 검토할 수 있습니다.

이런 코드 정리에는 Build iOS Apps 플러그인을 사용하세요. 이 플러그인의 SwiftUI 뷰 리팩터링 스킬은 실용적이고 분명한 원칙을 제시합니다. MVVM 대신 MV를 기본으로 사용하고, 비즈니스 로직은 서비스나 모델에 두며, 로컬 뷰 상태와 환경 종속성을 먼저 활용하고, 기능에 분명히 필요한 경우에만 뷰 모델을 유지합니다.

Codex에 요청할 작업

먼저 구체적인 화면 파일 하나를 지정한 다음, 구조를 개선하되 동작은 유지하도록 Codex에 요청하세요. 다음 리팩터링 규칙은 프롬프트에 직접 넣는 것이 좋습니다:

• 환경 종속성, 저장 프로퍼티, 뷰와 무관한 계산 상태, init, body, 뷰 헬퍼, 헬퍼 메서드 순으로 배치해 위에서 아래로 쉽게 훑어볼 수 있도록 파일을 재정렬하세요.
• 의미 있는 섹션을 작고 명시적인 입력, @Binding, 콜백을 받는 전용 View 타입으로 추출하세요.
• 계산형 some View 헬퍼는 드물게 사용하고 작게 유지하세요. 하나의 거대한 화면을 private 계산형 뷰 조각을 길게 나열하는 방식으로 다시 만들지 마세요.
• 간단한 수준을 넘어서는 버튼 액션과 사이드 이펙트는 body 밖으로 옮기고, 실제 비즈니스 로직은 서비스나 모델로 옮기세요.
• 루트 뷰 트리를 안정적으로 유지하세요. 화면 전체를 바꾸는 최상위 if/else 분기보다 섹션이나 모디파이어 내부의 국소 조건문을 우선하세요.
• Observation의 소유권도 함께 바로잡으세요. iOS 17 이상에서 루트 @Observable 모델을 소유하는 뷰는 해당 모델을 @State에 저장해야 합니다. 레거시 observable 래퍼는 배포 대상 때문에 필요한 경우에만 사용하세요.

간단한 검증 루프 요청하기

동작 보존 리팩터링에는 검증 근거가 필요합니다. 의미 있는 섹션을 추출할 때마다 해당 화면을 실행해 보는 최소 범위의 빌드, 프리뷰, 테스트 또는 시뮬레이터 검사를 Codex에 요청하세요. 그런 다음 구조적으로 달라진 점과 의도적으로 그대로 둔 점을 요약하게 하세요.

실용적인 팁

먼저 분리하고 아키텍처는 나중에 논의하기

화면이 너무 크다면 새 추상화 레이어를 도입하기 전에 Codex에 섹션 뷰 추출을 요청하세요. 더 짧고 명시적인 뷰 트리를 만들면 뷰 모델을 추가할 필요 자체가 사라지는 경우가 많습니다.

각 서브뷰에는 가능한 한 최소한의 인터페이스만 전달하기

모든 자식 뷰에 부모 모델 전체를 넘기기보다 let 값, @Binding, 단일 목적 콜백을 사용하세요. 그러면 추출한 각 섹션을 더 쉽게 프리뷰할 수 있고, 화면 전체와 의도치 않게 다시 결합될 가능성도 줄어듭니다.

의도적으로 바꾸지 않은 사항도 명시하도록 Codex에 요청하기

안전한 리팩터링에서는 Codex가 비즈니스 규칙, 내비게이션 동작, 영속성, 애널리틱스 의미 체계, 사용자에게 보이는 레이아웃 등 변경하지 않은 사항을 명시적으로 나열하면 도움이 됩니다. 이렇게 하면 검토가 훨씬 빨라집니다.