동작을 유지하면서 화면 하나 리팩터링하기

하나의 SwiftUI 파일에 화면 전체의 코드가 쌓여 작은 수정조차 부담스러울 때 이 방법을 활용하세요. 기능을 재설계하거나 새로운 아키텍처를 도입할 필요는 없습니다. Codex에 기존 동작과 레이아웃을 유지하면서 화면을 작은 하위 뷰로 나누고 데이터 플로우를 명확히 드러내 달라고 요청하세요. 그러면 다음 변경 사항을 더 쉽게 검토할 수 있습니다.

이런 작업에는 Build iOS Apps 플러그인을 사용하세요. 이 플러그인의 SwiftUI 뷰 리팩터링 스킬은 MVVM보다 MV를 기본으로 삼고, 비즈니스 로직은 서비스나 모델에 둡니다. 뷰의 로컬 상태와 환경 종속성을 우선 활용하고, 기능에 뷰 모델이 꼭 필요한 경우에만 유지합니다.

Codex에 요청할 작업

먼저 리팩터링할 화면 파일 하나를 지정하고, 기존 동작을 유지하면서 코드 구조를 개선해 달라고 요청하세요. 프롬프트에 다음 규칙을 직접 포함하세요.

• 파일을 위에서 아래로 훑어보기 쉽도록 환경 종속성, 저장 프로퍼티, 뷰 이외의 상태를 계산하는 프로퍼티, init, body, 뷰 헬퍼, 헬퍼 메서드 순으로 정리하세요.
• 역할이 뚜렷한 섹션은 별도의 View 타입으로 분리하고, 필요한 입력값과 @Binding, 콜백만 명시적으로 전달하세요.
• some View를 반환하는 연산 프로퍼티는 꼭 필요할 때만 짧게 작성하세요. 큰 화면 하나를 여러 조각으로 나눠 비공개 연산 프로퍼티로 길게 나열하는 방식은 피하세요.
• 복잡한 버튼 액션과 사이드 이펙트는 body 밖으로 옮기고, 실제 비즈니스 로직은 서비스나 모델로 옮기세요.
• 루트 뷰 트리의 구조를 안정적으로 유지하세요. 최상위 if/else 분기로 화면 전체를 교체하기보다 섹션 안에서 조건을 처리하거나 수정자에 조건을 적용하세요.
• 리팩터링하면서 Observation 모델의 소유 관계도 바로잡으세요. iOS 17 이상에서는 루트 @Observable 모델을 소유한 뷰가 해당 모델을 @State에 저장해야 합니다. 기존 방식의 관찰용 래퍼는 배포 대상 버전에서 필요한 경우에만 사용하세요.

작은 단위로 검증 요청하기

리팩터링 후에도 화면이 이전처럼 동작하는지 확인해야 합니다. Codex에 섹션 하나를 분리할 때마다 빌드, 미리보기, 테스트, 시뮬레이터 실행 중 해당 화면을 확인할 수 있는 가장 간단한 방법으로 검증해 달라고 요청하세요. 그런 다음 구조상 달라진 부분과 의도적으로 유지한 부분을 요약해 달라고 하세요.

실무 팁

먼저 화면을 나눈 뒤 아키텍처 검토하기

화면이 너무 크다면 새로운 추상화 계층을 도입하기 전에 Codex에 각 섹션을 별도의 뷰로 분리해 달라고 요청하세요. 뷰 트리가 짧아지고 구조가 명확해지면 뷰 모델을 추가할 필요가 없어지는 경우가 많습니다.

각 하위 뷰에 꼭 필요한 인터페이스만 전달하기

모든 하위 뷰에 부모 모델 전체를 넘기기보다 필요한 let 값과 @Binding, 한 가지 작업만 수행하는 콜백을 전달하세요. 그러면 분리한 섹션을 개별적으로 미리 보기 쉽고, 의도치 않게 화면 전체에 다시 종속될 가능성도 줄어듭니다.

Codex에 의도적으로 유지한 항목을 명시해 달라고 요청하기

안전하게 리팩터링하려면 Codex에 비즈니스 규칙, 탐색 동작, 데이터 영속성, 분석 이벤트의 의미, 사용자에게 보이는 레이아웃 등 그대로 유지한 항목을 명시해 달라고 하세요. 그러면 변경 사항을 훨씬 빠르게 검토할 수 있습니다.