가비지 컬렉팅, Loosely type binding, 기타 등등

잡담
아는 사람은 안다는 티스토리 내부 개비(?) 작업중. 외형적으로는 별 차이가 없는 것으로 보이겠지만 내부적인 엄청난 코드 변화가 티스토리에 일어나고 있다. 내부 개발서버에 수십번의 커밋이 일어나고 있고 테스트 해야 하는 양도 엄청나다. 어제는 SQL문을 다중 서브쿼리까지 써 가며 몇몇 부분의 로직을 새로 작성하였고 특정 상황에서 동작하지 않는 기능을 디버깅 하기 위해 DOM 문서와 자바스크립트 문법을 펴 두고 몇시간을 해메이기도 했다. 뭐 괜히 이회사 왔다가 대학시절 한학기에 언어 4~5개 배우고 플젝하던 악몽이 다시 생각나기도 하는 시절이다. 이노무 PHP는 뭐이리 어려운 언어인지..

Loosely Type Binding
Perl 혹은 PHP가 쉽다고 하는 사람들을 보면 정말 존경 스럽다. 아직 몇달밖에 되지 않은 초보 PHP 프로그래머인긴 하지만 오늘도 이 어려운 언어 때문에 고생 좀 했다.

'Gendoh' == 0

위의 문장이 참일까 거짓일까? 몇시간 전만 하더라도 난 저것은 당연히 '거짓'인줄 알았다. 허나 PHP는 참이란다. PHP를 좀 하신 분들은 저런것도 모르냐고 구박하실지 모르겠다. 하지만...

