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

4년을 몸담았던 첫 직장을 떠나게 된 날.

마지막 마무리를 잘 하고 온것 같지만 그래도 남아있는 섭섭한 마음.

좀더 잘 할 걸 하는 후회도 든다.

마지막 인사를 한바퀴 돌까 말까 고민했는데 결국은 하길 너무나도 잘했다.

많은 진심어린 응원과 조언을 들을 수 있었고, 내가 느끼는것 이상으로 많은 사람들이

나를 좋게 생각해주고 있었다는 것을 느낄 수 있었다. 너무나도 고맙고 감사할 따름이었다.

원하는 회사에 가기 위해 오랜기간 노력했다. 그리고 결국 그 꿈이 이루어졌다.

실감이 나지 않는다. 익숙하고 정든 둥지를 떠나 낯선 곳으로 날아 간다.

앞으로는 달라지자. 조금씩. 더욱 괜찮은 사람이 되자.

새해에는. 30대의 첫 시작에는 한계에 도전해보자.

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

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

벡터의 멤버함수 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가 선언 범위를 넘어가는 순간 소멸자가 호출되고 소멸자 내에서 자기 자신의 동적 

메모리를 삭제 한다.

 나의 개발 결과물은 다양한 환경 요소의 영향을 받곤 한다. 조여오는 일정. 개발 당시의 컨디션,

수많은 테스트와 검증이 진행된(그래서 안전하다고 착각을 할 수 있는) 코드에 대한 믿음과 신뢰,

내 영역이 아닌 코드를 수정함으로 인해 오는 스트레스, 심지어 눈앞에 아른거리는 신상 가죽자켓에 대한 생각 등. 

나의 손끝에서 이루어지는 코딩 작업은 이러한 뇌속의 수많은 복잡한 생각들을 반영하듯 뒤죽 박죽일때도,

한편의 아름다운? 시처럼 매끄러울때도 있다. 그 중. 특히 내게 많은 영향을 끼치고 있던 것은

"이전 사람들이 구현해놓은 구조에 대한 강박" 이다.

 회사 프로젝트는 많은 멀티 쓰레드 & 멀티 프로세스 프로그램이다. 그러다보니 여러 쓰레드와 프로세스가 사용하는 

버퍼가 있는데, 이 버퍼의 용도는 다양한 구조체의 정보를 담아 여기 저기에 전달하는, 

말 그대로 데이터들의 버퍼로 사용 되고 있었다. 

 프로그램의 특정 내부의 어떤 리스트의 크기가 증가함에 따라 구조체의 크기가 증가하였고, 필연적으로 이 버퍼에도 영

향이 발생 하였다. 하지만 수정은 호락호락하지 않았는데, 미친년 머리카락처럼 꼬여있던 코드는, 단순히 전역 상수

(버퍼 크기)만 증가시켜서는 무시무시한 프로그램 종료를 피할 수 없는 지경이었다. 

나는 이 문제를 해결하기 위해 연관된 모든 사이즈, 로직 등을 전역 상수의 값으로 변경시키는 작업을 진행 하였고, 

오버플로 디버깅에 귀중한 시간들을 소모 했다. 결과는 만족스러웠다. 팀장님의 코드리뷰가 있기 전까지는..

 "뭐하러 관련된 부분을 다 수정시킨거야??. 그 기능에서 사용하는 구조체만 따로 빼서 관리하면 되는걸."

망치로 맞는 기분이었다. 저렇게 간단하고 직관적인 해결책이 있었는데, 나는 왜 그렇게 어렵고 크게 일을 해결하려

했던걸까?? 곰곰이 되짚어 보았다. 그리고 오래지 않아 그 답을 알 수 있었다. 

이유는 바로, "이전 구조와 틀을 넘어서면 무시무시한 일이 일어날 거야"라는 강박에서 비롯된 것이다. 

이 말이 틀린것은 아니다. 회사 프로젝트는 여러 사람의 공동 작업물이며, 효율과 관리를 위해 공통의 코딩규칙(그 

외에도 있다.)이나 설계가 존재 하기 마련이다. 하지만 눈앞의 사실 하나에만 집중 하면, 더 멀리 있는 본질을 

놓칠 수가 있다. 이전의 구조체와 버퍼의 흐름 구조를 유지하는 선에서의 개선방법만을 찾다 보니 그것에서 조금이라도 

벗어나는, 바로 옆의 더욱 간단하고 강력한 해결책을 놓친 나의 경험처럼 말이다.

  이전의 검증되고 안정된 코드와 모듈은 유지 하되, 필요에 따라 과감한 수정이나 개선을 할 수 있는 깡다

구와 멀리 내다 볼 수 있는 시야가 필요 하다.