UITableView를 쓰지 말아야할 때

UITableView는 당연히 사용할 줄 알아야 하는 필수적인 클래스인만큼 잘못 사용되는 경우도 잦은 클래스다. 컨텐츠가 화면에 다 담기지 않아 스크롤이 발생하는 레이아웃을 만들어야할 때 별 고민없이 테이블뷰가 사용되는 상황을 많이 봤다. 심지어 스크롤이 발생하지 않더라도 단지 같은 뷰가 여러번 반복된다는 이유로 테이블뷰를 사용하기도 한다. 하지만 테이블뷰를 사용하기로 쉽게 결정하기 전에, 정말 뷰를 재사용하는 컴포넌트가 필요한지 짚어봐야 한다.

테이블뷰의 장점: 구조화된 데이터 표현 및 메모리 효율

테이블뷰는 데이터가 일관된 구조를 가지고 있고 계층화되어 있을 때 가장 유용하다. iOS의 설정 앱이나 연락처 앱이 대표적인 예시다. 내비게이션 뷰컨트롤러와 함께 사용하면 계층적인 구조를 정말 잘 나타낼 수 있다. 그리고 뷰(UITableViewCell)를 재사용하기 때문에 보여줘야 할 데이터가 수 백, 수 천 개여도 화면을 채울 만큼만 인스턴스가 만들어지기 때문에 데이터의 사이즈가 커도 메모리 걱정을 하지 않아도 된다.

테이블뷰의 단점: 복잡한 코드 + ⍺

프로그래밍과 관련된 거의 모든 결정에는 트레이드오프가 발생하는 거처럼, 테이블뷰도 뚜렷한 단점이 있다. 뷰 인스턴스를 재사용하는 장점을 얻는 대신 구조가 더 복잡해지고 코드가 길어지고 버그에 취약해진다.

UITableView를 설정해주고, UITableViewCell을 상속하고, DataSource와 Delegate를 구현해야 한다. 또한 셀 인스턴스가 재사용되면서 발생할 수 있는 이상한 동작을 방지하기 위해 추가되는 코드가 소소하지만 꽤 많다. 셀에 필요한 UI 데이터(이미지 등)를 비동기로 불러와야 경우, 외부의 사건(유저 액션 등)으로 인해 셀의 UI가 바뀌어야 하는 경우 등등에 추가적인 검사 로직을 넣어줘야 한다. 게다가 뷰의 레이아웃이나 크기를 동적으로 바꾸거나 애니메이션을 넣는 간단한 일도 테이블뷰가 연관되면 잘 안되고 귀찮아질 때가 많다.

테이블뷰 필요없는 경우 🔴

글의 시작 부분에서 언급한 오용이란 장점을 제대로 누리지 못하는 상황을 말한다. 대표적으로 셀이 재사용될 필요가 거의 없거나 재사용이 안되는 경우다. 테이블 열의 갯수가 적으면 메모리 걱정을 할 필요가 없다. 또한 테이블뷰의 열이 10개인데 10개가 다 다른 종류의 셀이라면 아무것도 재사용되지 않는다. 굳이 테이블뷰를 쓸 이유가 없다.

테이블뷰 필요한 경우 🟢

반대로 테이블뷰를 꼭 써야하는 경우는 데이터가 많을 때다. ‘많다’를 판별하는 절대 기준이 있는건 아니다. 하지만 너무 보수적으로 잡을 필요는 없다고 생각한다.

고민이 필요한 경우 🟠

개발하다보면 중간지대의 상황도 자주 맞닥뜨린다. 데이터는 적당히 많으면서 셀 종류도 두어개, 많게는 10개 정도. 유저 인터랙션도 있고 그에 따른 상태 변화와 UI 변화도 있는 경우. 그럴땐 뷰 재사용이 꼭 필요한지, 아니면 간단하고 안전한 코드가 더 이득일지 판단을 내려야 한다. 경험적으로 두 페이지가 넘어가지 않는 경우나, 필요한 뷰들을 한꺼번에 생성해도 메인쓰레드가 블락되지 않는 정도라면 간결한 코드의 장점이 더 크다.

