100% Compose로 안드로이드 앱 출시한 후기

안드로이드 컴포즈에 관한 간략한 소개와, 컴포즈로 하나의 앱을 출시하면서 느낀 여러가지 사항들, 이 외 프로젝트 관련 이야기를 담은 평범한 프로젝트 반성문및여러분제앱’이룸’좀봐주세요! 회고입니다.

앱 소개) 오늘도, 내일도, 미래에도 하고 싶은 게 많은 당신을 위한 버킷리스트 앱, ‘이룸’으로 언젠가, 또 오늘 이루고 싶은 일들을 한 번에 정리하세요!

👇 클릭하면, 플레이스토어로 넘어갑니다 쨔-란 🥳

---

🚀 이룸 프로젝트 시작

바야흐로 작년 10월.. 벌써 이 글을 쓰는 시점의 반 년전 쯤 이 프로젝트를 시작했다. 목적은 2가지였다.

첫째, 안드로이드 컴포즈? 재밌겠는데? 써 보고 싶다.
둘째, 서버 없이 작고 귀엽고 도움되는 앱 하나 출시하고 싶다.

첫째 목적과 관련해서는 이따가 Compose 이야기 할 때 얘기하도록 하겠다. 둘째 목적은, 계기가 있다. 작년 초에 토이프로젝트로 첫 앱 출시를 한 적이 있다. 하지만 서버는 aws 프리티어를 사용했고(1년간 사용 가능), 서버가 끊기면 스플래시부터 넘어가지 않는 앱이었다. 그래서 아쉽지만 1년 후 사용자도 적기도 해서 앱을 플레이스토어에서 내렸다. 그래서 이번에는 내가 끝까지 꾸준히 책임질 앱을 출시하고 싶었다. (나의 개발 역량과 개인 시간 안에서 품을 수 있는?!!) 앞으로 크래시 리포트 꾸준히 확인 등등 하면서 업데이트 할 것이다.

반 년. 물론 기획과 디자인을 포함한 기간이긴 하나, 프로젝트를 시작한 지 6개월만에 마치고, 회고를 쓰는 것은 초~큼 많이 늦은 것 같다 ㅎㅎ (더욱이 복잡한 앱이 아니기에..) 변명을 하자면, 이건 취업 프로젝트의 목적도 있었는데, 막상 취업을 하고 나니...^^ 여유로워졌다. 하!지!만! 버킷리스트, 투두리스트 앱을 만들면서.. 무언가를 이루기 위한 기록 앱을 만들면서.. 앱 이름이 ‘이룸’인데(미룸 아님)... 더 이상 미룰 수는 없어서, 결국 출시도 하고 이렇게 후기 글도 쓴다. 함께한 디자이너님(+ 기획, QA..) 덕분이다..!👍

---

🤔 Compose가 뭔데? 왜 썼는데?

컴포즈는 안드로이드에서 제공하는, 선언형 UI이다. 선언형 방식은 명령형 방식과 대조되는데, 이를테면 이런식이다.

선언형) A 버튼은 파란색이며, 자식으로 "click"이라는 하얀색 텍스트를 가진다.
명령형) 버튼 하나 만들어라. 걔 이름은 A이다. A의 색은 파란색이다. 텍스트 하나 만들어라. 걔 이름은 B이다. B의 텍스트는 click이다. B의 색은 하얀색이다. B는 A의 자식이다...

어우 명령형 너무 귀찮지 않은가. 선언형은 원하는 것을 말하기만 하면, 그 세부적인 것들은 프레임워크에서 대신 해주는데, 명령형은 하나하나 세세히 이야기해주어야 한다. 비유를 하자면, 선언형 ui를 쓰는 것은, 내 머릿속 그림을 말하면 중간에서 자세한 지시를 대신 내려주는 똑똑한 중간 관리자를 고용하는 것과 같다. 내가 해 줄 것은 그저 ui 선언과, state 관리이다. 그럼 중간 관리자가 state에 맞게 ui를 선택적으로 그려준다. 위의 예시로 설명하자면, "click" 이란 텍스트를 state로 관리하고 "clicked"로 바꿔주면, 선언형의 경우 자동으로 그려지고, 명령형의 경우 다시 setText를 명령해주어야 한다는 것이다.

Flutter, Swift UI, React 또한 선언형 ui이다. 안드로이드는 조금 늦게 등장한 편이기는 하나, xml 또한 선언형 방식이긴 하다. 다만, Acitivity/Fragment에서 또 명령해주어야 하는 부분이 있어서 컴포즈와는 대조적이다. 특히 변경점이 생겼을 때, xml과 안드로이드 클래스의 강한 의존성은 개발자를 괴롭힌다. 데이터바인딩이 이를 조금 해결해주기는 하나, 여전히 Fragment의 사용 등 귀찮은 부분이 있다. 컴포즈를 사용하면 Fragment는 필요 없다. 모든 ui가 함수 형태로 작성되게 된다. 아래 그림은 안드로이드 개발자 문서에서 컴포즈를 소개하는 대표적인 그림이다.

