iOS 개발자라면 한번은 들어봤거나 써봤을 오픈소스 툴 Sourcery를 만든 Krzysztof Zabłocki와 팟캐스트 녹음을 했는데 작년 엉클밥을 봤을 때와 비슷한 큰 자극와 영감을 얻었습니다. Krzysztof는 좋은 앱 아키텍처와 개발자 툴을 만들어서 개발자 경험을 개선하는 것에 목표를 두고 여러 툴을 만들면서 현재 뉴욕타임스에서 iOS 팀을 리딩하고 있는 개발자입니다.

잘못된 선택보다 올바른 선택을 하는게 더 쉬운 구조가 좋은 아키텍처다.

이 분은 모바일 아키텍처와 프로그래밍을 굉장히 실용주의적인 관점으로 해석하고 실행에 옮기시는 분이란 인상을 받았습니다. 그는 좋은 아키텍처를 구분하는 기준은 그 아키텍처를 쓰는 개발자가 얼마나 행복한가로 판단해야 한다고 합니다. 또한 좋은 아키텍처란 ‘잘못된 선택보다 올바른 선택을 하는게 더 쉬운 구조’라고 합니다. 왜냐면 인간은 여러 갈래가 있을때 쉬운 길을 택하는 경향이 있기 때문이죠. 좋은 코드를 짜기 위해 아키텍처와 싸워야하는게 최악의 상황이라고 합니다.

그래서 이분이 지금까지 만든 것들을 보면 의외로 간단한 아이디어에서 시작하지만 매일 매일 프로그래밍하는 개발자들의 생산성을 증가시켜주거나, 불필요한 반복 작업을 줄여서 실수를 줄여주거나, 코드를 좀 더 좋은 구조로 짜게 강요(?)하는 마법을 부리는 것 같습니다. Protocol extension으로 앱 로깅을 담당하는 싱글턴 객체를 숨기면서 유닛테스트도 할 수 있게 해주는 방법이라던지, 유저가 버그 리포트를 했을 당시 유저의 앱의 상태를 복원할 수 있는 데이터 스냅샷 기능 등을 보면 기존 코드를 많이 뜯어고치지 않는 간단한 방식으로 팀 전체의 개발 및 디버깅 경험을 개선시켜줍니다.

애플 엔지니어들마저 베껴간 Sourcery

더 대단하고 인기 많은 툴도 있습니다. Sourcery라는 툴은 스위프트에서 Equatable이나 Codable 프로토콜 등을 쓸 때 자동으로 구현 코드를 생성해주는 툴입니다. 지금이야 스위프트 자체에서 지원하는 부분이 있지만 초창기에는 디폴트 구현를 지원하지 않아서 모든걸 다 수동으로 구현해줘야 했을때 만들었다고 합니다. 이걸 만들고 얼마 지나지 않아 애플 엔지니어들마저 내부에서 사용하기 시작했다고 합니다. 재밌게도 그걸 알게된건 애플 엔지니어들이 회사 정책 때문인지 오픈소스에 직접 PR을 보내진 못하고 트위터 비공개 DM으로 패치를 보내주면서 버그를 고쳐 달라고 요청이 들어오기 시작했다네요.

애플의 거짓말을 들춰낸 Objective-C Playground

또 하나 놀라운 일화는 애플이 WWDC에서 스위프트 플레이그라운드를 발표하면서 옵젝씨로는 이런거 못한다고 말한걸 듣고 빡쳐서 불과 12시간만에 옵젝씨 플레이그라운드를 만들어버림으로써 애플이 틀렸다는걸 증명해버렸습니다. 이 프로젝트는 옵젝씨 뿐 아니라 스위프트까지 지원하고, 애플에서 만든 스위프트 플레이그라운드와는 비교도 안되게 훨씬 빠르다고 자랑합니다. 심지어 플러터처럼 앱 hot reloading도 할 수 있게 해버렸네요. ‘Code Injection’이라는 키워드를 처음 배웠습니다.

iOS 아키텍처와 테스팅

마지막으로 이 분은 iOS 개발을 하기 전에는 게임 엔진도 만들고 그래픽 개발도 하고 웹/백엔드 개발도 해봤는데, 모바일 진영이 그 중 제일 테스트코드 짜기를 꺼려하는 분위기라고 합니다. 그 이유 중 하나는 아마도 애플이 제시하는 MVC가 테스트하기 극도로 안좋은 아키텍처이기 때문인거 같다고 하네요. 일단 테스트가 잘 되려면 UIKit과 완전히 분리된 로직만 담당하는 클래스가 있어야하는데 “애플의 MVC”는 기본적으로 injection도 없고 composition도 없어서 그게 어렵다는 의견을 제시합니다. 그럼 대체 애플은 왜 십 수년간 MVC만 미는가, 좀 더 나은 아키텍처를 밀어주는 변화는 없을까란 질문에 대해서도 꽤 그럴듯한 답변을 내놨습니다.

일단 MVC 외에 인기있는 주류 아키텍처로는(2017년 발표 당시) MVVM과 VIPER(또는 여타 unidirectional architecture)가 있는데요. 먼저 MVVM은 FRP스러운 바인딩이 있어야하는데 이건 잘 만들기도 어렵고 당장 UIKit과 잘 맞지 않아서 후보가 될 수 없고, VIPER는 어려워서 배우기 쉽지 않다고 합니다. 애플은 신규 개발자들이 애플 플랫폼에 쉽게 들어오기를 바라기 때문에 이렇게 어려운 아키텍처를 밀어줄리는 없다고 하네요. 아키텍처에 대한 폭넓은 인사이트는 몇 년 전에 했던 인기 많았던 발표를 참고하시면 되겠습니다. Good iOS Application Architecture: MVVM vs. MVC vs. VIPER. 2020년 현재, Combine과 SwiftUI가 생겼으니 MVC를 벗어나기 쉬워졌을까요?

바로 오늘 도움이 되는 실용적인 코드와 툴을 만들어내는 개발자

이분은 프리랜싱과 컨설팅을 한 적이 있어서 그런지 개발 생산성과 코드 재사용성을 끌어올리는 아키텍처와 tooling에 전문가셨고, 특히 본인이 필요해서 만든 툴로 인해서 얼마를 벌었다는걸 구체적인 액수로 말하는게 정말 인상적이었습니다. 왜냐면 프리랜서는 시간이 수입으로 직결되니까 툴을 만들어서 매일 반복 작업으로 쓰이던 시간을 줄이거나 예전 프로젝트에서 썼던 코드를 재활용할 수 있게 되면 그게 곧바로 수입으로 계산될 수 있기 때문이겠죠. 엉클밥이나 GoF 옹들이 이론과 이상향을 제시하는 분들이라면 Krzysztof는 그 이론과 디자인 패턴을 바탕으로 당장 오늘 도움이 되는 실용적인 코드와 툴을 만들어내는 개발자 같았습니다. 특히, 매일 해야하는 디버깅과 코딩에서 최대한 반복 작업을 없애고 좋은 아키텍처가 퍼질 수 있게 꾸준히 무언가를 만들고 고민하는 모습에서 정말 큰 영감을 얻을 수 있었습니다.