대안: UIStackView + UIScrollView

뷰 재사용이 필수적인 요구사항이 아니라면 스택뷰 단독이나 스택뷰+스크롤뷰 조합을 이용해 훨씬 간결한 코드로 UI를 만들수 있다. 이 방식은 뷰를 직접 참조하여 들고 있을 수 있어서 언제든 간단하게 변화를 줄수도 있고, 테이블뷰처럼 의무적으로 호출해야 하는 메서드도 없어서 실수도 덜하고 디버깅도 쉽다.

Tags: UITableView, UIStackView  

모바일 앱 스터디원 모집

5월 17일부터 20일까지 오후 7시-8시 반, 4일 동안 진행하는 단기 스터디를 함께할 스터디원을 모집합니다.

주제

Building Mobile Apps at Scale을 읽고, 책에 나오는 사례를 위주로 각자의 실제 경험을 나누는 시간을 가지려고 합니다. 저자는 앱 개발을 하면서 겪을 수 있는 다양한 문제와 해결법 몇 가지를 알려주긴 하지만 너무 짧고 간단하게 설명하고 있는 부분들이 아쉬워서 스터디를 계획하게 됐습니다. 실제로 문제를 겪고 해결했던 사례를 공유하면서 더 자세히 파고 들어가보면 어떨까 합니다.

장소

온라인 화상미팅

참여 방법

요일별로 주제가 다르니 책을 읽고 나서 관심있는 주제나 관련 경험이 있는 주제에 해당하는 요일에 구글폼 제출해주시면 개별 연락드려서 참여 확정을 하겠습니다.

요일별 주제

Day 1(월요일): 앱의 특수성으로 인한 어려움 (세부 주제 및 신청 폼)
Day 2(화요일): 앱이 커지면서 발생하는 어려움 (세부 주제 및 신청 폼)
Day 3(수요일): 팀이 커지면서 발생하는 어려움 및 크로스 플랫폼 관련 (세부 주제 및 신청 폼)
Day 4(목요일): 앱을 고도화할 때 발생하는 어려움 (세부 주제 및 신청 폼)

Tags: study  

테스트와 좋은 설계의 관계, 그리고 나쁜 설계의 영향

TDD는 설계 방법론이 아니다 글을 읽고 쓴 글입니다.

TDD는 안해봤지만 1년 동안 진하게 유닛 테스트 추가하고 레거시 코드를 테스트 가능하게 리팩토링 하면서 느낀 점과 유사하다. 요약하자면

  1. 테스트 가능한 코드는 강한 결합을 회피하고 의존성 역전 원칙만큼은 지키게 해준다.
  2. 단일 책임 원칙과 인터페이스 분리 원칙은 알아서 챙겨야 한다.

작년에는 코드를 테스트 가능하게 만드는 것부터 시작했다. RIBs는 워낙 기본 구조가 잘게 분리되어 있고 각 요소가 단일 책임 원칙을 지키고 있어서 그에 맞춰 짜기만 해도 중요 로직은 어느정도 테스트 가능하다. MVC를 제외한 대부분의 아키텍처가 비슷할 것이다. 그래서 모바일 개발 환경에서는 아키텍처의 손이 뻗지 않은 그 외 15-20프로 정도의 코드에서만 개발자의 설계 역량이 중요한거 같다.

그런데 그 15-20프로의 코드가 매우 중요하다. 앱의 디자인이나 기능과 유사하게 코드도 템플릿화되어 쉽게 복사되고 퍼진다. 어느 정도 코드베이스가 쌓이면 완전히 새로운 설계를 하게 되는 경우는 드물고 기존에 있는 비슷한 기능을 하는 코드를 찾아 쓰게 된다. 그리고 대부분의 사람들은 기존의 코드를 손쉽게 복붙해서 가져간다.