여기까지가 간략한 Compose에 대한 설명이다. 내가 간략하게 언급한 안드로이드 ui 이야기는 Jetpack Compose가 필요한 이유 라는 글이 훨씬 자세하다👍 이 외에도 컴포즈 이론과 관련된 좋은 글들이 많으므로, 이 글에서는 이제 왜 썼는지에 대해 이야기해보겠다.

안드로이드 개발로 개발에 입문한 후, 리액트를 잠깐 한 적 있다. 리액트는 UI 만드는 방식(단방향 데이터 흐름)이 안드로이드와 달랐고, 나중에 그것이 Declarative UI(선언형 UI) 라고 부른다는 것을 알았다. 처음에는 안드로이드 ConstraintLayout이 너무 익숙해서 편하다고 느꼈었고, 데이터바인딩으로 더 편리하다고 생각했다. 그런데 데이터바인딩은 선언형 UI의 장점(적은 코드량, UI 상태에만 집중)을 적용하기 위해 기존의 방식에서 보완점으로 나온 것이라는 것을 알게 되자, 이 방식을 받아들이면 더욱 빠르고 유지보수에 좋은 코드를 작성할 수 있을 것으로 생각되며 매료되었다. 그래서 앞으로 계속 해서 지원이 활발해질 것으로 예상되는 Jetpack Compose를 공식 문서를 통해 학습하고 토이 프로젝트에 적용해보았다.

이거는 숙고하여 정리한 이유이고, 간단하게 말하자면 그냥 재밌어보여서 썼다.💚

컴포즈를 써야지~ 하면서 우아콘, DEVIEW 등에서 여러 적용 사례 발표를 듣기도 하였는데, 생각해보지 못한 아키텍처와의 상관관계, 꿀팁 등을 들을 수 있어 좋았다. 아마 지금 시점에는 더 방대한 자료들이 있을 것이고, 앞으로 더 방대해질 것으로 기대된다. 컴포즈로 개발하는 중간 중간, 그런 자료들을 찾아보다가 예상치 않게 큰 도움을 받는 재미도 쏠쏠했다. 또 컴포즈를 써야지~ 하면서 이건 컴포즈에서 어떻게 하지? 싶었던 부분들(생명주기, Context 사용 등)은 컴포즈에서 쉽게 이용할 수 있게 되어 있었다(개발자 사이트 튜토리얼도 굿)👍
.
.
.

+) 컴포즈를 포함한 선언형 UI에 대한 간략한 표현.

UI = f(State)

너무 깔끔해서 짜릿하다.

그렇다면, 컴포즈로 앱 개발하면서 마냥 좋기만 했을까...?!

---

⚠️ Compose 쓰면서 주의해야 할 점

맨 처음에는 쓰면서 마냥 좋았다. 히야~ 히야~ 우와~ 키야~ 이러면서 컴포즈를 개발한 분들께 감사하며 개발했다. 지금도 개인적으로 하는 안드로이드 프로젝트를 할 때는 컴포즈를 쓸 것이라는 마음은 그대로이다! 그래도 몇 가지 힘들었어서 처음 쓰는 분은 주의하세요..!라고 할 만한 것들을 적어보자면, 다음과 같다.

1️⃣ 모든 것을 Compose로 하고 싶었지만...

제목은 100%라고 썼지만, 사실 99.8%(정확X) 정도로 컴포즈를 썼다. 아마 모든 것을 본인이 만들어서 쓰는 개발자보다는, 적절히 라이브러리를 활용할 개발자가 많을 것으로 생각된다. 바로 그 부분, 라이브러리를 활용해서 만든 ui는 해당 라이브러리가 컴포즈를 지원하지 않는다면, 직접 만들거나 다른 라이브러리를 찾아 보는 수 밖에 없다. 물론 컴포즈는, xml 뷰를 사용하는 것도, 그 반대의 경우도 지원한다! 따라서 혼합하여 만들 수 있고, 점진적으로 컴포즈의 비중을 늘릴 수도 있다. 하지만 컴포즈를 사용함으로써, 성능 상 이점을 얻고 싶다면, 혼합하여 사용하는 것은 재고해야 한다.

2️⃣ 스택오버플로우만으로는 안돼요! 이슈 트래커 찾아보기!

컴포즈 쓰기 전에는 개발하면서 이슈 트래커를 살펴 볼 일이 거의 없었다. 그런데 이번 기회에 이슈 트래커도 알게 되고, 스타도 눌러서 빨리 고쳐줘~ 기능 만들어줘~ 라는 의견도 표할 수 있었다. 나름 재밌었던 부분이다. 또, 답글들을 보다보면 다른 방안을 제시해주시는 똑똑한 분들이 계시기 때문에, 빠른 문제 해결을 위해서도 찾아보면 좋다.

