2022년 시니어 iOS 개발자 로드맵

벌써 11월이라는 것에 놀라 올해를 돌아보니 삶의 중대한 일들을 지나느라 올해는 순수 개발 공부를 많이 못했다. 그래서 밀린 주제들이 많다.

Swift 및 iOS 개발 환경에도 변화의 바람이 불어오고 있다. 개인적으로 관심을 가지고 공부하고 있거나 앞으로 중점적으로 공부할 예정인 주제들을 골랐다.

1. 선언형(Declarative) UI

애플의 SwiftUI, 안드로이드의 Compose, 구글의 Flutter가 선언형 UI를 택했다. 올해 회사에서 플러터로 신규 기능 개발을 하면서 선언형 UI를 처음 써봤다. 명령형 UIKit과는 완전히 다른 프로그래밍 방식이었고 꽤 재밌었다. 모바일에서는 리액티브와 선언형이 합쳐진 UI 개발 방식이 대세가 되고 있다.

모바일 개발에서 UI는 핵심 요소다. UI 프레임워크의 동작 방식이 이렇게 크게 바뀌면 앱의 아키텍처도 바뀔 수 밖에 없다. 회사에서 플러터 개발을 할 때 flutter redux를 써보니 Redux와 선언형 UI가 잘 맞는다고 느꼈다. SwiftUI로 개발할 때도 Redux 기반 아키텍처가 좋은 시작점이 될 것 같다. 그래서 PointFree The Composable Architecture에 관심을 두고 있다.

2. 비동기 프로그래밍

Structured concurrency라는 대주제로 Swift 5.5에 다양한 비동기 프로그래밍 관련 문법들이 추가됐다. async, await, AsyncSequence, Task, actor 등등 공부해야할게 수북하다. Completion handler를 멸종시킬 수 있게 된 점이 무엇보다 기쁘다. 조금만 복잡해져도 가독성이 매우 떨어지고 실수하기 쉬운 completion handler를 쓰지 않기 위해 예전부터 Promise와 같은 외부 라이브러리를 가져다 쓰고 있었지만, 써드파티 라이브러리를 팀의 표준으로 삼을순 없었다.

하지만 이제는 훨씬 나은 퍼스트파티 대안이 많이 생겼다. Combine은 기능이 부족하긴하지만 확장해서 쓰기에는 충분하다. Structured Concurrency와 Combine 프레임워크로 훨씬 가독성 높고 실수가 적은 비동기 프로그래밍이 가능해졌다. Completion handler는 이제 뒤도 안돌아보고 보내줄때다.

3. 테스팅

자동화 테스팅은 프로그램의 실패와 오류를 최대한 빨리 파악하기 위해 중요하다. 테스팅은 단기간에 끝나는 공부가 아니라 커리어 내내 공부하고 경험치를 쌓아야 하는 분야인 것 같다. 자동화 테스트는 두가지 방면으로 공부가 필요한데 테스트 가능한 코드를 만드는 것과 작성한 테스트를 잘 운영하는 것이다.

테스트 가능한 코드를 만들기 위해선 디자인 패턴 공부가 도움이 많이 됐다. 켄트 벡의 구현 패턴, 마틴 파울러의 리팩터링을 계속 참고하게 될 듯 하다. 그리고 새 프로젝트에 유닛 테스트, 스냅샷 테스트, 통합 테스트 등 차근차근 쌓아가고 있기 때문에 앞으로 앱과 코드를 운영 하면서 노하우를 쌓기를 기대하고 있다. 최근에 한글로 번역돼서 나온 단위 테스트라는 책이 평이 좋던데 꼭 봐야겠다.

4. 스위프트 패키지

우리 팀에서 스위프트 패키지를 적극 활용하고 있는데 지금까지의 경험은 매우 좋다. 우리는 계층화된 모듈로 코드를 분리해서 개발하기 때문에 관리해야할 라이브러리가 많은데 xcodeproj에서 발생하는 코드 충돌이 없어서 한결 편하다. 리소스도 추가 가능해져서 사실상 모든걸 할 수 있다. 이젠 스위프트 패키지를 지원하지 않는 외부 라이브러리도 거의 없다. 아직 엑스코드 버그 몇 개 때문에 가끔 불편하긴 한데 심각한 정도는 아니다.

