젊은 모바일 개발자의 슬픔 (부제: 회사 미워!!)

윤성현·2026년 1월 25일

서론

"16GB 맥북에어인데, 개발하기엔 충분하지 않나요? 🤔"

최근 회사에서 장비 요청을 했다가 이런 질문을 받았다. 이 내용을 옆자리 웹 개발자 동료에게 얘기했는데, 16GB RAM 맥북 에어로도 충분해서 공감이 어렵다는 답변을 받았다. 왜 모바일 개발자만 유독 높은 사양이 필요한걸까?

이 글은 그 질문에 대한 답이다. Android 개발(그리고 전반적인 모바일 개발)이 왜 더 많은 컴퓨팅 자원을 필요로 하는지, 기술적인 근거와 함께 정리해보려고 한다. 언젠가 장비 요청서를 쓰거나, 회사나 팀에 설명해야 할 때 참고가 되었으면 한다.

본론

1. 개발 환경 자체가 다르다

웹 개발 환경

웹 개발자의 일반적인 개발 환경을 생각해보자.

도구	용량
VS Code	~200MB
Node.js + npm packages	프로젝트별 수백MB
브라우저	이미 설치되어 있음
터미널	-

VS Code는 200MB도 채 되지 않는 가벼운 에디터다. 공식 문서에 따르면 1GB RAM만 있어도 동작한다고 명시되어 있다. 물론 실제로 개발하려면 4GB 정도는 있어야 쾌적하지만, 그래도 이 정도면 요즘 나오는 웬만한 컴퓨터에서는 문제가 없다.

코드를 작성하고 저장하면? 브라우저에서 바로 결과를 확인할 수 있다. Hot Reload 덕분에 수 초 내로 변경사항이 반영된다. 컴파일이라는 과정 자체가 필요 없거나, 있더라도 매우 빠르다.

Android 개발 환경

이제 Android 개발자의 개발 환경을 보자.

도구	용량
Android Studio (IDE만)	~1.5GB
Platform Tools	~150MB
Build Tools (버전당)	~200MB
Platform/API (버전당)	~200MB
시스템 이미지 (버전당)	1~2GB
Gradle 캐시	프로젝트별 수백MB ~ 수GB
에뮬레이터 실행 시	2~4GB RAM 사용

Android Studio의 공식 시스템 요구사항을 보면, 최소 8GB RAM을 요구한다. 그리고 이건 정말 "최소"다. Google은 32GB를 권장하고 있으며, 실제로 8GB로 개발하면 IDE가 버벅거리고, 에뮬레이터를 띄우는 순간 시스템 전체가 느려지는 것을 경험하게 된다.

디스크 용량도 마찬가지다. IDE + SDK + 에뮬레이터 이미지를 기본으로 설치하면 최소 8GB가 필요하고, 여러 API 레벨을 테스트하거나 프로젝트 규모가 커지면 금방 50GB 이상을 차지하게 된다.

숫자로 비교해보자

항목	웹 개발 (VS Code)	Android 개발
IDE 용량	~200MB	~1.5GB
SDK/도구 용량	수백MB	10GB+
최소 RAM	1GB	8GB
권장 RAM	4GB	32GB
권장 디스크	수 GB	50GB+ SSD

같은 "개발"이라는 작업을 하는데, 요구 사양이 8배 정도 차이난다.

2. 빌드 과정의 근본적인 차이

"코드 한 줄 고쳤는데 왜 이렇게 오래 걸려요?"

이 질문에 대한 답은 컴파일 언어와 인터프리터 언어의 차이에서 시작한다.

웹 개발의 피드백 루프

JavaScript는 인터프리터 언어다. 코드를 작성하면 브라우저가 그 코드를 바로 실행한다. 별도의 컴파일 과정이 없다.

코드 수정 → 저장 → 브라우저 새로고침 → 결과 확인
           └────────── 수 초 ──────────┘

React나 Vue 같은 프레임워크를 사용하더라도, Webpack이나 Vite 같은 번들러가 변경된 부분만 빠르게 다시 빌드해준다. Hot Module Replacement(HMR) 덕분에 페이지 새로고침 없이도 변경사항이 즉시 반영되는 경우도 많다.

Android 빌드 과정

반면 Android 개발에서 사용하는 Kotlin과 Java는 컴파일 언어다. 코드를 작성한 후, 그 코드를 기계가 이해할 수 있는 형태로 변환하는 컴파일 과정이 반드시 필요하다.

Android 빌드 과정을 단계별로 살펴보면,

