나쁜 개발자? 좋은 인사평가?

언젠가 신입사원 기술 교육을 위해 강사로 불려가서 강의를 하던 시절... 

강의실에 앉아 있던 대부분의 사람들은 코딩을 체계적으로 배운 사람이라기 보다는 전자과나 비슷한 공대를 나와서 맛보기로 C언어를 조금 배워본 사람들이 대부분이었다. 실제 코딩을 위해, 프로그래밍을 위해 알아야 할 것은 C언어니 Java니 하는 것들이 아니고(이런 것들은 그냥 며칠 들여다 보면서 눈에 익으면 그리 어려운 일은 아니다) 실제 컴퓨터가 어떤 원리로 동작하는지, 또 OS가 어떻게 자원을 배분하고 Manage하면서 실제 프로세스가 돌아가는지를 알아야 전반적으로 코딩을 잘 할 수 있다.

대학교 시절 프로그래밍 언어를 배우는 것은 전공필수도 아니었다. 듣고 싶으면 들으라는 정도였다. 실제 C언어를 배우게 되더라도 정말 필요한 Keyword들은 OS자원 배분에 관한 것이었고, 이 역시 OS가 어떻게 돌아가는 지, Program counter가 어떻게 동작하는지, 메모리는 어떻게 할당이 되서 어떻게 운영이 되는지 등등에 대한 내용이다. 회사를 다니며 가장 놀랐던 것은 이런 기본적인 내용이 아니라, 바로 현업에서 쓸 수 있는 기술 혹은 knowhow를 가르쳐야 했던 일이다. 그런 친구들에게 특수한 경우를 제외하고 Global 변수를 쓰면 안되고, 메모리 할당은 해당 Block안에서 해지를 시켜야 하며, 협업과 코드 재사용성을 높이기 위해 코드의 Readability를 높이는 등, 가장 기본적인 프로그래밍에 관한 자세한 내용을 설명할 시간이 없었다. 그저 현업에서 열심히 일하고, 바로바로 output을 내며, 디버깅을 빨리하는 사람이 인정받게되는 어이없는 현상이 벌어지게 되었다. 그래서 계획, 디자인/설계 없이 맨땅에 코딩 시작해서 화면 부터 만들고, 구조나 status machine도 없이 화면 이동은 꼬였고, 결국 나중에 event가 진행이 되면서 생산되는 엄청난 양의 버그(원인을 본인이 잘 아니까 해결도 잘 한다) 를 빠른 시간내에 해결하는 사람이, 아이러니하게도 일잘하는 사람으로 인정을 받게되는 불상사?가 발생한 것이다.

반대로 디자인/설계 잘해서(이때 문제를 해결하면 나중에 구조를 뒤집어 엎는 문제가 다수 줄어 해결 비용이 대폭 단축된다) 코딩을 해도, 바로 output이 없기 때문에 핀잔 받고, 나중에는 문제 없이 잘 도는 프로그램 짜 높으면(당연히 디버깅하는 일도 적어지니), 하는 일 없이 빈둥댄다며 인사고과를 바닥으로 받는일이 많았다. 코딩, 개발을 manage하는 사람들은 대부분 컴터 전공이 아닌데다가, 컴터 전공이라도 실제 개발자들을 운영하고, 개발 일정을 조율하며, 사용자 요구사항을 정비해 나가는 일에는 대부분 문외한 인데다가 그렇게해서 사람들을 평가하는 기준도 정반대가 되는 어처구니 없는 일들이 많이 발생하였다. 

어느해인가 그냥 맨땅에 해딩하듯 코딩해서 나중에 event진행할때 버그가 하루에 30개 이상씩 나오는데, 그걸 매일 해결하는 모습을 본 boss는 나를 무척이나 높게 평가했던 일이 있었다. 반대로 코드 재사용성을 위해 부서 전체에 담당자들 회의를 소집하고, 직접 수정파일을 설명하고, 정리해서 보내고, 후에 유지 보수까지 해주는(굳이 하지 않아도 될) 일을 뿌듯하게 했었지만, 그래서 해당 모듈의 버그가 줄어들고, 모델 분기쳐도 유기적으로 대처할 수 있게 되었지만, 실제 나에게 돌아온 건 냉소와 비웃음이었다. 물론 인정을 해주는 사람들도 있었지만, 왜 굳이 사서 고생하면서 다른 팀들을 신경써주냐는 거다. 결국 부서전체적으로 보면 내부적으로는 팀단위로 경쟁인데 말이다.

또 한번은 새로운 플랫폼으로 개발을 진행하는데, 플랫폼 구조적으로 문제가 있어 이를 해결하기 위해 플렛폼 담당자들과 수 없이 메일 주고받고, 회의하고 피터지게 토론했지만, 나에게 돌아오는 건, 왜 다른 사람들은 아무 이야기 없이 잘 개발하고 있는데, 나만 GR이냐는 것이었다. 나름 대단한 프라이드로 무장한 개발자들이었고 실력도 꽤 나쁘지 않았지만, 하나의 화면 단위를 구성하기 위해 정형화된 초기화 루틴이 없었다는 것은 결국 여기저기서 문제를 야기했고, 결국 그 문제는 피투성이가 된 채, 두가지 방법을 선택적으로 적용할 수 있도록하는 것으로 해결이 되었다. 그리고 기본 개발이 끝난 그 소스들은 모델팀으로 넘어간 뒤, 수많은 버그를 견뎌낼 수 없었던 개발자들에 의해 그 초기화 루틴을 사용하는 것으로 소스가 수정되는 대작업이 진행되었다. (내 자랑 같지만 )sample code와 guide는 내가 만든 것으로 배포 되었다.

하지만 나에게 남은 건 10년된 피투성이 갑옷이었고, 몇명으로 부터는 인심을 잃었다. 그리고 나로인해 도움을 받은 사람들은 나에게 고마워하지 않았다. 그리고 회사는 그렇게 계속 돌아갔다. 비록 망해가는 프로젝트라도 책임의식을 가지고 열심히 했지만, 결국 망했던 프로젝트의 책임자에게는 책임이 지워지지 않았고, 오히려 다른 쪽 프로젝트에 줄을 서면서 자기것으로 만들어가는 것을 아주 많이 목격하게 된다. 일종의 조직문화 처럼 말이다. 수 많은 비용과 시간은 그냥 아무것도 아닌게 되었다. 무척이나 신기했다. 어떻게 그렇게 책임으로 부터 빠져나올 수 있으며, 다른 좋은 프로젝트에는 자연스럽게 줄을 서는 모습이. 물론 그게 생존을 위한 본능이었을지 모르겠다.