Thoughts2013.12.16 17:16

저는 야근을 잘 하지 않습니다. 회사 입사한 이후로, 어지간히 급한 데드라인이 걸려 있지 않으면 야근을 하지 않습니다. 여섯시 반이면 자전거를 몰고 집으로 가서 쉽니다. 물론, 저도 처음부터 그랬던 것은 아닙니다. 많은 관리자들이 야근하지 않으면 열심히 하지 않는다고 생각합니다. (미국에도 그런 회사는 많습니다.) 야근을 회사에 대한 충성심의 척도로 생각하는 것이죠. 


그래서 가끔 사람들이 묻습니다. 왜 야근을 하지 않느냐고. 이런 질문을 받으면 여러가지로 대답이 곤궁한데, 대체로 이런 이야기를 들려주고는 합니다.





그러니까 세상에 없던 제품을 만들어 3개월 만에 시연까지 마쳐야 했던 201X년의 어느날, 저는 "3개월만에 만들 수 있겠느냐"라는 윗분의 물음에, "3개월 만에 만들어 보이겠습니다"라고 호기로운 선언을 합니다. 추정키로, 3개월이면 넉넉할 것 같아 보였던 것이죠. 


그러나 정작 업무에 돌입하자, 모든 것이 빡빡해졌습니다. 밑바닥부터 구현을 시작했던 시스템은 도무지 완성될 줄을 몰랐고, 겨우 얼개를 쌓아올린 시스템은 그다지 만족스런 성능을 보여주지 않고 있었죠. 세상에 없던 소캣 클래스를 구현해야 했고, 세상에 없던 파일 시스템도 만들어야 했습니다. 그리고 거기에 단말을 물려, 비디오가 성공적으로 전송되고 재생되는 것 까지 보여야 했죠. 


솔직히 말해서, 회사에 출근해서 자리에 앉는 아홉시부터 저녁 퇴근하는 여섯시 반까지, 밥을 먹거나 화장실을 가거나 간식을 먹거나 차를 마시는 약간의 시간을 제외하고, 제 눈은 항상 모니터를 보고 있었습니다. 저녁에 퇴근할 시간이 되면 눈에서 눈물이 줄줄 흐르는 일도 많았죠. 


그러나 이렇게 일할 수록, 저는 '가능하면 야근은 하지 않는다'는 원칙을 포기하지 않았습니다. 야근 한다 해도 여덟시를 넘기지 않았습니다. 저는 이런 식으로 개발을 진행했습니다.


(1) 진행중인 디버깅은 무조건 다섯시 반까지 마친다: 뒤집어 이야기하면, 다섯 시 반까지 끝낼 수 없는 디버깅은 시작하지 않았다는 뜻입니다. 디버깅이 마무리되지 않은 채로 퇴근하면 집에서도 내내 그 생각만 하게 되기 때문에, 무조건 다섯 시 반에 일을 마감하고, 여섯시 반 까지는 잡무를 처리했습니다. 


(2) 소스 코드 관리 시스템을 적극적으로 활용해, 언제든지 이전 상태의 소스코드로 되돌릴 수 있는 준비를 한다: 그 덕에, 수정하고 테스트하는 과정에서 시스템에 돌이킬 수 없는 상태에 빠졌을 때 언제나 이전 코드로 되돌아갈 수 있었습니다. 그래서 시스템이 이상동작해도, 언제든지 손을 놓고 퇴근할 수 있었습니다. 다음날, 최종 commit 지점으로 돌아가면 충분했기 때문이죠. (이런 류의 작업에는 Git이 갑입니다.)


(3) 도무지 해결책이 보이지 않을 때는 알 만한 사람들을 귀찮게 한다: 그래서 꽤 많은 사람들을 만나고, 그들의 이야기를 들었습니다. 그들의 조언은, 거의 항상 저에게 새로운 돌파구를 보여주었습니다. 일단 돌파구라고 생각되는 지점을 만나면 미련없이 진격했고, 그 결과는 거의 항상 성공적이었습니다. 


