'Memory-Managed Programming'에 해당되는 글 1건

  1. 2007.08.04 RIA와 Memory-Managed Programming (4)

RIA와 Memory-Managed Programming

엔터프라이즈 자바 2007. 8. 4. 16:48 posted by 엔트웍스
자바 프로그래머는 메모리 할당과 해제에 신경쓸 필요가 없다. 자바는 메모리를 VM이 관리해주는 Memory-Managed Programming 언어이기 때문이다. 그저 new 키워드로 객체를 생성하고 쓰다가 잊어버리면 그만이다. C에서처럼 delete를 잊어버려 메모리 누수가 발생하는 문제도 없다. delete 키워드 따위는 애초에 존재하지도 않으며, C처럼 메모리 주소를 알아 낼 수 있는 방법도 없다. 겉보기에는 메모리라는 개념은 자바에 애초에 존재하지도 않으며, 메모리라는 저수준의 개념을 가지고 더 이상 머리를 싸맬 필요가 없다.

그러나 자바는 메모리 개념을 감추기만 했을 뿐 없애지는 못했다. 그리고 우리에게 가비지 컬렉터라는 신종 부라퀴를 풀어 놓았다. 참조가 해제된 객체가 가지고 있는 메모리를 해제하기 위한 가비지 컬렉터는, J2EE 환경에서 GC로 인한 성능저하 문제를 안겨준다.

게다가 메모리 누수 가능성이 0이 되지는 않았다. GC가 아무리 완벽하게 구현되었더라도 메모리 누수 가능성은 낮아질 뿐 0은 아니다. 간단히 어떤 클래스의 static 변수에 HashMap을 만들어 두면, 거기다 객체를 넣어두는 순간 이 객체는 영생을 얻고 메모리는 누수된다. 간단한 예지만 복잡하게 만들면 끝도 없이 복잡하게 만들 수도 있다. 자바는 메모리 누수에 대해 신경을 안쓰게 만들어 놓고 나중에 뒷통수를 때리는 언어일 수 있다.

결국 자바에서 메모리 관련한 문제가 해결된 것은 아무것도 없다. 나아진 것이라면 문제점들이 좀 더 정리되고 좀 더 컴포넌트화 되었다는 것이 달라졌을 뿐.

프로젝트에서 RIA(Rich Internet Application)를 적용하다 보니 문제는 돌고 도는 것이라는 진리를 다시금 깨닫는다. RIA도 메모리 문제에서 자유로울 수 없다.

기존의 DHTML 기반의 UI를 가진 시스템은, 클라이언트는 어느 정도 메모리 문제에서 자유롭다. 사용자는 하나의 페이지에서 길어야 분 단위로 머무를 뿐이다. 페이지가 갱신되고 나면  클라이언트 메모리는 다시 리셋된다. 따라서 하드코어하게 AJAX라도 사용하지 않는 한, 자바스크립트로 인한 누수된 메모리는 사용자가 인식하기 전에 새로운 페이지에서 사라져 버린다. 신경쓸 이유가 없으니 기억하거나 배울 필요도 없었다.

이제 RIA가 등장했다. RIA를 지원하는 환경은 모두 Memory-Managed Programming 언어를 제공한다. 그것이 어떤 언어이든지. 애시당초 웹 개발 언어가 Memory-Managed가 아니라면 보안문제가 발생할 것이다. 웹으로 다운로드 받은 프로그램이 내 OS의 메모리의 포인터를 얻어가는 걸 허용할 사람이 있을까?

그런데 대부분의 RIA 애플리케이션은 브라우저 입장에서는 하나의 웹페이지일 뿐이다. Rich한 애플리케이션은 러닝타임 또한 길 것이다. 러닝 타임이 길 수록 메모리 누수는 문제를 일으킬 가능성이 높아진다.

웹기반 시스템의 클라이언트 메모리 누수 문제? 심각하게 고민할 필요가 있나?

이것이 심각한 이유는, 대부분의 RIA 프로그램 들은 그 특성상 자체적으로도 하나하나의 객체가 상대적으로 메모리를 많이 차지하기 때문에, 메모리 누수는 매우 치명적일 가능성이 높다. RIA 애플리케이션은 각종 아이콘이나 이미지를 하나의 애플리케이션 메모리에서 처리함을 기억하라.

게다가 대부분의 RIA 프로그래머는 커리어의 특성상 이러한 메모리 누수의 개념 자체가 희박하거나, 기존 웹페이지 방식의 개발에 익숙한 나머지 그만 잊어버렸다는 것이다. 따라서 메모리 누수를 일으키는 프로그램을 작성할 가능성이 매우 높다. 팝업 윈도우 하나 띄우는데 1메가의 메모리가 필요하고, 이 팝업 윈도우를 닫아도 메모리가 해제되지 않는다면 그것은 재앙이나 다름없다.

게다가 대부분의 RIA 플랫폼은 GC를 통해 메모리를 해제하게 된다. 그런데 각 RIA 플랫폼의 GC 알고리즘은 아직 성숙되지도 않았고, 제대로 된 프로파일링 도구도 제공되지 않기 때문에 GC가 수행되었는지 알기 조차 힘들다. 또 GC는 대부분 수동 제어가 불가능하다.

메모리 누수 문제는 치명적인데 메모리 관리의 근간이 허술하니, 결국 인력으로 돌파할 수 밖에 없다. 경험 많은 엔지니어가 프로젝트 초기에 메모리 문제에 관해 명시하고 해결방법을 모색하고 가이드라인을 제공하고 프레임워크화하지 않는다면, 아마 대부분의 프로젝트는 막판에, 최악의 경우에는 프로젝트 완료 후에 진정한 고생길이 열릴 것이다.

Flex? Silverlight? JavaFX?
DHTML 기반에서는 꿈도 꾸지 못하던 멋진 사용자 인터페이스. 마치 데스크탑 애플리케이션같은 User Experience를 제공하는 매력적인 웹기반 시스템.
그러나 세상에 공짜는 없는 법이다.
모든 문제는 해결되지 않고 다른 곳에서 나타날 뿐이다.
RIA는 웹과 Rich Client의 빛을 함께 지녔지만, 중첩된 그림자는 더 진하다.

  1. Commented by 얼음공주 at 2007.08.21 15:23

    블로그 구경잘 하였습니다. 블로그에 필요한 동영상, boom4u.net 도 구경 오세요~~

  2. Commented by 민재 at 2007.12.05 17:53

    Memory-Managed가 아니라면 보안문제가 발생
    RIA는 메모리 관리가 되므로 보안 문제가 발생하지 않는다는 말이죠?

    이 부분은 여전히 헷갈리는 부분입니다. 개념적으로 잘 안 서요..

    • Commented by Favicon of http://crosscutter.info BlogIcon entworks at 2007.12.06 18:27

      아니 갑자기 이 글이 왜 최신으로 갱신되었죠.. -_-
      Memory-managed 프로그래밍 환경이 사용자측 리소스 보안 문제를 예방하는 충분조건은 아니고, 중요한 필요조건 정도가 아닐까요? 파일이나 키보드같은 자원에 액세스하는 걸 프로그래밍 언어가 막는건 아니니까요.

  3. Commented by 민재 at 2007.12.05 17:53

    "RIA는 웹과 Rich Client의 빛을 함께 지녔지만, 중첩된 그림자는 더 진하다." 이 말 멋지군요.. 음.