이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트로 만든 iOS 앱에서 장시간 사용 시 메모리가 계속 올라가는 현상이 있었습니다. Xcode Instruments의 Leaks와 Allocations 도구를 써서 확인했더니, 특정 뷰 컨트롤러가 dismiss 후에도 메모리에 남아 있었습니다. 원인을 추적해보니 클로저에서 self를 강하게 캡처하는 순환 참조 때문이었고, [weak self]로 바꾸면서 해결됐습니다. 처음에는 어떤 도구를 써야 하는지도 몰라서 Debug Memory Graph를 먼저 열었다가 그래프 해석이 어려웠고, 결국 Allocations에서 생성·해제 카운트를 비교하는 방식으로 방향을 잡았습니다. 그 경험 이후로는 뷰 컨트롤러에서 클로저를 쓸 때 캡처 리스트를 먼저 확인하는 습관이 생겼습니다.
메모리 누수 원인을 찾을 때 Debug Memory Graph를 처음 써봤는데 그래프를 읽는 방법을 몰라서 헤맨 경험이 있습니다. 뷰 컨트롤러가 dismiss 후에도 메모리에 남아 있다는 것을 Allocations에서 확인했는데, 왜 그런지를 파악하려고 Memory Graph를 열었습니다.
객체들이 서로 참조하는 그래프가 나왔는데 어떻게 읽어야 하는지 몰랐고, 결국 Xcode 문서와 샘플 코드를 보면서 순환 참조가 어떻게 그래프에 표시되는지를 이해했습니다. 그 과정에서 내 뷰 컨트롤러와 클로저 사이에 cycle이 있다는 것을 직접 눈으로 확인할 수 있었습니다.
도구를 쓸 줄 아는 것과 도구가 보여주는 것을 해석할 줄 아는 것은 다르다는 것을 배웠습니다. 이후 Instruments를 처음 쓸 때는 빈 프로젝트에서 먼저 연습하는 방식을 씁니다.
순환 참조 문제를 [weak self]로 수정하고 나서 실제로 해결됐는지를 확인하는 과정도 중요했습니다. 코드를 바꾼다고 바로 믿는 게 아니라, Allocations에서 뷰 컨트롤러 인스턴스 카운트를 다시 확인했습니다. 수정 전에는 화면을 여러 번 열고 닫아도 카운트가 계속 올라갔는데, 수정 후에는 dismiss 할 때마다 카운트가 줄어드는 것을 확인했습니다. 그 차이를 직접 보는 것이 수정이 맞았다는 확신을 줬습니다. 메모리 문제는 코드만 고치는 것으로 끝나는 게 아니라 고친 후에 실제로 해제가 일어나는지 측정으로 검증하는 것이 전체 과정이라는 것을 그때 이해했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.