좀 더 공부가 필요한 부분은 SPM이 알아서 라이브러리 타입을 다이나믹과 스태틱 중에 선택해준다는건데 아직 정확히 동작을 파악할 시간적 여유가 없었다. 다이나믹 라이브러리 갯수는 관리 대상이기 때문에 동작을 이해하고 써야한다.

5. 컬렉션뷰

정말 오랜만에 테이블뷰/컬렉션뷰 코딩을 하게 돼서 최근에서야 UICollectionViewCompositionalLayout을 공부하고 적용했는데 예상만큼 강력했다. 제대로 구현하려면 은근 골치아팠던 Orthogonal 레이아웃을 쉽게 구현할 수 있다. Diffable data source도 앞으로 유용하게 쓰일거 같다. 애플이 제공한 샘플코드만 봐도 기능이 정말 많아서 익숙해지는데에 시간이 좀 걸릴듯 싶다. 이제 테이블뷰는 deprecate돼도 이상하지 않을거 같다.

6. 지속적 통합/배포

Trunk Based Development를 도입하고 자동화 테스트를 운영하고 있는 우리 팀에서는 CI/CD가 특히 중요하다. 지속적 통합과 지속적 배포를 떼어놓고 앱 개발을 할 수는 없는데 환경을 구축하고 운영하는게 결코 쉽지 않은 일이다. 툴은 많은데 사용이 편하면 기능 확장이 쉽지 않고 자유도가 높은건 구축과 운영 비용이 높다. 엑스코드 클라우드가 좋은 대안이 되길 기대하고 있다.

7. 도메인 지식

현재 회사에서 동영상과 이미지를 아주 많이 다루는데 미디어 포맷 관련 지식이 부족해서 한계를 느끼고 있다. 몇 달 전에는 mp4 동영상의 프레임을 시간 역순으로 불러오려고 이틀을 붙잡고 있다가 코덱 특성상 불가능한 일이었다는걸 배웠다. 코덱이 뭔지도 이때 처음 공부했다. 이제는 어깨 너머로 익힌게 쌓여 삽질하는 정도는 아니지만 프로젝트를 잘 이끌기 위해 더 깊은 도메인 지식이 필요하다. mp4, jpg, webp, webm 등을 공부할 예정이다.

그랩페이를 개발할때는 금융에 대한 지식이 도움이 됐고 웹툰을 개발할때는 컨텐츠 소비에 대한 경험과 관심이 도움이 됐다. 도메인 지식을 몰라도 어느정도 앱은 만들수 있겠지만, 시니어로 갈수록 회사의 도메인에 대한 공부와 관심이 더욱 중요하지 않나 싶다. 단순히 요구사항만 맞추는게 아니라 서비스의 방향도 책임지는 개발자라면.

8. 모듈 아키텍처

모듈화는 확장 가능한 앱 아키텍처를 구축하기 위해 반드시 해야할 일이다. 그랩에서 엄청난 규모의 코드가 모듈화되어 돌아가는걸 봤고, 거기서 엿본 패턴과 원칙과 경험을 토대로 더 개선해서 현재 프로젝트에 적용하고 있다.

모듈끼리 느슨하게 결합하고, 단방향으로만 참조하는 계층 구조를 구축해서 서비스의 특성과 팀의 구조에 맞춰 발전시키고 있다. 아키텍처를 상황에 맞춰 꾸준히 진화시키는 값진 경험을 쌓을 것이다. 이 목록에 있는 것들을 배우고 적용시키면서 맞이할 2022년을 기대해본다.

-

모듈 아키텍처의 원리와 구축, 비동기 코드 테스팅, 자동화 테스트 작성과 운영 노하우, 스위프트 패키지로 모듈 관리하는 법, Combine 활용법 등을 알고 싶다면 제 강의 [The Red : 노수진] 슈퍼앱 운영을 위한 확장성 높은 앱 아키텍처와 구축을 좋은 시작점으로서 추천합니다.

Tags: senior ios developers, 2022 roadmap  

슈퍼앱 운영을 위한 확장성 높은 앱 아키텍처 구축

🧑‍💻 강의 링크

모바일 개발자에게 확장성(scalability)이란

모바일 팀과 앱의 규모가 계속 커져도 사용자 경험과 개발자 경험 모두를 안정적으로 유지하는 것이라고 생각합니다.