(4) 일 이외에는 아무것도 보지 않고 말하지 않는다: 그리고 그 3개월 동안, 저는 업무 이외의 분야에는 인터넷을 사용하지 않았습니다. (일이 없었다면 불가능했을 겁니다.) 대화 내용은 항상 일과 관계된 것이었고, 일 이외의 것에 대해서는 별로 이야기를 하지 않았습니다. 


그랬던 탓인지, 최종 시연이 오는 그날까지 아무도 저의 칼퇴근을 문제삼지 않았습니다. 중요한 것은 회사에서 보내는 시간의 질이지 양이 아니라는 사실을 점차로, 저와 함께 일하는 직속 상관도, 동료도 모두 이해해 주었습니다. 그리고 그 모든 시간이 결국 저의 평판을 만들었습니다. 


저는 이렇게 생각합니다. 누군가 야근을 강요한다면, 그것은 그 사람이 당신이 어떻게 일하는지 보지 못하기 때문입니다. 당신의 직속 상관 마저도 당신에게 야근을 강요한다면, 그것은 당신의 직속 상관마저도 당신이 어떻게 일하는 지 알지 못한다는 뜻입니다. 자주 보고하세요. 중요한 일은 가장 먼저 직속 상관과 상의하세요. 귀찮더라도 그것이 답입니다. 당신이 어떻게 일하는지 알게 만든다는 것. 그것이 가장 중요합니다. 일을 대하는 당신의 태도에서 자연스럽게 느끼게 하던, 이메일을 통해 느끼게 하던, 당신은 당신이 무슨 일을 하고 있으며 그 일을 얼마나 소중하게 생각하고 있는지 끊임없이 알릴 의무와 책임이 있습니다. 


물론 말하거나 보여주지 않아도 그 모든 걸 알아차려 줄 눈썰미 좋은 직속 상관 밑에서 일한다면 문제는 또 다르겠습니다만, 어디 세상이 그렇게 만만한가요.


저작자 표시 비영리 변경 금지
신고
Posted by 이병준
TAG 야근