3️⃣ State (일일이 명령 안 하는 대신, 잘 알고 구성해 놔야 해!!)

선언형 ui에서는 state 관리가 가장 중요하다. state가 변하면, recomposition 하는 방식으로 ui를 업데이트 하기 때문이다. 따라서 이걸 구성을 잘 해 놔야한다. 또 언제 recomposition이 되고 안 되는지 알아야 한다. 이를 위해서는 기본적인 지식들이나 컴포즈에서 제공하는 것들에 대한 이해가 필요하다(쓰고 나니 너무 당연한 말). 또 하나의 state를 변경하는 부분들을 잘 관리하여, 예상치 못한 이슈가 발생하지 않도록 주의해야 한다. 여기서 그런 것들은 모두 얘기할 수는 없고나도 모르니까, 나의 지식 부족으로 겪었던 하나의 단편적인 사례를 소개하겠다.

val a: String by eroomViewModel.eroomTitle.observeAsState("")
val b: State<String> = diaryViewModel.eroomTitle.observeAsState("")

LaunchedEffect(key1 = a) {
	...//1번
}
LaunchedEffect(key1 = b) {
	...//2번
}

1번과 2번 모두, string 값이 바뀌었을 때 실행될까? ❌ 1번만 실행된다. LaunchedEffect는 key 값이 변화했을 때 취소하고 재실행되는 블록이다. 1번처럼 'by'를 쓴 경우, observeAsState에서 리턴된 State Object를 자동으로 래핑 해제하여 String을 반환한다. 하지만 2번은 '='을 썼으므로 그대로 State<String>을 return한다. 그리고 State 내부의 값이 바뀐 것이 State 객체 자체가 바뀐 것이 아니기 때문에 변화로 인식되지 않는다.
.
.
.
이 외에도 컴포저블을 쪼개고 쪼개고, 인자를 넘기고 넘기다 보니 점점 길어지는 함수 인자...들도 나에겐 별로(?)인 부분이었다. 또 어디까지 쪼개고 재활용할 지 결정하는 것도 고민해야할 부분이었다. 또 뷰모델과의 철저한 역할 분리도... 하지만 역시 뭐니뭐니해도 이런 것들은 아직 컴포즈에 익숙지 않아서 혹은, 안드로이드 개발 경험 또한 적은 데에서 오는 부분들이었기에 모두에게 주의할 사항은 아닌 것 같다ㅎㅎ 그냥 클린한 코드를 작성하고 싶은데, 막상 아직 그렇지 못해서 하는 한 풀이(?)이다. 클~린한 코드를 작성하고 싶다!!!

---

👩‍💻 이룸 프로젝트 진행 중

프로젝트는 나와 디자이너님, 둘이서 진행했다. 지역적인 문제로 대부분 온라인 회의를 통해 진행했는데, 두 명이라 오디오 겹치는 문제도 거의 없고, 화면공유하면서 보기도 좋고 여러모로 좋았다. (나.. 비대면 시대에 적응한 것일까..?) 게다가 디자이너님께서 개발에 취미를 붙이고 계시던 중이라, 더 이해도 잘해주시고 커뮤니케이션 하기 좋았다. 이슈도 깃허브 이슈로 공유하고, 카톡으로 링크 전달하고 그런 식으로 진행했다. 나도 개발은 혼자 하는 작업이었지만, 깃플로우 적용해서 feature브랜치 pr 올리고~ 공유하고 그렇게 했다. 개발하면서는 노션에 할 일 정리하고(내가 내게 일을 커밋별로 나눠서 주고) 과정을 기록하기도 하면서 진행했다. 이제와서 보니 다 기록이 되어 있어서 너무 좋다ㅎㅎ

이룸 프로젝트는 지금도 진행 중이다. 짠! 앱 다 만들었다~ 출시 쨔란~! 끝! 아니고 이제 시작이라는 경건한 마음으로 리팩토링도 하고, 개발하면서 반창고로 대충 붙여놓은 부분도 다시보고.. 사용자 의견이 생긴다면 기능도 개선해 보고! 할 것이다. 작년에 생애 첫 출시한 앱은 출시하고 한 달 정도 지나서는 내 머릿속에서 잊혀졌다ㅋㅋㅋ 취업 준비하면서 조금 챙겨본 정도..? 였다. 이번에는 절대 그러지 않겠다는 마음으로 이렇게 정성 들여 후기도 작성한다..!!

끝으로 이 글을 쓰면서 든 생각인데, ‘미룸’이란 이름의 앱을 만들어 보는 건 어떨까ㅎㅎ 뭔가를 미루면서도 죄책감은 또 드는데, 해야지 해야지 하면서 또 미루고 미루다 하는 사람을 위한 앱... 죄책감을 폭발시켜서 바로 하게 만드는 그런...

🌈 이룸은 계속 됩니다! 1년쯤 운영했을 때 다시 후기 들고 올게요!