function A($a)
{
  if ($a == 'gendoh') ...

저 문제때문에 돌아 가시는 줄 알았다. PHP가 String Comparison을 지원하네 하면서 와 좋다하던 저 코드가 오동작의 원인이 될 줄은;;;; 매우매우 정리해서 저렇게 요약된거지 원래는 쿼드모니터의 도움이 없었으면 힘들었다.
스트링 컴패리즌에 0이 들어 있는 숫자 변수가 온다고 엄하게 동작하다니! PHP의 Losse와 Strict Comparision의 차이는 알고 있긴 했지만 매우 스페셜 한 것을 프리티한 코드로 표현하고 싶을때나 쓰나 보다 하고 있었는데 이건 아니었다. 까딱 잘못하면 원자력 발전소 뚜껑 열리고 인공위성 태양에 들이대는 거다.

더 멋있는 코드!

function A($a)
{
  if ($a == 0) ...

누군가 새로운 언어를 만들려는 사람이 있다면... 저얼대 type 맘대로 쓰는 시스템은 참아주시길...

Garbage Collecting
휴지는 휴지통에... 이런 시절이 좋았다. 동적으로 생성된 객체가 사용이 끝났다면 휴지통에 넣어주기. 분리수거도 가능해서 메모리 재활용 테크닉도 되고 Copy Constructor, Call by Rederance 놀이도 가능했다. 하지만 이제 그런 것이 불가능해 지면서 누구는 퇴근도 못하고 디버깅 중이다. 엄한 메모리 접근때문에 밤새던 걸 이제는 좀 안하게 되나 싶었더니 정 반대의 상황이.. ㅠ.ㅠ
GC가 프로그래머의 메모리 관리 노력을 줄여준다고 누가 말한다면 나는 답하리라. 쓰레기를 아무대나 버렸더니 침대밑에서 썩고 있는 우유팩을 찾을 수가 없다고...
GC는 레퍼런스가 끝나면 자동으로 객체가 사라진다. 따라서 이미 지워진 객체를 엑세스 할 일도 없고 지우는 노력도 필요없고 가장 중요한 지우는 타이밍을 알아서 계산해 준다라는 장점이 있다. 사실 이전에는 바로 이 '타이밍'을 쉽게 생각해 내는 사람이 메모리 관리와 관련하여 경험많은 사람이라 할 수 있을 것이다.
GC의 단점이라고 한다면 자신도 모르게 참조하고 있는 객체가 사라지지 않는 다는 것이다. 마시다 만 우유라고 마시지도 못할 썩은 우유가 침대 밑에 방치되는 것이다. 더 머리아프게 하는 것은 한번 이런 식으로 동작하기 시작하면 우유가 모이기 시작하고 왠지 모를 방안의 냄새로 두통에 시달리는 것이다.
(이와 관련하여.. 옛부터 건망증이 심한 나는 침대위에서 우유들고 뒹굴거리다가 있다 먹어야지 하면서 짱박은 여러개의 우유를 몇일 후에 발견하였다. 개봉된 우유가 상온에서 얼마나 변질이 잘 되는지에 대해서는.... 아우~~ @.@;)
웹 환경에서 DOM에 접근하면서 innerHTML을 바로 수정하거나 removeChild 등으로 나름대로 자식들을 깔끔하게 날려버리는 경우가 많은데 이게 가끔 잘 안되는 경우가 있다. 바로 레퍼런스가 살아 있는 경우이다. 쉴새없이 노드를 생성하고 삭제하는 욕나오는 사이트 들의 경우 잠시 밥먹고 왔는데 IE가 메모리 수십메가를 들고 있다거나.. 한숨 자고 일어났더니 IE가 뻗어버리는 경우도 발생할 수 있다.
GC에서 가장 짜증나는 부분이라고 한다면 구석에 짱박힌 객체는 대부분의 경우 외부에서의 연결이 매우 희미해 져서 아무리 Watch 창이나 DOM Browser로 찾아도 나오지 않는 경우가 많다. 또한 객체 사이즈가 작으면 작을수록 현상 자체를 인식하는 것 조차 힘들어 지기도 한다. 이게 윈도우 문제인지 IE 문제인지 알수가 있어야 말이지...
메모리가 대량으로 새지 않으면 별 문제 없지 않냐라는 이야기를 하는 사람도 있다. 요즘 운영체제는 프로세스가 종료되면 메모리가 완벽히 반환되니 delete 할 필요가 없다는 사람도 있는데 이보다는 양반이긴 하다. 뭐 가끔 개념없는 의사가 몸안에 메스 넣어 두고는 생명에 지장 없다고 하는데;;;; 반대로 티끌 메모리 누수가 이정도의 중요함이라는 것을 느끼기 바란다.

아무튼 이번에 특정 조건에서 메모리가 약간씩 흐르고 있음을 감지하였으나  나의 담당한 부분도 아닌데 PHP 3~4개를 지속적으로 호출하고 Flash 객체가 하나 끼어 있고 자바스크립트 파일도 여러개 되는 상황에서.. 나같은 JS는 여자이름 '지선'의 약자인가 하는 프로그래머로서는 쥐쥐다.

뭐 담당자에게 대충 조사결과 보고하고 잡으셈 하고 하겠지만... 정말 마지막 한톨까지 찾아내려면.. 쿼드 디스플레이로도 부족하고 헤테로 이상이 필요한지도;;;;;

잡담.
아무튼.. PHP라던지.. JS등은 사실 생산성적인 부분이 강화되어 언어가 디자인 되었는데 이것이 널리 쓰이고 상당히 핵심적인 요소가 되다 보니 태생적인 부작용이 나오는 지도 모르겠다. IE에 사이트 켜놓고 퇴근했다가 아침에 보면 컴터가 미쳐가고 있는 것도 가끔 보고... 몇몇 웹 어플들의 삽질도 보이고.. (태터도 뭐 몇몇의 머리속에만 들어있는 삽질의 부분이;;)

이런 식으로 가다간 프로그래머들의 월급이 더 줄어 들지도 모르겠다. 신입들의 진입 장벽은 낮아지고 대신 버그에 의한 손실로 IT의 이익을 많이 까먹으니... 정말 C++처럼 어려운 새로운 언어의 등장이 필요한 시기인지도 모르겠다.