소중한 의견, 감사합니다. ^^

  1. 키레네

    (4)번이 가능해야 나머지 것들도 가능하겠네요. ^^;
    대부분의 사람들은 (4)번 지키기를 너무 힘들어 하니 ..
    (4)번을 지키셨다는 것 자체로도 대단하고 아무나(?) 따라할 수 있는 일은 아니겠네요. :)

    2013.12.16 19:06 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 업무시간중으로 한정하고 식사시간을 빼면 어느정도는 가능하지않을까합니다.^^

      2013.12.16 19:56 신고 [ ADDR : EDIT/ DEL ]
  2. 검은무당벌레

    최근 야근이 뿌쩍 믾아진 시회 초년생입니다. 아직 배워야할 것도 많고 일을 함에 있어서 혼자 하는 것보단 협업 위주의 업무가 많아 시간이 오래 걸리는 경우가 잦습니다. 위에 쓰신 글 이외에 일을 좀 더 효율적으로 할 수 있는 노하우가 더 있는지 궁금합니다

    2013.12.17 00:19 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 말씀하신대로 숙련도가 낮은 사회 초년생일 때에는, 업무를 효율적으로 할 수 있는 방법을 잘 모르기 때문에 시간이 많이 걸립니다. 아마 한두 해 정도 시간이 지나면 자연스럽게 좋아질 것인데요. 일을 좀 더 효율적으로 하고 싶으시다고 하셨죠? 어떤 종류의 일인지 알려주시면 좀 구체적으로 답할 수 있을 것 같습니다.

      2013.12.17 08:51 신고 [ ADDR : EDIT/ DEL ]
  3. 노야그니즘은 저희팀 모토여서 저희팀도 위와같은 방법으로 사람과 시간을 최대한 활용하여 노야그니즘으로 3년간 버텨왔는데 이 시간이 누적되다보니 1년전에 팀장님이 "다른팀믄 야근이 잦은데, 일단 우리는 안하니 경영진이 올해는 얘기하네. 그렇게 어려운 프로젝트가 아니었던건지 정말로 능력이 좋아서인지." 하는 얘기를 들으셨나봅니다. 그리고 회사에 잔돈을 벌 수 있는 프로젝트를 하나 더 받으셨습니다. 그래도 야근을 안하려 다들 업무분담을 하여 일을 진행했죠. 근데 올해는 잔돈 프로젝트가 점점 늘어나더니 노야그니즘 3년이 지나니 이제는 고착화 됩니다. 이렇게 되다보니 저희 성과를 회사에서는 타팀에도 강요하기 시작했고 타팀은 저희팀을 엄청 싫어합니다. 연봉역시 몇년전이나 3년전이나 지금이나 % 유지가 아닌 강등입니다.
    요지는 이런 개인적 노하우와 노력으로 진행해와도 경영자들 입장에서는 당연한 것으로 인식되고 더욱 플러스 알파를 요구하지 고생흔적을 잘 알아주진 않는다는 생각입니다. 회사 전사적 활동이 아닌 이상에는 타팀과도 교류의 문이 닫히는 상황이고 순수개발자 회사분위기에서 정치라는 것이 시작된 느낌입니다.

    2013.12.17 10:02 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 전사적인 문제를 언급하시니 가슴이 답답해지는군요. ^^; 말씀하신 문제에 충분히 공감합니다. 이런 문제를 해결하려면 전사적인 차원에서 성과와 개발 방법론이 충분히 공유되어야 할 것 같은데요. 제조업 부문에서 이야기하는 생산 프로세스 개선과 비슷한 레벨에서 이야기가 되어야 하지 않을까 생각이 됩니다. 어차피 소프트웨어도 '생산'하는 것이니까요. 그런 부분에 대한 공유가 전체적으로 이루어지지 않으면, 개인이나 팀 차원에서 하는 노력이 빛을 잃을 수 있겠습니다. 그런 의미에서 보자면, 전사적으로 영향력을 행사할 수 있는 '목소리가 큰' 사람이 한 분은 있어야 하지 않을까 생각되는데요. 윗 선과의 소통이 부족한 상황으로 보이니 말이죠. 물론 제가 닻별님 회사의 상황을 잘 모르니 이렇게 말씀드리는 것 조차도 '뭘 잘 모르는 소리'로 들릴 가능성은 농후하겠습니다. 자주 뵙겠습니다. 감사합니다.

      2013.12.17 10:23 신고 [ ADDR : EDIT/ DEL ]
  4. 좋은글 잘 읽었습니다. 서로를 이해한다면 당연한 결과인것 같아요! 하지만 현실은 서로를 못믿어서 ㅋㅋ

    2013.12.17 19:14 신고 [ ADDR : EDIT/ DEL : REPLY ]
  5. 중요한 것은 회사에 보내는 시간의 질이지 양이 아니라는 말씀에 동감합니다.
    좋은 글로 많은 점을 느꼈습니다. 5시 반까지 끝낼 수 없는 디버깅은 시작도 않는 다고 하셨는데
    저도 그렇게 하고 싶지만, 가능할지 모르겠어요. 순차적으로 작업하는 방식을 바꾸어야 봐야겠네요.

    2013.12.18 10:18 신고 [ ADDR : EDIT/ DEL : REPLY ]
  6. Deflame

    이 분.. 제대로 애자일하시네요 ㅇㅇㅋㅋ

    2013.12.18 15:34 신고 [ ADDR : EDIT/ DEL : REPLY ]
  7. 사실상 근무시간에 땡땡이 안치고, 웹서핑 1분도 안하고, 업무에만 집중해서 일을 했다면...
    저녁 6시가 되면 녹초가 됩니다.
    더 일을 하고 싶어도 할 수 없다는...

    2014.02.06 18:14 신고 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2008.02.06 12:46
오늘 이 글을 보다가 든 생각입니다만, 좋은 개발자가 되려면, 아무래도 인간성이 좋아야 할 것 같아요. (사실 이 비슷한 생각을 한 지는 오래 되었습니다.) 왜 이런 말을 하냐 하면, 적어도 국내에서는 다음의 두 가지 가정이 유효하기 때문입니다.

1. 개발자에게 주어지는 환경이 아주 척박하다
2. 혼자서 모든 개발을 다 해내는 것은 어려운 일이다.

