일본 IT 앱 현장에서 XML을 Compose로 옮긴 1년 (점진적 마이그레이션, 디자인 시스템, 일정 협상)

2024년 가을에 들어간 쇼핑몰 앱 현장은 화면이 80개 정도 되는데, 전부 XML이었습니다. 안건 설명에는 Jetpack Compose 경험자 우대라고 적혀 있었는데, 막상 들어가 보니 Compose로 만든 화면은 하나도 없었습니다. 리드가 첫날 점심을 먹으면서 한 말이 아직도 기억납니다. “옮기고 싶은데, 아무도 첫발을 안 떼요.”

일본 현장에서는 이런 상황이 드물지 않습니다. 오래 운영된 앱이 많고, 개발팀은 발주처 직원, 협력사 직원, 저 같은 프리랜서가 섞여 있는 경우가 많습니다. 다들 계약된 업무만 하면 되니, 당장 눈에 보이는 성과가 없는 마이그레이션을 먼저 꺼내는 사람이 없는 겁니다. 그 현장도 그랬습니다.

그렇게 제가 그 첫발을 떼게 됐습니다. 그 뒤 1년 동안 화면의 절반 가까이를 Compose로 옮겼는데, 코드를 바꾸는 것보다 사람을 설득하는 데 시간이 더 들었습니다. 비슷한 현장에 들어갈 분들을 위해 그때 있었던 일을 적어봅니다.

점진적 마이그레이션

처음 계획은 간단했습니다. 새로 만드는 화면은 Compose로, 기존 화면은 손댄 때마다 하나씩 옮기기로 했습니다. 앱 전체를 한 번에 바꾸는 건 80개 화면 규모에서 현실적이지 않았고, 그런 계획은 어차피 승인도 안 났을 겁니다.

XML과 Compose는 서로 끼워 넣을 수 있습니다. XML 레이아웃 안에 ComposeView를 두면 그 부분만 Compose로 그릴 수 있고, 반대로 Compose 화면 안에서 예전 커스텀 뷰를 써야 하면 AndroidView로 감싼 들어오면 됩니다. 저희는 상품 상세 화면의 리뷰 영역부터 ComposeView로 바꿨습니다. 화면 전체가 아니라 한 조각만 바꾸니, 문제가 생겨도 되돌리기 쉬웠습니다.

예상 못한 건 성능이었습니다. 리뷰 목록을 LazyColumn으로 바꾸고 나서, 테스트용으로 받은 오래된 저가 단말에서 스크롤이 뚝뚝 끊기기 시작했습니다. 원인은 아이템에 key를 안 준 것과, 아이템마다 날짜 포맷을 매번 계산하는 코드였습니다. 그걸 고치기 전까지 일주일 동안, 팀 내에서는 “역시 Compose는 느리다”는 말이 돌았습니다. 첫 화면에서 성능 문제가 보이면 팀 전체가 등을 돌릴 수 있으니, 첫 화면은 팀에서 가장 느린 기기로 꼭 확인해 보세요.

디자인 시스템

리뷰 영역을 바꾸고 릴리스한 다음 날, 디자이너한테서 스크린샷 두 장이 왔습니다. 예전 버전과 새 버전의 별점 색이 미묘하게 다르다는 거였습니다. 저는 나란히 놓고 봐야 겨우 보이는 차이였는데, 디자이너는 단번에 알아봤습니다.

원인은 색을 정의한 곳이 두 군데라는 것이었습니다. XML 쪽은 colors.xml과 테마 스타일에, Compose 쪽은 제가 급하게 만든 MaterialTheme에 색이 따로 들어 있었고, 그 과정에서 값 하나를 잘못 옮겨 적었습니다. 다크 모드까지 있었다면 더 크게 터졌을 겁니다.

그 뒤로는 화면을 더 옮기기 전에 색, 글꼴, 여백 값부터 한곳에 모았습니다. 디자이너가 쓰는 Figma의 이름을 그대로 가져와서 Compose 테마를 만들고, XML 쪽 값도 그 이름에 맞게 정리했습니다. 작업 자체는 지루했지만, 디자이너와 대화할 때 같은 이름으로 부르게 되자 피드백 횟수가 눈에 띄게 줄었습니다.

버튼이나 카드 같은 공통 컴포넌트도 이때 만들었습니다. 스크린샷 테스트를 같이 붙여두었더니, 누군가 여백 값을 바꾸면 PR 단계에서 바로 걸렸습니다. 별점 색 사건 이후로 디자이너에게 색 지적을 받은 적은 없습니다.

일정 협상

솔직히 가장 힘들었던 건 이 부분입니다. 처음에 PM에게 마이그레이션만 하는 스프린트를 두 번 잡아달라고 했다가 깔끔하게 거절당했습니다. 사용자 눈에는 아무것도 바뀜지 않는 일에 2주를 쓸 수는 없다는 거였죠. PM 입장에서는 당연한 말이었습니다.

지금 생각하면 제안 방식부터 잘못됐습니다. 저는 준위임 계약으로 들어간 프리랜서라, 제가 쓰는 시간이 곧 발주처가 내는 돈입니다. 마이그레이션 스프린트는 발주처 입장에서 보면 ‘기능이 하나도 안 늘어나는 2주치 청구서’였던 거죠. 게다가 그 PM도 자기 선에서 결정할 수 있는 게 아니라 윗선에 설명해야 하는 입장이었습니다. 회의 자리에서 갑자기 꺼낸 제안을 그 자리에서 들어줄 수는 없었던 겁니다.

그래서 방식을 바꿨습니다. 기능 추가나 수정으로 어차피 손대야 하는 화면이 생기면, 그 화면만 같이 Compose로 옮기는 것을 팀 규칙으로 넣자고 제안했습니다. 견적에는 그 분량만큼 반나절에서 하루 정도를 얹었고요. 이때 설득 자료로 쓴 건 리뷰 영역을 옮긴 뒤의 코드 양이었습니다. 같은 기능인데 파일 수와 줄 수가 크게 줄었고, 다음에 리뷰 화면을 고칠 때 걸린 시간도 같이 보여주었습니다. 이건 통했습니다.

이번에는 정식 회의 전에 PM과 리드에게 따로 먼저 이야기했습니다. 일본에서 말하는 네마웨시(根回し)죠. 그리고 PM이 윗선에 그대로 가져갈 수 있도록, 줄어든 코드 양과 수정 시간을 한 장짜리 자료로 만들어 드렸습니다. 설득해야 하는 사람은 PM이 아니라 PM의 상사였던 거죠. 정식 회의에서는 이미 다 아는 내용이라 10분 만에 통과했습니다.

이 규칙으로 1년 동안 옮긴 화면이 대략 절반입니다. 빨랐다고는 못 하겠지만, 중간에 도로 XML로 돌아가자는 얘기가 한 번도 나오지 않았다는 게 더 중요하다고 생각합니다. 남은 화면은 요즘도 그 팀이 같은 방식으로 옮기고 있다고 들었습니다.

프리랜서 입장에서 돌아보면, 이 경험은 면담에서 꽤 쓸모가 있었습니다. Compose를 쓸 줄 아느냐보다, XML로 가득한 기존 앱을 어떻게 옮겨본 적이 있느냐는 질문이 훨씬 많았거든요. 일본에는 오래 운영된 앱이 많아서, 그런 현장을 어떻게 움직였는지 설명할 수 있으면 이야기가 빨리 풀립니다.