형식주의자들은 문학적인 전개법으로 파불라(fabula)와 슈제트(syuzhet)라는 개념을 사용했다고 합니다. 재료와 구성을 각각 파불라와 슈제트로 분류하기도 했으며 인과 관계로 나열된 미세한 사건들의 총체를 서술에 의해서 예술적으로 배열한 것을 슈제트라고 불렀습니다. Fabula는 SwiftUI의 기술적 재료들을 학습하고 조합하여 창의적인 결과물을 도출하기 위한 개인 프로젝트였습니다. 거창해 보이지만 실은 게으른 개발자가 되지 않으려는 수단이었습니다.
현재는 SwiftUI 개발자들이 FabulaItemsProvider 패키지를 통해서 본인의 작품을 PR(Pull Request)하고 앱을 통해서 사용자와 소통할 수 있는 놀이터가 되었으면 하는 마음으로 진행하고 있습니다. 그동안 프로젝트를 진행하며 생각했던 의식의 흐름대로 이야기해보겠습니다.
Fabula 프로젝트를 시작하게 된 배경 - 의식의 5 단계
1. 단계 : 개인적인 학습과 궁금증
a. 주기적인 학습을 통해 러닝 커브를 최소화 해보자.
개발을 취미로 하는 것만큼 학습에 도움이 되는 방법도 없습니다. 다만 속세의 유혹을 멀리하며 누구의 도움도 받지 않고 스스로 새로운 것에 대한 갈증을 지속해서 해결하기란 쉬운 일이 아닌 것 같습니다. 이런 취미를 이어가기 위해서는 자신만의 동기가 필요합니다. Fabula는 그런 동기를 만들기 위해 진행한 작업이었습니다.
b. SwiftUI를 채택하기 전에 기술적 한계는 어디까지일까?
SwiftUI를 채용하기 위해서는 SwiftUI의 기술적 한계를 확인할 필요가 있습니다. 어떤 요소가 구현하기 어려운지, 또는 동일한 사용성을 구현할 때 공수는 얼마나 들어가는지에 대한 검토가 필요합니다. 이러한 검증이 완벽하게 확인되지는 않았지만 “대체적으로” SwiftUI로 구현 불가능한 것은 없는 것 같습니다. 기본적인 UI 설계에서는 UIKit/AppKit을 사용할 때보다 공수가 많이 줄었습니다. 물론 추가적으로 확인이 필요한 부분이기는 합니다.
c. 생성성 측면에서 정말 UIKit/AppKit보다 효율이 정말 좋을까?
비즈니스의 기본 전략은 생산 비용을 줄임으로써 주어진 시간에 고품질의 제품을 개발하는 것입니다. 저는 기존 개발 방식(이벤트 중심의 명령형 프로그래밍)에 비해서 SwiftUI가 얼마나 효율이 높은지 궁금했습니다. 지금까지 경험으로는 UIKit/AppKit보다 두 배 이상은 높은 것 같습니다. 기본적인 시스템 컴포넌트를 활용한 UI설계 작업에서는 획기적인 변화를 느낄 수 있었습니다.
d. 모든 라이브러리 및 컴포넌트를 SwiftUI로 대체 가능할까?
우리는 프로젝트를 진행할 때 내/외부 라이브러리 및 컴포넌트를 자주 사용합니다. 이 또한 개발 효율을 높이는 방법입니다. 시스템 컴포넌트만으로 요구 조건에 부합하는 사용성을 표현할 수 없거나 공수가 많이 들어갈 때, 우리는 보통 라이브러리 컴포넌트를 활용합니다. SwiftUI는 아직 내부 시스템 컴포넌트의 자유도가 높지 않은 편입니다. 커스텀한 디자인을 적용하기 위해서는 요구 조건에 맞는 커스텀 컴포넌트를 개발해야하는 상황도 발생할 수 있습니다.
이는 역설적이게도 SwiftUI의 요소 대부분이 기본 프로토콜(View )로 추상화되어 컴포넌트 구조가 단순하고 가독성이 높으며 유지 관리가 쉬운 것의 어두운 그림자입니다. 하지만 커스텀 컴포넌트를 개발하는 공수 또한 UIKit/AppKit에 비해 획기적으로 줄었다고 할 수 있습니다. 이제 더 이상 시스템 컴포넌트에 종속될 필요가 없습니다. (물론 네비게이션바와 같이 프레임워크에서 주도하는 기능 요소들은 되도록 시스템 컴포넌트를 활용하는 것이 좋겠습니다.)
e. iOS뿐만 아니라 macOS에도 대응할 수 있는 기술적 범위는 어디까지일까?
모든 플랫폼에서 동일 코드로 개발할 수 있다지만 일정부분 불가피한 제약이 따릅니다. 대부분은 SwiftUI로 래핑되어 동일 코드로 UI개발을 할 수 있지만 UIKit과 AppKit의 차이로 발생하는 기능들이 있습니다. 예를 들어 터치와 마우스 클릭의 차이, Tabbar의 기본적인 사용성 차이(iOS에서는 하단 탭 메뉴로 표현, macOS에서는 상단 탭으로 표현) 등의 차이가 있습니다. 정도에 따라서 컴파일러 지시문을 통해 플랫폼을 분기 처리해야 할 수도 있습니다.
또한 tvOS와 watchOS는 iOS/macOS와 다르게 사용성에서 차이가 발생합니다. 따라서 iOS와 macOS는 프로젝트 내에서 객체별로 분기 처리할 수 있으나 tvOS와 watchOS는 별도의 타겟으로 관리하는 것이 코드 가독성에 도움이 될 수 있습니다.
2. 단계 : Fabula가 개발자들에게 놀이터가 될 수 있을까?
a. 세계 곳곳에 흩어져 있는 SwiftUI 기술 파편들을 한 곳에서 볼 수 없을까?
SwiftUI는 프리뷰 기능을 통해서 실시간으로 개발 결과물을 확인할 수 있습니다. 그래서 요즘 SNS를 통해서 UI개발 과정을 공유하는 사례도 많이 볼 수 있습니다. 이는 캡슐화된 구조체를 쉽게 공유할 수 있으며 모듈화할 수 있는 장점이기도 합니다. SwiftUI를 사용하여 개발하는 수많은 결과물을 한 곳에 모아 볼 수 있다면 저 뿐만이 아니라 다른 개발자들에게도 도움이 되리라 생각합니다.
b. 자료를 아카이브하여 필요할 때 누구나 쉽게 찾아볼 수 있다면?
개발 기술 자료들을 아카이브하는 방법은 각자 다양합니다. 블로그를 쓰기도 하고 Medium 같은 서비스를 이용하기도 하며, 노트에 정리하기도 합니다. 저는 개인적으로 개발 결과물을 문서로 정리하는 습관을 들이지 못해서 효율이 떨어지는 편입니다. 그래서 별도의 문서 작성 없이 코드를 아카이브하고 검색을 통해서 쉽게 찾아볼 수 있으면 좋겠다고 생각했습니다.
c. 개발자들이 앱 안에서 소통할 수 있으면 좋겠다.
별도의 설명 없이 코드를 통해서 소통하고 싶었습니다. 하지만 부족한 부분이 많습니다. 그래서 유닛 아이템 단위로 앱 내에서 개발자들이 소통할 수 있으면 좋겠다는 생각을 하게 되었습니다. 그래서 Firebase Cloud Firestore를 사용하여 간단한 대화방 기능을 추가했습니다. 아직은 대화방이 활발한 편은 아니지만 최소한의 커뮤니케이션은 가능하지 않을까 싶습니다. 추가로 대화방 기능은 앱 업데이트 소식을 전하는 기능도 하고 있습니다.
3. 단계 : SwiftUI 개발자들의 놀이터가 되려면 필요한 것이 무엇일까?
a. 자신의 코드를 순쉽게 공유할 수 있어야.
놀이터가 접근하기 어려운 곳에 있거나 놀이 기구를 사용하기 위해 복잡한 허가 과정이 필요하다면 그 놀이터는 좋은 놀이터가 될 수 없을 겁니다. Fabula는 FabulaItemsProvider 패키지를 통해서 모든 유닛 아이템들을 수집하고 관리합니다. 따라서 패키지를 자신의 github 계정에 Fork하여 아이템을 추가하고 PR(Pull Request)하면 FabulaItemsProvider 패키지에 병합(merge) 후, 최종적으로 Fabula 앱을 통해서 앱스토어에 배포하게 됩니다. 아직 코드 기여자가 저 뿐이라서 혼자 코드를 제공하고 있지만 놀거리가 풍부해지면 많은 분들과 함께 이 놀이터에서 놀 수 있지 않을까 기대하고 있습니다.
b. 기여자에게 보상은?
Fabula 앱은 모든 것을 무료로 제공하고 있습니다. 따라서 금전적인 보상보다는 위와 같이 기여자 리스트를 통해서 최소한의 감사를 표하고 있습니다. 기여자분들에게는 추가적으로 혜택을 드릴 수 있는 방법을 지속적으로 고민하고 있습니다.
4. 단계 : 홍보의 한계
a. 프로젝트의 취지를 알리고 기여자를 찾기가 쉽지 않다.
SwiftUI가 보편적인 프레임워크로서 아직은 활성화되지 않은 것 같습니다. 또한 앱을 홍보하기 위해 별도의 비용을 들이지 않고 앱스토어 검색을 통해서만 노출되고 있어서 한계가 있습니다. iOS 13/macOS 10.15이 최소 버전이라는 부담이 사라지고, 앞으로 SwiftUI가 보편적인 프레임워크로 채용되는 시점이 되면 지금보다 컨텐츠가 더욱 풍성해지지 않을까 기대합니다.
b. 개발자들의 참여가 미미하다.
프로젝트의 취지를 전달하는 것에 제 부족함이 있습니다. 또한 이런 것을 PR(Pull Request)해도 될까 싶은 마음, 또는 컨텐츠가 영어라서 부담이되시는 분들도 있을 것 같습니다. 하지만 기존 아이템 중에는 100줄 미만의 단순한 아이템도 많이 있습니다. 본인이 필요할 때 찾아볼 만한 아이템이라면 어떤 것이라도 상관었습니다. 그리고 영어는 저도 잘 하는 편이 아니라서 번역기에 의존하고 있습니다. 언어적인 부분은 의미만 전달할 수 있으면 큰 문제 없다고 생각합니다. 부담 없이 편하고 자유롭게 PR하셔도 좋겠습니다.
5. 단계 : 실제로 필요한 것을 만들어 보자
a. 일단 나부터 재밌게 놀아보자.
SwiftUI를 공부하면서 습득하는 파편들을 이곳에 모아두면 필요할 때 쉽게 찾아서 확인할 수 있을 것입니다. 다른 분들도 비슷하겠지만 머리속에서 문제 해결 방법을 찾을 수 없을 때, Stack Overflow의 도움을 많이 받습니다. 하지만 찾는 과정에서 시간을 많이 소모하는 것도 사실입니다. 이런 시간적 비용을 Fabula 앱을 통해서 줄일 수 있다면 저에게도 많은 도움이 될 것입니다.
b. SwiftUI의 시스템 컴포넌트 경직성이 개발 자유도를 해치는 것은 아닐까?
아직 시스템 컴포넌트들을 완전히 통달하지는 못했지만, Swift의 자유도에 비하면 경직된 것이 사실입니다. 여러 플랫폼을 동일 코드로 래핑하면서 발생하는 불가피한 부분이기도 합니다. 하지만 기획/디자인이 요구하는 사용성이 개발자로서 충분히 납득된다면 이러한 경직성을 해결할 방법을 우리는 고민해야 합니다.
c. UI를 설계할 때 좀 더 쉽게 구현할 수 있는 방법은 없을까?
시스템 컴포넌트들은 애플 개발자들의 수많은 의사결정 과정에서 다듬어지고 있습니다. 따라서 커스텀 컴포넌트의 사용법이 시스템 컴포넌트와 완전히 다른 것은 지양할 필요가 있다고 생각합니다. 최대한 시스템 컴포넌트의 사용법을 따르면서도 원하는 기능을 쉽고 빠르게 개발할 수 있는 방법을 고민하고 있습니다. 이런 고민은 최종 결과물을 떠나 과정에서 얻을 것이 분명 있으리라 생각합니다.
d. 필요한 것을 Open Library로 만들어보자.
SwiftUI로 개발할 때 쉽게 사용할 수 있는 라이브러리를 하나하나 만들어보고 있습니다. 컴포넌트 구조를 어떻게 설계하는 것이 사용하기 편하고 개발 자유도를 해치지 않을지 고민 중입니다. 범용 라이브러리로서 가치가 없다 하더라도 컴포넌트화 과정에서 적용하는 방법은 다른 문제를 해결하는 데도 힌트가 될 수 있으리라 생각합니다.
마무리
개발 초기에는 SwiftUI에 익숙해지기 위해 지극히 개인적으로 시작했지만 저와 비슷한 고민을 하는 분들이 많은 것 같아서 조금이나마 도움이 될 방법을 찾아보고 있습니다. 앞으로 Fabula 프로젝트가 SwiftUI에 관심이 있는 분들에게 실질적인 도움이 되었으면 하는 바람입니다.
다음 편에서는 Fabula 프로젝트의 구조와 Workflow에 관해서 이야기하겠습니다.