우리나라의 SW 개발 환경이 외국에 비해 그다지 좋지 못하다는 이야기는 나온지 꽤 오래된 이야기입니다. 대부분의 개발 프로젝트는 일정 중심적(date-driven)인 프로젝트이고, 개발을 진행하다보면 요구사항(requirements)도 시도 때도 없이 변화합니다. 다른 프로그래머들과 맞춰야 하는 인터페이스는 한두가지가 아니고, 그러다보면 가끔 굉장히 비생산적인 논쟁에 빠지게 되는 일도 허다합니다.

그런데 이런 비-프로그래머 중심적인 환경에서도 빛나는 프로그래머들이 있습니다. Guru는 아닐지라도, 다른 사람의 가치를 내 가치처럼 중요하게 여기고, 내 편의를 위해 다른 사람의 불편함을 강요하지 않으며, 섣불리 다른 사람의 능력을 폄하하지 않는, 그런 프로그래머들 말입니다.

통계적으로 보면 (어디까지나 제 주관적인 통계에 의한 것이긴 합니다만) 그런 프로그래머들일 수록 신기술을 습득하는 데 주저하지 않고, 맘에 들지 않는 기술이라고 해서 자기 잣대로 폄하하지 않으며, 다른 사람들과의 관계를 원만히 이끌어 갑니다. 남들이 귀찮아하는 TDD도 솔선수범하는 경향이 있고, 문제가 생기면 언제나 자기가 맡은 부분을 주저없이 의심하는 자세를 보여주죠.

하지만 개발 환경이 척박해질 수록, 이런 개발자들도 함께 드물어진다는 것은 서글픈 일입니다. 이런 개발자들이 점차로 드물어진다는 것은, 소프트웨어 기술자들을 계속하여 재생산해 낼 책무를 지는 개발집단들이 개발자들에게 바람직한 역할 모델을 보여주지 못한다는 뜻이기도 합니다.

그런 역할 모델을 보여주지 못하는 이유로는 여러가지가 있겠습니다만, 가장 큰 것으로는 "개발 집단의 상당수가 개발 방법론을 잘 모른다"는 것을 꼽을 수 있겠습니다.

startup 회사부터 좀 잘 나가는 회사까지 여러 회사를 접해보았습니다만, 폭포수적인 개발방법론이나마 꾸준히 적용해보려는 의지를 가진 회사도 드물었고, 일의 양을 정확하게 추정해 보려는 시도를 하는 회사는 더더욱 드물었습니다. 잘못된 추정으로 시작하더라도 중간 중간에 그것을 바로잡을 기회는 자주 주어집니다만, 그 기회를 제대로 이용하는 회사도 드물었어요.

보통은 "야근-대책없는 휴식-야근-대책없는 휴식-야근-대책없는 휴식..."을 소프트웨어를 릴리즈하는 그날까지 반복하죠. 회의시간은 보통 "지시사항 전달"로 변질되고, 개발자들은 요구사항을 내놓은 사람들과 대면하고 요구사항을 이해할 기회조차 갖지 못합니다. 결국 잘 만들어놓으면 "그게 아니었어..."가 되니까 다시 야근을 하게 되구요. 이런 상황에서라면 아무리 인간성이 좋은 개발자라도 종국에는 인간성이 더러워지지 않을까요?

소프트웨어 개발도 남과 더불어 하는 일이니까, 결국 사람과의 인간관계가 가장 중요하기 마련인데, 그 관계를 차단한 다음 닭장에 밀어넣어 놓고는 "니가 할 일만 잘 하면 돼!"라고 하는 꼴이죠. 결국은 나중에 가서 "왜 내 말을 제대로 이해하지 못한거야!"라고 할거면서 말이에요. :-P

이런 억지스러운 환경을 개선하려면 어떻게 해야 할까요? 저는 요즘 그 답을 찾기 위해 애쓰는 중입니다.




신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 자네도

    개발자가 잘못된게 아니라 중간관리자 및 경영진이 잘못하고 있습니다.
    더 골(The goal)이라는 소설만 읽어도 이정도는 아니겠다는 생각이 듭니다.

    2008.02.08 12:57 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 네. 개발자가 잘못되었다는 이야기는 한적이 없구요. ㅋㅋ 중간관리자 및 경영진을 포함하는 많은 사람들이 이런 상황을 개선하기 위해 공부를 좀 해야할것 같습니다.

      2008.02.08 17:31 신고 [ ADDR : EDIT/ DEL ]

