RocketSim과 RocketTrace로 구현하는 에이전트 기반 iOS 개발

핵심 요약

1. RocketSim은 에이전트가 시뮬레이터에서 앱을 탐색하고 접근성 트리와 화면을 확인하게 하며, RocketTrace는 Xcode Instruments 기록에서 성능 문제를 추려 근거와 함께 제공한다.
2. 접근성 감사에서는 141개 요소를 검사한 홈 화면이 0점에서 99점으로 개선됐고, Amplitude 분석 결과를 바탕으로 첫 영상 압축을 돕는 TipKit 안내를 구현했다.
3. 네 가지 작업 모두 Plan mode에서 근거와 수정 계획을 먼저 검토한다. 성능 분석에서 확인되지 않은 화면의 문제는 추측해 수정하지 않고 추가 기록을 계획했다.

도입

코딩 에이전트가 코드만 읽으면 앱의 실제 동작을 검증할 수 없다. 이 글은 Cursor와 RocketSim, RocketTrace를 활용해 에이전트가 시뮬레이터에서 화면을 탐색하고 접근성을 검사하며 성능을 측정하는 작업 흐름을 소개한다. 접근성 감사, 분석 데이터 기반 TipKit 안내, App Store 스크린샷 갱신, 탐색 중 성능 분석의 네 가지 프롬프트를 실제 앱에 적용했다.

상세 요약

에이전트가 앱을 직접 검증하는 도구

코드만 읽는 에이전트는 앱이 실제로 올바르게 동작하는지 확인하지 못한다. RocketSim은 시뮬레이터에서 화면을 읽고 탭·스와이프·텍스트 입력을 수행하며, 접근성 감사와 기기 프레임이 포함된 스크린샷 캡처도 지원한다. RocketTrace는 Xcode Instruments 기록을 분석해 원시 .trace 패키지 대신 우선순위가 매겨진 발견 사항을 반환한다. 두 도구 모두 Agent Skill을 제공하며, 프롬프트에서 /rocketsim 또는 /rockettrace로 호출한다.

1. 전체 화면 접근성 감사

에이전트는 화면마다 접근성 트리를 읽고 감사 결과와 수정 제안을 만든다. Video Compressor의 홈 화면은 141개 요소 검사에서 처음에 0/100점, 오류 2개와 경고 29개를 받았다. 수정 작업을 거친 뒤에는 99/100점, 경고 4개로 바뀌었다.

가장 흔한 항목은 hit_region_small이었다. 상호작용 요소의 크기가 28×28포인트보다 작으면 오류이며, 권장 크기인 44×44포인트보다 작으면 경고다. 작성자는 에이전트가 코드를 고치기 전에 계획을 검토해 탭 가능한 영역만 넓히고 레이아웃은 옮기거나 줄이지 않는지 확인한다.

2. 분석 데이터로 TipKit 안내 결정

Amplitude MCP를 이용해 기기 안에 영상이 하나 이상 있는 최근 사용자 57명을 확인했다. 이 중 35명(61%)은 영상 압축에 성공했고, 22명은 압축하지 않았다. 이 결과에 따라 에이전트는 새 기능을 추가하는 대신 첫 압축을 돕는 TipKit 안내를 구현했다.

각 안내는 특정 조건에서만 나타나므로, 앱을 한 번 실행하는 것만으로는 확인하기 어렵다. 에이전트가 RocketSim으로 안내가 보이는 상태까지 이동해 각각의 스크린샷을 캡처하도록 요청했다. 작성자는 이를 pull request에서 시각적으로 검토한다.

3. App Store 스크린샷 갱신

이 작업은 RocketSim, Sketch MCP, Helm CLI를 연결한다. RocketSim으로 기기 프레임이 포함된 화면을 캡처하고, Sketch MCP로 디자인 파일을 갱신한다. /helm-asc와 Helm CLI는 내보내기와 App Store Connect 업로드를 처리한다. 영어 로캘용 디자인을 만든 뒤 나머지 18개 로캘로 복제했다.

4. 탐색 중 성능 문제 측정

RocketSim이 사용자처럼 앱을 탐색하는 동안 RocketTrace가 성능을 기록한다. Release 빌드에서 51.8초 동안 측정한 결과 hitch 178건과 hang·stall 관련 발견 19건이 나왔다. hitch 구간의 85%에서는 Core Animation 레이아웃 작업이 원인으로 확인됐다.

에이전트는 결과 요약, 간략한 발견 목록, 개별 항목의 상세 정보 순서로 확인했다. 계획 승인 뒤 별도 브랜치에서 세 가지를 수정했다.

• 홈 화면에서 PhotoLibraryService 접근과 VideoAsset 값 복사가 결합해 발생한 198ms stall.
• 영상마다 main actor에서 수행하던 PhotoKit 작업을 묶음 단위로 availability를 가져오도록 변경.
• 스크롤 중 이미지 상태를 초기화했을 가능성이 있는 썸네일 ID 중복 기록 319건.

반면 178개 hitch 중 102개는 알 수 없는 화면에서 발생했다. 원인을 확인할 증거가 부족해 바로 수정하지 않고 OSSignposter 구간을 추가해 다시 기록하는 계획을 세웠다. 수정 후 기기에서 재기록하지는 않았으며, 새 기록과 기존 기록을 RocketTrace로 비교하는 단계가 남아 있다. SwiftUI 성능 측정의 다른 사례는 Xcode Instruments에서 SwiftUI 뷰 다시 그리기와 원인 추적하기에서 확인할 수 있다.

모든 작업에서 Plan mode를 쓰는 이유

네 가지 프롬프트는 Plan mode에서 시작하거나 계획을 먼저 요구한다. 에이전트가 제시한 감사 점수, 사용자 분석, 스크린샷, 성능 발견 사항을 코드 변경 전에 검토한다. 접근성 수정이 레이아웃을 바꾸거나 성능 수정이 잘못된 함수를 겨냥하는 문제를 계획 단계에서 확인할 수 있다. 근거가 부족하면 추측으로 수정하지 않고 추가 측정을 계획한다.

결론

이 워크플로의 핵심은 에이전트가 작업 결과를 직접 검증하도록 하고, 코드 수정 전에 계획을 사람이 확인하는 것이다. 감사 점수와 분석 수치, 스크린샷, 성능 기록을 수정 근거로 삼는다. 성능 원인을 확인하지 못한 항목은 바로 고치지 않고 추가 측정을 계획했으며, 적용 후에는 새 기록을 만들어 이전 결과와 비교할 예정이다.