개발자의 기술력은 개발 과정에서 발생하는 병목 현상을 얼마나 잘 처리하는지에서 보여지죠. 서버의 경우에는 많은 사용자가 몰릴 때 병목 현상이 발생하지만, 모바일의 경우에는 하나의 프로그램에 다수의 개발자들의 코드가 몰릴 때 병목이 발생한다고 볼 수 있습니다.

관련글: 모바일 개발자에게 scalability란 뭘까

강의 내용

1부. 코드 레벨 아키텍처: 재사용 가능한 코드를 만드는 스킬

객체를 작게 만들고, 작은 객체를 조합해서 복잡한 기능으로 합치는 것이 아키텍처의 시작입니다. Massive View Controller, Massive View Model, Massive Interactor를 벗어나게 해주는건 또다른 아키텍처가 아니라 composition 활용 능력입니다. Composition이 강력한 아키텍처 프레임워크 RIBs를 기반으로 미니 슈퍼앱을 만들어봅니다.

관련1: 스위프트로 다시보는 객체지향 프로그래밍: 피해야할 코딩 습관
관련2: 개발자와 라면 조리법
관련3: google/promises를 활용한 스위프트 비동기 프로그래밍과 에러 핸들링

2부. 모듈 레벨 아키텍처: 유지 보수와 개발 속도를 고려하는 모듈화

‘느슨하게 결합된 모듈 구조’는 ‘확장성 있는 아키텍처’와 같은 말이나 다름없습니다. 200명의 iOS 앱 개발자가 기여하는 슈퍼앱 그랩, 약 75명이 기여하는 에어비엔비 같은 회사의 개발자들이 생산성을 지킬 수 있는 방법입니다. 왜 모듈화를 하면 빌드 시간이 줄어들고 생산성이 오르는지 원리를 알아보고 실습을 통해 미니 슈퍼앱에 적용해봅니다.

관련1: 모바일 앱의 느슨한 결합
관련2: Sourcery 개발자로부터 배우는 모바일 아키텍처와 개발자 경험

3부. 자동화 테스팅

테스트를 처음 시작하기 어려운 이유는 레거시 코드가 테스트 불가능한 구조로 짜여져 있기 때문이라고 생각합니다. 하지만 실습에서 짜는 코드는 99% 테스트 가능한 코드입니다. 테스트 가능한 코드의 특징을 한번이라도 익히고 직접 테스트를 작성해보면 레거시 코드에 도입하기도 쉽습니다. 유닛테스트, 스냅샷테스트, UI테스트, 통합테스트를 작성해봅니다.

관련1: 테스트와 좋은 설계의 관계, 그리고 나쁜 설계의 영향
관련2: 테스트 코드 작성하면 좋은 점
관련3: uber/RIBs 유닛 테스트 짜기
관련4: XCTest 소요시간 단축하기

4부. 확장성 있는 인프라: 코드만으로 해결할 수 없는 문제들

확장성 있는 아키텍처는 코드 뿐 아니라 개발 프로세스도 뒷받침해줘야 합니다. 피쳐플래그와 품질 모니터링을 도입해서 얻을 수 있는 것들과 제가 경험해본 좋은 개발 문화 사례를 공유합니다.

관련1: 앱 안정성을 향한 끊임없는 여정
관련2: 팀워크
관련3: 개인과 팀이 성장하는 모바일 개발 환경

Tags: app architecture, super app, fastcampus  

모바일 앱의 느슨한 결합

프로그래밍은 제대로 동작하는 소프트웨어를 효율적으로 만들어내는 일이고, 그걸 잘하려면 유지 보수가 쉬운 코드를 만들어야 한다. 그리고 유지 보수하기 좋은 코드를 만드는 매우 효과적인 방법은 객체를 느슨하게 결합(loose coupling)하는 것이다. Gang of Four는 디자인 패턴에서 다음과 같이 말했다.

Program to an interface, not an implementation.

구현에 의존하지 않고 인터페이스에 의존하는 결합 관계를 느슨하다고 한다. 느슨하게 결합된 코드는 확장이 용이하고 유지보수하기 훨씬 수월하다. 프로그램이 커지고 복잡해져도 관리할 수 있다.

