들어가며: 왜 지금 Jetpack Compose인가
안드로이드 UI를 XML로만 짜오다가 처음 Jetpack Compose를 접했을 때 솔직히 좀 당황했습니다. "코드로 화면을 그린다고?" 싶었거든요. 그런데 막상 몇 주 써보니 다시는 XML 레이아웃으로 돌아가고 싶지 않더라고요. 이 글에서는 제가 실제 프로젝트에 Jetpack Compose를 도입하면서 느낀 점과, 입문자가 꼭 알아야 할 핵심을 솔직하게 정리해보려 합니다.
Compose가 등장한 배경
기존 안드로이드 개발은 XML로 레이아웃을 짜고, 코드에서 findViewById나 ViewBinding으로 뷰를 찾아 데이터를 연결하는 방식이었습니다. 화면이 복잡해질수록 XML과 Kotlin 코드를 오가며 동기화하는 일이 정말 번거로웠죠. Jetpack Compose는 이 두 세계를 하나로 합쳐, 오직 Kotlin 코드만으로 선언적(declarative)으로 UI를 작성하게 해줍니다.
선언형 UI라는 패러다임
핵심은 "어떻게 그릴지"가 아니라 "무엇을 보여줄지"만 선언한다는 점입니다. 상태(state)가 바뀌면 Compose가 알아서 화면을 다시 그려줍니다. React나 SwiftUI, Flutter를 다뤄본 분이라면 금방 익숙해질 거예요. 저처럼 크로스플랫폼을 오가는 개발자에게는 이 일관된 사고방식이 특히 반갑습니다.
Jetpack Compose 시작하기
이론보다 중요한 건 직접 짜보는 것입니다. 환경 설정은 생각보다 간단합니다.
개발 환경 준비
최신 Android Studio를 설치하면 Compose 프로젝트 템플릿이 기본 제공됩니다. "Empty Compose Activity"를 선택하면 Kotlin 기반의 Compose 프로젝트가 바로 생성되죠. 별도의 복잡한 설정 없이 Gradle에 Compose BOM 의존성만 추가되어 있으면 끝입니다. Kotlin과 Compose는 사실상 한 몸이라, Kotlin에 익숙할수록 학습 곡선이 완만해집니다.
첫 번째 Composable 함수
Compose의 UI 단위는 @Composable 어노테이션이 붙은 함수입니다. 예를 들어 @Composable fun Greeting(name: String) 안에서 Text("Hello $name")를 호출하면 화면에 텍스트가 나타납니다. 함수 하나가 하나의 UI 조각이 되고, 이걸 레고처럼 조합해 화면을 완성합니다. 처음엔 낯설지만, 재사용 가능한 컴포넌트를 만드는 감각이 금방 손에 붙습니다.
상태 관리와 리컴포지션
Compose에서 가장 중요한 개념이 바로 상태입니다. remember와 mutableStateOf를 함께 쓰면 값이 바뀔 때마다 해당 UI만 다시 그려지는데, 이를 리컴포지션(recomposition)이라고 합니다. 버튼을 누를 때마다 숫자가 올라가는 카운터 예제를 직접 만들어보면 "아, 이래서 상태 기반이구나" 하고 감이 옵니다.
실전에서 얻은 사용 팁
문서만으로는 알기 어려운, 직접 부딪히며 배운 팁을 공유합니다.
Preview를 적극 활용하기
첫 번째 팁은 @Preview 어노테이션입니다. 에뮬레이터를 띄우지 않아도 Android Studio 우측 패널에서 UI를 실시간으로 확인할 수 있어요. 다크 모드, 다양한 화면 크기를 동시에 미리보기로 띄워두면 작업 속도가 체감상 두 배는 빨라집니다. 이것 하나만으로도 Compose를 쓸 이유가 충분하다고 느낄 정도였습니다.
상태 끌어올리기(State Hoisting)
두 번째 팁은 상태를 컴포넌트 안에 가두지 말라는 것입니다. 상태를 상위로 끌어올리고 자식 컴포넌트에는 값과 콜백만 넘기면, 재사용성과 테스트 용이성이 크게 올라갑니다. 처음엔 귀찮게 느껴져도, 화면이 커질수록 이 습관이 코드를 살립니다.
Modifier 순서에 주의하기
세 번째 팁은 Modifier의 순서입니다. padding을 background 앞에 두느냐 뒤에 두느냐에 따라 결과가 완전히 달라집니다. Modifier는 위에서 아래로 순서대로 적용되기 때문이죠. 의도와 다르게 UI가 나온다면 십중팔구 Modifier 순서 문제입니다. 네 번째 보너스 팁으로, 무거운 리스트는 LazyColumn을 써서 보이는 항목만 렌더링하면 성능이 확 좋아집니다.
장단점 솔직 비교
좋은 점만 늘어놓으면 신뢰가 안 가겠죠. 기존 XML 방식과 비교해 정리했습니다.
| 구분 | 장점 | 단점 |
|---|---|---|
| 개발 생산성 | XML과 코드 분리가 사라져 보일러플레이트가 대폭 감소 | 기존 XML 자산을 점진적으로 마이그레이션해야 함 |
| 학습 곡선 | Kotlin 한 언어로 통일, 선언형 사고에 익숙하면 빠름 | 리컴포지션·상태 개념을 제대로 이해하기 전엔 혼란 |
| 유지보수 | 컴포넌트 재사용과 미리보기로 관리가 편리 | 잘못된 상태 설계 시 불필요한 리컴포지션으로 성능 저하 |
| 생태계 | 구글이 미는 표준, 자료와 라이브러리 빠르게 성장 | 일부 오래된 서드파티 라이브러리는 호환 작업 필요 |
마무리: 누구에게 추천할까
몇 주간 Jetpack Compose를 실무에 써본 결론은 명확합니다. 초기 학습 비용은 분명 있지만, 그걸 충분히 상쇄하고도 남는 생산성을 줍니다.
이런 분께 강력 추천
새 안드로이드 프로젝트를 시작하는 분, Kotlin에 어느 정도 익숙한 분, 그리고 React나 Flutter 같은 선언형 UI를 경험한 크로스플랫폼 개발자라면 망설일 이유가 없습니다. 신규 프로젝트라면 처음부터 Jetpack Compose로 시작하는 걸 적극 권합니다.
이런 경우엔 신중하게
반대로 대규모 레거시 XML 프로젝트를 운영 중이라면 전면 전환보다는, 화면 단위로 Compose를 섞어 쓰는 점진적 도입을 추천합니다. Compose는 기존 View 시스템과 공존할 수 있으니까요. 결국 Jetpack Compose는 안드로이드 UI 개발의 현재이자 미래입니다. 지금 시작하는 게 가장 빠른 선택이라고 자신 있게 말씀드릴 수 있습니다.