이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 안드로이드 앱 크래시율이 0.8% 수준이었는데, 아무도 줄이는 작업을 하지 않고 있었습니다. 크래시 로그를 직접 분석해 보니 상위 3개 원인이 전체 크래시의 70%를 차지하고 있었습니다.
가장 빈도가 높았던 것은 특정 안드로이드 버전에서의 null 참조 오류였습니다. 재현 조건을 파악하고 분기 처리를 추가하니 전체 크래시가 0.3%로 줄었습니다. 2주 작업이었고 저 혼자 진행했습니다.
실패 경험도 있었습니다. 수정한 분기 처리가 다른 버전에서 새로운 예외를 만들어 배포 직후 크래시가 일시적으로 올랐습니다. 단위 테스트를 여러 버전 에뮬레이터에서 돌리는 습관이 그때 생겼습니다. 품질 개선은 혼자 조용히 진행해도 수치가 말한다는 걸 그때 배웠습니다.
사이드 프로젝트에서 만든 안드로이드 음악 플레이어 앱이 30분 이상 사용하면 느려진다는 피드백이 있었습니다. 메모리 프로파일러로 확인하니 Activity가 종료돼도 메모리에 남아 있는 패턴이 보였습니다.
원인은 리스너를 Activity 생명주기에 맞춰 해제하지 않은 것이었습니다. onDestroy()에서 리스너를 명시적으로 해제하고, 싱글톤 객체가 Activity 참조를 직접 갖지 않도록 구조를 수정했습니다. 수정 후 같은 30분 사용 기준으로 메모리 사용량이 안정됐습니다.
생명주기를 놓치면 겉으로는 잘 돌아가는 것처럼 보이지만 서서히 나빠진다는 걸 그때 처음 실감했습니다. 메모리 안정성은 기능 완성 후에 한 번은 확인해야 하는 별도 항목이라는 기준이 그때 생겼습니다.
인턴 때 상품 목록 화면의 스크롤이 뚝뚝 끊기는 문제를 맡았습니다. 처음엔 이미지가 많아서 그런가 했는데, 화면 렌더링 프로파일러를 켜니 특정 아이템 바인딩 시 메인 스레드에서 DB 조회가 발생하고 있었습니다.
비동기로 분리하고, 자주 쓰는 데이터를 미리 캐시해 바인딩 시 바로 가져올 수 있게 했습니다. 60fps 기준으로 프레임 드롭이 거의 사라졌습니다. 작업 전후 프로파일 캡처를 팀에 공유하니 왜 개선이 됐는지 눈으로 확인할 수 있어서 반응이 좋았습니다.
메인 스레드에서 무거운 작업이 얼마나 간단한 실수에서 시작되는지 처음 알았습니다. 이후엔 리스트 화면을 만들 때 바인딩 로직에서 IO 작업이 있는지 항상 점검하게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.