Extremely Agile/General2008.01.22 05:55

SW 프로젝트는 일입니다. 모든 일이 다 그렇듯, 시간이 지나면 남은 일의 양은 차츰 감소하게 마련입니다. 하지만 대부분의 SW 프로젝트의 경우, 그렇지 않을 떄도 많습니다. 가장 흔한 것은, 마감 시간에 맞추어 밤을 새우는 일입니다. 일의 총량은 정해져 있을 터인데, 왜 프로젝트가 끝나갈 무렵까지 일의 양은 전혀 줄어들지 않고, 결국에는 철야를 하게 되는 것일까요?

애자일 방법론을 만든 사람들은 이 문제를 깊이 있게 연구했습니다. 그리고 그 결과, 이런 결론을 얻습니다.

일은 빵과 같다. 빵을 먹으면, 빵은 줄어든다. 일도 마찬가지이다. 일을 하면, 남은 일의 크기는 점점 작아진다. 하지만 '내가 먹으려는 이 빵이 정말로 내가 먹고 싶었던 빵인지' 한 입 베어물어 보기 전에는 정확하게 알 수 없는 것과 마찬가지로, 고객에게 소프트웨어를 인도하기 전까지는 누구도 그것이 정말로 고객이 원했던 그것인지 확신할 수가 없다.

고객이 원하지 않는 기능을 구현하게 되면, 그 기능을 구현하는 데 투자했던 시간들이 고스란히 오버헤드가 되고, 결국 고객이 정말로 원하는 기능을 구현하기 위해 프로젝트 후반부에 날밤을 새우게 됩니다. 이런 문제에 대해서는 마이크 콘(Mike Cohn)을 비롯한 여러 사람들이 많은 연구를 했고, 좋은 책도 많이 있습니다. Agile Estimating and Planning은 그 중 하나입니다.

하지만 오늘은 그 보다는 좀 더 개인적인 이야기를 해 볼까 합니다. 개인적인 견지에서 보면, 프로젝트 막바지에 더 바쁜 가장 결정적인 이유는, 프로젝트 중간 중간에 박혀있는 마일스톤 점검 시점에 반드시 해야 할 몇 가지 일들을 하지 않고 넘어갔기 때문입니다.

마일스톤 점검시에, 제가 속한 팀은 주로 그 때 까지 개발한 소프트웨어의 큰 틀이 정상동작하는지를 점검합니다. 속칭 '연동시험'을 하는 것이죠. 이 연동시험은 개발에 참여하는 여러 업체와 개발자들로 하여금 '다른 사람의 관점에서' 시스템을 바라볼 수 있도록 해 주기 때문에 굉장히 중요합니다. 그 과정에서 '개발에는 별로 적합하지 않은' 업체나 개발자가 가려지기도 하죠. ('다른 사람의 입장을 전혀 고려하지 않는 개발자'는 그 한 예가 되겠습니다. 이런 개발자일수록 '개발자의 자질'에 대해 더 많이 이야기하곤 한다는 것은 아이러니 한 일이죠. 좋은 코더가 되는 것도 중요하지만, 사실 더 중요한 것은 존중의 자세입니다.)

그런데 이 마일스톤 점검시에는 보통 자질구레한 사항이나 버그들에 신경을 쓰기 보다는, 서로 다른 사람들이 만든 시스템이 별 탈 없이 연동되어 돌아가는지를 살펴보는데 집중하는 일이 많습니다. 자잘한 문제들은 TO-DO 리스트에 적어놓는 것으로 점검을 마무리 짓곤 하죠.

문제는 그렇게 만들어진 TO-DO 리스트를 나중에는 아무도 거들떠보지 않는다는 사실입니다. 그러다보니, 데드라인이 다가오면 최종 연동시험과 병행해서 '자질구레한' 버그들도 함께 잡아 나가야 하는 일이 벌어지게 되고, 결국은 잠을 줄이게 되는 것이죠.

