개발자는 마침표 대신 세미콜론을 찍는다
"우리는 무익한 것에서 생명을 얻고 유익한 일을 하면서 탈진한다. 유익한 일로 말미암아 우리는 파멸하고 죽게 될 것이다."
- 조지오 망가넬리
문장의 종결은 마침표다.
문장이 끝나지 않으면 이야기도 끝나지 않는다; 우리의 일상에도 쉼표가 있고, 삶의 마디마디에는 끝과 새로운 시작을 알리는 마침표가 필요하다; 마침표는 새로운 시작을 의미한다; 종결감 없이는 새로운 것을 시작할 수 없다; 소프트웨어 개발도 마찬가지다; 프로젝트의 시작이 있으면 끝이 있기 마련이다; 개발이 끝나고 끝없는 유지보수에 종결감을 느끼지 못할수도 있지만, 엄연히 하나의 프로젝트에는 시작과 끝이 있다; 소프트웨어 개발자는 통상 수개월마다 새로운 프로젝트를 시작한다; 불행하게도 대부분의 개발자들이 종결감이라는 것을 느끼지 못하고, 쉼표와 마침표의 존재를 잊은 채 살아가고 있다; 개발자들이 한 라인의 코드, 즉 프로그램의 문장에 찍는 마지막 부호는 쉼표도 마침표도 아닌 세미콜론이다; 세미콜론은 종결을 의미하지 않는다; 그것은 단지 문장과 문장을 구분하는 구분선일 뿐이다; 일반적인 문장에서 세미콜론(;)은 쌍반점( 雙半點)으로 속성상 일종의 쉼표이지만, 잠깐 쉬었다가 다시 설명을 이어나가야 하는 경우에 쓰인다; 그래서 그것은 쉼표라기보다는 구분선이며 연장선일 뿐이다; 수많은 세미콜론은 시작도 끝도 없는 개발업무를 상징한다; 일종의 톱니바퀴에 불과한 개발자들은 한 프로젝트가 끝나면, 바로 다른 프로젝트에 투입된다; 프로젝트의 시작은 있는데, 끝이 없다; 개발자들의 하루하루는 이슈와 버그, 그리고 그 해결의 연속이다; 다음날도 똑같은 이슈에 시달리고, 그 이슈가 일단락될 즈음이면 또다시 새로운 이슈가 불거진다; 문제와 그 해결, 그리고 또 다른 문제 사이에는 쉼표도 마침표도 아닌 세미콜론만이 존재한다;;;;;;;;;;;
개발자들이 프로그래밍의 문법에 갇혀 있듯 그들이 업무 속에 갇혀 있는 근본적인 이유는 회사나 조직에 있다. 무리한 개발일정으로 잔업과 개인에 대한 희생이 강요된다. 죽자살자 몇달을 고생해서 프로젝트가 끝나도 팀원들은 종결감을 느낄수가 없다. 표면상 프로젝트 일정 관리의 문제처럼 보이지만, 실상 관리자나 경영진의 잘못된 인식과 태도가 가장 큰 원인이다. 십여년전만 하더라도 잔업과 야근을 당연시하던 사회풍토가 주 40시간 정착 및 주당 52시간 이하 근무 규정등으로 변하고 있다. 하지만 여전히 야근을 밥먹듯이 하는 직군과 직업, 그리고 회사들이 있다. 대기업은 점점 처우와 복리후생이 좋아지고, 유동근무제로도 모자라서 자택근무까지 도입하는 판국에, 조그마한 회사들에서는 야근비도 없는 연장근무를 강요당하는 일이 여전히 일상사다. 말로는 정시퇴근을 외치는 회사들에서도 잔업과 야근은 일상화되어 있다. 이는 비현실적인 개발일정 때문인 경우가 대부분이다. 언제나 개발일정은 비현실적이다. 얼마전 신규 거래가 성사되어 조만간 프로젝트 킥오프를 할 예정이었다. 아직 구체적인 사양이 협의되기 이전의 프로젝트 초기 협의 단계였다. 하루는 경영진이 프로젝트에 할당된 팀원들과 관리자에게 다음과 같은 이메일을 보냈다.
"중요한 프로젝트이므로 지금보다 일정단축을 해주시기 바랍니다."
서글픈 현실은 아직 아무런 일정이 나오지도 않은 상태였다는 것이다. 일정을 보고한 적도 없었다. 어떻게 단축을 하라는 말인가? 아직 일정이 없는데 무작정 줄이라는 말은 말인가, 막걸리인가? 그냥 말 그대로 받아들이면 어떤 일정이 나오든지 무조건 줄이라는 이야기다. 밤늦게까지 일하고 주말에도 출근하라는 얘기다. 개발자를 한없이 자기방어적으로 만들수밖에 없는 이런 관리방식은 어디서 나오는 것인가?
시작부터 이렇게 쪼아대는 이유는 경영자들이 과거에 무리한 일정단축으로 좋은 효과를 보았던 경험이 있어서가 아니다. 본질적인 이유는 단지 불안하기 때문이다. 매번 지연되는 프로젝트와 막판에 발생하는 문제들을 경험해온 그들은 불안하다. 그래서 시작부터 개발자들을 쪼아대며 일정을 다그친다. 근거는 없다. 단지 불안할 뿐이다. 불안의 이유는 현재 상태가 제대로 진행되고 있는지, 그리고 미래의 결과가 성공적일지를 가늠하고 확신할 만한 수단이 그들에게 없기 때문이다. 그렇게 확신을 하지 못 하는 이유를 따지고 들어가보면 쉽게 말해 무능함 때문이다. 무능력은 선천적인 문제가 아니다. 무능함의 원인은 현실을 직시하지 못하고 개선의 방안을 찾지 못하는 태도에 있다. 경영진은 올라오는 보고에만 수동적으로 의존한 채 독단적인 판단을 내릴 것이 아니라, 적극적으로 맨 밑바닥 수준까지 상황을 파악하려고 노력해야 한다. 이슈 관리 시스템을 개발자만 쓰라는 법은 없다. CTO는 수시로 이슈 관리 시스템에 로그인해서 프로젝트의 돌아가는 형국을 파악해야 한다. 비록 초기에는 정확성이 다소 떨어지더라도 최대한 제대로 된 프로젝트 성과 측정을 할 수 있도록 끊임없는 시스템 개선을 주도해야 한다. 이것들은 경험에서 축적된 능력과 지혜 없이는 불가능한 일들이다. 특히나 개선이나 효율의 원뜻을 알지 못 한채 과거의 행태를 되풀이하는 경영자나 관리자들에게는 더욱 쉽지 않은 일이다.
개발자들은 무리한 개발일정의 압박에 어쩔수 없는 하책으로 대응하게 된다. 야근을 불사하며 무리한 일정에 주말까지 나와서 일 하게 된다. 프로젝트가 실패하는 경우 어쩔수 없이 역부족이었다는 증거를 남기기 위함이다. 이런 사실에 대해 소프트웨어 공학의 거장이었던 제리 와인버그(Jerry Weinberg) 또한 동의한다. "사람들이 초과근무를 하는 이유는 과제를 주어진 시간 안에 끝마치기 위해서라기보다는, 일을 정해진 기간까지 끝마치지 못했을 때 비난받게 될 것을 우려해 자신을 보호하기 위함이다." 다들 인정하려 하지 않겠지만 하책으로 근근히 살아가는 직장인들의 정곡을 찌르는 말이다. 톰 디마르코는 그의 책 <피플웨어>에서 이렇게 이야기했다. "직장인에게 있어 초과근무란 세상 물정 모르는 관리자의 상상이 만들어낸 허구에 지나지 않는다. 시간에 쫓기며 일하는 사람들은 일을 더 잘하는 것이 아니라 단지 더 빠르게 일할 뿐이다." 야근을 하지 않고, 일정안에 일을 완수하면 어리석은 관리자나 경영자는 다른 시선으로 당신을 쳐다볼지도 모른다. 일이 너무 쉽고 적은 것으로 오해해서 더 많은 일을 줄 수도 있다. 이런 상사들과 일하려면 능력껏 일하는 것이 중요한 게 아니라 눈치껏 일하는 것이 훨씬 중요하다.
중세에는 종교의 영향으로 인해 시간이 신의 소유라고 믿었다. 그래서 태만은 죄악이었다. 현대사회에서 직장인들의 시간은 본인 스스로가 아닌 회사에 귀속되어 있다. 근무시간은 그렇다고 할 수 있다. 하지만 그 근무시간이 정해진 출근과 정해진 퇴근까지의 업무시간만을 얘기하지 않는 것이 문제다. 업무시간외 충성도에 따라 평가를 받는 것이 오늘날 대부분 회사에서의 현실이다. 소프트웨어 회사나 하드웨어 회사나 어떤 회사든 대부분 그렇다. 근무시간에 대한 잘못된 인식이 여전히 많은 경영자와 관리자들의 사고의 밑바탕에 깔려 있다.
효율과 성과가 아닌, 초과근무를 프로젝트의 기본적인 인자로 보고 있는 것이 가장 큰 문제다. 주당 40시간이라는 근무시간은 임의로 정해진 시간이 아니다. 이것은 사회적인 맥락에 의해 결정된 대의다. 사회적 인간으로서 사회적 맥락의 밖에서 움직이는 것을 정상적인 상황으로 간주해서는 안된다. 모든 사회적 구조가 사회적 합의에 따라 규정된 시간안에서 돌아간다. 이제 아이들은 주말에 학교를 가지 않는다. 상가, 학원, 업소의 영업시간 또한 이 합의된 시간에 맞춰서 돌아간다. 다시 말해 사회가 요구하는 기본적인 라이프 패턴이 규정된 법적 근무시간에 맞춰 돌아가는 것이다. 1980년도에는 모두가 토요일에 일을 했고, 학교는 토요일에 수업을 했다. 80년대 가장들은 토요일에 가족과 함께 한다는 생각 자체를 할 수 없었다. 그러나 지금은 아니다. 여전히 쌍팔년도를 들먹이면서 개발자들의 희생이 당연한 것처럼 여기는 관리자나 경영자가 있다면 깊이 생각해볼 부분이다. 장기적이고 거시적인 관점에서 오래 일하는 것은 결코 성과와는 아무런 관련이 없다.
결국 초과근무는 기본적인 옵션조차도 될 수 없다. 그것은 단기적인 극약처방일 뿐이다. 기나긴 장거리 경주에서 맨 마지막 스퍼트에서나 쓸 수 있는 마지막 수단이라고 생각해야 한다. 프로젝트를 진행하다보면 각각의 마일스톤을 맞추기 위해 어쩔수 없이 초과근무가 필요한 경우가 있다는 항변을 할지도 모른다. 만약 그렇다면 그것은 둘 중 하나일뿐이다. 프로젝트 일정 관리가 실패했거나, 애초부터 프로젝트 일정을 잘못 수립한 것이다. 경영진과 관리자가 잘못 수립된 일정에 개발자들의 희생을 당연한 것마냥 강요해서는 안된다. 한두번은 참아줄수가 있다. 하지만 그런 행태가 반복된다면 그것은 관리자의 기본적인 능력과 자질부족의 문제다. 일을 하다보면 예상치 못한 상황이 발생할 수 있으므로, 초과근무가 없을수는 없다. 단, 그 예기치 못한 상황이 많다면 그 또한 프로젝트 관리의 문제다. 마찬가지로 프로젝트 관리의 실패를 개발자의 잔업과 희생으로 메꾸는 것을 당연하게 생각해서도 안 될 일이다.
