Jacob's Tech Tavern — Designing The Perfect Modular Architecture (2026-07-29)
원문: https://blog.jacobstechtavern.com/p/modular-ios-architecture
핵심 요약
- MVC·MVVM 같은 화면 레이어 논쟁 대신 모듈 간 경계 설계, 즉 진짜 "아키텍처"를 다룬다.
- 화면 단위 파일 구조 선택은 일관성 문제일 뿐, 제대로 된 아키텍처가 아니다.
- 진짜 아키텍처는 building block들이 어떻게 맞물리는지를 설계하는 과학이자 예술이다.
- 모듈형 iOS 아키텍처의 필요성, 의존성 그래프 개념, 10년간 경험한 아키텍처들, Granola 실제 설계 사례를 다룬다.
- 좋은 iOS 코드베이스 다수는 단일 모듈 덩어리로 시작해 초반엔 잘 작동한다.
- 모놀리식 모듈이 커지면 작은 변경도 의존성 그래프 전체를 무효화시켜 빌드가 느려진다.
- 단일 모듈에서는 internal이 기본이라 진짜 경계를 강제하기 어렵고 규율에 의존해야 한다.
- 아키텍처는 조직 형태를 반영하며 성장, 플랫폼 팀은 Core 모듈을, 피처 팀은 파드 단위 모듈을 만든다.
- 팀 구조와 코드 경계가 어긋나면 소유권 불명확, 중복 구현, API 불일치가 발생한다.
- 모듈화는 캡슐화를 강제하고 재사용을 장려하며 병렬 작업을 가능하게 한다.
- 모듈화는 재컴파일 범위를 줄여 빌드를 개선하지만 과도하면 오히려 느려진다.
- Granola의 모듈형 재설계는 팀 성장과 코드베이스 신호가 맞물려 시작됐다.
- 도구는 SPM이 기본이며 저자는 Tuist를 선호, CocoaPods·Carthage는 사실상 지원 종료로 본다.
- static·dynamic·mergeable 라이브러리 선택은 빌드 속도, 번들 크기, 실행 시간의 균형 문제다.
- 의존성 그래프에서 노드는 의존성이 모두 컴파일돼야 컴파일 가능, 리프부터 앱 모듈까지 순서대로 빌드된다.
- 스파게티 구조는 작은 변경이 그래프 전역 수십~수백 모듈을 무효화시켜 빌드를 느리게 만든다.
- Tuist TMA·Feature Interface의 핵심은 퍼블릭 인터페이스만 유지되면 내부 변경 시 의존 모듈이 재컴파일되지 않는다는 통찰이다.
- 저자는 2.5년 전 확장성 문제 있던 초기 모듈형 아키텍처 글을 부끄러워했고, 이후 단순함의 가치를 더 존중하게 됐다.
- 이어지는 유료 본문에서는 단일 모듈부터 하이퍼모듈형까지 아키텍처 문제점과 서비스&오케스트레이션 레이어, API 계약 기반 해법을 다룬다.
- 마지막 절에서는 이 학습을 Granola iOS 앱에 실제 적용한 설계 과정과 대규모 리팩토링 경험을 공유한다.
전체 번역 노트: Study/뉴스레터/2026-07-29-Jacobs.md (개인 Obsidian 보관용)