느슨하게 결합된 코드를 짤 수 있게 해주는 소프트웨어 디자인 원칙이자 패턴을 의존성 주입이라고 한다. 강하게 결합된(tightly coupled) 코드에는 없는 요소기 때문에 이런 추가적인 요소가 왜 필요한지 납득하려면 느슨하게 결합된 코드의 장점을 먼저 이해해야 한다.

1. 늦은 연결(Late Binding)이 가능하다.

코드를 다시 컴파일하지 않고도 구현체를 갈아 끼울 수 있다. 딱 맞아 떨어지는 예시는 아니지만 모바일 앱 관점에서 보면 운영체제가 업데이트되거나 애플/안드로이드가 제공하는 프레임워크가 업데이트됐을 때 굳이 앱을 새로 배포하지 않아도 유저들은 새로운 기능을 경험할 수 있는 원리와 비슷하다.

하지만 이건 모바일 앱 개발자 입장에서는 와닿지 않는다. 왜냐하면 앱은 개발자가 정의하고 구현한 환경에서만 실행되기 때문에 사실상 구현체를 갈아끼울 일이 없다. 가령 데이터베이스가 필요한 앱을 만들때 앱 개발자 본인이 도입한 데이터베이스 외의 다른 데이터베이스를 쓰는 환경에서 내 앱이 실행될 거라는 가정과 고려 자체를 할 필요가 없다. 따라서 늦은 연결은 모바일 개발자가 누릴 수 있는 이점이라고 보기 어렵다. 하지만 느슨한 결합의 장점은 이게 전부가 아니다.

2. 확장과 재사용이 쉽다.

앱은 유저에 맞춰 요구사항이 바뀌고 사업에 맞춰 계속 진화한다. 클래스/모듈을 느슨하게 결합하면 새로운 기능을 개발하거나 기존 기능을 수정하고 확장하는게 쉬워진다. 느슨하게 결합된 코드는 확장에는 열려있고 수정에는 닫혀있게 된다. 느슨하게 결합된 코드에서는 객체를 조립하는 지점(composition root)이 따로 있고 여기서 실제 구현체를 생성해서 주입하기 때문에 인터페이스를 사용하고 있는 쪽 코드는 바뀔 필요가 없다.

예를 들어 앱에 결제 기능이 있을 때, 상품 쪽 코드가 결제 관련 인터페이스에 의존하고 있다면 결제 플로우를 개선하거나 개편해야할 때 결제 기능을 가져다 쓰는 상품 쪽 코드는 아예 건드릴 필요가 없다. 좀 더 일반화해서 A/B 테스팅을 생각해볼 수 있다. 동일한 기능을 여러 종류의 방식으로 제공해야할 때, 그 기능을 호출하는 쪽의 코드 수정 없이도 새 기능을 추가하거나 뺄 수 있다.

3. 병렬로 개발 할 수 있다.

프로젝트와 팀이 커지면 한 코드베이스에 여러 개발자가 병렬적으로 일하게 된다. 코드가 느슨하게 결합되어 있으면 개발자들이 여러 모듈을 동시에 개발하기 쉽다.

그랩 모바일 개발 팀은 100+명의 iOS 개발자가 모빌리티, 푸드, 페이먼트, CX 등 10개 미만의 큰 TF(Tech Family)로 나뉘어져 있다. 각 팀은 다른 팀이 만드는 기능(실시간 채팅, 결제, 잔액 조회, 리워드 포인트, 유저 정보/인증 등등)을 활용하면서도 느슨하게 결합된 코드 덕분에 ‘슈퍼앱’을 동시에 개발할 수 있다.

4. 유지 보수가 쉽다.

클래스와 모듈의 경계와 역할이 명확하게 구분되어 있는 코드는 유지 보수하기 쉽다. 신규 기능을 개발할 때 어디를 수정하면 될지 빨리 파악할 수 있고 영향 범위를 쉽게 볼 수 있다. 하나의 역할만 하는 클래스나 모듈로 결합된 코드에선 디버깅도 덜 힘들다. 역할과 범위가 잘 분리되어 있으면 버그를 일으켰을 만한 지점을 비교적 잘 좁힐 수 있기 때문이다.

5. 테스트가 용이하다.

정확히 말하면 유닛 테스트가 용이하다. 유닛 테스트를 하려면 테스트 대상을 의존성으로부터 고립시킬 수 있어야 한다. 객체끼리 느슨하게 결합되어 있으면 테스트 대역으로 치환하기가 쉽다.

