꿈을 코딩하는 프로그래머.

싸이클을 탄지 3년.

그동안 제대로 자전거 청소를 한건 한번뿐.

그래서 이번에 마음먹고 자전거 대청소를 했다. 

준비물 : 오렌지 세정제, 체인 분리기, 육각렌치, 십자드라이버, 체인 기름(필름 뭐시기), 칫솔, 신문지 등등

우선 체인을 풀어보기로 했다. 뒷바퀴를 빼고,  가이드폴리나 체인폴리를 풀어주면 빠지겠거니 하고 근육을

쥐어 짜내어 다 풀었건만... 안빠진다. 하. 멍청하다. 그게 왜 빠질거라 생각한건지. 처음부터 체인을 풀었어야

했다.. 근데 어떻게 풀지? 검색 해보니 체인 분리기가 필요하다. 다행스럽게 내가 가진 만능 렌치에 체인 분리기가 포

함되어 있다. 체인을 오렌지 세정제에 담가 몇시간 놔두길 두번 반복하고, 뒷바퀴의 스프라켓에 세정제를 뿌려 세척

그리고 체인링도 기름을 쫙 제거 했다. 검은 기름때가 모두 씻겨가니 막힌 가슴이 뻥 뚫렸다. 어떻게 타고 다닌건지.. 

앞으로는 자주 닦아줘야 겠다. 프레임 역시 전체적으로 세제로 씻어내주고 거품을 모두 닦아낸 후엔 바로,

마른 걸레로 닦아 주었다. 그리고 건조 시킴과 동시에 담가둔 체인을 꺼내어 보니 기름기가 제거되어 은빛깔을 내며

번쩍인다. 사이사이를 칫솔로 닦아주고 이제 다시 체인을 연결. 그런데 연결부분의 체인이 너무 뻑뻑하다. 다시 풀고

조이고를 반복하고, 해당 체인을 힘주어 양옆으로 구부리자 다시 부드러워 졌다. (인터넷에서 롱노즈로 풀어주라는걸

본 기억이 있었으나, 롱노즈가 없어서 손으로)

분해한 체인과 바퀴등을 모두 조이고나서, 전체적으로 기름칠을 해주었다. 스프라켓, 체인링, 체인 그리고 프레임이나

사이사이 나사등에도 분사하여 문질러주었다. (전에 엔지니어인 친구가 이렇게 하라고함)

드디어 끝났구나 이제 밥먹어야지! 하는데. 왠 길쭉한 나사 하나가 수줍게 날 바라본다. 머리가 띵해온다. 저놈이 왜 

저기에 있는거지. 누가 가져다 놨을리는 없고. 다시 자전거를 분해하여 나사 위치를 찾아보는데. 아무리 찾아도 안나

온다. 그렇게 몇시간을 확인한 결과. "왠지 이 나사 전부터 여기 버려져 있던것 같아" 라고 착각을 하기 시작했다.

그렇게 힘겨운 자전거 청소를 마무리 할 수 있었다.

PS : 남은 나사 하나는 전조등을 연결하는 나사였다.

출하를 몇일 앞두고, 프로그램 전반적으로 메모리 누수가 발견됬다.

원인은, 객체를 동적 할당하여 이곳 저곳 벡터에 포인터 값을 넘겨 저장하고,

벡터의 멤버함수 close()를 호출하여 마무리 작업을 완료 하였기 때문. (당황스럽지만 실제 발생된 일이다.)

실수라고 보기엔 너무나도 어이없고 당황스러운일. 아무튼 문제를 빨리 해결하는게 급선무.

그럼 그냥 delete문만 추가해주면 되겠네?? 하지만 현실은 그리 호락호락 하지 않다.

동적 할당된 구조체의 주소를 이곳 저곳 벡터에서 동시에 사용 하다 보니, 어느 하나의 벡터의 요소들을

먼저 delete 해버리면, 다른 vector에 혹시라도 중복된 요소가 있을경우, 그 요소가 가리키는 메모리가

해제된걸 알지못하고 두번 delete하는 일이 발생하여 결국 프로그램 Down으로 이어진다.

그럼 어떻게 하냐고??

세가지 방안을 생각해봤다.

첫째, 동적 할당된 주소를 넘겨 처리하던 구조를 정적할당한 구조체 자체로 넘겨주는 구조로 변경한다.

이렇게 되면 해당 벡터의 요소를 참조하는 모든 부분의 접근 연산자를 '->' 에서 '.'으로 변경 해주어야 한다.

물론 이는 탐색 변경 기능으로 빠르게 수정 가능하다. 다만 메모리 사용률이 동적할당 주소값을 사용하던 시절보다

많아진다는 단점은 있었다.(당연히 동적 할당된 메모리를 처리하지 않아 누수되는것보단 백번 낫다)

둘째, 동적 할당된 주소들을 관리하는 로직을 추가한다. 이 방법을 사용 하면 첫째 방법에 비해 메모리 효율이 있고

