[칼럼] 프로그래머의 35세 정년설에 대하여

이 칼럼은 개발자 천국을 꿈꾸는 최강의 IT 포탈 DEVPIA의 김수동님이 작성하셨습니다.

 

프로그램의 질에는 큰 차이가 있다.

프로그래머에 관한 설의 하나로서 유명한「35세 정년설」이 있다. 간단하게 말한다면, 프로그래밍의 일은 젊을 때 밖에 하지 못하고, 35세 당으로 능력이 저하하므로, 은퇴하는 편이 좋다고 하는 내용이다. 무엇을 근거로 누가 말하기 시작했는지 불명하지만, 꽤 넓게 널리 알려지고 있다. 그런데 , 실력이 있는 사람만큼 부정하고 있지만, 유감스럽지만, 설득력이 있는 반론을 본 적이 없다. 거기서, 조금 논리적으로 부정해 보자.

최초로 주목하고 싶은 것은, 프로그래머의 레벨이다. 같은 언어로 프로그램을 만들 수 있다고, 전원이 같은 레벨은 아니다. 완성된 프로그램의 질에는, 하늘과 땅 정도의 차이가 있다. 질 높은 프로그램이 안정되어 만들 수 있는 만큼, 레벨의 높은 프로그래머, 즉 우수한 프로그래머다.

그럼, 프로그램의 질과는 도대체 무엇일까. 처리 속도나 사이즈도 소중하지만, 그것 만이 아니다. 파악성, 유연성, 신뢰성등도 고려해 만들 필요가 있다. 파악성이란, 프로그램의 원시 코드로, 처리 내용의 읽어내기 쉬움을 의미한다. 유연성이란, 기능의 변경이 용이하고, 변경해도 버그가 나오기 어려운 일까지 포함된다. 1개의 프로그램내의 이야기 뿐만이 아니라, 프로그램의 분할 방법에도 크게 관계한다. 신뢰성이란, 버그가 적은 것과 메모리 부족등이 엄격한 환경에 강한 것이다. 시스템을 변경하면서 길게 이용한다면, 유연성이 높지 않으면 신뢰성도 높게 유지할 수 없다. 변경이 용이하지 않으면, 변경 후의 신뢰성이 저하하기 쉽기 때문이다.

이것들 전부를 맞춘 평가가, 프로그램의 질이다. 다만, 대상이 되는 프로그램에 의해서, 평가 기준은 조금씩 다르다. 처리 속도가 매우 중요하면, 파악성이나 유연성을 희생하고, 속도를 추구한 프로그래밍 방법을 선택한다. 반대로 변경이 많은 경우는, 처리 속도를 희생하고, 파악성이나 유연성이 높은 만드는 방법을 채용한다. 즉, 프로그램의 질이란, 요구되고 있는 특징에 적합하고 있을지도 포함하는 것이다. 최근에는, CPU의 처리 능력이 향상하고 있기 때문에, 파악성이나 유연성을 중시하는 경향이 강하다. 이러한 요망에 응하고, 프로그램을 만들어 나눌 수 있으면, 정말로 우수한 프로그래머이다.

이상과 같은 점을 고려하지 않고 만들어진 프로그램은, 트러블을 일으키기 쉬울 뿐만 아니라, 변경이나 이식등에서 여분의 수고나 코스트를 일으키게 한다. 좋은 프로그램과의 차이는, 아주 조금이 아니고, 매우 큰 것이다. 상당히 참아도 무시할 수 없을 정도 크다.

 

프로그램의 질을 높이려면 폭넓은 지식이나 기술이 필요.

 

프로그램의 질을 높이려면 , 프로그래밍 이외의 기술도 필요하다. 예를 들어, 제대로 테스트를 하는 기술로, 신뢰성을 높이기 위해서 도움이 된다. 또, 개발툴의 사용법, OS나 동작환경의 기능등도 이해해야 한다. 더하고, 프로그래밍에 관한 설계 기술도 구할 수 있다.