유닛 테스트의 필요성이나 코드 구조의 테스트 용이성을 높게 평가하지 않는 사람도 있을거다. Jetbrain의 2021년 개발자 설문을 보면 62%의 스위프트/Obj-C 개발자가 유닛 테스트를 작성하지 않는다고 한다. 그러나 자동화된 테스트의 이점을 한번이라도 경험해보면 (과장 조금 보태서) 테스트 코드를 안짜던 시절로 돌아갈 수 없다.

유닛 테스트는 상당한 테스트 업무를 자동화할 수 있게 해준다. 그랩에선 100+ 여 명의 개발자가 한달에도 수십 만 줄의 앱 코드를 생산하고 있는데, 유닛 테스트 없이 새로운 코드와 기존 코드의 동작을 전부 수동으로 검사하기란 실질적으로 불가능하다. 그랩에서 우리 팀이 새로 만들어졌을 때 만해도 코드 커버리지가 낮았지만, 1년 넘게 테스트를 추가한 결과 실제로 회귀 버그와 중대 버그의 수가 눈에 띄게 줄었다.

마무리

엉클밥에 의하면 객체 지향 언어가 개발자에게 쥐어준 가장 강력한 무기는 다형성을 안전하게 쓸 수 있게 된 것이라고 한다. 다형성이 안전해진 덕분에 개발자는 본인의 시스템이 의존하고 있는 모든 구현체(implementation detail)를 교체 가능한 플러그인으로 만들어 버릴 수 있다. 시스템 사이, 모듈 사이의 결합을 느슨하게 만들 수 있게 됐다. 엉클밥은 더 나아가, 이렇게 할 방법이 있다는걸 알면서 시스템을 이런식으로 디자인하지 않을 이유가 대체 무엇이겠냐고 반문한다. (The Future of Programming Languages 강연 중)

Tags: loose coupling, interface, dependency injection  

팀워크

얼핏보면 개발자는 각자 컴퓨터랑만 일하는거 같아 보인다. 하지만 보이지 않는 팀워크가 조직의 실행력 뿐 아니라 코드 품질과 개인의 성장까지도 결정한다. 여러 팀을 거치며 동료를 다양하게 많이 만날수록 팀 스포츠를 하고 있다는 생각을 한다. 똑같은 프론트엔드 개발자라 하더라도 누군가는 손이 빠르고, 누군가는 설계를 잘하고, 누군가는 UI를 매우 잘 만들고, 누군가는 멘토링을 잘하고, 누군가는 분위기 메이커 역할을 잘하는 등 여러 포지션을 나눠 가지고 있다. 그리고 의사결정을 할 때도 기술적으로 딱 떨어져서 만장일치가 되는건 환상에 가깝다. 팀이 처한 상황에 따라, 경험이나 능력에 따라, 또는 누군가의 영향력에 따라 유동적이다. 같은 문제라도 팀마다 다른 해결책을 도출해낸다.

그래서 중요한게 팀워크인거 같다. 문제 상황이 닥쳐도 유연하게 대처하고 빨리 회복하게 해주는 원동력이다. 그리고 팀워크의 기초는 안전감과 신뢰라고 생각한다.

개인을 탓하지 않는 분위기

문제가 발생했을때 일을 맡았던 담당자나 문제 코드를 작성한 개발자를 탓하는건 쉽다. 하지만 이건 심리적 안전감을 해치는 정말 나쁜 문화다. 게다가 개인의 잘못이나 실수라고 여기고 끝내면 그 팀은 똑같은 유형의 문제를 나중에 또 겪을거다. 문제 자체보다는 ‘누가’ 일으켰는지만 기억에 남기 때문이다. 문제와 사람을 분리하지 않고 문제 자체를 더 깊게 파고 들어가보지 않았을 것이다. 그러면 팀원들은 이번엔 나만 아니길 바라며 조마조마한다.

예전 조직장님은 문제를 수습한 이후에 꼭 팀을 모아놓고 이렇게 말하셨다. “문제를 피하고 싶으면 아무것도 안하면 된다. 레거시도 잘 돌아가니까 그냥 두고 새로운 도전도 하지 말고. 그런데 우리는 그러면 안된다. 계속 발전하고 성장해야 한다. 문제를 겪었으면 재발 방지책을 철저히 세우고 또 도전하면 된다”고 독려했다.