잘못 설계된 공통 모듈이 그에 의존하고 있는 모듈 수십 개과 수십 명의 개발자에게 안 좋은 영향을 주는걸 봤고, 누군가가 집어 넣은 잘못 설계된 구조가 스멀스멀 퍼져나가는걸 목격했다. 불필요한 의존성이 덤으로 딸려오는 바람에 인터페이스 분리 원칙도 못지키게 되고 빌드 시간도 늘어난다. 또한 누군가가 만든 테스트 불가능한 구조가 다른 개발자들이 별 생각없이 가져가 쓰면서 점점 증식되기도 한다. 코드가 안좋아지는 것 뿐아니라 의미없는 코드 리뷰어가 강제되어 리뷰 받으려는 사람, 리뷰 해야하는 사람의 시간을 허비하게 만들었다.

그래서 공통 모듈을 만들거나, 새로운 구조를 도입할때는 앞으로 이 코드가 오랫동안 남아서 미칠 영향을 고려하여 특히나 책임감을 가지고 설계해야 한다. 구글은 코드 리뷰 대원칙에서 이와 같이 말한다. ‘개발자는 맡은 일을 완수하면서도 코드 품질을 개선시켜야 한다. 꾸준히 개선하지 않으면 품질은 절대 나아지지 않는다.’

Tags: tests, design  

어차피 SwiftUI에는 뷰컨이 없다

(언젠가부터 애플 공식 MVC 문서에는 Retired Document 라는 경고 팝업이 뜬다.)

프로토타입용으로 만드는 iOS 앱이 아니라 사업에 중요한 앱이라면 Cocoa MVC를 벗어나야 한다.

가장 큰 이유는 testability다. MVC는 여러 이유로 커버리지를 확보하기 쉽지 않고, 또한 SOLID를 지키는거보다 안지키는게 더 쉬운 아키텍처다. 애초에 초보자도 쉽게 iOS개발을 시작할 수 있게 만들어놓은 구조에 너무 많은걸 바라면 안된다.

Cocoa MVC로 테스트도 잘하고 SOLID도 지키려면 뷰컨트롤러를 뷰 계층으로 취급하고 UIKit에 의존성 전혀 없는 컨트롤러 부분을 새로 정립해야 한다. 추가적으로 (SwiftUI가 아닌) UIKit을 쓴다면 라우팅 로직도 별도 계층으로 따로 빠지는게 좋고.

이렇게까지 대규모 공사를 해서 MVC를 쓸 바에야 이미 한번 개조되고 커뮤니티의 검증 받은 MVVM, VIPER, RIBs, VIP 등으로 시작해서 조금씩 변형시키는게 더 합리적인 선택이 아닐까. 불필요한 시행착오를 줄이고 시간을 아낄 수 있을 거다.

P.S. SwiftUI 시대가 도래하면 속칭 라우터가 있는 아키텍처는 쓸모 없어질 것 같다. 뷰모델의 상태값을 바꾸는 행위만으로 라우팅이 되기 때문에 별도 계층으로 분리하는게 무의미하다. 현재 가장 인기 많지만 라우터가 없는게 약점으로 꼽히는 MVVM은 라우터가 불필요해진 SwiftUI 시대가 오면 더 인기가 많아질 것 같은데(사실상 새로운 표준이 될 것 같다) 과연 VIPER, RIBs 등등의 자리는 어떤 새 아키텍처가 꿰차게 될까. 어느 아키텍처가 과도기에 매끄러운 전환을 지원할 것인가.

참고자료
https://nalexn.github.io/clean-architecture-swiftui/ https://slideslive.com/38897361/good-ios-application-architecture-en http://merowing.info/2016/01/improve-your-ios-architecture-with-flowcontrollers/

Tags: architecture, swiftui