여기까지의 이야기로, 완성된 프로그램의 질을 향상시키는 것으로, 테스트등의 기술을 마스터 하는 것이 필요하다고 알았다. 그럼, 이것들을 체득 하려면 , 얼마나의 시간이 걸릴 것이다인가. 실은, 사람에 의해서 크게 다르다.

우선, 본인의 능력에 관계하는 부분이다. 프로그래밍에의 적성이 있으면, 프로그램의 처리 속도나 사이즈에 관해서는, 자료를 모아 공부하는 것으로 어떻게든 된다. 프로그래밍에 대한 적성이 높은 만큼, 단기간으로 마스터 할 수 있을 것이다. 신뢰성의 향상에 관해서도, 최근에는 정보가 많이 나와 있으므로, 찾아 공부하면 어느 정도는 마스터 할 수 있다.

그 이외의 항목이 되면, 독학에서는 어렵다. 해설한 책이나 정보가 거의 나와 있지 않기 때문이다. 어떤 환경에서 일하는지, 어떤 사람과 함께 일할지가 제일 크게 영향을 준다. 특히, 파악성이나 유연성의 필요성은, 좀처럼 이해할 수 없는 것 같다. 타인이 만든 시스템의 멘테넌스를 경험하고, 파악성 등 고려하고 있지 않는 프로그램을 몇개정도 보면, 필요성을 몸으로 알려진다. 그런데 , 그런 경험이 없으면 이해하는 것은 꽤 어렵다. 그런 경험의 후에, 파악성이나 유연성을 향상시키는 방법을 배우면, 정말로 이해하면서 기억할 수 있다. 테스트 기술도 마찬가지로, 제대로 한 테스트를 실시하고 있는 사람이 가르쳐 주지 않으면 좀처럼 마스터 할 수 없다.

게다가 설계 기술과 같이, 어느 정도의 경험이 필요한 것도 있다. 처음은 좋다고 생각해 설계해도, 나중에 발생한 기능의 확장에 대응 하기 어렵고, 설계가 실패(이었)였다고 생각하는 경험도 중요하다. 어떤 설계가 베스트인가, 같은 의식을 가지는 동료와 몇번이나 토론하는 것이, 설계의 능력을 높이는 것에 도움이 된다. 여러가지 생각해에 접해보다 많은 아이디어를 시험하는 것으로 설계 기술이 닦아진다.

이와 같이 보고 가면, 단순한 경험 연수만으로는 안된 것이 밝혀진다. 독학만으로는 어렵기 때문에, 제일 중요한 것은, 많은 기술을 마스터 할 수 있는 환경에서 일하는 것이다. 또 하나, 폭넓은 기술을 마스터 하려고 하는 본인의 의식도 중요하다. 그 양쪽 모두를 채워, 본인의 적성이 높으면, 최단이라면 5년 정도의 기간에 몸에 걸칠 수 있다고 생각한다. 반대로, 그런 환경에 없으면, 몇 십년 경험해도 체득 할 수 없다.

 

우수한 프로그래머 만큼 정년설과 무관계.

 

소프트웨어의 업계는, 기술 혁신이 격렬하다. 그 때문에, 새로운 기술을 마스터 하지 않으면 한 사람 분으로서 일을 할 수 없다. 정년설의 배경으로서 연령이 높아지는 것으로, 신기술을 마스터 할 수 없는 점이 포함되어 있을지도 모르다. 그러나, 35세 당으로 신기술을 마스터 할 수 없게 되는 것일까. 새로운 기술은 등장하지만, 내용이 획기적으로 새로운 것은, 거의 없다. 외관이나 사양이 다른 것만으로, 새로운 부분은 조금 밖에 포함되지 않은 것이 현상이다. 기존의 기술을 제대로 체득 하고 있으면, 고생을 하지 않고 마스터 할 수 있다. 연령이 높아지면 기억력은 저하하지만, 35세 정도에서는 아직도 괜찮아.

