그놈 메모리 누수 현상 패치 도우미 모집

메모리누수란 쉽게말해 프로그램이 점유하는 메모리를 시간이 가면 갈 수록 점점 더 늘리는 현상을 말합니다.
그러니까 가만히 있을 뿐인데 메모리를 계속 처묵처묵하는 것입니다.

이 현상이 계속되면 누수된것처럼 메모리의 가용량이 서서히 줄어들게 되는데 단순히 느리게 만드는 수준이면 그러려니하는데 심각하면 충돌및 오류를 뿜게됩니다.

과거 메모리누수로 고생한 프로그램이 파이어폭스 2.x이 있습니다. 이 쪽은 탭을 닫으면 탭이 먹었던 만큼 뱉어야하는데 그냥 메모리를 꿀꺽하는 문제가 있었습니다. 그래서 인터넷 좀 하다보면 메모리가 부족해지곤 했었지요. 이는 파이어폭스 3.x이후 해결되었습니다.

그리고 몇몇 일본산 게임들은 더 심각해서 게임을 켜고 조금 게임을 하다보면 혼자서 메모리를 반 이상 먹어버립니다. (유명업체가 이런짓을 합니다. 테크모, 세가 장난하냐?)

그래서 가비지 컬렉터라고 해서 자동으로 메모리를 정리해주는 기능도 있는데 이건 어디까지나 JAVA나 Python같이 중간 매개체가 있을 때 이야기이고 C나 C++로 짜여진 경우에는 개발자가 알아서 메모리를 뱉게 짜야합니다. 그놈도 C++로 짜여진 만큼 어디서 메모리가 새는지 찾아야 할겁니다.

메모리 누수 현상과 가베지 컬렉션 문제는 아주 오래전부터 프로그래머 사이에는 핫 이슈이고, 실제로 다양한 방법으로 언어별로 처리하는 기법이 다 있습니다.

그러나 이런 것까지 고려해서 프로그래밍을 척척 잘 짜주시는 정성스러운 분들이 생각보다 적어서 최종 소비자인 대중들 입장에서는 메모리 누수 현상으로 인한 피해(?)아닌 피해를 입게됩니다.

예전에는 어떤 언어를 사용하던 간에 최적화라는 주제는 프로그래머의 가장 핵심적인 의식이었고 실제로 그렇게 프로그래밍했습니다. 요즈음은 프로그래머들이 편해져서 그냥 언어에서 지원하는 라이브러리에 의존해서 프로그래밍하다보니 근본적인 문제가 생기면 덜덜 떠는 분위기입니다. 이런 분위기는 많이 쇄신되어야 한다고 봅니다.

아주 옛날 80년대, 90년대 초반까지만 해도 원라인 테스트(베이직 언어 256자 내외로 프로그래밍을 하는 기발한 프로그래밍 테스트), 최적화 테스트 (어셈블리어와 기계어를 이용해서 가장 최적으로 원하는 결과를 얻어내는 테스트), 가베지 컬렉션 테스트(각 언어별로 최적의 메모리 관리 방법을 제시하는 테스트) 등... 말 할려면 한 도 끝도 없음... 

여하튼 다양한 방법으로 최적화를 이루어서 지금으로는 말도 안 되는 64K 메모리, 128K 메모리에서 엄청난 작품들이 쏟아지고 실제로 현장에서 사용되었다는 사실을 기억해야 합니다.

지금은 너무 편해져서 이런 최적화 부분, 알고리즘 부분, 가베지 켈렉션 부분, 기타 코딩의 최적화 부분 등을 종합적으로 고려하지 못하는 분위기인 것 같습니다. 이번 기회를 통해서 오픈 소스 계열도 쇄신이 필요하다고 보입니다.

C언어에서도 가베지 켈렉션 방법론이 아무 오래전부터 이미 충분하게 공개되어 있으니, 이를 시스템에 맞게 잘 반영하면 문제해결 되는 것은 전혀 문제될 것 없다고 보입니다. 문제는 전문 프로그래머들이 돈을 받고 사업적으로 프로그래밍 하시는 분들이 아니라 취미 차원에서 또는 자신이 시간될 때 프로그래밍 하시는 분들이 많아서 이를 최적으로 협동적으로 결과를 이끌어 낼지가 고민이다고 보이네요.