'엉뚱한 기능'을 구현하는 것도 위험천만한 일이지만, 진짜 '일'을 남겨두는 것도 위험천만하기는 마찬가지라는 거에요. 그런데 이런 실수를 되풀이하게 되는 이유는 대체 뭘까요?

가장 큰 이유는, 그런 '뒷마무리 작업'이 대체로 재미가 없기 때문입니다. 뭔가 그럴듯한 새 기능을 시스템에 추가하는 건 재미있습니다만, 그 부산물들을 치우는 것은 사실 지루한 일이죠. 물론, 그런 뒷마무리 작업을 충실히 할 만큼 넉넉한 시간이 주어지지 않는 경우도 있습니다. 자고 일어나면 세상은 달라져 있고 또 뭔가 새로운 요구사항은 생겨나게 마련이니까요.


PS.

이 글은 새벽 네시쯤 쓴 것 같군요.
저도 날밤을 새고 있었다는 이야기죠. ㅋㄷ



 

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. SW개발은 아니지만 나름 개발일을 하고 있는 완전공감이에요 ;ㅁ;
    내일까지 프로젝트마감을 맞추기위해 1주일전부터 완전철야중. 하루에 2~3시간밖에 못자는것 같아요 ;ㅁ;
    지금도 밤샘중 흑흑흑;;;
    왜 마지막날이 되면 온갖 수정사항들이 나오는건지 TO DO LIST가 줄질않네요.
    한개 지우면 2~3개 추가되고. orz

    2008.01.22 06:27 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그러게요. 이런 문제를 극복해 나가는 현명한 방법을 찾는 것이 개발자들이 해야 할 일이겠죠. 개인적으로는 TO-DO LIST를 관리하는 것 보다는, TO-DO BOARD(해야할 일 게시판)을 만들어 모두가 볼 수 있는 자리에 배치하는 것도 한 방법이 되지 않을까 생각하고 있습니다. 그러면 시간이 지날수록 그 게시판에 나열된 개선 항목들이 줄어드는 모습을 볼 수 있어서 좋을 거라고 생각해요. 어쩐지 '사용자 스토리'의 동어반복같다는 생각도 드는군요. 덧글 감사합니다.

      2008.01.22 06:44 신고 [ ADDR : EDIT/ DEL ]
  2. 개발자만 공감하는 얘기는 아니랍니다 ;ㅁ;
    기획자도 똑같은 짓(?)을 하고 있다죠

    제 시간관리 능력을 탓해야 겠지요 쩝

    2008.01.22 07:47 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 기획자도 개발팀의 일원이니 개발자라고 보는 것이 좋겠죠. 시간관리라는 문제를 개인 차원의 문제로 접근하면 전반적인 상황은 크게 개선되지 않을 수도 있다고 생각합니다. 가급적 팀 단위의 해결책을 찾는 것이 좋겠죠.

      2008.01.22 09:25 신고 [ ADDR : EDIT/ DEL ]
  3. 아직 프로젝트에 대한 경험이 없어서 선배분들의 얘기가 마냥 멀리 느껴집니다.OTL.....
    하지만 토이박스를 몇 번 만들어본터라 막바지에 자질구레한 일 때문에 지겹고 바빠진다는 것을 매번 느꼈습니다.;;ㅜㅜ

    2008.01.22 08:54 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그런 일들이 쌓이고 쌓이면 결국 개발이라는 것이 막판에는 재미없는 일이 되어버리겠죠.

      2008.01.22 09:26 신고 [ ADDR : EDIT/ DEL ]
  4. 저는 프로그램 개발과는 완전 거리가 먼....출판 편집을 하고 있지만 와닿네요. ㅡㅡ;;

    2008.01.22 22:19 신고 [ ADDR : EDIT/ DEL : REPLY ]
  5. ㅡㅡ;

    [펌] 해가겠습니다. ^^; 당연히 펌한 url 과 명시는 꼭 하겠습니다. ^^;
    감사합니다. 펌한 사이트 : http://cafe.daum.net/aspdotnet

    2008.02.13 00:36 신고 [ ADDR : EDIT/ DEL : REPLY ]

Thoughts2007.09.09 22:48

