안드로이드 앱 구조 입문 시리즈 (2편) – Activity와 Fragment는 왜 나뉘어 있을까

안드로이드 앱 구조 입문 시리즈 (2편) – Activity와 Fragment는 왜 나뉘어 있을까는 안드로이드 초보자가 아주 자주 막히는 질문을 다룹니다. 화면이 있으면 Activity 하나면 될 것 같은데 왜 굳이 Fragment까지 써야 하는지, 구조 관점에서 설명합니다.

이 글이 시리즈에서 맡는 역할

1편에서는 안드로이드 앱을 화면, 생명주기, 상태, 비동기 작업이 얽힌 구조로 보는 큰 그림을 잡았습니다. 이번 2편은 그 구조 안에서 화면 책임을 어떻게 나누느냐를 다룹니다. 즉 이번 글을 이해하면 뒤에서 나올 ViewModel, 상태 관리, 생명주기 글도 훨씬 자연스럽게 연결됩니다.

시리즈의 첫 글은 안드로이드 앱 구조 입문 시리즈(1편) – 안드로이드 앱은 어떻게 돌아갈까에서 볼 수 있습니다.

Activity 하나로 다 처리하면 왜 힘들어질까

초보자가 처음 앱을 만들 때는 하나의 Activity 안에 모든 것을 넣는 경우가 많습니다. 툴바 처리, 목록 표시, 상세 정보 표시, 버튼 이벤트, 로딩 상태, 에러 메시지, 네비게이션 처리가 한 파일에 모입니다. 처음에는 빠르게 만들 수 있지만 기능이 늘어나면 Activity가 너무 커지고, 어떤 코드가 어떤 화면 책임인지 흐려집니다.

즉 문제는 Activity라는 클래스 자체가 아니라 Activity 하나에 너무 많은 화면 책임을 몰아넣는 구조입니다. 코드가 한 파일에 모여 있으면 찾기는 쉬워 보여도 의미가 섞이기 시작합니다.

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        setupToolbar()
        setupRecyclerView()
        bindProfileHeader()
        bindFeedSection()
        bindRecommendationSection()
        bindBottomNavigation()
        observeUiState()
        loadData()
    }
}

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        setupToolbar()
        setupRecyclerView()
        bindProfileHeader()
        bindFeedSection()
        bindRecommendationSection()
        bindBottomNavigation()
        observeUiState()
        loadData()
    }
}

이 코드는 당장 틀렸다고 말할 수는 없지만 화면 섹션이 늘어날수록 Activity가 점점 모든 것을 아는 클래스가 되기 쉽습니다. 문제는 파일 길이보다 수정 포인트가 한곳에 몰리고 화면 일부를 독립적으로 생각하기 어려워진다는 점입니다.

Activity가 맡는 역할은 무엇일까

Activity는 보통 화면의 진입점이자 안드로이드 시스템과 직접 연결되는 바깥 경계에 가깝습니다. 앱이 열리고, 화면이 보이고, 다른 화면으로 이동하고, 생명주기 변화가 들어오는 큰 흐름을 가장 먼저 받는 위치입니다.

• 화면 진입 관리
• 전체 화면 컨테이너 역할
• navigation 연결
• 시스템 이벤트와 생명주기 접점
• 상위 수준 화면 조립

중요한 점은 Activity가 아무것도 하지 않는 껍데기여야 한다는 뜻은 아니라는 점입니다. 다만 그 책임이 모든 화면 세부 사항을 직접 처리하는 쪽으로 커지면 구조가 무거워집니다.

Fragment는 왜 필요할까

Fragment는 Activity를 대신하는 존재라기보다 화면 책임을 더 잘게 나누기 위한 도구로 이해하는 편이 좋습니다. Activity가 앱 화면의 큰 틀이라면 Fragment는 그 안에서 의미 있는 화면 조각과 그 조각의 책임을 맡는 쪽에 더 가깝습니다.

즉 Fragment를 쓰는 이유는 단순히 화면을 쪼개기 위해서가 아니라 한 화면 안의 역할을 구분하기 위해서입니다. Fragment의 장점은 재사용 이전에 구조를 읽기 쉽게 만든다는 점에 있습니다.

책임 분리가 실제로 어떤 차이를 만들까

구조 A에서는 Activity가 모든 View 참조, 클릭 이벤트, 데이터 표시를 직접 담당합니다. 이 방식은 초반에는 빠르지만 화면이 커질수록 읽기 어려워지고 수정 범위가 커집니다. 구조 B에서는 Activity가 큰 틀을 맡고 Fragment가 자기 화면 조각의 UI와 상호작용을 맡습니다.

