어느덧 아이폰이 우리나라에서 공식 출시된 지 지난 11월 말로 만 2년이 지났습니다. 아이폰이 국내 출시된 이후로 우리나라에는 천지개벽할 정도는 아니어도 참 많은 변화가 일어났습니다. 이는 전 세계 동시대적으로 일어난 사건은 아니었고, IT 강국이라 불리우는 나라로서는 사실 많이 뒤늦은 경험이었지요.

아이폰이라는 애플의 모바일 기기가 불러온 것 중 하나는 앱스토어를 통한 애플리케이션 개발과 출시를 들 수 있겠습니다. 기업이든 개인이든 누구나 애플 개발자 프로그램에 등록하고 만든 앱을 자유롭게 올림으로써 스스로 퍼블리셔의 역할까지 할 수 있게 된 것이죠. 물론 한편에서는 극단의 폐쇄성이라고 일컬어지는 애플이라는 큰 울타리 안에서 가능한 일이었지만 말입니다.

맥 컴퓨터, 오브젝티브C, 아이폰OS SDK 등 당시만 해도 흔히 접하기도 갖추기도 어려운 이런 낯선 환경 속에서도 애플의 아이폰 개발에 관한 열기가 뜨거울 수밖에 없었던 것은 어쩌면 애플에서 제공하는 엑스코드(Xcode)와 인터페이스 빌더(Interface Builder)라는 마당이 잘 갖춰졌기 때문인지도 모릅니다.

아이폰 SDK 베타 2 버전부터 제공된 아이폰용 인터페이스 빌더는 GUI도구를 써서 애플리케이션의 UI를 쉽게 제작할 수 있는 아주 유용한 툴입니다. 윈도우와 뷰, 뷰를 구성하는 요소를 배치하고 속성을 손쉽게 편집하는 기능을 제공하죠. 인터페이스 빌더의 역사는 1980년대 후반 넥스트스텝(NextSTEP) 시절로부터 거슬러 올라갑니다. 위키피디어에 따르면 팀 버너스 리가 넥스트 워크스테이션을 이용해 월드와이드웹을 개발할 때 쓰인 툴 중 하나가 바로 인터페이스 빌더였다고 하지요. 모두가 잘 아시다시피 인터페이스 빌더는 엑스코드4가 출시되면서 통합됐습니다.

손쉬운 인터페이스 빌더, 그러나 코드의 라이프사이클은? 유지보수는?

1990년대 후반에서 2000년대 초반 인터넷 붐과 함께 웹사이트 제작이 열풍이었습니다. 드림위버, 나모웹에디터, 손쉽게 메뉴를 딸깍딸깍 누르는 것만으로도 홈페이지를 뚝딱뚝딱 만드는 기능을 제공하면서 너도나도 홈페이지를 만들어 사이버 집을 꾸리는 게 유행이었죠. 지금 생각하면 얼마 되지 않은 시기인데 마치 강산은 열 번은 변한 느낌이 드네요.

이렇듯 간단한 웹 제작 도구로 만든 사이트, 막상 코드를 열어 유지보수를 하려 하면 골칫덩어리 자체였습니다. 유지보수는커녕 코드를 해석하기도 힘들고, 어디서부터 어디까지 손을 대야 할지 모를 정도였죠. 물론 지금은 어도비는 드림위버만으로도 웹표준은 물론 향후 HTML5까지도 완벽히 대응할 수 있는 툴로 널리 활용시키겠다는 포부가 크다는 이야기도 들립니다.

이것이 개인 프로젝트가 아닌 기업 프로젝트라면 이야기는 달라집니다. 기업 홈페이지나 모바일 애플리케이션은 많은 인원의 협업도 일어나며 담당자 교체도 수시로 일어납니다. 소스코드의 라이프사이클도 짧지 않으며, 주석만으로도 코드의 정체성과 역할을 충분히 전달해야 합니다. 한눈에 파악해서 언제 어디서나 누가 수정을 하고 향후 개선작업을 하더라도 손쉽게 작업할 수 있어야 합니다.

견고한 클린 코드, 유용한 레거시 관리를 위하여
이제는 인터페이스 빌더에 대한 의존도를 낮춰야 한다!

그야말로 아이폰 애플리케이션 개발의 유용한 레거시 관리를 위해 이젠 과감히 인터페이스 빌더를 버려야 한다고 이 책의 저자들은 이야기 합니다.

잠시 저자의 말을 들어볼까요.