사실 개발자로서 '소통'의 문제를 전혀 고민하지 않은 채 독야청청 가끔 책이나 들여다보고 지식의 외연을 넓혀가는 데 지나치게 만족하고 살다 보니, 어느새 세상 돌아가는 꼴을 모르는 우물안 개구리가 되어 있더군요.

그래서 요즘 블로그 질이다 뭐다 해서 나름대로 열심히 하던 와중에.

"에자일 이야기"라는 블로그를 하나 발견했습니다. 알고보니 에자일 이야기의 운영자님은 꽤 유명한 분이더군요. (그런 것도 모르고 살았으니 개발자로서는 지나치게 게을렀던 셈이지요 ㅋㅋ)

그 블로그에 포스팅된 기사를 뒤적거리다보니, "야근 금지"를 모토로 하는 한 회사에 관한 기사가 눈에 들어왔습니다. 알고보니 이 회사도 꽤 유명한 회사더군요 -_-


"대체 너는 아는게 뭐냐"


라고 물으시면 할말없3 ㅜㅜ

야근 금지라... 사실 모든 개발자의 꿈이기도 하죠. 야근 금지는 다른 말로 하면 칼퇴근 정도로 바꿀 수 있겠습니다. 사실 서울에서 직장생활하던 때, 저는 칼퇴근을 해 본 적이 거의 없었습니다. 코딩도 해야하고, 때로는 전화도 받아야 하는 팍팍한 벤처에서 칼퇴근이라는 것은 언감생심 꿈꾸기 민망한 소망이었죠.

+ + +

저의 경험상, 칼퇴근은 '숙련도가 어느 수준 이상 상승한 프로그래머' 혹은 '요구사항의 변화를 엄격하게 통제할 수 있는 환경에서 근무하는 프로그래머' 또는 '을보다는 갑의 지위에 더 가까운 계약관계를 지속적으로 유지하는 회사에서 근무하는 프로그래머'라야 누릴 수 있는 특권적인 혜택입니다.

숙련도가 어느 정도 상승한 프로그래머는, 자신의 코딩 경험을 라이브러리 화 해 놓을 수 있습니다. 그 축적된 라이브러리를 바탕으로, 프로그래머는 자신의 다음 업무에 드는 코딩 시간을 배로 단축할 수 있습니다. 자, 그러면 이 프로그래머가 하게 되는 업무 영역에 큰 변화가 없다고 가정한다면, 이 프로그래머의 순수 코딩 시간은 맡는 프로젝트가 끝날 때 마다 exponential하게 감소하겠군요 :-P

물론, 그러려면 '업무 영역에 큰 변화가 없다'는 가정이 계속적으로 유지가 되어야 합니다. '업무 영역에 큰 변화가 없는' 환경에서 근무하려면, 회사가 하는 업무 형태에 일관성이 있어야 합니다. 제가 근무했던 한 회사의 업무 영역은 제가 근무하는 1년 동안 두 번 바뀌었습니다. 처음에는 웹 개발이었는데, 나중에는 네트워크 장비 개발로 업무 영역이 바뀌었죠. 게다가 근무하는 동안에 다른 업체의 용역 개발을 수행할 일도 있어서, 업무 영역에 변화가 없을래야 없을 수가 없었습니다. 거기다 개발자로서는 처음 맡아보는 업무들이 태반이었으니... 능력 부족으로 자진 퇴사한 뒤 대전으로 튀었습니다만, 지금도 그 때 좀 더 잘해볼껄 하는 후회가 남습니다. 아무튼 각설하고.

용역을 수행하더라도 그 용역의 범위에 일관성이 있으면 좀 낫습니다만, 없는 경우에는 개발자로서는 난감할 때가 많습니다. 이런 코딩도 해야하고, 저런 코딩도 해야하니까요. (심하면 서버 코딩만 전문으로 하다가 GUI 프로그래밍을 하게 되기도 합니다.) 먹고 살자면 그런 일도 생깁니다. 계약서에 명시된 역할이 '을'에 가까울 수록 이런 일은 더 자주 생깁니다. 대개의 경우 '을'은 '갑'이 요구사항을 아무리 자주 바꾸더라도 어쩔 수 없이 응해야 할 때가 많습니다. 요구사항이 바뀌면 코드를 뒤엎어야 하는 일도 늘어나고, 야근 횟수도 늘어납니다. (물론 그런 것 까지 예측하여 프로그래밍을 할 수 있는 수퍼 코더라면야 문제는 또 다르겠습니다만... ㅎㅎ)