즉 Fragment의 가치는 기술적인 화려함보다 구조를 덜 복잡하게 만드는 데 있습니다. 중요한 것은 Fragment를 쓰면 무조건 좋아진다가 아니라, 책임 분리가 필요할 때 Fragment가 강력한 수단이 된다는 점입니다.

간단한 코드로 보면 차이가 더 잘 보인다

목록 화면과 상세 화면을 전부 Activity 하나에 넣으면 구조가 금방 무거워집니다. 반대로 Fragment로 나누면 누가 어떤 화면 책임을 가지는지 더 읽기 쉬워집니다.

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        setupListSection()
        setupDetailSection()
        observeListState()
        observeDetailState()
        bindListEvents()
        bindDetailEvents()
    }
}

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        setupListSection()
        setupDetailSection()
        observeListState()
        observeDetailState()
        bindListEvents()
        bindDetailEvents()
    }
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

class FeedFragment : Fragment(R.layout.fragment_feed) {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        bindFeedList()
        observeFeedState()
    }
}

class DetailFragment : Fragment(R.layout.fragment_detail) {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        bindDetailView()
        observeDetailState()
    }
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

class FeedFragment : Fragment(R.layout.fragment_feed) {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        bindFeedList()
        observeFeedState()
    }
}

class DetailFragment : Fragment(R.layout.fragment_detail) {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        bindDetailView()
        observeDetailState()
    }
}

여기서 중요한 것은 코드 줄 수가 아니라 누가 어떤 화면 책임을 갖는지가 더 잘 보인다는 점입니다. 좋은 구조는 코드를 잘게 찢는 것이 아니라 책임의 경계를 분명하게 만드는 것입니다.

Fragment가 항상 정답은 아니다

초보자가 Fragment를 배우면 반대로 무조건 Fragment를 써야 한다고 생각하기 쉽습니다. 하지만 그것도 아닙니다. 작고 단순한 화면이라면 Activity 하나로도 충분할 수 있습니다. 예를 들어 설정 화면 하나, 소개 화면 하나, 입력 요소가 많지 않은 단순 페이지 같은 경우에는 굳이 Fragment까지 도입하지 않아도 됩니다.

핵심은 Fragment 사용 여부 자체가 아니라 화면 책임이 이미 분리 필요할 만큼 커졌는가를 보는 것입니다. 구조를 단순하게 유지할 수 있다면 단순한 쪽이 더 나을 때도 많습니다.

초보자가 자주 하는 실수

1. Activity를 화면 컨테이너가 아니라 만능 클래스처럼 쓰는 경우
2. Fragment를 도입했지만 실제 책임 분리가 안 된 경우
3. 화면 분리를 구조가 아니라 기술 취향으로만 결정하는 경우
4. 재사용만 보고 Fragment를 판단하는 경우

이 실수들의 공통점은 Activity와 Fragment를 API 이름으로만 보고 구조 안에서의 역할 차이로 보지 않는다는 점입니다. 핵심은 무엇을 쓰는가보다 무엇을 어디까지 맡길 것인가입니다.

그럼 실제로는 어떻게 판단하면 좋을까

1. 이 화면은 Activity 하나가 들고 있기엔 책임이 너무 많은가
2. 화면 안에 의미 있는 독립 구역이 있는가
3. 이 구역은 별도 상태와 상호작용을 갖는가
4. 나중에 일부만 교체하거나 재사용할 가능성이 있는가
5. 지금 구조가 이미 Activity를 비대하게 만들고 있는가

이 질문에 여러 개가 그렇다라면 Fragment로 책임을 나눌 가치가 큽니다. 반대로 대부분 아니라면 Activity 하나로도 충분할 수 있습니다. 즉 Fragment는 무조건 도입해야 하는 규칙이 아니라 복잡도를 관리하기 위한 선택지입니다.

이 판단 기준이 생기면 나중에 single-activity 구조를 보든 여러 화면 패턴을 보든 겉모양보다 책임 배치를 먼저 읽게 됩니다. 바로 그 감각이 안드로이드 구조를 이해하는 데 중요합니다.

이번 편의 핵심 정리

• Activity는 화면의 진입점과 큰 틀을 맡는 쪽에 가깝다
• Fragment는 화면 책임을 더 잘게 나누기 위한 도구다
• Fragment를 쓰는 이유는 단순 분할이 아니라 책임 분리다
• 작은 앱에서는 Activity 하나만으로도 충분할 수 있다
• 중요한 것은 API 선택보다 구조가 얼마나 덜 복잡해지는가다

이 기준이 잡히면 다음 편인 생명주기를 알아야 설계가 쉬워지는 이유도 훨씬 쉽게 이어집니다.

공식 참고 자료는 Fragments overview 와 Introduction to activities입니다.