고생하며 배운 교훈: 앱의 완성도를 높이고 싶다면 SwiftUI를 사용하지 마세요. 적어도 AI로 코딩할 때는 말이죠.

고생하며 배운 교훈: 앱이 놀라운 외관과 느낌을 갖길 원한다면 SwiftUI를 사용하지 마세요. 적어도 AI와 함께 코딩할 때는 말이죠. (이 글을 읽고 계신 Apple 동료분들께는 죄송합니다 😅)

제가 이 칼로리 추적기(calorie tracker)를 '바이브 코딩(vibe coding)'하며 겪은 과정을 공유합니다. 영상 속의 부드러운 전환(fluid transition)에 대해 질문을 많이 받았는데요, 전체 이야기를 들려드릴게요.

처음에는 Claude가 SwiftUI를 사용하여 그리드(grid)를 구축했습니다. 빠르고 쉬웠으며 보기에도 좋았습니다! 하지만 데이 뷰(day view)로의 전환은 지루한 네비게이션 푸시/팝(navigation push/pop) 방식이었습니다. 재미가 없었죠. 저는 뭔가 커스텀(custom)한 것을 원했습니다.

저는 Claude에게 음식 타일(food tiles)을 소스 위치에서 목적지 위치로 재매핑하는 부드러운 전환을 만들어 달라고 요청했습니다. 그러자 모든 것이 엉망이 되었습니다.

Claude는 여러 가지 끔찍한 시도들을 했습니다. 처음에는 매치드 지오메트리 이펙트(matched geometry effects)를 사용했는데, 작동은 괜찮았지만 제스처 기반 애니메이션(gesture-driven animations)에는 적합하지 않았습니다. 그래서 SwiftUI의 프리퍼런스 키(preference keys)와 지오메트리 리더(geometry readers)를 사용하여 소스 및 목적지 위치를 파악하고, 제스처 진행 상황에 따라 보간된 위치(interpolated position)를 계산하여 그리드와 데이 뷰 간의 조율을 시도했습니다. 하지만 이는 네이티브 SwiftUI 그리드 내부에서 타일의 위치를 재설정할 수 없었기 때문에 커스텀 레이아웃(custom layout)을 직접 작성해야 함을 의미했습니다. 또한 뷰 사이에서 어색한 핸드오프(handoff)를 수행해야 했는데, 이는 항상 보기 싫은 팝(pops)이나 점프(jumps) 현상을 만들어냈습니다. 바운시 스프링(bouncy spring) 효과를 넣으려고 시도한 것은 말도 꺼내지 마세요. 수학적 계산을 10배는 더 버그투성이로 만들 뿐이었습니다.

다행히 Claude Fable은 이것이 재앙이 되어가고 있다는 것을 알아차릴 만큼(그리고 시뮬레이터에서 대부분의 문제를 스스로 발견할 만큼) 영리했기에, SwiftUI에서 벗어나 방향을 전환했습니다. Opus는 그렇게 현명하지 못할 수도 있으니, 여러분이 주의를 기울이고 개입해야 합니다.

결국, 순수 UIKit으로 다시 작성했고 모든 것이 훌륭하게 풀렸습니다. 그 후, 우리는 2D 이미지에서 3D 에셋(3D assets)으로 넘어갔고, 이는 새로운 성능 과제들을 불러왔으며, 결국 아래에서 볼 수 있는 단일 Metal 레이어(single Metal layer)로의 또 다른 재작성을 불러왔습니다. 혹시 관심 있는 분이 계신다면 2D에서 3D로 넘어가는 대서사시에 대해 더 자세히 써보겠습니다.

만약 제가 다시 할 수 있다면, 첫 번째 프롬프트부터 그냥 "SwiftUI를 사용하지 마세요"라고 말해서 몇 시간 동안의 골칫거리를 줄였을 것입니다. SwiftUI는 코드에서 직접 반복 작업을 수행하는 인간에게는 놀라울 수 있습니다. 하지만 에이전트(agents)는 SwiftUI의 그 어떤 장점으로부터도 이득을 얻지 못합니다. 게다가 에이전트들은 수십 년간의 UIKit 학습 데이터(training data)를 보아왔기 때문에, UIKit을 작성하는 데 매우 능숙하며 훨씬 더 유연합니다.

앞으로 SwiftUI가 에이전트 친화적인 방식으로 더 많이 개선되기를 바랍니다. 그때까지 저는 아마 SwiftUI를 피하게 될 것 같습니다.