이런 문제들을 해결하고 '칼퇴근 맨'이 되기 위해서는, 스스로 부단한 노력을 거듭해서 '자기 분야에서 숙련도가 어느 수준 이상 상승한 프로그래머'가 되거나, '요구사항의 변화를 엄격하게 통제할 능력이 있는 상사' 밑에서 일하던가, '잘 정리된 솔루션을 가지고 있고, 그런 솔루션에 대한 꾸준한 개발 계획을 가지고 있으며, 미래에 대한 비전도 있는' 회사에서 일하거나, '거의 항상 갑의 위치에서 계약을 하는 회사'에서 일하거나, 이도 저도 안되면 '출중한 개발자 및 컨설팅 그룹'에서 일하거나 해야 합니다.

+ + +

저는 대전으로 튄 후 5년간 꾸준히 칼퇴근 맨이었습니다. 저의 경우에는 '거의 항상 갑의 위치에서 계약을 하는 회사'에서 일한 탓도 있었고, 스스로 '요구사항의 변화를 칼같이 짜른' 탓도 있었고(그래서 욕도 엄청나게 얻어먹었습니다 ㅎㅎㅎ), 나름대로 5년동안 한 회사에서 굴러먹다 보니 제 분야에서 '숙련도가 어느 수준 이상 상승한' 탓도 있었습니다. 대전이라는 환경이 서울보다는 좀 살기에 널널한 탓도 있었죠. (어떻게 보면 그게 가장 지배적인 요인 같기도 하군요 ㅋㅋ)

앞서도 말했듯, 칼퇴근은 개발자의 꿈입니다만, 그만큼 성취하기 어려운 목표이기도 해요. 그래서 그런지, 야근금지를 모토로 하는 저런 회사가 참으로 신기해보이기도 하고, 대전에서 보낸 지난 5년동안의 시간이 좀 아깝기도 합니다. 서울에서 좀 치열하게 생활했었으면 아마 저런 회사나 개발자 그룹에서 좀 더 큰 꿈을 펼쳐보겠다... 뭐 이런 생각을 가지고 보다 더 열심히 공부를 했었을지도 모르겠다, 그런 생각이 들거든요.

뭐, 모로가도 서울만 가면 된다고, 어찌 어찌 해서 야근 안하는 프로그래머가 되었으니 어떻게든 목표를 달성한 셈이긴 하지만 말입니다.. ㅎㅎㅎㅎㅎ

아무튼, 제 입장에서만 보자면 야근은 안하는 게 낫습니다. 야근을 상습적으로 하게 되면 낮 동안의 업무 효율이 떨어지고, '야근하면 되지...'하는 생각에 심각한 업무를 밤에 미뤄두게 됩니다. 체력도 별로 안좋아지고요. 낮 동안에 가급적 모든 업무를 재빨리 처리하고, 밤에는 차라리 시간날때 운동을 하거나, 공부를 하거나 하는 것이 더 낫습니다.

제가 한동안 애들을 다 재운 밤 열시 이후에 회사에 나와서 야근을 하고 담날 다시 정상근무를 하는 비정상적인 생활을 한 두어달 했던 적이 있는데요 (소스코드를 날려먹는바람에 어쩔수가 없었습니다 ㅎㅎㅎㅎ 거기다 애도 봐야하고 아흑 ㅜㅜ) 일은 성공적으로 마무리했습니다만 그 뒤에 정신상태가 피폐해져서 한 한달가량은 뭘 제대로 할 수가 없더군요. 공부도 손에 안 잡히고...

그렇다면 프로그래머가 추구해야 할 길은 오직 하나로군요.

공부를 열심히 해서 숙련도를 향상시키는 거... -_-;;

사실 그 이외의 문제는 '환경'의 문제이고, '환경'의 문제는 프로그래머 맘대로 콘트롤 할 수 있는 게 아니니까요.




신고
Posted by 이병준

소중한 의견, 감사합니다. ^^