핵심 요약
앱 코드가 CPU 명령으로 실행된다는 사실은 출발점일 뿐이며, 실제 성능 개선은 추측이 아니라 프로파일링으로 자주 실행되는 경로를 찾는 데서 시작합니다.
검수 범위
명령어 집합의 이론을 앱 성능과 직접 연결하던 표현을 줄이고 Flutter 프로파일링과 메모리 할당 관점으로 검수했습니다.
앱도 결국 CPU 명령으로 실행되지만, Dart나 Flutter 코드의 한 줄을 보고 실제 명령 수를 추측하는 것은 성능 문제를 찾는 좋은 출발점이 아닙니다. 컴파일 방식, 런타임, 기기, 최적화 상태에 따라 결과가 달라지기 때문입니다. 대부분의 앱에서는 먼저 프로파일러로 느린 프레임과 자주 실행되는 함수를 확인해야 합니다.
명령어 집합이 의미하는 것
CPU는 메모리에서 값을 읽고, 산술·논리 연산을 수행하고, 조건에 따라 실행 위치를 바꾸고, 결과를 다시 저장하는 작은 명령을 처리합니다. ARM64와 x86-64처럼 CPU 계열에 따라 사용할 수 있는 명령과 레지스터 구조가 다릅니다. Flutter 애플리케이션 개발자가 이 차이를 직접 다루는 경우는 FFI, 네이티브 라이브러리, 코덱, 암호화 또는 매우 낮은 수준의 최적화를 할 때입니다.
일반 앱에서 먼저 볼 병목
- 한 프레임 안에서 큰 목록을 반복 변환하거나 정렬하는 코드
build()가 호출될 때마다 만들어지는 큰 객체와 문자열- 메인 isolate에서 수행하는 큰 JSON 파싱이나 이미지 처리
- 화면에 보이지 않는 항목까지 한꺼번에 만드는 목록
- 같은 네트워크 요청과 데이터 변환이 여러 번 실행되는 구조
- 짧은 간격의 타이머, 폴링, 불필요한 애니메이션
측정 순서
- 가능하면 실제 기기에서 profile 또는 release와 가까운 조건으로 재현합니다.
- Flutter DevTools의 Performance 화면에서 느린 프레임이 UI 작업인지 래스터 작업인지 확인합니다.
- CPU Profiler로 시간이 많이 쓰인 호출 경로를 찾습니다.
- Memory 화면에서 객체가 계속 늘어나는지, 짧은 시간에 할당이 반복되는지 확인합니다.
- 한 번에 한 가지를 바꾸고 같은 시나리오로 다시 측정합니다.
메모리 접근과 할당을 줄이는 예
화면을 그릴 때마다 원본 목록을 필터링하고 정렬하면 데이터가 작을 때는 문제가 보이지 않다가 항목 수가 늘면 프레임이 흔들릴 수 있습니다. 필터 조건이나 원본 데이터가 바뀔 때만 결과를 계산하고 렌더링에서는 준비된 목록을 읽도록 책임을 나누는 편이 낫습니다. 다만 캐시도 무조건 답은 아닙니다. 갱신 조건이 복잡해지거나 오래된 값을 보여주는 문제가 생길 수 있으므로 측정 결과와 데이터 크기를 근거로 사용합니다.
백그라운드 작업을 고려할 때
큰 JSON 파싱이나 압축처럼 CPU를 오래 점유하는 작업은 isolate로 분리할 수 있습니다. 하지만 isolate 사이의 메시지 전달 비용도 있으므로 작은 계산까지 모두 분리하면 오히려 느려질 수 있습니다. 작업 시간, 입력 크기, 프레임 영향부터 측정한 뒤 결정합니다.
CPU 명령 수준까지 내려가야 하는 경우
프로파일러에서 네이티브 함수가 확실한 병목으로 나타났거나, FFI로 연결한 라이브러리가 특정 CPU 아키텍처에서만 실패하는 경우입니다. 이때는 빌드한 ABI, 네이티브 심볼, 정렬 조건, SIMD 지원을 확인합니다. 일반적인 화면 지연을 해결하기 위해 처음부터 어셈블리나 명령어 집합을 공부하는 것은 문제와 거리가 멀 수 있습니다.
성능 개선의 완료 기준
“코드가 더 빨라 보인다”가 아니라 같은 기기와 같은 입력에서 프레임 시간, CPU 사용량, 메모리 증가, 배터리 영향을 비교해야 합니다. 사용자가 느끼는 문제를 수치와 연결하고 회귀 테스트를 남기면 이후 기능 변경에서도 성능을 지키기 쉽습니다.
측정 기록 예시
성능 수정 전에는 “검색 결과 1,000개에서 첫 스크롤 시 프레임 지연 발생”처럼 입력과 행동을 고정합니다. 사용 기기, 빌드 모드, 데이터 개수, 느린 프레임 수, CPU 프로파일의 상위 호출을 기록한 뒤 정렬 시점 변경이나 목록 지연 생성처럼 한 가지 수정만 적용합니다. 수정 뒤 같은 조건을 다시 측정해야 개선과 우연을 구분할 수 있습니다.
디버그 모드는 개발 편의를 위한 검사와 서비스가 포함되어 release 성능과 다를 수 있습니다. 그렇다고 release에서만 측정하면 원인 추적이 어려울 수 있으므로 profile 모드로 병목을 찾고, 최종 결과는 release에 가까운 실제 기기 조건에서도 확인합니다.
메모리 그래프가 잠깐 상승했다가 가비지 컬렉션 후 내려오는 현상과, 화면을 반복해서 열 때 기준선 자체가 계속 올라가는 현상은 구분해야 합니다. 후자는 해제되지 않은 리스너·컨트롤러·큰 이미지 캐시를 의심하고 같은 동작을 여러 차례 반복해 추세를 확인합니다.
검증 기준과 참고 자료
이 글은 2026-09-08에 아래 공식 문서와 공개 기술 문서를 기준으로 내용과 용어를 다시 검수했습니다. 제품 버전과 기기 제조사에 따라 화면 이름은 달라질 수 있으므로 실제 화면과 공식 문서를 함께 확인하세요.