코드 개선은 감이 아니라 분석으로 하는거야

회사의 KMP 기반 안드로이드 POS 프로젝트에서, 대량의 주문 데이터를 안정적으로 처리하기 위해 비동기 큐(requestQueue)를 도입했다.

도입 당시에는 '비동기 처리만 붙여도 속도 이슈가 조금은 나아지겠지'라는 기대가 있었다. 하지만 한편으로는 '과연 이것만으로 완벽히 해결될까?' 하는 막연한 불안감도 존재했다. 막상 코루틴을 이용해 비동기를 붙이고 테스트해 보니 슬픈 예감은 틀리지 않았다. 일반적인 상황에서는 속도가 미세하게 개선되었지만, 주문이 몰리는 가혹 환경에서는 기대와 다르게 CPU 사용량이 폭주하고 UI까지 심하게 버벅이며 오히려 이전보다 더 느려지는 현상이 발생했다.

 

스레드를 늘려도 보고 채널도 건드려 보았지만, 이런 것들은 현재 상황의 본질적인 원인이 아니었다. 어차피 속도와 최적화 이슈는 언젠가는 마주하게 되어있다. 이번 기회에 제대로 뿌리를 뽑아보자는 마음으로 Android Profiler를 연결하여 앱의 진짜 상태부터 파헤쳐 보았다.

Android Profiler CPU Trace Log

 

원인

 

데이터를 분석한 결과, 미흡한 DB 트랜잭션 처리와 불필요하게 잦은 리렌더링이 속도 저하의 핵심 원인이라고 결론지었다.

좀 더 정확히 말하자면, 코틀린과 SQLite, 그리고 Android WebView가 연결되는 파이프라인 구조를 시스템 레벨에서 전혀 고려하지 못했던 것이다. 상황을 복기해 보면 다음과 같은 패착들이 있었다.

 

1. 비동기 큐에 대한 맹신
   백그라운드의 코루틴으로 작업을 넘겼으니, 메인 스레드는 자유로워져서 겉보기에는 당연히 빨라질 거라고만 생각했다.
2. 미흡한 트랜잭션 처리로 인한 무수한 DB I/O
   현재 Ktorm + SQLite 조합을 사용 중인데, 큐에서 데이터를 꺼내서 처리할 때마다 단건으로 insert나 update를 날렸다.
   데이터 한 건을 처리할 때마다 무수히 DB 파일을 열고 닫으며 JNI를 호출해 네이티브로 넘기니, 프로그램이 느려질 수 밖에 없었다.

 

정리하자면 이렇다. 

우리가 했던 것 (느렸던 방식)

• 마구잡이의 비동기 큐 사용
• 단건 단위의 순차적인 SQLite Insert

우리가 했어야 할 것 (이상적인 방식)

• 명시적인 DB 트랜잭션(Ktorm의 useTransaction)으로 묶어 파일 I/O 최소화
• 데이터 폭주 같은 악조건까지 고려한 데이터 업데이트 주기 및 레이어 최적화

 

 

해결

이 문제는 DB에 대한 접근 방식만 고쳐도 수십 배의 성능 향상을 가져올 수 있을 것으로 보였다. 즉시 개별 Insert 로직들을 Batch와 Transaction으로 묶어서 일괄 처리하도록 리팩토링을 진행했다. 추가로 프론트엔드로 넘어가는 데이터 업데이트 주기를 조절하여 리렌더링 부하도 함께 낮췄다.

결과는 대성공이었다.
기존에 주문과 결제가 일어날 때 수백 번씩 날아가던 DB Commit이 단 몇 십 건 단위로 줄어들었고, 마감이나 개점 같은 무거운 작업에서도 눈에 띄는 속도 개선이 이루어졌다.

가장 놀라운 체감 성능은 하드웨어 스펙에서 나타났다. 기존에는 Rockchip rk3588 보드 정도의 고스펙 장비여야 쓸만하다고 느껴졌던 우리 POS 앱이, 이제는 한참 낮은 스펙인 Rockchip rk3399 보드에서도 충분히 빠르다고 느껴질 정도로 비약적인 개선을 이루어냈다.

 

결론

결국 우리 프로그램을 실제로 구원한 것은, 감에 의존해 맹목적으로 추가했던 비동기 처리가 아니라 '데이터 추적을 통한 시스템 분석과 구조적인 접근'이었다.

처음에 진행했던 단순 비동기 처리는 현재 프로그램의 병목 상태를 전혀 고려하지 않은 채 '믿음'만으로 진행했고, 그렇기에 실패할 수밖에 없었다. 하지만 Android Profiler 등 객관적인 툴로 데이터를 추적하여 현재 상태를 명확히 파악하고 나니, 개선 근거가 뚜렷해졌고 정확한 조치를 통해 문제를 해결할 수 있었다.

물론 데이터를 수집하고, 분석하고, 콜스택을 뒤져보는 일은 생각보다 훨씬 피곤하고 고생스러운 과정이다. 하지만 미래에 이 프로젝트를 유지보수할 누군가(아마도 높은 확률로 나 자신)를 위해서는 결국 시스템의 현재 상황을 정확히 직시해야만 한다.

지금 이 순간에도 "대체 왜 느린 거지?" 라며 막막한 성능 이슈로 고통받고 있을 동료 개발자들에게 나는 이 사례를 말해주며 이 조연을 꼭 전하고 싶다.

 

개선을 진행하기 전에 프로젝트의 현재 상태부터 분석하기.