예전 매니저도 문제 발생 상황시 팀 전체가 모여 해결책을 논의하는 자리는 언제나 이런 말로 회의를 열었다. “누구를 탓하고 추궁하려고 모인게 아니다. 여기 있는 누구라도 이런 실수를 할 수 있었고 그렇기 때문에 앞으로 똑같은 실수를 우리 팀에서 원천 차단할 수 있는 해결책을 마련하기 위해 모인 미팅이다.”

자신이 문제를 일으켰다는게 밝혀지면 사람은 본능적으로 자신을 방어하게 된다. 다른 사람이 하는 말들이 자신과 자신의 능력에 대한 비판으로 들린다. 그래서 리더가 더 적극적으로 이런 분위기를 만들어서 문제와 사람을 분리하게끔 유도하면, 개인은 안전감을 느끼고 이걸 토대로 팀 차원에서 문제를 해결하고 방지책을 세울 수 있다.

머리로 하는 회고

문제와 사람을 분리하고나서 하는 냉철한 회고는 성장통과 같다. 당사자 입장에서는 부끄럽고 곤욕스러울 수 있으나 자신의 인격에 화살이 향하는게 아니라는 안전감이 있으므로 문제 해결과 재발 방지를 위해 무슨 일이 있었는지 투명하게 공개해서 팀이 함께 대처하고 회복할 기회를 얻을 수 있다.

그랩에서는 핫픽스를 하게 되면 몇 주 내로 공개적인 회고를 한다. 회고에 앞서 미리 사후 보고서를 양식에 맞게 채워놓아야 한다. 문제 조치한 시각표, 사고의 영향, 원인, 방지 대책 등 최대한 구체적이고 자세히 적는다. 그리고 1시간의 회고 시간 동안 개발자 수십명이 모여 날카로운 질문을 던지고 해결책을 제안을 하며 집단 지성을 발휘한다. 얼버무리면서 넘어갈 틈은 없다.

처음 참석했을 때는 제 3자가 들어도 살벌하다고 느낄 정도로 직설적이어서 흠칫하기도 했다. 하지만 계속 듣다보니 모두가 한 마음으로 모였다는 걸 알 수 있었다. 청문회가 아니라 작전 회의인거다. 최대한 감정을 빼고 차갑게 회고를 하면 함께 성장할 수 있다.

같이 성장하려는 자세

오랜 멘토님은 프로그래밍 실력을 언급할 때마다 개인이 아니라 팀을 주어로 놓고 말씀할 때가 많았다. 전체적인 코드의 품질이나 코드 리뷰의 수준은 가장 잘하는 개발자가 아니라 팀의 평균 실력을 따라간다는 것이다. 그래서 우리가 문제를 더 잘 해결하려면 누군가 혼자만 잘해서는 안되고 팀원 전체가 같이 성장해야 한다. 스터디를 지속적으로 만들고, 또 열심히 참여해서 지식을 나누는 개발자들은 이걸 아는게 틀림없다.

아주 가끔씩 그런 개발자가 있다. 새로운 팀에 오자마자 레거시의 잘못된 부분을 죄다 지적하고, 본인의 기준에만 맞춰 코드 리뷰를 하면서 기존 팀원들을 깎아 내린다. 레거시란 어제까지는 최선의 선택이었다는 말이 있다. 자신이 새롭게 기여할 점이 보인다면 팀원들을 설득하고 지식을 전파해서 팀의 평균을 끌어 올리는게 맞다고 생각한다. 자신과 팀을 분리해서 생각하면 양쪽 모두에게 이로운게 없다.

사람들은 혼자 돋보이려는 사람과 진심으로 팀을 위해 헌신하는 사람을 아주 잘 구분할 수 있다. 선의와 친절로 서로를 대하는 사람들 사이에는 신뢰가 생기고, 반면에 혼자만 잘하려고 하는 사람은 팀워크를 해친다. 그래서 어떤 선배 개발자는 채용할 때 인성이 제일 중요하다고 말하고, 어떤 유명 코치는 개인의 능력이 아니라 그 사람의 태도를 보고 채용해야 한다고 말하는 것 같다.

Tags: teamwork, culture