단계	설명	디버그 빌드
1. Configuration Phase	Gradle이 빌드 스크립트를 분석하고 태스크 그래프 생성	✅ 동일
2. 의존성 해결	프로젝트의 모든 라이브러리를 확인하고 다운로드	✅ 동일
3. 코드 컴파일	Kotlin/Java → Bytecode 변환	✅ 동일
4. 리소스 처리	drawable, layout, values 등 XML 처리, R.java 생성	✅ 동일
5. 코드 난독화/최적화	R8(ProGuard)로 코드 난독화 및 최적화	⏭️ 생략
6. 리소스 축소	미사용 리소스 제거	⏭️ 생략
7. DEX 변환	JVM 바이트코드 → Android Runtime용 DEX 변환	✅ 동일
8. APK 패키징	DEX + 리소스 + 네이티브 라이브러리 → APK	✅ 동일
9. 서명	앱에 디지털 서명 추가	🔑 디버그 키로 자동 서명

디버그 빌드에서는 난독화와 리소스 축소가 생략되어 릴리즈보다 빠르지만, 그래도 대부분의 단계는 여전히 필수다. 이 과정이 순차적으로, 때로는 병렬로 실행된다. 프로젝트가 커질수록 각 단계에서 처리해야 할 양이 늘어나고, 빌드 시간은 기하급수적으로 증가한다.

Gradle이 느린 이유

Gradle은 강력하지만, 그만큼 무겁다. 근본적으로 느린 이유를 살펴보자.

1️⃣ JVM 기반이다

Gradle은 JVM 위에서 동작한다. 빌드를 시작하면 JVM이 먼저 부팅되어야 하고, 클래스들을 로딩하고, JIT 컴파일이 진행된다. Gradle Daemon이 이 문제를 완화해주지만, 첫 빌드나 Daemon이 죽은 후에는 이 오버헤드를 피할 수 없다.

2️⃣ Configuration Phase가 매번 실행된다

Gradle은 실제 빌드 작업을 수행하기 전에 모든 빌드 스크립트를 평가한다. build.gradle.kts 파일들을 파싱하고, 플러그인을 로딩하고, 태스크 그래프를 구성한다. 모듈이 10개든 100개든, 이 과정은 매 빌드마다 실행된다.

3️⃣ 의존성 그래프 해석

Android 프로젝트는 수십~수백 개의 라이브러리에 의존한다. Gradle은 이 모든 의존성의 버전을 확인하고, 충돌을 해결하고, 다운로드 여부를 판단해야 한다. 의존성이 많을수록 이 과정이 길어진다.

4️⃣ 증분 빌드의 한계

Gradle은 변경된 부분만 다시 빌드하는 증분 빌드를 지원한다. 하지만 어떤 파일이 변경되면 어디까지 다시 빌드해야 하는지 판단하는 것 자체가 복잡하다. 특히 api로 선언된 모듈이 변경되면 그걸 사용하는 모든 모듈이 재컴파일된다.

5️⃣ Annotation Processing (kapt)

Room, Dagger/Hilt 같은 라이브러리들은 어노테이션 프로세싱을 사용한다. kapt는 Kotlin 코드를 Java stub으로 변환한 후 어노테이션 프로세서를 실행하는데, 이 과정이 각 모듈마다 별도로 실행된다. 모듈이 많을수록 이 오버헤드가 누적된다.

6️⃣ I/O 병목

빌드 과정에서 수천 개의 파일을 읽고 쓴다. 캐시 확인, 중간 결과물 저장, 최종 APK 생성까지 디스크 I/O가 끊임없이 발생한다. 아무리 로직이 빨라도 I/O가 병목이 되면 빌드 시간이 늘어난다.

실제로 얼마나 차이날까?

상황	웹 (React)	Android (Kotlin)
개발 서버 시작	1~5초 (Vite 기준)	3~5분 (첫 빌드)
코드 1줄 수정	1~3초 (HMR)	30초 ~ 2분
의존성 추가 후	서버 재시작 수 초	1~3분
프로덕션 빌드	30초 ~ 1분	5~10분

코드 한 줄 수정하고 결과를 확인하는 데 웹은 수 초, Android는 수십 초에서 수 분이 걸린다. 하루에 수십 번, 수백 번 빌드를 한다고 생각하면, 이 차이가 생산성에 미치는 영향은 상당하다.

3. 왜 고사양 장비가 필요한가

2번에서 빌드가 느린 이유를 살펴봤다. 그렇다면 왜 좋은 장비가 필요할까? 느린 건 어쩔 수 없는 거 아닌가?

결론부터 말하면, 장비 사양이 곧 빌드 시간이다.

메모리: 동시에 돌아가는 JVM들

