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

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

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

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

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

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

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

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

Swift로 치면,

이 원칙을 클래스 → 모듈 → 패키지 수준까지 확장하는 것이다.

즉,

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

라는 개념이다.

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

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

예를 들면:

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

이렇게 하면,

를 동시에 가져갈 수 있다.

Export 모듈 패턴

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

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

개발 환경에서는:

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

이를 위해 다음과 같은 구조를 사용한다.

AppDev (개발 환경)

@_exported import DatabaseClient
@_exported import NetworkClient

AppLive (프로덕션 환경)

@_exported import DatabaseClientLive
@_exported import NetworkClientLive

이렇게 하면,

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

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

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

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

하지만 내가 느낀 가장 큰 이유는 따로 있다.

프로덕션 프로젝트는 결국 무거워진다

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

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

프로젝트가 작아도,

빠른 개발 속도에 대한 집착

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

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

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

이 생산성이 정말 말이 안 된다.

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

정리

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

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

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