말 많은 아이폰 램 이야기 입니다. 옳은 정보와 그릇된 이야기가 뒤 섞여 불필요한 논쟁을 유발하는 게 거슬려 글을 써봅니다.

먼저 그릇된 이해입니다.

*다다익램? 그건 PC 이야기.

PC에서는 메모리가 부족하면 디스크 페이징이 일어납니다. 디스크는 메모리보다 10배이상 느리므로 메모리가 많아질수록 느려질 확률이 대폭 감소합니다. 그러나 모바일은 페이징 파일을 사용하지 않습니다. 물리적인 메모리의 한도에서만 사용하므로 램을 늘린다고 빨라지지 않습니다.

*램이 늘어나면 정말 쾌적할까?

2G만 되도 얼마나 쾌적할까 하시는 분들이 계신데, 꺼꾸로 생각해봐야 합니다. 처음 사용할 때는 빈 공간이겠지만, 결국 사용하다 보면 모두 채워지기 마련입니다. 그 다음부터는 2G를 대상으로 빈 공간을 만들어 내야 합니다. 자, 2G를 관리하는 게 빠를까요 1G를 관리하는 게 빠를까요? 개별 앱에게 부족하지만 않다면 작은 게 당연히 빠릅니다.

*안드로이드와의 차이

가상 머신과 네이티브는 메모리 관리에서 아주 많이 다릅니다. 사실 안드로이드에게 메모리 증설(2G이상)은 너무도 절실했습니다. 왜냐하면 가상 머신의 메모리 관리는 최소 일정 크기 이상의 메모리 풀이 있어야 효율적이기 때문입니다. 그래서 안드에서의 2~3G나 iOS에서의 1G나 가용 자원의 측면에서는 그리 크게 차이 나지는 않습니다.

이번은 애플에 대한 이야기입니다.

*증가가 멈췄다

아마도 아이폰 메모리가 이슈가 되는 첫 번째 이유는 매년 128->256->512->1024MB 이렇게 증가해오던 것이 더 이상 늘지 않고 멈추어 버렸기 때문일 겁니다. (규칙대로라면 이번이 2G차례). 더구나 늦게 출발했던 안드로이드는 최근 1~2년 사이에 3G까지 올라와버린 상황이라 더 비교되지요. 

저는 램 증설에 대해 ‘불필요’하다는 쪽과 ‘준비부족’이라는 두 가지 시각을 모두 가지고 있었습니다. 작년까지만 해도 불필요 하다는 생각이었는데 64비트가 모든 것을 바꾸어 버렸습니다. 그래서 5S 이후로는 ‘준비 부족’이 더 크지 않나 싶습니다.

*생각보다 더 어려운 64비트.

작년의 64비트 발표는 정말 놀라운 것이었습니다. PC에서의 64비트는 사실 메모리 증설 효과로 빨라지는 경우가 많습니다. 그러나 아이폰은 같은 용량으로 더 빨라졌다고 하지요. 여기에는 여러 가지 테크닉 동원될 것으로 알고 있습니다. 예를 들어 64비트 메모리 주소 중에 앞부분은 쓰지 않게 되는데, 이것을 메모리 참조 카운트로 활용한다거나 하는 식으로요. 그래서 메모리 단위 크기가 두 배로 늘었음에도 전체 메모리 사용량은 30% 증가 밑으로 잡았다고 하더군요. 64비트가 사진이나 동영상처리에서 상당한 효과가 있는 것은 분명하지만 전체적인 성능에서는 오히려 불리한 점이 많습니다. 애플은 64비트를 단순히 도입하는데 그치지 않고 그 어려운 점을 극복했기데 칭찬을 받았던 것입니다. (그래서 안드로이드가 벌써 일년이 지났지만 64비트 전환이 쉽지가 않지요. 숫자만 올려 봤자 이득이 적기 때문입니다.)

