Duckcoder

https://www.youtube.com/watch?v=jWqRqL4_mV0 

최근 17년전에 작성한 프로그램을 다시 추가 개발하고 있습니다.

당시 7년차일때 작성한 리눅스 프로그램으로 출장개발로 1년이 걸렸지요.

현재까지도 이 프로그램을 잘 운영되고 있고, 운영사에서 직접 유지보수하고 있지만

다른 개발자 5명 이상은 손을 거쳐간 프로그램이 되었습니다.

단순 테스트 검증시 1주일, 상세 검증은 한 달이 걸리는 나름 규모가 있는 프로그램입니다.

라인수 카운트를 해보니 6만5천줄 정도 되네요. 흥미로운 사실은 개발당시 리눅스 라이브러리에 대한 고정관념 같은게 있어서, C standard 라이브러리 이 외에는 전혀 다른걸 사용하지 않았다는 겁니다. 해당 줄 수가 실제 제가 코딩한 전부라는 거지요. xml parser, ftp 등등을 무슨 똥배짱인지 직접 다 코딩했었지죠. 이런 무식이! T.T

이 프로그램을 다시 개발하게 되었을 때 예전의 나를 보는 것 마냥 두근대고 부끄러워지더군요.

막상 소스를 열어보니 웬걸 제법 잘 짰는데..라고 생각되었습니다 (자화자찬 +.+)

main 문 안에 전부 task 처리하고, 변수는 struct 로 묶어서 전부 포인터 처리.

더 놀라운 사실은 17년동안 해당 전체 구조가 전혀 바뀌지 않은 상태로 유지되었다는 거고,

다른 개발자들도 제가 짠 구조 아래서 그 구조를 답습하여 프로그램을 개발해왔다는 사실입니다.

사실, 누구라도 외주 개발사 입장에서는 맘에 안들어도 전체를 뜯어 고치는 일은 전혀 다른 일이긴 합니다.

이번 수정은 추가 장비가 붙는 바람에 약 10% 정도 수정이 필요한 작업이었는데, 실제 집중 투여한 시간은 20일 정도입니다. 예전 7년차 개발 속도라면 2개월이 걸릴 일이 되겠군요. 17년만에 3배 이상 빨라진거 같습니다.

이번에 수정해야 할 부분 중  개발 당시 제일 애를 먹었던 알고리즘 수정 부분이 있었는데

도대체 왜 이렇게 구현했는지 소스를 따라가도 남의 소스를 보는 마냥 이해가 되지 않는 것이이었습니다.

그래서 해당 부분은 그 대로 남기고 , 오롯이 새로 코딩해보니 ,

결국 원래 부분과 똑같이 구현되는 것을 발견했습니다. 아, 그때 삽질한 게 아니었구나.. 하는 걸 알게 되었지요.

리눅스 시스템이나 쓰레드도 없는 함수 태스크 방식의 루프 프로그램이었지만

그 당시에 정말 예쁘게 짜려고 , 프로그램 경력에 오점을 남기지 않으려고 (다른 사람이 욕하는 프로그램을 짜면 안되니깐..) 나름 노력했었는데, 한참뒤에 제가 그걸 돌려받게 될 줄은 전혀 몰랐지요.

예전의 나의 모습을 거울로 다시 보는 듯한 경험.

그 당시의 고민의 흔적을 다시 되새기며, 그때 왜 그랬을까 한줄한줄 따라가다가

그 길이 최선이있다는 재발견.

흥미로운 경험이었습니다~~~

일반적으로 프로그램 과제를 진행하는데 있어 자그마한 목표들이 있다.

여러가지 사유로 인하여 지연되기도 하고 일정의 문제로 기본적인 문제를 해결하지 못한체로

땜방식으로 일을 처리하기도 한다.

한가지 중요한 사실은 "왜 이것을 개발해야 하는가" 이다.

이 질문을 놓치게 된다면 사실 개발의 의미가 없다고 보아도 된다.

예를 들면

 A 기능을 구현하기로 했다고 치자.

A 기능을 구현하여야 되는 이유와 명분, 소비자의 반응, 일정 이런 것들이 총체적으로 합쳐서 이루어져서 판단을 해야 한다. 단지 지시로 며칠까이 이런 기능만 구현해라고만 된다면, 그런 목표가 있는 사람과 단순히 코딩만 한 사람과의 결과물은 같지만 다르다.

후자는 영원히 그자리에 머물 것이고 전자는 다음번에는 같은 일을 반복하지 않거나

다시 리비전하여 원래 목표대로 완성을 할 것이다.

작은 차이가 큰 변화를 만든다.

내가 짜는 함수가 어떤 목적을 가지고 있는지 명확히 하자!