THE STEADY COMPANY
1인 또는 소규모 환경에서도 모듈을 열심히 나눠야 하는 이유 cover image

1인 또는 소규모 환경에서도 모듈을 열심히 나눠야 하는 이유

안전하면서 빠른 속도를 유지하는 방법

2025-01-16 22:00

·
  • iOS
  • Modularization
  • Architecture
  • Productivity
  • Build

들어가며

1인 개발이나 소규모 팀에서 모듈화를 이야기하면 종종 이런 질문을 받아요.

"이 정도 규모에서 굳이 이렇게까지 나눌 필요가 있을까?"

저도 같은 고민을 했고, 실제로 초반에는 단일 타겟, 단일 패키지로 시작했어요.
하지만 경력이 쌓이고 불편한 점이 생기면서 생각이 바뀌었어요.

모듈화는 단순히 구조를 예쁘게 나누는 작업이 아니라,
개발 속도와 빌드 성능, 그리고 사고의 복잡도를 줄이기 위한 도구라는 점을 체감하게 됐거든요.

모듈화는 객체지향의 캡슐화와 닮아 있어요

제가 생각하는 모듈화의 핵심은 객체지향의 캡슐화와 매우 닮아 있어요.

  • 필요한 것만 외부에 노출하고
  • 불필요한 것은 내부로 숨겨요

Swift로 치면,

  • 외부에 꼭 필요한 타입과 API만 public
  • 나머지는 모두 internal

이 원칙을 클래스 -> 모듈 -> 패키지 수준까지 확장하는 거예요.

즉,

"모듈 수준에서도 캡슐화를 한다"

라는 개념이에요.

기능 단위 패키지와 패키지 수준 캡슐화

그래서 최근에는 기능 성격에 따라 패키지를 나누고 있어요.

예를 들면:

  • Platform
  • UI
  • 결제
  • 인증
  • 광고

중요한 점은 단순히 그룹으로만 묶는 것이 아니라,
패키지 내부에서도 외부에 노출할 타겟을 명확히 정한다는 것이에요.

이렇게 하면,

  • 모듈 단위 캡슐화
  • 패키지 단위 캡슐화 (특정 타겟만 열어두는 방식으로)

를 동시에 가져갈 수 있어요.

Export 모듈 패턴

최근에는 export 전용 모듈을 두는 패턴을 적극적으로 사용하고 있어요.
(Flutter에서는 꽤 익숙한 방식이에요.)

개발 환경과 프로덕션 환경 분리

개발 환경에서는:

  • 구현체를 알 필요가 없고
  • 인터페이스만 알면 돼요

반대로 프로덕션 환경에서는:

  • 실제 구현체에 대한 의존성이 필요해요

이를 위해 다음과 같은 구조를 사용하고 있어요.

AppDev (개발 환경)

@_exported import DatabaseClient
@_exported import NetworkClient

AppLive (프로덕션 환경)

@_exported import DatabaseClientLive
@_exported import NetworkClientLive

이렇게 하면,

  • 외부에서는 AppDev 또는 AppLive만 import 하면 되고
  • 내부 의존성 구조를 일일이 신경 쓸 필요가 없어요

모듈 간 의존성 그래프에서 헷갈릴 일이 현저히 줄어들어요.

1인 또는 소규모에서도 모듈화를 해야 하는 진짜 이유

여기까지 보면 이렇게 느낄 수도 있어요.

"그래도 결국 복잡도 줄이기 아닌가?"

하지만 제가 느낀 가장 큰 이유는 따로 있어요.

프로덕션 프로젝트는 결국 무거워져요

아무리 작은 앱이라도, 프로덕션 환경에서는 다음을 피할 수 없어요.

  • Firebase (Analytics, A/B Test)
  • Google / Kakao Login
  • 광고 SDK (AdMob + 미디에이션)
  • 각종 서드파티 SDK

결국 빌드 속도는 느려질 수밖에 없어요.

프로젝트가 작아도,

  • 5초 -> 1초 빌드가 된다면
  • 체감 생산성은 완전히 달라져요

빠른 개발 속도에 대한 집착

요즘 가장 큰 관심사는 압도적으로 빠른 개발 속도예요.

  • Cursor에서 Swift 빌드를 돌리면
    • Xcode 대비 체감상 느린 느낌이 들 때가 있어요
  • 그래서:
    • 핫리로드
    • 필요할 때만 빌드

이 조합을 적극적으로 사용하고 있어요.

Cursor에 룰셋만 잘 정의해두면,

  • UI는 거의 "딸깍" 수준
  • Mock 데이터 생성
  • 테스트 코드 작성

이 생산성이 정말 말이 안 돼요.

복잡한 비즈니스 로직은 아직 손으로 작성하는 게 편한 부분도 있지만,
자동완성과 보조 역할만으로도 충분히 값어치를 한다고 느끼고 있어요.

마치며

결국 제가 생각하는 잘 만든 모듈화의 장점은 다음과 같아요.

  • 계층 구조가 명확해져요
  • 의존성 관리가 쉬워져요
  • 모듈 단위 빌드가 가능해져요
  • 데모 / 샘플 앱을 만들기 쉬워져요
  • 빌드 속도가 빨라져요
  • AI + Mock 기반 개발 생산성이 극대화돼요

특히 데모 앱 환경에서는,
AI가 Mock을 너무 잘 만들어주기 때문에
개발 속도가 눈에 띄게 빨라져요.

1인 개발이든, 소규모 팀이든
모듈화는 '미래를 대비하는 과한 설계'가 아니라
현재 생산성을 높이기 위한 선택이라고 생각해요.