Xcode Storyboard, 약인가 독인가

스토리보드도 Xcode 4 버전에 들어서 새롭게 지원되기 시작한 개발 도구이다. 뷰 디자인과 흐름을 시각화 시켜서 직관적인 개발이 가능하게 도와준다는 점에서 편하게 개발 할 수 있다. 이 글은 이 스토리보드에 관한 감상 일 뿐이지 상세한 설명을 위한 글이 아님을 먼저 밝힌다.

제목이 '약이냐 독이냐' 라고 지었다면 역시 결론은 나온다. 잘 쓰면 약이고 못 쓰면 독이다. 다만 잘 써야 한다는 것은 잘 사용해야 한다는 의미가 아니라 용도에 맞게 사용해야 한다는 점이다.

스토리보드의 간략한 개념

스토리보드

쉽게 스크린샷으로 표현하자면 이렇다.

한 눈에 알 수 있다. 처음 시작되는 뷰 컨트롤러, 특수한 뷰컨트롤러(여기서는 탭바컨트롤러)의 부속품의 정의, 그리고 그 뷰에서 이어지는 뷰 컨트롤러를 화살표로 연결하는 형식으로 UI를 개발하는 도구이다.

물론 각 연결 부위가 직접적으로 연결 표시를 해 주는 건 아니고 단지 뷰의 소속이나 전환 순서는 확실하게 파악 할 수 있다.

세그웨이(Segueway)

스토리보드에서 세그(Segue)라는 단어는 굉장히 중요하다. 세그웨이의 약자인 세그는 UI의 전환을 표현하는 방법을 의미한다.

세그웨이는 위 스크린샷에서 뷰와 뷰 사이를 연결하는 화살표를 의미힌다. 이 화살표는 뷰의 연결 흐름(방향)과 연결 방법(화면에 표시되는 방법)을 정의하고 있다.

각 세그는 기본 뷰 컨트롤러의 지원 방식에 따라 전환 방법을 다양하게 정의 할 수 있다. 예를 들어 UINavigationController에서 연결되는 세그는 Push 가 있다. 물론 ModalViewController 형태로 전환하는 것도 얼마든지 가능하다.

이건 편하더라

단순한 UI를 가지는 앱

스토리보드로 UI를 만들게 되면 앱의 작동 구조를 시각화 할 수 있다. 일정 수준의 디자인도 가능하여 디자이너와 함께 혹은 디자이너나 기획자가 직접 앱을 디자인 할 수 있는 수준이다.

하지만 그렇다고 동적(Dynamic or Runtime)인 구현까지 쉽게 가능한 건 아니다. 이런 부분은 프로그래머의 코딩이 필요하다.

따라서 동적인 변화가 별로 없는 단순한 앱을 만들 때는 최고의 도구가 될 수 있다.

테이블 셀

테이블(UITableView)에 올릴 셀(UITableViewCell)을 커스텀 할 때 스토리보드는 굉장히 편한 방법을 제공한다. 다만 이 커스텀 셀을 구현하는 건 코드 구현도 함께 이루어져야 하기에 스토리보드만으로 만든다고 표현하기는 힘들다.

고정 셀(Static Cell) 형식도 기존에는 잘 보기 힘들었던, 즉 스토리보드에서 제공되는 새로운 테이블 구성 방법이기도 하다. 대신 고정셀을 이용하게 되면 기존에 사용하던 UITableViewDataSource 형식을 쓸 수 없게 된다.

이건 불편하더라

코드와 세그웨이의 비직관성

프로그래머는 코드에서 모든 것을 표현하고 읽는다. 세그의 존재는 이 코드의 많은 부분을 생략시켜 버리게 된다. 코드를 줄여주는 것은 좋지만 표현까지 생략시켜 버리는 건 간혹 안좋은 영향을 끼치기도 한다.

물론 performSegueWithIdentifier 라는 걸 사용하게 된다면 어느 정도 직관적인 코드 표현이 가능해진다. 하지만 이걸 이용한다면 스토리보드에서 오히려 이해하지 못 할 그림을 그려야 할 지도 모른다.

뷰 사이에 데이터 전송에서도 스토리보드 만으로 표현 못 하는 부분은 코드로 표현해야 한다. 대표적인 것이 prepareForSegue 라는 오버라이딩 용 메서드이다. 이 메서드는 뷰를 전환하기 위해 세그웨이를 호출 했을 때 실제 뷰가 로딩되기 전에 거치는 메서드이다. 그런데 필수적으로 구현해야 할 메서드는 아니기 때문에 전환 시 어떠한 데이터가 뷰로 넘어가는지 파악하려면 결국 찾아봐야 한다.