아이폰 개발은 맥에서 엑스코드(Xcode)로 개발하는데, 화면을 구성하는 인터페이스 빌더라는 개발 툴을 제공합니다. 인터페이스 빌더를 이용하면 개발이 좀 더 쉬워집니다. 각 객체에 대해 필요한 델리게이트나 뷰 템플릿 등을 제공해주므로 코딩 시간도 줄고, 객체의 다양한 속성도 속성 창에서 손쉽게 찾아 설정하고, 좌표를 일일이 계산하지 않아도 되죠. 하지만 2인 이상이 개발을 진행하는 협업 프로젝트에서는 인터페이스 빌더라는 툴이 오히려 방해가 되기도 합니다.

가장 큰 단점은 개발 소스의 가독성이 떨어진다는 점입니다. 유지 보수 측면에서 소스의 가독성이 떨어진다는 점은 치명적일 수밖에 없는 노릇이지요. 때문에 중대형 프로젝트에서는 인터페이스 빌더의 사용을 지양하고 일명 막코딩으로 구현하기를 권장합니다.

실례로 모 대기업의 애플리케이션을 개발할 당시 초기에는 인터페이스 빌더를 이용해 모든 화면을 구성했습니다. 하지만 초기에 기획하지 않았던 가로 모드에 대한 스펙이 추가되면서 문제가 드러나기 시작했습니다. 가로모드에 대한 부분을 고려하지 않고 개발했기 때문에 해당 스펙을 추가하기란 불가능했습니다. 때문에 무리를 해서라도 xib(인터페이스 빌더를 이용해 개발한 파일)를 모두 들어내고 코딩만으로 화면을 다시 개발했습니다. 결과적으로는 무진장 힘들었고 일정에 지연이 조금 있었지만, 이후 클라이언트의 새로운 요건을 수용하거나 유지 보수 측면에서는 아주 탁월한 선택이었습니다. 해당 기업에서는 저희들의 개발 방법론을 가이드로 작성해 이후 개발을 진행하는 업체들에 배포해 인터페이스 빌더 사용을 초기부터 배제합니다.

거의 모든 책과 예제들이 이 인터페이스 빌더를 이용한 개발 방법을 제시하고 설명합니다. 하지만 이 책에서는 인터페이스 빌더를 전혀 다루지 않습니다. 인터페이스 빌더를 이용해 개발하는 방법이 잘못된 방법이라고 말하고 싶지는 않습니다. 다만 코드만 보고 프로그램의 라이프 사이클을 읽을 수 없고 인터페이스 빌더를 왔다 갔다 해야 해서 여간 불편한 것이 아닙니다. 주석을 남길 수도 없지요.

우리는 유지 보수를 위해 담당자들에게 인수인계라는 어렵고도 귀찮은 작업을 해야만 하기에 알아보기 쉽게 코딩을 해야만 하는 의무가 있습니다. 최대한 많은 주석을 작성해 소스에 대한 가독성을 높여 프로그램에 대한 이해도를 높이는 것이 바람직하다 할 수 있습니다. 때문에 가능하다면 인터페이스 빌더를 이용하지 않고 개발을 진행해 많은 주석을 남겨야 할 필요가 있는 것이죠.

- 대표저자 박지성 / 저자의 말 중에서

이만하면 이 책의 집필 의도는 충분히 전달되지 않았을까 싶습니다. 인터페이스 빌더는 충분히 유용한 개발도구이며, 예쁜 UI를 매우 빠르고 손쉽게 만드는 데는 더할 나위없는 도구입니다. 그러나 장기적인 안목으로 개발해야 하는 프로젝트가 있을 때는 인터페이스 빌더 없이 개발하는 방법도 반드시 알아야 합니다. 사수가 화살이 떨어지면 근처에 있는 나무라도 깎아 촉을 세우고 사냥을 해야 하지 않겠습니까. 연필 깎는 법은 모르고 매번 자동연필깎이에 연필을 깎아 쓴다면 정작 칼만 쥐어졌을 때는 손에 피가 나기 마련일 테니까요.

좀 더 쉬운 이해를 위해 한 가지 예를 들어보겠습니다.
아이폰 개발자라면 모두들 잘 아실 아주 초보적인 내용입니다.
저희 책 p43에 나오는 예제로서 3가지 뷰를 상하위 뷰로 나눠, 빨강, 파랑, 까망 오브젝트의 순서로 배열하는 코드를 설명합니다. 우선 결과물을 먼저 보시죠.