안녕하세요, 저는 iOS 리드를 맡고 있는 와니입니다. 

iOS팀은 3명의 열정적인 개발자로 구성되어 있고, 중고차 시장에서 혁신을 이끌고 있는 헤이딜러 앱 개발을 맡고 있습니다. 저희 팀은 지속적인 성장과 도전을 추구하며, 각자의 발전이 팀의 발전으로 이어진다고 믿고 있습니다. 이를 위해 북리뷰, 10분 컷, 회고 등 다양한 활동을 진행하고 있어요.

우리 팀은 문제를 임시방편으로 넘기는 걸 별로 좋아하지 않아요. 구멍 난 배에 테이프를 붙이면 물이 새는 걸 잠깐 막을 수는 있겠지만, 결국엔 더 큰 문제가 될 수 있잖아요? 그래서 꼭 문제의 뿌리를 찾아 제대로 해결하려고 해요. 이런 접근 방식으로 인해 처음엔 시간이 더 걸릴 수 있지만, 결과적으로 보다 안정적이고, 나중에 수정할 때도 훨씬 수월합니다.

코드를 작성할 때도 비슷해요. 저희는 그냥 잘 작동하는 코드를 넘어서, 코드 하나 하나에 의도와 이유가 드러나야 한다고 생각해요. 그래서 팀원 모두가 '좋은 코드'가 무엇인지 명확히 이해하고, 같은 방향을 향해 나아가도록 노력하고 있습니다. 

개인 취향보다는 팀이 추구하는 이상적인 코드 기준을 만들고 맞춰 나가는 걸 중요시합니다. 서로 지속적으로 피드백을 주고받으면서 적합한 방향성이 무엇인가를 논의하는 과정이 우리 팀을 더 단단하게 만들어 줘요. 이런 접근 방식은 저희 팀 핵심 철학이며, 우리가 만드는 제품 품질 향상에도 결정적인 역할을 하고 있습니다.

iOS 13부터 SwiftUI를 도입한 게 기억남습니다.

당시에는 SwiftUI에 대한 자료도 별로 없고, 프레임워크 자체에 버그도 많아서 정말 힘들었어요. 물론 익숙한 UIKit으로 계속 개발하는 게 당장은 편했지만, 장기적인 생산성을 고려해서 SwiftUI를 선택했습니다. 앞으로 모든 프로젝트를 SwiftUI로 바꿔야 할 때가 올 거라고 생각했거든요. 프로젝트를 시작하기 전에, 시간이 오래 걸리더라도 방향을 제대로 잡는 게 중요하다고 판단했습니다.

먼저, 레고 블록처럼 조립할 수 있는 디자인 시스템을 만드는 데 시간을 많이 썼습니다. SwiftUI와 UIKit에 둘 다 적용할 수 있는 디자인 시스템이 필요하다고 생각했기 때문에, 작은 단위의 컴포넌트부터 시작해서 디자인팀이 정한 전체 디자인 시스템을 공통 라이브러리에 구현했고, 덕분에 개발 속도가 훨씬 빨라졌어요. 
SwiftUI에서 지원하지 않는 UIKit 기능들을 어떻게 구현할지도 큰 고민거리였는데요. 이 문제를 해결하기 위해 'SwiftUI 코드도 결국 UIKit 코드를 이용해 만들었다'라는 관점으로 접근했습니다. 고민이 많았던 대표적인 기능은 화면 전환 기능이에요. Panmodal, Hero 등 UIKit에는 이미 검증된 오픈소스들이 많이 있는데, SwiftUI로만 작업하려고 하면 오히려 더 큰 비용과 버그가 생길 수도 있다고 생각했어요. 그래서 UIKit과 함께 가는 방향을 선택했고, SwiftUI에서 작성해도 어색하지 않도록 비슷한 인터페이스를 만들어서 개발했습니다.
동시에 오픈 소스처럼 확장성 있게 만들려면 어떻게 해야 할지도 많이 고민했어요. 현재 상황에만 들어맞는 기능보다는, 여러 상황에 대응할 수 있는 유연한 기능을 만들고 싶었거든요. 작업 속도가 다소 느려지기도 했지만, 결과적으로 새로운 요구사항에 쉽게 대응할 수 있게 됐습니다. 

iOS팀은 지금도 계속 코드를 개선하고 더 나은 방식을 찾아 적용하고 있어요. 이런 노력들이 팀의 생산성을 높이는 데 큰 도움이 됐고, 각자에게도 정말 의미있는 성장 기회가 됐어요.