지금의 구조는 그대로 유지 가능하나, 추가 로직을 구현하고 전반적으로 많은 테스트가 필요하다는것이 상당히

번거로우며 시간적 효율이 없어 보인다.

셋째, Boost 라이브러리의 Shared Pointer를 사용 한다. 이 방법을 사용 하면 동적 할당된 메모리의 해제를 직접

해줄 필요가 없다. 메모리를 참조하던 변수들의 개수가 0이 되는 순간(내부 참조 카운트를 가진다) 스스로를 delete

하는 아주 쓸모있는 포인터이다. 다만 한번도 써본적이 없어서 사용 방법을 익히고 동작 매커니즘을 이해해야 한다는

수고는 있다. (첫째 방법과 마찬가지로, 벡터 요소를 참조하는 모든 로직의 수정이 필요하다.)

자 어떤 방법을 사용 할까? 선택은 내 몫이다. 

*Shared Pointer : 동적 메모리의 주소값을 참조하는 변수들을 자체적으로 Count한다. 이를 레퍼런스 카운트라

하는데, 레퍼런스 카운트가 0이 되는 순간 스스로를 delete 시킨다. (즉 New가 있으나 Delete가 없는 광경)

*Weak Pointer : Shared Pointer가 스스로를 참조할경우 레퍼런스 카운트가 꼬이는? 현상을 방지하며, 해당

Shared Pointer가 가리키는 동적 메모리가 존재 하는지를 판별하는 용도로 사용 된다.(설명이 어렵다.)

*Smart Pointer : Pointer가 선언 범위를 넘어가는 순간 소멸자가 호출되고 소멸자 내에서 자기 자신의 동적 

메모리를 삭제 한다.

 책 제목을 보라. 얼마나 흥미진진하고 궁금증을 자아내는가. 컴퓨터 과학이고 컴퓨터 공학으로 분류되며

누군가에겐 지적 노가다 작업인 프로그래밍이 상상이라니. 제목에서 부터 강한 예술의 냄새가 풍기지 않는가.

 프로그래밍을 단순 노가다 작업으로 여기고 평가 절하하는 사람과, 모든 작업에 상상력과 창의력을 부여하며

창조적이고 예술적으로 여기는 사람에겐 큰 차이가 존재한다. 바로 프로그래밍을 통한 '기쁨'이다. 프로그래밍을

어떻게 생각하고 행하는가에 따라 만들어지는 결과물은 분명 큰 차이를 갖게 된다. 프로그래밍은 생산성의 향상을

위해 과학과, 공학과 결합한 컴퓨터 공학이나 컴퓨터 과학과는 다르다. 무에서 유를 창조하며 사용자에게 감동이나

재미 즐거움을 전달한다는 점에서 이미, 감각적이고 창의적인 프로그래머의 손끝을 통해 탄생한 예술 작품인 것이다.

임백준 작가는 이와 같은 프로그래밍의 즐거움과 예술성을 책의 전반에 걸쳐 이야기 한다.

 책 발간 당시의 여러 관심사와 최신 IT 트렌드에 대해서 이야기 하고 있지만, 2004년에 발간된 책이니 만큼 지금의 

최신 트렌드에 많이 뒤쳐져 있는 내용이다. 하지만 '최신' 이라는 속성만 제외 하고 본다면 개발자로써, 그리고 IT 상식

으로써 충분히 알아 두어야할 내용 들이라고 생각한다. 에자일 프로그래밍 방법론, 자유 소프트웨어, 웹3.0 등이 그렇

다. 또한 리팩토링, 객체지향, 디자인 패턴등에 대한 개요는 본격적인? 이론은 아니었지만 핵심을 살짝 들여다 볼 수

있어서 좋았다. 왜 필요하고 공부해야할 가치가 있는 이론들인지 느껴졌다.

 좋은 개발자가 되기 위해서는, 알고리즘이나 디자인패턴과 같은 테크닉 뿐만 아니라 개발에 대한 태도나 마음가짐

사람들과의 커뮤니케이션이나 논쟁과 같은 비기술적인것들도 중요하다는 것을 깨달았다. 

- 프로그래머에게 필요한 본질은 논리력, 끈기, 순발력. 프로그래머는 상상하기 떄문에 행복하다.

- 프로그래밍은 프로그래머에게 놀이다!

- 웹 2.0, 시맨틱 웹, 웹 3.0

- 가상화 기술

- 리아 시장

- 서비스 중심 아키텍쳐(SOA), SOA가 추구하는 원리는 근본적으로 객체지향의 원리가 지향하는 바와 다를 바 없다.

- 매쉬업

- 하드코어 프로그래머, 멀티 쓰레딩

- 메타프로그래밍

- 상황중심의 프로그래밍(Aspect Oriented Programming)

- 유닛테스트

- 프로그래밍을 구성하는 일곱 개의 단계

- 애자일 프로그래밍 

- 프로그래밍은 예술이다.

- 소설처럼 읽히는 프로그래밍