전에는 항상 스토리보드로 UI를 그렸는데, 어느 순간부터 다른 팀원들이 코드로 UI를 그리길래 따라하다보니, 지금도 코드로 UI를 그리고 있다. 여러 조언을 들었을 때, 코드로 진행을 하는 것이 더 좋다고 했지만 장단점을 명확하게 해보고 싶었다.
스토리보드는 처음 Xcode에서 프로젝트를 진행할 때, UI를 그려보는 그래픽 인터페이스 빌더이다. 이 스토리보드의 장단점을 한 번 알아보자.
시각적 디자인: 개발자는 컴포넌트를 드래그 앤 드롭하여 사용자 인터페이스를 구성할 수 있다. 이는 코드를 직접 작성하는 것보다 직관적이고 빠를 수 있다.
통합된 화면 전환: 뷰 컨트롤러 간의 세그웨이를 통해 화면 전환을 쉽게 구현할 수 있다. 개발자는 화면 전환의 시각적 흐름을 쉽게 파악하고 관리할 수 있다.
오토레이아웃의 용이성: 스토리보드는 오토레이아웃을 사용하여 다양한 화면 크기와 방향에 맞게 인터페이스를 쉽게 조정할 수 있도록 도와준다.
즉각적인 피드백: 사용자 인터페이스의 변경사항을 즉시 시각적으로 확인할 수 있다. 이는 디자인 수정 과정을 신속하게 만들어준다.
손쉬운 속성 접근: 컴포넌트에는 많은 속성이 있는데, 이런 속성을 직관적이고 쉽게 설정을 할 수 있다.
소스 컨트롤의 복잡성: 스토리보드 파일은 XML 형식으로 저장된다. 여러 개발자가 동시에 같은 스토리보드 파일을 수정하면 병합 충돌이 발생하기 쉽다. 이런 이유로 현업에서는 스토리보드를 잘 사용하지 않는것으로 알고있다.
컴파일 시간 증가: 큰 스토리보드 파일은 프로젝트의 컴파일 시간을 증가시킬 수 있다. 경험상 8개 이상이 되면 급격하게 오래걸린다.
런타임 에러: 스토리보드에서 설정한 아웃렛(outlet)이나 액션(action)이 코드에서 제거되었을 때, 컴파일 타임에 에러가 발생하지 않고 런타임에 에러가 발생할 수 있다.
동적인 UI 구현의 어려움: 스토리보드는 정적인 인터페이스 설계에 적합하다. 동적으로 뷰를 생성하거나 수정해야 하는 경우 코드를 사용하는 것이 더 적합할 수 있습니다.
스토리보드는 시각적인 디자인이 강조되고 화면 전환의 흐름이 중요한 프로젝트에 적합할 수 있다. 그러나 대규모 팀이나 복잡한 동적 인터페이스를 구현해야 하는 프로젝트에서는 코드 기반의 접근 방식을 고려하는 것이 좋다.
그렇다면 코드로 UI를 그렸을 때 장단점은 무엇일까.
버전 관리 용이: 인터페이스가 코드로 구현되어 있으면 소스 컨트롤 시스템을 사용하여 변경사항을 더 쉽게 추적하고 관리할 수 있다. 코드 기반의 접근 방식은 병합 충돌을 줄이고, 코드 리뷰를 더 효과적으로 수행할 수 있게 한다.
동적인 UI 생성: 코드를 사용하면 실행 시간에 인터페이스를 동적으로 생성하고 수정하는 것이 훨씬 쉬워진다. 이는 사용자의 입력이나 앱의 상태에 따라 인터페이스를 유연하게 변경해야 할 때 유용하다.
재사용성과 모듈성: 커스텀 뷰나 컴포넌트를 만들 때, 코드를 사용하면 재사용성을 높이고 모듈성을 강화할 수 있다. 이러한 컴포넌트는 다른 프로젝트에서도 쉽게 사용할 수 있다.
정밀한 컨트롤: 코드를 사용하면 인터페이스의 모든 측면을 정밀하게 제어할 수 있다. 스토리보드의 그래픽 인터페이스에서는 할 수 없는 세밀한 조정이 가능하다.
시각적 피드백의 부족: 인터페이스를 코드로 작성하면 디자인의 변화를 즉시 볼 수 없다. 앱을 컴파일하고 실행해야만 변경사항을 확인할 수 있다. (이 부분을 해결하기 위해 SwiftUI의 기능을 사용하기도 한다)
개발 속도 저하: 특히 복잡하지 않은 인터페이스를 구현할 때, 코드를 작성하는 것이 스토리보드를 사용하는 것보다 시간이 더 걸릴 수 있다.
코드의 복잡성 증가: 인터페이스 로직이 애플리케이션의 나머지 코드와 섞이게 되면, 코드의 복잡성이 증가하고 유지 관리가 더 어려워질 수 있다.
사용자 인터페이스를 코드로 구현하는 것은 유연성과 재사용성이 중요하고, 동적인 UI 요소가 필요한 프로젝트에 적합할 수 있다. 그러나 시각적 피드백의 부족과 개발 속도 저하는 고려해야 할 단점이다.