이전 누군가의 코드를 유지 하려는 것.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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