기업 차원에서도 서로 협력하지 않으면 위에 언급한 게임과 같은 결과가 나오기도 합니다. 

이미 알고리즘과 방법론 등에 모두 공개되어 있으나 이런 것까지 완벽하게 고려해서 프로그래밍하는 것은 사실 고역이죠. 그 마음은 이해합니다.

그렇지만, 이번 기회에 그놈이 이런 부분까지 해결을 근본적으로 본다고 하니 잘 한 일이라고 보입니다.

새롭게 그놈도 태어나야죠.

양, 질, 속도로 나눠 생각할 수 있습니다.

옛날부터 지금까지 양(量)을 추구하다가 어느정도 성과를 이루자, 질(質)을 추구할 수 밖에 없게 되었고,

질 역시도 어느정도 성과를 이루자 속도(速度)가 중요하게 되어 집중하게 된 결과, 오늘날

비슷한 문제가 잊을만하면 발생하게 된 것 같습니다.

편중(偏重)을 경계하며 균형(均衡)을 추구한다면 최상의 결과에 가까워지리라 생각합니다만, 그걸 구분할줄 안다면

이런 글을 쓸 이유도 없겠죠.

moordev 님 친절한 설명 감사합니다.

돈 빌리고 안 갚아서 문제가 생겼다고 보면 될까요?

늦게 봤네요.

많이 비슷합니다. 돈 빌리고 안 갚는 수준이 아니라 돈을 빌리고 계속 빌리기만 하는 상황이라고 봐야겠지요.

계속 빌리기만 하니 은행(가용 메모리)에는 자꾸 돈이 떨어지고 그러니 다른 사람들이 돈을 못빌리는 상황에 처하게 되는데 사회간접자본(중요 시스템, 네트워크 매니저, UI 관리자 등)에 들어갈 돈까지 가져가는 바람에 사채(스왑)까지 쓰게되면 시스템 전체가 망하게 되는 것이지요.

BUG(벌레)는 반드시 때려 잡아야 합니다. ㅋㅋ

예를 들어서 집에 바퀴벌레가 전혀 보이지 않다고 어떤 이유인지는 모르지만 한 두 마리씩 보이기 시작하면 그냥 그러느니 하고 방치하면 몇 달도 안 되어서 엄청나게 번식해서 나중에는 감당하기 힘든 지경에 까지 이릅니다. 그래서 근본적으로 바퀴벌레를 때려잡는 방법을 동원해서 전멸시켜야죠. ㅋㅋ

프로그램에서도 버그를 한 번 방치하기 시작하면 꼬리에 꼬리를 물고 예상하지 못한 큰 영향을 끼칩니다. 일종의 나비 효과와 비슷하다고 이해하시면 됩니다. 아주 사소한 것은 방치하지 말고 바로 때려잡아 주기....

이것이 프로그램과 관련된 사람들의 식견과 기본적인 수칙이 되어야 하지 않을까 생각합니다.

일종의 프로그래밍 습관에 관한 문제죠. 습관이라는 것이 이런 부분에서도 참으로 중요함을 느낍니다.

여하튼 오픈 소스 계의 버그에 대한 다양한 시각이 있는데, 분명한 사실은 버그는 방치하면 안 된다는 상식을 지켜나가야 더욱 발전적으로 나갈 것이라 보입니다.

그리고 최종 사용자도 "나는 전문가가 아니니 알아서 전문가들이 버그를 찾아서 고치시오"라는 심정으로 프로그램을 사용하는 것에 집중하는 것보다는 가능하면 자신이 할 수 있는 범위에서는 최선을 다해서 버그를 보고하고 피드백을 해서 근본적으로 프로그램 버그를 찾고, 고치고 하는데 일조하는 분위기가 된다면 더욱 시스템이 안정적으로 개선될 것입니다. 이 부분도 인식의 전환이 대단히 필요한 부분이죠.