최근의 새로운 기술 중(안)에서 주목해야 하는 것은, 객체 지향의 생각이다. 프로그래밍의 세계에도 깊게 침투해, C++나 Java가 주류가 되고 있다(선진적인 유저는 이미 이행 했다). 이런 종류의 기술이 전과 크게 다른 것은, 힘을 만드는 방법이 통용되지 않는 점이다. 객체 지향은, 설계에 있어서의 생각이 중심이 되고 있다. 그 때문에, 객체 지향의 설계 사상을 이해 없으면, 좋은 설계나 프로그래밍은 할 수 없다. 즉, 힘에서는 잘 다루지 못하고, 우수한 프로그래머 밖에 특징을 살릴 수 없는 도구다. 이러한 툴의 등장에서, 프로그래머의 능력차이는 더욱 더 퍼지게 되었다.

문제인 것은, 이러한 새로운 생각이 많은 기술을, 35세 이상에서도 마스터 할 수 있을까다. 이 점이야말로, 이번 테마의 중심일 것이다. 자신의 주위를 보는 한, 우수한 프로그래머는“고생하지 않고 ”마스터 하고 있다. 여기서, 잘 생각하면 좋겠다. 35세를 넘었다고, 머리가 나빠지는 것은 아닌 것이다. 만약 그러면, 온 세상의 연구자는 젊은 사람(뿐)만일 것이다. 35세 이상이 되어도, 새로운 성과를 계속 낳고 있는 연구자는 많다. 머리가 나쁘게 안 되기는 커녕, 능숙하게 생각하는 기술을 몸에 걸친 사람도 있고, 보다 높은 성과를 내는 것이 가능하다. 프로그래머도 같고, 비록 60세가 되어도, 질 높은 프로그램을 계속 만들 수 있다.

또 하나, 연령이 오르는 것에 따라 철야가 어려워지는 것이 이유라고 하는 사람도 있다. 분명히, 시스템 개발에서는 철야하기도 한다. 그러나, 철야의 회수가 많은 것은, SE나 프로그래머가 우수하지 않기 때문이다. 레벨의 낮은 사람을 기준에 정년설을 주장한다면, 그러한 조건을 붙여야 하는 것이다.

 

이제 결론을 말하자. 프로그래머의 35세 정년설은 분명하게 실수다. 그 뿐만 아니라, 우수한 프로그래머는, 머리가 노망까지, 질 높은 프로그램을 계속 만들 수 있다. 만약 본인이 프로그래밍을 정말 좋아하면, 좋은 프로그램을 자꾸자꾸만들어 주는 편이 좋다. 시스템의 신뢰성이나 유연성이 높아져, 유저도 큰 혜택을 얻을 수 있다.

반대로, 우수하지 않은 프로그래머는 어떻겠는가. 어떻게 해야 하는가는 사람에 따라서 다르다. 제대로 한 경험이 없는 것이 원인이라면, 지금부터에서도 공부하고 경험을 쌓으면, 우수한 프로그래머로 변신할 수 있다. 그러나, 프로그래밍에의 적성이 없는 것이 원인이라면, 일을 바꾸는 것이 현명한 선택이다. 이 일은, 이용자에게의 폐가 발생하므로, 본인만의 문제는 아니다. 어느 쪽인가 판단하기 위해서도, 여러가지 기술의 체득을 시험해야 하는 것이다.

마지막으로, 개발비의 이야기를 해 두고 싶다. 프로그래머의 생산성은, 최저와 최고를 비교하면, 적게 봐도 10배는 다르다. 우수하지 않은 프로그래머를 몇 사람 모아도, 고생이 증가할 뿐으로 이득은 되지 않는다. 우수한 프로그래머에 수배의 보수를 지불하고, 열심히 일해 주는 편이, 좋은 시스템을 구축할 수 있다. 실제로는, 보수는 2~3배 당으로 침착하므로, 개발비를 생각하면 싸게 들다(2~3배를 추천 하고 있는 것은 아니다). 같이 우수한 SA(시스템 어널리스트)나 SE를 모아 어느 정도까지 비싼 보수를 지불하는 편이 좋다. 다만, 이것을 실시하려면 , 우수한 사람을 판별하는 능력이 필요하고, 우수한 사람 밖에 우수한 사람을 분별할 수 없다. 그것이 간단하지 않기 때문에, 결국은 어렵다고 할 수 밖에 없다.