Android 개발의 핵심 도구들은 전부 JVM 위에서 동작한다.

Android Studio (IntelliJ 기반)
Gradle
Kotlin 컴파일러

JVM은 시작할 때 메모리를 힙(Heap)으로 미리 할당받는다. 그리고 이 도구들은 각각 별도의 JVM 프로세스로 실행된다. 즉, 빌드 한 번 하면 여러 개의 JVM이 동시에 메모리를 잡아먹는다.

프로세스	메모리 사용량
Android Studio IDE	1.5 ~ 3GB
Gradle Daemon	1 ~ 2GB
Kotlin Compiler Daemon	500MB ~ 1GB
에뮬레이터	2 ~ 4GB
합계	최소 5GB, 보통 8GB 이상

여기에 Chrome 탭 몇 개, Slack, Figma 정도만 띄워도 8GB는 순식간에 바닥난다. 16GB도 빠듯하게 느껴지는 이유다.

CPU: 코어가 곧 빌드 속도

Gradle은 병렬 빌드를 지원한다. 여러 모듈을 동시에 컴파일하고, 여러 파일을 동시에 처리한다. 하지만 이건 CPU 코어가 충분할 때 이야기다.

요즘 맥북 기준으로 보면, M3 (8코어)와 M3 Pro (12코어)의 빌드 시간 차이는 체감할 수 있을 정도로 크다. 코어가 많을수록 병렬 처리 효율이 올라간다.

극단적인 예로, Google 공식 문서에서 AOSP 빌드 사례를 보면,

환경	풀 빌드 시간
72코어, 64GB RAM	약 40분
6코어, 64GB RAM	약 6시간

코어 수 12배 차이에 빌드 시간 9배 차이. 물론 이건 AOSP라는 초대형 프로젝트의 극단적인 사례지만, 코어 = 생산성이라는 공식은 일반 프로젝트에서도 유효하다.

웹 개발자는 왜 저사양으로도 되는가?

반면 웹 개발은 상황이 다르다.

항목	웹 개발	Android 개발
IDE	VS Code (Electron, 가벼움)	Android Studio (JVM, 무거움)
빌드	없거나 매우 빠름	매번 컴파일 필수
테스트 환경	브라우저 (이미 있음)	에뮬레이터 (2~4GB RAM)
병렬 처리 필요성	낮음	높음

웹 개발자가 8GB 맥북 에어로 충분한 이유는, 무거운 작업 자체가 없기 때문이다. 컴파일도 없고, 에뮬레이터도 없고, JVM도 없다.

4. 에뮬레이터의 무게

웹 개발자는 테스트할 때 브라우저만 있으면 된다. 브라우저는 이미 모든 컴퓨터에 설치되어 있고, 추가 리소스를 거의 사용하지 않는다.

Android 개발자는 다르다. 실제 디바이스가 없으면 에뮬레이터를 사용해야 한다.

Android 에뮬레이터가 무거운 이유

Android 에뮬레이터는 실제 Android 기기를 가상화한다. 이는 다음을 의미한다.

전체 OS 실행: Android 운영체제 전체를 메모리에 로드
하드웨어 에뮬레이션: CPU, GPU, 센서 등을 소프트웨어로 시뮬레이션
시스템 이미지: API 레벨별로 1~2GB의 시스템 이미지 필요

하나의 에뮬레이터가 2~4GB의 RAM을 사용한다. 여러 화면 크기나 API 레벨을 테스트하기 위해 여러 에뮬레이터를 동시에 실행하면? RAM이 순식간에 고갈된다.

에뮬레이터 시스템 이미지 용량

여러 API 레벨을 테스트해야 하는 경우,

API 레벨	Android 버전	시스템 이미지 용량
API 34	Android 14	~1.5GB
API 33	Android 13	~1.5GB
API 31	Android 12	~1.2GB
API 29	Android 10	~1.0GB
API 26	Android 8	~900MB
합계	-	~6GB

여기에 각 에뮬레이터의 사용자 데이터, 스냅샷 등을 포함하면 용량은 더 늘어난다.

5. React Native는 더하다

여기까지가 Android 네이티브 개발의 이야기다. 그런데 React Native로 개발한다면? 상황은 더 심각해진다.

React Native 개발 환경의 특수성

React Native는 "한 번 작성하고, 양 플랫폼에서 실행한다"는 철학을 가지고 있다. 이 말은 곧, Android와 iOS 개발 환경이 모두 필요하다는 뜻이다.