뷰 전환 시 prepareForSegue 뿐만이 아니라 뷰 컨트롤러에 내장된 storyboard 인스턴스를 통해 ViewController Identifier를 이용한 뷰 컨트롤러 인스턴트 생성 및 찾기 기능(instantiateViewControllerWithIdentifier)을 활용 할 수도 있다. 하지만 이건 새롭게 만들어 지는 것인지 아니면 기존에 떠 있는 뷰를 찾는 건지 애매모호 할 때도 있다.

눈에 보이는 것 만이 전체가 아닐 때

UI를 어떻게 기획하느냐에 따라 스토리보드로는 개발하기 어려운 경우도 있다. 예를 들자면 하나의 뷰 컨트롤러 내부에 다수의 서브 뷰가 있을 경우. 특히 서브 뷰가 모두 항상 보이는 경우가 아닌 경우이다.

대표적으로 예를 들자면 스크롤뷰(UIScrollView)를 만들고 여기에 올릴 큰 서브뷰(Sub View)를 만들 경우를 생각해보자. 스토리보드의 경우 서브뷰를 별도로 생성할 수 없다. 무조건 메인 뷰에 붙여야 한다. 따라서 화면 보다 큰 서브뷰를 만드려면 수작업으로 서브뷰의 위치를 옮겨가며 화면에 표시될 부분을 실제로 스토리보드 상에서 보이게 한 후 뷰를 편집해야 한다.

스크롤뷰 안에 넣을 뷰를 별도의 뷰 컨트롤러로 분리해서 개발하는 것도 물론 생각해 볼 수는 있다. 단지 나는 이렇게 동일한 분류가 되어야 할 모듈을 분리해 버리는 디자인은 그다지 선호하지 않을 뿐이다.

무겁고 느리다

스토리보드는 기존의 XIB로 분리되어 있는 UI 구현부분을 하나의 화면에서 구현하도록 설계되었다. 다시 말해 많은 UI 요소를 한 화면에 불러들여야 하니 로딩에 느리다. 더구나 많은 UI가 한 화면에 표시되니 그 만큼 편집도 느리다. 시스템 사양이 안좋다면 좀 답답할 것이다. 안그래도 Xcode4는 3버전에 비해 많이 무겁고 느린데 말이다.

많은 요소가 한 화면에 표시된다는 건 그 만큼 어떤 UI를 찾을 때 시간이 걸리게 된다. 축소시켜 버리면 이게 어떤 화면인기 분간하기 힘들 때도 있다.

스토리보드의 좌측에는 스토리보드에 실려있는 모든 뷰 컨트롤러의 리스트가 나타나는데 여기서 원하는 뷰를 찾는 것도 힘들다. 많고 느리기 때문이다.

모든 UI를 하나의 스토리보드에 담기 때문에, 만약 하나의 뷰 컨트롤러에 관련된 부분을 고치게 되면 전체 UI의 컴파일(Compile)이 발생하게 된다. 기존의 하나하나 XIB를 컴파일 하던 때를 생각하면 확실히 수정 내용에 비해 빌드 과정이 느리다.

그리고 좁다

스토리보드는 화면을 너무 많이 차지하는 도구이다. 27인치 모니터에서 조차 아이패드용 뷰 하나만 풀로 표시해 버리면 다른 UI를 표시할 공간이 없을 정도이다. 물론 그래서 화면의 확대/축소 기능을 지원하고 있지만 상황에 따라 굉장히 불편하다. 따라서 노트북 등의 작은 화면에서는 스토리보드를 이용하기 굉장히 껄끄러울 것이다.

... 이런 식의 화면을 13인치 노트북으로 처음 봤을 때의 답답함은 절망 수준이었다 ...

스토리보드 적용 추천

정적인 컨텐츠를 구현하는 경우 스토리보드는 굉장히 편리하다. 대표적인 예를 들자면 앱진(Appzine) 형식이 있다.

잡지(Magazine)를 앱(App) 형태로 발간하는 앱진의 경우 스토리보드는 최고의 개발 도구이다. 책자 등 사진과 문구로 컨텐츠가 구성되어 있고 동적인 흐름은 없으며 정적인 목차나 하이퍼링크 등으로만 동작하기 때문에 사실상 코드 구현이 거의 없다고 봐도 된다.

이런 런타임으로 동적인 컨텐츠 표시나 다이나믹한 뷰 전환이 필요 없는 앱은 스토리보드로 개발하기를 추천하지만 그렇지 않다면 전통적인 인터페이스 빌더를 이용한 개발이 차라리 편할 때도 많다.


...


안좋은 이야기를 많이 한 것 같은데, 스토리보드와 ARC를 섞어서 활용한다면 간단한 앱은 정말 코드 몇 줄 안만들고도 개발이 가능한 멋진 도구임에는 틀림이 없다. 단지 만능도구는 아니라는 점을 잘 이해해야 한다.