제가 가진 정보의 한계로 더 깊숙이 알기는 어렵지만 64비트를 최적화한 상황에서 2G로 증설하는 것은 다방면에 시스템적인 영향이 큰 걸로 보여집니다. 사실 너무도 ‘빠른’ 64비트 진행이었기 상대적으로 여기서 더 느리지만 충분한 준비를 하는 게 온당할 수도 있지요. 어쨌던 기대하지 않았던 64비트는 준비했으면서 스케줄상 당연해 보였던 램 증설이 되지 않는 요상한 상황이 되었지요.

*iOS8의 변화

제가 GM이후로 iOS8을 사용했기에 충분치 않은 시간이지만 몇 가지 변화가 보입니다.

우선 64비트 시스템의 메모리 페이징 관리에 약간에 변화가 있어 보입니다. 7까지는 물리적인 한계와 무관하게 4G공간을 주었는데 8부터는 1G로 다시 내렸던 군요. 개별 앱에게 메모리 관리를 더 효율적으로 하라는 것인지는 더 살펴봐야 할 것 같습니다.

둘째로 꼭 필수적이지 않았던 스크린 캡춰 이미지의 우선 순위를 많이 낮춘 듯 합니다. 그래서 쓸 때 없이 메모리를 차지하고 있던 많은 스냅샷들이 시원하게 없어졌습니다. 다만 사파리의 멀티탭등에서 캡처 이미지 없이 까만 화면만 있어 당황스러울 수 있겠습니다. (사실 이전과 똑 같은 리플레쉬 과정임. 다만 이 부분은 아직 완전히 정리되지 않은 듯합니다. 직전 이미지는 없는데 전전 이미지는 남아있다거나 하는.)

어쨌든 가능한 한 많은 앱이 백그라운드로 살아 남아 있으면 좋겠지만 사실 세상에 꽁짜는 없습니다. 간단해 보이는 게 많은 노력이 필요하지요. 또한 메모리 증설보다 빠른 메모리 스냅샷/복구 로직이 거의 무한대로 백그라운드 상태를 보존할 수도 있습니다. (이 경우는 작은 메모리가 스냅샷에 더 유리하겠지요.)

어쨌든 애플이 기대를 충족시키진 못했지만 ‘시간을 더 줘도 된다’라고 정리해도 무리는 없을 거라고 봅니다.

PS. 원래는 옆동네에 쓸려고 했던 글인데 제가 글쓰기 권한이 없더군요. 그래서 어쩔까 싶다가 여기에 올립니다.(그래서 퍼가셔도 좋음)

PS2. 밑에 사파리에 대한 질문이 있어 추가합니다.

사파리의 경우는 조금 다릅니다. 자바스크립트가 가상머신 기반이라서 기본 메모리가 어느정도 필요합니다. (웹킷은 메모리를 더 많은 먹는 걸로 알려짐. 크롬처럼). 그래서 램이 증설된다면 가장 먼저 혜택을 받는 앱이 될 것입니다. 다만 512M의 아이폰 4(iOS7)에서도 느리지만 거의 튕김없이 웹튠들을 보고 있기에 모바일 사파리의 필요한 메모리는 그 안쪽이라고 보여집니다.  일시적으로 다른 앱이 너무 많이 사용중이라면 처음 사용시 튕길 확율이 높아 진다고 할 수 있습니다. 보통 튕기는 증상은 그냥 부족해서 발생하는게 아니라, ‘정해진 시간’안에 필요한 양을 확보 못하면 생김니다. 정리해야 할 메모리가 너무 많으면 확보하는데 시간이 걸리겠지요. 그래서 두번째 실행은 잘 되는 경우가 많습니다. 결론은 1G가 결코 부족하지는 않지만 늘릴 필요가 없는 것도 아니다. 오히려 늘리면 직접 혜택을 받는 현재로서는 거의 유일한 앱이 될 것이다. 그리고 여러번 자꾸 튕기는 사이트가 있을 수 있는데(스크롤의 압박이나 무한 동영상 첨부), 그런 곳은 아애 사용하지 않는게 모바일에서는 정신 건강에 좋을 것 같다 입니다.