구분	도구	용량/리소스
공통	VS Code	~200MB
공통	Node.js + npm	수백MB
공통	Metro Bundler	실행 시 ~300MB RAM
Android	Android Studio	~1.5GB
Android	Android SDK	10GB+
Android	에뮬레이터	실행 시 2~4GB RAM
iOS	Xcode	~15GB
iOS	iOS 시뮬레이터	각 5GB+
iOS	시뮬레이터	실행 시 2~3GB RAM

양 플랫폼 동시 테스트의 현실

React Native 개발의 일반적인 워크플로우를 생각해보자. 코드를 작성하고, 그 결과를 확인하려면,

Metro Bundler 실행 (JS 코드 번들링)
Android 에뮬레이터에서 확인
iOS 시뮬레이터에서 확인

"양쪽 다 잘 동작하는지" 확인하려면, 에뮬레이터와 시뮬레이터를 동시에 띄워야 한다.

이때의 메모리 사용량,

프로세스	메모리 사용량
VS Code	~500MB
Metro Bundler	~300MB
Android Studio (백그라운드)	~1GB
Android 에뮬레이터	~3GB
Xcode (백그라운드)	~1.5GB
iOS 시뮬레이터	~2.5GB
Chrome (문서 참고용)	~1GB
Slack	~500MB
합계	약 10GB 이상

⚠️ 16GB RAM으로도 빠듯하다. 32GB가 있어야 쾌적하게 개발할 수 있다.

디스크 용량은?

React Native 개발 환경의 디스크 사용량

항목	용량
Android Studio + SDK	~15GB
Xcode + 시뮬레이터	~50-60GB
Node.js + npm	~수백MB
프로젝트 node_modules	500MB ~ 1GB (프로젝트당)
합계	최소 70GB, 권장 120GB+

256GB SSD로는 여유 공간이 거의 남지 않는다. React Native 개발을 하려면 512GB 이상을 권장한다.

빌드 시간은?

React Native의 빌드 과정은 크게 두 부분으로 나뉜다.

JavaScript 번들링 (Metro): 비교적 빠름 (수 초 ~ 수십 초)
네이티브 빌드 (Gradle/Xcode): Android 네이티브와 동일하게 느림

특히 네이티브 모듈을 사용하거나, 앱을 처음 빌드할 때

빌드 대상	초기 빌드 시간
Android	3~5분
iOS	3~5분
합계	6~10분 (순차 빌드 시)

코드 수정 후 Hot Reload가 동작하면 빠르지만, 네이티브 코드를 건드리거나 의존성을 추가하면 풀 빌드가 필요하다.

결론

모바일 개발자가 더 높은 사양의 장비를 필요로 하는 것은 사치가 아니라 필수다.

Android 네이티브 개발의 경우

개발 도구 자체가 무겁다: Android Studio와 SDK는 웹 개발 도구에 비해 10배 이상 무거운 환경이다.
컴파일이 필수다: 코드 수정 → 결과 확인까지 웹은 수 초, Android는 수십 초에서 수 분이 걸린다.
JVM 기반 도구들이 메모리를 많이 사용한다: IDE, Gradle, 컴파일러가 모두 GB 단위의 메모리를 요구한다.
병렬 처리가 중요하다: CPU 코어가 많을수록 빌드 시간이 단축된다.
에뮬레이터가 추가 리소스를 사용한다: 테스트 환경 자체가 무겁다.

React Native 개발의 경우

위의 모든 이유에 더해,

Android와 iOS 환경이 모두 필요하다: 저장 공간이 2배로 필요하다.
에뮬레이터와 시뮬레이터를 동시에 실행한다: 메모리 사용량이 급격히 증가한다.
세 가지 패키지 매니저를 관리한다: npm, Gradle, CocoaPods 각각의 캐시가 쌓인다.

비용 관점에서 생각해보면

빌드 한 번에 5분이 걸리는 환경에서 일하는 것과, 1분이 걸리는 환경에서 일하는 것의 차이는 단순히 4분의 차이가 아니다.

하루에 30번 빌드를 한다면,

빌드 시간	하루 총 빌드 대기 시간
5분 × 30회	150분 = 2시간 30분
1분 × 30회	30분
차이	하루 2시간

한 달이면 40시간, 1년이면 480시간이다.

개발자 연봉을 시급으로 환산하면, 좋은 장비에 투자하는 것이 싼 장비를 쓰면서 개발자의 시간을 낭비하는 것보다 훨씬 경제적이다.

이 글이 장비 요청서를 쓰거나, 비개발 직군에게 설명해야 할 때 도움이 되었으면 한다.
우리 모두 쾌적한 환경에서 개발합시다. 🙏

윤성현

이전 포스트